Endlich geloest: RAID5 fuer /video incl. OS-Upgrade

Zitat

Original von berndl
Aber wie ich das automatisch hinbekomme ist mir schleierhaft. Ich finde auch im Netz keine Beschreibung, wie ein existierendes RAID bei einer neuen Installation einzubinden ist...

Leider hast du immer noch nicht auf die Nachfrage reagiert:

Zitat

Original von PeterD
Was passiert den, wenn du einfach versuchts dein raid mit einen "mount" einfach zu starten ?
Irgendwelche fehlermeldungen oder infos in den logfiles dabei ?
Poste doch mal deine fstab wie du das da drin hats und wie du's gemountets hast.

Also vergiss mal mdadm.
Mounte einfach mal dein raid indem du in /etc/fstab du eine gültige zeile für /dev/md0 drin hast.
Dann mounten und falls es probleme gibt die meldungen hier posten.

Nochmal:
Bei mir brauche ich nur ein mount auf /raid0 zu machen.
Zeile /etc/fstab:

/dev/md0  /raid0  xfs defaults  0  0

Also "mount /raid0" und das RAID ist da.
Macht natürlich sysinit bei mir automatisch sobald alle partitionen in der /etc/fstab gemountet werden.

/var/log/syslog:

Aug 10 10:15:38 vdr kernel: device-mapper: 4.1.1-ioctl (2004-04-07) initialised: dm-devel@redhat.com
Aug 10 10:15:38 vdr kernel: md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27
Aug 10 10:15:38 vdr kernel:  [events: 0000162b]
Aug 10 10:15:38 vdr kernel: md: bind<sdb6,1>
Aug 10 10:15:38 vdr kernel:  [events: 0000162b]
Aug 10 10:15:38 vdr kernel: md: bind<sda6,2>
Aug 10 10:15:38 vdr kernel:  [events: 0000162b]
Aug 10 10:15:38 vdr kernel: md: bind<sdc6,3>
Aug 10 10:15:38 vdr kernel:  [events: 0000162b]
Aug 10 10:15:38 vdr kernel: md: bind<sdd6,4>
Aug 10 10:15:38 vdr kernel:  [events: 0000162b]
Aug 10 10:15:38 vdr kernel: md: bind<hdd5,5>
Aug 10 10:15:38 vdr kernel:  [events: 0000162b]
Aug 10 10:15:38 vdr kernel: md: bind<hda8,6>
Aug 10 10:15:38 vdr kernel: md: hda8's event counter: 0000162b
Aug 10 10:15:38 vdr kernel: md: hdd5's event counter: 0000162b
Aug 10 10:15:38 vdr kernel: md: sdd6's event counter: 0000162b
Aug 10 10:15:38 vdr kernel: md: sdc6's event counter: 0000162b
Aug 10 10:15:38 vdr kernel: md: sda6's event counter: 0000162b
Aug 10 10:15:38 vdr kernel: md: sdb6's event counter: 0000162b
Aug 10 10:15:38 vdr kernel: raid5: measuring checksumming speed
Aug 10 10:15:38 vdr kernel:    8regs     :  1195.600 MB/sec
Aug 10 10:15:38 vdr kernel:    32regs    :   645.200 MB/sec
Aug 10 10:15:38 vdr kernel:    pIII_sse  :  2140.800 MB/sec
Aug 10 10:15:38 vdr kernel:    pII_mmx   :  1371.200 MB/sec
Aug 10 10:15:38 vdr kernel:    p5_mmx    :  1271.600 MB/sec
Aug 10 10:15:38 vdr kernel: raid5: using function: pIII_sse (2140.800 MB/sec)
Aug 10 10:15:38 vdr kernel: md: raid5 personality registered as nr 4
Aug 10 10:15:38 vdr kernel: md0: max total readahead window set to 1024k
Aug 10 10:15:38 vdr kernel: md0: 4 data-disks, max readahead per data-disk: 256k
Aug 10 10:15:38 vdr kernel: raid5: device hda8 operational as raid disk 0
Aug 10 10:15:38 vdr kernel: raid5: spare disk hdd5
Aug 10 10:15:38 vdr kernel: raid5: device sdd6 operational as raid disk 4
Aug 10 10:15:38 vdr kernel: raid5: device sdc6 operational as raid disk 3
Aug 10 10:15:38 vdr kernel: raid5: device sda6 operational as raid disk 2
Aug 10 10:15:38 vdr kernel: raid5: device sdb6 operational as raid disk 1
Aug 10 10:15:38 vdr kernel: raid5: allocated 5381kB for md0
Aug 10 10:15:38 vdr kernel: raid5: raid level 5 set md0 active with 5 out of 5 devices, algorithm 2
Aug 10 10:15:38 vdr kernel: RAID5 conf printout:
Aug 10 10:15:38 vdr kernel:  --- rd:5 wd:5 fd:0
Aug 10 10:15:38 vdr kernel:  disk 0, s:0, o:1, n:0 rd:0 us:1 dev:hda8
Aug 10 10:15:38 vdr kernel:  disk 1, s:0, o:1, n:1 rd:1 us:1 dev:sdb6
Aug 10 10:15:38 vdr kernel:  disk 2, s:0, o:1, n:2 rd:2 us:1 dev:sda6
Aug 10 10:15:38 vdr kernel:  disk 3, s:0, o:1, n:3 rd:3 us:1 dev:sdc6
Aug 10 10:15:38 vdr kernel:  disk 4, s:0, o:1, n:4 rd:4 us:1 dev:sdd6
Aug 10 10:15:38 vdr kernel: RAID5 conf printout:
Aug 10 10:15:38 vdr kernel:  --- rd:5 wd:5 fd:0
Aug 10 10:15:38 vdr kernel:  disk 0, s:0, o:1, n:0 rd:0 us:1 dev:hda8
Aug 10 10:15:38 vdr kernel:  disk 1, s:0, o:1, n:1 rd:1 us:1 dev:sdb6
Aug 10 10:15:38 vdr kernel:  disk 2, s:0, o:1, n:2 rd:2 us:1 dev:sda6
Aug 10 10:15:38 vdr kernel:  disk 3, s:0, o:1, n:3 rd:3 us:1 dev:sdc6
Aug 10 10:15:38 vdr kernel:  disk 4, s:0, o:1, n:4 rd:4 us:1 dev:sdd6
Aug 10 10:15:38 vdr kernel: md: updating md0 RAID superblock on device
Aug 10 10:15:38 vdr kernel: md: hda8 [events: 0000162c]<6>(write) hda8's sb offset: 20482752
Aug 10 10:15:38 vdr kernel: md: hdd5 [events: 0000162c]<6>(write) hdd5's sb offset: 40021504
Aug 10 10:15:38 vdr kernel: md: sdd6 [events: 0000162c]<6>(write) sdd6's sb offset: 20482752
Aug 10 10:15:38 vdr kernel: md: sdc6 [events: 0000162c]<6>(write) sdc6's sb offset: 20482752
Aug 10 10:15:38 vdr kernel: md: sda6 [events: 0000162c]<6>(write) sda6's sb offset: 40049920
Aug 10 10:15:38 vdr kernel: md: sdb6 [events: 0000162c]<6>(write) sdb6's sb offset: 40049920
Aug 10 10:15:38 vdr kernel: EXT2-fs warning (device ide0(3,3)): ext2_read_super: mounting ext3 files
Aug 10 10:15:38 vdr kernel:
Aug 10 10:15:38 vdr kernel: EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
Aug 10 10:15:38 vdr kernel: SGI XFS with no debug enabled
Aug 10 10:15:38 vdr kernel: XFS mounting filesystem md(9,0)
Aug 10 10:15:38 vdr kernel: Ending clean XFS mount for filesystem: md(9,0)

Hier siehst du das einzig das automatische mounten von /raid0 offensichtlich das modul "md" nachläd und das RAID selbstständig zusammensetzt.
Mdadm hat da NIX mit zu tun.

Also bitte, mdadm und das modul 'md' erst mal vergessen und einfach mal dein RAID mit "mount" und über einen eintrag in der '/etc/fstab' versuchen zu mounten.

gruss Peter

EDIT
Ich weiss das klingt zu einfach als das du es bereits probiert hast
Vielleicht hast du deshalb ja nix gefunden, weil es "offensichtlich trivial" ist.

Zitat

Original von berndl
so, noch eine klitzekleine Frage: Wenn ich jetzt mal ein neues OS aufspiele, wie kriege ich dann mein RAID5 wieder?

Kann ich da mit 'mdadm --assemble /dev/md0 /dev/hdx....' was machen? Woher kennt das System denn dann /dev/md0? Oder wie geht das???

Hat da noch jemand 'nen Tipp fuer mich?

Gruss,
- berndl

Alles anzeigen

Kleine Frage, längliche Antwort:

Wenn Du die Partitionen, die für RAID verwendet werden, auf den Typ 0xFD (RAID autodetect) stellst, dann geht das normalerweise automagisch. Dazu muß der Kernel aber mit Autodetection compiliert sein. Die Minor ID des RAID Devices steht üblicherweise in den Metadaten, d. h. wenn Deine Distri das auswertet (bei meinen Versuchen mit Knoppix als Notfallsystem war das m. W. nicht der Fall) und es keine Konflikte gibt (z. B. mehrere Verbünde mit der gleichen Minor ID) dann tauchen die RAID-Geräte unter ihren ursprünglichen Kennungen auf.

Bei Debian geht das alles etwas anders, da bringt das mdadm-Paket einige Skripte mit, die sehr früh (RAM-Disk) die RAIDs starten. Ob selektiv oder alle konfigurierst Du im mdadm-Paket selbst (dpkg-reconfigure mdadm), dabei wird - wenn ich mich richtig erinnere - auch die /etc/mdadm.conf automatisch aktualisiert. Die RAM-Disks müssen dann ebenfalls aktualisiert werden.

Aus eigener Erfahrung mit meinem 8TB Video-RAID kann ich momentan nur davon abraten, über ein RAID5 LVM zu legen. Das hat reichlich Performance gekostet. Ich habe außerdem noch mit EVMS experimentiert, da er die Verwaltung prinzipiell um Einiges komfortabler gestaltet, aber das hat nochmal kräftig Performance gekostet (außerdem wird EVMS nicht mehr gepflegt).

Bei meinem Home-Server liegt das System auf einem RAID1 aus zwei Notebookplatten, diese laufen dauernd (da wandern auch Web-, Mail-, Musik-Server etc. drauf). Über diesem RAID1 liegt LVM2, das geht mit der Performance in Ordnung.

Die RAID5-Verbünde (bei 10 1TB-Platten sind das effektiv rd. 8,3TB Platz, da die 1TB ja mit 10^3 statt 2^10 schöngerechnet sind - daher ein 8TB-Verbund, weil ext3 unter Debian Etch nicht mehr kann, und ein kleiner Rest) nutze ich allerdings direkt.

Bei 128K Chunk-Size liegt der Durchsatz im RAID5 Verbund bei ca. 150MB/s. Das ist letztlich eine bewußt in Kauf genommene Hardware-Limitierung, da der Controller ein Single Lane PCIe Controller mit zwei nachgeschalteten Port Multipliern ist. Das war letztlich eine Frage der Vernunft. Der Server sollte beim "Herumidlen" möglichst wenig Energie brauchen - andere Lösungen mit Hardware RAID-Controller oder breiter angebundenem PCIe Controller wären letztlich deutlich teurer geworden und bräuchten auch mehr Energie. Und bei einem Hardware-RAID-Controller machst Du Dich letztlich auch vom Hersteller abhängig, d. h. Du solltest einen zweiten Controller in Reserve haben, falls der erste mal stirbt.

Mit ext3 im writeback-Modus (also kein wirklich transaktionales Journaling) liegt der Durchsatz immer noch in diesem Bereich. Packe ich jetzt aber LVM2 drüber, dann sinkt der Durchsatz signifikant (noch ca. 90MB/s). Ich kann mir das nur so vorstellen, daß mit dem LVM2 obendrüber die Ausrichtung der Schreib-Lese-Operationen im ext3 (trotz korrektem stride-Setup) nicht mehr paßt. Und EVMS reißt das Ganze dann auf ca. 50MB/s herunter.

Übrigens stoppe ich die Video-Plattenverbünde, wenn keine Zugriffe erfolgen, mit einem kleinen Perl-Skript, das ich mal in einem Forum gefunden habe (sowohl die 1TB Platten von WD als auch die von Seagate haben leider Firmware-Fehler, die dazu führen, daß die Platten nicht immer stoppen, die WD-Platten kann man sogar durch ein einziges falsches Kommando nachhaltig unbrauchbar machen). Mit einem 35W Athlon64 X2 3800+ schaffe ich es so, im Idle-Zustand auf ca. 35-40W zu kommen.

Viele Grüße,
Torsten

torsten

Zitat

Originally posted by torsten lang

Übrigens stoppe ich die Video-Plattenverbünde, wenn keine Zugriffe erfolgen, mit einem kleinen Perl-Skript, das ich mal in einem Forum gefunden habe

Könntest Du das Skript mal veröffentlichen?

Gruß,
Farseer

Zitat

Original von Farseer
torsten

Könntest Du das Skript mal veröffentlichen?

Gruß,
Farseer

Alles anzeigen

Aber gerne doch. Ich habe mal alles reingepackt, drives_idle_daemon.sh ist das interessante Skript (wie gesagt, nicht von mir). Bei den übrigen (*set_idle_time*.sh), show_drive_state.sh, start_drives.sh und stop_drives.sh handelt es sich um Spezialfälle für meine Konfiguration, die über die laufwerkseigenen Timer etc. arbeiten. Wie gesagt, bei meinen WD-Platten ging das gar nicht (und ein versehentliches "hdparm -s" statt "hdparm -S" macht die Platte dauerhaft unbrauchbar, da sich das Feature nicht mehr abschalten läßt) und bei den Seagate Platten willkürlich an verschiedenen Backplane-Positionen nicht.

Für die Konfiguration mit den 2*5 Platten an Port-Multipliern braucht's speziell in aktuellen Kernels (2.6.26 und kurz davor) weitere Patches, da die Wartezeiten im Kernel zu knapp konfiguriert sind. Kann ich auch noch posten, wenn's von Interesse ist.

Viele Grüße,
Torsten

Zitat

Original von torsten lang

Kleine Frage, längliche Antwort:

Wenn Du die Partitionen, die für RAID verwendet werden, auf den Typ 0xFD (RAID autodetect) stellst, dann geht das normalerweise automagisch. Dazu muß der Kernel aber mit Autodetection compiliert sein. Die Minor ID des RAID Devices steht üblicherweise in den Metadaten, d. h. wenn Deine Distri das auswertet (bei meinen Versuchen mit Knoppix als Notfallsystem war das m. W. nicht der Fall) und es keine Konflikte gibt (z. B. mehrere Verbünde mit der gleichen Minor ID) dann tauchen die RAID-Geräte unter ihren ursprünglichen Kennungen auf.

Bei Debian geht das alles etwas anders, da bringt das mdadm-Paket einige Skripte mit, die sehr früh (RAM-Disk) die RAIDs starten. Ob selektiv oder alle konfigurierst Du im mdadm-Paket selbst (dpkg-reconfigure mdadm), dabei wird - wenn ich mich richtig erinnere - auch die /etc/mdadm.conf automatisch aktualisiert. Die RAM-Disks müssen dann ebenfalls aktualisiert werden.

Alles anzeigen

Verwirr 'berndl' nicht noch mehr.

Der partition type 0xFD scheint nur nötig zu sein wenn du das OS direkt auf ein RAID installierst (also /boot oder / auf dem RAID). Wenn das RAID nur user daten enthält scheint das egal zu sein (schaded aber sicher nicht wenn die partitionen 0xFD sind).
Mein RAID wird z.b. auch von Knoppix (live-CD) automatisch erkannt, trotz type 0x83.

Ich hab Debian (ctvdr/Knoppix), da sind keine RAID scripte in der initrd.
Es scheint nur nötig zu sein das md modul (oder in den kernel compiliert) zu starten. Das macht 'mount' schon selber wenn ein mdX device angesprochen wird.

Auch scheint /etc/mdadm.conf nicht (mehr) nötig zu sein. Die RAID daten stecken anscheinend schon in der partionstabelle.
Eventuell ist es nötig tatsächlich einmal mit 'mdadm --assemble dev1 dev1 ...' das RAID auf dem neuen system zu starten um die superblöcke auf das neue system anzupassen.

Ubuntu ist aber letztlich Debian, da sollten keine grösseren lgischen unterschiede auftauchen.

gruss Peter

Uups - doppelter Post...

Zitat

Original von PeterD
...

Verwirr 'berndl' nicht noch mehr.

Der partition type 0xFD scheint nur nötig zu sein wenn du das OS direkt auf ein RAID installierst (also /boot oder / auf dem RAID). Wenn das RAID nur user daten enthält scheint das egal zu sein (schaded aber sicher nicht wenn die partitionen 0xFD sind).
Mein RAID wird z.b. auch von Knoppix (live-CD) automatisch erkannt, trotz type 0x83.

Ich hab Debian (ctvdr/Knoppix), da sind keine RAID scripte in der initrd.
Es scheint nur nötig zu sein das md modul (oder in den kernel compiliert) zu starten. Das macht 'mount' schon selber wenn ein mdX device angesprochen wird.

Auch scheint /etc/mdadm.conf nicht (mehr) nötig zu sein. Die RAID daten stecken anscheinend schon in der partionstabelle.
Eventuell ist es nötig tatsächlich einmal mit 'mdadm --assemble dev1 dev1 ...' das RAID auf dem neuen system zu starten um die superblöcke auf das neue system anzupassen.

Ubuntu ist aber letztlich Debian, da sollten keine grösseren lgischen unterschiede auftauchen.

gruss Peter

Alles anzeigen

Moin Peter,
jetzt bin ich doch mal neugierig geworden und habe ein wenig in den Etch-initrd-Dateien gestöbert. Also bei mir sind definitiv Skripte und Konfigurationsdaten drin, die RAID und LVM2 betreffen. Wie gesagt, bei Debian Etch wird auch immer noch eine mdadm.conf erzeugt, wenn man mdadm konfiguriert. Bei mir liegt das System selbst allerdings auch auf einem RAID1-Verbund und ich trage diesen aus Sicherheitsgründen auch ein.

Mag sein, daß sich das bei neueren Debian-Distris mittlerweile geändert hat, aber so lange es bei Lenny noch heißt, daß bei mehreren Controllern die sd-Devices u. U. "auf Wanderschaft gehen" riskiere ich da kein Dist-Upgrade.

Daß das Vorgehen bei Debian grundsätzlich nicht mehr notwendig ist, ist klar (zumindest, wenn der Kernel passend konfiguriert ist). Die mdadm.conf ist eigentlich überflüssig, da alle relevanten Metadaten (RAID-UUID, Status des Devices, Minor-ID etc. pp.) im Block-Device selbst stecken (nicht in der Partition Table), beim alten Format am Anfang, bei neueren Superblocks ab 1.0 am Ende, wobei ich Letzteres nicht empfehlen kann, da es dort einen üblen Bug gibt, der nach dem Versagen eines Block-Devices und dem Entfernen das erneute Hinzufügen verhindert, weil angeblich das Gerät zu klein sei. Ich habe damit beim Experimentieren schon einigen Ärger gehabt und verwende jetzt wieder das Default Format 0.90 (im Moment ist das noch OK, da es keine Platten >2TB gibt).

Viele Grüße,
Torsten

Zitat

Original von torsten lang
jetzt bin ich doch mal neugierig geworden und habe ein wenig in den Etch-initrd-Dateien gestöbert. Also bei mir sind definitiv Skripte und Konfigurationsdaten drin, die RAID und LVM2 betreffen. Wie gesagt, bei Debian Etch wird auch immer noch eine mdadm.conf erzeugt, wenn man mdadm konfiguriert. Bei mir liegt das System selbst allerdings auch auf einem RAID1-Verbund und ich trage diesen aus Sicherheitsgründen auch ein.

Also hier gibsts nur in init.d einige scripte, hautsächlich mdadm als daemon.
Und das ist hier ein steinaltes Sarge.

Zitat

Original von torsten lang
Mag sein, daß sich das bei neueren Debian-Distris mittlerweile geändert hat, aber so lange es bei Lenny noch heißt, daß bei mehreren Controllern die sd-Devices u. U. "auf Wanderschaft gehen" riskiere ich da kein Dist-Upgrade.

Also bei einem controller scheint das wohl kein problem.
Als letztens eine S-ATA platte ihren geist aushauchte sind die sd devices auch vom controller umnummeriert worden.
Das RAID hat's nicht gestört aber VDR kamen die video partitionen durcheinander

Kann aber sein das mehrere controller dann ein problem sind.

Von dist-upgrade halte ich auch nix.
Eventuell installation auf zweite partition kopieren und anschliessend mit dieser kopie experimentieren.
Aber ein dist-upgrade auf der produktiv-installation ist wohl gemeinhin das equivalent zum bungeejump OHNE seil

Peter

Zitat

Original von berndl
So, backup fertig. Heute mach' ich nix mehr, ich hab' jetzt erstmal Hunger! :o)

Zitat

Original von berndl
[EDIT] Achso, wenn ich danach modprobe md, gefolgt von mdadm --assemble .... und mount ... mache, dann ist das RAID da [/EDIT]

[EDITEDIT]Ich habe mdadm mal deinstalliert und dann neu per Synaptic installiert, gleiches Ergebnis...[/EDITEDIT]
'now I'm with my latin at the end...'
[3EDIT]Wenn ich 'md' in die /etc/modules einfuege, boote, dann reicht nach dem booten ein mdadm --assemble gefolgt von mount ... und das RAID ist da. Die '/etc/mdadm/mdadm.conf' existiert, aber mdadm wird wohl nicht gestartet...[/3EDIT]

Reicht vielleicht ein laden des moduls "md" gefolgt vom mounten ?

modeprobe md
mount /video/srv_md0

Dann fehlt Ubuntu vielleicht nur etwas um das md modul automatisch laden zu können (/etc/modules.conf ?).
Sonst bin ich mit dem latein bei Ubuntu hier auch am ende.
http://wiki.ubuntuusers.de/Software-RAID?highlight=raid
Da steht eigentlich auch nix weiter als /etc/fstab anzupassen.

Vielleicht rechteprobleme, da du ja nicht als root unter Ubuntu arbeiten kannst? Sudo ist eben oft nicht 'root'.

Peter

Das kommt mir aber trotzdem spanisch vor.
Ziemlich viel aufwand dafür.

Nachteil der mdadm --assemble methode sind die festen devices.
Als bei mir eine platte defekt war wurden aus sdc und sdd plötzlich sdb und sdc. Assemble kommt damit nicht klar, da müsstest du manuell ändern
Wie gesagt bei mit reicht ein simpler mount und alles wird nachgeladen.

Ich kann mir eigentlich nicht vorstellen dass das so komplizeirt sein muss.
Könnte sein das Ubuntu als desktopsystem RAID vernachlässigt.

gruss Peter

Zitat

Original von berndl
Vielleicht interessierts ja jemand anderen auch...

Und wie - das wollte ich schon lange mal machen, weil die Video-Partition volläuft und ich gerade nicht zum Aufräumen komme. Jetzt soll die Spare-Platte dauerhaft mitarbeiten.

Zitat

Original von berndl

Code

mdadm --add /dev/md1 /dev/loop2  # jetzt das 'alte' loop2 wieder als spare hinzu fuegen
mdadm --grow /dev/md1 --raid-devices=4  # spare wird aktiv ins RAID eingebunden
umount /mnt/testraid  # uebliches unmounten, fs-check und resize
e2fsck -f /dev/md1
resize2fs /dev/md1

Es handelt sich ja nur um /video, no risk, no fun - ich habe auf das Backup verzichtet (hatte gerade keine 500GB rumliegen) und bin deiner Anleitung gefolgt.
Nach rund 6 1/2 Stunden war die Spare-Platte im Raid, noch eine halbe Stunde später war es auf netto 3x250 GB (von 2x) erfolgreich gewachsen.
Dann Panik beim nächsten Boot: md0 nicht mountbar. Ich hatte vergessen, in der mdadm.conf bekannt zu machen, dass jetzt alle 4 Devices zum RAID gehören und die Spare nicht mehr da ist. Nach der Korrektur läuft es wie geschmiert.
Jetzt muss ich nur noch Exim aufsetzen, damit mir der mdadm eine Mail schickt, wenn eine der Platten aussteigt...

Besten Dank für die Zusammenstellung.

Grüße,
Carsten