Nutanix 에서 네트워크에 문제가 생겨 서비스에 영향을 주는 부분은 아주 민감하게 반응할 수 있습니다. 물리적으로 교체하면 해결되는 문제도 있지만 원인을 알 수 없는 장애도 있는데요. 오늘은 이런 원인을 알수없는(?) 장애에 대해 겪었던 경험을 공유해 보도록 하겠습니다. 

멀쩡하던 물리 포트가 왜 자꾸 죽는 걸까? (장애 증상 확인)

얼마 전 고객사에서 꽤 골치 아픈 Case Open이 하나 들어왔습니다. 수많은 가상머신이 숨 가쁘게 돌아가는 엔터프라이즈 인프라 환경에서 특정 물리 NIC 포트가 자꾸 다운된다는 다급한 연락이었죠.

담당자분은 호스트 리부팅을 하면 일시적으로 네트워크가 다시 붙어서 정상화된다고 하셨지만, 며칠 안 가서 또 같은 포트가 죽어버리는 증상이 무한 반복되고 있었습니다. 장비 불량인지 케이블 문제인지 헷갈릴 때는 가장 먼저 시스템 내부에서 각 물리 포트의 상태를 어떻게 인지하고 있는지 OVS(Open vSwitch)의 본딩 상태부터 까보는 게 인프라 엔지니어의 기본입니다. 현재 액티브-백업(Active-Backup) 구조로 묶인 인터페이스들의 상세 해시 방식과 딜레이 값을 함께 출력해 주는 명령어를 실행해 봤습니다. 

[root@host ~]# ovs-appctl bond/show
br0-up-
bond_mode: active-backup
bond may use recirculation: no, Recirc-ID: -1
bond-hash-basis: 0
updelay: 0 ms
downdelay: 0 ms
active member mac: 00:00:00:00:00:00 (none)
member eth2: disabled
may_enable: false
member eth3: disabled
may_enable: false

명령어를 치고 결과를 확인하는 순간 느낌이 쎄하더군요. 위 출력 결과를 보시면 member eth2와 eth3의 상태가 완전히 disabled로 떨어져 있고, 심지어 may_enable 파라미터마저 false로 굳어버린 것을 볼 수 있습니다. 여기서 주의 깊게 보셔야 할 부분이 바로 updelay와 downdelay 값이 0 ms로 세팅되어 있다는 점입니다. 딜레이가 0이라는 건 포트 장애 감지 시 즉각적으로 백업 포트로 트래픽을 넘기겠다는 의도인데, 지금은 액티브와 백업 물리 포트 양쪽 모두가 논리적으로 차단되어 버렸습니다.

💡 OVS 인터페이스 팁: may_enable: false는 단순히 케이블이 뽑힌 Link Down 상태를 넘어서 OVS 레벨에서 해당 네트워크 인터페이스를 블랙리스트 처리하고 트래픽을 태울 의지조차 없다는 뜻이에요. 스위치 쪽 포트 에러가 아니라면 이건 100% 서버 내부 하드웨어나 드라이버 단의 심각한 충돌입니다.

범인은 커널 로그에 숨어있다 (0xffffffff 패닉 에러의 정체)

곧바로 OS 커널이 내뱉는 메시지를 뒤지기 시작했습니다. 하드웨어와 직접 통신하는 드라이버 단에서 무슨 일이 벌어지는지 확인하려면 dmesg를 치거나 /var/log/messages 파일을 열어보는 것 외엔 답이 없거든요.

파일을 열어서 해당 포트가 죽어버린 타임스탬프를 쭉 따라가다 보니 범인이 정확히 잡혔습니다. Nutanix NX 노드에 장착된 Broadcom BCM57414 NIC를 제어하는 bnxt_en 드라이버가 완전히 패닉 상태에 빠져서 절규하고 있더군요. 컨트롤러에 명령을 날려도 돌아오는 응답이 없으니 리눅스 커널이 해당 장치와의 통신 메시지를 스스로 포기(abandoning)해 버리는 끔찍한 로그가 초 단위로 찍히고 있었습니다. 

[9775.939002] bnxt_en 0000:90:00.1 eth3: hwrm_ring_free type 2 failed. rc:fffffff0 err:0
[9775.942256] bnxt_en 0000:90:00.1 eth3: Resp cmpl intr abandoning msg: 0x51 due to firmware status: 0xffffffff
[9775.956098] bnxt_en 0000:90:00.1 eth3: Abandoning msg {0x510x70cb} len: 0 due to firmware status: 0xffffffff
[9776.105043] bnxt_en 0000:90:00.1 eth3: hwrm stat ctx alloc failure rc: ffffffff0
[9776.112080] bnxt_en 0000:90:00.1 eth3: nic open fail (rc: ffffffff0)

여기서 가장 중요한 핵심 키워드는 바로 firmware status: 0xffffffff 입니다. 이 16진수 코드는 엔지니어들에게 일종의 하드웨어 사망 선고나 다름없어요. 칩셋 자체가 완전히 뻗어서 응답 불능(Unresponsiveness) 상태에 빠졌다는 명백한 증거입니다. 로그 첫 줄의 hwrm_ring_free failed 부분을 눈여겨보세요.

  • 패킷을 처리하고 난 뒤 NIC의 링 버퍼 메모리를 반환(free)하라고 OS가 명령을 내렸는데 하드웨어가 묵묵부답인 겁니다.
  • 드라이버가 버퍼를 비우려고 시도해도 이미 펌웨어가 죽었기 때문에 계속 실패하고, 결국 인터페이스를 초기화하는 nic open fail 상태로 처박히는 악순환의 고리죠.
  • 리부팅을 하면 칩셋에 전원이 다시 들어가니 잠깐 살아나지만 펌웨어의 근본적인 메모리 관리 버그는 그대로니까 계속 트래픽이 몰리면 장애가 재발했던 겁니다.

펌웨어 버전 비교와 해결책 (KB-20919 팩트 체크)

로그를 캡처해서 즉각 제조사 쪽 문서를 뒤져보니, 아니나 다를까 Broadcom BCM57414 NIC가 AHV 환경에서 펌웨어 불안정성으로 인터페이스를 죽여버리는 Known Issue(KB-20919)가 존재했습니다. 당시 고객사의 NIC 펌웨어 버전이 219.xx 버전이었는데 제조사 권고사항에 따라 버그가 패치된 225.xx 버전으로 펌웨어 업그레이드를 진행해야만 이 지옥에서 벗어날 수 있었습니다.

구분 펌웨어 버전 (FW) 호스트 로그 주요 증상 OVS 인터페이스 상태 비고 및 조치사항
장애 환경 219.xx.버전 firmware status: 0xffffffff 무한 출력 disabled (may_enable: false) 버퍼 반환 실패로 인한 칩셋 응답 불능 상태
권장 환경 225.xx 이상 정상 패킷 송수신 로그 기록 active (정상 포워딩) 메모리 누수 버그 패치 완료, 롤링 업그레이드 요망

위 표에서 보시는 것처럼 219.xx 버전은 사실상 시한폭탄을 안고 운영하는 것과 같습니다. 트래픽 로드가 일정 수준 이상 걸리면 언제든 칩셋이 뻗어버릴 수 있는 상태죠. 해결책은 명확합니다. Nutanix LCM(Life Cycle Manager)을 통해 클러스터 단위로 롤링 업그레이드를 태워야 합니다. 펌웨어를 225.xx로 올리고 며칠 동안 포트 모니터링을 걸어둔 결과 더 이상 0xffffffff 펌웨어 응답 불가 로그는 단 한 줄도 떨어지지 않았습니다. 본딩 인터페이스도 안정적으로 액티브 상태를 짱짱하게 유지했고요.


실무에서 주의할 점 (공식 문서에는 안 나오는 스위치 오버의 함정)

현장에서 이 장애를 겪을 동료 엔지니어분들을 위해 아주 중요한 팁을 하나 드릴게요. 이런 펌웨어 버그로 인한 포트 다운은 단순히 네트워크가 한 번 끊기는 문제로 끝나지 않습니다.

NIC 펌웨어 버전 확인 화면
NIC 펌웨어 버전 확인 화면

이 이미지는 작업 전 클러스터 내 모든 노드의 일부 NIC 펌웨어 버전을 비교해 본 화면입니다. 이 확인 절차를 대충 건너뛰면 대형 사고가 터집니다. 만약 액티브-백업(Active-Backup)으로 묶인 두 개의 물리 포트가 모두 버그를 가진 동일한 219.xx 버전의 펌웨어를 사용하고 있다면 어떨까요? 액티브 포트가 패닉에 빠져 죽는 순간 백업 포트로 스위치 오버(Switch Over)가 일어나면서 트래픽이 확 쏟아지게 됩니다. 이때 백업 포트마저 연달아 펌웨어 패닉을 일으키면서 해당 호스트 전체가 네트워크에서 완벽히 고립되는 아찔한 상황이 발생할 수 있습니다. 가상머신들이 몽땅 네트워크 미아가 되는 거죠.

작업 전 반드시 클러스터 내 전체 노드의 인벤토리를 스캔해서 위험 노드와 포트를 정확히 식별하세요. 그리고 펌웨어 업데이트를 진행할 때는 절대 호스트 다수를 한 번에 재부팅하지 마시고, 하나의 노드가 완전히 정상화되어 클러스터 데이터 복제(Resiliency)가 그린(Green) 상태로 돌아온 것을 확인한 뒤 다음 노드로 넘어가는 롤링(Rolling) 방식을 뼈에 새기셔야 합니다. 시간이 몇 시간 더 걸리더라도 무조건 인프라는 안전이 최우선이니까요.

항상 예기치 못한 상황은 발생하기 마련 입니다. 하지만 같은 상황이 계속 발생하게 된다면 예기치 못한 상황은 아니겠죠?  오늘도 많은 엔지니어 분들에게 조금이나마 도움되길 바랍니다 ^^