Cloud Operations

CloudStack Async Job: CloudStack async job이 pending으로 남을 때 - DB 상태 관점

CloudStack async job이 pending으로 남을 때를 DB 상태 관점에서 좁혀 보는 케이스. Async Job 계층의 증상, 확인 명령, 조치 전 판단, 복구 기준을 정리했다.

devmes

• 조회 171

이 글은 CloudStack Async Job: CloudStack async job이 pending으로 남을 때 - DB 상태 관점 케이스를 다룬다. 핵심은 CloudStack async job이 pending으로 남을 때를 DB 상태 관점에서 좁혀 보는 케이스다.

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

CloudStack 운영에서 async job은 장애 원인이자 증거다. 작업이 pending으로 보일 때 실제로는 backend가 일하는 중인지, 이미 끝났는데 상태만 남은 것인지 구분하는 것이 핵심이다.

async job은 오래 남아 있다고 전부 실패가 아니다. backend task가 아직 살아 있는지, sync queue가 재처리 중인지, management server 재시작 때문에 stale 상태로 보이는지에 따라 조치가 완전히 달라진다.

이 글에서 다루는 케이스

케이스 초점CloudStack async job이 pending으로 남을 때를 DB 상태 관점에서 좁혀 보는 케이스
정리한 주제Async Job
주요 계층CloudStack management server, async_job, sync queue
운영 단서2개 명령/로그 단서 기준으로 재구성

겉으로 보이는 증상

  • 관리 작업이 pending으로 남거나 완료 job cleanup 기준이 버전마다 다르게 보인다.
  • management server 재시작 이후 job result가 cancelled 또는 stale 상태로 남는다.
  • UI에서는 작업 중으로 보이지만 실제 backend task는 끝난 상태일 수 있다.

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

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

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

처음에 나눠봐야 할 것

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

  • job id, account, command, instance id를 먼저 식별한다.
  • management-server.log의 AsyncJob heartbeat와 sync queue 로그를 같은 시간대로 본다.
  • 버전별 로그 문구 차이를 감안해 completed/execute sync queue 패턴을 모두 확인한다.

확인에 쓴 명령 흐름

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

grep -E 'AsyncJob|SyncQueue|pending|Execute sync-queue' /var/log/cloudstack/management/management-server.log

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

select id, job_cmd, job_status, job_result_code, created, removed
from async_job
where id = <job_id>;

select id, queue_id, content_type, content_id, last_process_msid, created
from sync_queue_item
where content_id = <job_id>
order by created desc;

조치 전에 판단할 지점

  • 작업이 실제로 진행 중이면 강제 정리하지 않고 backend task 완료를 기다린다.
  • stale job은 DB 상태, management server msid, sync queue 상태를 확인한 뒤 정리한다.
  • 동일 계정/동일 리소스의 중복 작업은 추가 입력을 잠시 멈추고 상태를 먼저 맞춘다.

복구됐다고 판단하는 기준

  • async_job과 sync_queue에서 대상 job이 더 이상 재처리되지 않는지 확인한다.
  • UI의 작업 상태와 실제 리소스 상태가 일치하는지 본다.
  • management log에 같은 job id가 반복되지 않는지 확인한다.

운영하면서 남은 교훈

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

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

BGM EVER