Le dimanche 21 octobre, le ser­veur http4 a été indis­po­nible de 1h02 à 10h17 (UTC+2). Cet article revient sur cette panne anor­ma­le­ment longue : ce qui s’est pas­sé en détails, ce que nous allons faire pour que cela ne se repro­duise plus, et une mise au point sur la redon­dance.

Ce qui s’est passé

Samedi, à 16h51, le ser­veur http4 a été retrou­vé tota­le­ment free­zé. Nous l’avons redé­mar­ré, puis sur­veillé la situa­tion — les logs n’apportaient aucune indi­ca­tion. Un freeze peut être cau­sé par un pro­blème maté­riel ou logi­ciel ; impos­sible à ce moment d’être cer­tain de l’origine.

À 22h01, le pro­blème s’est mani­fes­té à nou­veau. Les logs nous ont cette fois-ci per­mis d’identifier à coup sûr l’origine maté­rielle (carte mère en fin de vie). Nous avons donc pro­gram­mé avec notre four­nis­seur le rem­pla­ce­ment de la carte pour le début de la nuit, à 1h00.

À 1h02, le ser­veur est mis hors ser­vice pour pro­cé­der au rem­pla­ce­ment de la carte mère. En temps nor­mal, ce genre d’opération dure moins de 30 minutes.

Après le chan­ge­ment de la carte mère, le ser­veur refu­sait de démar­rer. L’intégralité de la RAM a été chan­gée, ce qui a réso­lu ce pro­blème. Seconde ano­ma­lie, la carte réseau (Intel 10Gb) affi­chait en boucle :

Le reste du sys­tème fonc­tion­nait bien, le noyau se com­por­tait nor­ma­le­ment. Le tech­ni­cien a donc essayé d’identifier la cause du pro­blème et a notam­ment :

  • véri­fié le câblage ;
  • véri­fié la confi­gu­ra­tion du switch ;
  • chan­gé la carte réseau pour un modèle iden­tique ;
  • remis l’ancienne carte réseau ;
  • remis l’ancienne carte mère ;
  • remis la nou­velle carte mère ;
  • mis à jour le BIOS de la carte mère ;
  • mis à jour le firm­ware de la carte réseau.

Sans suc­cès. Le tech­ni­cien a ensuite déci­dé de mon­ter en urgence un ser­veur neuf, à la confi­gu­ra­tion iden­tique, et d’y insé­rer les disques de notre ser­veur. Sans que cela ne résolve le pro­blème.

Il faut ajou­ter une pré­ci­sion impor­tante : seul notre propre noyau Linux (celui que nous com­pi­lons et main­te­nons, avec notre propre confi­gu­ra­tion) pré­sen­tait le bug. Le noyau stan­dard de notre four­nis­seur, lui, fonc­tion­nait cor­rec­te­ment, ce qui semble exclure un pro­blème matériel/câblage. Néanmoins, notre noyau fonc­tion­nait par­fai­te­ment jusqu’à pré­sent sur ce ser­veur… ce qui rend la panne d’autant plus mys­té­rieuse.

Enfin, un tech­ni­cien senior a, peu avant 10h, pu récu­pé­rer un modèle de carte réseau très légè­re­ment dif­fé­rent (tou­jours une Intel 10Gb) : cela a fina­le­ment réso­lu le pro­blème.

Diminuer les risques à l’avenir

Le pro­blème d’origine — la carte réseau qui subi­te­ment refuse de fonc­tion­ner — reste mys­té­rieux et non élu­ci­dé. Ce peut être dû à un bug par­ti­cu­liè­re­ment capri­cieux du dri­ver noyau, par exemple. Il est impos­sible de se pré­mu­nir contre ce genre d’anomalie, heu­reu­se­ment excep­tion­nel­le­ment rare.

C’est néan­moins la pre­mière fois, en 6 ans, que nous sommes confron­tés à une panne sur un ser­veur d’une telle ampleur. Nous pou­vons en tirer plu­sieurs conclu­sions.

Privilégier les serveurs des gammes les plus courantes

Notre four­nis­seur (OVH, en l’occurrence), pro­pose des ser­veurs de dif­fé­rentes gammes. Le ser­veur http4, datant de début 2010, fait par­tie de la plus haute gamme, avec davan­tage encore de pro­tec­tions que les ser­veurs plus clas­siques (par exemple, ils dis­posent d’une double ali­men­ta­tion ou de connexions réseau 10 Gb/s).

D’expérience (nous avons des ser­veurs de toutes les gammes), nous consta­tons que :

  • la fia­bi­li­té maté­rielle théo­ri­que­ment supé­rieure des ser­veurs haut de gamme n’est pas signi­fi­ca­ti­ve­ment dif­fé­rente de celles des autres gammes ;
  • le parc de ser­veurs haut de gamme de notre four­nis­seur est bien plus limi­té que celui des autres ser­veurs. En consé­quence, et d’après notre expé­rience sub­jec­tive et limi­tée :
    • ces ser­veurs semblent davan­tage sus­cep­tibles d’être vic­times de cer­tains types de bugs « rares » (maté­riel, rou­tage) : plus il y a d’utilisateurs d’un équi­pe­ment X, plus vite les éven­tuels bugs seront détec­tés et cor­ri­gés ;
    • les tech­ni­ciens (de niveau 1) étant moins fré­quem­ment confron­tés à ces ser­veurs, ils ont glo­ba­le­ment moins d’expérience des­sus. Expérience pré­cieuse en cas de pro­blème urgent ;
    • les chances d’avoir un ser­veur de rem­pla­ce­ment déjà prêt à l’emploi sont plus faibles.

En fai­sant le bilan, nous consta­tons que la fia­bi­li­té des ser­veurs haut de gamme aura plu­tôt ten­dance à être infé­rieure à celle des autres gammes, para­doxa­le­ment. Nous allons donc ces­ser pro­gres­si­ve­ment d’utiliser ces ser­veurs (en mutua­li­sé, http4 et http6 sont concer­nés).

Si http4 avait été sur un ser­veur de gamme stan­dard, il est pos­sible que le bug mys­tique de la carte réseau aurait déjà été décou­vert et réso­lu avant qu’il ne nous impacte. Par ailleurs, des ser­veurs de secours auraient pro­ba­ble­ment été dis­po­nibles plus rapi­de­ment.

S’assurer que nos serveurs peuvent démarrer avec le noyau de notre fournisseur

Notre four­nis­seur per­met d’utiliser leur propre noyau Linux pré­com­pi­lé. Nous ne les uti­li­sons pas pour de nom­breuses rai­sons, notam­ment l’impossibilité d’en choi­sir la ver­sion, d’appliquer des patches ou de modi­fier la confi­gu­ra­tion.

S’il n’est donc pas ques­tion de nous mettre à uti­li­ser les noyaux stan­dards de notre four­nis­seur (à cause des limi­ta­tions indi­quées), il serait sou­hai­table qu’en cas d’urgence, il soit au moins pos­sible de boo­ter nos ser­veurs avec. Ne serait-ce que pour aider au débo­gage.

Concrètement, les modi­fi­ca­tions à appor­ter à la confi­gu­ra­tion de nos ser­veurs est minime.

Si nous avions pu démar­rer http4 sur le noyau de notre four­nis­seur, le ser­veur aurait été à nou­veau acces­sible bien plus rapi­de­ment. Quitte à ce que cer­taines fonc­tion­na­li­tés non essen­tielles soient désac­ti­vées.

Permettre d’accéder rapidement aux données en mode rescue

En cas de pro­blème, il est pos­sible de démar­rer les ser­veurs dans un mode rescue (boot via TFTP/NFS). Les disques durs ne sont alors pas du tout uti­li­sés par le sys­tème, ce qui garan­tit théo­ri­que­ment que ce mode rescue est acces­sible même en cas de pro­blème de confi­gu­ra­tion.

Nous allons désor­mais dis­po­ser de notre propre ser­veur de secours (spare). En cas de pro­blème maté­riel ou logi­ciel grave qui ne peut être réso­lu rapi­de­ment, nous aurons alors la pos­si­bi­li­té de démar­rer le ser­veur en ques­tion en rescue, puis d’exporter sa par­ti­tion de don­nées vers le ser­veur de secours. Ce der­nier pren­dra alors le relai du ser­veur en panne, lequel pour­ra être débo­gué cal­me­ment ensuite. Nous avons simu­lé cette bas­cule ces der­niers jours, avec suc­cès.

Des techniciens de niveau 2, 24h/24

À l’heure actuelle, des tech­ni­ciens de niveau 2 ne sont pas sys­té­ma­ti­que­ment pré­sents chaque nuit. En l’occurrence, la panne est arri­vée un dimanche, les tech­ni­ciens de niveau 2 n’arrivaient pas avant 10h. Notre four­nis­seur nous a indi­qué tra­vailler sur ce point et pro­cé­der actuel­le­ment à de nom­breux recru­te­ments pour atteindre l’objectif d’avoir des tech­ni­ciens de niveau 2, 24h/24.

Et la redondance ?

Nos ser­veurs étaient jusqu’à peu redon­dés en Irlande, uti­li­sant la tech­no­lo­gie DRBD. Cette redon­dance en temps réel, mise en place dès le début d’alwaysdata, avait pour but de pal­lier les pannes graves (maté­rielles, réseau) qui pour­raient s’éterniser en bas­cu­lant vers le data­cen­ter de secours. Pourquoi ce bas­cu­le­ment n’a pas été fait ?

Après plu­sieurs années équi­pés de cette redon­dance, nous avons pro­gres­si­ve­ment com­men­cé à la désac­ti­ver sur cer­tains ser­veurs. Les rai­sons sont les sui­vantes :

  • la sta­bi­li­té n’est pas suf­fi­sante. DRBD a trop sou­vent été la source de blocages/plantages sur le ser­veur pri­maire, et ce mal­gré les mises à jour fré­quentes. Il suf­fit de regar­der le chan­ge­log pour consta­ter que chaque nou­velle ver­sion cor­rige des bugs assez graves. Nous uti­li­sons DRBD dans un mode WAN qui n’est pas le plus fré­quent, ce qui pour­rait expli­quer la rela­tive insta­bi­li­té ;
  • nous n’avions jamais eu, en 6 ans, de panne excep­tion­nelle jus­ti­fiant de bas­cu­ler vers le data­cen­ter de secours (la panne de http4 est la toute pre­mière). C’est une bonne nou­velle : cela signi­fie que la sta­bi­li­té de notre four­nis­seur prin­ci­pal est très bonne ;
  • la redon­dance a un coût :
    • (assez faible) sur les per­for­mances IO des ser­veurs,
    • (non négli­geable) sur la com­plexi­té de notre archi­tec­ture,
    • (faible) finan­cier ;
  • moins on a l’occasion d’effectuer en situa­tions réelles la bas­cule vers le data­cen­ter secon­daire, plus on court de risques que tout ne se passe pas par­fai­te­ment le jour où on doit le faire – mal­gré les simu­la­tions.

Le bilan est donc sans appel : la redon­dance ne nous a jamais ser­vi, mais a cau­sé à plu­sieurs reprises des pannes. C’est indis­cu­ta­ble­ment un para­doxe : la redon­dance a dimi­nué la dis­po­ni­bi­li­té moyenne.

On peut tou­te­fois se deman­der pour­quoi ne pas avoir acti­vé la redon­dance lors de pannes de plus petite ampleur (>= 30 minutes) :

  • les pannes de petite ampleur d’origine maté­rielle ou réseau (les seules sus­cep­tibles d’être éli­mi­nées par un bas­cu­le­ment) sont tout d’abord très rares. Sur les 64 pannes réfé­ren­cées depuis que nous avons notre page d’état des ser­vices, seules 3 ont duré plus de 30 minutes et auraient pu être éli­gibles à un bas­cu­le­ment vers le ser­veur secon­daire ;
  • le bas­cu­le­ment n’est pas ins­tan­ta­né : le ser­veur secon­daire doit prendre le relai, et sur­tout les DNS doivent être mis à jour. En pra­tique, sur du HTTP, il faut envi­ron 30 minutes pour que la grande majo­ri­té des nou­velles connexions soient effec­tuées sur la nou­velle IP ;
  • consé­quence du point pré­cé­dent : le bas­cu­le­ment peut être contre-pro­duc­tif. Si on décide le bas­cu­le­ment après 30 minutes de panne, mais que cette der­nière est réso­lue 5 minutes après, on va devoir rebas­cu­ler vers le ser­veur pri­maire. Au final, il aurait mieux fal­lu ne rien faire. Or la plu­part des pannes qui durent plus de 30 minutes durent moins de 60 minutes ;
  • le bas­cu­le­ment pré­sente des risques de split-brain si on ne peut pas s’assurer que la machine pri­maire est hors ser­vice. Cela rend la bas­cule assez ris­quée lors d’une panne de réseau, notam­ment.

Au final, même si la panne de http4 aurait jus­ti­fié de bas­cu­ler (panne longue, ser­veur hors ser­vice), nous ne remet­tons pas en cause notre déci­sion d’arrêter la redon­dance.

Une erreur tou­te­fois : nous aurions dû annon­cer publi­que­ment l’arrêt de cette redon­dance, fut-elle par­tielle (cer­tains ser­veurs ont encore la redon­dance d’activée à l’heure actuelle). C’est désor­mais chose faite.

D’autres formes de redondance à l’avenir ?

Si nous arrê­tons aujourd’hui la redon­dance via DRBD, il est pos­sible que nous nous diri­gions à l’avenir vers d’autres formes de redon­dance — par exemple une répli­ca­tion des bases de don­nées ou une syn­chro­ni­sa­tion sys­té­ma­tique des sys­tèmes de fichiers. Le but ne serait tou­te­fois pas uni­que­ment d’améliorer la dis­po­ni­bi­li­té mais d’offrir d’autres avan­tages, par exemple en termes de per­for­mances.

Précisons que la sup­pres­sion de la redon­dance en temps réel n’a stric­te­ment aucun lien avec les sau­ve­gardes, tou­jours effec­tuées quo­ti­dien­ne­ment et conser­vées pen­dant 30 jours.

En conclusion

Nous pré­sen­tons toutes nos excuses à nos clients pour cette panne excep­tion­nelle. Ceux qui ont été impac­tés peuvent ouvrir un ticket en deman­dant le rem­bour­se­ment inté­gral du mois d’octobre, comme nos condi­tions géné­rales de vente le sti­pulent.

Rappelons notre atta­che­ment à four­nir le meilleur taux de dis­po­ni­bi­li­té pos­sible, même sur un envi­ron­ne­ment mutua­li­sé. C’est un chal­lenge quo­ti­dien, compte tenu de la grande sou­plesse que nous offrons (e.g. ouvrir un compte sans payer, pou­voir faire tour­ner n’importe quel pro­ces­sus sur son compte).

Promettre qu’il n’y aura plus jamais de grosse panne serait illu­soire : per­sonne ne peut garan­tir cela. Ce que nous pro­met­tons, c’est une trans­pa­rence totale, durant l’incident et après, avec des mesures concrètes pour évi­ter que cela ne se repro­duise. Et des réponses à vos ques­tions, si vous en avez.