VMware wird die nativen NSX Load Balancer auslaufen lassen. Kunden sollten auf den derzeit unterstützten NSX Advanced Load Balancer (Avi) umsteigen, der gleichzeitig für zukünftige Multi-Cloud- und Container-Strategien vorbereitet. Avi funktioniert in allen Umgebungen jenseits des NSX-Frameworks und erweitert die Anwendungsfälle auf Public Cloud, Container und App-Security, während gleichzeitig Funktionen für GSLB, WAF und Analytics hinzugefügt werden. Ein Migrationstool wird verfügbar sein, um die Migration bestehender Konfigurationen auf die aktuelle Technologie einfach und problemlos zu gestalten.
VMware Cloud Foundation (VCF) ist die einheitliche SDDC-Plattform für die Hybrid Cloud. Sie basiert auf der Compute-, Storage- und Netzwerkvirtualisierung von VMware.
VMware Cloud Foundation kann modular um weitere Workload Cluster erweitert werden, oder eine vorhandene Management-Domain über eine zweite Availability-Zone (AZ) gestreckt werden. Der Erweiterungsprozess wird über den SDDC-Manager gesteuert. Der Ablauf hierzu ist im Prinzip recht einfach und der SDDC-Manager übernimmt im Hintergrund alle Konfigurations-Aufgben, wie z.B. die Erzeugung des vSAN Clusters, der Netzwerke, Kernelports, vCenter umd NSX-Manager.
Hosts mit ESXi Basisimage installieren
Management IP definieren
root Login definieren
DNS und NTP konfigurieren
neue Hosts in den SDDC-Manager importieren
WLD erzeugen
Es gibt jedoch einen kleinen Stolperstein, der leicht übersehen wird: Die NIC Reihenfolge der neuen Hosts. Vor dem Import der Hosts wir eine Checkliste angezeigt, die uns darüber informiert, welche Eigenschaften die Hosts haben müssen. Gefordert werden zwei physische NICs mit mindestens 10 GBit.
Was jedoch oft überlesen wird, ist das Prädikat “traditional numbering“. Das bedeutet, die beiden 10 GBit NICs müssen die Nummern vmnic0 und vmnic1 haben. Eine Information, die leider allzuleicht überlesen wird. Diese Reihenfolge ist hart-verdrahtet und läßt sich nicht auswählen. Erschwerend kommt hinzu, dass viele Serversysteme Onboard-Netzwerkadapter haben, die zum Teil in 1 GBit ausgelegt sind. ESXi beginnt bei der Nummerierung der vmnics bei diesen Onboard-Adaptern. In solch einem Fall hätten dann also die geplanten 10 GBit NICs höhere Nummern wie z.B. vmnic2 oder vmnic3. Damit scheitert das Rollout der VCF Erweiterung.
Es ist in der aktuellen VCF Version 4.2 nicht möglich, die NICs explizit zu wählen, wie dies beispielsweise im Bringup-Sheet der Fall ist. Auch die Verwendung von mehr als 2 NICs geht nur über API-Calls und nicht über den SDDC-Manager.
Ausweg
Der einzige Ausweg besteht gegenwärtig darin, die Onboard Adapter im BIOS der Server zu deaktivieren und ggf. den PCIe LAN Adapter in einen Slot mit niedriger Nummer zu stecken, damit die NICs die Nummern 0 und 1 erhalten.
Ich werde hier den Setup-Prozess beschreiben. Zunächst muss die ca. 6 GB große Imagedatei der Appliance von VMware Downloads geladen werden (Login erforderlich). Die Appliance wird in einen bestehenden Cluster über den Assistenten “Deploy OVF Template” bereitgestellt.
Bereistellung der Plattform Appliance (Collector)
Hier gibt es etwas Verwirrung. Die Kollektor Appliance heisst jetzt “Platform” Appliance. Das ist natürlich schwierig, wenn man im Download Portal (vergeblich) nach dem Collector sucht.
Virtuelle Distributed-Switches (vDS) haben zahlreiche Vorteile gegenüber Standard vSwitches. Durch die zentrale Verwaltung und einheitliche Konfiguration über alle Hosts, ist weniger Raum für Konfigurationsfehler im Vergleich zu Standard vSwitches. Nennt mich altmodisch, aber ich habe dennoch gerne das Management Interface des Hosts an einem klassischen Standard vSwitch. Wenn irgendetwas dummes passiert kann man dann immer noch den Host erreichen und Änderungen vornehmen.
Kürzlich ist der Host eines Kunden ausgefallen. Nach der Wiederherstellung und Rückspielung der Konfiguration war die Nummerierung der vmnics aus noch nicht geklärter Ursache vertauscht. Der Host war daher weder über vCenter, noch über Hostclient ansprechbar. Der Kunde hatte nicht genügend vmnics im Host und konfigurierte daher das Management Network über eine Portgruppe auf dem vDS. Das ist erlaubt und in der Regel kein Problem. In diesem speziellen Fall war es jedoch durchaus ein Problem. Ich war im wörtlichen Sinn vom Host ausgesperrt. Normalerweise könnte man über das Direct Console User Interface (DCUI) die Zuordnung der vmnics zum Management Netzwerk neu organisieren. Das funktionierte jedoch nicht, da alle vmnics von Distributed vSwitches beansprucht waren. Sie konnten daher keinem Standard vSwitch und somit auch nicht dem Management Kernelport zugeordnet werden.
Was nun?
Es gibt einen Ausweg aus dieser Lage. Dazu muss man Zugang zum CLI des DCUI haben. Über eine lokal angeschlossene KVM-Konsole, ILO oder iRMC kann man sich auf dem Host anmelden und wählt im Hauptmenü “Troubleshooting Options”.
