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 : 64 Ko d'E/S séquentielles, lectures et écritures, ligne de base sans mise en cache

Dans cette référence de référence, les tests démontrent qu’un volume standard Azure NetApp Files peut gérer entre environ 3 600 Mio/s de lectures séquentielles pures de 64 Kio et environ 2 400 Mio/seconde 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.

En ce qui concerne la lecture pure, la ligne de base de 64 Ko a obtenu des performances légèrement meilleures que la ligne de base de 256 Ko. Cependant, en ce qui concerne l'écriture pure et toutes les charges de travail mixtes de lecture/écriture, la ligne de base de 256 Ko a surpassé 64 Ko, ce qui indique qu'une taille de bloc plus grande de 256 Ko est globalement plus efficace pour les charges de travail à haut débit.

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

Résultats : 256 Ko d'E/S séquentielles sans mise en cache

Dans les deux tests de référence suivants, FIO a été utilisé pour mesurer la quantité d’E/S séquentielles (lecture et écriture) qu’un seul volume régulier dans Azure NetApp Files peut fournir. Afin de produire une ligne de base reflétant la véritable bande passante qu'une charge de travail de lecture entièrement non mise en cache peut atteindre, FIO a été configuré randrepeat=0 pour s'exécuter avec le paramètre de génération de jeu de données. Chaque itération de test a été compensée par la lecture d'un ensemble de données volumineux complètement distinct ne faisant pas partie de l'analyse comparative afin d'effacer toute mise en cache qui aurait pu se produire avec l'ensemble de données de l'analyse comparative.

Dans ce graphique, les tests montrent qu’un volume standard Azure NetApp Files 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.

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 : comparaison du cache de débit de lecture et d'E/S séquentielles de 64 Ko

Pour démontrer comment la mise en cache influence les résultats de performances, FIO a été utilisé dans la comparaison de micro-évaluation suivante pour mesurer la quantité d’E/S séquentielles (lecture et écriture) qu’un seul volume régulier dans Azure NetApp Files peut fournir. Ce test est contrasté avec les avantages qu’une charge de travail partiellement mise en cache peut offrir.

Dans le résultat sans mise en cache, les tests ont été conçus pour atténuer toute mise en cache en cours comme décrit dans les tests de référence ci-dessus. Dans l’autre résultat, FIO a été utilisé sur des volumes réguliers Azure NetApp Files sans le paramètre randrepeat=0 et en utilisant une logique d’itération de test en boucle qui a lentement rempli le cache au fil du temps. La combinaison de ces facteurs a produit une quantité indéterminée de mise en cache, augmentant ainsi le débit global. Cette configuration a donné lieu à des performances de lecture globales légèrement meilleures que celles des tests exécutés sans mise en cache.

Les résultats des tests affichés dans le graphique présentent la comparaison côte à côte des performances de lecture avec et sans l'influence de la mise en cache, où la mise en cache a produit jusqu'à ~4 500 Mio/seconde de débit de lecture, tandis qu'aucune mise en cache n'a atteint environ ~3 600 Mio/seconde.

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