Probleme mit MS Cluster auf vSphere 4.1

[ESXRolf]

Guten Tag Zusammen,

Leider habe ich seit gestern ein Problem mit meinem MS Cluster (2008 R2) welcher auf meiner ESX Farm läuft und bin einwenig am Anschlag.

Kurz einige Informationen vorab.
- vSphere 4.1
- 8 Hosts (verteilt über zwei RZ)
- Storage Lösung ist SVC (ebenfalls verteilt über zwei RZ)

Ich habe vor einiger Zeit folgendes Setup gemacht:

- Neue LUNs für den Cluster auf dem SVC erstellt und den ESX Hosts zugewiesen
- Neue VM erstellt und die RAW LUNs direkt verbunden
- Zweite VM erstellt und "vorhandene Virtuelle Festplatte" gewählt und die jeweiligen disks von der ersten VM angehängt.
- Die Disks haben sowohl auf der ersten sowie auf der zweiten VM die gleichen SCSI ID's 1:0, 1:1, etc.
- Die SCSI-Controller sind vom Typ "LSI Logic SAS" und sind im Mode "Physisch"

Soweit so gut, das funktionierte dann eigentlich alles zimlich gut. Bis wir gestern einen Host auf welchem eine dieser VMs lief in den Maint Mode gesetzt haben und diese danach neugestartet haben. Wenn ich nun meine zweite VM wieder einschalten möchte, erhalte ich folgende Fehlermeldung:

- "Die virtuelle Festplatte 'Hard disk 2' ist eine zugeordnete Direktzugriffs-LUN. Es kann nicht darauf zugeriffen werden"

Was ich ebenfalls einwenig merkwürdig finde, ist wenn ich in den Eigenschaften der VM welche ich nicht mehr starten kann, diese Festplatte auswähle und danach auf "Pfade Verwalten" klicke, erhalte ich folgende Fehlermedung:

- "Für diese LUN gibt es keine Multipath-Konfiguration"

Was ich nun nach einiger Forschung ebenfalls noch ausfindig gemacht habe (weiss jedoch nicht wirklich ob dies einen Einfluss hat) ist. Wenn ich in der Speicherkonfiguration der Host auf welchen sich die beiden VMs befinden die "Geräte" anschaue, stelle ich fest das die Disks welche von den beiden VMs geteilt werden sollten, auf den unterschiedlichen Hosts nicht die gleiche LUN ID haben.

Beispiel:
- Host 1 (VM läuft zur Zeit): vmhba0:C0:T0:L7
- Host 2 (VM lässt sich nicht starten): vmhba0:C0:T2:L6

Fakt ist, der ganze Cluster hatte ohne jegliche Probleme funktioniert, auf ausschalten und wieder einschalten einzelner VMs war kein Problem. Jedoch seit dem Restart des Hosts der zweiten VM lässt sich diese nicht mehr starten.

Folgendes habe ich schon probiert:
- Beide VMs ausschalte und nacheinander starten in jeder Möglichen Reihenfolge
- Diskzuweisungen bei VM zwei neu gemacht
- VM zwei lässt sich ohne die shared Disk problemlos starten
- Cluster service auf der aktiven VM eins gestoppt und danach VM zwei versucht zu starten
- etc

Ich hoffe hier hat jemand schon mal ähnliche Erfahrungen gemacht oder kann mir sonst weiterhelfen.

Vielen Dank für Eure Unterstüzung und gebt mir Bescheid falls Ich irgendwelche Informationen die fürs Troubleshooting relevant sind vergessen haben.

Gruss,
Rolf Berger

[ideFix]

Hallo!

Hast du das Setup for Failover Clustering and Microsoft Cluster Service schon gelesen?

Habe in der Vergangenheit mal mit MS Cluster gespielt. Jedoch nicht mit RAW LUNs.

[ESXRolf]

Hallo ideFix,

Ja habe das Dokument schon gelesen und das setup welches ich gemacht habe basiert auf diesem Dokument.

Wie schon erwähnt hatte das ganze Setup ja schon funktioniert, bis der Host neugestartet wurde.

Gruss

[Tschoergez]

Wenn die LUN unterschiedliche IDs für die zwei ESX hat, wirds wohl nicht funktionieren.
weil der ESX die eine LUN als unterschiedliche identifiziert => auf dem storage dafür sorgen, dass die LUN wieder eine ID bekommt.

durch den neustart des hosts wurde ein rescan ausgeführt, der änderungen im Storage dem ESX klargemacht hat.
bei laufendem betrieb ohne rescan können solche änderungen durchaus vom esx nicht bemerkt worden sein, drum lief die VM ohne probleme.
grüße,
jörg

[ESXRolf]

Hallo Tschoergez,

Vielen Dank für das Feedback. Ich habe heute Nachmittag auf dem Storage jeweils eine LUN ID zugewiesen und das ganze mapping zu den ESX Hosts neu gemacht.

Danach habe ich das Cluster setup nochmals überprüft und die jeweiligen Disks neu mit den VMs verbunden.

Die LUN ID ist nun auf allen Hosts identisch... wenn ich versuche die zweite VM zu starten erhalte ich leider immernoch die gleiche Fehlermeldung:

- "Die virtuelle Festplatte 'Hard disk 2' ist eine zugeordnete Direktzugriffs-LUN. Es kann nicht darauf zugegeriffen werden."

Was sich auch nicht geändert hat, ist wenn ich in den Einstellungen der zweiten VM die virtuelle Festplatte auswähle und auf Pfade Verwalten drücke, erhalte ich folgende Meldung:

- "Für diese LUN gibt es keine Multiptah-Konfiguration"

Da dieses Ding so schnell wie Möglich wieder laufen sollte, hoffe ich Ihr könnt mir noch irgendwie anders weiterhelfen? Braucht Ihr irgendwelche Logfiles? Weitere Informationen?

Vielen Dank für die Unterstützung!

[Tschoergez]

schau mal in die vmware.log der beiden VMs, wie die LUNs genau angesprochen werden.
ein blick ins vmkernel.log kann auch nicht schaden, v.a. während eines Rescans.
Ich tippe auf eine Fehlkonfiguration im Storage...

[kastlr]

Hallo Rolf,

vielleicht hast du ja gar kein ESX Problem, sondern ein Problem mit dem MS Cluster.
W2K8 R2 verwendet SCSI 3 persistent reservations für die shared LUNs.
Da kann es schon mal zu Problemen kommen, wenn der zweite Node auf die LUN's zugreifen möchte, denn manchmal werden diese beim runterfahren nicht sauber gelöscht.
In der physikalischen Welt wirkt sich das nicht ganz so schlimm aus, aber da ein ESX Server beim Starten einer VM überprüft, ob er den Zugriff auf alle Resourcen der VM bereitstellen kann, verhindert eine Reservierung eventuell das Starten der VM.

Um dieses Scenario auszuschließen kannst du folgendes ausprobieren.
Verschiebe den zweiten Clusternode auf den ESX Server, der bereits den running Node hostet.
Gelingt es dir in dieser Konstellation den zweiten Node zu starten, liegt das Problem an den SCSI Reservierungen.

Sollte dies in deiner Umgebung zutreffen, würde ich wie folgt weiter vorgehen.

- Stoppen der zweiten VM
- Migration auf den ursprünglichen ESX Server
- Stoppen Cluster Service auf Node 1
- Ausführen des Kommandos cluster.exe node node1 /clearpr:2 (für alle shared Disks wie Quorum etc. die entsprechende Disknummer verwenden)
- Starten des zweiten Cluster Nodes
- Starten Cluster Service auf Node1
- Verschieben der Clustergruppe(n) zwischen den beiden Nodes als Funktionstest

Ansonsten kann ich mich Jörg nur anschließen, der vmware.log sowie der vmkernel Log sollte dir erste Hinweise auf das Problem liefern.

Viel Erfolg bei der Fehlersuche
Ralf

[ESXRolf]

Vielen Dank für die Hilfreichen tips.. Ich bin inzwischen einen kleinen Schritt weitergekommen und ich denke ich kann das Problem einwenig eingrenzen.

Wie ich ja am Anfang erwähnt habe ist unser ESX Cluster über zwei Datacenter verteilt. Dabei habe ich die Cluster VMs gezielt ebenfalls auf die Hosts im Datacenter verteielt:

- VM1 -> Datacenter 1
- VM2 -> Datacenter 2

Wie Ihr ja wisst lässt sich die VM2 leider nicht mehr starten. Was ich nun probiert habe ist, dass ich die VM2 auf einen Host im Datacenter 1 verschoben habe, und siehe da, die VM lässt sich wieder ohne Probleme starten.. Sobald ich die VM2 wieder in Datacenter 2 verschiebe kann diese erneut nicht gestartet werden.

Im Anhang noch einige Screenshots der Fehlermeldungen die ich erhalte, eventuell habt Ihr so ein Szenario ja schon mal gesehen und könnt mir sagen wo das Problem liegt, verstehe langsam gar nichts mehr

Erklärung zu den Screenshots:

1. 1_pfadeverwalten_vmeigenschaften.png (http://www.styledesigns.ch/esx/1_pfadeverwalten_vmeigenschaften.png)
Wenn ich auf der VM2 in den Einstellungen einer vDisk auf "Pfade Verwalten" klicke

2. 2_versuch_vm_zustarten.png (http://www.styledesigns.ch/esx/2_versuch_vm_zustarten.png)
Folgende Meldung erhalte ich wenn ich versuche die VM2 zu starten

3. 3_pfade_host_vm1.png
(http://www.styledesigns.ch/esx/3_pfade_host_vm1.png)
Das sind die eigenschaften der Konfiguration auf dem Host in Datacenter 1 auf welchen die erste VM läuft.

3. 4_pfade_host_vm2.png (http://www.styledesigns.ch/esx/4_pfade_host_vm2.png)
Das sind die eigenschaften der Konfiguration auf dem Host in Datacenter 2 auf welchen die zweite VM läuft - welche sich eben nicht mehr starten lässt.

[kastlr]

Hallo Rolf,

ich habe mal ein ähnliches Problem bei einem israelischem Kunden gesehen.
Dieser Kunde konnte eine running VM mit pRDM's nicht mehr verschieben, da jeder ESX Server seines Clusters behauptete, das er keinen Zugriff auf die LUN's bekam.
Kurioserweise galt das auch für den ESX Server, auf dem die VM aktuell betrieben wurde.

Wir haben das Problem wie folgt gelöst.
Nachdem wir die entsprechende VM's gestoppt haben, haben wir die Platten aus der VM mit der Option "Delete from Disk" gelöscht.
Da es sich ja um pRDM's handelte, wurde nur die jeweilige "Pointer" Datei entfernt, die Daten auf den Platten wurden nicht gelöscht.
Danach wurden die Pointer Dateien neu angelegt und der VM unter Verwendung der ursprünglichen SCSI ID's zugewiesen, damit sich aus Sicht des vOS keine Änderung ergibt.
Im Anschluß konnte der Kunde die VM wieder sauber starten und auch innerhalb seines Clusters verschieben.

Hoffe, das hilft dir weiter.

Viel Erfolg
Ralf

[ESXRolf]

Hallo Ralf,

Vielen Dank für deinen Tipp, habe das ganze wie Beschrieben ausprobiert.. leider ohne Erfolg. Die zweite VM lässt sich immernoch nicht starten und die Fehlermeldungen sind immernoch die gleichen, es ist zum verzweifeln.

Hat eventuell noch jemand eine andere Idee?

Vielen Dank,
Rolf

[kastlr]

Hallo Rolf,

dann bleibt dir nur noch ein Blick in die Datei vmware.log im Verzeichnis der VM2, kurz nachdem du versucht hast diese zu starten.
Sie sollte nicht all zu groß werden, vielleicht kannst du sie ja hier direkt posten.

gruß
Ralf

[ESXRolf]

Hallo Ralf,

Ich würde dir ja gerne das logfile posten, das Problem ist nur das da gar nichts reingeschrieben wird. Die letzte Änderung am vmware.log ist vor 3 Tagen , da hatte ich die VM mal ohne die zusätzlichen HD's gestartet..

Muss ich das irgendenwie forcen damit immer in das Log geschrieben wird?

Danke,
Rolf

[kastlr]

Hallo Rolf,

alternativ kannst du auch den vmkernel log des ESX Servers auswerten.

Gruß
Ralf

[Tschoergez]

Das vmware.log wird erst geschrieben, wenn die VM gestartet wird.
Hier siehts so aus, dass der ESX vorher schon erkennt, das was nicht stimmt
=> vmkernel.log, wie schon geschrieben.
Am besten auch während eines rescans...

Kann denn das Storage die LUNs gleichzeitig über verschiedene Targets präsentieren, inkl. shared zugriff?

[ESXRolf]

So wie besprochen hier das vmkernel file. Habe einen Rescan gemacht sowie versucht die VM nochmals zu starten. Könnt ihr damit etwas anfangen?

http://www.styledesigns.ch/esx/vmkernel

Danke und Gruss,
Rolf

[kastlr]

Hallo Rolf,

im vmkernel Log finden sich folgende Meldungen für die Cluster Devices.

Jun 14 10:08:33 srrz2vmw02 vmkernel: 92:13:06:29.632 cpu2:19107)ScsiDeviceIO: 1672: Command 0x1a to device "naa.60050768018f0271200000000000003c" failed H:0x5 D:0x0 P:0x0 Possible sense data: 0x0 0x0 0x0.
Jun 14 10:08:43 srrz2vmw02 vmkernel: 92:13:06:39.669 cpu2:4098)ScsiDeviceIO: 1672: Command 0x1a to device "naa.60050768018f0271200000000000003d" failed H:0x5 D:0x0 P:0x0 Possible sense data: 0x0 0x0 0x0.
Jun 14 10:08:53 srrz2vmw02 vmkernel: 92:13:06:49.700 cpu2:4098)ScsiDeviceIO: 1672: Command 0x1a to device "naa.60050768018f0271200000000000003e" failed H:0x5 D:0x0 P:0x0 Possible sense data: 0x0 0x0 0x0.
Jun 14 10:08:53 srrz2vmw02 vmkernel: 92:13:06:49.700 cpu1:4108)WARNING: ScsiDeviceIO: 4555: QErr set to 0x0 for device naa.60050768018f0271200000000000003e. This may cause unexpected behavior.
Jun 14 10:08:53 srrz2vmw02 vmkernel: 92:13:06:49.700 cpu1:4108)WARNING: ScsiDeviceIO: 4558: The device was originally configured to the supported QErr setting of 0x0, but this has been changed and could not be reset.
Jun 14 10:09:03 srrz2vmw02 vmkernel: 92:13:06:59.718 cpu2:19107)ScsiDeviceIO: 1672: Command 0x1a to device "naa.60050768018f0271200000000000003f" failed H:0x5 D:0x0 P:0x0 Possible sense data: 0x0 0x0 0x0.

Laut Understanding SCSI host-side NMP errors/conditions in ESX 4.x hat der HBA Treiber ein Kommando "aborted", leider enthalten die SCSI Sense Codes keinen weiteren Hinweis auf das "Warum".
Das fehlgeschlagene Kommando war ein "Mode Sense", weitere Details dazu findest du hier SCSI Mode Sense Command.

Ich würde mir an deiner Stelle mal deine SAN Virtualisierungs Lösung genau ansehen, ob der Zugriff auf diese LUN's aus dem zweiten RZ wirklich möglich ist.
Ich bin mir ziemlich sicher, das es sich bei deinem Problem nicht um ein VMware Problem handelt.

Viel erfolg
Ralf