> Tech > Annoncer la présence de la VIPA pour fournir la tolérance aux pannes

Annoncer la présence de la VIPA pour fournir la tolérance aux pannes

Tech - Par Renaud ROSSET - Publié le 19 décembre 2012
email

Les deux méthodes permettant de résoudre cette énigme passent par la publicité de la VIPA.

La première est proxy ARP, qui permet à une unité de s’identifier elle-même, et la seconde est RIPv2 en utilisant le Router Daemon (RouteD). Voyons d’abord la méthode proxy ARP. Si une interface doit en contacter une autre, elle regarde d’abord si elle a configuré ou mis en cache de l’information sur la manière d’y parvenir. Dans la négative, elle émet une requête ARP. Les autres unités présentes sur le subnet répondent à la requête si elles sont elles-mêmes la cible ou si elles connaissent le moyen d’atteindre la cible. Donc, un serveur pourrait répondre par son adresse MAC, ou un routeur par la promesse d’envoyer ce paquet à la bonne destination.

Annoncer la présence de la VIPA pour fournir la tolérance aux pannes

Mais vous ne pouvez pas enficher une VIPA dans le réseau. Jusqu’à ce que le cable Ethernet virtuel soit créé, une interface physique doit répondre pour la VIPA. Cette interface « proxy » répond avec son adresse MAC aux requêtes ARP. Les unités envoient ensuite le paquet à l’adresse physique et journalisent l’adresse MAC dans leur cache ARP (c’est aussi la raison pour laquelle une VIPA seule ne peut pas faire l’équilibrage de charge entrant—même si une interface physique différente répond à chaque requête ARP, une nouvelle requête ne sera pas faite par une unité avec une route valide dans son cache ARP jusqu’à ce que ce cache expire ou soit effacé).

C’est parfait pour les unités qui se trouvent sur le même subnet que la VIPA, mais qu’en est-il de celles qui se trouvent de l’autre côté du routeur ? Si la VIPA est contiguë aux adresses du subnet, le routeur annoncera tout le trafic dans cet espace d’adresses, et l’entrée dans le cache ARP du routeur se chargera du reste. Ainsi, comme dans l’exemple précédent, le routeur annonce toutes les adresses dans la plage 172.20.1.0/24. Quand un paquet dirigé vers la VIPA 172.20.1.4 rencontre ce routeur, il regarde dans son cache ARP. S’il n’y a pas d’entrée, le routeur envoie une requête ARP à l’un quelconque des proxies, disons 172.20.1.3, qui répond avec son adresse.

Dans l’IBM i 5.4 et versions ultérieures, il y a une liste d’interfaces préférées pour la VIPA quand on utilise proxy ARP. Si la première d’entre elles est indisponible, la suivante dans l’ordre devient associée à la VIPA, comme le montre la figure 5. Dans cet exemple, vous pourriez choisir les interfaces désirées (dans le cas présent, 172.16.1.2 et 172.16.1.3) et cliquer sur Add pour chacune à tour de rôle pour l’ajouter à la liste des interfaces préférées. Pour plus de détails (et un aperçu d’autres astuces TCP/IP), voir l’IBM Redpaper Tips and Techniques for Using TCP/IP on i5/OS.

Aussi à partir de la 5.4, vous pouvez utiliser proxy ARP pour annoncer une VIPA sur un subnet différent, mais seulement avec Local Area Mobility (LAM) de Cisco dans IOS (pas « notre » IBM i OS, mais celui de Cisco). Vous pourriez procéder ainsi dans le cas où un système IBM i est déplacé en permanence d’un subnet dans un autre. Le système est connecté physiquement à un subnet distant différent, mais les routeurs validés LAM Cisco diffusent encore « l’ancienne » adresse (qui est maintenant une VIPA) et la route qui y conduit vers le nouveau subnet. Pour un aperçu de cette configuration, voir le document IBM « Virtual IP – Load Balancing, Fault Tolerance, & IOA Sharing ».

Et si vous voulez réellement utiliser VIPA pour DR sur un autre système puis revenir ? Et si votre machine de production à l’adresse 10.1.3.10/24 se trouve en Californie et votre système de secours (DR) à l’adresse 10.2.4.10/24 se trouve dans le New Jersey ? Le routeur Californie annoncera les adresses 10.1.3.1–10.1.3.254, donc si vous créez une VIPA telle que 10.1.3.11, elle ne fonctionnera pas sur le réseau New Jersey 10.2.4.0 avec proxy ARP (sauf avec LAM, comme indiqué précédemment, mais alors comment la ramener rapidement ?).

Dans ce cas, pour créer une VIPA qui peut aller d’un subnet à un autre et revenir, vous créez une VIPA qui est unique. Ce pourrait être n’importe quelle adresse que vous n’utilisez pas sur votre réseau. S’il n’est pas nécessaire que ce soit une adresse publique (c’est-à-dire atteignable par Internet sans NAT)—utilisez simplement une adresse d’un réseau non utilisée ailleurs dans votre société. Dans l’exemple avec 192.168.1.10, vous créeriez d’abord la VIPA sur les deux systèmes : production et secours (DR). En effet, l’adresse ne sera active que sur l’un de ces systèmes à la fois. Si le clustering est actif, cela sera traité automatiquement. Pour plus de détails sur cette option automatique, voir « Enabling application switchover across subnets » dans l’IBM Information Center.

Une fois la VIPA établie sur les deux systèmes, ne l’associez pas à une interface physique au moyen de proxy ARP (il ne doit pas y avoir d’interfaces associées, et la case proxy ARP doit rester non cochée). Mais alors, comment le monde connaît-il existence de cette adresse ? Cette question nous amène à la seconde méthode d’annonce, ou de publicité, de la VIPA.

Routing Information Protocol, ou plus spécifiquement RIPv2, est un protocole de routage qui permet à des unités d’envoyer des routes à des routeurs et à des unités sur un réseau. Autrement dit, au lieu de configurer manuellement des routes statiques au travers du réseau, un job sur le système IBM i diffuse la route. Ce job est le Router Daemon, connu aussi sous le nom de RouteD.

Sur le système qui devrait actuellement annoncer la VIPA, RouteD doit être configuré et actif. Pour changer la configuration de RouteD à partir de l’écran vert, vous pouvez utiliser la commande WRKRTDCFG. Pour changer la configuration de RouteD avec Navigator, sélectionnez Network, Servers, TCP/IP, puis faites un clic droit sur RouteD et sélectionnez Properties. Pour plus de détails sur la configuration au travers de la GUI (et pour bien d’autres informations intéressantes), voir l’IBM Redbook IBM i5/OS IP Networks: Dynamic.

L’une ou l’autre des méthodes vous permet d’éditer le fichier de configuration de RouteD, en ajoutant des instructions qui annoncent la VIPA aux autres unités du réseau. Dans notre exemple dans lequel les éléments physiques sont 10.1.3.10 et 10.1.3.11 sur le serveur de production et la VIPA est 192.168.1.10, il y aura probablement des instructions de ce genre dans votre configuration:

RIP_INTERFACE 10.1.3.10 31 SUPPLY RIP2 FORWARD.COND
192.168.1.10 32 NOFORWARD 0.0.0.0 MASK 0.0.0.0 BLOCK 0.0.0.0
MASK 0.0.0.0

Cette instruction signifie que pour la plage d’adresses 10.1.3.10 masque 255.255.255.254 (31 bits—donc c’est juste les deux adresses physiques 10.1.3.10 et 10.1.3.11), la VIPA 192.168.1.10 masque 255.255.255.255 (32 bits) sera annoncée sur ces éléments physiques. Le .COND signifie que cela ne se produit que si les éléments physiques sont actifs. Les instructions NOFORWARD et BLOCK empêchent que les autres réseaux ne soient reçus ou annoncés par ce job.

Avant de démarrer le job RouteD, vérifiez que votre réseau est prêt pour cela ! En effet, tous les routeurs ne sont pas configurés pour RIPv2, et peut-être d’autres unités sur le réseau utilisent ce protocole. Donc, voyez cela de très près avec votre équipe réseau. Assurez-vous que RouteD est en mesure d’annoncer des routes et de démarrer en même temps que TCP/IP. Faites cela dans Navigator ou avec la commande Change RouteD Attributes (CHGRTDA). Vous pouvez le régler pour qu’il démarre en même temps que TCP/IP ou le démarrer manuellement, mais il doit être démarré pour que les autres unités puissent atteindre la VIPA. Pour plus de détails sur RouteD, voir le document IBM « System i – Networking RouteD – Version 6 Release 1 » (tinyurl.com/yleavjt) et le document technique IBM « Fault Tolerance Configuration for the IBM System i Server Using Virtual IP. » (tinyurl.com/yffuov9)

Sur le système de secours (DR), vous pouvez démarrer RouteD également, mais assurez-vous que les interfaces physiques et la VIPA sont à l’arrêt. Si elles sont actives et si celles de production le sont également, les deux jobs Router Daemon annonceront des routes vers leurs adresses physiques. Tout cela fera un peu désordre !

Si tout est bien en place, vous aurez la tolérance aux pannes sur un système donné (si l’un des éléments physiques est défaillant, la VIPA utilisera automatiquement l’autre parce que RouteD n’annoncera que les actifs) et—mieux encore—la possibilité, en quelques instants, de basculer d’un système à un autre.

Si New Jersey est défaillant (ou même si vous arrêtez volontairement les interfaces), une fois que la VIPA est arrêtée sur la boîte de production et activée sur le système DR, les utilisateurs visant la VIPA se connecteront au système Californie presque directement. Je dis « presque, » parce qu’il y a en général un léger délai de quelques secondes (ou minutes, selon votre réseau) pour que les routes soient annoncées. Même dans ce cas, la transition est douce pour les utilisateurs. Si cette organisation s’accompagne d’une bonne réplication, les utilisateurs pourraient même ne pas s’apercevoir qu’ils sont sur un système différent. À tout le moins, les utilisateurs n’auront plus sur leurs ordinateurs une icône pour la production et une pour le secours (DR) !

Ces deux méthodes pour annoncer la VIPA montrent sa grande capacité à fournir la tolérance aux pannes, à la fois sur les adaptateurs physiques dans un système et entre des systèmes séparés. Bien entendu, les bonnes pratiques sont de mise : toujours éviter des points de défaillances uniques. Par exemple, si vous vous donnez le mal d’avoir des NIC multiples avec une VIPA pour la tolérance aux pannes dans un système, n’affaiblissez pas la résilience de la configuration en enfichant toutes les NIC dans le même commutateur ! Vous devez répartir les ressources. Si possible, ayez chaque NIC dans un rack différent, sur une alimentation différente, attachée à un commutateur différent, et ainsi de suite. Votre mécanisme de tolérance aux pannes sera inutile pour vos utilisateurs si, à cause d’une négligence, ils ne peuvent quand même pas parvenir au système !

Téléchargez cette ressource

Cybersécurité des collectivités : Enjeux, Perspectives & Solutions

Cybersécurité des collectivités : Enjeux, Perspectives & Solutions

Villes, intercommunalités, métropoles, départements et régions sont particulièrement exposés aux risques de cybersécurité. Ce livre blanc Stormshield présente les défis cyber que rencontrent les collectivités, les solutions et perspectives pour qu’elles puissent assurer leur mission d’utilité publique, en toute sécurité.

Tech - Par Renaud ROSSET - Publié le 19 décembre 2012