{"id":997,"date":"2011-12-28T11:08:42","date_gmt":"2011-12-28T10:08:42","guid":{"rendered":"http:\/\/blogdev.alwaysdata.com\/2011\/12\/28\/details-sur-les-perturbations-des-14-et-23-decembre\/"},"modified":"2018-02-01T16:32:41","modified_gmt":"2018-02-01T15:32:41","slug":"details-sur-les-perturbations-des-14-et-23-decembre","status":"publish","type":"post","link":"https:\/\/blog.alwaysdata.com\/fr\/2011\/12\/28\/details-sur-les-perturbations-des-14-et-23-decembre\/","title":{"rendered":"D\u00e9tails sur les perturbations des 14 et 23 d\u00e9cembre"},"content":{"rendered":"

Les 14 et 23 d\u00e9cembre 2011, deux incidents ont impact\u00e9 le bon fonctionnement de nos services pour une majorit\u00e9 de nos clients. Ce billet revient sur ce qui s\u2019est pass\u00e9 et sur les conclusions que nous en tirons.<\/p>\n

Ce qui s\u2019est pass\u00e9<\/h2>\n

Le 14 d\u00e9cembre<\/h3>\n

Le 14 d\u00e9cembre vers 18h30, nous avons d\u00e9tect\u00e9 un packet loss d\u2019environ 3 % entre certains de nos serveurs (http4 et http6). Ce packet loss a eu des r\u00e9percussions imm\u00e9diates pour les comptes concern\u00e9s : la communication entre ces serveurs et nos autres serveurs internes (SQL, SSH, FTP) \u00e9tait fortement ralentie. Concr\u00e8tement, le temps d\u2019affichage d\u2019une page Web faisant de nombreux acc\u00e8s \u00e0 la base de donn\u00e9es pouvait passer de 0,5 \u00e0 plus de 5 secondes.<\/p>\n

Nous avons imm\u00e9diatement averti notre fournisseur de ce packet loss afin qu\u2019il y rem\u00e9die. Moins de 30 minutes apr\u00e8s, le probl\u00e8me avait disparu.<\/p>\n

Le packet loss est r\u00e9apparu plus tard dans la soir\u00e9e, avant de disparaitre \u00e0 nouveau. \u00c0 nouveau le lendemain, le probl\u00e8me est r\u00e9apparu al\u00e9atoirement. Devant les difficult\u00e9s de notre fournisseur \u00e0 isoler et r\u00e9soudre la source du probl\u00e8me \u2013 le caract\u00e8re intermittent n\u2019aidant pas \u2013 nous avons d\u00e9cid\u00e9 de d\u00e9ployer en urgence une fonctionnalit\u00e9 qu\u2019il propose : les VLAN<\/a>. Cela permet \u00e0 nos serveurs de communiquer entre eux via un chemin privil\u00e9gi\u00e9, isol\u00e9 du r\u00e9seau public.<\/p>\n

Apr\u00e8s avoir rapidement effectu\u00e9 quelques tests et nous \u00eatre assur\u00e9s que le probl\u00e8me initial de packet loss \u00e9tait r\u00e9solu en passant par les VLAN, nous avons d\u00e9marr\u00e9 le d\u00e9ploiement sur nos serveurs impact\u00e9s. Ce d\u00e9ploiement a n\u00e9cessit\u00e9 une mise \u00e0 jour du noyau, et donc un red\u00e9marrage de plusieurs serveurs. En fin de soir\u00e9e, le probl\u00e8me \u00e9tait r\u00e9solu, \u00e0 l\u2019exception des acc\u00e8s FTP encore partiellement ralentis.<\/p>\n

Pr\u00e9cisons que nous avions pr\u00e9vu d\u2019utiliser les VLAN \u2013 fonctionnalit\u00e9 lanc\u00e9e depuis plusieurs mois par notre fournisseur \u2013 au premier semestre 2012. Pourquoi pas avant ? Parce que pour \u00eatre d\u00e9ploy\u00e9 correctement, cela demande du temps ; la mise en production effectu\u00e9e pour r\u00e9soudre le probl\u00e8me reste relativement bancale et temporaire. Par ailleurs, cette fonctionnalit\u00e9 n\u2019est pas non plus exempte de probl\u00e8mes, et nous pr\u00e9f\u00e9rons \u00e9viter de nous ruer vers les nouveaut\u00e9s pour en essuyer les pl\u00e2tres.<\/p>\n

Le 23 d\u00e9cembre<\/strong><\/p>\n

Le probl\u00e8me initial \u2013 le packet loss al\u00e9atoire \u2013 a toutefois perdur\u00e9, bien qu\u2019il ne nous impactait plus. Le 23 d\u00e9cembre \u00e0 22h05, l\u2019acc\u00e8s \u00e0 nos deux serveurs http4 et http6 est devenu tr\u00e8s fortement perturb\u00e9 : plus de 50 % de packet loss. Cette fois-ci, le probl\u00e8me ne concernait pas uniquement le trafic interne mais aussi le trafic externe (d\u2019Internet vers nos serveurs). En cons\u00e9quence, l\u2019acc\u00e8s \u00e0 l\u2019ensemble des sites est devenu extr\u00eamement difficile (l\u2019ensemble des autres services n\u2019\u00e9tant pas impact\u00e9).<\/p>\n

Nous avons imm\u00e9diatement remont\u00e9 le probl\u00e8me \u00e0 notre fournisseur, puis avons d\u00e9cid\u00e9 parall\u00e8lement de le contourner en redirigeant le trafic HTTP vers d\u2019autres serveurs non impact\u00e9s, ces derniers servant alors de proxy vers les serveurs perturb\u00e9s (en communiquant via le VLAN). Vers minuit \u2013 il a fallu le temps d\u2019attendre la propagation DNS \u2013 le probl\u00e8me \u00e9tait donc en tr\u00e8s grande partie r\u00e9solu, du moins dans les faits. Vers 1h30, notre fournisseur a pu identifier et r\u00e9soudre le probl\u00e8me. Nous avons alors pu rebasculer le trafic sur les serveurs HTTP d\u2019origine.<\/p>\n

Conclusions<\/h2>\n

Plusieurs conclusions peuvent \u00eatre tir\u00e9es de ces perturbations :<\/p>\n