Seit Anfang März kann man sich bei Cisco für die Public Beta des Cisco Nexus 1000V für Hyper-V registrieren und selbigen nach erfolgreicher Registrierung, sowie herunterladen der Daten, ausgiebig testen. Der erste Teil dieser zweiteiligen Blogserie befasst sich mit der Erklärung der Begrifflichkeiten, der schematischer Darstellung der betriebsbereiten Konfiguration und der Vorbereitung für die Konfiguration und Bereistellung des Cisco Nexus 1000V für Hyper-V.
Wenn man die Beta heruntergeladen hat, so beinhaltet die ZIP-Datei, die gut 255 MB groß ist, die folgenden Komponenten.
- Dokumentation
- Cisco Zertifikat
- Nexus 1000V Installer App
- Nexus 1000V Virtual Ethernet Module (VEM) MSI Package (Nexus1000V.msi)
- Nexus 1000V Virtual Supervisor Module (VSM) ISO (n100vh-dk9.5.2.1.SM1.5.0.1.iso)
- Virtual Switch Extension Manager (VSEM) Provider MSI Package (CiscoProviderInstaller.msi)
Wofür werden die einzelnen Komponenten benötigt?
Cisco Zertifikat:
Das Zertifkat wird für den Beta Code benötigt und muss in der Testumgebung, am einfachsten geht dies mit einer Gruppenrichtlinie, verteilt werden. So wie ich es der Dokumentation entnommen habe und interpretiere, wird das Zertifikat für das Nexus 1000 VEM auf den Hyper-V Hosts benötigt.
Nexus 1000V Installer App:
Die App installiert automatisch das Nexus 1000V VSM und den VSEM Provider.
Nexus 1000V VEM:
Das VEM ist die eigentliche Virtual Switch Extension für die Hyper-V Hosts und kann manuell oder per SC2012 SP1 VMM auf den Hyper-V Hosts installiert werden.
Nexus 1000V VSM:
Das VSM ist eine Standalone VM oder eine Primary VM und Secondary VM im Hot-Standby Modus für erhöhte Verfügbarkeit. Mittels VSM werden die Einstellungen für das Nexus 1000V VEM vorgenommen. Der VMM Management Server synchronisiert die Einstellungen vom VSM. Dazu aber später (Teil 2) mehr.
Der Ordner der das Nexus 1000V VSM beinhaltet, enthält auch ein VM Template für den SC2012 SP1 VMM und ein PowerShell Skript, mit dem man das VM Template und die ISO-Datei in die VMM Library importieren kann.
VSEM Provider:
Der VSEM Provider wird für den SC2012 SP1 VMM Management Server benötigt, so dass der VMM Management Server mit dem VSM kommunizieren kann.
Wie sieht in der Grafik betrachtet nachher die endgültige betriebsbereite Konfiguration aus?
Vorweg möchte ich erwähnen, dass es eine Konfiguration gibt, die die Best Practice darstellt, und eine mit der man Aufgrund der Beta leider vorlieb nehmen muss.
Kommen wir aber zu der Konfiguration, die nach Cisco Best Practice wäre.
Grundvoraussetzung pro Hyper-V Host sind mindestens vier NICs im Server! NIC 1 wird für das Management des Hyper-V Hosts verwendet und ist somit nicht Teil eines Virtual Switch. NIC 2 wird für das VSM verwendet und wird für einen External Virtual Switch verwendet, an dem wiederum die Primary VSM VM oder die Secondary VSM VM angebunden ist. Dies ist erforderlich, damit während des Deployments des Nexus 1000V die Verbindung nicht zwischen VSM VM und VMM Management Server sowie dem Nexus 1000 VEM abbricht. Wie in der Grafik zusehen ist, sind NIC 3 und NIC 4 in einem Team zusammengefasst und werden für den Nexus 1000V verwendet. Daran sind dann die VMs angebunden.
Nach Cisco Best Practice befindet sich auf dem einen Hyper-V Host die Primary VSM VM und auf dem anderen Hyper-V Host die Secondary VSM VM. Leider funktioniert dies in der Beta nicht. Wenn man diese Konfiguration fährt meint die Primary VSM VM, dass die Secondary VSM VM nicht erreichbar ist und andersherum, so dass im Endeffekt beide VSM VMs den Betrieb für sich beanspruchen. Um aber den sogenannten Hot-Standby Modus betreiben zu können, müssen beide VMs auf einem Hyper-V Host laufen. Cisco empfiehlt sogar selber in der Dokumentation, dies noch für die Beta so zu handhaben.
Bevor wir zu den vorbereitenden Schritten kommen, möchte ich vorweg sagen, dass ich nicht die Installer App verwendet habe, sondern das mitgelieferte VM Template im Nexus 1000V VSM Ordner.
Als vorbereitende Maßnahmen habe ich zuerst das Cisco Zertifikat per GPO ausgerollt. In der jeweiligen GPO geht man dazu den folgenden Weg.
Computer Configuration –> Policies –> Windows Settings –> Security Settings –> Public Key policies
Dort wird das Zertifikat einmal unter Trusted Root Certification Authorities und Trusted Publishers importiert. Im nächsten Schritt habe ich den VSEM Provider auf dem VMM Management Server installiert und das VEM MSI Package auf den VMM Management Server in den folgenden Pfad kopiert C:ProgramDataSwitch Extension Drivers, so dass das VEM automatisch über den VMM Management Server auf den Hyper-V Hosts installiert werden kann.
Danach habe ich mittels des VM Templates eine Primary VSM VM und eine Secondary VSM VM bereitgestellt, die ISO-Datei für die Installation eingebunden und die VSM VMs entsprechend konfiguriert. An dieser Stelle sei angemerkt, dass man dies auch ohne Dokumentation bewerkstelligen kann, da die einzelnen Setupschritte durchaus selbsterklärend sind.
Jede VSM VM besitzt insgesamt drei NICs. Dabei wird die erste NIC immer für das Control Interface verwendet, die zweite NIC immer für das Management Interface und die dritte NIC für das Packet Interface.
In der OOBE sind standardmäßig die folgenden Features des VSM aktiviert.
- http-server
Das http-server feature dient zur Kommunikation mit dem VMM Management Server. - network-segmentation
Das network-segmentation feature dient zur Konfiguration der Einstellungen für das Nexus 1000V VEM. - sshServer
Das sshServer feature dient dazu, dass man sich per SSH verbinden und die Konfiguration vornehmen kann.
Zu Beginn sind fünf Befehle essentiell, um eine Übersicht zu bekommen und die Konfiguration starten zu können.
show-module:
show-module zeigt die VSMs und VEMs sowie deren Status an. Zu Beginn sieht eine Ausgabe so aus:
Mod Ports Module-Type Model Status
— —– ——————————– —————— ————
1 0 Virtual Supervisor Module Nexus1000V active *
2 0 Virtual Supervisor Module Nexus1000V ha-standbyMod Sw Hw
— —————— ————————————————
1 5.2(1)SM1(5.0.9) 0.0
2 5.2(1)SM1(5.0.9) 0.0Mod MAC-Address(es) Serial-Num
— ————————————– ———-
1 00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8 NA
2 00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8 NAMod Server-IP Server-UUID Server-Name
— ————— ———————————— ——————–
1 10.0.1.100 NA NA
2 10.0.1.100 NA NA* this terminal session
show system redundancy status:
show system redundancy status gibt darüber Auskunft welchen Status die jeweiligen VSM VMs im Hot-Standby Modus haben.
Redundancy role
—————
administrative: primary
operational: primaryRedundancy mode
—————
administrative: HA
operational: HAThis supervisor (sup-1)
———————–
Redundancy state: Active
Supervisor state: Active
Internal state: Active with HA standbyOther supervisor (sup-2)
————————
Redundancy state: Standby
Supervisor state: HA standby
Internal state: HA standby
attach module 2:
Mittels attach module 2 wechselt man auf die Oberfläche des Secondary VSM.
show feature:
show feature gibt eine Übersicht über die aktivierten beziehungsweise deaktivierten Features aus.
Der letzte und meiner Meinung nach wichtigste Befehl ist ein einfaches config! Damit wechselt man auf dem Primary VSM in den Konfigurationsmodus!
Die Konfiguration der Einstellungen für das Nexus 1000V VEM mittels des VSM wären somit der nächste Schritt und werden im nächsten und letzten Teil, Teil 2, beleuchtet.