Rubriques Connexes

# À propos du basculement FireCluster

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 cluster maître. 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 cluster maître. Le cluster maître 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 et 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 cluster maître.

L'indice de l'état de santé du cluster maître 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 cluster maître est plus bas que l'indice de l'état de santé du maître de sauvegarde, cela déclenche un basculement du cluster maître.

Pour plus d'informations sur l'indice de l'état de santé du cluster, voir Contrôler l'état de santé de Cluster.

Perte de la pulsation du cluster maître

Le cluster maître 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 cluster maître, cela déclenche le basculement du cluster maître. 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, voir 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 cluster maître vers le maître de sauvegarde.

Pour plus d'informations sur cette commande, voir Forcer un basculement du cluster maître.

## Que se passe-t-il lorsqu'un basculement se produit ?

Lorsqu'un basculement du cluster maître se produit, le maître de sauvegarde devient le cluster maître. Ensuite, le cluster maître 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.
Mobile VPN with IPSec | Si le cluster maître 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 cluster maître 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 cluster maître, même pour un cluster actif/actif. Si le cluster maître 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.

## 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 cluster maître 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, voir Configurer l'équilibrage de charge côté serveur.

## Basculement FireCluster et routage dynamique

Quand vous autorisez un routage dynamique sur un FireCluster, seul le cluster maître participe directement au domaine du routage dynamique. Le cluster maître synchronise les informations du routage dynamique avec l'autre membre du cluster. Quand un basculement se produit, le nouveau cluster maître utilise initialement les routes dynamiques précédemment apprises. Le nouveau cluster maître 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 cluster maître 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 cluster maître 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 cluster maître utilise un ensemble de routes dynamiques connues synchronisées depuis l'ancien cluster maître 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 cluster maître utilise un ensemble de routes dynamiques connues synchronisées depuis l'ancien cluster maître 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 cluster maître, vous pouvez voir le rôle du cluster maître 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 cluster maître passe à inactif, puis à veille au moment du redémarrage du périphérique.
- Le rôle de l'ancien cluster maître passe à maître de sauvegarde après le redémarrage du périphérique.

Pour plus d'informations, voir 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.

#### Voir aussi

FireCluster

Configurer FireCluster

Envoyer Vos Commentaires • Obtenir de l'Aide • Documentation Complète des Produits • Recherche Technique