Im Rahmen eines VMware Cloud Foundation (VCF) Greenfield Deployments wird die Cloud Builder Appliance zum einmaligen Gebrauch verwendet. Diese stellt automatisiert die Management Infrastruktur eines VCF Clusters bereit und kann danach verworfen werden.
Idealerweise wird das zuvor erstellte Workbook bzw. JSON abgearbeitet und der Cluster erfolgreich erstellt.
In der UI des Cloud Builders gibt es jedoch keine Möglichkeit den Assistenten zurückzusetzen und komplett neu zu starten. Beispielsweise weil sich Anforderungen verändert haben und ein neues oder angepasstes Workbook verwendet werden soll. Oder man mächte die Appliance für einen weiteren Rollout verwenden. In diesem Fall müsste die Appliance komplett neu bereitgestellt werden. Auch eventuelle Fehler im JSON File können so nicht korrigiert werden.
Es gibt jedoch einen Trick, um den Cloud Builder wieder auf Null zu setzen und ihn mit einem veränderten JSON File zu füttern. Zu verdanken ist dies einem API Call, der möglicherweise währen der Entwicklung ‘vergessen’ wurde. Dazu müssen wir uns als User root auf der Konsole des Cloud Builders anmelden.
[Optional] Hier ist es unter Umständen einfacher, wenn man dem root User temporär SSH Zugriff erlaubt. Dazu meldet man sich als root an der VM Konsole an und editiert die sshd Konfiguration.
sudo vi /etc/ssh/sshd_config
Innerhalb des Config-Files folgende Zeile finden und mit einem # auskommentieren.
# PermitRootLogin no
Die Konfiguration speichern und eine SSH Verbindung als root aufbauen. In diesem Kontext führen wir dann einen internen API Call aus.
curl -X GET http://localhost:9080/bringup-app/bringup/sddcs/test/deleteAll
Danach loggen wir uns auf der Web-GUI des Cloud Builders ein und können diesen wieder von Anfang an ausführen.
Ich denke es ist keine Übertreibung, wenn ich sage “2020 war ein Jahr wie kein anderes”. So ziemlich jeder in der IT Branche und auch anderswo wird das bestätigen. Ich nehme diesen letzten Tag im Jahr 2020 zum Anlaß, den letzten Blogartikel des Jahres zu schreiben und darin für mich wichtige Ereignisse Revue passieren lassen.
Januar
Das Jahr begann ganz normal, fast wie jedes andere. Nach dem Jahreswechsel begannen Aufgaben und Projekte der kommenden Monate langsam anzulaufen. Es ist erfahrungsgemäß ein ruhiger Monat, denn auch Kunden haben oft bis KW 2 noch Betriebsferien.
Februar
Der Februar hatte einige persönliche Highlights des Jahres zu bieten.
Wir veranstalteten am 13.2. ein VMUG Meeting in Nürnberg. Heute muss man schon ergänzend hinzufügen, dass es ein vor Ort Treffen war. Damals eine Selbstverständlichkeit. Heute klingt es wie die Erzählung aus einer fernen Zeit. Ich selbst hatte dort einen Vortrag zum Thema “Strategien zur proaktiven Fehlervermeidung” gehalten. Eine Betrachtung der Produkte VMware Skyline und Runecast Analyzer. Was sind deren Gemeinsamkeiten und wo liegen Alleinstellungsmerkmale?
Eine lange geplante private Reise führte uns in die hohen Breiten der Arktis. Spitzbergen im Winter. Kein anderes Ereignis hinterließ dieses Jahr so tiefe Eindrücke wie dieses. Am 14. Februar endet auf Spitzbergen nach 84 Tagen Dunkelheit die lange Polarnacht und die Sonne kommt erstmals wieder über den Horizont. Bereits Mitte April geht sie dann für 99 Tage gar nicht mehr unter. In der Zeit dazwischen erstrahlt die Eiswüste in wunderbarem Licht. Dies wollten wir erleben und in Bildern festhalten.
Spitzbergen erkunden bedeutet viele Stunden bei bis zu -38°C abseits der Zivilisation unterwegs zu sein. Immer in Begleitung eines bewaffneten Guides, denn die Insel ist Eisbärenland und niemand darf sich außerhalb der Siedlung unbewaffnet bewegen.
Wir lernten, dass zum Beispiel so einfache Dinge wie Essen bei Temperaturen unterhalb der Gefriertruhe eine echte Herausforderung sind. Auch was es bedeutet in einem White-Out zu sein, wenn der Horizont mit dem Eis verschmilzt und alles um einen herum nur noch weiß ist.
Svalbard reindeer
Eine erfreulich Nachricht erreichte mich unterwegs in meinem Postfach: Ich wurde für ein weiteres Jahr als vExpert nominiert.
März
Unser Aufenthalt dauerte bis in die erste Märzwoche. Doch die Welt, in die wir zurückkehrten war eine andere. Schon unterwegs lasen wir Nachrichten über Corona-Ausbrüche und ausverkauftes Toilettenpapier. Als wir aus Deutschland abreisten war Corona kaum ein Thema. Jetzt war es DAS Thema und sollte es für Monate bleiben.
Noch am 11. März fand in den Räumlichkeiten von VMware in München die letzte deutsche VMUG vor Ort statt. Ich selbst war Co-Organisator und Referent und hatte damals keine Bedenken bezüglich der Zugfahrt und des Treffens. Rückblickend und mit dem Wissen von heute war es sicherlich nicht die beste Idee. Wir setzten uns unnötigerweise einem großen Risiko aus. Händewaschen alleine reicht bei SARS-CoV-2 nicht. Meines Wissens blieb die Aktion für alle Beteiligten ohne weitere Folgen.
Ich hatte im vergangenen Jahr ausführlich über die Planung und die Hardware meines Homelab vSAN-Clusters berichtet (Teil 1 und Teil 2). Aus Gründen der Einfachheit wurden die vier kleinen Supermicro E300-9D einfach in einem IKEA Regal untergebracht.
Low budget Rack, made in Sweden.
Das funktionierte über einen langen Zeitraum gut, aber Änderungen in der Verkabelung, oder Hardware-Wartungen gestalteten sich schwierig. Patchkabel und Stromversorgung lösen war immer eine Herausforderung an das Fingespitzengefühl. Noch schwieriger war es, die Verkabelung wieder herzustellen. Nicht selten wurde bei solchen Aktionen ein Port vertauscht.
Kurzum: Abhilfe musste her. Ideal wäre ein 19″ Rack, aber ich habe in meinem Büro keinen Platz für einen 48 HE Schrank. Nach etwas Recherche fand ich bei einem meiner Hardware Lieferanten ein kleines Rack mit 12 HE, das man zudem auch mit Rollen ausstatten kann. Dies schien perfekt, da es gerade einmal so hoch war wie mein Schreibtisch. Auch die Tiefe ist variablel von 57,5cm bis 101cm. Kein Problem also für die kurzen E300-9D und ein paar Netzwerk-Komponenten.
Bastelstunde
Das Gestell kommt in sehr kompaktem Packmaß und entpuppt sich als solider Metallbau mit ordentlicher Verschraubung.
Aufbau Phase 1. Rack auf der Seite liegend.Variable Einstellung der Rack Tiefe.Fast fertig
Umrüstung auf 19″
Einige der vorhandenen Komponenten mussten auf 19 Zoll umgerüstet werden. So zum Beispiel der Ubiquiti EdgeRouter 10X, für den es vom Hersteller ein Umrüstkit gibt (SKU: ER-RMKIT). Das gleiche gilt für die Supermicro E300-9D Mini-Server. Supermicro bietet auch dafür ein Umrüstkit (MCP-290-30002-0B) an, welches die Server seitlich auf 19″ verlängert und eine Halterung für das Netzteil mitbringt.
Vorläufiger Endausbau
In der Planungsphase hätte ich nicht gedacht, alle 12 Höheneinheiten belegen zu können. Aber Schritt für Schritt wurde klar, dass weitere Komponenten sinnvol sind und zugefügt werden müssen. So zum Beispiel die Schaltleiste, mit der einzelne Gerätegruppen geschaltet werden können. Mit ihr werden Kaltgeräte Verteilerleisten auf der Rückseite geschaltet. Auch Kabelführungen sind Pflicht, möchte man nicht in einem Chaos enden. So wurde recht schnell klar, dass für die 1 GBit Verbindungen ein eigener Switch notwendig ist, wenn man keine 10 GBit Ports für 1 GBit verschwenden möchte.
Obwohl ich ein großer Fan des Ubiquiti UniFi Systems bin, entschied ich mich für das Homelab für Geräte der EdgeMax Serie. Diese können individuell auf der CLI oder der Web-GUI konfiguriert werden.
Die E300-9D sind mit insgesamt 4 x 10 GBit Adaptern ausgestattet. Davon 2x Kupfer und 2x SFP+. Dies führte zur Erweiterung mit einem Ubiquiti EdgeSwitch 16 XG.
Rückseitig sind Ablageflächen verbaut, auf denen zum Beispiel Raspberry Pi und anderes Zubehör Platz finden. Ein Raspberry Pi übernimmt im Lab die Aufgaben DNS und Zeitserver.
Da das ganze Rack auf Rollen montiert ist, kann es problemlos für Wartungsarbeiten hervorgezogen werden. Es ist dafür nur ein Patchkabel und eine Stromversorgung zu trennen.
Geräuschentwicklung
Mit steigender Anzahl an Geräten steigt natürlich auch die Geräuschentwicklung. Wie man den Netgear 10G Switch zum Schweigen bringt, hatte ich bereits in einem älteren Beitrag beschrieben. Die Ubiquiti Switche arbeiten erstaunlich leise und werden nur beim Start etwas lauter. In einem Meter Entfernung erreichen alle Switche einen Schalldruck von etwa 20 dB. Das enspricht einem (lästigen) Moskito. Nicht wirklich störend, aber hörbar. Den größten Geräuschanteil haben derzeit noch die vier E300 Server, aber auch hier könnte man mit die Original-Lüfter durch Noctua Modelle ersetzen. Sicher ein Projekt für die Zukunft…
Eine Neuerung von vSAN 7.0 U1 ist die Bereitstellung von SMB Shares über den vSAN Fileservice. Dieser war in Version 7.0 noch auf das NFS Protokoll beschränkt.
Wo ist die SMB Option?
Ich war etwas verwundert, dass ich im Homelab trotz Cluster Update und Update der FS-Service-VMs das SMB Protokoll nicht auswählen konnte.
Wie meistens in solchen Fällen hilft es, die Augen zu öffnen und das Kleingedruckte zu lesen. 🙂 Direkt unter dem Dropdown Menü steht unmissverständlich:
Enable active directory configuration in the File Service configuration before using SMB protocol.
Klingt logisch und erklärt, warum ich das SMB-Protokoll nicht zur Auswahl habe. Mein Homelab arbeitet ohne ADS. Die Namensauflösung erledigt ein Bind9 Server.
Auch in den Eigenschaften eines vorhandenen File-Shares ist der Hinweis zu finden.
