Benchmarks de performance pour grands volumes Azure NetApp Files pour Linux
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 : 12 800 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.
Écritures séquentielles : 100 % des écritures séquentielles plafonnées à 8 500 Mio/seconde dans ces points de références du secteur. (Le débit maximal d’un seul grand volume est limité à 12 800 Mio/seconde par le service. Un débit supplémentaire potentiel est possible.)
Lectures séquentielles : 100 % des lectures séquentielles plafonnées à environ 12 761 Mio/seconde dans ces points de référence du secteur. (Le débit d’un seul grand volume est limité à 12 800 Mio/seconde. Le résultat est proche du débit maximal réalisable à ce jour.)
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 12 800 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 utilisant 12 machines virtuelles lisant et écrivant dans un seul grand volume utilisant un ensemble de travail de 1 Tio. Le graphique 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 12 761 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 12 800 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 obtenu sans nconnect.
Notez que 10 000 Mio/s correspond à peu près au débit de la carte d’interface réseau de 100 Gbps attachée au E104id_v5.
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.
