Ceph : le voyage vers 1 TiB/s

Ceph : le voyage vers 1 TiB/s

• Un article qui retrace le parcours d'amélioration des performances d'un cluster Ceph, et raconte comment un long travail de débogage et d'optimisation a permis d'atteindre un débit de traitement des données de 1 TiB/s.
• Il partage les différents problèmes techniques rencontrés et leurs solutions lors de l'accompagnement, par l'entreprise Clyso, de la mise en place d'un cluster Ceph de 10 pétaoctets basé sur NVMe.
• Le réseau du client est extrêmement rapide, parmi les configurations Ethernet les plus performantes.

Remerciements

• Remerciements au client de Clyso, dont la coopération a permis de partager cette expérience avec la communauté Ceph.
• Remerciements également à IBM/Red Hat et à Samsung pour avoir fourni le matériel utilisé dans les tests comparatifs.
• Des remerciements sont aussi adressés aux contributeurs de Ceph pour leurs efforts afin de faire de Ceph un excellent logiciel.

Configuration du cluster

• Le client avait proposé 34 nœuds 2U bi-socket répartis sur 17 racks, mais Clyso a suggéré plusieurs configurations utilisant des nœuds plus petits.
• L'architecture Dell a finalement été retenue, permettant de réduire les coûts tout en offrant une bande passante mémoire plus élevée, davantage de ressources CPU et un débit réseau supérieur.
• Cela réduit également de moitié l'impact de la panne d'un nœud sur la récupération du cluster.

Configuration des tests

• Déploiement d'un cluster Ceph temporaire avec CBT, puis exécution de tests FIO.
• Utilisation de tests FIO basés sur des bibliothèques pour découper le cluster en plus petites unités et comparer les résultats aux précédents.
• Tests en réplication 3X et en erasure coding 6+2, ainsi que du protocole de messages version 2 en mode chiffré et en mode sécurisé.

Attention au nombre de PG

• Des tests empiriques ont été menés pour mesurer l'impact du nombre de PG sur les performances.
• Un nombre élevé de PG peut avoir un effet positif sur les performances, mais, en production réelle, cela doit être envisagé avec les autres réglages.

Des débuts difficiles

• Dès les premières connexions au matériel, la résolution des problèmes s'est révélée difficile en raison de performances inférieures aux attentes.
• Les premiers tests de performance étaient bons, mais une baisse des performances est apparue lors des essais avec plusieurs OSD.

Un comportement étrange

• En exécutant différentes combinaisons de tests OSD, une anomalie dans les performances a été observée.
• Le système voyait ses performances chuter après des tests multi-OSD, puis les récupérer plusieurs heures plus tard.

Trois solutions

• La résolution d'un problème de latence lié aux transitions de CPU c-state a légèrement amélioré les performances.
• La désactivation de l'IOMMU a permis une amélioration importante des performances.
• La correction d'un problème de drapeaux de compilation de RocksDB a doublé les performances en écriture aléatoire 4K.

Première semaine de 2024

• Une panne majeure sur un autre cluster le jour de l'An a empêché l'équipe de se concentrer sur les tests de performance.
• Les tests ont repris le vendredi, confirmant que le cluster fonctionnait bien même sous forte charge.

Le sourire du destin

• À mesure que les résultats des tests s'amélioraient, il est devenu clair que le cluster montait en charge de façon linéaire.
• Un cluster de 63 nœuds a atteint un débit de traitement des données de 635 GiB/s.

Une Étoile de la mort partiellement opérationnelle

• Faute d'un nombre suffisant de nœuds clients, il a fallu partager les nœuds OSD avec les processus FIO.
• Même dans cette configuration, des performances proches de 950 GiB/s ont été atteintes.

Atteindre 1 TiB/s

• En ajustant le nombre de shards OSD et le nombre de threads du messager, le cluster a atteint un débit de traitement des données de 1 TiB/s.

Sommeil ; erasure coding

• Après des tests en réplication 3X, le cluster a été reconfiguré en erasure coding 6+2, celui que le client utilisera en production, puis testé à nouveau.
• Les performances en lecture ont dépassé 500 GiB/s, tandis que les performances en écriture ont atteint près de 400 GiB/s.

Avis de GN⁺ :

1. Cet article décrit en détail le processus d'optimisation des performances d'un cluster Ceph et offre un éclairage technique précieux en montrant comment un haut niveau de performance a été atteint au terme d'une résolution de problèmes complexe.
2. Il montre comment la coopération avec le client, les efforts des contributeurs de la communauté et diverses stratégies d'optimisation matérielle et logicielle peuvent produire des résultats majeurs dans le monde réel.
3. Ce texte fournit des informations utiles non seulement aux spécialistes des systèmes de stockage de données à grande échelle, mais aussi aux ingénieurs intéressés par l'optimisation des performances.

[GN⁺]

Commentaires Hacker News

• L’annonce de l’atteinte de 1 TB/s au CERN et l’histoire de Ceph
  • Un utilisateur mentionne que le CERN a atteint une vitesse de 1 TB/s via un cluster EOS, en précisant que ce cluster utilise principalement des HDD et comporte davantage de nœuds. Il partage aussi l’histoire intéressante de Ceph, conçu à l’origine chez Dreamhost pour des besoins internes, puis acquis par Red Hat.
• L’expérience d’un ancien responsable technique et son appréciation de Ceph
  • Un utilisateur se remémore son expérience comme responsable technique chez Cisco, où il a configuré Kubernetes sur du bare metal et expérimenté avec GlusterFS et Ceph, en disant qu’il avait apprécié ces expérimentations. Il félicite également l’auteur pour la qualité de l’article.
• Proposition de réduire la taille des nœuds
  • Un utilisateur souligne que la consommation énergétique par nœud du système actuel est élevée et suggère un effort d’ingénierie pour réduire la taille des nœuds. Selon lui, cela permettrait d’avoir besoin de moins de nœuds et de limiter l’impact d’une panne unique à 10 disques.
• Perspective historique sur le volume de stockage des données numériques
  • Un utilisateur remarque qu’au cours des 60 dernières années, il a probablement existé un jour où, pour la première fois, 1 TiB de données numériques avait été stocké dans le monde entier, et exprime son étonnement qu’aujourd’hui une telle quantité de données soit déplacée chaque seconde.
• Retour d’expérience sur l’amélioration des performances du cache Docker via un cluster Ceph
  • Un utilisateur explique qu’il exploite un cluster de stockage Ceph pour conserver le cache des couches Docker, et partage qu’après être passé d’EBS à Ceph, le débit s’est considérablement amélioré. Il ajoute que Ceph ne nécessite presque aucune maintenance.
• Problèmes des logiciels de contrôleur de stockage dans Kubernetes
  • Un utilisateur indique que, dans Kubernetes, le principal problème lié au stockage dynamique n’est pas l’I/O, mais les situations où le logiciel de contrôleur de stockage rencontre de vrais problèmes. Il cite notamment des cas avec rook/ceph et Longhorn, où des PVC ne se rattachent qu’après un très long délai.
• Analyse des performances de 1 TiB/s face aux limites théoriques du matériel
  • Un utilisateur analyse comment la performance de 1 TiB/s se compare aux limites théoriques du matériel, et souligne que le réseau constitue le goulet d’étranglement. Il conclut aussi que la complexité de Ceph impose une charge importante au CPU et que le modèle de threading des OSD n’est pas optimisé, en espérant des améliorations.
• Demande de comparaison entre Ceph et d’autres moteurs de stockage objet
  • Un utilisateur dit qu’il aimerait voir des comparaisons et des benchmarks entre Ceph et d’autres moteurs de stockage objet comme MinIO ou Garage.
• Question sur l’adéquation de Ceph au stockage de bases de données transactionnelles et sur la latence d’E/S
  • Un utilisateur demande si Ceph convient au stockage de bases de données transactionnelles et comment se situe la latence d’E/S, ajoutant qu’il souhaiterait migrer vers un système de fichiers moins coûteux pouvant rivaliser avec des systèmes comme le système de fichiers cluster d’Oracle ou Veritas.