introduction

InfoScale garantit le fonctionnement sur RHEL sur AWS et présente les deux principaux avantages suivants. En fait, dans le monde sur site, de nombreuses entreprises déploient InfoScale pour profiter des avantages suivants: ** 1. La fonction unique de gestion du stockage réduit les temps d'arrêt et les efforts de travail pendant la maintenance du stockage (EBS dans le cas d'AWS) ** ** 2. La fonction de clustering unique améliore la disponibilité pour couvrir les échecs au niveau des applications et du système d'exploitation ** Cependant, la réalité est qu'il existe une préoccupation profondément enracinée selon laquelle "la gestion des performances d'E / S sur le cloud est difficile contrairement à sur site, mais en introduisant InfoScale sur AWS, cela deviendra encore plus compliqué?" Dans cet article, afin d'éliminer cette anxiété, je publierai les résultats des tests de performances d'E / S dans une configuration typique où la version d'InfoScale 7.4.2 RHEL est basée sur AWS. En outre, nous examinerons l'opportunité d'introduire InfoScale pour la gestion du stockage et la mise en cluster pour chaque configuration. Il décrit également un réglage simple pour améliorer les performances d'E / S.

5 configurations avec tests de performance

** Configuration 1 Configuration à un seul nœud ** C'est la structure qui devrait être la norme dans ce manuel. Si InfoScale est installé dans une instance de configuration non-cluster sur AWS et que le stockage en bloc est géré, le système de fichiers peut être étendu lors de l'expansion ou de l'ajout de stockage en bloc sans interruption de service ou dans un temps d'interruption de service plus court. (Pour plus d'informations, ici et ici Veuillez vous reporter à en_US / doc / InfoScale7.4.1_Win_on_AWS_VVR_storage_maintenance). Veuillez l'utiliser comme une norme de performance d'E / S pouvant être obtenue lorsque InfoScale est installé dans des instances non en cluster sur AWS. De plus, en comparant le degré d'infériorité des quatre autres configurations par rapport aux performances d'E / S obtenues avec cette configuration, les points à garder à l'esprit concernant les performances d'E / S pour chaque configuration de cluster deviennent clairs.

** Configuration 2 Configuration du cluster de disques partagés ** En considérant dans quelle mesure les performances d'E / S se détériorent par rapport à la configuration 1, il est possible de comprendre le degré de surcharge associé à la mise en cluster. Dans la configuration 1 et la configuration 2, une instance a toujours un accès dédié à un EBS, donc en théorie, seule la surcharge de clustering est perceptible. Veuillez vous reporter à ici pour savoir comment créer la configuration ci-dessus.

** Configuration 3 Configuration du cluster dans AZ à l'aide de FSS (heartbeat est le système TCP1) ** En considérant à quel point les performances d'E / S se détériorent par rapport à la configuration 2, il est possible de comprendre le degré de surcharge associé au miroir virtuel par FSS. La seule différence entre la configuration 2 et la configuration 3 est de savoir si vous utilisez ou non un miroir virtuel, donc en théorie seule la surcharge du miroir virtuel sera perceptible. Veuillez consulter ici pour savoir comment créer la configuration ci-dessus.

** Configuration 4 Configuration du cluster dans AZ à l'aide de FSS (Heartbeat est un système UDP 2) ** En comparant la configuration 3 et les performances d'E / S, il est possible de comprendre l'effet de la configuration du Heartbeat LAN qui réalise le miroir virtuel par FSS sur les performances d'E / S. La différence entre la configuration 3 et la configuration 4 est de savoir si le réseau local Heartbeat possède un système TCP / IP ou deux systèmes UDP / IP. Si une charge d'E / S qui dépasse les performances de la carte réseau AWS est appliquée, on peut s'attendre à ce que la configuration 4, qui peut répartir la charge sur deux systèmes, prévaudra et, dans d'autres cas, la configuration 3, qui a une petite surcharge, prévaudra. Veuillez consulter ici pour savoir comment créer la configuration ci-dessus.

** Configuration 5 AZ configuration de cluster chevauchante utilisant FSS (heartbeat est le système UDP 2) ** En comparant la configuration 4 et les performances d'E / S, il est possible de comprendre l'effet du retard du réseau sur AZ sur les performances d'E / S. La seule différence entre la configuration 4 et la configuration 5 est de savoir si elle chevauche ou non AZ. Les performances du miroir virtuel par FSS, en particulier IOPS, dépendent de la latence du réseau Heartbeat utilisé, on peut donc s'attendre à ce que la configuration 4 soit supérieure. Veuillez vous reporter à ici pour savoir comment créer la configuration ci-dessus.

** Type d'EBS utilisé ** Dans ce document, l'EBS utilisé pour la vérification utilise "gp2". gp2 a une fonction appelée "burst bucket", qui garantit un certain IOPS s'il y a de la place dans le ticket burst. Généralement, les IOPS d'EBS sont proportionnels à la capacité, donc si vous utilisez EBS avec une petite capacité, vous ne pourrez peut-être pas obtenir suffisamment d'IOPS, mais vous pouvez éviter cet inconvénient en utilisant gp2. Attention cependant à ne pas manquer de tickets en rafale. Pour plus d'informations sur gp2 et les buckets de rafale, consultez Informations AWS.

** Environnement machine ** Les informations environnementales pour cette vérification sont les suivantes OS：RHEL7.7 InfoScale 7.4.2 Type d'instance: t2.large (2Core, 8 Go de mémoire) EBS: SSD standard gp2 5 Go

Comparaison des résultats des tests de performance pour 5 configurations

Dans la comparaison de chaque configuration, la tendance était presque la même pour tous les 9 types suivants. Dans ce livre, nous présenterons et discuterons des résultats de la "taille d'E / S 4Kbyte, rapport lecture / écriture 5: 5, accès aléatoire". ・ Taille E / S Rapport de lecture / écriture de 4 Ko 10: 0, accès aléatoire ・ Taille E / S 4 Ko Rapport lecture / écriture 5: 5, accès aléatoire ・ Taille E / S 4 Ko Rapport lecture / écriture 0:10, accès aléatoire ・ Taille E / S 4 Ko Rapport lecture / écriture 10: 0, séquentiel ・ Taille E / S 4 Ko Rapport lecture / écriture 5: 5, séquentiel ・ Taille E / S 4 Ko Rapport lecture / écriture 0:10, séquentiel ・ Taille E / S 64 Ko Rapport lecture / écriture 10: 0, séquentiel ・ Taille E / S 64 Ko Rapport lecture / écriture 5: 5, séquentiel ・ Taille E / S 64 Ko Rapport lecture / écriture 0:10, séquentiel

IOPS Comme pour les IOPS, comme prévu, la configuration unique et la configuration du cluster de disques partagés ont donné presque les mêmes résultats. Le fait que la configuration du cluster de disques partagés ait légèrement dépassé semble être une erreur. Les deux ont démontré la performance d'environ 2000 IOPS. Considérant que l'IOPS garanti par le seau de rafale était de 3000 et la charge appliquée par IOMETER, on peut dire que le résultat est comme attendu. Les deux configurations avec mise en miroir virtuelle FSS en AZ représentent environ la moitié des IOPS par rapport aux deux configurations précédentes. Cela peut être considéré comme une surcharge du miroir virtuel. Enfin, dans la configuration où le miroir virtuel était exécuté par FSS sur AZ, les performances étaient encore détériorées en raison du délai de battement cardiaque causé par le chevauchement de AZ.

débit En termes de débit, le résultat de la comparaison est exactement le même que celui des IOPS. En effet, le débit correspond aux IOPS multipliés par la taille des E / S. En ce qui concerne la valeur de débit spécifique, par exemple, lorsque vous vous concentrez sur la configuration à un seul nœud, l'IOPS de la page précédente était de 2000, donc le multiplier par la taille d'E / S de 4 Ko donne 8 Mo, ce qui correspond au graphique ci-dessus.

** L'utilisation du processeur ** En termes d'utilisation du processeur, les résultats de la comparaison étaient complètement différents des IOPS et du débit, ce qui est également conforme aux attentes. Les configurations à nœud unique et à disque partagé sans traitement spécial lié aux E / S ont donné des résultats très faibles. En revanche, les trois configurations restantes avec mise en miroir virtuelle FSS ont une surcharge maximale d'environ 2%. Bien que cela semble bien visible dans le graphique, 2% est une valeur négligeable pour l'ensemble du système. De plus, le taux d'utilisation du processeur est légèrement plus élevé dans la configuration utilisant TCP / IP car diverses vérifications sont effectuées dans la communication réseau pour le traitement synchrone du miroir virtuel.

Considération

** Configuration à un seul nœud ** Lorsque InfoScale est installé sur une instance RHEL à nœud unique (configuration sans cluster) sur WS dans le but d'améliorer la gestion du stockage, la surcharge du processeur due à l'introduction d'InfoScale se situe dans la plage d'erreur et les performances d'E / S sont également dans l'environnement natif. On peut dire qu'il n'y a pas beaucoup de différence.

** Configuration du cluster de type de disque partagé (cluster dans AZ) ** Les performances d'E / S et la surcharge du processeur de la configuration de cluster de type de disque partagé à l'aide de nfoScale n'étaient pas très différentes de celles de la configuration sans cluster. Par conséquent, lors de l'examen d'une configuration de cluster dans l'AZ, il est recommandé de sélectionner un cluster de type de disque partagé du point de vue des performances.

** Configuration du cluster dans AZ ** Les trois modèles utilisant des miroirs virtuels par FSS étaient inférieurs en termes de performances d'E / S et de surcharge du processeur par rapport aux types de disque unique et partagé. Par conséquent, s'il n'est pas nécessaire de faire un miroir virtuel (cluster en AZ), un cluster de type miroir virtuel n'est pas recommandé du point de vue des performances. Cependant, les miroirs virtuels sont une option viable car les configurations de disque partagé ne sont pas disponibles pour les clusters dans les zones de disponibilité. Il est possible d'utiliser la réplication en plus des miroirs virtuels, mais par souci de clarté, nous ne mentionnerons pas la réplication dans ce document. En d'autres termes, en supposant un cluster chevauchant AZ, un réglage est nécessaire pour améliorer les performances d'E / S du cluster à l'aide de miroirs virtuels. Le réglage est décrit en détail dans le chapitre suivant.

Réglage pour améliorer les performances du miroir virtuel

Le réglage Heartbeat est un moyen efficace d'améliorer les performances d'E / S des clusters virtuels en miroir. En effet, les clusters virtuels en miroir synchronisent les disques locaux des nœuds de cluster individuels via la pulsation. Il existe trois façons de régler le rythme cardiaque.

1. Extension de la taille MTU
Extension de la taille du tampon de communication RHEL
1. Extension du seuil de contrôle de flux de LLT, le pilote de pulsation d'InfoScale Chacun a sa propre convenance, je vais donc les expliquer individuellement.

** Amélioration des performances en augmentant la taille du MTU ** Lors de la synchronisation de disques locaux via Heartbeat, plus la taille de MTU est grande, plus l'unité de transfert de données est grande et meilleure est l'efficacité du transfert. Cependant, si la taille d'écriture des données est petite, l'efficacité du transfert sera pire, alors soyez prudent. Le réglage est efficace dans les cas suivants.

1. Le traitement par lots
Accès séquentiel
1. Beaucoup d'écritures Par exemple, si le NIC MTU est de 1 500 octets et que la taille de bloc du système de fichiers est de 8 Ko, vous pouvez vous attendre à une amélioration des performances en augmentant la taille de MTU de plus de 8 Ko.

Voici une comparaison des performances de la taille des E / S 4 Ko, du rapport lecture / écriture 5: 5 et de l'accès séquentiel dans un cluster à l'aide de TCP / IP pour les pulsations en AZ. Les 4 modèles suivants ont été comparés.

1. Pas de réglage
Taille MTU étendue de 1500 octets à 9000 octets
1. Extension de la taille du tampon de communication RHEL à 4 fois la valeur par défaut
Seuil de contrôle de flux LLT étendu à deux fois la valeur par défaut Dans ce modèle, 4 Ko de données circulent en continu au rythme cardiaque, donc l'extension de la taille MTU était le résultat le plus efficace.

** Amélioration des performances en augmentant la taille du tampon de communication RHEL ** Lors de la synchronisation de disques locaux via Heartbeat, une grande taille de tampon de communication RHEL améliorera l'efficacité du transfert de données et les performances. Cependant, la taille de la mémoire tampon ne doit pas dépasser la quantité de mémoire disponible. Le réglage est efficace dans les cas suivants.

1. Le traitement par lots
UDP est sélectionné pour le battement de cœur du cluster
1. Nombreuses écritures et grande taille de bloc d'E / S Pour plus d'informations sur les tampons de communication RHEL et les méthodes de réglage, consultez la documentation Red Hat (https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/6/html/performance_tuning_guide/s-network-dont- Voir réglages par défaut).

Voici une comparaison des performances avec une taille d'E / S de 64 Ko, un rapport lecture / écriture de 5: 5 et un accès séquentiel dans un cluster à l'aide de UDP / IP pour les pulsations en AZ. Les 4 modèles suivants ont été comparés.

1. Pas de réglage
Taille MTU étendue de 1500 octets à 9000 octets
1. Extension de la taille du tampon de communication RHEL à 4 fois la valeur par défaut
Seuil de contrôle de flux LLT étendu à deux fois la valeur par défaut Dans ce modèle, il n'y a pas beaucoup de différence dans les réglages, mais le résultat est que l'expansion de la taille du tampon de communication est légèrement plus efficace que les autres.

** Amélioration des performances en élargissant le seuil de contrôle de flux LLT ** Le battement de cœur d'InfoScale est effectué dans un protocole unique appelé LLT. LLT effectue un contrôle de flux pour empêcher une grande quantité de données de s'accumuler dans la file d'attente d'envoi. Le contrôle de flux a un seuil, et lorsque la quantité de données accumulées dans la file d'attente dépasse la valeur d'eau élevée, la file d'attente ne sera pas acceptée tant que la quantité de données accumulées ne sera pas inférieure à la valeur d'eau basse. Par conséquent, lorsque le transfert de données se produit en rafales, le contrôle de flux réduit l'efficacité du transfert de données. À l'inverse, en augmentant le seuil de contrôle de débit (valeur d'eau élevée), l'efficacité du transfert de données et les performances s'amélioreront. Cependant, la taille de la file d'attente ne doit pas dépasser la quantité de mémoire disponible. Le réglage est efficace dans les cas suivants.

1. Latence réseau importante, par exemple entre les zones de disponibilité
Beaucoup d'écritures Pour plus d'informations sur les seuils de contrôle de flux LLT et les méthodes de réglage, reportez-vous à la page 1155 du manuel InfoScale (https://sort.veritas.com/DocPortal/pdf/142044775-142044783-1).

Ce qui suit est une comparaison des performances de la taille des E / S 4 Ko, du rapport lecture / écriture 5: 5 et de l'accès séquentiel dans un cluster qui utilise UDP / IP sur AZ pour la pulsation. Les 4 modèles suivants ont été comparés.

1. Pas de réglage
Taille MTU étendue de 1500 octets à 9000 octets
1. Extension de la taille du tampon de communication RHEL à 4 fois la valeur par défaut
Seuil de contrôle de flux LLT étendu à deux fois la valeur par défaut Dans ce modèle, le contrôle de flux se produit fréquemment en raison de la latence élevée du rythme cardiaque. Le réglage pour le supprimer était le résultat le plus efficace. Ce réglage est recommandé si vous souhaitez utiliser des miroirs virtuels FSS dans un cluster sur des zones de disponibilité pour améliorer les performances.

En outre, Veritas a publié un livre blanc sur les tests de performances globales, comprenant des détails sur la méthode de réglage décrite ici. Veuillez consulter ici!

en conclusion

Comment était-ce? Cet article et le livre blanc présentés dans l'article ne réduisent-ils pas les préoccupations lors de l'introduction d'InfoScale dans RHEL sur AWS? Veuillez attendre avec impatience InfoScale sur AWS à l'avenir!

Pour une consultation en négociation commerciale ici

Lorsque vous répondez aux demandes de cet article, veillez à saisir la balise #GWC dans le champ "Commentaire / Communication". Vos informations seront gérées conformément à la politique de confidentialité de Veritas.

Autres liens

[article récapitulatif] Liens vers tous les articles de Veritas Technologies Merci pour votre coopération.

[LINUX] InfoScale 7.4.2 pour RHEL sur AWS Performance Test Results Publication publique