Azure VMware Solution Génération 2 arrive en préview

 



Microsoft annonce l'arrivée de AVS gen2 et c est une belle évolution. La principale différence est que AVS gen2 est directement hébergé dans Azure et non plus a coté comme avant. Cela entrainer l'obligation d'avoir un expressroute entre AVS et Azure comme l'indique le schéma ci dessous.


AVS Gen2 est basé sur les host AV64 qui avait l'obligation d'avoir installer un premier cluster avec des serveurs AV36, AV36P, AV48 ou AV52. le schéma ci dessous démontre l'ancienne architecture au niveau des serveurs AVS.



Maintenant avec AVS Gen2 seul les hosts AV64 sont disponibles, très probablement d'autres viendront par la suite


AVS Gen2 nécessite toujours 3 hosts AV64 pour démarrer le cluster mais maintenant tout est connecté dans Azure natif via un Vnet Peering et non plus un expressroute.

Les avantages

Déploiement simplifié et rentabilité

  •          Vous pouvez déployer directement des clouds privés Azure VMware Solution Gen2 avec la référence SKU AV64, ce qui élimine le besoin d’un minimum de 3 hôtes AV36, AV36P, AV48 ou AV52. Un cluster AV64 d'au moins 3 hôtes est encore requis.

Intégration Azure transparente

  •          Les clouds privés Azure VMware Solution Gen 2 sont désormais déployés à l’intérieur d’un réseau virtuel Azure par défaut, fournissant une connectivité instantanée à d’autres services Azure.
  •          Aucune configuration réseau supplémentaire n’est nécessaire et le peering de réseaux virtuels Azure fonctionne immédiatement.

Amélioration de la sécurité et de la conformité

  •          Votre cloud privé Azure VMware Solution s’exécute toujours sur du matériel dédié et isolé, ce qui signifie que vous bénéficiez des avantages continus d’un cloud privé tout en restant dans Azure.
  •          Vous pouvez appliquer des outils de sécurité centrés sur Azure, tels que des groupes de sécurité réseau (NSG), pour simplifier la gestion de la sécurité.

Autres fonctionnalités et capacités déverrouillées

  •        Possibilité de sélectionner la résolution DNS privée pour votre cloud privé, ce qui permet aux entreprises de communiquer entre les environnements Azure et locaux sans être exposées à l’interne.
  •          Possibilité de sélectionner la zone de disponibilité dans laquelle déployer votre cloud privé pour réduire la latence dans les environnements locaux.
  •          Actuellement la solution est disponible dans 2 régions, USA est et Suisse nord

Limitations pendant la préversion publique

Ces limitations seront levées à l’avenir :

  • Vous ne pouvez pas supprimer votre groupe de ressources, qui contient votre cloud privé.
  • Vous ne pouvez déployer que 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é.
  • La connectivité directe des points de terminaison du service de réseau virtuel à partir des charges de travail Azure VMware Solution n’est pas prise 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’adresse IP publique jusqu’à VMware NSX Microsoft Edge pour la configuration d’Internet ne sera pas prise en charge.
  • La prise en charge de AzCLIPowerShell et le SDK .NET n’est pas disponible pendant la préversion publique.
  • Les commandes d’exécution qui interagissent avec les segments de client ne sont pas prises en charge, notamment Zerto, JetStream et d’autres intégrations tierces.
  • 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.

Intégrations non prises en charge pendant la préversion publique

Les intégrations de 1ère et 3ème parties suivantes ne seront pas disponibles pendant la préversion publique :

  • SAN élastique Azure
  • Zerto DR
  • JetStream DRVA

 

Enfin quelques é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 :



 


Commentaires

Messages les plus consultés de ce blogue

VMware Explore 2024 Party list events

VMware Explore 2025 registration is now live and there is some great improvements

Changement dans les licences VMware à compter du 10 avril 2025