Considérations relatives au niveau de performance d’un magasin de données Azure VMware Solution pour Azure NetApp Files

Article
03/29/2024

Cet article fournit des considérations relatives au niveau de performance pour la conception et le dimensionnement d’un magasin de données Azure VMware Solution lorsque vous l’utilisez avec Azure NetApp Files. Ce contenu est applicable aux administrateurs de virtualisation, aux architectes cloud et aux architectes de stockage.

Les considérations exposées dans cet article vous permettent d’obtenir de vos applications des niveaux de performance supérieurs avec une efficacité économique optimisée.

Azure NetApp Files fournit un niveau de performance haute performance et instantanément évolutif et un service de stockage hautement fiable pour Azure VMware Solution. Les tests incluent diverses configurations entre Azure VMware Solution et Azure NetApp Files. Les tests ont pu gérer plus de 10 500 Mio/s et plus de 585 000 opérations E/S par seconde (IOPS) avec seulement quatre hôtes Azure VMware Solution/ESXi et un pool de capacités Azure NetApp Files unique.

Obtenir un niveau de performance de stockage supérieur pour Azure VMware Solution en tirant parti d’Azure NetApp Files

L’approvisionnement de plusieurs magasins de données éventuellement plus volumineux à un niveau de service peut avoir un coût inférieur tout en fournissant un niveau de performance supérieur. La raison est due à la distribution de charge sur de multiples flux TCP à partir d’hôtes Azure VMware Solution vers plusieurs magasins de données. Vous pouvez utiliser l’estimateur de coût TCO de magasin de données Azure NetApp Files pour Azure VMware Solution afin de calculer les économies éventuelles en chargeant un rapport RVTools ou en entrant un dimensionnement manuel moyen de machines virtuelle.

Lorsque vous déterminez la configuration de magasins de données, la solution la plus simple du point de vue de la gestion consiste à créer un seul magasin de données Azure NetApp Files, à le monter et à y placer toutes vos machines virtuelles. Cette stratégie fonctionne de manière satisfaisante pour différentes situations jusqu’à ce qu’un débit ou des IOPS supplémentaires soient nécessaires. Dans le but d’identifier les différentes limites, les tests ont utilisé un générateur de charge de travail synthétique, le programme fio, afin d’évaluer une plage de charges de travail pour chacun de ces scénarios. Cette analyse peut vous permettre de déterminer la façon d’approvisionner des volumes Azure NetApp Files en tant que magasins de données afin d’optimiser le niveau de performance et les coûts.

Avant de commencer

Pour les données de performances d’Azure NetApp Files, consultez :

Azure NetApp Files : tirer le meilleur parti de votre de stockage cloud

Sur un hôte Azure VMware Solution, une connexion réseau unique est établie par un magasin de données NFS semblable à l’utilisation de nconnect=1 sur les tests Linux référencés dans la Section 6 (Options de paramétrage). Cet élément est essentiel pour comprendre les bonnes performances de la mise à l’échelle d’Azure VMware Solution dans plusieurs magasins de données.
Points de référence du secteur sur le niveau de performance d’un magasin de données Azure NetApp Files pour Azure VMware Solution

Méthodologie de test

Cette section décrit la méthodologie utilisée pour les tests.

Tester des itérations et des scénarios

Ces tests suivent la méthodologie des « quatre coins » qui inclut les opérations en écriture et les opérations en lecture pour chaque entrée/sortie (E/S) séquentielle et aléatoire. Les variables des tests incluent un à plusieurs hôtes Azure VMware Solution, les magasins de données Azure NetApp Files, les machines virtuelles (par hôte) et les disques de machine virtuelle (VMDK) par machine virtuelle. Les points de données de mise à l’échelle suivants ont été sélectionnés pour trouver les IOPS et le débit maximaux pour les scénarios donnés :

Mise à l’échelle de disques de machine virtuelle, chacun sur son propre magasin de données pour une seule machine virtuelle.
Mise à l’échelle d’un certain nombre de machines virtuelles par hôte sur un seul magasin de données Azure NetApp Files.
Mise à l’échelle d’un certain nombre d’hôtes Azure VMware Solution, chacun avec une machine virtuelle partageant un seul magasin de données Azure NetApp Files.
Mise à l’échelle d’un certain nombre de magasins de données Azure NetApp Files, chacun avec un disque de machine virtuelle réparti de façon égale sur des hôtes Azure VMware Solution.

Le fait de tester les opérations de blocs de petite et de grande taille et d’itérer via des charges de travail aléatoires et séquentielles veillent au test de tous les composants dans le calcul, le stockage et les piles réseau jusqu’en périphérie. Pour couvrir les quatre coins avec la randomisation et la taille de bloc, les combinaisons courantes suivantes sont utilisées :

Tests séquentiels de 64 Mo
- Les grandes charges de travail diffusion en continu lisent et écrivent couramment dans de grandes tailles de bloc et constituent également la taille d’étendue MSSQL par défaut.
- Les tests de grands blocs génèrent généralement le débit le plus élevé (en Mio/s).
Tests aléatoires de 8 Ko
- Ce paramètre est la taille de bloc couramment utilisée pour des logiciels de base de données, notamment les logiciels de Microsoft, Oracle et PostgreSQL.
- Les tests de petits blocs génèrent généralement le nombre d’IOPS le plus élevé.

Remarque

Cet article aborde uniquement les tests d’Azure NetApp Files. Il ne couvre pas le stockage vSAN inclus avec Azure VMware Solution.

Détails de l'environnement

Les résultats de cet article sont obtenus en utilisant la configuration d’environnement suivante :

Hôtes d’Azure VMware Solution :
- Taille : AV36
- Nombre d’hôtes : 4
- VMware ESXi version 7u3
Connectivité du clou Azure VMware Solution : passerelle UltraPerformance avec FastPath
Machines virtuelles invitées :
- Système d’exploitation : Ubuntu 20.04
- Processeurs/mémoire : 16 processeurs virtuels/64 Go de mémoire
- Contrôleur virtuel LSI SAS SCSI avec un disque de système d’exploitation de 16 Go sur un magasin de données vSAN Azure VMware Solution
- Contrôleur SCSI Paravirtual pour des disques de machine virtuelle de test
- Configurations de disque/gestionnaire de volumes logiques (LVM) :
  - Un volume physique par disque
  - Un groupe de volumes par volume physique
  - Une partition logique par groupe de volumes
  - Un système de fichiers XFS par partition logique
Protocole Azure VMware Solution vers Azure NetApp Files : NFS version 3
Générateur de charge de travail : fio version 3.16
Scripts FIO : fio-parser

Résultats des tests

Cette section décrit les résultats des tests effectués.

Mise à l’échelle de machine virtuelle unique

Lorsque vous configurez un stockage présenté au magasin de données sur une machine virtuelle Azure VMware Solution, vous devez considérer l’impact de la disposition du système de fichiers. La configuration de plusieurs disques de machine virtuelle répartis sur plusieurs magasins de données offre la quantité de bande passante disponible la plus élevée. La configuration un à plusieurs disques de machine virtuelle sur un seul magasin de données garantit la plus grande simplicité en matière de sauvegardes et d’opérations de récupération d’urgence, mais a un coût inférieur en termes de plafond du niveau de performance. Les données empiriques fournies dans cet article vous aident à prendre des décisions.

Pour optimiser le niveau de performance, il est courant de mettre à l’échelle une seule machine virtuelle sur plusieurs disques de machine virtuelle et de placer ces derniers sur plusieurs magasins de données. Une seule machine virtuelle ayant un ou deux disques de machine virtuelle peut être limitée par un magasin de données NFS, car il est monté via une connexion TCP unique sur un hôte Azure VMware Solution donné.

Par exemple, les ingénieurs approvisionnent souvent un disque de machine virtuelle pour un journal de base de données, puis approvisionnent un à plusieurs disques de machine virtuelle pour des fichiers de base de données. Il existe deux options pour plusieurs disques de machine virtuelle. La première option consiste à utiliser chaque disque de machine virtuelle en tant que système de fichiers individuel. La deuxième option est d’utiliser un utilitaire de gestion du stockage tel que LVM, MSSQL Filegroups ou Oracle ASM pour équilibrer les E/S en effectuant un entrelacement sur les disques de machine virtuelle. Lorsque vous utilisez des disques de machine virtuelle comme systèmes de fichiers individuels, la distribution de charges de travail sur plusieurs magasins de données exige un effort manuel qui peut être fastidieux. L’utilisation d’utilitaires de gestion du stockage pour répartir les fichiers sur des disques de machine virtuelle permet d’obtenir une scalabilité des charges de travail.

Si vous effectuez un entrelacement des volumes sur plusieurs disques, le logiciel de sauvegarde ou le logiciel de récupération d’urgence prend en charge la sauvegarde simultanée de plusieurs disques virtuels. Étant donné que les écritures individuelles sont entrelacées sur plusieurs disques, le système de fichiers doit vérifier que les disques sont « gelés » pendant des opérations de capture instantanée ou de sauvegarde. Les systèmes de fichiers les plus modernes comportent une opération de capture instantanée ou de gelée, telle que xfs (xfs_freeze) et NTFS (copies de mise en mémoire fantôme de volumes), dont un logiciel de sauvegarde peut tirer parti.

Pour comprendre les bonnes performances de la mise à l’échelle d’une seule machine virtuelle Azure VMware Solution à mesure que d’autres disques virtuels sont ajoutés, des tests ont été effectués sur un, deux, quatre et huit magasins de données (chacun contenant un seul disque de machine virtuelle). Le diagramme suivant montre un disque unique dont la moyenne est de 73 040 IOPS environ (mise à l’échelle de 100 % en écriture / 0 % en lecture vers 0 % en écriture / 100 % en lecture). Lorsque ce test a été augmenté pour passer à deux disques, le niveau de performance a augmenté de 75,8 % pour atteindre 128 420 IOPS. L’augmentation pour passer à quatre disques a commencé à montrer une diminution des retours par rapport à ce qu’une seule machine virtuelle, dimensionnée tel que testé, aurait pu envoyer (push). Le pic d’IOPS observé a été de 147 000 IOPS avec 100 % de lectures aléatoires.

Mise à l’échelle d’hôte unique – Magasin de données unique

La mise à l’échelle est peu performante pour augmenter le nombre de machines virtuelles et envoie des E/S vers un seul magasin de données à partir d’un seul hôte. Cet élément est dû au flux réseau unique. Quand un niveau de performance maximal est atteint pour une charge de travail donnée, c’est souvent le résultat d’une seule file d’attente utilisée tout au long du parcours vers un magasin de données NFS unique de l’hôte sur une seule connexion TCP. En utilisant une taille de bloc de 8 Ko, le nombre total d’IOPS a augmenté entre 3 et 16 % lors de la mise à l’échelle d’une machine virtuelle avec un seul disque de machine virtuelle vers quatre machines virtuelles avec un nombre total de 16 disques de machine virtuelle (quatre par machine virtuelle, tous sur un seul magasin de données).

L’augmentation de la taille du bloc (jusqu’à 64 Ko) pour des charges de travail à grand bloc a eu des résultats comparables, atteignant un pic de 2 148 Mio/s (machine virtuelle unique, disque de machine virtuelle unique) et 2 138 Mio/s (4 machines virtuelles et 16 disques de machine virtuelle).

Mise à l’échelle d’hôte unique – Plusieurs magasins de données

Dans le contexte d’un seul hôte Azure VMware Solution, bien qu’un seul magasin de données ait permis aux machines virtuelles de gérer 76 000 IOPS environ, la répartition des charges de travail sur deux magasins de données a augmenté le débit total de 76 % en moyenne. Le passage de deux à quatre magasins de données a entraîné une augmentation de 163 % (sur un magasin de données, une augmentation de 49 % de deux à quatre) comme illustré dans le diagramme suivant. Bien que les gains en niveau de performance soient restés présents, l’augmentation au-delà de huit magasins de données a montré des retours en diminution.

Mise à l’échelle de plusieurs hôtes – Magasin de données unique

Un seul magasin de données à partir d’un seul hôte a généré plus de 2 000 Mio/s de débit à 64 Ko séquentiel. Une distribution de la même charge de travail sur les quatre hôtes a généré un pic de gain de 135 % gérant plus de 5 000 Mio/s. Ce résultat représente probablement le plafond du niveau de performance du débit d’un seul volume Azure NetApp Files.

La diminution de la taille de bloc de 64 Ko à 8 Ko et la nouvelle exécution des mêmes itérations ont entraîné la génération par quatre machines virtuelles de 195 000 IOPS, comme illustré dans le diagramme suivant. Le niveau de performance est mis à l’échelle lors de l’augmentation du nombre d’hôtes et du nombre de magasins de données, car le nombre de flux réseau diminue. Le niveau de performance augmente en effectuant une mise à l’échelle du nombre d’hôtes multiplié par le nombre de magasins de données, car le nombre de flux réseau est un facteur des hôtes multipliés par les magasins de données.

Mise à l’échelle de plusieurs hôtes – Plusieurs magasins de données

Un seul magasin de données avec quatre machines virtuelles réparties sur quatre hôtes ont généré plus de 5 000 Mio/s d’E/S de bloc 64 Ko séquentielles. Pour des charges de travail plus exigeantes, chaque machine virtuelle est déplacée vers un magasin de données dédié, générant plus de 10 500 Mio/s au total, comme illustré dans le diagramme suivant.

Pour des charges de travail aléatoires à petit bloc, un seul magasin de données a généré 195 000 IOPS de bloc 8 KO aléatoires. La mise à l’échelle vers quatre magasins de données a généré 530 000 IOPS de bloc 8 Ko aléatoires.

Implications et suggestions

Cette section aborde la raison pour laquelle la répartition de vos machines virtuelles sur plusieurs magasins de données présente des avantages importants en matière de niveau de performance.

Comme illustré dans les résultats des tests, les capacités de performance d’Azure NetApp Files sont nombreuses :

Les tests montrent qu’un magasin de données peut gérer une moyenne d’environ148 980 IOPS, bloc de 8 Ko ou environ 4 147 Mio/s avec des IOPS de bloc de 64 Ko (moyenne de tous les tests %écriture/%lecture) à partir d’une configuration à quatre hôtes.
Une machine virtuelle sur un magasin de données –
- Si vous avez des machines virtuelles qui peuvent avoir besoin de plus de 75K IOPS, bloc de 8 Ko ou plus de 1 700 Mio/s, répartissez les systèmes de fichiers sur plusieurs disques de machine virtuelle pour mettre à l’échelle le niveau de performance de stockage des machines virtuelles.
Une machine virtuelle sur plusieurs magasins de données – Une seule machine virtuelle sur 8 magasins de données peut atteindre jusqu’à environ 147 000 IOPS de bloc 8 Ko ou environ 2 786 Mio/s avec une taille de bloc de 64 Ko.
Un hôte – Chaque hôte a pu prendre en charge une moyenne d’environ 198 060 IOPS de bloc 8 Ko ou environ 2 351 Mio/s si vous avez utilisé au moins 4 machines virtuelles par hôte avec au moins 4 magasins de données Azure NetApp Files. Vous avez donc la possibilité d’équilibrer un approvisionnement suffisant des magasins de données pour obtenir un niveau de performance maximal et éventuellement bursting plutôt qu’une gestion et des coûts compliqués.

Recommandations

Lorsque les capacités de performance d’un seul magasin de données sont insuffisantes, répartissez vos machines virtuelles sur plusieurs magasins de données pour bénéficier d’une mise à l’échelle plus importante. Une simplicité est souvent préférable, mais le niveau de performance et la scalabilité peuvent justifier une complexité ajoutée, quoique limitée.

Quatre magasins de données Azure NetApp Files fournissent jusqu’à 10 Gbit/s de bande passante utilisable pour des E/S séquentielles de grand taille ou la possibilité de gérer jusqu’à 500K d’IOPS de bloc de 8 Ko aléatoires. Bien qu’un magasin de données puisse être suffisant pour de nombreux besoins en matière de niveau de performance, démarrez avec quatre magasins de données au minimum pour obtenir les meilleures performances.

Pour bénéficier d’un réglage granulaire du niveau de performance, les systèmes d’exploitation invités Windows et Linux permettent l’entrelacement sur plusieurs disques. Par conséquent, vous devez entrelacer des systèmes de fichiers sur plusieurs disques de machine virtuelle répartis sur plusieurs magasins de données. Toutefois, si la cohérence de capture instantanée d’application constitue un problème et ne peut pas être résolue avec LVM ou des espaces de stockage, envisagez de monter Azure NetApp Files à partir du système d’exploitation invité et d’investir dans une mise à l’échelle au niveau de l’application sur lesquels Azure dispose de plusieurs options intéressantes.

Si vous effectuez un entrelacement des volumes sur plusieurs disques, le logiciel de sauvegarde ou le logiciel de récupération d’urgence prend en charge la sauvegarde simultanée de plusieurs disques virtuels. Étant donné que les écritures individuelles sont entrelacées sur plusieurs disques, le système de fichiers doit vérifier que les disques sont « gelés » pendant les opérations de capture instantanée ou de sauvegarde. Les systèmes de fichiers les plus modernes comportent une opération de capture instantanée ou de gelée, telle que xfs (xfs-freeze) et NTFS (copies de mise en mémoire fantôme de volumes), dont un logiciel de sauvegarde peut tirer parti.

Étant donné qu’Azure NetApp Files facture la capacité approvisionnée au niveau du pool de capacités au lieu de la capacité allouée (magasins de données), vous allez payer la même chose pour des magasins de données 4X20To ou des magasins de données 20x4To. Le cas échéant, vous pouvez ajuster à la demande la capacité et le niveau de performance des magasins de données dynamiquement via la console/API Azure.

Par exemple, vous constatez que vous avez besoin d’un niveau de performance supérieur en matière de stockage sur un magasin de données Standard à l’approche de la fin de l’exercice financier. Vous pouvez augmenter le niveau de service des magasins de données pendant un mois pour permettre à toutes les machines virtuelles s’y trouvant d’avoir un niveau de performance supérieur à leur disposition tout en maintenant d’autres magasins de données à un niveau de service inférieur. Non seulement vous faites des économies, mais vous obtenez aussi un niveau de performance supérieur en ayant des charges de travail réparties sur plus de connexions TCP entre chaque magasin de données dans chaque hôte AVS.

Vous pouvez surveiller les métriques de votre base de données via vCenter Server ou via la console/API Azure. Dans vCenter Server, vous pouvez surveiller la moyenne des IOPS agrégées d’un magasin de données dans les Performances/Graphiques avancés tant que vous activez une collection de métriques de contrôle d’E/S de stockage sur le magasin de données. L’API et la console Azure offrent des métriques pour WriteIops, ReadIops, ReadThroughput et WriteThroughput, entre autres, permettant de mesurer vos charges de travail au niveau du magasin de données. Grâce aux métriques Azure, vous pouvez définir des règles d’alerte avec des actions pour redimensionner automatiquement un magasin de données via une fonction Azure, un webhook ou d’autres actions.

Partager via