Hallo Liste,
Zuerst eine Einführung, damit mein Anliegen vielleicht besser verstanden wird: Ich hab einen Server mit großen internen Platten, auf die diverse Backups geschrieben werden. Die Daten sind zu wichtig um dass ich sie im Server klauen oder verbrennen lassen will, drum stecken gleich große Platten extern (usb, fw, esata) dran und ich habe mittels mdadm je über eine interne und externe ein Raid gespannt (Spiegel). Würden die Externen da jetzt immer verbleiben hätte ich außer höherer Ausfallsicherheit nichts erreicht, deshalb werden die jede Woche getauscht und ausgelagert um eine Woche später wieder "dran" zu sein. Die resultierende mdX-Partition habe ich komplett durch truecrypt gezogen und dann gibt samba Teile frei und/oder rsnapshot schreibt direkt drauf. Die Verfügbarkeit der resultierenden Partition sollte nahezu "immer" sein.
Momentan wechsle ich die Platten so: ich erkläre den Fehler (mdadm --fail) für die zu entnehmende Platte im Verbund, entferne diese (mdadm --remove) und hänge die neue dran (mdadm --re-add). Nun dauert der sync nach Anhängen ewig und belastet das System.
Die Verfügbarkeit der Schalter -add und --re-add suggeriert mir, dass auch nur ein sync der geänderten Blöcke möglich wäre, würde ich die Platte nicht mit --fail rausnehmen.
- Liege ich mit der Vermutung richtig? - Für wie viel "Änderung" reicht denn der Metadatenblock, ein paar Dutzend gb ändern sich ein einer Woche schon? - Wie entferne ich eine Platte ohne --fail?
Dann gibt es gelegentlich noch ein Problem, und das ist die Unterstützung der Controller der externen Schnittstellen. Keiner (ob esata, fw, usb) ist stabil (habe auch verschiedenste Controller/Chipsätze probiert), der Kern meldet immer mal den Verlust einer dieser externen Platten (auch da habe ich reichlich ein Dutzend durch). Da fliegt z.B. /dev/sde1 weg und es wird manchmal /dev/sdf1 erkannt. /proc/partitions führt dann sde noch, aber ein Zugriff ist nicht möglich. Mdadm hat wegen udev längst sf1 in den Verbund aufgenommen und /proc/mdstat führt nun sde1 mit "F" was zu regelmäßigen Mails führt.
Jetzt würde ich sdeX gern los, was so leicht nicht geht, das /dev wohl dynamisch ist und /dev/sdeX fehlt. Selbst wenn ich nun mittels mknod eines anlege mag mdadm das nicht:
backup:~# /sbin/mdadm -q --manage /dev/md0 --remove /dev/sde1 mdadm: hot remove failed for /dev/sde1: No such device or address backup:~# ls -la /dev/sde* brw-r--r-- 1 root disk 8, 54 16. Mär 08:37 /dev/sde brw-r--r-- 1 root disk 8, 55 16. Mär 08:37 /dev/sde1
- Wie kann ich hier ohne reboot aufräumen?
Mit freundlichen Grüßen / With kind regards Ronny Seffner
Hallo!
Am 16. März 2011 09:01 schrieb Ronny Seffner ronny@seffner.de:
Momentan wechsle ich die Platten so: ich erkläre den Fehler (mdadm --fail) für die zu entnehmende Platte im Verbund, entferne diese (mdadm --remove) und hänge die neue dran (mdadm --re-add). Nun dauert der sync nach Anhängen ewig und belastet das System.
Die Verfügbarkeit der Schalter -add und --re-add suggeriert mir, dass auch nur ein sync der geänderten Blöcke möglich wäre, würde ich die Platte nicht mit --fail rausnehmen.
- Liege ich mit der Vermutung richtig?
- Für wie viel "Änderung" reicht denn der Metadatenblock, ein paar Dutzend
gb ändern sich ein einer Woche schon?
- Wie entferne ich eine Platte ohne --fail?
Du tauschst also immer die externe Platte, 1 Woche lang Platte A, 1 Woche lang Platte B? Ich denke der richtige Ansatz wäre dann, das Raid 1 mit der internen Platte, der externen Platte A und der externen Platte B aufzusetzen. So sollte kein kompletter rebuild nötig sein nach 1 Woche Abwesenheit - denke ich.
Viele Grüße!
-- morphium - morphium@jabber.ccc.de - 113332157 http://identi.ca/morphium - http://twitter.com/morphium86
Hallo morphium,
Ich denke der richtige Ansatz wäre dann, das Raid 1 mit der internen Platte, der externen Platte A und der externen Platte B aufzusetzen. So sollte kein kompletter rebuild nötig sein nach 1 Woche Abwesenheit
- denke ich.
Das wäre ein Ansatz, an den ich noch nicht gedacht habe, aber die Kernfragen bleiben die gleichen: - Wie werde ich jede Woche einer dieser Platten los, ohne sie "hart" abzuziehen (zumal extern A und B mangels Schnittstellen nie gleichzeitig stecken werden)? Momentan funktioniert das --remove eben erst nach dem --fail. - Habe ich das Konzept mit den metadaten überhaupt richtig verstanden und kann also ein Teilrebuild nach einer Woche überhaupt noch funktionieren?
Mit freundlichen Grüßen / With kind regards Ronny Seffner
Das wäre ein Ansatz, an den ich noch nicht gedacht habe, aber die Kernfragen bleiben die gleichen:
Vergessen hatte ich noch: - Wenn das "mdX" dann aus 3 devices besteht und immer eines fehlt habe ich doch weiterhin die Warnmails am Hals? Abstellen will ich die aber nicht für den Fall, das mal nur noch ein device da ist.
Mit freundlichen Grüßen / With kind regards Ronny Seffner
Hallo Ronny
Jetzt würde ich sdeX gern los, was so leicht nicht geht, das /dev wohl dynamisch ist und /dev/sdeX fehlt. Selbst wenn ich nun mittels mknod eines anlege mag mdadm das nicht:
backup:~# /sbin/mdadm -q --manage /dev/md0 --remove /dev/sde1 mdadm: hot remove failed for /dev/sde1: No such device or address backup:~# ls -la /dev/sde* brw-r--r-- 1 root disk 8, 54 16. Mär 08:37 /dev/sde brw-r--r-- 1 root disk 8, 55 16. Mär 08:37 /dev/sde1
- Wie kann ich hier ohne reboot aufräumen?
partprobe bzw. hdparm -z /dev/sde
(Wobei beide Verfahren funktionieren, aber nicht so richtig. Um wechselneden Laufwerksbuchstaben zu entgehen, mounte ich immer über die UUID einer Festplattenpartition. (siehe "ls -l /dev/disk/by-uuid/"). Diese Liste der UUIDs wird aber nicht mit aktualisiert.)
Jens Weiße
Hi Jens,
- Wie kann ich hier ohne reboot aufräumen?
partprobe bzw. hdparm -z /dev/sde
Danke, das probiere ich demnächst. Momentan habe ich allerdings:
backup:~# cat /proc/partitions major minor #blocks name
8 0 488386584 sda 8 1 1951866 sda1 8 2 486432135 sda2 8 16 976762584 sdb 8 17 976760001 sdb1 8 32 976762584 sdc 8 33 976760001 sdc1 9 0 976759936 md0 9 1 976759936 md1 8 48 976762584 sdd 8 49 976760001 sdd1 253 0 976759680 dm-0 8 80 976762584 sdf 8 81 976760001 sdf1 253 1 976759680 dm-1
backup:~# cat /proc/mdstat Personalities : [raid1] md1 : active raid1 sdf1[1] sdc1[0] 976759936 blocks [2/2] [UU]
md0 : active raid1 sde1[2](F) sdb1[0] 976759936 blocks [2/1] [U_]
- Wie bekomme ich nun aber ohne reboot das "sde1" aus dem "md0" raus?
Mit freundlichen Grüßen / With kind regards Ronny Seffner
Ronny Seffner wrote:
backup:~# cat /proc/mdstat Personalities : [raid1] md1 : active raid1 sdf1[1] sdc1[0] 976759936 blocks [2/2] [UU]
md0 : active raid1 sde1[2](F) sdb1[0] 976759936 blocks [2/1] [U_]
- Wie bekomme ich nun aber ohne reboot das "sde1" aus dem "md0" raus?
Funktioniert mdadm --remove /dev/md0 /dev/sde1 bei dir nicht?
Ciao, Thomas
Funktioniert mdadm --remove /dev/md0 /dev/sde1 bei dir nicht?
Nee, nicht, wenn das Raid dabei weiterlaufen muss:
backup:~# mdadm --remove /dev/md1 /dev/sdf1 mdadm: hot remove failed for /dev/sdf1: Device or resource busy
Darum mache ich vorher das "--fail" welches beim Wiederanstecken dann aber zum vollen rebuild führt. Und wenn das device zwischedurch abgepfiffen ist, geht weder das "--fail" noch das "--rebulid", weil er meldet, dass das device zum Entfernen nicht verfügbar wäre.
Mit freundlichen Grüßen / With kind regards Ronny Seffner
Hallo noch mal,
md0 : active raid1 sde1[2](F) sdb1[0] 976759936 blocks [2/1] [U_]
- Wie bekomme ich nun aber ohne reboot das "sde1" aus dem "md0" raus?
Oh man, der Wald und die Bäume ... Ich habe es zufällig mit "sde1" statt "/dev/sde1" in der "mdadm --remove" probiert und schwups, weg ;-)
Mit freundlichen Grüßen / With kind regards Ronny Seffner
Hallo Ronny,
Ronny Seffner wrote: [...]
Die Verfügbarkeit der Schalter -add und --re-add suggeriert mir, dass auch nur ein sync der geänderten Blöcke möglich wäre, würde ich die Platte nicht mit --fail rausnehmen.
- Liege ich mit der Vermutung richtig?
Ja, dann brauchst du aber ein Intentlog - auch Bitmapfile genannt. Das kannst du bei "--create" mit "-b /wo/auch/immer/bitmap/file" anlegen. Du kannst es mit der grow-Aktion auch nachträglich anlegen, aber das habe ich noch nie gemacht :)
- Für wie viel "Änderung" reicht denn der Metadatenblock, ein paar Dutzend
gb ändern sich ein einer Woche schon?
Du kannst die bitmap auf eine - nicht im Raid befindliche - ext3-Partition legen. Da sollte es theoretisch möglich sein, bis zur Gesamtgröße der Partition zu gehen - aber das macht wenig Sinn ;)
- Wie entferne ich eine Platte ohne --fail?
Das sollte mit dem --re-add auch gehen, wenn die Platte vorher mit --fail rausgenommen wurde. Voraussetzung ist eben das Bitmapfile.
Ciao, Thomas
Hallo Thomas,
Ja, dann brauchst du aber ein Intentlog - auch Bitmapfile
Also so wie hier schon vorgeschlagen ein Raid 1 aus allen drei Platten mit einem bitmapfile. - Dieses merkt sich dann den Zustand für alle 2 Platten, die im Wechsel (und nie zusammen) mal dran sind, getrennt? - In der Konstellation ist im Verbund immer ein device mit "[F]" markiert, was zu Statusmeldungen per Mail führt, die ich nicht pauschal deaktivieren möchte; wie löst man das?
Mit freundlichen Grüßen / With kind regards Ronny Seffner
Hallo Ronny,
Ronny Seffner wrote:
Hallo Thomas,
Ja, dann brauchst du aber ein Intentlog - auch Bitmapfile
Also so wie hier schon vorgeschlagen ein Raid 1 aus allen drei Platten mit einem bitmapfile.
Sowas habe ich noch nie ausprobiert. Immer nur ein Raid1 aus 2 Platten mit einem Bitmapfile.
- Dieses merkt sich dann den Zustand für alle 2 Platten, die im Wechsel (und
nie zusammen) mal dran sind, getrennt?
Ich habe noch nie probiert, wie das geht. Theoretisch sollte das möglich sein. Versuch macht schlau :-)
- In der Konstellation ist im Verbund immer ein device mit "[F]" markiert,
was zu Statusmeldungen per Mail führt, die ich nicht pauschal deaktivieren möchte; wie löst man das?
Dazu habe ich keine wirkliche Idee, weil für den Anwendungsfall wurde das eher nicht konzipiert.
Wobei mein Ansatz auch ein anderer wäre: Mit fest verbauten Platten ein Raid bauen (das dann auch schön meckern darf wenn eins kaputt ist) und eine oder zwei externe Platten dran mit eigenen Filesystem und die Daten werden dann mit rsync auf die externe Platte gespiegelt. Mit rsnapshot wird schon fast eine kleine Backuplösung draus.
Ciao, Thomas
Moin Ronny,
nur mal so als Idee ... Eventuell wäre bei dir DRBD [http://www.drbd.org/] besser geeignet. Gedacht ist DRBD zum Replizieren von Festplatten über ein Netzwerk. Also ein RAID 1 über Netzwerkkabel. Intern arbeiten die mit einem Bitmap-File und synchronisieren nach einem Netzwerkfehler nur die Differenzen. Das Netzwerkkabel lässt sich weglassen.
Jens
Hallo Jens,
drbd kenne ich seit Jahren gut - im HA Umfeld. Das ich Deine Idee nicht selbst abstrahiert habe? Klingt auf jeden Fall gut.
Mit freundlichen Grüßen / With kind regards Ronny Seffner
lug-dd@mailman.schlittermann.de
-
Jens Weiße -
morphium -
Ronny Seffner -
Thomas Köhler