OVHcloud Bare Metal Cloud Status
Current status
Legend
- Operational
- Degraded performance
- Partial Outage
- Major Outage
- Under maintenance
Strasbourg Stockage/Storage
Incident
Report for Bare Metal Cloud
Resolved
Suite à cet incident http://travaux.ovh.com/?do=details&id=21737 nous avons à nouveau 2 PG inactifs, nous travaillons à la résolution du problème.
Following http://travaux.ovh.com/?do=details&id=21737 we still have 2 inactives PG, we are working on fixing this.
Update(s):
Date: 2016-12-02 17:34:09 UTC
Here is was had been done during the last few days, the root causes and how we will improve the situation.
Root causes :
Hosts hanging under load on CPU 100% on sys due to some kernel bug
ceph monitors overloaded due to sharing CPU with OSDs and running on slow disk - caused slow peering of PGs and often monitor elections.
ceph osd hammer version bug which caused osd to fail to start after stopping (4 osds impacted) - http://tracker.ceph.com/issues/17916
ceph osd crashed due to failure to remove unfound object (1 osd impacted) - http://tracker.ceph.com/issues/10405
ceph PG recovery priority issue which preferred to handle recover_wait PGs (5k+) first to PGs which were inactive (2)
Actions :
(CET time)
2016-11-29 ~22:00 planned intervention to grow cluster
2016-11-29 23:00~04:00 2-3 hosts have had huge load and cpu was doing 100% on sys (cause unknown). After restart all continued
2016-11-30 ~04:40: A host hangs and we restart it
2016-11-30 ~5:00: An osd stops and fails to peer with other OSDs causing blocked requests on it's PGs
2016-11-30 ~8:00: restarted all OSDs rack by rack, 2 OSDs failed to start
2016-11-30 ~9:00: We stopped the same OSD which allowed solved PG blocking
2016-11-30 10:48: all PGs are active, recovery/rebalance ongoing
2016-11-30 15:00: rebalance almost stopped, investigating
2016-11-30 ~22:00: we force PG to peer by setting down it's OSD.
2016-11-30 ~23:30: rebalance is progressing in a nice way
2016-12-01 01:16 1/2 inactive pg left (count changes every few minutes)
2016-12-01 ~4:00: host crash with another osd not being able to start
2016-12-01 ~12:00 all PGs are active again, no more stuck in peered state
2016-12-01 15:30: one monitor still down, it's not able to sync with two others (syncing puts too big load on those two)
2016-12-01 ~18-20: monitors have elections every few seconds because of a monitor that have a disk overloaded
2016-12-01 ~22:00: added a monitor with increased mon_sync_timeout to 3000 which allowed it to sync and join quorum (~5 minutes quorum downtime in last sync phase). Mons load is now ok and they do not do elections. Recovery continues.
2016-12-01 ~23:30: deleted 2 osd containers which failed to restart - after all OSDs are up and in.
2016-12-02 01:18: Cluster stopped rebalancing 9K object missplaced due to 2 unfound objects stalling recovery of 2 PGs
2016-12-02 11:18: Both PG fixed, cluster rebalances.
2016-12-02 13:30: cluster fully rebalanced, all OK
Quick actions taken to solve the issue
created a monitor on empty host with optimized XFS to have better perf - after joining quorum monitor load decreased significantly
added 2 temp OSDs with PGs from crashed OSD to recover data
added 2 temp OSDs with same IDs as crashed OSDs to unclock recovery
manually increased osd_max_backfills on OSDs with inactive+peered PGs to make recovery faster
wrote script to sequentially ceph osd down OSDs with undersized PGs to unblock recovery on them
increased osd_recovery_max_active to 60 to speed up recovery of recovery_wait PGs
increased osd_max_backfills to 2 (temporary) to speed up backfilling
Improvements :
Provide more resources to monitors
Run monitors on an optimized storage
Working on host hanging
Upgrade cluster to Jewel
Voici ce qui a été fait durant le weekend, les root cause et ce qui sera fait pour améliorer les choses.
Root causes :
Serveurs qui freezent avec une charge CPU à 100% à cause d'un bug kernel
Moniteurs surchargés car ils partagent le processeur avec les OSD et utilisent des disques lents et non optimisés. Cela génère des peerings lents et des élections régulières.
Bug des OSD avec la version hammer qui empêche de redémarrer l'OSD après l'arrêt (4 osd impactés) - http://tracker.ceph.com/issues/17916
Crash d'un OSD car il n'arrivait pas à supprimer un object unfound (1 osd impacté) - http://tracker.ceph.com/issues/10405
Problème de priorisation par Ceph qui préfère gérer les PG en recover_wait (plus de 5000) avant les PG inactive (2)
Actions :
2016-11-29 ~22:00 Opération plannifiée pour faire grossir le cluster
2016-11-29 23:00~04:00 2/3 hosts ont une charge importante avec un CPU à 100%, serveurs redémarrés
2016-11-30 ~04:40: Un serveur freeze et nous le redémarrons
2016-11-30 ~5:00: Un osd s'arrête et n'arrive pas à joindre lse autres OSD ce qui bloque certaines requêtes.
2016-11-30 ~8:00: Redémarrage de tous les OSD rack par rack, 2 OSD ne redémarrent pas
2016-11-30 ~9:00: Nous arrêtons l'osd qui génrait le blocage de requêtes et les requêtes ne sont plus bloquées
2016-11-30 10:48: Tous les PG sont actifs, les données se déplacent.
2016-11-30 15:00: Les données se déplacent lentement, nous investiguons
2016-11-30 ~22:00: Nous forçons les PG à joindre le cluster en arrêtant l'OSD.
2016-11-30 ~23:30: Les données se déplacent parfaitement.
2016-12-01 01:16 On a 1 ou 2 PG inactifs qui flappent, pas d'impact sur les requêtes
2016-12-01 ~4:00: Un serveur crash et un OSD ne veut pas démarrer
2016-12-01 ~12:00 Tous les PG sont actifs, les données se déplacent.
2016-12-01 15:30: Un moniteur toujours KO, il n'arrive pas à se synchroniser avec les 2 autres à cause de la charge
2016-12-01 ~18-20: Les moniteurs font des élections toutes les quelques secondes à cause de la surcharge des disques
2016-12-01 ~22:00: Ajout d'un moniteur avec mon_sync_timeout à 3000 pour que le moniteur ait le temps de joindre le cluster. La charge des moniteurs diminue et il n'y a plus d'élections. Le déplacement des donnée progresse.
2016-12-01 ~23:30: Suppression des 2 OSD qui ne voulaient pas démarrer, tous les OSD sont UP et dans le cluster.
2016-12-02 01:18: Le cluster arrête de déplacer les données à cause de 2 PG, il ne reste que 9000 objects à déplacer.
2016-12-02 11:18: Les 2 PG sont réparés, les données se déplacent.
2016-12-02 13:30: Les données sont au bon endroit, tout est OK.
Actions prises pour rapidement résoudre le problème :
Créer un moniteur sur une machine vide avec un XFS optimisté pour avoir de meilleures performances. Après avoir rejoint le quorum la charge diminue de façon importante.
Ajout de 2 OSD temporaire avec les PG des OSD crashés pour conserver les données.
Ajout de 2 OSD temporaires avec des ID identiques aux OSD crashés pour débloquer le déplacement des données
Augmentation manuelle de osd_max_backfills sur les OSD ayant des PG inactive+peered pour récupérer rapidement les données.
Ecriture d'un script pour arrêter 1 à 1 les OSD ayant des PG udersize pour débloquer la récupération des données
Augmentation de osd_recovery_max_active à 60 pour débloquer plus rapidement les PG recovery_wait
Augmentation de osd_max_backfills à 2 (temporairement) pour que les donnée se déplacent plus rapidement
Améliorations :
Donner plus de resources aux moniteurs
Fournir un stockage optimisé aux moniteurs
Crueser/fixer les hosts qui freezent
Mettre à jour les clusters vers Jewel
Date: 2016-12-02 08:28:36 UTC
Les données sont maintenant correctement placés.
Data are now at the right place.
Date: 2016-12-01 14:48:59 UTC
Pour aller plus vite, nous priorisons de déplacement des données aux IO des utilisateurs.
Cela limite donc les IO utilisateurs.
To rebalance faster, we prioritise the data migrations above user IO.
It impacts users IO.
Date: 2016-12-01 12:12:17 UTC
Tous les PG sont maintenant actifs.
Le post mortem est en cours de réalisation, il sera partagé.
All PG are now activ.
The post mortem is in progress, it will be shared.
Date: 2016-12-01 10:24:23 UTC
Il reste 1 pg inactif, pour le dernier il faut attendre que autres PG en liens avec ce PG soient à jour.
La synchronisation est en cours.
1 inactiv PG left, for the last one we have to wait that his peered PG are up to date.
Syncing is in progress.
Following http://travaux.ovh.com/?do=details&id=21737 we still have 2 inactives PG, we are working on fixing this.
Update(s):
Date: 2016-12-02 17:34:09 UTC
Here is was had been done during the last few days, the root causes and how we will improve the situation.
Root causes :
Hosts hanging under load on CPU 100% on sys due to some kernel bug
ceph monitors overloaded due to sharing CPU with OSDs and running on slow disk - caused slow peering of PGs and often monitor elections.
ceph osd hammer version bug which caused osd to fail to start after stopping (4 osds impacted) - http://tracker.ceph.com/issues/17916
ceph osd crashed due to failure to remove unfound object (1 osd impacted) - http://tracker.ceph.com/issues/10405
ceph PG recovery priority issue which preferred to handle recover_wait PGs (5k+) first to PGs which were inactive (2)
Actions :
(CET time)
2016-11-29 ~22:00 planned intervention to grow cluster
2016-11-29 23:00~04:00 2-3 hosts have had huge load and cpu was doing 100% on sys (cause unknown). After restart all continued
2016-11-30 ~04:40: A host hangs and we restart it
2016-11-30 ~5:00: An osd stops and fails to peer with other OSDs causing blocked requests on it's PGs
2016-11-30 ~8:00: restarted all OSDs rack by rack, 2 OSDs failed to start
2016-11-30 ~9:00: We stopped the same OSD which allowed solved PG blocking
2016-11-30 10:48: all PGs are active, recovery/rebalance ongoing
2016-11-30 15:00: rebalance almost stopped, investigating
2016-11-30 ~22:00: we force PG to peer by setting down it's OSD.
2016-11-30 ~23:30: rebalance is progressing in a nice way
2016-12-01 01:16 1/2 inactive pg left (count changes every few minutes)
2016-12-01 ~4:00: host crash with another osd not being able to start
2016-12-01 ~12:00 all PGs are active again, no more stuck in peered state
2016-12-01 15:30: one monitor still down, it's not able to sync with two others (syncing puts too big load on those two)
2016-12-01 ~18-20: monitors have elections every few seconds because of a monitor that have a disk overloaded
2016-12-01 ~22:00: added a monitor with increased mon_sync_timeout to 3000 which allowed it to sync and join quorum (~5 minutes quorum downtime in last sync phase). Mons load is now ok and they do not do elections. Recovery continues.
2016-12-01 ~23:30: deleted 2 osd containers which failed to restart - after all OSDs are up and in.
2016-12-02 01:18: Cluster stopped rebalancing 9K object missplaced due to 2 unfound objects stalling recovery of 2 PGs
2016-12-02 11:18: Both PG fixed, cluster rebalances.
2016-12-02 13:30: cluster fully rebalanced, all OK
Quick actions taken to solve the issue
created a monitor on empty host with optimized XFS to have better perf - after joining quorum monitor load decreased significantly
added 2 temp OSDs with PGs from crashed OSD to recover data
added 2 temp OSDs with same IDs as crashed OSDs to unclock recovery
manually increased osd_max_backfills on OSDs with inactive+peered PGs to make recovery faster
wrote script to sequentially ceph osd down OSDs with undersized PGs to unblock recovery on them
increased osd_recovery_max_active to 60 to speed up recovery of recovery_wait PGs
increased osd_max_backfills to 2 (temporary) to speed up backfilling
Improvements :
Provide more resources to monitors
Run monitors on an optimized storage
Working on host hanging
Upgrade cluster to Jewel
Voici ce qui a été fait durant le weekend, les root cause et ce qui sera fait pour améliorer les choses.
Root causes :
Serveurs qui freezent avec une charge CPU à 100% à cause d'un bug kernel
Moniteurs surchargés car ils partagent le processeur avec les OSD et utilisent des disques lents et non optimisés. Cela génère des peerings lents et des élections régulières.
Bug des OSD avec la version hammer qui empêche de redémarrer l'OSD après l'arrêt (4 osd impactés) - http://tracker.ceph.com/issues/17916
Crash d'un OSD car il n'arrivait pas à supprimer un object unfound (1 osd impacté) - http://tracker.ceph.com/issues/10405
Problème de priorisation par Ceph qui préfère gérer les PG en recover_wait (plus de 5000) avant les PG inactive (2)
Actions :
2016-11-29 ~22:00 Opération plannifiée pour faire grossir le cluster
2016-11-29 23:00~04:00 2/3 hosts ont une charge importante avec un CPU à 100%, serveurs redémarrés
2016-11-30 ~04:40: Un serveur freeze et nous le redémarrons
2016-11-30 ~5:00: Un osd s'arrête et n'arrive pas à joindre lse autres OSD ce qui bloque certaines requêtes.
2016-11-30 ~8:00: Redémarrage de tous les OSD rack par rack, 2 OSD ne redémarrent pas
2016-11-30 ~9:00: Nous arrêtons l'osd qui génrait le blocage de requêtes et les requêtes ne sont plus bloquées
2016-11-30 10:48: Tous les PG sont actifs, les données se déplacent.
2016-11-30 15:00: Les données se déplacent lentement, nous investiguons
2016-11-30 ~22:00: Nous forçons les PG à joindre le cluster en arrêtant l'OSD.
2016-11-30 ~23:30: Les données se déplacent parfaitement.
2016-12-01 01:16 On a 1 ou 2 PG inactifs qui flappent, pas d'impact sur les requêtes
2016-12-01 ~4:00: Un serveur crash et un OSD ne veut pas démarrer
2016-12-01 ~12:00 Tous les PG sont actifs, les données se déplacent.
2016-12-01 15:30: Un moniteur toujours KO, il n'arrive pas à se synchroniser avec les 2 autres à cause de la charge
2016-12-01 ~18-20: Les moniteurs font des élections toutes les quelques secondes à cause de la surcharge des disques
2016-12-01 ~22:00: Ajout d'un moniteur avec mon_sync_timeout à 3000 pour que le moniteur ait le temps de joindre le cluster. La charge des moniteurs diminue et il n'y a plus d'élections. Le déplacement des donnée progresse.
2016-12-01 ~23:30: Suppression des 2 OSD qui ne voulaient pas démarrer, tous les OSD sont UP et dans le cluster.
2016-12-02 01:18: Le cluster arrête de déplacer les données à cause de 2 PG, il ne reste que 9000 objects à déplacer.
2016-12-02 11:18: Les 2 PG sont réparés, les données se déplacent.
2016-12-02 13:30: Les données sont au bon endroit, tout est OK.
Actions prises pour rapidement résoudre le problème :
Créer un moniteur sur une machine vide avec un XFS optimisté pour avoir de meilleures performances. Après avoir rejoint le quorum la charge diminue de façon importante.
Ajout de 2 OSD temporaire avec les PG des OSD crashés pour conserver les données.
Ajout de 2 OSD temporaires avec des ID identiques aux OSD crashés pour débloquer le déplacement des données
Augmentation manuelle de osd_max_backfills sur les OSD ayant des PG inactive+peered pour récupérer rapidement les données.
Ecriture d'un script pour arrêter 1 à 1 les OSD ayant des PG udersize pour débloquer la récupération des données
Augmentation de osd_recovery_max_active à 60 pour débloquer plus rapidement les PG recovery_wait
Augmentation de osd_max_backfills à 2 (temporairement) pour que les donnée se déplacent plus rapidement
Améliorations :
Donner plus de resources aux moniteurs
Fournir un stockage optimisé aux moniteurs
Crueser/fixer les hosts qui freezent
Mettre à jour les clusters vers Jewel
Date: 2016-12-02 08:28:36 UTC
Les données sont maintenant correctement placés.
Data are now at the right place.
Date: 2016-12-01 14:48:59 UTC
Pour aller plus vite, nous priorisons de déplacement des données aux IO des utilisateurs.
Cela limite donc les IO utilisateurs.
To rebalance faster, we prioritise the data migrations above user IO.
It impacts users IO.
Date: 2016-12-01 12:12:17 UTC
Tous les PG sont maintenant actifs.
Le post mortem est en cours de réalisation, il sera partagé.
All PG are now activ.
The post mortem is in progress, it will be shared.
Date: 2016-12-01 10:24:23 UTC
Il reste 1 pg inactif, pour le dernier il faut attendre que autres PG en liens avec ce PG soient à jour.
La synchronisation est en cours.
1 inactiv PG left, for the last one we have to wait that his peered PG are up to date.
Syncing is in progress.
This incident affected: Virtual Private Servers || Operating System (ERI, GRA, SBG, LIM, WAW, BHS, SGP, SYD).