OVHcloud Bare Metal Cloud Status
Current status
Legend
- Operational
- Degraded performance
- Partial Outage
- Major Outage
- Under maintenance
Cluster de stockage SBG/GRA
Scheduled Maintenance
Report for Bare Metal Cloud
Completed
Nous constatons une augmentation de la latence à intervalle régulière sur le cluster de stockage.
Nous investiguons pour trouver l'origine de cette latence.
Update(s):
Date: 2016-10-26 12:44:12 UTC
Performance degradation was caused by rbd images having more than 5 snapshots. Those snapshots were left after bogus backups or those that were still in progress. We ensured that no unneeded snapshots are present which restored the performance to correct levels.
Large number of snapshots on an rbd image does affect number of attributes ceph has to store for rados objects. Rados object attributes can be stored in either xfs attrs or in internal leveldb key-value store. Ceph does determine whether attribute ends up in xfs xattrs or in leveldb by checking the length of value and number of attributes.
Due to misconfiguration of ceph in our clusters, those threshold values were to high. Although xfs can handle such larger xattr values, the performance of such operations is much lower because they're not inlined inside inode structure. We observed that some xattr writes took more than 200ms compared to usual less than 1ms.
Due to internal sequencing mechanisms in ceph, such long xattr update can cause degradation of given osd node and thus the whole cluster.
La dégradation des performances était causé par les images rbd ayant plus de 5 snapshots. Ces snapshots étaient présents à cause d'un bug dans la gestion des backups ou à cause de backups en cours. L'anomalie corrigée, nous n'avons plus cette situation et les performances sont à nouveau celles attendues.
Un grand nombre de snapshots sur une image rbd impacte le nombre d'attributs que Ceph doit stocker pour les objets rados. Les attributs objets rados peuvent être stockés entant qu'attributs XFS ou par Ceph lui même dans sa base leveldb. Ceph détermine le meilleur choix en fonction de la longueur de la valeur et du nombre d'attributs.
A cause d'une mauvaise configuration de Ceph sur nos clusters, ces valeurs étaient trop hautes. Bien qu'XFS puisse gérer de grandes valeurs xattr, les performances des performances sont inférieures car ces attributs se retrouvent éparpillés sur plusieurs inode. Nous avons observé que certains écritures d'xattr pouvait prendre plus de 200ms là ou elle prend habituellement moins d'1ms.
A cause du séquençage interne de Ceph, une mise à jour lente d'un xattr peut diminuer les performances d'un OSD et donc du cluster dans sa globalité.
Date: 2016-10-17 15:42:41 UTC
Première opération terminée, On réalise un petite modification dans la soirée pour préparer la seconde opération.
First operation done, we realize a little modification in the evening to prepare the second operation.
Date: 2016-10-15 15:21:12 UTC
Opération terminée, nous ferons la prochaine opération lundi.
Operation done, we'll do the next one on monday.
Date: 2016-10-14 21:09:23 UTC
Début de l'opération.
Operation started.
Date: 2016-10-13 14:05:01 UTC
We dug up to analyzing the kernel's syscall to understand what's going on.
we found a similar behavior between this cluster and the one with constant performances.
There are some large writing sequences then reading sequences, coincidence makes that some disks receives more writes and reads than the other. We'll change the configuration to have a better data allocation.
In a second time we'll update Ceph to a more recent release.
The configuration change will be done in several times and will start at the end of the week, it will impact the performances.
For the update we are currently doing some tests to confirm the his usage on our infrastructure.
Date: 2016-10-11 13:40:46 UTC
On a creusé jusqu'à analyser les appels systèmes (syscalls) du kernel pour comprendre ce qu'il se passe.
On retrouve un comportement similaire entre ce cluster et ceux ayant des performances constantes.
Il y a de grosses séquences d'écriture puis de lecture , le hasard fait que certains disques reçoivent plus d'écritures et lectures que d'autres. Nous allons donc modifier la configuration pour mieux répartir les données.
Dans un second temps nous allons mettre à jour la version de Ceph utilisée sur ce cluster.
Le changement de configuration sera réalisé en plusieurs fois à partir de la fin de semaine et entraînera une diminution des performances.
Pour la mise à jour nous effectuons des tests pour valider le bon fonctionnement de la nouvelle version.
Date: 2016-09-23 15:49:53 UTC
Nous continuons nos investigations, pour l'instant celles-ci nous ont uniquement permis d'écarter de potentielles causes.
Date: 2016-09-22 14:24:18 UTC
Sortir le disque remontant le plus de latence n'a pas rétabli les performances attendues, nous continuons nos investigations.
Date: 2016-09-22 09:35:39 UTC
les logs remontent des disques du cluster avec un haut temps de réponse. Cependant quelques disques se démarquent par un plus grand nombre d'occurrence.
Nous cherchons à comprendre ce qui explique cela, il est possible que l'on sorte des disques du cluster pour observer l'influence de ceux-ci.
Nous investiguons pour trouver l'origine de cette latence.
Update(s):
Date: 2016-10-26 12:44:12 UTC
Performance degradation was caused by rbd images having more than 5 snapshots. Those snapshots were left after bogus backups or those that were still in progress. We ensured that no unneeded snapshots are present which restored the performance to correct levels.
Large number of snapshots on an rbd image does affect number of attributes ceph has to store for rados objects. Rados object attributes can be stored in either xfs attrs or in internal leveldb key-value store. Ceph does determine whether attribute ends up in xfs xattrs or in leveldb by checking the length of value and number of attributes.
Due to misconfiguration of ceph in our clusters, those threshold values were to high. Although xfs can handle such larger xattr values, the performance of such operations is much lower because they're not inlined inside inode structure. We observed that some xattr writes took more than 200ms compared to usual less than 1ms.
Due to internal sequencing mechanisms in ceph, such long xattr update can cause degradation of given osd node and thus the whole cluster.
La dégradation des performances était causé par les images rbd ayant plus de 5 snapshots. Ces snapshots étaient présents à cause d'un bug dans la gestion des backups ou à cause de backups en cours. L'anomalie corrigée, nous n'avons plus cette situation et les performances sont à nouveau celles attendues.
Un grand nombre de snapshots sur une image rbd impacte le nombre d'attributs que Ceph doit stocker pour les objets rados. Les attributs objets rados peuvent être stockés entant qu'attributs XFS ou par Ceph lui même dans sa base leveldb. Ceph détermine le meilleur choix en fonction de la longueur de la valeur et du nombre d'attributs.
A cause d'une mauvaise configuration de Ceph sur nos clusters, ces valeurs étaient trop hautes. Bien qu'XFS puisse gérer de grandes valeurs xattr, les performances des performances sont inférieures car ces attributs se retrouvent éparpillés sur plusieurs inode. Nous avons observé que certains écritures d'xattr pouvait prendre plus de 200ms là ou elle prend habituellement moins d'1ms.
A cause du séquençage interne de Ceph, une mise à jour lente d'un xattr peut diminuer les performances d'un OSD et donc du cluster dans sa globalité.
Date: 2016-10-17 15:42:41 UTC
Première opération terminée, On réalise un petite modification dans la soirée pour préparer la seconde opération.
First operation done, we realize a little modification in the evening to prepare the second operation.
Date: 2016-10-15 15:21:12 UTC
Opération terminée, nous ferons la prochaine opération lundi.
Operation done, we'll do the next one on monday.
Date: 2016-10-14 21:09:23 UTC
Début de l'opération.
Operation started.
Date: 2016-10-13 14:05:01 UTC
We dug up to analyzing the kernel's syscall to understand what's going on.
we found a similar behavior between this cluster and the one with constant performances.
There are some large writing sequences then reading sequences, coincidence makes that some disks receives more writes and reads than the other. We'll change the configuration to have a better data allocation.
In a second time we'll update Ceph to a more recent release.
The configuration change will be done in several times and will start at the end of the week, it will impact the performances.
For the update we are currently doing some tests to confirm the his usage on our infrastructure.
Date: 2016-10-11 13:40:46 UTC
On a creusé jusqu'à analyser les appels systèmes (syscalls) du kernel pour comprendre ce qu'il se passe.
On retrouve un comportement similaire entre ce cluster et ceux ayant des performances constantes.
Il y a de grosses séquences d'écriture puis de lecture , le hasard fait que certains disques reçoivent plus d'écritures et lectures que d'autres. Nous allons donc modifier la configuration pour mieux répartir les données.
Dans un second temps nous allons mettre à jour la version de Ceph utilisée sur ce cluster.
Le changement de configuration sera réalisé en plusieurs fois à partir de la fin de semaine et entraînera une diminution des performances.
Pour la mise à jour nous effectuons des tests pour valider le bon fonctionnement de la nouvelle version.
Date: 2016-09-23 15:49:53 UTC
Nous continuons nos investigations, pour l'instant celles-ci nous ont uniquement permis d'écarter de potentielles causes.
Date: 2016-09-22 14:24:18 UTC
Sortir le disque remontant le plus de latence n'a pas rétabli les performances attendues, nous continuons nos investigations.
Date: 2016-09-22 09:35:39 UTC
les logs remontent des disques du cluster avec un haut temps de réponse. Cependant quelques disques se démarquent par un plus grand nombre d'occurrence.
Nous cherchons à comprendre ce qui explique cela, il est possible que l'on sorte des disques du cluster pour observer l'influence de ceux-ci.
This scheduled maintenance affected: Virtual Private Servers || Operating System (ERI, GRA, SBG, LIM, WAW, BHS, SGP, SYD).