Je vais écrire un billet un peu inhabituel, aujourd’hui. Je dis souvent qu’il ne faut jamais compter sur la fiabilité des ordinateurs. C’est tellement vrai que depuis une semaine, j’enchaîne les problèmes techniques sur mes serveurs, les uns après les autres. Aucune relation entre les problèmes, ce sont juste de fâcheux concours de circonstance qui nous font perdre des dizaines de milliers d’euros de chiffre d’affaire.
Reprenons depuis le début. Les serveur de mon entreprise sont loués chez une entreprise française très connue, leader européen de l’hébergement. Nous avons actuellement 5 serveur chez eux, sachant qu’on en a eu jusqu’à 7 en même temps. Ce n’est pas une infrastructure de folie, mais le coût tourne quand même autour du millier d’euros mensuel.
Historique
Avant de parler des problèmes qui s’enquillent depuis une semaine, voici un petit récapitulatif rapide des problèmes rencontrés ces 2 dernières années (je ne liste là que les problèmes techniques pour lesquels l’hébergeur a fait des erreurs ; je ne liste pas les quelques problèmes qui ont été résolus en moins de 2 heures) :
22 décembre 2008
Problème disque dur.
Retards de communication et mauvaise prise en charge par l’hébergeur.
18h30 d’interruption de service.
15 jours de location serveur offerts.
26 mai 2010
Problème carte mère.
Mauvaise gestion du load-balancing par l’hébergeur.
10 heures d’interruption de service.
10 jours de location serveur offerts.
07 juillet 2010
Problème disque dur.
Mauvais diagnostic technique par l’hébergeur.
8 heures d’interruption de service.
14 jours de location serveur offerts.
25 novembre 2010
Problème carte mère.
Mauvaise gestion du load-balancing par l’hébergeur.
4 jours d’indisponibilité de service.
Un mois de location serveur offert.
Dans tous ces cas, l’hébergeur garantissait un délai de rétablissement de 4 heures maximum. C’est la raison pour laquelle des pénalités de retard furent appliquées.
Pour la petite histoire, j’ai aussi un serveur personnel chez cet hébergeur. Et il a aussi connu 2 changements de disques et un changement de carte mère dans le même intervalle.
L’emmerdement maximal
Juste pour montrer comment les choses peuvent s’additionner pour provoquer des interruptions de service à répétition, voici ce qui s’est passé ces derniers jours :
Jeudi dernier, notre serveur d’intranet (emails, wiki, buglist, …) se met soudainement dans un état bizarre. Après investigation, on soupçonne la machine d’avoir été hackée.
Pour info, nos systèmes tournent sous Ubuntu, qui propose des version avec support à court terme et d’autres avec support à long terme. Le serveur en question, installé à une époque avec une version LTS (long terme), avait été mis à jour par notre ancien administrateur système sans qu’il ne me prévienne. Cette mise-à-jour l’avait fait passer sur une version avec support à court terme. Grave erreur, car au lieu d’avoir un serveur stable pendant 5 ans, on s’est retrouvé sans le savoir avec un serveur qui ne recevait plus de nouveaux patchs de sécurité au bout d’un an et demi. Ce qui devait arriver arriva, et un hacker en profita.
Résultat : Réinstallation complète de la machine, une demi-journée sans email ni outils de travail collaboratif.
En même temps qu’on réinstallait ce serveur, on a remarqué qu’il était devenu impossible de se connecter par SSH sur l’un de nos serveurs frontaux. Comme on avait d’autres chats à fouetter sur le moment (imaginez une boîte de 30 personnes, dont des commerciaux, qui viennent vous voir sans arrêt parce que les emails ne fonctionne pas…), on s’en est occupé lundi. Très bizarrement, le serveur fonctionnait correctement au niveau HTTP. Les services répondaient correctement. Mais alors pourquoi le SSH est-il tombé ? Cette machine aurait-elle été corrompue elle aussi ? Son système était bien plus récent, mais les derniers patchs kernels n’étaient pas pris en compte car notre administrateur n’avait pas rebooté le serveur après la dernière mise-à-jour. On a essayé d’utiliser le système de KVM mis à disposition par l’hébergeur, qui doit permettre de prendre la main sur le serveur comme si on avait un clavier et un écran branchés directement dessus, mais le bousin n’a jamais voulu fonctionner.
Résultat : Réinstallation complète de la machine, une journée et demi à faire tourner nos sites avec un serveur frontal de moins, ce qui dégrade la qualité du service.
Juste histoire de rire, on a redémarré un autre serveur frontal après l’avoir mis à jour. Et évidemment, le système a fait un fsck (vérification du système de fichier, pour ceux qui n’ont pas l’habitude des systèmes Unix).
Résultat : 20 minutes d’attente avant que le serveur ne finisse de redémarrer, et une grosse frayeur en attendant.
Hier, nous décidons de mettre à jour notre serveur de base de données. Contrairement aux serveurs frontaux qu’on peut arrêter s’il le faut (en redirigeant les requêtes vers les autres frontaux), ce serveur contient nos bases MySQL centralisées. S’il s’arrête, ce sont tous nos services qui s’arrêtent. Il s’agit donc d’une machine haut de gamme, plutôt chère, avec de la redondance de partout (disques en RAID 1, alimentation électrique redondée, deux interfaces réseau). Pour ne pas bloquer nos sites à un moment de fort trafic, on prend la décision de faire la mise-à-jour et le redémarrage à 4 heures du matin. La mise-à-jour se passe bien, mais au redémarrage du serveur, rien de répond. L’explication finit par arriver : un des disques est mort. Mais la machine ne peut pas redémarrer ; c’est bien la peine d’avoir des disques en RAID…
Le technicien qui intervient sur la machine la place est mode « rescue », pour nous permettre de récupérer les données du disque. Mais nous ne recevrons jamais les identifiants nous permettant de nous y connecter. Le plus amusant, c’est qu’après leur avoir dit «OK, on vous donne le feu vert, dépêchez-vous de changer le disque, ça fait déjà 4 heures que le serveur est planté !», on a attendu 45 minutes pour qu’un autre technicien se penche dessus… et remette la machine en mode rescue au lieu de changer le disque ! Hop, encore une heure de perdue.
Résultat : Le temps d’attendre que le disque soit changé, qu’on réinstalle le système et qu’on rapatrie les données, on a eu 10 heures d’interruption de service.
Quel bilan en tirer ?
- Le matériel n’est pas fiable. Ce n’est pas parce qu’on vous change un disque dur qu’il ne va pas vous lâcher de nouveau un an et demi après.
- L’hébergeur fait de son mieux pour satisfaire ses clients. Mais vu la masse de clients qu’il a, il lui est sûrement plus rentable d’offrir 10 jours de location si les délais sont un peu dépassés que de mettre en place toute l’infrastructure nécessaire pour que ce genre de cas n’arrive pas.
- Corollaire du point précédent, ce n’est pas parce qu’un serveur « haut de gamme » coûte plus cher et qu’il propose une garantie de temps de réparation plus courte, que les administrateur vont effectivement s’en occuper avec un plus grand soin. Ils font de leur mieux sur toutes leurs interventions. S’ils se plantent dans le changement de disque d’un serveur d’entrée de gamme à 50€/mois, ils pourront se planter tout autant quand il faudra changer le disque d’un serveur à 400€/mois.
- Il ne faut pas compter sur les pénalités de retard. Un service indisponible pendant plusieurs heures, et ce sont des milliers d’euros de manque à gagner (sans compter les pertes d’image, de référencement, l’insatisfaction de nos propres clients). En contrepartie, quelques jours de location gratuite, c’est totalement négligeable.
- Les solutions techniques qui devraient justement servir à assurer la continuité de service ne sont pas fiables. Pour nous, un problème de carte mère (changée en 2 heures) s’est transformé en problème de mise-à-jour des tables de routage du load-balancing (effectuée au bout de 4 jours). Alors que le load-balancing est justement là pour réorienter les requêtes quand un serveur tombe en panne !
- La sécurité informatique est un serpent de mer insaisissable. Il y aura toujours plus de hackers compétents que d’experts en sécurité dans votre entreprise. Mais si vous n’êtes pas assez important pour intéresser les vraies méchants hackers (ceux qui en ont après les informations confidentielles que vous possédez), vous ne serez la cible potentielle que de ceux qui cherchent des machines à infecter pour en faire des relais de spam ou pour infecter d’autres machines. Un firewall bien configuré et des patchs de sécurité parfaitement à jour (sur le système et sur les applications) vous épargneront la plupart des soucis. Par contre, si vous avez des données critiques, faites appels à des professionnels ; la sécurité, c’est un métier.
- La loi de Murphy fait que lorsque vous pensez avoir vécu le pire, les choses vont encore empirer. Il faut réfléchir au pire scénario possible, et mettre en place des mesures préventives. Et même là encore, il se passera un truc auquel vous n’avez pas pensé.
En conclusion : Vous êtes seul responsable de votre architecture technique. Ne comptez pas sur la fiabilité théorique qui vous est annoncée, et encore moins sur les garanties qu’un hébergeur est censé vous offrir. Au final, c’est vous qui perdrez de l’argent en cas de problème. À vous de mettre en place les bonnes stratégies, à base de sauvegardes, d’archivages, de serveurs de remplacement.
Et si ça vous dépasse, faites appel à des infogérants. Ça coûte cher, mais il y a une raison à ça.
Edit : Pour le problème remonté ici, datant de février, notre hébergeur nous a royalement offert 6 jours de location du serveur. Soit le plus petit dédommagement qu’on a reçut, alors qu’il s’agit d’un serveur haut de gamme…
Article très intéressant, on parle souvent des choses qui vont bien.
Cela remet aussi un peu les pendules à l’heure sur le « tout hébergé » à l’heure où l’on entend parler que de cloud.
Maintenant avec les moyens qu’il faut, des solutions en virtu avec une stratégie de haute disponibilité et on se sent « plus tranquille »
Chez ce fameux hébergeur (que tout le monde aura reconnu), je vous conseille le service VIP. ça a fait des miracles avec moi par rapport au support classique. Et vu que le prix est fixe quelque soit le nombre de serveur, ça vaux vraiment le coup quand son parc grossi.
Benoit
PS: félicitation pour votre blog.
@Nico : Ah, les sirènes du virtuel… Mais quand je vois à quel point la moindre techno un peu pointue se transforme en nid à emmerdes (cf. load-balancing), je me dis qu’il vaut mieux − à l’heure actuelle − miser sur les technos les plus rustiques possibles.
@fuleran : Oui, on va passer au service VIP, c’est prévu. D’un autre côté, le fait d’avoir un contact privilégié avec un commercial n’aurait rien changé aux bourdes faites par les administrateurs les plus compétents qui se sont occupés de nos serveurs… Par contre, c’est sûr que ça doit permettre de faire bouger les choses quand il y en a besoin.
En effet, article intéressant qui donne envie de réagir sur plusieurs points.
Nous travaillons avec cet hébergeur depuis plusieurs mois maintenant, et nous possédons une infrastructure assez important.
En effet, le service VIP est très intéressant, le contact technique comme le contact commercial dédié permet de ne pas ré-expliquer l’histoire de la choucroute à chaque appel téléphonique …
De plus, avec le temps, on commence à connaitre nos interlocuteurs et l’on peut plus facilement apprécié leurs réactions humaines.
Au niveau des services, il est bien connu que nous ne sommes jamais mieux servit que par nous même… Avoir un hébergement décentralisé, des garanties, des SLA.. C’est ultra pratique dans 90% du temps. Mais lorsque l’infrastructure plante pour X raison(s), il va y avoir des délais d’intervention liés à la disponibilité des techniciens, à votre importance au sein de l’hébergeur..
Au final, il s’écoule régulièrement plus de quelques heures avant que le problème ne soit résolu.
En contre partie, cette hébergeur offre des coûts extrêmement bas, mais faut-il savoir en tirer profils.
Il est bien évident que l’on ne peut pas donner de conseil sans avoir une vision précise de votre infrastructure. Mais il peut être intéressant pour vous de prendre un nouveau serveur physique avec un VMWare ESXi dessus permettant de créer des machines virtuelles. Imaginons une solution de Load Balancing, ainsi qu’un serveur MySQL esclave présent pour prendre le relais du serveur MySQL maitre.
Si vous souhaitez assurer une Haute Disponibilité, pensez à doubler le serveur hôte VMWare ESXi, et réalisez de la synchronisation / croisement de service entre chaque hôte. Si vous disposez de 3 serveurs dédiés sous-utilisés, vous pouvez les migrer sur l’infrastructure virtuelle et ainsi économiser 3 serveurs…
PS : Pensez à tester vos KVM régulièrement. C’est parfois votre dernière chance … :p
En fait, notre situation est un peu particulière. Nous ne cherchons pas à avoir de la haute disponibilité. Si un frontal tombe, on redirige les requêtes vers les autres frontaux. Si il y a dégradation du service pendant quelques (dizaines) de minutes, ce n’est pas grave. Si le serveur de base de données tombe et qu’il faut 3 heures pour remettre le service en ligne, on peut vivre avec (tant que ça n’arrive que rarement). Nous ne faisons pas du e-commerce.
En temps normal, cela nous revient moins cher de vivre avec un risque d’interruption de service de quelques heures, que de mettre en place les infrastructures nécessaires à de la haute dispo. Si les délais de GTR prévus sur les serveurs (4 heures sur les frontaux, 2 heures sur le back-end) étaient respectés et si les erreurs humaines étaient moins fréquentes, je ne me plaindrais pas.
En plus, après avoir utilisé un certain nombre de technos de virtualisation, et avoir mis en place de la réplication MySQL (le tout de manière très sérieuse ces 4 dernières années), je préfère maintenant éviter cela en production. Je ne compte plus les fois où les problèmes venaient justement de la couche de virtualisation, ou les réplications qui fonctionnent très bien jusqu’au jour où on bascule sur l’esclave − parce que le maître est tombé − et qu’on se rend compte qu’il y a des « trous » dans les données…
Et, encore une fois, l’hébergeur n’est pas capable de fournir 4 services de base de manière fiable :
– Le RAID ne marche pas. À chaque fois qu’un de nos serveur a eu un problème de disque, la machine s’est arrêtée. Alors il y a quand même un intérêt, les données ne sont pas perdues ; dès que le disque est remplacé il se re-synchronise avec celui en place. Mais c’est quand même insatisfaisant.
– Redémarrage en mode « rescue ». On ne reçoit pas les identifiants permettant de se connecter au serveur. Interrogé au téléphone, le technicien me répond que lorsque les machines sont lentes à répondre, le système ne détecte pas bien que la machine à rebooté. Sérieusement, une machine avec 8 processeurs et 16 GO de mémoire, démarrée en netboot sur un système minimal, ça peut être lent à démarrer ?
– Load balancing qui déconne à chaque fois qu’une machine se fait changer sa carte mère. Il envoie des paquets au serveur avec l’ancienne adresse MAC de l’interface réseau. La mise-à-jour automatique des tables de routage ne fonctionne jamais, et les administrateurs oublient de le faire (même quand on leur rappelle plusieurs fois dans les tickets de support).
– KVM qui reste désespérément noir. Et là, autant réinstaller tout de suite le serveur.
Donc oui, il faut améliorer les choses pour anticiper les problèmes et réduire les risques d’interruption de service. Mais je ne suis pas convaincu que la réponse passe par une augmentation de la complexité technique.
Article génial, j’ai beaucoup apprécié la pertinence des faits ! Je me pose tout de même une question sur la gestion du load-balancing : que stipule le contrat ? Où intervient l’hébergeur et quelles sont ses garanties ? Est-ce vraiment le load-balancing qui n’a plus fonctionné suite à une panne où s’agit-il du failover qui n’a pas pris la relève ?
Pourquoi ne pas passer quelques temps (heures/jours) à mettre en place votre propre solution de load-balancing (au niveau DNS, ou des modules apache – ou autre serveur web) ?
Concernant le load-balancing, c’est assez simple. La carte mère du serveur a été changée, donc l’interface réseau l’a été en même temps. L’infrastructure de load-balancing se rend compte lorsqu’une machine n’est plus accessible, et arrête alors de lui envoyer les requêtes. Quand le serveur est redevenu disponible, il a commencé à recevoir des requêtes de nouveau. Sauf que le load-balancing a systématiquement envoyé des paquets contenant l’adresse MAC de l’ancienne interface réseau. Quand le serveur reçoit ces paquets, il se dit «Ce n’est pas pour moi, je laisse tomber». Donc il reçoit bien les données mais il ne les traite pas.
Il y a normalement un mécanisme qui remet à jour les table de routage du load-balancing, mais il n’a jamais fonctionné. Même s’ils le savent, les administrateurs de l’hébergeur oublient de lancer la mise-à-jour à la main.
Les obligations de l’hébergeur ? Si un serveur est indisponible à cause d’un problème technique qui est de son ressort (disque dur, carte mère, réseau), il est censé réparer en 2 ou 4 heures (suivant le serveur). Chaque heure de retard est remboursée à hauteur de 5% du prix de location mensuel du serveur, avec un remboursement maximal équivalent à 50% ou 100% du prix mensuel (suivant le serveur). Autant dire que même en obtenant un mois de location gratuite, ce n’est rien du tout par rapport au chiffre d’affaire perdu.
Depuis, nous avons effectivement mis en place notre propre alternative au load-balancing. Nous utilisons du DNS round-robin pour répartir les requêtes entre nos serveurs. Le TTL du DNS est très court (quelques minutes), pour qu’en cas de problème on puisse “sortir” un serveur du pool de round-robin. C’est une solution simple, fiable, qui marche très bien.
Merci du retex.
J’ai souvent pensé à ces problèmes et je me demande si prendre 2 hébergeurs différents n’est pas la meilleure solution:
le load-balancing étant géré par soi-même, le serveur principale chez l’hébergeur A et le serveur secondaire chez l’hébergeur B.
Pour le service/fonctionnalité suivant(e) (ex: db, messagerie) on inverse les hébergeur, cad: le serveur principale chez l’hébergeur B et le secondaire chez l’hébergeur A.
C’est pas par manque de confiance de l’hébergeur (et encore) mais ainsi on n’est lié à personne. Si l’hébergeur A pose trop de problèmes, on peut rapidement l’exclure de l’infra en ne gardant que B dans le load-balancing. Puis prendre un hébergeur C et le faire monter à la place de A (via le load-balancing).
J’avoue, j’ai tendance à utiliser le load-balancing, ou le cluster, comme outil de migration. Ce n’est pas la fonction première mais ça marche du tonnerre 😀
En plus la parano aidant, si l’hébergeur disparait (faillite, coupure du net, coupure électrique, incendie, inondation…), on perd tous et pour (trop) longtemps. En étant dés le départ chez plusieurs hébergeurs, on évite tous ces problèmes.
Les backup c’est parfait sauf qu’en il faut s’en servir, c’est toujours la merde, le load-balancing/cluster c’est le seul moyen réellement efficace. J’ai perdu la « foi » en la backup suite à une question:
c’est quand la dernière fois que vous avez utilisé un backup pour remonter un serveur en prod (même en test/exercice) ???
Comme tout le monde: il ya bien longtemps = j’ai oublié comment faire = le nouveau sait pas faire = j’ai la procédure quelque part = ils sont où les backup ?? = …
@Sylvain : Ce n’est pas si simple.
Avoir deux hébergeurs fonctionne bien avec une infrastructure actif-passif. Tu as un serveur (ou un groupe de serveur) qui répond aux requêtes, et un autre serveur (ou groupe de serveurs) qui est ailleurs, prêt à recevoir les requêtes à tout moment.
Sauf que :
1. C’est coûteux. On a tendance à préférer une architecture actif-actif. Tous les serveurs répondent aux requêtes, et si un serveur tombe on redirige ses requêtes vers les autres serveurs.
2. C’est simple pour les serveurs frontaux, mais beaucoup plus compliqué pour une base de données. Tu peux mettre en place une réplication maître-esclave, pour avoir les données les plus à jour possible sur le serveur de secours. Mais tu risques alors les loupés technologiques qui font perdre des données. Ou bien tu peux te baser sur des sauvegardes fréquentes de ta base, mais tu perdras forcément les données créées entre le backup et le crash.
Joli article… le genre à vous demander si quelqu’un ne vous aurait pas jeté un sort, des fois.
Bon courage, ça va passer 🙂
Concernant la Loi de Murphy / Loi de l’emmerdement maximal :
http://yannickprimel.wordpress.com/2010/10/16/la-loi-de-murphy/
– Yannick.
C’est exact ! Les disques durs actuel ont plein de défauts de fiabilité. Il faut vraiment doubler les sauvegardes.