Schlankes Netzwerkprotokoll für Cluster?

Dabei seit
Feb. 2010
Beiträge
213
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
 

RalphS

Lieutenant
Dabei seit
Feb. 2015
Beiträge
935
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

Lt. Junior Grade
Dabei seit
Juni 2015
Beiträge
262
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

Lieutenant
Dabei seit
Dez. 2006
Beiträge
621
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

Captain
Dabei seit
Jan. 2016
Beiträge
3.266
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.
 
Top