![\"Comment](\"\/wp-content\/uploads\/2020\/02\/62b3d222c1911fb28a345defdd81135c.jpeg\")
<\/p>\nBonjour, je m'appelle Kostya Kramlih, je suis le d\u00e9veloppeur principal du d\u00e9partement Virtual Private Cloud chez Yandex.Cloud. Je m'occupe des r\u00e9seaux virtuels et, comme vous pouvez l'imaginer, dans cet article, je vais parler de l'architecture du Virtual Private Cloud (VPC) dans son ensemble et des r\u00e9seaux virtuels en particulier. Vous d\u00e9couvrirez \u00e9galement pourquoi nous, d\u00e9veloppeurs du service, appr\u00e9cions les retours de nos utilisateurs. Mais commen\u00e7ons dans l'ordre.<\/p>\n
<\/p>\n
<\/a><\/p>\n Aujourd'hui, il existe de nombreuses possibilit\u00e9s pour d\u00e9ployer des services. Je suis s\u00fbr que certaines personnes gardent encore un serveur sous le bureau de l'administrateur, m\u00eame si j'esp\u00e8re que ce genre d'histoires devient de plus en plus rare.<\/p>\n Actuellement, les services cherchent \u00e0 migrer vers des nuages publics, et c'est \u00e0 ce moment-l\u00e0 qu'ils rencontrent le VPC. Le VPC est une partie du nuage public qui relie les ressources utilisateur, infrastructure, plateforme et autres en une seule entit\u00e9, o\u00f9 qu'elles se trouvent, dans notre Cloud ou en dehors. Le VPC permet \u00e9galement de ne pas exposer ces ressources sur Internet sans n\u00e9cessit\u00e9, elles restent dans votre r\u00e9seau isol\u00e9.<\/p>\n Par VPC, nous entendons avant tout un r\u00e9seau overlay et des services r\u00e9seau tels que VPNaaS, NATaas, LBaas, etc. Et tout cela fonctionne sur une infrastructure r\u00e9seau r\u00e9siliente, dont il a d\u00e9j\u00e0 \u00e9t\u00e9 question un excellent article<\/a> ici m\u00eame, sur Habr.<\/p>\n Examinons de plus pr\u00e8s le r\u00e9seau virtuel et sa structure.<\/p>\n Consid\u00e9rons deux zones de disponibilit\u00e9. Nous fournissons un r\u00e9seau virtuel \u2013 ce que nous avons appel\u00e9 VPC. En r\u00e9alit\u00e9, il d\u00e9finit l'espace d'unicit\u00e9 de vos adresses \u00ab grises \u00bb. Dans chaque r\u00e9seau virtuel, vous g\u00e9rez compl\u00e8tement l'espace des adresses que vous pouvez attribuer aux ressources de calcul.<\/p>\n Le r\u00e9seau est global. Il est projet\u00e9 sur chacune des zones de disponibilit\u00e9 sous la forme d'une entit\u00e9 appel\u00e9e Sous-r\u00e9seau. Pour chaque Sous-r\u00e9seau, vous attribuez un certain CIDR de 16 ou moins. Dans chaque zone de disponibilit\u00e9, il peut y avoir plus d'une telle entit\u00e9, avec une routage toujours transparent entre elles. Cela signifie que toutes vos ressources au sein d'un m\u00eame VPC peuvent \u00ab communiquer \u00bb entre elles, m\u00eame si elles se trouvent dans des zones de disponibilit\u00e9 diff\u00e9rentes. \u00ab Communiquer \u00bb sans sortir sur Internet, par nos canaux internes, \u00ab pensant \u00bb qu'elles se trouvent dans un m\u00eame r\u00e9seau priv\u00e9.<\/p>\n Le sch\u00e9ma ci-dessus montre une situation typique : deux VPC qui se chevauchent par certaines adresses. Elles peuvent toutes deux vous appartenir. Par exemple, l'une pour le d\u00e9veloppement et l'autre pour les tests. Il peut \u00e9galement s'agir de diff\u00e9rents utilisateurs \u2013 dans ce cas, cela n'a pas d'importance. Et dans chaque VPC, il y a une machine virtuelle connect\u00e9e.<\/p>\n Complexifions le sch\u00e9ma. Il est possible de faire en sorte qu'une machine virtuelle soit connect\u00e9e \u00e0 plusieurs sous-r\u00e9seaux. Et pas seulement \u00e7a, mais dans diff\u00e9rentes r\u00e9seaux virtuels.<\/p>\n Cependant, si vous devez exposer des machines sur Internet, cela peut se faire via l'API ou l'UI. Pour cela, il est n\u00e9cessaire de configurer la traduction NAT de votre adresse \u00ab grise \u00bb, interne, en une adresse \u00ab blanche \u00bb \u2013 publique. Vous ne pouvez pas choisir l'adresse \u00ab blanche \u00bb, elle est assign\u00e9e de mani\u00e8re al\u00e9atoire \u00e0 partir de notre pool d'adresses. D\u00e8s que vous cessez d'utiliser l'IP externe, elle retourne dans le pool. Vous ne payez que pour le temps d'utilisation de l'adresse \u00ab blanche \u00bb.<\/p>\n Il est \u00e9galement possible de donner \u00e0 une machine l'acc\u00e8s \u00e0 Internet en utilisant une instance NAT. Le trafic peut \u00eatre rout\u00e9 vers l'instance via une table de routage statique. Nous avons pr\u00e9vu ce cas, car il peut \u00eatre n\u00e9cessaire pour certains utilisateurs, et nous en sommes conscients. Par cons\u00e9quent, dans notre catalogue d'images, il y a une image NAT sp\u00e9cialement configur\u00e9e.<\/p>\n Mais m\u00eame lorsque l'image NAT est pr\u00eate, la configuration peut \u00eatre complexe. Nous avons compris que pour certains utilisateurs, ce n'est pas la solution la plus pratique, c'est pourquoi nous avons finalement cr\u00e9\u00e9 la possibilit\u00e9 d'activer NAT pour le sous-r\u00e9seau souhait\u00e9 en un clic. Cette fonctionnalit\u00e9 est encore en preview ferm\u00e9e, test\u00e9e avec des membres de la communaut\u00e9.<\/p>\n Comment l'utilisateur interagit-il avec le r\u00e9seau virtuel ? Le r\u00e9seau se tourne vers l'ext\u00e9rieur via son API. L'utilisateur acc\u00e8de \u00e0 l'API et travaille avec l'\u00e9tat cible. Gr\u00e2ce \u00e0 l'API, l'utilisateur voit comment tout devrait \u00eatre organis\u00e9 et configur\u00e9, tout en voyant l'\u00e9tat, \u00e0 quel point l'\u00e9tat r\u00e9el diff\u00e8re du souhait\u00e9. C'est la perspective de l'utilisateur. Et que se passe-t-il \u00e0 l'int\u00e9rieur ?<\/p>\n Nous enregistrons l'\u00e9tat souhait\u00e9 dans Yandex Database et allons configurer les diff\u00e9rentes parties de notre VPC. Le r\u00e9seau superpos\u00e9 dans Yandex.Cloud est construit sur la base de composants s\u00e9lectionn\u00e9s d'OpenContrail, qui s'appelle d\u00e9sormais Tungsten Fabric. Les services r\u00e9seau sont r\u00e9alis\u00e9s sur une plateforme unique, CloudGate. Dans CloudGate, nous avons \u00e9galement utilis\u00e9 quelques composants open source : GoBGP pour interroger les informations de contr\u00f4le, ainsi que VPP pour la mise en \u0153uvre d'un routeur logiciel fonctionnant au-dessus de DPDK pour le chemin de donn\u00e9es.<\/p>\n Tungsten Fabric communique avec CloudGate via GoBGP. Il informe sur ce qui se passe dans le r\u00e9seau superpos\u00e9. CloudGate, \u00e0 son tour, relie les r\u00e9seaux superpos\u00e9s les uns aux autres et \u00e0 Internet.<\/p>\n Voyons maintenant comment le r\u00e9seau virtuel r\u00e9sout les probl\u00e8mes d'\u00e9volutivit\u00e9 et de disponibilit\u00e9. Prenons un cas simple. Il y a une zone de disponibilit\u00e9 et deux VPC sont cr\u00e9\u00e9es \u00e0 l'int\u00e9rieur. Nous avons d\u00e9ploy\u00e9 une instance de Tungsten Fabric, qui prend en charge plusieurs dizaines de milliers de r\u00e9seaux. Les r\u00e9seaux se connectent \u00e0 CloudGate. CloudGate, comme nous l'avons d\u00e9j\u00e0 mentionn\u00e9, assure leur connectivit\u00e9 entre eux et avec Internet.<\/p>\n Supposons qu'une deuxi\u00e8me zone de disponibilit\u00e9 soit ajout\u00e9e. Elle doit \u00eatre compl\u00e8tement ind\u00e9pendante de la premi\u00e8re. Par cons\u00e9quent, dans la deuxi\u00e8me zone de disponibilit\u00e9, nous devons installer une instance s\u00e9par\u00e9e de Tungsten Fabric. Ce sera un syst\u00e8me distinct qui s'occupe du superpos\u00e9 et qui sait peu de choses sur le premier syst\u00e8me. La visibilit\u00e9 que notre r\u00e9seau virtuel est global se cr\u00e9e gr\u00e2ce \u00e0 notre API VPC. C'est sa mission.<\/p>\n VPC1 se projette dans la zone de disponibilit\u00e9 B, si des ressources dans la zone de disponibilit\u00e9 B se connectent \u00e0 VPC1. Si aucune ressource de VPC2 n'est pr\u00e9sente dans la zone de disponibilit\u00e9 B, alors VPC2 ne se mat\u00e9rialise pas dans cette zone. En revanche, puisque les ressources de VPC3 existent uniquement dans la zone B, VPC3 n'existe pas dans la zone A. C'est simple et logique.<\/p>\n Allons un peu plus loin et examinons comment un h\u00f4te sp\u00e9cifique est configur\u00e9 dans Yandex.Cloud. Ce que je tiens \u00e0 souligner, c'est que tous les h\u00f4tes sont configur\u00e9s de la m\u00eame mani\u00e8re. Nous faisons en sorte que seul le minimum n\u00e9cessaire de services fonctionne sur le mat\u00e9riel, tous les autres fonctionnent sur des machines virtuelles<\/a>. Nous construisons des services de niveau sup\u00e9rieur sur la base de services d'infrastructure fondamentaux et utilisons \u00e9galement le Cloud pour r\u00e9soudre certaines t\u00e2ches d'ing\u00e9nierie, par exemple dans le cadre de l'int\u00e9gration continue.<\/p>\n Si nous regardons un h\u00f4te sp\u00e9cifique, nous verrons que trois composants fonctionnent dans le syst\u00e8me d'exploitation de l'h\u00f4te :<\/p>\n En plus de cela, des machines virtuelles<\/a> des services sont en cours d'ex\u00e9cution : des services d'infrastructure Cloud, des services de plateforme et les ressources des clients. Les ressources des clients et les services de plateforme passent toujours par l'overlay via VRouter.<\/p>\n Les services d'infrastructure peuvent se brancher sur l'overlay, mais en g\u00e9n\u00e9ral, ils pr\u00e9f\u00e8rent fonctionner dans l'underlay. Ils se connectent dans l'underlay gr\u00e2ce \u00e0 SR-IOV. En fait, nous d\u00e9coupons la carte en cartes r\u00e9seau virtuelles (fonctionnalit\u00e9s virtuelles) et les ins\u00e9rons dans des machines virtuelles d'infrastructure pour ne pas perdre en performance. Par exemple, ce fameux CloudGate est ex\u00e9cut\u00e9 sous la forme d'une de ces machines virtuelles d'infrastructure.<\/p>\n Maintenant que nous avons d\u00e9crit les t\u00e2ches globales du r\u00e9seau virtuel et les composants de base du cloud, examinons comment diff\u00e9rentes parties du r\u00e9seau virtuel interagissent entre elles.<\/p>\n Nous identifions dans notre syst\u00e8me trois couches :<\/p>\n Comme je l'ai mentionn\u00e9 pr\u00e9c\u00e9demment, tout commence quand l'utilisateur ou un service de plateforme interne acc\u00e8de \u00e0 l'API et d\u00e9crit un certain \u00e9tat cible.<\/p>\n Cet \u00e9tat est imm\u00e9diatement enregistr\u00e9 dans Yandex Database, renvoyant via l'API l'ID de l'op\u00e9ration asynchrone et lan\u00e7ant notre machinerie interne pour fournir l'\u00e9tat souhait\u00e9 par l'utilisateur. Les t\u00e2ches de configuration vont au contr\u00f4leur SDN et informent Tungsten Fabric de ce qu'il faut faire dans l'overlay. Par exemple, elles r\u00e9servent des ports, des r\u00e9seaux virtuels, etc.<\/p>\n Le Config Plane de Tungsten Fabric envoie \u00e0 Control Plane l'\u00e9tat requis. C'est aussi par lui que Config Plane communique avec les h\u00f4tes, leur indiquant ce qui va bient\u00f4t y fonctionner.<\/p>\n Voyons maintenant \u00e0 quoi ressemble le syst\u00e8me sur les h\u00f4tes. Dans une machine virtuelle<\/a> Il existe un certain adaptateur r\u00e9seau, ins\u00e9r\u00e9 dans le VRouter. Le VRouter est un module central de Tungsten Fabric qui examine les paquets. Si un flux existe d\u00e9j\u00e0 pour un certain paquet, le module le traite. S'il n'y a pas de flux, le module effectue ce qu'on appelle un punting, c'est-\u00e0-dire qu'il envoie le paquet au processus en mode utilisateur. Le processus analyse le paquet et r\u00e9pond soit lui-m\u00eame, comme dans le cas de DHCP et DNS, soit dit au VRouter quoi en faire. Apr\u00e8s cela, le VRouter peut traiter le paquet.<\/p>\n Ensuite, le trafic entre les machines virtuelles au sein d'un m\u00eame r\u00e9seau virtuel circule de mani\u00e8re transparente, il n'est pas dirig\u00e9 vers CloudGate. Les h\u00f4tes sur lesquels les machines virtuelles sont d\u00e9ploy\u00e9es communiquent directement entre eux. Ils encapsulent le trafic et le transf\u00e8rent les uns aux autres via l'underlay.<\/p>\n Le Control Plane communique entre les zones de disponibilit\u00e9 via BGP, comme avec un autre routeur. Ils informent sur les machines qui sont d\u00e9ploy\u00e9es, afin que les machines virtuelles d'une zone puissent interagir directement avec les autres machines virtuelles.<\/p>\n De plus, le Control Plane communique avec CloudGate. Il informe \u00e9galement de l'emplacement et des adresses des machines virtuelles. Cela permet de diriger le trafic externe et le trafic provenant des \u00e9quilibreurs de charge vers ces machines.<\/p>\n Le trafic qui sort du VPC arrive sur CloudGate, dans le chemin de donn\u00e9es, o\u00f9 il est rapidement trait\u00e9 par le VPP avec nos plugins. Ensuite, le trafic est orient\u00e9 soit vers d'autres VPC, soit vers l'ext\u00e9rieur, dans des routeurs de bordure, qui sont configur\u00e9s via le Control Plane de CloudGate lui-m\u00eame.<\/p>\n Pour r\u00e9sumer tout ce qui a \u00e9t\u00e9 dit ci-dessus en quelques phrases, on peut dire que le VPC dans Yandex.Cloud r\u00e9sout deux probl\u00e8mes importants :<\/p>\n Et pour bien r\u00e9soudre ces t\u00e2ches, il est n\u00e9cessaire d'assurer la scalabilit\u00e9 et la r\u00e9silience au niveau de l'architecture interne, ce que le VPC fait.<\/p>\n Progressivement, le VPC enrichit ses fonctionnalit\u00e9s, nous mettons en \u0153uvre de nouvelles possibilit\u00e9s, nous essayons d'am\u00e9liorer certains aspects en termes de confort pour les utilisateurs. Certaines id\u00e9es sont exprim\u00e9es et passent dans la liste des priorit\u00e9s gr\u00e2ce aux participants de notre communaut\u00e9.<\/p>\n Nous avons actuellement une liste de projets futurs qui ressemble \u00e0 ceci :<\/p>\n L\u2019\u00e9quilibreur de charge et la possibilit\u00e9 de changer l'adresse IP pour une machine virtuelle d\u00e9j\u00e0 cr\u00e9\u00e9e ont \u00e9t\u00e9 ajout\u00e9s \u00e0 cette liste sur demande des utilisateurs. Honn\u00eatement, sans feedback explicite, nous aborderions ces fonctionnalit\u00e9s plus tard. Cependant, nous travaillons d\u00e9j\u00e0 sur la question des adresses.<\/p>\n Initialement, une adresse IP \u00ab blanche \u00bb ne pouvait \u00eatre ajout\u00e9e que lors de la cr\u00e9ation de la machine. Si l'utilisateur oubliait de le faire, il fallait recr\u00e9er la machine virtuelle. Il en \u00e9tait de m\u00eame pour le retrait d'une IP externe. Bient\u00f4t, il sera possible d'activer ou de d\u00e9sactiver une IP publique sans recr\u00e9er la machine.<\/p>\n N'h\u00e9sitez pas \u00e0 partager vos id\u00e9es et \u00e0 soutenir les suggestions<\/a> d'autres utilisateurs. Vous nous aidez \u00e0 am\u00e9liorer le Cloud et \u00e0 obtenir plus rapidement des fonctionnalit\u00e9s importantes et utiles !<\/p>\nQu'est-ce que le VPC ?<\/h2>\n
Comment le r\u00e9seau virtuel appara\u00eet de l'ext\u00e9rieur<\/h2>\n
![\"Comment](\"\/wp-content\/uploads\/2020\/02\/073a0cbac0e733decd8a4e6ffd9570ff.jpeg\")
<\/p>\n![\"Comment](\"\/wp-content\/uploads\/2020\/02\/b1b7a15912f9c7995663ab9943d473f1.jpeg\")
<\/p>\n![\"Comment](\"\/wp-content\/uploads\/2020\/02\/73e872a4f6c3e19576db4e4980d62a45.jpeg\")
<\/p>\n![\"Comment](\"\/wp-content\/uploads\/2020\/02\/cc4ab2c7553d63ef2636924df1575479.jpeg\")
<\/p>\n![\"Comment](\"\/wp-content\/uploads\/2020\/02\/c2375fd6d0fb7b55ca55787adf505229.jpeg\")
<\/p>\n![\"Comment](\"\/wp-content\/uploads\/2020\/02\/744ac3bdd2f388bab2597d6fe1519d76.jpeg\")
<\/p>\nComment est structur\u00e9e une r\u00e9seau virtuelle de l'int\u00e9rieur<\/h2>\n
![\"Comment](\"\/wp-content\/uploads\/2020\/02\/71cab3ae7f067f165a87e30c60559794.jpeg\")
<\/p>\n![\"Comment](\"\/wp-content\/uploads\/2020\/02\/222d68fff4b9577f316c8642e846172e.jpeg\")
<\/p>\n![\"Comment](\"\/wp-content\/uploads\/2020\/02\/4da02ba041dcd886eee212dd8998718c.jpeg\")
<\/p>\n![\"Comment](\"\/wp-content\/uploads\/2020\/02\/4664bd03793ba394ceda1f8214fa2c16.jpeg\")
<\/p>\n\n
\n
![\"Comment](\"\/wp-content\/uploads\/2020\/02\/644cddfa8bce83a501bf4788a21f9588.jpeg\")
<\/p>\n![\"Comment](\"\/wp-content\/uploads\/2020\/02\/c2c6e443c93f8dedc6a63e4bd3fd7042.jpeg\")
<\/p>\n![\"Comment](\"\/wp-content\/uploads\/2020\/02\/2139361a9e1837c7bc7f156e8bc36d38.jpeg\")
<\/p>\n![\"Comment](\"\/wp-content\/uploads\/2020\/02\/1247f20fa2a12f093d7f1d2361d48a02.jpeg\")
<\/p>\n![\"Comment](\"\/wp-content\/uploads\/2020\/02\/f70cd562220c7367e29597d8e8b62f81.jpeg\")
<\/p>\nPlans pour un avenir proche<\/h2>\n
\n
\n