level66 – Wenn Hosting nur das Nebenprodukt ist

Cloud-Infrastruktur wird häufig in Compute gemessen. Wie viele CPU-Kerne stehen zur Verfügung? Wie viel Arbeitsspeicher besitzen die Nodes? Welche Storage-Klassen gibt es? Wie schnell lassen sich neue Ressourcen provisionieren? Für eine Edge Cloud sind diese Fragen wichtig. Aber sie beginnen aus unserer Sicht zu spät. Bevor ein Request einen Kubernetes-Cluster erreicht, hat er bereits einen erheblichen Teil der Infrastruktur durchlaufen, die über seine Performance entscheidet. Er wurde durch autonome Systeme geroutet, über Transitprovider oder Peerings transportiert und möglicherweise an einem Internet Exchange zwischen verschiedenen Netzen übergeben. Deshalb stellen wir in unserer Serie Partner Spotlight die Unternehmen vor, die gemeinsam mit uns die Infrastruktur hinter der ayedo Edge Cloud aufbauen. Heute geht es um level66.network. Und um ein Unternehmen, bei dem eine Aussage besonders gut beschreibt, warum wir zusammenarbeiten: Hosting ist eigentlich nur ein Nebenprodukt.

Ein Edge-Standort ist zuerst ein Netzwerkstandort

Ein Kubernetes-Cluster lässt sich an vielen Orten betreiben. Für eine Edge Cloud reicht das allein nicht aus. Unsere Standorte verarbeiten öffentlichen Traffic und werden Teil einer verteilten Infrastruktur. Damit spielt nicht nur die verfügbare Compute-Leistung eine Rolle, sondern vor allem die Frage, wie ein Standort mit dem restlichen Internet verbunden ist. Welche Netze sind direkt erreichbar? Welche Internet Exchanges werden genutzt? Welche alternativen Pfade existieren? Wie wird mit DDoS-Angriffen umgegangen? Und wie viel Netzwerkkapazität steht zur Verfügung, wenn der Traffic wächst? Bei der Auswahl unserer Infrastrukturpartner betrachten wir deshalb nicht nur Server. Wir betrachten Netzwerke. Und genau dort liegt die Spezialisierung von level66.

Wer ist level66?

level66.network UG (haftungsbeschränkt) ist auf Netzwerkinfrastruktur spezialisiert. Hosting gehört ebenfalls zum Angebot, ist aber nicht der eigentliche Mittelpunkt des Unternehmens. Das Netzwerk ist es. level66 betreibt umfangreiches Peering an verschiedenen Internet Exchanges und direkte Anbindungen an zahlreiche Hosting-Netzwerke. Laut bgp.tools gehört das Netzwerk zu den Top 60 Known Peers in Germany und den Top 70 AS Cone in Germany. Für einen klassischen Hosting-Kunden mögen solche Zahlen zunächst abstrakt wirken. Für eine Edge-Plattform beschreiben sie etwas sehr Konkretes: wie stark ein Netzwerk mit anderen Teilen des Internets verbunden ist. Denn jeder direkte oder sinnvoll gewählte Netzwerkpfad kann dazu beitragen, unnötige Umwege zwischen Nutzer und Anwendung zu vermeiden.

Unser Edge-Standort in Frankfurt

Gemeinsam mit level66 betreiben wir einen PoP der ayedo Edge Cloud in Frankfurt am Main. Die Infrastruktur befindet sich im Digital Realty FRA11, einem carrier-neutralen Rechenzentrumsstandort. Carrier-neutral ist dabei für uns ein entscheidendes Stichwort. Denn eine Edge Cloud soll möglichst nicht von einem einzigen Carrier oder einem einzigen vorgegebenen Netzwerkpfad abhängig sein. Stattdessen möchten wir Standorte dort aufbauen, wo unterschiedliche Netzwerke zusammenkommen und verschiedene Möglichkeiten für Peering und Connectivity bestehen. Vereinfacht lässt sich die Rolle des Standorts so darstellen:

                  Internet
                     │
          +----------+----------+
          │          │          │
       Peering    Peering    Transit
          │          │          │
          +----------+----------+
                     │
               level66.network
                     │
                     ▼
          Digital Realty FRA11
                     │
                     ▼
              ayedo Edge Cloud

Der Edge-Standort ist damit nicht einfach ein Cluster mit Internetanschluss. Er befindet sich an einem Ort, an dem Netzwerk und Interconnection im Mittelpunkt stehen.

Warum Peering für eine Edge Cloud wichtig ist

Das Internet ist ein Netzwerk aus Netzwerken. Diese Netze werden als autonome Systeme betrieben und müssen entscheiden, wie sie Traffic untereinander austauschen. Eine Möglichkeit dafür ist IP Transit. Ein Netzwerk bezahlt einen anderen Provider dafür, Traffic in andere Teile des Internets zu transportieren. Eine andere Möglichkeit ist Peering. Dabei tauschen zwei Netze Traffic direkt miteinander aus – beispielsweise über einen Internet Exchange. Vereinfacht:

Mit zusätzlichem Transitpfad

User
  │
  ▼
Access Provider
  │
  ▼
Transit
  │
  ▼
weiteres Netzwerk
  │
  ▼
Edge

\
Direkterer Pfad

User
  │
  ▼
Access Provider
  │
  ▼
Peering
  │
  ▼
Edge

Das bedeutet nicht automatisch, dass jeder Peering-Pfad immer schneller ist. Routing ist komplexer als die Anzahl der Linien in einem Diagramm. Aber umfangreiches Peering schafft mehr Möglichkeiten, Traffic direkt zwischen Netzen auszutauschen und geeignete Pfade auszuwählen. Genau deshalb ist die Peering-Infrastruktur eines Partners für uns mindestens genauso interessant wie die Compute-Hardware, auf der unsere Kubernetes-Nodes laufen.

Bis zu 400 Gbit/s

Netzwerkarchitektur benötigt nicht nur gute Pfade. Sie benötigt Kapazität. Die Infrastruktur von level66 am Standort ist technisch auf Bandbreiten von bis zu 400 Gbit/s ausgelegt. Das bedeutet ausdrücklich nicht, dass die ayedo Edge Cloud heute 400 Gbit/s Bandbreite an diesem Standort gebucht hat oder nutzt. Es beschreibt die technisch verfügbare Größenordnung der Infrastruktur. Für uns ist diese Unterscheidung wichtig. Denn beim Aufbau einer Edge-Plattform planen wir Standorte nicht ausschließlich für den Traffic von heute. Die Architektur muss mitwachsen können. Ein Standort, der heute einen Teil des Traffics verarbeitet, kann mit zunehmender Nutzung der Plattform deutlich größere Anforderungen an Netzwerk und Interconnection entwickeln. Kapazitätsreserven sind deshalb keine Zahl für ein Datenblatt. Sie sind Teil der langfristigen Architektur.

DDoS-Schutz direkt im Netzwerk

Je näher Infrastruktur am öffentlichen Internet betrieben wird, desto wichtiger wird der Umgang mit unerwünschtem Traffic. Ein öffentlich erreichbarer Edge-Standort kann nicht davon ausgehen, ausschließlich legitime Requests zu erhalten. DDoS-Mitigation ist deshalb keine Funktion, die wir erst innerhalb von Kubernetes betrachten können. Sie muss wesentlich früher beginnen. Bei level66 geschieht ein Teil dieser Abwehr direkt auf den Routern. Die Infrastruktur ermöglicht eigenes DDoS-Scrubbing mit einer Kapazität von bis zu 400 Gbit/s. Zusätzlich kann schädlicher Traffic über Upstreams geblackholed werden. Besonders interessant ist jedoch ein weiterer Bestandteil der Architektur: FlowSpec.

Wenn Routingregeln zur Firewall des Backbones werden

BGP FlowSpec ermöglicht es, Regeln zur Behandlung bestimmter Traffic-Muster über die Routing-Infrastruktur zu verteilen. Statt lediglich komplette Präfixe oder IP-Adressen aus dem Routing zu entfernen, können damit wesentlich spezifischere Regeln beschrieben werden. Vereinfacht:

                 Eingehender Traffic
                        │
                        ▼
                 level66 Router
                        │
               Traffic Analyse
                        │
             +----------+----------+
             │                     │
         legitim                Angriff
             │                     │
             ▼                     ▼
        weiterleiten         FlowSpec-Regel
             │                     │
             ▼                     X
      ayedo Edge Cloud          Drop

level66 verwendet dafür ein eigenes Tool namens flowwler. flowwler dient dazu, FlowSpec-basierte Regeln zu verwalten und wird von level66 als DDoS-Protection-Lösung auch für andere Carrier und Service Provider entwickelt beziehungsweise angeboten. Für uns zeigt das einen wichtigen Unterschied zwischen einem klassischen Hostinganbieter und einem netzwerkorientierten Infrastrukturpartner. Die Antwort auf ein Netzwerkproblem besteht nicht zwangsläufig darin, eine weitere virtuelle Appliance vor einen Server zu stellen. Manchmal liegt die richtige Stelle für die Lösung direkt im Netzwerk.

400 Gbit/s Compute wären nutzlos ohne das Netzwerk

Moderne Server können enorme Mengen an Requests verarbeiten. Eine Plattform kann horizontal skalieren, zusätzliche Pods starten und Workloads über mehrere Nodes verteilen. All das hilft jedoch wenig, wenn der Netzwerkpfad davor zum Flaschenhals wird. Für Edge-Infrastruktur müssen deshalb mehrere Ebenen gemeinsam skalieren:

Application
     │
Kubernetes
     │
Compute
     │
Network
     │
Peering
     │
Internet

Jede dieser Ebenen kann die darüberliegenden begrenzen. Genau deshalb ist die Spezialisierung von level66 für uns interessant. Compute ist vorhanden. Aber die eigentliche Kompetenz beginnt eine Ebene darunter.

MAINPORT – Connectivity als eigene Plattform

Diese Netzwerkorientierung zeigt sich auch in einem weiteren Projekt von level66. Mit MAINPORT entwickelt das Unternehmen eine eigene Connectivity-Plattform. Das Thema ist für uns besonders spannend, weil moderne Infrastruktur zunehmend nicht mehr aus voneinander isolierten Rechenzentren besteht. Unternehmen verbinden Cloud-Provider, Colocation, eigene Standorte, Internet Exchanges und spezialisierte Plattformanbieter miteinander. Connectivity wird damit selbst zu einem Produkt. Für eine verteilte Edge Cloud ist diese Entwicklung unmittelbar relevant. Je mehr Standorte Teil unserer Plattform werden, desto wichtiger wird die Frage, wie diese Standorte mit anderen Netzen, Clouds und Kundeninfrastrukturen verbunden werden können.

Zusammenarbeit mit Netzwerkspezialisten

Eine der Ideen hinter unserer Partner-Spotlight-Serie ist es zu zeigen, dass die ayedo Edge Cloud nicht von einem einzelnen Infrastrukturunternehmen gebaut wird. Und das ganz bewusst. Ein Unternehmen besitzt besondere Erfahrung im Rechenzentrumsbetrieb. Ein anderes betreibt einen eigenen Backbone. Ein weiteres verfügt über besondere regionale Präsenz oder Connectivity. level66 bringt eine ausgeprägte Spezialisierung auf Netzwerk-Infrastrukturen, Peering und DDoS-Mitigation in diese Architektur ein. Genau diese unterschiedlichen Schwerpunkte möchten wir miteinander verbinden. Denn eine verteilte Plattform wird aus unserer Sicht robuster, wenn nicht jeder Standort exakt dieselben Voraussetzungen und Abhängigkeiten besitzt.

Edge beginnt vor Kubernetes

Als Plattformunternehmen verbringen wir viel Zeit mit Kubernetes. Wir automatisieren Deployments. Wir bauen Operatoren. Wir betreiben Datenbanken. Wir beobachten Cluster. Wir entwickeln APIs. Aber wenn ein Nutzer einen unserer Dienste aufruft, beginnt sein Request nicht in Kubernetes. Er beginnt irgendwo im Internet. Von dort durchläuft er Netzwerke, Router, Peerings und Transitverbindungen, bevor der erste Pod überhaupt etwas von ihm erfährt. Deshalb endet unsere Arbeit an der ayedo Edge Cloud nicht an der Kubernetes-API. Und sie beginnt auch nicht dort. Mit level66.network haben wir einen weiteren Partner an unserer Seite, dessen Arbeit genau in diesem Bereich beginnt: im Netzwerk. Mit umfangreichem Peering, einem carrier-neutralen Standort in Frankfurt, hoher verfügbarer Netzwerkkapazität und eigenen Werkzeugen für DDoS-Mitigation schafft level66 einen weiteren Teil der Infrastruktur, auf der unsere Plattform wachsen kann. Denn bevor Kubernetes einen Request verarbeiten kann, muss das Netzwerk ihn erst einmal dorthin bringen.