¶ Importance
vCenter vous aide à gérer de manière centralisée plusieurs hôtes ESXi, machines virtuelles ainsi que leur réseau et leur stockage.
Si vous ne déployez, ne configurez et ne gérez pas correctement vCenter, votre environnement pourrait connaître une baisse d’efficacité administrative ou de capacité de gestion.
¶ Leçons du module
- Sauvegarde et restauration de vCenter
- Haute disponibilité vCenter (vCenter High Availability)
- Profils de configuration vSphere (vSphere Configuration Profiles)
- Gestion des certificats VMware
¶ Leçon 1 : Sauvegarde et restauration de vCenter
¶ Objectifs d'apprentissage
- Créer un calendrier de sauvegarde de vCenter
- Restaurer vCenter à partir d’une sauvegarde
- Configurer une sauvegarde de l’appliance vCenter
¶ À propos de la sauvegarde et de la restauration de vCenter
Les opérations de sauvegarde et de restauration de vCenter protègent les données. Ces opérations fonctionnent de la manière suivante :
- Utiliser l’interface de gestion de vCenter
- Supprimer la dépendance aux solutions de sauvegarde tierces
- Prendre en charge FTPS, HTTP, HTTPS, SFTP, FTP, NFS et SMB
- Inclure l’option de chiffrement des sauvegardes
- Restaurer directement à partir de l’installateur GUI de vCenter
- Restaurer une instance vCenter vers une nouvelle appliance
L’interface de gestion de vCenter prend en charge la sauvegarde des parties clés de l’appliance. Vous pouvez protéger les données de vCenter et réduire le temps nécessaire à la restauration des opérations du centre de données.
Le processus de sauvegarde collecte les fichiers clés de vCenter et la base de données vCenter dans une archive .tar, puis compresse l’ensemble pour réduire la charge du réseau. Afin de minimiser l’impact sur le stockage, la transmission est diffusée en continu sans mise en cache dans l’appliance. Pour réduire le temps total requis pour terminer la sauvegarde, le processus gère les différents composants en parallèle.
Vous pouvez chiffrer le fichier compressé avant sa transmission vers l’emplacement de stockage de la sauvegarde. Lorsque vous choisissez le chiffrement, vous devez fournir un mot de passe qui servira à déchiffrer le fichier lors de la restauration.
L’opération de sauvegarde inclut toujours la base de données vCenter et les fichiers de configuration du système afin qu’une opération de restauration dispose de toutes les données nécessaires pour recréer une appliance fonctionnelle. En option, vous pouvez spécifier qu’une opération de sauvegarde doit inclure les statistiques, événements et tâches de l’état actuel du centre de données. Les alertes actives sont toujours incluses dans une sauvegarde.
¶ Méthode pour la sauvegarde et la restauration de vCenter
Sauvegarde et restauration basées sur des fichiers :
- Utilisez l’interface de gestion de vCenter pour créer une sauvegarde basée sur des fichiers.
- Restaurez la sauvegarde via l’installateur graphique de l’appliance.
- Planifiez la sauvegarde et la restauration basées sur des fichiers.
¶ Planification des sauvegardes
Vous pouvez planifier des sauvegardes automatiques basées sur des fichiers.
Le planificateur de sauvegarde prend en charge :
- Une politique de rétention pour conserver toutes les sauvegardes ou un nombre défini de sauvegardes.
- Une planification quotidienne, hebdomadaire ou personnalisée.
Les sauvegardes échouées déclenchent une alarme dans le client vSphere.
Vous pouvez configurer un calendrier de sauvegarde basé sur des fichiers pour effectuer des sauvegardes périodiques :
- Le calendrier peut être configuré avec des informations sur l’emplacement de sauvegarde, la récurrence et la rétention des sauvegardes.
- Vous ne pouvez définir qu’un seul calendrier à la fois.
La destination de sauvegarde doit être suffisamment grande pour accueillir N+1 sauvegardes.
¶ Affichage du calendrier de sauvegarde
Vous pouvez afficher le calendrier de sauvegarde existant défini à partir de l’interface de gestion de vCenter.
Le calendrier de sauvegarde peut être modifié, désactivé ou supprimé.
¶ Sauvegarde basée sur des fichiers de vCenter
Vous pouvez effectuer une sauvegarde manuelle basée sur des fichiers.
Vous utilisez l’interface de gestion de vCenter pour exécuter une sauvegarde basée sur des fichiers de la configuration principale de vCenter, de l’inventaire et des données historiques de votre choix.
Les données sauvegardées sont transmises via le protocole sélectionné vers un système distant.
La sauvegarde n’est pas stockée sur vCenter.
Lors de la spécification de l’emplacement de la sauvegarde, utilisez la syntaxe suivante :
protocol://<server-address>:<port-number>/folder/subfolder
¶ Restauration basée sur des fichiers de vCenter
Vous pouvez utiliser l’installateur GUI de vCenter pour restaurer vCenter sur un hôte ESXi ou une instance vCenter.
La procédure de restauration se déroule en plusieurs étapes :
- Un nouvel appareil est déployé.
- Le vCenter nouvellement déployé est rempli avec les données stockées dans la sauvegarde basée sur des fichiers.
Pour effectuer une restauration réussie :
- Le mot de passe de chiffrement (s’il est utilisé) doit être saisi manuellement.
- La taille de l’appareil doit être identique ou supérieure à celle au moment de la sauvegarde.
- Les numéros de version de vCenter doivent correspondre.
Vous pouvez effectuer une restauration basée sur des fichiers uniquement pour une instance vCenter que vous avez préalablement sauvegardée à l’aide de l’interface de gestion de vCenter.
Vous pouvez effectuer l’opération de restauration à l’aide de l’installateur GUI de vCenter.
Ce processus automatise le déploiement d’une nouvelle instance de vCenter et la copie des données depuis la sauvegarde basée sur des fichiers vers le nouvel appareil.
Vous pouvez également effectuer une opération de restauration en déployant une nouvelle instance de vCenter et en utilisant l’interface de gestion de vCenter pour copier les données de la sauvegarde basée sur des fichiers vers le nouvel appareil.
L’installateur GUI de vCenter ne prend pas en charge la restauration à partir d’une sauvegarde utilisant les protocoles NFS ou SMB.
Pour effectuer une restauration à partir d’un protocole NFS ou SMB, vous devez utiliser l’interface de gestion de vCenter.
Pour plus d’informations, consultez « Restaurer le serveur vCenter à partir d’une sauvegarde basée sur des fichiers » à l’adresse suivante : https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-vcenter-installation/GUID-F02AF073-7CFD-45B2-ACC8-DE3B6ED28022.html
¶ Lab 13 : Sauvegarde de l’Appliance vCenter
Accédez à l’interface de gestion de l’Appliance du serveur vCenter et créez une sauvegarde de l’Appliance vCenter.
- Sauvegarder l’Appliance vCenter
Retrouvez le lien du Lab en cliquant ici : Lab 13 : Accéder à l'environnement de lab
¶ Revue des objectifs d’apprentissage
- Créer un calendrier de sauvegarde de vCenter
- Restaurer vCenter à partir d’une sauvegarde
- Configurer une sauvegarde de l’Appliance vCenter
¶ Leçon 2 : vCenter High Availability
¶ Objectifs d’apprentissage
- Reconnaître l’importance de vCenter High Availability
- Expliquer le fonctionnement de vCenter High Availability
- Identifier les exigences de vCenter High Availability
¶ Importance de maintenir vCenter hautement disponible
La haute disponibilité est une caractéristique importante pour de nombreuses solutions VMware et tierces qui dépendent de vCenter en tant que plateforme principale de gestion :
- vCenter est la base de l’infrastructure de bureau virtuel.
- Les solutions de sauvegarde et de reprise après sinistre reposent sur vCenter.
vSphere est une plateforme de virtualisation qui constitue la base pour construire et gérer les infrastructures cloud virtuelles, publiques et privées d’une organisation.
vCenter se trouve au cœur de vSphere et fournit des services pour gérer divers composants d’une infrastructure virtuelle, tels que les hôtes ESXi, les machines virtuelles, ainsi que les ressources de stockage et de réseau.
À mesure que de grandes infrastructures virtuelles sont construites à l’aide de vSphere, vCenter devient un élément essentiel pour assurer la continuité d’activité d’une organisation.
vCenter doit se protéger contre un ensemble de défaillances matérielles et logicielles dans un environnement donné et doit pouvoir se rétablir de manière transparente après de telles pannes.
¶ À propos de vCenter High Availability
vCenter High Availability protège vCenter contre les défaillances matérielles et logicielles.
vCenter High Availability forme un cluster composé de plusieurs nœuds :
- Active node : exécute l’instance active de vCenter
- Passive node : prend automatiquement le rôle du Active node en cas de défaillance
- Witness node : fournit un quorum pour se protéger contre une situation de split-brain
vCenter High Availability est intégré à vCenter et inclus avec la licence standard.
Avec vCenter High Availability, vCenter se rétablit automatiquement après une défaillance avec un temps d’arrêt minimal.
¶ Scénario : défaillance du nœud actif
Si le nœud actif tombe en panne, le nœud passif prend le rôle du nœud actif. Le cluster est alors considéré comme fonctionnant dans un état dégradé.
L’animation montre ce qui se produit lorsqu’un nœud actif échoue.
Pour visionner l’animation, rendez-vous sur ce lien
Le nœud actif exécute l’instance active de vCenter.
Ce nœud utilise une adresse IP sur le Management Network pour permettre la connexion du vSphere Client et des hôtes ESXi.
Si le nœud actif échoue (à cause d’une panne matérielle, logicielle ou réseau), le nœud passif prend alors le rôle du nœud actif.
L’adresse IP à laquelle le vSphere Client était connecté est transférée du nœud défaillant vers le nouveau nœud actif.
Le nouveau nœud actif commence alors à traiter les requêtes des clients.
Pendant ce processus, l’utilisateur doit se reconnecter au vSphere Client pour continuer à accéder à vCenter.
Comme seulement deux nœuds sont alors en fonctionnement, le cluster vCenter High Availability est considéré comme étant en état dégradé, et un nouvel échec ne peut pas être géré automatiquement.
Une défaillance supplémentaire dans cet état signifierait que les services vCenter ne seraient plus disponibles.
Un nœud passif est donc requis pour ramener le cluster à un état sain.
¶ Scénario : défaillance du nœud passif
Si le nœud passif tombe en panne, le nœud actif continue de fonctionner normalement.
Cependant, le cluster est considéré comme fonctionnant dans un état dégradé.
Si le nœud passif échoue, le nœud actif continue de fonctionner normalement.
Aucune interruption de service ne se produit, et les utilisateurs peuvent continuer à accéder au nœud actif via le vSphere Client.
Cependant, comme le nœud passif n’est plus disponible, le nœud actif n’est plus protégé.
Le cluster est alors en état dégradé, car seuls deux nœuds (actif et témoin) sont en fonctionnement.
Une nouvelle défaillance dans cet état signifierait que les services vCenter ne seraient plus disponibles.
Un nœud passif est donc nécessaire pour ramener le cluster à un état sain.
¶ Scénario : défaillance du nœud témoin
Si le nœud témoin échoue, le nœud actif continue de fonctionner normalement.
Cependant, le cluster est considéré comme étant dans un état dégradé.
Le nœud témoin est utilisé pour maintenir le quorum.
Si le nœud témoin échoue, le nœud actif continue à fonctionner sans interruption de service.
Cependant, comme seulement deux nœuds restent en fonctionnement, le cluster est considéré comme étant dans un état dégradé, et un basculement (failover) ne peut pas se produire.
Une défaillance supplémentaire dans un cluster dégradé rendrait les services vCenter indisponibles.
Le nœud témoin doit donc être restauré afin de ramener le cluster à un état sain.
¶ Avantages de vCenter High Availability
vCenter High Availability offre de nombreux avantages :
- vCenter devient plus résilient.
- Une protection contre les défaillances matérielles, hôte et applicatives est assurée.
- La restauration s’effectue en quelques minutes, réduisant au minimum le temps d’arrêt global.
- L’architecture active-passive permet un basculement transparent :
- Objectif de point de restauration (RPO) : aucune perte de données.
- Objectif de temps de restauration (RTO) : en quelques minutes.
- Les nœuds peuvent être géographiquement distants (moins de 10 millisecondes de latence).
- Aucun stockage partagé n’est requis.
- Aucune technologie tierce n’est nécessaire.
¶ Exigences de vCenter High Availability
| Composant | Exigences |
|---|---|
| ESXi | • Un minimum de trois hôtes ESXi est recommandé. |
| vCenter | • Une taille de déploiement Small ou supérieure est requise pour atteindre le RTO. • Un espace disque suffisant est nécessaire pour collecter et stocker les bundles de support pour les trois nœuds sur le nœud actif. |
| Connectivité réseau | • La latence réseau entre les trois nœuds doit être inférieure à 10 millisecondes. • Le réseau vCenter HA doit être sur un sous-réseau différent de celui du Management Network. |
| Licence | • Une licence vCenter Standard unique est requise. |
Pour plus d’informations sur les exigences de vCenter High Availability, consultez :
vSphere Availability Guide (VMware)
¶ Revue des objectifs d’apprentissage
- Reconnaître l’importance de vCenter High Availability
- Expliquer le fonctionnement de vCenter High Availability
- Identifier les exigences de vCenter High Availability
¶ Leçon 3 : Profils de configuration vSphere
¶ Objectifs d’apprentissage
- Reconnaître les avantages de l’utilisation des profils de configuration vSphere
- Expliquer le fonctionnement de la fonctionnalité Profils d’hôte (Host Profiles)
- Configurer et gérer les profils de configuration vSphere
¶ À propos des profils de configuration vSphere
Introduits dans vSphere 8, les administrateurs peuvent utiliser les profils de configuration vSphere pour tester les fonctionnalités et fournir des commentaires pendant le processus de développement.
À partir de vSphere 8.0 Update 1 et versions ultérieures, les profils de configuration vSphere sont entièrement pris en charge.
Avec les profils de configuration vSphere, les administrateurs peuvent :
- Gérer collectivement la configuration de tous les hôtes d’un cluster.
- Définir une configuration souhaitée pouvant être appliquée à tous les hôtes en une seule opération.
- Utiliser un hôte de référence et faire de sa configuration la configuration souhaitée pour l’ensemble du cluster.
Dans vSphere 8, les profils de configuration vSphere ont été introduits sous forme d’aperçu technologique (Technology Preview) et n’étaient pas encore entièrement pris en charge.
Les administrateurs peuvent activer les profils de configuration vSphere uniquement sur les clusters que vous gérez à l’aide d’une image unique.
¶ Exigences pour les profils de configuration vSphere
Pour utiliser les profils de configuration vSphere, vous devez vous assurer que votre environnement répond aux exigences suivantes :
- vCenter Server 8.0 Update 1
- ESXi 8.0 Update 1
- Licence Enterprise Plus
¶ Limitations des profils de configuration vSphere
Les profils de configuration vSphere présentent les limitations suivantes :
- Une fois activés sur un cluster, les profils de configuration vSphere ne peuvent pas être désactivés.
- Ne prennent pas en charge un cluster si NSX est également activé.
- Ne prennent pas en charge un cluster avec des hôtes équipés de DPU.
- Certains services ESXi, tels que les états de démarrage et d’exécution, ne sont actuellement pas gérés par les profils de configuration vSphere.
- Par exemple, les paramètres de démarrage et d’exécution du service SSH ne sont pas inclus dans un document de configuration de cluster.
¶ Configuration au niveau du cluster
Dans vSphere 8 Update 1 et les versions ultérieures, la gestion de la configuration des hôtes ESXi au niveau du cluster se trouve dans Desired State > Configuration, sous l’onglet Configure de l’objet cluster.
¶ Utilisation des profils de configuration vSphere
Le flux de travail de configuration commence par des vérifications d’éligibilité sur le cluster et les hôtes.
- Si le cluster n’est pas éligible, le processus de configuration ne se poursuivra pas.
- Si le cluster est éligible, les administrateurs peuvent importer une configuration à partir d’un hôte du cluster ou d’un fichier JSON.
Référence – Utilisation des profils de configuration vSphere pour gérer la configuration des hôtes au niveau du cluster.
¶ Afficher les paramètres des hôtes dans la configuration souhaitée
Vous pouvez consulter des informations sur la manière dont chaque paramètre d’hôte est configuré dans la configuration souhaitée actuelle du cluster.
Pour chaque paramètre d’hôte défini dans le document de configuration, vous pouvez voir les valeurs définies pour tous les hôtes du cluster ainsi que les éventuelles exceptions spécifiques à certains hôtes.
Les paramètres communs, les paramètres spécifiques aux hôtes et les exceptions d’hôtes sont configurés manuellement dans le document de configuration, qui est un fichier JSON modifiable.
¶ Schéma de configuration et document de configuration
Les administrateurs peuvent configurer et gérer la configuration souhaitée des hôtes pour un cluster entier en travaillant avec le document de configuration du cluster concerné.
Le document de configuration est un fichier JSON que vous pouvez télécharger sur votre ordinateur local et modifier à l’aide d’un éditeur JSON.
Un document de configuration valide contient une section profile et, éventuellement, des sections host-specific et host-override :
- La section
profilecontient une configuration commune applicable à tous les hôtes du cluster. - La section
host-specificreprésente la configuration qui ne peut être spécifiée que pour un hôte particulier. - La section
host-overridereprésente la configuration qui remplace celle d’un hôte spécifique dans le cluster.
¶ Vérifier la conformité des hôtes par rapport à la configuration souhaitée du cluster
Vous pouvez vérifier la conformité de chaque hôte d’un cluster par rapport à la configuration souhaitée définie pour l’ensemble du cluster.
La tâche Vérification de la conformité de la configuration du cluster s’exécute automatiquement dans les cas suivants :
- Lorsque vous apportez des modifications à la configuration souhaitée du cluster.
- Lorsque vous ajoutez un hôte au cluster.
¶ Exécuter une prévérification de remédiation
Vous exécutez une prévérification de remédiation afin de vous assurer que la configuration souhaitée est valide et que le cluster est en bon état de fonctionnement.
Pendant cette prévérification, vSphere Configuration Profiles effectue divers contrôles d’intégrité sur chaque hôte ainsi que sur l’ensemble du cluster.
La prévérification de remédiation calcule également l’impact que la remédiation pourrait avoir sur les hôtes.
¶ Corriger un cluster selon la configuration souhaitée
Vous pouvez corriger un cluster en fonction de la configuration souhaitée afin que tous les hôtes non conformes deviennent conformes à la configuration définie pour le cluster.
Dans cette étape, vous pouvez examiner l’impact de la remédiation.
Par exemple :
- Les hôtes du cluster seront placés en mode maintenance, puis redémarrés si nécessaire.
- Les hôtes concernés seront ensuite remis en fonctionnement une fois la remédiation terminée.
¶ Configuration cohérente sur plusieurs sites
Vous pouvez obtenir une configuration cohérente sur plusieurs serveurs vCenter dans votre environnement.
À partir du vCenter source (Source VC) :
-
Vous exportez la configuration au format JSON, incluant :
- La configuration de l’appliance,
- La configuration réseau,
- Les utilisateurs et les privilèges.
Ensuite, vous pouvez valider et importer cette configuration dans les vCenters de destination (Dest. VC1, VC2, VC3, VC4, VC5) afin de garantir une uniformité de configuration entre tous les sites.
¶ Prise en charge de vSphere Distributed Switch
Les profils de configuration vSphere (vSphere Configuration Profiles) prennent en charge la co-existence avec les configurations de vSphere Distributed Switch.
Cela signifie que vSphere Distributed Switch et les informations des Distributed port groups sont toujours gérés par vCenter et sont compatibles avec l’utilisation des profils de configuration vSphere.
Par exemple, si vous créez ou modifiez des Distributed port groups, vous n’avez pas besoin d’ajouter ces informations au document de configuration du cluster.
Le Distributed port group est géré par le vSphere Distributed Switch indépendamment du cluster.
Cependant, si vous attachez des interfaces vmkernel à des Distributed port groups, la configuration des interfaces vmkernel doit être gérée par les profils de configuration vSphere.
Référence – Annoncer les profils de configuration vSphere (Announcing vSphere Configuration Profiles)
¶ Transition d’un cluster avec un vSphere Distributed Switch
Un cluster existant configuré pour utiliser des profils d’hôtes (Host Profiles) peut être converti afin d’utiliser à la place les profils de configuration vSphere.
¶ État de santé du service vSphere Configuration Profiles
vSphere Configuration Profiles est fourni par le service VMware vSphere Update Manager.
Les messages de journal (log messages) sont principalement enregistrés dans le fichier
vmware-vum-server-XX.log situé dans le répertoire suivant sur le vCenter : /var/log/vmware/vmware-updatemgr/vum-server/
¶ À propos des Host Profiles
Introduits avec vSphere 4.0, les Host Profiles sont désormais les prédécesseurs des vSphere Configuration Profiles.
Les Host Profiles sont également utilisés pour automatiser et centraliser la gestion de la configuration des hôtes ainsi que la conformité de cette configuration.
Tout comme les vSphere Configuration Profiles, les Host Profiles présentent de nombreux avantages :
- Configuration et gestion des modifications simplifiées pour les hôtes ESXi
- Détection facilitée de la non-conformité par rapport aux configurations standard
- Rémédiation automatisée
Au fil du temps, votre environnement vSphere évolue et s’étend. De nouveaux hôtes sont ajoutés au centre de données et doivent être configurés pour coexister avec les autres hôtes du cluster. Par exemple :
- Stockage : datastores tels que VMFS et NFS, initiateurs et cibles iSCSI, et multipathing
- Réseau : commutateurs virtuels, port groups, vitesse des cartes réseau physiques (NIC), sécurité, stratégies d’agrégation (NIC teaming policies), etc.
- Licences : sélection de l’édition, saisie de la clé de licence, etc.
- Configuration de la date et de l’heure : serveur Network Time Protocol (NTP)
- Paramètres de sécurité : paramètres du pare-feu, configuration Active Directory, services ESXi, etc.
- DNS et routage : serveur DNS, passerelle par défaut IP, etc.
Traditionnellement, vous modifiiez la configuration d’un seul hôte :
- Manuellement, à l’aide du vSphere Client ou de la ligne de commande
- Automatiquement, à l’aide de scripts
Grâce à la fonctionnalité Host Profiles, vous pouvez exporter les paramètres de configuration d’un hôte de référence principal et les enregistrer sous forme d’un ensemble de règles portables appelé host profile. Vous pouvez ensuite utiliser ce profil pour configurer rapidement d’autres hôtes dans le centre de données.
Configurer des hôtes à l’aide de cette méthode réduit considérablement le temps de configuration de nouveaux hôtes. Plusieurs étapes sont regroupées en un seul clic. Les Host Profiles éliminent également le besoin de créer des scripts spécialisés pour configurer les hôtes.
Le système vCenter utilise les Host Profiles comme base de configuration des hôtes, ce qui permet de surveiller les changements de configuration, de détecter les écarts et de les corriger.
En tant que fonctionnalité sous licence de vSphere, les Host Profiles ne sont disponibles qu’avec la licence Enterprise Plus.
Si vous rencontrez des erreurs, assurez-vous que vos hôtes disposent de la licence vSphere appropriée.
¶ Mise en œuvre des Host Profiles
Vous commencez avec un hôte de référence pour créer un host profile qui peut ensuite être appliqué à de nouveaux hôtes.
Suivez ce flux de travail de base pour implémenter les Host Profiles :
- Configurez un hôte destiné à servir d’hôte de référence.
L’hôte de référence est celui à partir duquel le profil sera créé. - Utilisez l’assistant Create Profile pour créer un profil à partir de l’hôte de référence désigné.
vCenter récupère les paramètres de configuration de l’hôte de référence, y compris les montages NFS et les ports vSphere vMotion.
Vous pouvez modifier le profil afin de personnaliser davantage les règles définies dans le profil. - Associez le host profile à un hôte ou à un cluster d’hôtes.
Vous pouvez attacher un profil à un hôte autonome ou à un ou plusieurs clusters d’hôtes. - Vérifiez la conformité des hôtes par rapport au profil de l’hôte de référence.
Si tous les hôtes sont conformes au host profile, cela signifie qu’ils sont correctement configurés. - Vérifiez la conformité des nouveaux hôtes par rapport au profil de l’hôte.
Vous pouvez facilement appliquer le host profile à d’autres hôtes ou clusters d’hôtes non conformes.
Vous pouvez également importer et exporter un host profile vers un fichier de profil au format VMware Profile (.vpf).
Cette fonctionnalité est utile pour partager des host profiles entre plusieurs instances de vCenter.
¶ Surveillance de la conformité
Lorsqu’un nouvel hôte est ajouté à un cluster, celui-ci est vérifié pour s’assurer de sa conformité avec le host profile appliqué.
Un cluster peut également être vérifié manuellement pour la conformité avec un host profile.
Après la création du host profile et son association à un ensemble d’hôtes ou de clusters, vous pouvez vérifier l’état de conformité à plusieurs endroits dans le vSphere Client :
- Vue principale du host profile : affiche l’état de conformité des hôtes.
- Onglet Summary de l’hôte : affiche l’état de conformité de l’hôte sélectionné.
- Onglet Monitor du host profile : après avoir lancé une vérification de conformité, cet onglet affiche l’état de conformité des hôtes sélectionnés.
Cette vue affiche également toutes les incohérences entre les valeurs des hôtes et celles définies dans le host profile (comme illustré sur la diapositive).
Vous pouvez également vérifier la conformité de composants ou de paramètres individuels.
Ces vérifications de conformité intégrées sont particulièrement utiles pour vSphere DRS et vSphere DPM.
¶ Standardisation entre plusieurs instances de vCenter
Les organisations qui possèdent plusieurs instances de vCenter peuvent exporter un host profile à partir d’une instance de vCenter et l’importer dans d’autres instances de vCenter afin de l’utiliser dans ces environnements.
Certaines organisations disposent d’environnements étendus comportant de nombreuses instances de vCenter.
Si vous souhaitez standardiser une configuration d’hôte unique sur plusieurs environnements vCenter, vous pouvez exporter le host profile d’une instance de vCenter afin que d’autres instances puissent l’importer et l’utiliser dans leurs environnements.
Les host profiles ne sont ni répliqués, ni partagés, ni synchronisés entre les instances de vCenter connectées par le Enhanced Linked Mode.
Les fichiers sont exportés au format de profil VMware (.vpf).
Remarque : Lorsqu’un host profile est exporté, les mots de passe des profils administrateur et utilisateur ne sont pas exportés.
Cette restriction constitue une mesure de sécurité empêchant l’exportation de mots de passe en texte brut. Après l’importation du profil, vous êtes invité à ressaisir les valeurs des mots de passe, qui sont ensuite appliquées à l’hôte.
¶ Lab 14 : Utilisation des profils de configuration vSphere
Effectuez la transition d’un cluster utilisant des baselines vers l’utilisation d’images et de profils de configuration vSphere afin de gérer tous les hôtes du cluster :
- Configurer un cluster avec une seule image
- Configurer un cluster avec des profils de configuration vSphere
- Corriger (remediate) les hôtes d’un cluster
- Consulter le document de configuration
Retrouvez le lien du Lab en cliquant ici : Lab 14 : Accéder à l'environnement de lab
¶ Revue des objectifs d’apprentissage
- Identifier les avantages de l’utilisation des profils de configuration vSphere
- Expliquer le fonctionnement de la fonctionnalité Host Profiles
- Configurer et gérer les profils de configuration vSphere
¶ Leçon 4 : Gestion des certificats VMware
¶ Objectifs d’apprentissage
- Utiliser VMware Certificate Authority et VMware Endpoint Certificate Store pour configurer la gestion des certificats de sécurité vSphere
- Décrire les utilisateurs de la solution et leurs exigences en matière de certificats
- Décrire les modes courants de VMware CA
- Remplacer les certificats VMware CA par des certificats d’entreprise ou commerciaux tiers
- Utiliser le client vSphere pour gérer les certificats vSphere
¶ Cas d’utilisation des certificats
Votre navigateur ne reconnaît pas ou ne fait pas confiance au certificat racine de VMware CA.
Pour éviter que des messages d’avertissement relatifs aux certificats n’apparaissent à chaque connexion à vCenter, vous devez ajouter le certificat racine VMware CA à la liste des certificats de confiance de votre navigateur.
Consultez la documentation du fournisseur pour votre navigateur.
¶ À propos des autorités de certification
Les autorités de certification (CA) émettent des certificats à clé publique :
- Les CA commerciales facturent l’émission de certificats.
- Les CA communautaires, telles que CAcert.org, fournissent des certificats gratuits.
Certaines organisations déploient leur propre CA et émettent des certificats auto-signés.
Pour qu’un certificat signé par une CA soit approuvé, les clients tels que les navigateurs web, doivent avoir installé le certificat racine de la CA :
- Les certificats racine des grandes autorités de certification commerciales sont préinstallés dans les navigateurs modernes.
Les systèmes cryptographiques à clé publique utilisent des paires de clés. Les données sont chiffrées à l’aide d’une clé privée, connue uniquement du propriétaire. Les données peuvent être déchiffrées uniquement à l’aide de la clé publique correspondante, qui peut être largement diffusée.
Les CA jouent un rôle important dans les systèmes d’infrastructure à clé publique (PKI). Lorsqu’un client SSL (Secure Sockets Layer) ou TLS (Transport Layer Security) se connecte à un serveur, ce dernier envoie sa clé publique au client afin de s’authentifier. Cependant, le serveur ne peut pas envoyer sa clé publique en clair, car elle pourrait être interceptée et modifiée par des attaquants pouvant s’introduire dans la communication.
À la place, le serveur envoie un certificat X.509 au client. Ce certificat contient le nom du serveur (le sujet), sa clé publique et d’autres informations. Les certificats X.509 sont signés par une CA de confiance, ce qui signifie qu’ils sont chiffrés avec la clé privée de la CA.
Le client fait confiance à la CA car il possède déjà la clé publique de cette dernière, soit préinstallée, soit installée manuellement par un administrateur. Par exemple, les navigateurs tels que Safari, Firefox, Internet Explorer et Chrome possèdent les clés publiques des principales autorités de certification déjà intégrées.
L’utilisation de SSL ou TLS ne se limite pas aux sites web et aux navigateurs, bien que ce soit leur usage le plus courant. Tout logiciel client ou serveur nécessitant une authentification sécurisée entre les parties peut utiliser SSL ou TLS de la manière décrite ici.
¶ À propos de VMware CA
VMware CA émet et valide des certificats.
Le principal objectif de VMware CA est d’émettre des certificats afin que les composants vSphere puissent établir des relations de confiance.
Les principaux consommateurs de certificats émis par VMware CA sont les services qui s’exécutent dans le cadre de vCenter.
Les services demandent des certificats pour établir leur propre identité et pour authentifier l’identité d’autres entités vSphere.
Par défaut, VMware CA agit comme une autorité de certification racine. Elle émet et valide des certificats pour les composants vSphere, tels que les hôtes ESXi et les solutions associées.
VMware CA peut gérer l’ensemble du processus de gestion des certificats pour vous. VMware CA provisionne les composants vCenter ainsi que les hôtes ESXi avec des certificats utilisant VMware CA comme autorité de certification racine.
¶ Types de certificats vSphere
vSphere utilise plusieurs types de certificats :
- Certificat racine VMCA
- Certificats machine :
— vCenter
— ESXi - Certificats utilisateur de solution
Les composants vSphere utilisent SSL pour communiquer de manière sécurisée entre eux et avec les hôtes ESXi. Les communications SSL garantissent la confidentialité et l’intégrité des données. Les données sont protégées et ne peuvent pas être modifiées durant leur transit sans détection.
Les services vCenter, tels que le client vSphere, utilisent également des certificats pour leur authentification initiale auprès de vCenter Single Sign-On.
vCenter Single Sign-On attribue à chaque composant un jeton SAML que le composant utilise pour l’authentification à partir de ce moment-là.
Les produits VMware utilisent des certificats X.509 version 3 (X.509v3) standards afin de chiffrer les informations de session transmises via SSL entre les composants.
Pour obtenir plus d’informations sur les exigences relatives aux certificats vSphere, veuillez consulter la page : Where vSphere Uses Certificates
¶ Chaîne de confiance
Si vous faites confiance à l’autorité de certification (CA), vous faites implicitement confiance à tous les certificats émis par cette CA.
- Pour faire confiance à un certificat, vous devez avoir confiance en la chaîne de confiance. L’une des conditions suivantes doit être remplie :
— Vous devez indiquer que vous faites explicitement confiance au certificat lui-même.
— Vous devez indiquer que vous faites explicitement confiance à la CA qui l’a émis. - Dans le cas d’un certificat auto-signé, l’émetteur et l’utilisateur sont le même système :
— Pour utiliser des certificats auto-signés, chaque système client doit installer et approuver explicitement chaque certificat auto-signé utilisé dans le réseau.
— Chaque fois qu’un nouveau service est mis en ligne, tous les clients doivent installer et approuver individuellement chaque certificat auto-signé du réseau. - Une CA interne ou commerciale élimine la nécessité pour chaque système client d’installer tous les certificats auto-signés, à condition que :
— Tous les systèmes clients fassent confiance à la CA.
— Tous les certificats proviennent de cette CA de confiance.
Cette configuration est appelée chaîne de confiance à deux nœuds.
Les deux nœuds sont :
- Le système client
- La CA (autorité de certification)
Le client fait confiance au serveur parce que l’autorité de certification (CA) a émis le certificat du serveur, et le client fait confiance à cette CA.
Cette configuration est appelée chaîne de confiance à trois nœuds.
Les trois nœuds sont :
- Le système client
- L’ICA (autorité de certification intermédiaire)
- La CA (autorité de certification)
Le client fait confiance au serveur parce que l’autorité de certification intermédiaire (ICA) a émis le certificat du serveur, la CA a émis le certificat de l’ICA, et le client fait confiance à la CA.
¶ Modes de fonctionnement de VMware CA
VMware CA peut être configuré pour fonctionner selon plusieurs modes :
- Autorité de certification racine (Root CA) (par défaut) : VMware CA agit comme une autorité de certification racine. Elle utilise son propre certificat racine auto-signé pour créer et émettre des certificats destinés à vCenter, ESXi et à d’autres composants qui en ont besoin.
- Autorité de certification subordonnée (Subordinate CA) : VMware CA agit comme une autorité de certification intermédiaire (ICA) rattachée à une autorité de certification d’entreprise existante ou à une autorité de certification tierce externe pour tous les certificats vSphere.
- Hybride (Hybrid) : VMware CA est subordonnée à une autorité de certification d’entreprise existante ou à une autorité tierce externe uniquement pour le certificat racine VMCA et le certificat de machine vCenter.
- Personnalisé (Custom) : tous les certificats émis par VMware CA sont remplacés par des certificats personnalisés émis par une autorité de certification commerciale ou d’entreprise. Cette option contourne VMware CA.
Par défaut, VMware CA est configurée pour agir comme une autorité de certification racine capable d’utiliser son propre certificat racine auto-signé afin d’émettre et de signer d’autres certificats.
Cependant, il est également possible de configurer VMware CA comme autorité de certification subordonnée.
Dans ce mode, VMware CA agit comme une autorité de certification intermédiaire au sein d’une chaîne de confiance reliant une autorité de certification d’entreprise ou une autorité tierce externe.
Si vous ne souhaitez pas utiliser VMware CA, vous pouvez la contourner et installer des certificats personnalisés sur tous vos systèmes, émis par une autorité de certification externe ou d’entreprise.
Utilisez le mode subordonné ou le mode contournement si vous souhaitez utiliser des certificats approuvés.
Tous vos certificats personnalisés (sauf les certificats d’hôte) doivent être installés dans VECS.
¶ VMware CA : Mode Autorité de Certification Racine (Root CA Mode)
Le mode Root CA est le mode par défaut pour VMware CA :
- Ce mode utilise un certificat racine auto-signé.
- Le certificat racine est un certificat d’autorité de certification (CA) capable d’émettre d’autres certificats.
- Tous les certificats vSphere sont créés à partir de ce certificat racine.
En général, une autorité de certification dispose d’un certificat auto-signé à sa racine, surtout lorsqu’il s’agit du premier certificat créé dans un nouveau domaine.
VMware CA utilise un certificat racine auto-signé. Elle émet des certificats pour vCenter, ESXi, etc., et gère ces certificats. Ces certificats forment une chaîne de confiance qui s’arrête au certificat racine de VMware CA.
VMware CA n’est pas une autorité de certification à usage général ; son utilisation est limitée aux composants VMware.
¶ Remplacement du certificat VMware CA en mode Root CA
Pour remplacer le certificat VMware CA en mode Root CA, suivez ces étapes :
- Créer un certificat VMware CA racine (Root CA certificate)
- (Facultatif) Remplacer les certificats émis
- (Facultatif) Supprimer l’ancien certificat VMware CA racine
Vous n’êtes pas obligé de remplacer les certificats qui ont été émis et signés par le précédent certificat racine VMware CA.
Lorsque vous remplacez le certificat racine VMware CA, cela n’invalide pas automatiquement le certificat précédent.
Le certificat précédent n’est pas supprimé non plus, il reste donc valide dans votre environnement vSphere.
Cependant, lorsque vous décidez de remplacer le certificat racine, il est recommandé de remplacer également tous les certificats existants (vCenter, hôtes ESXi, etc.) afin qu’ils soient signés par le nouveau certificat racine VMware CA.
Vous pouvez remplacer tous ces certificats en une seule opération à l’aide de l’outil vSphere Certificate Manager.
Utilisez le vSphere Client pour accéder à la page Certificate Management (Gestion des certificats), où vous pouvez trouver le VMware CA.
- Machine SSL Certificate
- VMware Certificate Authority (VMCA_ROOT_CERT)
- STS Signing Certificate
- Trusted Root Certificates
¶ VMware CA : Mode Subordinate CA
Lorsque VMware CA est en mode Subordinate CA :
- Vous remplacez le certificat CA auto-signé par défaut, créé lors de l’installation, par un certificat de confiance provenant d’une autorité de certification (CA) d’entreprise ou commerciale.
- Vous remplacez généralement tous les certificats par défaut émis après la mise en œuvre.
Ce mode nécessite une demande de signature de certificat (CSR) émise par VMware CA. Le CSR est utilisé dans une CA d’entreprise ou commerciale pour générer un nouveau certificat d’émission.
Une CA d’entreprise signe le CSR généré par VMware CA. Vous pouvez ensuite configurer VMware CA pour qu’il utilise ce certificat et ces clés.
En mode Subordinate CA, vous remplacez le certificat racine de VMware CA par un certificat signé par une CA tierce, qui inclut VMware CA dans la chaîne de certificats. Le certificat de remplacement peut être signé soit par votre CA d’entreprise, soit par une CA externe tierce.
Tous les certificats émis par VMware CA incluront désormais la chaîne complète. Vous pouvez remplacer les certificats existants par de nouveaux certificats générés, bien que cette étape ne soit pas obligatoire. Le certificat original reste valide s’il n’a pas expiré ou n’a pas été révoqué, et vous pouvez continuer à utiliser les certificats signés avec le certificat d’origine.
Le mode Subordinate CA combine la sécurité d’un certificat signé par une CA tierce avec la commodité de la gestion automatisée des certificats dans VMware CA.
Émettre un certificat signifie l’acte par lequel une autorité de certification crée un certificat et notifie l’abonné indiqué dans le certificat du contenu de celui-ci.
¶ Remplacement du certificat VMware CA par un certificat Subordinate CA
Pour remplacer le certificat racine VMware CA par un certificat CA d’entreprise ou tiers, suivez les étapes générales suivantes :
Pour configurer votre VMware CA en tant que Subordinate CA, vous devez générer une demande de signature de certificat (CSR) que vous pourrez présenter à votre CA d’entreprise ou à une CA tierce afin qu’elle crée un certificat approprié pour vous. Vous devez ensuite importer le certificat CA d’entreprise ou tiers dans VMware CA.
¶ VMware CA : Mode hybride
En mode hybride, le certificat racine VMCA est remplacé par un certificat de confiance. Le vCenter reçoit alors un certificat de confiance signé par la VMCA, mais les hôtes ESXi continuent d’utiliser leurs certificats non approuvés par défaut :
- La politique de l’entreprise peut ne pas autoriser les CA intermédiaires.
- Remplacez le certificat SSL de la machine vCenter par un certificat personnalisé signé par la CA d’entreprise et enregistré dans VECS.
- Tout le trafic vSphere restant est sécurisé par les certificats auto-signés par défaut émis par VMware CA.
Ce mode nécessite une demande de signature de certificat (CSR) émise par VMware CA.
Une CA d’entreprise utilise cette CSR pour signer un nouveau certificat, qui sera utilisé pour remplacer le certificat de la machine vCenter.
Pour plus d’informations sur le remplacement des certificats, consultez : Replacing vSphere Certificates
¶ Mode hybride : Remplacement du certificat de la machine vCenter par un certificat personnalisé
Le remplacement du certificat de la machine vCenter par un certificat personnalisé signé par une CA d’entreprise suit les étapes générales suivantes :
¶ Options de remplacement des certificats
Pour les solutions vCenter, vous devez remplacer les certificats dans les situations suivantes :
- En mode Root CA, lorsque vous souhaitez remplacer le certificat VMware CA par un nouveau certificat.
- En mode Subordinate CA, lorsque vous remplacez le certificat VMware CA par un certificat émis par votre CA d’entreprise ou par une CA tierce.
- En mode Custom, lorsque vous remplacez tous vos certificats par des certificats d’entreprise ou tiers.
Avec l’introduction de VMware CA dans vSphere 6.0, la gestion des certificats vSphere est devenue beaucoup plus simple.
Les situations décrites dans cette diapositive sont les trois cas les plus courants.
¶ Gestionnaire de certificats (Certificate Manager)
Vous pouvez utiliser le vSphere Client ou le vSphere Certificate Manager pour effectuer des tâches liées aux certificats.
| Option | Utilisation |
|---|---|
| 1 | Remplacer le certificat SSL de la machine par un certificat personnalisé émis par une CA. |
| 2 | Remplacer le certificat racine de VMware CA par un certificat personnalisé émis par une CA et remplacer tous les certificats. |
| 3 | Remplacer le certificat SSL de la machine par un certificat VMware CA. |
| 4 | Régénérer un nouveau certificat racine VMware CA et remplacer tous les certificats. |
| 5 | Remplacer les certificats des utilisateurs de solution par des certificats personnalisés. |
| 6 | Remplacer les certificats des utilisateurs de solution par des certificats VMware CA. |
| 7 | Annuler la dernière opération effectuée en republifiant les anciens certificats. |
| 8 | Réinitialiser tous les certificats. |
Avec vSphere 7 et les versions ultérieures, vous pouvez utiliser le vSphere Client pour remplacer les certificats de votre environnement vSphere et pour réinitialiser tous les certificats vSphere.
Vous pouvez également utiliser le vSphere Certificate Manager.
Pour plus d’informations sur la gestion des certificats, consultez : vSphere Certificate Management Overview
Pour démarrer le vSphere Certificate Manager, connectez-vous au système vCenter et exécutez la commande suivante dans l’invite de commande : /usr/lib/vmware-vmca/bin/certificate-manager
¶ Remplacement de tous les certificats VMware CA par des certificats personnalisés
Vous pouvez remplacer tous les certificats émis par VMware CA par des certificats personnalisés si les politiques de votre site l’exigent.
Lorsque vous remplacez VMware CA par des certificats personnalisés :
- VMware CA n’apparaît plus dans votre chaîne de certificats.
- Vous êtes responsable du remplacement de tous les certificats vous-même et du suivi de leurs dates d’expiration.
Pour utiliser des certificats personnalisés, envoyez des demandes de signature de certificat (CSR) à votre fournisseur de certificats et demandez les éléments suivants :
- Un certificat racine.
- Un certificat SSL machine pour chaque machine. Le CSR pour les certificats machine doit inclure le nom d’hôte et l’adresse IP de la machine.
- Les certificats des utilisateurs de solution ne doivent pas inclure d’adresse IP, de nom d’hôte ni d’adresse e-mail. Chaque certificat doit comporter le nom de l’utilisateur de solution.
Le remplacement des certificats émis par VMware CA par des certificats personnalisés d’entreprise ou de tiers n’est pas recommandé. Toutefois, les politiques de sécurité de votre site peuvent exiger l’utilisation d’une AC spécifique pour tous les systèmes de votre site.
Lorsque vous remplacez les certificats VMware CA par des certificats personnalisés, vous augmentez vos tâches de gestion des certificats, ce qui peut accroître le risque d’erreurs susceptibles d’entraîner des vulnérabilités de sécurité.
Vous êtes responsable de toutes les tâches de gestion des certificats.
Comme vous n’utilisez pas VMware CA, vous ne pouvez pas compter sur VMware CA pour gérer vos certificats à votre place.
¶ Expiration du certificat ESXi
Vous pouvez consulter les informations relatives à l’expiration des certificats signés par VMCA ou par une autorité de certification tierce (CA) dans le vSphere Client.
Une alerte jaune est déclenchée lorsque le certificat est dans l’état « Expiration prochaine » (moins de huit mois restants).
Une alerte rouge est déclenchée lorsque le certificat est dans l’état « Expiration imminente » (moins de deux mois restants).
¶ Options de remplacement des certificats ESXi
Plusieurs options sont disponibles pour le remplacement des certificats ESXi :
- Remplacer par des certificats émis par VMware CA :
— VMware CA approvisionne les certificats des hôtes.
— Les certificats des hôtes incluent la chaîne complète. - Utiliser des certificats d’entreprise ou de tiers :
— Vous pouvez utiliser vos propres certificats personnalisés.
— Vous devez disposer d’une autorité de certification d’entreprise.
Vous pouvez renouveler vos certificats avant leur expiration ou si vous souhaitez approvisionner l’hôte avec un nouveau certificat pour d’autres raisons.
Si vous ne renouvelez pas le certificat avant son expiration, la déconnexion puis la reconnexion de l’hôte entraîne le renouvellement automatique du certificat par vCenter.
Le fait de réajouter l’hôte à vCenter rétablit la confiance et permet à vCenter d’émettre sans condition le certificat renouvelé.
¶ Renouvellement des certificats ESXi
Si VMCA a attribué des certificats à vos hôtes ESXi, vous pouvez les renouveler ou les actualiser à partir du vSphere Client.
Renouveler les certificats :
- En général, vous renouvelez les certificats lorsqu’ils sont sur le point d’expirer, mais vous pouvez également approvisionner un hôte avec un nouveau certificat pour d’autres raisons.
- Le renouvellement permet d’obtenir un nouveau certificat signé pour l’hôte auprès de VMCA.
- Si le certificat est déjà expiré, vous devez déconnecter l’hôte puis le reconnecter.
- Par défaut, vCenter renouvelle automatiquement les certificats d’un hôte dont l’état est Expiré, Expirant immédiatement ou Expirant prochainement chaque fois que l’hôte est ajouté à l’inventaire ou reconnecté.
¶ Actualisation des certificats ESXi
L’actualisation des certificats CA (Certificate Authority) transfère tous les certificats contenus dans le magasin TRUSTED_ROOTS du vCenter VECS vers l’hôte.
Le magasin TRUSTED_ROOTS contient les certificats racine de confiance de toutes les instances de VMware CA, ainsi que ceux des autorités de certification tierces de confiance.
Pour renouveler ou actualiser les certificats CA à partir du vSphere Client :
- Accédez à l’hôte dans l’inventaire du vSphere Client.
- Cliquez sur Configure.
- Sous System, cliquez sur Certificate.
Vous pouvez afficher des informations détaillées sur le certificat de l’hôte sélectionné. - Choisissez Renew (Renouveler) ou Refresh (Actualiser).
- Cliquez sur Yes pour confirmer.
¶ Disponibilité de VMware CA
Dans le cas peu probable où VMware CA ne serait pas disponible, certaines opérations ne fonctionneraient pas :
- Ajout de nouveaux hôtes ESXi
- Actualisation ou renouvellement des certificats sur un hôte ESXi
Parfois, l’actualisation des certificats lors de leur expiration peut échouer.
Si VMware CA est indisponible pendant de courtes périodes, les opérations ne sont pas perturbées.
VMware CA est intégré à vCenter. Lorsque VMware CA n’est pas disponible, vous perdez la possibilité de gérer vos certificats. Cependant, les certificats déjà émis restent valides.
Vos services ou fonctions vSphere en cours ne devraient donc pas être interrompus.
¶ Lab 15 : Travailler avec les certificats
Générez et remplacez un certificat vCenter à l’aide du vSphere Client :
- Examiner le certificat Machine SSL
- Générer une demande de signature de certificat (CSR)
- Remplacer un certificat Machine SSL par un certificat CA pré-généré
Retrouvez le lien du Lab en cliquant ici : Lab 15 : Accéder à l'environnement de lab
¶ Revue des objectifs d’apprentissage
- Utiliser VMware Certificate Authority et VMware Endpoint Certificate Store pour configurer la gestion des certificats de sécurité vSphere
- Décrire les utilisateurs de solution et leurs exigences en matière de certificats
- Décrire les modes VMware CA courants
- Remplacer les certificats VMware CA par des certificats d’entreprise ou commerciaux tiers
- Utiliser le vSphere Client pour gérer les certificats vSphere
¶ Points clés
- Vous pouvez utiliser l’interface de gestion vCenter (vCenter Management Interface) pour surveiller l’utilisation des ressources de l’appliance et effectuer une sauvegarde basée sur des fichiers de celle-ci.
- Vous pouvez utiliser les profils de configuration vSphere (vSphere Configuration Profiles) pour tester les fonctionnalités et fournir des retours pendant le processus de développement des fonctionnalités.
- La gestion des certificats vSphere simplifie le processus de remplacement des certificats.
- VMware CA attribue à chaque hôte ESXi et à chaque service vCenter des certificats signés par VMware CA.
- vCenter High Availability (HA) est intégré à vCenter et protège l’appliance contre les pannes matérielles et logicielles.
Chapitre précédent : 5 - Opérations de stockage - Chapitre suivant : 7 - vSphere Monitoring