L'autre jour, lors d'une discussion avec certains utilisateurs, il m'est apparu clairement qu'ils ne comprenaient pas dans quelles conditions un système VSeries Stratus appellerait home concernant un adaptateur réseau. Ce malentendu a eu pour conséquence que le système a perdu sa connexion réseau. S'ils n'ont pas compris, je suis sûr que d'autres ne le comprennent pas non plus, et ce blog tentera donc d'expliquer quand un système appellera home concernant un adaptateur réseau.
La réponse est simple : le système appelle home lorsqu'il détecte une défaillance de l'adaptateur réseau. La zone grise est ce que signifie "failed". Si l'adaptateur se casse ou est cassé par le système, un ensemble de diagnostics sont exécutés, et si l'adaptateur passe, il est remis en service. S'il se brise trop souvent en un laps de temps trop court, l'adaptateur dépassera le seuil MTBF (Mean Time Between Failure) et restera hors service. Si cela se produit, le système appellera home au sujet de l'adaptateur. Si les diagnostics s'exécutent et échouent, l'adaptateur reste hors service et le système appellera home.
Si les messages de test sdlmux, qui sont transmis entre les partenaires de l'adaptateur réseau actif et de l'adaptateur réseau de secours, ne sont pas reçus par l'adaptateur partenaire, le système brisera la carte de secours, la testera et la remettra en service. Si les messages de test bloqués ne sont pas résolus, ce schéma se répétera jusqu'à ce que la carte dépasse le seuil MTBF et le système appellera home. Notez ici que le problème peut ne pas être l'adaptateur, mais le réseau.
Si une liaison tombe, de sorte qu'un adaptateur n'est plus connecté au réseau, le système basculera les adaptateurs réseau selon les besoins et ne fera rien d'autre. Il n'appellera pas home. La raison en est qu'il y a trop de raisons, presque toutes externes à l'adaptateur, pour que le lien soit interrompu. Il y a vingt-deux ans, dans la version 8.0 de VOS, la mise en œuvre originale de l'Ethernet Stratus appelait effectivement home lorsqu'un lien était perdu. Cela a entraîné l'ouverture de nombreux problèmes, ce qui n'a fait qu'ennuyer les gens lorsque nous les avons rappelés, car ils savaient qu'ils avaient redémarré un commutateur ou retiré un câble. Il a été décidé à l'époque qu'un lien perdu ne serait pas considéré comme un échec. Notez que les messages de test sdlmux mentionnés dans le paragraphe précédent ne sont pas envoyés à moins que les deux adaptateurs aient un lien avec un réseau.
Qu'est-il donc arrivé aux utilisateurs mentionnés dans le premier paragraphe ? Il y a environ un mois, ils ont perdu le lien vers un adaptateur. Ils n'en étaient pas conscients car le système n'avait aucun problème de connectivité. Puis, il y a quelques jours, ils ont perdu l'autre lien et, à ce moment-là, ils étaient hors réseau. Ce scénario montre pourquoi il est important de surveiller les adaptateurs de votre système pour confirmer qu'ils sont connectés au réseau. Une surveillance périodique aurait permis d'identifier le problème de la liaison du premier adaptateur à temps pour le corriger avant que le problème de la liaison du second adaptateur ne se produise.
La macro de commande monitor_sdlmux_adapter_status (figure 1) surveille périodiquement tous les adaptateurs sdlmuxed en partenariat. Elle enverra un message de 25 lignes aux utilisateurs sélectionnés et ajoutera une entrée dans le syserr_log. Une entrée dans le syserr_log est faite lorsque le lien est perdu pour la première fois, mais la macro monitor_sdlmux_adapter_status en ajoutera une à chaque vérification, ce qui augmentera la probabilité de la voir (figure 2). La macro doit être exécutée comme un processus lancé avec -privileged à yes puisqu'elle appelle analyze_system pour obtenir la liste des périphériques sdlmux.
La macro vérifie également si l'un des adaptateurs est "DOWN" et le signale de la même manière qu'elle signale un lien supprimé. Le système aurait dû appeler home mais il a été facile d'ajouter la vérification et je me suis dit que la notification supplémentaire ne pouvait pas faire de mal.
La 25e ligne et les messages syserr_log vous renvoient au fichier check_adapters dans le répertoire home de celui qui exécute la macro monitor_sdlmux_adapter_status. Ce fichier est constitué de la sortie de la commande dlmux_admin sdlmux_status exécutée sur chaque partenariat sdlmux du système (figure 3). Vous devrez examiner ce fichier pour identifier le ou les adaptateur(s) spécifique(s) présentant un problème.
La macro ne s'intéresse qu'aux adaptateurs qui ont été associés à sdlmux. Les problèmes liés aux adaptateurs qui n'ont pas été associés sont immédiatement apparents, de sorte qu'aucune surveillance supplémentaire n'est nécessaire. Notez que Stratus recommande que tous les adaptateurs réseau soient associés à sdlmux.
& monitor_sdlmux_adapter_status begins here |
Figure 1 - La macro de commande monitor_sdlmux_adapter_status
d >system>syserr_log.10-05-24 -match check_adapters%phx_vos#m16_mas>system>syserr_log.10-05-24 10-05-25 08:27:29 mst. . . . . . . . . |
Figure 2 - Messages de syserr_log
d check_adapters%phx_vos#m16_mas>SysAdmin>Noah_Davids>check_adapters 10-05-24 19:57:43 mst**************************************************--------------- 10-05-24.19:56:47 ----------------****************************************************************************************************Group Name: #sdlmuxA.m16.10-5-0.11-5-0Device Name: %phx_vos#enetA.m16.11-5-0Adapter State: ACTIVE UPPartner: %phx_vos#enetA.m16.10-5-0Partner State: UP (network connection lost)**************************************************Group Name: #sdlmuxA.m16.10-5-1.11-5-1Device Name: %phx_vos#enetA.m16.10-5-1Adapter State: ACTIVE UPPartner: %phx_vos#enetA.m16.11-5-1Partner State: UP**************************************************Group Name: #sdlmux.m16.11-2Device Name: %phx_vos#enet.m16.11.11-2Adapter State: ACTIVE UPPartner: %phx_vos#enet.m16.10.11-2Partner State: UP**************************************************Group Name: #sdlmux.m16.11-3Device Name: %phx_vos#enet.m16.10.11-3Adapter State: ACTIVE UPPartner: %phx_vos#enet.m16.11.11-3Partner State: UPready 19:57:43 |
Figure 3 - Sortie du fichier check_adapters montrant que le fichier #enetA.m16.10-5-0 a perdu le lien