Für ein paar Experimente habe ich meinen MPICH2-Cluster kraecher-i.local mit dieser Topologie neu aufgebaut.
Eigentlich wird die Dragonfly-Topology hauptsächlich für die interne Kommunikation von Hochleistungsclustern / Supercomputern verwendet.
Der Supercomputer “Piz Daint” am CSCS und die SUN StarFire E10k verwenden beispielweise die Dragonfly-(Netzwerk)topologie zur Kommunikation zwischen den einzelnen Rechenknoten.
Diese Netzwerktopologie, welche auch “fully connected” genannt wird, definiert eine direkte Verbindung von jedem Knoten zu jedem Knoten. So ist sie sehr leistungsfähig, sehr ausfallsicher, bietet ausserordentlich kurze Latenzzeiten, ist aber auch sehr teuer, da die Nummer der Verbindungen quadratisch mit der Anzahl der Nodes wächst: c=(n(n-1))/2.
Jede Node benötigt mindestens i=n-1 Netzwerkschnittstellen.
Nach dem Umbau sieht der Cluster nun so aus:
Meine Implementation hat einen Misstand: eine Node wird durch einen Cisco-Netzwerkswitch gestellt, da ich keine Möglichkeit habe, über eine andere Verbindung Zugriff ins Datennetzwerk zu erlangen.
node0 und node3 sind mittlerweile defekt und wurden somit der Verwertung zugeführt, daher besteht der Cluster aus den Nodes 1,2,4 und 5.
Die Netzwerkkonfiguration der einzelnen Nodes sieht nun so aus:
# cat /etc/conf.d/net config_enp3s4f0="null" config_enp3s4f1="null" config_enp9s1f0="null" config_enp9s1f1="null" bridge_br0="enp3s4f0 enp3s4f1 enp9s1f0 enp9s1f1" bridge_forward_delay_br0="0" bridge_hello_time_br0="1000" bridge_stp_state_br0="1" config_br0="dhcp"
Der maximale Datendurchsatz ändert sich nicht, er liegt nach wie vor bei rund 86MB/s.
Man mag sich nun fragen, warum?
Nun, Ethernet muss sicherstellen, dass zwischen zwei Nodes jeweils nur ein Datenpfad existiert, um Pakete eindeutig weiterleiten zu können. STP sorgt dafür, dass es keine unerwünscht kreisenden Pakete gibt.
Würde ich auf den Bridge’s STP deaktivieren, würde es zu Paket-Stürmen kommen. Man kann sich das vorstellen wie wenn man ein Mikrophon vor einen Lautsprecher hält, welcher über einen Verstärker an selbem Mikrophon hängt – das System beginnt zu pfeifen (Rückkopplung).
Als Alternative zum spanning tree protocol böten sich TRILL (TRansparent Interconnection of Lots of Links) oder SPB (Shortest Path Bridging), doch leider bietet Linux nativ keine Unterstützung für beide Protokolle an. Für SPB scheint es 2 Ansätze zu geben, doch ist es mir nicht gelungen, sie auf einen aktuellen Kernel anzuwenden.
Im Lagerhaus liegen leider keine Cisco Nexus oder “grössere” HP-Switches herum, mit denen ich mir behelfen könnte… Daher ist an dieser Stelle mein Experiment bereits beendet.