[linux-l] Blades selbst billiger entwickeln und bauen, als die Profis es können

[Mike Dornberger]

Hi,

On Thu, Apr 06, 2006 at 11:01:41AM +1000, Peter Ross wrote:
> Ich sehe bei Dir einen leichten Konflikt zwischen verschiedenen 
> Anspruechen:
> 
> - billig
> - Einsatz von Nicht-Massenware
> - Clustering-Requirements ohne genaue Spezifikation der Anwendungen

dies ist kein leichter Konflikt, sondern ein ganz gehöriger.

> In den letzten dreisig Jahren ging die Entwicklung immer mehr davon ab, 
> speziell fuer Clustering "massgeschneiderte" Hardware zu verwenden. Bis 
> auf ganz wenige Ausnahmen basieren alle Cluster auf Massenprozessoren, und 
> mehr und mehr Clusterloesungen verwenden auch Standard-Rechner und 
> -Betriebssysteme. Linux ist dabei nicht das unueblichste;-)

Falls dem so ist, liegt es aber nicht daran, daß "maßgeschneiderte" Hardware
keinen Sinn macht sondern eher an anderen Dingen. Wie z. B. eben es muß
billig sein oder (nahezu) ganz kostenlos. Letzteres: Ausnutzen des
brachliegenden Rechenpotentials von Workstations und "Internet-PCs".

Es sieht für mich eher danach aus, als ob eher so viele Entitäten zum
"Clustering-Geschäft" hinzukommen, die sich alle keine teure Hardware
leisten können oder wollen und nicht, daß "alle" von Spezial-Hardware
abrücken, Beispiel: Japans Earth-Simulator. Prozentual gesehen verkleinert
sich natürlich der letztere Teil.

> Dabei gibt es zwei Probleme, die mir gerade einfallen:
> 1. Kommunikation zwischen den Knoten

Das ist überhaupt der allergrößte Problem bei der ganzen Geschichte. Aus
meiner Sicht - und wenn ich mich nicht irre ist diese auch die der Experten
auf dem Gebiet - packt man Hardware eigentlich nur deshalb in Cluster, weil
die momentane Technik es noch nicht erlaubt, schnellere Hardware zu bauen -
oder man das Geld dazu nicht hat.

Ich beschränke mich hier mal auf den Bereich der Cluster, die wirklich
rechnen sollen. Aber ich vermute, daß es in anderen Bereichen, wo es um
Lastausgleich geht, eigentlich genauso aussieht. Einzige Ausnahme sind wohl
Hochverfügbarkeitssysteme, aber da sind es dann eher 2-5 (gleichartige)
Systeme, die man zusammenschaltet, im Gegensatz zu den Rechen-Clustern mit
hunderten bis tausenden Knoten.

> 2. Stromverbrauch
> 
> Das Wort "leise" kommt dabei meist nicht vor, die wenigsten haben vor, 
> das in die Wohnstube zu stellen, heute wie frueher.

> 1. kann bis zu einem gewissen Grade mit herkoemmlichen Ethernet geloest 
> werden, inzwischen ist ja ein 1GBit/sec erschwinglich und haeufig auch 
> onboard. Bei VPAC hier in Melbourne (http://www.hpc.unimelb.edu.au/vpac/) 
> wird, AFAIK, Myrinet eingesetzt, das ist nicht mehr ganz so billig.

Myrinet werden sie wohl eher nicht wegen der hohen Bandbreite, sondern eher
wegen der geringen Latenzzeit des Netzes benutzen. Ethernet braucht
"Ewigkeiten", bis es mal anfängt, Datenpakete zu versenden.

Dann kommt noch der ganze Overhead hinzu, die Nutzdaten ein- und
auszupacken, bei heterogenen Netzen dann noch die Byte-Ordnung zu verändern,
Integer-Größen anpassen, etc.

> Es kommt natuerlich auch drrauf an, auf welcher Kommunikationsebene 
> Clustering geloest wird.

Clustering ist m. W. genau dahingehend vorbelegt, viele Einzelrechner
zusammenzuschalten. Du denkst wahrscheinlich gerade eher an Boards mit
mehreren CPUs oder an Multi-Core-CPUs (Stichwort SMP).

Und hier sind wir auch genau an dem Punkt, warum Clustering immer nur die
(maximal) zweitbeste Lösung ist:

(Der Einfachheit halber unterscheide ich mal nicht zwischen MIPS und FLOPS.)

- Wenn du eine CPU hast, die x MIPS schafft, möchtest du nicht einen Cycle
  davon für etwas verschwenden, was nicht direkt mit der Lösung deines
  Problems zu tun hat. Bei Clustern hast du immer Kommunikations-Overhead.
  (Und sei es nur die einmalige Aufgabenverteilung am Anfang und ggf. ein
   Stop-Signal, wenn die Lösung gefunden wurde, aber Knoten noch rechnen.)

- Nur eine bestimmte Klasse von Problemen läßt sich überhaupt effizient auf
  Clustern allgemein - und auf i386-basierten Ethernet-Clustern im
  besonderen - effizient lösen, nämlich die der (nahezu) perfekt
  parallelisierenden.

- Willst du ein Problem aus einer anderen Klasse lösen, mußt du aufwendig
  schauen, ob du deinen Algorithmus so umbauen kannst, daß er
  a) immernoch halbwegs effizient und
  b) mit wenig Kommunikation zwischen den einzelnen Rechen-Knoten auskommt
     (Einmal viele Daten senden ist dabei meist besser, als häufig kleine
      Datenmengen senden.)
  c) deadlock-frei ist.

  [Und das er außerdem immernoch das selbe tut, wie der Original-
   Algorithmus.]

  -- oder eben Spezialhardware verwenden.

seti at home und z. B. Paßwörter knacken sind perfekt parallelisierbar. Bei
seti bekommt jeder Client etwas von der Datenmenge und er muß hierbei
nachschauen, ob ein Datum darin Merkmal X aufweist - dies ist vollkommen
unabhängig davon, ob alle anderen Daten diese Merkmal nun haben oder nicht.

Beim Paßwortknacken ebenso: (Z. B.) Wende das Entschlüsselungsverfahren mit
Schlüssel X an und schau, ob das Ergebnis sinnvoll ist. Hierbei muß kein
Prozeß vom anderen etwas erfahren. (Sinnvollerweise sendet man natürlich ein
"Paßwort gefunden" an alle Prozesse, die noch rechnen.) So kann z. B. Prozeß
1 alle Paßwörter von aaaa-mmmm durchrechnen und Prozeß 2 von mmmn-zzzz.

Ebenso das Ausrendern von CGI beim Film. Da ist jedes Bild unabhängig vom
vorherigen berechenbar, sogar jeder einzelne Pixel.

Anders sieht es z. B. aus, wenn man große (formale) neuronale Netze
durchrechnen will. Da kann man nicht z. B. jedem Neuron eine CPU zuweisen,
da im allgemeinen jedes Neuron mit jedem anderen verbunden ist. Das, was das
Neuron als Ausgabe hat, ist i. a. eine relativ simple Funktion all seiner
Eingaben. Hier würden also alle CPUs ganz kurz rechnen und sich dann so
lange langweilen, bis alle Datenpakete über das langsame Netzwerk gewandert
sind.

Bei den meisten finite-Elemente-Methoden z. B. sieht es ähnlich aus.
(Beispielsweise Simulation von Verbrennungen in Motoren,
Strömungssimulationen.)

Hab gerade den Link zu dem Buch gefunden (leider nicht online lesbar), bei
dessen Autoren ich mal ein Semester lang eine Vorlesung über Cluster
Computing gehört hatte - kann man ja mal in Bibliotheken nachschauen, ob es
da vorhanden ist:

Heiko Bauke und Stephan Mertens
Cluster Computing
Praktische Einführung in das Hochleistungsrechnen auf Linux-Clustern
Springer Verlag, 2005, ISBN: 3-540-42299-4
http://www.clustercomputing.de/

Ansonsten, siehe auch mal
http://tina.nat.uni-magdeburg.de/heiko/Publications/index.php#cluster
(Referenzen auf Linux-Magazin-Artikel z. B.)

(TINA ist übrigens ein PC-Cluster des Instituts für Theoretische Physik der
Uni Magdeburg, der es sogar mal [ganz kurz] unter die TOP500 der schnellsten
Rechner der Welt geschafft hatte.)

> Zum Thema Stromverbrauch:

[rausfliegende Sicherungen]

> Ich vermute, wenn Du auf geringen Stromverbrauch und Laut- (besser 
> Leise-)staerke wert legst, musst Du zu Prozessoeren und Chips greifen, die 
> Du sonst in Laptop findest. Dort findest Du auch Boards mit kleinen 
> Abmassen.. Nur sind die meist nicht die billigsten..

Wie gesagt, es macht so eigentlich keinen Sinn. Entweder, man kauft sich
einen Rechner mit einer 3GHz CPU, aber nicht z. B. 3*1GHz "in leise", wenn
man billig möchte.

Ich denke auch, daß die Stromkosten von 3*1GHz "in leise" durchaus höher
sein können, als 1*3GHz, z. B.

Nunja, eigentlich sollte man auch MIPS und FLOPS vergleichen - und das
jeweils für seine spezielle Anwendung. Es macht nämlich auch nochmal einen
Unterschied, ob z. B. dein rechenintensiver Code in den Cache der CPU paßt
oder/und ob dieser auf kleinen Datenmengen arbeitet, die alle in den
(Daten-)Cache der CPU passen oder ob er über viele Megabyte an Daten
regelmäßig rüber muß.

Gruß,
 Mike