Page 1 sur 7 L'idée générale pour assurer la disponibilité d'un service est de faire fonctionner plusieurs machines (deux au minimum) en même temps. Ces machines forment ce qu'on appelle un cluster et chaque machine est un node du cluster. Chacune des machines va vérifier si les autres répondent toujours en prenant le pouls de chacune des autres. Si une machine cesse de fonctionner, les autres assurent le service. Une fois le cluster configuré, on y accède au travers d'une seule et unique adresse IP qui est celle du cluster; qui lui-même est composé de plusieurs nodes. Pour pouvoir mettre en place ce genre de technique, nous allons utiliser l'application HeartBeat qui va se charger de surveiller les machines et d'appliquer une série de scripts définis par l'utilisateur si cela s'avère nécessaire (c'est-à-dire si une machine tombe). La configuration de tests : La configuration de tests se compose de deux machines; FRLEG-NET01 et FRLEG- NET02. Les deux machines sont configurées comme serveur PROXY avec SQUID - SQUIDGUARD Le cluster sera accessible au travers de l'adresse 192.168.1.160
Page 2 sur 7 HeartBeat s'installe très simplement. Le paquet se trouve dans les dépôts standards. Il vous suffit donc de lancer la commande suivante sur les deux machines (FRLEG- NET01 et FRLEG-NET02) : Relancer une seconde fois l installation car heartbeat n est pas forcement installé :
Page 3 sur 7 La configuration d'heartbeat repose sur 3 fichiers fondamentaux. Les trois fichiers de configuration sont strictement identiques sur les deux machines; chez vous, il convient donc de les copier sur chacune des machines du cluster. Créer un fichier ha.cf sous /etc/ha.d/ Voici le contenu de ce fichier : Examinons ce fichier de configuration en détails : bcast debugfile logfile logfacility keepalive deadtime warntime indique l'interface réseau par laquelle on va effectuer la prise de pouls. indique le fichier de déboguage à utiliser. indique le log d'activité à utiliser. indique que l'on utilise la facilité syslog en plus. indique le délai entre deux battements de pouls. Ce délai est donné par défaut en seconde; pour utiliser les millisecondes, on ajoute le suffixe ms. indique le temps nécessaire avant de considérer un nœud comme étant mort. Ce temps est donné par défaut en seconde; pour utiliser les millisecondes, on ajoute le suffixe ms. indique le délai avant d'envoyer un avertissement pour les pouls en retard. Ce délai est donné par défaut en seconde; pour utiliser les millisecondes, on ajoute le suffixe ms.
Page 4 sur 7 indique un deadtime spécifique pour les configurations où le réseau met un certain temps à démarrer. initdead est normalement deux fois plus grand initdead que deadtime (au minimum). Ce délai est donné par défaut en seconde; pour utiliser les millisecondes, on ajoute le suffixe ms. udpport indique le port à utiliser pour la prise de pouls. renseigne le nom des machines faisant partie du cluster. Ce nom doit être node identique à celui retourné par la commande uname -n. indique le comportement à adopter si le node maître revient dans le cluster. Si on met la valeur on, lorsque le node maître revient dans le cluster, tout est transféré sur ce dernier. Si on met la valeur off, les services continuent à tourner sur l'esclave même lorsque le maître revient dans le cluster. Personnellement, je préfère la valeur off pour pouvoir faire auto_failback un retour à la normale manuellement lorsque la charge de production est moins importante. De plus, si le node maître souffre d'un grave problème, on pourrait avoir une boucle de démarrage/extinction qui entraînerait un relais des services de manière incessante. Ce qui peut devenir problématique. Sur FRLEG-NET01 et FRLEG-NET02 : IMPORTANT : Le fichier de configuration des ressources doit être strictement identique sur chacun des nœuds. Créer un fichier haresources sous /etc/ha.d/ Maintenant, nous allons définir le node maître, l'adresse IP du cluster et les services devant être assurés. Nous allons mettre en place l'adresse IP du cluster. Dans notre exemple, le fichier de configuration des ressources ressemble à ceci : C'est-à-dire que nous définissons le node maître comme étant FRLEG-NET01 et que l'adresse IP du cluster est 192.168.1.160
Page 5 sur 7 Sur FRLEG-NET01 et FRLEG-NET02 : IMPORTANT : Le fichier de configuration des clés d'authentification doit être strictement identique sur chacun des nœuds. Créer un fichier authkeys sous /etc/ha.d/ Le fichier /etc/ha.d/authkeys permet aux nodes de cluster de s'identifier mutuellement Le mot clé auth indique quel est le système d'identification que l'on va utiliser. Si le lien n'est pas sûr physiquement, il est nécessaire d'utiliser un chiffrement md5 avec une chaîne de clé plus intelligente que celle-ci. Dans notre cas, il n'y a que les deux PROXY sur un petit réseau local et donc nous utilisons le système crc. (auth=2) Une fois le fichier édité, n'oubliez pas de le protéger en introduisant la commande : Démarrer Heartbeat sur les deux serveurs : Via la commande /etc/init.d/heartbeat start Test : Ping de l adresse ip du CLUSTER
Page 6 sur 7 Test de la bonne configuration du proxy (IP du Cluster sur le client) : Si je tante une connexion ssh sur le cluster je tombe sur FRLEG-NET01 Extinction du serveur FRLEG-NET01 : Si FRLEG-NET02 est bien configuré il prend le relais Si je tante une connexion ssh sur le cluster je tombe sur FRLEG-NET02 Internet fonctionne toujours, FRLEG-NET02 fonctionne bien en tant que proxy
Page 7 sur 7 Si maintenant je redémarre FRLEG-NET01 sans aucune autre action Si je tante une connexion ssh sur le cluster je tombe sur FRLEG-NET01, il a bien joué son rôle de maitre