Archive pour le Tag: ‘HA

3 articles trouvés dans cette archive
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

Lire la suite…

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. Lire la suite…

Mar/1012
Par , Dans KB, VMware

Il m’est déjà arriver plusieurs fois que le CPU0 (celui du Service Console) d’un ESX sature à 100%.

En regarde plus en détail avec top, on constate que c’est le processus ftPerl qui sature le Service Console.

Ce problè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 problème dans la configuration du Cluster.

Résolution:

  • le plus simple mais seulement temporaire, faire un « Reconfigure HA » sur cette ESX. Résolution temporaire car le problème reviendra plus tard.
  • la solution permanente est de créer un nouveau et de migrer les VMs et les ESX dans ce nouveau Cluster et supprimer l’ancien. Une KB existe chez VMware expliquant la recréation de Cluster.

Référence: