Le dimanche 21 octobre, le serveur http4 a \u00e9t\u00e9 indisponible de 1h02 \u00e0 10h17 (UTC+2). Cet article revient sur cette panne anormalement longue : ce qui s\u2019est pass\u00e9 en d\u00e9tails, ce que nous allons faire pour que cela ne se reproduise plus, et une mise au point sur la redondance.<\/p>\n
Samedi, \u00e0 16h51, le serveur http4 a \u00e9t\u00e9 retrouv\u00e9 totalement freez\u00e9. Nous l\u2019avons red\u00e9marr\u00e9, puis surveill\u00e9 la situation\u200a\u2014\u200ales logs n\u2019apportaient aucune indication. Un freeze peut \u00eatre caus\u00e9 par un probl\u00e8me mat\u00e9riel ou logiciel ; impossible \u00e0 ce moment d\u2019\u00eatre certain de l\u2019origine.<\/p>\n
\u00c0 22h01, le probl\u00e8me s\u2019est manifest\u00e9 \u00e0 nouveau. Les logs nous ont cette fois-ci permis d\u2019identifier \u00e0 coup s\u00fbr l\u2019origine mat\u00e9rielle (carte m\u00e8re en fin de vie). Nous avons donc programm\u00e9 avec notre fournisseur le remplacement de la carte pour le d\u00e9but de la nuit, \u00e0 1h00.<\/p>\n
\u00c0 1h02, le serveur est mis hors service pour proc\u00e9der au remplacement de la carte m\u00e8re. En temps normal, ce genre d\u2019op\u00e9ration dure moins de 30 minutes.<\/p>\n
Apr\u00e8s le changement de la carte m\u00e8re, le serveur refusait de d\u00e9marrer. L\u2019int\u00e9gralit\u00e9 de la RAM a \u00e9t\u00e9 chang\u00e9e, ce qui a r\u00e9solu ce probl\u00e8me. Seconde anomalie, la carte r\u00e9seau (Intel 10Gb) affichait en boucle :<\/p>\n
ixgbe 0000:04:00.0: eth0: Reset adapter\nixgbe 0000:04:00.0: eth0: detected SFP+: 0<\/pre>\nLe reste du syst\u00e8me fonctionnait bien, le noyau se comportait normalement. Le technicien a donc essay\u00e9 d\u2019identifier la cause du probl\u00e8me et a notamment :<\/p>\n
Sans succ\u00e8s. Le technicien a ensuite d\u00e9cid\u00e9 de monter en urgence un serveur neuf, \u00e0 la configuration identique, et d\u2019y ins\u00e9rer les disques de notre serveur. Sans que cela ne r\u00e9solve le probl\u00e8me.<\/p>\n
Il faut ajouter une pr\u00e9cision importante : seul notre propre noyau Linux (celui que nous compilons et maintenons, avec notre propre configuration) pr\u00e9sentait le bug. Le noyau standard de notre fournisseur, lui, fonctionnait correctement, ce qui semble exclure un probl\u00e8me mat\u00e9riel\/c\u00e2blage. N\u00e9anmoins, notre noyau fonctionnait parfaitement jusqu\u2019\u00e0 pr\u00e9sent sur ce serveur\u2026 ce qui rend la panne d\u2019autant plus myst\u00e9rieuse.<\/p>\n
Enfin, un technicien senior a, peu avant 10h, pu r\u00e9cup\u00e9rer un mod\u00e8le de carte r\u00e9seau tr\u00e8s l\u00e9g\u00e8rement diff\u00e9rent (toujours une Intel 10Gb) : cela a finalement r\u00e9solu le probl\u00e8me.<\/p>\n
Le probl\u00e8me d\u2019origine\u200a\u2014\u200ala carte r\u00e9seau qui subitement refuse de fonctionner\u200a\u2014\u200areste myst\u00e9rieux et non \u00e9lucid\u00e9. Ce peut \u00eatre d\u00fb \u00e0 un bug particuli\u00e8rement capricieux du driver noyau, par exemple. Il est impossible de se pr\u00e9munir contre ce genre d\u2019anomalie, heureusement exceptionnellement rare.<\/p>\n
C\u2019est n\u00e9anmoins la premi\u00e8re fois, en 6 ans, que nous sommes confront\u00e9s \u00e0 une panne sur un serveur d\u2019une telle ampleur. Nous pouvons en tirer plusieurs conclusions.<\/p>\n
Notre fournisseur (OVH, en l\u2019occurrence), propose des serveurs de diff\u00e9rentes gammes. Le serveur http4, datant de d\u00e9but 2010, fait partie de la plus haute gamme, avec davantage encore de protections que les serveurs plus classiques (par exemple, ils disposent d\u2019une double alimentation ou de connexions r\u00e9seau 10 Gb\/s).<\/p>\n
D\u2019exp\u00e9rience (nous avons des serveurs de toutes les gammes), nous constatons que :<\/p>\n
En faisant le bilan, nous constatons que la fiabilit\u00e9 des serveurs haut de gamme aura plut\u00f4t tendance \u00e0 \u00eatre inf\u00e9rieure \u00e0 celle des autres gammes, paradoxalement. Nous allons donc cesser progressivement d\u2019utiliser ces serveurs (en mutualis\u00e9, http4 et http6 sont concern\u00e9s).<\/p>\n
Si http4 avait \u00e9t\u00e9 sur un serveur de gamme standard, il est possible que le bug mystique de la carte r\u00e9seau aurait d\u00e9j\u00e0 \u00e9t\u00e9 d\u00e9couvert et r\u00e9solu avant qu\u2019il ne nous impacte. Par ailleurs, des serveurs de secours auraient probablement \u00e9t\u00e9 disponibles plus rapidement.<\/em><\/p>\n Notre fournisseur permet d\u2019utiliser leur propre noyau Linux pr\u00e9compil\u00e9. Nous ne les utilisons pas pour de nombreuses raisons, notamment l\u2019impossibilit\u00e9 d\u2019en choisir la version, d\u2019appliquer des patches ou de modifier la configuration.<\/p>\n S\u2019il n\u2019est donc pas question de nous mettre \u00e0 utiliser les noyaux standards de notre fournisseur (\u00e0 cause des limitations indiqu\u00e9es), il serait souhaitable qu\u2019en cas d\u2019urgence, il soit au moins possible de booter nos serveurs avec. Ne serait-ce que pour aider au d\u00e9bogage.<\/p>\n Concr\u00e8tement, les modifications \u00e0 apporter \u00e0 la configuration de nos serveurs est minime.<\/p>\n Si nous avions pu d\u00e9marrer http4 sur le noyau de notre fournisseur, le serveur aurait \u00e9t\u00e9 \u00e0 nouveau accessible bien plus rapidement. Quitte \u00e0 ce que certaines fonctionnalit\u00e9s non essentielles soient d\u00e9sactiv\u00e9es.<\/em><\/p>\n En cas de probl\u00e8me, il est possible de d\u00e9marrer les serveurs dans un mode rescue (boot via TFTP\/NFS). Les disques durs ne sont alors pas du tout utilis\u00e9s par le syst\u00e8me, ce qui garantit th\u00e9oriquement que ce mode rescue est accessible m\u00eame en cas de probl\u00e8me de configuration.<\/p>\n Nous allons d\u00e9sormais disposer de notre propre serveur de secours (spare<\/em>). En cas de probl\u00e8me mat\u00e9riel ou logiciel grave qui ne peut \u00eatre r\u00e9solu rapidement, nous aurons alors la possibilit\u00e9 de d\u00e9marrer le serveur en question en rescue, puis d\u2019exporter sa partition de donn\u00e9es vers le serveur de secours. Ce dernier prendra alors le relai du serveur en panne, lequel pourra \u00eatre d\u00e9bogu\u00e9 calmement ensuite. Nous avons simul\u00e9 cette bascule ces derniers jours, avec succ\u00e8s.<\/p>\n \u00c0 l\u2019heure actuelle, des techniciens de niveau 2 ne sont pas syst\u00e9matiquement pr\u00e9sents chaque nuit. En l\u2019occurrence, la panne est arriv\u00e9e un dimanche, les techniciens de niveau 2 n\u2019arrivaient pas avant 10h. Notre fournisseur nous a indiqu\u00e9 travailler sur ce point et proc\u00e9der actuellement \u00e0 de nombreux recrutements pour atteindre l\u2019objectif d\u2019avoir des techniciens de niveau 2, 24h\/24.<\/p>\n Nos serveurs \u00e9taient jusqu\u2019\u00e0 peu redond\u00e9s en Irlande, utilisant la technologie DRBD<\/a>. Cette redondance en temps r\u00e9el, mise en place d\u00e8s le d\u00e9but d\u2019alwaysdata, avait pour but de pallier les pannes graves (mat\u00e9rielles, r\u00e9seau) qui pourraient s\u2019\u00e9terniser en basculant vers le datacenter de secours. Pourquoi ce basculement n\u2019a pas \u00e9t\u00e9 fait ?<\/p>\n Apr\u00e8s plusieurs ann\u00e9es \u00e9quip\u00e9s de cette redondance, nous avons progressivement commenc\u00e9 \u00e0 la d\u00e9sactiver sur certains serveurs. Les raisons sont les suivantes :<\/p>\n Le bilan est donc sans appel : la redondance ne nous a jamais servi, mais a caus\u00e9 \u00e0 plusieurs reprises des pannes. C\u2019est indiscutablement un paradoxe : la redondance a diminu\u00e9 la disponibilit\u00e9 moyenne.<\/p>\n On peut toutefois se demander pourquoi ne pas avoir activ\u00e9 la redondance lors de pannes de plus petite ampleur (>= 30 minutes) :<\/p>\n Au final, m\u00eame si la panne de http4 aurait justifi\u00e9 de basculer (panne longue, serveur hors service), nous ne remettons pas en cause notre d\u00e9cision d\u2019arr\u00eater la redondance.<\/p>\n Une erreur toutefois : nous aurions d\u00fb annoncer publiquement l\u2019arr\u00eat de cette redondance, fut-elle partielle (certains serveurs ont encore la redondance d\u2019activ\u00e9e \u00e0 l\u2019heure actuelle). C\u2019est d\u00e9sormais chose faite.<\/p>\n Si nous arr\u00eatons aujourd\u2019hui la redondance via DRBD, il est possible que nous nous dirigions \u00e0 l\u2019avenir vers d\u2019autres formes de redondance\u200a\u2014\u200apar exemple une r\u00e9plication des bases de donn\u00e9es ou une synchronisation syst\u00e9matique des syst\u00e8mes de fichiers. Le but ne serait toutefois pas uniquement d\u2019am\u00e9liorer la disponibilit\u00e9 mais d\u2019offrir d\u2019autres avantages, par exemple en termes de performances.<\/p>\n Pr\u00e9cisons que la suppression de la redondance en temps r\u00e9el n\u2019a strictement aucun lien avec les sauvegardes, toujours effectu\u00e9es quotidiennement et conserv\u00e9es pendant 30 jours.<\/p>\n Nous pr\u00e9sentons toutes nos excuses \u00e0 nos clients pour cette panne exceptionnelle. Ceux qui ont \u00e9t\u00e9 impact\u00e9s peuvent ouvrir un ticket en demandant le remboursement int\u00e9gral du mois d\u2019octobre, comme nos conditions g\u00e9n\u00e9rales de vente<\/a> le stipulent.<\/p>\n Rappelons notre attachement \u00e0 fournir le meilleur taux de disponibilit\u00e9 possible, m\u00eame sur un environnement mutualis\u00e9. C\u2019est un challenge quotidien, compte tenu de la grande souplesse que nous offrons (e.g. ouvrir un compte sans payer, pouvoir faire tourner n\u2019importe quel processus sur son compte).<\/p>\n Promettre qu\u2019il n\u2019y aura plus jamais de grosse panne serait illusoire : personne ne peut garantir cela. Ce que nous promettons, c\u2019est une transparence totale, durant l\u2019incident<\/a> et apr\u00e8s, avec des mesures concr\u00e8tes pour \u00e9viter que cela ne se reproduise. Et des r\u00e9ponses \u00e0 vos questions, si vous en avez.<\/p>\n","protected":false},"excerpt":{"rendered":" Le dimanche 21 octobre, le serveur http4 a \u00e9t\u00e9 indisponible de 1h02 \u00e0 10h17 (UTC+2). Cet article revient sur cette panne anormalement longue : ce qui s\u2019est pass\u00e9 \u2026 Keep reading<\/a><\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"wp_typography_post_enhancements_disabled":false,"footnotes":""},"categories":[1],"tags":[148],"class_list":["post-1017","post","type-post","status-publish","format-standard","hentry","category-uncategorized","tag-panne-fr"],"acf":[],"_links":{"self":[{"href":"https:\/\/blog.alwaysdata.com\/fr\/wp-json\/wp\/v2\/posts\/1017","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.alwaysdata.com\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.alwaysdata.com\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.alwaysdata.com\/fr\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.alwaysdata.com\/fr\/wp-json\/wp\/v2\/comments?post=1017"}],"version-history":[{"count":0,"href":"https:\/\/blog.alwaysdata.com\/fr\/wp-json\/wp\/v2\/posts\/1017\/revisions"}],"wp:attachment":[{"href":"https:\/\/blog.alwaysdata.com\/fr\/wp-json\/wp\/v2\/media?parent=1017"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.alwaysdata.com\/fr\/wp-json\/wp\/v2\/categories?post=1017"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.alwaysdata.com\/fr\/wp-json\/wp\/v2\/tags?post=1017"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}S\u2019assurer que nos serveurs peuvent d\u00e9marrer avec le noyau de notre fournisseur<\/h3>\n
Permettre d\u2019acc\u00e9der rapidement aux donn\u00e9es en mode rescue<\/h3>\n
Des techniciens de niveau 2, 24h\/24<\/h3>\n
Et la redondance ?<\/h2>\n
\n
\n
\n
D\u2019autres formes de redondance \u00e0 l\u2019avenir ?<\/h3>\n
En conclusion<\/h2>\n