Accueil > vCenter, VMware > Les rôles dans un cluster VMware HA
Mai/11310

La Haute Disponibilité (High Availability) ou HA chez VMware n’est pas une nouveauté. C’est toujours la possibilité de redémarrer une VM qui était sur un ESX sur un autre noeud d’un Cluster. Suite à un problème, un ESX du cluster est identifié comme hors service, ses machines virtuelles sont alors redémarrées sur un autre ESX du cluster tant que les ressources le permettent ou que la politique mise en place le tolère.

Comment est-il diagnostiqué qu’un ESX n’est plus en ordre de délivrer son service ?

Sur une simple absence de communication avec les autres ESX du cluster.

Les serveurs hôtes d’un cluster HA s’échangent un Heartbeat chaque seconde (valeur par défaut). Au delà de 15s sans échanges d’un ESX du cluster, il sera considéré comme hors service suite à une vérification complémentaire par Ping. Le « host network isolation » est propre à un ESX. C’est une capacité à ce placer en mode d’isolation. Sans récupération de heartbeat des autres ESX du cluster pendant 12s, un ESX testera ses adresses d’isolation (par défaut la passerelle – 9 autres possibles) avant de se déclarer isolé du réseau. Au dela de 15s, les autres ESX du cluster tenteront de redémarrer les VM de l’ESX en mode d’isolation. Des mécanismes permettent aujourd’hui d’éviter les situations de split brain en changement le paramètre « host isolation response », et le timeout de 15s sur les locks des fichiers vmdk.

Ce fonctionnement nécessite une certaine coordination des serveurs dans le cluster. Elle est assurée par des serveurs primaires (primary host). Et s’il y a des primaires, il y a aussi des secondaires (secondary hosts). Ces serveurs primaires sont au nombre maximal de 5 dans un même cluster. Parmi ces 5 serveurs primaire, il y en a 1 qui est l' »active primary » ou « master primary ».

L’active primary : C’est le chef d’orchestre. C’est ce serveur qui va décider OU redémarrer une VM, il connait aussi l’historique des redémarrages et sait quand il est approprié de redémarrer une VM.

Un primary : C’est un membre de l’orchestre. Il permet d’écouter ses collègues, pour éventuellement détecter un problème qui sera remonté à l’active primary. Il prendra le role d’active primary dans le cas ou se dernier connait une défaillance.

Un secondary : tout autre ESX du cluster. Il prendra le rôle de primary uniquement si un primary est placé en mode maintenance. Dans le cas ou un primaire est brutalement stoppé, aucun secondaire ne sera promu.

Toutes les informations sont disponibles sur le guide VMware vSphere Availability Guide.

Comment répartir physiquement les ESX d’un cluster HA?

Il faut appliquer une règle en fonction du nombre des serveurs portant le rôle primary. Ces serveurs sont au nombre de 5 dans un cluster. C’est l’unique valeur supportée par VMware. Donc pour répartir un cluster sur deux localisations, et pour qu’il soit fonctionnel même sur la perte totale d’une localisation, il faut que la seconde possède au moins 1 primary. Donc il n’en reste plus que 4 pour le premier site.

Les clusters à 2 sites ne peuvent contenir que 8 ESX (4 par localisation) et les clusters à 3 sites limitent les clusters à 6 noeuds.

 

Les avancées technologiques des prochaines versions de vSphere permettront probablement de répartir les ESX sur des sites distants interconnectées par lien WAN, ce n’est pas le cas actuellement. Le vMotion est toujours limité par le besoin d’une bande passante importante, et le HA nécessite une connectivité au stockage primaire, depuis tous les sites.

Peut-on influencer le placement des rôles sur les hyperviseurs ?

Effectivement, il existe certains moyens pour modifier le comportement d’un cluster HA :

  1. On peut le faire par passage en mode maintenance de serveurs primary, mais le résultat n’est pas certain (quant à l’élection d’un secondaire précis) (GUI)
  2. On peut aussi modifier le nombre de serveurs primaires dans un cluster pour passer le nombre audela de 5 (CLI) mais cela n’est visiblement pas supporté
  3. On peut aussi placer les rôles sur des hosts nommés (CLI)

Quelles ressources à disposition ?

Les lignes de commandes sont les plus riches à ce jour. Tout ce qui est présenté est valable en environnement ESXi 4.1.

Pour consulter l’état global du cluster, plusieurs fichiers de logs sont disponibles :

# cat /var/log/vmware/aam/aam_config_util_listnodes.log

# cat /var/log/vmware/aam/aam_config_util_listprimaries.log

# cat /var/log/vmware/aam/aam_config_util_monitornodes.log
05/11/11 09:12:49 [issue_cli_cmd ] command is '/opt/vmware/aam/bin/ftcli -domain vmware -port 8042 -timeout 5 -cmd listnodes'
05/11/11 09:12:49 [issue_cmd     ] CMD:    /opt/vmware/aam/bin/ftcli -domain vmware -port 8042 -timeout 5 -cmd listnodes
05/11/11 09:12:49 [issue_cmd     ] STATUS: 0
05/11/11 09:12:49 [issue_cmd     ] RESULT:
05/11/11 09:12:49 [issue_cmd     ] *** Node esx04 is the master primary ***
05/11/11 09:12:49 [issue_cmd     ]         Node              Type           State
05/11/11 09:12:49 [issue_cmd     ] -----------------------  ---------    --------------
05/11/11 09:12:49 [issue_cmd     ]   esx09                  Primary      Agent Running
05/11/11 09:12:49 [issue_cmd     ]   esx01                  Primary      Agent Running
05/11/11 09:12:49 [issue_cmd     ]   esx02                  Primary      Agent Running
05/11/11 09:12:49 [issue_cmd     ]   esx03                  Primary      Agent Running
05/11/11 09:12:49 [issue_cmd     ]   esx04                  Primary      Agent Running

 

Cela est aussi possible en PowerCLI, mais il n’est pas possible d’y voir le master primary :

[vSphere PowerCLI] C:...vSphere PowerCLI> Get-Cluster Cluster_name | Get-HAPrimaryVMHost | select name,connectionstate
Name                     ConnectionState ----  
esx04.domain.dom         Connected
esx03.domain.dom         Connected
esx01.domain.dom         Connected
esx08.domain.dom         Connected
esx10.domain.dom         Connected

Enfin, toujours en ligne de commande et directement sur l’ESXi :

/opt/vmware/aam/bin # ./Cli
                             Welcome to VMware AAM
                                 Version 5.1.2
                          Copyright VMware, Inc. 2006
AAM> help
all                 actuator            admin               debug
domain              group               misc                monitor
node                process             rule                sensor
trigger             user

Pour lister toutes les commandes possibles :

AAM> help all
addNode <nodeName>             - Add node to domain
deleteNode <nodeName>          - Delete a node in the domain
promoteNode                    - Make a Secondary Agent into a Primary Agent
demoteNode                     - Make a Primary Agent into a Secondary Agent

A partir de cette commande en ligne on peut effectuer des changements de rôles, en désignant précisément l’esx à placer en primaire, ou en secondaire.

Pour lister les rôles :

AAM> lr
 -------------------------------  ----------   ----------------
 RuleMonitor                      enabled      esx04
 VMWareClusterManager             enabled      esx04

Pour afficher les détails d’un rôle :

AAM> gr VMWareClusterManager
 Description: Manages ESX Host Failures and the Cluster Environment
 Triggers:
    CheckVMotionState
    CheckVMState
    CleanDB
    DebugLevel
    DontUseHost
    DumpState
    HostCompatListChange
    HostHealthChanged
    HostHealthChangedOnDemand
    InitiateFailoverAction
    MarkTotalFailure
    NodeDeleted
    NodeStateChange
    NodeStateRunning
    PolicyChange
    RecoverFromTotalFailure
    SetHostMonitoring
    SignalLiveness
    StateChange
    UseHost
    VMapProcState
    VMDeleted
    VMPlacementRequested
 Rule Runtime State  : RUNNING
 Rule Running On Node: esx04

 Rule Variables:name=CHK_VMSTATE_AFTER_RESTART_DELAY    value=120
                name=ft_Trace                   value=ON
                name=ft_TraceLevel              value=3
                name=ft_TraceMbs                value=2
                name=ft_TraceOutput             value=File
                name=HOST_MONITORING            value=enabled
                name=MAX_FT_VM_RESTART_COUNT    value=5
                name=MAX_PRIMARY_COUNT          value=5
                name=MAX_VM_RESTART_COUNT       value=5
                name=SIGNAL_LIVENESS_INTERVAL   value=60
  1. Pas encore de commentaire
  1. Pas encore de trackbacks