Pour mieux comprendre le déploiement d'un cluster VRRP avec PineApp

A travers un exemple concret, nous proposons une méthode et des outils pour déployer un cluster PineApp basé sur le Protocole de Redondance Virtuel de Routeur (VRRP) . L'intérêt final est de bénéficier d'une architecture redondante avec répartition de charge ceci sans l'adjonction d'un matériel complémentaire tiers.

Le protocole VRRP est fréquemment utilisé pour réaliser une telle architecture. Pour en savoir plus sur VRRP:

VRRP - Wikipedia, the free encyclopedia :

RFC3768 - RFC3768 actualise RFC2338 : au format PDF (37,29 Ko)

RFC2338: au format PDF (34,34 Ko)

Le protocole VRRP est une norme ouverte et les équipements réclamant le support de VRRP se conforment aux caractéristiques présentées dans la RFC 3768 (actualisant la RFC 2338). Chaque unité d’une paire envoie des paquets pour voir si l'autre répond. Si l'unité d’envoi n'obtient pas de réponse de son associé, alors l'unité suppose que son associé est coupé et commence à assurer ses fonctions.

VRRP envoie des paquets à l'adresse multicast 224.0.018. Ce point est à noter lors d’une intégration avec des équipements de filtrage IP ou un pare-feu. VRRP exige que les deux unités puissent communiquer l’une avec l’autre.

Un aperçu de la structure du protocole VRRP

Lors de nos vérifications, nous devrons constater l'organisation suivante des données:

En résumé, les RFCs commentent ces données en précisant:

• Version -- The version field specifies the VRRP protocol version of this packet. This version is version 2.
• Type -- The type field specifies the type of this VRRP packet. The only packet type defined in this version of the protocol is: 1 ADVERTISEMENT.
• Virtual Rtr ID -- The Virtual Router Identifier (VRID) field identifies the virtual router this packet is reporting status for.
• Priority -- Specifies the sending VRRP router"s priority for the virtual router. VRRP routers backing up a virtual router MUST use priority values between 1-254 (decimal).
• Count IP Addresses --The number of IP addresses contained in this VRRP advertisement.
• Auth Type -- Identifies the authentication method being utilized.
• Advertisement Interval -- Indicates the time interval (in seconds) between advertisements.
• Checksum --  used to detect data corruption in the VRRP message.
• IP Address(es) -- One or more IP addresses that are associated with the virtual router. The number of addresses included is specified in the "Count IP Addrs" field. These fields are used for troubleshooting misconfigured routers.
• Authentication Data -- The authentication string is currently only utilized for simple text authentication. It is up to 8 characters of plain text.

Heureusement, l'implémentation de VRRP par PineApp nous simplifie le déploiement en nous demandant de fixer seulement deux valeurs "Virtual Rtr ID" (désignée par "LB ID" selon l'ergonomie PineApp) et Priority:

• Virtual Rtr ID (ou "LB ID") -- est un entier (sur 8 bits) qui devra être le même pour chaque Appliance du cluster (110, dans notre exemple)
• Priority -- est aussi un entier (sur 8 bits). Les RFCs précisent que les valeurs 0 et 255 sont réservées et que 100 est la valeur par défaut pour un backup (dans notre exemple: la valeur du "master" sera 250 et celle du "slave" sera donc de 100).

Pour vérifier que notre déploiement VRRP utilise effectivement cette structure, nous analyserons le trafic IP avec Wireshark qui permet de rejouer les captures:

Pour télécharger Wireshark : http://www.wireshark.org Copyright 1998-2007 Gerald Combs gerald@wireshark.org and contributors.

Description de notre plate-forme pour tester le cluster VRRP avec PineApp

Dans la DMZ d'un pare-feu, nous avons installé le cluster sur un simple HUB pour nous assurer que les paquets de multicast à l'adresse 224.0.018 ne soient pas filtrés :

La description de la plate-forme utilisée lors de nos tests : au format PDF (649,90 Ko)

L'extrait du manuel PineApp pour comprendre le cluster : au format PDF (196,18 Ko)

Pour résumer les informations demandées par le VRRP de PineApp (hors des adresses IP), il suffit de fixer le "LB ID" (110 dans notre exemple) et les priorités (250 et 100 dans notre exemple).

L'écran de configuration de l'Appliance "master" nommé "MailSecure-1":

Cliquez sur l'image pour l'agrandir...

L'écran de configuration de l'Appliance "slave" nommé "MailSecure-2":

Cliquez sur l'image pour l'agrandir...

Les résultats de nos tests et les captures IP pour visualiser le "Failover" du cluster

L'adresse virtuelle du cluster est 10.0.0.10. Les adresses réelles des Appliances sont 10.0.0.11 (le "master" avec la priorité 250) et 10.0.0.12 (le "slave" avec la priorité 100). Pour observer la tolérance "Failover", nous avons débranché  et reconnecté alternativement les boîtiers au HUB :

• Jusqu'à la frame 36 -- Les deux boîtiers sont actifs et 10.0.0.11 annonce "VRRP Announcement (V2)".
• Frame 37 -- L'Appliance 10.0.0.11 a été déconnecté du HUB. L'Appliance 10.0.0.12 prend la main et annonce "VRRP Announcement (V2)" à son tour.
• Frame 38 -- Un Broadcast "Gratuitous ARP" est émis.
• Jusqu'à la frame 89 -- L'Appliance 10.0.0.12 est seul et annonce "VRRP Announcement (V2)".
• Frame 90 -- L'Appliance 10.0.0.11 a été reconnecté du HUB. Il reprend la main et annonce "VRRP Announcement (V2)".
• Frame 94 -- Un Broadcast "Gratuitous ARP" est émis.
• Jusqu'à la frame 154 -- Les deux Appliances sont présents et 10.0.0.11 annonce "VRRP Announcement (V2)".
• De la frame 155 à 199 -- L'Appliance 10.0.0.12 a été déconnecté du HUB. L'Appliance 10.0.0.11 annonce "VRRP Announcement (V2)" et cherche périodiquement 10.0.0.12.
• A partir de la frame 200 -- L'Appliance 10.0.0.12 a été reconnecté du HUB. Les deux Appliances sont présents et 10.0.0.11 annonce "VRRP Announcement (V2)".
• Frame 270 -- L'Appliance 10.0.0.11 a été déconnecté du HUB. L'Appliance 10.0.0.12 prend la main et annonce "VRRP Announcement (V2)" à son tour. Un ping -t sur 10.0.0.10 est actif.
• Frame 271 -- Un Broadcast "Gratuitous ARP" est émis.
• Jusqu'à la frame 311 -- L'Appliance 10.0.0.11 est reconnecté...
• Etc...

Si vous avez téléchargé l'outil Wireshark, vous pouvez rejouer nos captures IP:

Pour observer une trame frame8 : au format PDF (74,94 Ko)

Une copie de l'écran Ethereal avec de la frame n°8 :

Cliquez sur l'image pour l'agrandir...

Les résultats de nos tests pour visualiser le "Load Balancing" du cluster

La fonction de répartition de charge est plus facile à observer car il suffit de consulter les logs : au format PDF (101,67 Ko)