Hallo, mein Name ist Kostya Kramlikh, ich bin der leitende Entwickler der Virtual Private Cloud-Abteilung in Yandex.Cloud. Ich bin ein virtueller Netzwerker, und wie Sie sich vorstellen können, werde ich in diesem Artikel über das Virtual Private Cloud (VPC)-Gerät im Allgemeinen und das virtuelle Netzwerk im Besonderen sprechen. Und Sie erfahren auch, warum wir, die Entwickler des Dienstes, Wert auf das Feedback unserer Nutzer legen. Aber das Wichtigste zuerst.
Was ist VPC?
Heutzutage gibt es eine Vielzahl von Möglichkeiten, Dienste bereitzustellen. Ich bin sicher, dass immer noch jemand den Server unter dem Schreibtisch des Administrators aufbewahrt, obwohl ich hoffe, dass es weniger solcher Geschichten gibt.
Jetzt versuchen Dienste, in öffentliche Clouds zu gelangen, und kollidieren hier mit VPCs. VPC ist Teil einer öffentlichen Cloud, die Benutzer, Infrastruktur, Plattform und andere Kapazitäten miteinander verbindet, egal wo sie sich befinden, in unserer Cloud oder außerhalb. Gleichzeitig ermöglicht Ihnen VPC, diese Kapazitäten nicht unnötig dem Internet auszusetzen, sondern sie bleiben in Ihrem isolierten Netzwerk.
Wie sieht ein virtuelles Netzwerk von außen aus?
Mit VPC meinen wir in erster Linie ein Overlay-Netzwerk und Netzwerkdienste wie VPNaaS, NATaas, LBaas usw. Und das alles funktioniert auf einer bereits vorhandenen fehlertoleranten Netzwerkinfrastruktur hier, auf Habré.
Schauen wir uns das virtuelle Netzwerk und sein Gerät genauer an.
Betrachten Sie zwei Verfügbarkeitszonen. Wir stellen ein virtuelles Netzwerk bereit – das, was wir VPC nennen. Tatsächlich definiert es den Eindeutigkeitsbereich Ihrer „grauen“ Adressen. Innerhalb jedes virtuellen Netzwerks haben Sie die vollständige Kontrolle über den Adressraum, den Sie Rechenressourcen zuweisen können.
Das Netzwerk ist global. Gleichzeitig wird es in Form einer Einheit namens Subnetz auf jede der Verfügbarkeitszonen projiziert. Für jedes Subnetz weisen Sie ein CIDR der Größe 16 oder weniger zu. In jeder Verfügbarkeitszone kann es mehr als eine solche Entität geben, und zwischen ihnen besteht immer transparentes Routing. Das bedeutet, dass alle Ihre Ressourcen innerhalb derselben VPC miteinander „kommunizieren“ können, auch wenn sie sich in unterschiedlichen Availability Zones befinden. „Kommunizieren“ Sie ohne Zugang zum Internet über unsere internen Kanäle und „denken Sie“, dass sie sich im selben privaten Netzwerk befinden.
Das obige Diagramm zeigt eine typische Situation: zwei VPCs, die sich irgendwo in Adressen überschneiden. Beides kann Ihnen gehören. Zum Beispiel einer für die Entwicklung, der andere zum Testen. Es kann einfach sein, dass es unterschiedliche Benutzer gibt – in diesem Fall spielt das keine Rolle. Und an jede VPC ist eine virtuelle Maschine angeschlossen.
Machen wir den Plan noch schlimmer. Sie können dafür sorgen, dass eine virtuelle Maschine in mehreren Subnetzen gleichzeitig hängen bleibt. Und das nicht einfach so, sondern in verschiedenen virtuellen Netzwerken.
Wenn Sie gleichzeitig Maschinen dem Internet zugänglich machen müssen, kann dies über die API oder die Benutzeroberfläche erfolgen. Dazu müssen Sie die NAT-Übersetzung Ihrer „grauen“, internen Adresse, in „weiße“ – öffentliche Adresse konfigurieren. Sie können keine „weiße“ Adresse auswählen, diese wird zufällig aus unserem Adresspool vergeben. Sobald Sie die Verwendung der externen IP beenden, wird sie an den Pool zurückgegeben. Sie zahlen nur für die Zeit der Nutzung der „weißen“ Adresse.
Es ist auch möglich, der Maschine über eine NAT-Instanz Zugriff auf das Internet zu gewähren. Sie können Datenverkehr über eine statische Routing-Tabelle an eine Instanz weiterleiten. Wir haben einen solchen Fall bereitgestellt, weil Benutzer ihn manchmal benötigen und wir darüber Bescheid wissen. Dementsprechend enthält unser Image-Katalog ein speziell konfiguriertes NAT-Image.
Aber selbst wenn ein fertiges NAT-Image vorhanden ist, kann die Einrichtung schwierig sein. Wir haben verstanden, dass dies für einige Benutzer nicht die bequemste Option ist, und haben es letztendlich ermöglicht, NAT für das gewünschte Subnetz mit einem Klick zu aktivieren. Diese Funktion befindet sich noch im geschlossenen Vorschau-Zugriff, wo sie mit Hilfe von Community-Mitgliedern getestet wird.
Wie das virtuelle Netzwerk von innen aufgebaut ist
Wie interagiert der Benutzer mit dem virtuellen Netzwerk? Das Web blickt mit seiner API nach außen. Der Benutzer gelangt zur API und arbeitet mit dem Zielzustand. Durch die API sieht der Benutzer, wie alles angeordnet und konfiguriert werden soll, während er den Status sieht, wie stark der tatsächliche Zustand vom gewünschten abweicht. Dies ist ein Bild des Benutzers. Was ist drinnen los?
Wir schreiben den gewünschten Status in die Yandex-Datenbank und konfigurieren verschiedene Teile unserer VPC. Das Overlay-Netzwerk in Yandex.Cloud basiert auf ausgewählten Komponenten von OpenContrail, das seit Kurzem Tungsten Fabric heißt. Netzwerkdienste werden auf einer einzigen CloudGate-Plattform implementiert. In CloudGate haben wir auch eine Reihe von Open-Source-Komponenten verwendet: GoBGP – für den Zugriff auf Kontrollinformationen sowie VPP – um einen Software-Router zu implementieren, der auf DPDK für den Datenpfad läuft.
Tungsten Fabric kommuniziert mit CloudGate über GoBGP. Sagt, was im Overlay-Netzwerk vor sich geht. CloudGate wiederum verbindet Overlay-Netzwerke untereinander und mit dem Internet.
Sehen wir uns nun an, wie ein virtuelles Netzwerk die Probleme der Skalierung und Verfügbarkeit löst. Betrachten wir einen einfachen Fall. Es gibt eine Verfügbarkeitszone und darin werden zwei VPCs erstellt. Wir haben eine Tungsten Fabric-Instanz bereitgestellt, die mehrere Zehntausend Netzwerke abruft. Netzwerke kommunizieren mit CloudGate. CloudGate stellt, wie bereits erwähnt, ihre Konnektivität untereinander und mit dem Internet sicher.
Nehmen wir an, eine zweite Verfügbarkeitszone wird hinzugefügt. Es sollte völlig unabhängig vom ersten scheitern. Daher müssen wir in der zweiten Verfügbarkeitszone eine separate Tungsten Fabric-Instanz installieren. Dies wird ein separates System sein, das sich mit dem Overlay befasst und wenig über das erste System weiß. Und die Sichtbarkeit, dass unser virtuelles Netzwerk global ist, schafft tatsächlich unsere VPC-API. Das ist seine Aufgabe.
VPC1 wird der Availability Zone B zugeordnet, wenn es Ressourcen in der Availability Zone B gibt, die an VPC1 gepusht werden. Wenn in der Verfügbarkeitszone B keine Ressourcen von VPC2 vorhanden sind, wird VPC2 in dieser Zone nicht materialisiert. Da Ressourcen von VPC3 wiederum nur in Zone B vorhanden sind, existiert VPC3 nicht in Zone A. Alles ist einfach und logisch.
Lassen Sie uns etwas tiefer gehen und sehen, wie ein bestimmter Host in Y.Cloud funktioniert. Das Wichtigste, was ich anmerken möchte, ist, dass alle Hosts gleich arrangiert sind. Wir sorgen dafür, dass nur das erforderliche Minimum an Diensten auf Hardware läuft, der Rest auf virtuellen Maschinen. Wir bauen Dienste höherer Ordnung auf Basis grundlegender Infrastrukturdienste auf und nutzen die Cloud auch zur Lösung einiger technischer Probleme, beispielsweise im Rahmen der kontinuierlichen Integration.
Wenn wir uns einen bestimmten Host ansehen, können wir erkennen, dass auf dem Host-Betriebssystem drei Komponenten ausgeführt werden:
- Compute – der Teil, der für die Verteilung der Rechenressourcen auf dem Host verantwortlich ist.
- VRouter ist ein Teil von Tungsten Fabric, der ein Overlay organisiert, das heißt, er tunnelt Pakete durch ein Underlay.
- VDisks sind Teile der Speichervirtualisierung.
Darüber hinaus werden Dienste in virtuellen Maschinen gestartet: Cloud-Infrastrukturdienste, Plattformdienste und Kundenkapazitäten. Kundenkapazitäten und Plattformdienste gehen immer über VRouter an das Overlay.
Infrastrukturdienste können im Overlay bleiben, aber grundsätzlich wollen sie im Underlay arbeiten. Sie werden mit Hilfe von SR-IOV in die Unterlage geklebt. Tatsächlich schneiden wir die Karte in virtuelle Netzwerkkarten (virtuelle Funktionen) und verschieben sie in virtuelle Infrastrukturmaschinen, um die Leistung nicht zu beeinträchtigen. Beispielsweise wird dasselbe CloudGate als eine dieser virtuellen Infrastrukturmaschinen gestartet.
Nachdem wir nun die globalen Aufgaben des virtuellen Netzwerks und die Struktur der Grundkomponenten der Cloud beschrieben haben, wollen wir uns ansehen, wie genau die verschiedenen Teile des virtuellen Netzwerks miteinander interagieren.
Wir unterscheiden in unserem System drei Schichten:
- Config Plane – legt den Zielzustand des Systems fest. Dies ist, was der Benutzer über die API konfiguriert.
- Control Plane – stellt benutzerdefinierte Semantik bereit, d. h. bringt den Zustand der Datenebene auf den vom Benutzer in Config Plane beschriebenen Zustand.
- Data Plane – verarbeitet die Pakete des Benutzers direkt.
Wie ich oben bereits sagte, beginnt alles damit, dass der Benutzer oder interne Plattformdienst auf die API kommt und einen bestimmten Zielzustand beschreibt.
Dieser Status wird sofort in die Yandex-Datenbank geschrieben, gibt die asynchrone Vorgangs-ID über die API zurück und startet unsere interne Maschinerie, um den vom Benutzer gewünschten Status zurückzugeben. Konfigurationsaufgaben gehen an den SDN-Controller und teilen Tungsten Fabric mit, was im Overlay zu tun ist. Sie reservieren beispielsweise Ports, virtuelle Netzwerke und dergleichen.
Config Plane in Tungsten Fabric sendet den erforderlichen Status an die Control Plane. Dadurch kommuniziert Config Plane mit den Hosts und teilt ihnen mit, was genau bald auf ihnen laufen wird.
Schauen wir uns nun an, wie das System auf den Hosts aussieht. Die virtuelle Maschine verfügt über einen Netzwerkadapter, der an VRouter angeschlossen ist. VRouter ist ein Kernmodul von Tungsten Fabric, das Pakete untersucht. Wenn für ein Paket bereits ein Flow vorhanden ist, verarbeitet das Modul diesen. Wenn kein Fluss vorhanden ist, führt das Modul das sogenannte Punting durch, das heißt, es sendet ein Paket an den Usermod-Prozess. Der Prozess analysiert das Paket und antwortet entweder selbst darauf, wie DHCP und DNS, oder teilt VRouter mit, was damit zu tun ist. Danach kann VRouter das Paket verarbeiten.
Darüber hinaus erfolgt der Datenverkehr zwischen virtuellen Maschinen innerhalb desselben virtuellen Netzwerks transparent und wird nicht an CloudGate weitergeleitet. Die Hosts, auf denen die virtuellen Maschinen bereitgestellt werden, kommunizieren direkt miteinander. Sie tunneln den Verkehr und leiten ihn gegenseitig durch die Unterlage weiter.
Kontrollebenen kommunizieren zwischen Verfügbarkeitszonen über BGP miteinander, wie mit einem anderen Router. Sie sagen, welche Maschinen sich wo befinden, sodass VMs in einer Zone direkt mit anderen VMs kommunizieren können.
Und Control Plane kommuniziert mit CloudGate. Ebenso wird berichtet, wo und welche virtuellen Maschinen ausgelöst werden und welche Adressen sie haben. Dadurch können Sie externen Datenverkehr und Datenverkehr von Balancern zu diesen leiten.
Der Datenverkehr, der die VPC verlässt, gelangt zu CloudGate, zum Datenpfad, wo das VPP mit unseren Plugins schnell zerkaut wird. Anschließend wird der Datenverkehr entweder an andere VPCs oder nach außen an Grenzrouter weitergeleitet, die über die Steuerungsebene von CloudGate selbst konfiguriert werden.
Pläne für die nahe Zukunft
Wenn wir alles oben Gesagte in wenigen Sätzen zusammenfassen, können wir sagen, dass VPC in Yandex.Cloud zwei wichtige Aufgaben löst:
- Bietet Isolierung zwischen verschiedenen Clients.
- Kombiniert Ressourcen, Infrastruktur, Plattformdienste, andere Clouds und On-Premise in einem einzigen Netzwerk.
Und um diese Probleme gut zu lösen, müssen Sie Skalierbarkeit und Fehlertoleranz auf der Ebene der internen Architektur bereitstellen, was bei VPC der Fall ist.
Nach und nach erhält VPC Funktionen, wir implementieren neue Funktionen und versuchen, den Benutzerkomfort zu verbessern. Einige Ideen werden geäußert und dank der Mitglieder unserer Community auf die Prioritätenliste gesetzt.
Wir haben derzeit die folgende Liste von Plänen für die nahe Zukunft:
- VPN als Dienst.
- Private DNS-Instanzen sind Images zum schnellen Einrichten virtueller Maschinen mit einem vorkonfigurierten DNS-Server.
- DNS als Dienst.
- Interner Load Balancer.
- Hinzufügen einer „weißen“ IP-Adresse, ohne die virtuelle Maschine neu zu erstellen.
Der Balancer und die Möglichkeit, die IP-Adresse für eine bereits erstellte virtuelle Maschine zu ändern, standen auf Wunsch der Benutzer auf dieser Liste. Ehrlich gesagt, ohne explizites Feedback hätten wir diese Funktionen etwas später übernommen. Und so arbeiten wir bereits an der Problematik der Adressen.
Eine „weiße“ IP-Adresse konnte zunächst nur beim Erstellen einer Maschine hinzugefügt werden. Wenn der Benutzer dies vergaß, musste die virtuelle Maschine neu erstellt werden. Das Gleiche tun und ggf. die externe IP entfernen. Es wird bald möglich sein, die öffentliche IP ein- und auszuschalten, ohne die Maschine neu erstellen zu müssen.
Fühlen Sie sich frei, Ihre Meinung zum Ausdruck zu bringen andere Benutzer. Sie helfen uns, die Cloud besser zu machen und wichtige und nützliche Funktionen schneller zu erhalten!
Source: habr.com