El otro día durante una discusión con algunos usuarios me quedó claro que no entendían bajo qué condiciones un sistema Stratus VSeries llamaría a home con respecto a un adaptador de red. Este malentendido hizo que el sistema perdiera su conexión de red. Si no lo entendieron, estoy seguro de que hay otros que no lo entienden tan bien, por lo que este blog tratará de explicar cuando un sistema llamará a home con respecto a un adaptador de red.
La respuesta simple es que el sistema llamará a home cuando detecte que el adaptador de red ha fallado. El área gris es lo que significa que ha fallado. Si el adaptador se rompe o es roto por el sistema se ejecutan una serie de diagnósticos, y si el adaptador pasa se vuelve a poner en servicio. Si se rompe demasiadas veces en un intervalo de tiempo demasiado corto, el adaptador superará el umbral del MTBF (tiempo medio entre fallos) y permanecerá fuera de servicio. Si eso ocurre, el sistema llamará a home en relación con el adaptador. Si los diagnósticos se ejecutan y fallan, el adaptador permanece fuera de servicio y el sistema llamará a home.
Si los mensajes de prueba del sdlmux, que se pasan entre los socios del adaptador de red activo y de reserva, no son recibidos por el adaptador asociado, el sistema romperá la tarjeta de reserva, la probará y la volverá a poner en servicio. Si lo que sea que haya bloqueado los mensajes de prueba no se resuelve, este patrón se repetirá hasta que la tarjeta supere el umbral de MTBF y el sistema llamará a home. Tengan en cuenta que el problema puede que no sea el adaptador, sino la red.
Si un enlace se cae, de modo que un adaptador ya no está conectado a la red, el sistema hará una conmutación por error de los adaptadores de red según sea necesario y no hará nada más. No llamará a home. La razón de esto es que hay demasiadas razones, casi todas externas al adaptador, para que el enlace caiga. Hace veintidós años, en la versión 8.0 de VOS, la implementación original de Ethernet Stratus llamó a home cuando se perdió un enlace. Esto provocó que se abrieran muchos problemas, lo que simplemente molestaba a la gente cuando les devolvíamos la llamada, ya que sabían que habían reiniciado un conmutador o retirado un cable. Se decidió en ese momento que un enlace perdido no se consideraría un fallo. Obsérvese que los mensajes de prueba sdlmux mencionados en el párrafo anterior no se envían a menos que ambos adaptadores tengan un enlace a una red.
Entonces, ¿qué pasó con los usuarios mencionados en el párrafo inicial? Hace un mes perdieron el enlace a un adaptador. No estaban al tanto de esto porque el sistema no tenía problemas de conectividad. Luego, hace unos días, perdieron el otro enlace y en ese momento estaban fuera de la red. Este escenario demuestra por qué es importante monitorear los adaptadores de su sistema para confirmar que están conectados a la red. La monitorización periódica habría identificado el problema con el enlace del primer adaptador a tiempo para corregirlo antes de que se produjera el problema con el enlace del segundo adaptador.
El comando macro monitor_sdlmux_adapter_status (figura 1) monitorizará periódicamente todos los adaptadores asociados a sdlmux. Enviará un mensaje de 25 líneas a los usuarios seleccionados y añadirá una entrada en el syserr_log. Se realiza una entrada en syserr_log cuando se pierde el enlace por primera vez, pero el macro monitor_sdlmux_adapter_status agregará uno cada vez que lo compruebe, lo que hace más probable que se vea (figura 2). El macro debe ser ejecutado como un proceso iniciado con -privileged establecido en yes ya que llama a analyze_system para obtener la lista de dispositivos sdlmux.
La macro también comprueba si uno de los adaptadores está "ABAJO" y lo reportará de la misma manera que reporta un enlace caído. El sistema debería haber llamado a home pero fue fácil añadir la comprobación y me imaginé que la notificación extra no puede hacer daño.
La línea 25 y los mensajes syserr_log te remiten al archivo check_adapters en el dir home de quien sea que esté ejecutando la macro monitor_sdlmux_adapter_status. Ese archivo consiste en la salida del comando dlmux_admin sdlmux_status ejecutado contra cada asociación sdlmux en el sistema (figura 3). Necesitarás revisar ese archivo para identificar el/los adaptador(es) específico(s) con un problema.
La macro mira sólo a los adaptadores que han sido asociados con sdlmux. Los problemas con los adaptadores que no han sido asociados son inmediatamente aparentes, así que no se necesita un monitoreo extra. Tengan en cuenta que Stratus recomienda que todos los adaptadores de red estén asociados con sdlmux.
& monitor_sdlmux_adapter_status begins here |
Figura 1 - el macro de comando 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. . . . . . . . . |
Figura 2 - mensajes 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 |
Figura 3 - la salida del archivo check_adapters que muestra #enetA.m16.10-5-0 ha perdido el enlace
Empresa