Le processus de basculement de FireCluster est le même pour les clusters actif/actif et les clusters actif/passif. Quel que soit le type de cluster, chaque membre du cluster conserve à tout moment les informations sur l'état et les sessions. En cas de basculement, les connexions via un filtre de paquets, les tunnels Branch Office VPN et les sessions d'utilisateur gérés par le périphérique en échec basculent automatiquement vers l'autre périphérique du cluster.
Un Firebox est le maître du cluster et l'autre périphérique est le maître de secours. Le maître de sauvegarde utilise l'interface cluster principale pour synchroniser les informations sur les connexions et les sessions à partir du maître du cluster. Si l'interface cluster principale échoue ou est déconnectée, le maître de sauvegarde utilise l'interface cluster de sauvegarde pour communiquer avec le maître du cluster. Le maître du cluster utilise également les interfaces de cluster principales et de sauvegarde pour envoyer un paquet de pulsations une fois par seconde au maître de sauvegarde. Nous vous recommandons de toujours configurer une interface cluster principale <u>et</u> une interface cluster de sauvegarde.
Les événements qui déclenchent un basculement
Il existe trois types d'événements qui peuvent provoquer un basculement vers le maître du cluster.
L'indice de l'état de santé du maître du cluster est plus bas que celui du maître de sauvegarde
Chaque membre du cluster a un indice d'état de santé calculé qui indique l'état de santé général du périphérique. Si l'indice de l'état de santé du maître du cluster est plus bas que l'indice de l'état de santé du maître de sauvegarde, cela déclenche un basculement du maître du cluster.
Pour plus d'informations sur l'indice de l'état de santé du cluster, consultez Contrôler l'État de santé de Cluster.
Perte de la pulsation du maître du cluster
Le maître du cluster envoie un paquet de pulsations une fois par seconde sur les interfaces cluster principale et de sauvegarde. Si le maître de sauvegarde ne reçoit pas trois pulsations consécutivement du maître du cluster, cela déclenche le basculement du maître du cluster. Le seuil par défaut pour la perte de pulsation est de trois. Vous pouvez augmenter le seuil des pulsations perdues qui déclenchent un basculement dans les paramètres Avancés de FireCluster.
Pour plus d'informations sur le seuil des pulsations perdues, consultez Configurer les Paramètres avancés de FireCluster.
Le cluster reçoit la commande Matrice de basculement
Dans Firebox System Manager, lorsque vous sélectionnez Outils > Cluster > Matrice de Basculement, vous forcez un basculement du maître du cluster vers le maître de sauvegarde.
Pour plus d'informations sur cette commande, consultez Forcer un Basculement du Cluster maître.
Que se passe-t-il lorsqu'un basculement se produit ?
Lorsqu'un basculement du maître du cluster se produit, le maître de sauvegarde devient le maître du cluster. Ensuite, le maître du cluster d'origine rejoint le cluster en tant que fichier principal de sauvegarde. Lorsqu'un basculement survient, le cluster conserve toutes les connexions via un filtre de paquets, les tunnels Branch Office VPN et les sessions d'utilisateur. Ce comportement est identique pour un FireCluster actif/actif ou actif/passif.
Dans un cluster actif/actif, si le maître de sauvegarde échoue, le cluster bascule et conserve toutes les connexions via un filtre de paquets, les tunnels Branch Office VPN et les sessions d'utilisateur. Les connexions proxy et Mobile VPN peuvent être interrompues, tel que décrit dans cette liste. Dans un cluster actif/passif, si le maître de sauvegarde échoue, il n'y aucune interruption des connexions ou des sessions car aucun trafic n'est attribué au maître de sauvegarde.
| Type de connexion/session | Impact d'un événement de basculement |
|---|---|
| Connexions via un filtre de paquets | Les connexions basculent sur l'autre membre du cluster. |
| Tunnels Branch Office VPN | Les tunnels basculent sur l'autre membre du cluster. |
| Sessions d'utilisateur | Les sessions basculent sur l'autre membre du cluster. |
| Connexions proxy | Les connexions affectées au périphérique en échec (maître ou maître de sauvegarde) doivent être redémarrées. Les connexions affectées à l'autre périphérique ne sont pas interrompues. |
| Access Portal | Les sessions utilisateur et les connexions aux applications web d’Access Portal restent actives après un basculement. Les connexions RDP et SSH établies via Access Portal sont déconnectées après un basculement. |
| Mobile VPN with IPSec | Si le maître du cluster bascule, toutes les sessions doivent être redémarrées. Si le maître de sauvegarde échoue, seules les sessions affectées au maître de sauvegarde doivent être redémarrées. Les sessions affectées au maître du cluster ne sont pas interrompues. |
| Mobile VPN with SSL | Si l'un des deux périphériques bascule, toutes les sessions doivent être redémarrées. |
| Mobile VPN with L2TP | Toutes les sessions L2TP sont affectées au maître du cluster, même pour un cluster actif/actif. Si le maître du cluster bascule, toutes les sessions doivent être redémarrées. Les sessions L2TP ne sont pas interrompues en cas d'échec du maître de sauvegarde. |
| Mobile VPN with IKEv2 | Si le maître du cluster bascule, toutes les sessions doivent être redémarrées. Si le maître de sauvegarde échoue, seules les sessions affectées au maître de sauvegarde doivent être redémarrées. Les sessions affectées au maître du cluster ne sont pas interrompues. |
Basculement de FireCluster et équilibrage de charge côté serveur
Si vous utilisez l'équilibrage de charge côté serveur pour équilibrer les connexions entre vos serveurs internes, lorsqu'un événement de basculement de FireCluster se produit, il n'y a pas de synchronisation en temps réel. Après un basculement, le nouveau maître du cluster envoie des connexions à tous les serveurs de la liste d'équilibrage de charge côté serveur pour identifier ceux qui sont disponibles. Il applique ensuite à tous les serveurs disponibles l'algorithme d'équilibrage de charge.
Pour plus d'informations sur l'équilibrage de charge côté serveur, consultez Configurer l'Équilibrage de Charge Côté Serveur.
Basculement FireCluster et routage dynamique
Quand vous autorisez un routage dynamique sur un FireCluster, seul le maître du cluster participe directement au domaine du routage dynamique. Le maître du cluster synchronise les informations du routage dynamique avec l'autre membre du cluster. Quand un basculement se produit, le nouveau maître du cluster utilise initialement les routes dynamiques précédemment apprises. Le nouveau maître du cluster participe alors au domaine du routage dynamique, et il utilise le protocole de routage dynamique configuré pour découvrir les dernières routes vers tous les réseaux de destination. Quand le nouveau maître du cluster découvre les routes dynamiques mises à jour, les anciennes routes dynamiques sont éliminées et remplacées par les nouvelles.
Le temps qu'il faut au nouveau maître du cluster et à tous les routeurs connectés pour convenir d'un ensemble commun de routes (le délai de convergence) dépend du protocole de routage dynamique.
Pour RIPv1 et RIPv2
Le routeur RIP point-à-point ne détecte pas l'événement de basculement FireCluster si la connexion elle-même n'est pas interrompue pendant le basculement.
OSPFv2
Le routeur point-à-point détecte l'événement de basculement FireCluster. Le délai de convergence pour OSPF varie entre 10 et 40 secondes. Le délai de convergence pourrait être plus court, car le nouveau maître du cluster utilise un ensemble de routes dynamiques connues synchronisées depuis l'ancien maître du cluster jusqu'à ce qu'il découvre les routes dynamiques mises à jour.
BGPv4
Le routeur point-à-point détecte l'événement de basculement FireCluster. Le délai de convergence pour BGP varie entre 1 et 3 minutes. Le délai de convergence pourrait être plus court, car le nouveau maître du cluster utilise un ensemble de routes dynamiques connues synchronisées depuis l'ancien maître du cluster jusqu'à ce qu'il découvre les routes dynamiques mises à jour.
Contrôler le cluster pendant un basculement
Le rôle de chaque périphérique du cluster s'affiche après le nom de membre sur l'onglet Panneau avant de Firebox System Manager. Si vous regardez l'onglet Panneau avant pendant un basculement du maître du cluster, vous pouvez voir le rôle du maître du cluster se déplacer d'un périphérique à l'autre. Pendant un basculement, vous voyez les modifications suivantes :
- Le rôle de l'ancien maître de sauvegarde passe de maître de sauvegarde à maître.
- Le rôle de l'ancien maître du cluster passe à inactif, puis à veille au moment du redémarrage du périphérique.
- Le rôle de l'ancien maître du cluster passe à maître de sauvegarde après le redémarrage du périphérique.
Pour plus d'informations, consultez Surveiller et Contrôler les Membres FireCluster.
Basculement de FireCluster et Services d'Abonnement
Si vous avez activé des services d'abonnement sous licence pour votre FireCluster, les services continuent d'être fonctionnels après le basculement, tant que vous avez acheté les services d'abonnement requis pour les membres du FireCluster. Les exigences sont différentes pour un FireCluster actif/actif et pour un FireCluster actif/passif.
- Actif/Actif — Vous devez disposer des mêmes services d'abonnement activés sur les clés de fonctionnalité des deux membres du cluster. Chaque membre d'un cluster applique les services à partir de sa propre clé de fonctionnalité.
- Actif/Passif — Vous devez activer les services d'abonnement sur la clé de fonctionnalité pour un seul membre du cluster. Le membre du cluster actif utilise les services d'abonnement actifs sur la clé de fonctionnalité de l'un des deux membres du cluster.
Pour plus d'informations sur les clés de fonctionnalité et le FireCluster, consultez À Propos des Clés de Fonctionnalité et de FireCluster.