La cuisine de Gandi

Kernel et cmdline

Nous vous proposons (enfin!) de choisir la version de votre kernel (parmi une liste qui évoluera), et les options de démarrage associées (cmdline). Les 2.6.18 et 2.6.27 sont les versions "de base" fournies par Xen (backport des patches xen pour la 2.6.27). La 2.6.32 actuellement disponible utilise paravirt_ops et l'implémentation "linux" des patches de Xen.

Nous vous annoncerons les nouveaux kernels disponibles ici même.

Ça se trouve dans "Mode avancé", dans l'interface d'administration du serveur : Options avancées

Et vous donne accès à ceci : Options avancées détail

Coté cmdline, vous pouvez maintenant désactiver selinux au boot, booter en single user, changer le disque et la partition de boot (pratique pour travailler avec des "images"), choisir la console la plus appropriée. Bref, de quoi gérer plus agréablement vos mises à jour ou réparer votre serveur de façon plus autonome.

Si une option vous manque, n'hésitez pas à nous la suggérer.


Cherokee arrive chez Gandi.

Un ami m'expliquait qu'il venait de terminer l'installation d'un serveur web. Ayant décidé de changer et de ne pas utiliser le géant Apache que tout le monde connait, mon ami semblait avoir trouvé une bonne alternative. Portant le doux nom de Cherokee, il paraissait plus léger et plus performant qu'Apache. Voir les benchmarks provenant du site du projet à la fin de l'article. [1]

Personnellement, je ne le connaissais pas du tout, j'avais certainement déjà entendu son nom une ou deux fois, mais je n'y avais pas prêté attention. Pour voir ce qu'il donnait, j'ai décidé de l'installer en local. Je fus agréablement surpris ! Sur une distribution Debian like, l'installation se fait très simplement avec un apt-get install cherokee (ou aptitude).

L'interface web qu'il fournit est claire et plutôt agréable. L'idée est intéressante. Il sera possible d'activer l'interpréteur PHP avec un simple clic, pareil pour l'activation de différents virtualhost ou autres options. Il y a un assistant qui permet d'installer des technologies comme Django, Rails, ou Wordpress, etc.

Je me suis dit que présenter ce projet à une réunion devs chez Gandi pouvait être intéressant, notamment pour les personnes utilisant GandiAI. Le projet a bien été perçu. Après discussion et un coup d'œil rapide sur le code source, rien ne nous a choqués. Cela ne signifie pas qu'il n'y a pas de bugs, toutefois un code propre c'est plutôt bon signe ! Le cœur est écrit en C et l'interface d'administration en Python.

C'est donc de cette manière que Cherokee a fait son apparition chez Gandi et qu'une image a été réalisée, vous permettant ainsi de le tester rapidement.

Nous avons ajouté une distribution en mode expert avec Cherokee de préinstallé... il vous suffit de choisir cette distribution lors de la création de votre serveur. Je vous rappelle aussi que si vous n'avez pas encore essayé notre service, vous pouvez faire une demande sur notre formulaire de demande de test.

Pour avoir plus d'informations sur Cherokee, vous pourrez vous rendre sur le site du projet . Un article lui a également été consacré dans Gnu/linux magazine France par Carl Chenet dans le numéro 125.

Notes

[1] benchmark.jpg benchmark-0.8


Le courriel s'est fait la malle

Okay, il fallait que je pousse un jeu de mots idiot comme d'habitude, mais c'est la meilleure traduction que j'ai trouvée pour introduire le post de Leland, que je recommande d'ailleurs dans sa version originale pour les anglophones, il est ici.

Comme beaucoup le savent maintenant, la plateforme de Mail Gandi a subi, ces deux dernières années, de récurrentes baisses de performance tous les deux mois en moyenne. Comme nous vous l'avons annoncé sur le Bar, nos équipes ont travaillé afin de vous offrir une nouvelle plateforme Mail bien plus robuste. Celle-ci est le résultat d'un investissement de ressource considérable sur plusieurs mois. Je suis aujourd'hui, heureux de vous dire que la nouvelle plateforme est totalement opérationnelle et que tous les clients Gandi Mail sont migrés dessus (la migration à elle toute seule a pris près de six semaines). Nous avons pris la décision de migrer les clients au fur et à mesure, en plusieurs semaines afin de minimiser l'éventuel impact sur nos clients, et pour la plupart (avec très peu d'exceptions), la migration complète s'est passée parfaitement sans même que personne ne s'en rende compte ;)

Bref, sans plus attendre, jetons rapidement un œil à cette nouvelle plateforme Mail et regardons ce qui a changé dans Gandi Mail V2. Oh, et juste avant de commencer, cet article va être (au grand désespoir du traducteur) quelque peu technique de temps en temps, avec l'utilisation (NDT: abusive) de quelques acronymes et autres expressions geeks. Ne vous inquiétez pas, vous saurez d'ici peu ce que nous autres, barbus technophiles, échangeons comme bavardage quotidien ! ;)


10 ans de Gandi: retour d'expérience

À l'occasion des dix ans de Gandi, l'idée un peu folle de donner, sur dix jours, 55000 domaines, a posé une question pratique. Comment, en ouvrant les vannes d'une telle opération, maintenir une qualité irréprochable sur le site ? L'ambiance festive aurait aussi bien pu se transformer en cauchemar pour nos clients si ils avaient été privés d'accès à leurs interfaces de gestion.

La décision fût donc prise d'héberger l'événement sur un site dédié. Occasion rêvée pour se mettre un peu à la place de nos clients, et utiliser notre infrastructure d'hébergement. Règles du jeu : on utilise exclusivement les outils fournis au client, on prépare une archi qui monte en charge facilement, ça ne doit pas coûter un bras, ça peut illustrer notre flexibilité légendaire.


Keep it simple, stupid

De la décision à l'implémentation, on avait une semaine. L'idée charmante de monter un site "cloudish" à base de technos modernes, et peu maîtrisées, est donc oubliée d'office. Pour être honnête, vu les délais, le développeur désigné d'office se voit choisir la techno : "là où t'es à l'aise, tu as une semaine". Ça sera PHP/mysql, ce qui n'est pas du goût de tout le monde ! Mais permettra de sortir le site testé et dans les temps.

Pour tenir une charge correcte, plusieurs serveurs seront nécessaires.  Premier rappel de nos imperfections, Gandi ne fournit pas de load balancing ! Qu'importe, on ira donc sur un round robin DNS, à petit TTL pour pouvoir sortir facilement un frontal cassé de la production.

Notre distribution pour l'occasion, sera une ubuntu 9.10 - parce qu'elle est assez à jour, et qu'elle utilise un kernel 2.6.27.


Multiplier les petits serveurs

La meilleur façon de monter en charge sur notre infrastructure est d'isoler fonctionnellement l'architecture en nombreux petits serveurs. Là où nous assurons un minimum de "scalabilité" verticale (vous pouvez augmenter dynamiquement la RAM, le CPU alloués à un serveur), c'est à l'architecture de prévoir la scalabilité "horizontale".

Ainsi, on peut facilement monter les ressources là où les bottlenecks se font sentir, et ajouter/ou déplacer des parts d'un serveur vers l'autre lorsque la puissance allouée le demande. Les avantages des "nombreux petits serveurs" sont multiples :

  • chaque serveur bénéficie au minimum d'un core CPU en burst (oui, un core entier, même sur une part : c'est nouveau)
  • la redondance est assurée, et vos parts s'étalent un peu aléatoirement sur des centaine de serveurs physiques
  • particulièrement en environnement virtualisé, la performance mémoire est meilleure sous 1G de RAM
  • si vous avez 4 serveurs d'une part, au lieu d'un gros de 4 parts, ils montent à 8x4 parts dynamiquement, ou 24x4 parts en un reboot, tout ça sans toucher à l'archi - là ou le gros s'arrête à 8 sans reboot, ou 24
  • les ressources sont faciles à déplacer vers les serveurs qui en ont besoin.

Nous partons sur l'infrastructure simpliste :

  • 24 (!) serveurs d'une part, pour gérer le web et PHP : 10 en anglais, 10 en français, et 2 + 2 pour l'IPv6
  • 2 serveurs de 4 parts, des memcached répliqués pour soulager la DB et gérer les sessions
  • 1 serveur mysql de 4 parts, qui contiendra les coupons pré-générés (ils tiennent en RAM, la base doit théoriquement s'ennuyer)

Après quelques belles surcharges et un bout de code revu, la base de donnée sera finalement épargnée au maximum par memcached (voir chapitre « un code léger… »)

Soit 36 parts, pour une durée de dix jours : environ 140 euros.

C'est un admin qui s'usera les doigts sur notre site pour créer, et configurer les 24 serveurs en parallèle. Visiblement, la sortie de l'API hosting ou une fonction dans l'interface web seraient les bienvenus. (Merci à cssh pour l'occasion).


Sécuriser (un peu) les machines

Une distribution par défaut mérite toujours quelques retouches. Exporter mysql sur le réseau « public » du hosting gandi nous ennuyait un peu. À grands coups de netstat, fermer les services inutiles qui écoutent sur un port public. Avec l'aide de tcpwrappers (hosts.allow, hosts.deny), on ferme toutes les interfaces « privées » (sshd, mysql réservé aux machines frontales du web).

Restera à bien faire attention au code php et à nos queries mysql : le meilleur moyen d'éviter les injections est encore de binder tous les params après un prepare(). En plus, ça décharge la DB lorsqu'on effectue plusieurs execute.

Un détail important : notre site autorisant l'envoi de mail à un destinataire « arbitraire », il était critique de limiter au maximum son exploitation potentielle par un spammer malin : restrictions du nombre d'envoi par coupon, au minimum, et monitoring.


Prévoir l'environnement de dev et le déploiement

Partager les données entre les sites, c'est ajouter un "single point of failure" et un point de contention à l'archi. Nous optons donc pour un déploiement "local" à chaque serveur du contenu du site. Un site de développement et de "staging" sur une VM sert à tester et développer les mises à jour. Un script et quelques rsync permettent de déployer l'ensemble sur tous les frontaux de l'architecture. On a dit simple !


Surveiller ses ressources

Quelques minutes avant l'opération, pour prévenir plutôt que guérir, la totalité des machines virtuelles sont augmentées d'une à deux parts. En utilisant l'interface des stats, dès le premier jour, on peut constater l'ennui total qui habitait les machines virtuelles:

Cpu sur un front FR Interface réseau sur un front FR

Il aurait été malin, à ce moment précis, de revenir à une part par machine. Ou d'exploiter gandi "autoflex", ou encore, vu le type de charge observée, de préparer des flexs programmés pour les heures de lâcher des coupons ! Malheureusement, beaucoup de monde sur beaucoup de ponts, on a raté l'occasion de vous faire cette belle démonstration (écono-techno-(éco ?)logique).


Un code léger vaut mieux que mille CPU costauds

Même si nous avions à notre disposition plusieurs milliers de CPU et beaucoup de teras de RAM, mardi fut suffisamment chaotique pour qu'on en reparle ici : après un lundi très bien tenu en charge, le plan d'exécution de notre unique SELECT COUNT changea brutalement et devint terriblement plus lent (300ms). Avec foi, nous avions pensé que ce query « unique », sur une table présente complètement en mémoire, ne poserait pas de problème : il était donc exécuté sur toutes les pages du site. La concurrence d'accès avec les UPDATEs des coupons finit par avoir raison de la base qui, malgré des stats systèmes proches de l'idle, entra discrètement en contention de lock.

La réaction habituelle est d'ajouter des parts pour monter en charge. C'est une solution temporaire acceptable, mais ça ne suffit pas !

Un analyse système, une remise en question du code, et une utilisation salvatrice de memcached permit de retrouver des performances acceptables. Une modification des queries utilisés aurait peut-être pu faire l'affaire également.

Une moralité à cet épisode: le code, les indexes, l'architecture, (…) sont les garants de votre montée en charge, et si ils sont « cpu friendly » vous épargneront, sinon une catastrophe, au moins un achat de parts inutiles.

En plus, comme on dit ici en plaisantant, c'est écolo.


Quelques chiffres


  • 36 parts, mais on aurait pu tenir sur moins (snif)
  • 5% de CPU en peak
  • 4000 requêtes par frontal dans la première minute de chaque heure de pointe (environ 1400 req/seconde au total)
  • un minimum de 11 secondes pour donner 1000 coupons
  • pour le même nombre de coupons, un maximum de 40 minutes, pendant l'incident.

Que faire si son serveur ne répond plus ?

Comme vous le savez probablement déjà, notre plateforme vous met à l'abri d'une panne matérielle sur votre serveur.

En effet, en cas de soucis sur la machine ou si nous suspectons un problème à venir (température anormale, mémoire corrompue...), votre "serveur" sera migré automatiquement sur une autre machine. Par contre, si vous avez un problème interne à celui-ci et qu'il ne répond plus, c'est alors souvent à vous d'intervenir.

Penser infrastructure web

Comme vous le savez, notre système est flexible et vous permet de passer à n'importe quel moment et autant de fois que vous le souhaitez d'un serveur sur 1 part (1/64 de machine + 1/64 en boost, 256Mo de Ram) à un serveur de 16 parts (1/4 de machine + 1/4 en boost, 4Go de Ram), mais nous avons de plus en plus de clients qui après le lancement de leur service sont victimes de leur succès et se retrouvent en limite d'utilisation des 16 parts et viennent nous demander des serveurs de 24 ou 32 parts.

Notre réponse est souvent la même, nous leur conseillons alors de penser infrastructure web plutôt que serveur web.

En effet, notre solution vous permet de créer autant de serveurs que vous le souhaitez sur les ressources souscrites dans votre compte hébergement, la solution optimale consiste donc à séparer vos services pour une plus grande flexibilité et une plus grande robustesse.

Mais le plus simple est de prendre un exemple concret : comme certains le savent déjà, nous soutenons l'association Millenium pour la promotion des jeux et loisirs numériques en ligne.

Le succès grandissant du site millenium.org nous poussait à rapidement repenser l'architecture du site pour tenir la charge (de nombreuses vidéos, 17 000 visiteurs uniques/jours). Pour ne rien vous cacher, nous avons quelques priorités et projets Gandi à régler avant de nous occuper du site.

Suite à une importante mise à jour d'un des jeux suivis par Millenium (NDLR: WOW patch 3.1), et même si nous avions anticipé une charge importante en passant le serveur sur 16 parts, celle-ci a vite dépassé nos estimations avec plus de 50 000 visiteurs uniques le premier jour et surtout presque autant les jours suivants.

Le site recevait alors entre 500 et 1000 visiteurs en simultané, ce qui n'est pas viable pour un serveur unique de type LAMP avec, de plus, de très nombreuses vidéos. Nous avons donc changé l'infrastructure immédiatement, pour passer d'un modèle sur un serveur unique (qui est souvent le choix au démarrage) à un modèle en infrastructure. Nous sommes passés d'une extension verticale (plus de puissance) vers une extension horizontale (plus de serveurs) :


Comme le montre ce schéma, nous avons donc sorti la base de données sur un serveur à part et dupliqué le serveur web sur 2 machines, la répartition de charge se faisant via la zone DNS du domaine. Nous pouvions aussi envisager de dédier un serveur d'une part à la répartition de charge, mais cette solution était un peu plus longue à mettre en place. Dans notre cas, il a fallu 2 minutes pour ajouter des parts sur le compte, 6 minutes pour créer les 2 serveurs, 10 minutes pour transférer les données et 2 heures environ pour configurer les services.

Aujourd'hui, la plateforme tient 1 million de visiteurs uniques par mois pour plus de 3 millions de pages vues, ce qui est une bonne chose. Mais le mieux c'est que maintenant la plateforme est évolutive. Si la base de données souffre, il nous suffira d'augmenter le nombre de parts allouées au serveur, et si les frontaux web arrivent à saturation, il nous suffira d'en ajouter un.

Si vous vous trouvez confronté à ce genre de problématique, n'hésitez pas à nous consulter, nous nous ferons un plaisir de vous conseiller.

page 2 de 2 -