In den ersten beiden Artikeln habe ich das Thema Automatisierung angesprochen und deren Rahmen skizziert, im zweiten habe ich einen Exkurs in die Netzwerkvirtualisierung als ersten Ansatz zur Automatisierung der Servicekonfiguration gemacht.
Jetzt ist es an der Zeit, ein Diagramm des physischen Netzwerks zu zeichnen.

Wenn Sie mit der Organisation von Rechenzentrumsnetzwerken noch nicht auf dem richtigen Weg sind, empfehle ich Ihnen dringend, damit anzufangen Artikel über sie.

Alle Veröffentlichungen:

• 0. ADSM. Teil Null. Planung
• 1. ADSM. Teil eins (der nach Null liegt). Netzwerkvirtualisierung
• 2. ADSM. Zweiter Teil. Netzwerk-Design

Die in dieser Serie beschriebenen Praktiken sollten auf jede Art von Netzwerk, jede Größe und jede Vielzahl von Anbietern anwendbar sein (nein). Es ist jedoch unmöglich, ein universelles Beispiel für die Anwendung dieser Ansätze zu beschreiben. Daher werde ich mich auf die moderne Architektur des DC-Netzwerks konzentrieren: Kloz-Fabrik.
Wir werden DCI auf MPLS L3VPN durchführen.

Zusätzlich zum physischen Netzwerk gibt es ein Overlay-Netzwerk vom Host (dies kann OpenStacks VXLAN oder Tungsten Fabric oder alles andere sein, das nur grundlegende IP-Konnektivität vom Netzwerk erfordert).

In diesem Fall erhalten wir ein relativ einfaches Automatisierungsszenario, da viele Geräte auf die gleiche Weise konfiguriert sind.

Wir wählen einen kugelförmigen Gleichstrom im Vakuum:

• Überall eine Designversion.
• Zwei Anbieter bilden zwei Netzwerkebenen.
• Ein DC ist wie ein anderer wie zwei Tropfen Wasser.

Inhalt

• Physikalische Topologie
• Routenführung
• IP-Plan
• Laba
• Abschluss
• Nützliche Links

Lassen Sie beispielsweise unseren Dienstleister LAN_DC Schulungsvideos über das Überleben festgefahrener Aufzüge hosten.

In Megastädten erfreut sich dies großer Beliebtheit, sodass viele physische Maschinen erforderlich sind.

Zunächst beschreibe ich das Netzwerk ungefähr so, wie ich es sehen möchte. Und dann werde ich es für das Labor vereinfachen.

Physikalische Topologie

Standorte

LAN_DC wird 6 DCs haben:

• Russland (RU):
  • Moskau (msk)
  • Kasan (kzn)

• Spanien (SP):
  • Barcelona (bcn)
  • Málaga (mlg)

• China (CN):
  • Shanghai (sha)
  • Xi'an (beide)

Im DC (Intra-DC)

Alle DCs verfügen über identische interne Konnektivitätsnetzwerke basierend auf der Klose-Topologie.
Was sind Kloz-Netzwerke und warum genau sind sie das? Artikel.

Jeder DC verfügt über 10 Racks mit Maschinen, sie werden mit nummeriert A, B, C Und so weiter.

In jedem Rack befinden sich 30 Maschinen. Sie werden uns nicht interessieren.

Außerdem gibt es in jedem Rack einen Switch, an den alle Maschinen angeschlossen sind – das ist Top-of-the-Rack-Schalter – ToR oder anders, in Bezug auf die Klose-Fabrik, wie wir es nennen werden Blatt.

Allgemeines Schema der Fabrik.

Wir werden sie benennen XXX-BlattYWo XXX - Drei-Buchstaben-Abkürzung DC und Y - Ordnungsnummer. Zum Beispiel, kzn-leaf11.

In meinen Artikeln erlaube ich mir, die Begriffe Leaf und ToR eher leichtfertig als Synonyme zu verwenden. Es muss jedoch daran erinnert werden, dass dies nicht der Fall ist.
ToR ist ein im Rack montierter Switch, mit dem sich Maschinen verbinden.
Leaf ist die Rolle eines Geräts in einem physischen Netzwerk oder eines Switches der ersten Ebene im Sinne der Klose-Topologie.
Das heißt, Leaf != ToR.
So kann ein Leaf beispielsweise ein EndofRaw-Schalter sein.
Im Rahmen dieses Artikels werden wir sie jedoch weiterhin als Synonyme behandeln.

Jeder ToR-Switch ist wiederum mit vier höheren Aggregations-Switches verbunden – Rücken. Unter Spine's wird ein Rack im DC zugewiesen. Wir werden es so benennen: XXX-WirbelsäuleY.

Im selben Rack befinden sich Netzwerkgeräte für die Konnektivität zwischen DCs – 2 Router mit MPLS an Bord. Aber im Großen und Ganzen sind das die gleichen Tors. Das heißt, aus Sicht der Spine-Switches spielt es keine Rolle, was das übliche ToR mit angeschlossenen Maschinen oder ein Router für DCI ist – eine verdammte Sache.

Solche speziellen ToRs werden genannt Randblatt. Wir werden sie benennen XXX-KanteY.

Es wird so aussehen.

Im Diagramm oben habe ich Kante und Blatt tatsächlich auf gleicher Höhe platziert. Klassische dreischichtige Netzwerke lehrte uns, Uplink (daher der Begriff) als Links nach oben zu betrachten. Und hier stellt sich heraus, dass der DCI-„Uplink“ wieder ausfällt, was für einige ein wenig mit der üblichen Logik durchbricht. Bei großen Netzwerken, wenn Rechenzentren in noch kleinere Einheiten unterteilt sind – POD's (Point Of Delivery), individuell zuordnen Edge-PODfür DCI und Zugriff auf externe Netzwerke.

Для удобства восприятия в дальнейшем я буду всё же рисовать Edge над Spine, при этом мы будем держать в уме, что никакого интеллекта на Spine и отличий при работе с обычными Leaf и с Edge-leaf нет (хотя тут могут быть нюансы, но в целом ist das so).

Fabrikdiagramm mit Kantenblättern.

Die Dreifaltigkeit Blatt, Wirbelsäule und Kante bildet ein Unterlagenetzwerk oder eine Unterlage.

Die Aufgabe der Netzwerkfabrik (lesen Sie Underlay), wie wir bereits in definiert haben letztes Problem, sehr, sehr einfach – IP-Konnektivität zwischen Maschinen sowohl innerhalb desselben DC als auch zwischen ihnen bereitzustellen.
Aus diesem Grund wird das Netzwerk als Fabrik bezeichnet, genau wie beispielsweise eine Schaltfabrik in modularen Netzwerkkästen, über die Sie mehr in lesen können SDSM14.

Im Allgemeinen wird eine solche Topologie als Fabrik bezeichnet, da Fabric in der Übersetzung ein Fabric ist. Und es ist schwer, anderer Meinung zu sein:

Die Fabrik ist komplett L3. Keine VLANs, kein Broadcast – das sind die wunderbaren Programmierer, die wir in LAN_DC haben, sie können Anwendungen schreiben, die im L3-Paradigma leben, und virtuelle Maschinen erfordern keine Live-Migration mit Speicherung der IP-Adresse.

Und noch einmal: Die Antwort auf die Frage, warum die Fabrik und warum L3 in einem separaten ist Artikel.

DCI – Data Center Interconnect (Inter-DC)

DCI wird mit Hilfe von Edge-Leaf organisiert, das heißt, sie sind unser Ausgangspunkt zur Autobahn.
Der Einfachheit halber gehen wir davon aus, dass DCs durch direkte Verbindungen miteinander verbunden sind.
Den externen Zusammenhang schließen wir von der Betrachtung aus.

Mir ist bewusst, dass ich jedes Mal, wenn ich eine Komponente entferne, das Netzwerk erheblich vereinfache. Und wenn wir unser abstraktes Netzwerk automatisieren, wird alles gut, aber im echten Netzwerk werden Krücken auftauchen.
Ist das so. Und doch geht es in dieser Serie darum, Lösungsansätze zu denken und zu erarbeiten, und nicht darum, fiktive Probleme heroisch zu lösen.

Bei Edge-Leafs wird das Underlay im VPN platziert und über das MPLS-Backbone (die gleiche direkte Verbindung) übertragen.

Hier ist ein solches Top-Level-Schema erhalten.

Routenführung

Für das Routing innerhalb des DC verwenden wir BGP.
Auf dem OSPF+LDP MPLS-Backbone.
Für DCI ist das die Organisation der Konnektivität im Underlay – BGP L3VPN über MPLS.

Allgemeines Routing-Schema

Im Werk gibt es kein OSPF und ISIS (Routing-Protokoll in der Russischen Föderation verboten).

Und das bedeutet, dass es keine automatische Erkennung und Berechnung der kürzesten Wege gibt – sondern nur manuelle (eigentlich automatische – wir sprechen hier von Automatisierung) Protokoll-, Nachbarschafts- und Richtlinieneinstellungen.

BGP-Routing-Schema innerhalb von DC

Warum BGP?

Es gibt gesamter RFC benannt nach Facebook und Arista, das erklärt, wie man baut sehr groß Rechenzentrumsnetzwerke mit BGP. Es liest sich fast wie eine Fiktion, ich kann es für einen entspannten Abend wärmstens empfehlen.

Auch diesem Thema ist in meinem Artikel ein ganzer Abschnitt gewidmet. Wohin kann ich dich bringen und schicken.

Dennoch ist kein IGP für Netzwerke großer Rechenzentren geeignet, in denen die Anzahl der Netzwerkgeräte in die Tausende geht.

Darüber hinaus können Sie durch die Verwendung von BGP überall nicht auf die Unterstützung mehrerer verschiedener Protokolle und die Synchronisierung zwischen ihnen verzichten.

Hand aufs Herz, in unserer Fabrik, die höchstwahrscheinlich nicht so schnell wachsen wird, würde OSPF für unsere Augen ausreichen. Das ist tatsächlich das Problem der Mega-Scaler und Cloud-Titanen. Aber lassen Sie uns nur für ein paar Probleme davon ausgehen, dass wir es brauchen und BGP verwenden werden, wie es Peter Lapukhov hinterlassen hat.

Routing-Richtlinien

Auf Leaf-Switches importieren wir Präfixe von Underlay-Netzwerkschnittstellen in BGP.
Wir werden dazwischen eine BGP-Sitzung haben jeder ein Paar Leaf-Spine, in dem diese Underlay-Präfixe hier und da über das Netzwerk bekannt gegeben werden.

Innerhalb eines Rechenzentrums werden wir die Details verteilen, die wir in Tor importiert haben. Auf Edge-Leafs werden wir sie aggregieren und an Remote-DCs bekannt geben und an Tors senden. Das heißt, jeder Tor weiß genau, wie er zu einem anderen Tor im selben DC gelangt und wo sich der Einstiegspunkt befindet, um zum Tor in einem anderen DC zu gelangen.

In DCI werden Routen als VPNv4 übertragen. Dazu wird auf dem Edge-Leaf die Schnittstelle zur Fabrik im VRF platziert, nennen wir es UNDERLAY, und die Nachbarschaft mit dem Spine auf dem Edge-Leaf wird innerhalb des VRF und zwischen den Edge-Leafs ansteigen in der VPNv4-Familie.

Wir werden auch die erneute Ankündigung von Routen, die wir von Spines erhalten haben, an diese verbieten.

Auf Leaf und Spine importieren wir keine Loopbacks. Wir benötigen sie nur zur Ermittlung der Router-ID.

Aber auf Edge-Leafs importieren wir es in Global BGP. Zwischen Loopback-Adressen bauen Edge-Leafs untereinander eine BGP-Sitzung in einer IPv4-VPN-Familie auf.

Zwischen EDGE-Geräten verfügen wir über einen Trunk, der auf OSPF + LDP ausgeweitet ist. Alles in einer Zone. Extrem einfache Konfiguration.

Hier ist ein Bild mit Routing.

BGP-ASN

Edge Leaf ASN

Auf Edge-Leafs wird es in allen DCs eine ASN geben. Es ist wichtig, dass zwischen den Edge-Leafs iBGP vorhanden ist, damit wir nicht auf die Nuancen von eBGP stoßen. Lassen Sie es 65535 sein. In Wirklichkeit könnte es eine öffentliche AS-Nummer sein.

Wirbelsäulen-ASN

Auf Spine haben wir eine ASN pro DC. Beginnen wir hier mit der allerersten Nummer aus dem Bereich der privaten AS – 64512, 64513 usw.

Warum ASN auf DC?

Zerlegen wir diese Frage in zwei Teile:

• Warum die gleiche ASN auf allen Spines eines DCs?
• Warum unterscheiden sie sich in verschiedenen DCs?

Warum die gleiche ASN auf allen Spines eines DC?

So sieht der AS-Pfad der Underlay-Route auf dem Edge-Leaf aus:
[leafX_ASN, spine_ASN, edge_ASN]
Beim Versuch, es an Spine zurückzumelden, wird es gelöscht, da sein AS (Spine_AS) bereits auf der Liste steht.

Innerhalb des DC sind wir jedoch vollkommen davon überzeugt, dass die Underlay-Routen, die bis zum Rand aufgestiegen sind, nicht absteigen können. Die gesamte Kommunikation zwischen Hosts innerhalb eines DC muss innerhalb der Spine-Ebene erfolgen.

Gleichzeitig erreichen die aggregierten Routen anderer DCs in jedem Fall frei Tors – ihr AS-Pfad enthält nur ASN 65535 – die Anzahl der AS Edge-Leafs, da sie auf ihnen erstellt wurden.

Warum sind sie in verschiedenen DCs unterschiedlich?

Theoretisch müssen wir möglicherweise Loopback und einige virtuelle Dienstmaschinen zwischen DCs verschieben.

Auf dem Host führen wir beispielsweise Route Reflector oder aus das gleiche VNGW (Virtual Network Gateway), das sich über BGP mit Tor verbindet und seinen Loopback ankündigt, der von allen DCs verfügbar sein sollte.

So sieht sein AS-Pfad aus:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

Und es sollte nirgendwo wiederholte ASNs geben.

Das heißt, Spine_DC1 und Spine_DC2 müssen unterschiedlich sein, genau wie leafX_DC1 und leafY_DC2, und das ist genau das, was wir anstreben.

Wie Sie wahrscheinlich wissen, gibt es Hacks, die es Ihnen ermöglichen, Routen mit doppelten ASNs trotz des Loop-Prevention-Mechanismus (allowas-in bei Cisco) zu akzeptieren. Und es hat sogar legitime Verwendungsmöglichkeiten. Dies ist jedoch eine potenzielle Lücke in der Stabilität des Netzwerks. Und ich persönlich bin ein paar Mal darauf reingefallen.

Und wenn wir die Möglichkeit haben, keine gefährlichen Dinge zu verwenden, werden wir sie nutzen.

Blatt-ASN

Wir werden auf jedem Leaf-Switch im gesamten Netzwerk eine individuelle ASN haben.
Wir tun dies aus den oben genannten Gründen: AS-Pfad ohne Schleifen, BGP-Konfiguration ohne Lesezeichen.

Damit Routen zwischen Leafs reibungslos verlaufen, sollte AS-Path wie folgt aussehen:
[leafX_ASN, spine_ASN, leafY_ASN]
Dabei wären leafX_ASN und leafY_ASN schön unterschiedlich.

Dies ist auch für die Situation mit der Ankündigung des VNF-Loopbacks zwischen DCs erforderlich:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

Wir werden eine 4-Byte-ASN verwenden und diese basierend auf der ASN des Spine und der Nummer des Leaf-Switches generieren, und zwar wie folgt: Spine_ASN.0000X.

Hier ist so ein Bild mit ASN.

IP-Plan

Grundsätzlich müssen wir Adressen für die folgenden Verbindungen vergeben:

1. Unterlegen Sie Netzwerkadressen zwischen ToR und Maschine. Sie müssen im gesamten Netzwerk eindeutig sein, damit jede Maschine mit jeder anderen kommunizieren kann. Tolle Passform 10/8. Für jedes Rack / 26 mit einem Rand. Wir werden 19 US-Dollar pro DC und 17 US-Dollar pro Region zuweisen.
2. Linkadressen zwischen Leaf/Tor und Spine.

   Ich möchte sie algorithmisch zuweisen, also aus den Namen der zu verbindenden Geräte berechnen.

   Lass es sein... 169.254.0.0/16.
   Nämlich 169.254.00X.Y/31Wo X - Rückennummer, Y — P2P-Netzwerk /31.
   Dadurch können Sie bis zu 128 Racks und bis zu 10 Spine im DC betreiben. Link-Adressen können (und werden) von DC zu DC wiederholt werden.

3. Joint Spine – Edge-Leaf-Organisation in Subnetzen 169.254.10X.Y/31, wo genau das gleiche X - Rückennummer, Y — P2P-Netzwerk /31.
4. Verknüpfen Sie Adressen vom Edge-Leaf mit dem MPLS-Backbone. Hier ist die Situation etwas anders – die Zusammenführung aller Teile zu einem Kuchen, sodass Sie nicht die gleichen Adressen wiederverwenden können – Sie müssen das nächste freie Subnetz auswählen. Daher nehmen wir als Grundlage 192.168.0.0/16 und wir werden uns davon befreien.
5. Loopback-Adressen. Geben wir ihnen die ganze Bandbreite 172.16.0.0/12.
   • Blatt – jeweils 25/128 im DC – die gleichen 23 Racks. Weisen Sie /XNUMX pro Region zu.
   • Wirbelsäule – um /28 auf dem DC – bis zu 16 Wirbelsäule. Weisen Sie /26 pro Region zu.
   • Edge-Leaf – /29 bei DC – bis zu 8 Boxen. Weisen Sie 27/XNUMX pro Region zu.

Wenn wir nicht genügend zugewiesene Bereiche im DC haben (und das wollen wir auch nicht – wir geben vor, Hyperscaler zu sein), wählen wir einfach den nächsten Block aus.

Hier ist ein Bild mit IP-Adressierung.

Loopbacks:

Präfix
Geräterolle
Region
Gleichstrom

172.16.0.0/23
Rand
 
 

172.16.0.0/27
ru
 

172.16.0.0/29
msk

172.16.0.8/29
kzn

172.16.0.32/27
sp
 

172.16.0.32/29
bcn

172.16.0.40/29
mlg

172.16.0.64/27
cn
 

172.16.0.64/29
sha

172.16.0.72/29
beide

172.16.2.0/23
Rückgrat
 
 

172.16.2.0/26
ru
 

172.16.2.0/28
msk

172.16.2.16/28
kzn

172.16.2.64/26
sp
 

172.16.2.64/28
bcn

172.16.2.80/28
mlg

172.16.2.128/26
cn
 

172.16.2.128/28
sha

172.16.2.144/28
beide

172.16.8.0/21
Blatt
 
 

172.16.8.0/23
ru
 

172.16.8.0/25
msk

172.16.8.128/25
kzn

172.16.10.0/23
sp
 

172.16.10.0/25
bcn

172.16.10.128/25
mlg

172.16.12.0/23
cn
 

172.16.12.0/25
sha

172.16.12.128/25
beide

Unterlage:

Präfix
Region
Gleichstrom

10.0.0.0/17
ru
 

10.0.0.0/19
msk

10.0.32.0/19
kzn

10.0.128.0/17
sp
 

10.0.128.0/19
bcn

10.0.160.0/19
mlg

10.1.0.0/17
cn
 

10.1.0.0/19
sha

10.1.32.0/19
beide

Laba

Zwei Anbieter. Ein Netzwerk. ADSM.

Wacholder + Arista. Ubuntu. Gute alte Eva.

Die Menge an Ressourcen auf unserer virtuellen Maschine in Miran ist immer noch begrenzt, daher werden wir zum Üben ein so vereinfachtes Netzwerk bis zum Äußersten nutzen.

Zwei Rechenzentren: Kasan und Barcelona.

• Jeweils zwei Drehungen: Juniper und Arista.
• Jeweils ein Torus (Blatt) – Juniper und Arista, mit einem verbundenen Host (nehmen wir hierfür eine leichte Cisco IOL).
• Je ein Edge-Leaf-Knoten (bisher nur Juniper).
• Ein Cisco-Switch, der sie alle beherrscht.
• Zusätzlich zu den Netzwerkboxen wurde ein virtueller Maschinenmanager eingeführt. Unter Ubuntu.
  Es hat Zugriff auf alle Geräte, es führt IPAM-/DCIM-Systeme, eine Reihe von Python-Skripten, Ansible und alles andere aus, was wir benötigen.

Vollständige Konfiguration aller Netzwerkgeräte, die wir durch Automatisierung zu reproduzieren versuchen werden.

Abschluss

Wird es auch akzeptiert? Unter jedem Artikel eine kurze Schlussfolgerung ziehen?

Also haben wir uns entschieden dreistufig Kloz-Netzwerk innerhalb des DC, weil wir viel Ost-West-Verkehr erwarten und ECMP wollen.

Das Netzwerk wurde in physisches (Underlay) und virtuelles (Overlay) unterteilt. Gleichzeitig geht das Overlay vom Host aus – wodurch die Anforderungen an das Underlay vereinfacht werden.

Aufgrund seiner Skalierbarkeit und Richtlinienflexibilität wurde BGP als Router-Routing-Protokoll ausgewählt.

Wir werden separate Knoten für die Organisation von DCI haben – Edge-leaf.
Auf dem Backbone wird es OSPF+LDP geben.
DCI wird basierend auf MPLS L3VPN implementiert.
Für P2P-Links berechnen wir IP-Adressen algorithmisch basierend auf Gerätenamen.
Loopbacks werden nacheinander entsprechend der Rolle der Geräte und ihrem Standort zugewiesen.
Unterlagepräfixe – nur bei Leaf-Schaltern in Reihe basierend auf ihrer Position.

Nehmen wir an, dass wir derzeit keine Geräte installiert haben.
Daher werden unsere nächsten Schritte darin bestehen, sie in Systeme (IPAM, Inventar) zu integrieren, den Zugriff zu organisieren, eine Konfiguration zu generieren und diese bereitzustellen.

Im nächsten Artikel befassen wir uns mit Netbox, einem Inventarisierungs- und Verwaltungssystem für den IP-Bereich in einem DC.

Danke

• Andrey Glazkov alias @glazgoo für das Korrekturlesen und Bearbeiten
• Alexander Klimenko alias @v00lk für Korrekturlesen und Korrekturen
• Artyom Chernobay für KDPV

Source: habr.com