Forum

You are not logged in.

#1 02-04-2010 11:22:07

@Cyril
Staff
From: Paris
Registered: 06-02-2007
Posts: 5,560
Website

Perturbations de la matinée du 2 avril 2010

Bonjour,

D'importantes perturbations ont eu lieu ce matin, de 9h45 à 11h35, impactant une partie de nos clients.

Ce qui s'est passé

- un de nos serveurs HTTP (http5) a soudainement connu un packet loss important en IPv4 (environ 15 %) ;
- en conséquence, toutes les interactions entre ce serveur et les autres ont été fortement perturbées. Et notamment avec les serveurs SQL, mail et SSH ;
- l'accès mail, FTP et SSH était donc globalement gelé. Pire, les sites de nos clients impactés semblaient très lents dès qu'ils utilisaient du SQL.

Petit point technique pour que tout le monde comprenne : 15 % de packet loss, cela veut dire que 15 % des paquets (TCP en l'occurrence) n'arriveront pas à destination. Il n'y a pas de perte de données à proprement parler, puisque le paquet perdu sera réenvoyé après un timeout. Mais ce temps d'attente peut durer jusqu'à quelques secondes. Si vous avez 20 requêtes SQL pour afficher votre page, cela fait statistiquement 3 délais de retransmission à attendre.

Du coup, les pages s'affichaient très lentement. Pire : pour les sites les plus consultés, les processus FastCGI s'accumulaient jusqu'à atteindre la limite de 20. Au delà, les processus ne sont plus démarrés pour éviter les débordements. Du coup, ces sites étaient presque complètement inaccessibles.

Le serveur http5 est celui de la « nouvelle architecture », sur laquelle sont les clients ayant volontairement migrés et tous les nouveau comptes depuis environ un mois et demi.

Comment éviter que cela ne se reproduise à nouveau ?

Tout d'abord, nous n'avons pas de pouvoir sur la source même du problème (le packet loss), qui est du ressort de notre fournisseur. Cela ne veut toutefois pas dire que nous ne pouvons rien faire. On peut envisager plusieurs pistes :

- basculer en IPv6 (qui, en l'occurrence, n'était pas impacté par le problème) ;
- diminuer drastiquement le temps de retransmission TCP pour limiter les effets ;
- les mails seront bientôt hébergés en local plutôt que via NFS, ce qui rendrait l'architecture mail immune à ce genre de problème.

N'étant pas préparés à ce cas de figure, nous n'avons rien pu faire ce matin. Nous allons toutefois très rapidement réfléchir aux points ci-dessus pour parer une éventuelle situation identique à l'avenir.

Nous présentons naturellement toutes nos excuses aux clients touchés.

Offline

Board footer

Powered by FluxBB