IPv6 im Clusterumfeld

Geschrieben von Beat Rubischon (Link) am Freitag, 2. November 2007, 15:35 aus dem *big-iron* dept. Privat bastelt er mit IPv6, sein Geld verdient er mit High Performance Clustern. Passt das zusammen? Jein. Einerseits wäre IPv6 die Lösung für das übliche IP Knuddelmuddel: Cluster haben normalerweise ein internes Netz, das mit privaten IPs abgedeckt wird. Spätestens dann, wenn mehrere Cluster zu einem grossen Grid zusammengefasst werden sollen, gibt das massiv Aerger. Oeffentliche IPs für diesen Fall zu beantragen macht erst bei den Systemen Sinn, die so gross sind, dass die Anzahl verbratete IPs schmerzen würde. Ich muss bei jeder Installation erst mit dem Kunden abklären, welche IP Ranges frei sind und muss aufgrund einer Annahme ein "passendes" Netz wählen. Vielleicht reicht es, vielleicht ist es irgendwann zu klein. Vielleicht werden auch sinnlos viele Nummern verbraten. Viele Kunden sind auch nicht in der Lage, ihr Netz richtig zu beschreiben und ich muss bei der Installation des Systemes vor Ort noch einmal Korrekturen vornehmen. Ein /64 reicht allemal. Es ist auch für einen "Minicluster" von zwei Knoten nicht zu gross und es ist auch für einen 200'000 Node Cluster ausreichend. Nebst den 2^48 MAC Adressen habe ich einen beinahe endlosen Range für "funktionale" IP Adressen und kann so beispielsweise einem Fileserver eine beständige IP geben. Ein Renumbering ist nichts anderes als das Announcement eines anderen Prefixes. Statt jeden Knoten anzupassen, muss ich nur auf dem Gateway einen entsprechenden Eintrag machen und das Hostsfile oder den DNS anpassen. Die eigentliche Nodeadresse bleibt bestehen. Mehrere Cluster zusammenfassen schmerzt auch nicht mehr, sondern bedingt nur das Oeffnen einer Route zwischen den beiden Netzen. Kosten tut das Ganze nichts. Der IPv6 Header ist trotz einer grösseren IP Nummer nicht gewachsen, es wird daher auch keine Performanceeinbusse geben. In der Praxis sieht das jedoch ganz anders aus: Die PXE Bootroms sprechen ausschliesslich IPv4. Sie beziehen eine IP per DHCP, danach machen sie einen TFTP Request. Erst der mittels PXELinux oder ELILO geladene Kernel "versteht" IPv6. Das wäre noch zu verschmerzen, da die Installation eines Knoten normalerweise eine lokale Sache ist und nicht geroutet wird. Filesharing wird normalerweise per NFS gemacht. Linux ist noch nicht so weit und kennt ausschliesslich NFS über IPv6 IPv4 - ganz im Gegensatz zu den *BSDs, welche doch schon Ende der 90er NFS über IPv6 im Griff hatten. Die spezialisierten Clusterfilesysteme wie Lustre oder das Panasas eigene Protokoll sind IPv4 only. Filesharing über mehrere Cluster hinweg wird damit zu einem echten Problem. Genauso die Message Passing Libraries. MPI und IPv6 sind noch kein Thema - einzig zu OpenMPI ist ein IPv6 Stack in Entwicklung, zu dem aktuell aber nur eine Präsentation verfügbar ist. Genauso die Job Scheduler - bei der Grid Engine ist IPv4 only, die Alternativen sehen auch nicht besser aus. Allenfalls die Meta Scheduler, die oftmals in Java geschrieben sind und daher von der Virtual Machine her einen IPv6 Support kennen. Auch so kleine Dinge wie Lizenzserver (FlexLM, FlexNet) sind IPv4 only. Dabei sind genau das die Services, die man möglichst zentralisiert betreiben möchte, um möglichst wenige Lizenzen zu verschwenden. So kommt es, dass High Performace Cluster das vermutlich am besten für IPv6 geeignete Einsatzgebiet wären - gleichzeitig aber mehr Stolpersteine im Weg liegen als anderswo. Permalink

Das Kleingedruckte: Der Besitzer der folgenden Kommentare ist wer immer sie eingeschickt hat. Wir sind in keiner Weise für sie verantwortlich.