SDLMUX Revisité

Le logiciel SDLMUX combine deux adaptateurs réseau en une seule interface IP, offrant une capacité de basculement si la liaison sur l'adaptateur actif tombe en panne ou si l'adaptateur tombe en panne. Une fois configuré, il ne nécessite pratiquement aucune administration, mais il y a certaines choses que vous devez savoir.

Premièrement, le SDLMUX n'assure aucun équilibrage de charge ; tout le trafic est émis et reçu sur l'adaptateur actif.

Deuxièmement, sur le matériel ftServer VSeries, l'adaptateur actif a une adresse MAC de la forme 00:00:A8:4v:wx:yz. Le 00:00:A8 est l'identifiant unique de l'organisation (OUI) Stratus , attribué par l'IEEE. Le "v" est un index basé sur l'ordre d'initialisation des appareils SDLMUX, commençant à 0. La valeur "wx:yz" est basée sur le numéro de série du système. L'adresse de veille ne diffère de l'adresse active que dans la partie supérieure du quatrième octet, au lieu d'un 4, c'est un 6. De même, la différence entre les adresses MAC de deux adaptateurs actifs (ou de veille) sur le même module ne se trouve que dans la partie inférieure du quatrième octet. La manière la plus simple d'obtenir une liste de toutes les adresses MAC est d'utiliser la requête "dump_sdlmux" de analyze_system sur "MAC", voir figure 1.

Les adresses MAC ne sont pas très utiles ; en les comparant par "MAC" ou "#", vous obtenez les adresses MAC et les noms des appareils SDLMUX et des adaptateurs réseau. Notez que cette liste ne contient aucun adaptateur réseau qui ne fasse pas partie d'un partenariat SDLMUX.

Troisièmement, les adaptateurs réseau SDLMUX envoient des trames Ethernet 802.2 LLC à leurs partenaires pour s'assurer que le chemin du réseau fonctionne correctement. Cinq séries de ces trames de test sont envoyées à trois secondes d'intervalle, suivies d'un intervalle de 33 secondes. La Trace 1 montre trois cycles de ce schéma. La trace 1 montre également la trame réelle de l'adaptateur actif (trame 1) et de l'adaptateur de veille (trame 2). J'ai mis en évidence l'image suivant l'intervalle de 33 secondes juste pour rendre les cycles plus faciles à lire. Il ne s'agit pas de trames Ethernet de type II ou de paquets IP et les commutateurs connectés aux adaptateurs réseau et tout commutateur le long du chemin entre les deux adaptateurs doivent avoir une configuration qui ne bloque pas ces trames 802.2 LLC.

Notez que vous ne pouvez pas utiliser packet_monitor pour voir ces cadres de test. Les trames sont envoyées en dessous du point où packet_monitor se connecte à la pile et SDLMUX retire les trames de la pile avant que packet_monitor ne puisse les lire.

Quatrièmement, si chaque adaptateur est connecté à un commutateur différent et que la liaison entre ces commutateurs échoue ou que, pour une autre raison, les trames de test ne sont pas obtenues, vous verrez quelque chose qui ressemble à la figure 3 dans le syserr_log. À partir des versions 16.2.1ak et 17.0.0ah, en cas d'échec d'une trame de test, le SDLMUX déclenche une requête ARP vers le dernier hôte qui a réussi l'ARP sur l'interface suspecte. S'il obtient une réponse, il sait que l'adaptateur actif fonctionne et réinitialise l'adaptateur de secours pour essayer de le faire fonctionner. Si un problème réseau bloque les trames de test, la réinitialisation de l'adaptateur n'aide pas et l'adaptateur finit par passer en MTBF, voir l'horodatage 08:08:10 sur la figure 3. La commande dlmux_admin signalera l'adaptateur défectueux en indiquant DOWN, figure 4, et une trace n'affichera aucune trame de test puisqu'à ce stade il n'y a rien à tester. Si une réponse ARP n'est pas reçue ou si le problème se situe sur une version qui n'envoie pas la demande ARP, SDLMUX échouera sur les adaptateurs et cassera le nouvel adaptateur de secours. Si, au cours du cycle suivant, les cadres de test échouent à nouveau et qu'aucune réponse ARP n'est reçue, le basculement et l'interruption se feront à nouveau. Un adaptateur finira par passer en mode MTBF.

Pour remettre l'adaptateur en service, vous devez l'ajouter à nouveau avec la commande board_admin. Bien sûr, si vous faites cela sans corriger le problème sous-jacent, l'adaptateur sera à nouveau juste MTBF.

Cinquièmement, comme l'adaptateur actif a toujours la même adresse MAC, le basculement a pour effet de déplacer l'adresse MAC d'un port de commutateur à un autre. Tous les paramètres de sécurité des ports du commutateur doivent permettre ce changement. Les ports de commutation peuvent également être configurés pour communiquer avec d'autres ports de commutation, en négociant divers paramètres. Ils peuvent être déclenchés lorsque le commutateur remarque un changement de topologie, comme une nouvelle adresse MAC ou une liaison en cours de restauration. Tant que ces paramètres ne sont pas négociés, un commutateur peut ne pas passer les trames normales. Les ports du commutateur connectés aux adaptateurs SDLMUX doivent être configurés de manière à ne pas effectuer ces négociations. En outre, les ports de commutation connectés aux adaptateurs SDLMUX doivent être configurés de manière à ne pas exécuter le protocole spanning tree ou à sauter les étapes d'apprentissage et d'écoute (ce que Cisco appelle portfast). Pendant les étapes d'apprentissage et d'écoute, le commutateur ne passera pas les trames de données normales. Dans les cas extrêmes, le délai causé par ces réglages peut être si long que SDLMUX déclenche un autre basculement.

Enfin, l'état des liens des adaptateurs doit être surveillé pour s'assurer que les deux liens sont en place. La défaillance d'un lien n'entraînera pas l'appel du système à home et, comme il est tolérant aux pannes, il n'y a pas de perte de connectivité du système, j'ai couvert ce point dans un précédent billet de blog, voir Surveillance de l'état des adaptateurs réseau.