|
Projekt Mosix Cluster
Autor: Philip Schaller
|
Einleitung |
|
|
Für die Zeit von etwa 1- 2 Monate suchte ich ein spannendes Projekt. Da mich Linux schon
lange interessiert hat, ich jedoch noch nie richtig damit arbeiten konnte, suchte ich nach
einem Linuxprojekt. Im Internet fand ich dann einige interessante Berichte über Cluster
Management Systeme, welche unter Linux laufen. Deshalb entschied ich mich für dieses Thema.
Als Hardware für das Projekt wurden vier Compaq DP4000, ein Hub und die dazugehörenden
Kabel genommen. Bei der Software entschied ich mich wie gesagt für Linux (Red Hat 7.1)
und als Clustersoftware MOSIX. Auf die Software werde ich später noch etwas genauer
beschreiben. Im Voraus erstellte ich jedoch einen Plan, wie das ganze einmal aussehen
und funktionieren sollte:
Bevor ich aber die Installation und Konfiguration der Cluster erkläre, möchte ich gerne
etwas allgemeines über Cluster erklären.
|
|
Cluster |
|
|
Ein Cluster ist ein Multiprozessorsystem, mit dessen Hilfe sich insbesondere Hochverfügbarkeitslösungen
und rechenintensive Datenverarbeitung skalierbar und kostengünstig realisieren lassen. Skalierbarkeit ist
die Eigenschaft eines Rechners, die Gesamtrechenleistung des Systems möglichst flexibel an eine
Aufgabenstellung anzupassen. Der Cluster besteht aus miteinander vernetzten Stand- Alone Computern,
welche als Knoten bezeichnet werden. Die Knoten des Clusters können aus einem oder mehreren Prozessoren
bestehen und sind über ein schnelles Netzwerk miteinander verbunden. Mittlerweile sind ca. 50 % der
weltweit schnellsten Rechner Cluster-Systeme (http://www.top500.org).
Linux- Cluster zeichnen sich durch ein hervorragendes Preis-/ Leistungsverhältnis aus, da sie auf einem
sehr stabilen, freien und kostenlosen Betriebssystem basieren. Die Rechenleistung läßt sich durch einen
modularen Hardwareaufbau sehr gut skalieren, so sind Cluster aus beispielsweise 1024 Knoten technisch
durchaus realisierbar. Dadurch läßt sich eine hohe Ausfallsicherheit erzielen. Für Linux- Cluster steht
ein großes Angebot an freier, parallelisierter Software zur Verfügung.
Anwendung
Typische Anwendungsbeispiele für den Einsatz von Clustern sind rechenintensive Applikationen, welche die Rechenkapazität
einer Ein- oder Zweiprozessormaschine überfordern.
Im technisch- wissenschaftlichen Bereich sind dies Simulationen aller Art, Messdatenakquirierung, -vorverarbeitung und
-auswertung, sowie Datenfilterung, -verschlüsselung, -kodierung und -komprimierung.
Die auf Interaktivität basierende Virtual Reality wird um so realistischer, je schneller und intelligenter der Rechner
reagiert. Nur eine gelungene Aufteilung der hier entstehenden Rechenlast auf leistungsstarke Prozessorknoten kann
realitätsnahe Bilder und Filme erzeugen. Hierbei kann ausschließlich ein skalierendes System mit den ständig steigenden
Anforderungen Schritt halten, welche sich durch immer komplexere Benutzereingaben ergeben.
Wie erreicht man Hochverfügbarkeit?
Das Zauberwort im Falle der Hochverfügbarkeit heisst Redundanz, einfach gesagt: Jede Komponente,
ob Netzteil, Festplatte oder Netzwerkkarte sollte mit einem "Stellvertreter" abgesichert sein, der die Funktion der
ausgefallenen Komponente wenn nötig übernimmt.
Hat die Dienstverfügbarkeit des Clusters höchste Priorität, ist der Einsatz eines Load Balancers zu überlegen. Ein Load
Balancer nimmt eine Anfrage von einem Client (z.B. eine http-Verbindung, um eine Website herunterzuladen) an und verteilt
diese dann an einen verfügbaren Server. Dies bietet sich insbesondere bei WWW- und Mail-Diensten, Proxy- Servern, Firewalls
und ähnlichem an. Besonders gut geeignet sind Dienste, wo die einzelnen Verbindungen voneinander unabhängig sind, da die
Server im Hintergrund ja auch mehr oder weniger eigenständig arbeiten. Wenn ein Server abstürzt, werden die aktiven
Verbindungen zu diesem Server unterbrochen. Da aber auch ab sofort keine neuen Anfragen mehr an diesen Server geleitet
werden, merkt der Client z.B. beim WWW nichts außer einer kleinen Verzögerung. Wenn er auf Reload drückt, erhält er die
Seite korrekt angezeigt (die Anfrage wird von einem neuen Server beantwortet).
Load Balancing
Webfarmen oder Mailcluster lassen sich unter Linux mit Linux Virtual Server realisieren. Die einzelnen "real existierenden"
Server können untereinander entweder über LAN oder geographisch getrennt über WAN miteinander verbunden sein.
Ihnen vorgeschaltet ist ein Load Balancer, der die Last möglichst gleichmäßig über die ihm untergeordneten realen
Server verteilt. Der Parallelbertieb der Server erscheint nach außerhalb als die Leistung eines einzelnen virtuellen
Servers unter einer einzigen IP- Adresse. Bei dem Ausfall einzelner Knoten wird das System entsprechend rekonfiguriert.
|
|
Projektsoftware |
|
|
Wie schon beschrieben, wurde beim Projekt Red Hat Linux 7.1 und Mosix benutzt. Warum ich diese Software benutzt
habe und was die Vor- und Nachteile sind, werden jetzt kurz beschrieben.
Red Hat Linux 7.1
Zuerst installierte ich auf den PC Red Hat 7.2. Jedoch wurde dieses von der Cluster- Software nicht getestet, was ich
dann auch gemerkt habe. Es gab Probleme mit dem Filesystem ext3, was die Installation von Mosix nicht möglich machte.
Deshalb entschloss ich mich für Red Hat 7.1. Der Grund, dass ich Red Hat genommen habe ist, dass ich mich nicht mehr
nach der Software umschauen musste, da ich die Software schon hatte. Es wäre aber auch mit SuSE gelaufen
Mosix 1.4.0
Mosix (http://www.mosix.org) ist der Name der Cluster- Software. Ich habe diese gewählt,
weil es schon diverse erfolgreiche Tests damit gegeben hat und es eine relativ einfach Installation hat. Zur Installation gibt es
ein Script, welches selber den Kernel mit dem Mosix compiliert. Für den Überblick aller Clustersysteme gibt es den Mosixviewer
(http://www.mosixview.com). Er wird am Schluss installiert und zeigt eine graphische Übersicht über alle alle Cluster mit
diversen Einstellungsmöglichkeiten.
Mosixview 1.0
Mosixview (http://www.mosixview.com) ist eine zusätzliche Software zum Mosix. Mit Mosixview lassen sich die wichtigsten
Parameter eines Mosix- Clusters einstellen. Es ist ein graphisches Tool, welches als RPM- Paket oder als Source
heruntergeladen werden kann.
|
|
Installation und Konfiguration |
|
|
Für die Installation und Konfiguration mussten diverse Dateien editiert oder neu erstellt werden. Die nachfolgende
Dokumentation ist spezifisch auf mein Projekt, sollte jedoch durch kleinere Änderungen auch bei anderen Installationen
funktionieren.
Für die Installation von Red Hat 7.1 wird die benutzerspezifische Installation gewählt, welche die Kernel Entwicklung
integriert hat. Dies ist wichtig, dass man später den Mosix- Kernel erstellen kann. Sonst gibt es keine speziellen
Einstellungen.
Wenn die Installation erfolgreich war, dann kann mit dem herunterladen der Software und dem Kernel begonnen werden:
http://www.mosix.cs.huji.ac.il/ftps/mosix-1.4.0.tar.gz
http://www.kernel.org/pub/linux/kernel/v2.4/linux-2.4.10.tar.gz
Am Besten werden diese Sachen direkt ins Verzeichnis /usr/src kopiert. Danach kann das Mosix- Archiv entpackt werden:
tar -xzf /usr/src/mosix-1.4.0.tar.gz
In das entpackte Verzeichnis wechseln und ./mosix.install ausführen. Damit wird das Installations- Script begonnen.
Es werden nun einige lästige Fragen gestellt. Es kann dabei oft der Vorgabewert mit einem Druck auf die Enter- Taste
bestätigt werden:
Please specify the location of the plain (non-MOSIX)
Linux-$kernel_version kernel sources: it can be
either a directory, a compressed tar file
(with a .gz or .bz2 extension) or `-' to skip the kernel
installation. Linux
sources (default=/usr/src/linux-$kernel_version)
:- /usr/src/linux-2.4.10.tar.gz
Would you like the new kernel to be added to lilo [Y/n] :- Y
It is highly recommended to create symbolic links from
/usr/include to the kernel's include directory.
OK to create those links now? [Y/n] :- Y
In which run-levels to run MOSIX? (`-' for none; default=2345) :- 2345
Create an MFS mount point now [Y/n] :- Y
Which configuration method to use:
config, xconfig or menuconfig (default) :- menuconfig
Do you need to watch the kernel compilation details [y/N] :- N
Do you need to watch the user-level compilation details [y/N] :- N
Das Script entpackt nun als erstes die Kernel- Sourcen und öffnet das Configfenster. Dort können nun die Sachen
angegeben werden, welche der Kernel enthalten soll. Dabei ist es wichtig, dass beim Filesystem kein „M“ steht, da
es sonst vom Modul geladen wird (wird aber nie soweit kommen). Es muss also ein * dastehen. Mit „Exit“ kann das Menü
verlassen werden und es beginnt die Kompilation des Kernels. Die Kompilation und Installation des Kernels und der Mosix-
Kommandozeilenbefehle sollte nun problemlos vonstatten gehen. Vor dem anschliessenden Reboot ist es empfehlenswert,
noch die /etc/mosix.map anzulegen.
Befinden sich beispielsweise vier Rechner mit den IP- Adressen 192.168.1.1 bis 192.168.1.4 und dazu zwei Rechner mit
den Adressen 192.168.1.10 und 192.168.1.11 im Cluster, dann sieht die entsprechende Konfigurationsdatei /etc/mosix.map
wie folgt aus:
# | IP | Range |
1 | 192.168.1.1 | 4 |
5 | 192.168.1.10 | 2 |
Die erste Spalte gibt jeweils die Knotennummer für den Rechner mit der IP- Adresse in der zweiten Spalte an. Die dritte
Spalte verrät wieviele Rechner mit fortlaufender IP- Adresse noch zum Cluster gehört. Der Rechner mit der IP 192.168.1.11
hätte in unserem Beispiel also die Knotennummer 6.
Dieser Vorgang muss nun für jeden Konten wiederholt werden.
Wie schon vorher beschrieben, kann Mosixview direkt als RPM- Paket heruntergeladen werden. Deshalb wird die Installation
sehr einfach, es müssen jedoch noch einige Anforderungen erfüllt werden:
- QT >= 2.3.0
- root Berechtigung !
- rlogin und rsh (oder ssh) zu allen Cluster-Knoten ohne Passwort
- Die MOSIX-tools mosctl, migrate, runon, iojob, cpujob ... (sind in jeder MOSIX Distribution enthalten)
r- Kommandos
Bevor die einzelnen Cluster nun miteinander kommunizieren können, müssen noch die r- Kommandos freigeschaltet werden
(rlogin, rsh, usw.).
Standardmässig sind diese Tool deaktiviert, deshalb muss noch das RPM- Paket rsh-0.17-2.5.src.rpm von der Red Hat CD2
installiert werden. Mit dem Befehl ntsysv wird ein Programm gestartet, bei welchem man dann die Tools rsh und rlogin
aktivieren kann. Weiter sollten die Dateien /etc/xinetd.d/rlogin und /etc/xinetd.d/rsh nun etwa so aussehen:
/etc/xinetd.d/rlogin
#/etc/xinetd.d/rlogin
service login
{
disable = no
socket_type = stream
wait = no
user = root
server = /bin/mosrun
server_args = -l /usr/sbin/in.rlogind
protocol = tcp
}
/etc/xinetd.d/rsh
#/etc/xinetd.d/rsh
service shell
{
disable = no
socket_type = stream
wait = no
user = root
server = /usr/sbin/in.rshd
server_args = -L
protocol = tcp
}
Um die Änderungen vom ntsysv zu aktivieren muss der xinetd- Dienst neu gestartet werden. Dies geschieht
durch /etc/rc.d/init.d/./xinetd restart
Damit die Namenauflösung funktioniert, muss die Datei /etc/hosts folgendermassen editiert werden:
192.168.1.1 | Master |
192.168.1.3 | cluster1 |
192.168.1.4 | cluster2 |
192.168.1.5 | cluster3 |
Möchte jetzt ein Benutzer auf einen Rechner zugreifen, ohne dass er ein Passwort eingeben will, dann kann er das mit
dem rlogin- Befehl machen. Der Aufrufsyntax sieht folgendermassen aus:
rlogin [option(en)] hostname
Als Hostnamen sind alle Maschinen erlaubt, welche in der Datei /etc/hosts eingetragen sind.
Damit jetzt alle Benutzer auf eine Maschine zugreifen können, braucht es auf dem Zielrechner die Datei /etc/hosts.equiv in welcher man alle „trusted“ Rechner einträgt (Vertrauensrechner):
/etc/hosts.equiv
#/etc/hosts.equiv auf master
cluster1
cluster2
cluster3
Wenn in der Datei nur ein Pluszeichen (+) eingegeben wird, dann haben alle Benutzer
auf irgendeinem Rechner Zugriff.
Es haben jetzt jedoch alle Benutzer Zugriff, jedoch Root gehört nicht zu den normalen Benutzer. Damit bei ihm diese
r- Kommandos funktionieren (was beim Mosix nötig ist), müssen nochmals zwei Dateien editiert werden. Es sind die
Dateien /root/.rhosts und /etc/securetty.
/root/.rhosts
#.rhosts auf master
cluster1 root
cluster2 root
cluster3 root
/etc/securetty
#/etc/securetty auf master
..
..
rsh
rlogin
Bei der Datei /etc/securetty müssen die zwei Einträge unten hinzugefügt werden. Ich weiss nicht, ob diese Datei Red Hat
spezifisch sind und sie bei anderen Versionen gleich heissen.
Nach einem Reboot sollten die Befehle nun auch für den Root brauchbar sein und auch das Cluster- Systems sollte
funktionieren. Der Mosixviewer kann mit dem Befehl mosixview gestartet werden. Wie der Mosixviewer genau funktioniert
kann unter http://www.mosixviewer.com nachgelesen werden.
|
|
Schlusswort |
|
|
Die Informationen über Cluster – Allgemein habe ich zum Teil aus dem Internet geholt. Die Installation und Konfiguration
habe ich jedoch selber durchgeführt und dokumentiert. Es heisst aber nicht, dass es so auch immer funktioniert, was in der
Informatik noch oft so ist! ;-)
|
|