Re: Linux, network root filesystems

[Markus Hochholdinger <Markus@xxxxxxxxxxxxxxxxx>]

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
> > gefaellt ist dass man Heartbeat benoetigt. Mir scheint das sehr kompliziert
> > zu sein. Mir gefallen ausgereifte und einfache (transparente) Loesungen am
> > meisten.
> Ja habe ich. Ich fand es nicht besonderst kompliziert, hearbeat ist
> relativ einfach einzurichten (und generell ein gutes tools fuer alle HA
> Sachen) und sehr stabil. DRDB war auch nicht sonderlich kompliziert und
> laeuft hier z.B fuer einen Mailservercluster sehr stabil.

das ist schoen zu hoeren. Ich werde mir das mal genauer anschauen. Bin ich also 
doch nicht der einzige hier der versucht solche Probleme zu loesen.


> Oder in einer Loesung wo Du keine Storage-Server hast sondern halt nur
> einen "Fileserver-Cluster" mit DRDB kannst du per heartbeat das alles
> ueberwachen 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 abstuerzen/haengen. Laesst
> sich evtl. durch NFS auf eine virtuelle IP loesen, die dann vom secondary
> uebernommen wird, wobei ich den Uebergang hier sehr unsauber finde, da
> aber auf dem absoluten "root" system wohl keine Daten geschrieben werden
> sollten evtl. moeglich. Alternativ wuerde ich lieber von NFS booten und
> das root System (kann ja sehr klein sein) in eine RAM-Disk kopieren,
> aehnlich wie das bei CD/Flash Distributionen gemacht wird.

Ja, nfs ist irgendwie mit dem ganzen Locking-Zeugs nicht so einfach zu 
handhaben wenn etwas ausfaellt. Aber fuer alte Systeme leider unverzichtbar.

Die Idee mit dem root-Dateisystem als RAM-Disk (z.B. initrd) ist eigentlich 
genial. Damit koennte man einige Probleme schon im Vorhinein loesen (z.B. das 
Aufsetzen von iSCSI, GFS, DRBD, usw. beim boot-Vorgang). Und da es im 
Speicher laeuft kann man auch ein virtuelles System per "live migration" 
verschieben. Nachteil ist, dass Aenderungen beim Reboot verloren gehen und 
"irgendwie" zurueck kopiert werden muessen.


> > Wo ich mir noch nicht ganz sicher bin: Was passiert wenn ein iSCSI Geraet
> > "haengt". Wie reagiert das RAID1? Bleibt das auch "haengen"? Benoetigt man
> > evtl. dafuer doch Heartbeat um zu erkennen wann ein iSCSI Geraet
> > ausgefallen ist?
> Da sollte eigentlich kein Unterschied zu dem Fall sein wo eine
> Festplatte "haengt" oder besser gesagt Fehler produziert. Heartbeat hilft
>   Dir da nicht viel, das ist ja nur ein framework. Was Du evtl. brauchst
> ist die Moeglichkeit per Software zu erkennen ob iSCSI Geraete ausgefallen
> bzw. in Ordnung sind, aber das muss ja eher der Treiber uebernehmen.

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 Ausfaelle passieren koennen 
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 wuerde ein 
System dann "stehen" bzw. kein I/O auf Platte mehr machen koennen.


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