(Nested) VCF 4.2 Setup

VMware Cloud Foundation stellt die Basis für ein SDDC dar. Es handelt sich hierbei um einen Greenfield Ansatz, ein Datacenter komplett automatisiert aufzusetzen und zu lifecyclen. Hierzu wird zunächst die Basisumgebung mittels einer VM, dem sog. Cloudbuilder aufgesetzt. Diese Maschine ist aktuell ca. 20GB gross und enthält alle Komponenten für VCF.

Nested ESXi

Zunächst müssen die Nested ESXi Server aufgesetzt werden. Diese benötigen mindestens 8vCPUs und 64 GB RAM. Durch Ressourcen Ersparnisse (Deaktiveren von Salt und Large Pages im Nested und Physical Host) läuft die Management Domain mit 37GB RAM im Leerlauf.

Die Nested Server sind mit 8vCPUs und aktiviertem IOMMU sowie Virtualisierungs- und Performance Indikatoren erstellt. Der virtuelle Switch auf dem Host läuft mit VLAN Trunk und ohne Security Settings, damit die virtuellen MAC Adressen nicht blockiert werden.

Die Maschinen haben 4 Disks. Disk 1 ist 20GB gross und dient zum Bootup der Hosts. Disk 2 ist eine virtuelle NVMe mit 100GB als vSAN Cache Device. Zwei 500GB SSDs (oder Disks, je nach Wunsch) dienen als Kapazitätslayer des späteren vSAN Clusters. Die VMs haben zwei vmxnet3 Adapter.

Meine Umgebung läuft auf den physischen Hosts auf einem All-Flash vSAN. Da das virtuelle vSAN Cluster mit RAID1 aufgesetzt ist, kann ich mir diesen Schutz und die Kapazität auf der Physik sparen und setze für die vSAN VMDKs eine R0 Policy.

Doch Obacht: Müssen die physischen Hosts nun in Wartung gesetzt werden, sollte man darauf achten, dass die Disks nicht avakuiert werden, damit man keine unnötigen Migrationsprozesse hat.

Cloud Builder

Der Cloudbuilder bietet eine Excel Tabelle zum Download an, in die alle notwendigen Parameter für ein Setup eingetragen werden. Diese Datei lädt man wieder auf den Cloudbuilder hoch. Diese Datei enthält u.a. Angaben zu den vier Management Hosts und den notwendigen IP Adressen und bei Nutzung der Application Virtual Networks auch die ASNs der Gateways. Hier geht man davon aus, dass der oder die ToR Switches das dynamische Routing der Netze übernehmen.

In meinem Fall habe ich keinen L3 ToR Switch. Daher wird ein zentraler Router die Aufgabe übernehmen. Ich setze hierzu einen EdgeRouter Lite von Ubiquity ein. Das Ding kann 1Gb Line Speed Routen und kostete knapp 100€. Dafür kann er alles, was das Herz begehrt. Die Software basiert auf dem beliebten VyOS. Mittlerweile wurde das Modell vom Markt genommen. Der Nachfolger ist der ER-4. Wenn man kein Gb Datendurchsatz braucht, reicht auch ein ER-X für knapp 60€ aus.

Die BGP Parameter für den EdgeSwitch lassen sich in der GUI oder via CLI setzen. Oben kann man das Ergebnis via GUI sehen. Konfigurieren wir das mal in der CLI:

Login via ssh in den Router, danach config Mode aufrufen:
configure

BGP AS Nummer des lokalen und des fremden Systems angeben, sowie Routen aus der statischen Routing Tabelle ins BGP schicken:

 set protocols bgp 65001 neighbour 192.168.8.200 remote-as 65003 
 set protocols bgp 65001 neighbour 192.168.8.201 remote-as 65003 
 set protocols bgp 65001 neighbour 192.168.9.200 remote-as 65003 
 set protocols bgp 65001 neighbour 192.168.9.201 remote-as 65003 
 set protocols bgp 65001 redistribute static

Der Cloudbuilder erwartet die vier Hosts als Basiskonfig mit folgenden Parametern:

1. 1 NIC für Management, GW und DNS entsprechen denen in der Excel Tabelle
2. NTP Server eingerichtet
3. SSH Dienst läuft

Also wie man sieht, eine Standardkonfiguration mit fixer IP, NTP und SSH. Keine große Sache.

Richtet man häufiger solche Cluster ein, kann der Cloudbuilder auch als DHCP und PXE Server dienen und die Hosts von Scratch an hoch ziehen. Dies ist aber eher selten der Fall.

Setup Prozess

Die ersten Schritte möchte ich hier kurz darstellen:

1. Akzeptieren der EULA
2. Plattformauswahl
   VCF auf Standard Servers – Lifecycle Management wird komplett via VMware Technologien erfüllt. Für HW Lifecycle wird ein Image für den vLCM erstellt.
   VCF auf VxRail – Die Dell VxRail ist eine Schlüsselfertige Lösung, die ein integriertes Lifecycle Management mitbringt. VCF nutzt dieses und lagert alle Hardware nahen Aufgaben an den VxRail Manager aus.
3. Sichten der Voraussetzungen auf physikalischer Seite.
4. Herunterladen des Excel Workbooks.
5. Ausfüllen des Workbooks
   
   
6. Hochladen des Workbooks
   
7. Validieren der Daten – dies erfolgt automatisch und prüft, ob alle Hosts erreichbar sind, ob die Lizenzen korrekt sind, die Passwörter den Regeln entsprechen, die IP Adressen und die MTU Size funktionieren und vieles mehr. Der Check dauert ca. 5 -10 Minuten und kann nicht abgebrochen werden. Wichtig ist auch, dass die ESXi Version passt. Im Notfall kann man sich das korrekte Image mittels sftp von der CloudBuilder Appliance herunter laden. Stösst der Pre-Check auf ein Problem, wird dies kenntlich gemacht und man kann am Ende nur dann die Installation starten, wenn man die Probleme aktiv akzeptiert. In meinem Video konnte der NTP Server nicht erreicht werden. Handelt es sich um schwerwiegende Probleme, kann die Installation erst gar nicht gestartet werden.
   
   
   Die gesamte Umgebung ist auf meinem Edgerouter konfiguriert (DHCP Server für die Overlay Netze nicht vergessen, da sonst Adressen aus dem APIPA Pool genutzt werden und diese können nicht angepingt werden:
   
   
8. Im Anschluss werden die Hosts tatsächlich konfiguriert und die Lösung installiert. D.h., es wird ein ein-Knoten vSAN erstellt, darauf der vCenter Installiert, danach die restlichen drei Hosts ins Cluster und vSAN aufgenommen und die restlichen Management Systeme installiert. Dieser Vorgang dauert bei mir ca. 2-3h Stunden. Wichtig: Der Vorgang kann nicht abgebrochen werden! Auf schnellerer Hardware, insbesondere nicht nested, dauert die Installation ca. 90-120 Minuten.
9. Nach der Installation erhält man direkt Zugriff auf den SDDC Manager. Dieser ist für den kompletten Lifecycle Mechanismus zentraler Dreh- und Angelpunkt.
   

Installationsprobleme auf Ryzen CPUs

Nutzt man nicht unterstützte Hardware – wie ich (Ryzen CPU, statt Intel) – so scheitert der Rollout beim Deployment der Edge Nodes.

Wenn man nicht trickst, wird die erste Appliance ausgerollt. NSX bringt die Appliance nicht hoch und der Cloudbuilder rollt diese dann neu aus. Nach einigen Versuchen gibt er auf und bricht die Installation ab. Daher kann man zu einem kleinen Trick greifen:

1. Warten, bis die erste Appliance ausgerollt ist.
2. Den CloudBuilder pausieren.
3. Im VCF vCenter anmelden
4. Remote Console auf die Edge Appliance aufmachen
5. In der Datei /opt/vmware/nsx-edge/bịn/config.py nach „AMD“ suchen. In der Zeile mit „AMD EPYC“ das „EPYC“ rauslöschen. Datei speichern und rebooten.
6. Wenn die Appliance wieder da ist (es werden zwei Reboots durchgeführt), und im VCF NSX Manager die Appliance als verfügbar gekennzeichnet ist, kann man den Cloudbuilder weiter laufen lassen.
7. Den Vorgang ab Punkt 2 wiederholen, sobald die zweite Edge Appliance ausgerollt wird.

Anschliessend geht der Installationsvorgang weiter und wird erfolgreich beendet.