Le module HA dans vSphere 5 a été com­plè­te­ment réécrit, du coup l'agent est renommé main­te­nant de AAM en FDM (Fault Domain Manager).

Avant de ren­trer plus dans le détail voici déjà une syn­thèse de amé­lio­ra­tion de ce nou­veau HA:

• Prise en charge de l’IPv6
• Sup­pres­sion des pro­blèmes stan­dard de confi­gu­ra­tion (lié à la réso­lu­tion DNS)
• Uti­lise le sto­ckage par­tagé comme che­min secon­daire de véri­fi­ca­tion de l’isolation d’un Host
• Prise ne charge des par­ti­tions réseau de gestion
• Amé­lio­ra­tion de la capa­cité à détec­ter cer­tain type de plan­tage et four­nit la redondance
• API orien­tée appli­ca­tions : assure la sur­veillance des appli­ca­tions stratégiques
• Faci­lité d’utilisation accrue : modi­fi­ca­tion de la pro­cé­dure de jour­na­li­sa­tion et de l’interface utilisateur
• Amé­lio­ra­tion du repor­ting des erreurs : un seul fichier log par host, ce qui sim­pli­fie le troubleshooting
• Amé­lio­ra­tion de l’interface utilisateurs
• Amé­lio­ra­tion des méca­nismes de déploiement

Lire la suite...

La Haute Dis­po­ni­bi­lité (High Avai­la­bi­lity) ou HA chez VMware n'est pas une nou­veauté. C'est tou­jours la pos­si­bi­lité de redé­mar­rer une VM qui était sur un ESX sur un autre noeud d'un Clus­ter. Suite à un pro­blème, un ESX du clus­ter est iden­ti­fié comme hors ser­vice, ses machines vir­tuelles sont alors redé­mar­rées sur un autre ESX du clus­ter tant que les res­sources le per­mettent ou que la poli­tique mise en place le tolère.

Com­ment est-il diag­nos­ti­qué qu'un ESX n'est plus en ordre de déli­vrer son service ?

Sur une simple absence de com­mu­ni­ca­tion avec les autres ESX du cluster.

Les ser­veurs hôtes d'un clus­ter HA s'échangent un Heart­beat chaque seconde (valeur par défaut). Au delà de 15s sans échanges d'un ESX du clus­ter, il sera consi­déré comme hors ser­vice suite à une véri­fi­ca­tion com­plé­men­taire par Ping. Le "host net­work iso­la­tion" est propre à un ESX. C'est une capa­cité à ce pla­cer en mode d'isolation. Sans récu­pé­ra­tion de heart­beat des autres ESX du clus­ter pen­dant 12s, un ESX tes­tera ses adresses d'isolation (par défaut la pas­se­relle - 9 autres pos­sibles) avant de se décla­rer isolé du réseau. Au dela de 15s, les autres ESX du clus­ter ten­te­ront de redé­mar­rer les VM de l'ESX en mode d'isolation. Des méca­nismes per­mettent aujourd'hui d'éviter les situa­tions de split brain en chan­ge­ment le para­mètre "host iso­la­tion res­ponse", et le timeout de 15s sur les locks des fichiers vmdk. Lire la suite...

Il m'est déjà arri­ver plu­sieurs fois que le CPU0 (celui du Ser­vice Console) d'un ESX sature à 100%.

En regarde plus en détail avec top, on constate que c'est le pro­ces­sus ftPerl qui sature le Ser­vice Console.

Ce pro­blème existe sur des ESX en 3.0 et en 3.5 jusqu'à l'update 4 (peut être résolu depuis), il est lié un pro­blème dans la confi­gu­ra­tion du Cluster.

Réso­lu­tion:

• le plus simple mais seule­ment tem­po­raire, faire un "Recon­fi­gure HA" sur cette ESX. Réso­lu­tion tem­po­raire car le pro­blème revien­dra plus tard.
• la solu­tion per­ma­nente est de créer un nou­veau et de migrer les VMs et les ESX dans ce nou­veau Clus­ter et sup­pri­mer l'ancien. Une KB existe chez VMware expli­quant la recréa­tion de Cluster.

Réfé­rence:

• http://professionalvmware.com/2009/05/ftperl-hates-me/