Haute disponibilité d’une machine virtuelle dans Hyper-V
La cas m’a occupé un certain temps avant de finaliser la solution à ce problème.
Posons la problématique
L’environnement a été installé selon les spécifications du guide détaillé de mise en œuvre d’Hyper-V en cluster. Si on se réfère à ce guide, on peut tester la haute disponibilité de la machine virtuelle simplement en arrêtant le service cluster. Jusque là, le comportement est normal. Mais poussons un peu plus les tests?
Qu’est ce qui se passe si on déconnecte la carte réseau privée? Pas de problème, c’est prévu dans le mode de fonctionnement du cluster, il va utiliser la carte publique pour le Heartbeat. Pas de problème pour la machine virtuelle.
Qu’est ce qui se passe si on déconnecte la carte réseau publique (celle liée à Hyper-V)? Rien, le cluster détecte bien la défaillance de la carte réseau publique mais cela ne provoque rien au niveau de la machine virtuelle. Elle n’est pas accessible sur le réseau mais techniquement elle répond au Heatbeat Hyper-V. Donc la machine virtuelle est opérationnelle mais inaccessible.
Cela peut sembler aberrant mais c’est bien le fonctionnement normal d’Hyper-V dans un cluster. Ce mode de fonctionnement ne pose pas de problème pour une machine virtuelle contenant elle même un nœud de cluster (SQL Server, Exchange) mais pour un système d’exploitation standard, cela pose problème.
Solution
Le début de réponse vient d’un billet de Robert Vierthaler, Escalation Engineer en Allemagne. Sa solution consiste à créer une ressource cluster de type “Script” qui va surveiller la carte réseau utilisée par Hyper-V. Comme il le dit lui même, cette nouvelle ressource sera liée à la machine virtuelle mais ne déclenchera pas encore sa bascule. Pour cela, il faut franchir une autre étape, ce que je me propose de détailler.
Configuration de la machine virtuelle
La première chose, c’est de s’assurer que la machine virtuelle n’est pas configurée pour un démarrage automatique dans la console Hyper-V. En effet, c’est le cluster qui doit décider de la mise en ligne ou non de la machine virtuelle et non Hyper-V.
La seconde chose, c’est de s’assurer d’avoir un assez grand nombre de défaillance autorisée de la machine virtuelle avant de basculer. Pour cela, on autorise un grand nombre de défaillance sur une large période. De cette manière, on s’assure que qu’on ne basculera pas la machine virtuelle simplement par ce que le réseau est surchargé.
Pour le “Failback”, je considère qu’il ne doit être réalisé qu’en dehors des heures ouvrables. On évite ainsi le phénomène de “Ping pong” de la machine virtuelle.
Création de la ressource Script générique
Etudions le script de Robert Vierthaler. Pour faire simple, le script sera exécuté périodiquement. Le script n’a pas de point d’entrée. C’est le cluster qui vient se servir des fonctions mises à dispositions, en particulier de la fonction “ISAlive()”. Tout bêtement, la fonction teste la disponibilité d’une carte réseau identifiée par une propriété privée de la ressource. Allons y.
Commençons par copier le script de Robert Vierthaler dans le répertoire %Windir%\Cluster sur tous les nœuds de notre cluster Hyper-V.
Continuons en créant une ressource cluster liée à la machine virtuelle. Le type de ressource est important, dans notre cas, c’est un script générique. On remarquera que la machine virtuelle est actuelle est en ligne, il faudra la redémarrer pour qu’à la fin la nouvelle configuration soit prise en charge.
Le script à été copié dans un répertoire donné, donc on va le déclarer comme existant au même endroit.
Une petite validation avant de créer la machine virtuelle puis on passe à la suite.
L’opération a réussi. Cela signifie non seulement que le script existe mais que les points d’entrée nécessaires ont bien été identifiés.
Notre nouvelle ressource est en ligne. A ce stade, elle n’est pas encore opérationnelle car, le script ne sait pas encore quelle carte réseau il faut surveiller. Donc ne pas mettre la ressource en ligne, cela ne changera rien à notre problème.
On va donc identifier la carte réseau à surveiller. Contrairement à ce que l’on pourrait penser, ce n’est pas la carte réseau d’Hyper-V qu’il faut surveiller mais bien la carte physique. La raison est toute simple, vous ne verrez jamais la carte réseau virtuelle déconnectée. Dans mon implémentation ci-dessous, j’ai volontairement renommé mes cartes réseaux pour mieux les identifier. Donc dans mon cas, ce sera “Carte réseau publique”.
La configuration de la propriété passera par la commande CLUSTER.EXE. Pour que cela fonctionne, attention à bien lancer une invite de commande MS-DOS avec tous les privilèges.
Pour y exécuter la ligne de commande magique qui va nous permettre de configurer la propriété “NICNAME” de la ressource “NICHA Script” avec le nom de la carte réseau à sur veiller. Attention à bien configurer la propriété pour la bonne ressource de cluster.
Pour s’en assurer, on va afficher les propriétés de la ressource nouvellement déclarée. On constate que la propriété “NICNAME” est maintenant bien configurée.
Finissions en par la configuration de la stratégie de bascule du script. Si la ressource échoue (carte réseau déconnectée) on va commencer par tenter un redémarrage. Une simple déconnexion de la carte réseau ne doit pas déclencher la bascule.
On va tenter un seul redémarrage dans une période de quinze minutes. Si notre redémarrage échoue, cela déclenchera la bascule de toutes les ressources liées à notre machine virtuelle. Dans ma configuration, on dispose d’une minute pour reconnecter le câble réseau avant de déclencher la bascule.
Pour tester, il suffit de mettre en ligne la ressource “Script”.
Si la carte réseau à surveiller est bien opérationnelle, alors elle apparaître bien “en ligne”. Il faudra arrêter et redémarrer la machine virtuelle pour prendre en compte les modifications.
Maintenant que la machine virtuelle a été redémarrée, dès lors que la carte réseau spécifiée est identifiée comme déconnectée depuis une minute, la machine virtuelle sera automatiquement basculée sur un autre nœud du cluster. C’est une démarche à suivre pour toutes vos machines virtuelles.
Limitation
Cette approche ne fonctionne pas pour les clusters Hyper-V gérés depuis SCVMM. La machine virtuelle sera marquée comme “Non supportée”. Cette problématique sera adressée dans SCVMM 2008 R2. En attendant, il faut travailler avec le Management Pack d’Hyper-V.
Benoîts – Simple by Design (100ème post, cela se fête!!!)