Schlankes Netzwerkprotokoll für Cluster?

[Chiron McAnndra]

Hi,

ich bin auf der Suche nach Netzwerkprotokollen speziell für Cluster. Der ganze Overhead für die Kommunikation zwischen entfernten Rechnern über Router u.ä. wäre für die Kommunikation zwischen den Nodes größtenteils überflüssig und machen den Informationsfluss langsam. Jeder Layer des TCP/IP Layermodells schmälert den Datendurchsatz und füllt ihn stattdessen mit oftmals redundanten Daten, die für die normale LAN-Verbindung wichtig, für eine Schnelle Kommunikation zwischen den Einzelrechnern innerhalb eines Clusters eher hnderlich sind.
Kennt hier jemand Alternativen?

Danke,

CMA

 

[leipziger1979]

Geht es etwas spezieller als nur der große Oberbegriff "Cluster"?
Pauschal würden mir aber Jumbo Frames einfallen.

 

[naniii]

Infiniband

 

[RalphS]

So viel Inter-Cluster Kommunikation gibts da ja nicht. Heartbeat reicht ja schon.
Plus, Clusternetzwerk, welches ggfs breiter sein kann als das externe.

 

[Je_Tho]

Geht es etwas spezieller als nur der große Oberbegriff "Cluster"?
Pauschal würden mir aber Jumbo Frames einfallen.

Ich stimme zu, ein paar mehr Information zum Anwendungsfall wären sicher hilfreich!

JumboFrames und Infiniband sind sicher schon gute Stichwörter.
Wobei man sich durch JumboFrames alleine natürlich nicht den IP- bzw. TCP-/UDP-"Overhead" spart.
Je nach Art des Clusters, müsste man aber sicher auch über FibreChannel, oder andere Techniken nachdenken.

Im Zweifelsfall am besten erstmal das OSI-Modell zur Hand nehmen und checken, welche Alternativen zu Ethernet in Frage kommen.
Und falls es doch Ethernet sein muss, dann gibt es auch noch ein paar andere Schichten, bei denen man verschiedene Optionen hat.

VG Je_Tho

 

[esb315]

Seperates Netzwerk und Server für die jeweilige Aufgaben. Und HA-Protokolle sollten eigentlich immer in nen eigenen Netzwerk laufen. Details wären hier aber schon sinnvoll.

 

[snaxilian]

Cluster haben im besten Fall drei getrennte Kommunikationswege:

• Traffic zwischen den Clustern zur Abstimmung. Hier reicht in der Regel 1Gbit Ethernet da nur Heartbeats etc ausgetauscht werden und Managementzugriff auf die einzelnen Clusterknoten.
• Traffic um Nutzdaten zu synchronisieren, beispielsweise bei Storage-Systemen zum Sync der Daten. Bei synchroner Replikation empfiehlt sich 10G Ethernet oder mehr oder Lösungen wie FibreChannel mit geringerem Protokolloverhead. Diese sind aber in der Regel nur sinnvoll bzw. nutzbar bis zu gewissen Kabelstrecken. Ab einer gewissen Entfernung ist die Latenz zu hoch für synchrone Replikation und man nutzt eher asynchrone Replikation. Anwendungsfall wäre ein Storage-Cluster an Standort A (mit sync. Repl.) und zusätzlich eine async. Repli. zu einem weiteren Cluster an Standort B als Backup/Failover System.

Das ist am Ende aber auch immer eine Kosten-/Nutzen-Frage. Infiniband ist vergleichsweise teurer als FibreChannel und das wiederum teurer als Ethernet. Ethernet ist dafür auch nutzbar für große Entfernungen und mit Jumbo Frames wird der Overhead im Vergleich zur Payload geringer.
- Traffic für die Nutzdaten/Anwender. Um beim Beispiel eines Storage-Clusters zu bleiben wären dies z.B. Hypervisors die den Cluster als Ablage für die VMs. Hier sollte natürlich auch je nach Anforderung entsprechende Bandbreite zur Verfügung stehen, jedoch macht es wenig Sinn wenn diese höher ist als die zur internen Cluster-Replikation da sonst bei Volllast die Replikation nicht mehr hinterher kommt.

Wie du siehst gibt es je nach Anforderungen an Latenz, Bandbreite und Budget verschiedene Lösungen: Ethernet oder Fibre Channel oder eben Infiniband. Alle jeweils in unterschiedlichsten Bandbreiten und Redundanzen und so ziemlich alle als switched fabric Lösung. Bei Ethernet sind es VLANs, bei FC dann das Zoning und wie auch immer das bei Infiniband heißt.

 

[Chiron McAnndra]

Es geht hier um eine grundsätzliche Überlegung. TCP/IP hat etliche Layer - und jeder einzelne davon nimmt die Information, teilt sie in vorgegeben große Stüccke und packt dann die eigenen Layerspezifischen Informationen dazu, bevor die Päckchen an den nächsten Layer weitergereicht werden.
Auf der Empfängerseite werden diese dann in umgekehrter Reihenfolge wieder ausgepackt und zusammengesetzt, bis am Ende die Originalinformation da ist.
Ein Großteil dessen, was dabei über die Strecke geschickt wird, ist für die Kommunikation zwischen Maschinen, die im Verbund eines Clusters dicht beeinanderstehen und die ganz sicher nicht über irgendwelche annonymen Verbindungselemente miteinander verlnüpft werden müssen, bei denen erst mal lange rumgesucht werden muss, welches Päckchen wo hin gehört, wird das meiste davon überhaupt nicht benötigt. Dummerweise ist es aber da und es spart Arbeit, wenn man etwas vorhandenes, das sich bewährt hat, weiterhin benutzt - und es ist eben leichter, sich diesen Zustand schönzureden, als ihn effizienter zu gestalten.
Ich bin der Ansicht, dass man für die Kommunikation einzelner Nodes innerhalb eines Clusters im Grunde alles weglassen könnte, was an Sicherheitsebenen eingebaut wurde, die dazu da sind, dass ein Datenpäckchen seinen Weg durch ein Netzt von Stadt A nach Stadt B findet - denn das würde die Kommunikation der Nodes untereinander sehr stark beschleunigen.
Es müßte im Grunde nur ein Knoten pro Cluster befähigt sein, nach außen (also über TCP/IP) zu kommunizieren.

 

[Je_Tho]

..und es ist eben leichter, sich diesen Zustand schönzureden, als ihn effizienter zu gestalten.

Naja, da haben sich ganz schön viele Leute ganz schön viele Gedanken gemacht, um erst einmal soweit zu kommen.

Und genau deswegen, lässt sich auch keine universell gültige Antwort auf deine Frage finden, so lange sich kein genauerer Anwendungsfall spezifizieren lässt.
Ethernet + MAC + IP + TCP/UDP + x ist einfach super praktisch, weil sich verschiedenste Dienste / Applikationen damit abwickeln lassen.
Und das auch noch vollkommen standardisiert über eine einzige Schnittstelle!

Gehen wir nochmal einen Schritt zurück und denken über den Begriff >Paketvermittelndes Netzwerk< nach.

Um es grundsätzlich zu erklären: Wenn Du kein IP bzw. TCP verwenden möchtest, dann kannst Du auch "einfach" auf einen anderen Standard zurückgreifen. Einige Ideen wurden ja bereits genannt.
Und bei z.B. HPC-Clustern (wo die Nodes typischer Weise auch dicht beieinander stehen), wird für die Interkommunikation von produktiven Informationen ja auch gar kein TCP / IP genutzt, sondern etwa Infiniband.
In einem Speichercluster (z. B. SAN (Fernreplizierung mal außen vor), wird mitunter auf SAS gesetzt.

VG Je_Tho

 

[Timberwolf90]

Wenn es relativ einfach aber sogleich auch performant und schnell umzusetzen sein soll würde ich mir mal ZeroMQ genauer ansehen: ZeroMQ - The Guide. Es gibt eine Vielzahl von ZeroMQ Bindings für diverse Programmiersprachen, welche zudem auch gut dokumentiert sind.

Für deinen speziellen Anwendungsfall habe ich auch einen netten Artikel mit einem bereits implementierten Beispiel gefunden: Easy cluster parallelization with ZeroMQ