Hallo Zusammen,
ich habe eine Horror Woche hinter mir und die ist noch nicht ganz beendet.
Zum System:
3x HP DL360 mit je 32 GB Speicher, 2x Quad Core 2,67 GHz
1x HP MSA 2312i mit 12x 500 GB Festplatten, 1 Controller, Raid 5, 3 LUN's 1x vDisk
1x HP Procurve Gigabit Switch
RZ mit redundanter Stromversorgung (USV+Diesel), 1 Gbit/s Internet
VMware vSphere 4.0 U1 Essentials Plus, HA aktiviert
18 VM's mit Linux und Windows Maschinen bis auf einen Exchange nicht sehr I/O intensiv.
2 shared LUN's für VM's und eine LUN exklusiv für einen physikalische Windows Server.
Was geschah:
Vorletzten Freitag fing es damit an dass zunächst eine Windows VM ausgefallen ist. Kurz nachdem ich mich am vCenter Server angemeldet hatte sind alle anderen VM's die auf dieser LUN waren ausgefallen.Kurz darauf war keine einzige LUN mehr erreichbar. Die MC der MSA erklärte mir nur noch dass das Storage System nicht zur Verfügung stehe. Ich habe dann den SC neu gestartet und die LUNS waren wieder Verfügbar. Allerdings war die 1. LUN auf welcher sich die VM's der ausgefallenen VM's befanden keine Daten vorhanden. Der VMware Support stellte dann fest dass a) die Partitions-. und Dateizuordnungstabelle beschädigt sind, und b) sich Fehler im Dateisystem befinden.Der VMware Support konnte zwar noch die Partitiontabelle wiederherstellen, mehr aber auch nicht. Man verwies mich dann auf einen sehr bekannten Datenretter.
Dieser Datenretter ist nun seit einer Woche 24/7 damit beschäftigt die einzelnen VM's wieder herzustellen. Bei der Analyse wurden folgende Fehler festgestellt:
- Partitiontabelle und Dateizuordnungen durch Windows Daten überschrieben
- Metadaten der VMDK's zerstört
- VMDK's großteils extrem fragmentiert. (Normal lt. deren aussagen wäre 5-10 Fragmente, hier mehrere 1000)
- Teilsweise sind die Pointer auf die Fragmente nicht vorhanden oder falsch.
Rund 50% der in den VMDK's befindlichen Daten konnte mittlerweile mit mehr oder weniger großen Aufwand hergestellt werden. Bei zwei Maschinen sind wir noch dran.
Jetzt kommt natürlich die große Frage wodurch dies verursacht wurde. HP schweigt zu diesem Problem standhaft. Man hat aber gleich angeboten die MSA kostenfrei auszutauschen. Der Datenretter macht mehrere Ursachen dafür verantwortlich.
- Die Metadaten der VMDK's wurden durch einen ESX Server zerstört
- Die Partitiontabelle und Dateizuordnungen wurde durch Windows Daten überschrieben, da vermutlich die MSA oder der Windows Server irgendwas mit den LUN ID's durcheinander gebracht hat. Und in der Tat wurde wenige Stunden vor dem Ausfall der Windows Kiste massehaft Daten auf die Windows LUN geschrieben.
- Die Pointer zu den Fragmenten sind vermutlich durch RAID Fehler bzw. durch Fehler innerhalb der MSA entstanden.
Das Szenario ist ziemlich heftig und vor allem kostspielig. Und alle beteiligten Dienstleister und Experten sind sich alle einig: Dies hätte niemals passieren dürfen. Langsam geht es von meiner Seite an die Ursachenforschung, da ich diese Szenario nie und nimmer nochmals haben möchte, und mich dagegen absichern will.
Hat von euch jemand so was schon erlebt und hat damit schon Erfahrungen? Wie kann man es besser machen? Abgesehen von einem Backup (auf das der Kunde kostentechnisch verzichtet hat, der ist jetzt aber geheilt...)
Viele grüße
Seppi
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!
Was könnte da passiert sein?
Nachtrag:
1 Minuten bevor die VM's ausgefallen sind haben sich die Dienste vom vCenter Server (physikalischer Server) verabschiedet.
Später habe ich dann festgestellt dass 4 der 18 VM's auf einmal auf jedem ESX Server registeirt waren (ist ja auch nicht normal)
Die MSA ist seit dem täglich 1-2 mal vollständig abgeschmiert, sodass nur noch ein harter Reboot (Stromstecker) half. Der SC konnte nicht neu gestartet werden (Meldung: Der SC ist nicht bereit für diese Oparation), alle Kontrollleuchten der Platten aus. Im Even Log der MSA sind keine Fehler enthalten. Lt. MSA haben weder das RAID noch die Platten Fehler.
Gruß
Christian
1 Minuten bevor die VM's ausgefallen sind haben sich die Dienste vom vCenter Server (physikalischer Server) verabschiedet.
Später habe ich dann festgestellt dass 4 der 18 VM's auf einmal auf jedem ESX Server registeirt waren (ist ja auch nicht normal)
Die MSA ist seit dem täglich 1-2 mal vollständig abgeschmiert, sodass nur noch ein harter Reboot (Stromstecker) half. Der SC konnte nicht neu gestartet werden (Meldung: Der SC ist nicht bereit für diese Oparation), alle Kontrollleuchten der Platten aus. Im Even Log der MSA sind keine Fehler enthalten. Lt. MSA haben weder das RAID noch die Platten Fehler.
Gruß
Christian
-
irix
- King of the Hill
- Beiträge: 13063
- Registriert: 02.08.2008, 15:06
- Wohnort: Hannover/Wuerzburg
- Kontaktdaten:
Bei sowas kannst du von einen aussenstehenden ja nun keine Loesung erwarten ausser das geteiltes Leid nur halbes Leid ist.
Die Gefahr bei iSCSI ist das es sehr einfach moeglich ist das ein falsches System LUNs beschreibt ohne das man phy. irgendetwas patchen und stecken muesste. Alles geht bequem ueber Software zukonfiguieren. Man koennte meine das ein VCB Proxy die LUNs beschrieben haette weil jemand das "automount disable/scrub" vergessen haette.
Allerdings haette kann man in den Logs sehen welcher initiator sich wo anmeldet. Das kann man ein bisschen unterbinden mittels getaggten VLANS ode noch besser phy. getrennen "SAN" Switchen nur fuer das Storage. Das ist ja nicht umsonst ein BestPractice.
Allerdings erklaert es nicht das komische Verhalten deiner HP MSA.
Gruss
Joerg
PS: Welches Backupkonzept wird eigentlich verwendet? - Ak, OK... habs nun gelesen wie es behandelt wurde :|
Die Gefahr bei iSCSI ist das es sehr einfach moeglich ist das ein falsches System LUNs beschreibt ohne das man phy. irgendetwas patchen und stecken muesste. Alles geht bequem ueber Software zukonfiguieren. Man koennte meine das ein VCB Proxy die LUNs beschrieben haette weil jemand das "automount disable/scrub" vergessen haette.
Allerdings haette kann man in den Logs sehen welcher initiator sich wo anmeldet. Das kann man ein bisschen unterbinden mittels getaggten VLANS ode noch besser phy. getrennen "SAN" Switchen nur fuer das Storage. Das ist ja nicht umsonst ein BestPractice.
Allerdings erklaert es nicht das komische Verhalten deiner HP MSA.
Gruss
Joerg
PS: Welches Backupkonzept wird eigentlich verwendet? - Ak, OK... habs nun gelesen wie es behandelt wurde :|
sicher, dass das mapping richtig ist?
wenn ihr nichts am mapping geändert habt und kein vcb einsetzt klingt es für mich danach, als wenn ein windows host in der mapping-gruppe der esx-hosts war jedoch vorher nie versucht hat auf die lun zu schreiben (was sich z.b. durch einen rescan der datenträger oder durch einen reboot geändert hat). dann trat halt das ein was irix schreibt. lein automount disable/scrub gesetzt und der windows host schreibt seine signatur auf das volume
wenn ihr nichts am mapping geändert habt und kein vcb einsetzt klingt es für mich danach, als wenn ein windows host in der mapping-gruppe der esx-hosts war jedoch vorher nie versucht hat auf die lun zu schreiben (was sich z.b. durch einen rescan der datenträger oder durch einen reboot geändert hat). dann trat halt das ein was irix schreibt. lein automount disable/scrub gesetzt und der windows host schreibt seine signatur auf das volume
Hallo,
die 2312i ist eine G2. Die hat von Haus aus ein explizites Mapping, also jeder sieht nur das, was er sehen darf. Ist nichts konfiguriert, sieht kein Host etwas, außer den Control LUNs. Nun ja, ohne Details zur Config wird das Troubelshooting schwer. Ich tippe aber auf ein Problem mit dem Mapping.
die 2312i ist eine G2. Die hat von Haus aus ein explizites Mapping, also jeder sieht nur das, was er sehen darf. Ist nichts konfiguriert, sieht kein Host etwas, außer den Control LUNs. Nun ja, ohne Details zur Config wird das Troubelshooting schwer. Ich tippe aber auf ein Problem mit dem Mapping.
Hallo Zusammen,
die LUN's waren auf allen Servern sichbar. Also die 3 ESX'en hatten auf die beiden VM-LUN's Zugriff und auch auf das Windows LUN. Die Windows Kiste hatte ebenfalls Zugriff auf alle LUN's. Also dann ein Problem des Mapping. Was ich aber nicht ganz verstehe, wenn ich der Windows Kiste eine LUN einrichte mit dem iSCSI Initiator warum solle diese dann urplötzlich auf eine andere LUN zugreifen? Diese dann auch noch automatisch platt machen und Daten drauf schreiben. Klingt für mich jetzt unlogisch, aber ich lasse mich da gerne eines besseren belehren. Ein VCB Proxy ist nicht im Einsatz.
Das Backupkonzept sah leider so aus, dass der Kunden davon ausging dass er dass nicht braucht bzw. er wollte sich einfach das Geld dafür sparen. Da dürfte er nun geheilt sein, da ihm die Datenrettung allein schon rund um die 50k€ kostet. Dafür hätte er 5 Backupsystem aufsetzten können.
Bleibt nur noch das merkwürdige verhalten der MSA. Heute trat dieses Phänomen wieder auf, und das im Leerlauf. Es hatte eine Maschine Zugriff auf eine LUN, es lief aber kein Datenverkehr drüber. Heute habe ich aber auch einen Eintrag im Event Log:
Bei Google konnte ich dazu rein gar nichts finden, und der HP Support konnte keine Aussage machen.
Gruß
Christian
die LUN's waren auf allen Servern sichbar. Also die 3 ESX'en hatten auf die beiden VM-LUN's Zugriff und auch auf das Windows LUN. Die Windows Kiste hatte ebenfalls Zugriff auf alle LUN's. Also dann ein Problem des Mapping. Was ich aber nicht ganz verstehe, wenn ich der Windows Kiste eine LUN einrichte mit dem iSCSI Initiator warum solle diese dann urplötzlich auf eine andere LUN zugreifen? Diese dann auch noch automatisch platt machen und Daten drauf schreiben. Klingt für mich jetzt unlogisch, aber ich lasse mich da gerne eines besseren belehren. Ein VCB Proxy ist nicht im Einsatz.
Das Backupkonzept sah leider so aus, dass der Kunden davon ausging dass er dass nicht braucht bzw. er wollte sich einfach das Geld dafür sparen. Da dürfte er nun geheilt sein, da ihm die Datenrettung allein schon rund um die 50k€ kostet. Dafür hätte er 5 Backupsystem aufsetzten können.
Bleibt nur noch das merkwürdige verhalten der MSA. Heute trat dieses Phänomen wieder auf, und das im Leerlauf. Es hatte eine Maschine Zugriff auf eine LUN, es lief aber kein Datenverkehr drüber. Heute habe ich aber auch einen Eintrag im Event Log:
Code: Alles auswählen
Critical Error: Fault Type: NMI p1: 0x022A197, p2: 0x0226FE6, p3: 0x0227015, p4: 0x02085AF CThr: MScrub 00Bei Google konnte ich dazu rein gar nichts finden, und der HP Support konnte keine Aussage machen.
Gruß
Christian
seppi hat geschrieben:die LUN's waren auf allen Servern sichbar. Also die 3 ESX'en hatten auf die beiden VM-LUN's Zugriff und auch auf das Windows LUN. Die Windows Kiste hatte ebenfalls Zugriff auf alle LUN's. Also dann ein Problem des Mapping. Was ich aber nicht ganz verstehe, wenn ich der Windows Kiste eine LUN einrichte mit dem iSCSI Initiator warum solle diese dann urplötzlich auf eine andere LUN zugreifen? Diese dann auch noch automatisch platt machen und Daten drauf schreiben. Klingt für mich jetzt unlogisch, aber ich lasse mich da gerne eines besseren belehren. Ein VCB Proxy ist nicht im Einsatz.
wenn du den windows iscsi initiator nutzt dann wählst du nur ein target nicht aber die lun aus. bedeutet der windows server hat alle luns gesehen und auf die esx-luns seine signatur geschrieben. daraufhin haben die esx-hosts ihr vmfs nicht mehr erkannt
Bleibt nur noch das merkwürdige verhalten der MSA. Heute trat dieses Phänomen wieder auf, und das im Leerlauf. Es hatte eine Maschine Zugriff auf eine LUN, es lief aber kein Datenverkehr drüber. Heute habe ich aber auch einen Eintrag im Event Log:Code: Alles auswählen
Critical Error: Fault Type: NMI p1: 0x022A197, p2: 0x0226FE6, p3: 0x0227015, p4: 0x02085AF CThr: MScrub 00
kenne mich mit der msa nicht aus aber ist der richtige hosttype gewählt?
Vorschlag:
Lass mal ein unabhängiges (VMware zertifiziertes) Systemhaus das System überprüfen - auch wenn "Du" dann als Dienstleister eventuell eingestehen musst Fehler gemacht zu haben....wenn der Kunde aber sieht, dass man was tut und für Ihn da ist dürfte das wohl kein Problem sein.
So ist dir/euch geholfen, weil ihr eventuelle Schwachpunkte/Fehler zukünftig zu vermeiden und der Kunde ist auch zukünftig wieder mit euch und VMware zufrieden, wenn er weiß wo das Problem lag. Wenn man "nur" irgendwie das System wieder gangbar macht, lebt der Kunde eventuell langfristig mit Sorgen, was niemand möchte.
Gruß
Lass mal ein unabhängiges (VMware zertifiziertes) Systemhaus das System überprüfen - auch wenn "Du" dann als Dienstleister eventuell eingestehen musst Fehler gemacht zu haben....wenn der Kunde aber sieht, dass man was tut und für Ihn da ist dürfte das wohl kein Problem sein.
So ist dir/euch geholfen, weil ihr eventuelle Schwachpunkte/Fehler zukünftig zu vermeiden und der Kunde ist auch zukünftig wieder mit euch und VMware zufrieden, wenn er weiß wo das Problem lag. Wenn man "nur" irgendwie das System wieder gangbar macht, lebt der Kunde eventuell langfristig mit Sorgen, was niemand möchte.
Gruß
-
irix
- King of the Hill
- Beiträge: 13063
- Registriert: 02.08.2008, 15:06
- Wohnort: Hannover/Wuerzburg
- Kontaktdaten:
seppi hat geschrieben:Hallo Zusammen,
die LUN's waren auf allen Servern sichbar. Also die 3 ESX'en hatten auf die beiden VM-LUN's Zugriff und auch auf das Windows LUN. Die Windows Kiste hatte ebenfalls Zugriff auf alle LUN's. Also dann ein Problem des Mapping. Was ich aber nicht ganz verstehe, wenn ich der Windows Kiste eine LUN einrichte mit dem iSCSI Initiator warum solle diese dann urplötzlich auf eine andere LUN zugreifen? Diese dann auch noch automatisch platt machen und Daten drauf schreiben. Klingt für mich jetzt unlogisch, aber ich lasse mich da gerne eines besseren belehren. Ein VCB Proxy ist nicht im Einsatz.
..
Na dann ist die Ursache doch mit hoher Wahrscheinlichkeit geklaert. Es muss ja nicht ein VCB Proxy sein. Ich hab das nur erwaehnt weil es im VMware Umfeld mit iSCSI eine hohe Wahrscheinlichkeit gibt das sowas eingesetzt wird und da dieser ja Zugriff auf die VMFS LUNs braucht muss bei der Config halt extrem aufpassen.
Wenn du hier und jetzt sagst das jeder Server, egal ob Windows oder ESX jede der vorhanden LUNs sehe konnte.... dann ist es klar warum auf den VMFS LUNs spuren von Windows waren.... der hat die Luns signieren wollen auch wenn das nicht deine Absicht war. Das machen halt alle Windowsversionen so bis auf die Datacenter Editions.
Jemand der VMware VI/vSphere einrichtet mit iSCSI weis das aber weil es in der Schulung behandelt wird. Das man es vergessen kann steht ausser Frage aber von aussen betrachtet sieht es doch so aus als ob das Masking garnicht zielgerichtet war.
Gruss
Joerg
-
Mr.Schrotti
- Member
- Beiträge: 212
- Registriert: 02.06.2007, 19:45
Hi,
das klingt hart. Möchte ich auf keinen Fall erleben.
Nun meine Frage würde es reichen wenn ich auf dem iSCSI als restriction einstelle das NUR die ESXi Server auf die LUN Zugreifen darf?
Von einer Physikalischen ja sogar von einer Trennung via vLAN sind wir noch etwas entfernt wird aber definitiv irgendwann passieren.
Ist leider bei uns nicht ganz so einfach umzusetzen da wir 2 Eigenständige netze haben mit 3 Räumen in dem je 1 Server steht. Der eine Server ist zur Zeit noch ein außenseiter und hätte dann keinen Zugriff mehr auf das iSCSI da ich den nicht ohne weiteres in das vLAN packen könnte.
Gruß
Mr.Schrotti
das klingt hart. Möchte ich auf keinen Fall erleben.
Nun meine Frage würde es reichen wenn ich auf dem iSCSI als restriction einstelle das NUR die ESXi Server auf die LUN Zugreifen darf?
Von einer Physikalischen ja sogar von einer Trennung via vLAN sind wir noch etwas entfernt wird aber definitiv irgendwann passieren.
Ist leider bei uns nicht ganz so einfach umzusetzen da wir 2 Eigenständige netze haben mit 3 Räumen in dem je 1 Server steht. Der eine Server ist zur Zeit noch ein außenseiter und hätte dann keinen Zugriff mehr auf das iSCSI da ich den nicht ohne weiteres in das vLAN packen könnte.
Gruß
Mr.Schrotti
Hallo Zusammen,
ich hatte eben nochmal ein längeres Gespräch mit dem Data Recovery Experten der zudem VMware certified proessional ist.
Das Windows alles LUN's gesehen hat und ggfls. seine Signatur drauf geschrieben hat, ist nicht für diese Schäden verantwortlich. Eine Windows Signature macht inder Regel auf "fremden" Disks keine Probleme oder richtet Schäden an.
Die Schwerwiegenden Schäden liegen an zerstörten Metadaten der vmdk's und an falschen Pointern in den EXT3 Volumes innerhalb der vmdk's. Alle anderen Schäden wären leicht und schnell behebbar gewesen.
Auch an falschen Mapping kann es nicht liegen, den Windows kann auf inkompatible Dateisysteme nicht einfach Daten schreiben. Die LUN's dürfen nach seiner Ansicht nach auch wenn im Regelfall nicht benötigt für Windows sichtbar sein. Im moment ist es auch so dass das Recovery auf einer Windows Maschine läuft, welche die Windows LUN (zum Speichern der recoverten Daten) und das defekte LUN sieht (auf der Kiste laufen die Analyse und Recovery Tools). Und das gibt laut Ontrack keinerlei Probleme.
Das Problem ist tatsächlich eher auf der MSA Seite zu suchen, bzw. am Storage Controller. Der heutige Ausfall der MSA hatte wie wir jetzt germekt haben wieder einen Datenverkust zu verzeichnen. Diesmal sind Teile der Windows LUN spurlos verschwunden. Zum Glück waren da nur die Recoverten Daten die ich schon weiter verarbeitet hatte drauf, was jetzt nicht weiter schlimm ist. Aber es macht deutlich dass diese Ausfälle im Zusammenhang mit dem Datenverlust(en) stehen.
Die genaue Ursache wird man vermutlich nie raus bekommen. Ontrack hat versucht Ursachen zu finden, aber das Schadensbild ergibt im gesamten keinen Zusammenhang und erscheint ziemlich verworen.
Gruß
Seppi
ich hatte eben nochmal ein längeres Gespräch mit dem Data Recovery Experten der zudem VMware certified proessional ist.
Das Windows alles LUN's gesehen hat und ggfls. seine Signatur drauf geschrieben hat, ist nicht für diese Schäden verantwortlich. Eine Windows Signature macht inder Regel auf "fremden" Disks keine Probleme oder richtet Schäden an.
Die Schwerwiegenden Schäden liegen an zerstörten Metadaten der vmdk's und an falschen Pointern in den EXT3 Volumes innerhalb der vmdk's. Alle anderen Schäden wären leicht und schnell behebbar gewesen.
Auch an falschen Mapping kann es nicht liegen, den Windows kann auf inkompatible Dateisysteme nicht einfach Daten schreiben. Die LUN's dürfen nach seiner Ansicht nach auch wenn im Regelfall nicht benötigt für Windows sichtbar sein. Im moment ist es auch so dass das Recovery auf einer Windows Maschine läuft, welche die Windows LUN (zum Speichern der recoverten Daten) und das defekte LUN sieht (auf der Kiste laufen die Analyse und Recovery Tools). Und das gibt laut Ontrack keinerlei Probleme.
Das Problem ist tatsächlich eher auf der MSA Seite zu suchen, bzw. am Storage Controller. Der heutige Ausfall der MSA hatte wie wir jetzt germekt haben wieder einen Datenverkust zu verzeichnen. Diesmal sind Teile der Windows LUN spurlos verschwunden. Zum Glück waren da nur die Recoverten Daten die ich schon weiter verarbeitet hatte drauf, was jetzt nicht weiter schlimm ist. Aber es macht deutlich dass diese Ausfälle im Zusammenhang mit dem Datenverlust(en) stehen.
Die genaue Ursache wird man vermutlich nie raus bekommen. Ontrack hat versucht Ursachen zu finden, aber das Schadensbild ergibt im gesamten keinen Zusammenhang und erscheint ziemlich verworen.
Gruß
Seppi
Hallo bla!zilla,
ich vernute mein Kunde hat auf extra Ausgaben beim Support verzichtet. Aber es kommt jetz nicht so sehr auf Geschwindigkeit an, da HP eh erst dann an die MSA darf wenn das recovery abgeschlossen ist.
Der Kunde hat bereits die gleiche MSA geordert und im Büro stehen. Die muss ich dann demnächst wohl in Betrieb nehmen. Die jetzige wird dann erstmal untersucht und repariert, und fungiert dann als Backup System. Da muss ich aber noch schauen was geschickter ist. Entweder als eigenes System mitlaufen lassen, oder mit de 2. MSA Koppeln... da könnte man ja mit zwei Controllern und 24 Platten schöne redundante Systeme herstellen. Wobei der Kunde (und im Monet auch ich) eher dazu tendieren die zweite MSA eigenständig mitlaufen zu lassen, und die Daten rüber zu syncronisieren. Dann geht bei einem Controller defekt nicht wieder gleich alles hops....
Grad habe ich wieder eine VM bekommen die aus Snapshots irgendwie zusammengebaut wurde. Ein Snapshot ist wohl ziemlich fehlerhaft gewesen, aber geschaft haben Sie es trotzdem das System vollständig wieder herzustellen. Unglaublich was die Jungs leisten.
ich vernute mein Kunde hat auf extra Ausgaben beim Support verzichtet. Aber es kommt jetz nicht so sehr auf Geschwindigkeit an, da HP eh erst dann an die MSA darf wenn das recovery abgeschlossen ist.
Der Kunde hat bereits die gleiche MSA geordert und im Büro stehen. Die muss ich dann demnächst wohl in Betrieb nehmen. Die jetzige wird dann erstmal untersucht und repariert, und fungiert dann als Backup System. Da muss ich aber noch schauen was geschickter ist. Entweder als eigenes System mitlaufen lassen, oder mit de 2. MSA Koppeln... da könnte man ja mit zwei Controllern und 24 Platten schöne redundante Systeme herstellen. Wobei der Kunde (und im Monet auch ich) eher dazu tendieren die zweite MSA eigenständig mitlaufen zu lassen, und die Daten rüber zu syncronisieren. Dann geht bei einem Controller defekt nicht wieder gleich alles hops....
Grad habe ich wieder eine VM bekommen die aus Snapshots irgendwie zusammengebaut wurde. Ein Snapshot ist wohl ziemlich fehlerhaft gewesen, aber geschaft haben Sie es trotzdem das System vollständig wieder herzustellen. Unglaublich was die Jungs leisten.
seppi hat geschrieben:Code: Alles auswählen
Critical Error: Fault Type: NMI p1: 0x022A197, p2: 0x0226FE6, p3: 0x0227015, p4: 0x02085AF CThr: MScrub 00
btw: Ihr habt ja eine Single-Controller MSA und dies ist ein NMI Event, also Hardware- oder Firmwarefehler. War bei euch das Vdisk Scrubbing aktiv? Ich meine mal ein Advisory gesehen zu haben, bei dem darüber berichtet wurde, dass Controller bei hoher Last und aktiviertem Scrubbing ausgestiegen sind. Welche Firmware habt ihr aktuell im Einsatz?
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 7 Gäste