VMWare-Umgebung durch USV herunterfahren

[PAT 10]

Hallo zusammen,

 

ich habe hier ein Problem, welches auf den ersten Blick recht einfach erscheint, das aber irgendwie zur neverending Story mutiert.

 

Folgende Ausgangssituation: Zwei VMWare-Server mit vSphere 4 Enterprise (dahinter hängt noch ein Fibrechannel-Storage). Als USV kommt eine Effekta Pegasus in Einsatz. Effekta dürfte für die meisten hier kein Begriff sein, allerding setzen die einen SNMP-Adapter und die Shutdown-Software "RCCMD" ein, welche bei den meisten USV-Herstellern ebenfalls verwendet wird.

 

Nun sollen mittels dieser Software die Server heruntergefahren werden, sobald die USV eine gewisse Kapazität unterschreitet. Hierzu gibt die USV über den SNMP-Adapter ein Signal ins Netzwerk, welches von der RCCMD-Software interpretiert wird, diese fährt dann den Server herunter.

 

Dies funktioniert bei den physikalischen Servern auch ohne Probleme, allerdings möchte ich natürlich auch die VMWare-Umgebung herunterfahren.

Spricht die USV soll die Hosts herunterfahren, welche vorab die VMs herunterfahren.

Und hier (vor allem bei den Hosts) fängt mein Problem an.

 

- Das Systemhaus, dass die VM-Umgebung eingerichtet hat, will nichts davon wissen. Offiziell sagen die entweder, es funktioniert nicht, oder behaupten, diese Geschichte wäre von VMWare nicht supportet. Aber im Grunde haben die auftragsmäßig Land unter und zeigen keinerlei Interesse an einer Lösung.

 

- Effekta als USV-Hersteller verweist auf Generex als Hersteller von SNMP-Adapter und Shutdown-Software.

 

- Generex sagt, dass es geht und bietet sogar unter http://www.generex.de/generex/download/manuals/manual_RCCMD_Win_Unix_Mac_en.pdf eine Anleitung. Zudem gibt's eine Kompatibilitätsliste unter http://www.generex.de/generex/download/misc/database_UPSSUITE-OSVersions_en.pdf, in welcher VMWare aufgeführt wird, allerdings kann ich vSphere 4 Enterprise dort nicht genau zuordnen.

 

- Generex verweist außerdem auf den Händler "Online USV", welcher für seine Produkte eine VMWare-Zertifizierung anbietet. Generex hat mir schriftlich bestätigt, dass es sich bei den Produkten von "Online USV" um Generex-Produkte handelt, lediglich ein anderes Label drauf klebt.

 

- Online USV bestätigt dies indirekt und weist auf ein ein Support Statement unter http://www.online-usv.de/downloads/formulareundmerkblaetter/supportstatement_vmware_de_2009-09-29.pdf hin, in welchem sie beschreiben, dass eine VMWare-Zertifizierung besteht. Allerdings bezieht sich dieses Statement auf Partnummern von Online USV und zudem ist es auf dem Jahr 2008, nirgendwo wird ersichtlich, auf welche VMWare-Version sich dieses Statement bezieht, geschweige denn, dass das Statement sich explizit auf vSphere 4 bezieht.

 

- Natürlich könnte ich rein theoretisch die Software nach der Anleitung von Generex selber installieren, traue mich aber ehrlich gesagt nicht so ganz ran. Wenn da was schief läuft, geht u.U. die ganze VMWare-Umgebung nicht mehr.

 

Ich weiß nicht, was daran so schwierig sein soll. Ich glaube auch nicht, dass ich der einzige bin, der sowas umsetzen will.

 

Wie habt ihr das bei euch realisiert? Ist das wirklich so ein Akt oder bauschen die beteiligten das Thema nur unnötig auf?

bearbeitet 13. Juli 2010 von PAT

[zahni 554]

Hi,

 

ich wüsste nicht, was gegen RCCMD spricht. Obwohl VMWare fremde Software in der Service Console nur bedingt supported. Und RCCMD arbeitet meines Wissens nach mit einem eigenen Protokoll.

Auspassen: Nicht die selbe Serienummer mehrfach verwenden. Sonst sperrt der Managment-Adapter in der USV diese IP-Adresse aus.

 

Wichtig: Bei ESX 3.5 (bei 4.0 nicht getestet), bewirkt ein Shutdown viw Rccmd in der Service Console ein shutdown des ESX-Servers. Nicht der laufenden VM's (!!!). Die werden dabei hart ausgeschaltet.

 

Bei ESX 3.5 habe ich das Shutdown-Script wie folgt geändert:

 

cat rccmd_shutdown.sh
#!/bin/sh

# rccmd_shutdown.sh - This script is called by rccmd after receiving
# the "SHUTDOWN" command from the network.

# available parameters are:
# $@ - optional

error_exit() {
   echo $@ >/dev/console
   exit 1
}

MESSAGE=${@:-""}   # not all versions of "shutdown" support a custom message!

[b]for vm in `vmware-cmd -l`
do
       [color="Red"]vmware-cmd "$vm" stop trysoft[/color]
#       vmware-cmd "$vm" stop hard
done[/b]
sleep 30

cd /                            # some systems need this!

shutdown -h now &                       # do not wait :-)

[PAT 10]

Obwohl VMWare fremde Software in der Service Console nur bedingt supported.

Genau da liegt ein Teil des Problems. Wenn dort was schief läuft, könnte es doch sein, dass VMWare sagt "Pech gehabt, da nicht supportete Lösung verwendet wurde", oder?

 

Wichtig: Bei ESX 3.5 (bei 4.0 nicht getestet), bewirkt ein Shutdown viw Rccmd in der Service Console ein shutdown des ESX-Servers. Nicht der laufenden VM's (!!!). Die werden dabei hart ausgeschaltet.

Im vSphere-Client (vormals unter 3.5 Infrastructure Client) kann ich bei dem Hosts unter "Konfiguration -> VM Starten/Herunterfahren" konfigurieren, dass virtuelle Maschinen mit dem System heruntergefahren werden.

Könnte das von Dir beschriebene Problem nicht dadurch gelöst werden?

[zahni 554]

1. Frage: So schlimm wird das mit dem offiziellen VMWare-Support schon nicht ;)

 

2. Kann sein, solltest Du testen: Aktivieren und im der Service Console "Shutdown" eingeben. Wichtig: der Shutdown um VI-Client unterscheidet sich u.U. von direkten befehlen in der Service Console.

 

Wir benutzen VMotion, daher ist diese Variante nicht praktikabel.

 

-zahni

[unst 10]

ist das nen cluster oder zwei verschiedene ESXs? Wenns nen Cluster ist, ists ja relativ unkristisch wenn ESX1 rum-muckt...

[zahni 554]

@unst,

 

Deine Antwort verstehe ich, in Bezug auf die ursprüngliche Frage, nicht

[PAT 10]

Wir benutzen VMotion, daher ist diese Variante nicht praktikabel.

Hmm, wir auch. Meinst Du das so, dass der Host versuchen könnte, beim herunterfahren die VM zu verschieben statt ebenfalls zu beenden?

 

 

@unst

Du scheinst das nicht ganz verstanden zu haben.

Die Hosts sind in einem Cluster. Es geht aber darum, dass die USV beide Hosts und die VMs herunterfahren soll, wenn ihr der Saft ausgeht.

[zahni 554]

@Pat,

 

hängen alle Cluster-Teilnehmer an der selben USV ?

 

Wenn ja, ist das Verschiebe eher sinnfrei.

 

Da hilft das Script oben. Das fährt alle VM's sauber runter (wenn die VMWare-Tools installiert sind), die gerade auf dem "Blech" laufen.

 

-Zahni

[PAT 10]

Ja, die selbe USV.

Ich will ja auch nichts verschieben, sondern automatisiert runterfahren.

 

Wichtig: Bei ESX 3.5 (bei 4.0 nicht getestet), bewirkt ein Shutdown viw Rccmd in der Service Console ein shutdown des ESX-Servers. Nicht der laufenden VM's (!!!). Die werden dabei hart ausgeschaltet.

Da hilft das Script oben. Das fährt alle VM's sauber runter (wenn die VMWare-Tools installiert sind), die gerade auf dem "Blech" laufen.

Was gilt nun? Fahren dadurch die VMs nun runter?

[unst 10]

was ich meinte: wenn du auf dem ESX1 die software installierst und es läuft etwas schief laufen die VMs halt auf dem ESX2 weiter es gibt keinen Ausfall. Mit dem Urspungsproblem hat es nicht direkt etwas zu tun. Es ging nur um "schadensbegrenzung".

 

So, jetzt ist da der ganze Gedanke nicht nur das Ende ;)

[PAT 10]

OK, wenn die Installation auf dem einen Host schief läuft, habe ich noch den anderen, das stimmt. Aber dann habe ich das Problem, wie ich den Host wieder in den alten Zustand zurück versetze. Support von dem Systemhaus erhalte ich dann keinen.

[zahni 554]

Zum Script:

 

Das ist ein einfahces BASH-Script.

 

Ein paar Linux-Grundkenntnisse sind bei VMWare sinnvoll. Das Script ermittelt alle laufenden VM's mit vmware-cmd -l und fährt die VM's in der FOR-Schleife mit vmware-cmd einzeln runter.

 

VmWare-cmd ist Bestandteil der Service Console.

 

-Zahni