Cloud Operations

OpenStack VM 운영: OpenStack VM 상태 전이가 실패할 때 - scheduler 판단 관점

OpenStack VM 상태 전이가 실패할 때를 scheduler 판단 관점에서 좁혀 보는 케이스. OpenStack 계층의 증상, 확인 명령, 조치 전 판단, 복구 기준을 정리했다.

devmes

• 조회 35

이 글은 OpenStack VM 운영: OpenStack VM 상태 전이가 실패할 때 - scheduler 판단 관점 케이스를 다룬다. 핵심은 OpenStack VM 상태 전이가 실패할 때를 scheduler 판단 관점에서 좁혀 보는 케이스다.

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

OpenStack에서 VM 상태 조작이 실패할 때는 단일 명령 실패로 보지 않는 편이 낫다. scheduler, aggregate, storage backend, network reachability가 모두 맞아야 VM이 원하는 host에서 정상 상태로 돌아온다.

OpenStack 계열 장애는 결과보다 scheduler의 선택 과정을 보는 쪽이 빠르다. flavor, aggregate, AZ, volume backend가 서로 맞지 않으면 VM은 계속 같은 방향으로 실패하고, 단순 재시도는 상태만 더 꼬이게 만든다.

이 글에서 다루는 케이스

케이스 초점OpenStack VM 상태 전이가 실패할 때를 scheduler 판단 관점에서 좁혀 보는 케이스
정리한 주제OpenStack
주요 계층Nova scheduler, Cinder volume, Neutron network, host aggregate
운영 단서주제 프로파일과 장애 흐름 기준으로 재구성

겉으로 보이는 증상

  • server resize, shelve, unshelve, boot 과정에서 잘못된 compute host가 선택된다.
  • 선택된 compute host와 backend storage/network 사이 reachability가 맞지 않는다.
  • API mapping, flavor, aggregate, availability zone 설정이 서로 어긋난다.

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

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

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

처음에 나눠봐야 할 것

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

  • server action history로 어떤 API가 먼저 상태를 꼬이게 했는지 확인한다.
  • flavor extra specs, host aggregate, AZ, volume backend를 같은 기준으로 본다.
  • compute host에서 storage path와 network route를 직접 확인한다.

확인에 쓴 명령 흐름

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

openstack server show <server-id> -f yaml
openstack server event list <server-id>
openstack server event show <server-id> <request-id>
openstack volume show <volume-id> -f yaml
openstack aggregate list
openstack aggregate show <aggregate-name>

ip route
ping -c 3 <storage-endpoint>
grep <request-id> /var/log/nova/nova-compute.log
grep <request-id> /var/log/cinder/cinder-volume.log

조치 전에 판단할 지점

  • 잘못된 aggregate 선택이면 aggregate membership 또는 flavor mapping을 수정한다.
  • 스토리지 접근 문제가 있으면 임시 route보다 scheduler 정책 수정이 우선인지 판단한다.
  • 복구 후 resize/unshelve를 다시 수행할 때는 target host를 명확히 통제한다.

복구됐다고 판단하는 기준

  • server가 의도한 compute host에서 ACTIVE 상태인지 확인한다.
  • volume attachment와 multipath/iSCSI/Ceph 접근이 정상인지 본다.
  • nova-compute, scheduler, cinder 로그에 같은 request id가 실패하지 않는지 확인한다.

운영하면서 남은 교훈

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

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

BGM EVER