Wie wir während der COVID-19-Krise einen Netzwerk-PoP remote bereitgestellt haben
Als Teil unserer SaaS-basierten Kontrollebene haben wir unser eigenes globales Backbone (AS35280) erstellt und betreiben es, wobei wir mehrere 100G- und 400G-Verbindungen zwischen unseren PoPs verwenden.
Auf diese Weise haben wir die vollständige Kontrolle über die End-to-End-Konnektivität zwischen unseren regionalen Rändern, können unseren Kunden aber auch über ihre privaten Rechenzentren, Randstandorte, öffentlichen Cloud-VPCs (AWS, Azure, GCP) sowie SaaS-Anbieter hinweg dieselbe Hochleistungskonnektivität und geringe Latenz bieten.
Die Forderung
Mit Niederlassungen in Paris, London, Amsterdam und Frankfurt waren wir in Europa bereits recht gut aufgestellt, aber bestehende und neue Kunden benötigten einen neuen PoP in Lissabon (Portugal).
Dies alles wurde Anfang 2020 vereinbart und die Bereitstellung war für das dritte Quartal 2020 geplant. Das war natürlich vor COVID-19 :)
Aufgrund der Krise verzeichneten wir auf unserem Backbone wesentlich mehr Datenverkehr (und auch DDoS-Angriffe, aber mehr dazu in einem zukünftigen Blogbeitrag) und das Gleiche galt für unsere Kunden.
Sie baten uns, die Bereitstellung vor dem dritten Quartal durchzuführen, da sie diesen PoP so schnell wie möglich benötigten – genauer gesagt vor Ende Mai. Und weil wir bei Volterra nette Leute sind und Herausforderungen mögen, haben wir uns die Zeit, die wir brauchen, um die Kundennachfrage zu erfüllen, genau angesehen:
- Wir brauchten mindestens 2 Wochen für die Bereitstellung und den Test,
- Und eine Woche zur Validierung
Da wir wussten, dass es Anfang April war, sah alles gut aus und wir entschieden uns, weiterzumachen und das Projekt zu starten, obwohl das aus folgenden Gründen eigentlich der denkbar ungünstigste Zeitpunkt dafür war:
- Reiseverbot,
- Kein Zugriff auf das Rechenzentrum,
- Globaler Komponentenmangel,
- Ganz zu schweigen von den gesundheitlichen Risiken.
Was wird benötigt?
Bei der Bereitstellung eines neuen PoP geht es nicht nur um Router, Switches und Kabel. Sie müssen außerdem:
- Netzwerktechnik durchführen, um den besten Standort und die besten Anbieter für Wellen auszuwählen,
- einen Deal mit dem ausgewählten Rechenzentrum (in diesem Fall Equinix LS1) abschließen/verhandeln,
- Umgang mit IXP zur Sicherung von Peering-Ports,
- und natürlich die Bestellung der entsprechenden Hardware/Material (Router, Switches, Kabel, Firewalls, …)
So haben wir es gemacht
Angesichts der anhaltenden Krise war es unmöglich, die erforderliche Hardware rechtzeitig zu beschaffen. Daher haben wir uns entschieden, einen Teil des Materials, das wir zur Verfügung hatten, wiederzuverwenden, das meiste davon aus unserem Labor. Dies war ein akzeptabler Kompromiss (z. B. werden als Router Juniper QFX10K anstelle der geplanten MX10K verwendet).
Das Staging, das wir normalerweise offensichtlich in einem Rechenzentrum durchführen (wegen des benötigten Stroms und Rack-Platzes, aber auch … wegen des Lärms!), musste aufgrund der Ausgangssperre zu Hause erfolgen. Raphaël, unser CTO für Infrastruktur, hatte ein ausreichend großes Büro (einschließlich eines 60-Ampere-Vertrags, der sich als nützlich erweisen kann, wenn Sie Geräte hochfahren/mit Strom versorgen, die bis zu 16 Ampere benötigen!), sodass er die gesamte Inszenierung alleine durchführen konnte, wodurch auch vermieden wurde, dass anderes Personal einbezogen wurde bzw. aussteigen musste.
Nachdem alles konfiguriert und mehrfach getestet war, haben wir nach Lissabon verschickt:
Rack-Installation in Lissabon durch Equinix Remote-Hands
Obwohl wir von unserem Setup überzeugt waren (und ohnehin Fernzugriff über OOB oder unser Backbone hatten), war dies dennoch das erste Mal, dass ein neuer PoP nicht direkt von uns, sondern von jemand anderem bereitgestellt wurde 😅
Wir verwenden auf der ganzen Welt dasselbe Rack-Design und das Ziel bestand darin, einheitlich zu sein und für diesen neuen Lisbon PoP das gleiche Setup zu verwenden.
Deshalb mussten wir bei den Anweisungen, die wir den Remote-Hands von Equinix gaben, äußerst präzise sein, damit sie diese nachahmen und einfach „der Anleitung folgen“ konnten.
Nachfolgend finden Sie einen Teil des Verfahrens, das wir an Equinix gesendet haben, damit sie alles problemlos in Racks einbauen und anschließen können.
Es müssen viele Komponenten berücksichtigt werden – nicht nur die Hardwaregeräte (Router, Switches, Firewalls, Server), sondern auch die Verkabelung und, noch wichtiger, die Switch- und Server-Ports, an die die Kabel angeschlossen werden.
Wie Sie unten sehen können, ist das Verfahren so detailliert wie möglich, wobei zu berücksichtigen ist, dass die Equinix-Techniker viele Installationen durchzuführen haben. Je präziser wir also sind, desto besser!
Hat das geklappt?
Ja! Die Installation begann am 5. Mai. Alle Geräte waren bereits im Rack installiert und mit Strom versorgt, und es gab keinen Hardwarefehler. Wir hatten Glück, oder vielleicht lag es an unserer Erfahrung, dass Versand und Verpackung ordnungsgemäß durchgeführt wurden, oder vielleicht beides. Auf jeden Fall hat alles problemlos funktioniert.
Am nächsten Tag kümmerten sich die Techniker von Equinix um die Verkabelung (Kupfer/Glasfaser) und um 23:30 Uhr konnten wir von Paris aus unseren PoP in Lissabon anpingen!
Die Installation wurde am 7. Mai abgeschlossen. Abschließend mussten noch die letzten Aufgaben erledigt werden, wie etwa die Konfiguration der PDUs, das Cross-Connect der OOB-Ports und die End-to-End-Prüfung der IXP-Ports. Sogar unsere Switches/Firewall-Konfiguration war voll funktionsfähig, wir mussten Equinix nicht um Konfigurationsänderungen bitten.
Die endgültige Installation sieht folgendermaßen aus:
Da wir sehr anspruchsvoll sind, sind wir nicht 100 % zufrieden. Beispielsweise ist die Rückseite des Gepäckträgers nicht so sauber, wie wir es gerne hätten – aber das werden wir beheben, sobald sich die Krise gelegt hat und wir wieder nach Portugal reisen können.
„Post-Mortem“ – was hat funktioniert, warum und was kann verbessert werden
Obwohl wir überaus glücklich und stolz sind, dass wir die Herausforderung gemeistert haben, möchten wir gerne einen Schritt zurücktreten und darüber nachdenken, was funktioniert hat, vor allem aber, was verbessert werden kann.
Was hat funktioniert:
- Equinix: Es ist wichtig, einen Anbieter zu informieren, wenn etwas nicht gut läuft. Noch wichtiger ist es jedoch, dies zu tun, wenn etwas gut läuft und darüber hinaus – und das ist hier der Fall. Vom Vertrieb und der Geschäftsführung bis zu den Technikern im Rechenzentrum waren die Unterstützung und Reaktionsfähigkeit, die wir erhielten, einfach unglaublich – insbesondere in diesen schwierigen Zeiten. Also wirklich ein großes Lob an Equinix!
Warum hat das funktioniert?
- Volterra war bereits zuvor ein überwiegend verteiltes und Remote-First-Unternehmen – insbesondere unser französisches Team, das für NetOps verantwortlich ist, ist über ganz Frankreich verteilt und ist es gewohnt, mithilfe von kollaborativen Tools remote zu arbeiten.
- Wir hatten genügend Ersatz-/Laborhardware zur Verfügung, sodass wir pünktlich fertig waren
- Das oben kurz erläuterte Verfahren ist das Ergebnis jahrelanger Implementierung und Erfahrung sowie iterativer Verbesserungen – und es hat sich gelohnt.
- Eine gute Beziehung zu unseren Lieferanten ist für uns von entscheidender Bedeutung: Wenn etwas schief geht, rufen wir sie an und scheuen uns nicht, es ihnen mitzuteilen. Auf der anderen Seite ermöglicht ihnen dies aber auch, sich zu verbessern, nicht nur für uns, sondern für alle ihre Kunden.
- Bedarf an Geschwindigkeit/Preis/Qualität: Sie müssen hohe Erwartungen haben – dazu gehört auch die Investition in Ressourcen, BEVOR Sie sie benötigen!
Was kann verbessert werden?
- Wir haben festgestellt, dass nur eine Handvoll Leute (3 bis 4) im Unternehmen eine solche Bereitstellung bewältigen können – wir müssen einen Weg finden, um zu skalieren
- Außerdem möchten wir die Inszenierung verbessern, um zu vermeiden, dass wir zuerst eine vollständige Inszenierung durchführen müssen.
- Schließlich ist ein solcher Einsatz nicht nur eine technische Angelegenheit: Der Vertrieb/Presales muss sich darüber im Klaren sein, wie viel Zeit für das gesamte Projekt und die einzelnen Schritte benötigt wird – und darf nicht davon ausgehen, dass NetOps alles lösen kann und deshalb Projekte ohne angemessene zeitliche Qualifikation aufgeben.
Wir haben diese Bereitstellung während des ersten Remote-RIPE-Meetings (RIPE 80) vorgestellt. Sie können die Aufzeichnung hier ansehen: