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!
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 werdenFifal 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?
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/
