Kurze Einführung:

Um einen Xgrid Rechnerverbund (Cluster) zu installieren benötigt ihr drei Komponenten:

- Xgrid Controller

- Xgrid Client

- Xgrid Agent

Der Controller verwaltet den Cluster, auf dem Client läuft das Programm, welches die Clusterressourcen anfordert und die Agenten sind auf jedem Knoten im Cluster (also jedem Rechner) installiert und nehmen die Aufträge entgegen.

Die Agenten sind in jeder MAC OS X Version ab 10.4 ( Tiger & Leopard) bereits installiert - müssen nur noch aktiviert werden (Für Panther also 10.3 gibt es einen Agenten per download). Der Controller lässt sich auch über das Terminal bzw. externe Software aktivieren und managen. GUI - Clientsoftware muss Xgrid Support anbieten, im Terminal laufen, es muss einen Workarround geben bzw. müsst ihr eure eigenen Programme entsprechend anpassen.

Info: Es gibt Probleme, wenn ihr im Cluster sowohl Tiger als auch Leopard betreibt. In diesem Fall muss der Controller auf einem Rechner mit 10.4.X (Tiger) installiert sein! So können auch 10.5 Agenten darauf zugreifen. Läuft der Controller auf 10.5, dann kann Tiger nicht den Controller benutzen. Grund: Leopard nutzt mit Xgrid 2 eine neue Xgrid Version -> die Agenten sind abwärtskompatibel .. 10.4 Agenten aber natürlich nicht aufwärtskompatibel zu Leopard Xgrid 2 Controller. (Gilt für 10.5 Beta! - News bitte an mich!)

Schritt eins: Aktivieren eines Controllers:

Natürlich geht alles in der OSX Server-Version, leichter aber wer hat die schon!? Der Controller lässt sich ganz einfach über das Tool "Xgrid Lite" installieren und konfigurieren:

Die Software findet ihr hier: http://edbaskerville.com/software/xgridlite/

Nach der Installation und dem Reboot findet ihr das Menü in den „Systemeinstellungen -> Xgridlite“ ohne Reboot :) unter „$root/Library/preferencepane/xgridlite“

Sicherheit: Setzt hier falls gewünscht ein Password und startet den Controller ... That's it ... Xgrid verwendet eine vollwertige Zwei-Wege Authentifizierung (client-controller und controller-agent) aber auch Authentifizierung über Kerberos und Directory Services. Nicht vergessen, die Passwörter dann am Client und/oder am Agenten zu konfigurieren!!!

Alternativ geht es auch ohne Xgrid Lite ganz einfach im Terminal über:

sudo xgridctl controller start  (bzw. stop oder status)

Schaut nun, ob ihr irgendwelche Firewalls laufen habt und gebt Xgrid eventuell frei ... Der einzige offene Port, der benötigt wird, ist der des Controller auf Port 4111 !!!

Schritt zwei: Aktivieren der Agenten

Unter Mac OS X: Ganz einfach: In den Systemeinstellungen unter "Sharing" Xgrid aktivieren und konfigurieren.

Sprich: Passwörter setzen und angeben, ob der Agent immer zur Verfügung stehen soll oder nur wenn alle Ressourcen frei sind (Computer inaktiv ist). Ihr könnt entscheiden, ob ihr einen festen Controller nutzen wollt (wenn aktiviert - steht er zur Auswahl) oder ob der jeweils erste Controller automatisch Zugriff bekommt. Möglichkeit Zwei ist natürlich einfacher, da ihr nicht immer an jedem Agenten alles umkonfigurieren müsst, wenn sich der Controller oder dessen Name ändert. Apropos Name: Der Name, mit dem Controller und Agenten sich identifizieren, ist der Name, den ihr unter "Sharing" für den Rechner definiert habt.

Unter Windows & Unix (Linux): Vier Möglichkeiten:

- 1. Java Agent installieren (Alle OS)

- 2. Unix Agent (Nur Unix und Linux)

- 3. Mac OS über Vmware oder anderer Virtualisierung installieren

- 4. Mac OS nativ auf Intel oder AMD mit SSE2 installieren (verboten!!)

1. Java Agent: Ganz einfach hier das Java Programm herunter laden und per Terminal/Kommandozeile starten (benötigt Sun Java Environment JRE -> gibt es hier, falls nicht schon installiert)

ausführen mit:

java -jar xgridagent.jar [CONTOLLER-IP] [HOSTNAME] [FREQUENZ-CPU]

Controller-IP ist die IP eures Controllers, Hostname der, den der Agent führen soll und Frequenz - die der CPU auf dem Agenten.

2. Unix Agent: Sourcen und Pakete herunter laden und kompilieren. Siehe dazu die komplette Anleitung hier. Das ganze ist etwas komplizierter und benötigt einen Compiler (Falls nicht Pre-compiliert verfügbar) und viel, viel Zeit im Terminal.

Hinweis: Es funktioniert  - ist jedoch etwas anspruchsvoller als die anderen Methoden. Wenn ihr nicht soviel Zeit investieren wollt, dann würde ich auch wirklich den Java-Agenten (oben) empfehlen.

3.OSX PC virtuell: Natürlich könnt ihr auch Mac OS X auf eurem AMD/Intel PC installieren. Wie das geht findet ihr im Netz. Entweder ihr nutzt eine Virtualisierungsumgebung wie VMware oder Parallels - was allerdings eine schlechte Performance nach sich zieht (Mittlerweile jedoch wenigstens eine legale Alternative, sofern ihr über eine original Version des OS X Betriebssystems verfügt)

4. OSX PC nativ: Verboten - aber sicherlich schneller ist es, Mac OSX nativ zu installieren. Geht sofern die PC-CPU zumindest SSE2 unterstützt. Dazu benötigt man jedoch illegale Tools bzw. gehackte Installations - DVD's. Es ist natürlich verboten bei entsprechenden Orten und Torrents im Internet nach „JAS“ zu suchen und diese Images herunter zu laden!

Nun, wie ihr seht, könnt ihr durchaus ein Loch in euer Boot bohren, damit das Wasser abfließt - oder einfach nur noch Apple Rechner kaufen :) Ich will hier natürlich keine Werbung für MAC OS 10 und Apple Systeme machen - aber Xgrid zeigt einmal mehr, wie leicht Cluster zu installieren sein können. Sicher, es gibt auch durchaus Kritik an OS X und Apple zu üben, aber wer einmal Cluster unter anderem Betriebssystem in Betrieb genommen hat, wird mir zustimmen ...

Ist alles soweit installiert, ladet euch bitte noch die Perlen -  die "Mac OS Server Admin Tools" herunter (kostenlos hier oder bereits in der OSX Server Version :) - diese ermöglichen weitere Konfiguration und Management des Controllers. Achtet darauf, das ihr die korrekte Version für euer OS ladet (Tiger oder Leopard) Das ist keine essentielle Software, jedoch eine ziemlich praktische!

Startet von diesen Tools jetzt bitte „Xgrid - Admin“: Jetzt den Controller definieren und alles andere ist in dieser tollen Übersicht dann selbsterklärend.

Die Agenten findet ihr im Reiter: "Agenten" - ihr seht hier, welche Rechner zur Verfügung stehen und welche nicht - also freie Ressourcen haben, oder besetzt sind bzw. nicht am Grid angemeldet sind. Unter „Sharing (Preferences) -> Xgrid -> Konfigurieren“ könnt ihr wie schon oben erwähnt entscheiden, ob ein Agent:

1. -immer einen Job annimmt
   

2. -nur Job annimmt wenn Computer inaktiv ist; also „frei“ ist
   

Als Alternativ für den Xgrid Admin gibt es hier auch wieder ein Terminal-Programm vom Stanford Projekt > „xgridstatus“. Mehr dazu auf der ausführlichen Seite des Projektes ... usage:

xgridstatus [ [-h hostname] [-p password | -k password] ]* [-r interval] [-o file] [-abcgjlstvxAJT]

So, jetzt ist ein guter Zeitpunkt für eine Pause gekommen; sollte etwas nicht funktionieren, benötigt ihr nämlich einen klaren Kopf ... Trinkt also erstmal eine Tasse Kaffee etc.

Schritt 3: Den Cluster nutzen :)

Wenn ihr eigene Programme schreiben wollt, dann informiert euch bitte über das Jobmanagement im Internet. Gute Anleitungen und Tools für C++, Ruby [2], Python oder Perl sind mir bekannt. Es gibt ganz gute Frameworks wie die XgridFoundation API oder das GridEZ von Stanford.

Teilweise ist auch möglich, dass die GUI Software, die ihr nutzt, keinen Xgrid Support stellt - bzw. ihr ihn erst konfigurieren müsst z.B. bei Photoshop). In der Regel lassen sich Programme, die im Terminal laufen über Xgrid beschleunigen. Allerdings gibt es Ausnahmen, wenn das Programm:

1. -Spezielle Installationen oder Lizenzen auf mehreren Nodes benötigt
   

2. -ein unmittelbares User - Homeverzeichniss benötigt
   

- z.B. direkte Netzwerkressourcen benötigt

Läuft ein Programm in der GUI, dann kann nur der Entwickler selbst den Xgrid Support aktivieren. ABER: Für gängige Programme gibt es oft einen Workarround!!!

Prinzipiell muss die Software für ein paralleles Arbeiten konstruiert, also „parallelisierbar“ sein. Das gehört zum Grundverständnis, wenn ihr mit Xgrid arbeiten wollt. Natürlich kann es auch von Vorteil sein, wenn ihr nicht parallelisierbare Daten über des Grid bearbeiten wollt. Die ist zum Beispiel der Fall, wenn ihr die Bearbeitung eines Job mehrfach mit unterschiedlichen Laufbedingungen bzw. Startvariablen laufen lassen wollt. Ein gutes Beispiel dafür ist Audio-Grabbing. Der Umwandlungs-Job von Audio-Daten in das mp3 Format ist schlecht zu splitten, jedoch könnt ihr über das Grid durchaus mehrere Audio Dateien gleichzeitig gabben - was natürlich den Bearbeitungs- und Zeitaufwand im Vergleich zu einem einzelnen Rechner erheblich reduzieren kann. Ein gutes Beispiel für schlechte Parallelisierbarkeit sind Fourier-Reihen oder Fibonacci-Reihen ... diese sind typisch sequentiell zu zerlegen und daher schlecht über ein Grid abzubilden

Aber auch dazu findet ihr im Einzelfall im Netz zahlreiche weitere Anleitungen. Für einen schnellen Test des Grids könnt ihr zum Beispiel „VisualHub“ installieren und einmal ein paar Videos rippen ...

Die Abhängigkeit des Grids von einer guten der Netzwerkperformance versteht sich von selbst. Gigabit-Ethernet sollte den Ansprüchen in der Regel voll genügen. Prinzipiell ist jedoch jede Kabelverbindung einer WLAN-Connection vor zu ziehen.

Je nach Job, müssen unter Umständen sehr große Datenmengen über das Netzwerk geschaufelt werden!! In speziellen Fällen bei z.B. Grabbing oder speziellen Workarrounds werden gar ganze Audio/Video-Files oder komplette Programme über das Netzwerk übertragen!

Wenn ihr nun einzelne Jobs an den Controller senden wollte, so könnt ihr dies natürlich wieder über das Terminal mit Xgrid (MANpage hier) machen (müsst ihr aber nicht!):

xgrid -job run /bin/hostname (Job synchron ausführen - kurze Tests etc.)

xgrid -job submit /bin/hostname (Job asynchron ausführen)

xgrid -job attributes -id 7 (Job-Status abfragen)

xgrid -job results -id 7 (Resultat abfragen wenn Job fertig)

Multitask-Jobs:

xgrid -job submit /usr/bin/cal 3 2005 (Multitask Job starten)

xgrid -job specification -id 8 (Get Job-Spezifikationen)

xgrid -job specification -id 8 > batch.plist (Get editable p.list file*)

1. *Apple Property List File Format
   

xgrid -job batch batch.plist (Starte diesen Job-Batch)

xgrid -job results -id 10 (Resultate wieder abfragen wie oben)

Wer lieber XML Property Files mag: plutil -convert xml1 batch.plist

Um die Batch-Files zu bearbeiten gibt es auch das Tools „Xgrid batch Editor“ von Andrew Keller:

Wenn ihr mit Multitask-Jobs arbeitet, dann solltet ihr auch ein Auge auf Gridstuffer werfen. Dieses Cocoa Tool erleichtert euch die Arbeit ungemein! In diesem Zusammenhang möchte ich gleich auf das Xgrid@Stanford Projekt hinweisen ... ihr findet auf der Seite natürlich auch alle Infos und Anleitungen für Gridstuffer. Im folgenden eine Übersicht über Gridstuffer (C)

Ein weiteres Tools auf der Projektseite ist Xgrid Fuse - welches euren Controller in ein vollständiges Filesystem verwandelt. Somit ist der Zugriff auf die generierten Daten jetzt ein Kinderspiel, da sie direkt am Controller via Terminal oder Finder abgefragt werden können. Auch hier findet ihr alle Infos auf der Standford Website - die auch das Copyright (C) der Gridstuffer und Fuse Bilder hier hält:

Anmerkungen:

SSH: Ja, ihr könnt über einen Tunnel die Verbindungen über Port 4111 per SSH schalten:

ssh user@controller.hostname.com -L 4111:controller.hostname.com:4111

Ihr müsst dem Agenten oder Client in diesem Fall mitteilen, dass er den localhost (127.0.0.1) anstelle des Controllers anspricht. Um den Agenten über ssh zu tunneln geht etwa so vor:

ssh -R 2000:192.168.1.1:4111 user@192.168.1.2 /usr/libexec/xgrid/GridAgent -ServiceName localhost:2000 -RequireControllerPassword NO -UsesRendezvous NO -OnlyWhenIdle NO -BindToFirstAvailable NO

Firewall: Nochmal - sofern ihr eine Firewall betreibt gebt bitte auf allen Clients, Agenten und dem Controller unbedingt den Port 4111 frei. Wenn ihr SSH nutzen wollt, dann natürlich auch den SSH Port !!

Genzen: Xgrid unterstützt bis zu 128 Agenten, 20.000 Jobs oder 100.000 Tasks/Job. Xgrid verarbeitet bis zu 2 GB Daten pro Job und bis zu 1 GB pro abgeschlossenem Task; bei bis zu 10 GB finalen Output-Daten.

Kompatibilität: Wie beschrieben funktioniert alles ab OS X 10.4 -> sofern der Controller in gemischten Grids (10.4 & 10.5) auf einem 10.4 Rechner läuft. Leopard unterstützt keine 10.4 Agenten ... für 10.3 Panther gibt es hier einen Agenten der auch mit 10.4. Tiger Controllern läuft. In wie weit die Lösungen für Windows, Unix&Linux Agenten kompatibel sind kann ich nicht wirklich verifizieren. Bei einem 10.4. Controller liefen die vorgestellten Lösungen „problemlos“ - wie es bei einem Leopard Controller aussieht müsst ihr ggf. auf den entsprechenden Webseiten der Agenten nachschlagen.

Am Client den eigenen Agenten aktivieren? Ja ! Vor allem bei Mehr-Prozessorsystemen ist dies eindeutig von Vorteil!

So, hoffe geholfen zu haben ... Für Anmerkungen, Vorschläge, Kritik und Lob bin ich offen :) Da ich diese Anleitungen immer in meiner Freizeit schreibe, würde ich euch natürlich nochmals darum bitten, mich über einen Klick auf die Werbung am Ende der Seite zu unterstützen. Ich weiß, dass mag nerven - ist aber, so finde ich, keine große Sache. Lieben Dank!!!

(C) 2007-2009 by Janice

ad @ fr-j .com (remove spaces!)