Get best of the week

Wie Yandex.Cloud von Virtual Private Cloud gehostet wird und wie unsere Benutzer uns bei der Implementierung nützlicher Funktionen helfen

Hallo, mein Name ist Kostya Kramlikh, ich bin ein führender Entwickler der Division Virtual Private Cloud in Yandex.Cloud. Ich bin in einem virtuellen Netzwerk tätig, und wie Sie sich vorstellen können, werde ich in diesem Artikel über das VPC-Gerät (Virtual Private Cloud) im Allgemeinen und das virtuelle Netzwerk im Besonderen sprechen. Sie erfahren auch, warum wir, die Entwickler des Dienstes, das Feedback unserer Benutzer schätzen. Aber das Wichtigste zuerst.



Was ist eine VPC?


Heutzutage gibt es für die Bereitstellung von Diensten eine Vielzahl von Möglichkeiten. Ich bin mir sicher, dass immer noch jemand den Server unter dem Administrator-Tisch hält, obwohl es hoffentlich immer weniger solche Geschichten gibt.

Jetzt versuchen die Dienste, in öffentliche Clouds zu gelangen, und genau hier sind sie mit VPC konfrontiert. VPC ist ein Teil der öffentlichen Cloud, die Benutzer, Infrastruktur, Plattform und andere Kapazitäten in unserer Cloud oder darüber hinaus miteinander verbindet, wo immer sie sich befinden. Gleichzeitig ermöglicht VPC, diese Kapazitäten nicht unnötig ins Internet zu stellen, sondern verbleibt in Ihrem isolierten Netzwerk.

Wie ein virtuelles Netzwerk von außen aussieht




Unter VPC verstehen wir in erster Linie das Overlay-Netzwerk und Netzwerkdienste wie VPNaaS, NATaas, LBaas usw. Und all dies funktioniert zusätzlich zu der ausfallsicheren Netzwerkinfrastruktur, über die es hier auf Habré bereits einen ausgezeichneten Artikel gab .

Schauen wir uns das virtuelle Netzwerk und sein Gerät genauer an.



Betrachten Sie zwei Zugänglichkeitszonen. Wir bieten ein virtuelles Netzwerk - was wir VPC nannten. Tatsächlich definiert es den Eindeutigkeitsraum Ihrer „grauen“ Adressen. Innerhalb jedes virtuellen Netzwerks steuern Sie vollständig den Adressraum, den Sie Computerressourcen zuweisen können.

Das Netzwerk ist global. Gleichzeitig wird es in Form einer Entität namens Subnetz auf jede der Zugriffszonen projiziert. Für jedes Subnetz weisen Sie eine bestimmte CIDR mit einer Größe von 16 oder weniger zu. In jeder Verfügbarkeitszone kann es mehr als eine solche Entität geben, während zwischen ihnen immer ein transparentes Routing besteht. Dies bedeutet, dass alle Ihre Ressourcen innerhalb derselben VPC miteinander "kommunizieren" können, selbst wenn sie sich in unterschiedlichen Zugriffszonen befinden. "Kommunizieren" Sie ohne Zugang zum Internet über unsere internen Kanäle und "denken" Sie, dass sie sich innerhalb desselben privaten Netzwerks befinden.

Das obige Diagramm zeigt eine typische Situation: Zwei VPCs, die sich irgendwo an Adressen schneiden. Beide können dir gehören. Zum Beispiel eine für die Entwicklung, eine andere zum Testen. Es kann einfach verschiedene Benutzer geben - in diesem Fall spielt es keine Rolle. In jeder VPC steckt eine virtuelle Maschine fest.



Verbinden Sie das Schema. Sie können eine virtuelle Maschine gleichzeitig in mehrere Subnetze einbinden. Und das nicht nur so, sondern in verschiedenen virtuellen Netzwerken.



Wenn Sie Autos ins Internet stellen müssen, kann dies gleichzeitig über die API oder die Benutzeroberfläche erfolgen. Dazu müssen Sie die NAT-Übersetzung Ihrer "grauen" internen Adresse in "weiß" - öffentlich konfigurieren. Sie können keine „weiße“ Adresse auswählen, diese wird zufällig aus unserem Adresspool zugewiesen. Sobald Sie die externe IP nicht mehr verwenden, kehrt sie zum Pool zurück. Sie zahlen nur für die Zeit, in der Sie die "weiße" Adresse verwenden.



Es ist auch möglich, dem Computer über eine NAT-Instanz Zugriff auf das Internet zu gewähren. In einer Instanz können Sie Datenverkehr über eine statische Routing-Tabelle abrufen. Wir haben einen solchen Fall bereitgestellt, weil Benutzer ihn benötigen und wir darüber Bescheid wissen. Dementsprechend liegt in unserem Bildkatalog ein speziell konfiguriertes NAT-Image.



Aber selbst wenn es ein fertiges NAT-Image gibt, kann die Konfiguration kompliziert sein. Wir haben festgestellt, dass dies für einige Benutzer nicht die bequemste Option ist. Daher haben wir es letztendlich möglich gemacht, NAT für das gewünschte Subnetz mit einem Klick einzuschließen. Diese Funktion befindet sich noch im privaten Vorschau-Zugriff, wo sie mithilfe von Community-Mitgliedern integriert wird.

Wie ein virtuelles Netzwerk von innen nach außen funktioniert





Wie interagiert ein Benutzer mit einem virtuellen Netzwerk? Das Netzwerk schaut mit seiner API nach außen. Der Benutzer kommt zur API und arbeitet mit dem Zielstatus. Über die API sieht der Benutzer, wie alles angeordnet und konfiguriert werden soll, während er den Status sieht, in dem sich der tatsächliche Status vom gewünschten unterscheidet. Dies ist ein Bild des Benutzers. Was ist drinnen los?

Wir zeichnen den gewünschten Status in der Yandex-Datenbank auf und konfigurieren verschiedene Teile unserer VPC. Das Overlay-Netzwerk in Yandex.Cloud basiert auf ausgewählten Komponenten von OpenContrail, das kürzlich als Tungsten Fabric bezeichnet wurde. 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 Steuerinformationen und VPP - für die Implementierung eines Software-Routers, der auf DPDK für den Datenpfad arbeitet.

Tungsten Fabric kommuniziert mit CloudGate über GoBGP. Zeigt an, was im Overlay-Netzwerk passiert. CloudGate wiederum verbindet Overlay-Netzwerke miteinander und mit dem Internet.



Lassen Sie uns nun sehen, wie ein virtuelles Netzwerk Skalierbarkeit und Verfügbarkeit berücksichtigt. Betrachten Sie einen einfachen Fall. Es gibt eine Verfügbarkeitszone und zwei VPCs werden darin erstellt. Wir haben eine Instanz von Tungsten Fabric bereitgestellt, die Zehntausende von Netzwerken einbezieht. Netzwerke kommunizieren mit CloudGate. Wie bereits erwähnt, stellt CloudGate die Konnektivität untereinander und mit dem Internet sicher.



Angenommen, eine zweite Barrierefreiheitszone wurde hinzugefügt. Es sollte völlig unabhängig von der ersten fehlschlagen. Daher müssen wir in der zweiten Zugriffszone eine separate Tungsten Fabric-Instanz bereitstellen. Dies wird ein separates System sein, das sich mit Überlagerungen befasst und wenig über das erste System weiß. Und der Anschein, dass unser virtuelles Netzwerk global ist, schafft tatsächlich unsere VPC-API. Das ist seine Aufgabe.

VPC1 wird in die Zugriffszone B projiziert, wenn sich in der Zugriffszone B Ressourcen befinden, die in VPC1 verbleiben. Wenn in Zugriffszone B keine Ressourcen von VPC2 vorhanden sind, wird VPC2 in dieser Zone nicht materialisiert. Da Ressourcen von VPC3 nur in Zone B vorhanden sind, befindet sich VPC3 wiederum nicht in Zone A. Alles ist einfach und logisch.

Lassen Sie uns etwas tiefer gehen und sehen, wie ein bestimmter Host in Y. Cloud angeordnet ist. Die Hauptsache, die ich beachten möchte, ist, dass alle Hosts auf die gleiche Weise angeordnet sind. Wir sorgen dafür, dass sich nur das erforderliche Minimum an Diensten auf der Hardware dreht, der Rest funktioniert auf virtuellen Maschinen. Wir bauen Dienste höherer Ordnung auf der Grundlage grundlegender Infrastrukturdienste auf und verwenden die Cloud auch, um einige technische Probleme zu lösen, beispielsweise im Rahmen der kontinuierlichen Integration.



Wenn wir uns einen bestimmten Host ansehen, werden wir feststellen, dass sich drei Komponenten im Host-Betriebssystem drehen:
  • Compute ist der Teil, der für die Verteilung der Computerressourcen auf dem Host verantwortlich ist.
  • VRouter ist Teil des Wolframgewebes, das die Überlagerung organisiert, dh Pakete durch die Unterlage tunnelt.
  • VDisk sind Teile der Speichervirtualisierung.

Darüber hinaus wurden Dienste in virtuellen Maschinen eingeführt: Cloud-Infrastrukturdienste, Plattformdienste und Kundenfunktionen. Kundenfunktionen und Plattformservices werden immer über VRouter überlagert.

Infrastrukturdienste können in der Überlagerung bleiben, aber im Grunde wollen sie an der Unterlage arbeiten. Sie werden mittels SR-IOV in eine Unterlage geklebt. Tatsächlich schneiden wir die Karte in virtuelle Netzwerkkarten (virtuelle Funktionen) und schieben sie in virtuelle Infrastrukturmaschinen, um die Leistung nicht zu verlieren. Beispielsweise wird dasselbe CloudGate wie eine dieser virtuellen Infrastrukturmaschinen gestartet.

Nachdem wir nun die globalen Aufgaben des virtuellen Netzwerks und die Anordnung der Grundkomponenten der Cloud beschrieben haben, wollen wir sehen, wie genau die verschiedenen Teile des virtuellen Netzwerks miteinander interagieren.

Wir unterscheiden drei Schichten in unserem System:
  • Konfigurationsebene - Legt den Zielstatus des Systems fest. Dies konfiguriert der Benutzer über die API.
  • Steuerebene - Bietet eine benutzerdefinierte Semantik, dh, der Status der Datenebene wird auf den vom Benutzer in der Konfigurationsebene beschriebenen Status gebracht.
  • Datenebene - verarbeitet Benutzerpakete direkt.



Wie oben erwähnt, beginnt alles mit der Tatsache, dass ein Benutzer oder ein interner Plattformdienst zur API kommt und einen bestimmten Zielstatus beschreibt.

Dieser Status wird sofort in der Yandex-Datenbank aufgezeichnet, gibt die ID der asynchronen Operation über die API zurück und startet unsere interne Maschinerie, um den vom Benutzer gewünschten Status zurückzugeben. Konfigurationsaufgaben gehen zum SDN-Controller und teilen Tungsten Fabric mit, was im Overlay zu tun ist. Beispielsweise reservieren sie Ports, virtuelle Netzwerke und dergleichen.



Die Konfigurationsebene bei Tungsten Fabric sendet den erforderlichen Status an die Steuerungsebene. Dadurch kommuniziert Config Plane mit Hosts und teilt mit, was sie in naher Zukunft einschalten werden.



Nun wollen wir sehen, wie das System auf Hosts aussieht. In der virtuellen Maschine steckt ein bestimmter Netzwerkadapter in VRouter. VRouter ist ein Wolfram-Fabric-Kernmodul, das Pakete betrachtet. 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, dh es sendet das Paket an den Benutzermodusprozess. Der Prozess analysiert das Paket und antwortet entweder selbst darauf, beispielsweise auf DHCP und DNS, oder teilt VRouter mit, was damit zu tun ist. Danach kann der VRouter das Paket verarbeiten.

Darüber hinaus wird der Datenverkehr zwischen virtuellen Maschinen innerhalb desselben virtuellen Netzwerks transparent ausgeführt und nicht an CloudGate weitergeleitet. Hosts, auf denen virtuelle Maschinen bereitgestellt werden, kommunizieren direkt miteinander. Sie tunneln den Verkehr und leiten ihn über die Unterlage aneinander weiter.



Die Steuerebene kommuniziert wie bei einem anderen Router zwischen BGP-Zugriffszonen miteinander. Sie geben an, auf welchen Maschinen sie ausgelöst werden, sodass virtuelle Maschinen in einer Zone direkt mit anderen virtuellen Maschinen interagieren können.



Außerdem kommuniziert Control Plane mit CloudGate. In ähnlicher Weise wird berichtet, wo und welche virtuellen Maschinen ausgelöst werden und wie ihre Adressen lauten. Auf diese Weise können Sie externen Datenverkehr und Datenverkehr von Balancern zu diesen leiten.

Datenverkehr, der VPC verlässt, gelangt zu CloudGate im Datenpfad, wo VPP mit unseren Plugins schnell gekaut wird. Als Nächstes wird der Datenverkehr entweder an anderen VPCs oder an den Edge-Routern nach außen ausgelöst, die über die Steuerebene von CloudGate konfiguriert wurden.

Pläne für die nahe Zukunft


Wenn wir alle oben genannten Punkte in mehreren Sätzen zusammenfassen, können wir sagen, dass VPC in Yandex.Cloud zwei wichtige Aufgaben löst:

  • Bietet Isolation zwischen verschiedenen Kunden.
  • Kombiniert Ressourcen, Infrastruktur, Plattformdienste, andere Clouds und On-Premise in einem einzigen Netzwerk.

Um diese Probleme gut zu lösen, müssen Sie Skalierbarkeit und Fehlertoleranz auf der Ebene der internen Architektur bereitstellen, wie dies bei VPC der Fall ist.

VPC erwirbt nach und nach Funktionen, wir erkennen neue Möglichkeiten und versuchen, die Benutzerfreundlichkeit zu verbessern. Einige Ideen werden geäußert und fallen dank Mitgliedern unserer Community in die Prioritätenliste.

Jetzt haben wir ungefähr die folgende Liste von Plänen für die nahe Zukunft:

  • VPN als Dienst.
  • Private DNS – DNS-.
  • DNS .
  • .
  • «» IP- .

Der Balancer und die Möglichkeit, die IP-Adresse für die bereits erstellte virtuelle Maschine zu wechseln, wurden auf Anforderung der Benutzer in dieser Liste aufgeführt. Ehrlich gesagt, würden wir diese Funktionen ohne explizites Feedback etwas später übernehmen. Und so arbeiten wir bereits an einer Aufgabe über Adressen.

Eine "weiße" IP-Adresse konnte zunächst nur beim Erstellen des Computers hinzugefügt werden. Wenn der Benutzer dies vergessen hat, musste die virtuelle Maschine neu erstellt werden. Das Gleiche und entfernen Sie gegebenenfalls die externe IP. In Kürze wird es möglich sein, die öffentliche IP-Adresse ein- und auszuschalten, ohne die Maschine neu zu erstellen.

Fühlen Sie sich frei, Ihre Ideen auszudrücken und die Vorschläge anderer Benutzer zu unterstützen. Sie helfen uns, die Cloud zu verbessern und wichtige und nützliche Funktionen schneller zu erhalten!

Source: https://habr.com/ru/post/undefined/

More articles:


All Articles