Blogbeiträge verschiedener Anbieter zur Verwendung von iSCSI mit VMware vSphere

 

Bei dem folgenden Artikel handelt es sich um einen Blog zum Thema VMware. Die Beiträge von Mitarbeitern verschiedener Anbieter wurden von Eric Schott und seinem Team aus der Dell EqualLogic Technik- und Produktmanagement-Abteilung zusammengestellt.

 

Blogbeiträge verschiedener Anbieter zur Verwendung von iSCSI mit VMware vSphere
Einer unserer beliebtesten Beiträge war der ursprüngliche “Blog mit Beiträgen mehrerer Anbieter zur Unterstützung gemeinsamer iSCSI-Kunden bei der Verwendung von VMware”, der sich vor allem mit der Verwendung des iSCSI-Software-Initiators in ESX 3.5 mit mehreren iSCSI-Targets von verschiedenen Anbietern beschäftigte. Aufgrund unzähliger Nachfragen haben wir nun eine Fortsetzung erstellt, in der Mitarbeiter verschiedener Anbieter gemeinsam posten. Der Blog nutzt viele Inhalte der VMworld Sessions TA2467 und TA3264 von 2009. Die Blogbeiträge wurden von folgenden Autoren verfasst: Andy Banta (VMware), Chad Sakac (EMC), Vaughn Stewart (NetApp), Eric Schott (Dell™ EqualLogic™) und Adam Carter (HP/Lefthand Networks).

Ein wichtiger Hinweis vorab – Alle in diesem Blog erwähnten Befehle, Konfigurationen und Funktionen gelten sowohl für vSphere ESX als auch für ESXi (Wir haben uns vorgenommen, in diesem Punkt konsequent zu sein). Wir haben die Befehlszeilenformate für VMware vMA gewählt, die sowohl mit ESX als auch mit ESXi verwendet werden können. Alternative Befehlszeilen sind bei der Verwendung von Remote-CLI oder der Wartungskonsole möglich, aber wir benutzen hier einheitlich das vMA-Format.


Der Schwerpunkt dieses Blogs liegt auf Änderungen in vSphere ESX/ESXi 4 und der Konfiguration des iSCSI-Software-Initiators bei vSphere ESX/ESXi 4. Daneben wird eine große Bandbreite an verwandten Themen behandelt, wie zum Beispiel:

  • Multipathing mit NMP und der plug-fähigen Massenspeicherarchitektur
  • vmkNIC-/vSwitch-Setup
  • Subnetzkonfiguration
  • Jumbo Frames
  • Verzögerte Bestätigung (Delayed Ack)
  • Weitere Empfehlungen zur Konfiguration

Wenn das für Sie interessant klingt, oder wenn Sie iSCSI und vSphere 4 verwenden (oder mit dem Gedanken spielen, es einzuführen) – Lesen Sie weiter!

Erstes Thema: Grundlegende Änderungen beim iSCSI-Software-Initiator im Vergleich zu ESX 3.x

Der ESX iSCSI-Software-Initiator wurde für vSphere 4 von Grund auf neu geschrieben. Vorwiegend aus Leistungsgründen, aber auch weil die Kompatibilität mit Linux-Treibern vom 2.4- auf den 2.6-Kernel umgestellt wurde. Denken Sie daran, dass der VMkernel Linux nicht „ausführt“ oder auf „Linux ausgeführt wird“, sondern dass der Kerntreiber-Stack einige Elemente mit Linux teilt. Außerdem führt die Wartungskonsole eine Linux-Variante aus. Dies sind die beiden Hauptursachen für den Irrglauben, dass VMware auf Linux ausgeführt werde.

Nebenbei bemerkt besteht auch Interesse an der Entwicklung eines iSCSI-HBA-Treiberentwicklungskits, das es HBA-Anbietern ermöglichen würde, unabhängig von ESX-Versionen ihre eigenen Treiber zu schreiben und bereitzustellen. Die Änderungen könnten auch Massenspeicheranbietern die Möglichkeit bieten, Komponenten für die Verwaltung von Sitzungen zu schreiben und bereitzustellen, die die plug-fähige Multipathing-Funktion von ESX4 besser ausnutzen können. (Bis jetzt wurden weder das HBA-Treiberentwicklungskit noch die Funktion zur Sitzungsverwaltung herausgebracht. An der Entwicklung, Dokumentation und Zertifizierung wird noch gearbeitet.)

Einige der Vorzüge von ESXi 3.5 wurden auch in allen anderen ESX-Versionen übernommen:

 

·     Das iSCSI-Netzwerk benötigt keinen Konsolen-Port mehr. Alle iSCSI-Kontrollpfad-Vorgänge werden über denselben VMkernel-Port ausgeführt, der auch für den Datenpfad verwendet wird. Bei ESX 3.x war für iSCSI-Kontrollvorgänge noch ein Konsolen-Port erforderlich. Dies ist eine sehr positive Entwicklung: ESX 4 benötigt keinen Konsolen-Port mehr – und das gilt für alle Versionen.

· Durch das Aktivieren des iSCSI-Service werden automatisch alle nötigen Firewall-Eigenschaften konfiguriert.

Die Leistung wird in mehrerlei Hinsicht verbessert:

·         Die Speicherpfade sind effizienter und beschränken Kopier und andere Vorgänge, die die Leistung beeinträchtigen könnten, auf ein Minimum.

·         Systeme, die Intel Nehalem-Prozessoren verwenden, können Digest-Berechnungen an die im Prozessor integrierte CRC-Rechenengine weitergeben und werden so entlastet.

·         Der größte Fortschritt in Sachen Leistung ist jedoch, dass das Speichersystem sich an die Anzahl der verfügbaren NICs anpasst. Dahinter steht die Idee, dass das Speichersystem besser in der Lage ist, die verfügbaren Pfade auszunutzen, als die NIC-Zusammenfassung auf Netzwerkebene.

·         Wenn jede physische NIC des Systems wie ein Port für einen Dateipfad aussieht, können sie mit der Speicherpfad-Auswahlrichtlinie genutzt werden.

 

Zweites Thema: iSCSI-Multipathing

Dies ist die vielleicht wichtigste Änderung beim vSphere iSCSI-Stack.

iSCSI-Multipathing wird manchmal auch als „port binding“ bezeichnet. Diese Bezeichnung ist jedoch missverständlich und löst oft falsche Assoziationen an Link-Aggregation aus, sodass wir uns wohl einen besseren Namen überlegen sollten…

Standardmäßig ist iSCSI-Multipathing in vSphere 4 deaktiviert. Der ESX iSCSI-Initiator verwendet, ähnlich wie ESX 3.5, ein VMkernel-Netzwerk, ohne dass dafür umständliche Anpassungen notwendig wären. Der Initiator stellt einen einzigen Endpunkt dar, und durch NIC-Teaming wird über den ESX vSwitch die Auswahl der NIC geregelt. Daher ist es relativ unkompliziert, die 3.5-Version aufzurüsten und einfache iSCSI-Setups zu konfigurieren.

Die Einrichtung von iSCSI-Multipathing kostet etwas mehr Mühe, bedingt durch die zusätzliche Virtualisierungsebene, die der vSwitch liefert. Der vom iSCSI-Initiator verwendete ESX VMkernel-Netzwerk-Stack kommuniziert mit virtuellen NICs oder vmkNICs. Die vmkNICs sind an einen virtuellen Switch, oder vSwitch, angeschlossen, welcher wiederum an physische NICs angeschlossen ist.

Sobald iSCSI-Multipathing eingerichtet wurde, wird jedem Port des ESX-Systems eine eigene IP-Adresse zugewiesen, wobei aber alle Ports den gleichen iSCSI-Initiator-IQN-Namen tragen.

iSCSI-Multipathing einrichten – in vier einfachen Schritten:

1. Schritt: Mehrere vmkNICs konfigurieren

Zunächst einmal müssen Sie mehrere physische Ethernet-Schnittstellen und mehrere VMkernel-NIC- (vmkNICs)-Ports konfigurieren, wie im folgenden Screenshot gezeigt.




Dazu müssen Sie das Dialogfenster „Properties“ für einen vSwitch öffnen und dort „Add“ auswählen. Oder Sie klicken auf „Add Networking“ und fügen so weitere vmkNICs hinzu.

Alternativ können Sie auch die folgende Befehlszeile verwenden:

 

esxcfg-vmknic --server <servername> -a -i 10.11.246.51 -n 255.255.255.0


Hinweis: Einige vmkNIC-Parameter (wie z. B. die Jumbo-Frame-Konfiguration) können nur bei der Erstkonfiguration bestimmt werden. Um diese Parameter nach der Erstkonfiguration zu ändern, müssen Sie die entsprechende vmkNIC entfernen und neu hinzufügen. Weitere Informationen zum Jumbo-Frame-Beispiel finden Sie weiter unten in diesem Blog.

2. Schritt: Explizite vmkNIC-zu-vmkNIC-Bindung konfigurieren


Um sicherzugehen, dass die vom iSCSI-Initiator verwendeten vmkNICs auch tatsächliche Speicherpfade sind, muss die vmkNIC für die ESX-Konfiguration an eine Port-Gruppe angeschlossen werden, die nur über einen einzigen aktiven Uplink verfügt. Wenn dann der Uplink nicht verfügbar ist, befindet sich der Speicherpfad sozusagen außer Betrieb, sodass ein anderer Pfad ausgewählt wird. Um das einmal ganz deutlich zu sagen: Sie sollten bei iSCSI keine Link-Aggregationsverfahren einsetzen, sondern stets MPIO verwenden (denn so werden End-to-End-Pfade vom Initiator zum Target definiert). Das soll nicht bedeuten, dass Link-Aggregationsverfahren grundsätzlich schlecht sind (sie werden häufig bei der Verwendung von NFS-Datenspeichern benötigt) – aber was Multipathing betrifft, müssen Sie bedenken, dass bei Blockspeichermodellen MPIO im Speicher- (und nicht im Netzwerk-) Stack verwendet wird.

Die vmkNICs so zu konfigurieren, dass sie nur einen einzigen Uplink verwenden, kann über die Benutzeroberfläche erfolgen (siehe unten): Wählen Sie einfach den Adapter in der „Active“-Liste und verschieben Sie ihn nach unten zu „Unused Adapters“, sodass jeder für iSCSI verwendeten vmkNIC nur ein aktiver physischer Adapter zugeordnet wird.



Eine Anleitung dazu finden Sie in Kapitel 3 des iSCSI SAN Konfigurationshandbuchs iSCSI SAN Configuration Guide, (in der derzeit aktuellen Version auf S. 32).

3. Schritt: Den iSCSI-Initiator so konfigurieren, dass er mehrere vmkNICs verwendet

Nun ist die Konfiguration der entsprechenden Befehlszeilen erforderlich. In diesem Schritt müssen Sie die vmkNICs dem ESX iSCSI-Initiator zuweisen. Sobald die vmkNICs zugewiesen wurden, verwendet der iSCSI-Initiator als ausgehende Ports diese festgelegten vmkNICs anstatt der VMkernel-Routingtabelle. Rufen Sie die Liste der für iSCSI verwendeten vmkNICs ab (im unten abgebildeten Screenshot wurde dies mithilfe des Befehls vicfg-vmknic --server <servername> –l getan):



Danach muss der iSCSI-Software-Initiator explizit dazu aufgefordert werden, alle entsprechenden vmkNICs für iSCSI zu verwenden. Dies erreichen Sie mit folgendem Befehl:

esxcli --server <servername> swiscsi nic add -n <VMkernelportname> -d <vmhbaname>


Um den vmhba-Namen herauszufinden, navigieren Sie im vSphere Client zur Registerkarte „Configuration“, und wählen Sie dort „Storage Adapters“. Ihr Bildschirm sieht dann etwa so wie im unten abgebildeten Screenshot aus. In diesem Beispiel lautet der vmhba-Name „vmhba38“, und die zwei Geräte haben vier Pfade.



Am Ende dieser Konfiguration sollten mehrere Pfade zum Speicher bereitstehen. Wie viele Pfade das sind, hängt von Ihrem konkreten iSCSI-Target, bzw. vom Typ des Speicheranbieters, ab. Der iSCSI-Initiator meldet sich bei den Targets an, die ihm der Befehl „Send Targets“ vorgibt. Dieser Befehl wird an das iSCSI-Target ausgegeben, welches im Dialogfenster „Dynamic Discovery“ zu jeder iSCSI-vmkNIC aufgeführt ist.

Bevor wir fortfahren, erklären wir hier kurz das Speicherkonzept eines Storage-Portals für alle, die nicht mit iSCSI vertraut sind. Grob gesagt besteht ein iSCSI-Portal aus Portnummer und IP-Adresse(n) eines SCSI-Speicher-Targets. Die Implementierung von Storage-Portalen kann von Anbieter zu Anbieter leicht unterschiedlich erfolgen.

In der Speicher-Nomenklatur wird der „Runtime Name“ von Geräten in folgendem Format wiedergegeben: vmhba#:C#:T#:L#. Dabei steht C für Controller, T für das SCSI-Target und L für die LUN.

Bei Massenspeichern mit einem zentralen Portal, wie z. B. bei EqualLogic- oder LeftHand-Systemen, gibt es so viele Pfade zum Speicher wie vmkNICs für die iSCSI-Verwendung konfiguriert sind (das Maximum für ESX liegt bei 8 pro LUN/Volume).

Diese Speichersysteme haben nur einen zentralen Speicher-Port, auch wenn Verbindungen zu anderen Ports weitergeleitet werden. ESX stellt also einen Pfad von jedem Server-Verbindungspunkt (den vmkNICs) zum zentralen Speicher-Port her.

 



Eine Variante der Speichersysteme mit zentralem Portal ist ein EMC Celerra iSCSI-Target. Im Fall der EMC Celerra kann eine große Anzahl von iSCSI-Targets konfiguriert werden, aber eine LUN steht hinter einem einzigen Target. Außerdem werden bei der Celerra, anders als bei EqualLogic oder LeftHand, keine Verbindungen weitergeleitet. Für die EMC Celerra muss ein iSCSI-Target-Netzwerkportal mit mehreren IP-Adressen konfiguriert werden. Dazu müssen Sie einfach einem einzelnen iSCSI-Target mehrere logische (oder physische) Schnittstellen zuweisen. ESX stellt einen Pfad von jeder Server-Verbindung (den vmkNICs) zu allen IP-Adressen des Netzwerkportals her.

Andere Speichersysteme haben mehrere Ports für den Speicher, entweder mit getrennten Target-IQN-Namen oder mit unterschiedlichen Target-Portal-Gruppen-Tags (also Informationen, die während der ersten Erkennung vom Speicher an den Server zurückgeleitet werden). Bei solchen Speichersystemen mit mehreren Ports, wie z. B. die EMC CLARiiON, die NetApp FAS oder die IBM N-Serie, können Pfade zwischen jeder Server-NIC und jedem Storage-Portal hergestellt werden. Wenn in Ihrem Speichersystem also drei vmkNICs für iSCSI verwendet werden, und das System über zwei Portale verfügt, dann werden insgesamt sechs Pfade erstellt.



Diese Unterschiede an sich sollten nicht als besser oder schlechter betrachtet werden (zumindest nicht im Rahmen dieses Blogs, an dem mehrere Anbieter zusammenarbeiten – überlassen wir die Bewertung lieber den jeweiligen Verkaufsteams). Bei jedem Array funktioniert iSCSI ein bisschen anders.

Bei Speichersystemen mit mehreren Ports sind einige Einschränkungen zu berücksichtigen. So erlaubt zum Beispiel die EMC CLARiiON derzeit von jedem Initiator-IQN aus nur eine einzige Anmeldung an jedem Portal. Da alle Initiator-Ports denselben IQN haben, verweigert dieses System die zweite Anmeldung. (Protokollmeldungen dazu finden Sie über die Ursache für fehlgeschlagene Anmeldeversuche 0x03 0x02, „Out of Resources“.) Sie können das Problem umgehen, indem Sie die hier beschriebene Subnetzkonfiguration verwenden. Details zur iSCSI-Target-Konfiguration und Multipathing mit der CLARiiON liefert das EMC Storage Viewer Plug-in für vCenter.

Standardmäßig stellen alle Speicher-Arrays von NetApp, einschließlich der IBM N-Serie, ein iSCSI-Portal für jede IP-Adresse des Controllers bereit. Diese Einstellung kann geändert werden, indem Zugriffslisten erstellt und/oder der iSCSI-Zugriff auf physische Ethernet-Ports deaktiviert wird. Eine automatisierte Konfiguration der Einstellungen kann mithilfe des NetApp Rapid Cloning Utility auch vom vCenter aus erfolgen.

Beachten Sie, dass iSCSI-Multipathing mit virtuellen verteilten Switches bisher nicht unterstützt wird (Das gilt sowohl für das VMware-Angebot als auch für Cisco Nexus 1000V). An der Behebung dieses Problems wird zurzeit gearbeitet, damit in Zukunft alle virtuellen Switches unterstützt werden.

4. Schritt: Multipathing über die plug-fähige Massenspeicherarchitektur aktivieren

Blockspeicher-Multipathing wird vom MPIO-Bestandteil des Speicher-Stacks geregelt und wählt Pfade (für Leistungs- und Verfügbarkeitszwecke) basierend auf einem End-to-End-Pfad.



Diese Ebene liegt ÜBER dem SCSI-Bestandteil des Speicher-Stacks (der wiederum über iSCSI liegt; und iSCSI liegt über dem Netzwerk-Stack). Stellen Sie sich den SCSI-Initiator-Port als die „Auffahrt“ zu einem Pfad vor. Im spezifischen Fall von iSCSI basiert diese auf der iSCSI-Sitzung –und nach Schritt 3 haben Sie mehrere iSCSI-Sitzungen. Wenn es also mehrere iSCSI-Sitzungen zu einem einzelnen Target gibt (und damit zu allen LUNs, die hinter dem Target stehen), gibt es auch mehrere Ports, in denen MPIO seine Aufgabe erfüllen kann.


Der nächste Schritt ist ähnlich für iSCSI, FC und FCoE.


Was die Pfadauswahl, Bandbreiten-Aggregation und Link-Flexibilität in vSphere angeht, so stehen Kunden mehrere Optionen offen: Sie können wahlweise die Native Multipathing (NMP)-Pfadauswahlrichtlinien (PSPs) von VMware, PSPs von Drittanbietern oder Multipathing-Plug-ins (MPPs) von Drittanbietern, wie z. B. PowerPath V/E von EMC, verwenden.


Die in diesem Blog vertretenen Anbieter unterstützen ausnahmslos alle zu vSphere gehörigen NMP-PSPs, weshalb wir uns hier nicht mit den Pros und Contras für/gegen PSPs und MPPs von Drittanbietern beschäftigen, und für unsere Zwecke die Verwendung von NMP annehmen.

 

NMP ist in allen vSphere-Versionen ohne Aufpreis enthalten und wird von zwei „plug-fähigen Modulen“ unterstützt. Das SpeicherArrayTyp-Plug-in (SATP) identifiziert das Speicher-Array und weist ausgehend von den Empfehlungen des Speicherherstellers das entsprechende Pfadauswahl-Plug-in zu (PSP).

VMware wird mit systemeigenen SATPs und 3 PSPs geliefert: Festgelegt (Fixed), Zuletzt verwendet (Most Recently Used, MRU) und Round Robin (RR). Fixed- und MRU-Optionen waren bereits bei VI3.x verfügbar und dürften unseren Lesern bekannt sein. Round Robin wurde testweise bei VI3.5 eingeführt und wird von allen vSphere-Versionen serienmäßig unterstützt.

NMP so zu konfigurieren, dass eine spezifische PSP (wie etwa Round Robin) verwendet wird, ist einfach: Dazu müssen Sie lediglich im vSphere Client zur Registerkarte „Configuration“ navigieren und dort unter „Storage Adapter“ die entsprechenden Geräte auswählen. Rechtsklicken Sie, um die „Properties“ aufzurufen. Daraufhin wird folgendes Dialogfenster angezeigt (Beachten Sie, dass standardmäßig immer Fixed oder MRU als PSP festgelegt sind. Bei diesen Richtlinien können – abhängig vom Array-Typ – mehrere Pfade aktiven oder Standby-Status haben, aber nur einer wird als „Active (I/O)“ angezeigt):



In diesem Dialogfenster können Sie in der Dropdown-Liste ein anderes Pfadauswahl-Plug-in auswählen. Wenn dazu die GUI verwendet wird, muss dies für jedes Gerät und auf jedem vSphere-Server manuell geschehen. Es ist wichtig, dass Sie bei allen Hosts im Cluster einheitlich vorgehen. Sie sollten außerdem daran denken, dass Änderungen an den Einstellungen wirksam werden, sobald Sie in der Liste ein anderes Plug-in auswählen, und nicht erst, wenn Sie das Dialogfenster schließen.

Sie können die PSP für alle Geräte auch mit diesem Befehl konfigurieren:

 

esxcli -–server <servername> nmp device setpolicy --device <device UID> --psp <PSP type


Alternativ kann vSphere ESX/ESXi 4 auch so konfiguriert werden, dass automatisch Round Robin für jedes Gerät ausgewählt wird, das von einem bestimmten SATP erkannt wird. Um für alle neuen Geräte, die ein bestimmtes SATP verwenden, automatisch Round Robin einzustellen, konfigurieren Sie ESX/ESXi über die Befehlszeile so, dass Round Robin als Standard-Pfadauswahlrichtlinie festgelegt wird.

esxcli --server <servername> corestorage claiming unclaim --type location
esxcli --server <servername> nmp satp setdefaultpsp --satp <SATP type> --psp VMW_PSP_RR
esxcli --server <servername> corestorage claimrule load
esxcli --server <servername> corestorage claimrule run


Drei weitere Fragen und Antworten zur Round-Robin-PSP…

1. Frage:
„Unter welchen Umständen sollte ich Round Robin nicht verwenden?“


Antwort: Während Sie die Schnittstelle konfigurieren, fällt Ihnen vielleicht auf, dass Fixed und MRU stets als Standard-PSPs für die nativen SATP-Optionen festgelegt sind – bei allen Arrays. Dies ist eine Schutzmaßnahme für den Fall, dass Sie Microsoft Cluster Services (MSCS) auf VMs ausführen. Round Robin kann zu Konflikten mit Anwendungen führen, die SCSI-Reservierungen für die gemeinsame Nutzung von LUNs durch mehrere VMs verwenden. Daher wird Round Robin nicht unterstützt, wenn LUNs mit MSCS verwendet werden. Ansonsten spricht nichts gegen die Verwendung von NMP-Round-Robin, abgesehen von der zusätzlichen Ausnahme, die unten genannt wird (Ihr iSCSI-Array erfordert ALUA, und aus irgendeinem Grund können Sie das nicht ändern).


2. Frage: „Wenn ich ein Aktiv/Passiv-Array verwende – muss ich ALUA verwenden?“

Antwort: Ein weiterer Umstand ist zu bedenken, wenn Sie iSCSI mit einem Array verwenden, das ein „Aktiv/Passiv“-LUN-Besitzmodell nutzt. Wenn das Speicher-Target nicht richtig konfiguriert ist, kann Round Robin bei diesen Arrays zu „path thrashing“ führen (Das heißt, es kommt zu Race-Bedingungen, in denen ein Speicher-Target in einer Art Wettrennen mit vSphere hinter Speicherprozessoren springt).
Von den hier beteiligten Anbietern werden EMC CLARiiON und NetApp häufig mit „Aktiv/Passiv“-LUN-Besitzmodellen in Verbindung gebracht. Tatsächlich aber verhält sich ein NetApp-iSCSI-Target in dieser Beziehung eher wie ein EMC Celerra-iSCSI-Target und ist „Aktiv/Aktiv“ (Das heißt, wenn der Cluster selbst ausfällt, übernimmt das gesamte „Gehirn“, anstatt dass die LUN von einem „Gehirn“ zum nächsten weitergegeben wird. „Gehirn“ heißt bei der Celerra „Datamover“ und bei NetApp „Cluster Controller“).

Bei der CLARiiON hingegen funktioniert die iSCSI-Target-LUN ebenso wie die FC-Target-LUN und wird von einem Speicherprozessor an den nächsten weitergegeben. Die ALUA-Konfiguration ist also wichtig bei der CLARiiON für iSCSI-Hosts und Hosts, die über Fibre Channel/FCoE angeschlossen sind, und wichtig bei NetApp, wenn Fibre-Channel-/FCoE-Konnektivität verwendet wird (Details dazu würden allerdings den Rahmen dieses Blogs sprengen). Sie können also zur 3. Frage zum Thema Round Robin springen, wenn Sie weder CLARiiON iSCSI nutzen, noch die CLARiiON oder NetApp mit Fibre Channel/FCoE verwenden (da sich dieser Abschnitt zu Multipathing auf FC/FCoE bezieht).

Im VMware-Jargon bedeutet „Aktiv/Passiv“-LUN-Besitzmodell nicht, dass ein Speicherprozessor (oder „Gehirn“ des Arrays) sich im Leerlauf befindet, sondern vielmehr, dass sich eine LUN in jedem beliebigen Moment „im Besitz“ eines der beiden Speicherprozessoren befindet (also quasi „hinter“ dem Prozessor steht). Wenn Sie die EMC CLARiiON CX4 (oder ein NetApp-Array mit Fibre Channel) in Verbindung mit vSphere verwenden, sollten die LUNs für Asymmetric Logical Unit Access (ALUA) konfiguriert werden. Wenn ALUA konfiguriert ist, werden sie als „active“ angezeigt – im Gegensatz zu den Ports des „nicht besitzenden“ Speicherprozessors, die im vSphere Client als „standby“ angezeigt werden. Nun werden diese Ports normalerweise nicht für E/A verwendet, da es sich bei den Ports des „nicht besitzenden“ Speicherprozessors um „nicht optimierte“ Pfade handelt (Diese Ports stellen langsamere, umständlichere E/A-Pfade dar). Dies verdeutlicht folgendes Diagramm:



Auf jeder Plattform erfordert die Konfiguration von ALUA spezielle Bedingungen.

Auf einem EMC CLARiiON-Array, das in Verbindung mit vSphere verwendet wird (welches ALUA speziell mit SCSI-3-Befehlen, nicht mit SCSI-2, unterstützt), muss die neueste FLARE 28-Version ausgeführt werden (04.28.000.5.704 oder höher). Damit kommt derzeit nur CX4 in Frage, nicht CX3 und nicht AX. Wenn die Vorbedingung erfüllt ist, starten Sie den Failover-Assistenten und konfigurieren Sie die Hosts im vSphere-Cluster so, dass der Failover-Modus 4 verwendet wird (ALUA-Modus). Dieses Thema wird auch im CLARiiON/VMware Applied Technology Guide (der CLARiiON/vSphere-Bibel) behandelt, und außerdem in diesem Blog besprochen.

3. Frage: „Ich habe Round Robin konfiguriert, aber die Pfade werden nicht gleichmäßig ausgelastet.“

Antwort:
Anders als viele glauben, werden E/As von der Round-Robin-Richtlinie nicht einfach als Ringverteilung zwischen Pfaden ausgegeben. Standardmäßig sendet die Round-Robin-PSP 1.000 Befehle über einen Pfad, bevor zum nächsten Pfad gewechselt wird. Das nennt sich EA-Vorgangsbegrenzung. In einigen Konfigurationen entsteht durch diese Standardeinstellung keine Aggregation, da häufig einige der tausend Befehle bereits ausgeführt sind, ehe der letzte Befehl gesendet wird. Das bedeutet, dass ein Pfad nicht völlig ausgelastet wird (auch wenn möglicherweise die Warteschlange im Speicher-Array voll belegt ist). Bei der Verwendung von 1-Gbit-iSCSI wird der Datendurchsatz häufig durch den physischen Pfad beschränkt. Daher führt die Nutzung mehrerer Pfade gleichzeitig zu höheren Datendurchsätzen.


Die Anzahl der Befehle, die über einen konkreten Pfad ausgegeben werden, bevor zum nächsten Pfad gewechselt wird, können Sie bis auf 1 Befehl reduzieren, sodass alle aufeinanderfolgenden Befehle über unterschiedliche Pfade gesendet werden. Für Dell EqualLogic empfiehlt Eric 3 aufeinanderfolgende Befehle pro Pfad.

Diese Einstellung können Sie mithilfe des folgenden Befehls übernehmen:

esxcli --server <servername> nmp roundrobin setconfig --device <lun ID> --iops <IOOperationLimit_value> --type iops


Dabei ist zu beachten, dass eine Reduzierung der IOPS einige potenzielle Probleme mit sich bringt. Bei einigen Arrays erfolgt die Zwischenspeicherung für jeden Pfad gesondert. Indem Anfragen über mehrere Pfade verteilt werden, kann im Speicher keine Caching-Optimierung stattfinden, was zu schlechterer Leistung führen könnte. Glücklicherweise führen die meisten modernen Speichersysteme die Zwischenspeicherung nicht für jeden Port gesondert durch. Trotzdem ergeben sich in ESX durch häufiges Wechseln des Pfads leichte Nachteile, wie ein wahrscheinlich etwas höherer CPU-Overhead beim Host.

Das war’s schon!

Wenn Sie diese Schritte durchgehen, sieht Ihr Bildschirm ungefähr so aus wie unten gezeigt. Round Robin ist als Pfadauswahlrichtlinie festgelegt, und die beiden Pfade zur LUN werden als „Active (I/O)“ angezeigt. Bei einer für AULA-konfigurierten CLARiiON werden die Pfade zu den Ports des „nicht-besitzenden“ Speicherprozessors als „Active“ angezeigt. Das bedeutet, dass sie aktiv sind, aber nicht für E/A verwendet werden.



Die Datenübertragung findet also über mehrere vmkNICs statt (Auf der vSphere Client-Registerkarte „Performance“ werden mehrere vmkNICs angezeigt. Ein Blick auf die Leistungskennzahlen des Arrays verrät auch, dass die Datenübertragung über mehrere Target-Ports läuft).

Im Anschluss folgen noch ein paar weitere wichtige Anmerkungen, die Sie unbedingt lesen sollten:-)

Drittes Thema: Routing-Setup

Bei iSCSI-Multipathing mit MPIO wird die VMkernel-Routingtabelle bei der Bestimmung des von ESX verwendeten ausgehenden Ports umgangen. Deshalb ist laut offiziellen VMware-Angaben Routing mit iSCSI-SANs, die iSCSI-Multipathing verwenden, nicht möglich. Darüber hinaus ist es generell eine schlechte Idee, iSCSI-Datenverkehr über ein Gateway zu routen – Das würde nur zu unnötiger Latenz führen. Die folgenden Ausführungen sind also rein akademischer Natur. Darin sind wir uns alle einig – Routen Sie keine iSCSI-Datenübertragungen.

Aber der Vollständigkeit halber sei gesagt, dass Routing in vSphere minimal unterstützt wird, weil bei der Wahl der vmkNIC zum Senden der Daten eine Route-Suche durchgeführt wird. Wenn sich das iSCSI-Speichernetzwerk in einem anderen Subnetz befindet UND die iSCSI-Multipathing-vmkNICs sich im selben Subnetz befinden wie das Gateway zu diesem Netzwerk, dann funktioniert Routing zum Speicher. Sehen Sie sich zum Beispiel diese Konfiguration an:

Auf dem vSphere ESX/ESXi-Server:

vmk0 10.0.0.3/24 General purpose vmkNIC

vmk1 10.1.0.14/24 iSCSI vmkNIC

vmk2 10.1.0.15/24 iSCSI vmkNIC

Standard-Route: 10.0.0.1

Auf dem iSCSI-Array:

iSCSI Storage port 1: 10.2.0.8/24

iSCSI Storage port 2: 10.2.0.9/24


In diesem Beispiel kommunizieren vmk1 und vmk2 nicht mit den beiden Speicher-Ports, weil der Zugriff auf die einzige Route zum Speicher über vmk0 führt, die nicht für die iSCSI-Verwendung eingerichtet ist. Wenn Sie die folgende Route hinzufügen:

Ziel: 10.2.0.0/24 Gateway: 10.1.0.1 (und wenn sich ein Router an der Gateway-Adresse befindet)

dann können vmk1 und vmk2 mit dem Speicher kommunizieren, ohne das weitere VMkernel-Routing zu beeinträchtigen.


Viertes Thema: vSwitch-Setup
Es gibt keine Best Practices bezüglich der Frage, ob bei iSCSI-Multipathing die vmkNICs auf demselben oder auf verschiedenen vSwitches liegen sollten. Vorausgesetzt die vmkNIC verfügt über einen einzigen aktiven Uplink, dann spielt es keine Rolle, ob sich noch weitere iSCSI-vmkNICs auf demselben Switch befinden oder nicht.

Die günstigste vSwitch-Konfiguration hängt von der restlichen Systemkonfiguration ab. Wenn es sich bei einem System zum Beispiel um ein Blade mit nur zwei NICs handelt, die den gesamten iSCSI- sowie den herkömmlichen Datenverkehr teilen, dann ist es am sinnvollsten, wenn sich beide Uplinks auf demselben vSwitch befinden (um die Teaming-Richtlinie für den allgemeinen, nicht-iSCSI-Datenverkehr zu regeln). Bei anderen Konfigurationen sind gesonderte vSwitches möglicherweise günstiger.

Grundsätzlich funktionieren beide Konfigurationen.

Viertes Thema: Jumbo Frames
Jumbo Frames werden für iSCSI in vSphere 4 unterstützt. Es gab einige Verwirrung bezüglich der Frage, ob sie mit ESX 3.5 unterstützt werden – die Antwort lautet Nein, sie werden für VMkernel-Datenverkehr nicht unterstützt (wohl aber für Datenübertragungen zwischen virtuellen Rechnern).

Das Konzept „Jumbo Frames“ bedeutet einfach, dass der größte zwischen zwei Hosts des Ethernet-Netzwerks übertragene Ethernet-Frame größer ist als der Standard. Standardmäßig liegt die maximale Übertragungseinheit (MTU) für Ethernet bei 1500 Byte. Jumbo Frames sind oft 9000 Byte groß, denn dort liegt das verfügbare Maximum für viele Ethernet-Komponenten.

Dahinter steht die Idee, dass größere Frames weniger Overhead im Netz bedeuten und an beiden Enden weniger Arbeitsaufwand erfordern, um die Ethernet-Frames zu zerlegen und wieder zu den von iSCSI-verwendeten TCP/IP-Paketen zusammenzusetzen. Die jüngsten Ethernet-Verbesserungen, TSO (TCP Segment Offload) und LRO (Large Receive Offload), sorgen zwar dafür, dass CPU-Zyklen von Hosts nicht mehr so dringend gespeichert werden müssen, doch Jumbo Frames werden häufig trotzdem verwendet, um jeden möglichen Vorteil auch voll auszuschöpfen.

Jumbo Frames müssen end-to-end konfiguriert werden, um wirklich sinnvoll zu sein. Das bedeutet, dass Jumbo Frames von Speicher, Ethernet-Switches, Router und Host-NIC unterstützt werden müssen – und dass Jumbo Frames im Netzwerk korrekt end-to-end konfiguriert sein müssen. Wenn dabei auch nur eine einzige Ethernet-Komponente übersehen wird, kommt es zu einer erheblichen Anzahl an Ethernet-Layer-Fehlern (bei denen es sich im Wesentlichen um fragmentierte Ethernet-Frames handelt, die nicht korrekt wieder zusammengesetzt wurden).

In ESX müssen Jumbo Frames auf den physischen NICs, auf dem vSwitch und auf den iSCSI-vmkNICs konfiguriert werden. Die physischen Uplinks und vSwitch werden durch MTO-Konfigurierung am vSwitch eingerichtet. Sobald die Einrichtung erfolgt ist, werden alle physischen NICs, die Jumbo Frames unterstützen, ebenfalls konfiguriert. Bei iSCSI müssen auch die vmkNICs für Jumbo Frames konfiguriert werden.

Damit sie Jumbo Frames unterstützen, müssen vSwitch und vmkNICs leider mithilfe der unten stehenden Befehlszeile hinzugefügt (oder, wenn sie bereits vorhanden sind, entfernt und neu erstellt) werden. Dabei werden alle aktiven iSCSI-Verbindungen getrennt, weshalb der Vorgang als Wartungsmaßnahme durchgeführt werden sollte, während die in Datenspeichern/RDMs befindlichen VMs auf anderen ESX-Hosts ausgeführt werden. (Ich weiß, das klingt ziemlich offensichtlich, ist aber eine gut gemeinte Warnung.)

Nachfolgend ein Beispiel:

# esxcfg-vmknic --server <servername> -l|cut -c 1-161
Interface Port Group/DVPort IP Family IP Address Netmask Broadcast MAC Address MTU TSO MSS Enabled Type
vmk1 iSCSI2 IPv4 10.11.246.51 255.255.255.0 10.11.246.255 00:50:56:7b:00:08 1500 65535 true STAT
vmk0 iSCSI1 IPv4 10.11.246.50 255.255.255.0 10.11.246.255 00:50:56:7c:11:fd 9000 65535 true STAT
# esxcfg-vmknic --server <servername> -d iSCSI2
# esxcfg-vmknic --server <servername> -a -i 10.11.246.51 -n 255.255.255.0 -m 9000 iSCSI2
# esxcfg-vmknic --server <servername> -l|cut -c 1-161
Interface Port Group/DVPort IP Family IP Address Netmask Broadcast MAC Address MTU TSO MSS Enabled Type
vmk0 iSCSI1 IPv4 10.11.246.50 255.255.255.0 10.11.246.255 00:50:56:7c:11:fd 9000 65535 true STAT
vmk1 iSCSI2 IPv4 10.11.246.51 255.255.255.0 10.11.246.255 00:50:56:7b:00:08 9000 65535 true STAT

Wenn die vmkNICs bereits als iSCSI-Multipathing-vmkNICs eingerichtet sind, müssen Sie sie aus der iSCSI-Konfiguration entfernen, bevor Sie sie mit der geänderten MTU erneut hinzufügen.


Fünftes Thema: Verzögerte Bestätigung (Delayed ACK)

Dabei handelt es sich um eine TCP/IP-Methode zur Reduzierung von E/A-Overhead, die es Segmentbestätigungen ermöglicht, sich an andere Segmentbestätigungen oder an andere Daten anzuhängen, die über eine Verbindung gesendet werden.




Wenn Ihr Speichersystem verzögerte Bestätigung unterstützt, sollten Sie Ihren Anbieter fragen, ob es ratsam ist, diese zu aktivieren.

Sechstes Thema: Weitere Empfehlungen zur Konfiguration

Die meisten allgemeinen Empfehlungen im ursprünglichen iSCSI-Blog sind weiterhin gültig. Wenn Sie ein Ethernet-Netzwerk für die Verwendung von iSCSI (oder NFS-Datenspeichern) einrichten, gehen Sie nicht mit der Einstellung „Das ist ja nur in meinem LAN“ heran, sondern denken Sie besser: „Dies ist die Speicherinfrastruktur, die meine gesamte wichtige VMware-Infrastruktur trägt.“ IP-basierter Speicher erfordert dieselbe Denkweise, die üblicherweise auf FC-Infrastruktur angewandt wurde – und wenn mit Sie diese Haltung einnehmen, kann IP-basierter Speicher eine ebenso hohe Verfügbarkeit erreichen wie herkömmliche FC-SANs. Hier sind einige Punkte, über die Sie nachdenken sollten:

Laufen Ihr Speicher- und Netzwerk-Datenverkehr auf verschiedenen Ports? Könnten Sie dafür VLANs verwenden? Sicher. Aber ist das die Einstellung, mit der Sie Ihr Unternehmen erfolgreich machen? Diese Haltung ist vertretbar, wenn Sie einen Blade und eine beschränkte Anzahl an Schnittstellen mit hoher Bandbreite verwenden, aber überlegen Sie mal... Möchten Sie, dass ein vorübergehend ausgelastetes LAN Ihren Speicher überschwemmt (und umgekehrt), nur wegen ein paar NICs und Switch-Ports? Also, wenn Sie VLANs verwenden, seien Sie gründlich und implementieren Sie QoS-Mechanismen. Wenn Sie 10GbE verwenden, können VLANs vielleicht sinnvoll sein, um Netzwerkschnittstellen, Kabel und Ports zu sparen – aber das macht keinen wirklich großen Unterschied.

Denken Sie an die Flusskontrolle – Die sollte so eingestellt werden, dass Sie Daten von Switches empfängt und an iSCSI-Targets weitergibt.

Entweder Sie deaktivieren das Spanning Tree Protocol (nur bei den einfachsten iSCSI-Netzwerken) oder Sie aktivieren es, wobei Sie sich zwischen RSTP oder Portfast entscheiden müssen. Wenn Sie die Netzwerk-Switches mit dem LAN teilen, können Sie dies auch durch das Filtern oder Beschränken von Bridge-Protokoll-Dateneinheiten auf Speichernetzwerk-Ports erreichen.

Wenn möglich, verwenden Sie Cat6a-Kabel anstatt von Cat5e (Cat5 sollten Sie nicht verwenden). Ja, es funktioniert auch mit Cat5e – aber denken Sie daran, Sie wollen doch Ihr Unternehmen erfolgreich machen, oder? Sind Sie sicher, dass Sie nicht doch das etwas teurere Kabel kaufen wollen?

Verfahren wie Cross-Stack EtherChannel-Trunking kann für einige Konfigurationen nützlich sein, in denen iSCSI in Verbindung mit NFS verwendet wird (weitere Informationen zu Blogs mit Beiträgen verschiedener Anbieter zum Thema NFS finden Sie hier).

Ethernet-Switches unterscheiden sich auch im Hinblick auf die interne Architektur – für netzwerkintensive Ethernet-Zwecke, die für Ihr Geschäft wesentlich sind (wie VMware-Datenspeicher in iSCSI oder NFS), Port-Puffer und andere interne Angelegenheiten ist es auf jeden Fall von Vorteil, wenn Sie wissen, was Sie verwenden.


Zum Abschluss…

Wir raten jedem, der die Verwendung von iSCSI mit vSphere in Betracht zieht, sich zunächst davon zu überzeugen, dass das vorhandene System hohe Leistung und Verfügbarkeit bereitstellen kann. Viele, viele Kunden haben bereits positive Erfahrungen mit den Vorteilen für Ethernet gemacht, die VMware und der erweiterte Speicher erbringen.

Der neue iSCSI-Initiator, das Ermöglichen mehrerer TCP-Sitzungen pro Target und die Multipathing-Funktion in vSphere ESX 4 bieten Speichersysteme mit hoher Verfügbarkeit und hoher Leistung, die bereits vorhandene Ethernet-Infrastruktur ausnutzen. Die im Vorgänger-Blog besprochenen provisorischen Lösungen, die für ESX 3.5 nötig waren, gehören nun der Vergangenheit an.

Damit die Implementierung gelingt, sollten Sie die in diesem Blog besprochenen Themen verstehen, und vor allem den Best Practices Ihres Speicheranbieters und der VMware folgen.

VMware: iSCSI SAN Configuration Guide

Dell EqualLogic: Tech Report - Configuring VMware vSphere Software iSCSI with Dell EqualLogic PS Series Storage (TR1049)

http://www.equallogic.com/resourcecenter/assetview.aspx?id=8453

EMC CLARiiON: VMware Applied Technology Guide

http://www.emc.com/collateral/hardware/white-papers/h1416-emc-clariion-intgtn-vmware-wp.pdf

Symmetrix: VMware Applied Technology Guide

http://www.emc.com/collateral/hardware/white-papers/h6531-using-vmware-vsphere-with-emc-symmetrix-wp.pdf

Celerra: VMware Applied Technology Guide

http://www.emc.com/collateral/hardware/white-papers/h6337-introduction-using-celerra-vmware-vsphere-wp.pdf

vSphere on NetApp – Storage Best Practices TR-3749 http://www.netapp.com/us/library/technical-reports/tr-3749.html