Considérations de conception pour les clouds privés de génération 2 pour Azure VMware Solution

Cet article décrit les principales considérations relatives à la conception des clouds privés de Azure VMware Solution génération 2 (Gen2). Il explique les fonctionnalités que cette génération apporte aux environnements de cloud privé VMware, ce qui permet d’accéder à vos applications à partir de l’infrastructure locale et des ressources Azure. Il existe plusieurs considérations à prendre en compte avant de configurer votre cloud privé Azure VMware Solution Gen2. Cet article fournit des solutions pour les cas d’usage que vous pouvez rencontrer lorsque vous utilisez le type de cloud privé.

Limites

La fonctionnalité suivante est limitée pendant cette période. Ces limitations seront levées à l’avenir :

• Vous ne pouvez pas supprimer votre groupe de ressources, qui contient votre cloud privé. Vous devez d’abord supprimer le cloud privé avant de supprimer le groupe de ressources.
• Vous pouvez déployer uniquement 1 cloud privé par réseau virtuel Azure.
• Vous ne pouvez créer qu’un cloud privé par groupe de ressources. Plusieurs clouds privés dans un seul groupe de ressources ne sont pas pris en charge.
• Votre cloud privé et votre réseau virtuel pour votre cloud privé doivent se trouver dans le même groupe de ressources.
• Vous ne pouvez pas déplacer votre cloud privé d’un groupe de ressources vers un autre après la création du cloud privé.
• Vous ne pouvez pas déplacer votre cloud privé d’un locataire vers un autre après la création du cloud privé.
• Si vous avez besoin de ExpressRoute FastPath ou Global Réseau virtuel Peering pour votre cloud privé AVS, créez un cas de support via le portail Azure.
• Service Endpoints la connectivité directe depuis les charges de travail de la solution Azure VMware n'est pas prise en charge.
• Les points de terminaison privés lorsqu'ils sont en peering global entre des régions connectées à Azure VMware Solution ne sont pas pris en charge.
• VCloud Director utilisant des points de terminaison privés est pris en charge. Toutefois, vCloud Director utilisant des points de terminaison publics n’est pas pris en charge.
• Les clusters étendus vSAN ne sont pas pris en charge.
• L’attribution d’une IP publique jusqu’à l’interface VMware NSX Microsoft Edge pour configurer l’accès Internet n’est pas prise en charge. Vous trouverez les options Internet prises en charge dans les options de connectivité Internet.
• Pendant une maintenance non planifiée , comme une défaillance matérielle de l’hôte, sur l’un des quatre premiers hôtes de votre Centre de données défini par logiciel (SDDC), vous pouvez rencontrer une interruption temporaire de connectivité réseau North-South pour certaines charges de travail, pouvant durer jusqu’à 30 secondes. La connectivité Nord-Sud fait référence au trafic entre vos charges de travail VMware AVS et les points de terminaison externes au-delà de l'Edge de Tier-0 (T0) NSX-T, comme les services Azure ou les environnements locaux. Cette limitation a été supprimée dans des régions Azure spécifiques. Vérifiez si votre région est affectée par cette limitation en vérifiant avec Azure support.  
• Les groupes de sécurité réseau associés au réseau virtuel hôte de cloud privé doivent être créés dans le même groupe de ressources que le cloud privé et son réseau virtuel.
• Les références inter-groupes de ressources et inter-abonnements des réseaux virtuels du client vers le réseau virtuel Azure VMware Solution ne sont pas prises en charge par défaut. Cela inclut des types de ressources tels que : itinéraires définis par l’utilisateur (UDR), plans de protection DDoS et autres ressources réseau liées. Si un réseau virtuel client est associé à l’une de ces références qui résident dans un groupe de ressources ou un abonnement différent du réseau virtuel Azure VMware Solution, la programmation réseau (telle que la propagation de segment NSX) peut échouer. Pour éviter les problèmes, les clients doivent s'assurer que le réseau virtuel Azure VMware Solution n'est pas connecté aux ressources d'un autre groupe de ressources ou d'un autre abonnement. Avant de continuer, supprimez toutes ces connexions, telles que les plans de protection DDoS, du réseau virtuel.
  • Pour conserver votre référence inter-ressources, créez une attribution de rôle à partir de votre groupe ou abonnement inter-ressources et attribuez à l’application « AzS VIS Prod App » le « rôle AVS on Fleet VIS ». L’attribution de rôle vous permet d’utiliser des références et d’appliquer correctement votre référence pour votre Azure VMware Solution cloud privé.
• Les déploiements de cloud privé Gen 2 peuvent échouer si Azure stratégies appliquent des règles strictes pour les groupes de sécurité réseau ou les tables de routage (par exemple, des conventions d’affectation de noms spécifiques). Ces contraintes de stratégie peuvent bloquer la création des groupes de sécurité du réseau Azure VMware Solution et des tables de routage pendant le déploiement. Vous devez supprimer ces stratégies du réseau virtuel Azure VMware Solution avant de déployer votre cloud privé. Une fois votre cloud privé déployé, ces stratégies peuvent être ajoutées à votre Azure VMware Solution cloud privé.
• Si vous utilisez DNS privé pour votre cloud privé Azure VMware Solution Gen2, l'utilisation de Custom DNS sur le réseau virtuel sur lequel un cloud privé Azure VMware Solution Gen2 est déployé n'est pas pris en charge. Le DNS personnalisé interrompt les opérations de cycle de vie telles que la mise à l’échelle, les mises à niveau et la mise à jour corrective.
• Si vous supprimez votre cloud privé et que certaines ressources créées par Azure VMware Solution ne sont pas supprimées, vous pouvez réessayer la suppression du cloud privé Azure VMware Solution à l’aide d’Azure CLI.
• Azure VMware Solution Gen 2 utilise un proxy HTTP pour faire la distinction entre le trafic réseau client et de gestion. Certains points de terminaison de service cloud VMware peuvent ne pas suivre le même chemin réseau ou les mêmes règles de proxy que le trafic managé par vCenter général. Voici quelques exemples : « scapi.vmware » et « apigw.vmware ». Le proxy VAMI régit l’accès Internet sortant de vCenter Server Appliance (VCSA), mais pas toutes les interactions de point de terminaison de service transitent par ce proxy. Certaines interactions proviennent directement du navigateur de l’utilisateur ou des composants d’intégration, qui suivent plutôt les paramètres proxy de la station de travail ou initient des connexions indépendamment. Par conséquent, le trafic vers les points de terminaison de service cloud VMware peut contourner entièrement le proxy VCSA.
• Les migrations HCX RAV et Bulk sur Gen 2 peuvent présenter des performances plus lentes en raison de blocages pendant les phases Base Sync et Online Sync. Les clients doivent planifier des fenêtres de migration plus longues et planifier des vagues en conséquence pour l’instant. Pour les charges de travail appropriées, vMotion offre une option plus rapide et à faible charge lorsque les conditions de l'hôte et du réseau le permettent.
• Peering Virtual HUB (virtual WAN) : pour établir une connexion de peering entre un réseau virtuel Gen-2 et un hub virtuel (virtual WAN), le hub virtuel doit se trouver dans la même région que le réseau virtuel Gen-2. Si vous devez établir un peering avec un hub virtuel dans une autre région, vous devez créer une demande de support dans le portail Azure.
• Destination de route /32 depuis un réseau virtuel (VNET) appairé : si vous annoncez des routes /32 depuis NSX (comme des routes HCX MON ou des routes de redirecteur DNS) et que vous devez accéder à cette destination /32 depuis un réseau virtuel appairé, vous devez ouvrir une demande de support dans le portail Azure. La connectivité à la destination /32 fonctionne correctement à partir du réseau virtuel local.
• Annonce du sous-réseau VNET Peer Sync et association de table de routage Azure (UDR) — Azure VMware Solution Gen 2 utilise deux architectures internes. L’architecture actuelle synchronise à la fois des sous-réseaux spécifiques et l’espace d’adressage Azure plus large pour les routes de segments ou de sous-réseaux NSX avec les réseaux virtuels Azure appairés. Par conséquent, avec l’architecture actuelle de Gen 2, vous devrez peut-être configurer les tables de routage Azure (UDR) avec des routes de sous-réseaux des segments NSX plus spécifiques, plutôt que d’utiliser des routes générales de l’espace d’adressage pour les segments de charge de travail d’Azure VMware Solution.

Intégrations non prises en charge

Les intégrations tierces et internes suivantes ne sont pas disponibles :

• Zerto DR

Sous-réseaux délégués et groupes de sécurité réseau pour Gen2

Lorsqu’un cloud privé Azure VMware Solution (AVS) Gen2 est déployé, Azure crée automatiquement plusieurs sous-réseaux délégués au sein du réseau virtuel hôte du cloud privé. Ces sous-réseaux sont utilisés pour isoler et protéger les composants de gestion du cloud privé.

Les clients peuvent gérer l’accès à ces sous-réseaux à l’aide de groupes de sécurité réseau (NSG) visibles dans le portail Azure ou via Azure CLI/PowerShell. Outre les groupes de sécurité réseau gérables par le client, AVS applique des groupes de sécurité réseau gérés par le système supplémentaires aux interfaces de gestion critiques. Ces groupes de sécurité réseau gérés par le système ne sont pas visibles ou modifiables par les clients et existent pour s’assurer que le cloud privé reste sécurisé par défaut.

Dans le cadre de la posture de sécurité par défaut :

• L’accès Internet est désactivé pour le cloud privé, sauf si le client l’active explicitement.
• Seul le trafic de gestion requis est autorisé à atteindre les services de plateforme.

Cette conception maintient l’environnement AVS sécurisé et isolé par défaut, tout en permettant aux clients de gérer et d’ajuster l’accès réseau en fonction de leurs besoins.

Éléments à prendre en considération en matière de routage et de sous-réseaux

Les clouds privés Azure VMware Solution Gen 2 fournissent un environnement cloud privé VMware accessible aux utilisateurs et aux applications à partir d’environnements ou de ressources sur site et basés sur Azure. La connectivité est fournie via la mise en réseau Azure standard. Des plages d’adresses réseau et des ports de pare-feu spécifiques sont nécessaires pour activer ces services. Cette section vous aide à configurer votre réseau pour qu’elle fonctionne avec Azure VMware Solution.

Le cloud privé se connecte à votre réseau virtuel Azure à l’aide de la mise en réseau Azure standard. Les clouds privés Azure VMware Solution Gen 2 nécessitent un bloc d’adresses réseau CIDR /22 minimum pour les sous-réseaux. Ce réseau complétant vos réseaux locaux, le bloc d’adresses ne doit pas chevaucher les blocs d’adresses utilisés dans d’autres réseaux virtuels situés de votre abonnement et de vos réseaux locaux. Les réseaux de gestion, de vMotion et de réplication sont approvisionnés automatiquement dans ce bloc d’adresses en tant que sous-réseaux à l’intérieur de votre réseau virtuel.

Évitez d’utiliser le schéma IP suivant réservé à l’utilisation de VMware NSX :

• 169.254.0.0/24 - utilisé pour le réseau de transit interne
• 169.254.2.0/23 - utilisé pour le réseau de transit inter-VRF
• 100.64.0.0/16 - utilisé pour connecter des passerelles T1 et T0 en interne
• 100.73.x.x : utilisé par le réseau de gestion de Microsoft

L’exemple /22 du bloc d’adresses réseau CIDR 10.31.0.0/22 est divisé en sous-réseaux suivants :

Programmation des routes NSX vers le réseau virtuel Azure

Les routes NSX Gen-2 d’Azure VMware Solution sont intégrées à Azure à l’aide de l’espace d’adressage et en les attribuant comme adresses IP secondaires sur le sous-réseau créé par le système "avs-network-infra-gw", ce qui permet une connectivité fluide entre Azure et les charges de travail des clients AVS. Lorsque NSX Tier-0 publie un itinéraire en fonction des paramètres utilisateur, tels que la création de segments, l’ajout d’itinéraires statiques ou l’utilisation de machines virtuelles HCX MON, le plan de contrôle Azure VMware Solution vérifie si le préfixe d’itinéraire existe dans l’espace d’adressage du réseau virtuel. Si ce n’est pas le cas, il crée l’espace d’adressage et ajoute le préfixe de route comme IP secondaires sur le sous-réseau « avs-network-infra-gw ». Pour les routes /32 annoncées par le Tier-0, comme les routes HCX MON, les adresses IP secondaires ne sont pas configurées, mais le plan de données est configuré en interne de manière à garantir la connectivité vers les destinations /32 dans Azure VMware Solution.

Outre l’espace d’adressage et la mise à jour du sous-réseau pour les itinéraires NSX, il existe une programmation interne dont les clients doivent être conscients, en particulier en ce qui concerne l’échelle prise en charge lorsque des masques de sous-réseau inférieurs sont utilisés. Pour plus d’informations sur l’aspect lié à la mise à l’échelle, consultez Architecture du routage pour Azure VMware Solution Gen 2

Considération relative à l’association de la table de routage Azure (UDR)

Azure VMware Solution Gen-2 comprend deux architectures internes, avec une légère variation. Certaines des clouds privés Gen-2 utilisent l’architecture interne initiale. Celles-ci sont mises à jour vers l’architecture actuelle par le biais d’une maintenance planifiée, coordonnée avec le client. Toutefois, il existe un changement de comportement avec l’architecture actuelle, par rapport à l’architecture initiale, qui peut affecter certaines considérations relatives à la conception du réseau, comme décrit ci-dessous.

Cloud privé Gen-2 initial :

• Azure réseau virtuel a deux sous-réseaux de passerelle de base nommés « avs-nsx-gw » et n'a pas le sous-réseau « avs-network-infra-gw » comme dans l'architecture actuelle.
• Tous les sous-réseaux de segment NSX AVS sont programmés sous le sous-réseau « avs-nsx-gw » comme adresse IPv4 supplémentaire pour la connexion de Azure aux charges de travail NSX.
• La table de routage (UDR) ou le NSG Azure pour le trafic provenant d’AVS vers le VNET Azure et au-delà (par exemple vers l’environnement on-premises) doit être appliqué au sous-réseau « avs-nsx-gw ».

Cloud privé Gen-2 actuel :

Veillez à prendre note de ce changement de comportement.

• Le réseau virtuel Azure comporterait un sous-réseau supplémentaire avec le préfixe « avs-network-infra-gw », ainsi que deux sous-réseaux de passerelle de base nommés « avs-nsx-gw », comme dans l’architecture initiale.
• Tous les sous-réseaux de segment NSX AVS sont désormais programmés sous ce sous-réseau en tant qu’adresse IPv4 secondaire pour la connexion Azure aux charges de travail NSX. Cela ne modifie pas la connectivité réseau du client.
• Le peering VNET annonce à la fois l’espace d’adressage et les sous-réseaux au VNET appairé, ce qui diffère de l’architecture initiale ou de la synchronisation VNET native Azure où seul l’espace d’adressage est synchronisé.

Considérations relatives à la conception en raison des modifications apportées à l’architecture interne Gen-2

• Les clients constatent des routes effectives supplémentaires pour les sous-réseaux AVS au sein du VNET appairé en raison du changement de comportement de synchronisation du peering VNET.
• Si un client utilise une table de routage Azure (UDR) pour envoyer le trafic local à AVS via un pare-feu ou une appliance virtuelle réseau, il doit mettre à jour l’UDR pour utiliser des itinéraires de sous-réseau NSX spécifiques au lieu de la plage d’adresses de supernet étendue utilisée précédemment. Cela est nécessaire pour empêcher le trafic destiné à AVS d’emprunter des routes de sous-réseau du réseau virtuel plus spécifiques, en contournant le pare-feu prévu, en raison du comportement de routage Azure basé sur la correspondance de préfixe la plus longue. Dans le cas contraire, cela peut entraîner un routage asymétrique, ce qui peut entraîner des problèmes de connectivité.
• Toutefois, la table de routage (UDR) ou le groupe de sécurité réseau (NSG) Azure pour le trafic d’AVS vers le réseau virtuel Azure (VNET) et au-delà (par exemple, en local) continuerait de s’appliquer aux sous-réseaux « avs-nsx-gw », et non à « avs-network-infra-gw ». Les clients ne doivent pas utiliser la table de routage (UDR) sur le sous-réseau « avs-network-infra-gw », même si les sous-réseaux de segment NSX sont configurés en tant qu’adresses IP secondaires.

Étapes suivantes

• Commencez à configurer votre compte principal de service Azure VMware Solution comme prérequis. Pour en savoir plus, consultez le guide de démarrage rapide Activer le principal de service Azure VMware Solution.

• Suivez un tutoriel pour Creating an Azure VMware Gen2 Private Cloud