Erstellung zusätzliche VMkernel Portgruppe (iSCSI) inkl. Route - Carsten Schäfer

Aus Thomas-Krenn-Wiki
Zur Navigation springen Zur Suche springen
Hinweis: Bitte beachten Sie, dass dieser Artikel / diese Kategorie sich entweder auf ältere Software/Hardware Komponenten bezieht oder aus sonstigen Gründen nicht mehr gewartet wird.
Diese Seite wird nicht mehr aktualisiert und ist rein zu Referenzzwecken noch hier im Archiv abrufbar.

Die Erstellung eines virtuellen Switches zur Verwendung als Software iSCSI-Initiator erfolgt über den gleichen Weg wie die Erstellung eines vSwitches für VMs. Lediglich ein anderer Connection Type wird zu Beginn des Wizards gewählt: VMkernel.

Bestätigen Sie die Auswahl mit Next:


VMware-iscsi1.jpg


Nachfolgend wählen Sie aus, dass ein neuer virtueller Switch erstellt werden soll und ordnen Sie die benötigten Netzwerkkarten diesem hinzu.

Bestätigen Sie die Auswahl mit Next:


VMware-iscsi2.jpg


Geben Sie nachfolgend einen Namen für die neu erstellte Port Group an und definieren Sie ggf. eine VLAN ID. Des Weiteren geben Sie eine IP-Adresse und eine Subnet Mask für diesen Switch an, also für diesen iSCSI-Initiator.

Bestätigen Sie diese Einstellungen mit Next:


VMware-iscsi3.jpg


Abschließend wird eine Zusammenfassung der gewählten Einstellungen angezeigt.

Starten Sie die Erstellung mit Klick auf Finish:


VMware-iscsi4.jpg


Da die Service Console (vLAN_149) in einem anderen Subnetz als die iSCSI-Targets (vLAN_150) ist, und zwischen beiden Netzen die Firewalls bzgl. iSCSI-Traffic geschlossen sind, muss die Service Console um eine weitere IP-Adresse im LAN der iSCSI-Targets erweitert werden.


Wählen Sie hierzu bei dem soeben erstellten vSwitch für iSCSI den Button Properties und im nachfolgenden Fenster den Button „Add“ um den Wizard wieder zu starten.

Diesmal verwenden Sie als Connection Type die Einstellung Service Console und klicken Sie auf Next:


VMware-iscsi5.jpg


Tragen Sie den Namen Service Console 4 iSCSI für die neue Port Group ein und legen die IP-Adresse sowie die Subnet-Maske für die zweite Netzwerkkarte der Service Console fest. Klicken Sie auf Next und bestätigen Sie auf dem nächsten Step des Wizards die Änderungen mit Finish:


VMware-iscsi6.jpg


Dieser Zustand bewirkt, dass die iSCSI-Management-Kommunikation über die weitere Netzwerkverbindung der Service Console erfolgen kann. Der reine iSCSI-Payload-Datenverkehr läuft über den dedizierten VMKernel Port iSCSI. Beide Portgroups greifen auf die gleichen physikalischen Netzwerkadapter (vmnic2 und vmnic11) zu. Damit die Service Console, die ja initial im vLAN_149 verankert ist, auch das Netz der iSCSI-Targets finden kann, muss eine Route hinzugefügt werden.

Diese Route weist die Service Console an mit den iSCSI-Targets im Netzwerk 10.11.152.0 (255.255.252.0) über den neuen Service Console-Port (Portgroup) Service Console 4 iSCSI mit der IP-Adresse 10.48.150.164 des neuen Adapters vswif1 zu kommunizieren.

Dabei wird als Gateway-Adresse nicht die IP-Adresse des vswif1-Adapters angegeben, sondern die IP-Adresse des Routers im vLAN_150 10.48.150.4:

route add –net 10.11.152.0 netmask 255.255.252.0 gw 10.48.150.4

Diese Route gilt jedoch nur zur Laufzeit des Servers; nach einen Reboot ist die Route nicht mehr vorhanden. Aus diesem Grunde muss die Route in den Start-Scripten des ESX-Servers verankert werden.

Ein Runlevel-Script muss verschiedene Eigenschaften ausweisen damit es als Runlevel-Script verwendet werden kann resp. vom Tool chkconfig in die Runlevels eingebungen werden kann. Diese Eigenschaften können Sie dem unteren Code entnehmen.

Ein wesentlicher Punkt ist, wann dieses Runlevel-Scripts ausgeführt wird. Zum einen muss das Script im Runlevel 3 ausgeführt werden da erst in diesem Level die Netzwerkverbindungen hergestellt sind. Des Weiteren muss der passende Punkt innerhalb des Runlevels gefunden werden. Hier sollte die Position 30 angegeben werden welcher kurz nach dem initialisieren des Netzwerks liegt und weit vor dem Starten weiterer Netzwerkdienste wie snmpd oder ntpd. Dieses wird mit folgender Codezeile im Script definiert:

#chkconfig 3 30 70

Die erste Zahl 3 gibt den Runlevel an, die zweite Zahl die Position zum starten (startorder) in der Startup-Sequence und die dritte Zahl die Stopposition in der shutdown-Sequence (stoporder). Dabei sollte die Regel stoporder = 100 – startorder beachtet werden. Das Runlevel-Script zum Setzen der Route für zweite Service Console NIC nennt sich setroute und sieht wie folgt aus:

#!/bin/sh
#
# chkconfig: 3 30 70
# description: sets a route to the iSCSI target for the service console

RETVAL=0
prog="setroute"

# source function library
. /etc/init.d/functions

start(){
       echo -n $"Setting route for iSCSI-LAN..."
       route add -net 10.11.152.0 netmask 255.255.252.0 gw 10.48.150.4
       RETVAL=$!
       echo
       return $RETVAL
}

stop(){
       echo -n $"Removing route for iSCSI-LAN..."
       route del -net 10.11.152.0 netmask 255.255.252.0 gw 10.48.150.4
       RETVAL=$!
       echo
       return $RETVAL
}

case "$1" in
       start)
            start
               ;;
       stop)
            stop
               ;;
       *)
       echo $"Usage: $0 {start|stop}"
       RETVAL=1
esac
exit 0


Hinweis: Es werden keine Rückmeldungen des route-Befehls ausgewertet!


Dieses Script wird im Verzeichnis /etc/init.d abgelegt und dessen Ausführungsrechte müssen mit dem chmod-Befehl erweitert werden:

chmod +xr setroute

Das Script zeigt sich wie folgt im Directory-Listing:


VMware-iscsi7.jpg


Damit dieses Script beim Starten ausgeführt wird, muss es im passenden runlevel-Verzeichnis verlinkt werden. Dies erfolgt über den Befehl chkconfig.

chkconfig --add setroute

Mit Hilfe des Paramters –list können Sie die Startup-Scripte in den jeweiligen Runlevels einsehen:

chkconfig --list

Die Ausgabe dieses Befehls:


VMware-iscsi8.jpg


Nach diesen Befehlen findet sich ein symbolic link im Verzeichnis des Runlevels 3, rc3.d:


VMware-iscsi9.jpg


Das Ergebnis der gesamten Mühe ist eine persistente Route!


Hinweis: Sollten nach dem Neustart eines ESX-Servers die iSCSI-Targets resp. deren LUNs nicht mehr angezeigt werden, so fehlt die Route zu den iSCSI-Targets resp. wurde die Route durch die ESX Runlevel-Scripts zu spät gesetzt.


Autor: Carsten Schäfer, Benutzer für Benutzer VMachine.de

VMware-VMachineLogo.jpg

Das könnte Sie auch interessieren

Hotkey Problem mit Virtual Infrastructure Client unter Linux und Netware
SATA Festplatten unter VMware ESX/ESXi
VMware ESX Kommandozeilen Skripte