[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: webserver mit software raid1



hi again,


> 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.

ack, wichtig und entscheiden ist, ob die der rechner bei einem ausfall
der ersten platte von der zweiten booten kann. ich habe bereits verschiedene
tests gemacht (ausstecken der ersten platte, booten manuell von cd) jedoch
hat diese nicht gebootet. die meldung am screen sah in etwa so aus

000000000000000000000000000000000 ....

was mir sagt, das kein mbr eintrag auf der zweiten vorhanden ist.

> 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
>
ich habs fast genauso ;) nur habe ich in /mnt/etc/lilo.conf
/dev/md0 eingetragen. jetzt ist mir klar, dass ich hier den
'richtigen' devicenamen angeben muss, also /dev/sdb
vielen dank für den tipp.


> 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.
das heißt im klartext: nachdem ich erfolgreich von meiner zweiten platte
gebootet habe, kann ich die die erste platte welche zum aktuellen stand noch
als 'failed-disk' markiert ist, in den raid verbund einhängen, danach
passe ich die /etc/fstab und analog dazu die /mnt/etc/fstab als auch
/etc/lilo.conf als auch die /mnt/etc/lilo.conf an. anschliessend wird der
mbr auf beide platten mittels lilo -x geschrieben, danach lilo -r /mnt/
alles klar :)

>
> 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.
erzwinge ich durch einfaches detachen der ersten platte.

>
> 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.
ack :)


> 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.
genau :)


> 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.

http://www.tldp.org/HOWTO/Software-RAID-HOWTO-7.html#ss7.4
ich nehms mir zu herzen :) ich danke dir fuer deine kompetenten beiträge.
ich denke ich sollte das morgen hinbekommen. schoenen sonntag noch,

gruesse,
werner



Reply to: