Zum Inhalt springen

Beowulf

Links hinzufügen
Aus Wikibooks

Dieses Buch steht im Regal EDV.

Zusammenfassung des Projekts

[Bearbeiten]

80% fertig „Beowulf“ ist nach Einschätzung seiner Autoren zu 80 % fertig

  • Buchpatenschaft / Ansprechperson: Zur Zeit niemand. Buch darf übernommen werden.
  • Sind Co-Autoren gegenwärtig erwünscht? Ja, sehr gerne.


Aufbau eines Beowulf/Diskless Clusters im Rahmen eines Praxissemesters

[Bearbeiten]

Was ist ein Beowulf Cluster?

[Bearbeiten]

Vor langer Zeit gab es in Skandinavien einen Helden namens Beowulf, der Sohn von Scyld. Wie bei Wikingern üblich, wuchs er im Kreis der Gefährten seines Vaters heran. Sie lehrten ihn die Kampfeskunst und Loyalität. Er wurde ein großer und gerechter Kämpfer, der zusammen mit seinen Freunden so manche siegreiche Schlacht führte, unter anderem auch gegen den Troll Grendel. Durch ihre Gemeinsamkeit waren sie so erfolgreich.

Das Lösen von Rechen-Problemen durch viele "normale" Computer geht im Teamwork unter Beachtung gewisser Vorbedingungen viel schneller als es vielleicht ein spezieller, teurer Spezial-Computer alleine kann. Die zweite Parallele, das Vertrauen, bezieht sich auf die Frage des Betriebssystems. Auf Beowulf-Clustern wird immer ein Open Source System (OSS) eingesetzt - Linux. Dieses ist frei benutzbar und auch die Quellen sind frei zugänglich und können gegebenenfalls geändert werden - diese Herangehensweise schafft Vertrauen bei den Anwendern (und auch bei den Verantwortlichen).

Ein Rechnerverbund auf dem zum Beispiel Windows NT installiert ist, darf nicht als Beowulf-Cluster bezeichnet werden, sondern trägt meist als Klassifikation den Namen Wulfpack.

Richtig populär wurde der Begriff Beowulf-Cluster durch die Arbeiten und Veröffentlichungen am Beowulf-Projekt des CESDIS (Center of Excellence in Space Data and Information Sciences, USA), welches wohl für den heutigen Bekanntheitsgrad dieses Namens die Hauptarbeit geleistet hat.

Per Definitionem besteht ein Beowulf-Cluster aus Hardware einer bestimmten Kategorie und natürlich aus Software, die zum Parallel-Computing notwendig ist. Die Hardware-Basis eines Beowulf-Cluster besteht aus:

  1. "Standard"-Rechnern, das können Intel-basierte PCs (oder Kompatible) oder solche mit Alpha-Architektur, aber auch Apple-Rechner (Zur Zeit noch PowerPC Architektur) sein. Jedenfalls sollte man diese "von der Stange" kaufen können.
  2. und einem Netzwerk.

Die Art der Netzwerk-Kopplung ist nicht festgelegt; üblicherweise werden Netzwerk-Komponenten eingesetzt, die für die zu lösenden Probleme das beste Preis-/Leistungsverhältnis darstellen.

Es wurde bereits gesagt, dass in einem Beowulf-Cluster immer ein freies Betriebssystem (Linux, FreeBSD o.ä.) eingesetzt wird. Die verwendete Anwendungssoftware sollte aber auch nicht kommerziell sein, sondern den Open Source Software-Kriterien genügen. Damit kann das Cluster als Ganzes als freies System betrachtet werden. Man kann ein Cluster auch als einen virtuellen Rechner ansehen. So etwas wird z.B. mit der Software MOSIX der Hebräischen Universität von Jerusalem versucht.

Bei der Programmierung von Anwendungen, die auf mehrere Rechner verteilt laufen sollen, muss natürlich auch der Datenaustausch zwischen den Teilprogrammen vorgesehen und programmiert werden. Dafür können standardisierte Bibliotheken genutzt werden, die eine abstrakte Kommunikationsschnittstelle zur Verfügung stellen. Im Idealfall ist diese sogar plattformunabhängig, d.h. die Kommunikation kann zwischen Prozessen auf verschiedenen Rechnern mit unterschiedlichen Plattformen ablaufen. Die bekanntesten Vertreter solcher Bibliotheken sind Message Passing Interface (MPI) und Parallel Virtual Machine (PVM).

Nun zurück zum Beowulf. Ein Cluster besteht aus einer gewissen Anzahl von Rechen-Knoten (compute nodes), einem oder mehreren Server-Knoten (server node) und in der Regel aus einem (oder mehreren) Zugangs-Knoten (front end), auf dem bzw. denen sich die Nutzer einloggen können. Von dort aus können sie sich die benötigte Menge von Rechen-Knoten für ihre Arbeit (Auftrag) reservieren und diese benutzen. Die Rechen-Knoten sind nur durch das Netz mit der "Außenwelt" verbunden und benötigen dementsprechend keinerlei Ein- oder Ausgabe-Peripherie wie Tastatur, Maus oder Bildschirm. Soll der Zugangsknoten auch zur Softwareentwicklung benutzt werden dürfen, muss eine entsprechende Entwicklungsumgebung (Compiler, Debugger usw.) dort bereitgestellt werden.


Damit können wir nun zusammenfassen und die Eingangsfrage beantworten: Was ist ein Beowulf?

  • Es ist ein Hoch-Leistungs-Parallel-Rechner.
  • Es besteht aus Standard-Hardware (PCs).
  • Es arbeitet mit einem freien Betriebssystem (z.B. GNU-Linux).
  • Es stellt freie Software für die Nutzer zur Verfügung.
  • Es besitzt eine Umgebung für Parallel-Programme (Kommunikationsschnittstelle).
  • Es verfügt über eine Parallele Programmierumgebung.
  • Es ist in der Regel nur remote erreichbar.
  • Es kann als virtueller Rechner mit vielen CPUs betrachtet werden.
  • Es ist durch die Art der installierten Software für Parallel-Computing optimiert.

Unsere Hardware

[Bearbeiten]

5 Knoten mit jeweils:

  • Shuttle AK32VN Mainboard
  • 256 MB Infinion DDR RAM
  • Onboard Via Rhine LAN Controller
  • PCI Grafikkarten

einer der Knoten dient als Server und hat daher

  • 120GB Festplatte
  • 20 fach CD-Rom


Wichtiger Hinweis zur Hardware

[Bearbeiten]

Wenn man einen Cluster bauen will, sollten folgende Punkte bei der Hardwarewahl unbedingt beachtet werden.

  • Vergewissern Sie sich, dass die Netzwerkkarten voll PXE-tauglich sind. Die Onboard-Controller auf unseren Shuttleboards machen sehr starke Probleme. Wer auf Nummer sicher gehen will, erwägt eine 3Com Karte.
  • Von großem Vorteil sind Onboard-Grafikkarten, da ein Rechner nicht ohne Weiteres ohne eine Grafikkarte booten kann (es muss allerdings kein Monitor angeschlossen sein). Um einen Rechner ohne Grafikkarte betreiben zu können, sind zumeist Änderungen im BIOS nötig. Nicht jedes Mainboard unterstützt dies jedoch.

benötigte Software

[Bearbeiten]
  • DHCP Server
  • TFTP Server
  • Kernel Source
  • rsync
  • syslinux
  • LAM/MPI


Der Kernel für die Knoten

[Bearbeiten]

Für die Knoten muss der Kernel leicht angepasst werden.

Dafür benutzen wir den make Befehl.

Der Sourcecode des Kernels muss dafür installiert sein. Danach gehen wir in das Verzeichnis /usr/src/linux Mit

  • %make menuconfig

ruft man das Menü zum Editieren des Kernels auf. Dort müssen die Netzwerkkartentreiber fest integriert werden (also nicht als Modul). Wenn dies geschehen ist können wir das Menü verlassen. Nun muss noch überprüft werden, ob folgende Flags in der .config gesetzt sind: 

CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
CONFIG_IP_PNP_BOOT=y
CONFIG_IP_PNP_RARP=y
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
CONFIG_ROOT_NFS=y

nun können wir mit

  • make dep
  • make clean
  • make bzImage
  • make modules
  • make modules_install

den Kernel neu kompilieren.

Danach wird mit

  • cp /usr/src/linux/arch/i386/boot/bzImage /boot/

der neue Kernel in das Bootverzeichnis kopiert. Dort ist ein symbolischer vmlinuz mit

  • ls -la vmlinuz

kann man sehen auf welchen Kernel er zeigt. Wir ändern mit

  • cd /boot/
  • rm vmlinuz
  • ln -s bzImage vmlinuz

den link auf unseren neuen Kernel.

Wenn dies erledigt ist können wir uns dem Server zuwenden.

Der Server

[Bearbeiten]

Nun brauchen wir ein Verzeichnis von dem sich später die Knoten den Kernel holen können. Wir haben uns für /tftpboot entschienden. Dorthin wird das oben erstellte bzImage hinkopiert.

mit

  • mkdir /tftpboot/slave1

legen wir dann noch ein Verzeichnis für den ersten Knoten an. In dem Verzeichnis kommt jetzt sein Rootverzeichnis von dem er später Programme wie die Bash starten kann.

Mit rsync kann man verzeichnisse kopieren ohne ihre Rechte oder Benutzereigenschaften anzufassen. So kopieren wir die wichtigsten Verzeichnisse für unseren Knoten:

  • rsync -avz /etc /tftpboot/slave1/etc
  • rsync -avz /bin /tftpbootut/slave1/bin
  • rsync -avz /sbin /tftpboot/slave1/sbin
  • rsync -avz /lib /tftpboot/slave1/lib
  • rsync -avz /dev /tftpboot/slave1/dev
  • rsync -avz /var /tftpboot/slave1/var
  • rsync -avz /usr /tftpboot/slave1/usr

Nun erstellen wir noch schnell die restlichen, für jeden Knoten wichtigen, Verzeichnisse.

  • mkdir /tftpboot/slave1/home
  • mkdir /tftpboot/slave1/proc
  • mkdir /tftpboot/slave1/tmp
  • mkdir /tftpboot/slave1/root
  • mkdir /tftpboot/slave1/opt

Alle anderen Verzeichnisse (opt, usr, home) werden später nur Read-only freigegeben und von den Knoten gemountet. Alle Knoten teilen sich diese Verzeichnisse.


DHCP Server

[Bearbeiten]

Der DHCP Server ist der erste Kontakt des Knotens wenn dieser bootet. Vom DHCP Server erfährt der Knoten z.B. welche IP für ihn zugedacht ist.

Zum Aufsetzen des DHCP Servers muss man die /etc/dhcpd.conf editieren. Unter Suse muss man darauf achten, dass Yast die Konfiguration nicht überschreibt, da der DHCP Server stark mit Yast verknüpft ist. 

authoritative ;
ddns-update-style ad-hoc;
ddns-updates off;
default-lease-time 86400;
filename "pxelinux.0";
log-facility local7;
max-lease-time 86400;
option routers 192.168.0.1;

subnet 192.168.0.0 netmask 255.255.255.0 {
   option domain-name "beowulf";
   option domain-name-servers 192.168.0.1;
   option routers 192.168.0.1;
   range 192.168.0.100 192.168.0.250;
}

host slave1 {
   fixed-address 192.168.0.2;
   hardware ethernet 00:01:02:07:b7:d3;
   option host-name "slave1";
   option root-path "/tftpboot/slave1";
}

der DHCP Server kann dann mit /etc/init.d/dhcpd restart gestartet werden.

TFTP Server

[Bearbeiten]

Der TFTP Server ermöglicht es dem Knoten den Kernel zu starten. Am schnellsten geht die Konfiguration in Yast.

  • TFTP Starten aktivieren.
  • Das Startverzeichnis auf /mnt/nfs ändern.

Syslinux bzw. Pxelinux

[Bearbeiten]

In dem Paket "Syslinux" ist auch eine Datei namens pxelinux.0. Diese wird vom Boot-Rom der Netzwerkkarte gebraucht. dazu kopieren wir die Datei mit

  • cp /usr/lib/syslinux/pxelinux.0 /tftpboot

in unser Verzeichnis für die Knoten. Danach brauchen wir noch das Verzeichnis

  • mkdir /tftpboot/pxelinux.cfg

Als allgemeine Startdatei muss in dem Verzeichnis noch eine Datei namens default angelegt werden. Ihr Inhalt ist folgendermaßen. 

#So kann eine default Datei zum Beispiel aussehen
DEFAULT bzImage init=/sbin/init rw ip=dhcp root=/dev/nfs

NFS Server

[Bearbeiten]

Der NFS Server sorgt dafür, dass die Knoten ihr Rootverzeichnis finden und es benutzen können. Dafür müssen wir in der /etc/exports der SERVERS folgende Änderungen durchführen: 

#Beispiel für eine /etc/exports des Servers
/tftpboot/slave1        192.168.0.2(sync,rw,no_root_squash,no_all_squash)
/tftpboot/share/opt     *(sync,ro,no_root_squash,no_all_squash)
/tftpboot/share/home    *(sync,rw,no_root_squash,no_all_squash)

Die /tftpboot/slave1/etc/fstab sieht so aus: 

#Beispiel für eine fstab der Clients
devpts                           /dev/pts    devpts  mode=0620,gid=5                                 0 0
proc                             /proc       proc    defaults                                        0 0
192.168.0.1:/tftpboot/slave1     /           nfs     sync,hard,intr,rw,nolock,rsize=8192,wsize=8192  0 0
192.168.0.1:/tftpboot/opt        /opt        nfs     sync,hard,intr,ro,nolock,rsize=8192,wsize=8192  0 0
192.168.0.1:/tftpboot/home       /home       nfs     sync,hard,intr,rw,nolock,rsize=8192,wsize=8192  0 0

mit

  • /etc/init.d/nfsserver restart

kann der NFS Server dann gestartet werden.

Abschließende Änderungen für die Clients

[Bearbeiten]

Ein paar Sachen (bedingt durch das Kopieren der Verzeichnisse für die Knoten) müssen noch geändert werden um den Knoten richtig laufen zu lassen.

Die /tftpboot/slave1/ect/HOSTNAME muss noch abgeändert werden und in unserem Fall slave1.local eingetragen werden

Auch muss in der /tftpboot/slave1/etc/sysconfig/network/ifcfg-eth0 noch die IP des Knotens eingetragen werden.

In der /tftpboot/slave1/etc/inittab wird mit id:3:initdefault: noch das runlevel auf 3 gesetzt um das Starten der grafischen Oberfläche zu verhindern.


Den Knoten aktuell halten

[Bearbeiten]

Die Knoten sind nun lauffähig und können genutzt werden. Um diese Up-to-Date zu halten gibt es allerdings wenig Wege. Software zu installieren ist über Yast nicht möglich und bei Installation über RPM gab es bei mir teilweise Probleme. Um immer ein einheitliches Bild auf dem Cluster zu haben wird unser Cluster in regelmäßigen Abständen Synchronisiert. Dies lässt sich realisieren indem man mit rsync die Verzeichnisse /bin, /sbin, /lib"" und /usr vom Master auf die Knoten spielt. Ein einfaches Skript könnte zum Beispiel so aussehen: 

echo " Synchronisiere slave1. Bitte warten ..."
rsync -auqz /usr/ /tftpboot/slave1/usr
rsync -auqz /bin/ /tftpboot/slave1/bin
rsync -auqz /sbin/ /tftpboot/slave1/sbin
rsync -auqz /lib/ /tftpboot/slave1/lib


Auf die Knoten einloggen

[Bearbeiten]

Damit wir auf den Clients arbeiten können ohne für jeden Knoten einen Monitor und Tastatur zu benutzen benutzen wir SSH. Durch

  • ssh slave1

kann man sich auf den Knoten einloggen, wenn dieser mit dem Bootvorgang fertig ist. Allerdings benutzt ssh eine Paswortabfrage die später noch bei dem Einrichten von PVM, MPI oder OpenMosix stören kann. Dies kann man wie folgt umgehen:

Als erstes müssen wir uns mit ssh auf allen Knoten mindestens einmal eingeloggt haben.

Danach können wir mit

  • ssh-keygen -t rsa1
  • ssh-keygen -t rsa

ssh Schlüssel erstellen. WICHTIG ist, dass wir KEINE Passphrase eingeben!

Diese Schlüssel müssen nun kopiert werden. In diesem Fall wird der Schlüssel für root auf dem Rechner master benutzt

  • ssh-copy-id root@master
  • ssh-copy-id -i ~/.ssh/id_rsa.pub user@remote-system

Nun kann der Inhalt von /root/.ssh/ auf die Knoten kopiert werden.

  • cp /root/.ssh/* /tftpboot/slave1/root/.ssh/

Wenn wir uns jetzt über ssh einloggen wird nicht mehr das Passwort abgefragt.

Die Knoten starten

[Bearbeiten]

Zum Starten der Knoten benutzen wir etherwake. Nach dem Entpacken können wir es mit

  • ./configure && make && make install

in unser System einbinden.

Nun können wir mit

  • etherwake <Hardwareadresse der gewünschten Netzwerkkarte>

die Knoten starten.

Die NICs der Knoten können wir herausfinden, indem wir uns per ssh auf die Knoten einloggen und per

  • ifconfig

die Details der Netzwerkkarten anzeigen lassen.

Zu beachten ist, dass zwischen einem Herunterfahren und Neustarten eines Knoten mindestens 2 Minuten Zeit gelassen werden müssen, da es ansonsten nicht funktioniert.

LAM/MPI einrichten

[Bearbeiten]

LAM (Local Area Multicomputer) ist eine MPI Programmier-Umgebung und ein Entwicklungssystem für Computer in einem Netzwerk. Mit LAM kann man aus einem Cluster oder einem Netzwerk von Rechnern einen virtuellen Parallel-Computer bauen, um Rechenprobleme zu lösen, die eine Paralle-Anwendung erfordern.

LAM/MPI unterstützt die Programmiersprachen

  • C/C
  • Fortran

LAM/MPI kann man sich auf www.lam-mpi.org besorgen.

Die Installation geht folgendermaßen vonstatten:

  • tar xzf lam-X.Y.Z.tar.gz
  • cd lam-X.Y.Z
  • ./configure --prefix=<InstallationsVerzeichnis> --with-rpi=tcp
  • make
  • make install

Die Option '--with-rpi=tcp' stellt sicher, dass kein gemeinsamer Speicher benutzt wird. So können die Prozesse richtig verteilt werden.

Bevor man LAM/MPI startet muss noch ein Hostfile angelegt werden.

  • vi /home/benutzer/hostfile.mpi

In dieser werden nun alle Rechner geschrieben die im Cluster/Netzwerk sind. 

#Dies ist eine Beispiel für ein Netzwerk
master
node1
node2
node3
#u.s.w.

Bei Clustern die auf OpenMosix basieren muss nur der Server mit der Anzahl der insgesamten Prozessesoren des Clusters hinzugefügt werden werden 

#Die ist eine OpenMosix Konfiguration
master cpu=<Anzahl der Rechner im Cluster>

Zum Start von LAM/MPI gibt man

  • lamboot -v hostfile.mpi

ein.

Nun kann man zum Beispiel seine C Programme folgendermaßen kompilieren.

  • mpicc -o test test.c

Ausgeführt werden dann die Programme mit

  • mpirun -np <Anzahl der Rechner> test

Komplett beendet wird LAM mit

  • lamhalt

ClusterKnoppix

[Bearbeiten]

Anschließend haben wir noch ClusterKnoppix ausprobiert, bzw. eine remasterte Version namens Quantian
Dabei haben wir uns an diese Anleitung gehalten. Bemerkenswerterweise hat ClusterKnoppix keine Probleme mit den OnBoard Netzwerkkarten.

Aktuelle Probleme und Sonstiges

[Bearbeiten]

PVM kann leider auf einen OpenMosix System nach meinem Erkenntnisstand nicht zum Laufen gebracht werden

Das Installationsskript für Clusterknoppix 3.4 und höher ist nicht wie in der Anleitung /usr/local/bin/knx-hdinstall sondern /KNOPPIX/usr/sbin/knx2hd.

Ab und zu vergißt ClusterKnoppix unsere Einstellungen nach einem Neustart. Dann muss die /etc/network/interfaces überprüft werden, openMosix neugestartet und der Knoppix Terminal openMosix Server erneut eingerichtet werden.

Leider ist mit ClusterKnoppix 3.4 keine DMA Unterstützung möglich. Sie lässt sich zwar mit

  • hdparm -c1 /dev/hda
  • hdparm -d1 /dev/hda

nachträglich aktivieren, aber

  1. stirbt das System total ab wenn man von CD auf Festplatte installieren will
  2. bringt es gefühlsmäßig nicht viel

Wer sein (Cluster)Knoppix / Debian System mit apt-get auf dem neuesten Stand halten und trotzdem nicht auf einen Proxy verzichten kann oder mag, muss die Umgebungsvariablen für http und ftp Zugriff setzten.

Zum Beispiel:

  • export http_proxy=http://proxy.url.de:3128
  • export ftp_proxy=http://proxy.url.de:3128

Somit kann man sich zum Beispiel mit

  • apt-get install g77

bequem den Fortran Compiler g77 besorgen, den man zur Installation von LAM/MPI benötigt, wenn man ClusterKnoppix 3.3 oder 3.4 benutzt.

Die NICs der einzelnen Knoten wurden per Skript zusammengefasst um ein Starten mit etherwake zu vereinfachen.

Abgerufen von „https://de.wikibooks.org/w/index.php?title=Beowulf&oldid=944421“