Cloud Operations

볼륨·스냅샷·SR: 스토리지 상태와 VM 상태가 다르게 보일 때 - guest OS 관점

스토리지 상태와 VM 상태가 다르게 보일 때를 guest OS 관점에서 좁혀 보는 케이스. Storage / Volume 계층의 증상, 확인 명령, 조치 전 판단, 복구 기준을 정리했다.

devmes

• 조회 117

이 글은 볼륨·스냅샷·SR: 스토리지 상태와 VM 상태가 다르게 보일 때 - guest OS 관점 케이스를 다룬다. 핵심은 스토리지 상태와 VM 상태가 다르게 보일 때를 guest OS 관점에서 좁혀 보는 케이스다.

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

스토리지 계층 장애는 조급하게 attach/detach를 반복할수록 상태가 더 나빠질 수 있다. 특히 VDI/VBD, snapshot chain, tapdisk가 얽힌 경우에는 어떤 계층이 아직 disk를 붙잡고 있는지부터 봐야 한다.

볼륨 장애는 포털의 attach/detach 상태만 보고 판단하면 놓치는 지점이 많다. 실제로는 guest OS의 mount 상태, XenServer의 VDI/VBD 연결, SR 여유량, snapshot chain이 모두 한 줄로 맞아야 정상이라고 볼 수 있다.

이 글에서 다루는 케이스

케이스 초점스토리지 상태와 VM 상태가 다르게 보일 때를 guest OS 관점에서 좁혀 보는 케이스
정리한 주제Storage / Volume
주요 계층SR, VDI, VBD, snapshot chain, tapdisk
운영 단서주제 프로파일과 장애 흐름 기준으로 재구성

겉으로 보이는 증상

  • 볼륨 attach/detach가 실패하거나 포털 상태와 hypervisor 상태가 다르다.
  • snapshot, coalesce, garbage, primary VHD, SR 용량 계산이 맞지 않는다.
  • tapdisk 또는 VBD가 남아 VM disk I/O가 멈추거나 작업이 hang 상태가 된다.

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

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

  • `서버 hang 원인 / vm hang / server hang 원인`
  • `금번 귀사 서버 hang의 정확한 원인을 파악하기는 어려우나,`
  • `- Flushing 시간 동안에 시스템은 거의 얼음 상태인데, 무한정 시간을 줄 수 없으니 time out이 존재함(default 120초)`
  • `Flushing이 120초를 넘어가는 일이 반복되게 되면 결국 시스템이 hang상태에 빠질 수 있음`
  • `ㅇ 서버 hang 해소 방안`
  • `- I/O성능을 높이는 방안`

처음에 나눠봐야 할 것

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

  • CloudStack volume 상태, XenServer VDI/VBD 상태, SR free space를 한 번에 본다.
  • 스냅샷 chain 문제는 현재 VHD, parent, coalesce task를 따로 확인한다.
  • attach/detach 문제는 guest OS umount 여부와 hypervisor VBD 상태를 분리한다.

확인에 쓴 명령 흐름

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

xe sr-list params=uuid,name-label,physical-size,physical-utilisation
xe vdi-list name-label=<volume-name> params=uuid,name-label,virtual-size,physical-utilisation,sm-config
xe vbd-list vdi-uuid=<vdi-uuid> params=uuid,vm-uuid,device,currently-attached
xe task-list status=pending

tap-ctl list
lsof /var/log
tail -n 200 /var/log/SMlog
tail -n 200 /var/log/blktap/tapdisk.<pid>.log

df -h
lsblk -f
mount | grep <mount-point>

조치 전에 판단할 지점

  • detach 전 guest OS filesystem flush/umount 여부를 확인한다.
  • VBD가 남아 있으면 VM power state와 device path를 확인한 뒤 정리한다.
  • SR 부족은 logical size와 physical utilization을 구분해서 capacity plan을 잡는다.

복구됐다고 판단하는 기준

  • VDI/VBD 목록에서 orphan attachment가 사라졌는지 확인한다.
  • VM 부팅 후 guest OS에서 disk, filesystem, mount 상태를 확인한다.
  • snapshot/coalesce task가 새로 누적되지 않는지 확인한다.

운영하면서 남은 교훈

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

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

BGM EVER