Commentaires de news :
Maintenance dans la nuit du jeudi au vendredi

Chers auditeurs, bonjour !

J'ai l'honneur de vous annoncer qu'un nouvel épisode des aventures d'Itchy et Scratchy est programmé pour la nuit du jeudi au vendredi de cette semaine. Un épisode sanglant, à l'issue incertaine... comme on les aime !



Petit rappel des faits pour nos nouveaux auditeurs : le Site du Zéro étant un site à fort trafic, il est hébergé sur des serveurs dédiés. Nous possédons plusieurs serveurs, 4 très exactement, à qui nous avons donné des noms des personnages des Simpsons pour mieux nous repérer :

• Bart : notre plus vieux serveur dédié, à l'époque où le site fonctionnait encore sur un seul serveur. Il sert aujourd'hui uniquement à des fins de sauvegarde, et de gestion de services annexes (mails, dns...). A l'occasion, nous le transformons aussi en serveur de jeux pour des soirées jeux ouvertes à tous.
• Lisa : bien plus performant que Bart, ce serveur assure aujourd'hui la fonction de serveur web (Apache 2).
• Itchy et Scratchy : ce sont les 2 serveurs les plus récents, achetés grâce aux bénéfices réalisés par la précédente vente de T-Shirts SdZ. Leur rôle était initialement de servir de serveurs SQL (PostgreSQL) en réplication et load balancing.

Oui mais voilà, le destin en a décidé autrement. La mise en place d'un cluster de serveurs PostgreSQL s'est révélée bien plus ardue que prévu, et le manque de documentation à ce sujet ne nous a pas aidé. Finalement, après de nombreuses tentatives, nous avons décidé de ne faire tourner PostgreSQL que sur Itchy et de ne pas faire de réplication, en attendant d'arriver à mettre en place l'architecture que nous voulions.



C'est un sujet un peu technique, mais pour la culture générale c'est toujours bon de savoir "en gros" de quoi il s'agit.

Alors en quelques mots, l'objectif est d'avoir 2 copies de la base de données du site qui tournent en même temps sur 2 serveurs différents. Ces serveurs seront en réplication maître / maître, ce qui veut dire que les serveurs vont mutuellement observer les changements qui interviennent sur l'un et l'autre pour les répliquer (les dupliquer).
En clair, si on insère une ligne dans une table sur Itchy, Scratchy doit écrire cette ligne en même temps. Pareil pour une mise à jour et une suppression de ligne.

Il s'agit d'une réplication synchrone, c'est-à-dire que la mise à jour doit être simultanée sur les 2 serveurs. Il ne peut pas y avoir de délai car cela poserait alors de graves problèmes d'accès au site (on aurait 2 "versions" différentes du site en même temps). Là, avec une réplication synchrone, on peut littéralement écrire l'équation : itchy = scratchy.

Par ailleurs, Lisa (le serveur web) doit disposer d'un système de load balancing pour rediriger les visiteurs vers Itchy ou Scratchy en fonction de la charge de chacun d'eux. Notre objectif est d'envoyer chaque requête de chaque visiteur vers le serveur le moins chargé à l'instant T pour faire ce qu'on appelle une répartition de charge (load balancing).
Bien entendu, les requêtes sont répliquées sur l'autre serveur immédiatement mais... pas les requêtes de sélection (SELECT) ! Comme ce sont en général les requêtes les plus courantes, ça veut dire qu'on peut répartir la charge pour ce type de requêtes et donc au final réduire les temps de chargement des pages du site.

Il y a par ailleurs une autre application très utile à cette technique : le failover. Si pour une raison ou une autre l'un des serveurs venait à rendre l'âme (crash des disques ou autre), alors l'autre serveur prendrait le relai et encaisserait la charge à lui tout seul. Plus difficilement certes, mais pendant ce temps le site n'est pas coupé et nous pouvons tranquillement travailler à remettre en route le serveur qui est mal en point.


Au final, le schéma des serveurs désiré est le suivant :





Bon, tout ça pour dire que nous avons une bonne nouvelle : cette architecture redevient enfin d'actualité !

Après avoir pas mal galéré il faut bien l'avouer (car c'est assez complexe), nous avons réussi à reproduire ce schéma en local sur nos machines de test dans les bureaux de Simple IT. La réplication synchrone maître / maître marche, le load balancing marche. Nous savons comment faire, il ne reste plus qu'à l'appliquer en production sur le SdZ.

C'est néanmoins une opération délicate qui comporte un certain nombre de risques, aussi nous avons besoin de couper le site pendant que nous mettons en place le cluster de serveurs en réplication. Par conséquent :



Nous ne connaissons pas la durée nécessaire à la maintenance, car en production on a toujours des surprises. Nous le ferons donc dans la nuit pour gêner le moins de visiteurs possible.

Nous vous tiendrons ensuite informés de l'issue de la maintenance, en espérant que tout se passe bien. Si tout va bien comme nous l'espérons, le serveur Scratchy (jusqu'alors inutilisé) remplira alors complètement sa fonction.

A terme, on devrait donc pouvoir bénéficier d'un Site du Zéro plus rapide et plus résistant aux pannes. Il deviendra aisé par la suite de rajouter un serveur au cluster pour augmenter la puissance du site si besoin est. Ce devrait donc être rassurant pour l'avenir du site quant à sa capacité à accueillir de nouveaux visiteurs