vSphere Replication und Traffic Separation

Reading Time 4 Minutes

Kürzlich hatte ich mal wieder mehr mit vSphere Replication und Site Recovery Manager zu tun (genauer gesagt mit den Versionen 8.6) und möchte hier meine Erfahrungen mit der Traffic Separation für vSphere Replication wiedergeben.

Was ist Traffic Separation?

Traffic Separation ist die Möglichkeit, den Netzwerkverkehr auf verschiedene Netze/Portgruppen/VLANs aufzuteilen und somit ggf. eine Erhöhung der Sicherheit und der Performance zu erzielen.

Und warum jetzt separieren?

Eine vSphere Replication Appliance kommt standardmäßig mit einem (virtuellen) Netzwerkadapter, und dieser wird für alle Netzwerk-Kommunikationsarten verwendet.
Diese sind:

  • Management Traffic zwischen vSphere Replication Management Server und vSphere Replication Server, zwischen vCenter und vSphere Replication Management Server
  • Replication Traffic von Quell-ESXi Hosts zum Ziel-vSphere Replication Server.
  • NFC (Network File Copy) Replication Traffic vom Ziel-vSphere Replication Server zu den Ziel-ESXi Datastores.

Dieser VMware KB Artikel beschreibt den Prozess auch sehr gut.

Traffic Flow vSphere Replication, Blau = Management Traffic, Orange = Replication Traffic, Grün = Replication NFC Traffic

Zum besseren Verständnis folgt man dem Netzwerkverkehr in der Grafik.
Man sieht, wie die Daten von den Quell ESXI Hosts auf der linken Seite zur Ziel Replication Appliance (vRMS, orange Linie) fließen und dann vom Ziel-vRMS zu den Ziel ESXi Hosts (grüne Linie). Die blauen Linien sind der Management Traffic.
Hinweis: Der Einfachheit halber ist in der Grafik wird nur der Weg in eine Richtung dargestellt. Für einen Failback und Replikation in die entgegengesetzte Richtung würde es genau umgekehrt der Fall sein.

Wie bereits erwähnt, nutzen alle dieser Traffic Arten in der Standardkonfiguration den gleichen virtuellen Netzwerkadapter der Appliance, dementsprechend die gleiche Portgruppe und das gleiche VLAN.
Nun kann es gut möglich sein, dass man darauf keinen Bock hat, dementsprechend: Traffic Separation!

Traffic Separation – so geht’s

Voraussetzung für die nachfolgenden Schritte sind:

  • die bereits ausgerollten vSphere Replication Appliances in Quell- und Ziel-vCenter
  • Portgruppen auf den virtuellen Switches sind vorbereitet

Bzgl. der Traffic Separation habe ich es mir einfach gemacht, da ich lediglich den Management Traffic vom gesamten Replication Traffic trennen möchte.
Dementsprechend benötige ich neben der Management Portgroup (bei mir alex-srm) nur eine Replication Portgroup (hier alex-replication).
Für den Fall, dass man den NFC Replication Traffic auch noch trennen möchte, noch eine weitere Portgroup bereitstellen und beim Teil mit der Netzwerkkarte noch eine Netzwerkkarte hinzufügen. #easy!

So schaut’s dann aus, wenn die Appliance fertig installiert ist und bevor wir mit den Anpassungen losgelegt haben:

vSphere Replication VAMI Networking after Installation

Die VM wieder ausschalten und in den Settings einen Network Adapter hinzufügen:

Add new Network Adapter

Den neuen Adapter in die separate Replikations Portgruppe connecten:

Connect new Network Adapter to the Replication Portgroup

Dann die VM wieder einschalten, danach sieht es im VAMI so aus, ein neues Interface „eth1“ ist aufgetaucht:

Check if eth1 shows up in vReplication VAMI

„Edit“ klicken und danach die Einstellungen für eth1 vornehmen.

Configure eth1, but with the Gateway of eth0!

Das Gateway ist erforderlich, aber Achtung: das hier gesetzte Gateway gilt „global“, also für die ganze VM und überschreibt das Gateway von eth0.
Aus diesem Grund habe ich das gleiche Gateway wie für eth0 eingetragen.
Sollten Quell- und Ziel-Netze in abweichenden Netzen liegen, muss ohnehin mit Static Routes gearbeitet werden, diese werden ausschließlich per SSH/CLI gesetzt.

Nach dem „Save“ noch mal kontrollieren, und… äh, „UP“ ist ja schon mal gut, aber was is da los? Wo ist meine Netzwerkkonfig hin?

eth1 up, but where is the rest of the information?

Keine Panik, die neue IP man zum einen im vCenter im VM Summary sehen…

All IP addresses visible in the vCenter VM Summary

…oder sich per CLI anschauen:

Or check the network config via CLI

Egal, davon erstmal nicht abhalten lassen und weitermachen und die Appliance in den jeweiligen vCentern registrieren. Dabei die IP Adresse von eth1 als „Storage Traffic IP“ setzen:

Register the Appliance with the vCenter Part 1
Register the Appliance with the vCenter Part 2

Im Appliance Management Interface behauptet die Appliance im Summary nun, dass die Storage Traffic IP leider mit keiner NIC IP übereinstimmt. 🤔

Storage Traffic IP does not match?

Okay?! Auch hier erstmal nicht verrückt machen lassen. Weiter geht’s!

Für die Quell- und Ziel-ESXi-Hosts habe ich jeweils einen neuen VMkernel angelegt und die Services „vSphere Replication“ und „vSphere Replication NFC“ aktiviert (falls sich schon mal jemand gefragt hat, wofür diese Häkchen gut sind, hier ist die Antwort 😎)

Warum beides aktivieren?
Noch mal kurz zusammengefasst:
„Replication“ ist von Quell-ESXi zu Ziel-Appliance.
„Replication NFC“ ist von Ziel-Appliance zu Ziel-ESXi.
Wenn ich beides auf dem VMkernel aktiviere, kann ich dann auch einfach in die entgegengesetzte Richtung replizieren 👍.

In unserem Lab hatte ich den Luxus, ein NSX Segment nutzen zu können und alle Hosts sich im gleichen Subnet befinden. Dadurch konnte ich mir die Static Routes in den Appliances ersparen.
(Falls doch jemand unterschiedliche Netze hat, hier die Stelle aus VMware’s Doku für Static Routing)

New VMkernel with Replication and Replication NFC enabled

Traffic Separation – the Test

Nachdem ich die beiden Replication Appliances über die vCenter miteinander verknüpft hatte, erstellte ich eine Replication für eine VM, um nachzuprüfen, welches Interface denn nun wirklich genutzt wird.

Mit folgendem Kommando ließ ich mir die Netzwerk-Statistiken der Appliance anzeigen, während die Replikation aktiv war:

watch -n1 --differences ip -s link show up

Es war deutlich zu sehen, dass der Traffic über eth1 läuft:

„ip -s link show up“ Command, clearly to see more throughput on eth1

Zusätzlich prüfte ich das Netzwerk des Ziel-ESXi Hosts per esxtop. Auch hier konnte man sehen, dass der neue VMkernel vmk2 und die dazugehörige vmnic3 ausgelastet waren.

esxtop Command, the Replication VMkernel is pretty busy.

Fazit

Abgesehen von der schlechten Implementierung des Features im Appliance GUI und dem Anschein, dass es sich eher um ein Hidden Feature handelt (zumindest aktuell bei vSphere Replication 8.6) sehe ich Traffic Separation als durchaus sinnvoll an. Verschiedene Netze für verschiedene Anwendungen/Funktionen sind einfach Teil eines sauberen Designs, erweitern die Sicherheit und die Performance. Warum also auch nicht für die Replikations-Daten.

🐵

Austausch des vCenter Machine Certificate …und den VxRail Manager nicht vergessen!

Reading Time 3 Minutes

Das Thema Zertifikate scheint mich momentan zu verfolgen.
Jedenfalls will ich hier kurz zeigen, wie einfach es mittlerweile ist, das SSL Zertifikat des vCenters durch ein Enterprise CA-signiertes zu ersetzen.

Schaut man sich den KB Artikel von VMware an (Replacing a vSphere 6.x /7.x Machine SSL certificate with a Custom Certificate Authority Signed Certificate), wird hier immer noch der „certificate-manager“ auf der Commandline zitiert.

CSR erstellen im vSphere Client

Dabei geht es doch auch ganz leicht über den vSphere Client. In meinem Fall hängen an diesem vCenter noch ein paar VxRail Cluster, hier muss man im VxRail Manager auch noch Hand anlegen (in dem Fall dann doch wieder per CLI), aber ist auch easy, siehe unten.
Auf zur Demo!

Im vCenter einloggen und weiter zu Administration >> Certificate Management, danach __MACHINE_CERT >> Actions >> Generate Certificate Signing Request:

Generate Certificate Signing Request (CSR)

Alle Infos zum Signing Request eingeben:

Enter Infos for the CSR

…und den CSR entweder kopieren oder herunterladen:

Copy or Download the CSR

Also das war ja einfach!
Die irgendwas.csr Datei benötigt nun der/die Zertifkats-Admin, oder, falls man das mit der Windows CA macht, gibt’s evtl. auch ein Self Service Portal, soll hier aber nicht das Thema sein (könnte aber so wie in diesem Blogpost ablaufen)

Der CSR wurde eingereicht, wie gehts weiter?

Nachdem aus dem CSR ein Zertifikat erstellt wurde, sollte wir nun eine CER Datei und ein Zertifikats-Chain-Datei haben, beides erhältlich bei unserer CA.

Also wieder im vSphere Client, diesmal Administration >> Certificate Management, danach __MACHINE_CERT >> Actions >> Import and Replace Certificate:

Import and Replace Certificate

Dann „Replace with external CA certificate where CSR is generated from vCenter Server“:

Replace where CSR was generated on vCenter

Hatte ich noch nicht erwähnt: der Vorteil bei einem CSR aus dem vCenter heraus liegt darin, dass der Private Key bereits „embedded“ ist. Bei einem CSR, der nicht auf dem vCenter erstellt wurde, fehlt dieser. Den müsste man sich dann noch zusätzlich besorgen und Option 3 auswählen.

Jedenfalls, bei Option 2 geht es dann so weiter:
Neue CER-Datei von der CA auswählen (Machine SSL Certificate) und Chain Zertifikats-Datei von der CA auswählen (Chain of trusted root certificates) und Replace drücken.
Achtung: nun starten die vCenter Dienste neu! Dauert zwar nicht lange, aber sollte in Produktiv-Umgebungen vermutlich nicht ohne Rücksprache erfolgen.

Add CER file and Chain-cert

Sollte man ungeduldig sein (F5!!! F5!!! F5!!!) und sich bereits wieder einloggen können, kann es sein, dass die Zertifikats-Übersicht etwas seltsam aussieht und auch ein paar Fehler ausspuckt. Entspannen und ein paar Minuten Zeit geben!

Und das wars dann auch schon, das vCenter hat nun ein „Trusted Certificate“ von der eigenen CA und der Browser nervt auch nicht mehr mit Sicherheitswarnungen.

Der VxRail Manager will auch wieder dran!

Sollte es Anwendungen geben, die sich mit dem vCenter unterhalten (kann vorkommen), wie z.B. vRealize Log Insight, vRealize Automation, vRealize Operations, Skyline Advisor, VxRail Manager,…. dann wissen die noch nichts von ihrem Glück und sollten angepasst werden (durch Neu-Authentifizierung o.ä.).

In meinem Fall gibt es hier ein paar VxRail Manager, die nun keinen „Trust“ mehr mit dem vCenter haben, was sich aber durch ein Python Script beheben lässt (erhältlich bei Dell im Support Artikel VxRail: How to manually import vCenter SSL certificate on VxRail Manager). Das Script wird hin und wieder aktualisiert, deswegen immer erst mal reinschauen!
Also:

  • Script auf den VxRail Manager laden (z.B. per WinSCP)
  • als „mystic“ per SSH anmelden
  • „su“ zum User „root“
  • Script ausführen: python cert_util.py
VxRail Manager cert_util.py

Wie man sieht, lädt das Script das neue CA Zertifikat vom vCenter, ersetzt die vorhandenen damit und startet danach ein paar Dienste neu. Fertig.

Einfach!

Der Einsatz von Selbst signierten Zertifikaten ist meiner Erfahrung nach noch Seltenheit, dabei ist der Aufwand gering. Der CSR ist ratzfatz generiert und die Zertifikate im vSphere Client schnell ausgetauscht.

vSphere+ – Installation und Erster Eindruck

Reading Time 4 Minutes

vSphere+ ist sein ein paar Wochen in aller Munde, also wollte ich mir selbst einmal einen (technischen) Eindruck verschaffen, was hinter all den Marketing-lastigen Blog-Artikeln und Announcements steckt.

Ein kurzes Schaubild vorweg, damit klar wird, worauf man sich einlässt:

Traditional vSphere Environment converted to vSphere+ Subscription, graphic courtesy of VMware

In einer klassischen vSphere Umgebung gibt es ein bis viele vCenter, die es zu verwalten gilt. Bei vSphere+ wird zusätzlich ein vCenter Cloud Gateway eingeführt, welches als Relay zwischen der VMware Cloud und den On-Premises vCentern fungiert. Dadurch können Services aus der VMware Cloud mit dem On-Prem Datacenter genutzt werden. Klingt doch ganz einfach!

Glücklicherweise bietet VMware eine 15-tägige Trial in der VMware Cloud an. Yeah, ab gehts! 🚀

Auf https://vmc.vmware.com/ mit meinen Customerconnect Portal Login-Daten angemeldet und die vSphere+ Trial gestartet:

VMware Cloud Portal
The Trial is running!

Weiter geht’s im Customer Connect Portal von VMware, hier gibt es das „VMware vCenter Cloud Gateway for vSphere+“ zum Herunterladen.

Eingelogged unter Products and Accounts >> Products >> All Products ist es auch schon schnell zu finden:

Customer Connect Portal – All Products
Customer Connect Portal – All Products – Finding the Download
Download the Product

Nach dem Download öffne ich die ISO Datei auf meinem Client Rechner, in meinen Fall Windows, wird das Image in ein „virtuelles Laufwerk“ eingehängt. Durchgehangelt über ui-installer >> win32 starte ich die installer.exe

Mount ISO File
Open ui-installer Folder
Open appropriate OS folder
Execute installer.exe

Das Fenster des grafischen Installers öffnet sich.

Der Cloud Gateway Appliance Installer

Die Installation der Appliance ähnelte bis hierhin der Installation eines vCenters. In den folgenden Schritten geht es dann grafisch aber anders weiter, dennoch ist hier nicht sonderlich viel zu beachten, deshalb hier ein kurzes Screenshot-Gewitter:

It’s just the Deploy Button to hit…
Accept the license agreement

Ein vCenter (oder ESXi Host) als Installationsziel für die Appliance auswählen und Credentials mitgeben:

Choose Deployment Location
Accept SSL certificate

Ordner und Cluster für die Installation auswählen:

Chose Folder…
…and Cluster/Host for Deployment

VM Name definieren inkl. root Passwort

VM name and root password

Datastore und Disk Mode festlegen:

Chose Datastore and Disk Mode

Dann noch die Netzwerkeinstellungen…

…hier wollte ich es mir einfach machen und habe ein NSX-T Segment mit lokalem DHCP Server ausgewählt. Leider zeigte sich später bei den Pre-Checks für die VMware Cloud Anbindung, dass die DNS Auflösung der Appliance nicht funktionierte (irgendwie logisch, wie sollte der Microsoft DNS in unserem Lab auch Wind davon bekommen). Wer hätte damit gerechnet, dass Forward und Reverse DNS Checks stattfinden… 😎
Dann wollte ich es mir erneut einfach machen, um die Appliance nicht umkonfigurieren zu müssen, doch auch das nachträgliche manuelle Eintragen in den DNS Server führte nicht zum Ziel, da die Appliance außerdem noch mit dem Hostnamen „localhost“ unterwegs war und sich der nicht so einfach über DNS auflösen lässt…
Hier der Fehler:

Failed Connectivity Tests because of missing DNS entries

Also kurzerhand die Appliance erneut installiert, diesmal mit fester IP Adresse und zuvor angelegten DNS Einträgen. Das ist schnell gemacht und der Installer hat sich auch die meisten Einstellungen gemerkt! Top! 👍

Set Static IP for the Appliance

Noch schnell die gewünschte Zeit-Synchronisierungs-Methode ausgewählt (Host oder NTP Server)…

…and finally an NTP Server

…und das Deplyoment beginnt…

…und ist nach ca. 8 Minuten in unserer Lab Umgebung fertig:

Deplyoment complete, Hit Launch to open the a Browser with next steps

Nach einem Click auf Launch öffnet sich der Browser unseres Vertrauens und zeigt uns das Webinterface des Cloud Gateways, oder händisch zu finden unter https://<vmwarecloudgateway>:5480/gw-platform/

Click auf Get Started:

Der nächste Schritt ist die Herstellung der Verbindung zwischen Cloud Gateway und VMware Cloud:

Step 1, Connect Cloud Gateway to VMware Cloud
Login Credentials needed for the Appliance

Das Cloud Gateway wird nun ein paar Connectivity Tests durchführen (wer aufmerksam gelesen hat: das hat vorher mit meinem ersten DHCP Setup nicht funktioniert).
Die Latenzen scheinen relativ hoch, aber ich darf trotzdem Next drücken:

Connectivity Tests

Die Verbindung zwischen Cloud Gateway und VMC muss noch durch einen 6-stelligen Code bestätigt werden, nach dessen Eingabe hart bei VMware gerechnet wird…:

Approval with 6-Digit code
Calculating….

Es bleibt weiter spannend. Dieser Schritt dauerte ca. 10 Minuten:

…und war danach erfolgreich. Cloud Gateway und VMC sind verbunden, fehlen nun das oder die vCenter, die mit dem Cloud Gateway verknüpft werden sollen. Das passiert in den nächsten Schritten:

Step 2: Connect vCenter Servers
Name/IP, User and Password for the vCenter
Next!
…and Acknowledge sending data to VMC

Ein paar Sekunden später wird es als Connected angezeigt:

VMware Cloud vSphere+ and vSAN+ Dashboard

Zurück in meinem VMware Cloud Dashboard sehe ich meine vSphere+ and vSAN+ Kachel:

Dann „launchen“ wir das ganze doch mal und schauen uns die neuen Funktionen an.

Im Inventory gibt es eine nette Übersicht über meine „SDDCs“. Außerdem gibt es hier auch eine Detail Ansicht, und die Möglichkeit, das verbundene vCenter zu aktualisieren (eine gültige Subscription vorausgesetzt):

Inventory
Sorry, no subscription for you! 👎

Im Infrastructure Operations Menüpunkt bekomme ich eine Übersicht der Events und Security Analyse (wie z.B. aktiviertes SSH) präsentiert:

Infrastructure Operations

Das Desired State Profile ermöglicht es, einen bestimmten Zustand festzulegen (durch Import direkt aus dem vCenter oder per JSON File) und diesen dann einem oder mehreren vCentern zuzuweisen. Das lässt sich dann regelmässig (automatisch) überprüfen und auf diesem Weg „Abweichungen“ festzustellen und zu vermeiden:

Desired State Profile

Fand ich jetzt ganz interessant, aber da geht sicherlich noch mehr: Abgesehen vom reinen Betrachten der VMs geht auch das Erstellen einer VM aus der VMC Oberfläche heraus:

Create Virtual Machine Part 1
Create Virtual Machine Part 2

Fazit

vSphere+ (und vSAN+) sind sicherlich eine ganz nette Idee, der Vorteil (oder das Ziel?) liegen aktuell meiner Meinung nach eher bei der Änderung am Licensing Modell, auf das man sich damit einlässt, denn hier gibt es den Wechsel zu Subscriptions. Extra Funktionen für vSAN (aka vSAN+) sind noch keine zu entdecken, und die Extras für vSphere+ sind auch überschaubar bzw. decken sich noch stark mit anderen Diensten wie Skyline Advisor. VMware hat hier einen ersten Schritt getan und zeigt an ersten Beispielen (vCenter Update/Upgrade und das Erstellen von einfachen VMs per VMC), wie eine wirklich zentralisierte Verwaltung einer stark fragmentierten vCenter Umgebung aussehen könnte.
Zudem ist durch die Anbindung an VMC auch ein Zusammenspiel mit anderen VMC Diensten in Zukunft denkbar (wie z.B. VMware Cloud Disaster Recovery, Hyperscalern,…) bzw. schon absehbar, wie in diesem VMware Blog Artikel erwähnt.

Der Vollständigkeit halber könnt ihr hier auch noch mal die VMware Doku selbst lesen:
https://docs.vmware.com/en/VMware-vSphere+/services/vsphereplus-using-managing/GUID-7D5545D9-6E35-48AA-88AE-BE549940344F.html

🐵

VMware NSX ALB / AVI Certificate Signing Request (CSR) mit Microsoft CA

Reading Time 2 Minutes

Da ich mich in unserer ITQ Lab Umgebung mit VMware NSX Advanced Load Balancer (oder NSX ALB aka AVI Loadbalancer, sucht es euch aus!) im Zusammenhang mit vSphere with Tanzu auseinandersetzte, wollte ich diesen auch durch ein „offizielles“ Zertifikat vertrauenswürdig machen und das „Self Signed Certificate“ ersetzen.

In der Lab Umgebung existiert bereits eine Windows Certificate Authority (CA) und das CA Web Enrollment auf einer Windows 2019 VM. Auf die Installation der CA gehe ich nicht weiter ein, hier hatte ich mich an einen Artikel auf dem VirtuallyThere Blog gehalten.

Zusätzlich habe ich ein Certificate Template nach Vorgaben von VMware erstellt. Dieses möchte ich in Zukunft für alle VMware Produkt Deployments im Lab einsetzen. Dazu habe ich einen weiteren Blog Artikel geschrieben (Erstellen eines Microsoft CA Certificate Templates für vSphere 6.x/7.x), oder wer es direkt von VMware lesen mag, hier der KB Artikel: Creating a Microsoft Certificate Authority Template for SSL certificate creation in vSphere 6.x/7.x

Weiterlesen

Erstellen eines Microsoft CA Certificate Templates für vSphere 6.x/7.x

Reading Time 2 Minutes

Um in unserer Lab Umgebung sinnvoll und „VMware konform“ einheitliche Zertifikate erstellen zu können, die durch eine Microsoft CA signiert sind, war es im voraus notwendig, ein Certificate Template zu erstellen.

Die folgende Anleitung orientiert sich dabei am VMware KB Artikel Creating a Microsoft Certificate Authority Template for SSL certificate creation in vSphere 6.x/7.x

Weiterlesen