Les (vilains) secrets de VMware High Availability (HA)
Posted by NiTRo | Filed under Tips & Tricks, VMware
MAJ 28/08/2011 : FDM (Fault Domain Manager) change complément la donne et ce même pour les cluster en 3.5, vous trouverez l’architecture de fonctionnement sur le blog de Duncan.
En suivant une discussion sur le blog de Duncan Epping (Senior PSO Consultant chez VMware) concernant le design d’un cluster HA répartie sur 2 châssis de lames, nous somme tombés sur un post détaillant le fonctionnement précis de VMware High Availability (HA). Duncan nous a autorisé à le traduire.
Avec les dernières version d’ESX 3.5 & VirtualCenter 2.5, un cluster HA peut contenir 32 nœuds maximum. Contrairement à un cluster XenServer (par exemple…), les différents noeuds d’un cluster HA n’ont pas besoin d’un quorum pour communiquer entre eux. Cet avantage, on le paye forcement d’un inconvénient…
En fait, les nœuds d’un cluster HA ne communiquent pas totalement entre eux : Les 5 premiers (tant qu’ils restent online) serveurs ajoutés au cluster (primary nodes) se communiquent, via le réseau, les réglages du cluster, leurs état et l’état des autres serveurs (secondary nodes). Les autres serveurs (1 à 27) communiquent leur état aux primary nodes. Tout cela chaque seconde (valeur par défaut, modifiable via l’option das.failuredetectioninterval).
L’un des 5 primary nodes assume le rôle de fail-over coordinator qui coordonnera le redémarrage des vm d’un ou des nœuds HS. Les VM sont redémarrées dans l’ordre où elles ont été coupées (priorité prise en compte).
Malheureusement, un nœud primaire n’est re-promu que si le nœud HS est placé en maintenance mode ou retiré du cluster. Par conséquent, si les 5 nœuds primaires “tombent” aucune vm ne sera redémarrée car aucun fail-over coordinator ne sera disponible pour gerer cette action.
C’est pour cette raison qu’il est impossible de fixer la tolérance du cluster à plus de 4 nœuds :
Conséquence : En considerant un cluster de 32 nœuds répartis sur 2 châssis (16+16), il est probable que les 5 primary nodes soient dans le même châssis.
le fichier /var/log/vmware/aam/aam_config_util_listnodes.log contient la liste des nœuds et leur type (primary ou secondary) :
La ré-élection d’un primary node étant aléatoire, jouer avec le maintenance mode risque de vous faire perdre la tête, même si c’est la seule solution pour forcer un changement de type.
Ducan suggère une alternative plus sûre qui consiste à créer de plus petit clusters (dans notre cas, 4x 8 nœuds) et de les répartir sur les 2 châssis. Le but étant de diminuer la probabilité que plus de 4 nœuds “tombent” simultanément.
ESX 4 nous fera peut etre grace d’une alternative plus techniquement correct…
Tags: Best Practices, ESX, ESXi, HA, Tips & Tricks
Loading ...
February 21st, 2009 at 13:28
Je du mal a comprendre le HA. Si par exemple j’ai 2 ESX hosts. J’ai 10 VM sur l’un, pour que HA fonctionne, je doit avoir les copies de ces 10 VMs sur l’autre ESX? Comment marche la MAJ de de ces VMs. EN temps réel, ou 1fois par jour? Bref J’ai encore des choses a apprendre… -:)
February 21st, 2009 at 15:42
Vladan, le HA te permet d’assurer le redémarrage d’une ou plusieurs VM qui tournaient sur un host ayant crashé. Dans le cas d’un cluster HA contenant 2 hosts, lorsqu’un host crash, les VM sont redémarrées sur l’autre en quelques secondes (selon ton paramétrage). Les VM font parties du cluster donc elles peuvent être démarrées sur n’importe quel host de ce cluster. Il faut biensur etre dans une config SAN, iSCSI ou NFS pour cela car les hosts doivent pouvoir accéder à toutes les VM (pas de syncro donc).
Tu trouveras tous les détails dans le whitepaper de VMware : http://www.vmware.com/files/pdf/VMwareHA_twp.pdf
February 22nd, 2009 at 7:17
Ah, je viens de comprendre. Il me faut absolument du SAN ou iSCSI ou NFS. Difficile de tester ça avec 2 ESX boxes à la maison avec du shared storage seulement. A moins de passer par un virtual appliance qui peut nous simuler le NAS? A suivre. Merci de ta réponse…
February 22nd, 2009 at 12:09
tu peux utiliser OpenFiler, c’est un produit très robuste et très simple d’utilisation. Parfait pour faire du iSCSI
March 15th, 2009 at 5:37
Justement, je viens de découvrir Openfiller. C’est cool comme storage. Mais, par rapport aux perfs, as-tu quelques experiences?
Je doit monter une labo de présentation. Implementer 2 serveurs ESX avec du HA, et Openfiller en tant que iSCSI SAN
Merci
March 15th, 2009 at 13:10
Oui, c’est meilleur que FreeNAS au niveau perf brut.
Dans mon infra j’ai un Openfiller qui héberge une partition vmfs de 500Go depuis plusieurs mois, je n’ai pas eu un seul problème. Par contre attention au coupure réseau…
April 2nd, 2009 at 18:21
Mon labo se précise. Je vais faire une presentation qui va porté sur le H.A justement. J’aurais quelques serveurs (2 ou 3 maxi). Egalement il y aurai un serveur qui va servir proxy VCB, vCenter et qui va faire AD et DNS. (je sais c’est pas recommendé…). Avec du Symantec Backup Exec avec l’agent pour sauvegarder les VM. Donc j’ai prévu Openfiler dedans (faute d’avoir un SAN).
J’ai testé à la maison un conf avec Openfiler et Cluster ESX avec seulement 2 machines physiques (un conf semi-virtuel): http://www.vladan.fr/how-to-configure-openfiler-iscsi-storage-for-use-with-vmware-esx
April 5th, 2009 at 23:24
Pas mal le how-to
L’étape suivante c’est monter 2 openfiler en cluster
March 24th, 2010 at 8:51
Est-ce que l’explication est valable aussi pour la version vSphere 4 + vCenter ?
Andelpin
March 24th, 2010 at 10:49
Oui, les mêmes limitations s’appliquent jusqu’à la v4.0 U1. Selon les rumeurs, cela va nettement changer avec la 4.1.