Posts Tagged Haute disponibilité
Mettre en place des règles d’affinité dans un cluster DRS sous VMware vSphere
Publié par Aurélien dans Virtualisation le 6 mai 2010
Les règles d’affinité permettent de définir que certaines machines virtuelles doivent être placées sur le même hôte ESX (affinity) ou au contraire sur des hôtes distincts (anti-affinity).
En général, on présume que les règles d’affinité s’établissent pour améliorer les performances et que les règles d’anti-affinité privilégient au contraire la haute disponibilité. En effet, on n’agira pas de la même manière selon que l’on doit sécuriser un cluster Exchange ou donner le maximum de proximité – et donc de performances – à une base de données et son serveur applicatif.
Pour définir une règle sur un cluster DRS, il suffit de cliquer droit sur le cluster et sélectionner Edit Settings…
La fenêtre qui apparaît propose ensuite de régler les paramètres du cluster, que ce soit au niveau de VMware HA ou de VMware DRS. Ici, on s’astreindra à sélectionner le menu Rules et à cliquer sur le bouton Add… pour ajouter une nouvelle règle.
Après avoir donné un nom à la nouvelle règle, il suffit juste de sélectionner des machines virtuelles du cluster (toujours via un bouton Add…) et de sélectionner le type de règle qui nous intéresse :
- Separate Virtual Machines : impose aux machines virtuelles sélectionnées de s’exécuter sur des hôtes distincts
- Keep Virtual Machines Together : impose aux machines virtuelles sélectionnées de rester sur le même hôte ESX
Sachez également qu’une règle d’anti-affinité n’autorise que deux machines virtuelles à la fois. C’est dommage mais c’est ainsi pour le moment…
Une fois vos modifications effectuées, vous les retrouverez dans le menu Rule. En décochant la case, vous pourrez à tout moment désactiver cette règle sans la détruire.
Le bouton Details vous permettra d’obtenir un résumé de votre règle et déterminer si d’autres règles rentrent en conflit avec votre nouvelle règle.
Le vCenter indiquera enfin par une tâche récente que la reconfiguration du cluster a bien été prise en compte.
Bien que les règles d’affinité soient très facilement compréhensibles, n’oubliez jamais que le niveau d’automation de votre cluster DRS agira également sur vos réglages. Si vous optez pour une automation Manual ou Partially automated, votre cluster ne prendra pas de décision à votre place. En ce sens, il ne pourra qu’établir des recommandations suivant vos règles.
Par exemple, si vous sélectionnez trois machines qui doivent rester ensemble et qu’une de ces trois machines se trouve sur un autre hôte ESX, vous devrez manuellement appliquer la recommandation.
Dans l’onglet DRS de votre cluster, vous aurez peut-être remarqué qu’il existe trois vues : Recommandations, Faults et History. La première vous permet de visualiser et de valider les recommandations le cas échéant. La deuxième vous permet de rapidement déterminer les problèmes sur vos règles. Le vue History permet quant à elle de retracer l’évolution des opérations.
Changez votre niveau d’automation à Fully automated si vous voulez que vos règles s’exécutent immédiatement, et ce sans intervention supplémentaire.
En outre, utiliser le cmdlet Powershell Get-DrsRule, vous permettra également connaître à tout moment le détail des règles existantes (activées ou pas) qui s’appliquent sur un cluster donné (notez l’astérisque qui sert de wildcard…).
[vSphere PowerCLI] C:> Get-DrsRule -Name "*" -Cluster "Cluster Prod"
Name Enabled KeepTogether VMIDs
---- ------- ------------ -----
Serveur web True True {VirtualMachine-vm-789, VirtualMachine-vm-...
Utiliser le Virtual Machine Failure Monitoring (VMware HA)
Publié par Aurélien dans Virtualisation le 23 novembre 2009
Si l’utilité principale de VMware High Availability est de détecter les pannes des hôtes physiques, depuis ESX 3.5, elle peut également détecter et gérer les pannes des machines virtuelles grâce à l’option Virtual Machine Failure Monitoring.
ATTENTION : cette fonction est expérimentale et ne peut donc être utilisée dans un environnement de production
Principe de fonctionnement
VMware HA utilise le heartbeat envoyé par les VMware Tools installés sur chaque machine virtuelle pour déterminer leur disponibilité. En temps normal, un heartbeat est envoyé chaque seconde. Le Virtual Machine Failure Monitoring vérifie par défaut qu’un heartbeat est bien envoyé toutes les 20 secondes. Si aucun n’est alors reçu pendant un temps défini, la machine est déclarée en panne et redémarrée.
Une finesse notable de l’outil consiste par exemple à pouvoir distinguer automatiquement une VM saturée qui renverrait moins de heartbeats que prévu d’une machine éteinte.
Mise en oeuvre et utilisation
L’activation du Virtual Machine Failure Monitoring s’effectue au niveau d’un Cluster pour lequel VMware HA serait déjà activé. Pour cela, cliquez droit sur un cluster > Edit Settings… puis, dans le menu VMware HA, cliquez sur le bouton Advanced Options…
A partir de la fenêtre qui apparaît, ajoutez ou modifiez les options suivantes pour satisfaire vos exigences :
[table id=8 /]
Il est difficile d’obtenir des informations concernant le Virtual Machine Failure Monitoring. Néanmoins, vous pourrez trouver des éléments relatifs aux opérations dans le fichier /var/log/vmware/hostd.log
Lire aussi : VMware High Availability (HA)
Surveiller un hôte et des services sous Debian Lenny grâce à Mon
Publié par Aurélien dans Linux, Monitoring le 28 septembre 2009
Pour monitorer la disponibilité d’un hôte et/ou de services, on installe mon :
apt-get install mon
mon prévient d’un problème via syslog, e-mail ou exécute un script donné. Il peut paramétrer chaque alerte selon plusieurs critères :
- heure/jour de la semaine
- combien de fois un problème doit être signalé
Pour connaître son statut, on utilise la commande monshow :
<serveur>:~# monshow server: localhost time: Thu Jul 23 17:15:38 2009 state: scheduler running All systems OK
Le fichier de configuration de l’application se trouve dans /etc/mon/mon.cf
A présent, je vais vous présenter un exemple de configuration de mon dans lequel vous remarquerez entre autres la possibilité de “prendre les ressources” indisponibles du serveur monitoré. Cela se fait au moyen du service heartbeat qui fera bientôt l’objet d’un article détaillé. Sachez juste pour le moment qu’il faut un deuxième serveur qui passera en production lorsqu’il remarquera une défaillance de son…voisin. Car oui, toute l’astuce réside dans le fait de monitorer son voisin plutôt que de se monitorer soi-même !
maxprocs = 20
histlength = 100
randstart = 60s
authtype = getpwnam
hostgroup ADSL 123.123.123.123
hostgroup SRV-TEST 123.123.123.123
# On surveille le routeur du fournisseur d'acces
watch ADSL
service ping
interval 5s
monitor ping.monitor
period wd {Mon-Sun}
alert mail.alert -S "Votre routeur ADSL est down !" votre_email
upalert mail.alert -S "Votre routeur ADSL est up !" votre_email
alert hb_standby
alertafter 5
alertevery 10m
# On surveille le serveur
watch SRV-TEST
# On surveille le protocole SMTP via Postfix
# En cas de probleme on recupere les ressources via heartbeat
service postfix
interval 5s
monitor smtp.monitor
period wd {Mon-Sun}
alert mail.alert -S "Le serveur mail ne repond pas" votre_email
alert hb_takeover
upalert mail.alert -S "Le serveur mail repond de nouveau" votre_email
alertafter 2
alertevery 10m
# On surveille le protocole HTTP via Squid
# En cas de probleme on recupere les ressources via heartbeat
service proxy
interval 5s
monitor http.monitor -p 8080 -u 'http://www.google.fr/'
period wd {Mon-Sun}
alert mail.alert -S "Le proxy ne repond pas" votre_email
alert hb_takeover
upalert mail.alert -S "Le proxy repond de nouveau" votre_email
alertafter 4
alertevery 10m
# On surveille si le port TCP 10443 est ouvert (Reverse Proxy)
# En cas de probleme on recupere les ressources via heartbeat
service reverse_proxy
interval 5s
monitor tcp.monitor -p 10443
period wd {Mon-Sun}
alert mail.alert -S "Le reverse proxy ne repond pas" votre_email
alert hb_takeover
upalert mail.alert -S "Le reverse proxy repond de nouveau" votre_email
alertafter 6
alertevery 10m
