Hallo, ich bin Kostiya Kramlih, der leitende Entwickler der Abteilung für Virtual Private Cloud bei Yandex.Cloud. Ich beschäftige mich mit virtuellen Netzwerken und wie Sie sich denken können, werde ich in diesem Artikel das Konzept des Virtual Private Cloud (VPC) im Allgemeinen und das virtuelle Netzwerk im Besonderen erläutern. Außerdem erfahren Sie, warum wir, die Entwickler des Dienstes, das Feedback unserer Nutzer schätzen. Aber der Reihe nach.
Was ist ein VPC?
Heute gibt es viele Möglichkeiten, Dienste bereitzustellen. Ich bin mir sicher, dass einige immer noch einen Server unter dem Tisch des Administrators stehen haben, wobei ich hoffe, dass solche Geschichten immer seltener werden.
Derzeit versuchen viele Dienste, in öffentliche Clouds zu migrieren, und genau hier begegnen sie dem VPC. Ein VPC ist ein Teil der öffentlichen Cloud, der Benutzer-, Infrastruktur-, Plattform- und andere Ressourcen miteinander verbindet, egal wo sie sich befinden, sei es in unserer Cloud oder außerhalb. Dabei ermöglicht es das VPC, diese Ressourcen nicht unnötig ins Internet zu veröffentlichen; sie bleiben innerhalb Ihres isolierten Netzwerks.
Wie sieht ein virtuelles Netzwerk von außen aus?
Unter VPC verstehen wir in erster Linie ein Overlay-Netzwerk und Netzwerkdienste wie VPNaaS, NATaaS, LBaaS und so weiter. Und all dies funktioniert auf einer ausfallsicheren Netzwerk-Infrastruktur, über die bereits berichtet wurde ein ausgezeichneter Artikel hier auf Habr.
Lassen Sie uns das virtuelle Netzwerk und seine Struktur näher betrachten.
Betrachten wir zwei Verfügbarkeitszonen. Wir bieten ein virtuelles Netzwerk an – das, was wir VPC genannt haben. Tatsächlich definiert es den Bereich der Einzigartigkeit Ihrer "grauen" Adressen. Innerhalb jedes virtuellen Netzwerks verwalten Sie vollständig den Adressraum, den Sie den Rechenressourcen zuweisen können.
Das Netzwerk ist global. Es wird jedoch in jeder Verfügbarkeitzone durch eine Entität namens Subnet projiziert. Für jedes Subnet weisen Sie eine CIDR mit einer Größe 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, selbst wenn sie sich in verschiedenen Verfügbarkeitszonen befinden. "Kommunikation" findet statt, ohne ins Internet zu gehen, über unsere internen Kanäle, womit sie glauben, sich innerhalb eines privaten Netzwerks zu befinden.
Das obige Diagramm zeigt eine typische Situation: zwei VPCs, die sich an bestimmten Stellen in den Adressen überschneiden. Beide können Ihnen gehören. Zum Beispiel eine für die Entwicklung und die andere für das Testen. Es können einfach verschiedene Benutzer sein – in diesem Fall spielt das keine Rolle. In jede VPC ist eine virtuelle Maschine integriert.
Verkomplizieren wir das Diagramm. Es ist möglich, dass eine virtuelle Maschine gleichzeitig in mehrere Subnets integriert ist. Und nicht einfach so, sondern in verschiedenen virtuellen Netzwerken.
Wenn Sie virtuelle Maschinen ins Internet stellen müssen, können Sie dies über die API oder die Benutzeroberfläche tun. Dafür ist es erforderlich, die NAT-Übersetzung Ihrer "grauen", internen IP-Adresse in eine "weiße" – öffentliche Adresse einzurichten. Sie können die "weiße" Adresse nicht wä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 Nutzungszeit der "weißen" Adresse.
Es besteht auch die Möglichkeit, einer Maschine über eine NAT-Instanz Internetzugang zu gewähren. Der Traffic kann über eine statische Routing-Tabelle zu dieser Instanz geleitet werden. Wir haben diesen Fall vorgesehen, weil wir wissen, dass er für einige Benutzer erforderlich ist. In unserem Katalog finden Sie daher ein speziell konfiguriertes NAT-Image.
Aber selbst wenn es ein fertiges NAT-Image gibt, kann die Einrichtung kompliziert sein. Wir haben erkannt, dass dies für einige Benutzer nicht die bequemste Option ist, und haben daher die Möglichkeit geschaffen, NAT für das gewünschte Subnetz mit einem Klick zu aktivieren. Diese Funktion ist derzeit noch im geschlossenen Vorschau-Zugang, wo sie mit Hilfe von Community-Mitgliedern getestet wird.
Wie das virtuelle Netzwerk intern aufgebaut ist
Wie interagiert ein Benutzer mit dem virtuellen Netzwerk? Das Netzwerk betrachtet die externe API. Der Benutzer greift auf die API zu und arbeitet mit dem gewünschten Zustand. Über die API sieht der Benutzer, wie alles organisiert und konfiguriert sein sollte, während er den Status einsehen kann, wie stark der aktuelle Zustand vom gewünschten abweicht. Dies ist die Benutzeransicht. Was geschieht jedoch im Hintergrund?
Wir speichern den gewünschten Zustand in der Yandex-Datenbank und beginnen mit der Konfiguration verschiedener Teile unserer VPC. Das Overlay-Netzwerk in Yandex.Cloud basiert auf ausgewählten Komponenten von OpenContrail, das seit kurzem den Namen Tungsten Fabric trägt. Die Netzwerkdienste werden auf einer einheitlichen Plattform, CloudGate, bereitgestellt. In CloudGate haben wir auch eine Reihe von Open-Source-Komponenten verwendet: GoBGP zur Verwaltung von Kontrollinformationen und VPP für die Implementierung eines Software-Routers, der auf DPDK für den Datenpfad basiert.
Tungsten Fabric kommuniziert über GoBGP mit CloudGate. Es meldet, was im Overlay-Netzwerk geschieht. CloudGate verbindet wiederum die Overlay-Netzwerke untereinander und mit dem Internet.
Lassen Sie uns nun untersuchen, wie ein virtuelles Netzwerk die Herausforderungen von Skalierbarkeit und Verfügbarkeit meistert. Betrachten wir einen einfachen Fall. Es gibt eine Verfügbarkeitszone, in der zwei VPCs eingerichtet sind. Wir haben eine Instanz von Tungsten Fabric bereitgestellt, die mehrere zehntausend Netzwerke unterstützt. Diese Netzwerke sind mit CloudGate verbunden. CloudGate sorgt, wie bereits erwähnt, für deren Vernetzung und die Verbindung zum Internet.
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 installieren. Dies ist ein eigenständiges System, das sich mit dem Overlay befasst und kaum Informationen über das erste System hat. Die Sichtbarkeit, dass unser virtuelles Netzwerk global ist, wird durch unsere VPC-API geschaffen. Dies ist ihre Aufgabe.
VPC1 wird in die Verfügbarkeitszone B projiziert, wenn in der Verfügbarkeitszone B Ressourcen vorhanden sind, die mit VPC1 verbunden werden können. Wenn keine Ressourcen aus VPC2 in der Verfügbarkeitszone B vorhanden sind, werden wir VPC2 in dieser Zone nicht bereitstellen. Da die Ressourcen aus VPC3 nur in Zone B existieren, ist VPC3 in Zone A nicht vorhanden. Alles ist einfach und logisch.
Lassen Sie uns etwas tiefer eintauchen und sehen, wie ein spezifischer Host in Y.Cloud aufgebaut ist. Das Wichtigste, was man hervorheben sollte, ist, dass alle Hosts gleich aufgebaut sind. Wir sorgen dafür, dass nur die notwendige Grundausstattung an Dienstleistungen auf der Hardware läuft, während alle anderen Dienste auf virtuellen Maschinen wurde vereinfacht.. Wir erstellen Dienste höherer Ordnung auf der Basis grundlegender Infrastrukturservices und nutzen die Cloud zur Lösung bestimmter Ingenieuraufgaben, wie beispielsweise im Rahmen der Continuous Integration.
Wenn wir uns einen spezifischen Host ansehen, stellen wir fest, dass im Betriebssystem des Hosts drei Komponenten 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 einrichtet, also Pakete durch das Underlay tunnelt.
- VDisk – dies sind Segmente der Speichervirtualisierung.
Darüber hinaus sind in virtuellen Maschinen wurde vereinfacht. diese Services aktiv: Infrastrukturservices der Cloud, Plattformservices und die Kapazitäten der Kunden. Die Kapazitäten der Kunden und die Plattformservices sind stets über VRouter im Overlay verbunden.
Infrastrukturservices können in Overlay-Netzwerke integriert werden, aber sie möchten hauptsächlich im Underlay arbeiten. Dort werden sie mithilfe von SR-IOV integriert. Tatsächlich teilen wir die Netzwerkadapter in virtuelle Netzwerkfunktionen auf und stecken sie in Infrastruktur-Virtual Machines, um Leistungseinbußen zu vermeiden. Beispielsweise läuft das CloudGate als eine dieser Infrastruktur-Virtual Machines.
Jetzt, da wir die globalen Aufgaben des virtuellen Netzwerks und die Struktur der grundlegenden Cloud-Komponenten beschrieben haben, schauen wir uns an, wie die verschiedenen Teile des virtuellen Netzwerks miteinander interagieren.
In unserem System unterscheiden wir drei Schichten:
- Config Plane – legt den angestrebten Zustand des Systems fest. Dies geschieht durch Konfiguration des Benutzers über die API.
- Control Plane – sorgt dafür, dass die vom Benutzer definierte Semantik eingehalten wird, das heißt, sie bringt den Zustand des Data Plane in Übereinstimmung mit dem, was der Benutzer im Config Plane beschrieben hat.
- Data Plane – verarbeitet direkt die Benutzerdatenpakete.
Wie bereits erwähnt, beginnt alles damit, dass der Benutzer oder ein interner Plattformdienst über die API kommt und einen bestimmten Zielzustand beschreibt.
Dieser Zustand wird sofort in der Yandex-Datenbank gespeichert, 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 und Ähnliches.
Das Config Plane in Tungsten Fabric liefert den benötigten Zustand an das Control Plane. Darüber kommuniziert das Config Plane auch mit den Hosts und informiert sie darüber, was bald auf ihnen ausgeführt wird.
Jetzt schauen wir uns an, wie das System auf den Hosts aussieht. In virtuellen Maschine gibt es einen Netzwerkadapter, der im VRouter eingesteckt ist. VRouter ist das Kernmodul von Tungsten Fabric, das die Pakete überwacht. Wenn für ein bestimmtes Paket bereits ein Flow existiert, wird dieses vom Modul verarbeitet. Wenn kein Flow vorhanden ist, führt das Modul so genanntes Punten 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 informiert den VRouter darüber, was damit zu tun ist. Danach kann der VRouter das Paket verarbeiten.
Der Datenverkehr zwischen virtuellen Maschinen innerhalb eines virtuellen Netzwerks erfolgt transparent und wird nicht über CloudGate geleitet. Die Hosts, auf denen die virtuellen Maschinen bereitgestellt sind, kommunizieren direkt miteinander. Der Datenverkehr wird getunnelt und über Unterlagen weitergeleitet.
Der Control Plane kommuniziert untereinander über die Verfügbarkeitszonen hinweg mithilfe von BGP, ähnlich wie mit einem anderen Router. Sie informieren, welche Maschinen wo aktiv sind, sodass virtuelle Maschinen in einer Zone direkt mit anderen virtuellen Maschinen interagieren können.
Zusätzlich kommuniziert der Control Plane mit CloudGate. Er informiert ebenfalls darüber, wo und welche virtuellen Maschinen aktiv sind und welche IP-Adressen sie haben. Dadurch kann externer Datenverkehr sowie der Verkehr von Load Balancern zu ihnen geleitet werden.
Der Datenverkehr, der aus dem VPC austritt, gelangt zu CloudGate in den Datenpfad, wo er schnell von VPP mit unseren Plugins verarbeitet wird. Danach wird der Datenverkehr entweder an andere VPCs oder nach außen zu den Grenzroutern weitergeleitet, die über den Control Plane von CloudGate konfiguriert werden.
Pläne für die nächste Zukunft
Um alles oben Gesagte in wenigen Sätzen zusammenzufassen, kann man sagen, dass VPC in Yandex.Cloud zwei wichtige Aufgaben löst:
- Sorgt für Isolation zwischen verschiedenen Kunden.
- Vereint Ressourcen, Infrastruktur, Plattformdienste, andere Clouds und On-Premise in einem einzigen Netzwerk.
Um diese Aufgaben gut zu bewältigen, muss Skalierbarkeit und Ausfallsicherheit auf der Ebene der internen Architektur sichergestellt werden, was VPC ermöglicht.
Das VPC entwickelt sich stetig weiter, wir setzen neue Funktionen um und bemühen uns, die Benutzerfreundlichkeit zu verbessern. Einige Ideen werden geäußert und landen dank der Mitglieder unserer Community auf der Prioritätenliste.
Momentan haben wir etwa folgende Pläne für die nahe Zukunft:
- VPN als Dienst.
- Private DNS-Instanzen – Vorlagen für die schnelle Konfiguration virtueller Maschinen mit einem vorab konfigurierten DNS-Server.
- DNS als Dienst.
- Interner Lastenausgleich.
- Hinzufügen einer „weißen“ IP-Adresse ohne die Notwendigkeit, die virtuelle Maschine neu zu erstellen.
Der Lastenausgleich und die Möglichkeit, die IP-Adresse für bereits erstellte virtuelle Maschinen zu wechseln, stehen aufgrund der Nutzungsanfragen auf dieser Liste. Ehrlich gesagt würden wir uns ohne eindeutiges Feedback später mit diesen Funktionen beschäftigen. Jetzt 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 Nutzer dies vergaß, musste die virtuelle Maschine neu erstellt werden. Das Gleiche galt, wenn eine externe IP entfernt werden musste. Bald wird es möglich sein, die öffentliche IP ein- und auszuschalten, ohne die Maschine neu zu erstellen.
Scheuen Sie sich nicht, Ihre Ideen und Vorschläge anderer Nutzer zu unterstützen. Sie helfen uns, die Cloud zu verbessern und erhalten schneller wichtige und nützliche Funktionen!
Quelle: habr.com
