La vidéo + le making of

L’infrastructure VDM : MySQL

Par Maxime, le 10 mars 2010.

Depuis des mois je promets une série d’articles qui ne va peut-être pas intéresser grand monde, mais qui aura le mérite d’exister et de soulager ma conscience (ma mère m’a dit que ce n’était pas joli de ne pas tenir ses promesses).

Contrairement à ce que certains laissent penser, je fais quelque chose de mes journées. Je suis développeur Web, mais aussi administrateur système. Créer puis s’occuper de l’hébergement de sites comme VDM et FML n’arrive pas tous les jours, et j’ai gagné beaucoup d’expérience ces 12 derniers mois en montant une infrastructure qui accueille chaque jour plus de 3 millions de visiteurs.

L’infrastructure que j’ai montée pour VDM/FML

Dans cette série de billets (normalement trois en comptant celui là), je vais vous raconter ce qui se passe derrière les URL viedemerde.fr et fmylife.com, qui représentent 98% du trafic de l’infrastructure d’hébergement de ma société, Beta&Cie. Ces articles n’ont pas pour vocation de me vanter ou de dire au monde entier que ma solution est la meilleure, c’est juste ma solution et elle marche bien jusqu’à maintenant.

Passons au premier sujet : Les serveurs MySQL.

Réplication circulaire

Mes sept petits bouts de chou.

Comme le montre le schéma, mes sept serveurs sont configurés en réplication circulaire. C’est à dire que chacun est maître et esclave à la fois (pas de connotations sexuelles ici, merci !). s1 est donc maître sur s2, mais il est esclave de s7.

Cette configuration a l’avantage de bien fonctionner derrière un load balancer puisque chaque serveur a le droit d’écriture. C’est donc transparent pour le développeur qui n’a qu’à renseigner l’IP du load balancer dans sa connexion à MySQL et travailler comme s’il n’avait qu’un seul serveur.

L’inconvénient est un inconvénient de taille. Comme les requêtes s’exécutent comme dans une ronde, si un serveur plante, toute la ronde est cassée et plus rien ne se réplique. Il faut donc avoir du bon matériel, et au cas où ça arrive quand même, agir très vite pour éviter que les utilisateurs ne râlent :)

Une petite astuce pour éviter que votre réplication ne s’arrête pour des raisons connes : Je fais ignorer par mes serveurs systématiquement les erreurs 1062 (nouvelle entrée avec le même ID) et 1053 (déclenchée quand le serveur maître s’éteint ou redémarre) :

slave-skip-errors=1062,1053

Pour diminuer les latences de réplication il est aussi important d’avoir un bon réseau…

Réseau VLAN

Au delà de l’onomatopée, un VLAN est l’abréviation de Réseau Local Virtuel (RLV ça le faisait pas, hein ?). Il permet de créer un réseau indépendant du reste des machines du réseau où est hébergée l’infrastructure. Concrètement chaque serveur possède deux interfaces physiques :

# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:30:48:b9:42:e2
          inet addr:91.191.146.199  Bcast:91.191.146.255  Mask:255.255.255.192

eth1      Link encap:Ethernet  HWaddr 00:30:48:b9:42:e3
          inet addr:10.191.146.199  Bcast:10.191.146.255  Mask:255.255.255.0

eth0 a l’adresse IP 91.191.146.199 qui est atteignable de l’extérieur du réseau, alors que eth1 a l’adresse IP 10.191.146.199 qui est interne au VLAN et qui par conséquent ne peut communiquer qu’avec ses copines du même VLAN qu’elle.

Avoir ses serveurs en VLAN diminue donc la latence entre les serveurs, la réplication se fait plus rapidement et avec plus de sécurité puisqu’aucun paquet ne sort de votre réseau local. Deux avantages indéniables qui devraient vous faire quitter OVH choisir un hébergeur qui fait du VLAN ! En effet les réseaux virtuels se configurent au niveau des routeurs/switches, il faut donc choisir un hébergeur qui puisse le prendre en charge.

Disques SSD

Pour économiser un certain nombre de machines dans ma réplication circulaire et ainsi réduire le nombre de défaillances matérielles, j’ai très vite décidé d’utiliser du SSD pour héberger les données de mes bases. Au début j’ai eu des X25-M chez OVH (mon ancien hébergeur), qui est le moyen de gamme du SSD, puis je suis passé récemment au X25-E, la version haut de gamme, comme le montre ce benchmark par SD-France, mon gentil hébergeur :

Le X25-E dépasse largement tous ses concurrents en terme d’écriture et de lecture de disque. Cela assure évidemment un meilleur temps de réponse sur les requêtes, différence qui se ressent lorsque l’on traite 15 000 requêtes par seconde…

Les deux inconvénients de cette méthode :

• La capacité. La plus grande taille disponible est 64 Go, ce qui peut paraître beaucoup pour de simples bases de données, mais qui se remplit vite quand le site repose sur beaucoup d’anecdotes / commentaires et surtout votes.
• Le prix. Les disques SSD X25-E sont encore très chers, même s’ils économisent parfois de nouvelles machines, je me fais taper quand j’en demande des nouveaux :D

Optimisations

Comme le disque SSD est déjà pas mal occupé à traiter les requêtes SQL, la copie des résultats de SELECT sur les bases temporaires dans /tmp (configuration par défaut) est fortement ralentie. En parallèle la RAM n’est en général pas utilisée à fond. Il est donc judicieux d’utiliser la RAM restante comme espace pour les fichiers temporaires, grâce au système de fichier tmpfs :

mkdir /tmpfs
mount tmpfs /tmpfs -t tmpfs

Vérifiez que votre nouveau répertoire fonctionne correctement, puis modifiez la configuration de votre my.cnf pour la valeur suivante :

tmpdir = /tmpfs

Ne pas oublier de rajouter le montage du tmpfs dans votre /etc/fstab, pour éviter les problèmes au reboot :)

Avec tout ceci, nous arrivons à traiter vaguement ces quelques données :

• 2 millions d’anecdotes, 8000 nouvelles par jour
• 1,7 million de commentaires, 5000 nouveaux par jour
• 630 millions de votes, 850 000 nouveaux par jour

Voilà mes petits pandas, je pense avoir couvert pas mal des aspects principaux « caractéristiques » de l’infrastructure au niveau de MySQL. Mais j’ai sûrement oublié beaucoup de choses, alors n’hésitez pas si vous avez des questions.

Pas de date pour le prochain article mais j’espère la semaine prochaine.

Ce billet a été écrit le 10 mars 2010 à 17:35 et rangé dans Développement, Ma vie, PHP, Web. Vous pouvez voir toutes les réponses à ce billet via le flux RSS 2.0. You can skip to the end and leave a response. Pinging is currently not allowed.

Realistically Light and Render Interior Scenes using 3ds Max and Vray Feb 19th in 3D Art, Autodesk 3Ds Max, Lighting, Rendering by Pratik Gulati

Discover the secrets behind properly lighting and rendering interior scenes with 3ds Max and Vray in this easy to follow, step by step walkthrough. Scene setup, modeling, texturing, lighting, and rendering for realistic output will all be discussed, so there is literally something in here for everyone!