VMFS Volume defekt

[Armadill0]

Hallo zusammen,

ich habe aktuell das Problem, dass auf meinem ESXi 4.0 Server nach einem Absturz ein VMFS Volume verschwunden ist. Ein Rescan brachte leider keinen Erfolg. Der Raid-Controller der das RAID5 da darunter läuft managed wird problemlos erkannt.
Folgendes sagt mir fdisk:

Code: Alles auswählen

~ # fdisk -l /dev/disks/mpx.vmhba2:C0:T0:L0

Disk /dev/disks/mpx.vmhba2:C0:T0:L0: 1999.2 GB, 1999296790528 bytes
255 heads, 63 sectors/track, 243067 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

                          Device Boot      Start         End      Blocks  Id System
/dev/disks/mpx.vmhba2:C0:T0:L0p1             1    243067 1952435613+  fb  VMFS

Sieht für mich alles normal aus.

Das Interessante ist, dass ich gerade mal von USB einen neuen ESXi 4.1 gestartet habe. Dort wird das VMFS Volume zeitweise erkannt. Allerdings wird die Größe völlig falsch dargestellt (mehrere Millionen TB statt knappe 2TB) und wenn ich auf Speicher durchsuchen gehe, dann ist er einfach leer. Ab und an verschwindet dann das Volume auch wieder und es erscheint wieder, wenn ich alles erneut prüfen lasse.

Hier mal die /var/log/messages:
http://www.penguinfriends.org/download/messages.txt

Die Fehlermeldungen da drin sehen echt böse aus. Aber ich weiß nicht so wirklich, wo der Fehler liegt. I/O Error hört sich halt auch echt ungut an.

Vielleicht weiß jemand von euch Rat, wäre echt dankbar!

[Dayworker]

Hast du herausbekommen, weshalb der ESXi abgestürzt ist?
Wenn er das VMFS-Volume zeitweise erkennt, kann es in meinen Augen nur am Raid-Controller liegen.

[Armadill0]

Nein, habe leider keine Ahnung, warum der Server abstürzt. In den Logs findet man danach ja leider gar nichts.

Ich hatte auch noch keinen kaputten RAID-Controller, kann schon sein, dass es davon kommt.

Wir sind inzwischen allerdings weitergekommen. Wir könnten über eine Linux-Livedistri mit dem Opensource-vmfs-Treiber anfangen die Daten aus dem Volume auf andere Platten zu sichern.

[Armadill0]

Guten Morgen,

leider sieht es aktuell so aus, dass heute Nacht die Sicherung irgendwann abgebrochen ist.
Aktuell versuche ich eine andere Methode und mir sind über dmesg von Knoppix folgende Meldungen im dmesg aufgefallen:

Code: Alles auswählen

[60160.054718] Buffer I/O error on device sdb1, logical block 45056
[60160.054723] Buffer I/O error on device sdb1, logical block 45057
[60160.054728] Buffer I/O error on device sdb1, logical block 45058
[60160.054733] Buffer I/O error on device sdb1, logical block 45059
[60160.054738] Buffer I/O error on device sdb1, logical block 45060
[60160.054743] Buffer I/O error on device sdb1, logical block 45061
[60160.054748] Buffer I/O error on device sdb1, logical block 45062
[60160.054753] Buffer I/O error on device sdb1, logical block 45063
[60160.089508] sd 3:0:0:0: [sdb] Unhandled sense code
[60160.089513] sd 3:0:0:0: [sdb] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[60160.089518] sd 3:0:0:0: [sdb] Sense Key : Hardware Error [current]
[60160.089524] sd 3:0:0:0: [sdb] Add. Sense: Internal target failure
[60160.089530] sd 3:0:0:0: [sdb] CDB: Read(10): 28 00 00 00 b0 80 00 00 08 00
[60160.089545] end_request: I/O error, dev sdb, sector 45184
[60160.089550] Buffer I/O error on device sdb1, logical block 45056
[60160.089554] Buffer I/O error on device sdb1, logical block 45057
[60167.746674] sd 3:0:0:0: [sdb] Unhandled sense code
[60167.746680] sd 3:0:0:0: [sdb] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[60167.746686] sd 3:0:0:0: [sdb] Sense Key : Hardware Error [current]
[60167.746694] sd 3:0:0:0: [sdb] Add. Sense: Internal target failure
[60167.746702] sd 3:0:0:0: [sdb] CDB: Read(10): 28 00 00 00 b0 80 00 00 08 00
[60167.746717] end_request: I/O error, dev sdb, sector 45184
[60167.746722] __ratelimit: 6 callbacks suppressed
[60167.746726] Buffer I/O error on device sdb1, logical block 45056
[60167.746732] Buffer I/O error on device sdb1, logical block 45057
[60167.746736] Buffer I/O error on device sdb1, logical block 45058
[60167.746741] Buffer I/O error on device sdb1, logical block 45059
[60167.746746] Buffer I/O error on device sdb1, logical block 45060
[60167.746750] Buffer I/O error on device sdb1, logical block 45061
[60167.746755] Buffer I/O error on device sdb1, logical block 45062
[60167.746760] Buffer I/O error on device sdb1, logical block 45063
[60167.781516] sd 3:0:0:0: [sdb] Unhandled sense code
[60167.781520] sd 3:0:0:0: [sdb] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[60167.781525] sd 3:0:0:0: [sdb] Sense Key : Hardware Error [current]
[60167.781531] sd 3:0:0:0: [sdb] Add. Sense: Internal target failure
[60167.781537] sd 3:0:0:0: [sdb] CDB: Read(10): 28 00 00 00 b0 80 00 00 08 00
[60167.781551] end_request: I/O error, dev sdb, sector 45184
[60167.781555] Buffer I/O error on device sdb1, logical block 45056
[60167.781560] Buffer I/O error on device sdb1, logical block 45057

Sieht in der Tat so aus, als ob da was kaputt ist beim RAID.

[Dayworker]

Kann es sein, daß Knoppix dein Raid5 nicht erkennt und du deshalb IO-Probleme mit "sdb1" angezeigt bekommst.
Normalerweise solltest du bei einem aktiven Raid keine einzelnen Platten sondern das Raid angezeigt bekommen oder liege ich da falsch???

[Armadill0]

Hi, doch das Knoppix erkennt das RAID. Die Daten sind jetzt über gefühlte 1000 Umwege und diverse unterschiedliche Versuche mit diversen Tools gerettet.
Grundsätzlich kann jeder RAID-Controller auch Daten über seine angehängten Festplatten an das System weitergeben. In der Regel, genau wie in diesem Fall geschieht das dann aber über den zugehörigen Treiber, in diesem Fall der aacraid-Treiber.
Die Platten können übrigens beim aacraid-Treiber über die sg-Devices abgerufen werden. Dadurch können sogar SMART-Werte der Platten abgerufen werden.

Dazu musste Folgendes durchgeführt werden:
- über die vmfs-tools das vmfs Volume mounten (fuse-Treiber):

Code: Alles auswählen

vmfs-fuse /dev/sdb1 /vmfs-ordner

- mit kpartx das vmdk-File-flat File als Raw/Loopback-Device einbinden:

Code: Alles auswählen

kpartx -av /pfad/Disk-flat.vmdk

- mit mount des Dateisystem innerhalb des vmdk Files mounten:

Code: Alles auswählen

mount /dev/mapper/loop0p1 /ordner -o ro

readonly deshalb, weil es sich in unserem Fall um ein NTFS-System gehandelt hat und man den Treiber lieber nichts schrieben lassen sollte. Er hat das NTFS allerdings sofort als nicht ordnungsgemäß beendet erkannt und das soweit gefixt.

Anschließend sind alle Daten aus dem Ordner abrufbar und können auf beliebige Art und Weise kopiert werden. Es kann sein, dass man bei großen Datenmengen alles mal unmounten und wieder neu einbinden muss, weil sich das Konstrukt dann aufhängt, anschließend funktioniert es aber wieder einwandfrei.

Nun zur Ursache meines Problems:
Der Grund warum sich das Ganze so ereignet hat ist wohl, dass der aktivierte WriteBackCache auf dem Controller, welcher übrigens ein Adaptec 2410SA ist, nicht sonderlich wohl gefühlt hat, als der Server abgestürzt ist und somit der Cache plötzlich leer war.
Abhilfe schafft in Zukunft entweder eine BBU oder die Deaktivierung des Caches.

Warum der Server abstürzt weiß ich allerdings weiterhin nicht.

Ich hoffe dass andere Leute von der Aktion noch profitieren können.

[Dayworker]

Nun zur Ursache meines Problems:
Der Grund warum sich das Ganze so ereignet hat ist wohl, dass der aktivierte WriteBackCache auf dem Controller, welcher übrigens ein Adaptec 2410SA ist, nicht sonderlich wohl gefühlt hat, als der Server abgestürzt ist und somit der Cache plötzlich leer war.
Abhilfe schafft in Zukunft entweder eine BBU oder die Deaktivierung des Caches.

Das ist ja wohl nichts neues. Ein Raid ohne BBU und mit aktivem WriteBack ist immer ein völlig unnötiges Risiko. Deshalb deaktiviert eigentlich jeder vernünftige Controller immer das WriteBack ohne installierte BBU.

Wenn du nicht gerade ein lahmes Raid1 im Einsatz hattest, dürfte dir der Direktzugriff auf eine einzelne Platte des Raidverbundes wie "/dev/sdb1" absolut nichts bringen.

[Armadill0]

Nun zur Ursache meines Problems:
Der Grund warum sich das Ganze so ereignet hat ist wohl, dass der aktivierte WriteBackCache auf dem Controller, welcher übrigens ein Adaptec 2410SA ist, nicht sonderlich wohl gefühlt hat, als der Server abgestürzt ist und somit der Cache plötzlich leer war.
Abhilfe schafft in Zukunft entweder eine BBU oder die Deaktivierung des Caches.

Das ist ja wohl nichts neues. Ein Raid ohne BBU und mit aktivem WriteBack ist immer ein völlig unnötiges Risiko. Deshalb deaktiviert eigentlich jeder vernünftige Controller immer das WriteBack ohne installierte BBU.

Hat er aber offensichtlich nicht.

Wenn du nicht gerade ein lahmes Raid1 im Einsatz hattest, dürfte dir der Direktzugriff auf eine einzelne Platte des Raidverbundes wie "/dev/sdb1" absolut nichts bringen.

Es handelt sich bei /dev/sdb1 NICHT um eine einzelne Festplatte. Es ist das RAID-Device, wie es vom aacraid-treiber geliefert wird. Es ist übrigens ein RAID5.