Wenn wir uns die klassischen Netzwerkkomponenten ansehen, fällt eines in der Regel auf: Die Systeme booten irgendein OS, wo jeder Hersteller sein eigenes Süppchen kocht – oder sogar je nach Hersteller unterschiedlichste Süppchen im gleichen Haus. Dies führt zu sehr geschlossenen Systemen, die schlecht automatisierbar und generalisierbar sind, und wenn man doch den Aufwand getrieben hat, ein System zu automatisieren, so ist man an dieses eine System gebunden. Dennoch ist man immer noch in den Grenzen unterwegs, die sich der Hersteller gedacht hat.
Aber was ist eigentlich heute ein Switch oder Router? Eigentlich ist das ziemlich genau ein PC mit sehr vielen Netzwerk-Interfaces. Glaubt ihr mir nicht?
Man kann hier recht schön sehen, dass in der oberen Hälfte ein PC steckt – in diesem Falle ein normaler Xeon – und in der unteren Hälfte der Netzwerkteil. Dieser Netzwerkteil hat „nur“ Strom- und einen PCIe-Anschluss (im SAS-Format) an das Serverboard. Hier kommt jetzt so langsam die Spannung rein: der Bootloader auf dem Board ist ein normaler Grub mit etwas ONIE-Magie. ONIE ist das Open Network Install Environment, ein Verfahren, das einfach via HTTP verschiedene Images auf verschiedene Partitionen kopieren kann und dann entsprechend den GRUB konfiguriert, von einem Image zu booten. Und hier kommt jetzt die Zukunft ins Spiel: die Software, die ich aufspiele muss nicht mehr zwingend die sein, die der Hersteller mitliefert, sondern auch welche von Drittherstellern. Das macht uns deutlich flexibler!
Wir schauen uns daher gerade Cumulus Linux an – das: Überraschung – ein Debian ist. Das ist sogar ein ziemlich originales Debian, das „nur“ 2 Extrakomponenten hat: Ein Kernelmodul für den Chipsatz des Switches und einen Daemon, genannt switchd. Mit diesen beiden Komponenten passiert die Magie – so dass man auf dem Linux auf einmal 50 Interfaces hat – genau die, die der Switch hat. Diese kann ich genau so wie normale Linux-Interfaces benutzen und konfigurieren – zum Beispiel Bridges einrichten, iptables nutzen und so weiter. Der Clou ist aber folgender: das Kernelmodul und der switchd übersetzen diese Dinge (Bridges, Routen, Firewall-Regeln) in Konfigurationen, die der Switchchip versteht – damit kommt Traffic gar nicht zur CPU, sondern wird direkt auf dem Switch-Chip verarbeitet – nur so kann man mehrere 100G Bandbreite sinnvoll nutzen.
Dieses Feature bringt aber einen entscheidenden Vorteil: wenn der Linux-Kernel Routen sieht, landen diese in der Hardware. Damit können wir auf dem Switch unseren „BIRD“ (Bird Internet Routing Daemon) nutzen, wie auch in unserer Bestandsplattform. Aus Administrationssicht ist der Switch nur ein weiterer Server, der halt sehr viele Interfaces hat – das wars. Damit ist er ein normaler Debian-basierender Server, den wir exakt mit den gleichen Mitteln verwalten können, wie andere Server: Ansible, Nagios etc.
Das vereinfacht sehr viel für uns und dadurch sind wir nicht mehr an einen Hardware-Hersteller gebunden, sondern können das Blech untendrunter einfach austauschen – Voraussetzung ist, das unser OS den Chip versteht.
Ob das Ganze seine Versprechungen hält, erfahren wir im nächsten Monat wenn wir ein Team ins Herstellerlabor senden und die Technik auf Herz und Nieren prüfen.
PS: Für die Hardcore-Nerds unter euch: Ja, unter dem Kühlkörper ist nur ein Chip, der 3.2 TBit/s Durchsatz schafft, also 128 25GBit/s Lanes hat.
