Wer über Edge Computing spricht, denkt zunächst häufig an den Standort von Compute-Ressourcen.
Server sollen näher an den Nutzern stehen. Anwendungen sollen geringere Latenzen erreichen. Daten sollen möglichst dort verarbeitet werden, wo sie entstehen oder benötigt werden.
Das ist richtig.
Es ist aber nur ein Teil der Geschichte.
Denn ein Server, der geografisch näher am Nutzer steht, ist nicht automatisch auch netzwerktechnisch näher an ihm. Entscheidend ist ebenso, welchen Weg die Daten tatsächlich nehmen: über welche Carrier sie transportiert werden, an welchen Internet Exchanges Netze miteinander verbunden sind, welche Routingentscheidungen getroffen werden und welche alternativen Pfade bei einer Störung zur Verfügung stehen.
Genau darum geht es in unserem heutigen Partner Spotlight.
Nachdem wir mit NMMN bereits einen der Infrastrukturpartner hinter der ayedo Edge Cloud vorgestellt haben, richten wir den Blick diesmal auf die JD Group und unseren neuen Edge-Standort in Alsbach.
Edge entsteht nicht allein durch Geografie
Die grundlegende Idee einer Edge Cloud klingt zunächst einfach.
Compute-Ressourcen werden auf mehrere Standorte verteilt und näher an die Nutzer gebracht.
In der Praxis entscheidet die Position eines Servers auf der Landkarte jedoch nur bedingt darüber, wie schnell ein Nutzer diesen Server tatsächlich erreicht.
Zwischen Nutzer und Anwendung liegt das Internet.
Und das Internet besteht nicht aus einer einzelnen Verbindung, sondern aus tausenden autonomen Netzen, Carriern, Internet Exchanges, Transitprovidern und Glasfaserstrecken.
Ein geografisch naher Server kann deshalb über einen überraschend langen Netzwerkpfad erreichbar sein.
Umgekehrt kann ein etwas weiter entfernter Standort durch gutes Peering und geeignete Routingpfade eine hervorragende Verbindung zu einem Nutzer besitzen.
Für unsere Edge Cloud betrachten wir deshalb Compute und Netzwerk nicht getrennt voneinander.
Ein Edge-Standort muss nicht nur Rechenleistung bereitstellen.
Er muss sinnvoll in die Netzinfrastruktur integriert sein.
Wer ist die JD Group?
Die JD Group betreibt eigene Provider- und Netzwerkinfrastruktur und verbindet dabei Rechenzentrumsbetrieb, Backbone, Routing, Security und individuelle Netzwerklösungen.
Ein wesentlicher Bestandteil dieser Infrastruktur ist das eigene autonome System AS204197 sowie ein MPLS-/EVPN-basierter Backbone.
Über diesen Backbone verbindet die JD Group verschiedene Infrastruktur- und Interconnection-Standorte miteinander. Dazu kommen mehrere voneinander unabhängige Transit- und Upstream-Pfade sowie Peering-Infrastruktur in Frankfurt.
Genau diese Kombination ist für uns interessant.
Denn für die ayedo Edge Cloud benötigen wir nicht einfach einen weiteren Ort, an dem Server betrieben werden können.
Wir benötigen Standorte, die sich sinnvoll in eine verteilte Routing- und Servicearchitektur integrieren lassen.
Unser neuer Edge-Standort in Alsbach
Gemeinsam mit der JD Group entsteht deshalb ein weiterer Standort der ayedo Edge Cloud in Alsbach.
Der PoP befindet sich dabei nicht isoliert hinter einem gewöhnlichen Internetanschluss.
Er wird Bestandteil des Providernetzes AS204197 und ist über den Backbone der JD Group mit der Interconnection-Infrastruktur in Frankfurt verbunden.
Vereinfacht dargestellt sieht die Architektur so aus:
Internet
│
Transit & Peering
│
+------------+------------+
│ │
DE-CIX Frankfurt LOCIX Frankfurt
│ │
+------------+------------+
│
JD Group Backbone
MPLS / EVPN
│
▼
PoP Alsbach
│
▼
ayedo Edge Cloud
Frankfurt übernimmt innerhalb dieser Architektur die Rolle eines zentralen Backbone-, Transit- und Peering-Standorts.
Alsbach wird über redundante Transportwege mit dieser Infrastruktur verbunden und damit Teil einer größeren Routing- und Servicearchitektur.
Genau dieser Unterschied ist wichtig.
Wir stellen nicht einfach Kubernetes-Nodes in ein weiteres Rechenzentrum.
Wir erweitern das Netzwerk, auf dem unsere Edge Cloud läuft.
Frankfurt ist mehr als ein Rechenzentrumsstandort
Frankfurt gehört zu den wichtigsten Interconnection-Standorten Europas.
Für uns ist dabei allerdings weniger entscheidend, dass Infrastruktur physisch in Richtung Frankfurt angebunden ist.
Entscheidend ist, welche Netzwerke dort erreichbar sind und welche Routingmöglichkeiten daraus entstehen.
AS204197 ist am DE-CIX Frankfurt vertreten und verfügt zusätzlich über zwei separate 10-Gbit/s-Übergaben am LOCIX Frankfurt.
Hinzu kommen mehrere unabhängige Transit- und Upstream-Pfade.
Damit stehen unterschiedliche Möglichkeiten zur Verfügung, Traffic in andere Access-, Content-, Cloud- und Hosting-Netzwerke zu transportieren.
Das hat einen direkten Einfluss auf die Eigenschaften einer Edge-Plattform.
Kürzere Netzwerkpfade.
Weniger unnötige Transit-Hops.
Alternative Wege bei Carrier-Störungen.
Und vor allem weniger Abhängigkeit von einem einzelnen Transitprovider.
Ein Backbone verbindet Standorte zu einer Plattform
Ein einzelner Edge-Standort ist zunächst genau das:
ein einzelner Standort.
Interessant wird Edge-Infrastruktur erst dann, wenn viele dieser Standorte gemeinsam als Plattform funktionieren.
Dafür benötigt man ein Netzwerk zwischen ihnen.
Der MPLS-/EVPN-basierte Backbone der JD Group bildet einen Teil dieser Grundlage. Der PoP Alsbach ist über redundante Glasfaser- und Transportwege an die Frankfurter Interconnection-Infrastruktur angebunden.
Damit lassen sich Standorte und Netzwerkdienste nicht nur über das öffentliche Internet miteinander verbinden.
Je nach Anforderung können auch private Layer-2- oder Layer-3-Verbindungen, dedizierte VLAN- und VRF-Strukturen oder individuelle Routingkonzepte umgesetzt werden.
Für eine Edge-Plattform eröffnet das interessante Möglichkeiten.
Internet
│
+------------+------------+
│ │
Peering Transit
│ │
+------------+------------+
│
JD Group Backbone
│
+----------+----------+
│ │
▼ ▼
Alsbach Frankfurt
│
▼
ayedo Edge Cloud
Aus einzelnen Serverstandorten entsteht dadurch schrittweise eine zusammenhängende Infrastruktur.
Routing ist Teil der Plattform
Bei klassischen Cloud-Angeboten endet die Sicht des Kunden auf das Netzwerk häufig an einer virtuellen Netzwerkschnittstelle.
Für unsere Architektur reicht das nicht aus.
Wir möchten verstehen und beeinflussen können, wie Traffic unsere Standorte erreicht und über welche Pfade er das Netzwerk wieder verlässt.
Dafür setzt die Infrastruktur unter anderem auf BGP-basiertes Failover und Traffic Engineering.
Hinzu kommen standortbezogene Routing-Präferenzen, eigene BGP-Communities sowie IRR- und RPKI-basierte Sicherheitsmechanismen.
Das ermöglicht eine Routingarchitektur, in der Pfade bewusst gesteuert und unterschiedliche Netzwerkanbindungen miteinander kombiniert werden können.
Gerade für unsere Anycast-Architektur ist diese Ebene entscheidend.
Denn Anycast bedeutet letztlich nicht einfach, dieselbe IP-Adresse an mehreren Orten zu verwenden.
Es bedeutet, Routing so zu gestalten, dass das Internet einen geeigneten Weg zu einem verfügbaren Standort findet.
Je mehr Standorte hinzukommen, desto wichtiger wird deshalb die Infrastruktur unterhalb von Kubernetes.
Was passiert, wenn ein Netzwerkpfad ausfällt?
Redundanz klingt auf Architekturdiagrammen häufig einfach.
Man zeichnet zwei Leitungen statt einer.
In realen Netzwerken reicht das allerdings nicht.
Die beiden Verbindungen müssen tatsächlich unterschiedliche Failure Domains besitzen.
Sie sollten möglichst nicht dieselbe Glasfasertrasse verwenden.
Nicht vom selben Carrier abhängen.
Nicht über dieselben aktiven Netzwerkkomponenten geführt werden.
Und ein Ausfall muss durch das Routing entsprechend verarbeitet werden können.
Die JD Group verfolgt deshalb beim weiteren Ausbau ihres Netzes unter anderem das Ziel, Trassen-, Carrier-, Standort-, Strom- und Hardware-Failure-Domains konsequent voneinander zu trennen.
Für unsere Edge Cloud ist genau diese Denkweise relevant.
Denn Hochverfügbarkeit entsteht nicht dadurch, dass eine Ressource auf einem Architekturdiagramm zweimal vorhanden ist.
Sie entsteht dadurch, dass beide Ressourcen möglichst wenige gemeinsame Fehlerursachen besitzen.
Edge-Infrastruktur endet nicht beim öffentlichen Internet
Ein weiterer interessanter Aspekt der Zusammenarbeit betrifft Anwendungen, die gar nicht ausschließlich über das öffentliche Internet kommunizieren sollen.
Unternehmen betreiben heute häufig hybride Infrastrukturen.
Ein Teil ihrer Anwendungen läuft in Public Clouds.
Ein anderer Teil befindet sich in eigenen Rechenzentren.
Weitere Systeme laufen möglicherweise an Edge-Standorten oder bei spezialisierten Infrastrukturprovidern.
In solchen Architekturen kann eine direkte oder private Verbindung deutlich interessanter sein als der Weg über das öffentliche Internet.
Über die Infrastruktur der JD Group lassen sich deshalb auch individuelle Netzwerkservices realisieren:
private Layer-2- und Layer-3-Übergaben, kundenspezifische BGP-Anbindungen, dedizierte VLAN- und VRF-Strukturen oder direkte Standortanbindungen.
Auch private Interconnects zu bestehenden Cloud-Umgebungen sind möglich.
Damit kann die ayedo Edge Cloud perspektivisch nicht nur ein Ziel im öffentlichen Internet sein.
Sie kann Teil der bestehenden Netzwerktopologie eines Unternehmens werden.
Sicherheit beginnt ebenfalls im Routing
Auch DDoS-Schutz ist letztlich zu einem erheblichen Teil eine Netzwerkaufgabe.
Innerhalb von AS204197 stehen dafür verschiedene Mechanismen zur Verfügung.
Traffic und Netzwerkzustände werden kontinuierlich überwacht. Bei Angriffen können betroffene Zieladressen über Remote Triggered Blackholing gezielt aus dem Routing genommen werden.
Der entscheidende Punkt dabei ist die Granularität.
Statt einen vollständigen Standort oder ein gesamtes Kundennetz vom Netz zu nehmen, können einzelne betroffene IP-Adressen isoliert werden.
Zusätzlich können Maßnahmen über Upstream-Partner eskaliert und bei Bedarf externe Scrubbing-Dienste eingebunden werden.
Für eine verteilte Plattform ist auch das Teil der Resilienzstrategie.
Nicht jeder Fehler lässt sich verhindern.
Entscheidend ist, seine Auswirkungen möglichst klein zu halten.
Zusammenarbeit auf Augenhöhe
Wie bereits bei unserem ersten Partner Spotlight gilt auch hier:
Technologie ist nur ein Teil einer Infrastrukturpartnerschaft.
Die Anforderungen einer Edge-Plattform verändern sich kontinuierlich.
Neue Standorte kommen hinzu. Routingkonzepte entwickeln sich weiter. Kunden benötigen private Anbindungen oder ungewöhnliche Netzwerkarchitekturen. Kapazitäten müssen erweitert und Failure Domains neu bewertet werden.
Standardisierte Produktkataloge stoßen bei solchen Anforderungen schnell an Grenzen.
Die JD Group verfolgt hier einen Ansatz, der gut zu unserer Arbeitsweise passt: direkte technische Ansprechpartner, kurze Entscheidungswege und die Möglichkeit, Netzwerk- und Routinglösungen an konkrete Anforderungen anzupassen.
Gerade wenn Compute, Netzwerk und Plattformarchitektur zusammen gedacht werden sollen, ist dieser direkte technische Austausch entscheidend.
Eine leistungsfähige Edge Cloud beginnt im Netzwerk
Kubernetes ist ein wichtiger Bestandteil unserer Plattform.
Compute ebenfalls.
Storage auch.
Aber keiner dieser Bausteine allein ergibt eine Edge Cloud.
Die tatsächliche User Experience hängt ebenso davon ab, wo ein Standort liegt, wie er angebunden ist, welche Peering-Beziehungen zur Verfügung stehen, welche Routingpfade genutzt werden und wie die Infrastruktur auf den Ausfall einzelner Carrier oder Netzwerkkomponenten reagiert.
Genau deshalb bauen wir die ayedo Edge Cloud gemeinsam mit Partnern auf, die unterschiedliche Teile dieser Infrastruktur beherrschen.
Mit der JD Group kommt ein weiterer davon hinzu.
Der neue PoP in Alsbach erweitert nicht nur unsere verfügbare Compute-Infrastruktur.
Er erweitert die Netzwerkarchitektur hinter unserer Plattform.
Und genau dort beginnt für uns Edge.
Eine leistungsfähige Edge Cloud beginnt im Netzwerk.