Les réseaux informatiques, comme Internet, proposent de plus en plus de services. Il n'est plus rare de recevoir une facture au format numérique, de payer ses impôts sur internet, de consulter ses comptes bancaires pour effectuer des virements sécurisés,...
Ces services informatiques offerts aux clients sont souvent importants pour le bon fonctionnement des sociétés, voir critiques. Imaginons un site commercial, dont le serveur chargé du paiement est hors-service pour cause de panne matériel ou logiciel. Dans ce cas, si aucune redondance n'a été prévue, il reste à prier que la sauvegarde fonctionne correctement. La disponibilité au sens sécurité informatique est un élément nécessaire, et malheureusement souvent négligée pour des raisons de faibles moyens mis en oeuvre ou par méconnaissance des administrateurs.

1) Comment améliorer la disponibilité des services?

En effectuant des redondances matériels ou logiciels; il n'est pas rare d'employer les 2. Pour certains services importants, on redonde les serveurs avec un système de détection et de reprise automatique.
1) Les redondances physiques/matériels permettent de pallier automatiquement à une panne matériel (double/triple alimentation, double attachement réseau physique, RAID, double contrôleur RAID,...etc).
2) Les redondances logicielles tel que :

Le round robin: Le DNS réalise un partage d'une adresse entre plusieurs serveurs. C'est à dire qu'il retourne tour à tour une adresse différente en effectuant une répartition par rotation circulaire des réponses aux requêtes, ce qui ainsi permet une répartition de charge entre les serveurs. C'est une technique classique de load-balancing, mais ne protége pas d'une panne d'un serveur.

Le cluster: il s'agit d'une grappe de serveur (minimum de deux serveurs) qui partage un élément commun à tous, le quorum. Le quorum est le cœur du système, il décrit la répartition du service entre les serveurs. On distingue 2 types de cluster, l'actif/passif (ou maitre/esclave) et l'actif/actif (ou maître/maître). Cette technologie nécessite un disque partagé sous forme d'une baie de disque ou par un DFS (Distributed File System).

Le cluster hybride: Ici pas d'espace partagé (donc beaucoup moins couteux), le service est rendu indépendamment par tel ou tel noeud de la grappe. Ce système nécessite une configuration identique du service à rendre et un outil de clustering.

Concept du cluster hybride:

Le principe du cluster hybride consiste à partager une adresse virtuelle (VIP-Virtual IP) entre 2 serveurs capables de répondre aux requêtes des clients, les 2 serveurs présentent tous les 2 un service client identique et sont donc capables de répondre aux clients. Le serveur maître est celui qui détient l'adresse virtuelle, le serveur esclave teste réguliérement si le serveur maître est actif, c'est le heart-beat. Si l'esclave constate que le maître n'est plus en service, il monte immédiatement l'interface virtuelle IP pour que le service soit de nouveau disponible. Les clients quand à eux contactent le serveur maître par le biais de l'adresse VIP. A noter, que plus l'intervalle de temps de test (de présence du maître par les esclaves) est court, plus vite le serveur esclave bascule en maître et donc meilleur est la disponibilité du service client.

Nous allons étudier 2 outils linux de clustering hybride, heartbeat et keepalived.

2)Heart-beat

Heart-beat est un logiciel pour Linux du monde libre. Heart-beat signifie battement de coeur, qui symbolise le test de présence des maîtres esclaves. Heart Beat propose une architecture cluster, selon la technologie « IP Adress Takeover ». L’un des nœuds est maître, l’autre esclave. Lorsque le maître rencontre un incident, l’esclave prend le relais en récupérant l’adresse IP du serveur maître.

Les commandes de gestion de Heart Beat :

#Pour lancer le service service Heart Beat start #Pour stopper le service service Heart Beat stop #Pour recharger les fichiers de configuration service Heart Beat reload

Fonctionnement de Heart Beat :
Le fonctionnement de Heart Beat doit être fait de telle sorte que :
1. Le serveur maître s’arrête.
2. Le serveur esclave monte l’adresse IP de la gateway de sortie.
3. Le serveur esclave diffuse des trames ARP pour signaler aux serveurs de la DMZ que l’adresse MAC de la passerelle par défaut a changé.
4. Le serveur maître est à nouveau disponible.
5. Le serveur maître signale sa présence à l’esclave.
6. Le serveur esclave descend l’interface virtuelle.
7. Le serveur maître remonte l’interface virtuelle avec l’adresse IP de la passerelle de sortie. On retrouve la situation de départ.
L’adresse IP de la passerelle de sortie est une VIP (Virtual IP). Elle se déplace entre les 2 serveurs. Mais attention, il s’agit d’une adresse IP supplémentaire car les interfaces ont leurs propres adresses.

Configuration de heartbeat

Dans cet exemple, Heart Beat utilise l’interface eth0 pour envoyer des tests UDP sur le port 694. Les variables keepalive, initdead et deadtime gouvernent la rapidité de réaction de Heart Beat en cas de problème sur S1.

Le fichier authkeys pour le Serveur 1 (S1) et le serveur 2 (S2) :

#Ce fichier precise le mode d’authentification auth 1 1 crc

Le fichier haresources pour s1 et s2 :

#Ce fichier precise le service a surveiller et l’adresse VIP (160.133.100.254), httpd est le service en cluster pour notre exemple S1.domain 160.133.100.254 httpd s2.domain 160.133.100.254 httpd

Le fichier ha.cf pour s1 :

debugfile /root/fw/log/ha-debug logfile /root/fw/log/ha-log keepalive 5 initdead 30 deadtime 10 #Si on utilise la liaison serie #serial /dev/ttyS0 #baud 19200 udpport 694 #interface de heartbeat bcast eth0 nice_failback off node s1.domain node s2.domain

Le fichier ha.cf pour s2 :

debugfile /ha-debug logfile /ha-log keepalive 5 initdead 30 deadtime 10 udpport 694 #interface de heartbeat bcast eth0 nice_failback on node s1.domain node s2.domain

Exemple :
HeartBeat n’est pas en service, voici ce que donne un ifconfig sur l'interface cluster du maître.

eth1 Lien encap:Ethernet HWaddr 00:04:76:21:8C:0D inet adr:160.133.100.250 Bcast:160.133.100.255 Masque:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:14 errors:0 dropped:0 overruns:0 carrier:14 collisions:0 lg file transmission:100 RX bytes:0 (0.0 b) TX bytes:840 (840.0 b) Interruption:9 Adresse de base:0x7800

HeartBeat est en service, il a monté l’interface virtuelle avec l’adresse virtuelle 160.133.102.254.

eth1 Lien encap:Ethernet HWaddr 00:04:76:21:8C:0 inet adr:160.133.100.250 Bcast:160.133.100.255 Masque:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:14 errors:0 dropped:0 overruns:0 carrier:14 collisions:0 lg file transmission:100 RX bytes:0 (0.0 b) TX bytes:840 (840.0 b) Interruption:9 Adresse de base:0x7800 eth1:0 Lien encap:Ethernet HWaddr 00:04:76:21:8C:0D inet adr:160.133.100.254 Bcast:160.133.100.255 Masque:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 Interruption:9 Adresse de base:0x7800

3)Keepalived

Keepalived est un outil de clustering hybride pour serveur Linux, il permet comme Heart-Beat la reprise du service client par un serveur esclave. Basé sur le protocole VRRP (Virtual Redundancy Routing Protocol), Keepalived est un outil très puissant, robuste et facile à mettre en oeuvre.

Prenons l'exemple ci dessous, on veut mettre en cluster 2 serveurs avec une reprise du serveur esclave. Le principe consiste à se partager une adresse IP virtuelle, "mountée" par le serveur maître en fonctionement normal ou par le serveur esclave si le maître est indisponible. Les clients pointants vers l'adresse virtuelle, ainsi toujours joignable.

Le fichier de configuration /etc/keepalived/keepalived.conf pour le serveur maître:

! Configuration File for keepalived vrrp_instance VI_1 { state MASTER interface eth0 virtual_router_id 1 priority 100 advert_int 1 authentication { auth_type PASS auth_pass 1111 } virtual_ipaddress { 192.168.100.254 } }

Le fichier de configuration /etc/keepalived/keepalived.conf pour le serveur esclave:

! Configuration File for keepalived vrrp_instance VI_1 { state BACKUP interface eth0 virtual_router_id 1 priority 10 advert_int 1 authentication { auth_type PASS auth_pass 1111 } virtual_ipaddress { 192.168.100.254 } }

A noter que l'interface virtuelle n’apparaît pas avec la commande ifconfig mais avec ip addr list. On peut créer plusieurs interfaces virtuelles en cas de besoin.