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.
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:
Die VM wieder ausschalten und in den Settings einen Network Adapter hinzufügen:
Den neuen Adapter in die separate Replikations Portgruppe connecten:
Dann die VM wieder einschalten, danach sieht es im VAMI so aus, ein neues Interface „eth1“ ist aufgetaucht:
„Edit“ klicken und danach die Einstellungen für eth1 vornehmen.
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?
Keine Panik, die neue IP man zum einen im vCenter im VM Summary sehen…
…oder sich per CLI anschauen:
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:
Im Appliance Management Interface behauptet die Appliance im Summary nun, dass die Storage Traffic IP leider mit keiner NIC IP übereinstimmt. 🤔
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)
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 upEs war deutlich zu sehen, dass der Traffic über eth1 läuft:
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.
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.
🐵