mai
2011
Un article de zinzineti
L’application UCARP permet de mettre en place un système de failover automatique entre des serveurs. Ce mécanisme de disponibilité des applications sur des serveurs, nécessite une adresse IP virtuelle.
Pour cet exemple nous avions SRV1 et SRV2 comme serveurs à mettre en failover.
SRV1 IP : 172.20.X.12
SRV2 IP : 172.20.X.13
IP VIRTUEL : 172.20.X.10
=> Installer le package yum sur les serveurs
Avant d’installer UCARP sur les serveurs, il faut avant d’abord installer le package yum depuis le dépôt de logicielle (repository software).
¤ Se connecter au serveur en tant que root
¤ Exécuter la commande suivante :
rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-4.noarch.rpm
=> Installer UCARP sur les serveurs
¤ Se connecter au serveur en tant que root
¤ Exécuter la commande suivante :
yum -y install ucarp
=> Configurer UCARP sur les serveurs
Après installation d’UCARP sur les serveurs il faut maintenant configurer le fichier /etc/ucarp/vip-001.conf
Sur SRV1 (/etc/ucarp/vip-001.conf)
———————————–
# ID SRV1
ID=001
# Network Interface
BIND_INTERFACE= »eth0″
# IP du serveur SRV1
SOURCE_ADDRESS= »172.20.X.12″
# IP Virtuel
VIP_ADDRESS= »172.20.X.10″
# UCARP Password
PASSWORD= »ucarp-pw »
# Options, pour voir toutes les options executer : ucarp – – help
OPTIONS= »–shutdown –preempt »
Sur SRV2 (/etc/ucarp/vip-001.conf)
———————————–
# ID SRV2 : doit être identique à celui du SRV1
ID=001
# Network Interface
BIND_INTERFACE= »eth0″
# IP du serveur SRV2
SOURCE_ADDRESS= »172.20.X.13″
# IP Virtuel
VIP_ADDRESS= »172.20.X.10″
# UCARP Password : doit être identique à celui du SRV1
PASSWORD= »ucarp-pw »
# Options, pour voir toutes les options executer : ucarp – – help
OPTIONS= »–shutdown –preempt »
=> Démarrer le service UCARP sur les serveurs
Après la configuration des fichiers /etc/ucarp/vip-001.conf sur les serveurs il faut démarrer le service UCARP en exécutant sur chaque serveur la commande :
service ucarp start
et vérifier l’état du service avec la commande :
service ucarp status
=> Activer le service UCARP au reboot automatique
Sur chaque serveur exécuter les commandes :
chkconfig --add ucarp
chkconfig - - level 2345 ucarp on
=> Master/Backup status
On démarrage UCARP négocie le status master/backup entre les serveurs SRV1 et SRV2.
Pour vérifier quel est le serveur maître (master) ou esclave (backup) il faut jeter un d’œil dans le fichier /etc/log/messages
Les fichiers :
/etc/log/messages.1
/etc/log/messages.2
/etc/log/messages.x (x étant un entier)
Exemple de contenu du fichier /etc/log/messages
—————————-
Apr 10 04:02:01 xxxxxxxxxxxx syslogd 1.4.1: restart.
Apr 12 11:55:48 xxxxxxxxxxxx kernel: bnx2: eth0 NIC Copper Link is Down
Apr 12 11:55:49 xxxxxxxxxxxx ucarp[32761]: [WARNING] Switching to state: BACKUP
Apr 12 11:55:49 xxxxxxxxxxxx ucarp[32761]: [WARNING] Spawning
Apr 12 11:55:49 xxxxxxxxxxxx ucarp[6523]: [WARNING] Switching to state: BACKUP
Apr 12 11:55:49 xxxxxxxxxxxx ucarp[6523]: [WARNING] Spawning
=> Failover test
Après avoir identifié le serveur MASTER et le serveur BACKUP, on peut tester si le système failover fonctionne bien.
¤ Pour cela depuis la machine d’administration pingé l’IP VIRTUEL
Ping 172.20.X.10
Si la machine d’administration est du Windows exécuter donc :
Ping -t 172.20.X.10
¤ Puis arrêter (shutdown) le serveur MASTER
Résultat : Il ne doit pas y avoir perte de packets.
¤ Redémarrer le serveur MASTER
Résultat :
———-
Après redémarrage du service UCARP sur cette machine, Cette dernière reprend son rôle de MASTER (voir fichier /etc/log/messages ou /etc/log/messages.X)
Il faut noter que UCARP gère le failover de la machine (niveau système). UCARP ne sait pas gérer le failover d’un service particulier comme tomcat ou autre. Donc pour gérer le failover au niveau services ou application il faut faire recours à un service de gestion de haute disponibilité plus pointu comme HEARTBEAT
———————
Etienne ZINZINDOHOUE
UCARP utilise une IP virtuelle pour la communication entre les noeuds. Et c’est justement cette IP virtuelle qui est adressée par les applications clientes pour se connecter aux serveurs (MASTER ou BACKUP). Ce qui est aussi intéressant avec UCARP c’est sa simplicité et facilité de mise en oeuvre…
A+
Je me suis mal exprimé .. ici je ne parlais pas du réseau physique qu’il faut bien sûr rendre rendondant. Nous sommes d’accors sur ce point.
Avec le cluster Windows il y a distinction entre le réseau privé destiné aux communications internes entre les noeuds et le réseau public utilisé par les clients pour se connecter au cluster. On peut bien entendu avoir plus de deux cartes réseaux pour augmenter la redondance. Le but étant que si une carte devient HS l’autre prend le relai. Ceci est valable pour les types de communication. Dédier un réseau distinct aux communications internes permet en cas de contention du réseau public de ne pas le perturber et éviter d’avoir un comportement instable du cluster.
Bon je suppose que la technologie UCARP ne fonctionne pas de la même manière
Merci pour ces infos en tout cas
++
Réseaux distincts ou non ça fonctionne. Ce n’est pas un facteur limitant. Il suffit tout simplement de configurer les fichiers /etc/ucarp/vip-001.conf avec les adresses IPs.
Mais une bonne pratique consiste à utiliser des IPs de LANs distincts.
Si tu veux on peut faire le même parallèle avec les alimentations des serveurs.
Prenons un serveur qui dispose de deux alimentations électriques, la bonne pratique consiste à branché ces alim sur deux réseaux électriques distincts pour des raisons que tu sais… Mais en branchant les deux alim sur le même réseau électrique le serveur va fonctionner … Mais comme tu l’évoque en cas de problème de coupure de courant électrique le serveur sera indisponible.
c’est exactement la même chose avec UCARP, si un client a acheté de la disponibilité et n’a pas 2 LANs distincts … il aura de la disponibilité sauf pour des problèmes de LANs…
A+
Comment gères tu dans ce cas la défaillance du réseau ?
Avec le cluster Windows, il faut comme tu le sais 2 réseaux distincts pour éviter le SPOF.
Comment UCARP gère t’il cela ?
++
Bonsoir David,
Non pas besoin de réseau dédié pour mettre en place le failover avec UCARP.
Ce qui est intéressant aussi avec UCARP c’est la facilité avec laquelle on le configure, en moins de 2H tout est OK y
compris les tests de failover…
Par contre lorsque j’ai tenté de faire une maquette sur VMWARE (les 2 machines SRV1 et SRV2 hebergées sur le même
VMWARE) ça n’a pas marché alors que sur des machines physiques ça roule comme sur des roulettes
A+
Bonsoir,
Pas de réseau dédié à la communication interne du cluster comme pour le cluster Windows ?
++