Support R3ZO

Le 9 novembre 2017, OVH fait face à un crash sans précédent sur son datacentre de Strasbourg à la suite d'une coupure électrique qui se passe mal.
Récit d'Octave Klaba, patron d'OVH, lecture instructive : http://travaux.ovh.net/?do=details&id=28247

Depuis 7h30 les services ont été perturbés puis totalement inaccessibles, à la suite d'une panne électrique sur les sites de Strasbourg, puis un blackout réseau sur le réseau Europeen d'OVH.

• 7h14 panne électrique sur le site de Strasbourg.
  Les groupes électrogènes de secours d'OVH n'ont pas démarré la conséquence : nous perdons notre serveur serv036 (l'un de nos hotes de machines virtuelles)

• Vers 8h alors que nous étudions la pertinence de basculer les services vers nos autres serveurs, le réseau d'OVH devient inopérant :

• Communiqué d'Octave Klaba de 8h15 :

Nous avons un souci d'alimentation de SBG1/SBG4. Les 2 arrivées électriques EDF sont down (!!) et les 2 chaines de groupes électrogènes se sont mis en défaut (!!!). L’ensemble de 4 arrivées elec n'alimentent plus la salle de routage. Nous sommes tous sur le problème.

• A partir de 8h aucune manipulation n'est possible compte tenue de l'état général du réseau d'OHV.

• 10h18, Octave Klaba :

SBG: 2 routing rooms are UP powered by gen. EDRF still down. ETA: 15min RBX: the DB of the optical node in RBX is corrupted. All links are still down. We upload the backup. ETA: 30min

On espère un rétablissement avant 11h

• 10h58 Roubaix est repartit, mais Strasbourg est toujours OFF. Le tableau de bord d'OVH est inopérant à cause de l'afflux de gens en panic.

• 11h Actuellement tout un pan des services et hébergement R3ZO est toujours OFF.

• 10h46, Octave Klaba (Twitter) :

SBG: ERDF repared 1 line 20KV. the second is still down. All Gens are UP. 2 routing rooms coming UP. SBG2 will be UP in 15-20min (boot time). SBG1/SBG4: 1h-2h

Donc pour les services encore en incident, rétablissement à prévoir vers 13h.

• 12h : les serveurs R3ZO sont tous remontés.
  Notre serv036 a subit deux arrêt 7h22 et 10h24 et 2 démarrages à 9h49 et 11h17. Autant dire qu'il à pris sa dose d'arrêts brutaux.
  Nous l'avons laissé vérifier ses filesystem avant de démarrer les services à partir de midi.

12h30 : Tous les services sont UP
Cependant nous observons encore des instabilités du réseau qui peuvent se traduire par des lenteurs de service notamment dans le chargement des pages web ou des mails.

Une partie des informations fournies par OVH : http://travaux.ovh.net/?do=details&id=28256

Bonjour,
Cette nuit le système de notre VM mutualisée 001 est passé en lecture seule. Il n'est plus possible d'écrire sur ses disques. Les conséquences sont une dégradation progressive des services, certains continuaient de fonctionner sans nécessité d'écrire des données, d'autres sont en dysfonctionnement total.

Nous avons choisi de restaurer une sauvegarde suffisamment antérieur pour ne pas se précipiter à nouveau dans le même problème. Nous restaurerons sur cette sauvegarde les dernières modifications enregistrées sur les bases de données.

Les services de cette VM sont totalement interrompus le temps de l'intervention. Seulement 3 sites web sont concernés, dont le site r3zo.com

Dans le cadre de l'évolution de la technologie utilisée par OVH pour nous fournir des réseaux privés, nous sommes contraints de mettre à jour les configurations réseau d'une partie de nos machines virtuelles et des serveurs physiques qui les hébergent.
Cette opération va durée plusieurs jours à partir du mardi 6 octobre, car nous procédons VM par VM pour minimiser l'impact sur les services hébergés.
Il est possible que ces manipulations provoquent des coupures de service de l'ordre de quelques minutes.
- Intervention terminée le 14 octobre -

Aujourd'hui, l'un de nos bloc RIPE principaux n'était plus routé correctement par OVH.
Plus d'informations sur cet incident viendront plus tard.

L'un de nos serveur de mail / IMAP perd sa connexion réseau depuis mercredi 4 juin à 12h02.
Nous nous efforçons de remonté cette connexion, mais celle-ci n'est pas stable. Le résultat est une alternance de disponibilités et d'indisponibilités du serveur entre midi et minuit ce mercredi. Les mails ne sont pas perdus, mais ne sont pas toujours délivrés rapidement.
Nos investigations nous conduisent successivement à : des recherches de traces d'attaques réseau, de modification de tables de routage, d'un changement d'IP, l'ajout d'IP, ... puis un changement de type de carte réseau.

4 juin : on cherche, on trouve, ça ne suffit pas, on cherche encore ...
5 juin 2h46 : ultime reboot avec une carte réseau supplémentaire
5 juin 8h : une partie de la queue de mails est restée en attente une douzaine d'heure
...
5 juin 9h45 : changement de type de carte réseau - reboot
...
5 juin 11h54 : Depuis 10h la situation est stable.

serv020 subit une mise en maintenance prévue de 15 min pour réinstallation du module de reboot.
Impact : coupures de 15mn sur certaines machines virtuelles et perturbation de l'acheminement du mail.

Intervention terminée, certains services ont été impactés entre 15h50 et 16h50.

Depuis 6h ce matin serv029 est instable avec des load très important. Intervention en cours.

10h45 : Le système est bloqué, je ne peux intervenir au niveau logiciel.

10h51 : OVH planifie un changement RAM et CPU dans l'heure.

11h20 : Les services redémarrent

Mercredi 25 octobre 2013.
Nous avons un serveur de virtualisation injoignable depuis 10h04, ainsi que les machines virtuelles qu'il supporte. Le problème est dû à un problème réseau chez OVH.
Tous les serveurs de plusieurs baies sont dans cet état et le support d'OVH à décidé de les remonter un par un.
Quelques informations sont disponible ici : http://travaux.ovh.net/?do=details&id=9568

Pour les clients qui ne sont pas en HA, nous attendons quelques minutes que OVH répare. Si le problème persiste, nous remontrons les VM sur un autre hyperviseur.

Les ralentissements provoqués sont perceptibles. Nous basculons certaines VM vers un autre hôte.