Thema: Was brauche ich für ein Raidsys. zu erstellen?

soo da ich seit heute nachmittag im besitz von ingesamt 8 250GB hdds von seagate bin, welche mit jeweils 4 im raid5 laufen an jeweils getrennten controllersn hier mal meine meinung zum raid5:

raid5 ist eine weiterentwicklung des raid10. raid10 bietet zwar geschwindigkeit und sicherheit, lässt aber nur die hälfte der platten als wirkliche nutzkapazität zu. raid5 hingegen nutzt genau die anzahl der zusammengefügten platten verringert um eine. raid5 besiert auf einer paritätsberechnung. sagen wir wir haben 8 hdds im raid5. die daten werden in stücke aufgeteilt (ähnlich raid0) nach 7 datenpaketen wird auf hdd acht jedoch ein parity-paket geschieben, aus dem sich im fall eines ausfalls einer platte dennoch alle daten basteln lassen (quasi liegt nun nen raid0 vor, nur dass das parity-paket entschlüsselt werden muss). die parity-pakete versteuern sich gleichmäßig auf alle hdds. wird nur eine platte für die partity-pakete benutzt so nennt sich dies raid4 (oder war es raid3 :hmm: egal eh fast nciht mehr genutzt )

raid6 funktioniert nahezu iedentisch, nur dass immer zwei parity-pakete anstehen, anstatt eins. so können maximal zwei platten ausfallen. frage die sich mir immer noch stellt: kostet mich das raid6 geschwindigkeit im vergleich zum raid5, da mehr parity-berechnungen anstehen?

eng mit der parity ist auch die frage verknüpft: brauche ich nen eigenen controller? hier kann generell gesagt werden, dass dieser für raid0/1/10 nicht sonderlic viel bringt. es wird ja nix berechnet sondern nur aufgesplittet. hier reicht normal die hostcpu. gibt kleinere vorteile insbesondere wenn es um readbalancing oder controller-cache geht.

für raid 5/6/50/60 ist jedoch ein extra controller mit IO-prozessor fast pflicht. insbesondere beim sogenannten software-raid5 (die CPU des rechners berechnet die parity) hab ich ne hohe cpu-last und sehr geringe schreibraten. die können selbst unterhalb denen einer einzelnen hdd liegen.
auch beim lesen erzielen sich nahezu transferraten, wie sie im raid0 der CPU zu erwarten sind. meine vier hdds erzielen um die 150MB/s durchschnitt bei den standardeinstellungen normaler benchmarks. vorteil des controllers hier: raid0 mit sicherheit namens raid5

nun aber zum schreiben. hier liegt auch der speed um den wert einer einzelnen hdd. jedenfalls wenn der controllercache nicht "genutzt" wird. man hat z.b. 512MB RAM auf der karte, die einem aber nicht sonderlich viel bringen. der passende begriff ist hier "write through" also "Durchschreiben". wie funktoniert das? recht einfach. das filesysem möchte etwas auf die hdds schreiben. der controller berechnet die parity (beim raid5/6) und schreibt diese und die daten auf die hdds. danach kommt die bestätigung ans filesystem, dass die daten auf den platten liegen. man sieht hier wird nix zwischengespeichert. der controllervorteil beschänkt sich somit auf den IO-prozessor der die daten berechnet (und dafür vielelicht auch den cache nutzt).

nun zur nutzung des cache beim schreiben. hier kommen wir zum "write back"-modus. hier wird zurückgeschrieben. das filesystem möchte daten auf die hdds bringen. der controller berechnet hier auch daten und parity. danach kommen diese in den controllercache und es wird die bestätigung ans filesystem gegeben. halt: richtig sie sind noch nicht auf die platten geschrieben. dies erfolgt erst "wenn der controller dazu zeit hat". vorteil: ram-schreibgeschwindigkeit bei kleinen daten. bei großen kommt ne pufferwirkung zum tragen. aber nun der nachteil: ram kann ja leider keine daten behalten wenn kein strom da ist. fällt also bei noch nicht geschriebenen daten der strom aus, so sind die weg. das erzeugt dateifehler im filesystem (denn sie sind ja angeblich schon geschrieben). der vorteil der geschwinidgkeit beim schreiben hat auch nen sicherheitsrisiko.
wie wirkt man dem entgegen? ganz einfach: man nimmt nen akku und hält die daten im ram im notfall am leben. eine USV kann hier auch helfen. bei einem unsauberen runterfahren kann es aber auch zum leeren cache kommen. somit ist ne BBU (battery backup unit =akku) zur sicherheit auch hier ganz nett.

ich persönlich würde auch mit bbu und usv meinem os-raid keinen write-back modus gönnen. es wird zuviel während des betriebs geschrieben und ich hab keine ahnung was derzeit grade ganz genau. daher write back bei mir nur für die daten-array(s). hier hab ich zumindest bei mir am rechner/netzwerk die übersicht was grad geschrieben wird. sollte wirklich mal was passieren, so kann ichs zur sicherheit nochmal schreiben lassen.

soviel zu theorie. was bringt mir das? hier mal zwei kopiervorgänge mit den gleichen daten (große daten - bei kleinen sind die werte niedriger)

write through modus (beide arrays 16k stripe size= die datenpakete des controllers beim aufsplitten sind genau 16kb groß):



also genau die geschwindigkeit einer einzelplatte wie schon oft gesagt. nun das ganze im write back modus:



kopiert wurden größere archive und images (600MB-10GB pro datei). bei kleinen (mp3s o.ä.) gibts aber immer noch gut 90-100MB/s)

werde mir wegen den ergebnissen doch ne bbu gönnen bei guten controllern lässt sich aber auch per management-software zwischen write back und through im betrieb switchen. hab ich keine lust auf langes kopieren großer dateien kann ich hierfür ins write back wechseln (z.b. bestand altes array aufs neue legen und nur kopieren und nicht verschieben - beim fehler liegt ja noch alles vor).

"2fast" find ich ja mal nen netten rechnernamen

der cache puffert wunderbar. wenn die daten drinne liegen ist ja genaug zeit. mache gehen schnell auf die platten, manche halt langsamer.