Benötige Hilfe bei Script für VM Umgebung herunterfahren nach Stromausfall
Hallo Kollegen,
ich bin gerade dabei ein Script zu schreiben um unsere VM Umgebung und 2 physische Server bei Stromausfall über die vorhandene USV herunterzufahren.
vSphere 7.0.1
Habe dieses Script geschrieben:
Ist der Code OK?
Werden die Physischen Server nach erfolgreicher Stormversorgungsaufbau wieder von alleine gestartet oder sollte ich die Server separat mit USV Agent runterfahren lassen?
Das große Problem ist aber, das ich im vSphere Client die Funktion "Starten und Heruntefahren von virtuellen Maschinen" nicht aktivieren kann.
"Bearbeiten" ist ausgegraut und der Hinweis "Wenn der Host Teil eines vSphere HA-Clusters ist, wird das automatische Starten und Herunterfahren von virtuellen Maschinen deaktiviert" ist hinterlegt.
Ist mein Script somit hinfällig und ich muss mir was anderes einfallen lassen?
Aber es muss doch eine einfache Lösung geben um das VM Umfeld ohnegroße Programmiererei bei Stromausfall sicher herunterzufahen und wieder hochfahren zu können.
Über Eure Hilfe wäre ich dankbar.
Gruß
Kalma
ich bin gerade dabei ein Script zu schreiben um unsere VM Umgebung und 2 physische Server bei Stromausfall über die vorhandene USV herunterzufahren.
vSphere 7.0.1
Habe dieses Script geschrieben:
cls
@ECHO OFF
REM VMs müssen nicht aufgelistet werden, da beim herunterfahren der ESX Server die VMs automatisch herunter gefahren werden.
REM Die Reihenfolge wird im vSphere Client eingestellt. Genauso wie das hochfahren.
REM ESX Server
REM Für Warteschleife bis alle VMs und dann ESX Server heruntergefahren sind um MSA abzuschalten.
SET server03=192.x.x.x 192.x.x.x
REM ESXShutDown
@start "" c:\_batch_usv\plink.exe -ssh -pw ************ -8 root@192.x.x.x "/sbin/shutdown.sh && /sbin/poweroff"
@start "" c:\_batch_usv\plink.exe -ssh -pw ************ -8 root@192.x.x.x "/sbin/shutdown.sh && /sbin/poweroff"
REM ESX Warteschleife vor MSA Shutdown
:ESXCheck
(for %%c in (%server03%) do (
PING %%c -n 1 |Find "TTL=" >nul
if !ERRORLEVEL! == 0 goto ESXCheck))
REM MSAs werden heruntergefahren
REM MSA 0001
@start "" C:\_batch_usv\plink.exe 192.x.x.x -v -ssh -l Administrator -pw ********** < msa-script.txt
@start "" C:\_batch_usv\plink.exe 192.x.x.x -v -ssh -l Administrator -pw ********** < msa-script.txt
REM MSA 0002
@start "" C:\_batch_usv\plink.exe 192.x.x.x -v -ssh -l Administrator -pw ********** < msa-script.txt
@start "" C:\_batch_usv\plink.exe 192.x.x.x -v -ssh -l Administrator -pw **********< msa-script.txt
REM Physicher Server1 ShutDown,
shutdown -s -m \\192.x.x.x -C "Shutdown nach Stromausfall" -t 25
REM Physicher Server1 ShutDown
shutdown.exe /s /f /t 10
endlocal
Ist der Code OK?
Werden die Physischen Server nach erfolgreicher Stormversorgungsaufbau wieder von alleine gestartet oder sollte ich die Server separat mit USV Agent runterfahren lassen?
Das große Problem ist aber, das ich im vSphere Client die Funktion "Starten und Heruntefahren von virtuellen Maschinen" nicht aktivieren kann.
"Bearbeiten" ist ausgegraut und der Hinweis "Wenn der Host Teil eines vSphere HA-Clusters ist, wird das automatische Starten und Herunterfahren von virtuellen Maschinen deaktiviert" ist hinterlegt.
Ist mein Script somit hinfällig und ich muss mir was anderes einfallen lassen?
Aber es muss doch eine einfache Lösung geben um das VM Umfeld ohnegroße Programmiererei bei Stromausfall sicher herunterzufahen und wieder hochfahren zu können.
Über Eure Hilfe wäre ich dankbar.
Gruß
Kalma
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 666015
Url: https://administrator.de/contentid/666015
Ausgedruckt am: 22.11.2024 um 05:11 Uhr
9 Kommentare
Neuester Kommentar
Moin,
Grundsätzlich sollte die schon ausreichend sein, aber wichtigste Frage wäre da, wo ist die Management Software installiert. Für VMWare gibt es für die R5000 folgende Doku: https://support.hpe.com/hpesc/public/docDisplay?cc=us&docId=emr_na-c ...
Dann wäre noch die Frage, wie alt die R5000 und insbesondere deren Batterien sind?
Deine Ausführungen im Eingangspost klingen etwas unvollständig, ohne die Umgebung komplett zu kennen, kann man da schlecht eine Entscheidung treffen.
Zunächst mal folgende Rückfragen/Hinweise:
- Wo soll das Script laufen, das wird nicht so klar, da wenn es in einer der VMs läuft, es vermutlicxh so nicht funktionieren wird.
Gruß
cykes
Grundsätzlich sollte die schon ausreichend sein, aber wichtigste Frage wäre da, wo ist die Management Software installiert. Für VMWare gibt es für die R5000 folgende Doku: https://support.hpe.com/hpesc/public/docDisplay?cc=us&docId=emr_na-c ...
MSA HP P2000 und 2060
Das sind nur Storage-Systeme, da muss es noch ein oder mehrere Server (Hosts) zu geben, hängen diese auch an der R5000?Dann wäre noch die Frage, wie alt die R5000 und insbesondere deren Batterien sind?
Deine Ausführungen im Eingangspost klingen etwas unvollständig, ohne die Umgebung komplett zu kennen, kann man da schlecht eine Entscheidung treffen.
Zunächst mal folgende Rückfragen/Hinweise:
- Wo soll das Script laufen, das wird nicht so klar, da wenn es in einer der VMs läuft, es vermutlicxh so nicht funktionieren wird.
vSphere 7.0.1
[...] vSphere Client
- meinst Du damit den fat client oder das Webinterface des Hosts? Bei ersterem wäre es für ESXi 7.x das falsche Tool.[...] vSphere Client
"Wenn der Host Teil eines vSphere HA-Clusters ist, wird das automatische Starten und Herunterfahren von virtuellen Maschinen deaktiviert"
- Dann brauchst Du erstmal Zugriff auf den vCenter Server, wenn das wirklich ein Cluster ist. Hinweis: Bitte in einem Cluster nicht auf einzelnen Hosts rumfummeln, das geht in die Hose.Aber es muss doch eine einfache Lösung geben um das VM Umfeld ohnegroße Programmiererei bei Stromausfall sicher herunterzufahen und wieder hochfahren zu können.
Die gibt es auch, nennt sich UPS/USV Management Software. Dann muss man nicht mit lokalen Scripten rumbasteln, die dann nur leidlich funktionieren. Aufgrund des vermutlichen Alters der USV könnte es aber sein, dass die Software nicht mehr kompatibel zu ESXi 7.x ist.Gruß
cykes
Hängen alle Hosts an derselben USV?
Kann der USV-Agent gegebenenfalls auf jeder VM installiert werden? Will heißen: Es wird so getan, als ob die VM's physisch existieren würden.
Da der Agent augenscheinlich zwischen Standalone und Cluster unterscheidet, würde ich zunächst einmal eruieren, wie das Verhalten in einem Cluster konfiguriert werden kann / soll. Vielleicht können dann ja doch die VM's sauber heruntergefahren werden, ohne mit einem Script hantieren zu müssen.
Viele Grüße
HansDampf06
PS: Noch einen Tipp - Beim Herunterfahren von VM's kann es trügerisch sein, anhand der Reaktion auf einen Ping zu entscheiden, ob die VM bereits ausgeschaltet ist. Bei Linux können unter Umständen (mehrere) Wartemomente von längerer Dauer aktiv sein. Hier sollte besser der Hypervisor über den Status befragt werden, weil der es ganz genau wissen muss.
Kann der USV-Agent gegebenenfalls auf jeder VM installiert werden? Will heißen: Es wird so getan, als ob die VM's physisch existieren würden.
Da der Agent augenscheinlich zwischen Standalone und Cluster unterscheidet, würde ich zunächst einmal eruieren, wie das Verhalten in einem Cluster konfiguriert werden kann / soll. Vielleicht können dann ja doch die VM's sauber heruntergefahren werden, ohne mit einem Script hantieren zu müssen.
Viele Grüße
HansDampf06
PS: Noch einen Tipp - Beim Herunterfahren von VM's kann es trügerisch sein, anhand der Reaktion auf einen Ping zu entscheiden, ob die VM bereits ausgeschaltet ist. Bei Linux können unter Umständen (mehrere) Wartemomente von längerer Dauer aktiv sein. Hier sollte besser der Hypervisor über den Status befragt werden, weil der es ganz genau wissen muss.
Das automatische Hochfahren von physischen Computern, wenn der Stromausfall beendet wird, ist eigentlich eine Aufgabe des jeweiligen BIOS. Denn das Herunterfahren führt zu einem kompletten Abschalten des betreffenden Computers.
Wenn die USV richtig kalibriert ist, schaltet sie die Sekundärseite ebenfalls erst nach dem Herunterfahren aller Systeme ab. Nur das neue Einschalten der Sekundärseite ist dann das Signal an die physischen Computer, gegebenenfalls wieder neu zu starten. Etwas anderes kann nur gelten, wenn das Mainboard einen besonderen KVM-Netzzugang hat und an diesen irgendein Aufwachkommando gesendet werden könnte. Doch wozu, wenn der zurückkehrende Strom ein eindeutiges und immer funktionierendes Signal ist.
Die Existenz einer solchen Steuerungsmöglichkeit wage ich daher stark zu bezweifeln. Denn - auch wenn ich die R5000 nicht kenne - glaube ich nicht, dass deren Hersteller etwas kann, was nicht auch APC schon längst realisiert hätte. Bei der Management-Software von APC ist mir eine solche Möglichkeit bisher jedenfalls nicht bekannt. Somit bleibt nur die BIOS-Variante nach vorheriger Abschaltung der Sekundärseite.
Viele Grüße
HansDampf06
Wenn die USV richtig kalibriert ist, schaltet sie die Sekundärseite ebenfalls erst nach dem Herunterfahren aller Systeme ab. Nur das neue Einschalten der Sekundärseite ist dann das Signal an die physischen Computer, gegebenenfalls wieder neu zu starten. Etwas anderes kann nur gelten, wenn das Mainboard einen besonderen KVM-Netzzugang hat und an diesen irgendein Aufwachkommando gesendet werden könnte. Doch wozu, wenn der zurückkehrende Strom ein eindeutiges und immer funktionierendes Signal ist.
Die Existenz einer solchen Steuerungsmöglichkeit wage ich daher stark zu bezweifeln. Denn - auch wenn ich die R5000 nicht kenne - glaube ich nicht, dass deren Hersteller etwas kann, was nicht auch APC schon längst realisiert hätte. Bei der Management-Software von APC ist mir eine solche Möglichkeit bisher jedenfalls nicht bekannt. Somit bleibt nur die BIOS-Variante nach vorheriger Abschaltung der Sekundärseite.
Viele Grüße
HansDampf06
Bliebe zu ermitteln, ob HA aktiviert ist oder nicht. Sind die Storages (MSAs) shared storage zwischen zwei Hosts?
Ansonsten könnte bei aktiviertem HA einfach ein Deaktivieren gefolgt vom Aktivieren helfen.
Vgl. https://vmware-forum.de/viewtopic.php?t=31330 (letzter Post)
Das "Problem" gab's wohl schon bei früheren VMWare-Versionen.
Wurde das System frisch installiert oder war das ein Upgrade 6 -> 7 oder so....?
Ansonsten könnte bei aktiviertem HA einfach ein Deaktivieren gefolgt vom Aktivieren helfen.
Vgl. https://vmware-forum.de/viewtopic.php?t=31330 (letzter Post)
Das "Problem" gab's wohl schon bei früheren VMWare-Versionen.
Wurde das System frisch installiert oder war das ein Upgrade 6 -> 7 oder so....?
Zitat von @Kalma73:
OK, das mit dem automatisch starten müsste klappen.
Weil als wir die Server aufgebaut haben, sind diese nach dem einstecken der Stromkabel von alleine gestartet.
Das Hauptproblem ist aber, das ich in der vSphere Console die Reihenfolge der Server fürs herunterfahren und wieder starten nicht bearbeiten kann.
"Wenn der Host Teil eines vSphere HA-Clusters ist, wird das automatische Starten und Herunterfahren von virtuellen Maschinen deaktiviert"
Das ist auch normal, die Meldung.OK, das mit dem automatisch starten müsste klappen.
Weil als wir die Server aufgebaut haben, sind diese nach dem einstecken der Stromkabel von alleine gestartet.
Das Hauptproblem ist aber, das ich in der vSphere Console die Reihenfolge der Server fürs herunterfahren und wieder starten nicht bearbeiten kann.
"Wenn der Host Teil eines vSphere HA-Clusters ist, wird das automatische Starten und Herunterfahren von virtuellen Maschinen deaktiviert"
Die Definition zur Startreihenfolge der VMs wurde mal hier ganz gut beschrieben: https://www.sikich.com/insight/setting-virtual-machine-start-order-with- ...
Das klappt auch für VMware 7.x (danach haben wir es ebenfalls umgesetzt)
Bei im Standard starten alle VMs direkt durch, sobald der Host wieder da ist. Mit obigen Link kannst du das steuern. Bei uns müssen auch erst die DCs gestartet sein, bevor das vCenter starten darf. erst wenn das läuft, starten die Administrationsserver, gefolgt vom Exchange, gefolgt vom ERP, ...
Zum Schluss sind dann unsere Terminalserver dran. damit ist gewährleistet, dass alles läuft, bevor die Jungs und Mädels wieder dürfen
Da hat wohl ein Systemtechniker vom Distributor bei der vorkonfiguration einen Fehler gemacht oder ist das ein Bug von vSphere 7.0.1
Nöö, works as designed Gruß
em-pie