Diskless-Clients / Bootsequenz

04/12/2008 - 11:57 von Andreas Pflug | Report spam
Hallo,

ich betreibe hier einen Cluster mit Debian Etch amd64. Abgesehen
vom Master werden alle anderen Rechner als Diskless Clients betrieben.
Diese führen via PXE einen Netzwerkboot aus, bekommen den Debian
Standardkernel nebst initrd. Die Hardwareerkennung scheint in diesem
Fall hinreichend gut mit dem Standard-Kernel zu funktionieren.

Der Kernel fàhrt hoch, initialisiert die CPUs, den PCI-Bus, ACPI usw.
und macht dann eine weitere DHCP-Abfrage, um das Root-Verzeichnis
über NFS zu mounten.

Weitere NFS-Verzeichnisse kommen spàter in einem Init-Skript hinzu, nàmlich
/home
/opt
/usr/local
/mnt/nodefs

/, /opt, /usr/local werden Read-Only gemounted,
/home und /mnt/nodefs Read-Write. /mnt/nodefs
ist für jeden Knoten mit einem individuellen Verzeichnis
auf dem Master verbunden, hier stehen hostname sowie
Kopien der Verzeichnisse var und tmp, die für jeden Knoten
unabhàngig existieren und beschreibbar sein müssen
(da es ansonsten Probleme z. B. mit lock-Files von
mehrfach gestarteten Dàmonen gibt). /home, /opt und /usr/local
sind auf dem Master und auf allen Knoten identisch.

Beim Hochfahren der Knoten besteht nun das Problem, dass
sysklogd nicht startet sondern einfach endlos (mindestens 30 min,
danach verließ mich die Geduld...) wartet und somit den
Bootvorgang torpediert.
Wenn ich sysklogd aus /etc/rc2.d herausnehme, habe ich gesehen, dass
sysklogd anschließend manuell nachgestartet werden kann, wenn
vorher statd làuft, letzterer wird mit dem nfs-common - Skript gestartet.

Somit reduziert sich das Problem anscheinend darauf, dass nfs-common
wàhrend des Bootvorgangs nicht richtig startet, obwohl das Skript
unter /etc/rc2.r vor dem Aufruf von sysklogd steht. Ruft
man nach dem Booten /etc/init.d/nfs-common start manuell auf,
findet man dann auch den statd als laufenden Prozess.
Im Syslog findet man anschließend einige Meldungen der
folgenden Art:

lockd: cannot monitor 192.168.0.1
lockd: failed to monitor 192.168.0.1

Diese scheinen sich auf den Bootvorgang zu beschrànken, da sie
spàter nicht mehr kommen. lockd scheint was mit den NFS-Diensten
zu tun zu haben. Kann jemand mit dieser Meldung was anfangen?

Das ganze geht derzeit mit viel Herumprobieren einher. Wenn die
Rechner und die fehlenden Dàmonen manuell gestartet sind, làuft
der Cluster hervorragend, das Problem ist nur dieser làstige
Bootvorgang...

Meine Fragen sind:

- Gibt es irgendwo Empfehlungen zur Bootsequenz (= numerische Reihenfolge
der Links in /etc/rc2.d/) bei Diskless Clients?
- Ich glaube anhand der Boot-Meldungen gesehen zu haben, dass man
bereits beim Kernel-NFS-Mount mehrere NFS-Verzeichnisse über ein
Skript mit angeben kann, anstatt dies - wie momentan hier - nachtràglich
über ein init-skript zu tun.
Dieses Skript muss anscheinend irgendwie in die
initrd mit eingebastelt werden. Ist dies eine bessere Alternative
und gibt es hierzu nàhere Erfahrungen?

Für Feedback wàre ich dankbar.

MfG

Andreas
 

Lesen sie die antworten

#1 Thomas Bliesener
04/12/2008 - 15:19 | Warnen spam
Andreas Pflug schrieb:
Beim Hochfahren der Knoten besteht nun das Problem, dass
sysklogd nicht startet sondern einfach endlos (mindestens 30 min,
danach verließ mich die Geduld...) wartet und somit den
Bootvorgang torpediert.



Vermutlich steht /var in dem Moment noch nicht zur Verfügung.
bli

Ähnliche fragen