Bonjour,

Après les travaux sur les serveurs SQL, il nous est possible maintenant de faire évoluer l'offre. En effet, nous avons revu notre système de gestion d'espace utilisé pour vos bases et le système d'alerte et d'information en temps réel (via le manager) ceci afin d'éviter le dépassement du quota de vos bases. Le système actuel fonctionne parfaitement avec plus de 250'000 bases et il a été pensé pour gérer plusieurs millions de bases.

Nous avons travaillé avec certains clients qui ont des bases de données très gourmandes en ressources ou/et en espace (100Mo, 250Mo et plus de 1Go) pour voir quels sont les propres limites de serveur MySQL 4 et 5 en MyISAM et InnoDB. Aussi il y a quelques mois, nous avons lancé SQLplan pour des bases très gourmandes ce qui nous a donné une certaine expérience de gestion de serveur avec peu de bases (moins de 40 bases) à forte charge dont la taille a été très importante.

Nos conclusions sont suivantes:

• Pour les bases SQL à forte charge, si la taille dépasse 500Mo, les corruptions de bases se font plusieurs fois par jour. Nous avons mis en place plusieurs scripts qui vérifient toutes les bases et les réparent automatiquement avant que le serveur MySQL ne plante. Le résultat de fonctionnement de ce scripts est que les serveurs ont gagné en fiabilité. En effet, MySQL plantait au bout d'un certain moment, surtout en 64bits, s'il attaquait une base corrompue. Depuis plus d'1 semaine, nous n'avons plus de problème de MySQL qui plante.
• 93% des bases SQL que nous hébergeons n'ont pas été indexées. Nous avons effectué cette opération ce qui a par exemple permit d'accélérer le calcul de quota via la commande "show table status". En effet, certaines bases ont été tellement mal construites qu'on ne pouvait pas savoir la taille occupée par la base. Ce problème est désormais résolu. Grâce à l'indexation généralisée, la charge de serveur a été divisée par 3 !
• Nous avons simulé l'augmentation de la taille de bases SQL par défaut dans nos offres pour proposer 100Mo par base et nous nous sommes rendus compte que ceci était trop risqué pour garantir la qualité de service. En effet, chaque serveur fonctionne avec un coefficient de sécurité entre 2 et 5. Augmenter la taille systématique à 100Mo remettrait en cause ce principe de sécurité. Par contre, il est possible d'accepter quelques bases importantes par serveur surtout grâce au fait que l'ensemble des serveurs tournent avec 4Go ou 6Go de RAM.

L'évolution des offres:
• Les paramètres de base des offres ne changent pas: 60gp, 300gp, 1000gp = 1 base de 25Mo (3 conn/base) 90plan = 5 bases de 40Mo (10 conn/base) 240plan = 15 bases de 45Mo (20 conn/base) 720plan,mediaplan,xxlplan = 25 bases de 50Mo (20 conn/base)
• Il est possible d'augmenter la taille d'une base SQL pour passer à SQLarge:
  • 100Mo pour 5Euros HT/mois
  • 250Mo pour 10Euros HT/mois
• Pour les bases SQL dont la taille dépasserait 250Mo, la solution est de passer en serveur dédié (c'est la solution la plus économique). Nous ne proposons pas de solution en hébergement mutualisé à cause d'instabilités de MySQL avec des bases de forte taille.
• Nous allons arrêter le SQLplan sous environ 1 mois. En effet, 80% des bases ont une taille plus importante que 250Mo et posent de graves problèmes de stabilité du serveur et donc de qualité de service, surtout lorsque le client l'utilise à partir d'un serveur dédié. Nous avons à gérer pas mal des plaintes de clients alors qu'en tout le service héberge moins de 250 bases SQL (sur plus de 250'000 bases qu'on héberge) ! Ceci nous fait du tord au niveau de l'image de l'entreprise. Les bases inférieures à 250Mo vont pouvoir être migrées sur le SQLarge avec un changement de serveur et donc possibilité de passer en MySQL 5.

Notre démarche est une démarche de recherche de qualité de service. Nous mettons l'accent particulier sur le temps de réponse de chaque serveur SQL 24 heures sur 24 heures. Les graphes sont publics et disponibles sur http://smokeping.ovh.net . De plus certains serveurs vont être migrés en bi-quad-xeon afin de généraliser un coefficient de sécurité entre 3 et 4. Ceci permet d'avoir de la puissance, nécessaire pour assurer la qualité de service lorsque par exemple un site se fait aspirer.

Le service SQLarge va être disponible à partir de demain. Les bases SQL dont la taille dépasse le quota ont déjà reçues des emails avec des warning. Nous allons prendre les dispositions à partir de demain pour envoyer systématiquement les emails et à partir de lundi prochain, nous allons commencer à contacter les bases qui dépassent le quota.

Depuis 1 semaine, nous remarquons une très bonne stabilité de chaque serveur SQL et nous pensons que sous 10 jours, la qualité de service redeviendra à nouveau parfaite et pour longtemps.

Amicalement
Octave