Les VPC (Virtual Private Cloud) NSX correspondent à une couche d'abstraction qui simplifie la configuration de réseaux de cloud privé virtuel autonomes dans un projet NSX défini par l'utilisateur pour consommer des services de mise en réseau et de sécurité dans un modèle de consommation en libre-service.

Les VPC NSX représentent une couche supplémentaire d'architecture mutualisée au sein d'un projet. Cela fournit un modèle de consommation simplifié des services de mise en réseau et de sécurité, qui est aligné sur l'expérience que vous auriez dans un environnement de cloud public.

Un NSX VPC 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 NSX VPC 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.


Ce diagramme est expliqué dans le texte qui s'y rapporte.

Le diagramme suivant montre un exemple de vue logique d'un NSX VPC 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.


Ce diagramme est expliqué dans le texte qui s'y rapporte.
Le NSX VPC du projet 1 contient trois sous-réseaux :
  • Sous-réseau d'application (privé)
  • sous-réseau Web (public)
  • Sous-réseau de test (isolé)
Chaque NSX VPC d'un projet représente un domaine de routage indépendant. Les sous-réseaux d'un NSX VPC représentent des domaines de diffusion indépendants de couche 2. Les sous-réseaux sont réalisés en tant que segments de superposition dans la zone de transport par défaut du projet. Les utilisateurs qui disposent du rôle d'administrateur VPC ou du rôle d'administrateur réseau sont attribués dans le NSX VPC peuvent ajouter des sous-réseaux dans le NSX VPC. En plus de ces deux rôles, un NSX VPC peut également disposer des rôles d'utilisateur suivants, mais avec leur étendue limitée au NSX VPC :
  • Administrateur de sécurité
  • Opérateur de réseau
  • Opérateur de sécurité

Lorsqu'un NSX VPC 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 NSX VPC plus loin dans cette documentation.

La création d'un NSX VPC 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 NSX VPC.

Le cycle de vie de cette passerelle implicite est géré par le système. La suppression d'un NSX VPC entraîne celle de la passerelle implicite automatiquement.

Dans le modèle de données de stratégie NSX, les objets NSX VPC 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 NSX VPC

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 NSX VPC, ces derniers peuvent ajouter des sous-réseaux dans le NSX VPC 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 NSX VPC et non en dehors du NSX VPC.

Par exemple, le diagramme suivant montre trois sous-réseaux nommés Dév, Test et Production dans le NSX VPC de gestion des commandes et trois sous-réseaux nommés Application, Web et Base de données dans le NSX VPC 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.


Ce diagramme est expliqué dans le texte qui s'y rapporte.

Workflow de NSX VPC général

À un niveau général, le workflow NSX VPC est le suivant :
  1. Administrateur de projet : ajoute NSX VPC dans un projet et définit des paramètres de base du NSX VPC, tels que l'attribution IP, la configuration DHCP, le cluster Edge, etc.
  2. Administrateur de projet : attribue des rôles aux utilisateurs dans le NSX VPC.
  3. Administrateur de projet : définit le quota ou les limites du nombre d'objets que les utilisateurs peuvent créer dans le NSX VPC.
  4. Administrateur VPC ou administrateur réseau : ajoute des sous-réseaux dans le NSX VPC. Connecte les charges de travail à ces sous-réseaux en fonction des besoins de l'entreprise.
  5. Administrateur VPC ou administrateur de sécurité : ajoute des stratégies de sécurité dans le NSX VPC 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 NSX VPC

Les modes d'accès pris en charge pour les sous-réseaux dans un NSX VPC sont les suivants :
Privé

Un sous-réseau privé est accessible uniquement dans le NSX VPC. 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 NSX VPC.

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 NSX VPC. 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 NSX VPC. Toutefois, les adresses IP du sous-réseau peuvent chevaucher le sous-réseau dans un autre NSX VPC. 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 NSX VPC, une règle SNAT par défaut est créée pour le NSX VPC afin d'autoriser le trafic provenant des charges de travail sur les sous-réseaux privés à acheminer en dehors du NSX VPC. 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 NSX VPC.

Public

Un sous-réseau public est accessible depuis l'extérieur du NSX VPC. 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 NSX VPC. En outre, les paquets provenant de sous-réseaux isolés ne peuvent pas sortir du NSX VPC.

Un administrateur VPC doit spécifier manuellement l'adresse CIDR d'un sous-réseau isolé.