Utilisation de la haute disponibilité (HA) et de VRRP

IBM Cloud® Virtual Router Appliance (VRA) prend en charge le protocole VRRP (Virtual Router Redundancy Protocol) en tant que protocole de haute disponibilité. Le déploiement des unités s'effectue de manière active/passive, avec une machine principale et une autre machine de secours. Toutes les interfaces sur les deux machines sont membres du même groupe de synchronisation ("sync-group"). Par conséquent, si une défaillance survient sur l'une des interfaces, les autres interfaces du même groupe sont également défaillantes et l'unité cesse d'être l'unité principale. La machine de secours détecte que la machine principale ne diffuse plus les messages de type keepalive/heartbeat (conservation de connexion active/signal de présence) et prend le contrôle des adresses IP virtuelles VRRP pour devenir la machine principale.

VRRP est la partie la plus importante de la configuration lors de la mise à disposition de passerelles. La fonctionnalité de haute disponibilité (HA) dépend des messages de signal de présence ; par conséquent, il est essentiel de s'assurer que ceux-ci ne sont pas bloqués.

Adresses IP virtuelles (VIP) VRRP

L'adresse IP virtuelle VRRP pour dp0bond1 ou dp0bond0 ou VIP est l'adresse IP flottante qui passe de l'unité principale à l'unité de secours lors du basculement. Lors du déploiement d'un dispositif VRA, celui-ci possède une connexion réseau de liaisons publiques et privées et des adresses IP réelles affectées sur chaque interface. Une adresse VIP est également affectée sur les deux interfaces, que l'unité soit autonome ou fasse partie d'une paire à haute disponibilité. Le trafic possédant une adresse IP de destination dans des sous-réseaux sur des réseaux locaux virtuels (VLAN) associés au dispositif VRA est envoyé directement à ces adresses VIP VRRP via une route statique sur le routeur FCR/BCR.

Vous ne devez jamais changer les adresses IP virtuelles VRRP pour les groupes de passerelles ni désactiver l'interface VRRP. Ces adresses IP constituent une méthode de routage du trafic vers la passerelle lorsqu'un réseau local virtuel est associé. Par conséquent, si elles sont arrêtées, le trafic VLAN l'est également. Si l'adresse IP n'est pas présente, le trafic ne peut pas être acheminé depuis le routeur BCR/FCR vers le dispositif VRA lui-même. Cette adresse virtuelle ou VIP n'est pas modifiable pour le moment. Cette limitation pourra changer à l'avenir, mais actuellement, ni la migration d'un dispositif VRA entre des routeurs POD/FCR/BCR ni la modification de l'adresse VIP n'est prise en charge.

Vous trouverez ci-dessous un exemple pour les configurations par défaut des adresses VIP dp0bond0 et dp0bond1 pour un dispositif VRA spécifique. Notez que vos adresses IP et vrrp-groups peuvent être différentes de l'exemple.

set interfaces bonding dp0bond0 vrrp vrrp-group 2 virtual-address '10.127.170.1/26'
set interfaces bonding dp0bond1 vrrp vrrp-group 2 virtual-address '159.8.98.209/29'

Pour plus d'informations, voir Sous-réseaux VLAN associés avec VRRP.

Par défaut, VRRP est défini sur désactivé. Ainsi, les nouvelles mises à disposition et les rechargements ne causent pas d'indisponibilités sur l'unité maître. Pour que le trafic VLAN fonctionne, le VRRP doit être réactivé une fois la mise à disposition ou un rechargement terminé. L'exemple suivant détaille la configuration par défaut :

set interfaces bonding dp0bond0 vrrp vrrp-group 2 'disable'
set interfaces bonding dp0bond1 vrrp vrrp-group 2 'disable'

Pour activer VRRP sur ces deux interfaces après une mise à disposition ou un rechargement, ce qui est nécessaire pour les dispositifs autonomes et les paires à haute disponibilité, exécutez les commandes ci-dessous. Ensuite, validez la modification :

delete interfaces bonding dp0bond0 vrrp vrrp-group 2 'disable'
delete interfaces bonding dp0bond1 vrrp vrrp-group 2 'disable'

Groupe VRRP

Un groupe VRRP est constitué d'un cluster d'interfaces ou d'interfaces virtuelles qui fournissent la redondance pour une interface principale (ou maître) dans le groupe. Le groupe VRRP définit l'élément virtual_router_id dans la configuration Keepalive. Dans le protocole VRRP lui-même, il s'agit de VRID. Le groupe VRRP possède un identificateur numérique unique et jusqu'à 20 adresses IP virtuelles peuvent lui être affectées.

L'ID du groupe VRRP est attribué par IBM Cloud et ne doit pas être modifié. Lorsqu'un nouveau groupe de passerelle est mis à disposition derrière un routeur Frontend Client Router (FCR)/Backend Customer Router (BCR) pour la première fois, il reçoit un groupe VRRP de 1. Les mises à disposition du groupe de passerelle suivant incrément cette valeur pour éviter les conflits. Par exemple, le groupe suivant est le groupe 2, puis le groupe 3, et ainsi de suite. Ce numéro est calculé et attribué par le processus de mise à disposition. La modification de cette valeur risque de créer un conflit avec d'autres groupes actifs et de générer des conflits maître/maître, ce qui peut entraîner une indisponibilité dans les deux groupes de passerelles.

Si vous effectuez une migration à partir d'une configuration antérieure, il est recommandé de vérifier votre code de configuration pour vous assurer que l'ID du groupe VRRP n'est pas attribué de manière statique.

L'ID du groupe VRRP est conservé dans la base de données. Par conséquent, la même valeur d'ID de groupe est utilisée lors d'un rechargement ou d'une mise à niveau du système d'exploitation. Tout ID de groupe VRRP modifié par un utilisateur est écrasé par la valeur affectée par le système lors d'un rechargement du système d'exploitation.

Priorité VRRP

La première machine dans un groupe de passerelles est associée à la priorité 254, et cette valeur est diminuée pour l'unité mise à disposition suivante. Vous ne devez jamais définir une priorité avec la valeur 255, car elle définit le "propriétaire d'adresse" VIP et peut induire un comportement non souhaité lorsque la machine est mise en ligne avec une configuration différente de celle de la machine principale (maître) active en cours d'exécution.

Préemption VRRP

La fonction de préemption doit toujours être désactivée sur toutes les interfaces VRRP, de sorte qu'une nouvelle unité ou une unité soumise au rechargement de son système d'exploitation n'essaie pas de prendre le contrôle du cluster.

Intervalle de publication VRRP

Pour signaler qu'elle est toujours en service, l'interface maître ou VIF envoie des paquets de type "signal de présence" nommés "annonces" au segment de réseau local en utilisant les adresses de multidiffusion affectées par l'IANA pour VRRP (224.0.0.18 pour IPv4 et FF02:0:0:0:0:0:0:12 pour IPv6).

Par défaut, l'intervalle est défini sur 1. Cette valeur peut être augmentée, mais il n'est pas recommandé de définir une valeur supérieure à 5. Sur un réseau très actif, largement plus d'une seconde peut être nécessaire pour que tous les avis VRRP arrivent sur l'unité de secours à partir du maître. Une valeur de 2 doit donc être utilisée pour les réseaux à fort trafic.

Synchronisation VRRP (sync-group)

Les interfaces figurant dans un groupe de synchronisation VRRP ("sync group") sont synchronisées de sorte que si l'une d'entre elles bascule sur l'unité de secours, toutes les interfaces du groupe suivent et basculent également sur l'unité de secours. Par exemple, en cas de défaillance d'une interface sur un routeur maître, le routeur complet bascule sur un routeur de secours.

Cette valeur est différente de celle du groupe VRRP, car elle définit quelles sont les interfaces d'une unité qui basculent lorsqu'une interface de ce groupe enregistre une défaillance. Il est recommandé que toutes les interfaces appartiennent au même groupe de synchronisation (sync-group) ; autrement, certaines interfaces seront des interfaces maîtres et posséderont des adresses IP de passerelle et d'autres seront des interfaces de secours, et le trafic ne sera plus acheminé correctement. Les configurations de type actif/actif ne sont pas prises en charge.

Compatibilité RFC de VRRP

La fonction de compatibilité RFC active ou désactive les adresses MAC RFC 3768 pour VRRP sur une interface. Cette fonction doit être activée sur les interfaces natives, mais désactivée sur toutes les interfaces VIF configurées. Certains commutateurs virtuels (la plupart VMware) ont des problèmes lorsque cette fonction est activée ; ils entraînent la suppression du trafic qui n'est plus envoyé à l'adresse IP de passerelle depuis la machine hôte (hyperviseur). Ne configurez pas ce paramètre pour les interfaces VIF.

Authentification VRRP

Si un mot de passe est défini pour l'authentification VRRP, le type d'authentification doit également être défini. Si le mot de passe est défini alors que le type d'authentification ne l'est pas, le système génère une erreur lorsque vous essayez de valider la configuration.

De même, vous ne pouvez pas supprimer le mot de passe VRRP sans supprimer aussi le type d'authentification VRRP. Autrement, le système génère une erreur lorsque vous essayez de valider la configuration. Si vous supprimez à la fois le mot de passe et le type d'authentification VRRP, l'authentification VRRP est désactivée.

L'IETF a décidé que l'authentification ne doit pas être utilisée pour VRRP version 3. Pour plus d'informations, voir RFC 5798 VRRP.

Prise en charge des versions 2/3

VRA prend en charge les protocoles VRRP version 2 (valeur par défaut) et version 3. Dans la version 2, vous ne pouvez pas avoir des adresses IPv4 et des adresses IPv6 simultanément ; toutefois, c'est possible dans la version 3.

Réseau privé virtuel (VPN) à haute disponibilité avec VRRP

VRA offre la possibilité de conserver la connectivité via un tunnel IPsec en utilisant une paire d'unités IBM Cloud® Virtual Router Appliance avec VRRP. Lorsqu'un routeur tombe en panne ou est arrêté à des fins de maintenance, le nouveau routeur maître VRRP restaure la connectivité IPsec entre les réseaux locaux et distants.

Lorsque vous configurez un réseau privé virtuel à haute disponibilité avec VRRP, dès qu'une adresse virtuelle VRRP est ajoutée à une interface VRA, vous devez réinitialiser le démon IPsec. En effet, le service IPsec est uniquement à l'écoute des connexions aux adresses présentes sur le dispositif VRA au moment de l'initialisation du démon du service IKE (Internet Key Exchange).

Exécutez la commande suivante sur les routeurs maître et les routeurs de secours, de sorte qu'en cas de basculement, les démons IPsec soient redémarrés sur une nouvelle unité maître après transit de l'adresse VIP, conformément à l'exemple suivant :

vyatta@vrouter# set interfaces bonding dp0bond1 vrrp vrrp-group 1 notify ipsec

Pare-feux à haute disponibilité avec VRRP

Lorsque deux unités composent une paire à haute disponibilité (HA), veillez, sur votre unité maître, à ne pas bloquer l'accès depuis l'autre unité. Le port 443 doit être autorisé entre les deux unités pour que la synchronisation de la configuration (config-sync) fonctionne, et VRRP doit être autorisé en envoi et réception, notamment pour la plage d'adresses multidiffusion 224.0.0.0/24.

Sous-réseaux VLAN associés avec VRRP

Pour toute configuration d'interface virtuelle (VIF) avec VRRP, vous avez besoin d'une adresse IP virtuelle (la première adresse IP utilisable sur le sous-réseau, l'adresse IP de la passerelle vers laquelle transitera tout ce qui se trouve sur le sous-réseau), ainsi qu'une adresse IP d'interface réelle pour l'interface VIF sur les deux unités. Pour conserver des adresses IP utilisables, il est recommandé que les adresses IP de l'interface réelles utilisent une plage hors bande, telle que 192.168.0.0/30, dans laquelle une unité a l'adresse .1 et l'autre l'adresse .2. Vous pouvez avoir plusieurs adresses IP virtuelles VRRP, mais vous n'avez besoin que d'une seule adresse réelle sur chaque interface VIF.

Voici un exemple de configuration VRRP avec deux réseaux locaux virtuels privés et trois sous-réseaux :

set interfaces bonding dp0bond0 address '10.100.11.39/26'
set interfaces bonding dp0bond0 mode 'lacp'
set interfaces bonding dp0bond0 vif 10 address '192.168.255.81/30'
set interfaces bonding dp0bond0 vif 10 description 'VLAN 10 - Two private subnets/VIPs'
set interfaces bonding dp0bond0 vif 10 vrrp vrrp-group 1 advertise-interval '1'
set interfaces bonding dp0bond0 vif 10 vrrp vrrp-group 1 preempt 'false'
set interfaces bonding dp0bond0 vif 10 vrrp vrrp-group 1 priority '254'
set interfaces bonding dp0bond0 vif 10 vrrp vrrp-group 1 sync-group 'vgroup1'
set interfaces bonding dp0bond0 vif 10 vrrp vrrp-group 1 virtual-address '10.100.105.177/28'
set interfaces bonding dp0bond0 vif 10 vrrp vrrp-group 1 virtual-address '10.100.38.1/26'
set interfaces bonding dp0bond0 vif 11 address '192.168.255.89/30'
set interfaces bonding dp0bond0 vif 11 description 'VLAN 11 - One private subnet/VIP'
set interfaces bonding dp0bond0 vif 11 vrrp vrrp-group 1 advertise-interval '1'
set interfaces bonding dp0bond0 vif 11 vrrp vrrp-group 1 preempt 'false'
set interfaces bonding dp0bond0 vif 11 vrrp vrrp-group 1 priority '254'
set interfaces bonding dp0bond0 vif 11 vrrp vrrp-group 1 sync-group 'vgroup1'
set interfaces bonding dp0bond0 vif 11 vrrp vrrp-group 1 virtual-address '10.100.212.65/26'
set interfaces bonding dp0bond0 vrrp vrrp-group 1 preempt 'false'
set interfaces bonding dp0bond0 vrrp vrrp-group 1 priority '254'
set interfaces bonding dp0bond0 vrrp vrrp-group 1 'rfc-compatibility'
set interfaces bonding dp0bond0 vrrp vrrp-group 1 sync-group 'vgroup1'
set interfaces bonding dp0bond0 vrrp vrrp-group 1 virtual-address '10.100.11.5/26'
set interfaces bonding dp0bond1 address '169.110.20.28/29'
set interfaces bonding dp0bond1 mode 'lacp'
set interfaces bonding dp0bond1 vrrp vrrp-group 1 notify 'ipsec'
set interfaces bonding dp0bond1 vrrp vrrp-group 1 preempt 'false'
set interfaces bonding dp0bond1 vrrp vrrp-group 1 priority '254'
set interfaces bonding dp0bond1 vrrp vrrp-group 1 'rfc-compatibility'
set interfaces bonding dp0bond1 vrrp vrrp-group 1 sync-group 'vgroup1'
set interfaces bonding dp0bond1 vrrp vrrp-group 1 virtual-address '169.110.21.26/29'

Un élément sync-group VRRP est différent d'un groupe VRRP. Lorsqu'une interface qui appartient à un élément sync-group change d'état, tous les autres membres du même élément sync-group prennent le même état.
Le nombre d'éléments vrrp-group des interfaces VLAN (VIF) doit presque toujours être identique à celui de l'interface native correspondante. Par exemple, dp0bond1.789 doit toujours avoir le même nombre d'éléments vrrp-group que dp0bond1, à moins que les deux interfaces ne partagent le même élément sync-group. Si le nombre de groupes est différent sur l'interface VIF et l'interface native, une condition de cerveau dédoublé (split brain) peut être générée en cas d'association à des groupes de synchronisation différents. Lorsque deux interfaces partagent le même groupe de synchronisation, même si elles appartiennent à des groupes vrrp différents, elles effectuent toutes les deux la transition entre l'unité maître et l'unité de secours, évitant ainsi la condition de cerveau dédoublé (split brain). D'autre part, si l'interface native est configurée avec un nombre d'éléments vrrp-group différent et un élément sync-group différent en tant qu'interface VLAN, dans la mesure où les sous-réseaux configurés sur les interfaces VLAN sont routés de manière statique vers l'adresse virtuelle sur l'interface native, si l'interface VLAN apparaît en tant qu'unité de secours et l'interface native est l'unité maître, le routeur continue d'envoyer le trafic de l'interface VLAN au dispositif VRA, où l'interface native est l'unité maître, même si l'interface VLAN est secondaire et inactive sur le dispositif VRA. Cette situation spécifique provoque une condition de cerveau dédoublé (split brain) et une indisponibilité. C'est pourquoi il est important de savoir comment les éléments sync-group sont configurés en conjonction avec les éléments vrrp-group. Il est également important de ne pas utiliser les mêmes nombres d'éléments vrrp-group pour plusieurs paires de dispositifs VRA à haute disponibilité dans le même réseau local virtuel de transit ; en effet, si quatre unités Vyatta utilisent le même groupe, trois dispositifs VRA assumeront potentiellement l'état de secours, alors qu'un seul sera maître, ce qui entraînera une indisponibilité.
Les adresses d'interface réelles sur les réseaux locaux virtuels natifs (par exemple, dp0bond1: 169.110.20.28/29) ne figurent pas toujours dans le même sous-réseau que leur adresse VIP (169.110.21.26/29).

Basculement VRRP manuel

Si vous devez forcer un basculement VRRP, vous pouvez le faire en exécutant la commande suivante sur l'unité qui est le maître VRRP en cours :

vyatta@vrouter$ reset vrrp master interface dp0bond0 group 1

L'ID de groupe est l'ID de groupe VRRP des interfaces natives et comme mentionné précédemment, il peut être différent dans votre paire.

Synchronisation des connexions

Lorsque deux unités VRA se trouvent dans une paire à haute disponibilité, il peut s'avérer utile de suivre les connexions avec état entre ces deux unités de sorte qu'en cas de basculement, l'état en cours de toutes les connexions sur l'unité défaillante soit répliqué sur l'unité de secours. Ainsi, il n'est pas nécessaire de régénérer complètement les sessions actives en cours (telles que les connexions SSL), ce qui pourrait interrompre l'acquis utilisateur.

C'est ce que l'on appelle la synchronisation du suivi des connexions.

Pour configurer cette synchronisation, vous devez déclarer la méthode de basculement, l'interface que vous utilisez pour envoyer les informations de suivi des connexions et l'adresse IP de l'homologue distant :

set service connsync failover-mechanism vrrp sync-group SYNC1
set service connsync interface dp0bond0
set service connsync remote-peer 10.124.10.4

L'autre unité VRA présente la même configuration mais un homologue distant (remote-peer) différent.

Notez que cette opération peut saturer une liaison s'il existe un nombre élevé de connexions entrantes sur d'autres interfaces et qu'il crée une concurrence avec un autre trafic sur la liaison déclarée.

Fonction Délai de démarrage VRRP

Vyatta OS version 1801p et versions ultérieures comporte une nouvelle commande vrrp.

vrrp spécifie un protocole d'élection qui affecte de façon dynamique la responsabilité pour un routeur virtuel à l'un des routeurs VRRP sur un réseau local. Le routeur VRRP qui contrôle les adresses IPv4 ou IPv6 associées à un routeur virtuel est appelé routeur maître. Il achemine les paquets qui sont envoyés à ces adresses IPv4 ou IPv6. Le processus d'élection fournit un basculement dynamique dans la responsabilité d'acheminement si le maître devient indisponible. L'ensemble de la messagerie de protocole est traité via des datagrammes multidiffusion IPv4 ou IPv6. Par conséquent, le protocole peut fonctionner sur une grande variété de technologies LAN multi-accès prenant en charge la multidiffusion IPv4/IPv6.

Pour réduire le trafic réseau, seul le maître de chaque routeur virtuel envoie régulièrement des messages d'annonce VRRP. Un routeur de secours ne tente pas de préempter le maître sauf s'il présente une priorité plus élevée. Ainsi, les interruptions de service sont éliminées sauf si un chemin préféré devient disponible. Il est également possible d'interdire de manière administrative toutes les tentatives de préemption. Si le maître devient indisponible, le routeur de secours associé à une priorité plus élevée devient le maître après un court délai, fournissant une transition contrôlée de la responsabilité de routeur virtuel avec une interruption de service minimale.

Dans les déploiements mis à disposition par IBM Cloud, le délai de démarrage prend la valeur par défaut. Vous pouvez modifier cette valeur à votre gré lorsque vous testez vos méthodes de basculement et de haute disponibilité.

Avec préemption/Sans préemption

Le protocole vrrp définit une logique qui décide quel homologue VRRP sur un réseau est associé à la priorité plus élevée, et par conséquent, est le plus à même de porter le rôle de maître. Avec une configuration par défaut, VRRP est activé pour effectuer la préemption, ce qui signifie qu'un nouvel homologue ayant une priorité plus élevée sur le réseau force la reprise du rôle de maître.

Lorsque la préemption est désactivée, un homologue dont la priorité est plus élevée reprendra le rôle de maître uniquement si l'homologue dont la priorité est plus faible n'est plus disponible sur le réseau. Il est parfois utile de désactiver la préemption dans des scénarios du monde réel pour mieux faire face aux situations où l'homologue associé à la priorité plus élevée a commencé à bagoter régulièrement en raison de problèmes de fiabilité avec l'homologue lui-même ou l'une de ses connexions réseau. Il est également utile d'empêcher le basculement prématuré vers un nouvel homologue dont la priorité est plus élevée qui n'a pas terminé la convergence du réseau.

Hypothèses et limitations de préemption

Si les homologues VRRP ont été configurés pour désactiver la préemption, il peut arriver qu'une préemption semble se produire ; en réalité, il s'agit simplement d'un basculement VRRP standard. Comme décrit précédemment, un protocole VRRP utilise des datagrammes de multidiffusion IP afin de confirmer la disponibilité du routeur maître élu. Dans la mesure où l'échec d'une paire VRRP est détecté par un protocole de couche 3, il est important que la détection de basculement dans VRRP soit retardée jusqu'à ce que VRRP et les couches 1 à 2 de la pile réseau soient prêts et convergés. Dans certains cas, l'interface réseau qui exécute VRRP peut confirmer au protocole que l'interface est active, mais il se peut que d'autres services sous-jacents, tels que l'arbre maximal ou la liaison, n'aient pas abouti. Par conséquent, la connectivité IP entre les homologues ne peut pas être établie. Si tel est le cas, VRRP sur un nouvel homologue dont la priorité est plus élevée devient le maître, car les messages VRRP émis par l'homologue maître en cours sur le réseau ne peuvent pas être détectés. Après la convergence, pendant la courte période où il existe deux homologues VRRP maître, la logique maître double de VRRP est exécutée. L'homologue dont la priorité est plus élevée reste maître et l'homologue dont la priorité est plus faible devient l'homologue de secours. Ce scénario semble révéler une faille dans la fonctionnalité "sans préemption".

Fonction Délai de démarrage

Pour traiter les problèmes liés au retard de convergence des niveaux inférieurs de la pile réseau durant un événement d'interface active, ainsi qu'à d'autres facteurs, une nouvelle fonction nommée "Délai de démarrage" est introduite dans le correctif 1801p. Avec cette fonction, l'état VRRP sur une machine qui a été rechargée demeure INIT pendant une période qui va au-delà d'un délai prédéfini, qui peut être configuré par l'opérateur réseau. La flexibilité de cette valeur de délai permet à l'opérateur réseau de personnaliser les caractéristiques de son réseau et de ses périphériques dans des conditions réelles.

Détails de la commande

vrrp {
start-delay <0-600>
}

start-delay peut avoir une valeur comprise entre 0 (par défaut) et 600 secondes.

Exemple de configuration

interfaces {
  bonding dp0bond1 {
address 161.202.101.206/29 mode balanced
vrrp {
      start-delay 120
      vrrp-group 211 {
preempt false
priority 253
virtual-address 161.202.101.204/29
} }
}