최근 몇몇 사용자와의 논의 중, 그들이 스트라터스 V시리즈 시스템이 네트워크 어댑터와 관련해 본사로 연락을 취하는 조건을 이해하지 못한다는 점이 분명해졌습니다. 이 오해로 인해 시스템이 네트워크 연결을 상실하는 사태가 발생했습니다. 그들이 이해하지 못했다면 분명 다른 사용자들도 마찬가지일 것이므로, 본 블로그에서는 시스템이 네트워크 어댑터와 관련해 본사로 연락을 취하는 시점을 설명하고자 합니다.
간단한 답변은 시스템이 네트워크 어댑터의 고장을 감지하면 본사로 연락한다는 것입니다. 애매한 부분은 '고장'이 무엇을 의미하는지입니다. 어댑터가 고장 나거나 시스템에 의해 손상되면 일련의 진단이 실행됩니다. 어댑터가 진단을 통과하면 다시 사용 가능 상태로 복귀합니다. 너무 짧은 시간 간격에 너무 자주 고장 나면 어댑터는 MTBF(평균 고장 간격) 임계값을 초과하여 사용 불가 상태로 유지됩니다. 이 경우 시스템은 어댑터 관련 정보를 본사로 보고합니다. 진단 실행 시 실패하면 어댑터는 계속 사용 불가 상태로 유지되며 시스템은 본사로 보고합니다.
활성 및 대기 네트워크 어댑터 파트너 간에 전달되는 sdlmux 테스트 메시지가 파트너 어댑터에 수신되지 않을 경우, 시스템은 대기 카드를 분리하여 테스트한 후 다시 서비스에 복귀시킵니다. 테스트 메시지 전달을 차단한 원인이 해결되지 않으면 이 패턴이 반복되며, 카드가 MTBF 임계값을 초과할 때까지 지속된 후 시스템이 본사로 알립니다. 여기서 주의할 점은 문제가 어댑터가 아닌 네트워크에 있을 수 있다는 것입니다.
링크가 끊어져 한 어댑터가 네트워크에 더 이상 연결되지 않으면 시스템은 필요에 따라 네트워크 어댑터를 페일오버할 뿐 그 외에는 아무 조치도 취하지 않습니다. 본사로 연락하지 않습니다. 그 이유는 링크가 끊어질 수 있는 원인이 너무 많고, 거의 모든 원인이 어댑터 외부에서 발생하기 때문입니다. 22년 전 VOS 8.0 버전에서 원래 Stratus 이더넷 구현은 링크가 끊어질 때 본사로 연락했습니다. 이로 인해 수많은 이슈가 발생했으며, 당사가 고객에게 연락했을 때 고객들은 스위치를 재부팅했거나 케이블을 제거한 사실을 알고 있었기에 오히려 불쾌감을 느꼈습니다. 당시 링크 손실을 장애로 간주하지 않기로 결정되었습니다. 참고로, 앞단락에서 언급된 sdlmux 테스트 메시지는 양쪽 어댑터 모두 네트워크에 연결된 상태일 때만 전송됩니다.
그렇다면 서두에서 언급한 사용자들은 어떻게 되었을까요? 약 한 달 전, 그들은 한 어댑터와의 연결을 잃었습니다. 시스템에 연결 문제가 발생하지 않았기 때문에 그들은 이를 인지하지 못했습니다. 그러다 며칠 전 다른 연결도 끊어지면서 네트워크에서 완전히 이탈하게 되었습니다. 이 사례는 시스템의 어댑터가 네트워크에 연결되어 있는지 확인하기 위해 모니터링이 중요한 이유를 보여줍니다. 주기적인 모니터링을 했다면 첫 번째 어댑터 링크의 문제를 제때 발견하여 두 번째 어댑터 링크 문제가 발생하기 전에 해결할 수 있었을 것입니다.
monitor_sdlmux_adapter_status 명령어 매크로(그림 1)는 모든 sdlmux로 연결된 페어링 어댑터를 주기적으로 모니터링합니다. 선택된 사용자에게 25번째 라인 메시지를 전송하고 syserr_log에 항목을 추가합니다. 링크가 처음 끊어질 때 syserr_log 항목이 생성되지만, monitor_sdlmux_adapter_status 매크로는 매번 확인할 때마다 항목을 추가하므로 더 쉽게 확인할 수 있습니다(그림 2). 이 매크로는 sdlmux 장치 목록을 얻기 위해 analyze_system을 호출하므로 -privileged를 yes로 설정하여 시작 프로세스로 실행해야 합니다.
매크로는 또한 어댑터 중 하나가 "DOWN" 상태인지 확인하며, 링크 끊김을 보고하는 방식과 동일하게 이를 보고합니다. 시스템은 본사에 보고해야 했지만, 해당 확인 기능을 추가하는 것은 쉬웠고 추가 알림이 해가 될 리 없다고 판단했습니다.
25번째 줄과 syserr_log 메시지는 monitor_sdlmux_adapter_status 매크로를 실행 중인 사용자의 홈 디렉터리에 있는 check_adapters 파일을 참조하도록 안내합니다. 해당 파일은 시스템 내 모든 sdlmux 파트너십에 대해 실행된 dlmux_admin sdlmux_status 명령어의 출력 결과로 구성됩니다(그림 3). 문제 발생 어댑터를 식별하려면 해당 파일을 검토해야 합니다.
이 매크로는 sdlmux와 페어링된 어댑터만 확인합니다. 페어링되지 않은 어댑터의 문제는 즉시 확인되므로 추가 모니터링이 필요하지 않습니다. Stratus는 모든 네트워크 어댑터를 sdlmux와 페어링할 것을 권장합니다.
& monitor_sdlmux_adapter_status begins here |
그림 1 – 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. . . . . . . . . |
그림 2 – 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 |
그림 3 – #enetA.m16.10-5-0이 링크를 잃었음을 보여주는 check_adapters 파일의 출력