vSphere prend en charge vMotion sur une machine virtuelle hébergeant le nœud d'un WSFC.

Conditions préalables pour la prise en charge de vMotion :

  • vMotion est pris en charge uniquement pour un cluster de machine virtuelle dans des hôtes physiques (CAB).
  • Le réseau vMotion doit être une liaison Ethernet de 10 Gbits/s. Une liaison Ethernet de 1 Gbits/s n'est pas prise en charge pour une opération vMotion sur des machines virtuelles WSFC.
  • vMotion est pris en charge pour Windows Server 2012 et versions ultérieures. Windows Server 2008 SP2 et versions antérieures ne sont pas pris en charge.
  • Le délai d'expiration du signal de pulsation du cluster WSFC doit être modifié au moins pour les valeurs répertoriées ci-dessous :
    • (get-cluster -name <cluster-name>).SameSubnetThreshold = 10
    • (get-cluster -name <cluster-name>).CrossSubnetThreshold = 20
    • (get-cluster -name <cluster-name>).RouteHistoryLength = 40
  • La version du matériel virtuel de la machine virtuelle WSFC doit être la version 11 ou ultérieure.

Modification du délai d'expiration du signal de pulsation WSFC :

Les nœuds WSFC utilisent le réseau pour envoyer des paquets de signaux de pulsation à d'autres nœuds du cluster. Si un nœud ne reçoit pas de réponse d'un autre nœud pendant une période spécifiée, le cluster retire le nœud de l'appartenance au cluster. Par défaut, un nœud de cluster invité est considéré hors service s'il ne répond pas dans les 5 secondes sous Windows 2012 et 2012 R2. D'autres nœuds membres du cluster prennent le relais des rôles en cluster qui s'exécutaient sur le nœud retiré.

Une machine virtuelle WSFC peut se bloquer pendant quelques secondes au cours d'une opération vMotion. Si la durée de blocage dépasse l'intervalle du délai d'expiration du signal de pulsation, le cluster invité considère que le nœud est hors service et peut ainsi provoquer un basculement non nécessaire. Pour laisser une marge de manœuvre et améliorer la tolérance du cluster invité, l'intervalle du délai d'expiration du signal de pulsation doit être modifié pour autoriser un minimum de 10 signaux de pulsation manqués. La propriété qui contrôle le nombre de signaux de pulsation non reçus autorisés est SameSubnetThreshold. Vous devrez remplacer la valeur par défaut de cette propriété par 10 au minimum. Depuis l'un des nœuds de cluster WSFC participants, exécutez la commande suivante :

(get-cluster -name <cluster-name>).SameSubnetThreshold = 10

Vous pouvez également modifier d'autres propriétés pour contrôler la tolérance de la charge de travail avant le basculement. Le délai d'ajustement détermine à quelle fréquence des signaux de pulsation sont envoyés entre les nœuds en cluster. Le paramètre par défaut est de 1 seconde et le paramètre maximal de 2 secondes. Définissez la valeur SameSubnetDelay sur 1. Le seuil détermine combien de signaux de pulsation consécutifs peuvent être manqués avant que le nœud considère que son partenaire n'est pas disponible et déclenche le processus de basculement. Le seuil par défaut est de 5 signaux de pulsation et le maximum, de 120 signaux de pulsation. La combinaison du délai et du seuil détermine la durée totale pendant laquelle les nœuds Windows en cluster peuvent perdre la communication avant de déclencher le basculement. Lorsque les nœuds en cluster se trouvent dans des sous-réseaux différents, ces propriétés sont appelées CrossSubnetDelay et CrossSubnetThreshold. Définissez la valeur CrossSubnetDelay sur 2 et la valeur CrossSubnetThreshold sur 20.
Note : Les valeurs recommandées pour les paramètres des signaux de pulsation WSFC sont désormais les valeurs par défaut sous Windows Server 2016 et versions ultérieures.