Que vous administriez un cluster de vSAN avec des lignes de base ou avec une seule image, la correction des hôtes faisant partie d'un cluster vSAN présente ses propres particularités.
- vSphere Lifecycle Manager ne place qu'un seul hôte à la fois en mode de maintenance.
- vSphere Lifecycle Manager corrige les hôtes faisant partie d'un cluster vSAN dans l'ordre.
- Étant donné que vSphere Lifecycle Manager gère la correction des hôtes dans l'ordre, le processus de correction d'hôte peut prendre un temps considérable.
- vSphere Lifecycle Manager corrige les clusters vSAN pour lesquels des domaines de pannes sont configurés en mettant à niveau tous les hôtes d'un domaine de pannes en premier, puis les hôtes du domaine de pannes suivant.
- Pour un cluster étendu vSAN, vSphere Lifecycle Manager corrige d'abord les hôtes du site préféré, puis procède à la correction des hôtes sur le site secondaire.
Mode de maintenance de l'hôte et clusters vSAN
Vous pouvez corriger un hôte se trouvant dans un cluster vSAN de deux manières, selon la façon dont vous souhaitez gérer les machines virtuelles sur l'hôte :
- Vous pouvez mettre l'hôte en mode de maintenance manuellement et le corriger à l'aide de vSphere Lifecycle Manager.
- L'hôte peut passer en mode de maintenance pendant le processus de correction de vSphere Lifecycle Manager.
Dans vSphere Client, lorsque vous mettez un hôte d'un cluster vSAN en mode de maintenance, vous pouvez choisir entre plusieurs options : Assurer l'accessibilité, Évacuation intégrale des données et Aucune évacuation de données. L'option Assurer l'accessibilité est l'option par défaut, ce qui signifie que lorsque vous mettez un hôte en mode de maintenance, vSAN garantit la disponibilité permanente de toutes les machines virtuelles accessibles sur cet hôte. Pour en savoir plus sur ces options, consultez la rubrique « Placer un membre du cluster vSAN en mode de maintenance » dans la documentation Stockage vSphere.
Pendant la correction, vSphere Lifecycle Manager met les hôtes du cluster vSAN en mode de maintenance et traite les machines virtuelles sur l'hôte de la même manière qu'avec l'option par défaut Assurer l'accessibilité.
Si un hôte fait partie d'un cluster vSAN et si l'une des machines virtuelles sur l'hôte utilise une stratégie de stockage de machine virtuelle avec pour paramètre « Nombre d'échecs à tolérer=0 », l'hôte risque de présenter des retards inhabituels lorsqu'il passe en mode de maintenance. Ces retards se produisent du fait que vSAN doit migrer les données de la machine virtuelle d'un disque dans le cluster de la banque de données vSAN vers un autre. Les retards peuvent durer plusieurs heures. Vous pouvez contourner ce problème en définissant le paramètre « Nombre d'échecs à tolérer=1 » pour la stratégie de stockage de machine virtuelle, ce qui entraîne la création de deux copies de fichiers de la machine virtuelle sur la banque de données vSAN.
Contrôle de santé de vSAN
vSphere Lifecycle Manager effectue une vérification préalable de la correction des clusters vSAN pour garantir la réussite de la correction. Le contrôle de santé vSAN fait partie de la vérification préalable de la correction.
Le contrôle de santé vSAN vous fournit des informations sur l'état du cluster et indique si vous devez prendre des mesures supplémentaires pour garantir la réussite de la correction. Même si vous n'effectuez pas les actions recommandées, vous pouvez néanmoins corriger le cluster vSAN ou un hôte du cluster. vSphere Lifecycle Manager met l'hôte en mode de maintenance et y applique les mises à jour. Toutefois, il se peut que l'hôte échoue à quitter le mode de maintenance et que le processus de correction échoue. Par conséquent, l'hôte du cluster vSAN est mis à niveau, mais vous devez effectuer une procédure manuelle pour sortir l'hôte du mode de maintenance.
Utilisation d'images de vSphere Lifecycle Manager pour corriger des clusters étendus vSAN
Lorsque vous gérez un cluster étendu vSAN ou un cluster ROBO à deux nœuds avec vSphere Lifecycle Manager, vous pouvez gérer les hôtes du cluster avec une seule image différente de l'image utilisée pour mettre à niveau l'hôte témoin dédié. Avec vSphere 8.0 Update 2, vous mettez à niveau l'hôte témoin vSAN de la même manière que vous mettez à niveau un hôte autonome.
Qu'est-ce qu'un cluster étendu ?
Un cluster étendu est un modèle de déploiement dans lequel deux hôtes ou plus font partie du même cluster logique, mais se trouvent dans des emplacements géographiques distincts. Tous les clusters étendus vSAN ou les clusters ROBO à deux nœuds doivent disposer d'un hôte témoin. Il s'agit d'un hôte autonome qui n'est pas membre du cluster correspondant, mais qui lui est associé. L'hôte témoin d'un cluster vSAN est géré par la même instance de vCenter Server que celle sur laquelle réside le cluster étendu ou le cluster ROBO correspondant.
vSphere Lifecycle Manager et hôtes témoins vSAN
L'hôte témoin vSAN est un hôte ESXi physique ou virtuel qui contient les composants témoins des objets de machine virtuelle stockés dans le cluster vSAN. L'hôte témoin ne prend pas en charge les charges de travail et n'est pas un nœud de données. Un cluster étendu ou un cluster ROBO à deux nœuds ne peut avoir qu'un seul hôte témoin.
- vCenter Server doit être de version 8.0 Update 2 ou ultérieure.
- L'hôte témoin doit utiliser ESXi version 7.0 Update 2 ou ultérieure.
- L'hôte témoin peut être un serveur virtuel ou un serveur physique.
- L'hôte témoin peut être un hôte témoin dédié ou un hôte témoin partagé.
- L'hôte témoin doit être mis à niveau avant les hôtes du cluster étendu vSAN ou à deux nœuds associé.
- L'hôte témoin et les clusters vSAN associés ne doivent pas être mis à niveau en parallèle.
- Vous ne pouvez pas exécuter des machines virtuelles sur un hôte témoin. Si vSphere Lifecycle Manager détecte des machines virtuelles périmées exécutées sur un hôte témoin, lors de la correction de l'hôte autonome, vSphere Lifecycle Manager définit le paramètre de correction État d'alimentation de la VM sur Ne pas modifier l'état d'alimentation. Pour plus d'informations, consultez Configurer les paramètres de correction de vSphere Lifecycle Manager pour les clusters ou les hôtes autonomes que vous gérez avec une seule image.
- Vous passez de l'utilisation de lignes de base de vSphere Lifecycle Manager à l'utilisation d'images de vSphere Lifecycle Manager pour un cluster étendu vSAN ou un cluster ROBO à deux nœuds existant et pour l'hôte autonome dédié.
Note : La transition vers l'utilisation d'images n'est pas bloquée si l'hôte témoin utilise une version d' ESXi antérieure à la version 7.0 Update 2. Toutefois, dans ce cas, après la transition, vous utilisez une seule image de vSphere Lifecycle Manager pour le cluster, mais vous devez toujours utiliser les lignes de base de vSphere Lifecycle Manager pour l'hôte témoin. Dans ces cas-là, vous pouvez utiliser des lignes de base pour mettre à niveau l'hôte témoin vers la version 7.0 Update 2 ou versions ultérieures, puis vous pouvez commencer à gérer l'hôte témoin avec une seule image vSphere Lifecycle Manager.
- Vous convertissez un cluster vSAN existant qui utilise une seule image en un cluster étendu avec un hôte témoin virtuel.
- Vous effectuez la mise à niveau vers la version 8.0 Update 2 et ultérieure pour vCenter Server et la version 7.0 Update 2 ou ultérieure pour l'hôte témoin.
- Vous convertissez un cluster étendu vSAN existant qui utilise des images en un cluster vSAN standard.
- Vous désactivez vSAN pour un cluster étendu vSAN existant que vous gérez avec une seule image.
Mise à niveau de clusters étendus vSAN à l'aide d'une image de vSphere Lifecycle Manager
Pour les clusters étendus vSAN, vous devez d'abord mettre à niveau les hôtes témoins avec l'image vSphere Lifecycle Manager distincte que vous avez configurée, puis procéder à la correction des hôtes du site préféré et du site secondaire. Si tous les hôtes du site préféré sont dans un état conforme, vSphere Lifecycle Manager ignore le site préféré et commence à corriger les hôtes à partir du site secondaire. Si un hôte dans l'ensemble du cluster est dans un état incompatible, la correction s'arrête. Pour plus d'informations sur la correction compatible avec les domaines de pannes et sur l'ordre dans lequel vSphere Lifecycle Manager corrige les hôtes dans un cluster vSAN, reportez-vous à la section Utilisation d'images de vSphere Lifecycle Manager pour corriger des clusters vSAN avec des domaines de pannes configurés.
À partir de vSphere 8.0 Update 2, vous pouvez utiliser une image de vSphere Lifecycle Manager complète pour mettre à niveau un hôte témoin de la même manière que vous mettez à niveau un hôte autonome. L'image souhaitée que vous appliquez sur un hôte témoin peut contenir une image ESXi de base, ainsi que des composants utilisateur, des composants de solution ou des modules complémentaires OEM.
- vCenter Server doit être de version 8.0 Update 2 ou ultérieure.
- L'hôte témoin doit utiliser ESXi version 7.0 Update 2 ou ultérieure.
- L'hôte témoin peut être un serveur virtuel et un serveur physique.
- L'hôte témoin peut être un hôte témoin dédié ou un hôte témoin partagé.
Utilisation d'images de vSphere Lifecycle Manager pour corriger des clusters vSAN avec des domaines de pannes configurés
Dans les clusters vSAN pour lesquels des domaines de pannes sont configurés, vSphere Lifecycle Manager corrige les hôtes dans un ordre que vSphere Lifecycle Manager calcule en fonction des domaines de pannes définis.
Qu'est-ce qu'un domaine de pannes ?
Un domaine de pannes comprend un ou plusieurs hôtes vSAN regroupés en fonction de leur emplacement physique dans le centre de données. Une fois configurés, les domaines de pannes permettent à vSAN de tolérer les échecs de l'intégralité des racks physiques ainsi que les échecs d'un hôte, d'un périphérique de capacité, d'une liaison réseau ou d'un commutateur réseau unique dédié à un domaine de pannes. Vous pouvez configurer des domaines de pannes pour des clusters vSAN non étendus et étendus. Pour plus d'informations sur la configuration des domaines de pannes, consultez la documentation Administration de VMware vSAN.
Mise à niveau de clusters vSAN configurés avec plusieurs domaines de pannes
vSphere Lifecycle Manager corrige les clusters vSAN pour lesquels des domaines de pannes sont configurés en corrigeant tous les hôtes d'un domaine de pannes à la fois. Pour définir l'ordre des domaines de pannes, vSphere Lifecycle Manager calcule et attribue la priorité à chaque domaine de pannes du cluster vSAN.
La correction commence par le domaine de pannes ayant la priorité la plus élevée. La priorité d'un domaine de pannes est déterminée par le nombre d'hôtes non conformes inclus dans ce domaine de pannes. Moins le nombre d'hôtes non conformes dans un domaine de pannes est élevé, plus la priorité de ce domaine de pannes est élevée. Cependant, si plusieurs domaines de pannes ont la même priorité, vSphere Lifecycle Manager sélectionne le premier domaine de pannes dans la liste des domaines de pannes.
Lorsque vSphere Lifecycle Manager sélectionne un domaine de pannes, vSphere Lifecycle Manager utilise des recommandations DRS pour sélectionner l'hôte optimal dans ce domaine à corriger.
Pour la correction compatible avec les domaines de pannes de clusters vSAN, les conditions suivantes sont requises :
- vCenter Server doit être de version 7.0 Update 1 et versions ultérieures.
- Les hôtes ESXi doivent être de version 7.0 ou ultérieure.
Mise à niveau des clusters vSAN avec NSX ou vSphere with Tanzu activé
Vous pouvez corriger un cluster vSAN par rapport à une image vSphere Lifecycle Manager qui contient la même version d'ESXi que la version d'ESXi actuellement disponible sur les hôtes, mais les dernières versions des composants NSX et vSphere with Tanzu. Dans ce cas, vSphere Lifecycle Manager met à niveau uniquement ces composants, sans mettre à niveau la version d'ESXi. Même dans de tels cas, vSphere Lifecycle Manager reconnaît toujours les domaines de pannes configurés pour le cluster vSAN et effectue la mise à niveau de la solution conformément à la configuration du domaine de pannes.
- vCenter Server doit être de version 7.0 Update 2.
- Les hôtes ESXi doivent être de version 7.0 ou ultérieure.