Diskgroups auf EVA4400

[nightflight]

Hallo Community,

Wir haben bei uns als SAN-Storage für unsere vSphere4.1-Umgebung eine EVA4400 mit 24*450GB FC-HDDs. Alle HDDs sind in einer Diskgroup (single Protection Level).
Die vDisks sind als Raid5 konfiguriert und werden als VMFS-Datatores im VMware verwendet.
Jetzt haben wir nach Ausfall einer Platte festgestellt, dass das Leveling ca. 7 Stunden dauert.
Wenn ich die Technik richtig verstanden habe dürfte in den 7 Stunden keine weitere Platte ausfallen - sonst wird's finster ...
Das ganze finde ich bei 24 Platten ziemlich risikobehaftet - daher meine Frage,
Was würdet ihr empfehlen:
1.) Aufteilung in 3 Diskgroups a 8 Disks (Vorteil: Risiko eines 2. Plattenausfalls während Reconstruction in der selben Diskgroup wird gedrittelt. Nachteil: mühseliges Umschaufeln von Daten und Ungroup der einzelnen Platten - immer mit langwierigem Releveling) - Die I/O-Lastigen VM's würde ich natürlich gleichmäßig auf die Datastores/LUNS/vDisks/Diskgroups aufteilen.
2.) Die vDisks in Raid6 wandeln (Vorteil: 2 Platten können gleichzeitig ausfallen. Nachteil: viel "verlorener" Speicherplatz)

Was würdet ihr bevorzugen?
Sind obige Maßnahmen (Ungroup Disks , Change RaidLevel) überhaupt im laufenden Betrieb (VMs in den Datastores der vDisks aktiv) möglich?
Wird der Releveling-Prozess bei weniger Platten deutlich schneller?


Nachtrag: Das Leveling nach dem Einbau der Ersatzplatte hat dann nochmal ca. 20h gedauert.
Bedeutet für mich, wenn in den 7h nach dem Plattenausfall und in den 20h nach Einbau der Ersatzplatte eine 2. HDD ausfällt sind auch alle Raid5-vDisk's weg, richtig?

[bla!zilla]

Wir haben bei uns als SAN-Storage für unsere vSphere4.1-Umgebung eine EVA4400 mit 24*450GB FC-HDDs. Alle HDDs sind in einer Diskgroup (single Protection Level).
Die vDisks sind als Raid5 konfiguriert und werden als VMFS-Datatores im VMware verwendet. Jetzt haben wir nach Ausfall einer Platte festgestellt, dass das Leveling ca. 7 Stunden dauert. Wenn ich die Technik richtig verstanden habe dürfte in den 7 Stunden keine weitere Platte ausfallen - sonst wird's finster ...

Dann hast du sie zum Glück missverstanden.

Single Level Protection heißt: Die EVA hält in der Diskgroup die doppelte Größe der größten Platte der Diskgroup (bei dir also 900 GB) über alle Platten frei, um im Falle eines Plattenausfalls die ausgefallene Platte (sowie die Widow) dorthin wiederherzustellen. Ist genügend freier Platz in der Diskgroup frei, dann wird dieser genutzt. Der freie Platz ist reserviert und steht nicht zu Verfügung.

Tauscht du die defekte Platte aus, dann wird ein Leveling durchgeführt. Die EVA verteilt also die Daten wieder über alle Platten. Abhängig vom Füllstand der Disks kann das ein wenig länger dauern. Das Leveling ist als Housekeeping Prozess nicht sonderlich hoch priorisiert. Es geht also nur darum die Daten wieder richtig zu verteilen. Geschützt sind die Daten auf jedem Fall, da die Wiederherstellung in den freien Platz der Diskgroup/ reservierten Platz der Diskgroup direkt nach dem Plattenausfall beginnt.

Konkret: Nach einem Plattenausfall wird ein Sparing durchgeführt. Das ist der eigentliche Rebuild, danach sind die Daten wieder sicher. Anschließend kommt das Leveling und sortiert die Daten wieder gleichmäßig auf alle Platten. Dann steckst du eine Disk rein - ein erneutes Leveling findet statt. Das Leveling ist u.a. notwendig zur sauberen Aufteilung der Disks in die RSS.

Deine RAID 5 vDisks bestehen eigentlich aus vielen kleinen 4+1. Streng genommen, und unter günstigsten Bedingungen, könntest du sogar mehre Platten (eine pro RSS) verlieren, bevor deine RAID 5 vDisks sterben.

Lies dir das mal durch:
http://www.blazilla.de/index.php?/archi ... -PSEG.html

[nightflight]

Okay - Aufgefallen ist ja nur der langwierige Releveling-Prozess.

Das Sparing ist ja bestimmt so erstmal nicht sichtbar bzw sehr schnell ...

[bla!zilla]

Siehst du in den Logs. Und Leveling ist halt normal wenn Platten hinzukommen.

[nightflight]

Oki - vielen Dank für die Antworten und für die ausführlichen Erklärungen auf deiner Website !!!

Ich war schon kurz davor, mir Speicherplatz aus den Rippen zu schneiden und alle vDisk's in Raid6 umzuwandeln

[nightflight]

In welchem Log finde ich eigentlich einen Hinweis auf die Dauer des Sparings -
im Controler-Log oder im Managemnt-Log (das ist nämlich leider schon recycled)

Ich hab jetzt wie ein Verrückter den Controler-Log durchsucht aber habe nix gefunden...
Wie müßte den die Description oder der Event-Code dafür sein?

Liegt die dauer des Sparings eher im Sekunden- oder im Minutenbereich?

[mbreidenbach]

Aus eigener Erfahrung weiß ich daß das auch mal Wochen bis Monate dauern kann wenn man die EVA nicht richtig konfiguriert hat (in diesem Fall - allen verfügbaren Platz für LUNs vergeben hat und die EVA keinen Platz übrig hat um Daten intern umzuschaufeln)

[bla!zilla]

Joar, das Occupancy Alarm Level auf 99% setzen und die Kiste voll machen is doof.

[nightflight]

Die EVA ist zu 96% allociert.
Eine Diskgroup mit 24HDD (Protection Level single)
Platz sollte durch die 2*450GB Reserve über das Protection Level also da sein.

Wenn ich bla!zilla richtig verstanden habe startet das Leveling erst nach dem Sparing (also wen alle Raids wieder save sind) - in unserem Falle ist das ziemlich zeitnah passiert.

Meine Frage war nur: In welchem Log stehen die Einträge "Sparing Start" und "Sparing finished" (sinngemäß), sodaß ich mir nochmal genau ein Bild machen kann, wie zügig die EVA die Raid5 wieder abgesichert hat?

[bla!zilla]

96% is aber schon ordentlich...

Den Event findet im Event Log.

[nightflight]

96% is aber schon ordentlich...

Den Event findet im Event Log.

Ja, aber ich hätte gedacht, genau dafür habe ich mein ProtectionLevel single (also 900GB Speicher) - die 96% beziehen sich doch nur auf den verfügbaren Speicher - die 2*450GB aus der SingleProtection sind da doch nicht mit drinne, oder ???

Wenn ich ProtectionLevel NONE hätte wären 4% zur Raidrekonstruktion natürlich zu wenig aber so...

Und welcher Eventlog - Controller oder Management ???

[bla!zilla]

Müsste AFAIK im Controller Eventlog zu finden sein. Aber die CV Events landen auch im Windows Server Eventlog. Da kannst du ja mal filtern.

[nightflight]

@bla!zilla
Naja, im WindowsLog steht so ziemlich das gleiche wie im Controllerlog.
Die Einträge zum Leveling gibt's
"Leveling of capacity in a Disk Group has started/finished"
aber nix zum Sparing...
Aber wenn du sagst, dass das Leveling erst startet wenn das Sparing beendet ist und die Raidredundanzen wieder hergestellt sind dann passt das für mich - das Leveling hat bei uns bereits wenige Minuten nach dem Plattenausfall begonnen.

Trotzdem gut, den Controllerlog mal komplett durchzusehen:
CV hat nämlich momentan eine recht eigenwillige Auslegung was Severity von Event anbelangt.
Backend-FibreChannelPort down -> Informational Event
physical Disk reported CheckConditionError -> Informational Event
...
Hier muß ich mich wohl mal schleunigst nach nem funktionierenden ParseFile umsehen