Outro dia, durante uma discussão com alguns usuários, ficou claro para mim que eles não entendiam em que condições um sistema Stratus VSeries entraria em contato com a central em relação a um adaptador de rede. Esse mal-entendido resultou na perda da conexão de rede do sistema. Se eles não entenderam, tenho certeza de que há outros que também não entenderam, então este blog tentará explicar quando um sistema entrará em contato com a central em relação a um adaptador de rede.
A resposta simples é que o sistema entrará em contato com a central quando detectar que o adaptador de rede falhou. A área cinzenta é o que significa falha. Se o adaptador quebrar ou for danificado pelo sistema, um conjunto de diagnósticos será executado e, se o adaptador for aprovado, ele será colocado novamente em serviço. Se ele quebrar muitas vezes em um intervalo de tempo muito curto, o adaptador excederá o limite de MTBF (tempo médio entre falhas) e permanecerá fora de serviço. Se isso acontecer, o sistema entrará em contato com a central em relação ao adaptador. Se os diagnósticos forem executados e falharem, o adaptador permanecerá fora de serviço e o sistema entrará em contato com a central.
Se as mensagens de teste sdlmux, que são transmitidas entre os adaptadores de rede ativo e em espera, não forem recebidas pelo adaptador parceiro, o sistema desativará a placa em espera, testará e a colocará novamente em serviço. Se o que bloqueou as mensagens de teste não for resolvido, esse padrão se repetirá até que a placa exceda o limite MTBF e o sistema entre em contato com a central. Observe aqui que o problema pode não ser o adaptador, mas a rede.
Se um link cair, de modo que um adaptador não esteja mais conectado à rede, o sistema fará o failover dos adaptadores de rede conforme necessário e não fará mais nada. Ele não entrará em contato com a central. A razão para isso é que existem muitos motivos, quase todos externos ao adaptador, para que o link caia. Vinte e dois anos atrás, na versão 8.0 do VOS, a implementação original do Stratus Ethernet entrava em contato com a central quando um link era perdido. Isso resultou em muitos problemas sendo abertos, o que apenas incomodava as pessoas quando ligávamos de volta, pois elas sabiam que haviam reiniciado um switch ou removido um cabo. Naquela época, foi decidido que uma conexão perdida não seria considerada uma falha. Observe que as mensagens de teste sdlmux mencionadas no parágrafo anterior não são enviadas, a menos que ambos os adaptadores tenham uma conexão com a rede.
Então, o que aconteceu com os usuários mencionados no parágrafo inicial? Há cerca de um mês, eles perderam a conexão com um adaptador. Eles não perceberam isso porque o sistema não apresentava problemas de conectividade. Então, há alguns dias, eles perderam a outra conexão e, nesse momento, ficaram fora da rede. Esse cenário demonstra por que é importante monitorar os adaptadores em seu sistema para confirmar se eles estão conectados à rede. O monitoramento periódico teria identificado o problema com o link do primeiro adaptador a tempo de corrigi-lo antes que o problema com o link do segundo adaptador ocorresse.
A macro de comando monitor_sdlmux_adapter_status (figura 1) monitorará periodicamente todos os adaptadores parceiros sdlmuxed. Ela enviará uma mensagem de 25 linhas para usuários selecionados e adicionará uma entrada no syserr_log. Uma entrada syserr_log é feita quando o link é perdido pela primeira vez, mas a macro monitor_sdlmux_adapter_status adicionará uma cada vez que verificar, tornando-a mais provável de ser vista (figura 2). A macro deve ser executada como um processo iniciado com -privileged definido como sim, pois ela chama analyze_system para obter a lista de dispositivos sdlmux.
A macro também verifica se um dos adaptadores está “DESLIGADO” e reporta isso da mesma forma que reporta uma ligação perdida. O sistema deveria ter chamado para casa, mas foi fácil adicionar a verificação e achei que a notificação extra não faria mal.
A linha 25 e as mensagens syserr_log remetem você ao arquivo check_adapters no diretório home de quem estiver executando a macro monitor_sdlmux_adapter_status. Esse arquivo consiste na saída do comando dlmux_admin sdlmux_status executado em todas as parcerias sdlmux no sistema (figura 3). Você precisará revisar esse arquivo para identificar o(s) adaptador(es) específico(s) com problema.
A macro analisa apenas os adaptadores que foram emparelhados com o sdlmux. Problemas com adaptadores que não foram emparelhados são imediatamente aparentes, portanto, não é necessário monitoramento adicional. Observe que a Stratus recomenda que todos os adaptadores de rede sejam emparelhados com o sdlmux.
& monitor_sdlmux_adapter_status begins here |
Figura 1 – A macro do 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 – Mensagens 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 – saída do arquivo check_adapters mostrando que #enetA.m16.10-5-0 perdeu a conexão
