Les instances de Virtual Private Cloud (VPC) NSX correspondent à une couche d'abstraction qui simplifie la configuration de réseaux Virtual Private Cloud autonomes dans un projet NSX pour consommer des services de mise en réseau et de sécurité dans un modèle de consommation en libre-service.
Cette fonctionnalité est prise en charge dans les projets à partir de NSX 4.1.1.
Un VPC NSX masque aux propriétaires d'applications la complexité de l'infrastructure NSX sous-jacente, de la topologie réseau, des objets de mise en réseau et de la gestion des adresses IP, et leur offre un modèle de consommation en libre-service pour exécuter des applications dans leur propre espace privé.
Les propriétaires d'applications ou les ingénieurs DevOps n'ont pas besoin de connaître l'infrastructure NSX sous-jacente pour exécuter des applications dans leur espace isolé. Ils peuvent ajouter des sous-réseaux (réseaux) dans le VPC NSX qui leur est attribué et configurer des stratégies de sécurité pour répondre aux conditions requises de leurs applications sans dépendre de l'administrateur d'entreprise.
Les VPC NSX sont facultatifs dans un projet. Le diagramme suivant montre deux projets dans l'organisation. Le projet 1 contient des VPC NSX tandis que le projet 2 ne contient aucun VPC NSX.
Le diagramme suivant montre un exemple de vue logique d'un VPC NSX dans le projet 1. Les projets 1 et 2 sont connectés à la même passerelle de niveau 0 ou passerelle VRF de niveau 0.
- Sous-réseau d'application (privé)
- sous-réseau Web (public)
- Sous-réseau de test (isolé)
- Administrateur de sécurité
- Opérateur de réseau
- Opérateur de sécurité
Lorsqu'un VPC NSX est créé, l'administrateur de projet spécifie les blocs d'adresses IP externes et les blocs d'adresses IP privées à utiliser pour la création de sous-réseaux dans le VPC. Les modes d'accès au sous-réseau pris en charge sont Privé, Public et Isolé. Pour en savoir plus sur les modes d'accès aux sous-réseaux, reportez-vous à la section Modes d'accès pour les sous-réseaux VPC NSX plus loin dans cette documentation.
La création d'un VPC NSX entraîne celle d'un système implicitement. Toutefois, cette passerelle implicite est exposée à l'administrateur de projet en mode lecture seule et n'est pas visible par les utilisateurs VPC NSX.
Le cycle de vie de cette passerelle implicite est géré par le système. La suppression d'un VPC NSX entraîne celle de la passerelle implicite automatiquement.
Dans le modèle de données de stratégie NSX, les objets VPC NSX sont créés sous des projets au chemin suivant :
/orgs/default/projects/<project_id>/vpcs/<vpc-id>
La passerelle implicite réalisée se trouve au chemin suivant :
/orgs/default/projects/<project_id>/infra/tier-1s/
Exemple d'un VPC NSX
Supposons que votre organisation ait créé un projet nommé « Ventes » dans son environnement NSX. L'objectif de l'administrateur de projet est de fournir un environnement de mise en réseau et de sécurité isolé pour les développeurs d'applications « Gestion des commandes » et « Analyse » dans l'unité commerciale Ventes.
Les développeurs d'applications doivent pouvoir provisionner des réseaux et configurer des stratégies de sécurité pour ces deux applications dans un modèle de consommation en libre-service et sans dépendre de l'administrateur d'entreprise ou de l'administrateur de projet.
Pour atteindre cet objectif, l'administrateur de projet peut créer deux VPC NSX dans le projet « Ventes » et attribuer ces VPC NSX aux développeurs d'applications.
Par exemple :
| Nom du VPC | Utilisateurs VPC | Blocs d'adresses IP |
|---|---|---|
| Gestion des commandes | Jim : administrateur VPC Bob : opérateur de réseau Carol : opérateur de sécurité |
Bloc d'adresses IPv4 privées : 172.16.0.0/24 Bloc d'adresses IPv4 externes : 192.168.1.0/24 |
| Analyse | Mike : administrateur VPC Steve : opérateur de réseau Maria : opérateur de sécurité |
Bloc d'adresses IPv4 privées : 172.18.0.0/24 Bloc d'adresses IPv4 externes : 192.168.1.0/24 |
Une fois les rôles attribués aux utilisateurs VPC NSX, ces derniers peuvent ajouter des sous-réseaux dans le VPC NSX et configurer des stratégies de sécurité pour ces charges de travail. Les stratégies de sécurité ont uniquement une incidence sur les charges de travail dans le VPC NSX et non en dehors du VPC NSX.
Par exemple, le diagramme suivant montre trois sous-réseaux nommés Dév, Test et Production dans le VPC NSX de gestion des commandes et trois sous-réseaux nommés Application, Web et Base de données dans le VPC NSX d'analyse. Les VM de charge de travail sont attachées à tous les sous-réseaux. Les VPC NSX sont attachés à la même passerelle de niveau 0 ou passerelle VRF de niveau 0 du projet Ventes.
Workflow de VPC NSX général
- Administrateur de projet : ajoute VPC NSX dans un projet et définit des paramètres de base du VPC NSX, tels que l'attribution IP, la configuration DHCP, le cluster Edge, etc.
- Administrateur de projet : attribue des rôles aux utilisateurs dans le VPC NSX.
- Administrateur de projet : définit le quota ou les limites du nombre d'objets que les utilisateurs peuvent créer dans le VPC NSX.
- Administrateur VPC ou administrateur réseau : ajoute des sous-réseaux dans le VPC NSX. Connecte les charges de travail à ces sous-réseaux en fonction des besoins de l'entreprise.
- Administrateur VPC ou administrateur de sécurité : ajoute des stratégies de sécurité dans le VPC NSX pour répondre aux exigences de sécurité des charges de travail connectées aux sous-réseaux dans le VPC.
Modes d'accès pour les sous-réseaux VPC NSX
- Privé
-
Un sous-réseau privé est accessible uniquement dans le VPC NSX. Les charges de travail attachées à un sous-réseau privé peuvent communiquer avec des charges de travail sur d'autres sous-réseaux privés ou publics dans le même VPC NSX.
Si l'attribution IP pour le sous-réseau privé est définie sur « automatique », les blocs d'adresses IP de sous-réseau (CIDR de sous-réseau) sont automatiquement attribués à partir des blocs IPv4 privés attribués au VPC NSX. Si l'attribution IP pour le sous-réseau privé est définie sur « manuel », l'administrateur VPC peut attribuer manuellement le CIDR de sous-réseau.
Le CIDR d'un sous-réseau VPC ne peut pas chevaucher celui d'un autre sous-réseau de VPC dans le même VPC NSX. Toutefois, les adresses IP du sous-réseau peuvent chevaucher le sous-réseau dans un autre VPC NSX. Il est possible d'effectuer cette configuration en allouant différents blocs d'adresses IP privées avec les mêmes plages d'adresses IP à différents VPC NSX.
Plusieurs VPC NSX dans un projet peuvent partager le même bloc d'adresses IPv4 privées. Dans ce cas, les sous-réseaux privés seront uniques dans les différents VPC qui partagent le même bloc d'adresses IP privées.
Si l'option NAT sortante par défaut est activée pour le VPC NSX, une règle SNAT par défaut est créée pour le VPC NSX afin d'autoriser le trafic provenant des charges de travail sur les sous-réseaux privés à acheminer en dehors du VPC NSX. Si cette option est désactivée sur des lignes similaires, le trafic provenant du sous-réseau privé ne peut pas être acheminé en dehors du VPC NSX.
- Public
-
Un sous-réseau public est accessible depuis l'extérieur du VPC NSX. Ce sous-réseau est annoncé automatiquement à la passerelle de niveau 0 du projet et bénéficie par défaut d'une connectivité externe directe. En d'autres termes, les adresses IPv4 dans les sous-réseaux publics sont accessibles depuis le projet et en dehors de celui-ci.
Si l'attribution IP pour le sous-réseau public est définie sur « automatique », les blocs d'adresses IP de sous-réseau (CIDR de sous-réseau) sont automatiquement attribués à partir des blocs IPv4 externes spécifiés pour le projet. Si l'attribution IP pour le sous-réseau public est définie sur « manuel », l'administrateur VPC peut attribuer manuellement le CIDR de sous-réseau.
- Isolé
-
Un sous-réseau isolé n'est pas connecté en interne à la passerelle implicite réalisée. Les charges de travail sur un sous-réseau isolé peuvent communiquer entre elles, mais ne peuvent pas communiquer avec des charges de travail sur des sous-réseaux privés ou publics dans le même VPC NSX. En outre, les paquets provenant de sous-réseaux isolés ne peuvent pas sortir du VPC NSX.
Un administrateur VPC doit spécifier manuellement l'adresse CIDR d'un sous-réseau isolé.
