Accueil > VMware > nouveauté vSphere5: FDM
Août/1110

Le module HA dans vSphere 5 a été complètement réécrit, du coup l’agent est renommé maintenant de AAM en FDM (Fault Domain Manager).

Avant de rentrer plus dans le détail voici déjà une synthèse de amélioration de ce nouveau HA:

  • Prise en charge de l’IPv6
  • Suppression des problèmes standard de configuration (lié à la résolution DNS)
  • Utilise le stockage partagé comme chemin secondaire de vérification de l’isolation d’un Host
  • Prise ne charge des partitions réseau de gestion
  • Amélioration de la capacité à détecter certain type de plantage et fournit la redondance
  • API orientée applications : assure la surveillance des applications stratégiques
  • Facilité d’utilisation accrue : modification de la procédure de journalisation et de l’interface utilisateur
  • Amélioration du reporting des erreurs : un seul fichier log par host, ce qui simplifie le troubleshooting
  • Amélioration de l’interface utilisateurs
  • Amélioration des mécanismes de déploiement

Les rôles des agents FDM

Avec FDM, le concept de nœud principal/secondaire a disparu, ce qui simplifie le design d’un cluster et améliore la sécurité sur une infrastructure de type châssis Blade. En effet, avant, on avait un maximum 5 nœuds principaux, si on perdait les 5 nœuds (par exemple perte d’un châssis) le HA était en croix et il n’y avait aucun redémarrage de VMs. Maintenant, un seul serveur ESXi est maître du cluster, si on le perd, il y a élection d’un nouveau maitre sans pour autant perturber le fonctionnement du cluster.

Le maître FDM surveille les serveurs ESXi et s’assure que les VMs soient disponibles. Comme avec le HA, si un Host esclave tombe en panne, ses VMs protégées redémarrent et si une VM protégée tombe en panne, le maître la redémarre. Le maître FDM gère des serveurs ESXi membres du cluster (mise-à-jour de la liste lors de l’ajout/le retrait d’un Host) et la listes des VMs protégées (mise-à-jour de la liste à chaque arrêt/démarrage de VMs). Le rôle de maître FDM est choisi par « élection », cette élection intervient lors de l’activation du HA, lors de la création d’une partition réseau de gestion ou lors de l’arrêt/panne du maître.

L’élection est déclenchée via UDP, lorsqu’elle est terminée, toutes les communications s’effectuent par TCP/IP crypté point à point (pas de Broadcast). L’algorithme d’ élection du maître est le suivant : l’Host qui à le plus grand nombre de DataStores l’emporte, s’il y a égalité c’est celui qui a lexiquement le MOID le plus élevé qui l’emporte (exemple ho)

Les esclave FDM surveillent le fonctionnement des VMs qui s’exécutent localement et signalent toute modification de leur état au maître. Ils exécutent les fonctionnalité HA qui ne nécessitent aucune coordination centrale : la surveillance de l’état de santé des VMs. Il surveillent également l’état du maître, si celui-ci plante, l’esclave participe à l’élection d’un nouveau maître.

Avec FDM, le concept de nœud principal/secondaire a disparu, ce qui simplifie le design d’un cluster et améliore la sécurité sur une infrastructure de type châssis Blade. En effet, avant, on avait un maximum 8 nœuds principale, si on perdait les 8 nœuds (par exemple perte d’un châssis) le HA était en croix et il n’y avait aucun redémarrage de VMs. Maintenant, un seul serveur ESXi est maître du cluster, si on le perd, il y a élection d’un nouveau maitre sans pour autant perturber le fonctionnement du cluster.

Le vCenter communique principalement avec le maître FDM : quand le maître est élu, il contact le vCenter, celui lui envoie la liste de compatibilité, celui-ci la stocke sur les disques locaux et la pousse à tous les esclaves. Ensuite communique avec le maître pour mettre à jour la listes des changements d’état des VMs et de la configuration du cluster. Le vCenter peut communiquer avec les esclaves dans certain cas : pour vérifier l’existence du maître (si le vCenter n’arrive pas à la contacter), pour vérifier l’état d’un esclave (si le maître n’arrive pas à joindre l’esclave), quand une VM secondaire en FT est démarrée et quand un Host est rapporté isolé.

Les agents FDM communiquent sur le port 8182 en TCP/UDP et en Inbound/Outbound.

Le HeartBeat par le Stockage

L’une des nouveautés les plus intéressantes est le « Storage HeartBeat » : la possibilité d’utiliser le stockage partagé comme chemin secondaire pour vérifier l’isolation d’un Host. Les volumes utilisés pour cela se nomment alors « Heartbeat Datastores » et ne ne sont utilisé qu’en cas de perte du réseau (isolation réseau d’un host ou partitionnement réseau). Ce mécanisme permet clairement d’éviter les « faux-positives » sur la détection d’isolation d’Host.

Les Heartbeat Datastores permettent au maître FDM de suivre la disponibilité des esclaves, de faire la distinction entre le partitionnement réseau ou l’isolation réseau d’un esclave et de faire la coordination de l’appartenance d’une VM entres les maitres (si plusieurs clusters). Par défaut le vCenter choisit automatiquement 2 Datastores pour cette fonction, ils peuvent également être choisies manuellement.

La disponibilité d’un Host est déterminée de manière différente en fonction du stockage utilisé : en VMFS le maître lit le Heartbeat VMFS, en NFS le maître surveille un fichier Heartbeat mise à jour par les esclaves.

La disponibilité des VMs est rapporté par un fichier créé par chaque esclave qui contient la liste des VMs allumé. La coordination entre plusieurs maître est faite par vérrouillage de fichiers sur le Datastores.

Les fichiers utilisés pour le mécanisme FDM :

Emplacement Fichier Description
Par Host dans /etc/opt/vmware/fdm fdm.cfg fichier de configuration de l’agent FDM qui inclus les paramètres pour les logs, les alertes et répertoire de travail de FDM
Hostlist la liste des Hosts participant au cluster, incluant les Hostnames, adresses IP, adresses MAC et les Heartbeat Datastores
Compatlist la matrice de compatibilité qui liste les Hosts avec une VM est compatible
Clusterconfig fichier de configuration du cluster, qui inclut notamment le comportement de l’isolation Host, la priorité de redémarrage des VMs, l’Adminssion controls et des informations sur la configuration DRS/DPM
Fichiers partagés (présent uniquement sur les Heartbeat Datastores) host-XXX-hb fichier Heartbeat par Host qui est utilisé par le maitre pour vérifier l’état des esclaves par le chemin stockage quand ils ne répondent plus par le réseau.
host-XXX-poweron fichier par Host  contenant la liste de tous les Hosts actuellement allumé, il est utilisé comme moyen de communication entres les Hosts en cas d’isolation réseau. Les esclaves utilisent ce fichiers pour avertir le maître qu’ils sont isolés. Présent que sur les Heartbeat Datastores.
Fichiers partagés sur tous les Datastores Protectlist fichier par Datastore qui liste les VMs protégées par FDM sur ce Datastore. En cas de partitionnement avec plusieurs maîtres, le premier maître verrouille avec succès le Datastores, est celui qui indique quelles VMs sont protégées et met à jour le fichier. Lorsque les esclaves voient la mise à jour, ils savent qu’un maître protège ces VMs.
Par Host dans /var/log fdm.log
fichier de log global pour ce Host, il inclut les traces de tous les problèmes FDM en relation avec l’Host.

Simplicité accrue de l’administration HA

Dans l’onglet Summary d’un Host on peut maintenant clairement voir son état dans un cluster HA.

Voici la liste des états possibles: 

  • N/A (HA non configuré)
  • Election (Election du maître en cours)
  • Master (Il peut en avoir plusieurs en cas de partitionnement réseau)
  • Connected (au Maître par le réseau)
  • Network Partitioned
  • Network Isolated
  • Dead
  • Agent Unreachable
  • Initialization Error
  • Unconfig Error

Chaque Host possède un fichier de log unique: /var/log/fdm.log. Ce qui rend plus facile le troubleshooting que dans les précédentes versions, d’autant que les messages sont plus compréhensibles et plus complets. C’est le fichier qu’il faut regarder en premier en cas problème de Partitionnement / d’Isolation / de Protection de VM / d’Election / de Failover HA.

L’écran « Summary » du Cluster propose un accès rapide aux données HA du Cluster, sous la forme de 3 parties: Host (le maître et le nombre d’esclaves), VMs (le nombre de VMs protégées et non-protégées) et Heatbeat Datastores (les Datastores utilisées pour le Heartbeat et le nombre d’Host connectés).

Dans la partie « Admission Control Policy« , il est maintenant possible de sélectionner plusieurs Hosts dans « Specify failover Hosts« .

Le module HA dans vSphere 5 fournit également une API de reconnaissance des applications. En effet, cette API est la même que celle utilisée par Neverfail (vAppHA) et Symantec (ApplicationHA), maintenant l’API est disponible de manière publique. Elle permettra de développer des solutions de surveillance de l’état de santé d’un application et de faire redémarrer la VM par HA si nécessaire.

L’API de reconnaissance des applications permet à vSphere HA de protéger l’intégralité de la pile de virtualisation des applications stratégiques.

Pour terminer, une petite présentation par Eric Sloof sur les améliorations du module HA de vSphere 5:

Sources intéressantes:

  1. Pas encore de commentaire
  1. Pas encore de trackbacks