Linux-Parallelrechner als Clusterserver in

Transkript

1 Linux-Parallelrechner als Clusterserver in einer RZ-Umgebung Studienarbeit von cand.-inform. Oliver Wellnitz Aufgabenstellung und Betreuung Dr. Jörg Weimar Institut für Wissenschaftliches Rechnen Technische Universität Braunschweig 1

2 Inhaltsverzeichnis 1 Einleitung Aufgabenstellung Danksagung Vorgeschichte Systemkonfiguration Überblick Systemkonfiguration Server Systemkonfiguration Clients /etc/rc.d/rc.sysinit Kernelkonfiguration Network Information System (NIS) Synchronisierung zwischen Client und Server mit rsync Andrew File System (AFS) Secure Shell ssh Ausblick Lastausgleich mit dem Domain Name Service Definition des Problems Der Lösungsansatz Der Lastinformationsdienst (beoprocd) Der Sammler (pollclient) Der DNS Server (beonamed) Interaktive Benutzer Parallel Virtual Machine PVM Konfiguration Informelle Daten Lastinformationen im World Wide Web

3 4 Lastabhängige Prozeßverteilung Hintergrund Überblick Konfiguration beostart beostart.conf Funktionsweise Besonderheiten und Einschränkungen Performancetests Beschreibung der Testumgebung Test des Lastverteilungssystems Testlauf (ohne spezielles Lastverteilungssystem) Testlauf (mit Lastverteilungssystem, 90 Sekunden Updateintervall) Testlauf (mit Lastverteilungssystem, 5 Sekunden Updateintervall) Testlauf (Round robin) Vergleich Round robin / beonamed Zusammenfassung und Ausblick Test der lastabhängigen Prozeßverteilung Analyse und Optimierung der Latenzzeiten Phase 1 - Linux-Kernel Phase 2 - Bildbearbeitung Zusammenfassung und Ausblick Zusammenfassung und Ausblick 35 A Konfiguration des DNS-Servers beonamed 36 B Bootpd-Konfigurationsdatei /etc/bootptab 37 C rsync Exclude Dateien 38 C.1 Root Filesystem update-clientexclude.root C.2 /var Filesystem update-clientexclude.var E Literaturverzeichnis 40

4 Linux-Parallelrechner als Clusterserver in einer RZ-Umgebung Seite 1 1 Einleitung 1.1 Aufgabenstellung Linux-Parallelrechner als Clusterserver in einer RZ-Umgebung Es soll ein Parallelrechner, der als Linux-Cluster gebaut ist, bereitgestellt werden, um als Server für Studenten zu dienen, die sich dort einloggen können. Dazu muß der Rechner zuerst auf den neuesten Stand des Betriebssystems gebracht werden, es muß eine Einbindung in die RZ-Umgebung mit NIS und AFS realisiert werden, es muß eine geeignete Softwareauswahl installiert werden. Um den Cluster als eng gekoppelten Rechner zu betreiben, sollen ausserdem folgende Fähigkeiten realisiert werden: eine lastabhängige Prozess-Migration. eine lastabhängige Auswahl des Einlog-Knotens. eine dynamische Erzeugung von Konfigurationsfiles für das Parallelrechnen mit PVM und MPI. Es sollen Werkzeuge angepaßt werden, die eine zentrale Überwachung aller Knoten erlauben. 1.2 Danksagung Bedanken möchte ich mich bei Frank Strauß für seine procps-patches, dem Rechenzentrum der Technischen Universität Braunschweig, insbesondere Herrn Dümpert für die überwiegend reibungslose Zusammenarbeit und Hilfestellung und natürlich dem PaRe-Team, ohne deren Vorleistung diese Arbeit gar nicht möglich gewesen wäre. Ganz besonderes bedanke ich mich bei Dr. Jörg Weimar, der sich bereiterklärt hat, dieses Thema zu betreuen. 1.3 Vorgeschichte Im Januar 1998 entstand unter der Leitung von Dr. Jörg Weimar das erste Praktikum Parallelrechner aus Standardkomponenten an der TU Braunschweig. Ziel dieses Praktikums war es, einen Supercomputer der Beowulf[BM 84]-Klasse aus Standard PC-Komponenten zu bauen. Die Teilnehmer sollten das Projekt bereits von der Design- und Beschaffungsphase an mit aufbauen und dabei praktische Erfahrungen in der parallelen Datenverarbeitung gewinnen. Als erstes Ergebnis wurden 18 PCs gekauft, die wie folgt ausgerüstet sind: intel Pentium II Prozessor mit 233 MHz 128 MB SD-RAM 4,3 GB IDE Festplatte 89mm (3,5 Zoll) Diskettenlaufwerk, 1,44 MB

5 Linux-Parallelrechner als Clusterserver in einer RZ-Umgebung Seite 2 Abbildung 1: Der PaRe-Cluster 100baseTX Fast Ethernet Netzwerkkarte Ein zusa tzlicher Rechner, der sogenannte Konsolenrechner, bekam eine 24-Port serielle Schnittstelle, er ist auch der einzige Rechner, der eine Grafikkarte und einen Monitor besitzt. Die 18 Pentium II Rechner rzpare01 rzpare18, der eigentliche PaRe Cluster, ko nnen u ber ihn gesteuert werden. Abbildung 1 zeigt das fertige System. Der erste Rechner, rzpare01, dient zusa tzlich als Router und Server fu r den Rest des Clusters und besitzt aus diesem Grund einen SCSI-Controller, eine zusa tzliche SCSI-Platte und eine zweite Netzwerkkarte. Die Rechner sind untereinander u ber einen 10/100 MBit Ethernet Switch der Firma NBase verbunden. Als Netzwerkprotokoll kommt TCP/IP zum Einsatz.

6 Linux-Parallelrechner als Clusterserver in einer RZ-Umgebung Seite 3 2 Systemkonfiguration 2.1 Überblick Der Cluster lief seit Ende des Praktikums im Oktober 1998 in einem stabilen Zustand mit Red- Hat Linux 5.0 und der Linux Kernelversion 2.0. Im Rahmen dieser Studienarbeit sollte das System gleichzeitig auf RedHat Linux 6.0 mit der Linux Kernelversion umgerüstet werden. Neben der glibc-2.1 und dem neuen Kernel ist eine einigermaßen aktuelle Distribution mit allen notwendigen Patches auch die Grundvoraussetzung für den sicheren Einsatz als Produktionsmaschine in einem Rechenzentrum. Die Umstellung aller System- und Anwendungsprogramme wird dankenswerterweise vollständig von der Linuxdistribution geleistet. Dennoch muß noch einiges umkonfiguriert und angepaßt werden, da PaRe nicht unbedingt die üblichen Merkmale eines PCs aufweist. Trotz einer eigenen 4 GB Festplatte booten die Rechner rzpare02 bis rzpare18 diskless. Momentan tun sie das noch mit Hilfe einer Diskette, auf der sich jedoch nur der Linux-Kernel befindet. Eine Version mit Boot-EPROMs ist ebenfalls denkbar. Das Root- und andere Filesysteme werden per Network File System (NFS) vom Server importiert. Die Festplatte wird natürlich auch genutzt. Sie enthält eine große temporäre Partition /tmp, den Cache für das Andrew File System (AFS) und den 256 MByte großen Swapbereich. Die Abbildungen 2 und 3 zeigen die Mounttabellen für Clients und Server. Filesystem Size Used Avail Use Mounted on /dev/root 585M 171M 384M 31% / server:/export/rzpare02-var 585M 171M 384M 31% /var /dev/hda9 2.5G 594k 2.4G 0% /tmp server:/home 2.3G 2.2G 28M 99% /home server:/usr 994M 523M 420M 56% /usr server:/usr/local 873M 419M 409M 51% /usr/local /dev/hda8 585M 22M 532M 4% /usr/vice/cache AFS 8.6G 0 8.6G 0% /afs Abbildung 2: Mount-Tabelle (diskless Clients) Das /export Filesystem enthält das Root-Filesystem für die 17 Clients und für jeden ein eigenes /var Verzeichnis, welche an die jeweiligen Rechner per NFS exportiert werden. Da das Root- Filesystem nur lesend an die Clients exportiert wird, braucht es nur einmal auf der Festplatte zu liegen, die Clients können ja nichts daran verändern. Anders ist es mit den /var Verzeichnissen. Hier liegen Lockfiles, Spoolverzeichnisse und Zwischenlagerungsbereiche, die jeder Rechner für sich braucht und auf die er auch schreibend zugreifen können muß. Im folgenden wird die Systemkonfiguration des Servers und der Clients ausführlich beschrieben, sofern sie von einer normalen stand-alone Installation abweicht. Weiterführende Informationen zur Systemkonfiguration unter Linux findet man in [Hei99] oder [WDK99]. Es wird jeweils ein oder mehrere Kommandozeilenbefehle gezeigt und dann im nächsten Absatz erläutert.

7 Linux-Parallelrechner als Clusterserver in einer RZ-Umgebung Seite 4 Filesystem Size Used Avail Use Mounted on /dev/sda5 61M 50M 7.5M 87% / /dev/sda6 585M 171M 384M 31% /export /dev/sda8 2.3G 2.2G 28M 99% /home /dev/sda7 994M 523M 420M 56% /usr /dev/hda7 2.5G 1.4G 965M 60% /tmp /dev/hda8 296M 85M 196M 30% /usr/vice/cache /dev/hda9 873M 419M 409M 51% /usr/local AFS 8.6G 0 8.6G 0% /afs 2.2 Systemkonfiguration Server Abbildung 3: Mount-Tabelle (Server) Zunächst einmal muß das root-verzeichnis und die /var Verzeichnisse für die Clients erstellt werden. Dazu werden die jeweiligen Filesysteme vom Server ersteinmal kopiert. rzpare01 # mkdir -p /export/root rzpare01 # tar cpbslf - / ( cd /export/root; tar xvpbsf - ) rzpare01 # cd /var rzpare01 # for i in seq -w 18 ; do tar cpbslf - /var ( cd /export ; tar xpbsf - ); mv /export/var /export/rzpare$i-var ; done Wie der aufmerksame Leser sicherlich schon bemerkt hat, erstellt das letzte Kommando auch eine Kopie von /var für rzpare01, den Server. Damit soll dem ganzen eine einheitliche Struktur gegeben werden, als Nebeneffekt werden jetzt auch Hardlinks zwischen allen /var Verzeichnissen möglich. Natürlich muß noch ein entsprechender Link erstellt werden: rzpare01 # rm -Rf /var rzpare01 # ln -s /export/rzpare01-var /var Damit die Cluster Clients über das Netz booten können, muß ein sogenannter Boot protocol-server (BOOTP) auf dem Server installiert und konfiguriert werden. Er übergibt den Clients unter anderem Informationen über Ihre IP-Adresse, die Subnetzmaske, das Rootfilesystem, die NIS Domäne und vieles andere mehr. Die Clients werden dabei aufgrund der eindeutigen Medium Access Control (MAC) Adresse der Netzwerkkarte unterschieden. Die vollständige Konfigurationsdatei des BOOTP daemon befindet sich in Anhang B. rzpare01 # mv /var/lib/rpm/* /usr/lib/rpm rzpare01 # rmdir /var/lib/rpm rzpare01 # ln -s /usr/lib/rpm /var/lib/rpm Die Linux-Distribution RedHat benutzt das Packagemanagementsystem RPM, welches Informationen über installierte Softwarepakete beinhaltet. Diese Datenbank liegt defaultmäßig in /var/lib/ rpm und ist somit im Cluster 18 mal vorhanden. Da die Clients die komplette Software vom Server beziehen, macht es Sinn diese Datenbank auch gleich in das /usr Filesystem zu verschieben.

8 Linux-Parallelrechner als Clusterserver in einer RZ-Umgebung Seite 5 TUBSnet Systemkonfiguration Clients Abbildung 4: Netzwerkstruktur rzpare-client # chkconfig --level 2345 network off Die Netzwerkkonfiguration wird vor dem Booten des Kernels bereits durch BOOTP ausgeführt und ist nicht notwendig. rzpare-client # ln -s /sbin/true /sbin/fsck.nfs Das Root-Filesystem der Clients kommt über NFS und braucht daher keinen Filesystemcheck zu durchlaufen. So verläuft der Test immer erfolgreich. rzpare-client # chkconfig --del nfs

9 Linux-Parallelrechner als Clusterserver in einer RZ-Umgebung Seite 6 NFS Filesysteme brauchen nicht mehr gemounted zu werden, da dies bereits vorher in /etc/rc. d/rc.sysinit passiert. rzpare-client # ln -s /etc/mtab /proc/mounts Das root Filesystem wird, wie später noch zu sehen sein wird, nicht schreibbar den Clients zur Verfügung gestellt. In /etc/mtab legen jedoch Programme wie zum Beispiel mount(8) Informationen über die aktuell gemounteten Dateisysteme ab. Da alle Clients dasselbe root Filesystem benutzen und somit auch dieselbe /etc/mtab, wäre es nicht ratsam, in diese Datei zu schreiben, da alle anderen Clients plötzlich andere, falsche Informationen hätten. Der Kernel hat jedoch seine eigene Mounttable, die er über das Pseudofilesystem /proc zur Verfügung stellt. rzpare-client # mkdir /var/dev rzpare-client # touch /var/dev/log rzpare-client # ln -s /var/dev/log /dev Der Socket /dev/log wird vom syslogd(8) daemon erstellt, der hierüber Meldungen von Programmen empfängt und weiterverarbeitet. Da auf jedem Rechner ein eigener daemon läuft, ist es sinnvoll, diesen Socket nach /var zu verlagern. Zusätzlich wird noch ein Link erstellt, um die Änderung transparent zu halten. Dieser Befehl muß auf jedem Client oder auf allen /export/ rzpare*-var Verzeichnissen ausgeführt werden, da jeder Rechner, wie bereits erwähnt, sein eigenes /var Filesystem besitzt. Es wurden noch weitere Anpassungen gemacht, die hier nicht im Detail beschrieben werden sollen. So wurde der Server als Empfänger aller syslog-nachrichten in /etc/syslog.conf eingetragen und die Datei /etc/fstab mit den notwendigen NFS Einträgen versehen /etc/rc.d/rc.sysinit Im Nachfolgenden wird die beim Systemstart wichtige Datei /etc/rc.d/rc.sysinit und die darin gemachten Änderungen näher betrachtet. Die Ausgabe eines diff(1) zwischen der Originaldatei und der geänderten wurde dafür etwas aufgearbeitet und kommentiert. Zeilen, die mit einem Minus beginnen, wurden aus der Originaldatei gelöscht, Zeilen mit einem Plus am Anfang ergänzt. Alle übrigen blieben unverändert. Zeile 57: - action Setting hostname $ HOSTNAME hostname $ HOSTNAME + action Hostname already set. We are hostname /bin/true Der Hostname wurde bereits mit dem BOOTP-Protokoll vom Server übermittelt und gesetzt. Deshalb ist eine Änderung hier nicht mehr notwendig. Stattdessen wird der Hostname zur Kontrolle auf der Konsole ausgegeben.

10 Linux-Parallelrechner als Clusterserver in einer RZ-Umgebung Seite 7 Zeile 61: # Set the NIS domain name if [ -n $NISDOMAIN ]; then action Setting NIS domain name $NISDOMAIN domainname $NISDOMAIN - else - domainname + #else + # domainname fi Ähnliches wie für den Hostnamen gilt auch für den NIS Domainnamen. Er wurde bereits gesetzt und braucht nicht verändert zu werden. Hier muß allerdings noch zusätzlich darauf geachtet werden, daß er nicht gelöscht wird, da die Variable NISDOMAIN nicht definiert ist. Um dies zu umgehen, wird der entsprechende else-fall einfach auskommentiert. Zeile 134: # Remount the root filesystem read-write. - action Remounting root filesystem in read-write mode - mount -n -o remount,rw / + #action Remounting root filesystem in read-write mode + # mount -n -o remount,rw / Das Root-Filesystem wird von allen Clients gleichzeitig benutzt. Aus diesem Grund ist es nicht ratsam den Schreibzugriff zu erlauben, da sich eine Veränderung auf alle Clients auswirkt. Ein Fehler eines Rechners könnte so den ganzen Cluster lahmlegen. Da das Root-Filesystem schon vom Kernel read-only gemounted wurde, kann die Aktion hier einfach auskommentiert werden. Zeile 153: # Clear mtab - >/etc/mtab + #>/etc/mtab Wie bereits auf Seite 6 beschrieben, ist /etc/mtab ein Link auf /proc/mounts. Ein Leeren ist also zweckfrei. Zeile 156: # Enter root and /proc into mtab. - mount -f / - mount -f /proc + #mount -f / + #mount -f /proc Aus demselben Grund wie schon zuvor müssen auch das Root- und das Proc-Filesystem nicht in die Datei /etc/mtab eingetragen werden. Der Kernel weiß bereits, daß sie gemounted sind.

11 Linux-Parallelrechner als Clusterserver in einer RZ-Umgebung Seite 8 Zeile 274: # Mount all other filesystems (except for NFS and /proc, which is already # mounted). Contrary to standard usage, # filesystems are NOT unmounted in single user mode. - action Mounting local filesystems mount -a -t nonfs,smbfs,ncpfs,proc + #action Mounting local filesystems mount -a -t nonfs,smbfs,ncpfs,proc + action Enabling loopback network device ifconfig lo action Mounting /var NFS filesystems + mount -t nfs -o nolock server:/export/ hostname -var /var + mount -a + action Mounting filesystems from /etc/fstab /bin/true Die Mountreihenfolge muß bei den diskless Clients etwas anders aussehen. Daher wird der Originalbefehl auskommentiert und durch drei eigene ersetzt. Zunächst wird das Loopback Netzwerkinterface aktiviert. Dies ist bei neueren Linux Kernels erforderlich, da sonst der nächste NFS-mount Befehl hängen bleibt. Außerdem ist die Aktivierung des Loopbackinterfaces sowieso erforderlich, da die Netzwerkkonfiguration der Distribution abgeschaltet wurde (vgl. Seite 5). Anschließend wird das für den entsprechenden Client gültige /var Filesystem per NFS vom Server gemountet. Danach kommt der Rest an die Reihe. Hauptsächlich sind das die Filesysteme für /usr und /tmp, eine genau Liste ist aus Abbildung 2 ersichtlich. Nach der Abbarbeitung dieses Blockes sind alle Filesysteme außer dem AFS verfügbar. Zeile 352: # Right, now turn on swap in case we swap to files. - swapon -a >/dev/null 2>&1 + #swapon -a >/dev/null 2>&1 action Enabling swap space /bin/true Eine explizite Aktivierung des Auslagerungsbereiches ist nicht mehr erforderlich, da direkt in Partitionen und nicht in Dateien ausgelagert wird. 2.4 Kernelkonfiguration Der neue Linux Kernel Version, der zunächst in der Version installiert wurde, bringt einige Veränderungen gegenüber dem alten System mit sich. Für den Parallelrechner ist die Neuimplementierung des Network File Systems (NFS) am Folgenreichsten gewesen. Im Gegensatz zum alten Userspace-Server wird die Hauptfunktionalität jetzt von einem Teil des Betriebssystems selber realisiert und nur noch ein kleiner Teil vom knfsd, dem Userspace-Dämonen, übernommen. Zusätzlich wurde im Linux Kernel das bisher fehlende File locking implementiert. Leider überzeugten die ersten Tests mit dem NFS System nicht. Neben Stabilitätsproblemen richtete das File locking mehr Schaden als Nutzen an. Es funktionierte nämlich gar nicht. Dies war zwar bei den alten Kernen auch der Fall, diese behaupteten aber auch, daß sie es nicht könnten. So war es Programmen möglich sich darauf einzustellen. Als Folge dieses Fehlers mußte das File locking per Befehlsoption nolock beim mounten ausgeschaltet werden. Das Stabilitätsproblem war mit einer handvoll Kernelpatches für die aktuelle Version und der neusten Entwicklerversion des knfsd in den Griff zu bekommen. Zukünftige Kernelversionen werden sicherlich aktuelle knfsd Versionen beinhalten, so daß keine Handarbeit mehr notwendig werden sollte.

12 Linux-Parallelrechner als Clusterserver in einer RZ-Umgebung Seite Network Information System (NIS) Durch das Ausschalten des File locking lief aber plötzlich das Programm ypbind nicht mehr, welches versucht seine Datenbank unter /var/yp zu locken. Das Network Information System (NIS), früher Yellow Pages (YP) genannt, ist eine zentrale Datenbank, die Benutzerinformationen, Rechneradressen, Servicenamen, also die Daten der Dateien /etc/passwd, /etc/hosts und /etc/services enthält aber auch Konfigurationsdateien für Automounter und vieles mehr bereithält und auf Wunsch anderen Rechnern zur Verfügung stellt. PaRe benutzt dabei den NIS Server des Rechenzentrums, um deren Benutzer den Zugriff auf den Cluster zu ermöglichen. Das einzige Verzeichnis, das File locking unterstützt ist das Verzeichnis für temporäre Dateien /tmp, welches auf der lokalen Platte liegt, der gesamte Rest kommt über NFS vom Server. Die eigentliche NIS Datenbank muß also in diesem Verzeichnis liegen. Dies ist durch den temporären Charakter von /tmp etwas schwieriger, denn es muß davon ausgegangen werden, daß das Verzeichnis nach dem Booten einen veränderten oder gar keinen Inhalt mehr besitzt. Vor dem Starten des Programmes ypbind muß also sichergestellt werden, daß das benötigte Verzeichnis sich in einem wohldefinierten Zustand befindet. Dazu wird das Startskript /etc/init.d/ypbind wie folgt ergänzt: rm -Rf /tmp/yp 2>/dev/null action Preparing YP directory /bin/mkdir -p /tmp/yp/binding cat <<EOF >/tmp/yp/nicknames passwd passwd.byname group group.byname networks networks.byaddr hosts hosts.byaddr protocols protocols.bynumber services services.byname aliases mail.aliases ethers ethers.byname EOF Damit diese Konstruktion auch benutzt wird, muß das Verzeichnis /var/yp ein Link auf /tmp/yp sein. Diese Änderung ist natürlich nur auf den Clients notwendig, da der Server das /var Dateisystem auf der lokalen Platte hat. Auch diese Speziallösung kann entfallen, wenn zukünftige Linux-Kernel NFS-File-Locking stabil unterstützt. 2.6 Synchronisierung zwischen Client und Server mit rsync Beim Installieren oder beim Update von Programmen werden Dateien in verschiedenen Bereichen des Systems angelegt oder überschrieben. Die Programme selber, die meistens irgendwo unter /usr beziehungsweise /usr/local liegen, sind damit sofort auf allen Rechnern des Clusters verfügbar. Diese Filesysteme sind nur einmal vorhanden und werden vom Server allen anderen zur Verfügung gestellt. Nicht so einfach ist es bei Konfigurationsdatei, Bibliotheken, Spoolverzeichnisse und ähnlichem. Das Rootverzeichnis gibt es zweimal im Cluster, einmal für den Server und einmal für alle

13 Linux-Parallelrechner als Clusterserver in einer RZ-Umgebung Seite 10 Clients. Das Verzeichnis /var sogar für jeden Rechner einmal. Es muß also ein Mechanismus gefunden werden, mit dem diese Dateien nach der Installation oder dem Update auf allen Rechner synchronisiert werden. Das Programm rsync ist für die Synchronisation von Dateien und Verzeichnissen zwischen zwei Rechnern konzipiert worden und eignet sich für diese Aufgabe hervorragend. Dabei werden die kompletten Verzeichnisse jeweils synchronisiert und bestimmte rechnerspezifische Dateien ausgeschlossen. Die Liste dieser Dateien finden sich in Anhang C. Der eigentliche Synchronisierungsvorgang erfolgt über ein Skript, welches alle Filesysteme nacheinander auf den aktuellen Stand bringt. Im wesentlichen sieht das wie folgt aus, hier als Bash-Skript: # Where are the directories? CLIENT=/export CONFIG=/usr/local/load-balancing # Sync root filesystem rsync -vrlshdxpogt --delete --exclude-from=$config/update-clientexclude.root / $CLIENT/root # Sync all /var filesystem for i in seq -w 2 18 ; do rsync -vrlshdxpogt --delete --exclude-from=$config/update-clientexclude.var /var/ $CLIENT/rzpare$i-var done Zwar kann das Skript update-clients manuell nach einer jeden Änderung aufgerufen werden, mit einem Cronjob ist man aber auf der sicheren Seite. Im Augenblick werden jeden Tag um Mitternacht die Client Rechner aktualisiert. Durch diese Automatisierung darf jetzt natürlich keinerlei Software mehr auf den Client Rechnern installiert werden. Jegliche Veränderung muß auf dem Server rzpare01 durchgeführt und dann mit diesem Mechanismus auf den Cluster verteilt werden. Nach dem Update oder der Installation von Softwarepaketen sollten beide Exclude-Dateien inspiziert und gegebenenfalls aktualisiert werden. Erst danach darf der Aktualisierungsprozess /usr/local/load-balancing/updateclients angeworfen werden. 2.7 Andrew File System (AFS) Das Rechenzentrum der Technischen Universität Braunschweig verwendet das Andrew File System (AFS) der Firma Transarc als verteiltes Dateisystem und zur Benutzerauthentfizierung. Aus diesem Grund wurde auch auf dem Parallelrechner ein AFS-Client installiert, was auch ohne weitere Zwischenfälle verlief. Das Filesystem speichert bereits aus dem AFS geholte Daten auf der eigenen Platte zwischen, um einen performanteren Zugriff zu ermöglichen. Da es keinen Sinn macht, diesen Cache selbst wieder über NFS vom Clusterserver zu holen, erhält jeder Rechner eine eigene Cache-Partition von circa

14 Linux-Parallelrechner als Clusterserver in einer RZ-Umgebung Seite MB Größe. Nach den mit AFS im Rechenzentrum bereits gemachten Erfahrungen reicht diese Größe auch bei intensiveren Arbeiten aus und ist großzügig dimensioniert. Auf der Partition wird mit mke2fs ein Standard Ext2-Dateisystem erstellt und diese wird danach mit dem Mountpunkt /usr/vice/cache in die Mounttabelle /etc/fstab eingetragen. Der AFS daemon arbeitet legt den Cache als normale Dateien im Filesystem ab und initialisiert das Verzeichnis beim Starten automatisch, wenn keine alten Daten gefunden wurden. Ein großer Nachteil an AFS ist, daß sämtliche Programme ersetzt werden müssen, die eine Benutzerauthentifikation durchführen. Das sind neben den Programmen, die zum Einloggen von Benutzern benötigt werden (login, rlogind, rshd u.ä.) auch zum Beispiel passwd zum Ändern von Benutzerpasswörtern oder su zum Wechsel von Benutzeridentitäten. Durch die Verwendung von Pluggable Authentication Modules (PAM), die in allen aktuellen Linux Distributionen standardmäßig verwendet werden, wird diese Änderung jedoch fast trivial. Bei PAM werden alle oben aufgeführten Programme gegen die Bibliothek libpam.so gelinkt. Die Authentifikation wird komplett von dieser Bibliothek durchgeführt, die sich für jedes Programm einzeln, in /etc/pam.d konfigurieren läßt. Sie bedient sich dabei der bereits erwähnten Authentifikationsmodule, die nach einem Regelsatz in der Konfigurationsdatei durchlaufen werden. Abbildung 5 zeigt die Datei/etc/ pam.d/login, die für die Authentifizierungsmethode des Loginprogramms /bin/login zuständig ist. Die dritte Zeile wurde hinzugefügt und macht das Programm ohne Neuübersetzung #%PAM-1.0 auth required /lib/security/pam securetty.so auth required /lib/security/pam nologin.so auth sufficient /lib/security/pam afs.so try first pass ignore root setenv password expires auth required /lib/security/pam pwdb.so shadow nullok account required /lib/security/pam pwdb.so password required /lib/security/pam cracklib.so password required /lib/security/pam pwdb.so shadow nullok use authtok session required /lib/security/pam pwdb.so Abbildung 5: PAM Konfiguration für das Loginprogramm /bin/login AFS-fähig. Ähnliches läßt sich mit allen oben erwähnten Programmen bewerkstelligen. Auf PAM und ihre Konfiguration soll an dieser Stelle nicht weiter eingegangen werden, nähere Informationen zu diesem Thema findet man in [Mor99]. Der kommerzielle AFS Client für Linux wird als binary-only Version ohne Quellcode nur für die Linux Kernelversionen und geliefert. Hauptsächlich aufgrund der NFS Probleme, die im Abschnitt 2.4 Kernelkonfiguration erwähnt wurden, ist es jedoch ratsam, einen aktuelleren Kernel aus der stabilen Versionsreihe 2.2.x zu verwenden. Der einzige Unterschied zwischen beiden Versionen des AFS-Clients besteht im AFS-Kernelmodul, das es für beide oben genannten Version jeweils einmal gibt. Da sich das Modulinterface zwischen verschiedenen Minor-Versionsnummer nicht ändert, ist es sehr wahrscheinlich, daß auch mit höheren Kernelversionsnummern ein stabiler AFS-Betrieb möglich ist. Das Laden des Kernelmoduls geschieht in /etc/init.d/afs mittels insmod(1). Geladen wird dabei /usr/vice/etc/libafs- uname -r.o. Damit das Ganze nun auch unter der installierten Version knfsd1.5.2 funktioniert, muß zunächst mit dem Befehl rzpare01 # cd /usr/vice/etc rzpare01 # ln -s libafs o libafs knfsd1.5.2.o

15 Linux-Parallelrechner als Clusterserver in einer RZ-Umgebung Seite 12 ein Link erstellt werden und dann der insmod Befehl im oben genannten Skript mit der Option -f für force versehen werden. Möglich wäre auch eine Variante mit modprobe(1) und der Kerneloption CONFIG MODVERSIONS. Das alte Modul läuft mittlerweile längere Zeit mit dem neuen Kern und hat sich als ausgesprochen stabil erwiesen. Die eben angesprochene Lösung ist jedoch keinesfalls generisch. Für jede neue Kernelversion aus der 2.2.xer Serie muß jeweils ein eigener Link erstellt werden. Natürlich hätte man das einfacher lösen können, doch wurde dieser Weg mit Absicht gewählt, da es ratsam ist, mit jedem neuen Kern ersteinmal einen intensiven Probelauf durchzuführen bevor man ihn im Produktionsbetrieb einsetzt. Trotz aller Vorsichtsmaßnahmen muß man im Auge behalten, daß strenggenommen das Modul außerhalb seiner Spezifikation betrieben wird. 2.8 Secure Shell ssh Sowohl der eingeschränkt einsetzbare kommerzielle sshd als auch das freie Pendant openssh hatten Probleme in der Zusammenarbeit mit AFS. Zwar klappte die Authentifizierung gegen dieses System, allerdings wurde kein AFS-Token zugeteilt. Letzteres ist aber Bedingung für den Zugriff auf das eigene Homeverzeichnis, so dass ein vernuenftiges Arbeiten nicht moeglich war. Auch durch den Patch aus [Son99] wurde das Problem nicht behoben, da eine Kerberos Authentifikation gegen das AFS immer fehlschlug. Erst der speziell angepasste Secure Shell Dämone des CERN brachte den gewünschten Erfolg. Da dieses Programm leider nur als vorkompiliertes Binary zur Verfügung stand, war eine genauere Analyse des Problems bzw. deren Lösung nicht möglich. 2.9 Ausblick Einige wünschenswerte Erweiterungen wurden im Laufe dieser Arbeit nicht realisiert, würden aber trotzdem eine sinnvolle Ergänzung darstellen. Der PaRe Cluster ist über den Server rzpare01 mit dem Campusnetz der TU Braunschweig und darüber auch mit dem Internet verbunden. Da in jüngster Zeit ein massiver Anstieg von Angriffen über das Internet auf Rechner der Universität stattgefunden hat, ist es sicherlich sinnvoll Maßnahmen zu ergreifen, um die Rechner vor solchen Attacken zu schützen. Durch seine Eigenschaft als Router ist der Server geeignet diese Aufgabe zu erfüllen und als Firewall den Rest des Netzes vor schädlichen Paketen zu schützen. Durch die bereits angedachte Lösung vom Konsolenrechner aus einen Hardwarereset des Clusters durchführen zu können, würde die remote Administration perfektionieren.

16 Linux-Parallelrechner als Clusterserver in einer RZ-Umgebung Seite 13 3 Lastausgleich mit dem Domain Name Service 3.1 Definition des Problems Die Migration von Prozessen ist gewöhnlich mit einer Reihe von Schwierigkeiten verbunden. Selbst wenn es auf den ersten Blick trivial erscheint, Prozesse durch einfaches Kopieren von einem Host auf den anderen zu bringen, wird diese Aufgabe beispielsweise bei geöffneten Dateien und/oder benutzen Sockets recht komplex. Dabei reagiert die Migrationstrategie meistens auch erst dann, wenn Systemresourcen wie Rechenzeit oder Speicher knapp werden. Die hier entwickelte Lastausgleichslösung setzt vorher an, indem bereits vor dem Einloggen des Benutzers oder dem Starten eines Programms versucht wird die Last auf alle Rechner des Clusters möglichst homogen zu verteilen. 3.2 Der Lösungsansatz Die Aufgaben eines Clusters sind zunächst in zwei große Gebiete unterteilt: Interaktiv arbeitende Benutzer und auf mehreren Maschinen laufende parallele Jobs. Für die letzte Kategorie beschränken wir uns auf Prozesse, die über das Parallel Virtual Machine (PVM) System gestartet werden. Dies geschieht exemplarisch für parallelisierbare Prozesse, eine Anpassung an andere Bibliotheken, wie etwas MPI, sind ebenfalls denkbar. Darüberhinausgehende Informationen zu dem hier benutzten PVM finden sich in [Mor99]. Als eindeutiges Identifikationsmerkmal von Rechnern im Internet werden die 32 Bit langen Adressen des Internet Protokols (IP) verwendet. Im alltäglichen Gebrauch werden Rechner aber über Namen bezeichnet, da diese sich erheblich einfacher merken lassen. Für das Mapping zwischen IP-Adressen und Hostnamen sorgt dabei der Domain Name Service (DNS), der in [Moc87a] und [Moc87b] beschrieben wird. Der hierarchische Aufbau des DNS sorgt dabei für den Erhalt der Eindeutigkeit der Rechnernamen. Für den Lastausgleich interaktiver Benutzer wird nun ein virtueller Rechnername erschaffen, dem jeweils dynamisch die Maschine mit der geringsten Last zugeordnet wird. Für PVM wird ein ähnliches Vorgehen angewandt. Auch hier wird ein virtueller Rechner geschaffen, der jedoch aus allen entsprechend konfigurierten Maschinen in gewichteter Reihenfolge besteht. Dieses Verfahren benötigt drei Funktionen: einen DNS Server, der dynamisch erzeugte Datensätze, sogenannte resource records verteilen kann, einen Dienst auf jedem Rechner des Clusters, der Lastinformation bereitstellt, und einen Sammler, der die Lastinformationen sammelt und dem DNS-Server zur Verfügung stellt.

17 Linux-Parallelrechner als Clusterserver in einer RZ-Umgebung Seite 14 Cluster... beo procd beo procd beo procd beo procd beo procd pollclient DNS beonamed Abbildung 6: Das DNS Lastverteilungssystems Der regelmäßige Austausch von Daten zwischen dem DNS-Server und dem Sammler legt nahe, beide Prozesse auf einem Rechner laufen zu lassen, um die Möglichkeit der Interprozesskommunikation auszunutzen. Wie die einzelnen Teile des Lastverteilungssystems zusammenhängen, zeigt Abbildung 6. Im folgenden werden alle drei Teilbereiche im Einzelnen näher betrachtet. 3.3 Der Lastinformationsdienst (beoprocd) Im Rahmen des schon erwähnten Praktikums Parallelrechner aus Standardkomponenten wurde von Frank Strauß ein Softwarepaket[Str98] basierend auf den procps utilities entwickelt, daß unter anderem die Kommandozeilentools ps und top clusterfähig macht. Grundlage hierfür ist der beoprocd daemon, der auf UDP Port Pakete wartet und auf Anfrage Informationen über Prozesse oder das System herausgibt. Durch die Verwendung des User Datagram Protocols (UDP), einem verbindungslosen Transportprotokoll, ist es per Broadcast/Multicast möglich, mit einfachen Mitteln Informationen über den gesamten Cluster zu erhalten. Dazu wird beispielsweise eine Anfrage an die Broadcastadresse des Clusters geschickt und alle Rechner antworten mit der gewünschten Information. Da die Anzahl der eingeloggten Benutzer für den Lastausgleich recht interessant ist, wurde beoprocd und das verwendete Nachrichtenformat verändert und ergänzt (siehe Abbildung 7). Zusätzlich

18 Linux-Parallelrechner als Clusterserver in einer RZ-Umgebung Seite 15 zu den Daten über die Last und die Speicherbelegung wurde je ein Feld über die Anzahl aller eingeloggten Benutzer und über die Anzahl aller benutzten Terminals hinzugefügt. Die zweite Zahl ist dabei größer oder gleich der ersten, da ein Benutzer mehrere Terminals benutzen kann. Um Inkompatibilitäten zwischen dem Originalprogrammpaket und der angepaßten Version zu vermeiden, wurden auch die Kodierungen geändert, mit dem auf die Informationen zugegriffen werden kann. Ein so veränderter Server reagiert auf Anfragen von älteren Clients somit nicht mit (für den Client) falschen Werten. struct sysinfo ; time t timestamp; char host[10]; double uptime; double idle; double loadavg 1; double loadavg 5; double loadavg 15; unsigned int user total; unsigned int user unique; unsigned long long meminfo total; unsigned long long meminfo free; unsigned long long meminfo shared; unsigned long long meminfo buffers; unsigned long long meminfo cached; unsigned long long meminfo swtotal; unsigned long long meminfo swfree; Abbildung 7: Datenstruktur der verteilten Lastinformation 3.4 Der Sammler (pollclient) Der Sammler sendet regelmäßig, defaultmäßig alle 30 Sekunden, einen Broadcast UDP Request auf Port 45367, um die Lastinformationen vom beoprocd aller Rechner des Clusters anzufordern. Im Falle mehrerer Netzwerkkarten benutzt er das Interface mit der kleinsten Netzmaske. Somit ist diese Version darauf beschränkt im gleichen Netzsegment zu laufen, wie auch der Cluster selber. Bevor wieder eine Anfrage gesendet wird, werden alle bisher vom Cluster empfangenen Daten in eine Datei geschrieben. Dann wird der DNS Server durch ein Signal dazu aufgefordert die Daten neu einzulesen. Der Sammler nimmt keinerlei Vorsortierung der Daten vor, denn er kennt auch die Konfiguration des Lastausgleichssystems nicht. Seine Aufgabe ist auf das reine Sammeln von Statusinformationen aus dem Cluster beschränkt. Die Schnittstelle zwischen Sammler und DNS Server wurde bewusst so einfach wie möglich gehalten, damit der Sammler austauschbar bleibt. Denkbar sind zum Beispiel auch Versionen, die außerhalb des Clusters lauffähig sind, oder ein Sammler, der seine Informationen über den Remote Procedure Call (RPC) Dienst rstatd und dergleichen bezieht. Ein eigenes Programm muß folgende Merkmale unterstützen:

19 Linux-Parallelrechner als Clusterserver in einer RZ-Umgebung Seite 16 Es existiert ein Kommandozeilenparamter mit dem Format -t Timeout-Wert in Sekunden angibt., der den Der Rechnerstatus wird jeweils einmal im Timeoutintervall aktualisiert. Das Ergebnis muß in die Datei /var/tmp/lb.status geschrieben werden. Um race conditions zu vermeiden, sollte eine temporäre Datei benutzt werden und diese mittels rename(2) erst kurz vor dem Senden des Signals in /var/tmp/lb.status umbenannt werden. Die Datei enthält pro Rechner eine Zeile und in mehreren durch Leerzeichen oder Tabulatoren getrennten Spalten diverse Informationen, die Tabelle 8 zu entnehmen sind. Der Sammler sendet nach Ablauf des Timeoutintervalls ein Signal (SIGUSR1) an seinen Vaterprozess. Spalte Information 1 Fully qualified domain named (FQDN) des Rechners 2 Zeit von Absenden der Antwort bis zur Ankunft der Antwort in Sekunden. 3 Last gemittelt über die letzte Minute 4 Last gemittelt über die letzten 5 Minuten 5 Last gemittelt über die letzten 15 Minuten 6 Anzahl der benutzen Terminals (0 falls nicht bekannt) 7 Anzahl der eingeloggten Benutzer (0 falls nicht bekannt) Abbildung 8: Dateiformat von /var/tmp/lb.status 3.5 Der DNS Server (beonamed) Es gibt bereits viele Implementationen für Domain Name Service (DNS) Server mit load-balancing Fähigkeiten, die verschiedene Ansätze und Ziele verfolgen (beispielsweise [lbnb] und [lbna]). Aus diesem Grund war es auch nicht notwendig das Rad neu zu erfinden. Der lbnamed [Sch95] von Roland Schemers benutzt ein recht modulares Konzept und ist auch nicht auf einen speziellen Verwendungszweck hin konzipiert. Zusätzlich ist er in Perl geschrieben und frei in Quellcode-Form erhältlich. Der im Laufe dieser Studienarbeit entwickelte beonamed basiert auf dem lbnamed, ist aber stark verändert und erweitert worden. Im nachfolgenden werden die einzelnen Funktionen des DNS Servers beleuchtet und und anschließend die Konfigurationsmöglichkeiten erörtert Interaktive Benutzer Zum interaktiven Arbeiten wird ein neuer, virtueller Rechner im DNS erschaffen, der die Benutzer abhängig von der Last der Maschinen des Clusters jeweils bei Zugriff auf den günstigen physikalischen Rechner leitet. Dabei kann durch Konfiguration festgelegt werden, welche Maschinen für diesen Zweck zur Verfügung stehen. Bei jeder Anfrage besteht die Antwort aus den beiden besten Rechnern, soweit verfügbar. Das hat zum einen den Zweck, daß notfalls der zweitbeste Rechner einspringen kann, falls zwischen dem Zeitpunkt der Lastabfrage und der DNS-Anfrage der beste Rechner unerwartet ausfällt. Zum anderen benutzen aktuelle DNS Resolver eine Round-Robin

20 A F D D Linux-Parallelrechner als Clusterserver in einer RZ-Umgebung Seite 17 Strategie für gecachte Einträge. Innerhalb der Gültigkeitsdauer der vom Lastausgleichssystem gegebenen Antwort findet demnach eine Gleichverteilung auf die beiden besten Rechner statt. Die Last eines Rechners wird wie folgt berechnet:!#" -,/ %$&'&(*)+ (87:9 6.;< $=9 6.;?>1.0@2465 (BA!#" ist die Anzahl der lauffähigen Prozesse im Scheduler, gemittelt über eine Minute. Die Variablen )+ und werden im Abschnitt Konfiguration näher erläutert. ist 6<,/.0@ ;<,/.'012C5 ein variabler Wert der sich nach der Formel berechnet. EDF $HG&IKJ@%(L $HG&IKJ Wie bereits erwähnt arbeitet das System mit Stichpunktmessungen der Rechnerlast in festen Intervallen. Tritt nun in einem Intervall eine große Anzahl von Nachfragen nach dem virtuellen Rechner auf, so resultiert hieraus immer dieselbe Antwort. Aus diesem Grund wird der Lastwert jedes Rechners um einen festen Wert verschlechtert, wenn er in einer Antwort erwähnt wird. Die Last wird für diese Rechner praktisch für die Zukunft vorhergesagt. Jede Antwort auf die Frage nach der Adresse des virtuellen Rechners wird mit zwei Rechnern beantwortet. Je nachdem wie oft ein Rechner als erster (G&IKJ@ ) oder zweiter (GMIKJ ) in einer Antwort enthalten war, umso größer wird seine Last. Der Sinn in der Existenz von A ist somit eine Art trivialer Prognose des Lastverhaltens eines Rechners zwischen zwei Stichpunktmessungen. Ein Rechner mit geringerem Lastwert wird dabei gegenüber einem mit höherem Wert bevorzugt Parallel Virtual Machine PVM Zur Benutzung von PVM steht das Programm beopvm zur Verfügung, daß die für den Benutzer günstigsten Rechner auswählt. Dabei werden nur die Rechner berücksichtigt, die in /etc/ cluster.conf für PVM Aufgaben konfiguriert wurden. Über Optionen auf der Kommandozeile lassen sich die gewünschte Anzahl der Rechner und ein Debugmodus einstellen. Ohne diese Angaben versucht beopvm, bei ausgeschaltetem Debug-Modus so viele Rechner wie möglich zu belegen. Die vollständige Kommandozeile sieht wie folgt aus: beopvm [-n #Hosts] [-d] [ Programm ] Das Programm konfiguriert den pvmd und startet eine Shell, von der aus sich PVM Programme und das Kommandozeilenfrontend pvm starten lassen. Beim Verlassen der Shell werden alle PVM Prozesse beendet. Für nicht-interaktive Arbeiten ist es auch möglich den PVM Job gleich beopvm mit auf der Kommandozeile zu übergeben Konfiguration Der DNS-Server beonamed wird über die Datei /etc/cluster.conf konfiguriert. Weitere Konfigurationsoptionen, beispielsweise Logging-Möglichkeiten, sind über die Kommandozeile beim Aufruf möglich. Hier kann auch eine alternative Konfigurationsdatei angegeben werden. Die genauen Optionen können der beonamed Manpage entnommen werden.

21 Linux-Parallelrechner als Clusterserver in einer RZ-Umgebung Seite 18 Die Datei beonamed wird zeilenbasiert abgearbeitet und enthält in jeder Zeile genau eine Direktive, gefolgt von einem Doppelpunkt und einem Wert. Ein Beispiel finden sich in Anhang A. Admin (notwendig) Adresse des Clusteradministrators. Die Mailadresse muß nach RFC 822[Cro82] gültig sein. Augenblicklich wird diese Adresse nur für den SOA (Start of Authority) Datensatz im DNS benutzt. Eine spätere Verwendung für Fehlernachrichten ist jedoch denkbar. DNSDomain (notwendig) Name der Domain, die an den beonamed-rechner deligiert wurde. Dieser Eintrag muß in der Konfigurationsdatei grundsätzlich vor der Direktive DNSLBHost definiert werden. DNSLBHost (notwendig) Name des virtuellen Hosts für interaktiv arbeitende Benutzer. Der Name muß ohne Domain angegeben und kann frei gewählt werden, der Name pvm und load ist jedoch reserviert. DNS Anfragen nach diesem Namen werden mit einem der interaktiven Rechner aus der Hosts Direktive beantwortet. DNSServer (notwendig) Name des Rechners, der verantwortlich für den Lastausgleich ist. Dieses ist der Rechner auf dem der beonamed daemon läuft. Host.[ Rechnername ]. Option (optional) Diese Direktive verändert einzelne Werte auf einer per Host- Basis. Der Rechnername muß in der Direktive Hosts erwähnt werden. Folgende Optionen können verändert worden sein. Interactive [yes/no] (Standardwert: yes) Dieser Rechner soll/soll nicht interaktiv benutzt werden. Der durch DNSLBHost konfigurierte virtuelle Rechner besteht ausschließlich aus der Gruppe interaktiver Maschinen. PVM [yes/no] (Standardwert: yes) Dieser Rechner soll/soll nicht für PVM (Parallel virtual machine) Aufgaben benutzt werden. UserPenalty [Zahl] (Standardwert: durch UserPenalty-Direktive angegeben oder 0) Strafwert für jeden eingeloggten Benutzer dieses Rechners. Gezählt wird hierbei nur die Anzahl der verschiedenen Benutzer. Dieser Wert wird mit der Benutzeranzahl multipliziert, bevor er zu dem 100fachen des Lastwertes des Rechners hinzuaddiert wird. HostPenalty [Zahl] (Standardwert: 0) Konstanter Strafwert pro Rechner. Dieser Wert wird zu dem 100fachen des Lastwertes des Rechners hinzuaddiert, bevor er mit anderen verglichen wird. Durch diese Option kann eine schwächere Maschine oder ein Rechner mit zusätzlichen Aufgaben besonders berücksichtigt werden. Hosts (notwendig) Durch Leerzeichen oder Tabulatoren getrennte Liste aller am Cluster teilnehmenden Rechner. Alle Einträge müssen durch den Resolver aufgelöst werden können. Poller (notwendig) Programm, das die Lastinformationen sammelt. Es muß der vollständige Pfad angegeben werden. Im Abschnitt 3.4 ist der Lastsammler näher beschrieben.

22 Linux-Parallelrechner als Clusterserver in einer RZ-Umgebung Seite 19 RunAs (notwendig) Diese Direktive gibt den Benutzer an, unter dem der DNS-Server und der Lastsammler läuft. Der DNS-Server startet zwar als root um sich an den DNS Port zu binden, macht aber nach Öffnen der Sockets ein setuid(2) auf die angegebene UserID. TTL (optional) Lebenszeit (TTL Time to live) der Lastinformationen. Dieses ist die Länge des Intervals, in dem die Lastinformationen der Rechner des Clusters auf den neusten Stand gebracht werden. Der Standardwert ist 30 Sekunden. UserPenalty (optional) Hiermit kann ein Strafwert für jeden eingeloggten Benutzer einer Maschine angegeben werden. Ein Benutzer, der mehrfach auf ein und derselben Maschine eingeloggt ist, wird nur einfach gezählt. Auf verschiedenen Maschinen zählt er jeweils als ein Benutzer Informelle Daten Zusätzlich zu den für das Lastausgleichsverfahren notwendigen Datensätzen gibt es noch einen weiteren. Auf die Anfrage nach load + Domainnamen erhält man einen RFC1464[Ros87]-kodierten Textstring. Abbildung zeigt eine solche Abfrage. Die Antwort enthält den festen String,,Load=, die aktuelle Anzahl der laufenden Rechner im Cluster und die drei jeweils aufsummierten realen Lastwerte des Clusters im ein, fünf und 15 minütigen Mittel. $ nslookup -query=txt load.pare.rz.tu-bs.de Server: meister.ibr.cs.tu-bs.de Address: load.pare.rz.tu-bs.de text = Load=17, 17.03, 17.03, pare.rz.tu-bs.de nameserver = rzpare01.rz.tu-bs.de Abbildung 9: Zusätzliche Lastinformation im DNS Lastinformationen im World Wide Web Eine Übersicht über die augenblickliche Konfiguration und die Last der einzelnen Rechner des Clusters stellt beonamed als HTML Seite im WWW dar. Abbildung 10 zeigt diese Übersicht. Auf sie kann über Port 8080 des DNS-Servers zugegriffen werden.

23 Linux-Parallelrechner als Clusterserver in einer RZ-Umgebung Seite 20 Abbildung 10: Lastinformation über PaRe im WWW