Re: Linux, network root filesystems

Hi,

Am Mittwoch, 11. Januar 2006 10:20 schrieb Johannes Walch:
> Markus Hochholdinger wrote:
> > sehr guter Ansatz. Hast Du damit Erfahrung? Was mir daran nicht so gut
> > gefällt ist dass man Heartbeat benötigt. Mir scheint das sehr kompliziert
> > zu sein. Mir gefallen ausgereifte und einfache (transparente) Lösungen am
> > meisten.
> Ja habe ich. Ich fand es nicht besonderst kompliziert, hearbeat ist
> relativ einfach einzurichten (und generell ein gutes tools für alle HA
> Sachen) und sehr stabil. DRDB war auch nicht sonderlich kompliziert und
> läuft hier z.B für einen Mailservercluster sehr stabil.

das ist schön zu hören. Ich werde mir das mal genauer anschauen. Bin ich also 
doch nicht der einzige hier der versucht solche Probleme zu lösen.


> Oder in einer Lösung wo Du keine Storage-Server hast sondern halt nur
> einen "Fileserver-Cluster" mit DRDB kannst du per heartbeat das alles
> überwachen und bei Ausfall einfach auf dem "secondary" Server den NFS
> hochziehen (automatisch).

Ja, das drbd bietet sich an wenn man keine extra Storage Server hat. Sondern 
z.B. zwei Server die zu einem Server-RAID1 zusammengeschlossen sind.


> Bleibt das Problem, dass die virtuellen Server abstürzen/hängen. Lässt
> sich evtl. durch NFS auf eine virtuelle IP lösen, die dann vom secondary
> übernommen wird, wobei ich den Übergang hier sehr unsauber finde, da
> aber auf dem absoluten "root" system wohl keine Daten geschrieben werden
> sollten evtl. möglich. Alternativ würde ich lieber von NFS booten und
> das root System (kann ja sehr klein sein) in eine RAM-Disk kopieren,
> ähnlich wie das bei CD/Flash Distributionen gemacht wird.

Ja, nfs ist irgendwie mit dem ganzen Locking-Zeugs nicht so einfach zu 
handhaben wenn etwas ausfällt. Aber für alte Systeme leider unverzichtbar.

Die Idee mit dem root-Dateisystem als RAM-Disk (z.B. initrd) ist eigentlich 
genial. Damit könnte man einige Probleme schon im Vorhinein lösen (z.B. das 
Aufsetzen von iSCSI, GFS, DRBD, usw. beim boot-Vorgang). Und da es im 
Speicher läuft kann man auch ein virtuelles System per "live migration" 
verschieben. Nachteil ist, dass Änderungen beim Reboot verloren gehen und 
"irgendwie" zurück kopiert werden müssen.


> > Wo ich mir noch nicht ganz sicher bin: Was passiert wenn ein iSCSI Gerät
> > "hängt". Wie reagiert das RAID1? Bleibt das auch "hängen"? Benötigt man
> > evtl. dafür doch Heartbeat um zu erkennen wann ein iSCSI Gerät
> > ausgefallen ist?
> Da sollte eigentlich kein Unterschied zu dem Fall sein wo eine
> Festplatte "hängt" oder besser gesagt Fehler produziert. Heartbeat hilft
>   Dir da nicht viel, das ist ja nur ein framework. Was Du evtl. brauchst
> ist die Möglichkeit per Software zu erkennen ob iSCSI Geräte ausgefallen
> bzw. in Ordnung sind, aber das muss ja eher der Treiber übernehmen.

Ich habe mich da jetzt ein wenig rein gelesen. Bei iSCSI kann man sowohl auf 
target als auch auf initiator Seite Timeouts definieren. Allerdings muss man 
hier aufpassen dass bei zu kurzen Timeouts auch Ausfälle passieren können 
wenn ein System einfach "nur" eine hohe Load hat. Und andersherum, bei langen 
Timeouts, kann es dauern bis z.B. das Software-RAID erkennt, dass eine 
Festplatte bzw. "Internet-Platte" ausgefallen ist. Und solange würde ein 
System dann "stehen" bzw. kein I/O auf Platte mehr machen können.


-- 
Gruß
                                                          \|/
       eMHa                                              (o o)
------------------------------------------------------oOO--U--OOo--
 Markus Hochholdinger
 e-mail  mailto:Markus@Hochholdinger.net             .oooO
 www     http://www.hochholdinger.net                (   )   Oooo.
------------------------------------------------------\ (----(   )-
                                                       \_)    ) /
                                                             (_/