Cloud Operations

VMware·vCloud: VMware 관리 작업이 화면에서 멈춘 것처럼 보일 때 - 관리 계층 관점

VMware 관리 작업이 화면에서 멈춘 것처럼 보일 때를 관리 계층 관점에서 좁혀 보는 케이스. VMware / vCloud 계층의 증상, 확인 명령, 조치 전 판단, 복구 기준을 정리했다.

devmes

• 조회 92

이 글은 VMware·vCloud: VMware 관리 작업이 화면에서 멈춘 것처럼 보일 때 - 관리 계층 관점 케이스를 다룬다. 핵심은 VMware 관리 작업이 화면에서 멈춘 것처럼 보일 때를 관리 계층 관점에서 좁혀 보는 케이스다.

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

VMware 관리 계층의 pending 작업은 한 화면으로 결론 내리기 어렵다. vCD, vCenter, ESXi, DB job이 서로 다른 상태를 보일 수 있기 때문에 작업 흐름을 시간순으로 다시 맞춰야 한다.

VMware 관리 계층에서는 vCD, vCenter, ESXi, DB job 상태가 서로 다르게 보일 수 있다. 한 화면의 pending만 보고 DB를 바로 수정하면 실제 backend task와 충돌할 수 있다.

이 글에서 다루는 케이스

케이스 초점VMware 관리 작업이 화면에서 멈춘 것처럼 보일 때를 관리 계층 관점에서 좁혀 보는 케이스
정리한 주제VMware / vCloud
주요 계층vCenter, vCloud Director, vROps, vCAV
운영 단서주제 프로파일과 장애 흐름 기준으로 재구성

겉으로 보이는 증상

  • vCloud Director job, vROps report, vCAV 인증서/URL filter 등 VMware 계층 작업이 실패한다.
  • 관리 포털 작업은 pending이지만 vCenter task는 완료 또는 실패로 다르게 보인다.
  • 인증서, NTP, endpoint reachability 문제가 job 실패로 보인다.

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

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

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

처음에 나눠봐야 할 것

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

  • vCD, vCenter, ESXi, DB job 상태를 같은 시간대 기준으로 맞춘다.
  • 인증서/시간/NTP/endpoint 연결성을 먼저 확인한다.
  • pending job은 실제 backend task 존재 여부를 확인한 뒤 조치한다.

확인에 쓴 명령 흐름

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

date
ntpq -p || chronyc sources -v
curl -vk https://<vcloud-endpoint>/api/versions

systemctl status vmware-vcd --no-pager
tail -n 200 /opt/vmware/vcloud-director/logs/cell.log

psql -h <vcloud-db> -U <readonly_user> <vcloud_db>
select id, status, operation, creation_date from jobs order by creation_date desc limit 20;

조치 전에 판단할 지점

  • DB 업데이트가 필요한 pending job은 대상 row와 rollback 값을 명확히 기록한다.
  • 인증서 갱신이나 URL filtering 변경은 service restart 영향도를 먼저 확인한다.
  • report 생성 실패는 collector, credential, target object permission을 분리한다.

복구됐다고 판단하는 기준

  • vCD/vCenter 양쪽에서 task 상태가 일치하는지 확인한다.
  • 대상 VM 또는 org/vDC 작업이 정상 수행되는지 확인한다.
  • 관리 서비스 로그에 같은 exception이 반복되지 않는지 본다.

운영하면서 남은 교훈

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

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

BGM EVER