VCSA und PSC über Rechenzentren hinweg verschieben

Heute war ich bei einem unserer Kunden, der Zerto als BC/DR-Software einsetzt. Er migriert gerade seine Workloads in zwei neue Rechenzentrumsstandorte. Die alte Umgebung war ein Stretched Cluster, die neue wird ebenfalls eines. Aus Sicht von Zerto werden also alle VMs auf sich selbst repliziert.

Heute wollte der Kunde die vCenter Server Appliance (VCSA) und die VMs des Platform Services Controller (PSC) in die neue Umgebung holen. Beide VMs lagen bereits in einem temporären Cluster, das im alten Rechenzentrum stand, aber Teil des neuen vCenter Inventory war. Wir mussten die VMs also innerhalb des vCenter Inventory von Cluster A nach Cluster B verschieben. Die beiden Cluster teilten sich keinen Storage und hatten unterschiedliche CPU-Typen auf ihren Hosts.

Als zusätzliche Schwierigkeit mussten wir die IP-Adressen der verschobenen VMs ändern, weil die neuen Rechenzentren eigene IP-Bereiche haben.

Das Problem: Zerto hängt am vCenter, und in einer Stretched-Cluster-Umgebung mit nur einem vCenter Server ist das vCenter besonders kritisch. Wir konnten den vCenter Server also nicht mit Zerto auf den neuen Standort schwenken. Alle übrigen VMs werden mit Zerto migriert, was übrigens ein hervorragender Anwendungsfall dafür ist.

Nach etwas Brainstorming stand dieser Plan:

• VMs an den neuen Standort kopieren beziehungsweise klonen
• beiden geklonten VMs ein internes Netz zuweisen
• geklonte VMs starten
• die IP-Adressen beider VMs über die vSphere Konsole ändern (ich bin diesem Post gefolgt)
• geklonte VMs herunterfahren
• Quell-VMs herunterfahren (womit die Verbindung zum vCenter natürlich weg ist)
• die Netzwerkzuweisung der geklonten VMs auf das neue Netz ändern (dvSwitch Portgroup)
• DNS auf die neuen IP-Adressen anpassen (sehr wichtig)
• geklonte VMs starten
• zurücklehnen und die gelungene Migration dieser kritischen VMs geniessen

Wie alle Pläne hielt auch dieser nicht. Das erste Problem: Nachdem wir vCenter und PSC geklont hatten, merkten wir, dass wir dem neuen Netz, das die geklonten VMs nutzen sollen, erst Uplinks zuweisen müssen. Das haben wir gemacht, im Wissen, dass es eine Änderung in der vCenter Datenbank ist, die beim Failover verloren geht.
Am Ende haben wir einem der Hosts im neuen Rechenzentrum einen Uplink vom dvSwitch weggenommen und daraus einen temporären Standard Switch mit der benötigten Portgroup gebaut. Damit war die Erreichbarkeit nach dem Start der VMs im neuen Rechenzentrum gelöst.

Mit diesen Anpassungen haben wir den Plan durchgezogen. Die VMs antworteten sofort auf Ping mit ihren neuen IP-Adressen. DNS und Netzwerk stimmten also. Aber dann das nächste Problem: Der Web Client startete nicht. Normalerweise bekommst du nach einem Neustart der VCSA ein paar Fehlermeldungen, bis der Web Client vollständig geladen ist. Hier kam ein «cannot display web page».

Nach etwas Suchen zeigte sich, dass viele Dienste nicht hochkamen. Der Befehl «service-control —status» aus der appliancesh der VCSA gab das aus:

root@VCSA [ ~ ]# service-control —status
Running:
lwsmd vmafdd
Stopped:
applmgmt vmcam vmonapi vmware-cm vmware-content-library vmware-eam vmware-imagebuilder vmware-mbcs vmware-netdumper vmware-perfcharts

Der Startvorgang der Dienste war also unterbrochen und lief nicht weiter. Der Befehl «service-control —start —all» lieferte diesen Fehler (gekürzt):

“localized”: “An error occurred while starting service ‘vmware-vmon’”,
“translatable”: “An error occurred while starting service ’%(0)s’"
"Stderr: Failed to execute operation: Unit file is masked\n”

Nach etwas Recherche fanden wir eine sehr hilfreiche Diskussion in den VMware Communities hier. Der Vorschlag: den vmon-Dienst «unmasken» und die Maschine neu starten.

Wir haben also aus der Bash Shell der VCSA Folgendes abgesetzt:

systemctl unmask vmware-vmon.service

Als Antwort kam, dass der Symlink zum Dienst entfernt wurde. Nach einem Neustart lief alles.

Erwähnenswert: Das betroffene vCenter lief auf dem aktuellsten vSphere 6.5 Build (Update 2b, Build 8815520).

Das ist ein gutes Beispiel dafür, wie viel es bringt, Wissen zu teilen. Hätte niemand den Hinweis mit dem Unmasken des Dienstes geteilt, wäre ich vielleicht nach ein paar Stunden Recherche selbst darauf gestossen. Oder eben nicht, und hätte am Ende das vCenter neu installiert und dabei viel Zeit verloren.