Mise en réseau de cloud privé pour VMware Engine
Ce document fournit une présentation de Google Cloud VMware Engine, traite des concepts de mise en réseau et des flux de trafic les plus courants et fournit des conseils sur l'utilisation de VMware Engine pour concevoir une architecture. Ce document explique le fonctionnement de VMware Engine, ses fonctionnalités et ce qu'il faut envisager pour choisir la meilleure architecture.
Ce document vous concerne si vous êtes un ingénieur réseau, un ingénieur cloud, un architecte ou un opérateur chargé de concevoir, de gérer ou de dépanner la sécurité, la connectivité et la disponibilité des applications reposant sur VMware et hébergées dans Google Cloud.
Ce document vous permet également d'en savoir plus sur VMware Engine, et sur ses exigences et ses fonctionnalités. Au fil de votre exploration de la technologie, ou si vous souhaitez la tester ou la déployer en production, ce document vous permettra de comprendre le fonctionnement de VMware Engine et son intégration à un nouvel environnement Google Cloud ou à un environnement Google Cloud existant. Ce document passe en revue tous les aspects de la mise en réseau et vous aide à déterminer la meilleure solution pour votre cas d'utilisation.
La mise en réseau VMware Engine s'intègre aux réseaux de cloud privé virtuel (VPC) qui disposent d'une connectivité existante avec des réseaux sur site, ainsi qu'avec d'autres services Google Cloud. VMware Engine repose sur une infrastructure hautes performances, fiable et à grande capacité, pour vous offrir une expérience VMware optimale.
Présentation
VMware est un service fourni par Google qui vous aide à migrer et à exécuter vos charges de travail VMware sur Google Cloud.
VMware Engine fournit un centre de données défini par logiciel (SDDC, software-defined data center) entièrement géré, comprenant les composants suivants : VMware vSphere, vCenter Server, vSAN et NSX-T. VMware Engine comprend HCX pour la migration vers le cloud dans un environnement dédié sur Google Cloud pour gérer les charges de travail de production des entreprises. Vous pouvez utiliser VMware Engine pour migrer ou étendre vos charges de travail sur site vers Google Cloud en vous connectant à un environnement VMware dédié directement via la console Google Cloud. Cette fonctionnalité vous permet de migrer vers le cloud sans le coût ni la complexité des applications de refactorisation, et d'exécuter et de gérer les charges de travail de manière cohérente avec votre environnement sur site. En exécutant vos charges de travail VMware sur Google Cloud, vous réduisez votre charge opérationnelle tout en bénéficiant d'évolutivité et d'agilité, et maintenez la continuité avec vos outils, règles et processus existants.
VMware Engine s'appuie sur l'infrastructure ultra-performante et évolutive de Google Cloud avec un réseau dédié de 100 Gbit/s entièrement redondant et avec une disponibilité allant jusqu'à 99,99 %, afin de répondre aux besoins de la pile VMware. Les services de mise en réseau cloud tels que Cloud Interconnect et Cloud VPN vous permettent d'accéder au cloud depuis vos environnements sur site. La bande passante élevée de ces connexions aux services cloud est optimisée pour améliorer les performances et la flexibilité, tout en réduisant les dépenses et les coûts opérationnels. L'assistance de bout en bout et de bout en bout vous offre une expérience fluide et intégrée, aussi bien dans ce service que dans le reste de Google Cloud.
Une fois les charges de travail déplacées, vous avez un accès immédiat aux services Google Cloud tels que BigQuery, Cloud Operations, Cloud Storage, Anthos et Cloud AI. Google Cloud offre également une facturation entièrement intégrée, ainsi qu'une gestion des identités et un contrôle des accès conçus pour unifier votre expérience avec d'autres produits et services Google Cloud.
Cas d'utilisation
Le diagramme suivant est une architecture de référence représentative qui montre comment migrer ou étendre votre environnement VMware vers Google Cloud tout en profitant des services Google Cloud. VMware Engine propose des solutions pour les cas d'utilisation suivants.
Exigences liées à l'intégration
Avant de commencer le déploiement de VMware Engine sur Google Cloud, assurez-vous de lire les conditions requises pour l'intégration.
Composants du système
En règle générale, les composants VMware Engine sont les suivants :
- Google Cloud :
- VMware Engine :
- NSX-T
- HCX
- vCenter
- vSAN
- Votre organisation Google Cloud :
- Votre projet Google Cloud disposant d'un réseau VPC
- Cloud Interconnect disposant de l'interconnexion partenaire, de l'interconnexion dédiée ou d'une connexion Cloud VPN aux systèmes sur site
- Connexion d'accès aux services privés à la région VMware Engine
- Connexion d'accès aux services privés
- Intégration des services gérés par Google
- VMware Engine :
- (Facultatif) Ressources sur site :
- Mise en réseau
- Stockage
- HCX (recommandé pour les connexions de couche 2, également appelée extension L2)
- vCenter
Un cloud privé est une pile VMware isolée constituée d'hôtes ESXi, d'un serveur vCenter et des composants vSAN, NSX-T et HCX. Ces composants sont collectivement appelés composants Google Cloud VMware Engine, et sont déployés lorsque l'administrateur cloud crée un cloud privé. Les utilisateurs de votre organisation peuvent ensuite accéder de manière privée aux clouds privés VMware Engine à partir de leurs réseaux VPC en établissant une connexion d'accès aux services privés. Le schéma suivant illustre cette architecture.
L'accès aux services privés est une connexion privée entre votre réseau VPC et un réseau appartenant à Google ou à un tiers. Google ou les entités tierces proposant des services sont également appelés producteurs de services.
Pour chacun de vos réseaux VPC connectés à VMware Engine, il existe un réseau VPC de producteur de services qui est créé lorsque vous créez une connexion d'accès aux services privés dans Google Cloud. Votre projet Google Cloud contient un réseau VPC partagé qui peut être utilisé pour se connecter à d'autres services Google Cloud, tels que Memorystore et Cloud SQL. Vous pouvez par exemple effectuer une migration Lift and Shift de vos VM MySQL ou PostgreSQL sur site vers VMware Engine, puis les migrer vers Cloud SQL à l'aide du service intégré Database Migration Service de Google Cloud, tout en autorisant vos charges de travail VMware Engine à accéder à ces bases de données.
VMware ne vous oblige pas à utiliser NSX-T sur site. De plus, l'utilisation de HCX n'est obligatoire pour aucun des cas d'utilisation, car vous pouvez utiliser d'autres mécanismes pour réaliser une migration de charge de travail et extension de couche 2 (L2). Cependant, nous vous recommandons d'utiliser HCX pour une migration efficace des charges de travail et pour plus de facilité, car cette fonctionnalité est déployée automatiquement lorsque vous créez votre cloud privé si vous sélectionnez cette option.
Fonctionnalités de mise en réseau
Voici un résumé des fonctionnalités de mise en réseau de VMware Engine:
- Connectivité multi-VPC : VMware Engine vous permet de connecter le même cloud privé à plusieurs réseaux VPC (jusqu'à trois au total, ou deux si vous utilisez le service Internet régional). Ces réseaux VPC peuvent être des réseaux VPC consommateur ou des services pour les partenaires gérés (MPS).
- Sous-réseaux : vous pouvez créer des sous-réseaux de gestion et de charge de travail dans vos clouds privés.
- Routage dynamique : les sous-réseaux VMware Engine administrés par NSX sont automatiquement annoncés sur le reste du réseau Google, ainsi que sur vos emplacements sur site, via le protocole BGP (Border Gateway Protocol).
- Fonctionnalités de routage régional et global : vous pouvez déterminer si les réseaux VPC partagés du producteur de services qui connectent vos clouds privés ne peuvent acheminer le trafic que dans une région ou au niveau mondial.
- Service IP public et passerelle Internet (entrée et sortie) : VMware Engine dispose de son propre service d'adresses IP publiques pour le trafic d'entrée et le trafic de sortie de passerelle Internet. Il s'agit d'un service régional.
- Stratégies de pare-feu : VMware Engine vous permet de créer des stratégies de pare-feu L4 et L7 à l'aide du pare-feu distribué NSX (est-ouest) et du pare-feu de passerelle NSX (nord-sud). Par exemple, vous pouvez appliquer des contrôles précis pour accéder aux charges de travail qui utilisent des adresses IP publiques, comme des serveurs Web.
- Chaînage de services pour la sécurité est-ouest : permet d'enregistrer une solution de sécurité partenaire (IDS, IPS ou NGFW) pour configurer les services réseau afin d'inspecter le trafic est-ouest entre les VM.
- Protection des points de terminaison : les VM sauvegardées par VMware Engine peuvent être protégées contre les logiciels malveillants et les virus via l'intégration de partenaires avec des tiers compatibles. Pour en savoir plus, consultez la documentation officielle de VMware.
- Accès privé à d'autres services Google : VMware Engine s'intègre à d'autres services Google Cloud à l'aide de l'accès privé à Google et de l'accès aux services privés. Pour obtenir la liste complète des services compatibles, consultez la page Options d'accès privé pour les services.
- Fonctionnalités DNS
- DNS pour l'accès au système de gestion : la résolution d'adresses globale des dispositifs de gestion VMware Engine (tels que vCenter et NSX Manager) à l'aide de Cloud DNS vous permet d'accéder aux dispositifs sans intervention de l'utilisateur.
- DNS pour les charges de travail : pour chaque cloud privé, vous choisissez la configuration DNS qui vous convient le mieux. Le service DNS NSX-T vous permet de transférer des requêtes DNS à certains serveurs DNS, de créer votre serveur DNS dans VMware Engine ou sur site, ou d'utiliser Cloud DNS ou Compute Engine.
- Serveur DHCP : le serveur DHCP est compatible avec les segments NSX-T.
- Relais DHCP : le relais DHCP permet par exemple aux organisations d'intégrer un système de gestion des adresses IP (IPAM, IP address management) sur site.
- VPN de Couche 2 de site à site et VPN de Couche 3 : ces services sont directement configurés dans NSX à l'aide du VPN de couche 2 et du VPN IPsec, respectivement.
- Équilibrage de charge : ce service utilise les fonctionnalités intégrées d'équilibrage de charge de NSX-T, qui incluent la compatibilité L4 et L7, ainsi que les vérifications d'état.
- Compatibilité avec le routage multicast IP partiel : le protocole PIM (Protocol Independent Multicast) est compatible, comme décrit dans la documentation de VMware.
- Compatibilité partielle avec IPv6 : cette fonctionnalité permet aux organisations de tirer parti du protocole IPv6 pour leurs applications compatibles avec VMware Engine, comme décrit dans le guide de conception de NSX-T 3.0.
- Migration de VM à longue distance (vMotion) : les migrations à chaud (applications toujours en cours d'exécution) et à froid (applications arrêtées) sont compatibles entre un environnement sur site et un environnement cloud, ou de cloud à cloud au sein de VMware Engine avec mobilité intégrée à la réplication, chiffrement et optimisation WAN intégrés. Cela est possible grâce à VMware HCX, inclus avec le service.
- Opérations réseau avancées : vous pouvez utiliser des outils et des instrumentations NSX intégrés, tels que la mise en miroir des ports, Traceflow, la capture de paquets et SNMP v1/v2/v3 avec interrogation et analyses, entre autres.
Réseaux et plages d'adresses
Google Cloud VMware Engine crée un réseau pour chaque région dans laquelle votre service VMware Engine est déployé. Le réseau est un espace d'adressage de Couche 3 unique avec le routage activé par défaut. Tous les clouds et sous-réseaux privés que vous créez dans cette région peuvent communiquer entre eux sans configuration supplémentaire. Vous pouvez créer des segments de réseau (sous-réseaux) à l'aide de NSX-T pour vos machines virtuelles de charge de travail. Vous pouvez configurer n'importe quelle plage d'adresses RFC 1918 qui ne chevauche pas les réseaux sur site, le réseau de gestion de votre cloud privé ni aucun sous-réseau VPC. Les adresses IP publiques utilisées en mode privé (Privately Used Public IPs ou PUPI) sont également acceptées.
Par défaut, tous les sous-réseaux peuvent communiquer entre eux, ce qui réduit la surcharge de configuration liée au routage entre les clouds privés. Le trafic de données sur des clouds privés de la même région reste sur le même réseau de couche 3 et est transféré sur l'infrastructure réseau locale de cette région. La sortie n'est donc pas nécessaire pour la communication entre ces clouds privés. Cette approche élimine les fluctuations de performances WAN ou de sortie lorsque vous déployez différentes charges de travail dans différents clouds privés.
Conceptuellement, un cloud privé est créé sous la forme d'un environnement de pile VMware isolé (hôtes ESXi, vCenter, vSAN et NSX) géré par un serveur vCenter. Les composants de gestion sont déployés sur le réseau sélectionné pour la plage CIDR des sous-réseaux vSphere/vSAN. La plage CIDR du réseau est divisée en différents sous-réseaux lors du déploiement.
Sous-réseaux de gestion dans VMware Engine
VMware Engine utilise plusieurs plages d'adresses IP. Certaines des plages d'adresses IP sont obligatoires et d'autres dépendent des services que vous prévoyez de déployer. L'espace d'adresses IP ne doit chevaucher aucun des sous-réseaux sur site, des sous-réseaux VPC ou des sous-réseaux de charges de travail planifiées. Les sections suivantes décrivent l'ensemble des plages d'adresses et les services correspondants qui utilisent ces plages.
Le schéma suivant présente les sous-réseaux de gestion des services expliqués dans les sections suivantes :
vSphere/CIDR vSAN
Les plages d'adresses IP suivantes sont nécessaires pour initialiser et créer un cloud privé :
| Nom | Description | Plage d'adresses IP |
|---|---|---|
| vSphere/CIDR vSAN | Obligatoire pour les réseaux de gestion VMware. Doit être spécifié lors de la création d'un cloud privé. Également obligatoire pour vMotion. | /21, /22, /23 ou /24 |
Lorsque vous créez un cloud privé, plusieurs sous-réseaux de gestion sont automatiquement créés. Les sous-réseaux de gestion utilisent l'allocation CIDR vSphere/vSAN requise décrite précédemment dans ce document. Voici un exemple d'architecture et de description des différents sous-réseaux créés à l'aide de cette plage CIDR :
- Gestion du système : VLAN et sous-réseau pour le serveur DNS, le serveur vCenter et le réseau de gestion des hôtes ESXi.
- VMotion : VLAN et sous-réseau pour le réseau vMotion des hôtes ESXi.
- VSAN : VLAN et sous-réseau pour le réseau vSAN des hôtes ESXi.
- NsxtEdgeUplink1 : VLAN et sous-réseau pour les liaisons montantes VLAN vers un réseau externe.
- NsxtEdgeUplink2 : VLAN et sous-réseau pour les liaisons montantes VLAN vers un réseau externe.
- NsxtEdgeTransport : VLAN et sous-réseau utilisés pour les zones de transport qui contrôlent la couverture des réseaux de couche 2 dans NSX-T.
- NsxtHostTransport : VLAN et sous-réseau pour la zone de transport de l'hôte.
Exemple :
La plage CIDR des sous-réseaux vSphere/vSAN qui est spécifiée est divisée en plusieurs sous-réseaux. Le tableau suivant fournit un exemple de répartition des préfixes autorisés (de /21 à /24) utilisant 192.168.0.0 comme plage CIDR.
| CIDR/Préfixe spécifié de sous-réseaux vSphere/vSAN | 192.168.0.0/21 |
192.168.0.0/22 |
192.168.0.0/23 |
192.168.0.0/24 |
|---|---|---|---|---|
| Gestion système | 192.168.0.0/24 |
192.168.0.0/24 |
192.168.0.0/25 |
192.168.0.0/26 |
| vMotion | 192.168.1.0/24 |
192.168.1.0/25 |
192.168.0.128/26 |
192.168.0.64/27 |
| vSAN | 192.168.2.0/24 |
192.168.1.128/25 |
192.168.0.192/26 |
192.168.0.96/27 |
| Transport d'hôte NSX-T | 192.168.4.0/23 |
192.168.2.0/24 |
192.168.1.0/25 |
192.168.0.128/26 |
| Transport edge NSX-T | 192.168.7.208/28 |
192.168.3.208/28 |
192.168.1.208/28 |
192.168.0.208/28 |
| NSX-T Edge liaison montante 1 | 192.168.7.224/28 |
192.168.3.224/28 |
192.168.1.224/28 |
192.168.0.224/28 |
| NSX-T liaison montante 2 | 192.168.7.240/28 |
192.168.3.240/28 |
192.168.1.240/28 |
192.168.0.240/28 |
Selon la plage CIDR sélectionnée, le masque de sous-réseau varie pour chaque sous-réseau. Par exemple, si vous sélectionnez la plage CIDR vSphere/vSAN /21, les sous-réseaux suivants sont créés : un sous-réseau de gestion de système /24, un sous-réseau vMotion /24, un sous-réseau VSAN /24, un sous-réseau de transport d'hôte NSX-T /23, un sous-réseau de transport Edge NSX-T /28, une liaison montante 1 NSX-T /28 et une liaison montante 2 NSX-T /28.
Plage CIDR du déploiement HCX
Les plages d'adresses IP suivantes sont requises pour HCX dans votre cloud privé :
| Nom | Description | Plage d'adresses IP |
|---|---|---|
| Plage CIDR du déploiement HCX | Obligatoire pour le déploiement de réseaux HCX. Facultatif pour la création d'un cloud privé. | /27 ou supérieur |
Plage d'adresses attribuée
Les adresses IP suivantes sont requises pour l'accès aux services privés de VMwareware Engine :
| Nom | Description | Plage d'adresses IP |
|---|---|---|
| Plage d'adresses attribuée | Plage d'adresses à utiliser pour la connexion de service privée aux services Google Cloud, y compris VMware Engine. | /24 ou supérieur |
Services Edge et sous-réseau client
Les plages d'adresses IP suivantes sont requises pour activer les services de mise en réseau Edge fournis par VMware Engine :
| Nom | Description | Plage d'adresses IP |
|---|---|---|
| Plage CIDR des services Edge | Obligatoire si les services Edge facultatifs, tels que le VPN de point à site, l'accès Internet et l'adresse IP publique, sont activés. Les plages sont déterminées par région. | /26 |
| Sous-réseau client | Obligatoire pour le VPN point à site. Les adresses DHCP sont fournies à la connexion VPN à partir du sous-réseau client. | /24 |
Options d'accès privé à Google pour les services
Google Cloud fournit plusieurs options d'accès privé pour vos charges de travail s'exécutant dans VMware Engine ou sur vos réseaux VPC Google. L'accès aux services privés fournit une connexion privée entre votre réseau VPC et le service VMware Engine. Lorsque vous utilisez l'accès privé à Google, vos charges de travail VMware peuvent accéder à d'autres API et services Google Cloud sans quitter le réseau Google Cloud.
Accès aux services privés
VMware Engine utilise l'accès aux services privés pour connecter votre réseau VPC à un réseau VPC de producteurs de services dans un dossier locataire de votre organisation Google à l'aide de l'adressage IP privé.
Pour en savoir plus sur la configuration de l'accès aux services privés, reportez-vous à la page Configurer l'accès aux services privés. L'accès aux services privés crée une connexion d'appairage de réseaux VPC. Il est donc important d'importer et d'exporter les routes.
Google et des tiers (appelés collectivement des producteurs de services) peuvent proposer des services avec des adresses IP internes hébergées sur un réseau VPC. L'accès aux services privés vous permet d'atteindre ces adresses IP internes. La connexion privée active la fonctionnalité suivante :
Les instances de VM dans votre réseau VPC et les VM VMware communiquent exclusivement à l'aide d'adresses IP internes. Les instances de VM n'ont pas besoin d'accès Internet ni d'adresses IP externes pour accéder aux services disponibles via l'accès aux services privés.
Communication entre les VM VMware et les services compatibles Google Cloud qui acceptent l'accès aux services privés à l'aide d'adresses IP internes.
Si vous disposez d'une connectivité sur site utilisant Cloud VPN ou Cloud Interconnect à votre réseau VPC, vous pouvez utiliser les connexions sur site existantes pour vous connecter à votre cloud privé VMware Engine.
Si vous utilisez un réseau VPC partagé dans votre propre projet, la plage d'adresses IP allouée et la connexion privée doivent être créées dans le projet hôte pour permettre aux instances de VM dans les projets de service d'être connectés avec l'environnement.
Vous pouvez configurer l'accès aux services privés indépendamment de la création du cloud privé VMware Engine. Vous pouvez également créer une connexion privée avant ou après la création du cloud privé auquel vous souhaitez connecter votre réseau VPC.
Par conséquent, lorsque vous configurez l'accès aux services privés, vous devez allouer une plage d'adresses IP internes, puis créer une connexion privée comme indiqué dans la section précédente. Cette plage allouée est un bloc CIDR réservé qui est utilisé pour la connexion d'accès aux services privés et ne peut pas être utilisé dans votre réseau VPC local. Cette plage est réservée aux producteurs de services, et elle empêche les chevauchements entre votre réseau VPC et celui du producteur de services. Lorsque vous créez une connexion aux services privés, vous devez spécifier une allocation. Pour en savoir plus sur le côté du producteur de services, consultez la page Activer l'accès aux services privés.
Pour éviter les chevauchements d'adresses IP, nous vous recommandons d'allouer tous les sous-réseaux VMware Engine à la connexion aux services privés. Dans la capture d'écran suivante, le bloc CIDR VMware Engine est utilisé pour la connexion aux services privés, et le bloc CIDR gcve-2 est alloué pour éviter les chevauchements d'adresses IP :
Service Networking ne recherche pas d'adresses qui se chevauchent sur les routes dynamiques reçues. Vous devez donc associer l'accès aux services privés à des préfixes réservés pour des services autres que VMware. Cela évite les problèmes liés au chevauchement d'adresses IP, car vous réservez des plages CIDR et vous ne pouvez donc pas les utiliser dans votre réseau VPC.
Lorsque vous configurez l'accès aux services privés, assurez-vous que la connexion d'appairage de VPC est correctement configurée pour importer et exporter toutes les routes de la connexion privée servicenetworking-googleapis-com. Vous devez également noter l'ID de projet appairé pour pouvoir l'utiliser lorsque vous configurez une connexion privée dans VMware Engine.
Le réseau VPC du producteur de services est automatiquement connecté au service VMware Engine, qui contient votre cloud privé (une installation à NSX-T unique et vCenter privé).
VMware Engine utilise la même connexion à plusieurs services Google Cloud provisionnés dans le réseau VPC du producteur de services qui utilisent un accès aux services privés tel que Cloud SQL, Memorystore pour Redis, Memorystore pour Memcached, AI Platform Training et des clusters privés GKE. Si vous souhaitez utiliser ces services, vous pouvez sélectionner la plage CIDR que vous avez utilisée pour établir la connexion aux services privés avec VMware Engine.
Dans le portail de services VMware Engine, lorsque l'état de la région est connecté, vous pouvez examiner la connexion privée à l'aide de son ID de projet locataire pour la région correspondante. Les détails de la connexion privée affichent les routes apprises via l'appairage de réseau VPC. Les routes exportées affichent les clouds privés appris de la région et exportés via l'appairage de VPC.
Un cloud privé représente un seul vCenter et une seule installation NSX-T avec un maximum de 64 nœuds. Vous pouvez déployer plusieurs clouds privés et, si vous atteignez la limite de 64 nœuds pour un seul cloud privé, vous pouvez créer un autre cloud privé. Cela signifie que vous gérez deux clouds privés, deux installations vCenter et deux installations NSX-T.
Selon votre cas d'utilisation, vous pouvez déployer un seul cloud privé ou déployer plusieurs clouds privés sans atteindre la limite de 64 nœuds. Par exemple, vous pouvez déployer un cloud privé avec des charges de travail de base de données et un cloud privé distinct pour un cas d'utilisation VDI, ou un cloud privé pour les charges de travail Amériques et un autre cloud privé pour les charges de travail EMEA. Vous pouvez également séparer les charges de travail dans plusieurs clusters au sein d'un même cloud privé, en fonction de votre cas d'utilisation.
Accès privé à Google
L'accès privé à Google vous permet de vous connecter aux API et services Google sans attribuer d'adresses IP externes à vos VM VMware Engine. Une fois l'accès privé à Google configuré, le trafic est acheminé vers la passerelle Internet, puis vers le service demandé sans quitter le réseau Google.
Pour en savoir plus, consultez la section Accès privé à Google : plus de détails.
Flux de trafic principaux
Cette section passe en revue certains flux de trafic clés et décrit l'architecture utilisée pour couvrir tous les différents flux de mise en réseau.
Vous trouverez ci-dessous des exemples de points à prendre en compte lors de la création d'une conception pour VMware Engine.
Connectivité utilisateur à distance et sur site VMware Engine
Vous pouvez utiliser les options suivantes pour accéder à l'environnement VMware Engine à partir d'un centre de données sur site ou d'un emplacement distant :
- Connectivité utilisateur à distance :
- Connectivité sur site :
Les passerelles VPN fournissent une connectivité sécurisée entre plusieurs sites, tels que les réseaux sur site, les réseaux VPC et les clouds privés. Ces connexions VPN chiffrées transitent par Internet et se terminent dans une passerelle VPN. Lorsque vous créez plusieurs connexions à la même passerelle VPN, tous les tunnels VPN partagent la bande passante disponible.
Les passerelles VPN de point à site permettent aux utilisateurs de se connecter à distance à VMware Engine à partir de leur ordinateur. Notez que vous ne pouvez créer qu'une seule passerelle VPN de point à site par région.
La passerelle VPN de point à site accepte les connexions TCP et UDP, et vous pouvez choisir le protocole à utiliser lorsque vous vous connectez depuis votre ordinateur. De plus, le sous-réseau client configuré est utilisé à la fois pour les clients TCP et UDP, et la plage définie par le bloc CIDR est divisée en deux sous-réseaux, un pour les clients TCP et un pour les clients UDP.
Le VPN de point à site envoie le trafic chiffré entre un réseau régional VMware Engine et un ordinateur client. Vous pouvez utiliser le VPN de point à site pour accéder à votre réseau cloud privé, y compris à votre cloud privé vCenter et à vos VM de charge de travail. Pour en savoir plus sur la configuration de la passerelle VPN de point à site, consultez la section Configurer des passerelles VPN sur le réseau VMware Engine.
Vous pouvez également utiliser Cloud VPN pour la connectivité VPN de site à site, ou Cloud Interconnect pour établir des connexions entre votre réseau sur site et votre cloud privé VMware Engine. Vous provisionnez Cloud VPN et Cloud Interconnect dans votre réseau VPC. Pour en savoir plus, consultez la documentation de Cloud VPN et de Cloud Interconnect.
Les options de connectivité VPN sont les suivantes : VPN NSX-T IPsec, VPN NSX-T de Couche 2 et VPN HCX de Couche 2, par exemple, pour configurer une extension de Couche 2. Un des cas d'utilisation du VPN NSX-T IPsec est le chiffrement de bout en bout avec la terminaison VPN directement dans votre cloud privé VMware Engine. Pour en savoir plus sur les fonctionnalités du VPN NSX-T, consultez la documentation sur le réseau privé virtuel VMware.
Nous vous recommandons de configurer l'accès aux services privés dans le réseau VPC où se trouve Cloud Router ou Cloud VPN (et où les rattachements de VLAN existent en cas d'utilisation du protocole BGP). Sinon, les routes VPC doivent être configurées. Si l'architecture contient plusieurs connexions d'appairage de VPC, gardez à l'esprit que l'appairage de VPC n'est pas transitif.
Les routes sur site annoncées via Interconnect ou VPN sont automatiquement propagées via un accès aux services privés si l'importation et l'exportation des routes sont configurées. Vous devez donc modifier manuellement les routes d'importation et d'exportation dans la connexion d'appairage de VPC.
Gardez également à l'esprit que les routes apprises via l'accès aux services privés ne sont pas automatiquement propagées aux systèmes sur site, car l'appairage de réseaux VPC n'est pas compatible avec le routage transitif. Les routes importées depuis d'autres réseaux ne sont pas automatiquement annoncées par les routeurs cloud de votre réseau VPC. Toutefois, vous pouvez utiliser des annonces de plages d'adresses IP personnalisées provenant de routeurs Cloud de votre réseau VPC pour partager des routes vers des destinations du réseau appairé. Pour les tunnels Cloud VPN utilisant un routage statique, vous devez configurer des routes statiques vers les plages de destination du réseau appairé sur votre réseau sur site.
Trafic d'entrée dans VMware Engine
Cette section décrit les options suivantes pour le trafic d'entrée dans VMware Engine :
- Trafic d'entrée utilisant le service d'adresse IP publique de VMware Engine
- Trafic d'entrée provenant de votre réseau VPC
- Trafic d'entrée provenant d'un centre de données sur site
L'option que vous sélectionnez dépend de l'emplacement dans lequel vous souhaitez appairer votre infrastructure Google Cloud avec Internet. Le schéma suivant illustre ces options de trafic d'entrée.
Les sections suivantes décrivent chaque option en détail.
Trafic d'entrée utilisant VMware Engine
Lorsque vous utilisez la passerelle Internet VMware Engine, des adresses IP publiques à la demande peuvent être créées et supprimées pour les ressources du cloud privé du portail VMware Engine. Dans ce scénario, chaque adresse IP publique correspond à une adresse IP privée, unique et configurée.
Le trafic d'entrée public peut être fourni via la passerelle d'adresse IP publique, qui est également responsable de la NAT. Ainsi, les utilisateurs provenant de l'Internet public se connectent à l'adresse IP publique de Google. L'adresse IP publique de Google est traduite en une adresse IP privée de machine virtuelle dans VMware Engine (sauvegardée par des segments NSX-T).
Lorsque vous créez des règles de pare-feu pour autoriser les connexions entrantes extérieures à une adresse IP publique exposée, les règles de pare-feu sont appliquées à une passerelle IP publique et ces règles de pare-feu doivent être provisionnées sur le portail VMware Engine.
Un routeur logique de niveau 0 est généralement utilisé pour le routage nord-sud, tel qu'une machine virtuelle connectée à Internet. Un routeur logique de niveau 1 est utilisé pour le routage est-west, et vous pouvez configurer plusieurs sous-réseaux pour le niveau 1.
Une adresse IP publique permet aux ressources Internet de communiquer en entrée avec des ressources cloud privées via une adresse IP privée. L'adresse IP privée est une machine virtuelle ou un équilibreur de charge logiciel sur votre cloud privé vCenter. L'adresse IP publique vous permet d'exposer à Internet les services qui s'exécutent sur votre cloud privé.
Une ressource qui est associée à une adresse IP publique utilise toujours l'adresse IP publique pour l'accès à Internet. Par défaut, seul l'accès Internet sortant est autorisé sur une adresse IP publique, et le trafic entrant sur cette adresse est refusé. Afin d'autoriser le trafic entrant, créez une règle de pare-feu pour l'adresse IP publique avec le port spécifique.
Les utilisateurs de votre organisation peuvent exposer et allouer des adresses IP publiques à des nœuds spécifiques dans leur cloud privé, tels que des charges de travail de VM. L'adresse IP publique ne peut être attribuée qu'à une seule adresse IP privée. L'adresse IP publique est dédiée à cette adresse IP privée jusqu'à ce que vous annuliez l'attribution. Nous vous recommandons de ne pas exposer les hôtes ESXi ni vCenter.
Si vous souhaitez allouer une adresse IP publique, vous devez indiquer un nom, un emplacement ou une région, ainsi que l'adresse locale associée.
Trafic d'entrée utilisant votre réseau VPC
Vous pouvez fournir un trafic d'entrée à VMware Engine via votre réseau VPC à l'aide de Cloud Load Balancing. Lorsque vous sélectionnez l'équilibreur de charge de votre choix en fonction des capacités dont vous avez besoin, vous pouvez créer un groupe d'instances géré (MIG, managed instance group) ou un Groupe d'instances non géré comme backend de cet équilibreur de charge pour qu'il achemine le trafic via la connexion d'appairage de VPC. Dans ce scénario, vous pouvez également utiliser un dispositif de réseau virtuel tiers provenant de Google Cloud Marketplace.
Vous pouvez combiner l'utilisation de Cloud Load Balancing et l'utilisation de votre propre adresse IP (BYOIP, Bring Your Own IP) au cas où vous souhaiteriez utiliser votre propre espace d'adresses IP public sur Google, ainsi que l'utilisation de Google Cloud Armor pour protéger vos applications et vos sites Web contre les attaques par déni de service distribué (DDoS) et les attaques Web telles que l'injection SQL ou les scripts intersites.
Trafic d'entrée utilisant votre réseau sur site
Pour fournir un trafic d'entrée sur site, nous vous recommandons d'utiliser Cloud Interconnect. Dans un cas de démonstration de faisabilité ou si vous avez un débit faible et aucune exigence de latence, vous pouvez utiliser Cloud VPN à la place.
Trafic de sortie de VMware Engine
Il existe plusieurs options pour le trafic de sortie de VMware Engine :
- Sortie via une passerelle Internet VMware Engine
- Sortie via votre réseau VPC
- Sortie via un centre de données sur site
Dans l'architecture suivante, vous pouvez voir ces options pour un flux de sortie du point de vue de VMware Engine.
Sortie publique via VMware Engine
Vous pouvez configurer l'accès Internet et les services IP publics pour vos charges de travail séparément pour chaque région. Vous pouvez diriger le trafic Internet en provenance de vos charges de travail VMware à l'aide de la périphérie Internet de Google Cloud ou d'une connexion sur site.
Le trafic d'une machine virtuelle hébergée dans un cloud privé VMware Engine destiné au réseau Internet public sort via la passerelle de niveau 0. La passerelle de niveau 0 transfère le trafic vers la passerelle Internet. La passerelle Internet effectue la traduction d'adresse de port (PAT, port address translation) source. Le service Internet est régional, ce qui signifie qu'il est activé séparément pour chaque région.
Sortie publique via votre réseau VPC
Sinon, à partir du portail de services VMware Engine, vous pouvez désactiver les services Internet et les adresses IP publiques, et fournir une sortie publique à partir de votre réseau VPC. Dans ce cas, l'accès à Internet se fait via votre réseau VPC si vous avez annoncé une route 0.0.0.0/0 par défaut.
Si vous souhaitez utiliser ce flux de paquets, désactivez l'accès Internet pour la région VMware Engine et injectez une route 0.0.0.0/0 par défaut.
Vous devez également supprimer toutes les adresses IP publiques allouées et les passerelles VPN de point à site avant de pouvoir sortir le trafic via votre réseau VPC.
La route par défaut doit être visible sur votre réseau VPC. Elle sera ensuite automatiquement appliquée à VMware Engine. L'une des conditions préalables est d'activer VPC Service Controls sur la connexion d'appairage de VPC entre votre réseau VPC et VMware Engine.
Pour effectuer une traduction d'adresse réseau (NAT), vous pouvez déployer une instance Compute Engine ou disposer d'une route 0.0.0.0/0 par défaut pointant vers un équilibreur de charge interne associé à un cluster de dispositif réseau virtuel tiers centralisé (disponible sur Cloud Marketplace) et exécuter le NAT source dans l'instance pour sortir de votre réseau VPC et accéder à l'Internet public. Pour en savoir plus, consultez la section comment utiliser des routes dans votre réseau VPC.
Sortie publique via un centre de données sur site
Vous pouvez faire passer le trafic de sortie via votre centre de données sur site si vous désactivez les services IP et Internet et fournissez une sortie publique à partir de l'environnement sur site. Dans ce cas, l'accès à Internet passe par votre réseau VPC avant d'atteindre le centre de données sur site via Cloud VPN ou Cloud Interconnect.
Pour mettre en œuvre une sortie publique via votre centre de données sur site, annoncez une route 0.0.0.0/0 par défaut, puis activez VPC Service Controls sur la connexion d'appairage afin que la route par défaut soit importée correctement, comme décrit ici.
Pour en savoir plus sur VPC Service Controls, consultez la Documentation de VPC Service Controls.
Si VPC Service Controls est désactivé sur la connexion d'appairage de VPC, l'accès Internet via une connexion sur site est également désactivé, même si une route par défaut (0.0.0.0/0) est annoncée et propagée via la connexion d'appairage de VPC.
Présentation de service : cloud privé et cloud privé
Les clouds privés sont gérés via le portail du service VMware Engine. Les clouds privés possèdent leur propre serveur vCenter, qui se trouve dans son propre domaine de gestion. La pile VMware s'exécute sur des nœuds matériels "bare metal" entièrement dédiés et isolés dans les emplacements Google Cloud. L'environnement de cloud privé est conçu pour éliminer les points de défaillance uniques.
Le schéma suivant illustre deux chemins de réseau pour la communication entre les clouds privés dans VMware Engine. Le chemin d'accès varie selon que les clouds privés se trouvent dans la même région ou dans des régions différentes :
- La communication entre deux clouds privés de la même région au sein du service VMware Engine se fait via une connectivité directe. Vous pouvez déployer plusieurs clouds privés dans la même région, afin que la communication entre ces clouds privés s'effectue localement.
- Si les clouds privés se trouvent dans des régions différentes, la connectivité passe par le réseau VPC du producteur de services, qui est géré et détenu par Google. Cela est possible à condition que le mode de routage soit défini sur "global".
Présentation de service : cloud privé et VPC
Cette section examine la connectivité entre votre réseau VPC et le cloud privé. Votre réseau VPC utilise le modèle d'accès aux services privés pour s'appairer au réseau VPC du producteur de services, puis étend la connectivité à la région VMware Engine. Le routage global est activé sur le réseau VPC du producteur de services, et tous les réseaux que vous créez dans le portail de services VMware Engine sont automatiquement annoncés par le routeur de niveau 0 dans NSX-T. Assurez-vous que l'option d'importation et d'exportation est activée sur la connexion d'appairage pour échanger des routes et pour établir une connectivité entre VMware Engine et votre VPC.
Le schéma suivant illustre le flux de trafic dans ce cas.
Présentation de service : cloud privé et VPC partagé
Lorsque vous utilisez un réseau VPC partagé, la connectivité est semblable à l'exemple précédent de connexion d'un cloud privé à un réseau VPC. La différence est la suivante : lorsque vous connectez un cloud privé à un réseau VPC partagé, les charges de travail résident dans le projet de service et elles utilisent l'espace d'adressage IP du réseau VPC partagé du projet hôte. De ce fait, vous devez configurer l'accès aux services privés dans le projet hôte où le réseau VPC partagé et Interconnect ou le VPN sont configurés.
Par exemple, si vous souhaitez disposer du cloud privé, d'IAM et de la facturation dans un projet de service, assurez-vous que la connexion d'accès aux services privés est établie dans le réseau VPC partagé du projet hôte.
Présentation de service : cloud privé et environnement sur site
Dans le cas d'une connectivité entre un cloud privé et un environnement sur site, vous disposez d'un réseau VPC dans votre projet et votre organisation, et la connectivité se fait entre le cloud privé et le centre de données sur site.
Comme mentionné précédemment, lorsque vous configurez VMware Engine, vous devez allouer un sous-réseau (et, dans l'idéal, les sous-réseaux de VMware Engine pour éviter tout conflit futur) pour la connexion d'accès aux services privés. Lors de l'allocation de ce sous-réseau, vous créez un réseau VPC de producteur de services qui les connecte à la région VMware Engine où le cloud privé existe.
Une fois la connexion d'appairage de VPC créée et provisionnée, le réseau VPC du producteur de services est connecté à votre réseau VPC. Ainsi, tous les sous-réseaux et les adresses IP de votre réseau VPC sont accessibles depuis le cloud privé. Veillez à activer l'importation et l'exportation de routes dans la connexion d'appairage de VPC lorsque vous configurez l'accès aux services privés.
Le schéma suivant illustre la connectivité de bout en bout entre un cloud privé dans VMware Engine et un centre de données sur site.
Accès privé à Google : plus de détails
Comme mentionné précédemment, vous pouvez utiliser l'accès privé à Google pour vous connecter aux API et services Google sans attribuer d'adresse IP externe à vos ressources Google Cloud, afin que le service VMware Engine puisse en bénéficier et utiliser la passerelle Internet pour d'accéder aux API Google.
Les instances de VM qui ne possèdent que des adresses IP internes peuvent profiter de l'accès privé à Google pour accéder aux adresses IP externes des API et services Google. Lorsque l'accès privé à Google est configuré, le trafic est acheminé vers la passerelle Internet, puis vers le service demandé.
Pour activer l'accès privé à Google pour VMware Engine, vous devez configurer votre serveur DNS dans votre environnement VMware Engine de sorte qu'il utilise l'adresse IP virtuelle privée. Pour en savoir plus, consultez les pages Accès privé à Google pour les hôtes sur site et Configurer l'accès privé à Google pour les hôtes sur site.
Le domaine private.googleapis.com utilise 199.36.153.8/30.
Pour gérer la résolution DNS, vous pouvez utiliser le service DNS fourni par NSX-T pour transférer les requêtes vers un serveur DNS spécifié. Le serveur DNS peut être une VM dans VMware Engine, Cloud DNS ou un serveur DNS sur site. Selon votre mode d'accès à Internet, comme décrit dans une section précédente, l'une de ces options sera utilisée.
L'accès privé à Google est compatible avec la plupart des API et services Google, tels que Cloud Storage, Cloud Spanner et BigQuery. L'accès privé à Google n'est pas compatible avec App Engine, Memorystore ou Filestore. Pour en savoir plus sur les options d'accès privé, consultez la section Options d'accès privé pour les services.
Voici des exemples d'utilisation de VMware Engine avec les services Google Cloud :
- Accéder à Cloud Storage à partir de VM VMware afin d'exporter des données ou en tant que cible de stockage étendue.
- Surveiller toutes vos applications publiques, privées et hybrides à l'aide de Cloud Monitoring.
- Importer des données depuis des bases de données dans BigQuery à des fins d'analyse.
- Déployer Anthos pour des déploiements d'applications conteneurisées de haute performance et privés.
Le schéma suivant illustre deux chemins d'accès réseau pour la communication avec les API et les services Google. La configuration de l'accès privé à Google dépend de l'accès Internet activé pour VMware Engine :
- Si l'accès à Internet est fourni via VMware Engine et activé pour la région, l'accès privé à Google et l'accès à Internet utilisent la passerelle Internet.
- Si vous fournissez un accès Internet (en annonçant une route
0.0.0.0/0) depuis un réseau sur site ou via votre réseau VPC, la communication utilise la passerelle Internet du réseau VPC du producteur de services. L'accès via le service Internet VMware Engine est ignoré.
Option 1 : Accès privé à Google avec accès Internet fourni par VMware Engine
Si vous fournissez un accès Internet via VMware Engine pour une région, l'accès privé à Google et Internet utilisent la passerelle Internet et exécutent le PAT. Dans ce cas, vous n'avez besoin d'aucune configuration supplémentaire, à l'exception de la résolution DNS pour l'accès privé à Google.
Option 2 : Accès privé à Google avec accès Internet fourni par le VPC client ou sur site
Si vous fournissez un accès Internet via un réseau sur site ou via votre réseau VPC, vous devez configurer le service VMware Engine pour acheminer les paquets vers les API Google via la passerelle Internet du réseau VPC locataire de l'organisation. Vous devez configurer le service VMware Engine pour acheminer les paquets des autres trafics via votre réseau VPC afin d'atteindre les connexions sur site via VPN ou Interconnect ou via votre réseau VPC.
Pour tout le trafic, désactivez l'accès Internet et les services IP publics pour la région VMware Engine et injectez une route 0.0.0.0/0 par défaut via l'environnement sur site.
Si vous fournissez un accès Internet via un réseau sur site ou via votre réseau VPC, supprimez toutes les adresses IP publiques allouées et les passerelles VPN de point à site avant de désactiver le service IP public. Assurez-vous que la route est visible dans votre réseau VPC et que la route est exportée vers le réseau VPC locataire.
En outre, vous devez activer VPC Service Controls sur la connexion d'appairage de VPC entre votre réseau VPC et VMware Engine.
Enfin, l'accès aux API Google utilise l'adresse IP virtuelle limitée. Le DNS doit donc être configuré en conséquence avec les enregistrements A et CNAME requis. L'accès aux API Google s'effectue via l'organisation Google, et non via votre réseau VPC.
Cloud privé et services pour les partenaires gérés
Les services pour les partenaires gérés (MPS, Managed Partner Services) vous permettent de proposer aux clients de Google Cloud des offres SaaS (Software as a Service) critiques à partir du matériel et des logiciels que vous hébergez dans une installation hébergée en colocation de MPS.
Pour le flux de trafic entre un cloud privé et des MPS, VMware Engine utilise la connectivité multi-VPC. Cette fonctionnalité vous permet d'établir une connectivité non seulement avec des réseaux VPC de clients de services supplémentaires, mais également avec les MPS de Google. Le schéma suivant est une version simplifiée de la connectivité entre un cloud privé et des MPS, ainsi que des réseaux VPC grand public supplémentaires.
Autres ressources : VMware
Pour en savoir plus sur la pile VMware, consultez la section Versions des composants VMware et le guide de conception de NSX 3.0.