![\"Wie](\"\/wp-content\/uploads\/2020\/02\/62b3d222c1911fb28a345defdd81135c.jpeg\")
<\/p>\nHallo, ich hei\u00dfe Kostya Kramlikh, ich bin leitender Entwickler der Abteilung Virtual Private Cloud bei Yandex.Cloud. Ich besch\u00e4ftige mich mit virtuellen Netzwerken und werde in diesem Artikel \u00fcber die Funktionsweise von Virtual Private Cloud (VPC) im Allgemeinen und von virtuellen Netzwerken im Besonderen berichten. Au\u00dferdem erfahren Sie, warum wir, die Entwickler des Dienstes, das Feedback unserer Nutzer sch\u00e4tzen. Doch der Reihe nach.<\/p>\n
<\/p>\n
<\/a><\/p>\n Heute gibt es viele verschiedene M\u00f6glichkeiten, 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.<\/p>\n Jetzt versuchen Dienste, in \u00f6ffentliche Clouds zu wechseln, und genau hier sto\u00dfen sie auf VPC. VPC ist ein Teil der \u00f6ffentlichen Cloud, die benutzerdefinierte, Infrastruktur-, Plattform- und andere Ressourcen miteinander verbindet, egal wo sie sich befinden, in unserer Cloud oder au\u00dferhalb davon. Mit VPC ist es zudem m\u00f6glich, diese Ressourcen nicht unn\u00f6tig ins Internet zu stellen; sie bleiben innerhalb Ihres isolierten Netzwerks.<\/p>\n 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, \u00fcber die bereits geschrieben wurde. ein ausgezeichneter Artikel<\/a> hier auf Habr.<\/p>\n Lassen Sie uns das virtuelle Netzwerk und seine Funktionsweise genauer ansehen.<\/p>\n Betrachten wir zwei Verf\u00fcgbarkeitszonen. Wir bieten ein virtuelles Netzwerk an \u2013 das, was wir VPC nennen. Tats\u00e4chlich definiert es den Raum der Einzigartigkeit Ihrer \"grauen\" Adressen. Innerhalb jedes virtuellen Netzwerks verwalten Sie den Adressraum vollst\u00e4ndig, den Sie Rechenressourcen zuweisen k\u00f6nnen.<\/p>\n Das Netzwerk ist global. Dabei wird es auf jede der Verf\u00fcgbarkeitszonen als Entit\u00e4t namens Subnet projiziert. F\u00fcr jede Subnet weisen Sie einen CIDR 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, auch wenn sie sich in verschiedenen Verf\u00fcgbarkeitszonen befinden. \"Kommunizieren\" ohne ins Internet zu gehen, \u00fcber unsere internen Kan\u00e4le, w\u00e4hrend sie \"glauben\", dass sie sich innerhalb eines privaten Netzwerks befinden.<\/p>\n Das obige Diagramm zeigt eine typische Situation: zwei VPCs, die sich in den Adressen \u00fcberschneiden. Beide k\u00f6nnen Ihnen geh\u00f6ren. Zum Beispiel eine f\u00fcr die Entwicklung, die andere f\u00fcr Tests. Es k\u00f6nnen einfach unterschiedliche Benutzer sein \u2013 in diesem Fall ist das unwichtig. In jede VPC ist eine virtuelle Maschine integriert.<\/p>\n Versch\u00e4rfen 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.<\/p>\n Dabei k\u00f6nnen Sie, wenn Sie Maschinen ins Internet stellen m\u00f6chten, dies \u00fcber die API oder die UI tun. Dazu m\u00fcssen Sie die NAT-\u00dcbersetzung Ihrer \u201egrauen\u201c, internen Adresse in die \u201ewei\u00dfe\u201c \u2013 \u00f6ffentliche Adresse einrichten. Sie k\u00f6nnen die \u201ewei\u00dfe\u201c Adresse nicht ausw\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 Zeit, in der Sie die \u201ewei\u00dfe\u201c Adresse verwenden.<\/p>\n Es besteht auch die M\u00f6glichkeit, einem Rechner \u00fcber eine NAT-Instanz Zugriff auf das Internet zu gew\u00e4hren. Der Verkehr kann \u00fcber eine statische Routingtabelle zu der Instanz geleitet werden. Wir haben diesen Fall ber\u00fccksichtigt, weil er f\u00fcr Benutzer manchmal notwendig ist, und wir sind uns dessen bewusst. In unserem Katalog von Images befindet sich daher ein speziell konfiguriertes NAT-Image.<\/p>\n Doch selbst wenn ein NAT-Image bereitsteht, kann die Konfiguration schwierig sein. Wir haben verstanden, dass dies f\u00fcr einige Benutzer nicht die bequemste Option ist, und haben schlie\u00dflich die M\u00f6glichkeit geschaffen, NAT f\u00fcr das ben\u00f6tigte Subnetz mit einem Klick zu aktivieren. Diese Funktion befindet sich derzeit noch im geschlossenen Vorabzugang, der mit Teilnehmern der Community getestet wird.<\/p>\n Wie interagiert der Benutzer mit dem virtuellen Netzwerk? Das Netzwerk schaut mit seiner API nach au\u00dfen. Der Benutzer kommt zur API und arbeitet mit dem Zielzustand. \u00dcber die API sieht der Benutzer, wie alles eingerichtet und konfiguriert sein sollte, w\u00e4hrend er den Status sieht, wie stark der aktuelle Zustand vom gew\u00fcnschten abweicht. Das ist das Bild des Benutzers. Was passiert jedoch im Inneren?<\/p>\n Wir speichern den gew\u00fcnschten Zustand in der Yandex-Datenbank und gehen hin, um verschiedene Teile unserer VPC zu konfigurieren. Das Overlay-Netzwerk in Yandex.Cloud basiert auf ausgew\u00e4hlten Komponenten von OpenContrail, das seit kurzem den Namen Tungsten Fabric tr\u00e4gt. Die Netzwerke sind auf einer einheitlichen Plattform namens CloudGate implementiert. In CloudGate haben wir ebenfalls einige Open-Source-Komponenten verwendet: GoBGP \u2013 f\u00fcr den Zugriff auf Kontrollinformationen und VPP \u2013 f\u00fcr die Umsetzung eines Software-Routers, der \u00fcber DPDK f\u00fcr den Datenpfad l\u00e4uft.<\/p>\n Tungsten Fabric kommuniziert \u00fcber GoBGP mit CloudGate. Es informiert dar\u00fcber, was im Overlay-Netzwerk passiert. CloudGate hingegen verbindet die Overlay-Netzwerke miteinander und mit dem Internet.<\/p>\n Jetzt schauen wir uns an, wie das virtuelle Netzwerk Skalierungs- und Verf\u00fcgbarkeitsanforderungen erf\u00fcllt. Betrachten wir einen einfachen Fall. Hier gibt es eine Verf\u00fcgbarkeitszone, 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\u00e4hnt, sorgt daf\u00fcr, dass sie untereinander und mit dem Internet verbunden sind.<\/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 bereitstellen. Dies wird ein separates System sein, das f\u00fcr das Overlay verantwortlich ist und wenig \u00fcber das erste System wei\u00df. Die Sichtbarkeit, dass unser virtuelles Netzwerk global ist, wird im Wesentlichen durch unsere VPC-API geschaffen. Das ist ihre Aufgabe.<\/p>\n VPC1 wird in die Verf\u00fcgbarkeitszone B projiziert, wenn es in der Verf\u00fcgbarkeitszone B Ressourcen gibt, die in VPC1 eingebunden werden. Wenn es keine Ressourcen aus VPC2 in der Verf\u00fcgbarkeitszone 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.<\/p>\n Lassen Sie uns etwas tiefer gehen und uns ansehen, wie ein bestimmter Host in Yandex.Cloud strukturiert ist. Das Wichtigste, was zu erw\u00e4hnen ist, ist, dass alle Hosts gleich aufgebaut sind. Wir stellen sicher, dass nur das notwendige Minimum an Diensten auf der 'Hardware' l\u00e4uft, alle anderen sind auf virtuellen Maschinen<\/a>. Wir bauen Dienstleistungen h\u00f6herer Ordnung auf der Grundlage grundlegender Infrastruktur\u670d\u52a1 und nutzen die Cloud zur L\u00f6sung einiger Ingenieuraufgaben, beispielsweise im Rahmen der kontinuierlichen Integration.<\/p>\n Wenn wir uns einen bestimmten Host ansehen, sehen wir, dass drei Komponenten im Betriebssystem des Hosts laufen:<\/p>\n Au\u00dferdem laufen virtuellen Maschinen<\/a> Services: Infrastrukturservices der Cloud, Plattformdienste und Kundenleistungen. Die Kundenleistungen und Plattformdienste laufen immer im Overlay \u00fcber VRouter.<\/p>\n Infrastrukturservices k\u00f6nnen in das Overlay integriert werden, aber sie m\u00f6chten haupts\u00e4chlich im Underlay arbeiten. Im Underlay werden sie durch SR-IOV integriert. Tats\u00e4chlich 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.<\/p>\n 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.<\/p>\n Wir unterscheiden in unserem System drei Schichten:<\/p>\n Wie bereits erw\u00e4hnt, beginnt alles damit, dass der Benutzer oder ein interner Plattformdienst zur API kommt und einen bestimmten Zielzustand beschreibt.<\/p>\n Dieser Zustand wird sofort in die Yandex Datenbank geschrieben, 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 usw.<\/p>\n Config Plane in Tungsten Fabric liefert den erforderlichen Zustand an Control Plane. \u00dcber diese Schnittstelle kommuniziert der Config Plane auch mit den Hosts und informiert sie dar\u00fcber, was in naher Zukunft auf ihnen laufen wird.<\/p>\n Nun schauen wir uns an, wie das System auf den Hosts aussieht. In virtuellen Maschine<\/a> Es gibt einen Netzwerkadapter, der in den VRouter eingesteckt ist. Der VRouter ist ein Kernmodul von Tungsten Fabric, das die Pakete \u00fcberwacht. Wenn f\u00fcr ein bestimmtes Paket bereits ein Flow vorhanden ist, verarbeitet das Modul es. Wenn kein Flow vorhanden ist, f\u00fchrt das Modul eine sogenannte Punting 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 sagt dem VRouter, was damit zu tun ist. Danach kann der VRouter das Paket weiterverarbeiten.<\/p>\n Der Datenverkehr zwischen virtuellen Maschinen innerhalb eines virtuellen Netzwerks l\u00e4uft transparent, er wird nicht an CloudGate geleitet. Die Hosts, auf denen die virtuellen Maschinen ausgef\u00fchrt werden, kommunizieren direkt miteinander. Sie tunneln den Datenverkehr und leiten ihn \u00fcber Underlay.<\/p>\n Die Control Plane kommuniziert \u00fcber BGP zwischen den Verf\u00fcgbarkeitszonen wie mit einem anderen Router. Sie informieren sich dar\u00fcber, welche Maschinen wo betrieben werden, damit virtuelle Maschinen in einer Zone direkt mit anderen virtuellen Maschinen interagieren k\u00f6nnen.<\/p>\n Die Control Plane kommuniziert auch mit CloudGate. Analog informiert sie dar\u00fcber, 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.<\/p>\n Der Datenverkehr, der aus der VPC kommt, gelangt zu CloudGate, in den Datenpfad, wo er schnell von VPP mit unseren Plugins verarbeitet wird. Anschlie\u00dfend wird der Datenverkehr entweder an andere VPCs oder nach au\u00dfen, zu den Grenzroutern, die \u00fcber die Control Plane von CloudGate konfiguriert werden, weitergeleitet.<\/p>\n Wenn man alles, was oben gesagt wurde, in einigen S\u00e4tzen zusammenfasst, kann man sagen, dass die VPC in Yandex.Cloud zwei wichtige Aufgaben l\u00f6st:<\/p>\n Und um diese Aufgaben gut zu bew\u00e4ltigen, muss man Skalierbarkeit und Ausfalltoleranz auf der Ebene der internen Architektur gew\u00e4hrleisten, was die VPC auch tut.<\/p>\n Allm\u00e4hlich wird die VPC um Funktionen erweitert, wir implementieren neue M\u00f6glichkeiten und bem\u00fchen uns, in Bezug auf die Benutzerfreundlichkeit Verbesserungen vorzunehmen. Einige Ideen werden ge\u00e4u\u00dfert und gelangen durch die Teilnehmer unserer Community in die Priorit\u00e4tenliste.<\/p>\n Derzeit haben wir ungef\u00e4hr diese Liste von Pl\u00e4nen f\u00fcr die n\u00e4here Zukunft:<\/p>\n Der Lastenausgleich und die M\u00f6glichkeit, die IP-Adresse f\u00fcr bereits erstellte virtuelle Maschinen zu wechseln, standen auf dieser Liste auf Wunsch der Benutzer. Ehrlich gesagt h\u00e4tten wir uns ohne klares Feedback sp\u00e4ter mit diesen Funktionen besch\u00e4ftigt. So 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 Benutzer verga\u00df, dies zu tun, musste die virtuelle Maschine neu erstellt werden. Das Gleiche galt, wenn die externe IP entfernt werden musste. Bald wird es m\u00f6glich sein, die \u00f6ffentliche IP ein- und auszuschalten, ohne die Maschine neu erstellen zu m\u00fcssen.<\/p>\n Scheuen Sie sich nicht, Ihre Ideen zu \u00e4u\u00dfern und Vorschl\u00e4ge<\/a> anderer Benutzer zu unterst\u00fctzen. Sie helfen uns, die Cloud zu verbessern und erhalten schneller wichtige und n\u00fctzliche Funktionen!<\/p>\nWas ist VPC?<\/h2>\n
Wie ein virtuelles Netzwerk von au\u00dfen aussieht<\/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 im Inneren 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\u00e4here Zukunft<\/h2>\n
\n
\n