Comme vous le savez peut-être, nous avons décidé dès le lancement d’alwaysdata de redonder nos serveurs principaux dans un second datacenter, en temps réel (via DRBD). Le but était de pouvoir rapidement pallier les pannes graves si besoin, en basculant le cas échéant l’activité sur le second serveur.
Ce système « de secours » a très rarement servi pour une raison simple : nous n’avons quasiment jamais eu des pannes matérielles importantes. Nous avons déjà subi des pannes assez longues, mais elles furent causées soit par des soucis logiciels (notamment la migration difficile vers la nouvelle architecture, en février dernier), soit par des perturbations réseau.
Ce système de redondance présente plusieurs défauts qui se sont révélés au fil du temps. Le premier, c’est que le surcoût engendré est important, puisque nous devons quasiment doubler le nombre de serveurs utilisés. Le deuxième, c’est que notre fournisseur de secours ne propose pas toujours des configurations équivalentes aux serveurs primaires, ce qui engendrerait des problèmes de performances en cas de bascule. Le troisième, c’est que la procédure de bascule est complexe, manuelle, et pas assez testée.
Une migration totale de tous nos serveurs en cas de panne du datacenter ou de son réseau serait donc longue et périlleuse. Or ces derniers jours, notre fournisseur principal a connu des pannes répétées, dont la plus grosse s’est produite samedi soir avec environ 50 minutes de quasi-indisponibilité. Deux autres pannes de 30 et 25 minutes avaient eu lieu en début de mois, heureusement en pleine nuit.
Cela n’impacte pas notre confiance envers notre fournisseur, malgré cette période difficile. Nous avons connu la nôtre en février dernier. Ces épisodes sont acceptables à nos yeux dès lors qu’ils restent rares, que la communication est transparente, et que des mesures sont prises pour que cela ne se reproduise plus.
De notre côté, nous avons commencé dès le mois de juin dernier (avant les indisponibilités récentes, donc) à repenser notre système de redondance pour éliminer les défauts sus-cités. Nous sommes encore en plein développement, mais il nous semblait important, surtout en ce moment, de vous en faire part.
Ce nouveau système repose sur le service EC2 d’Amazon plutôt que des serveurs physiques. Cela nous permet une économie financière substantielle, n’ayant plus besoin de faire tourner des serveurs secondaires 24h/24. Par ailleurs, nous allons travailler sur le processus de bascule afin qu’il soit plus simple, plus automatique.
EC2 va nous permettre également de dupliquer nos serveurs en production en toute simplicité. Cela pourrait servir pour tester des nouveaux déploiements sans risque, simuler des pannes, et d’autres choses sympathiques. Nous aurons l’occasion d’en reparler d’ici là.
Nous espérons mettre ce nouveau système de redondance en production pour la rentrée, mais comme toujours, les dates sont à prendre avec précaution…
Comme vous le savez peut-être, nous avons décidé dès le lancement d’alwaysdata de redonder nos serveurs principaux dans un second datacenter, en temps réel (via DRBD). Le but était de pouvoir rapidement pallier les pannes graves si besoin, en basculant le cas échéant l’activité sur le second serveur.
Ce système « de secours » a très rarement servi pour une raison simple : nous n’avons quasiment jamais eu des pannes matérielles importantes. Nous avons déjà subi des pannes assez longues, mais elles furent causées soit par des soucis logiciels (notamment la migration difficile vers la nouvelle architecture, en février dernier), soit par des perturbations réseau.
Ce système de redondance présente plusieurs défauts qui se sont révélés au fil du temps. Le premier, c’est que le surcoût engendré est important, puisque nous devons quasiment doubler le nombre de serveurs utilisés. Le deuxième, c’est que notre fournisseur de secours ne propose pas toujours des configurations équivalentes aux serveurs primaires, ce qui engendrerait des problèmes de performances en cas de bascule. Le troisième, c’est que la procédure de bascule est complexe, manuelle, et pas assez testée.
Une migration totale de tous nos serveurs en cas de panne du datacenter ou de son réseau serait donc longue et périlleuse. Or ces derniers jours, notre fournisseur principal a connu des pannes répétées, dont la plus grosse s’est produite samedi soir avec environ 50 minutes de quasi-indisponibilité. Deux autres pannes de 30 et 25 minutes avaient eu lieu en début de mois, heureusement en pleine nuit.
Cela n’impacte pas notre confiance envers notre fournisseur, malgré cette période difficile. Nous avons connu la nôtre en février dernier. Ces épisodes sont acceptables à nos yeux dès lors qu’ils restent rares, que la communication est transparente, et que des mesures sont prises pour que cela ne se reproduise plus.
De notre côté, nous avons commencé dès le mois de juin dernier (avant les indisponibilités récentes, donc) à repenser notre système de redondance pour éliminer les défauts sus-cités. Nous sommes encore en plein développement, mais il nous semblait important, surtout en ce moment, de vous en faire part.
Ce nouveau système repose sur le service EC2 d’Amazon plutôt que des serveurs physiques. Cela nous permet une économie financière substantielle, n’ayant plus besoin de faire tourner des serveurs secondaires 24h/24. Par ailleurs, nous allons travailler sur le processus de bascule afin qu’il soit plus simple, plus automatique.
EC2 va nous permettre également de dupliquer nos serveurs en production en toute simplicité. Cela pourrait servir pour tester des nouveaux déploiements sans risque, simuler des pannes, et d’autres choses sympathiques. Nous aurons l’occasion d’en reparler d’ici là.
Nous espérons mettre ce nouveau système de redondance en production pour la rentrée, mais comme toujours, les dates sont à prendre avec précaution…
Alwaysdata always à la pointe !
Il n’y a/avait pas trop de latence avec DRBD ?
Pourquoi Amazon EC2 plutôt qu’un autre d’ailleurs ? Il me semble que l’offre Rackspace est plus intéressante / personnalisable. Sans compter qu’ils promeut openstack.org :)
Nicolas : notre DRBD est configuré en asynchrone pour ne pas attendre que chaque octet ait bien été écrit sur le serveur secondaire avant de valider l’écriture sur le primaire. Du coup, la latence n’a pas d’effet sur les performances du serveur primaire (i.e. les performances au quotidien).
Quand je parle de synchronisation temps réel, c’est donc une approximation, on a en fait une fenêtre de quelques millisecondes de données potentiellement perdues en cas de bascule subite. À moins d’utiliser systématiquement fsync, de toute façon, un simple reboot inopiné d’un serveur causerait plus de pertes potentielles qu’une bascule vers le serveur secondaire.
Concernant EC2, nous avons étudié les offres concurrentes avec attention, mais aucune ne nous permettait de faire ce dont nous avons besoin. En l’occurrence, Rackspace a deux gros problèmes : le premier, c’est qu’ils ne disposent pas de l’équivalent aux EBS EC2, à savoir des disques détachables que l’on peut passer d’un serveur à l’autre, et qui est à la base de notre mécanisme de bascule. Le second, c’est que leur plus gros serveur n’a que 16 Go de RAM et 620 Go de disque, alors qu’on a besoin de 48 Go de RAM et 1 To de disque (notre plus gros serveur en ce moment).
Super idée que le Cloud pour cette utilisation. Je m’étais toujours demandé si le réseau secondaire était dimensionné comme le principal. Il est vrai que pour une panne qui trainerait en longueur cela pourrait être gênant si ce n’est pas le cas. Et n’importe comment, tant qu’à avoir la chance d’avoir son site toujours en ligne même en cas de panne qui affecte le Datacenter, c’est appréciable de voir les performances auxquelles nous sommes habitués êtres toujours la aussi.
La question du coût m’intriguait aussi. Maintenant il ne reste pour moi qu’une interrogation : jusqu’où pourra aller la rapidité de bascule en cas de besoin. Mais n’en dites pas plus : il n’y aurait plus de suspens.
shaitan : le temps de bascule est difficile à estimer et dépend du type de panne.
Le premier délai, c’est le temps qu’il faut à un admin pour être sur le problème. En pleine journée, ça peut être de l’ordre de la dizaine de secondes ; à d’autres moments, ça peut être un peu plus long. La bascule est une opération manuelle, et il n’est pas envisagé de la rendre automatique.
Ensuite, pour une panne qui n’affecte pas le réseau, le temps de bascule sera très court, probablement moins de 5 minutes. Il faut tout d’abord démarrer le serveur secondaire sur EC2. Nous prenons ensuite l’IP du serveur en panne, la déplaçons vers un serveur fonctionnel chez le même prestataire, puis de là mettons en place un proxy transparent qui redirige vers le serveur secondaire EC2.
En cas de panne globale du prestataire primaire, ça va être plus long. Pour deux raisons : d’abord, il va falloir s’occuper de démarrer de nombreux serveurs secondaires. Il faut qu’on automatise au maximum l’opération, guère plus qu’un script à lancer. Ensuite, nous allons devoir effectuer un changement des DNS pour que les sites/services pointent vers les nouveaux serveurs secondaires. On a un TTL très bas (5 minutes), mais dans la pratique tout le monde ne voit pas les changements aussi vite.
Les simulations que nous allons faire nous permettrons de rôder tout cela et d’avoir une meilleure visibilité du temps réel dont nous avons besoin pour la bascule.
Entendu, le cas de la panne globale du prestataire primaire est couvert aussi, c’est une question que je m’étais déjà posé.
Supposons une panne panne partielle dans un premier temps qui fait que vous activez la méthode du proxy transparent. La panne s’aggrave et le prestataire primaire subit une panne globale, je suppose que cela ne gêne en rien d’appliquer la méthode du changement de DNS ?
Alwaysdata is so good!!!!
@Cyril : merci pour le retour – sympa si DRDB, même à travers le réseau ne souffre pas trop de latence / pénalise pas trop :)
Merci pour le retour sur EC2 vs Rackspace ; c’est sur que ça dépend des besoins. Quand j’ai du envisager des solutions « cloud », je n’avais pas les mêmes besoins que vous :)
shaitan : même avec une panne partielle, on changera de toute façon les DNS. Le proxy ne sert finalement qu’à réduire le temps de propagation DNS au minimum, puisque l’ancienne IP continue de fonctionner.
Ah, je comprends (un peu) mieux. C’est de votre faute aussi, à force d’être choyés en fini en pleine régression infantile :)
EC2 va t’il par exemple vous permettre de simuler des montées en charge importante ? J’ai vu que Myspace en avait fait cette utilisation : http://www.haute-disponibilite.net/2010/03/07/test-de-charge-simuler-1-million-dutilisateurs-sur-myspace/
Oui, EC2 va nous permettre beaucoup de choses, notamment des simulations de montée en charge. D’autres choses encore plus sympas aussi, j’espère, mais gardons des surprises ;)
Je vais peut-être dire une bêtise, mais pourquoi ne pas plutôt passer vos serveurs principaux sur EC2 ? Le gros avantage de ce système est de ne plus avoir à se soucier du hardware (fini ‑en théorie- les pannes matérielles), et de pouvoir effectuer assez rapidement une migration vers une « instance » plus puissante lorsque c’est nécessaire.
Harry : d’une part, la fiabilité d’EC2 n’est pas non plus sans faille, en témoignent par exemple les déboires de Bitbucket. Deuxièmement, EC2 est très, très loin de proposer la souplesse d’un vrai serveur dédié. On est vraiment dans un système très spécifique, « propriétaire », souvent limité. Jusqu’à il y a moins d’un mois, on ne pouvait pas utiliser ses propres noyaux Linux ! Enfin, EC2 est considérablement plus cher.
Niveau avantages, il n’y a pas grand chose. La migration vers une instance plus puissante m’est inutile : quand on a besoin de davantage de puissance, on ajoute un serveur. Par ailleurs, les quelques vrais avantages d’EC2, je vais les avoir via notre mécanisme de redondance. Je pense par exemple à la simplicité d’ajouter/supprimer des serveurs pour faire des tests ou des simulations. Ou encore les snapshots.
Oh et accessoirement, je préfère avoir un prestataire français, non par chauvinisme, mais parce que c’est la langue que je maitrise le mieux :)
Sur :
« » »
Oh et accessoirement, je préfère avoir un prestataire français, non par chauvinisme, mais parce que c’est la langue que je maitrise le mieux :)
« » »
Il n’y a pas des contraintes légales aussi ?
Peut être pas à votre niveau remarque mais plutot au niveau de vos clients. La CNIL voit pas d’un très bon oeil par ex que les données soient hébergées en dehors de l’Europe…
Si vous stocker des données hors de France/Europe, je pense qu’il faudra prévenir vos clients, histoire qu’ils n’aient pas de mauvaises surprises le cas échéant…
Nicolas : je ne suis pas au courant de contraintes légales qui forceraient un hébergeur français à garder les données strictement en France. Aujourd’hui tout est en France, demain avec EC2 ce sera aussi en Irlande (puisque nous utiliserons le datacenter européen d’EC2).
S’il y a des contraintes réglementaires, elles sont à mon avis plus en amont, au niveau des sites eux-mêmes. Mais je n’en sais pas plus à vrai dire.
Je suis curieux : allez-vous continuer à utiliser DRBD pour synchroniser les données vers le backup EC2 ?
Note : j’ai le sentiment que cette solution relève plus du DRP (Disaster Recovery Plan) qu’un cluster HA (High Availability): le HA offre une redondance locale, avec un temps de bascule de quelques secondes, et donc une indisponibilité presque invisible.
Bref, de quoi eviter des indispo relativement longues en cas de panne d’un serveur… (on a déjà du aborder le sujet sur le forum, mais je ne me souviens plus du raisonnement ;-) )
Ceci étant dit, savoir qu’il y a un DRP dans un autre datacenter est extrêmement judicieux, et utiliser du cloud pour cela semble très pertinent !
wklinger : oui, nous allons continuer à utiliser DRBD.
Alors, DRP ou HA ? Probablement entre les deux. Certes, le temps de bascule ne sera pas de quelques secondes, mais l’idée reste que l’opération soit suffisamment simple et éprouvée pour qu’on puisse basculer en quelques minutes.
Le problème de la HA avec deux serveurs côte à côte, c’est qu’elle ne permet de pallier qu’une sous-partie assez faible de l’ensemble des problèmes qui peuvent arriver. Certes, c’est parfait pour une panne matérielle, mais ça ne protège en rien contre des problèmes de connectivité ou de datacenter.
Or depuis nos débuts, nous avons eu infiniment plus de problèmes logiciels ou liés au datacenter que de problèmes purement matériels. Donc une solution HA « classique » ne me conviendrait pas.
On est un peu en retard sur le planning – j’ai à peine eu le temps de retravailler dessus depuis ce billet – mais ça reste en priorité élevée. La v3 d’alwaysdata étant maintenant (presque) terminée, je devrais pouvoir attaquer ça en octobre :)