Améliorer les performances des threads d'E/S multiples pour OpenShift Virtualization

Red Hat OpenShift Virtualization 4.19 augmente considérablement les performances et la rapidité des charges de travail aux entrées/sorties (E/S) élevées, comme les bases de données. Cette solution inclut une nouvelle fonction de threads d'E/S multiples, qui permet de répartir les E/S de disque des machines virtuelles entre plusieurs threads de calcul sur l'hôte. Ces derniers sont ensuite associés à des files d'attente de disque à l'intérieur de la machine virtuelle. Ce processus permet à la machine virtuelle d'utiliser efficacement le processeur virtuel et le processeur hôte pour les E/S multiflux, avec, à la clé, de meilleures performances.

Cet article complète la présentation de cette fonction écrite par Jenifer Abrams. Je présente les résultats de nos tests afin de vous montrer comment régler votre machine virtuelle pour améliorer le débit d'E/S.

Les tests ont été effectués avec une charge de travail d'E/S synthétique fio et des machines virtuelles Linux. D'autres tests sont prévus avec des applications ainsi que sur Microsoft Windows.

Pour en savoir plus sur la mise en œuvre de cette fonction dans KVM, lisez cet article sur IOThread Virtqueue Mapping ainsi que cet article complémentaire sur l'amélioration des performances des charges de travail de base de données sur les machines virtuelles exécutées dans un environnement Red Hat Enterprise Linux. 

Description du test

Nous avons testé le débit d'E/S dans deux configurations : 

1. Un cluster avec un système de stockage local qui utilise le gestionnaire de volumes logiques provisionné par l'opérateur Local Storage Operator (LSO)
2. Un cluster distinct qui utilise OpenShift Data Foundation (ODF) 

Les configurations sont très différentes et ne peuvent pas être comparées.

Les tests ont été effectués sur des pods (comme valeur de référence) et des machines virtuelles, auxquelles 16 cœurs et 8 Go de RAM ont été alloués. J'ai utilisé des fichiers de test de 512 Go avec une machine virtuelle et de 256 Go avec deux machines virtuelles. J'ai utilisé des E/S directes dans tous les tests. Pour les machines virtuelles, j'ai utilisé des revendications de volume persistant (PVC) en mode bloc et au format ext4, et pour les pods, des PVC en mode système de fichiers également au format ext4. Tous les tests ont été exécutés avec le moteur d'E/S libaio.

J'ai testé la matrice ci-dessous :

J'ai utilisé ClusterBuster pour orchestrer les tests. Les machines virtuelles utilisaient CentOS Stream 9 et les pods utilisaient une base d'image de conteneur CentOS Stream.

Stockage local

Le cluster de stockage local comptait 5 nœuds (3 de gestion et 2 de calcul) de type Dell R740xd contenant 2 processeurs Intel Xeon Gold 6130, chacun avec 16 cœurs et 2 threads (32 processeurs), soit 32 cœurs et 64 processeurs au total. Chaque nœud disposait de 192 Go de RAM. Le sous-système d'E/S contenait quatre disques NVMe Dell Kioxia CM6 MU de 1,6 To, configurés comme un périphérique agrégé RAID0 avec des paramètres par défaut. Les PVC ont été exclues de ce périphérique à l'aide de l'opérateur lvmcluster. Malheureusement, je n'avais accès qu'à cette configuration modeste. Il est fort possible qu'un système d'E/S plus rapide offre davantage d'améliorations avec des threads d'E/S multiples.

OpenShift Data Foundation 

Le cluster ODF comptait 6 nœuds (3 de gestion et 3 de calcul) de type Dell PowerEdge R7625 contenant 2 processeurs AMD EPYC 9534, chacun avec 64 cœurs et 2 threads (128 processeurs), soit 128 cœurs et 256 processeurs au total. Chaque nœud disposait de 512 Go de RAM. Le sous-système d'E/S contenait deux disques NVMe de 5,8 To par nœud, avec une réplication tridirectionnelle sur un réseau de pods de 25 GbE par défaut. Je n'avais pas accès à un réseau plus rapide pour ce test. Du matériel réseau plus récent aurait probablement permis d'améliorer davantage les performances.

Synthèse des résultats

Ce test évalue des threads d'E/S multiples avec des backends d'E/S spécifiques qui ne sont pas forcément représentatifs de votre cas d'utilisation. Les différences dans les caractéristiques de stockage peuvent jouer un rôle important dans le choix du nombre de threads d'E/S.

Voici les résultats des tests.

• Débit d'E/S maximal : pour le stockage local, le débit maximal était d'environ 7,3 Go/s en lecture et 6,7 Go/s en écriture, tant pour les pods que pour les machines virtuelles, indépendamment du paramètre iodepth ou du nombre de tâches exécutées sur le stockage local. Ces résultats sont bien inférieurs à ce qui est globalement attendu du matériel. Les périphériques (chacun composé de 4 disques PCIe gen4) sont censés atteindre 6,9 Go/s en lecture et 4,2 Mo/s en écriture. Je n'ai pas cherché à comprendre ce phénomène, mais celui-ci peut s’expliquer par mon matériel, qui n'était pas vraiment récent. Les meilleures performances sont clairement supérieures à celles d'un disque seul, ce qui indique que l'agrégation par bandes a eu un effet positif. Pour ODF, nous avons obtenu 5 Go/s en lecture et 2 Go/s en écriture au maximum.
• Les E/S du grand bloc (1 Mo) ont présenté peu d'améliorations, si ce n'est aucune, car les performances étaient déjà limitées par le système.
• Le choix optimal pour le nombre de threads d'E/S varie en fonction des caractéristiques de la charge de travail et du stockage. Comme prévu, il y a eu peu d'améliorations pour les charges de travail ayant une faible simultanéité d'E/S.
  • Stockage local : pour les machines virtuelles avec une simultanéité d'E/S importante, on commence généralement par 4 à 8 threads. Il peut être utile d'en prévoir davantage pour les charges de travail qui utilisent de petites E/S et une haute simultanéité.
  • ODF : nous avons obtenu peu de résultats significatifs avec plus d'un thread d'E/S. Dans de nombreux cas, aucun n'a été nécessaire. La lenteur du réseau de pods est probablement en cause. Un réseau plus rapide aurait sûrement produit des résultats différents.
• Les threads d'E/S multiples se sont avérés plus efficaces lorsque plusieurs tâches étaient exécutées en simultané. Nous avons noté moins d'améliorations avec des E/S asynchrones profondes, du moins lors de ce test.
• Le comportement est resté stable avec une et deux machines virtuelles exécutées simultanément, jusqu'à ce que le débit d'E/S agrégé maximal (mentionné ci-dessus) soit atteint.
• Les threads d'E/S multiples n'ont pas complètement comblé l'écart avec les pods lorsque le nombre de tâches ou la valeur du paramètre iodepth étaient faibles. Avec une valeur iodepth élevée et de petites opérations, les machines virtuelles ont même largement dépassé les performances des pods en matière d'écriture.

Quelques chiffres

Voici le débit d'E/S global que j'obtiens avec des threads d'E/S multiples sur mon système de stockage local. Avec des charges de travail qui impliquent de petites E/S et qui se rapprochent beaucoup d'un système d'E/S rapide, les bénéfices sont considérables. Vous trouverez ci-dessous les autres améliorations obtenues avec différents nombres de threads d'E/S. Avec un bloc de 1 Mo, j'ai constaté peu d'améliorations, car les performances étaient déjà très proches de la limite du système sous-jacent. Les threads d'E/S supplémentaires donneraient probablement de bons résultats avec de grands blocs sur du matériel encore plus rapide.

Voici le nombre de threads d'E/S nécessaires pour atteindre 90 % du meilleur résultat possible, sans dépasser 16 threads d'E/S. Par exemple, si le meilleur résultat obtenu avec une opération, une taille de bloc, des tâches et une valeur iodepth spécifiques est de 1 Go/s, l'indicateur sera le plus petit nombre de threads nécessaires pour atteindre 900 Mo/s. On peut ainsi limiter le nombre de threads tout en optimisant les performances.

Résultats détaillés

Pour chaque cas de figure, j'ai calculé les facteurs de mérite suivants :

1. Mesure du débit d'E/S
2. Meilleures performances des machines virtuelles (qui ne sont pas directement indiquées)
3. Nombre minimal de threads d'E/S pour atteindre 90 % des meilleures performances des machines virtuelles
4. Rapport entre les meilleures performances des machines virtuelles et les performances des pods
5. Amélioration des performances des machines virtuelles par rapport aux performances de la base de référence

Je n'indique pas le nombre de threads qui donne les meilleures performances, car dans de nombreux cas, les différences étaient minimes et inférieures à la variation normale dans l'état des performances d'E/S.

Je sépare les résultats pour le stockage local et pour ODF en raison de leur grande différence de caractéristiques.

Tous les graphiques de performance ci-dessous montrent les résultats pour les pods (pod), pour une machine virtuelle de référence sans thread d'E/S (0) et pour le nombre spécifié de threads d'E/S sur l'axe des abscisses.

Stockage local

Les performances brutes montrent qu'au moins dans certains cas, l'utilisation de plusieurs threads d'E/S entraîne des progrès considérables. Par exemple, sur le stockage local avec 16 tâches et une E/S asynchrone dotée d'une valeur iodepth de 1, des threads d'E/S supplémentaires peuvent donner des résultats très intéressants :

Même avec un seul flux d'E/S, l'utilisation d'un thread d'E/S supplémentaire peut apporter des bénéfices. Sans surprise, aucune amélioration ne survient si l'on en utilise plusieurs :

Il existe aussi des anomalies dans lesquelles les threads d'E/S supplémentaires s'avèrent contre-productifs. Dans ce cas, avec des E/S asynchrones profondes et de petits blocs, les meilleures performances (plus élevées que celles des pods) sont obtenues avec des machines virtuelles qui n'utilisent pas de threads d'E/S dédiés. Je ne peux l'expliquer.

Ainsi, pour obtenir les meilleures performances avec plusieurs threads d'E/S, il faut effectuer des tests avec votre charge de travail spécifique.

Résultats du cluster ODF

Contrairement au stockage local, où l'écriture aléatoire avec de petits blocs et plusieurs threads d'E/S s'est montrée efficace, j'ai constaté peu d'améliorations avec ODF, même en exécutant de nombreuses tâches. Il est probable qu'un réseau plus rapide ou à latence plus faible donne de meilleurs résultats. Les opérations de lecture, en particulier en mode aléatoire, ont présenté quelques avancées, mais les opérations d'écriture et les petits nombres de tâches n'ont presque pas évolué (voire pas du tout).

Conclusion

Les threads d'E/S multiples pour OpenShift Virtualization sont une nouvelle fonction très intéressante d'OpenShift 4.19 qui peut améliorer considérablement les performances d'E/S des charges de travail avec des E/S simultanées, en particulier pour les systèmes d'E/S rapides, tels que le stockage NVMe local utilisé dans mes tests. Les sous-systèmes d'E/S plus rapides devraient bénéficier davantage de plusieurs threads d'E/S, car il faut plus de processeurs pour assurer le bon fonctionnement des E/S bare metal sous-jacentes. Comme toujours pour les E/S, les différences entre les systèmes d'E/S et les charges de travail globales peuvent avoir un effet important sur les performances. C'est pourquoi je vous recommande de tester vos propres charges de travail afin de tirer le meilleur parti de cette nouvelle fonction. J'espère que les résultats de mon test vous guideront dans vos choix de threads d'E/S.