OVHcloud Web Hosting Status

Current status
Legend
  • Operational
  • Degraded performance
  • Partial Outage
  • Major Outage
  • Under maintenance
PrivateSQL P19
Incident Report for Web Cloud
Resolved
# FR #
Nous avons un incident impactant les instances privateSQL de P19 depuis 2018-07-12 18h08 UTC.
Investigations en cours.

# EN #
We are having an incident on all PrivateSQL instances hosted at P19 since 2018-07-12 18h08 UTC.
Investigations in progress

Update(s):

Date: 2018-07-13 14:55:05 UTC
# FR #
Retour à la normal, toutes les bases sont actives.

# En #
Back to normal, everything is working.

Date: 2018-07-13 13:05:17 UTC
# FR #
Il reste 9 bases a traiter.

# En #
Still 9 databases are not working.

Date: 2018-07-13 10:55:08 UTC
# FR #
Le service de bases de données est opérationnel.
Il reste 20 bases sur 11500 qui sont encours d'investigation car elles ne démarrent pas.

# En #
Databases services are UP and Running.
Still 20 databases on 11500 are under investigation to know why they don't start.

Date: 2018-07-13 10:29:13 UTC
Bonjour,
Hier à 18h08, nous avons eu un souci sur l'un de cluster de stockage qui héberge une partie de bases de données de l'hébergement mutualisé dans le datacentre de p19 (encore lui). Cette panne a impacté 10000 sites web PERSO et PRO sur 1.3M qu'OVH héberge. La panne a été très complexe à fixer et a pris 14H-15H.

Le cluster de stockage CEPH impacté se compose de 18 serveurs hébergés dans 3 baies différentes qui travaillent ensemble. Chaque donnée est stockée sur 3 serveurs, chacun serveurs dans une baie séparée. Les serveurs sont alimentés par 2 sources d’énergie, 2 UPS différents. L'un des UPS a fait une surtension de 20% durant 3 minutes vers 18h00 (on ne connait pas encore l'origine). Cette surtension a eu pour conséquence de casser certains composant de certains serveurs (comme par exemple les disques NVMe). On pense que c'est lié à un bug dans un type de carte mère. La conséquence sur le cluster de stockage en question est que nous avons perdu 3 serveurs \"au hasard\" sur 18 serveurs:
- 1 serveur dans la 1ere baie
- 2 serveurs dans la 2eme baie
- 0 serveur dans la 3eme baie.

Afin de garantir le maximum de performance, nous configurons les clusters CEPH en mode performance : une donnée est divisée en 18 et on enregistre chaque petit morceau sur l'un de 18 serveurs en même temps.

En même temps le cluster CEPH est configuré pour protéger l’intégrité de données: le cluster s’arrête de fonctionner lors qu'il ne reste plus qu'une copie de données.

La conséquence d'avoir 3 serveurs en panne, au hazard, dans 2 baies sur 3, avec la configuration en max performance et l’intégrité à 1 copie a fait que le cluster s'est arrête de fonctionner à 18h02.

Nous avons fait beaucoup d'essais pour faire repartir le cluster en configuration initiales à 18 serveurs. Vers 1H du matin, nous avons pris la décision de reconfigurer le cluster avec 16 serveurs en laissant le cluster repliquer les données 3 fois mais les 16 serveurs. Cette opération a pris 4h et s'est terminé vers 6h du matin. Puis le matin nous avons redémarré les VMs avec les bases de données et nous avons vérifié que toutes les bases de données ont été en fonctionnement.

Il n'y a aucune perte de données. Toutes les données, y compris, enregistrées sur les caches NVMe ont été récupérées.

En tout, la panne a duré entre 14H et 15H pour les 10000 bases de données qui permettent aux 10000 sites web de fonctionner.

Nous sommes sincèrement désolés pour cette nouvelle panne sur l'hébergement mutualisé lié à notre ancien DC à P19. Les travaux sont en cours pour migrer tous les sites web PERSO et PRO dans nos DCs à GRA. Nous avons fini de coder tous les scripts de migrations durant ces derniers 6 mois et les premières migrations ont commencé la semaine passée. En tout, déjà 40% de sites web PERSO PRO que nous hébergeons sont déjà sur GRA et dans environ 3 à 4 mois 100% des ces sites web seront en dehors de P19.

En parallèle, cet incident a mis en lumière un type de panne \"improbable\" qui nous est quand même arriver sur nos clusters de stockage CEPH. Nous allons vérifier toutes les configurations CEPH que nous avons en production dans l'ensemble de nos DCs afin de garantir que chaque baie d'un cluster de stockage est dans un DC différent avec une source énergie et réseau différent. Le concept d'AZ est en train d'arriver dans nos produits et cela sera une bonne manière de l'utiliser en tant que le client interne.

Amicalement
Octave




Date: 2018-07-13 10:09:20 UTC
# FR #
90 % des bases de données sont actuellement fonctionnelles.
Nous travaillons au redémarrage des 10 % restants.

# En #
90% of the databases are UP and running.
We work at restarting the last 10%.

Date: 2018-07-13 08:57:41 UTC
# FR #
Toutes les machines sont fonctionnelles, des bases de données ne redémarrent pas.
Nous travaillons au rétablissement de ces bases.

# En #
All the PCI hosts are UP and running with a working Ceph. But still some databases don't goes UP.
We are working at make them work.

Date: 2018-07-13 08:42:19 UTC
# FR #
La communication entre PCI et Ceph est rétablie.
Les containers redémarrent et le service de bases de données va se rétablir.
Nous travaillons sur les dernières machines qui ne démarrent pas.

Liste des machines impactées :

privatesql020.p19.paas
privatesql064.p19.paas
privatesql122.p19.paas
privatesql109.p19.paas
privatesql042.p19.paas
privatesql089.p19.paas
privatesql071.p19.paas


# En #
Link between PCI and Ceph is UP.
Containers are starting and databases services will be UP soon.
We still work at starting the last failing hosts :

privatesql020.p19.paas
privatesql064.p19.paas
privatesql122.p19.paas
privatesql109.p19.paas
privatesql042.p19.paas
privatesql089.p19.paas
privatesql071.p19.paas


Date: 2018-07-13 08:22:09 UTC
# FR #
Le souci perdure, les différentes équipes travaillent à résoudre les problèmes de communication entre Ceph et PCI.

# En #
Issue is still ongoing, all the impacted team are working to solve the issue of link between Ceph and PCI.

Date: 2018-07-13 07:47:30 UTC
# FR #
Le cluster Ceph est fonctionnel. Les machines sur PCI sont en cours de redémarrage. Cependant, la liaison Ceph - PCI semble bloquée pour le moment. Nous continuons les investigations.

# En #
Ceph cluste is UP and running. Host on PCI are starting up but the link between Ceph and PCI seems to be stucked. We still investigate

Date: 2018-07-13 06:18:41 UTC
# FR #
Les données sont désormais sécurisées, mais nous rencontrons des difficultés à communiquer avec le cluster Ceph.
Toutes nos équipes poursuivent activement leur travail pour résoudre cet incident au plus vite.

# En #
Data are now secured but we are having difficulties communicating with the Ceph cluster.
All teams remain actively working on solving this incident as soon as possible.

Date: 2018-07-13 04:37:16 UTC
# FR #
Progression : 100 %
Les données sont sécurisées et le cluster Ceph est à nouveau stable.
Nous relançons progressivement le service.

# EN #
Progress: 100%
All data are secured and the Ceph cluster is stable again.
We are gradually putting the service back online.

Date: 2018-07-13 03:57:15 UTC
# FR #
Progression : 90 %

# EN #
Progress: 90%

Date: 2018-07-13 03:38:44 UTC
# FR #
Progression : 85 %

# EN #
Progress: 85%

Date: 2018-07-13 03:02:39 UTC
# FR #
Progression : 80 %

# EN #
Progress: 80%

Date: 2018-07-13 02:32:47 UTC
# FR #
Cette nuit, l'objectif est de dupliquer à nouveau les données sur 3 réplicats afin de rétablir le service en toute sécurité.
Dans un second temps, nous procéderons à l'ajout de nouveaux serveurs au cluster afin d'améliorer les performances et empêcher ce type d'incident de se reproduire.

Progression : 70 %

# EN #
Tonight, the goal is to duplicate the data 3 times in order to recover the service in the safest conditions.
In a second time, we will add additional servers to the cluster in order to both increase performances and preventing this type of incident from happening again.

Progress: 70%

Date: 2018-07-13 01:51:36 UTC
# FR #
Informations additionnelles : un cluster Ceph organise ses données (objets) sous forme de grappes logiques appelées \"placement groups\".
Afin de garantir l’intégrité et la disponibilité des données, chaque objet est répliqué dans 3 grappes logiques, aussi appelées \"failure domains\".
Par design, nous avons fait le choix de séparer ces grappes par racks physiques, et nous nous assurons que l'association \"grappe/racks\" garantit une anti-affinité des données au sein du centre de données.

L'incident qui s'est produit la nuit dernière a conduit à la perte de 2 serveurs, dans 2 rack différents, mais portant les réplicats d'une seule et même grappe.
Dans ces conditions, le cluster Ceph détecte que la grappe ne possède qu'une seule copie de ses objets (plutôt que 3) et se met en sécurité.

Le post-mortem complet suivra sous peu.

Nous avons initié la reconstruction des objets vers 23h20 UTC.
Ce ticket sera régulièrement mis à jour pour suivre l'avancement.

# EN #
A Ceph cluster organizes its data (objects) as logical groups called \"placement groups\".
In order to guarantee data integrity and availability, each object is duplicated across 3 logical groups called \"failure domains\".
By design, we made the choice to split these groups across physical rack, while ensuring that the \"group/rack\" association guarantees data anti-affinity within the datacenter.

The incident that occurred last night involved the loss of 2 distinct servers, physically located in 2 different racks but holding the replicated data of one single placement group.
In such situation, Ceph detects that only 1 copy of the objects exist (instead of 3) and put itself on stand-by.

The complete post-mortem will be posted soon.

We have started re-replicating the data around 23h20 UTC.
This ticket will be updated on a regular basis to follow up on the progress.

Date: 2018-07-12 22:25:20 UTC
# FR #
Nous sommes actuellement en train de bencher les composants en atelier. L'objectif étant de s'assurer que les données n'ont pas été altérées par l'incident.
Nous prenons toutes les précautions pour garantir l'intégrité des données et visons à restaurer le service au plus vite.

# EN #
We are currently benching hardware parts in our lab. The goal here is to ensure data haven't been altered by the incident.
We take all precautions to ensure data integrity and aim at restoring the service as soon as possible.

Date: 2018-07-12 21:31:11 UTC
# FR #
Comme mentionné précédemment, nous avons subitement perdu 3 hôtes de notre cluster Ceph. Par mesure de sécurité (l'intégrité des données passe avant tout), le cluster a été mis en stand-by le temps d'intervenir.
Malheureusement, certains disques NVMe ne sont pas correctement reconnus par la carte mère. Cette défaillance peut avoir plusieurs origines. Nous étudions toutes les possibilités pour restaurer le service sans avoir recours à de la reconstruction de données.

# EN #
As previously mentioned, we have lost 3 hosts on Ceph cluster. The cluster has been put on stand-by as a preventive measure (data integrity is our top priority here).
Unfortunately, some NVMe disks are not properly recognized by the motherboard. This faulty behavior can have multiples origins and we are analyzing all potential solutions in order to restore the service while avoiding data reconstruction.

Date: 2018-07-12 20:15:41 UTC
# FR #
Nos équipes travaillent toujours très activement à la résolution de cet incident.

# EN #
Our team are still actively working on solving this incident.

Date: 2018-07-12 19:30:30 UTC
# FR #
L'origine de l'incident a été identifiée : nous avons perdu 3 hôtes appartenant au cluster Ceph.
Nos techniciens travaillent activement à restaurer les équipements.

# EN #
The incident root cause has been identified: We have lost 3 hosts belonging to Ceph cluster.
Our technicians are actively working on fixing the faulty equipments.

Date: 2018-07-12 19:25:20 UTC
# FR #
Plusieurs serveurs du cluster de stockage hébergeant les PrivateSQL sont à l’arrêt. Le cluster s’est mis en sécurité pour éviter toute perte de données.

Nous travaillons avec les équipes du datacenter pour les relancer.

# EN #
Multiple hosts of the PrivateSQL storage cluster are curently down. Cluster automaticaly stopped all operation as a safety measure.

We are working with datacenters team to start them back.
Posted Jul 12, 2018 - 18:28 UTC
This incident affected: Web Hosting || Datacenter GRA (Cluster002, Cluster003, Cluster006, Cluster007, Cluster011, Cluster012, Cluster013, Cluster014, Cluster015, Cluster017, Cluster020, Cluster021, Cluster023, Cluster024, Cluster025, Cluster026, Cluster027, Cluster028, Cluster029, Cluster030, Cluster031).