Cisco introduit dans sa dernière version 7.3 un nouveau mode de résilience plus performant apportant la haute disponibilité aux points d’accès radio. Ce mode est appelé « AP SSO » (Stateful Switch Over), c’est-à-dire résilience sans perte de synchronisation des AP.
Ce mode introduit à la fois une efficacité technologique (sub-second resiliency), mais aussi une efficacité économique. Le contrôleur de backup n’a en effet pas besoin d’avoir de licence, il va dynamiquement récupérer celle du contrôleur primaire.
Principes de fonctionnement du mode AP SSO
Le principe utilisé pour mettre en œuvre le mode AP SSO est celui de l’active/backup. Un contrôleur primaire rend le service nominal, un second contrôleur de backup, en mode passif, est synchronisé en temps réel avec le primaire pour conserver les états des AP. Lors d’un incident d’accès vers le contrôleur primaire, le contrôleur passif va alors reprendre la gestion des AP de façon transparente pour ces derniers.
Pour réaliser cela, les deux contrôleurs doivent être de la même famille et être connectés physiquement par un câble ethernet dédié par lequel vont passer toutes les informations de synchronisation des états des AP, mais aussi les « keep-alive » permettant de surveiller l’état opérationnel du contrôleur principal.
Les contrôleurs 5508, Flex-7500 et 8500 vont donc utiliser un « Redundancy Port » dédié :
Les cartes WiSM-2, intégrées dans les chassis Cisco Catalyst 6500, vont utiliser un VLAN dédié pour réaliser ces opérations. A noter que la haute disponibilité des cartes WiSM-2 peut se faire dans le même chassis 6500 ou dans deux chassis différents, en VSS ou non.
Le processus de déclenchement de la haute disponibilité est le suivant :
- Toutes les 100 ms le contrôleur passif envoie un message « keepalive » au primaire pour vérifier son bon fonctionnement.
- Si le message n’est pas acquitté, un message ICMP est envoyé au contrôleur primaire pour vérifier si le problème de connexion n’est pas sur le lien de synchronisation.
- Un second message keepalive est envoyé au bout de 75 ms, si toujours pas de réponse, un ICMP est envoyé.
- Un troisième message keepalive est envoyé au bout de 50 ms, ainsi qu’un ICMP si nécessaire.
- Si lors de ce processus, l’un des messages est acquitté, alors le basculement est annulé, et le rythme des keepalives reprend normalement.
- Si aucun des messages n’est acquitté, alors le basculement est déclenché. Le contrôleur passif devient le contrôleur primaire, il reprend la gestion des AP de façon transparente en se substituant au contrôleur primaire.
Ainsi en cas de problème sur le contrôleur primaire, la bascule s’effectue en moins de 1 seconde. En cas d’incident sur le réseau, cette bascule peut être un peu plus longue (jusqu’à 3 minutes) en fonction de l’incident.
Il est à noter que le mode « AP SSO » synchronise l’état des AP, pas celui de tous les clients connectés. En cas de bascule le nouveau contrôleur primaire forcera une déconnexion des clients pour resynchroniser les états de ces derniers, à l’exception des clients se trouvant sur les AP en mode FlexConnect et commutation locale.
Gestion des licences en mode AP SSO
Afin d’offrir une fonction de haute disponibilité avec un coût abordable, la fonction technologique s’accompagne d’une adaptation du mode de licensing.
Le contrôleur passif n’a pas besoin d’avoir de licence pour gérer les AP. En effet il va récupérer de façon automatique les licences du contrôleur primaire en cas de panne de ce dernier pendant un délai de 90 jours. Ce délai permettant de remettre en service le contrôleur primaire.
Une nouvelle référence de contrôleur de type « HA » devient donc disponible au catalogue Cisco. Celui-ci ne peut fonctionner qu’en mode passif.
A noter qu’il est possible de transformer un contrôleur classique en contrôleur « HA » à partir du moment où celui-ci possède au moins 50 licences d’AP de base dans le cas d’un CT-5508 (100 AP pour une WiSM-2, 300 pour Flex7500/8500).
Si le contrôleur transformé en mode HA possède des licences ajoutées en plus des licences de base d’origine, ces dernières peuvent être « re-hostée » vers le contrôleur primaire.
1 commentaires