Composants VMware du cloud privé
Un cloud privé est un environnement isolé de la pile VMware (hôtes ESXi, vCenter, vSAN et NSX) géré par un serveur vCenter dans un domaine de gestion. Google Cloud VMware Engine déploie des clouds privés avec les composants de pile VMware suivants :
- VMware ESXi : hyperviseur sur des nœuds dédiés
- VMware vCenter : gestion centralisée de l'environnement cloud privé vSphere
- VMware vSAN : plate-forme de stockage définie par logiciel et hyperconvergée
- Centre de données VMware NSX : virtualisation des réseaux et logiciels de sécurité
- VMware HCX : migration d'applications et rééquilibrage des charges de travail entre les centres de données et les clouds
Vous pouvez récupérer les identifiants de connexion générés pour les composants de la pile VMware sur la page d'informations du cloud privé.
Versions des composants VMware
Une pile de cloud privé VMware dispose des versions de logiciels ci-dessous :
| Composant | Version | Version sous licence |
|---|---|---|
| ESXi | 7.0, mise à jour 2c | vSphere Enterprise Plus |
| vCenter | 7.0, mise à jour 2d | vCenter Standard |
| vSAN | 7.0, mise à jour 2c | Avancé + certaines fonctionnalités de vSAN Enterprise |
| NSX Data Center | 3.1.2 | Sélectionner les fonctionnalités disponibles. Pour plus d'informations, consultez la section Centre de données NSX. |
| HCX | 4.5 | Enterprise |
ESXi
Lorsque vous créez un cloud privé, VMware ESXi est installé sur des nœuds Google Cloud VMware Engine provisionnés. ESXi fournit l'hyperviseur pour le déploiement de machines virtuelles (VM) de charge de travail. Les nœuds fournissent une infrastructure hyperconvergée (calcul et stockage) et font partie du cluster vSphere dans votre cloud privé.
Chaque nœud possède quatre interfaces réseau physiques connectées au réseau sous-jacent. VMware Engine crée un commutateur VDS (vSphere Distributed Switch) sur vCenter en utilisant ces interfaces réseau physiques en tant que liaisons montantes. Les interfaces réseau sont configurées en mode actif pour une haute disponibilité.
vCenter Server Appliance
vCenter Server Appliance (VCSA) fournit les fonctions d'authentification, de gestion et d'orchestration de VMware Engine. Lorsque vous créez et déployez votre cloud privé, VMware Engine déploie un VCSA avec un contrôleur de services de plate-forme (PSC) intégré au cluster vSphere. Chaque cloud privé possède son propre VCSA. Lorsque vous ajoutez des nœuds à un cloud privé, des nœuds sont ajoutés au VCSA.
Authentification unique vCenter
Le contrôleur de services de plate-forme intégré au VCSA est associé à une authentification unique vCenter. Le nom de domaine est gve.local. Pour accéder à vCenter, utilisez l'utilisateur par défaut, CloudOwner@gve.local, qui est créé pour vous permettre d'accéder à vCenter. Vous pouvez ajouter vos sources d'identité pour vCenter sur site/Active Directory.
Stockage vSAN
Les clusters des clouds privés disposent d'un stockage vSAN entièrement configuré. Le stockage 100 % Flash est fourni par des disques SSD locaux. Pour créer un cluster vSphere avec un datastore vSAN, au moins trois nœuds du même SKU sont requis. Chaque nœud du cluster vSphere possède deux groupes de disques. Chaque groupe de disques contient un disque de cache et trois disques de capacité.
Vous pouvez activer [la déduplication et la compression]la compression de déduplication vmware sur le datastore vSAN dans VMware Engine.Ce service active la compression vSAN par défaut lorsqu'un cluster est créé. Chaque cluster de votre cloud privé contient un datastore vSAN. Si les données de machine virtuelle stockées ne sont pas adaptées à l'efficacité de l'espace vSAN par déduplication et compression, ou uniquement par compression, vous pouvez remplacer l'efficacité de l'espace vSAN par la configuration choisie sur le datastore vSAN individuel.
En plus des fonctionnalités avancées de vSAN, VMware Engine permet également d'accéder au chiffrement des données vSAN Enterprise pour les données au repos et en transit.
Règles de stockage vSAN
Une règle de stockage vSAN définit les pannes à tolérer et la méthode de tolérance des pannes. Vous pouvez créer de nouvelles règles de stockage et les appliquer aux VM. Pour respecter un contrat de niveau de service, vous devez maintenir une capacité de secours de 20% sur le datastore vSAN.
Sur chaque cluster vSphere, une règle de stockage vSAN par défaut s'applique au datastore vSAN. La règle de stockage détermine comment provisionner et allouer les objets de stockage de VM dans le datastore pour garantir un niveau de service.
Le tableau suivant présente les paramètres de règle de stockage vSAN par défaut :
| FTT | Failure tolerance method | Nombre de nœuds dans un cluster vSphere |
|---|---|---|
| 1 | RAID 1 (mise en miroir) Création de deux copies |
3 et 4 nœuds |
| 2 | RAID 1 (mise en miroir) Création de trois copies |
5 à 32 nœuds |
Règles de stockage vSAN compatibles
Le tableau suivant présente les règles de stockage vSAN acceptées et le nombre minimal de nœuds requis pour l'activation de la règle :
| FTT | Failure tolerance method | Nombre minimal de nœuds requis dans le cluster vSphere |
|---|---|---|
| 1 | RAID 1 (mise en miroir) | 3 |
| 1 | RAID 5 (codage d'effacement) | 4 |
| 2 | RAID 1 (mise en miroir) | 5 |
| 2 | RAID 6 (codage d'effacement) | 6 |
| 3 | RAID 1 (mise en miroir) | 7 |
NSX Data Center
NSX Data Center fournit des fonctionnalités de virtualisation réseau, de micro-segmentation et de sécurité réseau sur votre cloud privé. Vous pouvez configurer tous les services compatibles avec le centre de données NSX sur votre cloud privé avec NSX.
Fonctionnalités disponibles
La liste suivante décrit les fonctionnalités NSX-T compatibles avec VMware Engine, organisées par catégorie :
- Basculement, DNS, DHCP et IPAM (DDI) :
- Optimisation des méthodes d'apprentissage ARP et de suppression de la diffusion
- Réplication Unicode
- Réplication frontale
- SpoofGuard
- Gestion des adresses IP
- Blocs d'adresses IP
- Sous-réseaux IP
- Pools d'adresses IP
- Serveur DHCP IPv4
- Relais DHCP IPv4
- Adresses fixes/Liaisons statiques DHCP IPv4
- Relais DNS/proxy DNS IPv4
- Routage :
- Routes Null
- Routage statique
- Routage des appareils
- Contrôles de routes BGP à l'aide de cartes de routage et de listes de préfixes
- NAT:
- NAT sur les routeurs logiques Nord/Sud et Est/Ouest
- Source NAT
- NAT de destination
- NAT N:N
- Pare-feu :
- Pare-feu Edge
- Pare-feu distribué
- Interface utilisateur du pare-feu commune
- Sections du pare-feu
- Journalisation de pare-feu
- Règles de pare-feu de couche 2 et de couche 3 avec état
- Règles basées sur des tags
- IPFIX distribué basé sur un pare-feu
- Stratégies, tags et groupes de pare-feu :
- Ajout de tags d'objets/tags de sécurité
- Regroupement centré sur le réseau
- Regroupement centré sur la charge de travail
- Regroupement basé sur l'adresse IP
- Regroupement basé sur MAC
- VPN:
- VPN de couche 2
- VPN de couche 3 (IPv4)
- Intégrations :
- Mise en réseau et sécurité des conteneurs à l'aide de Tanzu Kubernetes Grid (TKG)
- Service VMware Cloud Director
- VMware Aria Automation
- Opérations VMware Aria pour les journaux
- Authentification et autorisation :
- Intégration directe avec Active Directory à l'aide de LDAP
- S'authentifier avec OpenLDAP
- Contrôle d'accès basé sur les rôles
- Automatisation :
- API REST
- SDK Java
- SDK Python
- Fournisseur Terraform
- Modules Ansible
- Spécifications OpenAPI/Swagger et documentation de l'API générée automatiquement pour l'API REST
- Inspection:
- Mise en miroir des ports
- Traceflow
- IPFIX basé sur un commutateur
Limites des fonctionnalités
Certaines fonctionnalités du centre de données NSX offrent des cas d'utilisation très spécifiques en matière de mise en réseau et de sécurité. Les clients qui ont créé leur compte Google Cloud au plus tard le 30 août 2022 peuvent demander l'accès aux fonctionnalités de ces cas d'utilisation en contactant Cloud Customer Care.
Le tableau suivant décrit ces fonctionnalités, les cas d'utilisation correspondants et les alternatives potentielles :
| Sélection | Cas d'utilisation | Alternative recommandée | Clients Google Cloud au plus tard le 30 août 2022 | Clients Google Cloud après le 30 août 2022 |
|---|---|---|---|---|
| Multidiffusion de couche 3 | Routage multicast de couche 3 à sauts | La multidiffusion de couche 2 est compatible avec un sous-réseau NSX-T. Cela permet de diffuser tout le trafic de multidiffusion aux charges de travail sur le même sous-réseau NSX-T. | Compatible | Non compatible |
| Qualité de service (QoS) | Application VoIP et sensible à la latence où la sursouscription du réseau se produit | Aucune configuration requise, car VMware Engine fournit une architecture réseau non surchargée. En outre, tous les tags QoS quittant un cloud privé sont supprimés lors de l'entrée dans le VPC via une connexion d'appairage. | Compatible | Non compatible |
| Pièges SNMP (Network Network Protocol) simples | Ancien protocole d'alerte pour la notification d'événements aux utilisateurs | Les événements et les alarmes peuvent être configurés dans NSX-T à l'aide de protocoles modernes. | Compatible | Non compatible |
| Fonctionnalités NAT telles que la NAT sans état, la journalisation NAT et la NAT64 | Utilisé pour la fonctionnalité NAT de niveau opérateur dans les déploiements de télécommunications volumineux | NSX-T est compatible avec la NAT/source de destination et les NAT N:N sur les routeurs logiques Nord/Sud et Est/Ouest. | Compatible | Non compatible |
| Règles de mise en réseau et de sécurité basées sur l'intent | Utilisé en association avec VMware Aria pour créer des stratégies de pare-feu basées sur l'entreprise dans NSX-T | La passerelle NSX-T et les fonctionnalités de pare-feu distribué peuvent être utilisées pour créer et appliquer des stratégies de sécurité. | Compatible | Non compatible |
| Groupes basés sur l'identité à l'aide d'Active Directory | Les déploiements VDI dans lesquels l'utilisateur s'est connecté à un invité VDI spécifique peut être détecté et recevoir un ensemble personnalisé de règles de pare-feu NSX-T. | Des postes de travail spécifiques peuvent être attribués aux utilisateurs à l'aide du pool d'attribution dédié. Utilisez les tags NSX-T pour appliquer ensuite des règles de pare-feu spécifiques par pool. | Compatible | Non compatible |
| Règles d'attribut de couche 7 (ID d'application) | Utilisé dans les règles de pare-feu NSX-T | Utilisez les groupes de services NSX-T pour définir un ensemble de ports et de services afin de faciliter la référence lors de la création d'une ou plusieurs règles de pare-feu. | Compatible | Non compatible |
| Règles de pare-feu de couche 2 et couche 3 sans état | Utilisé pour les pare-feu haut débit de niveau opérateur dans les déploiements de télécommunications de grande envergure. | NSX-T est compatible avec les règles de couche 2 et de couche 3 hautes performances avec état. | Compatible | Non compatible |
| Insertion du service NSX-T | Utilisé pour automatiser le déploiement Nord/Sud ou Est/Ouest des services réseau tiers à l'aide de NSX-T pour sécuriser et inspecter le trafic | Pour les déploiements de fournisseurs de solutions de sécurité tiers, VMware Engine recommande un modèle routé plutôt qu'un modèle d'insertion de services pour garantir que les mises à niveau de service de routine n'affectent pas la disponibilité du réseau. | Contacter Cloud Customer Care | Non compatible |
Mises à jour et mises à niveau
Cette section décrit les considérations relatives aux mises à jour et aux mises à niveau, ainsi que les responsabilités en matière de gestion du cycle de vie des composants logiciels.
HCX
VMware Engine gère l'installation initiale, la configuration et la surveillance de HCX dans des clouds privés. Ensuite, vous êtes responsable de la gestion du cycle de vie de HCX Cloud et des dispositifs de service tels que l'interconnexion HCX-IX.
VMware fournit des mises à jour pour HCX Cloud via son service HCX. Vous pouvez mettre à niveau HCX Manager et déployer des dispositifs de service HCX à partir de l'interface HCX Cloud. Pour connaître la date de fin de compatibilité d'un produit, consultez la Matrice du cycle de vie des produits VMware.
Autres logiciels VMware
Google est responsable de la gestion du cycle de vie des logiciels VMware (ESXi, vCenter, PSC et NSX) dans le cloud privé.
Les mises à jour logicielles incluent :
- Des correctifs : correctifs de sécurité ou corrections de bugs publiés par VMware
- Des mises à jour : modification de la version mineure d'un composant de la pile VMware
- Des mises à niveau : modification majeure de la version d'un composant de la pile VMware
Google teste un correctif de sécurité critique dès qu'il est disponible depuis VMware. Conformément au contrat de niveau de service, Google déploie le correctif de sécurité dans les environnements cloud privés dans un délai d'une semaine.
Google fournit des mises à jour trimestrielles concernant les composants logiciels VMware. Pour chaque nouvelle version logicielle majeure de VMware, Google collabore avec les clients pour coordonner un intervalle de maintenance adapté à la mise à niveau.
Cluster vSphere
Pour assurer la haute disponibilité du cloud privé, les hôtes ESXi sont configurés en tant que cluster. Lorsque vous créez un cloud privé, VMware Engine déploie les composants de gestion de vSphere sur le premier cluster. VMware Engine crée un pool de ressources pour les composants de gestion et déploie toutes les VM de gestion dans ce pool.
Vous ne pouvez pas supprimer le premier cluster pour réduire le cloud privé. Le cluster vSphere utilise vSphere HA pour assurer une haute disponibilité des VM. Les pannes à tolérer (FTT) sont basées sur le nombre de nœuds disponibles dans le cluster. La formule Number of nodes = 2N+1, où N correspond au FTT, décrit la relation entre les nœuds disponibles dans un cluster et le FTT.
Pour les charges de travail de production, utilisez un cloud privé contenant au moins trois nœuds.
Clouds privés à nœud unique
Pour les tests et les démonstrations de faisabilité avec VMware Engine, vous pouvez créer un cloud privé ne contenant qu'un seul nœud et un seul cluster. VMware Engine supprime les clouds privés ne contenant qu'un nœud ainsi que les VM et les données de charge de travail associées après 60 jours.
Vous pouvez redimensionner un cloud privé à nœud unique pour qu'il contienne trois nœuds ou plus. Dans ce cas, VMware Engine lance la réplication de données vSAN et ne tente plus de supprimer le cloud privé. Un cloud privé doit contenir au moins trois nœuds et effectuer la réplication complète des données vSAN pour être couvert par le contrat de niveau de service.
Les fonctionnalités ou opérations nécessitant plus d'un nœud ne fonctionneront pas avec un cloud privé à nœud unique. Par exemple, vous ne pouvez pas utiliser le DRS (Distributed Resource Scheduler) de vSphere ou la haute disponibilité.
Limites des clusters vSphere
Le tableau suivant décrit les limites de cluster vSphere dans les clouds privés qui répondent aux exigences du contrat de niveau de service :
| Ressource | Limite |
|---|---|
| Nombre minimal de nœuds pour créer un cloud privé (premier cluster) | 3 |
| Nombre minimal de nœuds pour créer un cluster | 3 |
| Nombre maximal de nœuds par cluster | 32 |
| Nombre maximal de nœuds par cloud privé | 96 |
| Nombre maximal de clusters par cloud privé | 21 |
Compatibilité avec le système d'exploitation invité
Vous pouvez installer une VM avec n'importe quel système d'exploitation invité compatible avec VMware pour la version ESXi de votre cloud privé. Pour obtenir la liste des systèmes d'exploitation invités compatibles, consultez le guide de compatibilité VMware pour le système d'exploitation invité.
Maintenance de l'infrastructure VMware
Il est parfois nécessaire d'apporter des modifications à la configuration de l'infrastructure VMware. Actuellement, ces intervalles peuvent survenir tous les 1 à 2 mois, mais la fréquence devrait diminuer avec le temps. Ce type de maintenance peut généralement être effectué sans interrompre l'utilisation normale des services.
Lors d'un intervalle de maintenance VMware, les services suivants continuent de fonctionner sans subir d'effet :
- Plan de gestion et applications VMware
- Accès à vCenter
- Mise en réseau et stockage
- Tout le trafic cloud
Stockage externe
Vous pouvez augmenter la capacité de stockage d'un cluster Google Cloud VMware Engine en ajoutant des nœuds. Vous pouvez également utiliser un espace de stockage externe si vous souhaitez uniquement faire évoluer le stockage. Le scaling du stockage augmente la capacité de stockage sans augmenter la capacité de calcul du cluster, ce qui vous permet de faire évoluer votre ressource indépendamment.
Pour en savoir plus sur l'utilisation de l'espace de stockage externe, contactez l'assistance Google ou votre conseiller commercial.