Kategorien

  • Keine Kategorien

Archive

Google

Google
Web www.barmala.de

Yahoo

Linux diskless via NFS booten

» Linux » Software

 

 

Was ist das? Wozu braucht man das?

„Thin Clients” verfolgen das Ziel, die Verwaltung von Arbeitsplatzrechnern zu zentralisieren. Speicherkapazität wird zentral vorgehalten und in Backupkonzepte einbezogen. Konfigurationen werden zentral verwaltet.

Da es beim diskless Rechner nicht um die Kostenersparnis für die lokale Platte, sondern um die zentrale Verwaltung und Sicherung geht, werden aus Performancegründen gerne „near diskless” Systeme mit eine lokalen Platte für Swap- und Temporärdateien eingesetzt.

Bei diesem Artikel geht es nicht um den Einsatz von FibreChannel oder iSCSI HBAs mit Boot-Prom (int 13 für „Wintel” und „EFI” für Itanium) sondern um booten über NAS. Es geht auch primär im Unix, weil booten vom NAS bei Windows nur bedingt oder gar nicht möglich ist. Als Beispiel wird SuSE Linux benutzt.

Ein verwandtes Thema ist, das Netzwerk nur zu nutzen, um das Betriebssystem auf Rechner zu installieren, die mit einer leeren Festplatte ausgeliefert werden. („Remote Installation Services” oder kurz „RIS”) In diesem Fall wird das Installationsprogramm über das Netz gebootet, das eigentliche Betriebssystem bootet aber von der lokalen Festplatte.

Wie geht das?

  1. Das diskless System, das vom Netz gebootet werden soll (im folgenden „Netboot-System”) genannt, holt sich seine IP-Konfiguration vom DHCP-Server. Dieser übergibt zusätzlich zu dieser Konfiguration einen Verweis auf den TFTP-Server
  2. Der TFTP-Server liefert ein Mini-Linux („pxelinux”). Dieses kann entweder dem Benutzer ein Menü mit verschiedenen Boot-Möglichkeiten darstellen oder selber eine Auswahl treffen, was als nächstes zu laden ist.
  3. Jetzt wird ein geeignet angepasster Linux Kernel geladen, dem als Parameter mitgegeben wird, wo er einen NFS-Export mit seinem Root-Filesystem findet.
  4. Der NFS Export und die Daten darauf, müssen vorher von einem anderen Rechner aus angelegt worden sein.

Es ist hilfreich zwei Maschinen zu haben, die identisch sind bis auf die Tatsache, dass eine lokal und die andere vom Netz bootet. Die eine nenne ich im folgenden „Referenzsystem”, die andere „Netboot-System”.

DHCP

Damit die Netzwerkkarte irgendetwas tun kann, bevor das Betriebssystem geladen ist, z. B. eine RARP, bootp oder DHCP-Anfrage schicken und anschließend mit dem TFTP-Server zu kommunizieren braucht sie entweder ein spezielles Boot-Prom oder Unterstützung durch das BIOS. Hierfür gibt es verschiedene Methoden, z. B. „Etherboot”. Daher gibt es eine verwirrende Vielfalt von z. T. recht komplexen Dokumenten. Glücklicherweise beherrschen die meisten aktuellen Rechner beherrschen von Hause aus PXE, so dass sich die Konfiguration des DHCP-Servers sehr einfach gestaltet:. Unter SuSE Linux kann man eine Grundkonfiguration mit „yast2 dhcp-server einrichten, und auf einem Windows-Server kann ein DCHP-Server ebenfalls mit ein paar Mausklicks eingerichtet werden. Danach muss man zwei Optionen zumr Konfiguration des DHCP-Servers hinzufügen:

filename "/pxelinux.0";
next-server name oder IP des TFTP-Servers;

Weitere, oft genannte Optionen sind nach meinen Erfahrungen nicht nötig.

TFTP, pxelinux

Unter SuSE Linux kann der TFTP-Server mit „yast2 tftp-server” installiert werden. Dabei wird das Verzeichnis „/tftpboot” angelegt. Dorthin muss man die Datei „pxelinux.0” (Das „Mini-Linux”) kopieren. Man bekommt sie von der Syslinux-Site oder aus dem SuSE syslinux RPM, das diese Datei unter „/usr/share/syslinux/pxelinux.0” ablegt. Das Konfigurationsverzeichnis liegt unter „/tftpboot/pxelinux.cfg”. In diesem Verzeichnis sucht pxelinux nach einer Datei, deren Namen der MAC-Adresse des Clients entsrpicht, dann nach einer Datei, die der IP-Adresse oder dem Subnet des Clients entspricht und zuletzt nach einer Datei namens „default”. Diese Datei könnte z. B. wie folgt aussehen:

default netboot
prompt 0
# timeout 10

label netboot
  kernel /SuSE/i386/vmlinuz
  append root=/dev/nfs rw nfsroot=servername:/nfsroot ip=dhcp

label install
  kernel /SuSE/i386/linux-install
  append initrd=/SuSE/i386/initrd-install install=nfs://servername/Instserver/source/suse/

label local
  LOCALBOOT 0

Achtung: „/SuSE” ist hier relativ zu „/tftpboot”

Die Option „install” ist dazu gedacht, ein System mit lokaler, aber noch leerer Platte zu installieren.

Manchmal wird „localboot” als Default gewählt, damit Maschinen, die nicht über Netz booten sollen, und schon gar nicht eine Neuinstallation via Netz veranlassen sollen, bei deinen aber PXE versehentlich eingeschaltet ist, trotzdem korrekt booten.

Kernel

Zunächst muss der Kernel oder die initrd alle Module enthalten, die zur Unterstützung der Hardware erforderlich sind. Wenn man beides vom „Referenzsystem” auf den TFTP-Server kopiert, ist das schon mal ein guter Anfang. Allerdings benötigt der Kernel die Option „CONFIG_ROOT_NFS”, die ihrerseits „CONFIG_IP_PNP” voraussetzt. Diese Optionen sind normalerweise im Kernel nicht enthalten, wie man mit „zcat /proc/config.gz | grep CONFIG_ROOT_NFS” oder „grep CONFIG_ROOT_NFS /boot/config-`uname -r`” leicht feststellen kann.

Um einen neuen Kernel zu bauen, müssen auf dem Linux-System die Entwicklungsumgebung und die Kernel Sourcen installiert sein. Die Konfiguration des aktuell laufenden Kernels kann man mit „make cloneconfig” in die Entwicklungsumgebung übernehmen. Dann kann man mit „make menuconfig” die erforderlichen Änderunge vornehmen. Es empfiehlt sich olgende Optionen built-in (nicht als initrd-Module) zu setzen:

device driver | network support | networking options
  TCP/IP networking
    IP Kernel level autoconfiguration
    dhcp support, Bootp support 
Network device support
  Ethernet 10 or 100 MBit
    AMD Pcnet32 PCI support
Filesystem
  Network File Systems
    NFS file system support
    Root file system on NFS

Mit „make bzImage” kann neue Kernel kompiliert werden. Mit „cp /usr/src/linux/arch/i386/boot/bzImage /tftpboot/SuSE/i386/vmlinuz” wir er auf dem TFTP-Server abgelegt. (Je nach Architektur könnte statt „i386” dort z. B. auch „x86_64” stehen.)

Die (hier nicht behandelte) Alternative zu einem Kernel, der seine Root-Verzeichnis auf NFS legen kann, ist ein mini-Root-Filesystem auf einer Ramdisk, das nur die darunterliegenden Verzeichnisse (/usr, /var, /home, ...) auf NFS liegen hat. Auf diese Art wäre es auch denkbar, einen Teil der Dateisysteme, z. B. Swap, nicht per NFS sondern per Software iSCSI initiator anzubinden.

NFS Root

Den NFS Export auf dem Referenzsystem unter „/var/tmp/dirinstall” mounten und dann mit „yast2 dirinstall” ein Linux dorthin installieren oder unter „/mnt” mounten und dann mit „cd /; cp -R alles außer /mnt mnt” das Referenzsystem dorthin kopieren. Mit „chroot /var/tmp/dirinstall” bzw. „chroot /mnt” kann man in diese Umgebung wechseln und dann z. B. mit „yast” die notwendigen Anpassungen (z. B. andere Netzwerkadresse als das Referenzsystem) vornehmen.

Die Reihenfolge, in der die Dienste gestartet und gestoppt werden, ist nicht für den Einsatz eines NFS-Root optimiert. Insbesondere die Netzwerkdienste werden beim herunterfahren zu früh gestoppt. Ein Eintrag CONNECTION_CHECK_BEFORE_IFDOWN="yes" in /etc/sysconfig/network/eth-id-mac-addr kann helfen.

NFS Swap

Beim Swappen über NFS ist mit sehr schlechter Performance zu rechnen. Es ist auch nicht unmittelbar supportet. Der Workaround ist, auf dem NFS Mount eine Datei in der Größe des beabsichtigten Swapspaces anzulegen, diese dann mit dem Loopback-Treiber zu mounten und das gemountete „Laufwerk” dann als Swapspace zu formatieren. Besser ist, genügend RAM zu verwenden, so dass kein Swap nötig ist oder eine lokale Platte zum Swappen zu verwenden. Die letztere Aussage ist natürlich problematisch in einer Firma, die betont, dass NAS schneller sei als lokale Platten.

Support

Die meisten Linux Distributoren verweisen darauf, dass man mit einem selbstgebauten Kernel den Support verliert. Einige Kollegen haben mich auf die Dokumentation von FujitsuSiemens FlexFrame hingewiesen, die über NFS booten und viel einfacher zu installieren seien, als ich es oben beschrieben habe. Dort hat FSC sich alle o.g. Gedanken gemacht und übernimmt auch die Pflege des „unsupporteten” Linux.

Links