Beowulf cluster: Unterschied zwischen den Versionen
Rcerny (Diskussion | Beiträge) |
Rcerny (Diskussion | Beiträge) |
||
Zeile 40: | Zeile 40: | ||
Auf dem Master und den Nodes wird das selbe OS laufen, der einfachheithalber und um den Wartungsaufwand niedrig zu halten. | Auf dem Master und den Nodes wird das selbe OS laufen, der einfachheithalber und um den Wartungsaufwand niedrig zu halten. | ||
<small><small>Anmerkung des Autors: Wenn das ganze läuft könnte man sich überlegen gentoo einzusetzen, da man dann das cluster zum kompilieren nutzen kann ;)</small></small> | <small><small>Anmerkung des Autors: Wenn das ganze läuft könnte man sich überlegen gentoo einzusetzen, da man dann das cluster zum kompilieren nutzen kann ;)</small></small> | ||
+ | |||
+ | Softwarevorschläge, Notizen: | ||
+ | * sinfo, top ähnliches tool für cluster | ||
== Hardware == | == Hardware == |
Aktuelle Version vom 9. Juni 2018, 16:31 Uhr
Einleitung
Als Einleitung hier kurz eine Beschreibung was ein Beowulf cluster auszeichnet:
- The nodes are dedicated to the beowulf cluster.
- The network on which the nodes reside are dedicated to the beowulf cluster.
- The nodes are Mass Market Commercial-Off-The-Shelf (M2COTS) computers.
- The network is also a COTS entity.
- The nodes all run open source software.
- The resulting cluster is used for High Performance Computing (HPC).
Wie man sieht ist nicht all zu viel nötig um etwas zu bauen das als Beowulf cluster zählt ;)
Ziele
Ziel des Projekts ist in erster Linie um Erfahrungen zu sammeln, vorallem wie man ein dynamisches cluster aufbaut/konfiguriert und auch anwendet und verwaltet. Das ganze soll auch nicht einfach nur ein Projekt ohne sinnvollem Nutzen sein. Auch wenn unter Umständen solch ein cluster durch 1-2 Leistungsstarke und top moderne Computer ersetzt oder sogar übertrumpft werden könnte, kann man trotzallem noch sinnvolle Dinge mit z.T zu schwacher Hardware für ihre ursprüngliche Anwendung (siehe funktionelles recycling) erledigen.
Als klar definierte "subziele" sei genannt:
- Das Cluster ist fähig distcc zu nutzen
- Das Cluster ist fähig Berechnungen für verschiedene BOINC Projekte durchzuführen
- Das Cluster ist komplett dynamisch, daher sollte man random COTS Computer anschliessen können um die Rechenleistung des Clusters zu erhöhen ohne die Konfiguration gross zu ändern
- <insert other ideas>
Die Theorie
Das ganze funktioniert vom Prinzip her ähnlich wie ein LTSP System, einfach verkehrt herum. Bei einem LTSP System sind die Clients simple I/O Terminals und die Rechenaufgabe übernimmt der LTSP Server. Bei einem Beowulf cluster übernimmt der Server die Rolle des I/O Terminals und die Clients das Rechnen.
Da diese beiden Usecases sehr ähnlich in Aufbau und Struktur sind, liegt es nahe diese auch ähnlich aufzubauen. Konkret bedeutet dass das man ebenso wie bei einem LTSP System ähnliche Software einsetzen kann und tut, genannt sei hier:
- DHCP Server + TFTP Server
- Clients Booten per PXE
- Images der Clients liegen auf dem Server
Software
Ab hier werde ich die Nomenklatur festlegen und benennen:
- Der Server ist der/die Master/Master-Node
- Die Clients sind Nodes
OS
Als OS habe ich vor Arch Linux zu verwenden. Gründe hierfür sind vorallem die aktuelle Software, die Schlichtheit des Systems und die schon vorhandenen Tools. Ebenso setze ich Arch Linux seit Jahren selbst ein. Auf dem Master und den Nodes wird das selbe OS laufen, der einfachheithalber und um den Wartungsaufwand niedrig zu halten. Anmerkung des Autors: Wenn das ganze läuft könnte man sich überlegen gentoo einzusetzen, da man dann das cluster zum kompilieren nutzen kann ;)
Softwarevorschläge, Notizen:
- sinfo, top ähnliches tool für cluster
Hardware
Master-Node
Der Master braucht nicht viel an Rechenleistung oder Auststattung, der Vollständigkeit halber erwähne ich zwar das man den Master mit einbinden könnte in das Cluster. Der Einfachheit halber werde ich das aber vorläufig noch nicht tun. Als Anhaltspunkte hier ein paar Systemvorraussetzungen und Gedanken/Meinungen dazu:
- Random Prozessor mit mehr als einem Kern (Ich will ja nicht Mittagspause machen müssen nur weil ich mal eben ein Paket baue)
- So viel RAM wie man nur reinstecken kann und unterstützt wird (die Images/homes/usw. der Nodes werde ich in einer ramdisk halten, dadurch läuft alles schnell und man braucht keine SSD's)
- min. 2 Festplatten (160GB SATAII platten z.b) im Raid 1 (Könnte man drauf verzichten, wäre aber trotzdem doof wenn eine Platte hobs geht)
- GBit Schnittstelle (Falls nötig mehrere, für mehrere Netze oder für bonding, falls der Durschsatz problematisch wird)
- Random anderes Zeugs (Grafikchip sollte vorhanden sein ;) USB, etc)
Nodes
Als Hardware könnte man so gut wie alles was x86 Architektur und PXE Booteigenschaften hat einsetzen (betrifft so gut wie jeden Computer/Laptop/Server der in den letzten 20-25 Jahren auf dem Markt erschienen ist) Um das ganze doch ein wenig überschaubar (und das Stromnetz nicht zu überlasten mit P4 Heizungen) zu halten und um den anfänglichen Konfigurationsaufwand niedrig zu halten habe ich mich entschieden Thinclients zu verwenden. Im speziellen diese hier. Die sind relativ Stromsparend und sind ziemlich gut für den Zweck ausgerüstet (Single Core 1GHz VIA C7 32bit Prozessor, 512MB RAM, GBit Ethernet). Eventuell sollte/müsste man den Arbeitsspeicher aufrüsten auf 1GB. Diese ThinClients sind klein, Energiesparend und Lüfterlos. Leider wurde diese effizienz durch einen einfachen CPU Core erkauft und gewissen Instruktionen kann er nicht so effizient wie z.B ein PIII umsetzen. Aber hier geht es weniger darum das beste hinzukriegen sondern zu lernen (abgesehen davon könnte man danach sämtliche Nodes durch welche mit i7 Octacore Kisten ersetzen, ich sagte ja "dynamisch" ^^).
Netzwerk
Für das Netzwerk werden Handelsübliche GBit Switches angewendet, die brauchen auch keine speziellen Features, schön wäre natürlich Lüfterlos, und viele Ports ;)
coming soon
Mal schauen wann ich die Zeit habe das ganze umzusetzen. Der ganze Prozess wird hier natürlich Dokumentiert ;)