Was wir tun · Netzwerk: Rechenzentrums-Fabric: EVPN/VXLAN auf Cisco Nexus
Bei Digital Realty Athens hängt jeder Server, jedes Blade-Chassis, jeder Storage-Host und jede Kunden-Firewall, die wir betreiben, an einer Cisco Nexus 9000 Leaf-und-Spine-Fabric mit BGP EVPN und VXLAN. Jeder Host ist doppelt angebunden, jedes VLAN kann auf jedem Leaf leben, und Ihr Gateway hat überall dieselbe Adresse, sodass Workloads umziehen und umschalten, ohne dass Adressen geändert werden müssen.
Was es ist
Eine Clos-Fabric: Spines oben, Leaf-Paare darunter, Border Leaves, die gerouteten Verkehr an unsere Edge-Router übergeben. EVPN ist die Control Plane, die Switches lernen also über BGP, wo jede Adresse lebt, statt es durch Fluten herauszufinden. VXLAN trägt jedes Layer-2-Segment durch die Fabric, was bedeutet, dass Ihr Netzwerk nicht an das Rack gebunden ist, in dem Ihr Server zufällig steht.
Wie wir es bauen
- Spines als reine Route Reflectors. Auf den Spines leben keine Tunnelendpunkte, by design.
- Leaves in vPC-Paaren. Server hängen mit LACP-Port-Channels an, die echte virtuelle Port-Channels über beide Switches eines Paars sind.
- Deterministische Blade-Verkabelung. HPE c7000 Blade-Enclosures hängen über Cisco Nexus 2000 Fabric Extender an, einer pro Fabric-Seite.
- Anycast-Gateways. Auf jedem Leaf.
- Keine Multicast-Abhängigkeit. Broadcast und unbekannter Verkehr werden per BGP Ingress Replication repliziert, was das Underlay einfach und vorhersehbar hält.
- Eine Nummerierungsregel, maschinell durchgesetzt. Der VXLAN-Identifier jedes Segments wird nach einer festen Regel aus seinem lokalen VLAN abgeleitet, mit expliziten Route Targets. Eine automatische Prüfung liest stündlich die vollständige Zuordnung von jedem Leaf, bestätigt, dass die Leaves identisch sind und die Regel einhalten, und vergleicht einen kryptografischen Fingerabdruck der gesamten Zuordnung mit einer signierten Baseline in der Versionskontrolle. Drift alarmiert einen Ingenieur. Eine beabsichtigte Änderung muss neu signiert werden, sodass jede Fabric-Änderung einen Autor und eine Prüfspur trägt.
- Natives Routing für Container-Plattformen. Kubernetes- und OpenShift-Cluster announcieren ihre öffentlichen Service-Adressen per eBGP von jedem Knoten an beide Leaves seines Paars in die Fabric, mit BFD für Fehlererkennung unter zwei Sekunden und Prefix-Listen, die auf exakte Host-Routen eingeengt sind.
- Bonds, die beide Links nutzen. Jeder gebondete Server, den wir bauen, hasht auf Layer 3 und Layer 4, mit passend eingestellter Switch-Seite, sodass parallele Flows tatsächlich über beide Mitglieder verteilt werden.
Wovor es Sie schützt
- Vor dem Ausfall eines einzelnen Switches, Links, Fabric Extenders oder einer NIC, der Ihren Host offline nimmt.
- Vor einem vertippten VLAN- oder VXLAN-Identifier, der stillschweigend die Netzwerke zweier Mandanten verbindet.
- Vor langsamem Failover, bei dem eine öffentliche Adresse Minuten statt Sekunden zum Umziehen braucht.
- Davor, dass eine routinemäßige VLAN-Ergänzung bestehende VLANs von einem laufenden Trunk entfernt.
- Davor, zwei Links zu bezahlen und einen zu nutzen.
In der Praxis
Failover durch Test bewiesen. In einem kontrollierten Ausfalltest haben wir einen Container-Cluster-Knoten neu gestartet, während er der bevorzugte Pfad für eine laufende öffentliche Adresse war. Die Fabric konvergierte etwa drei Sekunden später auf einen gesunden Knoten, und die öffentliche Adresse verließ die Routing-Tabelle der Fabric nie.
Ein Blade-Rack verkabelt, bevor die Blades ankamen. Vor dem Start neuer Kundenplattformen haben wir die komplette Port-Channel- und vPC-Topologie für ein ganzes Blade-Rack in einem Durchgang gebaut, bevor die meisten Blades physisch existierten. Jedes Datenbank-Cluster wurde so platziert, dass jede Replik in einem anderen Chassis sitzt, sodass kein einzelnes Chassis das Quorum brechen kann. Der Starttag war ein Einschalten, keine Verkabelungsarbeit.
Beide Links jedes Bonds in Nutzung. Nach jedem gebondeten Aufbau lesen wir die Zähler pro Port aus, um zu beweisen, dass beide Links Verkehr tragen.
Warum EuroVPS
- Eine echte EVPN/VXLAN-Fabric auf Cisco Nexus 9000, dieselbe Architektur, die große Unternehmen und Carrier betreiben.
- Dual-Homing für jeden Host, nicht nur für die teuren.
- Mandantentrennung, stündlich maschinell geprüft, gegen eine signierte Aufzeichnung dessen, was die Fabric sein soll.
- Container-Ingress nativ mit BFD geroutet, nicht über einen einzelnen Load Balancer angeschraubt.
Häufige Fragen
Ist mein Verkehr von anderen Kunden isoliert? Ja. Ihre Segmente tragen ihre eigenen Identifier und Route Targets, und die stündliche Integritätsprüfung existiert genau dafür, dass eine versehentliche Brücke zwischen Mandanten unmöglich zu übersehen ist.
Was passiert, wenn ein Switch ausfällt? Ihr Server ist über beide Switches eines Paars gebondet, und Ihr Gateway existiert auf jedem Leaf. Der Verkehr läuft über den verbleibenden Switch weiter.
Kann ich eigene VLANs und Subnetze bekommen? Ja. Dedizierte Segmente und öffentliche Subnetze werden als Anycast-Gateways über die Fabric gebaut, ohne die Konfiguration von irgendjemand anderem anzufassen.
Kann mein Kubernetes-Cluster seine eigenen Service-Adressen announcieren? Ja. Wir peeren jeden Knoten per eBGP mit BFD mit der Fabric, sodass ein ausgefallener Knoten in Sekunden umgangen wird.
Wenn Sie Ihre Server auf einer Fabric wollen, die so gebaut und geprüft wird, sprechen Sie mit einem Ingenieur.
Ihr nächster Infrastrukturpartner
Sehen wir uns Ihre Umgebung an.
Erzählen Sie uns, was Sie heute betreiben und was besser werden muss. Ein Ingenieur sieht Ihre Anfrage durch und hilft Ihnen, den nächsten Schritt zu planen.
+357 222 32280
Beginnen wir mit Ihrer Umgebung.
Ein wenig Kontext hilft uns, das richtige Gespräch zu beginnen.