VMware-Forum

Hallo,

ich komm grad bei einer Frage nicht weiter.

Ich plane gerade Notfalltests die bestimmte Ausfall Szenarien abdecken sollen und bin auf die Frage gestoßen was passiert,
wenn ein Host die Verbindung zum Storage über alle Pfade verliert und die VMs somt auf den Boden fallen? Greift HA hier auch?

Zum besseren Verständnis kurz die Umgebung erläutert.

3 ESXi 4.1 U2 als HA Cluster mit Essentials Plus Lizenzen
Jeder ESXi hat einen Dual Port HBA.
Die Ports sind jeweils auf einer anderen FC Fabric verbunden.
Storage Controller dito.
(Quasi klassische redundante Storage Anbindung)
Die Netzwerkkonfiguration sollte bei Betrachtung der Frage nicht relevant sein.

Der Ausfall eines einzelnen HBA-Ports am ESX-Host stellt kein Problem dar.

Was aber passiert wenn sich die Karte (Dual Port HBA) komplett verabschiedet, und beide Ports weg sind?
Der ESXi hat keinen Zugriff auf den Storage und die VM fällt wie bei einem "Hard Poweroff" auf die Nase. Soweit klar.
Greift "HA" in diesem Fall? Der Host ist ja weiterhin über das Netzwerk erreichbar.
Und falls "HA" nicht greift, wie sieht es mit einem manuellen Neustart der VM auf einem anderen Host im Cluster aus?
Die VM ist ja noch auf dem ESXi ohne Storage Verbindung registriert, kann die VM dann auf einem anderen Host neugestartet werden?

Gruß
Stefan

In erster Linie ist es erstmal schlechtes Design beide Ports für ein Storage auf den gleichen HBA zu legen. Das ein einzelner Port kaputt geht ist sicherlich seltener als das gleich die ganze Karte aussteigt.
HA würde wahrscheinlich greifen wenn der VMWare-Tools Heartbeat ausbleibt weil die VM nicht mehr reagiert oder einen Bluescreen geworden hat. Ausprobiert habe ich das aber noch nicht. VM-Monitoring muss dazu natürlich an sein.
Allerdings geht mir gerade durch den Kopf dass das VM-Monitoring ja nur die VM neustartet. Ob HA dann eingreift wenn de Storage weg ist und die VM gar nicht neu starten kann entzieht sich meiner Kenntnis.

Hi!
HA greift im Falle eines Storageausfalls NICHT ein!
Der ESX erkennt nen "All paths down" für den Datastore, und die VM würden ohne platte weiterlaufen, bis ggf. Windows oder die Applikation nen Bluescreen erzeugt.

VM Monitoring von HA bringt aber in dem Fall auch nix, da ein neustart der VM auf dem gleichen ESX (jetzt ja immer noch ohne Storage) nicht klappen wird.

Der HBA ist also in Deinem Design in der Tat ein Single Point of Failure, der durch keinen Mechanismus auf VMware Ebene abgefangen werden kann.

Viele Grüße,
Jörg

Moin moin,

HA greift im Falle eines Storageausfalls NICHT ein!

Ich hatte es mir schon gedacht, war mir aber unsicher. Danke.

Was den HBA als SPOF angeht da habt ihr natürlich recht. Die Tatsache als solche ist uns auch durchaus bewusst,
deswegen soll das Verhalten bei komplettem Pfad Ausfall auch getestet werden.

Daher auch meine Frage von oben nochmal wiederholt:
- Der ESX auf dem die VM läuft verliert alle Pfade zum Storage.
- Die VM "lebt" erstmal so lange weiter bis die OS Disk Timeouts erreicht sind und dann gibts z.B. nen BSOD. => VM tot.
- VM ist/bleibt am ESX registriert. kein HA

Wie kann/sollte man in diesem Fall vorgehen um die VM auf einem anderen Host neu zu starten?

Ich stell mir das ungefähr so vor:
- VM auf dem vom Pfad Ausfall betroffenen ESX ausschalten (Hard Poweroff)
- "offline"-Vmotion der VM auf einen ESX-Host mit aktiven Storage Pfaden
- starten der VM auf dem neuen Host
(Evtl. ist hier mal wieder nur der Wunsch Vater des Gedanken...??)

Ist aber auch alles nur "Vermutung" vielleicht hat ja jemand schon Erfahrung(en) und Hinweise mit welchen Komplikationen zu rechnen sein könnte.

Das worum es mir letzendlich geht ist einen definierten Weg zu haben eine VM in so einem Fall wieder ins Leben zurück zu holen.


Gruß Stefan

Ich stell mir das ungefähr so vor:
- VM auf dem vom Pfad Ausfall betroffenen ESX ausschalten (Hard Poweroff)
- "offline"-Vmotion der VM auf einen ESX-Host mit aktiven Storage Pfaden
- starten der VM auf dem neuen Host

Vmotion geht dann nicht, weil ja keine Pfade mehr. Aber Du kannst die Maschinen auf einem anderen ESX neu registrieren (halt händisch machen, was Vmotion automatisch erledigt) und dann neu starten.

"offline" vMotion war eher so gemeint, dass ich die VM über das vCenter auf einem anderen Host neustarte, nachdem sie ausgeschaltet wurde.
Das ganze findet ja in einem Cluster mit 3 Hosts statt.
Netzwerk Verbindungen sind ja vorhanden, warum sollte das per vMotion nicht gehen??

steh grad aufm Schlauch...

...und bitte um Erleuchtung

Wenn du das Wort vMotion verwendest dann denkt hier jeder das du noch was im lfd. Betrieb verschieben willst. Aber da ist nichts mehr was laeuft.

Ein neuregistieren wird daran scheitern vCenter die VM ja erstmal schon kennt und ein De-Register von VMs welche gerade nicht verfuegbar sind eine fummelige angelegenheit ist.

Probier es halt mal aus mit einer Test VM.

Gruss
Joerg

das verlieren des Storages ist das dämlichste was einem passieren kann. Da die VM auf einem anderen Host als Zombie weiter läuft, kann man sie nicht eben auf einem anderen Host weiter laufen lassen. Wenn man versucht diese VM per "hard power off" auszuschalten, meckert der Host, auf dem sie noch läuft, weil er natürlich keinen Zugriff auf die vmx und vmdks hat. Ich habe das hier mal getestet und das Ergebnis war recht unbefriedigend. Im Extremfall hilft es nur, den Host auszuschalten, auf dem die VM lief, damit die anderen Host hier übernehmen können.

Ich kann nur anraten das mal zu testen, ist recht frustrierend.

@irix: hast recht der Begriff ist bei vielen (generell auch zu Recht) mit "im laufenden Betrieb" verbunden.
Allerdings gibt/gab es ja das "Offline" vMotion durchaus und ich wollte nach der Aussage von Deathrow

Vmotion geht dann nicht, weil ja keine Pfade mehr. Aber Du kannst die Maschinen auf einem anderen ESX neu registrieren

nur darauf hinweisen, dass ich die VM gerne übers vCenter auf einen anderen Host gelegt hätte und mir dachte:
Naja vielleicht ist das "vMotion" so gut , dass es einen Weg hat die VM auf dem Host ohne Storage Pfad auszuschalten und dann auf einem anderen Host neu zu starten...
Dann wär man ja auch das "Zombie"-Problem los gewesen.

Mir war halt nicht klar, dass der Host ohne Storage Pfad sich doch so hartnäckig wehren würde die VM her zu geben.

Das neu registrieren war genau der Knackpunkt der mir diesbezgl. Sorgen macht, weil genau das was du sagst, ist mir auch schon durch den Kopf gegangen:
VM die im vCenter schon bekannt ist, auf einem anderen Host registrieren => nicht gut (wie mangold sagte ="Zombie")

@mangold

Da die VM auf einem anderen Host als Zombie weiter läuft, kann man sie nicht eben auf einem anderen Host weiter laufen lassen.
Wenn man versucht diese VM per "hard power off" auszuschalten, meckert der Host, auf dem sie noch läuft, weil er natürlich
keinen Zugriff auf die vmx und vmdks hat. Ich habe das hier mal getestet und das Ergebnis war recht unbefriedigend

Das war die Info die mir quasi noch fehlte.
Das Auschalten eines Hosts der keine aktiven VMs mehr hat könnte ich verschmerzen.
Wobei das glaub ich dann entweder auf der Console per Shutdown Befehl oder "Knöpfchen" drücken am Blech gemacht werden müsste?!
Weil das vCenter ja meint, das es auf dem Host noch eine laufende VM gibt, gell?

Soweit so gut...
um das noch mal in Form zu bringen:

- Der ESX auf dem die VM läuft verliert alle Pfade zum Storage.
- Die VM "lebt" bis zum OS Disk Timeout
- je nach OS der VM z.B. nen BSOD. => VM tot.
- VM ist/bleibt am ESX registriert (unser Zombie) und lässt sich nicht ausschalten
- kein HA

Um die VM wieder lauffähig zu bekommen
- ESX Host ausschalten (Dann wird eben die VM quasi mit ausgeschaltet.)
- Hier müsste doch dann HA eigentlich wieder greifen, da für das vCenter die VM immer noch "poweredOn" ist und der Host "ausgefallen", oder nicht?
- Neustart der VM (per HA oder manuell)

...oder bewege ich mich nach wie vor auf dem Holzweg???

Danke für eure Geduld
Gruß Stefan

straight_way hat geschrieben:@irix: hast recht der Begriff ist bei vielen (generell auch zu Recht) mit "im laufenden Betrieb" verbunden.
Allerdings gibt/gab es ja das "Offline" vMotion durchaus und ich wollte nach der Aussage von Deathrow

Vmotion geht dann nicht, weil ja keine Pfade mehr.

Der Punkt heisst aber Migrate im Menu und je nach Zustand sind dann mehrere Arten der Migration moeglich. Cold oder Hot.... und letzteres ist das was Umgangssprachig vMotion heisst.

Aber nun wissen wir ja was du wolltest .

Guck mal obs nen VMware KB Artikel gibt um "orphan(e)" VMs wieder zuerwecken.

Gruss
Joerg

- ESX Host ausschalten (Dann wird eben die VM quasi mit ausgeschaltet.)

Glaube ich nicht so wirklich, wie will die VM (d.h. die Dateien der VM) das mitbekommen? Es besteht ja keine Verbindung mehr.

deathrow hat geschrieben:

- ESX Host ausschalten (Dann wird eben die VM quasi mit ausgeschaltet.)

Glaube ich nicht so wirklich, wie will die VM (d.h. die Dateien der VM) das mitbekommen? Es besteht ja keine Verbindung mehr.

das Problem ist ja nicht die VM, die ist eh im Bluescreen. Problem bei der ganzen Geschichte, ist dass der Host weiterläuft und dadurch eine Verbindung ins Virtual Center hat. Dieses"glaubt" natürlich, dass die VM noch weiter läuft, Status im Host und Virtual Center ist ja immer noch "powered on", so das die VM nicht woanders eingeschaltet werden kann. Des weiteren gibt es Locks auf der vmdk, die auch nicht sofort beseitigt werden, wenn der Host den Kontakt zu den datastores verliert. Diese Locks verhindern auch wieder das starten auf einem anderen Host.

Im Grunde hat man einen schwebenden Zustand, und ich kann nur aus pers. Erfahrung sagen (die Erfahrung besteht aus lediglich 2 Stunden frustriertem rumknobeln), dass man das vorher testen sollte und das nicht so banal ist, wie man sich das vorstellt.

Des weiteren gibt es Locks auf der vmdk, die auch nicht sofort beseitigt werden, wenn der Host den Kontakt zu den datastores verliert. Diese Locks verhindern auch wieder das starten auf einem anderen Host.

Genau das sehe ich als Problem.

Bei den Hosts reicht u.U. ja Neustart oder Management-Neustart.

@irix

Der Punkt heisst aber Migrate im Menu und je nach Zustand sind dann mehrere Arten der Migration moeglich. Cold oder Hot.... und letzteres ist das was Umgangssprachig vMotion heisst.

Aber nun wissen wir ja was du wolltest .

Ich wollte den Text "kurz" halten und nicht zu viel erklären. aber jetzt haben wirs ja.

@deathrow

Glaube ich nicht so wirklich, wie will die VM (d.h. die Dateien der VM) das mitbekommen? Es besteht ja keine Verbindung mehr

Die VM hat keine Verbindung zum Datastore (so wie der Host auch) läuft aber nach wie vor noch auf dem ESX. Und wenn's eben "nur" das anzeigen eines Blue Screens ist.
Wird der ESX ausgeschaltet, sollte ,nach meinem Verständnis, die VM unweigerlich mit ihm sterben.

@mangold

Des weiteren gibt es Locks auf der vmdk, die auch nicht sofort beseitigt werden, wenn der Host den Kontakt zu den datastores verliert. Diese Locks verhindern auch wieder das starten auf einem anderen Host.

Wobei es doch so sein sollte, dass die File Locks immer nur eine bestimmte Lebensdauer haben und dann vom Host auf dem die VM läuft erneuert werden.
Bricht der Storage weg können die Locks nicht erneuert werden und andere Hosts sollten die VM starten können.
So ist es zumindest, meine ich, in den HA Guides von Vmware immer beschrieben worden.
Und nichts anderes passiert doch auch wenn mir der ESX aus anderen Gründen mit laufenden VMs stirbt und dann HA eingreift und die VMs neustarten will.

der "Zombie" im vCenter resultiert ja daraus dass der ESX noch mit dem vCenter kommuniziert und ja Recht hat wenn er sagt: VM is "poweredOn".
Wobei sich dieser Status ja durch das auschalten des ESX erledigen lassen sollte... (hätte/wäre/könnte)

straight_way hat geschrieben:So ist es zumindest, meine ich, in den HA Guides von Vmware immer beschrieben worden.
Und nichts anderes passiert doch auch wenn mir der ESX aus anderen Gründen mit laufenden VMs stirbt und dann HA eingreift und die VMs neustarten will.

der "Zombie" im vCenter resultiert ja daraus dass der ESX noch mit dem vCenter kommuniziert und ja Recht hat wenn er sagt: VM is "poweredOn".
Wobei sich dieser Status ja durch das auschalten des ESX erledigen lassen sollte... (hätte/wäre/könnte)

das Eingreifen von HA - also das Hochfahren einer im VC registrierten VM wenn ein Host wegstirbt - ist ein kontrollierter Vorgang. Ich bin mir nicht sicher ob das "wegbrechen" des kompletten Datastores so von VMware eingeplant ist.

Mich würde es aber auch interessieren, wie der ESX Server das mit den Locks auf den Disks genau macht, denn der "tote" Host kann die Locks ja nicht löschen.

Mich würde es aber auch interessieren, wie der ESX Server das mit den Locks auf den Disks genau macht, denn der "tote" Host kann die Locks ja nicht löschen.

Genau das meine ich!

Die vswap kann ich händisch knicken, aber die locks ja nicht...

Ich finds klasse das hier eine so muntere Diskussion entstanden ist

@mangold

das Eingreifen von HA - also das Hochfahren einer im VC registrierten VM wenn ein Host wegstirbt - ist ein kontrollierter Vorgang. Ich bin mir nicht sicher ob das "wegbrechen" des kompletten Datastores so von VMware eingeplant ist.

ich denke auch dass das "wegbrechen" des Datastores nicht unbedingt von Vmware so eingeplant ist.

Allerdings sehe ich HA nur bedingt als einen "kontrollierten Vorgang", eher als eine Reaktion auf ein (un)erwartetes Ereignis.
Denn das ein Host gleich den Löffel abgibt, weil z.B. eine CPU oder der Speicher hin ist, kündigt er auch nicht vorher an sondern
zeigt den PSOD i.d.R. erst wenn das Kind im Brunnen liegt.
Alle auf dem Host bis dato aktiven VMs sind tot, erst dann können die verbliebenen Hosts reagieren und die VMs neustarten.

Ich hab grad noch mal ein wenig rumgewühlt und Duncan Eppings HA-DeepDive gelesen http://www.yellow-bricks.com/vmware-high-availability-deepdiv/#HA-isolationresponse

Im Abschnitt "vSphere 4.1 specifics (AAM) \ Isolation Response" wird auf auf ein "Split Brain" Szenario eingegangen.
In dem Beispiel fällt ebenfalls der Storage Pfad aus (iSCSI/NFS), allerdings zeitgleich mit dem Management Network, wodurch ja dann HA ausgelöst wird.

Auch wenn HA in meinem Beispiel nicht ausgelöst wird, vermute ich dass sich die weiteren Mechanismen (vmdk locking usw.) gleich verhalten.
Denn schalte ich den Host mit der im VC noch laufenden VM (die längst einen BSOD zeigt) aus, müsste HA entsprechend auslösen
und ein anderer Host die VM neustarten wollen, und wichtiger: können.

Gruß
Stefan

PS: Evtl. laufe ich grad Gefahr den Stempel "Beratungs resistent" zu bekommen.
# Was nicht mein Ziel ist deswegen habt ein wenig Nachsicht
# Ich muss halt für den Moment mit meiner Config so klar kommen und deshalb einen definierten Weg zum wiederanlauf der VMs finden

Hi!
Wenn ein ESX die Verbindung zum Storage verliert, werden die filelocks automatisch aufgehoben, und zwar ziemlich schnell (innerhalb weniger Sekunden).

ein Registrieren der VM auf nem anderen ESX und starten der VM ist also möglich (manuell). Allerdings wohl nicht über das vCenter, sondern nur lokal am "ziel"-Host, weil das vCenter die VM ja noch auf dem "quell"-ESX kennt.

Wenn Du's ganz sauber machen willst, müsstest Du also vorher die VM auf dem host ohne storage de-registrieren (falls das noch funktioniert bei nem All-paths-down)...

Sowas lässt sich übrigens gut durchspielen mit nested (virtuellen) ESX servern und IP-Storage.
Dabei immer auch die vmkernel-logs der betreffenden ESX mitlesen, da sollte einiges drinstehen bei storage-ausfällen.

Es gab früher mal ne Option -D für die vmkfstools, mit denen man sich die Locks und deren Urheber anzeigen lassen konnte ( http://www.google.com/search?q="vmkfstools+-D"+site%3Avmware-forum.de ), keine Ahnung, ob die noch existiert...

Viele Grüße,
Jörg

Tschoergez hat geschrieben:ein Registrieren der VM auf nem anderen ESX und starten der VM ist also möglich (manuell). Allerdings wohl nicht über das vCenter, sondern nur lokal am "ziel"-Host, weil das vCenter die VM ja noch auf dem "quell"-ESX kennt.

und das ist ja eigentlich nicht gewollt, denn ich habe schon ein Problem, dass ich mit einem Workaround lösen kann. Es müsste eine Möglichkeit geben, dem VC zwangsweise mitzuteilen, dass die VM auf einem anderen Host laufen soll. Natürlich nur unter der Voraussetzung, dass - wie von dir beschrieben - die Locks nicht mehr vorhanden sind. Im Grunde ist das eine unbefriedigende Lösung.

Ähnliche Probleme hat man ja, wenn man mit einem gespiegelten Storage arbeitet und nicht noch andere Lösungen dazwischen schaltet (wie z.B. Storagevirtualisierung). Bricht ein Storage weg, hat man zwar eine Kopie auf dem Mirror, aber dem VCenter beizubringen, dass der Spiegel genutzt werden soll ist wirklich eine Qual. Und SRM hat ja seine eigenen Probleme.

Vielleicht bringt ja Marathon sein Produkt auch mal für VmWare (geplant haben sies zumindest mal, gemäss einer Mitteilung von 2010), die haben solche Szenarien für XEN nämlich excellent, funktionstüchtig und auch bezahlbar gemacht.

VmWare selbst interessiert sich irgendwie nicht grossartig für den Storage, wohl auch weil das die Baustelle von deren Inhaber EMC ist. Die Kleinumgebungen bleiben halt auf der Strecke.

naja, wenn der komplette Quell-ESX gestoppt wird, weil er ohne Storage keinen nutzen mehr bringt, dann wir die VM im vCenter ausgegraut. dann sollte auch im vCenter ein deregistrieren und neu registrieren wieder machbar sein.
Aber das vCenter braucht erfahrungsgemäß eine Weile, bis es solche ausfälle erkennt.

Bei vSphere 5 hat sich übrigens einiges getan in Sachen HA (inkl. Storage Heartbeats z.B.), allerdings wird auch hier ein kompletter Storage-Ausfall nicht abgefangen.

SRM hilft

@UrsDerBär: Marathon hängt sich zwischen OS und SCSI-Treiber, um die Platten zugriffe zu replizieren, oder?
Macht man das bei bei Xen pro VM, oder geht das für nen ganzen Server/Datastore?

Viele Grüße,
Jörg

Also wo genau er alles einhängt, kann ich nicht sagen. Ist auch einigermassen schwer an Infos zu kommen, da Community sehr klein. Muss aber zwungenermassen, tief unten sein, sonst wäre das ganze nicht ohne Datenverlust möglich. Aus den Unterlagen und auch aus einer Live-Demo weiss ich aber, dass er alle Arten von Ausfällen zuverlässig überbrücken kann.

Vm läuft zum Beispiel auf Host 1, ein zweiter bringt den Spiegel.

- Nic Ausfall an Host 1 für das Netzwerk, Traffic läuft einfach übe Host 2 weiter, die VM an sich aber auf Host 1
- Storage-Ausfall an Host 1, Host 1 holt sich einfach die Daten von Host 2, VM läuft aber auf Host 1 weiter
- Komplettausfall von Host 1, sofern sie im Lockstep bzw. Level 1 (auch Multicore) betrieben wird, läuft das Teil einfach komplett weiter via Host 2, ansonten normales HA Szenario wie auch bei VmWare, reboot auf dem anderen Server.

Storage ist dem Ding eigentlich egal woher er kommt. Verwaltet wird das eh vom Xen. Sinnvollerweise hat man deren zwei. Local oder auf einer SAN oder einem performanten DAS. Kann man den gewünschten/erforderten Performance-Anforderungen entsprechend nehmen.

Art der Absicherung: Du stellst für jede VM ein was du willst. Normalbetrieb ohne Absicherung durch Marathon, Level 2 (Komponentenausfall wird aufgefangen) oder Level 1 für Parallelbetrieb über zwei Hosts mit mittlerweile Multicores. Kann also ein ganzer Host wegkacken.

Die grössten Vorteile sehe ich in deren Lösung für Kleinumgebungen oder Absicherung von besonders wichtigen Maschinen. Die Kosten sind im Verhältniss zum gebotenen sehr überschau- und skalierbar. Im kleinsten Fall bekommt man für ein paar tausend Euro, dem Free Xen und zwei Standardserver mit Local-Storage eine komplett gespiegelte Umgebung. Bei mehr als zwei Hosts und Lockstep wird es auch komplexer wegen dem Heartbeat.

Wenn die das tatsächlich auch für VmWare bringen, wäre das schon cool und die Verbreitung mal etwas höher sein.

ok, danke für die Erklärungen.
Ist das ganze transparent für den Gast?

Soweit mir bekannt ja. Die VM bzw. die Dienste auf der VM bekommt angeblich nix davon mit. Interessiert zum Beispiel Exchange + SQL und AD nicht die Bohne. Es werden aber wohl ein paar spezielle Treiber benötigt, was die genau davon mitbekommen weiss ich nicht.

DisasterRecovery mit zweitem Standord mit asynchroner Übertragung gibts mittlerweile auch.