Considérations relatives à la conception pour les clouds privés Azure VMware Solution Génération 2

Cet article décrit les principales considérations relatives à la conception pour les clouds privés Azure VMware Solution Generation 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. Plusieurs considérations sont à 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 :

1. 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.

2. Vous ne pouvez déployer que 1 cloud privé par réseau virtuel Azure.

3. 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.

4. Votre cloud privé et votre réseau virtuel pour votre cloud privé doivent se trouver dans le même groupe de ressources.

5. 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é.

6. Vous ne pouvez pas migrer votre cloud privé d’un locataire vers un autre une fois le cloud privé créé.

7. Points de terminaison de service La connectivité directe depuis les charges de travail Azure VMware Solution n’est pas prise en charge.

8. 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.

9. 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.

10. Les clusters étendus vSAN ne sont pas pris en charge.

11. L’adresse IP publique jusqu’à VMware NSX Microsoft Edge pour la configuration d’Internet ne sera pas prise en charge. Vous trouverez les options Internet prises en charge dans les options de connectivité Internet.

12. 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 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 AVS VMware et les points de terminaison externes au-delà du tier-0 NSX-T, tels que les services Azure ou les environnements sur site.

13. 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.

14. Les références entre groupes de ressources et entre abonnements des réseaux virtuels clients 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 lié aux ressources d’un autre groupe de ressources ou abonnement et détacher ces ressources (par exemple, plans de protection DDoS) du réseau virtuel avant de continuer.

    • Pour gérer 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 la référence et d’appliquer correctement votre référence à votre cloud privé Azure VMware Solution.

15. Les déploiements de cloud privé Gen 2 peuvent échouer si des stratégies Azure qui 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) peuvent échouer. Ces contraintes de stratégie peuvent bloquer les groupes de sécurité réseau Azure VMware Solution requis et la création de 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 cloud privé Azure VMware Solution.

16. Si vous utilisez un DNS privé pour votre cloud privé Azure VMware Solution Gen2, l’utilisation d’un DNS personnalisé sur le réseau virtuel où 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.

17. 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.

18. 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.

19. HcX RAV et les migrations en bloc sur Gen2 peuvent rencontrer des performances beaucoup plus lentes en raison de blocages pendant les phases de synchronisation de base et de synchronisation en ligne. 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.

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 garantit que l’environnement AVS est isolé et sécurisé prêt à l'emploi, tout en permettant aux clients de contrôler et de personnaliser l’accès réseau selon leurs besoins spécifiques.

É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 de cloud privé VMware accessible aux utilisateurs et aux applications travaillant depuis des environnements sur site ou 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 minimum /22 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 :

Étapes suivantes

• Commencez à configurer votre principal de service Azure VMware Solution en tant que prérequis. Pour apprendre comment, consultez le guide de démarrage rapide Activer le principal du service Azure VMware Solution.

• Suivez un tutoriel pour créer un cloud privé Azure VMware Gen2