Introduction
Récapitulatif: Dans l’épisode du Blog–1, nous avons couvert les RHCS, l’introduction de BlueStore, les détails du matériel de laboratoire, la méthodologie d’analyse comparative et la comparaison des performances entre la configuration Ceph par défaut et la configuration Ceph réglée
Ceci est le deuxième épisode de la série de blogs de performance sur RHCS 3.2 BlueStore fonctionnant sur le cluster tout-flash. Il n’y a pas de règle empirique pour classer les tailles de blocs dans une catégorie petite, moyenne et grande. En tant que tels, nous avons désigné la catégorie 4K à petite taille de bloc, 8K-64K à moyenne et 1M-4M dans la catégorie de grande taille de bloc. Dans cet épisode, vous découvrirez la caractérisation des performances du stockage de blocs Ceph pour les tailles de blocs petites (4K), moyennes (8K-32K) et grandes (1M-4M) à travers des modèles de charge de travail en lecture aléatoire, en écriture aléatoire et en lecture-écriture aléatoire.
Résumé
- Charge de travail en petit bloc 4K, livrée jusqu’à 2.2 Millions de lectures aléatoires, 691 Ko de lecture-écriture aléatoire (70/30) et 463 Ko d’IOPS d’écriture aléatoire jusqu’à ce qu’elles soient limitées par la contention du processeur et des médias.
- Similaire à la charge de travail de petits blocs, les performances des blocs moyens ont été limitées par la contention du processeur et du support.
- Performances maximales de charge de travail de 4M de gros blocs enregistrées à 10,9 Go/s pour les trois modèles de test, c’est-à-dire un mélange aléatoire de lecture, d’écriture et de lecture-écriture (70/30) jusqu’à ce que la bande passante du réseau client soit limitée.
Partie 1: Performances de petite taille de bloc (4 Ko)
Points clés
- La charge de travail de lecture aléatoire a montré 2.Latence moyenne de 2 millions d’IOPS à 3 ms jusqu’à ce que la saturation des médias soit bloquée.
- La charge de travail de mixage aléatoire en lecture-écriture (70/30) a montré une latence moyenne de 691 Ko IOPS @ 6 ms jusqu’à ce qu’elle soit bloquée par la contention de ressources CPU du nœud Ceph.
- Écriture aléatoire : 463K IOPS @ 11ms de latence moyenne jusqu’à ce qu’il soit bloqué par la contention de ressources CPU du nœud Ceph.
Résumé
Dans cette partie du test, l’interface de stockage de blocs Ceph a été exercée avec une charge de travail de petite taille (4 Ko) sur des modèles de mélange de lecture aléatoire, d’écriture aléatoire et de lecture-écriture aléatoire (70/30). Les mesures clés capturées pendant le test incluent les IOPS, la moyenne, la latence, le processeur du nœud Ceph et l’utilisation des supports.
Le graphique-1 montre les performances de pointe pour la taille de bloc 4K sur différents modèles d’accès avec 5 nœuds tout flash. En tant que telle, la performance maximale s’est avérée être
- Lecture aléatoire : 2,2 millions d’IOPS @ 3ms de latence moyenne
- Lecture-écriture aléatoire (70/30) Mix: 691K IOPS @ 6ms de latence moyenne
- Écriture aléatoire: Latence moyenne de 463K IOPS @ 11ms
L’utilisation du processeur et des supports capturée dans les graphiques 2 et 3 nous a aidés à comprendre les goulots d’étranglement pour différents modèles de charge de travail.
- La performance de lecture aléatoire s’est avérée être entravée par la contention de ressources CPU, cependant, l’utilisation des médias s’est également avérée supérieure. En tant que tels, nous avons ajouté des nœuds Ceph supplémentaires (CPU et médias), les performances de lecture aléatoire auraient pu être plus élevées.
- Pour le mix d’écriture aléatoire et de lecture-écriture aléatoire (70/30), les performances ont été entravées par une consommation CPU plus élevée. Il est intéressant de noter que les médias disposaient en même temps d’un débit de rechange suffisant qui restait inutilisé en raison du manque de puissance de calcul. En tant que tel, une allocation de cœur de processeur plus élevée aux OSD Ceph aurait pu fournir des performances plus élevées pour les charges de travail de mélange lecture-écriture aléatoire en écriture aléatoire &.
L’utilisation du périphérique de données OSD (P4500 NVMe) est restée inférieure à 50% d’utilisation, le périphérique Intel Optane P4800 qui hébergeait les métadonnées BlueStore WAL et Rocksdb s’est avéré très occupé à 90%. Le paramètre bluestore_min_alloc_size_ssd a été défini sur 16 Ko, donc toutes les écritures inférieures à 16 Ko ont été différées, l’écriture va d’abord dans le périphérique WAL, puis est écrite de manière asynchrone dans les données OSD, d’où le périphérique Optane P4800 avait absorbé les écritures pour tous les OSD sur l’hôte. Malgré l’utilisation élevée du périphérique RocksDB / WAL, nous n’avons vu aucun signe de discorde sur le périphérique de données OSD P4500. Mais sur la base de cette expérience, nous ne recommandons pas de placer plus de 7 périphériques NVMe P4500 derrière un seul Intel Optane P4800 pour WAL / RocksDB.
Graphique 2
Graphique 3
Un autre test intéressant que nous avons effectué était le test de balayage des clients, où nous avons augmenté linéairement le nombre de clients commençant par 20 et allant jusqu’à 140. Au fur et à mesure que nous augmentions la charge client, nous avons observé une amélioration linéaire des performances jusqu’à ce que nous atteignions la congestion du processeur sur Ceph OSD. Avec 100 clients, nous avons observé des IOPS d’écriture 4K agrégées à ~ 445K. Après ce point, la congestion des ressources du système a entraîné des latences de queue élevées. Intel Optane utilisé comme métadonnées a aidé à absorber le pic de latence avec un nombre élevé de clients parallèles, car cette latence moyenne est restée inférieure à 40 ms.
G
Partie-2: Performances de taille de bloc moyenne
Points à retenir
- Jusqu’à ce que les performances soient bloquées par la saturation du processeur et des supports, 5 nœuds Ceph tout flash ont livré ~ 1,8 million de lectures aléatoires, ~636 Ko de lecture aléatoire (70/30) et ~410 Ko d’écriture aléatoire IOPS.
- Pour mettre à l’échelle les performances, des nœuds OSD Ceph supplémentaires ont dû être ajoutés dans le cluster Ceph existant.
Résumé
Dans les graphiques suivants, nous avons essayé de représenter différents points de données tels que les IOPS, la latence moyenne, la latence de queue, le CPU du nœud Ceph et l’utilisation des médias. Et tout cela sur une plage de taille de bloc, c’est-à-dire de 4K à 64K pour un mélange d’écriture aléatoire, de lecture aléatoire et de lecture-écriture aléatoire (70/30).
Quelques points de données intéressants incluent
- Comme prévu, les petites tailles de blocs ont montré des IOPS les plus élevées et des latences moyennes et de queue inférieures, par rapport aux tailles de blocs moyennes. En tant que tels, nous avons observé ~ 1,8 million, ~ 636K, ~ 410K IOPS pour la Lecture aléatoire, le Mélange de lecture aléatoire et la charge de travail d’écriture aléatoire respectivement.
- Une utilisation élevée a été observée sur les périphériques CPU et multimédias sur les nœuds OSD Ceph. L’utilisation s’est avérée aussi élevée que ~ 90% et ~ 80% respectivement pour le processeur et le support respectivement. En tant que telles, les performances auraient pu augmenter si nous avions ajouté des nœuds OSD Ceph au cluster Ceph existant.
G
Partie 3 : Performances de grande taille de bloc
Points à retenir
- Les performances de grand bloc 4M ont culminé à 10.9 Go/s pour un mélange aléatoire de lecture, d’écriture et de lecture-écriture (70/30).
- Le réseau client s’est avéré être le facteur limitant et provoquant un goulot d’étranglement des performances.
- Les performances auraient pu être plus élevées, si nous avions eu plus de nœuds clients ou des tuyaux réseau plus gros.
Résumé
Tous les différents modèles que nous avons testés, c’est-à-dire un mélange aléatoire de lecture, d’écriture et de lecture-écriture (70/30) pour une charge de travail de 4M de grande taille de bloc plafonnée à un débit agrégé de 10,9 Go / s. Le réseau client s’est avéré être le facteur limitant à l’origine du goulot d’étranglement des performances. Outre le réseau, la deuxième ressource la plus utilisée était les médias, mais elle disposait d’une marge de manœuvre suffisante pour offrir plus de performances, si le réseau n’était pas le goulot d’étranglement.
G
Suivant
Poursuivre la série de blogs d’analyse comparative, dans la section suivante, expliquera les résultats associés aux tests d’évolutivité de RHCS 3.2. Répondre à certaines questions clés comme « comment les performances changent-elles en passant d’un cluster de 3 nœuds à 5 nœuds ». Restez à l’écoute.