Re: webserver mit software raid1
Gruesse!
* Werner Detter <wd@ilum.org> schrieb am [09.01.05 16:32]:
> > Markierung des Quell-Devices als failed-disk *nur* vor dem
> > Synchronisieren, danach muss diese Partition auch als raid-disk
> > definiert sein.
>
> klar, nur dann ist alles unwiderruflich (wenn etwas schief gegangen ist)
> auf der ersten platte verloren, daher meine idee
> das system auf der zweiten platte auch bootbar zu machen um das setup
> auf der zweiten platte zu testen (lilo in den mbr
> der zweiten platte schreiben und dann versuchen das system auf der zweiten
> platte zu booten).
Aber das würde doch nur Sinn machen, wenn du dir (hardware-seitig)
irgendwie nicht sicher sein könntest, das die zweite Platte booten
kann. Entscheidend und wichtiger ist doch der Test, ob das Raid die
zweite, gespiegelte Platte nach einem Ausfall der ersten genauso
bootet.
Wenn du wirklich die zweite Platte nach dem händischen Kopieren booten
willst, müßtest du IMHO:
$2.HD/ -> /mnt/newroot
$2.HD/boot -> /mnt/newroot/boot
mounten. Dann mußt du die /mnt/newroot/fstab anpassen auf sdb. Genauso
die /mnt/newroot/lilo.conf: boot=/dev/sdb, root=/dev/sdbXXX
Daher dürfte auch dein lilo Problem aus der ersten Mail kommen. Der
boot Eintrag muß immer auf ein pysikalisches Device (bei dir sda
und/oder sdb) lauten. Der root Eintrag beim asynchonen Test auf
/dev/sdbXXX, beim Raid-Test auf /dev/mdXXX. Später, bei aktivem Raid
über beide Platten bietet dir lilo mit dem Parameter -x die Möglichkeit
MBRs auf alle beteiligten Platten zu legen.
Dann lilo -r /mnt/newroot
Beim Booten mußt du dann BIOS bzw. Controller-seitig sicherstellen, daß
von der zweiten statt von der ersten Platte gebootet wird.
Diese Änderungen mußt du auch nachher wieder rückgängig machen, weil im
Raid definitiv auch die lilo.conf bzw. die ftab identisch sein müssen.
Aber wie gesagt, hierbei ist RAID vollkommen aus dem Spiel. Und es wäre
IMHO wichtiger zu testen, ob das Raid nach einem Ausfall wirklich
"umschaltet".
> > Da hast du (Software-)Raid nicht ganz verstanden. Dieses "Kopieren"
> > macht das Raid, wenn es denn aktiv ist,
> das ist genau der punkt, bei mir ist es _noch_ nicht aktiv. das initiale
> setup von raid beinhaltet das kopieren der daten auf die zweite platte.
> ich möchte die funktionalität vor dem liveschalten des raid1 testen, d.h.
> sicherstellen, dass das system auch von der zweiten platte bootet.
Wenn die Platte nicht defekt ist wird sie, entsprechend gespiegelt, das
tun. So wie du das vorhast zu testen wäre zwei asynchrone Systeme
einzel zu testen (unterscheidliche fstab, lilo wegen sd[a|b]. Du willst
aber eigentlich: Ausfall 1.Platte+kein MBR -> MBR auf zweiter Platte
springt ein -> Raid merkt 1.Platte defekt -> 2.Platte wird wie erste
behandelt.
Wie gesagt, im Howto Abschnitt 7.4.2 wird dein Fall eigentlich genau
beschrieben. Und solange deine erste Platte als failed eingetragen ist
wird die vom Raid auch nicht angefaßt.
> > dein Raid ist nicht aktiv. Von 2 "DISKS [2/1] ist nur eine als gut
> > markiert, die andere als ausgefallen [U_]. Du hast also kein Raid-1.
> i know, das ist so gewollt. solange ich nicht weiss ob das system von der
> zweiten platte bootet, kann ich das raid nicht scharf schalten.
Diesen Test beschreibt Abschnitt 7.4.2 ja gerade. Die
Quell-Partition(en) bleiben, als failed markiert, unangetastet. Aber es
wird als Raid-Verbund (eben mit einer defekten Platte) gebootet.
Dazu könnte ich bei Bedarf auch noch ausführlicher werden.
>
> weitere ideen
>
> vielen dank und schoene gruesse,
> werner
Gruß
Gerhard
Reply to: