Ich habe einen Server mit 6 Platten. Ich bin ja ein Freund von RAID1 - einfach und sicher. Nun möchte ich aber da Mal über den Tellerrand hinaus schauen. Wie sind eure Erfahrungen mit z.b. RAID10 oder Raid5. Bei RAID10 würde sich ja ein Setup aus 2x2 + 2 HotSpare anbieten. Aber machen zwei HotSpare Platten wirklich Sinn? Bei RAID5 würde ich dann eher nur auf eine HotSpare setzen und hätte dann ja 4D+1P+1HS was ja an Geschwindigkeit und Datenvolumen schon super wäre. Allerdings bin ich am Arsch wenn zwei Platten abrauchen. Was allerdings in einer ungünstigen Konstellation auch im RAID10 der Fall wäre. Die Größe des Volume ist hier nicht der Ausschlag gebende Punkt. Da dies die Systemplatten wären, die Userdaten liegen auf einer externen Fault. Was sind da so eure Präferenzen?
Ein System OS auf 6 Platten? mach raid 1 für OS und gut ist. Nutze die anderen 4 für Daten ... Auch hier wieder raid 1 für privat. Alles Andere ist meiner Meinung nach im Fall der Fälle zu kompliziert. Und wenn Du lernen willst dann mach einfach, probe aber auch den Ernstfall,soll heißen ziehe Platten als simulierten Ausfall des RAID und versuche mal an die Daten ohne Rebuild und einem anderen PC dranzukommen... Ich denke du bist schnell wieder bei RAID 1
Rene K. schrieb: > Nun möchte ich aber da Mal über den Tellerrand hinaus schauen. Wenn schon Neues, dann vielleicht ZFS? Redundanz im Filesystem statt separat, Snapshots usw.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Wenn schon, dann vielleicht ZFS? Nein, ZFS bin ich aktuell gerade ganz weit weg gekommen. Nach dem Verlust einer einzigsten Platte hat sich das ganz Volume verabschiedet und lies sich, auch in Teilen, überhaupt gar nicht mehr herstellen. Mir sind die Vorteile von ZFS bekannt, aber diese Überwiegen genau diesen Nachteil in keinster Weise.
Moin, - meine Frau kocht Suppe mit einem grossen Loeffel. Soll heissen, solange Du Deine Requirements nicht aufschreibst kann man nichts empfehlen. Raid 6 schiebt das Problem mit der Belastung beim Rebuild ein wenig weiter, aber prinzipiell ist da kein Unterschied zu Raid 5. Und die Tradeoffs Nutzplatte / Plattenplatz vs. Geschwindigkeit sind auch offensichtlich. Du musst latuernich auch die passende Hardware haben (z.B. Controller mit acht Ports) und sinnvoll waere auch ein Monitor-System (nagios, Icinga). Und es ist auch wichtig, wie wichtig Dir die Verfuegbarkeit der Daten ist. Gruesse Th. P.S.: Heute geht etwas in die Pfanne, nix Suppe.
Bei sechs Platten wuerde ich genau ein Stripeset ueber alle Platten bauen. Das steigert die Geschwindigkeit naehrungsweise um den Faktor sechs. Da bekanntermassen einzelne Platten nie kaputt gehen, ist auch die Zuverlaessigkeit auf eben diesem hohen Niveau. :)
Rene K. schrieb: > Mir sind die Vorteile von ZFS bekannt, aber diese Überwiegen genau > diesen Nachteil in keinster Weise. Welche Nachteile? Ich bin gespannt.
Thomas W. schrieb: > Raid 6 schiebt das Problem mit der Belastung beim Rebuild ein wenig > weiter, aber prinzipiell ist da kein Unterschied zu Raid 5. Es dürfen dann 2 Disks kaputt gehen. Es hilft aber natürlich nicht gegen 6 annähernd gleichzeitig defekte Disks.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Thomas W. schrieb: >> Raid 6 schiebt das Problem mit der Belastung beim Rebuild ein wenig >> weiter, aber prinzipiell ist da kein Unterschied zu Raid 5. > > Es dürfen dann 2 Disks kaputt gehen. Es hilft aber natürlich nicht gegen > 6 annähernd gleichzeitig defekte Disks. Ja, und haeufig kauft man die sechs Platten in einem Auftrag (wg. Rabatt und Gewaehrleistung). Und dann sind sie alle gleich alt, mit gleicher Ausfallwahrscheinlichkeit (alt-werden ist Mist). Gruesse Th.
Thomas W. schrieb: > Ja, und haeufig kauft man die sechs Platten in einem Auftrag Hey, manche kaufen hunderte Disks in einem Auftrag, alle aus der gleichen Quelle. Sollte man die vorsorglich in 49 Parity-Disks und eine Date-Disk gruppieren. ;-)
:
Bearbeitet durch User
Da geht es aber um ein anderes Problem. Nicht Datensicherheit mit Datenverfügbarkeit verwechseln. Ein RAID ist eben kein Backup. Aber ein RAID garantiert Verfügbarkeit auch wenn eine Platte ausfällt. Dann kommt eine neue Platte rein und es wird wieder die Redundanz hergestellt. Und nur während dieser relativ kurzen Phase darf keine andere Platte sterben. Und auch das nur um die Verfügbarkeit zu garantieren. Stirbt trotzdem eine zweite Platte ist man eben kurz offline mit dem RAID und spielt das Backup ein.
Thomas W. schrieb: > Ja, und haeufig kauft man die sechs Platten in einem Auftrag (wg. Rabatt > und Gewaehrleistung). Und dann sind sie alle gleich alt, mit gleicher > Ausfallwahrscheinlichkeit (alt-werden ist Mist). Da gibt's einen einfachen Trick. Jeweils nur Eine auspacken, anschließen und sofort hoch laufen lassen. Mit allen weiteren so verfahren. So sind sie dann schon vor dem logischen Eingliedern in das RAID unterschiedlich stark gealtert. ;-)
:
Bearbeitet durch User
Mit einem passenden (LTO/DLT/...-)Streamer, kann man die sechsfache Geschwindigkeit des Stripesets fuer sehr schnelle Backups nutzen. Bei sechs Platten kommt da schon was zusammen...
Sicher dass du überhaupt ein RAID brauchst? Manche verwechseln RAIDs mit Backups. Ein RAID dient der Ausfallsicherheit und ersetzt kein Backup.
Gustl B. schrieb: > Dann kommt eine neue Platte rein und es wird wieder die > Redundanz hergestellt. Und nur während dieser relativ kurzen Phase darf > keine andere Platte sterben. Ein Raid5 Rebuild ist selten "relativ kurz" und Erfahrungsgemäß stirbt im privat betriebenen Umfeld genau während des Rebuild durch die erhöhte Last auf den Platten, die zweite Platte. Denn meistens ist es nämlich genau so: Thomas W. schrieb: > Ja, und haeufig kauft man die sechs Platten in einem Auftrag (wg. Rabatt > und Gewaehrleistung). Und dann sind sie alle gleich alt, mit gleicher > Ausfallwahrscheinlichkeit (alt-werden ist Mist). Unabhängig davon sind aber für eine sinnvolle Beantwortung der Ursprungsfrage zu wenig Informationen da. Ich hab in meinem Server 4 Platten als RAID10 und als "Backup" das gleiche nochmal. Aufgebaut auf 2 mittlerweile betagten HP Gen8 Microservern mit ULP Xeons drin. Jetzt kann ich natürlich noch anfangen ein Backup vom Backup zu machen und mindestens ein Backup dieses Backup in einem komplett anderen Gebäude zu lagern usw. Ist eben die Frage wie "wichtig" die Daten sind und wieviel Aufwand man betreiben möchte, bzw. wieviel Schaden entsteht wenn sie weg sind.
Gustl B. schrieb: > Welche Nachteile? Ich bin gespannt. Die Nicht-Wiederherstellbarkeit bei Verlust auch nur einer Platte aus einem LVM Verbund. Das schlimme an diesem Fall ist: Es wurde von jeder Platte ein DD Backup gemacht - eine Wiederherstellung, auch nach Rückspielung, ging nicht. Ja ich weiß, man hätte statt DD auch Snapshots machen können / müssen, aber wenn solch ein System bereits auf Hardwareebene versagt, dann ist dies für mich ein no-go. Es geht nicht um Backup oder Datensicherheit. Es geht mir eher um die Verfügbarkeit. Backup und Nutzdaten liegen, wie erwähnt auf einem externen Fault. Bei einem RAID1 war dies bis dato eben völlig simpel und der Ausfall bei einem Plattendefekt hat sich gen 0 genähert. Bei RAID5 ist die Belastung halt extrem hoch auf die verfügbaren Platten bei der Wiederherstellung und bei Platten mit 4TB dauert dies bei dem relativ Leistungsschwachen Controller schon einige Zeit. Da wäre der Vorschlag von px mit dem RAID6 schon besser. Oder eben ein RAID1+0 - bei einem RAID0+1 wäre ja dann auch die Belastung wieder hoch, weil ja dann die ganzen Platten aus dem 0 wieder gespiegelt werden müssten. Die Platten hängen an einem P420 - ja das ist ein 8-Port Controller.
Rene K. schrieb: > Bei RAID10 würde sich ja ein Setup aus 2x2 + 2 HotSpare anbieten. Aber > machen zwei HotSpare Platten wirklich Sinn? Hotspare macht keinen Sinn, außer die Arbeit des Admins das LW zu tauschen dauert zu lange. Die sind genau so lange am Strom wie die anderen, nur weniger Motorstunden. Man tauscht also das Risiko das sie einfach mal an Elektronikstunden sterben gegen Verstaubung (Cold Reserve gegen Hotspare) oder das Risiko das sie bei einem Rebuild eingesetzt werden und eins der anderen Drives stirbt gegen die Alterung im Betrieb (Hotspare gegen zus. Paritydrive) Für 3-5 Drives sollte man R5 nehmen, ab 5-6 kann bzw. sollte es R6 sein. Dann hat man alle Drives im Einsatz und muss nicht laufen. Rene K. schrieb: > Bei RAID5 würde ich dann eher nur auf eine HotSpare setzen und hätte > dann ja 4D+1P+1HS was ja an Geschwindigkeit und Datenvolumen schon super > wäre. R6 erlaubt zwei beliebige Tode im RAID und hat o.G. Vorteile ggü. Hotspare. R5 mit 6 Drives ist höheres Risiko als 5+Coldspare, plus "wo ist das Scheißding" im Krisenfall und Rebuildbombe. Und: soweit mir mal beigebogen wurde ist ein non-Stripe-RAID nicht schneller als ein einzelnes Drive, weil ja alle Drives gelesen werden müssen um die Sets zu vergleichen, bzw. alle Daten sicher auf die Drives geschrieben werden müssen.
Rene K. schrieb: > Gustl B. schrieb: >> Welche Nachteile? Ich bin gespannt. > > Die Nicht-Wiederherstellbarkeit bei Verlust auch nur einer Platte aus > einem LVM Verbund. Das schlimme an diesem Fall ist: Es wurde von jeder > Platte ein DD Backup gemacht - eine Wiederherstellung, auch nach > Rückspielung, ging nicht. Ja ich weiß, man hätte statt DD auch Snapshots > machen können / müssen, aber wenn solch ein System bereits auf > Hardwareebene versagt, dann ist dies für mich ein no-go. Das ist aber Dein Unvermoegen: Du hast im laufenden System eine unkonsistente Kopie gezogen, und das kann klappen oder auch nicht. Meistens nicht. Du brauchst Verstaendnis der eingesetzten Werkzeuge. Gerade ZFS ist eigentlich sehr stabil, man muss es nur bedienen koennen (und nicht herumbasteln). Es wuerde auch helfen, die Dokumentation zu lesen und verstehen. Gruesse Th.
Thomas W. schrieb: > man muss es nur bedienen koennen Richtig, und bei einem RAID1 ziehe ich die Defekte Platte und stecke die neue ein - Das war's. Da brauche ich weder mit Snapshots arbeiten noch sonst etwas. Aber sei es drum. Ich weiß das es damals mein Fehler / Unverständnis über ZFS war.
Ich A. schrieb: > Ein Raid5 Rebuild ist selten "relativ kurz" und Erfahrungsgemäß stirbt > im privat betriebenen Umfeld genau während des Rebuild durch die erhöhte > Last auf den Platten, die zweite Platte. > Denn meistens ist es nämlich genau so: > > Thomas W. schrieb: >> Ja, und haeufig kauft man die sechs Platten in einem Auftrag (wg. Rabatt >> und Gewaehrleistung). Und dann sind sie alle gleich alt, mit gleicher >> Ausfallwahrscheinlichkeit (alt-werden ist Mist). Dir ist klar was Ausfallwahrscheinlichkeit bedeutet? Das heißt nicht, dass die Platten am gleichen Tag ausfallen. Ja, beim Rebuild hat man höhere Last, aber man sollta ja sowieso regelmäßig Backup machen und gegen Bitrot auch mal einen Scrub (ZFS). Die paar Stunden müssen die Platten das eben aushalten und das RAID ist ja gleichzeitig auch verfügbar. Wenn noch eine Platte stirbt spielt man das Backup ein, dafür hat man das, sollte aber nur extrem selten benötigt werden. Ich A. schrieb: > Aufgebaut auf 2 mittlerweile betagten HP Gen8 > Microservern mit ULP Xeons drin. Das hab ich auch, funktioniert wunderprächtig. Rene K. schrieb: > Die Nicht-Wiederherstellbarkeit bei Verlust auch nur einer Platte aus > einem LVM Verbund. Das schlimme an diesem Fall ist: Es wurde von jeder > Platte ein DD Backup gemacht - eine Wiederherstellung, auch nach > Rückspielung, ging nicht. Ja ich weiß, man hätte statt DD auch Snapshots > machen können / müssen, aber wenn solch ein System bereits auf > Hardwareebene versagt, dann ist dies für mich ein no-go. Ja was ist denn nun kaputtgegangen, der LVM Verbund oder das ZFS RAID? Backup macht natürlich nur vom ganzen Volume Sinn, du willst ja, dass das Backup auch konsistent ist. Darüber hinaus ist ein Backup nur ein Backup wenn man das auch wieder herstellen kann. Das sollte man also ganz dringend testen. Zumindest einmalig und immer wenn man was an der Backupmethode geändert hat. Rene K. schrieb: > Es geht nicht um Backup oder Datensicherheit. Es geht mir eher um die > Verfügbarkeit. Backup und Nutzdaten liegen, wie erwähnt auf einem > externen Fault. Na dann einfach Backup einspielen fertig. Bei ZFS gibt es send/receive um das über Netzwerk/SSH zu übertragen, man kann aber auch auf der Backupplatte einen zpool anlegen. Dann steckt man die Backupplatte an und kann lokal mit z. B. rsync das Backup machen.
Jens M. schrieb: > Und: soweit mir mal beigebogen wurde ist ein non-Stripe-RAID nicht > schneller als ein einzelnes Drive, weil ja alle Drives gelesen werden > müssen um die Sets zu vergleichen, bzw. alle Daten sicher auf die Drives > geschrieben werden müssen. Lesend wird im RAID Layer nichts verglichen. Da liest man von nur einem Drive des Mirrors und verlässt sich auf den Check des Drives, oder bei manchen modernen Filesystemen auf eine Checksum im FS. Ab und zu macht man bei RAID allerdings eine Komplettkontrolle im Hintergrund.
:
Bearbeitet durch User
Das kommt stark auf den Raid-Controller an. Die professionellen prüfen die komplette Integrität der Daten, sprich die Spiegelungen werden komplett mitgelesen und alles verglichen. Patrol-Read (in Leerlauf-Zeiten wird regelmäßig der komplette Inhalt der Festplatten gelesen und getestet, ob dabei Fehler auftreten) machen eigentlich auch nur professionelle Controller.
Ben B. schrieb: > Patrol-Read (in Leerlauf-Zeiten wird regelmäßig der komplette Inhalt der > Festplatten gelesen und getestet, ob dabei Fehler auftreten) machen > eigentlich auch nur professionelle Controller. Ist ebenso in mdraid, btrfs und ZFS vorgesehen.
:
Bearbeitet durch User
Ben B. schrieb: > Die professionellen prüfen die komplette Integrität der Daten, sprich > die Spiegelungen werden komplett mitgelesen und alles verglichen. Welche? Bei RAID 1 wär's ja noch machbar, wenngleich ich das als Standardbetrieb bei jedem Lesezugriff für wenig sinnvoll halte. Machen die das dann auch bei einer RAID 6 Gruppe aus 12 Disks bei jedem Lesezugriff?
Frag mich nicht mehr nach genauen Typen, die in den Racks verbaut waren. Das ist zu lange her und waren alles SAS Enterprise-Lösungen, mit denen man im privaten Bereich nichts zu tun hat, das war alles viel zu teuer. Soweit ich mich erinnere verteilt Raid 6 die Daten und (doppelte) Paritäts-Informationen über alle Platten in einem Array, also müssen auch alle Platten gelesen werden wenn man einen Datenblock lesen oder testen möchte. Der Trend geht heute wohl in den meisten Fällen zu Raid 0,1 und 5 oder zu Kombinationen aus diesen (Raid 10 und 15), Raid 6 dürfte eine Nische sein. Nachtrag: Aus seinen 6 Platten könnte man z.B. ein sehr schönes Raid 15 bauen, was den gleichzeitigen Ausfall von drei Platten verkraften würde. Bei einer toten Platte pro Raid 5 passiert gar nichts, bei drei Platten (oder zwei Platten im gleichen Raid 5) ist eines der Raid 5 tot und das Raid 1 rettet, bei vier defekten Platten braucht man Glück, daß es die letzte Platte des bereits toten Raid 5 trifft. Bei zwei defekten Platten pro Raid 5 war's das.
:
Bearbeitet durch User
Ben B. schrieb: > also müssen > auch alle Platten gelesen werden wenn man einen Datenblock lesen oder > testen möchte. Nein, das läuft bei normalen Lesevorgängen anders. Man verlässt sich darauf, dass eine Disk ja nicht einfach jeden Mist durchreicht, sondern darauf überprüft, ob der Lesevorgang erfolgreich war. Ein Lesezugriff von z.B. 4 KB wird folglich an die eine Disk weitergeleitet, auf der diese Daten direkt stehen. Ist dieser Zugriff erfolgreich, ist die Sache damit beendet. Es werden keine Daten von anderen Disks gelesen (oder allenfalls zwecks Caching möglicherweise folgender Zugriffe). Erst wenn dieser Disk-Zugriff seitens der Disk mit Fehler quittiert wird, wird es erforderlich, die Daten anhand der übrigen Sektoren sowie der Parity-Information zu rekonstruieren. Dann, und nur dann, werden alle zu dieser Parity gehörenden Daten mitsamt der Parity gelesen, und die verlorenen Daten zurückgewonnen. Entsprechend langsamer arbeitet das System dann. Manche Filesysteme wie etwa ZFS und btrfs enthalten unabhängig davon Vorkehrungen gegen Fehler, die nicht von der Disk selbst erkannt werden. Auch das ist aber kein Datenvergleich, sondern eine separate blockbezogene Checksum über die wie beschrieben gewonnenen Daten. Erst Scrubbing, Patrol Read und wie solche regelmässigen bei schwacher Last im Hintergrund laufenden Routinekontrollen jeweils genannt werden, lesen alle Inhalte mitsamt Parity und kontrollieren die Konsistenz. NB: Auch beim Schreiben werden nicht notwendigerweise alle Sektoren betrachtet, aus denen sich eine RAID 5 Parity ableitet. Es kann nämlich je nach konkret anstehender Transfergrösse ökonomischer sein, den alten Sektorinhalt aus der Parity raus- und den neuen reinzurechnen, weil das gerade bei kleinen Requests auf grossen RAID Gruppen weit weniger Zugriffe beinhaltet.
:
Bearbeitet durch User
Beitrag #7427007 wurde vom Autor gelöscht.
Ben B. schrieb: > Der Trend geht heute wohl in den meisten Fällen zu Raid 0,1 und 5 oder > zu Kombinationen aus diesen (Raid 10 und 15), Raid 6 dürfte eine Nische > sein. Bei den hier betrachteten 6 Disks passt das, auch wenn manche aus Angst vor dem oft in den Medien berichteten (aber vmtl nicht ganz so oft selbst erlebten) Fehler bei Wiederherstellung auch dann schon RAID 6 in Betracht ziehen könnten. Grössere Gruppen fahre ich mindestens mit RAID 6, z.B. günstige Storage-Systeme mit 12 HDDs. Aber da du es warst, der professionelle System anführte: NetApp verwendete früher vorzugsweise RAID DP (deren Pendant zu RAID 6) in Gruppen von bis zu 28 Disks. Für noch grössere Gruppen wird mittlerweile RAID TEC (triple error correction) eingesetzt. Andere RAID Techniken findet man dort allenfalls bei den Systemdisks, denn bei nur wenigen Disks verwendet man deren Systeme üblicherweise nicht.
:
Bearbeitet durch User
Die professionellen Systeme entwickeln sich natürlich weiter und ich habe auch keinen Überblick darüber, was 2023 aktuell überall in Verwendung ist. Da gibt's inzwischen so viel verschiedenes und die "alten" Lösungen sind ja auch nicht wirklich schlecht, Geschwindigkeit wird immer wichtiger... "Früher Raid 6" - ja das glaube ich. Raid 5 erfordert einen enormen Rechenaufwand (XOR-Operationen), die Controller besaßen damals schon spezielle ASICs dafür oder wenn es "nicht ganz so Enterprise-Level" war, dann z.B. den i960 (32 Bit RISC Prozessor). Da kann es durchaus sein, daß man zur Vermeidung dieser hohen Rechenlast eher Raid 6 verwendet hat. Mit Deinem "nicht alle Platten lesen" gehe ich nicht mit, denn wenn ich beim Lesen einen Fehler feststelle und mir dann erst bei einer noch nicht gelesenen Platte Ersatz-Daten bestellen muss, dann fange ich mir eine ziemliche Delle in der Zugriffszeit ein und das will ich definitiv nicht. Beim Raid 5 z.B. geht's auch gar nicht anders, da die Daten über alle Platten verteilt liegen. Heißt ich muss alle Platten lesen (schon alleine um Fehler feststellen zu können, in Daten, die ich nicht lese, kann ich auch keinen Fehler feststellen), beim Raid 0 müssen ebenfalls alle Platten gelesen werden, weil die Daten nirgendwo anders verfügbar sind. Raid 0 ist nur was für Geschwindigkeit und absolut nichts für Datensicherheit. Bei 4 Platten Raid 0 hätte ich zwar die vierfache Geschwindigkeit einer einzelnen Platte, aber auch eine viermal so hohe Ausfallwahrscheinlichkeit.
:
Bearbeitet durch User
Ben B. schrieb: > "Früher Raid 6" - ja das glaube ich. Raid 5 erfordert einen enormen > Rechenaufwand (XOR-Operationen), die Controller besaßen damals schon > spezielle ASICs dafür oder wenn es "nicht ganz so Enterprise-Level" war, > dann z.B. den i960 (32 Bit RISC Prozessor). Da kann es durchaus sein, > daß man zur Vermeidung dieser hohen Rechenlast eher Raid 6 verwendet > hat. Das "früher RAID 6" leitest du vmtl von meiner Aussage "früher RAID DP" bei NetApp ab. Allerdings hast du das missverstanden, denn das läuft so:
1 | kleine RAID-Gruppe: RAID 4 = 1 dedizierte Parity Disk |
2 | mittlere RAID-Gruppe: RAID DP = 2 Parity Disk, linear+diagonal |
3 | grosse RAID-Gruppe: RAID TEC = 3 Parity Disks, linear+diagonal+antidiagonal |
Der rechnerische Aufwand steigt mit der Anzahl Parity Disks. RAID TEC ist vergleichsweise neu, daher mein "früher". > Mit Deinem "nicht alle Platten lesen" gehe ich nicht mit, denn wenn ich > beim Lesen einen Fehler feststelle und mir dann erst bei einer noch > nicht gelesenen Platte Ersatz-Daten bestellen muss, dann fange ich mir > eine ziemliche Delle in der Zugriffszeit ein und das will ich definitiv > nicht. Ein RAID System hat dabei mehrere Möglichkeiten. Es läuft letztlich auf die Frage hinaus, ob die Disk als ausgebucht eingestuft wird, oder als teilweise lesbar. Das ist eine Entscheidung der Implementierung. > Beim Raid 5 z.B. geht's auch gar nicht anders, da die Daten über > alle Platten verteilt liegen. Insgesamt betrachtet liegen sie verteilt, im Detail betrachtet hingegen nicht unbedingt. Das hängt von der Grösse des Transfers ab. Die Daten von Transfers innerhalb eines Stripes von z.B. 256 KB befinden sich auf nur einer Disk, werden also nur von dieser Disk gelesen. Diese Eigenschaft führt dazu, dass die Grösse des Stripes ein Optimierungsparameter abhängig von der typischen Nutzung ist. Kleine Stripes verteilen die Requests mit zunehmender Grösse auf mehrere Disks, zugunsten der Transferrate - aber eben deshalb auch zulasten der Zugriffszeit bei vielen parallelen Operationen, weil mehr Disks busy sind. > Heißt ich muss alle Platten lesen (schon > alleine um Fehler feststellen zu können, in Daten, die ich nicht lese, > kann ich auch keinen Fehler feststellen), Es ist nicht der RAID Layer, der Lesefehler erkennt. Das macht die Disk selbst. Der RAID Layer reagiert jedoch auf solche Lesefehler. Weiss dieser Layer aus voriger leidvoller Erfahrung, dass ein Zugriff auf Block 1 Disk 2 nicht funktionieren wird, wird er darauf auch keinen Zugriff mehr versuchen. Das kann aber unterschiedlich implementiert sein. Typisches Verhalten bei NetApp: Eine Disk, auf der ein ernster Fehler auftrat ohne dabei komplett auszufallen, wird ausgebucht und durch eine Spare ersetzt. Anschliessend wird die Disk im Hintergrund auf Herz und Nieren geprüft. Übersteht sie das, wird sie wieder als Spare freigegeben, ansonsten muss sie ersetzt werden. HDD-Systeme, die sich dem hinteren Ende der Badewannenkurve nähern, weil Richtung 10 Jahre, zeigen deshalb einen gewissen Ping-Pong Effekt. Es kann dann einige solche Zyklen dauern, bis eine Disk endgültig als failed klassifiziert wird. > beim Raid 0 müssen ebenfalls > alle Platten gelesen werden, weil die Daten nirgendwo anders verfügbar > sind. Auch für RAID 0 aka Striping gilt das, was ich oben schrieb. Transfers innerhalb eines Stripes bleiben auf nur einer Disk.
:
Bearbeitet durch User
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.