Migrer vers une plate-forme Google Cloud VMware Engine

Last reviewed 2024-09-17 UTC

De nombreuses entreprises souhaitent migrer leurs clusters VMware vers le cloud pour profiter de sa scalabilité, de sa résilience, de son élasticité et des services de niveau supérieur tels que Vertex AI Studio et BigQuery. Les entreprises souhaitent également passer d'un modèle matériel à forte intensité capitalistique à un modèle de dépenses opérationnelles plus flexible. Pour aider les entreprises à créer rapidement un environnement opérationnel conforme aux bonnes pratiques Google Cloud, nous avons créé le plan d'entreprise Google Cloud VMware Engine. Ce modèle vous fournit un guide complet sur le déploiement d'un environnement VMware prêt à l'entreprise afin que vous puissiez migrer vos charges de travail VM vers le cloud.

VMware Engine est un service entièrement géré qui vous permet d'exécuter la plate-forme VMware sur Google Cloud. Vos charges de travail VMware s'exécutent sur du matériel Google Cloud dédié, entièrement intégré aux services Google Cloud. Google s'occupe de l'infrastructure, de la mise en réseau et de la gestion. Le blueprint vous permet de déployer un projet Google Cloud contenant un cloud privé VMware Engine, un réseau VMware Engine géré par Google et les connexions d'appairage de réseau VPC qui permettent le flux de trafic de bout en bout.

Le plan d'entreprise VMware Engine comprend les éléments suivants:

  • Dépôts GitHub contenant le code Terraform et les scripts auxiliaires nécessaires pour déployer la plate-forme VMware Engine
  • Un guide des contrôles d'architecture, de mise en réseau et de sécurité que vous utilisez pour mettre en œuvre les dépôts GitHub (ce document)

Le plan est conçu pour s'exécuter sur une base de services de base, tels que les réseaux VPC. Vous pouvez utiliser le plan de base de l'entreprise ou Fabric FAST pour créer la base de ce plan.

Ce document est destiné aux architectes cloud, aux administrateurs de plates-formes cloud, aux administrateurs VMware Engine et aux ingénieurs VMware Engine qui peuvent utiliser le plan pour créer et déployer des clusters VMware sur Google Cloud. Ce modèle se concentre sur la conception et le déploiement d'un nouveau cloud privé VMware Engine et suppose que vous connaissez VMware et le service géré VMware Engine.

Présentation du plan d'entreprise VMware Engine

Le modèle d'entreprise VMware Engine repose sur une approche en couches pour activer la plate-forme VMware Engine. Le schéma suivant montre l'interaction des différents composants de ce plan avec d'autres plans et services.

Couches et composants du plan

Ce schéma comprend les éléments suivants :

  • L'infrastructure Google Cloud vous fournit des fonctionnalités de sécurité telles que le chiffrement au repos et le chiffrement en transit, ainsi que des éléments de base tels que le calcul et le stockage.
  • La base de l'entreprise vous fournit une référence de ressources telles que la mise en réseau, l'identité, les règles, la surveillance et la journalisation. Ces ressources vous permettent d'adopter rapidement Google Cloud tout en répondant aux exigences architecturales de votre organisation.
  • Le plan d'entreprise VMware Engine vous offre les avantages suivants:

  • L'automatisation du déploiement à l'aide d'un pipeline CI/CD vous fournit les outils nécessaires pour automatiser le provisionnement, la configuration et la gestion de l'infrastructure. L'automatisation vous aide à garantir des déploiements cohérents, fiables et contrôlables, à limiter les erreurs manuelles et à accélérer le cycle de développement global.

Architecture

Le schéma suivant illustre l'architecture déployée par le plan d'entreprise VMware Engine.

Architecture du plan

Le plan déploie les éléments suivants:

  • Un projet Google Cloud appelé projet VMware Engine autonome contenant un cloud privé VMware Engine
  • Un projet géré par Google pour le réseau VMware Engine
  • Les connexions d'appairage de réseaux VPC afin que le trafic puisse circuler des applications VMware Engine vers les clients

Le cloud privé VMware Engine se compose des composants suivants:

  • Outils de gestion:VLAN et sous-réseau pour le réseau de gestion des hôtes ESXi, le serveur DNS et le serveur vCenter
  • Sauvegarde:infrastructure de sauvegarde pour les VM de charge de travail
  • Machines virtuelles:VM de charge de travail
  • vCenter Server:gestion centralisée de l'environnement vSphere du cloud privé
  • NSX Manager:fournit une interface unique pour configurer, surveiller et gérer les services de mise en réseau et de sécurité NSX-T.
  • Hôtes ESXi:hyperviseur sur des nœuds dédiés
  • Stockage vSAN:plate-forme de stockage définie par logiciel et hyperconvergée
  • Réseau en superposition NSX-T:logiciel de virtualisation et de sécurité du réseau
  • VMware HCX : migration d'applications et rééquilibrage des charges de travail entre les centres de données et les clouds

Présentation de la mise en réseau VMware Engine

Le réseau VMware Engine est un réseau dédié qui connecte le cloud privé VMware Engine, les réseaux VPC et les environnements sur site. Le réseau VMware Engine présente les fonctionnalités suivantes:

  • Connectivité cloud privé:chaque cloud privé VMware Engine est connecté à un réseau VMware Engine, ce qui permet la communication entre les charges de travail dans le cloud privé.
  • Connectivité réseau VMware Engine:vous pouvez utiliser l'appairage de réseaux VPC pour établir une connectivité entre les réseaux VMware Engine et un VPC Google. Cette connectivité permet la communication entre les charges de travail exécutées sur VMware Engine et celles exécutées sur d'autres services de Google Cloud.
  • Connectivité sur site:pour créer une solution cloud hybride, vous pouvez étendre les réseaux VMware Engine aux centres de données sur site à l'aide de Cloud VPN ou Cloud Interconnect.
  • Services réseau:les réseaux VMware Engine utilisent divers services réseau, y compris les suivants :
    • Cloud DNS pour la résolution de nom des ressources internes et externes
    • Cloud NAT pour l'accès à Internet pour les charges de travail cloud privées
    • Appairage de réseaux VPC pour la connectivité réseau à d'autres VPC et d'autres réseaux VMware Engine
    • Connectivité privée aux API et services Google Cloud

Avec VMware Engine, vous êtes responsable de la création et de la gestion des VM de charge de travail à l'aide de la surface de gestion des applications VMware. Google Cloud est responsable de la mise à jour et du correctif des composants de l'infrastructure, ainsi que de la résolution des problèmes des composants défaillants.

Principales décisions en termes d'architecture

Zone de décision Décision Raisonnement décisionnel
Fondation Vous pouvez implémenter le plan de base d'entreprise VMware Engine sur le plan de base d'entreprise, Fabric FAST, ou sur une base qui répond aux conditions préalables définies. Le plan de base de l'entreprise et Fabric FAST fournissent les fonctionnalités de base qui aident les entreprises à adopter Google Cloud.
Calcul Vous pouvez déployer un seul cluster privé dans une région spécifique ou deux clusters privés dans deux régions. La configuration d'un seul cluster privé permet de simplifier la gestion et d'optimiser les coûts.
Le plan de déploiement déploie un nœud de réserve. Un seul nœud de réserve vous permet de gérer les défaillances, les événements de maintenance et les fluctuations de charge de travail tout en minimisant les coûts.
La sauvegarde et la reprise après sinistre sont gérées à l'aide du service de sauvegarde et de reprise après sinistre. Backup and DR vous permet d'utiliser un service géré et de réduire la quantité d'administration requise pour un déploiement VMware Engine.
Mise en réseau Le plan de mise en réseau permet la connectivité hybride. La connectivité hybride vous permet de connecter votre environnement sur site à votre environnement Google Cloud.
Le cloud privé utilise un espace IP privé, routable et contigu. Un espace IP contigu facilite la gestion des adresses IP. Lorsque l'espace IP est routable, le cloud privé peut communiquer avec vos ressources sur site.
L'accès à Internet est fourni via Cloud Load Balancing et est protégé par Google Cloud Armor. Google Cloud Armor améliore la posture de sécurité des charges de travail, tandis que Cloud Load Balancing permet de les faire évoluer et de les rendre haute disponibilité.
Le plan active Cloud DNS. Cloud DNS résout les noms internes et externes.

Personas de la plate-forme

Le plan utilise deux groupes d'utilisateurs : un groupe d'ingénieurs de la plate-forme cloud et un groupe d'ingénieurs de la plate-forme VMware. Ces groupes assument les responsabilités suivantes:

  • Le groupe d'ingénieurs de la plate-forme cloud est responsable du déploiement de la base du modèle VMware Engine et du déploiement du modèle.
  • Le groupe d'ingénierie de la plate-forme VMware est responsable de la configuration et du fonctionnement des composants VMware qui font partie du cloud privé.

Si vous déployez le plan sur le plan de base d'entreprise ou Fabric FAST, le groupe d'ingénierie de la plate-forme cloud est créé dans le cadre du processus de déploiement initial. Le groupe d'ingénierie de la plate-forme VMware est déployé dans le cadre de ce plan.

Structure organisationnelle

Le plan d'entreprise VMware Engine s'appuie sur la structure organisationnelle existante du plan de base de l'entreprise et de Fabric FAST. Il ajoute un projet VMware Engine autonome dans les environnements de production, hors production et de développement. Le schéma suivant montre la structure du modèle.

Hiérarchie de l'organisation pour le plan.

Mise en réseau

Le plan d'entreprise VMware Engine vous offre les options de mise en réseau suivantes:

  • Un seul réseau VPC partagé pour un cloud privé VMware Engine
  • Deux instances de VPC partagé pour un cloud privé

Les deux options sont déployées dans une seule région et vous permettent de gérer le trafic depuis votre environnement sur site.

Le schéma suivant montre un seul réseau VPC partagé pour une seule région.

Mise en réseau avec un seul réseau VPC partagé

Les instances VPC partagées distinctes vous permettent de regrouper les coûts et le trafic réseau dans des unités commerciales distinctes, tout en conservant une séparation logique dans le cloud privé VMware Engine. Le schéma suivant montre plusieurs réseaux VPC partagés dans une même région.

Mise en réseau avec plusieurs réseaux VPC partagés

Réseau cloud privé

Dans le cloud privé, la mise en réseau est assurée par NSX-T, qui fournit une couche réseau définie par logiciel avec des fonctionnalités avancées telles que la microsegmentation, le routage et l'équilibrage de charge. Le modèle VMware Engine crée un réseau pour votre service VMware Engine. Ce réseau est un espace d'adressage de couche 3 unique. Le routage est activé par défaut, ce qui permet à tous les clouds et sous-réseaux privés de la région de communiquer sans configuration supplémentaire. Comme illustré dans le diagramme suivant, lorsqu'un cloud privé est créé, plusieurs sous-réseaux sont créés, composés de sous-réseaux de gestion, de sous-réseaux de services, de sous-réseaux de charges de travail et de sous-réseaux de services de bord.

Réseau cloud privé pour ce modèle.

Lorsque vous configurez votre cloud privé, vous devez sélectionner une plage CIDR qui ne chevauche pas d'autres réseaux de votre cloud privé, réseau sur site, réseau de gestion de votre cloud privé ou plages d'adresses IP de sous-réseau de votre réseau VPC. Une fois que vous avez sélectionné une plage CIDR, VMware Engine alloue automatiquement des adresses IP pour différents sous-réseaux. À l'aide d'un exemple de plage CIDR 10.0.0.0/24, le tableau suivant présente les plages d'adresses IP du modèle pour ses sous-réseaux de gestion.

Sous-réseau Description Plage d'adresses IP
Gestion système VLAN et sous-réseau pour le réseau de gestion, le serveur DNS et le serveur vCenter des hôtes ESXi 10.0.0.0/26
VMotion VLAN et sous-réseau pour le réseau vMotion des hôtes ESXi 10.0.0.64/28
Liaison montante HCX Liaison montante pour les dispositifs HCX IX (mobilité) et NE (extension) afin qu'ils atteignent leurs homologues et permettent de créer le maillage de services HCX 10.0.0.216/29

Les VM de charge de travail sont contenues dans le sous-réseau NSX-T. Les liaisons montantes de bord NSX-T fournissent une connectivité externe. La taille de la plage CIDR de votre cloud privé définit le nombre de nœuds ESXi pouvant être pris en charge dans le sous-réseau NSX-T. Les nœuds ESXi utilisent le sous-réseau VSAN pour le transport de stockage.

Le tableau suivant présente les plages d'adresses IP du sous-réseau de transport d'hôte NSX-T, des sous-réseaux de liaison montante Edge NSX-T et des sous-réseaux VSAN, en fonction d'une plage CIDR 10.0.0.0/24.

Sous-réseau Description Plage d'adresses IP
VSAN Le sous-réseau VSAN est responsable du trafic de stockage entre les hôtes ESXi et les clusters de stockage VSAN. 10.0.0.80/28
Transport d'hôte NSX-T VLAN et sous-réseau de la zone d'hôte ESXi responsable de la connectivité réseau, permettant le pare-feu, le routage, l'équilibrage de charge et d'autres services réseau. 10.0.0.128/27
NSX-T edge uplink-N [N=1-4] L'uplink de bord NSX-T permet aux systèmes externes d'accéder aux services et aux applications exécutés sur le réseau NSX-T.
  • 10.0.0.160/29
  • 10.0.0.168/29
  • 10.0.0.176/29
  • 10.0.0.184/29

Pour les sous-réseaux de service et le sous-réseau de service Edge, VMware Engine n'alloue pas de plage ni de préfixe CIDR. Par conséquent, vous devez spécifier un préfixe et une plage CIDR sans chevauchement. Le tableau suivant présente les blocs CIDR du modèle pour les sous-réseaux de service et le sous-réseau de service de bord.

Sous-réseau Description Plage d'adresses IP
Service-N [N=1-5] Les sous-réseaux de service permettent aux machines virtuelles de contourner le transport NSX et de communiquer directement avec la mise en réseau Google Cloud pour permettre des communications haut débit.
  • 10.0.2.0/24
  • 10.0.3.0/24
  • 10.0.4.0/24
  • 10.0.5.0/24
Service Edge Obligatoire si les services Edge facultatifs, tels que le VPN de point à site, l'accès Internet et l'adresse IP externe, sont activés. Les plages sont déterminées pour chaque région. 10.0.1.0/26

Routage

À l'exception des réseaux étendus à partir de votre réseau sur site ou d'autres clouds privés VMware Engine, toutes les communications au sein de VMware Engine et vers des adresses IP externes sont routées (via la couche 3) par défaut. Le blueprint configure Cloud Router associé à la connexion hybride sur site (à l'aide de Cloud VPN ou Cloud Interconnect) avec des routes annoncées personnalisées récapitulatives pour les plages d'adresses IP VMware Engine. Les routes de segment NSX sont résumées au niveau du niveau 0. Le blueprint active les services DHCP via le relais DHCP NSX-T pour les services DHCP configurés dans le cloud privé VMware Engine.

Configuration DNS

VMware Engine vous permet d'utiliser une zone Cloud DNS dans votre projet en tant que point de terminaison de résolution DNS unique pour tous les dispositifs de gestion connectés dans un réseau VPC appairé. Vous pouvez le faire même si vos clouds privés sont déployés dans différentes régions.

Lorsque vous configurez la résolution d'adresses pour plusieurs clouds privés ou un seul, vous pouvez configurer la résolution d'adresse globale à l'aide de Cloud DNS.

Par défaut, vous pouvez résoudre la zone de gestion à partir de n'importe lequel de vos réseaux VPC pour lesquels Cloud DNS est activé.

Lorsque le modèle crée un cloud privé associé à un réseau VMware Engine standard, une zone DNS de gestion associée est créée et renseignée automatiquement avec les entrées des dispositifs de gestion.

Si le réseau VMware Engine standard est un réseau VPC associé à un VPC ou à un autre réseau VMware Engine, le blueprint crée automatiquement une liaison de zone DNS de gestion. Cette liaison de zone garantit la résolution des appareils de gestion à partir de vos VM Google Cloud sur ce réseau. Le schéma suivant illustre la topologie Cloud DNS.

Configuration DNS dans le plan.

Trafic sortant de VMware Engine vers Internet

Le blueprint vous propose les trois options suivantes pour le trafic sortant de VMware Engine vers Internet:

  1. Sortante via l'environnement sur site du client
  2. Trafic sortant via la passerelle Internet VMware Engine
  3. Sortant via le VPC associé au client à l'aide d'une adresse IP externe

Le schéma suivant illustre ces options.

Options de trafic sortant pour VMware Engine

Trafic entrant depuis Internet vers VMware Engine

Le blueprint vous propose les trois options suivantes pour le trafic provenant d'Internet vers VMware Engine:

  1. Trafic entrant via l'environnement sur site du client
  2. Trafic entrant via un VPC client avec Cloud Load Balancing et potentiellement Google Cloud Armor
  3. Trafic entrant via VMware Engine à l'aide d'une adresse IP externe

Le schéma suivant illustre ces options.

Options de trafic entrant pour VMware Engine

Journalisation

Le blueprint vous permet d'envoyer les actions administratives VMware Engine vers Cloud Audit Logging à l'aide d'un sink de journal. En analysant les journaux d'audit de VMware Engine, les administrateurs peuvent identifier les comportements suspects, examiner les incidents et démontrer la conformité aux exigences réglementaires.

Les exportations de journaux peuvent également servir de sources d'ingestion pour les systèmes de gestion des informations et des événements de sécurité (SIEM). Google est compatible avec les sources d'ingestion suivantes qui servent VMware Engine:

  • L'organisation Google Cloud qui héberge la plate-forme cloud et la télémétrie des composants
  • Composants de service VMware
  • Charges de travail exécutées dans VMware Engine

Google SecOps inclut un pipeline d'ingestion de journaux automatisé intégré pour l'ingestion des données de l'organisation, et fournit des systèmes de transfert pour transférer la télémétrie en streaming à partir de VMware Engine et des charges de travail vers le pipeline d'ingestion Google SecOps. Google SecOps enrichit la télémétrie avec du contenu contextuel et la rend consultable. Vous pouvez utiliser Google SecOps pour identifier et suivre les problèmes de sécurité à mesure qu'ils se développent.

Surveillance

Le blueprint installe un agent autonome pour Cloud Monitoring afin de transférer les métriques de votre cloud privé vers Cloud Monitoring. Le modèle configure des tableaux de bord prédéfinis qui fournissent un aperçu de vos ressources VMware Engine et de leur utilisation. Dans VMware vCenter Server, VMware fournit des outils pour vous aider à surveiller votre environnement et à identifier la source des problèmes. Vous pouvez utiliser ces outils dans le cadre de vos opérations en cours et en complément d'autres options de surveillance.

Comme illustré dans le diagramme suivant, le blueprint automatise le déploiement de l'agent autonome à l'aide d'un groupe d'instances géré déployé dans le VPC du client. L'agent collecte les métriques et les journaux syslog de VMware vCenter, puis les transfère à Cloud Monitoring et à Cloud Logging.

Surveillance du plan

Sauvegardes

Le blueprint utilise Backup and DR pour fournir des services de protection des données à vos charges de travail VMware. Le service utilise un appareil géré déployé dans le VPC du client. L'appliance est connectée au plan de contrôle Google via l'accès privé à Google et les websockets. Les sauvegardes sont stockées dans Cloud Storage. Le service propose des options de récupération précises, qui vous permettent de restaurer des fichiers individuels ou des VM entières à un moment spécifique.

Bonnes pratiques opérationnelles

Cette section décrit certaines des bonnes pratiques que vous pouvez implémenter, en fonction de votre environnement et de vos exigences, après avoir déployé le plan.

Ajouter des nœuds de réserve

Les clusters VMware Engine sont dimensionnés automatiquement de manière à disposer d'au moins un nœud de secours pour la résilience. Un nœud de réserve est un comportement inhérent à vSphere HA, ce qui signifie que ce nœud est disponible dans le cluster et facturé en conséquence.

Vous pouvez ajouter des nœuds de réserve au cluster pour garantir la capacité pendant les périodes de maintenance. Cette décision peut entraîner des coûts de consommation supplémentaires, et ces nœuds sont gérés directement par votre organisation.

Les nœuds de réserve que vous ajoutez apparaissent comme des nœuds supplémentaires dans votre cluster vSphere. Vous pouvez également planifier des charges de travail sur les nœuds de réserve.

Tenir compte des limites de ressources pour les clouds privés

Les clouds privés VMware Engine sont soumis à des limites de ressources pour les composants de calcul, de stockage et de mise en réseau. Tenez compte de ces limites lors de votre déploiement de cloud privé afin que votre environnement puisse évoluer en fonction des exigences de votre charge de travail.

Implémenter des options de gestion des coûts

Vous pouvez mettre en œuvre une ou plusieurs des options suivantes pour gérer vos coûts:

  • Remises sur engagement d'utilisation
  • Autoscaling
  • Limites du nombre de cœurs
  • Surabonnement de la capacité de calcul

Utiliser des remises sur engagement d'utilisation

Les remises sur engagement d'utilisation vous permettent de bénéficier de prix réduits en échange de votre engagement à utiliser un niveau minimal de ressources pendant une période spécifiée. Les remises sur engagement d'utilisation pour VMware Engine s'appliquent automatiquement à l'utilisation agrégée des nœuds VMware Engine dans une région, ce qui vous permet de bénéficier de coûts réduits et prévisibles, sans avoir à effectuer de modifications ou de mises à jour manuelles. Les remises s'appliquent à l'utilisation des nœuds VMware Engine dans les régions où le service est disponible et où vous avez acheté les CUD.

Utiliser l'autoscaling

VMware Engine vous permet d'ajouter ou de supprimer automatiquement des nœuds dans un cluster en fonction de seuils et de repères prédéfinis. Ces règles sont déclenchées si une condition spécifiée est maintenue pendant au moins 30 minutes. Lorsque vous appliquez ou mettez à jour une règle d'autoscaling à un cluster vSphere (standard ou étendu), tenez compte des points suivants:

  • L'autoscaling est désactivé par défaut. Vous devez l'activer explicitement pour chaque cluster.
  • Dans un cluster étendu, le nombre de nœuds que vous spécifiez dans la règle est ajouté ou supprimé par zone, ce qui a un impact sur la facturation.
  • Comme l'utilisation des ressources de calcul, de la mémoire et du stockage est souvent indépendante, les règles d'autoscaling qui surveillent plusieurs métriques utilisent la logique OU pour l'ajout de nœuds et la logique ET pour la suppression des nœuds.
  • Les valeurs maximales d'autoscaling sont déterminées par les quotas disponibles dans votre projet Google Cloud et dans le cloud privé VMware Engine.
  • L'activation de l'autoscaling et l'ajout ou la suppression manuels d'un nœud ne sont pas mutuellement exclusifs. Par exemple, avec la règle d'optimisation de la capacité de stockage, vous pouvez supprimer manuellement un nœud si vous pouvez réduire suffisamment l'espace disque de la VM pour accueillir toutes les VM du cluster. Bien qu'il soit possible de supprimer manuellement des nœuds, il n'est pas recommandé de le faire lorsque vous utilisez l'autoscaling.

Limiter le nombre de cœurs

VMware Engine permet aux administrateurs de réduire le nombre de cœurs de processeur effectifs exposés à l'OS invité (qui est la VM exécutée sur VMware Engine). Certains contrats de licence logicielle vous obligent à réduire le nombre de cœurs exposés.

Sursouscrire la capacité de calcul VMware Engine

L'abonnement excessif à la capacité de calcul VMware Engine est une pratique standard et, contrairement aux nœuds à locataire unique Compute Engine, n'entraîne pas de frais supplémentaires. Un ratio de surabonnement plus élevé peut vous aider à réduire le nombre de nœuds facturables effectifs dans votre environnement, mais peut affecter les performances de l'application. Lorsque vous dimensionnez des charges de travail d'entreprise, nous vous recommandons de commencer par un ratio de 4:1, puis de le modifier en fonction des facteurs applicables à votre cas d'utilisation.

Déployer le plan

Vous pouvez déployer le plan sur le plan de base d'entreprise ou sur Fabric FAST.

Pour déployer le plan sur le plan de base de l'entreprise, procédez comme suit:

Pour déployer le blueprint sur Fabric FAST, consultez le dépôt Fabric FAST. La plate-forme Google Cloud VMware Engine déploie le modèle d'entreprise VMware Engine.

Déployer le plan sans le plan de base d'entreprise ni Fabric FAST

Pour déployer le plan sans déployer d'abord le plan de base d'entreprise ou Fabric FAST, vérifiez que les ressources suivantes existent dans votre environnement:

  • Hiérarchie d'organisation avec des dossiers development, nonproduction et production
  • Un réseau VPC partagé pour chaque dossier
  • Un schéma d'adresses IP tenant compte des plages d'adresses IP requises pour vos clouds privés VMware Engine
  • Un mécanisme DNS pour vos clouds privés VMware Engine
  • Des stratégies de pare-feu alignées sur votre stratégie de sécurité
  • Un mécanisme permettant d'accéder aux API Google Cloud via des adresses IP internes
  • Un mécanisme de connectivité avec votre environnement sur site
  • Journalisation centralisée pour la sécurité et l'audit
  • Des stratégies organisationnelles alignées sur votre stratégie de sécurité
  • Un pipeline que vous pouvez utiliser pour déployer VMware Engine

Étape suivante