In diesem Abschnitt dokumentieren wir den Testlauf für einen Fall, den man als Serverbetreiber am liebsten nie haben möchte: Ausfall einer Platte im RAID-1.
Alle Aktionen in diesem Abschnitt führen wir mit dem MegaCli auf der Shell des Hosts durch.

Erkennung eines Plattenausfalls

Ein Plattenausfall äußert sich darin, daß das Virtual Drive 0 nicht mehr als “Optimal” angezeigt wird. Ersichtlich wird dies im vSphere-Client unter Configuration / Health Status:
Esxi-raid-degraded
Außerdem läßt es sich in der Host-Shell mittels MegaCli abfragen:
[bash]/opt/lsi/MegaCLI # ./MegaCli -ldinfo -lall -aall
Adapter 0 — Virtual Drive Information:
Virtual Drive: 0 (Target Id: 0)
Name :
RAID Level : Primary-1, Secondary-0, RAID Level Qualifier-0
Size : 2.728 TB
Is VD emulated : Yes
Mirror Data : 2.728 TB
State : Degraded
Strip Size : 64 KB
Number Of Drives : 2
[…]
Exit Code: 0x00[/bash]
Wir hoffen, daß dort “Degraded” steht und nicht “Failed”, was bedeuten würde, daß beide Platten ausgefallen sind. Allerdings würde der Server dann wohl nicht mehr booten.
Natürlich ist es unschön, manuell im vSphere-Client oder auf der Shell des Hosts nach RAID-Ausfällen schauen zu müssen. Man möchte wohl eher aktiv darüber informiert werden. Daher ist – falls kein vCenter zur Verfügung steht, das Email-Alarme unterstützt – eine Methode wie das –HIER– beschriebene Monitoring des RAID-Status mittels MegaCli, SCP und Zabbix empfehlenswert.
Zur Identifizierung der ausgefallenen Platte kann man ebenfalls im vSphere-Client nachschauen, oder wir holen wir uns die Info der physikalischen Platten im MegaCli. Interessant sind hier die Einträge “Enclosure Device ID”, “Slot Number” und “Firmware State”.
[bash]/opt/lsi/MegaCLI # ./MegaCli -pdlist -aall
Adapter #0
Enclosure Device ID: 252
Slot Number: 0
[…]
Firmware state: Online, Spun Up
Enclosure Device ID: 252
Slot Number: 1
Firmware state: Online, Spun Up[/bash]
Wenn dort etwas anderes als “Online” steht, z.B. “Failed”, “Unconfigured Bad”, “Missing” oder “Offline”, ist die Platte aus dem Array geflogen. Die Enclosure und Slot Nummer merken wir uns.

Forcierter Plattenausfall für den Test

Wir führen unseren Test durch, indem wir eine der Platten im RAID mit zwangs-offline setzen. Die Platte gilt dann als “ausgefallen”.
[bash]MegaCli -pdoffline -physdrv[252:1] -a0 # For test only, don’t do this on your server!!
Adapter: 0: EnclId-252 SlotId-1 state changed to OffLine.
Exit Code: 0x00[/bash]
Hieraufhin wird das Array als “Degraded” markiert, wie oben aufgelistet. In unserem Beispiel haben wir also die Enclosure ID 252, Slot Number 1 “bearbeitet”. Das physikalische Laufwerk fürdie weiteren Kommandos ist damit die “252:1”.

Austausch der Platte

Zunächst markieren wir die ausgefallene Platte als “Missing”, falls dies nicht schon der Fall ist. Das Kommando pdgetmissing muß die Platte melden.
[bash]/opt/lsi/MegaCLI # ./MegaCli -pdmarkmissing -physdrv[252:1] -a0
EnclId-252 SlotId-1 is marked Missing.
Exit Code: 0x00
/opt/lsi/MegaCLI # ./MegaCli -pdgetmissing -aall
Adapter 0 – Missing Physical drives
No. Array Row Size Expected
0 0 0 2861056 MB
Exit Code: 0x00[/bash]
Die “Array” und “Row” Nummern merken wir uns für später.
Im Falle einer tatsächlich defekten Platte würden wir diese jetzt zum Austausch durch den Support vorbereiten:
[bash] MegaCli -pdprprmv -physdrv[252:1] -a0[/bash]
Nach Austausch muß die neue Platte u.U. mit Kommandos wie -pdmakegood oder -pdonline bereitgemacht werden. Der Status der Platte muß jedenfalls “Unconfigured Good” sein. In unserem Testvorgang ist dies automatisch der Fall, da wir die Platte nicht tatsächlich austauschen lassen.

Rebuild der neuen Platte

Die neue Platte wird als Ersatz für die ausgefallene bestimmt und der Rebuild gestartet. Für “array” und “row” wählen wir die Werte aus der Tabelle von eben:
[bash]/opt/lsi/MegaCLI # ./MegaCli -pdreplacemissing -physdrv[252:1] -array0 -row0 -a0
Adapter: 0: Missing PD at Array 0, Row 0 is replaced.
Exit Code: 0x00
/opt/lsi/MegaCLI # ./MegaCli -pdrbld -start -physdrv[252:1] -a0
Started rebuild progress on device(Encl-252 Slot-1)
Exit Code: 0x00[/bash]
Dann läuft der Rebuild. Über den Fortschritt können wir uns so informieren:
[bash]/opt/lsi/MegaCLI # ./MegaCli -pdrbld -showprog -physdrv[252:1] -a0
Rebuild Progress on Device at Enclosure 252, Slot 1 Completed 15% in 38 Minutes.
Exit Code: 0x00[/bash]
Nach Abschluß des Rebuild ist die Platte dann wieder “Online” und das Array “Optimal”.

8 Responses

  1. Hallo,
    im vSphere Client auf meinem ESXi (Hetzner EX4s LSI Raid Controller) wird bei Systemstatus hinter beiden Festplatten “Fw: n/a – UNCONFIGURED GOOD” angezeigt.
    Bei “./MegaCli -pdlist -aall” über die Konsole wird jedoch bei beiden “Firmware state: Online, Spun Up” angezeigt.
    Woran liegt das?

  2. Hi,
    danke für die schnelle Antwort. Ja ich hab schon den ganzen Blog durchsucht und probiert. Doch nichts hat geholfen. Hab den ESXi erst heute Abend aufgesetzt, hinter den zwei Platten wurde/wird immer nur “Fw: n/a – UNCONFIGURED GOOD” angezeigt. Kann es vll. sein das ich etwas vergessen habe zu installieren?
    Oder sonst noch eine Idee wie ich das Problem beheben könnte?
    Danke!


    1. lsiprovider 500.04.V0.34-0006 LSI VMwareAccepted 2013-06-12
      vmware-esx-MegaCli-8.07.06 8.07.06-01 LSI PartnerSupported 2013-06-12

      1. Hmm, habe gerade mit Frank gesprochen (mein Kollege, der mit mir zusammen das alles hier rund um Hetzner mit VMware ESXi geschrieben hat) der hat / hatte das gleiche Problem, das liegt an nem verbuggten LSI VIB. Die einzige Lösung ist leider es zu ignorieren und zu hoffen, das es in der nächsten Version wieder funktioniert, andere Lösung ist ein Downgrade vom LSI VIB, bis zur einer funktionierenden Version.
        Sonst kannst du ja mit Hilfe von Zabbix das Monitoring aktivieren: http://virtpro.eu/raid-monitoring-zabbix-lsi-megaraid/
        Sorry!

      2. Wie Sven schon schrieb: Das Problem liegt an einem Bug im CIM-Provider von LSI. Zumindest in der Version, die wir damals benutzt hatten, trat das auf. Vermutlich werden Deine Platten als 252:4 und 252:5 angezeigt, richtig? Die richtigen IDs wären aber 252:0 und 252:1. Da kriegt der CIM irgendwas nicht richtig mit/hin.
        In früheren Versionen war der Fehler nicht, dafür hat diese das syslog des ESXi massiv zugemüllt.
        Letztendlich habe ich den CIM-Provider von meinen ESXi-Servern runtergeworfen und arbeite nur noch mit dem MegaCLI, welches a) stündlich Status-Infos über die RAIDs an mein Zabbix schickt und b) einmal täglich selbige Infos an mich per Email (für den Fall, daß das Monitoring mal unbemerkt ausfällt).