Point de référence du secteur des performances de volumes réguliers d’Azure NetApp Files pour Linux

Cette article décrit les points de référence du secteur des performances fournies par Azure NetApp Files pour Linux avec un volume régulier.

Charges de travail de streaming de fichiers entiers (tests de point de référence de scale-out)

L’objectif d’un test de scale-out est de montrer les performances d’un volume Azure NetApp File lors d’un scale-out (ou d’une augmentation) du nombre de clients qui génèrent une charge de travail simultanée dans le même volume. Ces tests peuvent généralement pousser un volume jusqu’à ses limites de performances et sont des indicateurs pour les charges de travail telles que le rendu multimédia, l’IA/le ML et d’autres charges de travail qui utilisent de grandes batteries de serveurs de calcul pour effectuer un travail.

Configuration des points de référence de scale-out d’IOPS élevées

Ces points de référence ont utilisé les éléments suivants :

• Un seul volume Azure NetApp Files standard de 100 Tio avec un jeu de données de 1 Tio utilisant le niveau de performance Ultra
• Le testeur FIO (avec et sans le paramètre randrepeat=0)
• Des tailles de bloc de 4 Kio et de 8 Kio
• 6 machines virtuelles D32s_v5 exécutant RHEL 9.3
• NFSv3
• Une qualité de service (QoS) manuelle
• Options de montage : rw,nconnect=8,hard,rsize=262144,wsize=262144,vers=3,tcp,bg

Configuration des points de référence de scale-out du débit élevés

Ces points de référence ont utilisé les éléments suivants :

• Un seul volume Azure NetApp Files standard avec un jeu de données de 1 Tio utilisant le niveau de performance Ultra
• Le testeur FIO (avec et sans le paramètre randrepeat=0)
• Des tailles de bloc de 64 Kio et de 256 Kio
• 6 machines virtuelles D32s_v5 exécutant RHEL 9.3
• NFSv3
• Une qualité de service (QoS) manuelle
• Options de montage : rw,nconnect=8,hard,rsize=262144,wsize=262144,vers=3,tcp,bg

Configuration des points de référence des connexions réseau en parallèle (nconnect)

Ces points de référence ont utilisé les éléments suivants :

• Un seul volume Azure NetApp Files standard avec un jeu de données de 1 Tio utilisant le niveau de performance Ultra
• Le testeur FIO (avec et sans le paramètre randrepeat=0)
• Taille du tampon de lecture/d’écriture de 4 Kio et de 64 Kio
• Une seule machine virtuelle D32s_v4 exécutant RHEL 9.3
• NFSv3 avec et sans nconnect
• Options de montage : rw,nconnect=8,hard,rsize=262144,wsize=262144,vers=3,tcp,bg

Tests de point de référence de scale-up

L’objectif du test de scale-up est de montrer les performances d’un volume Azure NetApp File lors d’un scale-up (ou d’une augmentation) du nombre de travaux générant une charge de travail simultanée sur plusieurs connexions TCP sur un seul client dans le même volume (par exemple, avec nconnect).

Sans nconnect, ces charges de travail ne peuvent pas pousser les limites des performances maximales d’un volume, car le client ne peut pas générer suffisamment d’E/S ou de débit réseau. Ces tests sont généralement des indicateurs de ce que peut être une expérience utilisateur dans des charges de travail telles que le rendu multimédia, les bases de données, l’IA/le ML et les partages de fichiers d’ordre général.

Points de référence de scale-out d’IOPS élevées

Les points de référence suivants montrent les performances obtenues pour Azure NetApp Files avec une charge de travail à IOPS élevées utilisant :

• 32 clients
• Des lectures et écritures aléatoires de 4 Kio et de 8 Kio
• Un jeu de données de 1 Tio
• Ratios de lecture/écriture comme suit : 100%:0%, 90%:10%, 80%:20% et ainsi de suite
• Avec et sans mise en cache de système de fichiers impliquée (utilisation de randrepeat=0 dans FIO)

Pour plus d’informations, consultez Méthodologie de test.

Résultats : 4 Kio, randomisation, mise en cache de client incluse

Dans ce point de référence, le testeur FIO s’est exécuté sans l’option randrepeat pour randomiser les données. Ainsi, une quantité indéterminée de mise en cache est entrée en jeu. Les chiffres des performances résultant de cette configuration sont dans l’ensemble légèrement meilleurs que les tests exécutés sans mise en cache avec toute la pile d’E/S utilisée.

Dans le graphique suivant, le test montre qu’un volume Azure NetApp Files standard peut gérer entre environ 130 000 écritures aléatoires pures de 4 Kio et environ 460 000 lectures aléatoires pures de 4 Kio pour ce point de référence. La proportion de lectures/écritures pour la charge de travail a été ajustée de 10 % à chaque exécution.

À mesure que la proportion de lectures/écritures d’E/S devient plus lourde en écriture, le nombre total d’IOPS diminue.

Résultats : 4 Kio, randomisation, mise en cache de client exclue

Pour ce point de référence, le testeur FIO a été exécuté avec le paramètre randrepeat=0 pour randomiser les données, ce qui réduit l’influence de la mise en cache sur les performances. Cela a entraîné une réduction d’environ 8 % des IOPS en écriture et une réduction d’environ 17 % des IOPS en lecture, mais les chiffres des performances sont plus représentatifs de ce que peut réellement faire le stockage.

Dans le graphique suivant, le test montre qu’un volume Azure NetApp Files standard peut gérer entre environ 120 000 écritures aléatoires pures de 4 Kio et environ 388 000 lectures aléatoires pures de 4 Kio. La proportion de lectures/écritures pour la charge de travail a été ajustée de 25 % à chaque exécution.

À mesure que la proportion de lectures/écritures d’E/S devient plus lourde en écriture, le nombre total d’IOPS diminue.

Résultats : 8 Kio, randomisation, mise en cache de client exclue

De plus grandes tailles de lecture et d’écriture entraînent un nombre inférieur d’IOPS, car davantage de données peuvent être envoyées avec chaque opération. Une taille de lecture et d’écriture de 8 Kio a été utilisée pour simuler de façon plus exacte ce que la plupart des applications modernes utilisent. Par exemple, de nombreuses applications EDA utilisent des lectures et des écritures de 8 Kio.

Pour ce point de référence, le testeur FIO s’est exécuté avec randrepeat=0 pour randomiser les données afin que l’impact de la mise en cache de client soit moindre. Dans le graphique suivant, le test montre qu’un volume Azure NetApp Files standard peut gérer entre environ 111 000 écritures aléatoires pures de 8 Kio et environ 293 000 lectures aléatoires pures de 8 Kio. La proportion de lectures/écritures pour la charge de travail a été ajustée de 25 % à chaque exécution.

À mesure que la proportion de lectures/écritures d’E/S devient plus lourde en écriture, le nombre total d’IOPS diminue.

Comparaisons côte à côte

Pour illustrer dans quelle mesure la mise en cache peut influencer les tests de point de référence des performances, le graphique suivant montre le nombre total d’IOPS pour les tests de 4 Kio avec et sans mécanisme de mise en cache en place. Comme indiqué, la mise en cache offre une légère amélioration des performances pour la tendance relativement constante des IOPS.

Décalage spécifique, charges de travail de lecture/écriture aléatoires en streaming : tests de scale-up avec des connexions réseau en parallèle (nconnect)

Les tests suivants montrent un point de référence d’E/S élevées en utilisant un seul client avec des charges de travail aléatoires de 4 Kio et un jeu de données de 1 Tio. La proportion de charges de travail générée utilise une profondeur d’E/S différente chaque fois. Pour booster les performances de la charge de travail d’un seul client, l’option de montage nconnect a été utilisée pour améliorer le parallélisme par rapport aux montages du client sans l’option de montage nconnect.

Lorsque vous utilisez une connexion TCP standard qui fournit un seul chemin d’accès au stockage, moins d’opérations totales sont envoyées par seconde que quand un montage peut exploiter davantage de connexions TCP (par exemple, avec nconnect) par point de montage. Lorsque vous utilisez nconnect, la latence totale des opérations est généralement inférieure. Ces tests sont également exécutés avec randrepeat=0 pour éviter intentionnellement la mise en cache. Pour plus d’informations sur cette option, consultez Méthodologie de test.

Résultats : 4 Kio, randomisation, avec et sans nconnect, mise en cache exclue

Les graphiques suivants illustrent une comparaison côte à côte de lectures et d’écritures de 4 Kio avec et sans nconnect pour mettre en évidence les améliorations des performances observées lors de l’utilisation de nconnect : IOPS plus élevées dans l’ensemble, latence inférieure.

Points de référence du débit élevé

Les points de référence suivants montrent les performances obtenues pour Azure NetApp Files avec une charge de travail à débit élevé.

Les charges de travail à débit élevé sont de nature plus séquentielles et sont souvent lourdes en lecture/écriture avec des métadonnées faibles. Le débit est généralement plus important que les IOPS. Ces charges de travail tirent généralement parti de tailles de lecture/écriture plus grandes (64 000 à 256 000), ce qui génère des latences plus élevées que les tailles de lecture/écriture plus petites, car les charges utiles plus importantes prennent naturellement plus de temps à être traitées.

Voici quelques exemples de charges de travail à débit élevé :

• Référentiels multimédias
• Calcul haute performance
• IA/ML/LLP

Les tests suivants montrent un point de référence de débit élevé en utilisant des charges de travail séquentielles de 64 Kio et de 256 Kio et d’un jeu de données de 1 Tio. La proportion de charges de travail générée diminue d’un pourcentage défini à la fois et montre ce à quoi vous pouvez vous attendre lors de l’utilisation de ratios de lecture/écriture variables (par exemple, 100%:0%, 90%:10%, 80%:20%, etc.).

Résultats : E/S séquentielles de 64 Kio, mise en cache incluse

Pour ce point de référence, le testeur FIO s’est exécuté à l’aide d’une logique de boucle qui a rempli le cache de manière plus agressive, de sorte qu’une quantité indéterminée de mise en cache a influencé les résultats. Les chiffres de performances résultants sont dans l’ensemble légèrement meilleurs que ceux des tests exécutés sans mise en cache.

Dans le graphique ci-dessous, le test montre qu’un volume Azure NetApp Files standard peut gérer entre environ 4 500 Mio/s de lectures séquentielles pures de 64 Kio et environ 1 600 Mio/s d’écritures séquentielles pures de 64 Kio. La proportion de lectures/écritures pour la charge de travail a été ajustée de 10 % à chaque exécution.

Résultats : E/S séquentielles de 64 Kio, mise en cache exclue

Pour ce point de référence, le testeur FIO s’est exécuté avec une logique de boucle qui a rempli le cache de manière moins agressive. La mise en cache de client n’a pas influencé les résultats. Les chiffres des performances d’écriture résultant de cette configuration sont légèrement meilleurs, mais les chiffres de lecture sont inférieurs à ceux des tests sans mise en cache.

Dans le graphique suivant, le test montre qu’un volume Azure NetApp Files standard peut gérer entre environ 3 600 Mio/s de lectures séquentielles pures de 64 Kio et environ 2 400 Mio/s d’écritures séquentielles pures de 64 Kio. Pendant les tests, une proportion de 50/50 a montré un débit total au même niveau qu’une charge de travail de lectures séquentielles pures.

La proportion de lectures/écritures pour la charge de travail a été ajustée de 25 % à chaque exécution.

Résultats : E/S séquentielles de 256 Kio, mise en cache exclue

Pour ce point de référence, le testeur FIO s’est exécuté avec une logique de boucle qui a rempli le cache de manière moins agressive, donc la mise en cache n’a pas influencé les résultats. Les chiffres des performances d’écriture résultant de cette configuration sont légèrement inférieurs par rapport aux tests de 64 Kio, mais les chiffres de lecture sont plus élevés que lorsque les mêmes tests de 64 Kio s’exécutent sans mise en cache.

Dans le graphique ci-dessous, le test montre qu’un volume Azure NetApp Files standard peut gérer entre environ 3 500 Mio/s de lectures séquentielles pures de 256 Kio et environ 2 500 Mio/s d’écritures séquentielles pures de 256 Kio. Pendant les tests, une proportion de 50/50 a montré un débit total qui est monté plus haut qu’une charge de travail de lectures séquentielles pures.

La proportion de lectures/écritures pour la charge de travail a été ajustée avec des incréments de 25 % à chaque exécution.

Comparaison côte à côte

Pour mieux montrer dans quelle mesure la mise en cache peut influencer les tests de point de référence des performances, le graphique suivant montre le nombre total de Mio/s pour les tests de 64 Kio avec et sans mécanisme de mise en cache en place. La mise en cache offre une légère amélioration initiale des performances pour le nombre total de Mio/s, car la mise en cache améliore généralement les lectures plus que les écritures. À mesure que la proportion de lectures/écritures change, le débit total sans mise en cache dépasse les résultats qui utilisent la mise en cache de client.

Connexions réseau en parallèle (nconnect)

Les tests suivants montrent un point de référence d’E/S élevées en utilisant un seul client avec des charges de travail aléatoires de 64 Kio et un jeu de données de 1 Tio. La proportion de charges de travail générée utilise une profondeur d’E/S différente chaque fois. Pour booster les performances de la charge de travail d’un seul client, l’option de montage nconnect a été utilisée pour un meilleur parallélisme par rapport aux montages du client qui n’a pas utilisé l’option de montage nconnect. Ces tests n’ont été exécutés qu’avec la mise en cache exclue.

Résultats : 64 Kio, séquentiel, mise en cache exclue, avec et sans nconnect

Les résultats suivants montrent les résultats d’un test de scale-up lors de la lecture et de l’écriture dans des blocs de 4 Kio sur un montage NFSv3 sur un seul client avec et sans parallélisation des opérations (nconnect). Les graphiques montrent qu’à mesure que la profondeur d’E/S augmente, les IOPS augmentent également. Toutefois, lorsque vous utilisez une connexion TCP standard qui fournit un seul chemin d’accès au stockage, moins d’opérations totales sont envoyées par seconde que quand un montage peut exploiter davantage de connexions TCP par point de montage. De plus, la latence totale des opérations est généralement inférieure lorsque vous utilisez nconnect.

Comparaison côte à côte (avec et sans nconnect)

Les graphiques suivants illustrent une comparaison côte à côte de lectures et d’écritures séquentielles de 64 Kio avec et sans nconnect pour mettre en évidence les améliorations des performances observées lors de l’utilisation de nconnect : débit plus élevé dans l’ensemble, latence inférieure.

Plus d’informations

• Méthodologie de test