RAID-5

R> Ich hoffe, Isotopp wirft den Text aus #offtopicana nachher noch ins Blog.

Okay, hiermit getan.

O> Tu ich in den Ersatz-Server nun 2 oder 4 500er-Platten?

R> Machs richtig.

B> Nimm 4. Oder 5, wenn es geht. Vier im Raid, eine als Hot Spare.

I> Raid-5 nur mit Hot Spare (außer bei mir daheim). Raid-5 im Degraded Mode hat einen tierischen Overhead. So hoch, daß man sich die Frage “Prio auf normale Accesses oder Prio auf Reconstruct” nicht stellen muss.

B> I: ah? Danke für den Hinweis.

I> Raid-5 undegraded mit 4 platten: Du hast Chunks von x kb (etwa 64k), und zwar 1. Chunk auf Disk A, 2. Chunk auf Disk b, 3. Chunk auf Disk C und Parity auf Disk 4.

I> Das ist eine Raidline, hier mit Size = 3x64k = 192k.

I> Nächste Raidline hat 4. chunk auf A, 5. chunk auf B, Parity auf C und 6. Chunk auf D.

I> Nächste dann 7=A, Parity=B, 8=C und 9=D

I> Dann Parity=A, 10=B, 11=C und 12=D.

I> Parity läuft also um. Da bei jedem Write auch Parity geschrieben wird, verteilen sich so die Parity Writes auf alle Spindeln.

I> Ein long write ist ein Rewrite einer ganzen Raidline, also hier 192k am Stück auf einer 192k-Grenze. Passiert oft bei Fileservern, die etwa Mediafiles schreiben. Das sind drei logische Writes: write 1, write 2, write 3. Die werden zu 4 physikalischen writes: write 1, write 2, write 3 und write p = 1 xor 2 xor 3.

I> Ein short write ist jeder andere write. Passiert oft bei Datenbanken. Ein LOGISCHER write (write 1) wird hier zu 4 physikalischen Disk Operations:

• read 1,
• read parity,
• (parity xor 1 xor 1neu = parity_neu),
• write 1neu,
• write parity_neu.

I> Mit Caches kann ein Raid-5 2 von den 4 physikalischen Operations eliminieren (die beiden Reads). Daher sind Raid-5 sehr schlecht bei Datenbanken und allem anderen Zeugs mit kleinen Writes.

I> Reads skalieren fein: ein 4-Disk Raid-5 performt beim Read wie ein 3-Disk Raid-0. Das ist gut

I> Das sind die “undegraded” Fälle. Jetzt failed eine Platte, sei es disk C. Wir lesen 1 → read A. Wir lesen 2 → read B.

I> Wir lesen 3 → Read D, (cacheable) read A, (cacheable) read B und deliver 3 = p xor a xor b.

I> Wenn wir short Reads haben, wird also jeder Read auf die failed Disk zu einem Read ALLER anderen Disks. Mit Caches geht es dann wieder.

I> Mit einem Hot Spare geht das Array bei einem Failure sofort in den Reconstruct und sollte so konfiguriert sein, daß es so viel Power als möglich in den Reconstruct steckt: Alle Idlezeit und garantierte Mindestbandbreite so konfiguriert, daß Wirkbetrieb gerade noch erträglich geserved wird.

I> Sobald das hotspare dann in sync ist, kann der Wirkbetrieb wieder ohne degraded Performance sauber geliefert werden. Und die Redundanz ist wieder hergestellt, Plattenfehler treten oft als Doppelfehler auf, das ist wie bei Glühbirnen, die haben ja auch dieses Gruppen-Fehlerverhalten.

O> Und um die Lehrstunde komplett zu machen, sagst Du mir, wie ich mit 4 Platten möglichst gut fahre.

I> 3 Platten ist minimum für Raid-5. Also 3+hotspare nach Lehrbuch, oder 4+keine spare und volles Risiko. Offiziell würde man immer 3+hotspare bauen und bei entsprechender Verfügbarkeitsanforderung auch noch Hotplug-Rahmen nehmen. Vielleicht mal mit Micha von Delta Computer reden. Die Plattengehäuse von Supermicro find ich jedenfalls gut.