Im Rahmen dieses Artikels möchten wir die Besonderheiten der Arbeit mit den All Flash Arrays von AccelStor auf einer der beliebtesten Virtualisierungsplattformen – VMware vSphere – erläutern. Insbesondere möchten wir auf diejenigen Parameter eingehen, die dazu beitragen, maximale Effizienz bei der Nutzung eines so leistungsstarken Werkzeugs wie All Flash zu erzielen.
Die All Flash Arrays von AccelStor NeoSapphire™ sind oder Node-basiertes Gerät auf Basis von SSD-Laufwerken mit einem grundlegend anderen Ansatz zur Umsetzung des Konzepts der Datenspeicherung und -zugriffsorganisation unter Verwendung einer eigenen Technologie anstatt der weit verbreiteten RAID-Algorithmen. Die Arrays bieten Blockzugriff für Hosts über Fibre Channel- oder iSCSI-Schnittstellen. Der Vollständigkeit halber sei erwähnt, dass die Modelle mit iSCSI-Schnittstelle auch Datei-zugriff als angenehmen Bonus haben. Doch in diesem Artikel konzentrieren wir uns auf die Verwendung von Blockprotokollen als die leistungsfähigsten für All Flash.
Der gesamte Prozess der Bereitstellung und anschließenden Konfiguration der Zusammenarbeit des AccelStor Arrays und des Virtualisierungssystems VMware vSphere kann in mehrere Phasen unterteilt werden:
- Implementierung der Verbindungstopologie und Einrichtung des SAN-Netzwerks;
- Konfiguration des All Flash Arrays;
- Konfiguration der ESXi-Hosts;
- Konfiguration der virtuellen Maschinen.
Als Hardwarebeispiele wurden die AccelStor NeoSapphire™ Arrays mit Fibre Channel- und iSCSI-Schnittstellen verwendet. Als grundlegende Software – VMware vSphere 6.7U1.
Vor der Bereitstellung der in diesem Artikel beschriebenen Systeme wird dringend empfohlen, die Dokumentation von VMware zu den Themen Leistung ( ) und iSCSI-Einstellungen ()
Verbindungstopologie und Einrichtung des SAN-Netzwerks
Die Hauptkomponenten des SAN-Netzwerks sind HBA-Adapter in den ESXi-Hosts, SAN-Switches und die Array-Nodes. Eine typische Topologie eines solchen Netzwerks würde so aussehen:
Unter dem Begriff Switch versteht man sowohl einen einzelnen physischen Switch oder eine Gruppe von Switches (Fabric) als auch ein zwischen verschiedenen Diensten geteiltes Gerät (VSAN bei Fibre Channel und VLAN bei iSCSI). Die Verwendung von zwei unabhängigen Switches/Fabrics ermöglicht es, einen möglichen Ausfallpunkt auszuschließen.
Der direkte Anschluss von Hosts an das Array wird zwar unterstützt, ist jedoch keinesfalls empfehlenswert. Die Leistung von All-Flash-Arrays ist ausreichend hoch, und für maximale Geschwindigkeit müssen alle Ports des Arrays genutzt werden. Daher ist das Vorhandensein mindestens eines Switches zwischen den Hosts und NeoSapphire™ unerlässlich.
Das Vorhandensein von zwei Ports am HBA-Host ist ebenfalls eine zwingende Anforderung, um maximale Leistung zu erreichen und Ausfallsicherheit zu gewährleisten.
Im Falle der Nutzung der Fibre-Channel-Schnittstelle ist eine Zonen-Einrichtung erforderlich, um mögliche Kollisionen zwischen Initiatoren und Zielen auszuschließen. Zonen werden nach dem Prinzip „ein Port des Initiators – ein oder mehrere Ports des Arrays“ aufgebaut.
Wenn eine Verbindung über iSCSI genutzt wird und ein Switch gemeinsam mit anderen Diensten verwendet wird, muss der iSCSI-Verkehr unbedingt innerhalb eines separaten VLAN isoliert werden. Es wird auch dringend empfohlen, Jumbo Frames (MTU = 9000) zu aktivieren, um die Paketgrößen im Netzwerk zu erhöhen und damit die Menge an Steuerinformationen bei der Übertragung zu reduzieren. Es ist jedoch zu beachten, dass für eine korrekte Funktion der MTU-Parameter in allen Komponenten der Netzwerkkette „Initiator-Switch-Ziel“ geändert werden muss.
Einrichtung des All-Flash-Arrays
Das Array wird den Kunden bereits mit vordefinierten Gruppen geliefert. . Daher sind keine Maßnahmen zur Zusammenführung von Speichermedien in eine einheitliche Struktur erforderlich. Es genügt, Volumes der gewünschten Größe und Anzahl zu erstellen.
Zu Ihrer Bequemlichkeit gibt es die Funktion zur zeitgleichen Erstellung mehrerer Volumes mit einem festgelegten Volumen. 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). Was die Leistung betrifft, so beträgt der Unterschied zwischen „dünnen“ und „dicken“ Volumes nicht mehr als 1 %. Wenn jedoch die volle Leistung des Arrays ausgeschöpft werden muss, kann jedes „dünne“ Volume jederzeit in ein „dickes“ Volume konvertiert werden. Es ist jedoch zu beachten, dass dieser Vorgang unwiderruflich ist.
Als Nächstes bleiben die erstellten Volumes zur Veröffentlichung und die Festlegung der Zugriffsberechtigungen seitens der Hosts mithilfe von ACL (IP-Adressen für iSCSI und WWPN für FC) sowie physischer Trennung über die Anschlüsse des Arrays. Für iSCSI-Modelle erfolgt dies durch die Erstellung von Zielen.
Bei FC-Modellen erfolgt die Veröffentlichung durch die Erstellung von LUNs für jeden Anschluss des Arrays.
Um den Einrichtungsprozess zu beschleunigen, können Hosts in Gruppen zusammengelegt werden. Wenn auf dem Host ein Multiport-FC-HBA verwendet wird (was in der Praxis am häufigsten vorkommt), erkennt das System automatisch, dass die Anschlüsse eines solchen HBAs zu einem einzigen Host gehören, da sich die WWPN um eins unterscheiden. Außerdem wird das batchweise Erstellen von Ziel-/LUN-Paaren für beide Schnittstellen unterstützt.
Ein wichtiger Hinweis bei Verwendung der iSCSI-Schnittstelle ist die Erstellung mehrerer Ziele für die Volumes zur Leistungssteigerung, da die Warteschlange am Ziel nicht geändert werden kann und es somit zu einem Engpass wird.
ESXi-Hosts einrichten
Von den ESXi-Hosts aus wird die Grundkonfiguration nach einem durchaus erwartbaren Szenario durchgeführt. Die Schritte für die iSCSI-Verbindung lauten:
- Hinzufügen eines Software-iSCSI-Adapters (nicht erforderlich, wenn er bereits hinzugefügt wurde oder wenn ein Hardware-iSCSI-Adapter verwendet wird);
- Erstellung eines vSwitch, über den der iSCSI-Verkehr läuft, und Hinzufügen physischer Uplinks und VMkernels;
- Hinzufügen der Adressen des Arrays zur dynamischen Entdeckung;
- Erstellung von Datastores
Einige wichtige Hinweise:
- In der Regel kann auch ein vorhandener vSwitch verwendet werden, aber bei einem separaten vSwitch wird die Verwaltung der Hostkonfigurationen deutlich einfacher.
- Es ist notwendig, den Verwaltungstraffic und iSCSI über separate physische Verbindungen und/oder VLANs zu trennen, um Leistungsprobleme zu vermeiden.
- Die IP-Adressen des VMkernels und der entsprechenden Anschlüsse des All-Flash-Arrays müssen sich aus Gründen der Leistung im selben Subnetz befinden.
- Für die Gewährleistung der Ausfallsicherheit gemäß VMware-Richtlinien sollte der vSwitch mindestens zwei physische Uplinks besitzen.
- Wenn Jumbo Frames verwendet werden, muss die MTU sowohl für den vSwitch als auch für den VMkernel geändert werden.
- Es wäre nicht überflüssig, daran zu erinnern, dass laut den VMware-Empfehlungen für physische Adapter, die für den Umgang mit iSCSI-Verkehr verwendet werden, unbedingt die Konfiguration von Teaming und Failover durchgeführt werden muss. Insbesondere sollte jeder VMkernal nur über einen Uplink arbeiten, der zweite Uplink muss in den Modus unused versetzt werden. Für die Ausfallsicherheit sollten zwei VMkernals hinzugefügt werden, die jeweils über ihren eigenen Uplink arbeiten.
VMkernel Adapter (vmk#)
Physischer Netzwerkadapter (vmnic#)
vmk1 (Storage01)
Aktive Adapter
vmnic2
Unbenutzte Adapter
vmnic3
vmk2 (Storage02)
Aktive Adapter
vmnic3
Unbenutzte Adapter
vmnic2
Für die Verbindung über Fibre Channel sind keine Vorbereitungen erforderlich. Man kann sofort ein Datastore erstellen.
Nach der Erstellung des Datastore ist sicherzustellen, dass die Round Robin-Politik für die Pfade zu Target/LUN als die leistungsfähigste verwendet wird.
Standardmäßig sieht die Konfiguration von VMware die Verwendung dieser Politik im Schema vor: 1000 Anfragen über den ersten Pfad, die nächsten 1000 Anfragen über den zweiten Pfad usw. Diese Interaktion des Hosts mit einem Dual-Controller-Speichersystem wäre unausgewogen. Daher empfehlen wir, den Parameter Round Robin policy = 1 über Esxcli/PowerCLI festzulegen.
Parameter
Für Esxcli:
- Verfügbare LUNs auflisten
esxcli storage nmp device list
- Gerätenamen kopieren
- Round Robin-Politik ändern
esxcli storage nmp psp roundrobin deviceconfig set —type=iops —iops=1 —device=«Device_ID»
Die meisten modernen Anwendungen sind für den Austausch von großen Datenpaketen konzipiert, um die Bandbreitenauslastung zu maximieren und die Belastung der CPU zu verringern. Daher überträgt ESXi standardmäßig Eingabe-/Ausgabe-Anfragen an das Speichergerät in Portionen von bis zu 32767 KB. Für bestimmte Szenarien kann jedoch der Austausch von kleineren Portionen effizienter sein. Für AccelStor-Speichersysteme gelten folgende Szenarien:
- Die virtuelle Maschine verwendet UEFI anstelle von Legacy-BIOS.
- Es wird vSphere Replication 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 Stabilität der Verbindung zu erhöhen und die Bestätigungsverzögerung der übertragenen Pakete DelayedAck zu deaktivieren. Beide Optionen befinden sich im vSphere Client: Host → Konfigurieren → Speicher → Speicheradapter → Erweiterte Optionen für den iSCSI-Adapter.
Ein wichtiges Thema ist die Anzahl der verwendeten Volumes für das Datenspeicher. Es ist verständlich, dass man zur Vereinfachung des Managements den Wunsch hat, ein großes Volume für das gesamte Array zu erstellen. Allerdings hat die Verwendung mehrerer Volumes und damit zusammenhängend Datenspeichers positive Auswirkungen auf die Gesamtleistung (mehr über Warteschlangen weiter unten im Text). Daher empfehlen wir die Erstellung von mindestens zwei Volumes.
Noch vor relativ kurzer Zeit empfahl VMware, die Anzahl der virtuellen Maschinen auf einem Datenspeicher zu begrenzen, um die bestmögliche Leistung zu erzielen. Mittlerweile ist dieses Problem jedoch, insbesondere mit der Verbreitung von VDI, nicht mehr so akut. Das kann jedoch das alte Prinzip nicht aufheben — verteilen Sie virtuelle Maschinen, die intensives IO erfordern, auf verschiedene Datenspeicher. Um die optimale Anzahl an virtuellen Maschinen pro Volume zu bestimmen, gibt es nichts Besseres, als im Rahmen Ihrer Infrastruktur.
Konfiguration von virtuellen Maschinen
Bei der Konfiguration von virtuellen Maschinen gibt es keine besonderen Anforderungen, oder besser gesagt, sie sind recht gewöhnlich:
- Verwendung der maximal möglichen VM-Version (Kompatibilität)
- Seien Sie vorsichtig bei der Angabe der RAM-Größe, wenn viele virtuelle Maschinen eng platziert sind, z. B. in VDI (da standardmäßig beim Start eine Swap-Datei in der Größe des RAM erstellt wird, was nützlichen Speicherplatz verbraucht und die endgültige Leistung beeinträchtigt)
- Verwenden Sie die leistungsfähigsten IO-fähigen Adapterversionen: Netzwerktyp VMXNET 3 und SCSI-Typ PVSCSI
- Verwenden Sie den Festplattentyp Thick Provision Eager Zeroed für maximale Leistung und Thin Provisioning für eine möglichst effiziente Nutzung des Speicherplatzes
- Wo immer möglich, die Arbeit von nicht kritisch IO-intensiven Maschinen mit Hilfe von Virtual Disk Limit einschränken
- VMware Tools unbedingt installieren
Hinweise zu Warteschlangen
Die Warteschlange (oder Outstanding I/Os) ist die Anzahl der Eingabe-/Ausgabeverrequests (SCSI-Befehle), die zu jedem Zeitpunkt bei einem bestimmten Gerät oder einer bestimmten Anwendung auf die Verarbeitung warten. Bei einer Überfüllung der Warteschlange wird der Fehler QFULL ausgegeben, was sich schließlich in einer Erhöhung des Latenzparameters äußert. Bei der Verwendung von Festplattensystemen (Spindelspeicher) gilt theoretisch: je höher die Warteschlange, desto höher ihre Leistung. Es ist jedoch Vorsicht geboten, da man leicht auf QFULL stoßen kann. Im Fall von All-Flash-Systemen ist die Situation etwas einfacher: Der Speicher hat Latenzen, die in der Regel um Größenordnungen geringer sind, und daher ist es meistens nicht erforderlich, die Größe der Warteschlangen separat zu regulieren. Andererseits ist es jedoch in bestimmten Nutzungsszenarien (starke Abweichung in den IO-Anforderungen für bestimmte virtuelle Maschinen, Tests zur maximalen Leistung usw.) erforderlich, wenn nicht die Parameter der Warteschlangen zu ändern, so doch wenigstens zu verstehen, welche Leistungswerte erreicht werden können und, was am wichtigsten ist, auf welche Weise.
Auf dem All-Flash-Speicher von AccelStor gibt es keine Limits hinsichtlich der Volumes oder der Eingabe-/Ausgabe-Ports. Bei Bedarf kann sogar ein einziges Volume alle Ressourcen des Arrays nutzen. Die einzige Einschränkung bei den Warteschlangen gibt es bei den iSCSI-Targets. Aus diesem Grund wurde oben die Notwendigkeit erwähnt, mehrere (idealerweise bis zu 8) Targets pro Volume zu erstellen, um dieses Limit zu überwinden. Darüber hinaus wiederholen wir, dass die Arrays von AccelStor sehr leistungsfähige Lösungen sind. Daher sollten alle Schnittstellenports des Systems genutzt werden, um die maximale Geschwindigkeit zu erreichen.
Auf der Seite des ESXi-Hosts ist die Situation ganz anders. Der Host wendet die Praxis des gleichberechtigten Zugriffs auf Ressourcen für alle Teilnehmer an. Daher gibt es separate IO-Warteschlangen für das Gastbetriebssystem und das HBA. Die Warteschlangen für das Gastbetriebssystem setzen sich aus den Warteschlangen für den virtuellen SCSI-Adapter und die virtuelle Festplatte zusammen:
Die Warteschlange zum HBA hängt von dem spezifischen Typ/Anbieter ab:
Die endgültige Leistung der virtuellen Maschine wird durch den kleinsten Wert des Warteschlangenlimits (Queue Depth Limit) unter den Hostkomponenten bestimmt.
Mit diesen Werten können die Leistungskennzahlen bewertet werden, die wir in einer bestimmten Konfiguration erhalten können. Zum Beispiel möchten wir die theoretische Leistung einer virtuellen Maschine (ohne Blockbindung) mit einer Latenz von 0,5 ms erfahren. Dann ist ihre IOPS = (1.000 / Latenz) * Outstanding I/Os (Queue Depth Limit)
Beispiele
Beispiel 1
- FC Emulex HBA-Adapter
- Eine VM im Datenspeicher
- VMware Paravirtual SCSI-Adapter
Hier wird der Queue Depth Limit durch Emulex HBA definiert. Daher ist IOPS = (1000 / 0,5) * 32 = 64K
Beispiel 2
- VMware iSCSI Software-Adapter
- Eine VM im Datenspeicher
- VMware Paravirtual SCSI-Adapter
Hier wird der Queue Depth Limit bereits durch den Paravirtual SCSI-Adapter definiert. Daher ist IOPS = (1000 / 0,5) * 64 = 128K
Die Top-Modelle der All-Flash-Speicher von AccelStor (zum Beispiel, ) sind in der Lage, eine Leistung von 700K IOPS beim Schreiben mit einer Blockgröße von 4K zu liefern. Bei dieser Blockgröße ist offensichtlich, dass eine einzelne virtuelle Maschine einen solchen Speicher nicht vollständig auslasten kann. Dazu sind 11 (zum Beispiel 1) oder 6 (zum Beispiel 2) VMs erforderlich.
Letztendlich können bei richtiger Konfiguration aller beschriebenen Komponenten des virtuellen Rechenzentrums durchaus beeindruckende Ergebnisse hinsichtlich der Leistung erzielt werden.
4K Random, 70% Lesen / 30% Schreiben
In der Realität ist die Welt viel komplexer, um sie mit einer einfachen Formel zu beschreiben. Auf einem Host sind immer mehrere virtuelle Maschinen mit unterschiedlichen Konfigurationen und IO-Anforderungen untergebracht. Auch der Host-Prozessor, der sich um die Eingabe/Ausgabe kümmert, hat eine begrenzte Leistung. Um das volle Potenzial des gleichen in der Realität auszuschöpfen, werden mindestens drei Hosts benötigt. Zudem bringen die innerhalb der virtuellen Maschinen laufenden Anwendungen ihre eigenen Anforderungen mit sich. Daher empfehlen wir für eine genaue Dimensionierung, von All-Flash-Speichern innerhalb der Infrastruktur des Kunden bei tatsächlichen aktuellen Aufgaben.
Quelle: habr.com
