[LINUX] InfoScale 7.4.2 für RHEL auf AWS Performance Test Results Public Release

Einführung

InfoScale garantiert den Betrieb unter RHEL unter AWS und bietet die folgenden zwei Hauptvorteile. In der lokalen Welt setzen viele Unternehmen InfoScale ein, um die folgenden Vorteile zu nutzen: ** 1. Die einzigartige Speicherverwaltungsfunktion reduziert Ausfallzeiten und Arbeitsaufwand während der Speicherwartung (EBS bei AWS) ** ** 2. Die einzigartige Clustering-Funktion verbessert die Verfügbarkeit, um Fehler auf Anwendungs- und Betriebssystemebene abzudecken ** Die Realität ist jedoch, dass tief verwurzelte Bedenken bestehen, dass "das E / A-Leistungsmanagement in der Cloud im Gegensatz zu On-Premise schwierig ist, aber durch die Einführung von InfoScale in AWS wird es noch komplizierter." In diesem Artikel werde ich die Ergebnisse des E / A-Leistungstests in einer typischen Konfiguration veröffentlichen, in der die RHoS-Version von InfoScale 7.4.2 auf AWS basiert, um diese Angst zu beseitigen. Darüber hinaus werden wir prüfen, ob die Einführung von InfoScale für die Speicherverwaltung und das Clustering für jede Konfiguration angemessen ist. Außerdem wird die einfache Optimierung zur Verbesserung der E / A-Leistung beschrieben.

5 Konfigurationen mit Leistungstests

** Konfiguration 1 Einzelknotenkonfiguration ** AWS_InfoScale_RHEL_single.jpg Dies ist die Struktur, die der Standard in diesem Dokument sein sollte. Wenn InfoScale in einer Nicht-Cluster-Konfigurationsinstanz unter AWS installiert ist und der Blockspeicher verwaltet wird, kann das Dateisystem erweitert werden, wenn Blockspeicher ohne Dienstausfall oder in kürzerer Dienstausfallzeit erweitert oder hinzugefügt werden. (Weitere Informationen finden Sie unter hier und hier. Weitere Informationen finden Sie unter en_US / doc / InfoScale7.4.1_Win_on_AWS_VVR_storage_maintenance. Verwenden Sie es als Standard für die E / A-Leistung, die erreicht werden kann, wenn InfoScale in nicht gruppierten Instanzen unter AWS installiert wird. Durch den Vergleich, wie minderwertig die anderen vier Konfigurationen der mit dieser Konfiguration erzielten E / A-Leistung sind, werden auch die Punkte deutlich, die hinsichtlich der E / A-Leistung für jede Clusterkonfiguration zu beachten sind.

** Konfiguration 2 Shared Disk Cluster Konfiguration ** AWS_InfoScale_RHEL_shareddisk.jpg Wenn berücksichtigt wird, um wie viel sich die E / A-Leistung in Bezug auf Konfiguration 1 verschlechtert, ist es möglich, den mit dem Clustering verbundenen Overhead zu verstehen. In Konfiguration 1 und Konfiguration 2 hat eine Instanz noch dedizierten Zugriff auf einen EBS, sodass theoretisch nur der Cluster-Overhead erkennbar ist. Informationen zum Erstellen der obigen Konfiguration finden Sie unter hier.

** Konfiguration 3 Clusterkonfiguration in AZ mit FSS (Heartbeat ist das TCP1-System) ** AWS_InfoScale_RHEL_FSS_TCP.jpg Wenn berücksichtigt wird, um wie viel sich die E / A-Leistung in Bezug auf Konfiguration 2 verschlechtert, ist es möglich, den Grad des Overheads zu verstehen, der mit virtuellen Spiegeln durch FSS verbunden ist. Der einzige Unterschied zwischen Konfiguration 2 und Konfiguration 3 besteht darin, ob Sie einen virtuellen Spiegel verwenden oder nicht. Theoretisch ist also nur der Overhead des virtuellen Spiegels erkennbar. Informationen zum Erstellen der obigen Konfiguration finden Sie unter hier.

** Konfiguration 4 Clusterkonfiguration in AZ mit FSS (Heartbeat ist UDP 2-System) ** AWS_InfoScale_RHEL_FSS_UDP.jpg Durch Vergleichen der Konfiguration 3 und der E / A-Leistung ist es möglich, die Auswirkung der Konfiguration des Heartbeat-LAN zu verstehen, das den virtuellen Spiegel durch FSS auf die E / A-Leistung realisiert. Der Unterschied zwischen Konfiguration 3 und Konfiguration 4 besteht darin, ob das Heartbeat-LAN über ein TCP / IP-System oder zwei UDP / IP-Systeme verfügt. Wenn eine E / A-Last angewendet wird, die die Leistung der AWS-Netzwerkkarte überschreitet, ist zu erwarten, dass Konfiguration 4, die die Last auf zwei Systeme verteilen kann, und in anderen Fällen Konfiguration 3 mit geringem Overhead vorherrscht. Informationen zum Erstellen der obigen Konfiguration finden Sie unter hier.

** Konfiguration 5 AZ-Cluster-Konfiguration mit FSS (Heartbeat ist UDP 2-System) ** AWS_InfoScale_RHEL_FSS_UDP_interAZ.jpg Durch Vergleichen der Konfiguration 4 und der E / A-Leistung ist es möglich, die Auswirkung der Netzwerkverzögerung über AZ auf die E / A-Leistung zu verstehen. Der einzige Unterschied zwischen Konfiguration 4 und Konfiguration 5 besteht darin, ob sie sich über AZ erstreckt oder nicht. Die Leistung des virtuellen Spiegels durch FSS, insbesondere IOPS, hängt von der Latenz des verwendeten Heartbeat-Netzwerks ab, sodass zu erwarten ist, dass Konfiguration 4 überlegen ist. Informationen zum Erstellen der obigen Konfiguration finden Sie unter hier.

** Art des verwendeten EBS ** In diesem Dokument verwendet das zur Überprüfung verwendete EBS "gp2". gp2 hat eine Funktion namens "Burst Bucket", die ein bestimmtes IOPS garantiert, wenn im Burst-Ticket Platz ist. Im Allgemeinen ist der IOPS von EBS proportional zur Kapazität. Wenn Sie also EBS mit einer geringen Kapazität verwenden, können Sie möglicherweise nicht genügend IOPS erhalten, aber Sie können diesen Nachteil vermeiden, indem Sie gp2 verwenden. Achten Sie jedoch darauf, dass Ihnen nicht die Burst-Tickets ausgehen. Informationen zu GP2- und Burst-Buckets finden Sie unter AWS-Informationen.

** Maschinenumgebung ** Die Umgebungsinformationen für diese Überprüfung lauten wie folgt OS：RHEL7.7 InfoScale 7.4.2 Instanztyp: t2.large (2Core, 8 GB Speicher) EBS: gp2 Standard SSD 5 GByte

Vergleich der Leistungstestergebnisse für 5 Konfigurationen

Beim Vergleich jeder Konfiguration war die Tendenz für alle folgenden 9 Typen nahezu gleich. In diesem Buch werden die Ergebnisse der typischsten "E / A-Größe 4 KByte, Lese- / Schreibverhältnis 5: 5, Direktzugriff" vorgestellt und diskutiert. ・ E / A-Größe 4 KB Lese- / Schreibverhältnis 10: 0, Direktzugriff ・ E / A-Größe 4 KB Lese- / Schreibverhältnis 5: 5, Direktzugriff ・ E / A-Größe 4 KByte Lese- / Schreibverhältnis 0:10, Direktzugriff ・ E / A-Größe 4 KByte Lese- / Schreibverhältnis 10: 0, sequentiell ・ E / A-Größe 4 KByte Lese- / Schreibverhältnis 5: 5, sequentiell ・ E / A-Größe 4 KByte Lese- / Schreibverhältnis 0:10, sequentiell ・ E / A-Größe 64 KByte Lese- / Schreibverhältnis 10: 0, sequentiell ・ E / A-Größe 64 KByte Lese- / Schreibverhältnis 5: 5, sequentiell ・ E / A-Größe 64 KByte Lese- / Schreibverhältnis 0:10, sequentiell

IOPS AWS_InfoScale_RHEL_IOPS_notune.jpg Wie bei IOPS ergaben die Einzelkonfiguration und die Konfiguration des gemeinsam genutzten Festplattenclusters erwartungsgemäß fast die gleichen Ergebnisse. Es scheint ein Fehler zu sein, dass die Konfiguration des gemeinsam genutzten Festplattenclusters geringfügig überschritten wurde. Beide zeigten die Leistung von etwa 2000 IOPS. In Anbetracht der Tatsache, dass der vom Burst-Bucket garantierte IOPS 3000 und die von IOMETER aufgebrachte Last betrug, kann gesagt werden, dass das Ergebnis wie erwartet ist. Die beiden Konfigurationen mit virtueller FSS-Spiegelung in AZ sind etwa die Hälfte des IOPS im Vergleich zu den beiden vorherigen Konfigurationen. Dies kann als Overhead für virtuelle Spiegel betrachtet werden. Schließlich wurde in der Konfiguration, in der der virtuelle Spiegel von FSS über AZ ausgeführt wurde, die Leistung aufgrund der Herzschlagverzögerung, die durch das Überspannen von AZ verursacht wurde, weiter verschlechtert.

** Durchsatz ** AWS_InfoScale_RHEL_Throughput_notune.jpg In Bezug auf den Durchsatz entspricht das Vergleichsergebnis genau dem von IOPS. Dies liegt daran, dass der Durchsatz IOPS multipliziert mit der E / A-Größe ist. Was beispielsweise den spezifischen Durchsatzwert betrifft, wenn Sie sich auf die Einzelknotenkonfiguration konzentrieren, war das IOPS auf der vorherigen Seite 2000, sodass das Multiplizieren mit der E / A-Größe von 4 KByte 8 MByte ergibt, was dem obigen Diagramm entspricht.

** CPU auslastung ** AWS_InfoScale_RHEL_CPU_notune.jpg In Bezug auf die CPU-Auslastung war das Vergleichsergebnis völlig anders als bei IOPS und Durchsatz, aber dies ist auch wie erwartet. Einzelknoten- und gemeinsam genutzte Festplattenkonfigurationen ohne spezielle E / A-bezogene Verarbeitung führten zu sehr geringen Ergebnissen. Andererseits haben die verbleibenden drei Konfigurationen mit virtueller FSS-Spiegelung einen maximalen Overhead von etwa 2%. Obwohl es in der Grafik deutlich sichtbar ist, sind 2% ein vernachlässigbarer Wert für das gesamte System. Darüber hinaus ist die CPU-Auslastungsrate in der Konfiguration mit TCP / IP geringfügig höher, da in der Netzwerkkommunikation verschiedene Überprüfungen für die synchrone Verarbeitung des virtuellen Spiegels durchgeführt werden.

Erwägung

** Einzelknotenkonfiguration ** Wenn InfoScale auf einer RHEL-Instanz eines einzelnen Knotens (Nicht-Cluster-Konfiguration) unter WS installiert wird, um die Speicherverwaltbarkeit zu verbessern, liegt der CPU-Overhead aufgrund der Einführung von InfoScale im Fehlerbereich, und die E / A-Leistung liegt auch in der nativen Umgebung. Man kann sagen, dass es keinen großen Unterschied gibt.

** Clusterkonfiguration für gemeinsam genutzten Festplattentyp (Cluster in AZ) ** Die E / A-Leistung und der CPU-Overhead der Clusterkonfiguration des gemeinsam genutzten Festplattentyps mit nfoScale unterschieden sich nicht wesentlich von denen der Nicht-Cluster-Konfiguration. Wenn Sie eine Clusterkonfiguration innerhalb der AZ in Betracht ziehen, wird daher empfohlen, einen Cluster mit gemeinsam genutzten Festplattentypen unter dem Gesichtspunkt der Leistung auszuwählen.

** Clusterkonfiguration in AZ ** Alle drei Muster, die virtuelle Spiegel von FSS verwenden, waren hinsichtlich E / A-Leistung und CPU-Overhead im Vergleich zu Einzelknoten- und gemeinsam genutzten Festplattentypen schlechter. Wenn daher kein virtueller Spiegel (Cluster in AZ) erforderlich ist, wird ein Cluster vom Typ virtueller Spiegel aus Sicht der Leistung nicht empfohlen. Virtuelle Spiegel sind jedoch eine praktikable Option, da für Cluster in verschiedenen AZs keine gemeinsam genutzten Festplattenkonfigurationen verfügbar sind. Es ist möglich, die Replikation zusätzlich zu den virtuellen Spiegeln zu verwenden. Aus Gründen der Übersichtlichkeit wird die Replikation in diesem Dokument jedoch nicht erwähnt. Mit anderen Worten, unter der Annahme eines Clusters, der sich über die AZ erstreckt, ist eine Optimierung erforderlich, um die E / A-Leistung des Clusters mithilfe virtueller Spiegel zu verbessern. Die Abstimmung wird im nächsten Kapitel ausführlich erläutert.

Optimierung zur Verbesserung der Leistung virtueller Spiegel

Heartbeat-Tuning ist ein effektiver Weg, um die E / A-Leistung von virtuell gespiegelten Clustern zu verbessern. Dies liegt daran, dass virtuell gespiegelte Cluster die lokalen Festplatten einzelner Clusterknoten über Heartbeat synchronisieren. Es gibt drei Möglichkeiten, den Herzschlag einzustellen.

    1. Erweiterung der MTU-Größe
  2. Erweiterung der Größe des RHEL-Kommunikationspuffers
    1. Erweiterung der Flusskontrollschwelle von LLT, dem Heartbeat-Treiber von InfoScale Jeder hat seine eigene Eignung, deshalb werde ich sie einzeln erklären.

** Verbesserte Leistung durch Erweiterung der MTU-Größe ** Bei der Synchronisierung lokaler Festplatten über Heartbeat gilt: Je größer die MTU-Größe, desto größer die Datenübertragungseinheit und desto besser die Übertragungseffizienz. Wenn die Datenschreibgröße jedoch klein ist, ist die Übertragungseffizienz schlechter. Seien Sie also vorsichtig. Die Abstimmung ist in den folgenden Fällen wirksam.

    1. Stapelverarbeitung
  2. Sequentieller Zugriff
    1. Viele schreiben Wenn die NIC-MTU beispielsweise 1500 Byte und die Blockgröße des Dateisystems 8 KB beträgt, können Sie eine Leistungsverbesserung erwarten, indem Sie die MTU-Größe größer als 8 KB machen.

Das Folgende ist ein Leistungsvergleich von E / A-Größe 4 KB, Lese- / Schreibverhältnis 5: 5 und sequentiellem Zugriff in einem Cluster unter Verwendung von TCP / IP für Heartbeat in AZ. Die folgenden 4 Muster wurden verglichen.

    1. Keine Abstimmung
  2. Erweiterte MTU-Größe von 1500 Byte auf 9000 Byte
    1. Die Größe des RHEL-Kommunikationspuffers wurde auf das Vierfache der Standardeinstellung erweitert
  4. Der Schwellenwert für die LLT-Flusskontrolle wurde auf das Doppelte des Standardwerts erhöht AWS_InfoScale_RHEL_IOPS_MTU.jpg In diesem Muster fließen 4 KB Daten kontinuierlich in den Herzschlag, sodass die Erweiterung der MTU-Größe das effektivste Ergebnis war.

** Leistungsverbesserung durch Erweiterung der Größe des RHEL-Kommunikationspuffers ** Bei der Synchronisierung lokaler Festplatten über Heartbeat verbessert eine große Größe des RHEL-Kommunikationspuffers die Effizienz der Datenübertragung und die Leistung. Die Puffergröße darf jedoch die Menge des verfügbaren Speichers nicht überschreiten. Die Abstimmung ist in den folgenden Fällen wirksam.

    1. Stapelverarbeitung
  2. UDP wird für den Heartbeat des Clusters ausgewählt
    1. Viele Schreibvorgänge und große E / A-Blockgrößen Weitere Informationen zu RHEL-Kommunikationspuffern und Optimierungsmethoden finden Sie in der Red Hat-Dokumentation (https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/6/html/performance_tuning_guide/s-network-dont-) Siehe Standardeinstellungen).

Das Folgende ist ein Leistungsvergleich mit einer E / A-Größe von 64 KByte, einem Lese- / Schreibverhältnis von 5: 5 und einem sequentiellen Zugriff in einem Cluster unter Verwendung von UDP / IP für Heartbeat in AZ. Die folgenden 4 Muster wurden verglichen.

    1. Keine Abstimmung
  2. Erweiterte MTU-Größe von 1500 Byte auf 9000 Byte
    1. Die Größe des RHEL-Kommunikationspuffers wurde auf das Vierfache der Standardeinstellung erweitert
  4. Der Schwellenwert für die LLT-Flusskontrolle wurde auf das Doppelte des Standardwerts erhöht AWS_InfoScale_RHEL_IOPS_Buffer.jpg In diesem Muster gibt es keinen großen Unterschied bei der Abstimmung, aber das Ergebnis ist, dass die Erweiterung der Kommunikationspuffergröße etwas effektiver ist als die anderen.

** Leistungsverbesserung durch Erweiterung der LLT-Flusskontrollschwelle ** Der Herzschlag von InfoScale erfolgt in einem einzigartigen Protokoll namens LLT. LLT führt eine Flusskontrolle durch, um zu verhindern, dass sich eine große Datenmenge in der Sendewarteschlange ansammelt. Die Flusskontrolle hat einen Schwellenwert, und wenn die in der Warteschlange akkumulierte Datenmenge den hohen Wasserwert überschreitet, wird die Warteschlange erst akzeptiert, wenn die akkumulierte Datenmenge den niedrigen Wasserwert unterschreitet. Wenn die Datenübertragung in Bursts erfolgt, verringert die Flusssteuerung daher die Datenübertragungseffizienz. Umgekehrt wird durch die Erweiterung der Durchflussregelschwelle (hoher Wasserwert) die Effizienz der Datenübertragung und der Leistung verbessert. Die Größe der Warteschlange darf jedoch die verfügbare Speichermenge nicht überschreiten. Die Abstimmung ist in den folgenden Fällen wirksam.

    1. Große Netzwerklatenz, z. B. über AZs hinweg
  2. Viele schreiben Weitere Informationen zu Schwellenwerten und Optimierungsmethoden für die LLT-Flusskontrolle finden Sie auf Seite 1155 des InfoScale-Handbuchs (https://sort.veritas.com/DocPortal/pdf/142044775-142044783-1).

Das Folgende ist ein Leistungsvergleich von E / A-Größe 4 KB, Lese- / Schreibverhältnis 5: 5 und sequentiellem Zugriff in einem Cluster, der UDP / IP über AZ für Heartbeat verwendet. Die folgenden 4 Muster wurden verglichen.

    1. Keine Abstimmung
  2. Erweiterte MTU-Größe von 1500 Byte auf 9000 Byte
    1. Die Größe des RHEL-Kommunikationspuffers wurde auf das Vierfache der Standardeinstellung erweitert
  4. Der Schwellenwert für die LLT-Flusskontrolle wurde auf das Doppelte des Standardwerts erhöht AWS_InfoScale_RHEL_IOPS_LLT.jpg In diesem Muster tritt die Flusssteuerung häufig aufgrund der hohen Latenz des Herzschlags auf. Die Optimierung zur Unterdrückung war das effektivste Ergebnis. Diese Optimierung wird empfohlen, wenn Sie virtuelle FSS-Spiegel in einem Cluster über AZs hinweg verwenden möchten, um die Leistung zu verbessern.

Darüber hinaus hat Veritas ein Whitepaper zu Leistungstests im Allgemeinen veröffentlicht, das die Details der hier erläuterten Optimierungsmethode enthält. Bitte beziehen Sie sich auf hier!

abschließend

Wie war es? Reduzieren dieser Artikel und das in diesem Artikel eingeführte Whitepaper nicht die Bedenken bei der Einführung von InfoScale in RHEL unter AWS? Bitte freuen Sie sich in Zukunft auf InfoScale auf AWS!

Beratung zu Geschäftsverhandlungen hier

Wenn Sie Anfragen aus diesem Artikel ausfüllen, geben Sie bitte das # GWC-Tag in das Feld "Kommentar / Kommunikation" ein. Ihre Daten werden gemäß den Datenschutzbestimmungen von Veritas verwaltet.

Andere Links

[Zusammenfassender Artikel] Links zu allen Artikeln von Veritas Technologies Vielen Dank für Ihre Zusammenarbeit.

Recommended Posts

InfoScale 7.4.2 für RHEL auf AWS Performance Test Results Public Release