In diesem Artikel möchten wir die Besonderheiten des Betriebs von All-Flash-Arrays von AccelStor mit einer der beliebtesten Virtualisierungsplattformen, VMware vSphere, erläutern. Insbesondere wollen wir auf die Parameter eingehen, die dazu beitragen, den maximalen Nutzen aus einem so leistungsstarken Werkzeug wie All Flash zu ziehen.
Die All-Flash-Arrays AccelStor NeoSapphire™ sind oder Knoten-Geräte, die auf SSD-Speicher basieren und einen grundlegend anderen Ansatz zur Umsetzung des Datenmanagements und Zugriffsmanagements mithilfe der eigenen Technologie anstelle weit verbreiteter RAID-Algorithmen bieten. Die Arrays ermöglichen blockweisen Zugriff für Hosts über Fibre-Channel- oder iSCSI-Schnittstellen. Fairerweise sei erwähnt, dass Modelle mit iSCSI-Schnittstelle auch Dateizugriff als angenehmen Bonus bieten. In diesem Artikel konzentrieren wir uns jedoch auf die Verwendung blockbasierter Protokolle, da sie für All Flash die leistungsstärksten sind.
Der gesamte Prozess der Bereitstellung und anschließenden Konfiguration der Zusammenarbeit zwischen dem AccelStor-Speichersystem und der Virtualisierungsplattform VMware vSphere lässt sich in mehrere Phasen unterteilen:
- Implementierung der Verbindungsarchitektur und Konfiguration des SAN-Netzwerks;
- Konfiguration des All-Flash-Speichers;
- Konfiguration der ESXi-Hosts;
- Konfiguration der virtuellen Maschinen.
Für die Beispiele wurden AccelStor NeoSapphire™ Arrays mit Fibre Channel- und iSCSI-Schnittstellen verwendet. Die Basissoftware ist VMware vSphere 6.7U1.
Vor der Bereitstellung der in diesem Artikel beschriebenen Systeme wird dringend empfohlen, die VMware-Dokumentation zu Leistungsfragen zu konsultieren ( ) und zu iSCSI-Einstellungen ()
Verbindungsarchitektur und Konfiguration des SAN-Netzwerks
Die Hauptkomponenten des SAN-Netzwerks sind HBA-Adapter in den ESXi-Hosts, SAN-Switches und die Speicherknoten. Eine typische Topologie eines solchen Netzwerks sieht folgendermaßen aus:
Der Begriff Switch bezieht sich hier sowohl auf einen einzelnen physischen Switch als auch auf eine Gruppe von Switches (Fabric), die gemeinsam genutzt werden, oder auf ein zwischen verschiedenen Diensten gemeinsames Gerät (VSAN im Falle von Fibre Channel und VLAN im Falle von iSCSI). Der Einsatz von zwei unabhängigen Switches/Fabric ermöglicht es, einen möglichen Single Point of Failure auszuschließen.
Obwohl eine direkte Verbindung von Hosts zu dem Array unterstützt wird, ist sie stark abzuraten. Die Leistung von All Flash Arrays ist ausreichend hoch. Um die maximale Geschwindigkeit zu erreichen, müssen alle Ports des Arrays genutzt werden. Daher ist der Einsatz von mindestens einem Switch zwischen den Hosts und NeoSapphire™ unerlässlich.
Das Vorhandensein von zwei Ports am HBA-Host ist ein zwingendes Erfordernis, um eine maximale Leistung und Ausfallsicherheit zu gewährleisten.
Bei der Verwendung der Fibre Channel-Schnittstelle ist eine Zonen-Einrichtungsanpassung erforderlich, um mögliche Kollisionen zwischen Initiatoren und Zielen zu vermeiden. Zonen werden nach dem Prinzip „ein Initiator-Port – ein oder mehrere Ports des Arrays“ aufgebaut.
Wenn eine Verbindung über iSCSI bei der Verwendung eines mit anderen Diensten geteilten Switches hergestellt wird, ist es unbedingt erforderlich, den iSCSI-Datenverkehr innerhalb eines separaten VLANs zu isolieren. Es wird auch dringend empfohlen, Jumbo Frames (MTU = 9000) zu aktivieren, um die Paketgrößen im Netzwerk zu erhöhen und somit den Anteil der Verwaltungsinformationen während der Übertragung zu verringern. Es ist jedoch zu beachten, dass für eine korrekte Funktion der MTU-Wert an allen Komponenten des Netzwerks in der Kette „Initiator-Switch-Target“ geändert werden muss.
Einrichtung eines All-Flash-Arrays
Das Array wird den Kunden bereits mit vorhandenen Gruppen geliefert . Daher sind keine Maßnahmen zur Zusammenführung der Speicher in eine einheitliche Struktur notwendig. Es genügt, Volumes in der gewünschten Größe und Anzahl zu erstellen.
Für den Komfort steht eine Funktion zum gleichzeitigen Erstellen mehrerer Volumes mit festgelegtem Speicherplatz zur Verfügung. Standardmäßig werden "dünne" Volumes erstellt, da dies eine effizientere Nutzung des verfügbaren Speicherplatzes ermöglicht (einschließlich der Unterstützung von Space Reclamation). Aus Leistungssicht beträgt der Unterschied zwischen "dünnen" und "dicken" Volumes nicht mehr als 1 %. Wenn jedoch die maximale Leistung des Arrays erforderlich ist, kann jedes "dünne" Volume jederzeit in ein "dickes" umgewandelt werden. Es ist jedoch zu beachten, dass dieser Vorgang irreversibel ist.
Anschließend bleibt es, die erstellten Volumes "zu veröffentlichen" und Zugriffsrechte über ACL (IP-Adressen für iSCSI und WWPN für FC) sowie physische Porttrennung des Arrays auf den Hosts festzulegen. Bei iSCSI-Modellen erfolgt dies durch die Erstellung eines Targets.
Bei FC-Modellen erfolgt die Veröffentlichung durch die Erstellung eines LUN für jeden Port des Arrays.
Um den Prozess der Host-Konfiguration zu beschleunigen, können Hosts in Gruppen zusammengefasst werden. Wenn auf dem Host ein Multi-Port FC HBA verwendet wird (was in der Praxis am häufigsten der Fall ist), erkennt das System automatisch, dass die Ports dieser HBA zu einem einzigen Host gehören, da sich die WWPN um eins unterscheiden. Für beide Schnittstellen wird zudem die Batch-Erstellung von Target/LUN unterstützt.
Ein wichtiges Detail beim Einsatz der iSCSI-Schnittstelle ist die gleichzeitige Erstellung mehrerer Targets für die Volumes zur Leistungssteigerung, da die Warteschlange auf dem Target nicht geändert werden kann und dieses faktisch zum Engpass wird.
Konfiguration der ESXi-Hosts
Von Seiten der ESXi-Hosts erfolgt die Grundkonfiguration nach einem in der Regel erwarteten Szenario. Der Ablauf für die iSCSI-Verbindung ist wie folgt:
- Software-iSCSI-Adapter hinzufügen (nicht erforderlich, wenn dieser bereits hinzugefügt wurde oder wenn ein Hardware-iSCSI-Adapter verwendet wird);
- Erstellung eines vSwitches, über den der iSCSI-Traffic geleitet wird, und Hinzufügen der physischen Uplinks und VMkernel;
- Hinzufügen der Adressen des Arrays zur dynamischen Entdeckung;
- Erstellung eines Datastores
Einige wichtige Hinweise:
- In der Regel können Sie auch einen vorhandenen vSwitch verwenden, aber bei einem separaten vSwitch wird die Verwaltung der Host-Einstellungen deutlich einfacher.
- Management-Verkehr und iSCSI sollten über separate physische Verbindungen und/oder VLANs getrennt werden, um Leistungsprobleme zu vermeiden.
- Die IP-Adressen der VMkernel und der entsprechenden Ports des All-Flash-Speichers müssen sich im selben Subnetz befinden, auch hier aus Leistungsgründen.
- Um die Ausfallsicherheit gemäß den VMware-Richtlinien zu gewährleisten, muss der vSwitch mindestens zwei physische Uplinks haben.
- Wenn Jumbo Frames verwendet werden, muss das MTU sowohl beim vSwitch als auch beim VMkernel angepasst werden.
- Es ist erwähnenswert, dass gemäß den VMware-Empfehlungen für physische Adapter, die für iSCSI-Verkehr verwendet werden, unbedingt eine Konfiguration für Teaming und Failover durchgeführt werden muss. Jeder VMkernel sollte dabei nur über einen Uplink betrieben werden, der zweite Uplink muss in den Status unused versetzt werden. Zur Gewährleistung der Ausfallsicherheit sollten zwei VMkernel hinzugefügt werden, die jeweils über ihren eigenen Uplink arbeiten.
VMkernel-Adapter (vmk#)
Physischer Netzwerkadapter (vmnic#)
vmk1 (Storage01)
Aktive Adapter
vmnic2
Nicht verwendete Adapter
vmnic3
vmk2 (Storage02)
Aktive Adapter
vmnic3
Nicht verwendete Adapter
vmnic2
Für die Verbindung über Fibre Channel sind keine vorherigen Maßnahmen erforderlich. Sie können sofort ein Datenspeicher erstellen.
Nach der Erstellung des Datenspeichers sollte sichergestellt werden, dass die Round Robin-Strategie für die Pfade zu Target/LUN verwendet wird, um die beste Leistung zu gewährleisten.
Standardmäßig sieht VMware vor, dass diese Strategie so funktioniert: 1000 Anfragen über den ersten Pfad, die nächsten 1000 Anfragen über den zweiten Pfad usw. Eine solche Interaktion des Hosts mit einem Dual-Controller-Array ist unausgeglichen. Daher empfehlen wir, die Round Robin-Policy über Esxcli/PowerCLI auf 1 zu setzen.
Einstellungen
Für Esxcli:
- Verfügbare LUNs auflisten
esxcli storage nmp device list
- Gerätenamen kopieren
- Round Robin-Policy ändern
esxcli storage nmp psp roundrobin deviceconfig set —type=iops —iops=1 —device="Device_ID"
Die meisten modernen Anwendungen sind so konzipiert, dass sie große Datenpakete austauschen, um die Bandbreitennutzung zu maximieren und die Belastung des CPUs zu reduzieren. Daher überträgt ESXi standardmäßig E/A-Anfragen in Blöcken von bis zu 32767 KB an das Speichergerät. Für einige Szenarien kann jedoch der Austausch kleinerer Blöcke effizienter sein. Bei AccelStor-Raids sind dies die folgenden Szenarien:
- Die virtuelle Maschine verwendet UEFI anstelle des Legacy BIOS
- vSphere Replication wird verwendet
Für solche Szenarien wird empfohlen, den Parameter Disk.DiskMaxIOSize auf 4096 zu ändern.
Für iSCSI-Verbindungen wird empfohlen, den Parameter Login Timeout auf 30 (standardmäßig 5) zu ändern, um die Verbindungsstabilität zu erhöhen, und die Verzögerung bei Bestätigungen übertragener Pakete (DelayedAck) zu deaktivieren. Beide Optionen finden Sie im vSphere Client: Host → Einrichten → Speicher → Speicheradapter → Erweiterte Optionen für den iSCSI-Adapter
Ein wichtiger Aspekt ist die Anzahl der verwendeten Volumes für den Datastore. Verständlicherweise besteht der Wunsch, zur Vereinfachung der Verwaltung ein großes Volume für das gesamte Array zu erstellen. Dennoch hat die Verwendung mehrerer Volumes und somit mehrere Datastores positive Auswirkungen auf die Gesamteffizienz (siehe die Details zu Warteschlangen weiter unten im Text). Daher empfehlen wir die Erstellung von mindestens zwei Volumes.
Bis vor kurzem riet VMware dazu, die Anzahl der virtuellen Maschinen auf einem Datastore zu begrenzen, um die bestmögliche Leistung zu erreichen. Heutzutage, insbesondere mit der Verbreitung von VDI, steht diese Problematik jedoch nicht mehr so stark im Vordergrund. Dies mindert jedoch nicht die alte Regel: Verteilen Sie virtuelle Maschinen mit intensivem IO auf verschiedene Datastores. Um die optimale Anzahl an virtuellen Maschinen pro Volume zu bestimmen, gibt es nichts Besseres als innerhalb Ihrer Infrastruktur.
Konfiguration der virtuellen Maschinen
Bei der Konfiguration der virtuellen Maschinen gibt es keine besonderen Anforderungen, vielmehr sind sie ganz gewöhnlich:
- Verwenden Sie die maximal mögliche VM-Version (Kompatibilität)
- Achten Sie darauf, die Größe des RAM bei einer dichten Platzierung von virtuellen Maschinen, zum Beispiel in VDI, präzise zu definieren (da standardmäßig beim Start eine Swap-Datei in der Größe des RAM erstellt wird, was den verfügbaren Speicherplatz beansprucht und die Gesamtleistung beeinträchtigt)
- Nutzen Sie die leistungsfähigsten Adapter in Bezug auf IO: Netzwerk vom Typ VMXNET 3 und SCSI vom Typ PVSCSI
- Verwenden Sie den Festplattentyp Thick Provision Eager Zeroed für maximale Leistung und Thin Provisioning für die effizienteste Nutzung des Speicherplatzes
- Sofern möglich, die Nutzung von nicht kritischen Maschinen durch den Virtual Disk Limit einschränken
- VMware Tools unbedingt installieren
Anmerkungen zu den Warteschlangen
Die Warteschlange (oder Outstanding I/Os) ist die Anzahl der Ein- / Ausgabever requests (SCSI-Befehle), die zu jedem Zeitpunkt auf die Verarbeitung durch ein bestimmtes Gerät / eine bestimmte Anwendung warten. Im Falle einer Überfüllung der Warteschlange tritt der Fehler QFULL auf, was schließlich zu einer Erhöhung des Parameters Latenz führt. Bei der Verwendung von Festplattensystemen kann theoretisch gesagt werden, dass je höher die Warteschlange, desto besser die Leistung ist. Dennoch sollte man dies nicht übertreiben, da es leicht zu einem QFULL-Fehler kommen kann. Bei All-Flash-Systemen ist es einerseits etwas einfacher: Das Array hat Latenzen, die um Größenordnungen niedriger sind, weshalb es häufig nicht erforderlich ist, die Größe der Warteschlangen separat zu regeln. Andererseits gibt es in bestimmten Nutzungsszenarien (starke Diskrepanz in den IO-Anforderungen für bestimmte virtuelle Maschinen, maximale Performance-Tests usw.) die Notwendigkeit, wenn nicht die Parameter der Warteschlangen zu ändern, dann zumindest zu verstehen, welche Werte erreicht werden können und, was am wichtigsten ist, auf welchen Wegen.
Auf dem reinen All-Flash-Array von AccelStor gibt es keine Begrenzungen hinsichtlich der Volumes oder I/O-Ports. Bei Bedarf kann sogar ein einzelnes Volume alle Ressourcen des Arrays nutzen. Das einzige Limit ist bei den iSCSI-Targets zu finden. Deshalb wurde empfohlen, mehrere (idealerweise bis zu 8) Targets pro Volume einzurichten, um dieses Limit zu umgehen. Außerdem möchten wir betonen, dass die AccelStor-Arrays sehr leistungsstark sind. Es ist daher ratsam, alle Interface-Ports des Systems zu nutzen, um die maximale Geschwindigkeit zu erreichen.
Die Situation auf der ESXi-Hostseite ist völlig anders. Der Host verwendet die Praxis des gleichberechtigten Zugriffs auf Ressourcen für alle Teilnehmer. Daher gibt es separate I/O-Queues für das Gastbetriebssystem und den HBA. Die Queues für das Gastbetriebssystem setzen sich aus den Queues des virtuellen SCSI-Adapters und der virtuellen Festplatte zusammen:
Die Queue zum HBA hängt vom spezifischen Typ/Vendor ab:
Die endgültige Leistung der virtuellen Maschine wird durch den geringsten Wert des Queue Depth Limits unter den Host-Komponenten bestimmt.
Diese Werte ermöglichen es, die Leistungskennzahlen zu bewerten, die wir in einer bestimmten Konfiguration erzielen können. Zum Beispiel möchten wir die theoretische Leistung einer virtuellen Maschine (unabhängig von der Einheit) mit einer Latenz von 0,5 ms erfahren. Dann beträgt ihre IOPS = (1.000 / Latenz) * Outstanding I/Os (Queue Depth Limit).
Beispiele
Beispiel 1
- FC Emulex HBA Adapter
- Eine VM auf dem Datenspeicher
- VMware Paravirtual SCSI Adapter
Hier wird das Queue Depth Limit vom Emulex HBA bestimmt. Daher beträgt IOPS = (1.000 / 0,5) * 32 = 64K.
Beispiel 2
- VMware iSCSI Software Adapter
- Eine VM auf dem Datenspeicher
- VMware Paravirtual SCSI Adapter
Hier wird das Queue Depth Limit bereits vom Paravirtual SCSI Adapter bestimmt. Daher beträgt IOPS = (1.000 / 0,5) * 64 = 128K.
Die Spitzenmodelle der All-Flash-Arrays von AccelStor (zum Beispiel ) sind in der Lage, eine Schreibleistung von 700K IOPS bei einer Blockgröße von 4K zu liefern. Bei dieser Blockgröße ist offensichtlich, dass eine einzige virtuelle Maschine ein solches Array nicht auslasten kann. Dafür sind 11 (zum Beispiel 1) oder 6 (zum Beispiel 2) VMs erforderlich.
Insgesamt können bei richtiger Konfiguration aller beschriebenen Komponenten des virtuellen Rechenzentrums beeindruckende Ergebnisse in Bezug auf die Leistung erzielt werden.
4K Random, 70% Lesen / 30% Schreiben
In der Tat ist die reale Welt viel komplexer, als sie durch eine einfache Formel beschrieben werden kann. Auf einem Host befinden sich immer zahlreiche virtuelle Maschinen mit unterschiedlichen Konfigurationen und Anforderungen an die E/A. Zudem verarbeitet der Host-Prozessor die Eingabe-/Ausgabe, dessen Leistung nicht unbegrenzt ist. Um das volle Potenzial des gleichen in der Praxis werden mindestens drei Hosts benötigt. Zudem bringen Anwendungen, die innerhalb der virtuellen Maschinen laufen, ihre eigenen Anforderungen mit sich. Daher empfehlen wir, für eine präzise Größenbestimmung von All Flash-Arrays innerhalb der Infrastruktur des Kunden anhand aktueller Aufgaben durchzuführen.
Quelle: habr.com
