Dies ist ein Post aus der Reihe “Teach the Expert” (TTE).
Wenn Ihr nach einer einfachen Möglichkeit sucht, die iSCSI-Kernelport-Konfiguration auf dem VMware ESXi-Host zu bearbeiten, ist PowerCLI die ideale Lösung. In diesem Beitrag erfahrt Ihr, wie Ihr PowerCLI zur Konfiguration des iSCSI-Kernelports verwendet und wie Ihr den iSCSI-Kernelport aktiviert oder deaktiviert. Wir werden auch einige Beispiele für die Verwendung von PowerCLI zur Konfiguration von iSCSI-Kernelport-Einstellungen geben. Also, fangen wir an!
Die Herausforderung
Um die Verwaltung von iSCSI mit PowerCLI Verbindungen besser verstehen zu können, verwenden wir ein fiktives Szenario:
- Die Hosts eines Clusters haben redundante Kernelports vmk2 und vmk3 zur Anbindung eines iSCSI basierten Storage Arrays.
- Portbindung ist aktiviert.
- Die MTU ist systemweit auf 9000 konfiguriert.
- Auf einigen Hosts soll nun die IP-Adresse und das Subnetz der Kernelports verändert werden und der Kernelport in eine andere Distributed Portgroup mit anderem VLAN umziehen.
- Die neue Distributed Portgroup existiert bereits und das VLAN ist konfiguriert.
- Der Prozess soll ohne Downtime durchgeführt werden.
- Das Storage Array akzeptiert Verbindungen aus dem neuen Subnetz und das Target Portal ist konfiguriert.
Vorbereitungen und Vorrausetzungen
Zunächst müssen wir sicherstellen, dass die alte iSCSI-Verbindung redundant ist. Wir werden einen der beiden Pfade auflösen und neu anlegen. In der Zwischenzeit darf die Verbindung zur LUN nicht abreißen.
Check der iSCSI-Verbindung
Wir prüfen die iSCSI-Verbindung mit netcat. Die Target IP in unserem Beispiel ist die 10.0.200.12. Das Kommando netcat kann mit nc abgekürzt werden. Der Parameter -z führt einen Portscan auf die Zieladresse anstatt Daten zu senden. Die Portnummer für iSCSI Verbindungen ist standardmäßig 3260.
nc -z 10.0.200.12 3260
Bei erfolgreicher Kontaktaufnahme erscheint die Meldung:
Connection to 10.0.200.12 3260 port [tcp/*] succeeded!
Alternativ kann mittels netcat auch die Quelladresse festgelegt werden. Der Parameter -s (source) definiert den Quellport.
nc -s 10.0.200.101 -z 10.0.200.12 3260
Test der korrekten MTU
Jumboframes mit einer Maximum Transmission Unit (MTU) von 9000 Byte sind immer wieder eine beliebte Fehlerquelle. Daher lohnt sich eine kurze Prüfung. Zu diesem Zweck senden wir ein entsprechend großes PING Paket zur Zieladresse und legen fest, dass dieses nicht fragmentiert werden darf. Es muss also in einem Stück durch die Leitung passen. Der Parameter -d bedeutet ‘don’t fragment’.
Die Größe des Pings Pakets legen wir mit dem Parameter -s (size) fest. Um eine MTU von 9000 Byte zu prüfen, senden wir ein Paket der Größe 8972 Byte. Der Grund, warum wir keine 9000 Byte senden liegt darin, dass unter Linux/Unix Systemen die ping Implementierung einen 28 Byte Overhead hat (8 Byte ICMP Header + 20 Byte IP-Header). D.h. unsere Paketgröße darf nur 8972 Byte groß sein. 28 Byte Overhead kommen oben drauf und damit sind die 9000 Byte voll.
Wir senden zunächst einen ping von Kernelport vmk2 und danach von vmk3, welche in unserem Beispiel die beinen iSCSI-Kernelports sind. Mit dem -I Parameter wählen wir das Quellinterface vmk2 bzw. vmk3 aus.
vmkping -s 8972 -d -I vmk2 10.0.200.12
vmkping -s 8972 -d -I vmk3 10.0.200.12
Gehen die pings verlustfrei durch, so ist die MTU 9000 auf dem gesamten Pfad von der Quelle zum Ziel korrekt konfiguriert.
Ersten Kernelport umziehen
Wir haben im letzten Abschnitt gesehen, dass unsere iSCSI-Verbindung redundant und funktional ist. Wir können nun einen der beiden Kernelports abbauen und neu erstellen.
Zunächst müssen wir in PowerCLI eine Verbindung zu vCenter herstellen.
Connect-VIServer vc.lab.local
Im Windows Anmeldefenster geben wir User und Passwort ein und authentifizieren uns an der PowerCLI gegenüber vCenter.
Port Binding entfernen
Bevor wir einen Kernelport entfernen können, müssen wir das Port-Binding auflösen. Wir können dies entweder direkt auf der esxcli machen, oder die esxcli über PowerCLI ansprechen.
esxcli
Unten sehen wir das Kommando, wie es auf der ESXCLI aussehen würde.
esxcli iscsi networkportal remove -A vmhba64 -f $true -n vmk2
Das ist natürlich ein Bruch im Workflow. Unser Ziel ist es innerhalb der PowerCLI zu bleiben und dort Kommandos als Skripte auszuführen.
PowerCLI
Hierfür müssen wir die esxcli in PowerCLI einbinden.
$esxcli = Get-EsxCli -VMhost esx1.lab.local -V2
Die Variable $esxcli können wir ab jetzt in PowerCLI verwenden. Wir benötigen einige Parameter, die wir mit der Invoke() Methode übergeben müssen.
$host = esx1.lab.local
$hba = $host | Get-VMHostHba -Type IScsi
$kernelport = vmk2
$binding = @{adapter=$hba; force=$true; nic=$kernelport}
In der Variable $hba steht dann z.B. vmhba64 oder vmhba65 (Software-iSCSI Adapter).
$esxcli.iscsi.networkportal.remove.Invoke($binding)
Kernelport entfernen
Nachdem das Port Binding aufgelöst wurde, kann nun der Kernelport vom Host entfernt werden.
Get-VMHost -Name $host | Get-VMHostNetworkAdapter -VMKernel -Name $kernelport | Remove-VMHostNetworkAdapter -Confirm:$false
Kernelport neu erzeugen
Zur Erzeugung eines Kernelports auf der PowerCLI benötigen wir weitere Parameter. In unserem Beispiel soll der Name des vSwitches DSwitch-IP-Storage sein und der Name der Portgruppe für iSCSI Verbindung 1 den Namen dvPG-iSCSI1 haben.
$vSwitch = DSwitch-IP-Storage
$pg = dvPG-iSCSI1
$kportip = 10.0.5.21
New-VMHostNetworkAdapter -VMHost $host -PortGroup $pg -VirtualSwitch $vSwitch -IP $kportip -SubnetMask "255.255.255.0" -Mtu 9000 -Confirm:$false
Portbinding festlegen
Für den neuen iSCSI Kernelport soll wieder eine Portbinding konfiguriert werden. Auch hier brauchen wir wieder die esxcli in PowerCLI und eine Liste an Parametern.
$host = esx1.lab.local
$hba = $host | Get-VMHostHba -Type IScsi
$kernelport = vmk2
$binding = @{adapter=$hba; force=$true; nic=$kernelport}
$esxcli = Get-EsxCli -V2 -VMHost $host
$esxcli.iscsi.networkportal.add.Invoke($binding)
Abschließend sollte noch ein rescan aller HBA erfolgen. In einen Script sollten wir dem System etwas Zeit geben, bevor wir einen Rescan auf den HBA auslösen. Ansonsten könnte es unnötigerweise zu Fehlermeldungen kommen.
Start-Sleep -Seconds 3
Get-VMHost -name $host | Get-VMHostStorage -RescanAllHba
Zweiten Kernelport umziehen
Die Prozedur ist nahezu identisch mit dem Umzug des ersten Kernelports. es muss lediglich vmk2 durch vmk3 ersetzt und die Kernelport IP adressen angepasst werden.
Tipps
Ich habe die Befehle hier schrittweise zur direkten Ausführung auf der CLI entwickelt. Natürlich wäre das für mehrere Hosts zu mühsam und fehleranfällig. Idealerweise übergibt man Parameter wie Hostname, Kernelport, Kernelport-IP und den Namen der Portgruppe mit einer CSV Datei, die vom Skript eingelesen wird.
Zuerst wird das Skript zur Löschung des ersten Kernelports ausgeführt. Wir übergeben ihm eine CSV Datei mit allen Hosts und deren erstem Kernelport. Die CSV-Datei könnte beispielsweise so aussehen:
host;kernelport;portip;pg
10.1.10.101;vmk2;192.168.1.11;dvPG-iSCSI1
10.1.10.102;vmk2;192.168.1.12;dvPG-iSCSI1
10.1.10.103;vmk2;192.168.1.13;dvPG-iSCSI1
10.1.10.104;vmk2;192.168.1.14;dvPG-iSCSI1Die Parameter Kernelport-IP und Portgruppe sind für den Löschvorgang nicht notwendig. Ich habe die CSV für die Löschung und Erzeugung dennoch bewusst im selben Format gehalten. Das macht die Bearbeitung einfacher und die CSV können durch Kopieren erzeugt werden.
Anschliessend wird das Skript zur Erzeugung des neuen iSCSI Kernelports ausgeführt und eine CSV mit neuen Port-Daten übergeben.
host;kernelport;portip;pg
10.1.10.101;vmk2;10.0.5.21;dvPG-iSCSI1
10.1.10.102;vmk2;10.0.5.22;dvPG-iSCSI1
10.1.10.103;vmk2;10.0.5.23;dvPG-iSCSI1
10.1.10.104;vmk2;10.0.5.24;dvPG-iSCSI1
Damit wäre ein Kernelport ausgetauscht und die Prozedur kann mit dem zweiten Kernelport fortgesetzt werden. Auch hier gibt es diskrete CSV Dateien für die Entfernung des vmk3 und Neuerstellung des vmk3.