Get best of the week

Comment Yandex.Cloud est hébergé par Virtual Private Cloud et comment nos utilisateurs nous aident à mettre en œuvre des fonctionnalités utiles

Bonjour, je m'appelle Kostya Kramlikh, je suis l'un des principaux développeurs de la division Virtual Private Cloud de Yandex.Cloud. Je suis engagé dans un réseau 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. Vous apprendrez également pourquoi nous, les développeurs du service, apprécions les commentaires de nos utilisateurs. Mais tout d'abord.



Qu'est-ce qu'un VPC?


De nos jours, pour le déploiement de services, il existe une variété d'opportunités. Je suis sûr que quelqu'un garde toujours le serveur sous la table de l'administrateur, même si, j'espère, il y a de moins en moins de telles histoires.

Désormais, les services tentent de pénétrer dans les clouds publics, et ici, ils sont confrontés au VPC. Le VPC fait partie du cloud public qui connecte les utilisateurs, l'infrastructure, la plate-forme et d'autres capacités ensemble, où qu'ils se trouvent, dans notre cloud ou au-delà. Dans le même temps, VPC permet de ne pas mettre inutilement ces capacités sur Internet, elles restent au sein de votre réseau isolé.

À quoi ressemble un réseau virtuel de l'extérieur




Par VPC, nous comprenons principalement le réseau de superposition et les services réseau, tels que VPNaaS, NATaas, LBaas, etc. Et tout cela fonctionne en plus de l'infrastructure réseau à sécurité intégrée, sur laquelle il y avait déjà un excellent article ici sur Habré.

Examinons de plus près le réseau virtuel et son appareil.



Considérez deux zones d'accessibilité. Nous fournissons un réseau virtuel - ce que nous avons appelé VPC. En fait, il définit l'espace d'unicité de vos adresses «grises». Au sein de chaque réseau virtuel, vous contrôlez complètement l'espace d'adressage que vous pouvez affecter aux ressources informatiques.

Le réseau est mondial. En même temps, il est projeté sur chacune des zones d'accès sous la forme d'une entité appelée Subnet. Pour chaque sous-réseau, vous affectez un certain CIDR de taille 16 ou moins. Il peut y avoir plusieurs entités de ce type dans chaque zone de disponibilité, tandis qu'il existe toujours un routage 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 d'accès différentes. "Communiquer" sans accès à Internet, via nos canaux internes, "penser" qu'ils se trouvent au sein d'un même réseau privé.

Le diagramme ci-dessus montre une situation typique: deux VPC qui se croisent quelque part aux adresses. Les deux peuvent vous appartenir. Par exemple, un pour le développement, un 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 bloquée dans chaque VPC.



Composez le schéma. Vous pouvez faire en sorte qu'une seule machine virtuelle reste 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 mettre des voitures sur 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 "blanc" - public. Vous ne pouvez pas sélectionner une adresse «blanche», elle est attribuée au hasard dans notre pool d'adresses. Dès que vous arrêtez d'utiliser l'IP externe, elle retourne dans le pool. Vous ne payez que pour la durée d'utilisation de l'adresse "blanche".



Il est également possible de donner à la machine un accès à Internet à l'aide d'une instance NAT. Sur une instance, vous pouvez obtenir du trafic via une table de routage statique. Nous avons fourni un tel cas, car les utilisateurs en ont besoin et nous le savons. En conséquence, dans notre catalogue d'images se trouve une image NAT spécialement configurée.



Mais même lorsqu'il existe une image NAT prête à l'emploi, la configuration peut être compliquée. Nous avons réalisé que pour certains utilisateurs, ce n'était pas l'option la plus pratique, donc à la fin nous avons rendu possible d'inclure NAT pour le sous-réseau souhaité en un seul clic. Cette fonctionnalité est toujours en accès-aperçu privé, où elle est déployée avec l'aide des membres de la communauté.

Fonctionnement d'un réseau virtuel de l'intérieur vers l'extérieur





Comment un utilisateur interagit-il avec un réseau virtuel? Le réseau 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 de la différence entre l'état réel et l'état souhaité. Ceci est une photo de l'utilisateur. Que se passe-t-il à l'intérieur?

Nous enregistrons 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 construit sur la base de 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 plateforme CloudGate. Dans CloudGate, nous avons également utilisé un certain nombre de composants open source: GoBGP - pour accéder aux informations de contrôle, et VPP - pour implémenter un routeur logiciel fonctionnant au-dessus de DPDK pour le chemin de données.

Tungsten Fabric communique avec CloudGate via GoBGP. Explique ce qui se passe sur le réseau de superposition. CloudGate, à son tour, connecte les réseaux de superposition entre eux et à Internet.



Voyons maintenant comment un réseau virtuel gère l'évolutivité et la disponibilité. Prenons un cas simple. Il y a une zone de disponibilité et deux VPC y sont créés. Nous avons déployé une instance de Tungsten Fabric, qui tire des dizaines de milliers de réseaux. Les réseaux communiquent avec CloudGate. CloudGate, comme nous l'avons dit, assure leur connectivité entre eux et avec Internet.



Supposons qu'une deuxième zone d'accessibilité soit ajoutée. Il devrait échouer complètement indépendamment du premier. Par conséquent, dans la deuxième zone d'accès, nous devons fournir une instance Tungsten Fabric distincte. Ce sera un système distinct qui traite des superpositions et connaît peu le premier système. Et l'apparence que notre réseau virtuel est global, en fait, crée notre API VPC. Telle est sa tâche.

VPC1 est projeté dans la zone d'accès B s'il y a des ressources dans la zone d'accès B qui restent dans VPC1. S'il n'y a pas de ressources du VPC2 dans la zone d'accès B, nous ne matérialiserons pas le VPC2 dans cette zone. À son tour, puisque les ressources de VPC3 n'existent que dans la zone B, VPC3 n'est pas dans la zone A. Tout est simple et logique.

Allons un peu plus loin et voyons comment un hôte particulier est organisé dans Y. Cloud. La principale chose que je veux noter est que tous les hôtes sont organisés de la même manière. Nous faisons en sorte que seul le minimum de services nécessaire tourne sur le matériel, tout le reste fonctionne sur des machines virtuelles. Nous construisons des services d'un 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 verrons que trois composants tournent dans le système d'exploitation hôte:
  • Le calcul est la partie responsable de la distribution des ressources informatiques sur l'hôte.
  • VRouter fait partie du Tungsten Fabric qui organise la superposition, c'est-à-dire, tunnelise les paquets à travers la sous-couche.
  • Les VDisk sont des éléments de virtualisation du stockage.

De plus, des services ont été lancés sur des machines virtuelles: services d'infrastructure cloud, services de plateforme et capacités client. Les capacités des clients et les services de plate-forme sont toujours superposés via VRouter.

Les services d'infrastructure peuvent rester dans la superposition, mais ils veulent essentiellement travailler sur la sous-couche. Ils sont coincés dans une sous-couche au moyen de SR-IOV. En fait, nous découpons la carte en cartes réseau virtuelles (fonctions virtuelles) et les poussons dans des machines virtuelles d'infrastructure afin de ne pas perdre de 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 disposition des composants de base du cloud, voyons comment exactement les différentes parties du réseau virtuel interagissent entre elles.

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 amè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 utilisateur.



Comme je l'ai dit ci-dessus, tout commence par le fait qu'un utilisateur ou un service de plate-forme interne arrive à l'API et décrit un état cible spécifique.

Cet état est immédiatement enregistré dans la base de données Yandex, renvoie l'ID de l'opération asynchrone via l'API et démarre notre machine interne pour retourner l'état souhaité par l'utilisateur. Les tâches de configuration vont au contrôleur SDN et indiquent à Tungsten Fabric quoi faire dans la superposition. Par exemple, ils réservent des ports, des réseaux virtuels, etc.



Le plan de configuration de Tungsten Fabric envoie l'état requis au plan de contrôle. Grâce à lui, Config Plane communique avec les hôtes, lui indiquant ce qu'il va activer sur eux dans un avenir proche.



Voyons maintenant à quoi ressemble le système sur les hôtes. Dans la machine virtuelle, une certaine carte réseau est bloquée dans VRouter. VRouter est un module central de Tungsten Fabric qui examine les paquets. S'il existe déjà un flux pour un paquet, le module le traite. S'il n'y a pas de flux, le module effectue ce que l'on appelle le «punting», c'est-à-dire qu'il envoie le paquet au processus en mode utilisateur. Le processus analyse le paquet et y répond lui-même, comme, par exemple, à DHCP et DNS, ou indique à VRouter quoi faire avec. Après cela, le VRouter peut traiter le paquet.

En outre, le trafic entre les machines virtuelles au sein du même réseau virtuel s'exécute 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 tunnelent le trafic et se le transmettent par le biais de la sous-couche.



Le plan de contrôle communique entre les zones d'accès BGP, comme avec un autre routeur. Ils indiquent quelles machines où ils sont élevés, de sorte que les machines virtuelles d'une zone puissent interagir directement avec d'autres machines virtuelles.



De plus, Control Plane communique avec CloudGate. Il indique également où et quelles machines virtuelles sont levées, quelles sont leurs adresses. Cela vous permet de diriger le trafic externe et le trafic des équilibreurs vers eux.

Le trafic qui quitte VPC arrive à CloudGate, dans le chemin de données, où VPP est rapidement mâché avec nos plugins. Ensuite, le trafic est déclenché sur d'autres VPC ou vers les routeurs périphériques configurés via le plan de contrôle de CloudGate.

Plans pour un avenir proche


Si nous résumons tout ce qui précède en plusieurs phrases, nous pouvons dire que VPC dans Yandex.Cloud résout deux tâches importantes:

  • Fournit l'isolement entre différents clients.
  • Combine les ressources, l'infrastructure, les services de plate-forme, d'autres clouds et sur site en 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.

Le VPC acquiert progressivement des fonctions, nous réalisons de nouvelles opportunités, nous essayons d'améliorer quelque chose en termes de confort d'utilisation. Certaines idées sont exprimées et tombent dans la liste des priorités grâce aux membres de notre communauté.

Nous avons maintenant approximativement la liste suivante de plans pour un avenir proche:

  • VPN en tant que service.
  • Private DNS – DNS-.
  • DNS .
  • .
  • «» IP- .

L'équilibreur et la possibilité de changer l'adresse IP de la machine virtuelle déjà créée figuraient dans cette liste à la demande des utilisateurs. Franchement, sans retour explicite, nous reprendrions ces fonctions un peu plus tard. Et donc nous travaillons déjà sur une tâche concernant les adresses.

Initialement, une adresse IP «blanche» ne pouvait être ajoutée que lors de la création de la machine. Si l'utilisateur oublie de le faire, la machine virtuelle doit être recréée. La même chose et, si nécessaire, supprimez l'IP externe. Bientôt, il sera possible d'activer et de désactiver l'adresse IP publique sans recréer la machine.

N'hésitez pas à exprimer vos idées et à soutenir les suggestions des autres utilisateurs. Vous nous aidez à améliorer le Cloud et à obtenir plus rapidement des fonctionnalités importantes et utiles!

Source: https://habr.com/ru/post/undefined/

More articles:


All Articles