Bonjour, je m'appelle Kostya Kramlih, je suis le développeur principal du département Virtual Private Cloud chez Yandex.Cloud. Je m'occupe des réseaux 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éseaux virtuels en particulier. Vous découvrirez également pourquoi nous, développeurs du service, apprécions les retours de nos utilisateurs. Mais commençons dans l'ordre.
Qu'est-ce que le VPC ?
Aujourd'hui, il existe de nombreuses possibilités pour déployer des services. Je suis sûr que certaines personnes gardent encore un serveur sous le bureau de l'administrateur, même si j'espère que ce genre d'histoires devient de plus en plus rare.
Actuellement, les services cherchent à migrer vers des nuages publics, et c'est à ce moment-là 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é, où qu'elles se trouvent, dans notre Cloud ou en dehors. Le VPC permet également de ne pas exposer ces ressources sur Internet sans nécessité, elles restent dans votre réseau isolé.
Comment le réseau virtuel apparaît de l'extérieur
Par VPC, nous entendons avant tout un réseau overlay et des services réseau tels que VPNaaS, NATaas, LBaas, etc. Et tout cela fonctionne sur une infrastructure réseau résiliente, dont il a déjà été question un excellent article ici même, sur Habr.
Examinons de plus près le réseau virtuel et sa structure.
Considérons deux zones de disponibilité. Nous fournissons un réseau virtuel – ce que nous avons appelé VPC. En réalité, il définit l'espace d'unicité de vos adresses « grises ». Dans chaque réseau virtuel, vous gérez complètement l'espace des adresses que vous pouvez attribuer aux ressources de calcul.
Le réseau est global. Il est projeté sur chacune des zones de disponibilité sous la forme d'une entité appelée Sous-réseau. Pour chaque Sous-réseau, vous attribuez un certain CIDR de 16 ou moins. Dans chaque zone de disponibilité, il peut y avoir plus d'une telle entité, avec une routage toujours transparent entre elles. Cela signifie que toutes vos ressources au sein d'un même VPC peuvent « communiquer » entre elles, même si elles se trouvent dans des zones de disponibilité différentes. « Communiquer » sans sortir sur Internet, par nos canaux internes, « pensant » qu'elles se trouvent dans un même réseau privé.
Le schéma 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éveloppement et l'autre pour les tests. Il peut également s'agir de différents utilisateurs – dans ce cas, cela n'a pas d'importance. Et dans chaque VPC, il y a une machine virtuelle connectée.
Complexifions le schéma. Il est possible de faire en sorte qu'une machine virtuelle soit connectée à plusieurs sous-réseaux. Et pas seulement ça, mais dans différentes réseaux virtuels.
Cependant, si vous devez exposer des machines sur Internet, cela peut se faire via l'API ou l'UI. Pour cela, il est nécessaire de configurer la traduction NAT de votre adresse « grise », interne, en une adresse « blanche » – publique. Vous ne pouvez pas choisir l'adresse « blanche », elle est assignée de manière aléatoire à partir de notre pool d'adresses. Dès 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 « blanche ».
Il est également possible de donner à une machine l'accès à Internet en utilisant une instance NAT. Le trafic peut être routé vers l'instance via une table de routage statique. Nous avons prévu ce cas, car il peut être nécessaire pour certains utilisateurs, et nous en sommes conscients. Par conséquent, dans notre catalogue d'images, il y a une image NAT spécialement configurée.
Mais même lorsque l'image NAT est prête, la configuration peut être complexe. Nous avons compris que pour certains utilisateurs, ce n'est pas la solution la plus pratique, c'est pourquoi nous avons finalement créé la possibilité d'activer NAT pour le sous-réseau souhaité en un clic. Cette fonctionnalité est encore en preview fermée, testée avec des membres de la communauté.
Comment est structurée une réseau virtuelle de l'intérieur
Comment l'utilisateur interagit-il avec le réseau virtuel ? Le réseau se tourne vers l'extérieur via son API. L'utilisateur accède à l'API et travaille avec l'état cible. Grâce à l'API, l'utilisateur voit comment tout devrait être organisé et configuré, tout en voyant l'état, à quel point l'état réel diffère du souhaité. C'est la perspective de l'utilisateur. Et que se passe-t-il à l'intérieur ?
Nous enregistrons l'état souhaité dans Yandex Database et allons configurer les différentes parties de notre VPC. Le réseau superposé dans Yandex.Cloud est construit sur la base de composants sélectionnés d'OpenContrail, qui s'appelle désormais Tungsten Fabric. Les services réseau sont réalisés sur une plateforme unique, CloudGate. Dans CloudGate, nous avons également utilisé quelques composants open source : GoBGP pour interroger les informations de contrôle, ainsi que VPP pour la mise en œuvre d'un routeur logiciel fonctionnant au-dessus de DPDK pour le chemin de données.
Tungsten Fabric communique avec CloudGate via GoBGP. Il informe sur ce qui se passe dans le réseau superposé. CloudGate, à son tour, relie les réseaux superposés les uns aux autres et à Internet.
Voyons maintenant comment le réseau virtuel résout les problèmes d'évolutivité et de disponibilité. Prenons un cas simple. Il y a une zone de disponibilité et deux VPC sont créées à l'intérieur. Nous avons déployé une instance de Tungsten Fabric, qui prend en charge plusieurs dizaines de milliers de réseaux. Les réseaux se connectent à CloudGate. CloudGate, comme nous l'avons déjà mentionné, assure leur connectivité entre eux et avec Internet.
Supposons qu'une deuxième zone de disponibilité soit ajoutée. Elle doit être complètement indépendante de la première. Par conséquent, dans la deuxième zone de disponibilité, nous devons installer une instance séparée de Tungsten Fabric. Ce sera un système distinct qui s'occupe du superposé et qui sait peu de choses sur le premier système. La visibilité que notre réseau virtuel est global se crée grâce à notre API VPC. C'est sa mission.
VPC1 se projette dans la zone de disponibilité B, si des ressources dans la zone de disponibilité B se connectent à VPC1. Si aucune ressource de VPC2 n'est présente dans la zone de disponibilité B, alors VPC2 ne se matérialise 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.
Allons un peu plus loin et examinons comment un hôte spécifique est configuré dans Yandex.Cloud. Ce que je tiens à souligner, c'est que tous les hôtes sont configurés de la même manière. Nous faisons en sorte que seul le minimum nécessaire de services fonctionne sur le matériel, tous les autres fonctionnent sur des machines virtuelles. Nous construisons des services de niveau supérieur sur la base de services d'infrastructure fondamentaux et utilisons également le Cloud pour résoudre certaines tâches d'ingénierie, par exemple dans le cadre de l'intégration continue.
Si nous regardons un hôte spécifique, nous verrons que trois composants fonctionnent dans le système d'exploitation de l'hôte :
- Compute – la partie responsable de la distribution des ressources de calcul sur l'hôte.
- VRouter – la partie de Tungsten Fabric qui organise l'overlay, c'est-à-dire qui tunnelise les paquets à travers l'underlay.
- VDisk – ce sont des morceaux de virtualisation de stockage.
En plus de cela, des machines virtuelles des services sont en cours d'exécution : 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.
Les services d'infrastructure peuvent se brancher sur l'overlay, mais en général, ils préfèrent fonctionner dans l'underlay. Ils se connectent dans l'underlay grâce à SR-IOV. En fait, nous découpons la carte en cartes réseau virtuelles (fonctionnalités virtuelles) et les insérons dans des machines virtuelles d'infrastructure pour ne pas perdre en performance. Par exemple, ce fameux CloudGate est exécuté sous la forme d'une de ces machines virtuelles d'infrastructure.
Maintenant que nous avons décrit les tâches globales du réseau virtuel et les composants de base du cloud, examinons comment différentes parties du réseau virtuel interagissent entre elles.
Nous identifions dans notre système trois couches :
- Config Plane – définit l'état cible du système. C'est ce que configure l'utilisateur via l'API.
- Control Plane – assure la sémantique définie par l'utilisateur, c'est-à-dire qu'elle fait correspondre l'état du Data Plane à ce qui a été décrit par l'utilisateur dans le Config Plane.
- Data Plane – traite directement les paquets de l'utilisateur.
Comme je l'ai mentionné précédemment, tout commence quand l'utilisateur ou un service de plateforme interne accède à l'API et décrit un certain état cible.
Cet état est immédiatement enregistré dans Yandex Database, renvoyant via l'API l'ID de l'opération asynchrone et lançant notre machinerie interne pour fournir l'état souhaité par l'utilisateur. Les tâches de configuration vont au contrôleur SDN et informent Tungsten Fabric de ce qu'il faut faire dans l'overlay. Par exemple, elles réservent des ports, des réseaux virtuels, etc.
Le Config Plane de Tungsten Fabric envoie à Control Plane l'état requis. C'est aussi par lui que Config Plane communique avec les hôtes, leur indiquant ce qui va bientôt y fonctionner.
Voyons maintenant à quoi ressemble le système sur les hôtes. Dans une machine virtuelle Il existe un certain adaptateur réseau, inséré dans le VRouter. Le VRouter est un module central de Tungsten Fabric qui examine les paquets. Si un flux existe déjà 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-à-dire qu'il envoie le paquet au processus en mode utilisateur. Le processus analyse le paquet et répond soit lui-même, comme dans le cas de DHCP et DNS, soit dit au VRouter quoi en faire. Après cela, le VRouter peut traiter le paquet.
Ensuite, le trafic entre les machines virtuelles au sein d'un même réseau virtuel circule 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 encapsulent le trafic et le transfèrent les uns aux autres via l'underlay.
Le Control Plane communique entre les zones de disponibilité via BGP, comme avec un autre routeur. Ils informent sur les machines qui sont déployées, afin que les machines virtuelles d'une zone puissent interagir directement avec les autres machines virtuelles.
De plus, le Control Plane communique avec CloudGate. Il informe également de l'emplacement et des adresses des machines virtuelles. Cela permet de diriger le trafic externe et le trafic provenant des équilibreurs de charge vers ces machines.
Le trafic qui sort du VPC arrive sur CloudGate, dans le chemin de données, où il est rapidement traité par le VPP avec nos plugins. Ensuite, le trafic est orienté soit vers d'autres VPC, soit vers l'extérieur, dans des routeurs de bordure, qui sont configurés via le Control Plane de CloudGate lui-même.
Plans pour un avenir proche
Pour résumer tout ce qui a été dit ci-dessus en quelques phrases, on peut dire que le VPC dans Yandex.Cloud résout deux problèmes importants :
- Il assure l'isolation entre différents clients.
- Il regroupe les ressources, l'infrastructure, les services de plateforme, d'autres clouds et on-premise dans un réseau unique.
Et pour bien résoudre ces tâches, il est nécessaire d'assurer la scalabilité et la résilience au niveau de l'architecture interne, ce que le VPC fait.
Progressivement, le VPC enrichit ses fonctionnalités, nous mettons en œuvre de nouvelles possibilités, nous essayons d'améliorer certains aspects en termes de confort pour les utilisateurs. Certaines idées sont exprimées et passent dans la liste des priorités grâce aux participants de notre communauté.
Nous avons actuellement une liste de projets futurs qui ressemble à ceci :
- VPN comme service.
- Instances DNS privé – images pour la configuration rapide de machines virtuelles avec un serveur DNS préconfiguré.
- DNS en tant que service.
- Équilibreur de charge interne.
- Ajout d'une adresse IP « blanche » sans recréer la machine virtuelle.
L’équilibreur de charge et la possibilité de changer l'adresse IP pour une machine virtuelle déjà créée ont été ajoutés à cette liste sur demande des utilisateurs. Honnêtement, sans feedback explicite, nous aborderions ces fonctionnalités plus tard. Cependant, nous travaillons déjà sur la question des adresses.
Initialement, une adresse IP « blanche » ne pouvait être ajoutée que lors de la création de la machine. Si l'utilisateur oubliait de le faire, il fallait recréer la machine virtuelle. Il en était de même pour le retrait d'une IP externe. Bientôt, il sera possible d'activer ou de désactiver une IP publique sans recréer la machine.
N'hésitez pas à partager vos idées et à soutenir les suggestions d'autres utilisateurs. Vous nous aidez à améliorer le Cloud et à obtenir plus rapidement des fonctionnalités importantes et utiles !
Source : habr.com
