Hallo Zusammen, Ich hab hier ein Software-Raid5 auf vier Platten. Eine der Platten haucht wohl bald ihr Leben aus, SMART meckert wegen mehr und mehr defekten Sektoren. Backups der wichtigen Daten auf dem Raid sind vorhanden, ein zeitaufwändiges Restore möchte ich dennoch vermeiden. Klar, die kranke Platte gehört ersetzt. Google findet hier haufenweise HowTos, aber alle nach dem Schema: Alte Platte als "failed" markieren. Rausnehmen. Neue Platte einbauen. Rebuild. Bzw, bei genug Anschlüssen: Neue Platte einbauen. Als Spare hinzufügen. Alte Platte als "failed" markieren. Rebuild. Beide haben das Risiko: Während des Rebuilds ist das RAID degraded, ein weitere Plattenausfall ==> Raid futsch. Und weil zwei der drei verbleibenden Platten aus derselben Serie wie die kranke kommen, und so ein Rebuild doch einigen Stress auf die Platten bringt: das Risiko ist mMn nicht vernachlässigbar. So, viel Text, nun die Frage: Geht das anders? Neue Platte sozusagen als Mirror der kranken in den Raid-verbund, kann im nicht-degradetem Zustand vollgeschrieben werden, dann die andere Raus? Das device-mapper Framework im Kernel müsste solche "schrägen" Raid-Strukturen hergeben, aber kriegt man das irgendwie vom userspace aus eingestellt? mdadm scheint jedenfalls nichts in der Richtung zu unterstützen. Danke!
pvmove sollte dein Freund werden, in Zukunft Raid6 statt Raid5 wählen.
Vielleicht würde ja ein Umweg über ein RAID 6 funktionieren: Einbauen Upgrade & Rebuild Downgrade und hierbei defekte Platte entfernen
Da Du Backups hast bist Du doch auf der sicheren Seite. Das noch eine zweite Platte ausgerechnet während des Rebuild den Geist aufgibt ist zwar möglich, aber eher unwahrscheinlich, erst recht, wenn sie noch keine Fehler meldet. (In 10 Jahren Berufserfahrung bei der Betreuung von einigen 1000 Servern ist mir das nicht ein einziges Mal passiert.) Sollte es doch passieren musst Du halt in den sauren Apfel beißen und restoren. Wenn Du Dir unsicher bist mache lieber noch ein weiteres Backup. Solltest Du auf Raid6 umsteigen wollen würde ich in jedem Fall erst die defekte Platte ersetzen, eventuell auch die, die Dir nicht mehr ganz geheuer sind, vorausgesetzt, die melden Fehler. Beim Umbau müssen nämlich alle Platten angefasst werden, nicht nur die neue, und es werden dabei keinesfalls weniger Daten bewegt als bei einem Rebuild, sondern mehr. Entsprechend höher ist das Risiko. Auch haben neue Platten ein höheres Ausfallrisiko als solche, die schon einige Zeit in Betrieb sind, also nach dem Ersetzen defekter Platen erst einige Zeit warten, bevor man den Umbau in Angriff nimmt.
Hab vor langer Zeit so eine Funktion in einem Hardware-Raid gesehen. Da konnte man (Menügeführt über Serielles Kabel) für den geplanten Plattenaustausch die Spare-Platte mit einer laufenden "Platz tauschen lassen". Einen Tag später waren dann die Daten umgeschaufelt, und man konnte die (neue) Spare-Disk entnehmen. Ich gehe davon aus, dass dieses Umkopieren soweit "Sicher" implementiert war, das auch währenddessen eine (beliebige) Platte ausfallen durfte. Für mdadm kenn ich so eine Funktion jedoch nicht.
Hallo, im Prinzip könntest du die fast defekte Platte herausnehmen und extern mit einem Imager duplizieren - aber nur wenn du den Server solange ausschalten kannst. Oder du riskierst es, ihn solange mit einer Platte weniger laufen zu lassen, aber das ist ja das Risiko das du vermeiden wolltest. Georg
Georg schrieb: > aber nur wenn du den Server solange > ausschalten kannst. Das wird wohl nicht möglich sein. Denn der einzige Grund für ein Raid ist ja gerade der unterbrechungsfreie Betrieb. Wenn es darauf nicht ankäme, könnte er ja einfach ein Rebuild machen, und für den unwahrscheinlichen Fall eines Doppelversagens einfach das Backup wieder einspielen.
Raid schrieb: > Ich hab hier ein Software-Raid5 auf vier Platten. > Eine der Platten haucht wohl bald ihr Leben aus, SMART meckert wegen > mehr und mehr defekten Sektoren. ... > Beide haben das Risiko: Während des Rebuilds ist das RAID degraded, ein > weitere Plattenausfall ==> Raid futsch. > > Und weil zwei der drei verbleibenden Platten aus derselben Serie wie die > kranke kommen, und so ein Rebuild doch einigen Stress auf die Platten > bringt: das Risiko ist mMn nicht vernachlässigbar. > Geht das anders? Jein. Zuerst mal: dieses Risiko ist nicht neu. Aus genau diesem Grund wird bei großen Arrays (wo die Zeitdauer, in der das RAID5 während des Rebuild degraded ist, eine signifikante Länge aufweist) statt dessen RAID6 empfohlen. Was du machen kannst: 1. das Array offline nehmen oder doch zumindest read-only machen. Die kranke Platte auf die neue Platte klonen. Array stoppen, kranke Platte entfernen und das Array mit den verbleibenden Platten wieder starten. 2. die neue Platte hinzufügen und das RAID5 auf RAID6 umkonfigurieren. Sobald das fertig ist, kann die kranke Platte als failed deklariert werden. Das RAID6 läuft dann degraded (mit verminderter Redundanz) weiter. Variante 1 funktioniert so nur, wenn du die kranke Platte noch komplett(!) auslesen kannst. Variante 2 dauert länger als ein RAID5 Rebuild und benötigt temporär zusätzlichen Plattenplatz (Manual lesen). Außerdem läßt Variante 2 ein RAID6 mit verminderter Performance zurück. Es wäre dann höchst empfehlenswert, eine weitere Platte dazu zu stecken und in Zukunft ein komplettes RAID6 zu fahren. Da du aber ein Backup hast, würde ich es einfach darauf ankommen lassen und ein normales Rebuild versuchen. Hat bei mir schon einige Male funktioniert. Anfangs mußte ich das RAID sogar einige Tage degraded lassen, weil ich keine Ersatzplatte im Haus hatte. Mittlerweile habe ich eine Spare-Platte permanent im System stecken. Irgendwann mal will ich das auf RAID6 migrieren. Vielleicht warte ich aber auch noch, bis ich die Hardware komplett ersetze und setze dann ein frisches RAID6 auf. XL
Georg schrieb: > Hallo, > > im Prinzip könntest du die fast defekte Platte herausnehmen und extern > mit einem Imager duplizieren - aber nur wenn du den Server solange > ausschalten kannst. Oder du riskierst es, ihn solange mit einer Platte > weniger laufen zu lassen, aber das ist ja das Risiko das du vermeiden > wolltest. > > Georg pvmove macht das online und atomar.
Vielen Dank für die Antworten! A. K. schrieb: > Du hast doch bestimmt einen Backup. RAID ersetzt keinen Backup. Ja, hab ich extra im Eröffnungs-Post geschrieben. Fifal schrieb: > pvmove sollte dein Freund werden Fifal schrieb: > pvmove macht das online und atomar Geht in dem Fall leider nicht. Setup ist 4 Platten -> Raid5 -> LVM d.h. /dev/md0 ist mein PV. Damit pvmove hilft, bräuchte ich ein zweites Raid mit mindestens selber Größe, um ganz /dev/md0 zu ersetzen. Fifal schrieb: > in Zukunft Raid6 statt Raid5 wählen. Elektro, Junge! schrieb: > Vielleicht würde ja ein Umweg über ein RAID 6 funktionieren: Sind leider nur 4 Plattenslots vorhanden. Temporär könnte ich da mit fliegend verkabelter Platte, USB-HDD oder NBD arbeiten, aber nicht als Dauerlösung. RAID6 wäre anschließend auch zu klein. Georg schrieb: > im Prinzip könntest du die fast defekte Platte herausnehmen und extern > mit einem Imager duplizieren Wäre eine Option, aber: Die Platte meldet mehrere "CurrentPendingSectors" und einen "OfflineUncorrectableSector". Das Image würde also nicht 100% OK sein. Εrnst B✶ schrieb: > Hab vor langer Zeit so eine Funktion in einem Hardware-Raid gesehen. Bin also nicht der Einzige, der an so ein Szenario gedacht hat :) Axel Schwenke schrieb: > Da du aber ein Backup hast, würde ich es einfach darauf ankommen lassen > und ein normales Rebuild versuchen. A. H. schrieb: > In 10 Jahren Berufserfahrung bei der Betreuung von > einigen 1000 Servern ist mir das nicht ein einziges Mal passiert. Ok, also geh ich den "Normalen Weg" mit "mdadm --fail" und rebuild. Besten Dank nochmal!
A. K. schrieb: > Du hast doch bestimmt einen Backup. RAID ersetzt keinen Backup. Hat auch niemand behauptet. Macht das irgendwie besonders stolz, unreflektiert und voellig unpassend coole Netzsprueche zu zitieren? Jeder, der schonmal wirklich ein xTera-System restoren musste, weiss, dass es sich lohnt das zu vermeiden. Und nichts Anderes will der TO - das Risiko eines noetigen Neuaufbaus und Restores vermeiden.
Raid schrieb: > Wäre eine Option, aber: Die Platte meldet mehrere > "CurrentPendingSectors" und einen "OfflineUncorrectableSector". Das > Image würde also nicht 100% OK sein. Nicht unmittelbar, aber dann hast du eine technisch einwandfreie Platte, vielleicht lassen sich dann die Fehler beheben oder verschwinden von selbst. Aber der von der Software vorgesehene Weg ist, nach einem Sicherheitsbackup, wohl der beste. Georg
Raid schrieb: > Fifal schrieb: >> pvmove sollte dein Freund werden > > Fifal schrieb: >> pvmove macht das online und atomar > > Geht in dem Fall leider nicht. > Setup ist 4 Platten -> Raid5 -> LVM > d.h. /dev/md0 ist mein PV. Damit pvmove hilft, bräuchte ich ein zweites > Raid mit mindestens selber Größe, um ganz /dev/md0 zu ersetzen. Die Raid-Member sind also nicht unter lvm Kontrolle? Was spuckt denn "pvs" und "fdisk -l" aus?
Schon mal was von google gehört ? Die Suche hat exakt 1 Minute gedauert.... Wie lange hast du gebraucht um deinen Beitrag zu tippen? http://unix.stackexchange.com/questions/74924/how-to-safely-replace-a-not-yet-failed-disk-in-a-linux-raid5-array Im untersten Beitrag findest du zwei Varianten für mdadm < 3.3 < Und man sieht, die Entwickler haben auch genau an deinen Fall und deine Wünsche gedacht .....
nighty2k schrieb: > Im untersten Beitrag findest du zwei Varianten für mdadm < 3.3 < Wow. Danke! Ich hab mich durch zwei Seiten Google-Hits geklickt, die alle nur das übliche "degrade -> rebuild"-Prozedere vorgeschlagen haben. Und ja: Ich habe länger gesucht als das Tippen des Eröffnungs-Posts gebraucht hat. meine mdadm-Version ist 3.2.6 (Oktober 2012) deshalb waren dessen Manpages auch keine Hilfe. Kernel-Version müsste jedoch passen, und mdadm ist ja schnell aktualisiert. Also: # mdadm /dev/md0 --replace /dev/bald-kaputt --with /dev/neu-und-gut :)
Fifal schrieb: > Die Raid-Member sind also nicht unter lvm Kontrolle? Nein. Raid-Member sind direkt die Platten-Partitionen. Das Raid-Device md0 ist dann ein LVM-PV. > Was spuckt denn "pvs" und "fdisk -l" aus? PV /dev/md0 und vier Platten mit Typ 0xFD "Raid Autodetect" Partitionen. Macht man das sonst wirklich anders herum? Also erst die Einzel-Platten als PVs und dann ein Raid über LVs aus dem LVM? Zum Vergrößern einer Parition müsste man dann erstmal vier LVs vergrößern und dann das Raid? Oder packt man eine zweite LVM-Schicht hinter das Raid aus LVM-LVs? Kommt mir unnötig komplex vor.
Wenn Du einen LVM hast und vielleicht sogar ohnehin planst, drei Deiner vier Platten zu ersetzen (klang ein wenig danach), dann würde ich Dir doch empfehlen, etwas größere Platten zu kaufen und im LVM auf RAID1 zu gehen. Das spart die eine komplette Software-Schicht, macht das ganze System einfacher, weniger fehleranfällig, wahrscheinlich auch performanter und im LVM hättest Du kein Probleme, im Fehlerfall eine dritte Platte in den Spiegel zu nehmen, bevor Du die angeschlagene heraus nimmst. Mit etwas Geschick könntest Du die ganze Migration sogar Online hinkriegen. Vier Platten im RAID6 würden ohnehin wenig Sinn machen. (OK, theoretisch können dann zwei beliebige Platten gleichzeitig ausfallen, aber der kleine Vorteil kostet nicht unerheblich Performance.)
A. H. schrieb: > dann würde ich Dir > doch empfehlen, etwas größere Platten zu kaufen und im LVM auf RAID1 zu > gehen. Das spart die eine komplette Software-Schicht, macht das ganze > System einfacher, weniger fehleranfällig, wahrscheinlich auch > performanter Dito. Siehe auch: http://www.baarf.com/
Thread beobachten
Seitenaufteilung abschaltenBitte 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.