Cloud Operations

Compute Node 장애: compute node 장애 뒤 VM 위치를 정리할 때 - host 상태 관점

compute node 장애 뒤 VM 위치를 정리할 때를 host 상태 관점에서 좁혀 보는 케이스. Compute Node 계층의 증상, 확인 명령, 조치 전 판단, 복구 기준을 정리했다.

devmes

• 조회 147

이 글은 Compute Node 장애: compute node 장애 뒤 VM 위치를 정리할 때 - host 상태 관점 케이스를 다룬다. 핵심은 compute node 장애 뒤 VM 위치를 정리할 때를 host 상태 관점에서 좁혀 보는 케이스다.

수집한 운영 단서에서 고객명, 내부 주소, 노드명을 제거하고 장애 흐름과 확인 순서만 남겼다.

compute node 장애는 한 대의 서버 문제가 아니라 그 위에 올라간 VM 묶음의 서비스 장애로 번진다. 그래서 첫 판단은 hardware 교체가 아니라, 남아 있는 VM을 어디까지 안전하게 옮길 수 있는지에서 시작한다.

운영 장애 대응은 원인을 바로 단정하기보다 계층을 나눠 증거를 맞추는 쪽이 안전하다. read-only 확인, 변경 조치, 검증 명령을 분리해야 긴급 상황에서도 판단이 흔들리지 않는다.

이 글에서 다루는 케이스

케이스 초점compute node 장애 뒤 VM 위치를 정리할 때를 host 상태 관점에서 좁혀 보는 케이스
정리한 주제Compute Node
주요 계층XenServer host, VM scheduling, hardware fault
운영 단서주제 프로파일과 장애 흐름 기준으로 재구성

겉으로 보이는 증상

  • compute node hardware fault, reboot, hang, power off 이후 VM 제어가 불안정하다.
  • 관리 포털에서는 VM이 Running으로 보이지만 실제 hypervisor에서는 domain이 없거나 멈춰 있다.
  • 장애 host에서 migration, evacuation, maintenance 전환이 실패한다.

로그에서 먼저 눈에 들어오는 신호

운영 중에는 긴 설명보다 반복되는 로그 문구가 먼저 눈에 들어온다. 아래 신호는 실제 값 대신 예시 placeholder로 바꿔 흐름만 볼 수 있게 정리했다.

  • Compute Node 계층에서 증상이 시작되지만 실제 원인은 다른 계층에 있을 수 있다.
  • 눈에 보이는 에러보다 장애 시각, 대상 리소스, 직전 변경 이력을 먼저 맞추는 편이 빠르다.
  • 읽기 전용 확인과 상태 변경 작업을 분리하면 급한 상황에서도 판단이 흐려지지 않는다.

처음에 나눠봐야 할 것

이 케이스는 한 번에 해결 명령을 찾기보다, 아래 기준으로 계층을 나누는 것이 먼저다.

  • host의 전원, management network, storage path, xapi 상태를 먼저 분리한다.
  • VM 단위 문제가 아니라 host 단위 문제인지 resident VM 목록으로 확인한다.
  • hardware 교체 전후에는 service tool 로그와 hypervisor 로그를 같이 남긴다.

확인에 쓴 명령 흐름

아래 명령은 공개 가능한 형태로 일반화했다. 실제 값은 환경마다 다르므로 placeholder를 대상 리소스에 맞춰 바꿔야 한다.

xe host-list params=uuid,name-label,enabled
xe host-param-list uuid=<host-uuid>
xe vm-list resident-on=<host-uuid> params=uuid,name-label,power-state
xe task-list status=pending

systemctl status xapi --no-pager
tail -n 200 /var/log/xensource.log
tail -n 200 /var/log/messages

xe vm-migrate vm=<vm-uuid> host=<target-host-uuid> live=true
xe host-disable uuid=<host-uuid>

조치 전에 판단할 지점

  • 가능하면 live migration으로 비우고, 불가능하면 HA 또는 cold migration 경로를 사용한다.
  • xapi 재시작은 진행 중 task와 VM 영향도를 확인한 뒤 maintenance window에서 수행한다.
  • 장애 host 격리 후 target host의 CPU, memory, SR 여유량을 확인한다.

복구됐다고 판단하는 기준

  • 장애 host가 pool에서 disable/maintenance 상태인지 확인한다.
  • 이전된 VM의 power state, NIC, disk attachment를 확인한다.
  • xensource.log와 management-server.log에 신규 error가 반복되지 않는지 확인한다.

운영하면서 남은 교훈

이 케이스는 조치 자체보다 대상 식별이 더 중요하다. 같은 “VM이 안 된다”는 증상이어도 VM guest, compute host, storage attachment, virtual router, management service 중 어디가 기준점인지에 따라 명령과 위험도가 완전히 달라진다.

장애 시각, 대상 리소스, 직전 변경 이력, 확인 명령, 실제 조치, 검증 결과를 같은 순서로 남겨두면 다음 장애에서 단순 기억이 아니라 판단 근거로 다시 쓸 수 있다.

BGM EVER