Wo gehobelt wird, da fallen Pakete (?)

Mit der eigenen Netzwerk-Infrastruktur läuft es wie mit dem eigenen Auto: Regelmäßig werden Inspektionen fällig, mal geht unerwartet etwas kaputt und hin und wieder stehen auch größere Arbeiten an. Aber zurück zu sipgate: In unserem konkreten Fall sind wir derzeit damit beschäftigt, die Netzwerk-Hardware an einem unserer Rechenzentrums-Standorte zu modernisieren. Das vorhandene Equipment hat sich seine Sporen durchaus verdient, kann aber mit unseren heutigen Anforderungen nicht mehr ganz mithalten. Die für uns besonders wichtigen Punkte bei dieser Modernisierung sind dabei höhere Geschwindigkeiten und natürlich bessere Automatisierung. Und mit “besser” meinen wir überhaupt mal Automatisierung. Tatsächlich gehört unsere Netzwerk Infrastruktur zu den wenigen Komponenten, die sich in den letzten Jahren erfolgreich allen Automatisierungsversuchen widersetzt hat.

Wir hatten in den vergangenen zwei Monaten hin und wieder Probleme mit unserer Netzwerk Infrastruktur, die sich zum Beispiel in Form von schlechter Sprachqualität für einen Teil unserer Kunden gezeigt haben. Darüber haben wir jeweils zeitnah via Twitter informiert. Wie es dazu kommen konnte, wollen wir Euch im nun folgenden, allerdings eher technisch ausgerichteten Blogpost mitteilen.

Vom Suchen und Finden

Da wir mit unseren Servern immer eher in die Breite skalieren, ist der Bedarf an Bandbreite pro Server gar nicht so hoch und wird von Allem mehr als abgedeckt, was der Markt derzeit her gibt. In Sachen Automatisierung sieht es da schon schnell schlecht(er) aus: Manche Hersteller kochen nur mit Wasser, aber es gibt auch genug, die sich wirklich Mühe geben. Natürlich bieten die großen Hersteller schon lange spezielle und meistens auch teure Management Lösungen für Ihre Geräte an – wir wollen aber mit den Tools arbeiten, die wir jetzt schon einsetzen. Damit stehen hauptsächlich ansible und puppet im Raum, wobei wir ansible an der Stelle bevorzugen. Gerade bei ansible hat der Netzwerk-Bereich mit den letzten Versionen ordentlich Fahrt aufgenommen und damit für uns genau zur richtigen Zeit. Bevor wir tatsächlich Hardware auf dem Tisch hatten, haben wir uns bei Team Operations einmal pro Woche in Zweiergruppen aufgeteilt und jeweils verschiedene Ansätze verfolgt, die uns zu einer neuen Netzwerk-Infrastruktur führen sollten. Dabei stand eine Aufrüstung vorhandener Komponenten genauso im Raum wie eine komplette Neuanschaffung. Und in letzterem Fall natürlich direkt die ganze Palette an Buzzwords, die das Thema Netzwerk aktuell hergibt: Leaf-and-Spine, SDN, Fabrics oder doch ganz klassisch? Ist „Routing on the Host“ das nächste große Ding oder will man BGP & Co doch lieber von Servern fernhalten? Und was bedeutet das alles für einen Migrationspfad? Die Liste der Fragen ist nicht unbedingt kurz.

Natürlich fängt es sich am schönsten immer auf einer grünen Wiese an – aber die hat man nun mal nicht, wenn schon eine dreistellige Anzahl Server verbaut sind und man auch (um die Zahl simultaner Änderungen und potentieller Fehlerquellen klein zu halten) an den Servern selbst möglichst wenig ändern möchte.

Neue Hardware – und nun?

Spulen wir jetzt mal einige Monate vorwärts: Wir haben uns nach verschiedenen Teststellungen für Juniper entschieden und starten mit komplett neuer Hardware. Trotz zweier Hürden – wir sind mit der neuen Hardware noch nicht vertraut und machen gerade unsere ersten Gehversuche mit ansible im Netzwerkumfeld – läuft alles sehr gut an und wir kommen zügig voran. Es war von vornherein unser Ziel, eine sanfte Migration durchzuführen und kein „Big-Bang-Umzugswochenende“ zu planen. Auf diese Weise können wir auch zwischen den einzelnen Schritten auf Entwicklungen reagieren, die wir vorher nicht einkalkuliert haben und entsprechend nachbessern. Das setzt also auch voraus, dass wir für eine ganze Weile eine stabile Verbindung zwischen der „alten“ und der „neuen“ Welt haben. Und genau da fingen die Probleme an – von einer ausreichenden Anzahl an Ports auf beiden Seiten über die Irrungen und Wirrungen der verschiedenen Spanning Tree Standards und -Implementierungen bis zu – für uns – eher neueren Konzepten wie Multi-Chassis-Link-Aggregation oder Virtual Chassis. Gleichzeitig sind wir offensichtlich über einen noch unbekannten Bug in der neuen Hardware gestolpert und wurden von der alten Hardware durch ungefragte Reboots, Packet Loss oder Packet Duplication abgestraft.

Das Alles hat uns und vor allem den betroffenen Kunden in den vergangenen Wochen deutlich mehr Schweißperlen bzw. Zornesfalten auf die Stirn gezaubert als nötig. Andererseits haben uns bereits vorhandene Redundanzkonzepte vor größerem Schaden bewahrt und erlauben uns, auch Arbeiten am Netzwerk oder ganzen Server-Racks zu regulären Arbeitszeiten durchzuführen, ohne dass es Auswirkungen hat.

Wie geht es jetzt weiter?

Wir haben die Migration aktuell angehalten bzw. einen kleinen Teil zurückbauen müssen, bis Juniper das von uns aufgedeckte Problem gelöst hat. Alles in allem sind wir allerdings auf der Zielgeraden angekommen und ein Großteil des Traffics in einem unserer Rechenzentrum läuft bereits über die neue Infrastruktur. Sobald alles abgeschlossen ist, werden wir Euch hier natürlich auf den neuesten Stand bringen und auch unsere Erfahrungen mit ansible und Juniper mit Euch teilen. Stay tuned!