Test de l’adresse IP virtuelle d’un cluster mirror SafeKit dans votre réseau

Ce guide décrit comment vérifier que l’adresse IP virtuelle (VIP) d’un cluster mirror SafeKit (module mirror) fonctionne correctement dans votre réseau : la VIP est détenue par le serveur principal et elle est redirigée vers le nouveau serveur principal après un basculement.

1. Principes clés

Prérequis : les deux nœuds du cluster mirror doivent se trouver dans le même sous-réseau IP de couche 2 : un LAN ou un VLAN étendu entre des sites distants.

• L’IP virtuelle (VIP) est active uniquement sur le serveur principal (états PRIM ou ALONE) : elle est définie comme un alias de l’adresse IP physique, sur la carte réseau de cette adresse, lorsque le module démarre en tant que principal sur le nœud (configuration where="one_side_alias").
• L’adresse MAC du serveur principal est donc celle associée à l’IP virtuelle (VIP) dans les tables ARP (routeur, passerelle, clients dans le même sous-réseau). Tout le trafic vers l’IP virtuelle (VIP) est envoyé au serveur principal.
• Lors d’un basculement (arrêt ou défaillance du primaire), l’IP virtuelle (VIP) est supprimée de l’ancien primaire et définie comme un alias sur le nouveau primaire. Deux mécanismes permettent alors au réseau d’associer l’IP virtuelle (VIP) à l’adresse MAC du nouveau primaire :
  • les messages réseau envoyés par le système d’exploitation lorsque l’adresse IP virtuelle (VIP) est ajoutée en tant qu’alias sur la carte réseau;
  • les GARPs (gratuitous ARP) envoyés par SafeKit, lorsque l’attribut arpreroute="on" est configuré dans la section <vip>.

Ce que vous devez donc tester :

1. l’adresse IP virtuelle (VIP) est détenue par le serveur principal et accessible depuis les clients ;
2. l’adresse MAC associée à l’IP virtuelle (VIP) est redirigée vers le nouveau serveur principal du réseau (routeur, passerelle, virtualisation) lorsque le serveur principal change.

2. Prérequis : configuration de l’adresse IP virtuelle (VIP)

1. Dans le userconfig.xml du module mirror, configurez l’adresse IP virtuelle (VIP) dans la section <vip>. L’attribut arpreroute="on" permet au nouveau primaire d’envoyer GARPs après un basculement :

   <vip>
     <interface_list>
       <interface arpreroute="on">
         <real_interface>
           <virtual_addr addr="<VIP>" where="one_side_alias"/>
         </real_interface>
       </interface>
     </interface_list>
   </vip>
   

2. Appliquez la configuration sur les deux nœuds.

3. Démarrez le module : un nœud doit être PRIM (Ready) et l’autre SECOND (Ready).

3. Test 1 – Adresse IP virtuelle (VIP) détenue par le serveur principal

Étapes

1. Sur le serveur principal, exécutez ipconfig (Windows) ou ip addr show (Linux). → Résultat attendu : l’adresse IP virtuelle (VIP) apparaît comme un alias sur la carte réseau de l’adresse IP physique.
2. Sur le serveur secondaire, exécutez la même commande. → Résultat attendu : l’adresse IP virtuelle (VIP) n’apparaît pas.
3. À partir d’un poste de travail client situé à l’extérieur du cluster, ping les deux adresses IP physiques et sur l’adresse IP virtuelle (VIP). → Résultat attendu : les trois commandes ping répondent (sauf si elles sont filtrées par des pare-feu).
4. Vérifiez l’accès via l’IP virtuelle (VIP) avec la mosaïque SafeKit : à partir d’un navigateur sur le client externe, connectez-vous à http://<VIP>:9010/safekit/mosaic.html (ou utilisez le port 9453 si le serveur Web et la console SafeKit ont été basculés vers HTTPS), puis entrez le nom du module mirror et exécutez le test. → Résultat attendu : toutes les cellules de la mosaïque affichent le nom du serveur principal, dans une seule couleur : toutes les connexions TCP à l’IP virtuelle (VIP) sont desservies par le serveur principal.

4. Test 2 – Basculement manuel (arrêt du serveur principal)

Ce test vérifie que l’adresse IP virtuelle (VIP) suit le serveur principal lors d’un basculement, déclenché par l’arrêt du module sur le serveur principal.

Étapes

1. Arrêtez le module sur le primaire (nœud 1) à partir de la console SafeKit (ou à partir de la ligne de commande avec safekit stop -m <module>). → Résultat attendu : le nœud 1 passe à STOP (NotReady) et le nœud 2 passe à ALONE (Ready). Dans le journal du nouveau primaire, le message Virtual IP <VIP> set apparaît.
2. Sur la nouvelle interface primaire, exécutez ipconfig ou ip addr show. → Résultat attendu : l’adresse IP virtuelle (VIP) apparaît désormais comme un alias sur ce nœud, et non plus sur l’ancien nœud principal.
3. Depuis le poste de travail client, répétez les trois commandes ping et exécutez à nouveau la mosaïque sur l’adresse IP virtuelle (VIP). → Résultat attendu : tout répond, et toutes les cellules de la mosaïque affichent maintenant le nom du nouveau primaire, dans une seule couleur.
4. Redémarrez le module sur le nœud 1 : il se resynchronise et passe à SECOND (Ready), tandis que le nœud 2 passe à PRIM (Ready).

5. Test 3 – Vérification du réacheminement MAC avec arp -a

Notez l’adresse MAC associée à l’adresse IP virtuelle (VIP) avant le basculement, puis vérifiez qu’elle a changé après.

Ce test n’est possible que si le poste de travail client se trouve dans le même sous-réseau IP que le cluster.

S’il y a un routeur entre le client et le cluster, la table ARP du client ne contient pas l’IP virtuelle (VIP), mais l’adresse de la passerelle utilisée pour atteindre le réseau du cluster. Dans ce cas, vérifiez la table ARP du routeur ou de la passerelle avec l’équipe réseau.

Étapes

1. Le module est PRIM (Ready) sur le nœud 1 et SECOND (Ready) sur le nœud 2.
2. Sur le poste de travail client, ping sur les deux adresses IP physiques et sur l’adresse IP virtuelle (VIP), puis exécutez arp -a. → Résultat attendu : l’adresse IP virtuelle (VIP) est associée à la même adresse MAC que l’adresse IP physique du serveur principal.
3. stop le module sur le primaire (nœud 1).
4. Effectuez un nouveau ping) sur l’adresse IP virtuelle (VIP), puis exécutez à nouveau arp -a. → Résultat attendu : l’adresse IP virtuelle (VIP) est maintenant associée à la même adresse MAC que l’adresse IP physique du nouveau serveur principal.

Effectuez un nouveau ping de l’adresse IP virtuelle (VIP) avant de lire la table ARP : l’entrée peut être marquée comme obsolète et ne sera actualisée qu’après un ping.

Exemple de la table ARP attendue, avant et après l’arrêt du serveur principal :

6. Test 4 – Vérification de bout en bout avec Wireshark (Windows) ou tcpdump (Linux)

Vous pouvez suivre une connexion TCP vers l’IP virtuelle (VIP) en capturant les paquets sur le client et sur les deux nœuds : avec Wireshark sur les machines Windows, et avec tcpdump sur les machines Linux.

Vous devez regarder les en-têtes MAC (Ethernet) des paquets : l’adresse IP de destination reste l’IP virtuelle (VIP), et c’est l’adresse MAC de destination qui indique quel nœud reçoit le trafic.

Ce que vous devez observer :

Si le poste de travail client se trouve dans un sous-réseau différent de celui du cluster, l’adresse MAC client vue sur les nœuds est l’adresse MAC de la passerelle (routeur) connectant les deux sous-réseaux, et non celle du poste de travail client.

7. À partir de quels postes de travail effectuer les tests

Le comportement dépend du chemin réseau entre le client et le cluster. Exécutez les tests 1 et 2 à partir de chaque type de client pertinent pour votre architecture :

8. Synthèse des résultats attendus

9. Dépannage

• L’adresse IP virtuelle (VIP) ne répond plus après le basculement : les messages de réacheminement MAC ne sont pas pris en compte par un périphérique sur le chemin (routeur, passerelle, commutateur virtuel), qui continue d’envoyer du trafic à l’adresse MAC de l’ancien périphérique principal. Vérifiez la gestion des messages de réacheminement MAC avec votre équipe réseau.
• Envoi GARPs : l’attribut arpreroute="on" de la section <vip> (avec arpinterval et arpelapse) envoie GARPs régulièrement sur l’IP virtuelle (VIP) après le basculement. Voir le Guide de l’utilisateur, section 13.6.4 « Syntaxe <vip> ».
• Diagnostic de la résolution IP virtuelle (VIP) ↔ MAC : consultez le Guide de l’utilisateur, section 7.24 « Dépannage de la résolution IP virtuelle (VIP) ↔ MAC », et la section 7.16 « Problème avec l’IP virtuelle après le basculement ».

Pour plus d’informations :

• Comment fonctionne une adresse IP virtuelle dans un cluster de haute disponibilité ?
• Pour l’équilibrage de charge avec une adresse IP virtuelle, consultez la section Test de l’adresse IP virtuelle d’équilibrage de charge dans un cluster farm.