В vorherige Ausgabe Ich habe das Netzwerkautomatisierungs-Framework beschrieben. Nach Ansicht einiger Leute wurden bereits mit dieser ersten Herangehensweise an das Problem einige Fragen geklärt. Und das freut mich sehr, denn unser Ziel im Zyklus ist nicht, Ansible mit Python-Skripten zu überdecken, sondern ein System aufzubauen.

Derselbe Rahmen legt die Reihenfolge fest, in der wir uns mit der Frage befassen.
Und die Netzwerkvirtualisierung, der sich diese Ausgabe widmet, passt nicht besonders in das ADSM-Thema, in dem wir die Automatisierung analysieren.

Aber schauen wir es uns aus einem anderen Blickwinkel an.

Viele Dienste nutzen schon seit langem dasselbe Netzwerk. Im Falle eines Telekommunikationsbetreibers sind dies beispielsweise 2G, 3G, LTE, Breitband und B2B. Im Falle eines DC: Konnektivität für verschiedene Clients, Internet, Blockspeicher, Objektspeicher.

Und alle Dienste erfordern eine Isolierung voneinander. So entstanden Overlay-Netzwerke.

Und alle Dienste möchten nicht darauf warten, dass eine Person sie manuell konfiguriert. So entstanden Orchestratoren und SDN.

Der erste Ansatz zur systematischen Automatisierung des Netzwerks bzw. eines Teils davon wird schon lange verfolgt und an vielen Stellen umgesetzt: VMWare, OpenStack, Google Compute Cloud, AWS, Facebook.

Damit beschäftigen wir uns heute.

Inhalt

• Gründe
• Vocabulary
• Unterlage – physisches Netzwerk
• Overlay – virtuelles Netzwerk
  • Überlagerung mit ToR
  • Overlay vom Host
  • Am Beispiel von Wolframgewebe
    • Kommunikation innerhalb einer einzelnen physischen Maschine
    • Kommunikation zwischen VMs, die sich auf verschiedenen physischen Maschinen befinden
    • Ausgang zur Außenwelt

• FAQ
• Abschluss
• Nützliche Links

Gründe

Und da wir gerade darüber reden, ist es erwähnenswert, die Voraussetzungen für die Netzwerkvirtualisierung zu erwähnen. Tatsächlich hat dieser Prozess erst gestern begonnen.

Sie haben wahrscheinlich mehr als einmal gehört, dass das Netzwerk schon immer der trägeste Teil eines jeden Systems war. Und das stimmt in jeder Hinsicht. Das Netzwerk ist die Basis, auf der alles ruht, und es ist ziemlich schwierig, daran Änderungen vorzunehmen – Dienste tolerieren es nicht, wenn das Netzwerk ausfällt. Oftmals kann die Stilllegung eines einzelnen Knotens dazu führen, dass ein großer Teil der Anwendungen lahmgelegt wird und viele Kunden betroffen sind. Dies ist zum Teil der Grund, warum das Netzwerkteam sich möglicherweise jeder Änderung widersetzt – denn jetzt funktioniert es irgendwie (Wir wissen vielleicht nicht einmal wie), aber hier müssen Sie etwas Neues konfigurieren, und es ist nicht bekannt, wie sich dies auf das Netzwerk auswirkt.

Um nicht darauf zu warten, dass Netzwerker VLANs einfügen und keine Dienste auf jedem Netzwerkknoten registrieren, kam man auf die Idee, Overlays – Overlay-Netzwerke – zu verwenden, von denen es eine große Vielfalt gibt: GRE, IPinIP, MPLS, MPLS L2/L3VPN, VXLAN, GENEVE, MPLSoverUDP, MPLSoverGRE usw.

Ihr Reiz liegt in zwei einfachen Dingen:

• Es werden nur Endknoten konfiguriert – Transitknoten müssen nicht berührt werden. Dies beschleunigt den Prozess erheblich und ermöglicht es Ihnen manchmal, die Netzwerkinfrastrukturabteilung vollständig von der Einführung neuer Dienste auszuschließen.
• Die Last ist tief in den Headern verborgen – Transitknoten müssen nichts darüber wissen, weder über die Adressierung auf den Hosts noch über die Routen des Overlay-Netzwerks. Das bedeutet, dass Sie weniger Informationen in Tabellen speichern müssen, was die Verwendung eines einfacheren/kostengünstigeren Geräts bedeutet.

In dieser nicht ganz erschöpfenden Ausgabe möchte ich nicht alle möglichen Technologien analysieren, sondern vielmehr die Rahmenbedingungen für den Betrieb von Overlay-Netzwerken in DCs beschreiben.

Die gesamte Serie beschreibt ein Rechenzentrum, das aus Reihen identischer Racks besteht, in denen die gleichen Servergeräte installiert sind.

Auf dieser Ausrüstung werden virtuelle Maschinen/Container/Serverlos ausgeführt, die Dienste implementieren.

Vocabulary

In einem Kreislauf Server Ich werde ein Programm nennen, das die Serverseite der Client-Server-Kommunikation implementiert.

Physische Maschinen in Racks werden als Server bezeichnet nicht wir werden.

Physische Maschine — x86-Computer in einem Rack installiert. Der am häufigsten verwendete Begriff Gastgeber. So nennen wir es“Maschine"Oder Gastgeber.

Hypervisor – eine Anwendung, die auf einer physischen Maschine ausgeführt wird und die physischen Ressourcen emuliert, auf denen virtuelle Maschinen ausgeführt werden. Manchmal wird in der Literatur und im Internet das Wort „Hypervisor“ als Synonym für „Host“ verwendet.

Virtuelle Maschine – ein Betriebssystem, das auf einer physischen Maschine auf einem Hypervisor läuft. Für uns in diesem Zyklus ist es eigentlich egal, ob es sich tatsächlich um eine virtuelle Maschine oder nur um einen Container handelt. Nennen wir es „VM«

Mieter ist ein weit gefasstes Konzept, das ich in diesem Artikel als separaten Dienst oder separaten Client definieren werde.

Mandantenfähigkeit oder Mandantenfähigkeit – die Nutzung derselben Anwendung durch verschiedene Clients/Dienste. Gleichzeitig wird die Isolierung der Clients voneinander durch die Anwendungsarchitektur und nicht durch separat laufende Instanzen erreicht.

ToR – Top-of-the-Rack-Schalter - ein in einem Rack installierter Switch, an den alle physischen Maschinen angeschlossen sind.

Zusätzlich zur ToR-Topologie praktizieren verschiedene Anbieter End of Row (EoR) oder Middle of Row (wobei letzteres eine abwertende Seltenheit ist und ich die Abkürzung MoR nicht gesehen habe).

Underlay-Netzwerk oder das zugrunde liegende Netzwerk oder die Unterlage ist die physische Netzwerkinfrastruktur: Switches, Router, Kabel.

Overlay-Netzwerk oder Overlay-Netzwerk oder Overlay – ein virtuelles Netzwerk von Tunneln, die über dem physischen Netzwerk laufen.

L3-Fabric oder IP-Fabric - eine erstaunliche Erfindung der Menschheit, die es Ihnen ermöglicht, STP zu wiederholen und TRILL für Vorstellungsgespräche zu lernen. Ein Konzept, bei dem das gesamte Netzwerk bis zur Zugriffsebene ausschließlich L3 ist, ohne VLANs und dementsprechend riesige erweiterte Broadcast-Domänen. Wir werden im nächsten Teil untersuchen, woher das Wort „Fabrik“ kommt.

SDN - Softwaredefiniertes Netzwerk. Braucht kaum eine Einführung. Ein Ansatz zur Netzwerkverwaltung, bei dem Änderungen am Netzwerk nicht von einer Person, sondern von einem Programm vorgenommen werden. Normalerweise bedeutet dies, dass die Steuerungsebene über die Endnetzwerkgeräte hinaus zum Controller verschoben wird.

NFV - Netzwerkfunktionsvirtualisierung – Virtualisierung von Netzwerkgeräten. Dies bedeutet, dass einige Netzwerkfunktionen in Form von virtuellen Maschinen oder Containern ausgeführt werden können, um die Implementierung neuer Dienste zu beschleunigen, die Dienstverkettung zu organisieren und die horizontale Skalierbarkeit zu vereinfachen.

VNF - Virtuelle Netzwerkfunktion. Spezifisches virtuelles Gerät: Router, Switch, Firewall, NAT, IPS/IDS usw.

Ich vereinfache die Beschreibung nun bewusst auf eine konkrete Implementierung, um den Leser nicht zu sehr zu verwirren. Für eine nachdenklichere Lektüre verweise ich ihn auf den Abschnitt Referenzen. Darüber hinaus verspricht Roma Gorge, der diesen Artikel wegen Ungenauigkeiten kritisiert, eine separate Ausgabe über Server- und Netzwerkvirtualisierungstechnologien zu schreiben, die ausführlicher und detailgetreuer ist.

Die meisten Netzwerke lassen sich heute klar in zwei Teile unterteilen:

Unterlage — ein physisches Netzwerk mit einer stabilen Konfiguration.
Auflage – Abstraktion über Underlay zur Isolierung von Mietern.

Dies gilt sowohl für DC (den wir in diesem Artikel analysieren werden) als auch für ISP (den wir nicht analysieren werden, weil dies bereits geschehen ist). SDSM). Bei Unternehmensnetzwerken ist die Situation natürlich etwas anders.

Bild mit Fokus auf das Netzwerk:

Unterlage

Die Grundlage bildet ein physisches Netzwerk: Hardware-Switches und Kabel. Geräte im Untergrund wissen, wie sie physische Maschinen erreichen.

Es basiert auf Standardprotokollen und -technologien. Nicht zuletzt, weil Hardware-Geräte bis heute mit proprietärer Software arbeiten, die weder eine Programmierung des Chips noch die Implementierung eigener Protokolle zulässt; daher sind Kompatibilität zu anderen Anbietern und Standardisierung erforderlich.

Aber jemand wie Google kann es sich leisten, eigene Schalter zu entwickeln und allgemein akzeptierte Protokolle aufzugeben. Aber LAN_DC ist nicht Google.

Das Underlay ändert sich relativ selten, da seine Aufgabe die grundlegende IP-Konnektivität zwischen physischen Maschinen ist. Underlay weiß nichts über die darauf laufenden Dienste, Clients oder Mandanten – es muss lediglich das Paket von einer Maschine zur anderen liefern.
Die Unterlage könnte so aussehen:

• IPv4+OSPF
• IPv6+ISIS+BGP+L3VPN
• L2+TRILL
• L2+STP

Das Underlay-Netzwerk wird auf klassische Weise konfiguriert: CLI/GUI/NETCONF.

Manuell, Skripte, proprietäre Dienstprogramme.

Der nächste Artikel der Serie wird sich ausführlicher mit der Unterlage befassen.

Auflage

Overlay ist ein virtuelles Netzwerk aus Tunneln, die sich über Underlay erstrecken. Es ermöglicht den VMs eines Clients, miteinander zu kommunizieren und sorgt gleichzeitig für Isolation von anderen Clients.

Die Client-Daten werden zur Übertragung über das öffentliche Netzwerk in einige Tunneling-Header gekapselt.

So können VMs eines Clients (eines Dienstes) über Overlay miteinander kommunizieren, ohne überhaupt zu wissen, welchen Weg das Paket tatsächlich nimmt.

Overlay könnte zum Beispiel wie oben erwähnt sein:

• GRE-Tunnel
• VXLAN
• EVPN
• L3VPN
• GENEVE

Ein Overlay-Netzwerk wird normalerweise über einen zentralen Controller konfiguriert und verwaltet. Von dort aus werden die Konfiguration, die Steuerungsebene und die Datenebene an Geräte übermittelt, die den Client-Verkehr weiterleiten und kapseln. Ein wenig unten Schauen wir uns das anhand von Beispielen an.

Ja, das ist SDN in seiner reinsten Form.

Es gibt zwei grundsätzlich unterschiedliche Ansätze zur Organisation eines Overlay-Netzwerks:

1. Überlagerung mit ToR
2. Overlay vom Host

Überlagerung mit ToR

Overlay kann beim im Rack stehenden Access Switch (ToR) beginnen, wie es beispielsweise bei einer VXLAN-Fabric der Fall ist.

Dies ist ein bewährter Mechanismus in ISP-Netzwerken und wird von allen Netzwerkgeräteanbietern unterstützt.

Allerdings muss in diesem Fall der ToR-Switch in der Lage sein, die verschiedenen Dienste entsprechend zu trennen, und der Netzwerkadministrator muss in gewissem Umfang mit den Administratoren der virtuellen Maschinen zusammenarbeiten und Änderungen (wenn auch automatisch) an der Konfiguration der Geräte vornehmen .

Hier verweise ich den Leser auf einen Artikel darüber VxLAN auf Habré unser alter Freund @bormoglotx.
Hierin Präsentationen mit ENOG Ansätze zum Aufbau eines DC-Netzwerks mit einer EVPN-VXLAN-Fabric werden ausführlich beschrieben.

Und für ein umfassenderes Eintauchen in die Realität können Sie Tsiskas Buch lesen Eine moderne, offene und skalierbare Struktur: VXLAN EVPN.

Ich stelle fest, dass VXLAN nur eine Kapselungsmethode ist und die Beendigung von Tunneln nicht auf ToR, sondern auf dem Host erfolgen kann, wie es beispielsweise bei OpenStack der Fall ist.

Allerdings ist VXLAN-Fabric, bei dem das Overlay bei ToR beginnt, eines der etablierten Overlay-Netzwerkdesigns.

Overlay vom Host

Ein anderer Ansatz besteht darin, Tunnel auf den Endhosts zu starten und zu beenden.
In diesem Fall bleibt das Netzwerk (Underlay) möglichst einfach und statisch.
Und der Host selbst übernimmt die gesamte erforderliche Kapselung.

Dies erfordert natürlich die Ausführung einer speziellen Anwendung auf den Hosts, aber es lohnt sich.

Erstens ist die Ausführung eines Clients auf einem Linux-Rechner einfacher oder, sagen wir, sogar möglich, während Sie auf einem Switch höchstwahrscheinlich auf proprietäre SDN-Lösungen zurückgreifen müssen, was die Idee der Multi-Vendor-Lösung zunichte macht.

Zweitens kann der ToR-Switch in diesem Fall sowohl aus Sicht der Control Plane als auch der Data Plane so einfach wie möglich gehalten werden. Dann muss er nämlich nicht mit dem SDN-Controller kommunizieren und es müssen auch nicht die Netzwerke/ARPs aller angeschlossenen Clients gespeichert werden – es reicht aus, die IP-Adresse der physischen Maschine zu kennen, was den Wechsel/die Umstellung erheblich vereinfacht. Routing-Tabellen.

In der ADSM-Serie wähle ich den Overlay-Ansatz vom Host aus – dann reden wir nur darüber und kehren nicht zur VXLAN-Fabrik zurück.

Am einfachsten ist es, sich Beispiele anzusehen. Und als Testobjekt nehmen wir die OpenSource-SDN-Plattform OpenContrail, jetzt bekannt als Wolframgewebe.

Am Ende des Artikels werde ich einige Gedanken zur Analogie zu OpenFlow und OpenvSwitch äußern.

Am Beispiel von Wolframgewebe

Jede physische Maschine hat vRouter – ein virtueller Router, der die mit ihm verbundenen Netzwerke kennt und weiß, zu welchen Clients sie gehören – im Wesentlichen ein PE-Router. Für jeden Client wird eine isolierte Routing-Tabelle verwaltet (VRF lesen). Und vRouter führt tatsächlich Overlay-Tunneling durch.

Etwas mehr über vRouter erfahren Sie am Ende des Artikels.

Jede VM, die sich auf dem Hypervisor befindet, ist über mit dem vRouter dieser Maschine verbunden TAP-Schnittstelle.

TAP - Terminal Access Point – eine virtuelle Schnittstelle im Linux-Kernel, die Netzwerkinteraktion ermöglicht.

Befinden sich hinter dem vRouter mehrere Netzwerke, wird für jedes davon eine virtuelle Schnittstelle erstellt, der eine IP-Adresse zugewiesen wird – es handelt sich um die Standard-Gateway-Adresse.
Alle Netzwerke eines Clients werden in einem zusammengefasst VRF (eine Tabelle), verschiedene - in verschiedene.
Ich möchte an dieser Stelle darauf hinweisen, dass nicht alles so einfach ist, und den neugierigen Leser an das Ende des Artikels verweisen.

Damit vRouter untereinander und damit auch mit den dahinter liegenden VMs kommunizieren können, tauschen sie Routing-Informationen über aus SDN-Controller.

Um in die Außenwelt zu gelangen, gibt es einen Austrittspunkt aus der Matrix – ein virtuelles Netzwerk-Gateway VNGW - Virtuelles Netzwerk-GateWay (meine Amtszeit).

Schauen wir uns nun Kommunikationsbeispiele an – und es wird Klarheit herrschen.

Kommunikation innerhalb einer einzelnen physischen Maschine

VM0 möchte ein Paket an VM2 senden. Nehmen wir zunächst an, dass es sich um eine einzelne Client-VM handelt.

Datenebene

1. VM-0 verfügt über eine Standardroute zu seiner eth0-Schnittstelle. Das Paket wird dorthin geschickt.
   Diese Schnittstelle eth0 ist tatsächlich über die TAP-Schnittstelle tap0 virtuell mit dem virtuellen Router vRouter verbunden.
2. vRouter analysiert, an welcher Schnittstelle das Paket angekommen ist, also zu welchem ​​Client (VRF) es gehört, und prüft die Adresse des Empfängers mit der Routing-Tabelle dieses Clients.
3. Nachdem vRouter erkannt hat, dass sich der Empfänger auf demselben Computer an einem anderen Port befindet, sendet er das Paket einfach ohne zusätzliche Header an ihn – in diesem Fall verfügt vRouter bereits über einen ARP-Eintrag.

In diesem Fall gelangt das Paket nicht in das physische Netzwerk, sondern wird innerhalb des vRouters weitergeleitet.

Steuerebene

Wenn die virtuelle Maschine startet, teilt ihr der Hypervisor mit:

• Ihre eigene IP-Adresse.
• Die Standardroute erfolgt über die IP-Adresse des vRouters in diesem Netzwerk.

Der Hypervisor meldet sich über eine spezielle API an vRouter:

• Was Sie zum Erstellen einer virtuellen Schnittstelle benötigen.
• Welche Art von virtuellem Netzwerk muss (VM) erstellt werden?
• An welches VRF (VN) es gebunden werden soll.
• Ein statischer ARP-Eintrag für diese VM – welche Schnittstelle sich hinter ihrer IP-Adresse befindet und welcher MAC-Adresse sie zugeordnet ist.

Auch hier wird der eigentliche Interaktionsvorgang zum besseren Verständnis des Konzepts vereinfacht.

Somit betrachtet vRouter alle VMs eines Clients auf einer bestimmten Maschine als direkt verbundene Netzwerke und kann selbst zwischen ihnen routen.

Aber VM0 und VM1 gehören zu unterschiedlichen Clients und befinden sich dementsprechend in unterschiedlichen vRouter-Tabellen.

Ob sie direkt miteinander kommunizieren können, hängt von den vRouter-Einstellungen und dem Netzwerkdesign ab.
Wenn beispielsweise die VMs beider Clients öffentliche Adressen verwenden oder NAT auf dem vRouter selbst erfolgt, kann eine direkte Weiterleitung an den vRouter erfolgen.

Im umgekehrten Fall ist es möglich, Adressräume zu überqueren – Sie müssen über einen NAT-Server gehen, um eine öffentliche Adresse zu erhalten – dies ähnelt dem Zugriff auf externe Netzwerke, die weiter unten besprochen werden.

Kommunikation zwischen VMs, die sich auf verschiedenen physischen Maschinen befinden

Datenebene

1. Der Anfang ist genau derselbe: VM-0 sendet ein Paket mit dem Ziel VM-7 (172.17.3.2) als Standard.
2. vRouter empfängt es und erkennt dieses Mal, dass sich das Ziel auf einem anderen Computer befindet und über Tunnel0 zugänglich ist.
3. Zunächst hängt es ein MPLS-Label an, das die Remote-Schnittstelle identifiziert, sodass vRouter auf der Rückseite ohne zusätzliche Suchvorgänge bestimmen kann, wo dieses Paket abgelegt werden soll.

   

4. Tunnel0 hat Quelle 10.0.0.2, Ziel: 10.0.1.2.
   vRouter fügt dem Originalpaket GRE- (oder UDP-)Header und eine neue IP hinzu.
5. Die vRouter-Routing-Tabelle verfügt über eine Standardroute über die ToR1-Adresse 10.0.0.1. Dorthin schickt er es.

   
   

6. Als Mitglied des Underlay-Netzwerks weiß ToR1 (z. B. über OSPF), wie es zu 10.0.1.2 gelangt, und sendet das Paket entlang der Route. Beachten Sie, dass ECMP hier aktiviert ist. In der Abbildung gibt es zwei Nexthops, in die verschiedene Threads nach Hash einsortiert werden. Im Falle einer echten Fabrik wird es eher 4 Nexthops geben.

   Gleichzeitig muss er nicht wissen, was sich unter dem externen IP-Header befindet. Das heißt, unter IP kann es tatsächlich ein Sandwich von IPv6 über MPLS über Ethernet über MPLS über GRE über über über Griechisch geben.

7. Dementsprechend entfernt vRouter auf der Empfängerseite GRE und erkennt mithilfe des MPLS-Tags, an welche Schnittstelle dieses Paket gesendet werden soll, entfernt es und sendet es in seiner ursprünglichen Form an den Empfänger.

Steuerebene

Beim Starten des Autos passiert das Gleiche wie oben beschrieben.

Und außerdem Folgendes:

• Für jeden Client weist vRouter ein MPLS-Tag zu. Dies ist das L3VPN-Dienstlabel, durch das Clients innerhalb derselben physischen Maschine getrennt werden.
  

  Tatsächlich wird das MPLS-Tag immer bedingungslos vom vRouter zugewiesen – schließlich ist nicht im Voraus bekannt, dass die Maschine nur mit anderen Maschinen hinter demselben vRouter interagiert, und dies ist höchstwahrscheinlich auch nicht der Fall.

• vRouter stellt eine Verbindung mit dem SDN-Controller über das BGP-Protokoll (oder ein ähnliches Protokoll – im Fall von TF ist dies XMPP 0_o) her.
• Über diese Sitzung meldet vRouter Routen zu verbundenen Netzwerken an den SDN-Controller:
  • Netzwerkadresse
  • Kapselungsmethode (MPLSoGRE, MPLSoUDP, VXLAN)
  • MPLS-Client-Tag
  • Ihre IP-Adresse als nexthop

• Der SDN-Controller empfängt solche Routen von allen angeschlossenen vRoutern und spiegelt sie an andere weiter. Das heißt, es fungiert als Routenreflektor.

Das Gleiche passiert in der umgekehrten Richtung.

Das Overlay kann sich mindestens jede Minute ändern. Dies ist ungefähr das, was in öffentlichen Clouds passiert, wo Clients ihre virtuellen Maschinen regelmäßig starten und herunterfahren.

Der zentrale Controller kümmert sich um die gesamte Komplexität der Konfigurationspflege und Überwachung der Switching-/Routing-Tabellen auf dem vRouter.

Grob gesagt kommuniziert der Controller mit allen vRoutern über BGP (oder ein ähnliches Protokoll) und übermittelt lediglich Routing-Informationen. BGP verfügt beispielsweise bereits über eine Adressfamilie, um die Kapselungsmethode zu übermitteln MPLS-in-GRE oder MPLS-in-UDP.

Gleichzeitig ändert sich die Konfiguration des Underlay-Netzwerks in keiner Weise, was übrigens viel schwieriger zu automatisieren und mit einer umständlichen Bewegung leichter zu durchbrechen ist.

Ausgang zur Außenwelt

Irgendwo muss die Simulation enden und Sie müssen die virtuelle Welt in die reale Welt verlassen. Und Sie benötigen ein Münztelefon-Gateway.

Es werden zwei Vorgehensweisen praktiziert:

1. Ein Hardware-Router ist installiert.
2. Es wird eine Appliance gestartet, die die Funktionen eines Routers implementiert (ja, nach SDN sind wir auch auf VNF gestoßen). Nennen wir es ein virtuelles Gateway.

Der Vorteil des zweiten Ansatzes ist die kostengünstige horizontale Skalierbarkeit – es ist nicht genügend Leistung vorhanden – wir haben eine weitere virtuelle Maschine mit einem Gateway gestartet. Auf jeder physischen Maschine, ohne nach freien Racks, Einheiten, Leistungsausgängen suchen, die Hardware selbst kaufen, transportieren, installieren, wechseln, konfigurieren und dann auch fehlerhafte Komponenten darin austauschen zu müssen.

Die Nachteile eines virtuellen Gateways bestehen darin, dass eine Einheit eines physischen Routers immer noch um Größenordnungen leistungsfähiger ist als eine virtuelle Multicore-Maschine und ihre auf die eigene Hardwarebasis zugeschnittene Software viel stabiler arbeitet (Nein). Es ist auch schwer zu leugnen, dass der Hardware- und Softwarekomplex einfach funktioniert und nur eine Konfiguration erfordert, während die Einführung und Wartung eines virtuellen Gateways eine Aufgabe für starke Ingenieure ist.

Mit einem Fuß blickt das Gateway wie eine normale virtuelle Maschine in das virtuelle Overlay-Netzwerk und kann mit allen anderen VMs interagieren. Gleichzeitig kann es die Netzwerke aller Clients terminieren und dementsprechend das Routing zwischen ihnen durchführen.

Mit seinem anderen Fuß blickt das Gateway in das Backbone-Netzwerk und weiß, wie es ins Internet gelangt.

Datenebene

Das heißt, der Prozess sieht folgendermaßen aus:

1. VM-0 sendet standardmäßig denselben vRouter und sendet ein Paket mit einem Ziel in der Außenwelt (185.147.83.177) an die eth0-Schnittstelle.
2. vRouter empfängt dieses Paket und sucht in der Routing-Tabelle nach der Zieladresse – findet die Standardroute über das VNGW1-Gateway durch Tunnel 1.
   Er sieht auch, dass es sich um einen GRE-Tunnel mit SIP 10.0.0.2 und DIP 10.0.255.2 handelt, und er muss auch zuerst das MPLS-Label dieses Clients anbringen, was VNGW1 erwartet.
3. vRouter packt das erste Paket mit MPLS, GRE und neuen IP-Headern und sendet es standardmäßig an ToR1 10.0.0.1.
4. Das zugrunde liegende Netzwerk übermittelt das Paket an das Gateway VNGW1.
5. Das VNGW1-Gateway entfernt die GRE- und MPLS-Tunneling-Header, sieht die Zieladresse, konsultiert seine Routing-Tabelle und erkennt, dass es an das Internet weitergeleitet wird – also über die Vollansicht oder die Standardeinstellung. Führt bei Bedarf eine NAT-Übersetzung durch.
6. Es könnte ein reguläres IP-Netzwerk von VNGW bis zur Grenze geben, was unwahrscheinlich ist.
   Es kann ein klassisches MPLS-Netzwerk (IGP+LDP/RSVP TE) geben, es kann eine Back-Fabric mit BGP LU oder ein GRE-Tunnel von VNGW zur Grenze über ein IP-Netzwerk geben.
   Wie dem auch sei, VNGW1 führt die erforderlichen Kapselungen durch und sendet das erste Paket an die Grenze.

Der Verkehr in die entgegengesetzte Richtung durchläuft dieselben Schritte in umgekehrter Reihenfolge.

1. Die Grenze wirft das Paket an VNGW1 ab
2. Er zieht ihn aus, schaut auf die Adresse des Empfängers und stellt fest, dass er über den Tunnel1-Tunnel (MPLSoGRE oder MPLSoUDP) erreichbar ist.
3. Dementsprechend hängt es ein MPLS-Label, einen GRE/UDP-Header und eine neue IP an und sendet diese an seinen ToR3 10.0.255.1.
   Die Tunnelzieladresse ist die IP-Adresse des vRouters, hinter dem sich die Ziel-VM befindet – 10.0.0.2.
4. Das zugrunde liegende Netzwerk übermittelt das Paket an den gewünschten vRouter.
5. Der Ziel-vRouter liest GRE/UDP, identifiziert die Schnittstelle mithilfe des MPLS-Labels und sendet ein nacktes IP-Paket an seine TAP-Schnittstelle, die mit eth0 der VM verknüpft ist.

Steuerebene

VNGW1 richtet eine BGP-Nachbarschaft mit einem SDN-Controller ein, von dem es alle Routing-Informationen über Clients erhält: welche IP-Adresse (vRouter) sich hinter welchem ​​Client befindet und durch welches MPLS-Label er identifiziert wird.

Ebenso teilt er dem SDN-Controller selbst die Standardroute mit der Bezeichnung dieses Clients mit und gibt sich selbst als Nexthop an. Und dann kommt dieser Standard bei vRouters an.

Bei VNGW erfolgt normalerweise eine Routenaggregation oder NAT-Übersetzung.

Und in die andere Richtung sendet es genau diese aggregierte Route mit Grenzen oder Route Reflectors an die Sitzung. Und von ihnen erhält es die Standardroute oder die Vollansicht oder etwas anderes.

In Bezug auf Kapselung und Verkehrsaustausch unterscheidet sich VNGW nicht von vRouter.
Wenn Sie den Umfang etwas erweitern, können Sie VNGWs und vRouter weitere Netzwerkgeräte hinzufügen, z. B. Firewalls, Verkehrsbereinigungs- oder Anreicherungsfarmen, IPS usw.

Und mit Hilfe der sequentiellen Erstellung von VRFs und der korrekten Ankündigung von Routen können Sie den Verkehr dazu zwingen, die von Ihnen gewünschte Schleife zu durchlaufen, was als Service Chaining bezeichnet wird.

Das heißt, auch hier fungiert der SDN-Controller als Route-Reflector zwischen VNGWs, vRoutern und anderen Netzwerkgeräten.

Tatsächlich gibt der Controller aber auch Informationen über ACL und PBR (Policy Based Routing) frei, was dazu führt, dass einzelne Verkehrsströme anders verlaufen, als die Route es ihnen vorgibt.

FAQ

Warum machen Sie immer wieder die GRE/UDP-Bemerkung?

Nun, im Allgemeinen kann man sagen, dass dies spezifisch für Wolframgewebe ist – Sie müssen es überhaupt nicht berücksichtigen.

Aber wenn wir es so nehmen, unterstützte TF selbst, obwohl es noch OpenContrail war, beide Kapselungen: MPLS in GRE und MPLS in UDP.

UDP ist gut, weil es im Quellport sehr einfach ist, eine Hash-Funktion aus dem ursprünglichen IP+Proto+Port in dessen Header zu kodieren, was Ihnen einen Ausgleich ermöglicht.

Im Fall von GRE gibt es leider nur externe IP- und GRE-Header, die für den gesamten gekapselten Datenverkehr gleich sind, und von Balancing ist keine Rede – nur wenige Menschen können so tief in das Paket hineinschauen.

Bis vor einiger Zeit taten Router, wenn sie wussten, wie man dynamische Tunnel nutzt, dies nur in MPLSoGRE, und erst vor kurzem lernten sie, MPLSoUDP zu verwenden. Daher müssen wir immer auf die Möglichkeit zweier unterschiedlicher Kapselungen achten.

Der Fairness halber ist anzumerken, dass TF die L2-Konnektivität über VXLAN vollständig unterstützt.

Sie haben versprochen, Parallelen zu OpenFlow zu ziehen.
Sie verlangen wirklich danach. vSwitch im selben OpenStack macht sehr ähnliche Dinge und verwendet VXLAN, das übrigens auch über einen UDP-Header verfügt.

Auf der Datenebene funktionieren sie ungefähr gleich, auf der Kontrollebene unterscheiden sie sich erheblich. Tungsten Fabric verwendet XMPP, um Routing-Informationen an vRouter zu liefern, während OpenStack Openflow ausführt.

Können Sie mir etwas mehr über vRouter erzählen?
Es ist in zwei Teile unterteilt: vRouter Agent und vRouter Forwarder.

Der erste läuft im User Space des Host-Betriebssystems und kommuniziert mit dem SDN-Controller und tauscht Informationen über Routen, VRFs und ACLs aus.

Die zweite implementiert Data Plane – normalerweise im Kernel Space, kann aber auch auf SmartNICs laufen – Netzwerkkarten mit einer CPU und einem separaten programmierbaren Switching-Chip, der es Ihnen ermöglicht, die CPU des Host-Computers zu entlasten und das Netzwerk schneller und leistungsfähiger zu machen vorhersagbar.

Ein weiteres mögliches Szenario besteht darin, dass vRouter eine DPDK-Anwendung im User Space ist.

vRouter Agent sendet Einstellungen an vRouter Forwarder.

Was ist ein virtuelles Netzwerk?
Ich habe am Anfang des Artikels über VRF erwähnt, dass jeder Mieter an seinen eigenen VRF gebunden ist. Und wenn dies für ein oberflächliches Verständnis der Funktionsweise des Overlay-Netzwerks ausreicht, müssen bei der nächsten Iteration Klarstellungen vorgenommen werden.

Typischerweise wird in Virtualisierungsmechanismen die Entität „Virtuelles Netzwerk“ (Sie können dies als Eigennamen betrachten) getrennt von Clients/Mandanten/virtuellen Maschinen eingeführt – eine völlig unabhängige Sache. Und dieses virtuelle Netzwerk kann bereits über Schnittstellen mit einem Mandanten, einem anderen, zwei oder überall verbunden werden. So wird beispielsweise Service Chaining implementiert, wenn Datenverkehr in der erforderlichen Reihenfolge durch bestimmte Knoten geleitet werden muss, indem einfach virtuelle Netzwerke in der richtigen Reihenfolge erstellt und verbunden werden.

Daher besteht keine direkte Korrespondenz zwischen dem virtuellen Netzwerk und dem Mandanten.

Abschluss

Dies ist eine sehr oberflächliche Beschreibung des Betriebs eines virtuellen Netzwerks mit einem Overlay aus dem Host und einem SDN-Controller. Aber egal, für welche Virtualisierungsplattform Sie sich heute entscheiden, sie wird auf ähnliche Weise funktionieren, sei es VMWare, ACI, OpenStack, CloudStack, Tungsten Fabric oder Juniper Contrail. Sie unterscheiden sich in den Arten der Kapselung und Header sowie in den Protokollen zur Übermittlung von Informationen an Endnetzwerkgeräte, aber das Prinzip eines per Software konfigurierbaren Overlay-Netzwerks, das auf einem relativ einfachen und statischen Underlay-Netzwerk arbeitet, bleibt dasselbe.
Wir können sagen, dass SDN, das auf einem Overlay-Netzwerk basiert, heute den Bereich der Erstellung einer privaten Cloud gewonnen hat. Dies bedeutet jedoch nicht, dass Openflow keinen Platz in der modernen Welt hat – es wird in OpenStacke und in derselben VMWare NSX verwendet, soweit ich weiß, Google verwendet es zum Aufbau des Untergrundnetzwerks.

Nachfolgend habe ich Links zu detaillierteren Materialien bereitgestellt, falls Sie sich eingehender mit dem Thema befassen möchten.

Und was ist mit unserer Unterlage?

Aber im Allgemeinen nichts. Er hat sich nicht völlig verändert. Im Falle eines Overlays vom Host muss er lediglich Routen und ARPs aktualisieren, wenn vRouter/VNGW erscheinen und verschwinden und Pakete zwischen ihnen transportieren.

Lassen Sie uns eine Liste mit Anforderungen für das Underlay-Netzwerk formulieren.

1. In unserer Situation können wir eine Art Routing-Protokoll verwenden – BGP.
2. Verfügen Sie über eine große Bandbreite, vorzugsweise ohne Überbelegung, damit Pakete nicht aufgrund von Überlastungen verloren gehen.
3. Die Unterstützung von ECMP ist ein integraler Bestandteil der Struktur.
4. Seien Sie in der Lage, QoS bereitzustellen, einschließlich kniffliger Dinge wie ECN.
5. Die Unterstützung von NETCONF ist eine Grundlage für die Zukunft.

Der Arbeit des Underlay-Netzwerks selbst habe ich hier nur sehr wenig Zeit gewidmet. Dies liegt daran, dass ich mich später in der Serie darauf konzentrieren werde und wir nur am Rande auf Overlay eingehen.

Offensichtlich schränke ich uns alle stark ein, indem ich als Beispiel ein DC-Netzwerk verwende, das in einer Cloz-Fabrik mit reinem IP-Routing und einem Overlay vom Host aufgebaut wurde.

Ich bin jedoch zuversichtlich, dass jedes Netzwerk, das über ein Design verfügt, formal beschrieben und automatisiert werden kann. Mein Ziel hier ist nur, Ansätze zur Automatisierung zu verstehen und nicht alle zu verwirren, indem ich das Problem in allgemeiner Form löse.

Im Rahmen von ADSM planen Roman Gorge und ich, eine separate Ausgabe über die Virtualisierung von Rechenleistung und ihre Interaktion mit der Netzwerkvirtualisierung zu veröffentlichen. In Kontakt bleiben.

Nützliche Links

• Architektur aus Wolframgewebe.
• about:cloud. 6 Stunden über Yandex.Cloud, das auch das virtuelle Netzwerk auf TF abdeckt.
• Was ist Open vSwitch?
• Einführung in VxLAN.
• RFC 7348. Virtual eXtensible Local Area Network (VXLAN): Ein Framework zur Überlagerung virtualisierter Layer-2-Netzwerke über Layer-3-Netzwerke.
  
• Scaleway-Ansatz für VXLAN EVPN Fabric. Es geht um das gesamte DC-Netzwerk, einschließlich Underlay, Overlay, Ansätze für Multi-Homing und Management.

Danke

• Roman Gorga - ehemaliger Moderator des Linkmeup-Podcasts und jetzt Experte im Bereich Cloud-Plattformen. Für Kommentare und Änderungen. Nun, wir warten in naher Zukunft auf seinen ausführlicheren Artikel zum Thema Virtualisierung.
• Alexander Schalimow - mein Kollege und Experte auf dem Gebiet der Entwicklung virtueller Netzwerke. Für Kommentare und Änderungen.
• Valentin Sinitsyn - mein Kollege und Experte auf dem Gebiet der Wolframgewebe. Für Kommentare und Änderungen.
• Artjom Tschernobay — Illustrator-Linkmeup. Für KDPV.
• Alexander Limonow. Für das Meme „Automato“.

Source: habr.com