Hallo, ich heiße Kostya Kramlikh, ich bin leitender Entwickler der Abteilung Virtual Private Cloud bei Yandex.Cloud. Ich beschäftige mich mit virtuellen Netzwerken und werde in diesem Artikel über die Funktionsweise von Virtual Private Cloud (VPC) im Allgemeinen und von virtuellen Netzwerken im Besonderen berichten. Außerdem erfahren Sie, warum wir, die Entwickler des Dienstes, das Feedback unserer Nutzer schätzen. Doch der Reihe nach.
Was ist VPC?
Heute gibt es viele verschiedene Möglichkeiten, Dienste bereitzustellen. Ich bin mir sicher, dass jemand immer noch einen Server unter dem Tisch des Administrators hat, obwohl ich hoffe, dass solche Geschichten immer seltener werden.
Jetzt versuchen Dienste, in öffentliche Clouds zu wechseln, und genau hier stoßen sie auf VPC. VPC ist ein Teil der öffentlichen Cloud, die benutzerdefinierte, Infrastruktur-, Plattform- und andere Ressourcen miteinander verbindet, egal wo sie sich befinden, in unserer Cloud oder außerhalb davon. Mit VPC ist es zudem möglich, diese Ressourcen nicht unnötig ins Internet zu stellen; sie bleiben innerhalb Ihres isolierten Netzwerks.
Wie ein virtuelles Netzwerk von außen aussieht
Unter VPC verstehen wir in erster Linie ein Overlay-Netzwerk und Netzwerkdienste wie VPNaaS, NATaas, LBaas usw. All dies funktioniert auf einer fehlertoleranten Netzwerk-Infrastruktur, über die bereits geschrieben wurde. ein ausgezeichneter Artikel hier auf Habr.
Lassen Sie uns das virtuelle Netzwerk und seine Funktionsweise genauer ansehen.
Betrachten wir zwei Verfügbarkeitszonen. Wir bieten ein virtuelles Netzwerk an – das, was wir VPC nennen. Tatsächlich definiert es den Raum der Einzigartigkeit Ihrer "grauen" Adressen. Innerhalb jedes virtuellen Netzwerks verwalten Sie den Adressraum vollständig, den Sie Rechenressourcen zuweisen können.
Das Netzwerk ist global. Dabei wird es auf jede der Verfügbarkeitszonen als Entität namens Subnet projiziert. Für jede Subnet weisen Sie einen CIDR von 16 oder weniger zu. In jeder Verfügbarkeitszone kann es mehr als eine solche Entität geben, wobei zwischen ihnen immer ein transparenter Routing besteht. Das bedeutet, dass alle Ihre Ressourcen innerhalb einer VPC miteinander "kommunizieren" können, auch wenn sie sich in verschiedenen Verfügbarkeitszonen befinden. "Kommunizieren" ohne ins Internet zu gehen, über unsere internen Kanäle, während sie "glauben", dass sie sich innerhalb eines privaten Netzwerks befinden.
Das obige Diagramm zeigt eine typische Situation: zwei VPCs, die sich in den Adressen überschneiden. Beide können Ihnen gehören. Zum Beispiel eine für die Entwicklung, die andere für Tests. Es können einfach unterschiedliche Benutzer sein – in diesem Fall ist das unwichtig. In jede VPC ist eine virtuelle Maschine integriert.
Verschärfen wir das Schema. Man kann eine virtuelle Maschine so konzipieren, dass sie gleichzeitig in mehrere Subnetze integriert wird. Und nicht einfach so, sondern in unterschiedlichen virtuellen Netzwerken.
Dabei können Sie, wenn Sie Maschinen ins Internet stellen möchten, dies über die API oder die UI tun. Dazu müssen Sie die NAT-Übersetzung Ihrer „grauen“, internen Adresse in die „weiße“ – öffentliche Adresse einrichten. Sie können die „weiße“ Adresse nicht auswählen, sie wird zufällig aus unserem Adresspool zugewiesen. Sobald Sie die externe IP nicht mehr nutzen, wird sie wieder in den Pool zurückgegeben. Sie zahlen nur für die Zeit, in der Sie die „weiße“ Adresse verwenden.
Es besteht auch die Möglichkeit, einem Rechner über eine NAT-Instanz Zugriff auf das Internet zu gewähren. Der Verkehr kann über eine statische Routingtabelle zu der Instanz geleitet werden. Wir haben diesen Fall berücksichtigt, weil er für Benutzer manchmal notwendig ist, und wir sind uns dessen bewusst. In unserem Katalog von Images befindet sich daher ein speziell konfiguriertes NAT-Image.
Doch selbst wenn ein NAT-Image bereitsteht, kann die Konfiguration schwierig sein. Wir haben verstanden, dass dies für einige Benutzer nicht die bequemste Option ist, und haben schließlich die Möglichkeit geschaffen, NAT für das benötigte Subnetz mit einem Klick zu aktivieren. Diese Funktion befindet sich derzeit noch im geschlossenen Vorabzugang, der mit Teilnehmern der Community getestet wird.
Wie das virtuelle Netzwerk im Inneren aufgebaut ist
Wie interagiert der Benutzer mit dem virtuellen Netzwerk? Das Netzwerk schaut mit seiner API nach außen. Der Benutzer kommt zur API und arbeitet mit dem Zielzustand. Über die API sieht der Benutzer, wie alles eingerichtet und konfiguriert sein sollte, während er den Status sieht, wie stark der aktuelle Zustand vom gewünschten abweicht. Das ist das Bild des Benutzers. Was passiert jedoch im Inneren?
Wir speichern den gewünschten Zustand in der Yandex-Datenbank und gehen hin, um verschiedene Teile unserer VPC zu konfigurieren. Das Overlay-Netzwerk in Yandex.Cloud basiert auf ausgewählten Komponenten von OpenContrail, das seit kurzem den Namen Tungsten Fabric trägt. Die Netzwerke sind auf einer einheitlichen Plattform namens CloudGate implementiert. In CloudGate haben wir ebenfalls einige Open-Source-Komponenten verwendet: GoBGP – für den Zugriff auf Kontrollinformationen und VPP – für die Umsetzung eines Software-Routers, der über DPDK für den Datenpfad läuft.
Tungsten Fabric kommuniziert über GoBGP mit CloudGate. Es informiert darüber, was im Overlay-Netzwerk passiert. CloudGate hingegen verbindet die Overlay-Netzwerke miteinander und mit dem Internet.
Jetzt schauen wir uns an, wie das virtuelle Netzwerk Skalierungs- und Verfügbarkeitsanforderungen erfüllt. Betrachten wir einen einfachen Fall. Hier gibt es eine Verfügbarkeitszone, in der zwei VPCs erstellt wurden. Wir haben eine Instanz von Tungsten Fabric bereitgestellt, die mehrere tausend Netzwerke verwaltet. Die Netzwerke sind mit CloudGate verbunden. CloudGate, wie bereits erwähnt, sorgt dafür, dass sie untereinander und mit dem Internet verbunden sind.
Angenommen, es wird eine zweite Verfügbarkeitszone hinzugefügt. Diese sollte völlig unabhängig von der ersten ausfallen. Daher müssen wir in der zweiten Verfügbarkeitszone eine separate Instanz von Tungsten Fabric bereitstellen. Dies wird ein separates System sein, das für das Overlay verantwortlich ist und wenig über das erste System weiß. Die Sichtbarkeit, dass unser virtuelles Netzwerk global ist, wird im Wesentlichen durch unsere VPC-API geschaffen. Das ist ihre Aufgabe.
VPC1 wird in die Verfügbarkeitszone B projiziert, wenn es in der Verfügbarkeitszone B Ressourcen gibt, die in VPC1 eingebunden werden. Wenn es keine Ressourcen aus VPC2 in der Verfügbarkeitszone B gibt, wird VPC2 in dieser Zone nicht materialisiert. Da die Ressourcen aus VPC3 nur in Zone B vorhanden sind, existiert VPC3 nicht in Zone A. Alles ist einfach und logisch.
Lassen Sie uns etwas tiefer gehen und uns ansehen, wie ein bestimmter Host in Yandex.Cloud strukturiert ist. Das Wichtigste, was zu erwähnen ist, ist, dass alle Hosts gleich aufgebaut sind. Wir stellen sicher, dass nur das notwendige Minimum an Diensten auf der 'Hardware' läuft, alle anderen sind auf virtuellen Maschinen. Wir bauen Dienstleistungen höherer Ordnung auf der Grundlage grundlegender Infrastruktur服务 und nutzen die Cloud zur Lösung einiger Ingenieuraufgaben, beispielsweise im Rahmen der kontinuierlichen Integration.
Wenn wir uns einen bestimmten Host ansehen, sehen wir, dass drei Komponenten im Betriebssystem des Hosts laufen:
- Compute – der Teil, der für die Verteilung der Rechenressourcen auf dem Host verantwortlich ist.
- VRouter – der Teil von Tungsten Fabric, der das Overlay organisiert, d.h. Pakete durch das Underlay tunnelt.
- VDisk – das sind Stücke der Speichervirtualisierung.
Außerdem laufen virtuellen Maschinen Services: Infrastrukturservices der Cloud, Plattformdienste und Kundenleistungen. Die Kundenleistungen und Plattformdienste laufen immer im Overlay über VRouter.
Infrastrukturservices können in das Overlay integriert werden, aber sie möchten hauptsächlich im Underlay arbeiten. Im Underlay werden sie durch SR-IOV integriert. Tatsächlich schneiden wir die Karte in virtuelle Netzwerkkarten (virtuelle Funktionen) und stecken sie in infrastrukturelle VMs, um Leistung nicht zu verlieren. Zum Beispiel wird das CloudGate als eine dieser infrastrukturellen virtuellen Maschinen betrieben.
Jetzt, da wir die globalen Aufgaben des virtuellen Netzwerks und die Struktur der grundlegenden Cloud-Komponenten beschrieben haben, lassen Sie uns ansehen, wie die verschiedenen Teile des virtuellen Netzwerks miteinander interagieren.
Wir unterscheiden in unserem System drei Schichten:
- Config Plane – legt den gewünschten Zustand des Systems fest. Das ist das, was der Benutzer über die API konfiguriert.
- Control Plane – gewährleistet die vom Benutzer vorgegebene Semantik, d.h. bringt den Zustand des Data Plane in den Zustand, der vom Benutzer im Config Plane beschrieben wurde.
- Data Plane – verarbeitet direkt die Benutzerpakete.
Wie bereits erwähnt, beginnt alles damit, dass der Benutzer oder ein interner Plattformdienst zur API kommt und einen bestimmten Zielzustand beschreibt.
Dieser Zustand wird sofort in die Yandex Datenbank geschrieben, gibt über die API die ID der asynchronen Operation zurück und startet unsere interne Mechanik, um den Zustand bereitzustellen, den der Benutzer wollte. Konfigurationstasks gehen an den SDN-Controller und informieren Tungsten Fabric darüber, was im Overlay zu tun ist. Zum Beispiel reservieren sie Ports, virtuelle Netzwerke usw.
Config Plane in Tungsten Fabric liefert den erforderlichen Zustand an Control Plane. Über diese Schnittstelle kommuniziert der Config Plane auch mit den Hosts und informiert sie darüber, was in naher Zukunft auf ihnen laufen wird.
Nun schauen wir uns an, wie das System auf den Hosts aussieht. In virtuellen Maschine Es gibt einen Netzwerkadapter, der in den VRouter eingesteckt ist. Der VRouter ist ein Kernmodul von Tungsten Fabric, das die Pakete überwacht. Wenn für ein bestimmtes Paket bereits ein Flow vorhanden ist, verarbeitet das Modul es. Wenn kein Flow vorhanden ist, führt das Modul eine sogenannte Punting durch, das heißt, es sendet das Paket an den Usermode-Prozess. Der Prozess analysiert das Paket und antwortet entweder selbst darauf, wie zum Beispiel bei DHCP und DNS, oder sagt dem VRouter, was damit zu tun ist. Danach kann der VRouter das Paket weiterverarbeiten.
Der Datenverkehr zwischen virtuellen Maschinen innerhalb eines virtuellen Netzwerks läuft transparent, er wird nicht an CloudGate geleitet. Die Hosts, auf denen die virtuellen Maschinen ausgeführt werden, kommunizieren direkt miteinander. Sie tunneln den Datenverkehr und leiten ihn über Underlay.
Die Control Plane kommuniziert über BGP zwischen den Verfügbarkeitszonen wie mit einem anderen Router. Sie informieren sich darüber, welche Maschinen wo betrieben werden, damit virtuelle Maschinen in einer Zone direkt mit anderen virtuellen Maschinen interagieren können.
Die Control Plane kommuniziert auch mit CloudGate. Analog informiert sie darüber, wo und welche VMs laufen und welche IP-Adressen sie haben. Dadurch kann der externe Datenverkehr sowie der Datenverkehr von Load Balancern an sie geleitet werden.
Der Datenverkehr, der aus der VPC kommt, gelangt zu CloudGate, in den Datenpfad, wo er schnell von VPP mit unseren Plugins verarbeitet wird. Anschließend wird der Datenverkehr entweder an andere VPCs oder nach außen, zu den Grenzroutern, die über die Control Plane von CloudGate konfiguriert werden, weitergeleitet.
Pläne für die nähere Zukunft
Wenn man alles, was oben gesagt wurde, in einigen Sätzen zusammenfasst, kann man sagen, dass die VPC in Yandex.Cloud zwei wichtige Aufgaben löst:
- Sie gewährleistet die Isolation zwischen verschiedenen Kunden.
- Sie vereint Ressourcen, Infrastruktur, Plattformdienste, andere Clouds und On-Premise in einem Netzwerk.
Und um diese Aufgaben gut zu bewältigen, muss man Skalierbarkeit und Ausfalltoleranz auf der Ebene der internen Architektur gewährleisten, was die VPC auch tut.
Allmählich wird die VPC um Funktionen erweitert, wir implementieren neue Möglichkeiten und bemühen uns, in Bezug auf die Benutzerfreundlichkeit Verbesserungen vorzunehmen. Einige Ideen werden geäußert und gelangen durch die Teilnehmer unserer Community in die Prioritätenliste.
Derzeit haben wir ungefähr diese Liste von Plänen für die nähere Zukunft:
- VPN wie ein Service.
- Private DNS-Instanzen – Abbildungen für die schnelle Einrichtung virtueller Maschinen mit einem vorab konfigurierten DNS-Server.
- DNS als Dienst.
- Interner Lastenausgleich.
- Hinzufügen einer "weißen" IP-Adresse, ohne die virtuelle Maschine neu zu erstellen.
Der Lastenausgleich und die Möglichkeit, die IP-Adresse für bereits erstellte virtuelle Maschinen zu wechseln, standen auf dieser Liste auf Wunsch der Benutzer. Ehrlich gesagt hätten wir uns ohne klares Feedback später mit diesen Funktionen beschäftigt. So arbeiten wir bereits an der Aufgabe bezüglich der Adressen.
Ursprünglich konnte eine "weiße" IP-Adresse nur bei der Erstellung der Maschine hinzugefügt werden. Wenn der Benutzer vergaß, dies zu tun, musste die virtuelle Maschine neu erstellt werden. Das Gleiche galt, wenn die externe IP entfernt werden musste. Bald wird es möglich sein, die öffentliche IP ein- und auszuschalten, ohne die Maschine neu erstellen zu müssen.
Scheuen Sie sich nicht, Ihre Ideen zu äußern und Vorschläge anderer Benutzer zu unterstützen. Sie helfen uns, die Cloud zu verbessern und erhalten schneller wichtige und nützliche Funktionen!
Quelle: habr.com
