Bonjour, je m'appelle Kostya Kramlikh, je suis le développeur principal de la division Virtual Private Cloud de Yandex.Cloud. Je suis un réseauteur virtuel, et comme vous pouvez le deviner, dans cet article, je parlerai du périphérique Virtual Private Cloud (VPC) en général et du réseau virtuel en particulier. Et vous découvrirez également pourquoi nous, les développeurs du service, apprécions les commentaires de nos utilisateurs. Mais avant tout.
Qu'est-ce qu'un VPC ?
De nos jours, il existe une variété d'options pour déployer des services. Je suis sûr que quelqu'un garde toujours le serveur sous le bureau de l'administrateur, même si j'espère qu'il y a moins d'histoires de ce genre.
Maintenant, les services essaient d'accéder aux clouds publics, et c'est là qu'ils entrent en collision avec les VPC. Le VPC fait partie d'un cloud public qui relie l'utilisateur, l'infrastructure, la plate-forme et d'autres capacités, où qu'ils se trouvent, dans notre cloud ou en dehors de celui-ci. En même temps, VPC vous permet de ne pas exposer inutilement ces capacités à Internet, elles restent au sein de votre réseau isolé.
À quoi ressemble un réseau virtuel vu de l'extérieur ?
Par VPC, nous entendons principalement un réseau superposé et des services réseau, tels que VPNaaS, NATaas, LBaas, etc. Et tout cela fonctionne au-dessus d'une infrastructure réseau tolérante aux pannes, qui a déjà été ici, sur Habré.
Examinons de plus près le réseau virtuel et son périphérique.
Considérez deux zones de disponibilité. Nous fournissons un réseau virtuel - ce que nous appelons VPC. En fait, il définit l'espace d'unicité de vos adresses « grises ». Au sein de chaque réseau virtuel, vous avez un contrôle total sur l'espace d'adresses que vous pouvez attribuer aux ressources de calcul.
Le réseau est mondial. En même temps, il est projeté sur chacune des zones de disponibilité sous la forme d'une entité appelée Subnet. Pour chaque sous-réseau, vous affectez un CIDR de taille 16 ou moins. Il peut y avoir plusieurs entités de ce type dans chaque zone de disponibilité, et il existe toujours un routage transparent entre elles. Cela signifie que toutes vos ressources au sein du même VPC peuvent « parler » entre elles, même si elles se trouvent dans des zones de disponibilité différentes. "Communiquez" sans accès à Internet, via nos canaux internes, "en pensant" qu'ils sont au sein du même réseau privé.
Le diagramme ci-dessus montre une situation typique : deux VPC qui se croisent quelque part dans les adresses. Les deux peuvent être vôtres. Par exemple, l'un pour le développement, l'autre pour les tests. Il peut simplement y avoir différents utilisateurs - dans ce cas, cela n'a pas d'importance. Et une machine virtuelle est connectée à chaque VPC.
Faisons empirer le schéma. Vous pouvez faire en sorte qu'une machine virtuelle soit bloquée dans plusieurs sous-réseaux à la fois. Et pas seulement comme ça, mais dans différents réseaux virtuels.
Dans le même temps, si vous devez exposer des machines à Internet, cela peut être fait via l'API ou l'interface utilisateur. Pour ce faire, vous devez configurer la traduction NAT de votre adresse « grise », interne, en « blanche » - publique. Vous ne pouvez pas choisir une adresse "blanche", elle est attribuée aléatoirement à partir de notre pool d'adresses. Dès que vous arrêtez d'utiliser l'adresse IP externe, elle est renvoyée au pool. Vous ne payez que le temps d'utilisation de l'adresse "blanche".
Il est également possible de donner à la machine un accès à Internet à l'aide d'une instance NAT. Vous pouvez acheminer le trafic vers une instance via une table de routage statique. Nous avons fourni un tel cas, car les utilisateurs en ont parfois besoin, et nous le savons. Par conséquent, notre catalogue d'images contient une image NAT spécialement configurée.
Mais même lorsqu'il existe une image NAT prête, la configuration peut être délicate. Nous avons compris que pour certains utilisateurs, ce n'est pas l'option la plus pratique, nous avons donc finalement rendu possible l'activation de NAT pour le sous-réseau souhaité en un clic. Cette fonctionnalité est toujours en accès préliminaire fermé, où elle est testée avec l'aide des membres de la communauté.
Comment le réseau virtuel est organisé de l'intérieur
Comment l'utilisateur interagit-il avec le réseau virtuel ? Le web regarde vers l'extérieur avec son API. L'utilisateur accède à l'API et travaille avec l'état cible. Grâce à l'API, l'utilisateur voit comment tout doit être organisé et configuré, tandis qu'il voit l'état, à quel point l'état réel diffère de celui souhaité. Ceci est une photo de l'utilisateur. Que se passe-t-il à l'intérieur ?
Nous écrivons l'état souhaité dans la base de données Yandex et allons configurer différentes parties de notre VPC. Le réseau de superposition dans Yandex.Cloud est basé sur des composants sélectionnés d'OpenContrail, qui a récemment été appelé Tungsten Fabric. Les services réseau sont mis en œuvre sur une seule plate-forme CloudGate. Dans CloudGate, nous avons également utilisé un certain nombre de composants open source : GoBGP - pour accéder aux informations de contrôle, ainsi que VPP - pour implémenter un routeur logiciel qui s'exécute au-dessus de DPDK pour le chemin des données.
Tungsten Fabric communique avec CloudGate via GoBGP. Indique ce qui se passe dans le réseau superposé. CloudGate, à son tour, connecte les réseaux superposés entre eux et avec Internet.
Voyons maintenant comment un réseau virtuel résout les problèmes d'évolutivité et de disponibilité. Considérons un cas simple. Il existe une zone de disponibilité et deux VPC y sont créés. Nous avons déployé une instance Tungsten Fabric, et elle tire plusieurs dizaines de milliers de réseaux. Les réseaux communiquent avec CloudGate. CloudGate, comme nous l'avons déjà dit, assure leur connectivité entre eux et avec Internet.
Supposons qu'une deuxième zone de disponibilité soit ajoutée. Il devrait échouer complètement indépendamment du premier. Par conséquent, dans la deuxième zone de disponibilité, nous devons installer une instance Tungsten Fabric distincte. Il s'agira d'un système distinct qui s'occupe de la superposition et connaît peu le premier système. Et la visibilité que notre réseau virtuel est mondial, en fait, crée notre API VPC. C'est sa tâche.
VPC1 est mappé à la zone de disponibilité B s'il y a des ressources dans la zone de disponibilité B qui sont poussées vers VPC1. S'il n'y a pas de ressources de VPC2 dans la zone de disponibilité B, nous ne matérialiserons pas VPC2 dans cette zone. À son tour, puisque les ressources de VPC3 n'existent que dans la zone B, VPC3 n'existe pas dans la zone A. Tout est simple et logique.
Allons un peu plus loin et voyons comment fonctionne un hôte particulier dans Y.Cloud. La principale chose que je tiens à noter est que tous les hôtes sont organisés de la même manière. Nous faisons en sorte que seul le minimum nécessaire de services s'exécute sur du matériel, tout le reste s'exécutant sur des machines virtuelles. Nous construisons des services d'ordre supérieur basés sur des services d'infrastructure de base, et utilisons également le Cloud pour résoudre certains problèmes d'ingénierie, par exemple dans le cadre de l'intégration continue.
Si nous regardons un hôte spécifique, nous pouvons voir qu'il y a trois composants en cours d'exécution sur le système d'exploitation hôte :
- Compute - la partie responsable de la distribution des ressources informatiques sur l'hôte.
- VRouter fait partie de Tungsten Fabric qui organise une superposition, c'est-à-dire qu'il tunnelise les paquets à travers une sous-couche.
- Les disques virtuels sont des morceaux de virtualisation du stockage.
De plus, des services sont lancés dans des machines virtuelles : services d'infrastructure cloud, services de plate-forme et capacités client. Les capacités des clients et les services de plate-forme vont toujours à la superposition via VRouter.
Les services d'infrastructure peuvent s'en tenir à la superposition, mais fondamentalement, ils veulent travailler dans la sous-couche. Ils sont collés dans la sous-couche à l'aide de SR-IOV. En fait, on découpe la carte en cartes réseau virtuelles (fonctions virtuelles) et on les pousse dans des machines virtuelles d'infrastructure pour ne pas perdre en performances. Par exemple, le même CloudGate est lancé comme l'une de ces machines virtuelles d'infrastructure.
Maintenant que nous avons décrit les tâches globales du réseau virtuel et la structure des composants de base du cloud, voyons comment exactement les différentes parties du réseau virtuel interagissent les unes avec les autres.
Nous distinguons trois couches dans notre système :
- Plan de configuration - définit l'état cible du système. C'est ce que l'utilisateur configure via l'API.
- Plan de contrôle - fournit une sémantique définie par l'utilisateur, c'est-à-dire qu'il ramène l'état du plan de données à ce qui a été décrit par l'utilisateur dans le plan de configuration.
- Plan de données - traite directement les paquets de l'utilisateur.
Comme je l'ai dit plus haut, tout commence par le fait que l'utilisateur ou le service de plateforme interne vient à l'API et décrit un certain état cible.
Cet état est immédiatement écrit dans la base de données Yandex, renvoie l'ID d'opération asynchrone via l'API et démarre notre machinerie interne pour renvoyer l'état souhaité par l'utilisateur. Les tâches de configuration vont au contrôleur SDN et indiquent à Tungsten Fabric ce qu'il faut faire dans la superposition. Par exemple, ils réservent des ports, des réseaux virtuels, etc.
Le plan de configuration dans Tungsten Fabric envoie l'état requis au plan de contrôle. Grâce à lui, Config Plane communique avec les hôtes, indiquant exactement ce qui leur arrivera bientôt.
Voyons maintenant à quoi ressemble le système sur les hôtes. La machine virtuelle a un adaptateur réseau branché sur VRouter. VRouter est un module central de Tungsten Fabric qui examine les paquets. S'il existe déjà un flux pour un package, le module le traite. S'il n'y a pas de flux, le module effectue ce qu'on appelle le punting, c'est-à-dire qu'il envoie un paquet au processus usermod. Le processus analyse le paquet et y répond lui-même, comme DHCP et DNS, ou indique à VRouter quoi en faire. Après cela, VRouter peut traiter le paquet.
De plus, le trafic entre les machines virtuelles au sein du même réseau virtuel passe de manière transparente, il n'est pas dirigé vers CloudGate. Les hôtes sur lesquels les machines virtuelles sont déployées communiquent directement entre eux. Ils tunnelisent le trafic et le transmettent l'un à l'autre à travers la sous-couche.
Les plans de contrôle communiquent entre eux entre les zones de disponibilité via BGP, comme avec un autre routeur. Ils indiquent quelles machines sont actives et où afin que les machines virtuelles d'une zone puissent communiquer directement avec d'autres machines virtuelles.
Et Control Plane communique avec CloudGate. De même, il indique où et quelles machines virtuelles sont déclenchées, quelles adresses elles ont. Cela vous permet de diriger le trafic externe et le trafic des équilibreurs vers eux.
Le trafic qui quitte le VPC arrive à CloudGate, au chemin des données, où le VPP avec nos plugins est rapidement mâché. Ensuite, le trafic est dirigé soit vers d'autres VPC, soit vers l'extérieur, vers des routeurs de bordure configurés via le plan de contrôle de CloudGate lui-même.
Plans pour un avenir proche
Si nous résumons tout ce qui a été dit ci-dessus en quelques phrases, nous pouvons dire que VPC dans Yandex.Cloud résout deux tâches importantes :
- Fournit une isolation entre différents clients.
- Combine les ressources, l'infrastructure, les services de plate-forme, d'autres clouds et sur site dans un seul réseau.
Et pour bien résoudre ces problèmes, vous devez fournir une évolutivité et une tolérance aux pannes au niveau de l'architecture interne, ce que fait VPC.
Petit à petit VPC acquiert des fonctions, nous implémentons de nouvelles fonctionnalités, nous essayons d'améliorer quelque chose en termes de confort d'utilisation. Certaines idées sont émises et mises sur la liste des priorités grâce aux membres de notre communauté.
Nous avons actuellement la liste suivante de plans pour le futur proche :
- VPN en tant que service.
- Les instances DNS privées sont des images permettant de configurer rapidement des machines virtuelles avec un serveur DNS préconfiguré.
- DNS en tant que service.
- Équilibreur de charge interne.
- Ajouter une adresse IP "blanche" sans recréer la machine virtuelle.
L'équilibreur et la possibilité de changer d'adresse IP pour une machine virtuelle déjà créée figuraient sur cette liste à la demande des utilisateurs. Pour être honnête, sans retour explicite, nous aurions pris ces fonctions un peu plus tard. Et donc nous travaillons déjà sur le problème des adresses.
Initialement, une adresse IP "blanche" ne pouvait être ajoutée qu'à la création d'une machine. Si l'utilisateur oubliait de le faire, la machine virtuelle devait être recréée. La même chose et, si nécessaire, supprimez l'adresse IP externe. Il sera bientôt possible d'activer et de désactiver l'IP publique sans avoir à recréer la machine.
N'hésitez pas à exprimer votre autres utilisateurs. Vous nous aidez à améliorer le Cloud et à obtenir plus rapidement des fonctionnalités importantes et utiles !
Source: habr.com