![\"Wie](\"\/wp-content\/uploads\/2020\/02\/62b3d222c1911fb28a345defdd81135c.jpeg\")
<\/p>\nHallo, ich bin Kostiya Kramlih, der leitende Entwickler der Abteilung f\u00fcr Virtual Private Cloud bei Yandex.Cloud. Ich besch\u00e4ftige mich mit virtuellen Netzwerken und wie Sie sich denken k\u00f6nnen, werde ich in diesem Artikel das Konzept des Virtual Private Cloud (VPC) im Allgemeinen und das virtuelle Netzwerk im Besonderen erl\u00e4utern. Au\u00dferdem erfahren Sie, warum wir, die Entwickler des Dienstes, das Feedback unserer Nutzer sch\u00e4tzen. Aber der Reihe nach.<\/p>\n
<\/p>\n
<\/a><\/p>\n Heute gibt es viele M\u00f6glichkeiten, 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.<\/p>\n Derzeit versuchen viele Dienste, in \u00f6ffentliche Clouds zu migrieren, und genau hier begegnen sie dem VPC. Ein VPC ist ein Teil der \u00f6ffentlichen Cloud, der Benutzer-, Infrastruktur-, Plattform- und andere Ressourcen miteinander verbindet, egal wo sie sich befinden, sei es in unserer Cloud oder au\u00dferhalb. Dabei erm\u00f6glicht es das VPC, diese Ressourcen nicht unn\u00f6tig ins Internet zu ver\u00f6ffentlichen; sie bleiben innerhalb Ihres isolierten Netzwerks.<\/p>\n 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, \u00fcber die bereits berichtet wurde ein ausgezeichneter Artikel<\/a> hier auf Habr.<\/p>\n Lassen Sie uns das virtuelle Netzwerk und seine Struktur n\u00e4her betrachten.<\/p>\n Betrachten wir zwei Verf\u00fcgbarkeitszonen. Wir bieten ein virtuelles Netzwerk an \u2013 das, was wir VPC genannt haben. Tats\u00e4chlich definiert es den Bereich der Einzigartigkeit Ihrer \"grauen\" Adressen. Innerhalb jedes virtuellen Netzwerks verwalten Sie vollst\u00e4ndig den Adressraum, den Sie den Rechenressourcen zuweisen k\u00f6nnen.<\/p>\n Das Netzwerk ist global. Es wird jedoch in jeder Verf\u00fcgbarkeitzone durch eine Entit\u00e4t namens Subnet projiziert. F\u00fcr jedes Subnet weisen Sie eine CIDR mit einer Gr\u00f6\u00dfe von 16 oder weniger zu. In jeder Verf\u00fcgbarkeitszone kann es mehr als eine solche Entit\u00e4t geben, wobei zwischen ihnen immer ein transparenter Routing besteht. Das bedeutet, dass alle Ihre Ressourcen innerhalb einer VPC miteinander \"kommunizieren\" k\u00f6nnen, selbst wenn sie sich in verschiedenen Verf\u00fcgbarkeitszonen befinden. \"Kommunikation\" findet statt, ohne ins Internet zu gehen, \u00fcber unsere internen Kan\u00e4le, womit sie glauben, sich innerhalb eines privaten Netzwerks zu befinden.<\/p>\n Das obige Diagramm zeigt eine typische Situation: zwei VPCs, die sich an bestimmten Stellen in den Adressen \u00fcberschneiden. Beide k\u00f6nnen Ihnen geh\u00f6ren. Zum Beispiel eine f\u00fcr die Entwicklung und die andere f\u00fcr das Testen. Es k\u00f6nnen einfach verschiedene Benutzer sein \u2013 in diesem Fall spielt das keine Rolle. In jede VPC ist eine virtuelle Maschine integriert.<\/p>\n Verkomplizieren wir das Diagramm. Es ist m\u00f6glich, dass eine virtuelle Maschine gleichzeitig in mehrere Subnets integriert ist. Und nicht einfach so, sondern in verschiedenen virtuellen Netzwerken.<\/p>\n Wenn Sie virtuelle Maschinen ins Internet stellen m\u00fcssen, k\u00f6nnen Sie dies \u00fcber die API oder die Benutzeroberfl\u00e4che tun. Daf\u00fcr ist es erforderlich, die NAT-\u00dcbersetzung Ihrer \"grauen\", internen IP-Adresse in eine \"wei\u00dfe\" \u2013 \u00f6ffentliche Adresse einzurichten. Sie k\u00f6nnen die \"wei\u00dfe\" Adresse nicht w\u00e4hlen, sie wird zuf\u00e4llig aus unserem Adresspool zugewiesen. Sobald Sie die externe IP nicht mehr nutzen, wird sie wieder in den Pool zur\u00fcckgegeben. Sie zahlen nur f\u00fcr die Nutzungszeit der \"wei\u00dfen\" Adresse.<\/p>\n Es besteht auch die M\u00f6glichkeit, einer Maschine \u00fcber eine NAT-Instanz Internetzugang zu gew\u00e4hren. Der Traffic kann \u00fcber eine statische Routing-Tabelle zu dieser Instanz geleitet werden. Wir haben diesen Fall vorgesehen, weil wir wissen, dass er f\u00fcr einige Benutzer erforderlich ist. In unserem Katalog finden Sie daher ein speziell konfiguriertes NAT-Image.<\/p>\n Aber selbst wenn es ein fertiges NAT-Image gibt, kann die Einrichtung kompliziert sein. Wir haben erkannt, dass dies f\u00fcr einige Benutzer nicht die bequemste Option ist, und haben daher die M\u00f6glichkeit geschaffen, NAT f\u00fcr das gew\u00fcnschte Subnetz mit einem Klick zu aktivieren. Diese Funktion ist derzeit noch im geschlossenen Vorschau-Zugang, wo sie mit Hilfe von Community-Mitgliedern getestet wird.<\/p>\n 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\u00fcnschten Zustand. \u00dcber die API sieht der Benutzer, wie alles organisiert und konfiguriert sein sollte, w\u00e4hrend er den Status einsehen kann, wie stark der aktuelle Zustand vom gew\u00fcnschten abweicht. Dies ist die Benutzeransicht. Was geschieht jedoch im Hintergrund?<\/p>\n Wir speichern den gew\u00fcnschten Zustand in der Yandex-Datenbank und beginnen mit der Konfiguration verschiedener Teile unserer VPC. Das Overlay-Netzwerk in Yandex.Cloud basiert auf ausgew\u00e4hlten Komponenten von OpenContrail, das seit kurzem den Namen Tungsten Fabric tr\u00e4gt. 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\u00fcr die Implementierung eines Software-Routers, der auf DPDK f\u00fcr den Datenpfad basiert.<\/p>\n Tungsten Fabric kommuniziert \u00fcber GoBGP mit CloudGate. Es meldet, was im Overlay-Netzwerk geschieht. CloudGate verbindet wiederum die Overlay-Netzwerke untereinander und mit dem Internet.<\/p>\n Lassen Sie uns nun untersuchen, wie ein virtuelles Netzwerk die Herausforderungen von Skalierbarkeit und Verf\u00fcgbarkeit meistert. Betrachten wir einen einfachen Fall. Es gibt eine Verf\u00fcgbarkeitszone, in der zwei VPCs eingerichtet sind. Wir haben eine Instanz von Tungsten Fabric bereitgestellt, die mehrere zehntausend Netzwerke unterst\u00fctzt. Diese Netzwerke sind mit CloudGate verbunden. CloudGate sorgt, wie bereits erw\u00e4hnt, f\u00fcr deren Vernetzung und die Verbindung zum Internet.<\/p>\n Angenommen, es wird eine zweite Verf\u00fcgbarkeitszone hinzugef\u00fcgt. Diese sollte v\u00f6llig unabh\u00e4ngig von der ersten ausfallen. Daher m\u00fcssen wir in der zweiten Verf\u00fcgbarkeitszone eine separate Instanz von Tungsten Fabric installieren. Dies ist ein eigenst\u00e4ndiges System, das sich mit dem Overlay befasst und kaum Informationen \u00fcber das erste System hat. Die Sichtbarkeit, dass unser virtuelles Netzwerk global ist, wird durch unsere VPC-API geschaffen. Dies ist ihre Aufgabe.<\/p>\n VPC1 wird in die Verf\u00fcgbarkeitszone B projiziert, wenn in der Verf\u00fcgbarkeitszone B Ressourcen vorhanden sind, die mit VPC1 verbunden werden k\u00f6nnen. Wenn keine Ressourcen aus VPC2 in der Verf\u00fcgbarkeitszone 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.<\/p>\n 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\u00fcr, dass nur die notwendige Grundausstattung an Dienstleistungen auf der Hardware l\u00e4uft, w\u00e4hrend alle anderen Dienste auf virtuellen Maschinen wurde vereinfacht.<\/a>. Wir erstellen Dienste h\u00f6herer Ordnung auf der Basis grundlegender Infrastrukturservices und nutzen die Cloud zur L\u00f6sung bestimmter Ingenieuraufgaben, wie beispielsweise im Rahmen der Continuous Integration.<\/p>\n Wenn wir uns einen spezifischen Host ansehen, stellen wir fest, dass im Betriebssystem des Hosts drei Komponenten laufen:<\/p>\n Dar\u00fcber hinaus sind in virtuellen Maschinen wurde vereinfacht.<\/a> diese Services aktiv: Infrastrukturservices der Cloud, Plattformservices und die Kapazit\u00e4ten der Kunden. Die Kapazit\u00e4ten der Kunden und die Plattformservices sind stets \u00fcber VRouter im Overlay verbunden.<\/p>\n Infrastrukturservices k\u00f6nnen in Overlay-Netzwerke integriert werden, aber sie m\u00f6chten haupts\u00e4chlich im Underlay arbeiten. Dort werden sie mithilfe von SR-IOV integriert. Tats\u00e4chlich teilen wir die Netzwerkadapter in virtuelle Netzwerkfunktionen auf und stecken sie in Infrastruktur-Virtual Machines, um Leistungseinbu\u00dfen zu vermeiden. Beispielsweise l\u00e4uft das CloudGate als eine dieser Infrastruktur-Virtual Machines.<\/p>\n 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.<\/p>\n In unserem System unterscheiden wir drei Schichten:<\/p>\n Wie bereits erw\u00e4hnt, beginnt alles damit, dass der Benutzer oder ein interner Plattformdienst \u00fcber die API kommt und einen bestimmten Zielzustand beschreibt.<\/p>\n Dieser Zustand wird sofort in der Yandex-Datenbank gespeichert, gibt \u00fcber die API die ID der asynchronen Operation zur\u00fcck und startet unsere interne Mechanik, um den Zustand bereitzustellen, den der Benutzer wollte. Konfigurationstasks gehen an den SDN-Controller und informieren Tungsten Fabric dar\u00fcber, was im Overlay zu tun ist. Zum Beispiel reservieren sie Ports, virtuelle Netzwerke und \u00c4hnliches.<\/p>\n Das Config Plane in Tungsten Fabric liefert den ben\u00f6tigten Zustand an das Control Plane. Dar\u00fcber kommuniziert das Config Plane auch mit den Hosts und informiert sie dar\u00fcber, was bald auf ihnen ausgef\u00fchrt wird.<\/p>\n Jetzt schauen wir uns an, wie das System auf den Hosts aussieht. In virtuellen Maschine<\/a> gibt es einen Netzwerkadapter, der im VRouter eingesteckt ist. VRouter ist das Kernmodul von Tungsten Fabric, das die Pakete \u00fcberwacht. Wenn f\u00fcr ein bestimmtes Paket bereits ein Flow existiert, wird dieses vom Modul verarbeitet. Wenn kein Flow vorhanden ist, f\u00fchrt das Modul so genanntes Punten durch, das hei\u00dft, 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\u00fcber, was damit zu tun ist. Danach kann der VRouter das Paket verarbeiten.<\/p>\n Der Datenverkehr zwischen virtuellen Maschinen innerhalb eines virtuellen Netzwerks erfolgt transparent und wird nicht \u00fcber CloudGate geleitet. Die Hosts, auf denen die virtuellen Maschinen bereitgestellt sind, kommunizieren direkt miteinander. Der Datenverkehr wird getunnelt und \u00fcber Unterlagen weitergeleitet.<\/p>\n Der Control Plane kommuniziert untereinander \u00fcber die Verf\u00fcgbarkeitszonen hinweg mithilfe von BGP, \u00e4hnlich 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\u00f6nnen.<\/p>\n Zus\u00e4tzlich kommuniziert der Control Plane mit CloudGate. Er informiert ebenfalls dar\u00fcber, 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.<\/p>\n 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\u00dfen zu den Grenzroutern weitergeleitet, die \u00fcber den Control Plane von CloudGate konfiguriert werden.<\/p>\n Um alles oben Gesagte in wenigen S\u00e4tzen zusammenzufassen, kann man sagen, dass VPC in Yandex.Cloud zwei wichtige Aufgaben l\u00f6st:<\/p>\n Um diese Aufgaben gut zu bew\u00e4ltigen, muss Skalierbarkeit und Ausfallsicherheit auf der Ebene der internen Architektur sichergestellt werden, was VPC erm\u00f6glicht.<\/p>\n Das VPC entwickelt sich stetig weiter, wir setzen neue Funktionen um und bem\u00fchen uns, die Benutzerfreundlichkeit zu verbessern. Einige Ideen werden ge\u00e4u\u00dfert und landen dank der Mitglieder unserer Community auf der Priorit\u00e4tenliste.<\/p>\n Momentan haben wir etwa folgende Pl\u00e4ne f\u00fcr die nahe Zukunft:<\/p>\n Der Lastenausgleich und die M\u00f6glichkeit, die IP-Adresse f\u00fcr bereits erstellte virtuelle Maschinen zu wechseln, stehen aufgrund der Nutzungsanfragen auf dieser Liste. Ehrlich gesagt w\u00fcrden wir uns ohne eindeutiges Feedback sp\u00e4ter mit diesen Funktionen besch\u00e4ftigen. Jetzt arbeiten wir bereits an der Aufgabe bez\u00fcglich der Adressen.<\/p>\n Urspr\u00fcnglich konnte eine \"wei\u00dfe\" IP-Adresse nur bei der Erstellung der Maschine hinzugef\u00fcgt werden. Wenn der Nutzer dies verga\u00df, musste die virtuelle Maschine neu erstellt werden. Das Gleiche galt, wenn eine externe IP entfernt werden musste. Bald wird es m\u00f6glich sein, die \u00f6ffentliche IP ein- und auszuschalten, ohne die Maschine neu zu erstellen.<\/p>\n Scheuen Sie sich nicht, Ihre Ideen und Vorschl\u00e4ge<\/a> anderer Nutzer zu unterst\u00fctzen. Sie helfen uns, die Cloud zu verbessern und erhalten schneller wichtige und n\u00fctzliche Funktionen!<\/p>\nWas ist ein VPC?<\/h2>\n
Wie sieht ein virtuelles Netzwerk von au\u00dfen aus?<\/h2>\n
![\"Wie](\"\/wp-content\/uploads\/2020\/02\/073a0cbac0e733decd8a4e6ffd9570ff.jpeg\")
<\/p>\n![\"Wie](\"\/wp-content\/uploads\/2020\/02\/b1b7a15912f9c7995663ab9943d473f1.jpeg\")
<\/p>\n![\"Wie](\"\/wp-content\/uploads\/2020\/02\/73e872a4f6c3e19576db4e4980d62a45.jpeg\")
<\/p>\n![\"Wie](\"\/wp-content\/uploads\/2020\/02\/cc4ab2c7553d63ef2636924df1575479.jpeg\")
<\/p>\n![\"Wie](\"\/wp-content\/uploads\/2020\/02\/c2375fd6d0fb7b55ca55787adf505229.jpeg\")
<\/p>\n![\"Wie](\"\/wp-content\/uploads\/2020\/02\/744ac3bdd2f388bab2597d6fe1519d76.jpeg\")
<\/p>\nWie das virtuelle Netzwerk intern aufgebaut ist<\/h2>\n
![\"Wie](\"\/wp-content\/uploads\/2020\/02\/71cab3ae7f067f165a87e30c60559794.jpeg\")
<\/p>\n![\"Wie](\"\/wp-content\/uploads\/2020\/02\/222d68fff4b9577f316c8642e846172e.jpeg\")
<\/p>\n![\"Wie](\"\/wp-content\/uploads\/2020\/02\/4da02ba041dcd886eee212dd8998718c.jpeg\")
<\/p>\n![\"Wie](\"\/wp-content\/uploads\/2020\/02\/4664bd03793ba394ceda1f8214fa2c16.jpeg\")
<\/p>\n\n
\n
![\"Wie](\"\/wp-content\/uploads\/2020\/02\/644cddfa8bce83a501bf4788a21f9588.jpeg\")
<\/p>\n![\"Wie](\"\/wp-content\/uploads\/2020\/02\/c2c6e443c93f8dedc6a63e4bd3fd7042.jpeg\")
<\/p>\n![\"Wie](\"\/wp-content\/uploads\/2020\/02\/2139361a9e1837c7bc7f156e8bc36d38.jpeg\")
<\/p>\n![\"Wie](\"\/wp-content\/uploads\/2020\/02\/1247f20fa2a12f093d7f1d2361d48a02.jpeg\")
<\/p>\n![\"Wie](\"\/wp-content\/uploads\/2020\/02\/f70cd562220c7367e29597d8e8b62f81.jpeg\")
<\/p>\nPl\u00e4ne f\u00fcr die n\u00e4chste Zukunft<\/h2>\n
\n
\n