Cloud Operations

CloudStack HA 복구: HA가 늦게 동작할 때 - HA 판단 관점

HA가 늦게 동작할 때를 HA 판단 관점에서 좁혀 보는 케이스. CloudStack HA 계층의 증상, 확인 명령, 조치 전 판단, 복구 기준을 정리했다.

devmes

• 조회 83

이 글은 CloudStack HA 복구: HA가 늦게 동작할 때 - HA 판단 관점 케이스를 다룬다. 핵심은 HA가 늦게 동작할 때를 HA 판단 관점에서 좁혀 보는 케이스다.

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

이 케이스의 출발점은 compute node 장애 이후 HA가 기대한 속도로 따라오지 않는 상황이다. 먼저 자동화가 늦은 것인지, platform이 VM 위치를 잘못 알고 있는 것인지, host 격리가 덜 된 것인지를 나눠야 한다.

자동 HA가 늦어지는 상황은 겉으로 보면 단순히 VM을 다시 켜면 될 것처럼 보인다. 하지만 실제 운영에서는 CloudStack이 기억하는 host_id, XenServer가 들고 있는 resident VM, 장애 host의 enable 상태가 맞지 않아 복구 명령 하나가 다른 장애로 이어질 수 있다.

이 글에서 다루는 케이스

케이스 초점HA가 늦게 동작할 때를 HA 판단 관점에서 좁혀 보는 케이스
정리한 주제CloudStack HA
주요 계층Compute host, CloudStack DB, HA automation
운영 단서1개 명령/로그 단서 기준으로 재구성

겉으로 보이는 증상

  • compute node 장애 후 VM 자동 HA가 지연되거나 일부 VM만 기동된다.
  • CloudStack UI 상태와 XenServer 실제 power state가 어긋난다.
  • 장애 host를 disable해야 하는데 대상 VM과 master host를 먼저 검증해야 한다.

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

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

  • `Xentool 에 따른 VM Hang 조치`
  • `--54 | VM - Hang 조치(Windows 서버, Xentool문제)`
  • `[<account> ~]# zgrep 'XENBUS | GnttabGet: fail1 ' /var/log/messages.*`
  • `/var/log/messages.1.gz:May 3 13:30:43 compute-node fe: qemu-dm-84[20669]: XENBUS | GnttabGet: fail1 (c000009a)`

처음에 나눠봐야 할 것

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

  • 장애 host의 CloudStack host id, XenServer host uuid, cluster/master 관계를 분리해서 확인한다.
  • VM 목록은 CloudStack DB의 state와 XenServer의 domain/power state를 함께 본다.
  • 수동 HA는 전체 VM을 일괄 처리하기보다 대상 host에 남은 Running VM만 좁혀서 수행한다.

확인에 쓴 명령 흐름

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

mysql -h <cloudstack-db> -u <readonly_user> -p cloud

select id, name, status, resource_state
from host
where name like '%<compute-host-pattern>%';

select id, instance_name, state, power_state, host_id
from vm_instance
where host_id = <host_id>
order by state, instance_name;

xe host-list name-label=<compute-host>
xe vm-list resident-on=<host-uuid> power-state=running
xe task-list status=pending

tail -n 200 /var/log/cloudstack/management/management-server.log
tail -n 200 /var/log/xensource.log

조치 전에 판단할 지점

  • 장애 host를 disable하기 전 대상 VM 목록, 서비스 영향, start 가능한 target host를 확정한다.
  • CloudStack DB 상태 변경이 필요한 경우에는 쿼리 결과를 캡처하고 단일 트랜잭션 범위로 진행한다.
  • 수동 stop/start 후에는 성공 VM과 실패 VM을 분리해서 재시도한다.

복구됐다고 판단하는 기준

  • VM state와 power_state가 Running으로 맞는지 확인한다.
  • 서비스 포트와 사용자 경로가 살아났는지 별도 네트워크 체크를 수행한다.
  • 장애 host에 VM이 남아 있지 않고 maintenance/disable 상태가 의도대로 유지되는지 본다.

운영하면서 남은 교훈

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

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

BGM EVER