VIPA : qu’est-ce que c’est et à quoi ça sert ?

Bien entendu, l’IBM i gère beaucoup d’interfaces simultanées (autant que d’adaptateurs possibles, plus quelques-unes comme Ethernet virtuel et OptiConnect virtuel). Il est d’ailleurs tout à fait possible d’avoir un même système IBM i sur plusieurs réseaux en même temps. Ce sera le cas, par exemple, après une fusion, lorsque deux sociétés ou plus accèdent aux mêmes applications sur le même serveur IBM i à partir de leurs réseaux respectifs. Chaque interface sur un tel système aurait des adresses IP spécifiques au réseau sur lequel chacune réside. VIPA pousse plus loin ce concept en autorisant une adresse IP qui continue à utiliser une interface sans lui être forcément attribuée ou assignée. En fait, à n’importe quel moment, elle pourrait utiliser une interface parmi plusieurs !

Cette approche présente plusieurs avantages :

VIPA, Redondance et basculement

En premier lieu,VIPA peut ajouter une couche de redondance. Si l’une des interfaces physiques associée à la VIPA est défaillante, une autre peut prendre le relais. À l’autre bout, les clients ne remarquent pas le basculement parce que l’adresse IP cible qu’ils utilisent rester inchangée. Comme nous le verrons plus loin, on peut élargir ce concept pour permettre une transition directe d’un serveur sur un autre, même si ceux-ci se trouvent sur des subnets différents.

Il se pourrait donc que des utilisateurs visent votre système de production et soient ensuite dirigés vers votre système de secours (DR) situé ailleurs sur un autre réseau. Avec le clustering tel qu’il existe dans l’IBM i, ce déplacement peut être rendu automatique. Le clustering lui-même n’entre pas dans le cadre de cet article, mais, même sans lui, il est possible de faire basculer manuellement la VIPA d’un serveur sur un autre. Dans la pratique, il peut y avoir un timeout pendant la commutation, mais les applications TCP/IP s’en accommodent fort bien.  Certaines se déconnecteront peut-être, mais l’important est que, quand elles se reconnecteront, elles seront dirigées vers le nouveau serveur sans changer leur adresse IP cible et sans qu’il soit nécessaire de promulguer un changement d’entrée DNS.

Bien entendu, les applications actives sur votre serveur de secours (DR) doivent être prêtes pour les utilisateurs qui étaient précédemment connectés en production ! Si vos données sont désynchronisées, vous risquez des ennuis. Mais il y a plusieurs applications HA/DR confirmées pour s’occuper de cela. Cela non plus n’entre pas dans le cadre de cet article. Comme je l’ai dit, les services de clustering existant pour l’IBM i sont à noter ici. Avec une application reconnaissant le cluster, il se peut que ce passage de la production au secours (DR) passe vraiment inaperçu aux yeux des utilisateurs. La technologie VIPA que j’expose a pour effet de permettre le basculement automatique avec le clustering.

Équilibrage de charge

Outre la redondance et le basculement, VIPA peut aussi vous permettre une répartition sur vos interfaces physiques. Bien que VIPA par elle-même ne puisse pas équilibrer la charge du trafic entrant, elle peut collaborer avec des unités d’équilibrage de charge externes. Ces unités peuvent attribuer, à tour de rôle, le trafic entrant aux interfaces physiques associées à la VIPA.

VIPA peut être considérée comme plus « tournée vers l’extérieur, » mais, plus loin dans cet article, je parlerai aussi d’une configuration associée qui peut laisser des paquets sortants se répartir sur des interfaces. Cela peut s’avérer utile lorsque le trafic sur une interface physique donnée menace de saturer la NIC. Par exemple, dans le cas d’applications à large bande passante, comme la journalisation à distance.

Transitions de serveurs directes

VIPA permet aussi au serveur d’être connu par deux réseaux privés différents par une seule adresse IP. Cela peut être utile dans des cas comme l’exemple de fusion dont j’ai parlé précédemment, particulièrement quand chaque firme a un espace d’adresses privé qui chevauche l’autre. Souvent, dans de tels cas, les réseaux sont joints entre eux par la Network Address Translation (NAT) afin d’éviter des adresses IP en double. Généralement, le but est de réadresser les unités dans un espace d’adresses, mais souvent cela prend du temps. Pendant cette période intermédiaire, les unités des deux réseaux peuvent avoir besoin de cibler les mêmes serveurs. VIPA permet cela en introduisant une adresse valide pour les deux réseaux. De cette manière, quand les réseaux sont entièrement fusionnés, il n’est pas nécessaire de changer à nouveau les machines et les entrées DNS pour refléter une nouvelle adresse pour le serveur. Cependant, cette approche présente quelques inconvénients, que nous verrons plus loin.