Benchmarks de performance pour grands volumes Azure NetApp Files pour Linux

Article
03/28/2024

Cet article décrit les caractéristiques des performances testées d’un seul grand volume Azure NetApp Files en ce qui concerne les cas d’usage Linux. Les tests ont exploré des scénarios pour les charges de travail de lecture et d’écriture de scale-out et scale-up, impliquant une et plusieurs machines virtuelles. Connaître l’enveloppe de performances des grands volumes vous permet de faciliter le dimensionnement des volumes.

Résumé du test

La fonctionnalité de grands volumes Azure NetApp Files offre trois niveaux de service, chacun avec des limites de débit. Les niveaux de service peuvent subir un scale-up ou down, de manière nondisruptive, à mesure que vos besoins en matière de performances changent.
- Niveau de service Ultra : 10 240 Mio/s
- Niveau de service Premium : 6 400 Mio/s
- Niveau de service Standard : 1 600 Mio/s
Le niveau de service Ultra a été utilisé lors de ces tests.
E/S séquentielles : 100 % d’écritures séquentielles maximales à 8 500 Mio/s, tandis qu’un seul grand volume peut atteindre un débit de 10 Gio/s (10 240 Mio/s).
E/S aléatoires : le même unique grand volume offre plus de 700 000 opérations par seconde.
Les charges de travail fortes en métadonnées sont avantageuses pour les grands volumes Azure NetApp File en raison du parallélisme accru du grand volume. Les avantages en matière de performances sont notables dans les charges de travail lourdes dans la création de fichiers, la dissociation et les renommages de fichiers comme couramment avec les applications VCS et les charges de travail EDA qui contiennent un nombre élevé de fichiers. Pour plus d’informations sur les performances des charges de travail avec d’importantes quantités de métadonnées, consultez Avantages de l’utilisation d’Azure NetApp Files pour l’automatisation de la conception électronique.
FIO, un générateur de charge de travail synthétique conçu comme un test de contrainte du stockage, a été utilisé pour obtenir ces résultats de test. Il existe fondamentalement deux modèles de test de performance du stockage :
- Calcul scale-out qui fait référence à l’utilisation de plusieurs machines virtuelles pour générer la charge maximale possible sur un unique volume Azure NetApp Files.
- Calcul scale-up qui fait référence à l’utilisation d’une machine virtuelle de grande taille pour tester les limites supérieures d’un seul client sur un unique volume Azure NetApp Files.

Test de scale-out Linux

Les tests ont observé des seuils de performance d’un seul grand volume sur scale-out et ils ont été effectués avec la configuration suivante :

Composant	Configuration
Taille de la machine virtuelle Azure	E32s_v5
Limite de bande passante de sortie pour une machine virtuelle Azure	2 000 Mio/s (2Gio/s)
Système d’exploitation	RHEL 8.4
Grand volume	101 Tio Ultra (débit de 10 240 Mio/s)
Options de montage	hard,rsize=65536,wsize=65536,vers=3 REMARQUE : L’utilisation de 262144 et 65536 a eu des résultats de performances similaires.

Charges de travail séquentielles de 256 Kio (Mio/s)

Le graphique représente une charge de travail séquentielle de 256 Kio et un ensemble fonctionnel de 1 Tio. Il indique qu’un seul grand volume Azure NetApp Files peut gérer entre environ 8 518 Mio/s de pures écritures séquentielles et environ 9 970 Mio/s de pures lectures séquentielles.

Charge de travail aléatoire de 8 Kio (IOPS)

Le graphique représente une charge de travail aléatoire de 8 Kio et un ensemble fonctionnel de 1 Tio. Le graphique montre qu’un grand volume Azure NetApp Files peut gérer entre environ 474 000 écritures aléatoires pures et 709 000 lectures aléatoires pures.

Test de scale-up Linux

Alors que les tests de scale-out sont conçus pour trouver les limites d’un unique grand volume, les tests de scale-up sont conçus pour trouver les limites supérieures d’une unique instance par rapport à un grand volume. Azure définit les limites de sortie réseau sur ses machines virtuelles. Pour le stockage attaché au réseau, cela signifie une limitation de la bande passante en écriture par machine virtuelle. Ces tests de scale-up illustrent les fonctionnalités étant donné l’importance de la bande passante disponible et compte tenu des processeurs suffisants pour piloter la charge de travail.

Les tests de cette section ont été exécutés avec la configuration suivante :

Composant	Configuration
Taille de la machine virtuelle Azure	E104id_v5
Limite de bande passante de sortie pour une machine virtuelle Azure	12 500 Mio/s (12,2 Gio/s)
Système d’exploitation	RHEL 8.4
Grand volume	101 Tio Ultra (débit de 10 240 Mio/s)
Options de montage	hard,rsize=65536,wsize=65536,vers=3 REMARQUE : L’utilisation de 262144 et 65536 a eu des résultats de performances similaires

Les graphiques dans cette section montrent les résultats de l’option de montage de nconnect côté client avec NFSv3. Pour plus d’informations, consultez Meilleures pratiques pour les options de montage NFS Linux pour Azure NetApp Files.

Les graphiques suivants comparent les avantages de nconnect avec un volume NFS monté sans nconnect. Dans les tests, FIO a généré la charge de travail à partir d’une unique instance E104id-v5 dans la région Azure USA Est à l’aide d’une charge de travail séquentielle de 64 Kio. Une taille d’E/S de 256 E/0 a été utilisée, soit la plus grande taille d’E/S recommandée par Azure NetApp Files, ce qui a entraîné des performances comparables. Pour plus d’informations, consultez rsize et wsize.

Débit de lecture Linux

Les graphiques suivants montrent des lectures séquentielles de 256 Kio d’environ 10 000 Mio/s avec nconnect, soit environ dix fois le débit atteint sans nconnect.

Remarquez que la bande passante de 10 000 Mio/s est proposée par un grand volume du niveau de service Ultra.

Débit d’écriture Linux

Les graphiques suivants montrent des écritures séquentielles. L’utilisation de nconnect offre des avantages visibles pour des écritures séquentielles à 6 600 Mio/s, soit environ quatre fois celle des montages sans nconnect.

IOPS de lecture Linux

Les graphiques suivants montrent des lectures aléatoires de 8 Kio d’environ 426 000 IOPS en lecture avec nconnect, environ sept fois ce qui est observé sans nconnect.

IOPS d’écriture Linux

Les graphiques suivants montrent des écritures aléatoires de 8 Kio d’environ 405 000 IOPS en écriture avec nconnect, environ 7,2 fois ce qui est observé sans nconnect.

Partager via