Hallo zusammen,
wir hatten einen Exchange 2013 Crash während eines HDD Firmware Update im SAN. Ich muss ein bißchen ausholen, um das Problem näher zu erläutern:
Wir bauen zurzeit eine neue Exchange 2013 Umgebung auf Windows Server 2013 unter vSphere 5.1 U1 auf. Sie besteht aus 3 Mailbox Server im DAG Verbund. Jeder MB Server liegt in einer eigenen 5TB LUN (VMFS-5). Jeder MB Server besteht aus mehreren VMDKs (1xSystem/ 4xDBs/ 1x Logs). Außerdem gibt es 2 CAS Server, die ebenfalls in separaten LUNs liegen. Alle VMs können via DRS Rule nicht auf einem gemeinsamen ESXi Host liegen.
Im SAN setzen wir Datacore SANsysmphony-v 9.0.3.1 ein. Die verwendete HW ist von Dell: Server sind R720, Storage ist MD1220 DAS (2,5 Zoll, 900GB, SAS, 10k). In den Datacore Systemen sind Qlogic 2562 FC HBAs. Je zwei Ports FE und zwei Ports Mirror.
Die ESXi Host haben Qlogic 8262 FCoE CNAs. Als Swicth kommt Cisco Nexus zum Einsatz. Die ESXi sind über ein 4-Pfade Zonning im RR/ ALUA Betrieb an die Datacore Systeme angeschlossen.
Anfang der Woche hatten wir bereits ca. 20 Postfächer von unserer noch produktiven Exchange 2007 auf unsere neue Exchnage 2013 Umgebung migiriert.
Am Donnerstag Abend musste ich ein von Dell empfohlenes HDD FW Update in die Dell MD1220 einspielen.
Folgende Vorgehensweise:
1. Datacore Dienst auf Seite A gestoppt, 2 von 4 Pfade brechen -> Alles okay
2. Datacore Reboot, um Dell Nautilus FW HDD Update Tool von USB Stick booten-> Alles okay
3. FW Update der HDDs -> Alles okay
4. Reboot des Datacore Server und Start der Datacore Software -> Alles okay
5. Start des Mirrorabgleich, Überprüfung unter VMware, ob wieder alle 4 Pfade verfügbar sind -> Alles okay
6. Datacore Dienst auf Seite B gestoppt, 2 von 4 Pfade brechen -> ALLE 3 EXCHANGE 2013 MB SERVER STÜRZEN AB
7. Datacore Reboot, um Dell Nautilus FW HDD Update Tool von USB Stick booten-> Alles okay
8. FW Update der HDDs -> Alles okay
9. Reboot des Datacore Server und Start der Datacore Software -> Alles okay
10. Start des Mirrorabgleich, Überprüfung unter VMware, ob wieder alle 4 Pfade verfügbar sind -> Alles okay
Nach der Wartung haben wir den Absturz der drei Exchange 2013 Server bemerkt. Ein Reboot der VMs endete lediglich im Windows Recovery/ Repair Mode. Wir haben MS eingeschaltet, um die VMs zu reparieren. Nach mehreren Stunden MS Support war es trotzdem nicht möglich die Systeme zu reparieren und wieder lauffähig zu machen. CHKDSK hat Unmengen an Fehler entdeckt, die auch repariert werden konnten, ein Reboot in OS war trotzdem nicht möglich.
VMware analysiert zurzeit ein Support Bundle eines ESXi Host, der einen der MB Server hostete.
Inzwischen haben wir parallel Systeme aufgebaut, konnten teilweise auf die defekten DB VMDKs zugreifen und zumindest einen Datenverlust vermeiden. Die urspüngliche Exchnage 2013 MB umgebung ist aber hin, wir müssen sie komplett neu aufbauen.
Ich habe inzwischen mit vmkfstools einige der betroffenen VMDKs geprüft. Der "Check" Parameter unter vmkfstools antwortete, dass die Disk okay wäre. Allerdings wunderte ich mich, dass der Check bei einer 600GB VMDK nur Sekunden dauerte. Ist das normal ?
Außerdem habe ich mit voma (VMware Onsite Metadata Analyzer) eine der betroffenen LUNs gecheckt. Ergebnis: 2,5 Millionen Fehler. Der Gegencheck einer nicht betroffenen LUN: 0 Fehler.
Okay, soweit so gut: Ich weiß also, dass das VMFS der LUNs in Mitleidenschafft gezogen wurde. In den VMware Pubs steht allerdings: voma ist ein read-only Tool, wenn Fehler erkannt werden, VMware Support einschalten-> Hab ich gemacht.
Die für mich entscheidene Frage, die ich zurzeit absolut nicht beantowrten kann, ist folgende: Warum crashen bei einer SAN Wartung genau die drei LUNs in dennen Exchnage 2013 VMs liegen. Wir haben 250VMs verteilt auf 100 LUNs.
Das sieht für mich nicht nach Zufall aus !!!
Habt ihr solch ein Verhalten schonmal gesehen ? Das sich eine Wartung, Pfadumschaltung, Failover, etc. auf eine bestimmte Applikation innerhalb der VM auswirkt. Könnte das etwas mit SCSI Timeouts etc. zu tun haben ?
Mir geht es nicht darum, das ihr jetzt irgendwelche Logs oder so auswertet, sondern eher um Tipps und Erfahrungen, wo ich und der Support ansetzen könnte ?
Vorab Danke fürs Feedback,
Nick
Die Foren-SW läuft ohne erkennbare Probleme. Sollte doch etwas nicht funktionieren, bitte gerne hier jederzeit melden und wir kümmern uns zeitnah darum. Danke!
Exchange 2013 Crash während HDD Firmware Update im SAN
-
kastlr
- Profi
- Beiträge: 993
- Registriert: 31.03.2008, 17:26
- Wohnort: Einzugsbereich des FC Schalke 04
- Kontaktdaten:
Hallo Nick,
ich an deiner Stelle würde mir mal die DataCore Lösung genauer ansehen.
Denn wenn ich das richtig verstanden habe, lagen deine Exchange VM's auf LUN's, welche über Datacore zu einem mirrored Volume aufgebohrt worden sind.
Überprüfe mal, wie viele der 4 Pfade pro LUN denn im Status Active oder Active (I/O) sind.
Nur über die mit Active (I/O) gekennzeichneten Pfade gehen I/O's, ich vermute, das in eurer Umgebung nur 2 Pfade wirklich verwendet werden.
Daher war vermutlich die Umgebung, welcher du als erstes die neue FW verpasst hast nicht die primäre Seite, somit lief das FW Update problemlos.
Als du dann die primäre (produktive) Seite bearbeiten wolltest, hätte die DataCore Lösung den Zugriff auf die LUN's über die zweite Umgebung freischalten müssen.
Das dürfte sie auch getan haben, so wie es allerdings aussieht, waren die Daten dort nicht aktuell/korrupt/weg.
Wenn ich eine Vermutung anstellen müßte, dann würde ich darauf setzen, das die Replizierung zwischen den beiden DataCore Systemen fehlerhaft ist.
SCSI TimeOuts werden höchstwahrscheinlich nicht das Problem sein, schließlich stellst du Sie für jeden ESX Server global ein.
Somit gelten diese Einstellungen für alle LUN's.
Und da Ihr ja auch ein kaputtes VMFS hast, liegt das Problem auch nicht an den VM's, denn die haben ja nur Zugriff auf die über die vmdk's bereitgestellten Bereiche der physikalischen LUNs.
Da Ihr Exchange virtualisiert habt, nehme ich einfach mal an, das Ihr mit Thick Volumes gearbeitet habt.
Somit sollten auf den Datastores auch kaum Änderungen stattfinden, welche in den Metadaten des VMFS gespeichert werden müßten.
Und da es sich bei VMFS um ein shared Filesystem handet und Ihr sicher mehreren ESX Servern den Zugriff auf die entsprechenden LUN's gewährt habt, wäre ein korruptes VMFS Filesystem höchstwahrscheinlich gemeldet worden.
Schließlich schreiben alle ESX Server Hearbeat Informationen in die VMFS Datastores, selbst wenn auf ihnen keine VM von dem jeweiligen DS läuft.
Mal ganz davon abgesehen, das VMFS inzwischen sehr stabil ist und Korruption fast immer durch defekte HW oder durch fehlerhaftes Zoning & Masking verursacht wird,
Alles in allem hört sich das für mich nach einem Problem mit der Mirror Lösung an.
Viel Erfolg bei der WIederherstellung.
Gruß,
Ralf
ich an deiner Stelle würde mir mal die DataCore Lösung genauer ansehen.
Denn wenn ich das richtig verstanden habe, lagen deine Exchange VM's auf LUN's, welche über Datacore zu einem mirrored Volume aufgebohrt worden sind.
Überprüfe mal, wie viele der 4 Pfade pro LUN denn im Status Active oder Active (I/O) sind.
Nur über die mit Active (I/O) gekennzeichneten Pfade gehen I/O's, ich vermute, das in eurer Umgebung nur 2 Pfade wirklich verwendet werden.
Daher war vermutlich die Umgebung, welcher du als erstes die neue FW verpasst hast nicht die primäre Seite, somit lief das FW Update problemlos.
Als du dann die primäre (produktive) Seite bearbeiten wolltest, hätte die DataCore Lösung den Zugriff auf die LUN's über die zweite Umgebung freischalten müssen.
Das dürfte sie auch getan haben, so wie es allerdings aussieht, waren die Daten dort nicht aktuell/korrupt/weg.
Wenn ich eine Vermutung anstellen müßte, dann würde ich darauf setzen, das die Replizierung zwischen den beiden DataCore Systemen fehlerhaft ist.
SCSI TimeOuts werden höchstwahrscheinlich nicht das Problem sein, schließlich stellst du Sie für jeden ESX Server global ein.
Somit gelten diese Einstellungen für alle LUN's.
Und da Ihr ja auch ein kaputtes VMFS hast, liegt das Problem auch nicht an den VM's, denn die haben ja nur Zugriff auf die über die vmdk's bereitgestellten Bereiche der physikalischen LUNs.
Da Ihr Exchange virtualisiert habt, nehme ich einfach mal an, das Ihr mit Thick Volumes gearbeitet habt.
Somit sollten auf den Datastores auch kaum Änderungen stattfinden, welche in den Metadaten des VMFS gespeichert werden müßten.
Und da es sich bei VMFS um ein shared Filesystem handet und Ihr sicher mehreren ESX Servern den Zugriff auf die entsprechenden LUN's gewährt habt, wäre ein korruptes VMFS Filesystem höchstwahrscheinlich gemeldet worden.
Schließlich schreiben alle ESX Server Hearbeat Informationen in die VMFS Datastores, selbst wenn auf ihnen keine VM von dem jeweiligen DS läuft.
Mal ganz davon abgesehen, das VMFS inzwischen sehr stabil ist und Korruption fast immer durch defekte HW oder durch fehlerhaftes Zoning & Masking verursacht wird,
Alles in allem hört sich das für mich nach einem Problem mit der Mirror Lösung an.
Viel Erfolg bei der WIederherstellung.
Gruß,
Ralf
Hi Ralf,
Danke für Deine Info.
Die Kommunikation zwischen ESXi und Datacore läuft, wie Du schon sagst, nur über 2 von 4 Pfaden. Zwei sind mit Active (I/O) (beide Pfade gehen zu einem Datacore Server) und zwei sind mit Active gekennzeichnet. Das ist allerdings normal. In Datacore konfiguriert man pro angeschlossenen ESXi einen sog. Preferred Datacore Server. Wir haben das in unserer Umgebung aufgeteilt, um einen rudimentären Lastenausgleich zu haben, d.h.
ESXi 01 -> Datacore Server A (Preferred Server)
ESXi 02 -> Datacore Server B (Preferred Server)
ESXi 03 -> Datacore Server A (Preferred Server)
usw....
Das ist allerdings ganz normal, da Datacore keine Active-Passiv Systeme, sondern ein Active-Active System ist.
Ich persönlich bezweifel das Datacore das Problem ist. Ich habe mir die Logfiles angesehen und hier scheint das Verhalten absolut standardmäßig gewesen zu sein. Nachdem ich den Datacore Dienst auf Server A gestoppt habe sehe ich im Log, dass der Spiegel gebrochen wurde und ESXi Server 01,03,05,07,.... (alle ESXi, die Datacore Server A als Preferred Server konfiguriert haben) eine Pfadumschaltung auf Datacore Server B. Nachdem ich mit dem FW Update auf Datacore Server A fertig war, habe ich den Server hochgefahren, Datacore wieder gestartet und nach kurzer Zeit hat das Log Recovery begonnen. Nachdem alle vDisks healthy waren, alle 4 Pfade wieder vorhanden waren (2 Active (I/O) - 2 Active), habe ich Datacore Server B gestoppt. Dann das gleiche Spiel, Pfadfailover, usw....
Wäre hier etwas defekt, wären deutlich mehr LUNs/VMs betroffen gewesen.
Vielleicht noch zur Info: Die defekten LUNs verhalten sich jetzt auch sehr strange. Obwohl die LUNs an alle ESXi gemappt sind, haben nicht mehr alle ESXi Zugriff auf die LUNs. Sie werden zwar noch im VMware Tab Storage Adapters gelistet, sind jedoch bei einzelnen ESXi unter Datastore nicht mehr gelistet, d.h. das Mapping ist vorhanden, jedoch der Zugriff über einzelnen ESXi nicht möglich.
Viele Grüße,
Nick
Danke für Deine Info.
Die Kommunikation zwischen ESXi und Datacore läuft, wie Du schon sagst, nur über 2 von 4 Pfaden. Zwei sind mit Active (I/O) (beide Pfade gehen zu einem Datacore Server) und zwei sind mit Active gekennzeichnet. Das ist allerdings normal. In Datacore konfiguriert man pro angeschlossenen ESXi einen sog. Preferred Datacore Server. Wir haben das in unserer Umgebung aufgeteilt, um einen rudimentären Lastenausgleich zu haben, d.h.
ESXi 01 -> Datacore Server A (Preferred Server)
ESXi 02 -> Datacore Server B (Preferred Server)
ESXi 03 -> Datacore Server A (Preferred Server)
usw....
Das ist allerdings ganz normal, da Datacore keine Active-Passiv Systeme, sondern ein Active-Active System ist.
Ich persönlich bezweifel das Datacore das Problem ist. Ich habe mir die Logfiles angesehen und hier scheint das Verhalten absolut standardmäßig gewesen zu sein. Nachdem ich den Datacore Dienst auf Server A gestoppt habe sehe ich im Log, dass der Spiegel gebrochen wurde und ESXi Server 01,03,05,07,.... (alle ESXi, die Datacore Server A als Preferred Server konfiguriert haben) eine Pfadumschaltung auf Datacore Server B. Nachdem ich mit dem FW Update auf Datacore Server A fertig war, habe ich den Server hochgefahren, Datacore wieder gestartet und nach kurzer Zeit hat das Log Recovery begonnen. Nachdem alle vDisks healthy waren, alle 4 Pfade wieder vorhanden waren (2 Active (I/O) - 2 Active), habe ich Datacore Server B gestoppt. Dann das gleiche Spiel, Pfadfailover, usw....
Wäre hier etwas defekt, wären deutlich mehr LUNs/VMs betroffen gewesen.
Vielleicht noch zur Info: Die defekten LUNs verhalten sich jetzt auch sehr strange. Obwohl die LUNs an alle ESXi gemappt sind, haben nicht mehr alle ESXi Zugriff auf die LUNs. Sie werden zwar noch im VMware Tab Storage Adapters gelistet, sind jedoch bei einzelnen ESXi unter Datastore nicht mehr gelistet, d.h. das Mapping ist vorhanden, jedoch der Zugriff über einzelnen ESXi nicht möglich.
Viele Grüße,
Nick
-
kastlr
- Profi
- Beiträge: 993
- Registriert: 31.03.2008, 17:26
- Wohnort: Einzugsbereich des FC Schalke 04
- Kontaktdaten:
Hallo Nick,
ALUA ist NICHT Active - Active, jedes ALUA Array stellt seine LUN's über einen optimized und non-optimized SP/Pfad zur Verfügung.
VMware erkennt dies im Allgemeinen selbständig und wählt dann automatisch die Pfade für den IO Flow aus, welche zum aktuellem Owner der LUN führen.
Ich kenne DataCore nicht, wir machen so etwas mit VPLEX.
Dort heißt das dann nicht mirrored, sondern distributed.
In einem vergleichbarem Design würden wir da aber die Verteilung per LUN und nicht per Server machen.
Ausnahme von dieser Regel sind Metro oder Geo Lösungen, wenn sich die beiden RZ nicht direkt nebeneinander befinden.
Vielleicht ist ja auch das der Grund für das jetzt beobachtete Problem.
Wenn ein ESX Server die LUN über DC1 anspricht und ein weiterer ESX Server dies über DC2 macht, müssen beide DC bidirektional Daten austauschen.
Denn auch wenn die LUN's auf beiden DC vorhanden sind, könnte der jeweilige Cache Inhalt von einander abweichen.
Es werden nämlich (vermutlich) nur die Writes zwischen den DC abgeglichen, Reads werden sich nur im lokalem Cache der verwendeten DC befinden.
Als weiteren Punkt solltest du überprüfen, ob alle ESX Server die LUN's mit der identischen LUN ID sehen.
Das ist zwar bei weitem nicht mehr so ein Thema wie unter ESX 3.x, gilt aber z. B. für RDM's noch heute.
Und was für ein Bild ergibt sich. wenn Ihr die ESX Logs und die DataCore Logs nebeneinander legt?
Da ja mindestens immer ein System verfügbar gewesen ist, solltet Ihr doch an Hand der Zeitstempel in der Lage sein, Ereignisse im vmkernel Log mit eventuell vorhandenen DataCore Einträgen in Einklang zu bringen.
Gruß,
Ralf
ALUA ist NICHT Active - Active, jedes ALUA Array stellt seine LUN's über einen optimized und non-optimized SP/Pfad zur Verfügung.
VMware erkennt dies im Allgemeinen selbständig und wählt dann automatisch die Pfade für den IO Flow aus, welche zum aktuellem Owner der LUN führen.
Ich kenne DataCore nicht, wir machen so etwas mit VPLEX.
Dort heißt das dann nicht mirrored, sondern distributed.
In einem vergleichbarem Design würden wir da aber die Verteilung per LUN und nicht per Server machen.
Ausnahme von dieser Regel sind Metro oder Geo Lösungen, wenn sich die beiden RZ nicht direkt nebeneinander befinden.
Vielleicht ist ja auch das der Grund für das jetzt beobachtete Problem.
Wenn ein ESX Server die LUN über DC1 anspricht und ein weiterer ESX Server dies über DC2 macht, müssen beide DC bidirektional Daten austauschen.
Denn auch wenn die LUN's auf beiden DC vorhanden sind, könnte der jeweilige Cache Inhalt von einander abweichen.
Es werden nämlich (vermutlich) nur die Writes zwischen den DC abgeglichen, Reads werden sich nur im lokalem Cache der verwendeten DC befinden.
Als weiteren Punkt solltest du überprüfen, ob alle ESX Server die LUN's mit der identischen LUN ID sehen.
Das ist zwar bei weitem nicht mehr so ein Thema wie unter ESX 3.x, gilt aber z. B. für RDM's noch heute.
Und was für ein Bild ergibt sich. wenn Ihr die ESX Logs und die DataCore Logs nebeneinander legt?
Da ja mindestens immer ein System verfügbar gewesen ist, solltet Ihr doch an Hand der Zeitstempel in der Lage sein, Ereignisse im vmkernel Log mit eventuell vorhandenen DataCore Einträgen in Einklang zu bringen.
Gruß,
Ralf
DataCore und VPLEX sind nicht vergleichbar. DataCore SSV entspricht am ehesten einem NetApp Metro Cluster oder einem auseinander gezogenen Dual-Controller Storage-System. Der Zugriff über unterschiedliche Storage Server auf ein eine mirrored Vietual Disk ist kein Problem.
Man müsste jetzt die Logs analysieren. Auf jeden Fall DataCore einschalten und denen die Kontakdaten/ Ticketnummern von DELL und VMware geben.
Man müsste jetzt die Logs analysieren. Auf jeden Fall DataCore einschalten und denen die Kontakdaten/ Ticketnummern von DELL und VMware geben.
Guten Morgen zusammen,
Datacore hat die Support Bundles untersucht und konnte kein Problem/ Fehlerverhalten feststellen.
Support:
".....were stopped cleanly and successfully completed mirror log recovery.
I don't see any strange behaivior...."
Der Support hat jetzt im zweiten Step die Errormeldungen abgefragt, die das VMware Tool voma ausspucken:
"ON-DISK ERROR: FB inconsistency found: (321,70) allocated in bitmap, but never used"
Auf die Antwort von VMware warte ich noch...
Datacore hat die Support Bundles untersucht und konnte kein Problem/ Fehlerverhalten feststellen.
Support:
".....were stopped cleanly and successfully completed mirror log recovery.
I don't see any strange behaivior...."
Der Support hat jetzt im zweiten Step die Errormeldungen abgefragt, die das VMware Tool voma ausspucken:
"ON-DISK ERROR: FB inconsistency found: (321,70) allocated in bitmap, but never used"
Auf die Antwort von VMware warte ich noch...
Zurück zu „vSphere 5 / ESXi 5 und 5.1“
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 15 Gäste