Markdown Preview
openstack compute 노드 제거
Frontmatter
정상 컴퓨트 노드는 스케줄링을 차단하고 인스턴스를 이동·검증한 뒤 서비스와 등록 정보를 정리하고, 장애 노드는 원본을 펜싱하고 데이터 보존 여부를 판단한 후 evacuation과 잔여 자원 점검을 진행해야 한다.
OpenStack을 운영하다 보면 하드웨어 교체나 서버 재배치 때문에 컴퓨트 노드를 제거해야 할 때가 있다. 이때 서버부터 초기화하면 인스턴스 정보는 Nova에 남아 있는데 실제 VM과 로컬 디스크는 사라진 상황을 만날 수 있다.
결론부터 말하면 신규 스케줄링 차단 → 인스턴스 이동 및 검증 → 대상 노드 서비스 중지 → inventory 제외 → 서비스 등록 정보 정리 순서로 진행하면 된다. 이미 장애가 났거나 초기화한 노드는 정상 노드의 migration 절차가 아니라, 데이터 보존 가능성을 먼저 판단한 뒤 evacuation 경로로 접근해야 한다.
이 글에서 다루는 내용
- 정상 노드 제거와 장애·초기화된 노드 처리의 차이
- 작업 전 용량·스토리지·네트워크 확인
- Live migration / Cold migration / Evacuation 선택 기준
- Kolla Ansible에서 특정 노드만 중지하는 방법
- Neutron·Nova 서비스 삭제와 Placement 잔여 allocation 점검
- 작업 후 검증 및 재발 방지 체크리스트
환경과 적용 범위
이 글은 관리자 권한의 OpenStack CLI와 Kolla Ansible 배포 환경을 중심으로 정리한다. 실제 OpenStack 릴리스, hypervisor, Neutron backend와 스토리지 구성은 환경에 맞게 확인해야 한다. 참고 자료의
latest 문서는 변경될 수 있으므로 운영 환경과 같은 릴리스의 문서를 함께 확인하자.항목 | 예시 및 확인 사항 |
제거할 Nova host | dms-compute4 — compute service 목록의 Host 값 |
Ansible inventory host | 예시에서는 dms-compute4 — Nova Host와 다를 수 있음 |
CLI 실행 위치 | 관리자 인증 정보를 로드한 관리 단말 또는 controller |
Kolla 명령 실행 위치 | Kolla Ansible 가상환경을 활성화한 배포 서버 |
대상 | 컴퓨트 전용 노드. Controller·Storage·Network 역할 겸용이면 별도 이관 필요 |
API microversion | 서비스 UUID 조회·삭제 예시는 Compute API 2.53 사용 |
이 문서는 운영 절차를 정리한 가이드이며, 아래 명령을 실제 클러스터에서 실행한 결과는 아니다.
노드 초기화, 컨테이너 삭제, 디스크 포맷은 가장 마지막에 수행한다. 특히 로컬 디스크를 이미 지웠다면
evacuate가 그 데이터를 되살려 주지는 않는다.전체 작업 흐름
정상 노드와 장애 노드의 처리 경로를 포함한 전체 순서다.
대상 노드·겸용 역할 확인
↓
신규 스케줄링 차단(disable)
↓
노드와 VM이 정상 동작하는가?
├─ 예 → Live / Cold migration → 이동·서비스 검증
└─ 아니오 → 원본 노드 fencing → 데이터 보존 판단 → Evacuation·복구 검증
↓
인스턴스 잔여·진행 중 migration이 없는지 확인
↓
대상 노드 서비스 중지 → inventory에서 제외
↓
Neutron agent / nova-compute 등록 삭제
↓
Placement 잔여 정보 확인 → 최종 테스트 → 장비 회수·초기화1단계: 작업 전 상태와 복구 지점 확보
대상 노드와 인스턴스 확인
관리자 인증을 로드한 단말에서 실행한다.
admin-openrc와 inventory 경로는 실제 환경에 맞게 수정한다.source ~/admin-openrc
# Nova Host와 Ansible inventory host를 구분해 지정한다.
HOST='dms-compute4'
INVENTORY_HOST='dms-compute4'
INVENTORY='/path/to/multinode'
openstack compute service list --host "$HOST"
openstack hypervisor list
openstack server list --all-projects --host "$HOST" --long
openstack network agent list --host "$HOST"
openstack volume service listStatus와 State는 의미가 다르다. disabled는 신규 스케줄링 차단, down은 heartbeat 기준 서비스 비정상 상태다. 서버를 초기화했다고 자동으로 disabled가 되는 것은 아니며, disabled라고 VM이 정지하는 것도 아니다.기존 문서에서 확인했던 compute service 목록은 아래와 같다. 과거 캡처이므로 현재 상태는 위 명령으로 다시 확인한다.
사전 확인 체크리스트
- 남은 노드의 vCPU·RAM·디스크 용량과 장애 대비 여유 용량이 충분한가?
- CPU 호환성, NUMA, hugepage, flavor extra spec, aggregate/AZ 제약을 만족하는가?
- GPU·PCI Passthrough·SR-IOV 인스턴스가 있는가? 릴리스와 드라이버별 이동 지원 조건을 별도로 확인했는가?
- Root/ephemeral 디스크는 로컬인가, Ceph RBD·NFS 같은 공유 스토리지인가?
- Boot-from-volume과 별개로 로컬 ephemeral 디스크에 중요한 데이터가 있는가?
- 목적지에서 스토리지, provider network, tunnel network에 접근할 수 있는가?
- 대상 노드가 DHCP·L3 agent, Cinder volume service, Ceph OSD 등 다른 역할을 겸하고 있지 않은가?
- 애플리케이션 백업, 유지보수 시간, 중단 허용 범위를 확보했는가?
GPU·PCI Passthrough가 있다고 일괄적으로 이동 불가라고 단정할 수는 없다. 다만 일반 VM과 같은 방식으로 이동된다고 가정하지 말고, 해당 환경에서 검증된 절차가 없다면 작업을 중단하고 별도 계획을 세운다.
상태와 설정 백업
# 관리자 CLI 단말: 작업 기록용. 민감 정보가 포함될 수 있다.
umask 077
RECORD_DIR="$HOME/compute-removal-$(date +%Y%m%d-%H%M%S)"
mkdir -p "$RECORD_DIR"
openstack compute service list --host "$HOST" -f json > "$RECORD_DIR/compute-services.json"
openstack server list --all-projects --host "$HOST" --long -f json > "$RECORD_DIR/servers.json"
openstack network agent list --host "$HOST" -f json > "$RECORD_DIR/network-agents.json"
# Kolla 배포 서버에서 별도로 실행
cp -a "$INVENTORY" "${INVENTORY}.bak.$(date +%Y%m%d-%H%M%S)"CLI 목록 저장은 VM 데이터 백업을 대신하지 않는다. Kolla 설정·host_vars·group_vars도 조직의 백업 절차에 따라 보관한다. 서로 다른 단말에서 명령을 실행한다면 앞의 변수를 각 단말에서 다시 설정해야 한다.
2단계: 신규 스케줄링 차단
openstack compute service set --disable "$HOST" nova-compute
openstack compute service list --host "$HOST" --service nova-computeStatus가 disabled인지 확인한다. 이 작업만으로 기존 인스턴스가 다른 노드로 이동하지는 않는다.3단계: 상태에 맞게 인스턴스 이동
상황 | 선택할 작업 | 핵심 주의사항 |
원본 노드 정상, live migration 조건 충족 | Live migration | 목적지 용량·CPU·네트워크·스토리지 호환 확인 |
원본 노드 정상, 중단 허용 | Cold migration | VERIFY_RESIZE 확인 후 confirm 또는 revert |
원본 노드 장애, VM이 실행되지 않음을 보장 | Evacuation | 원본 노드 fencing 필수, 스토리지별 데이터 보존 판단 |
원본 로컬 디스크 이미 삭제 | 백업 복구 또는 재구축 계획 | Evacuation으로 삭제한 로컬 데이터를 복구할 수 없음 |
A. 정상 노드: Live migration
먼저 VM 한 대로 검증한다. 목적지를 생략하면 scheduler가 선택한다.
SERVER_ID='<instance-uuid>'
openstack server migrate --live-migration --wait "$SERVER_ID"
# 목적지를 직접 지정할 경우: Compute API 2.30 이상 필요
TARGET_HOST='<target-nova-host>'
openstack --os-compute-api-version 2.30 server migrate \
--live-migration --host "$TARGET_HOST" --wait "$SERVER_ID"두 migration 명령은 선택지다. 같은 VM에 연속으로 실행하지 않는다. 공유 스토리지와 로컬 디스크의 이동 방식은 다르며, 로컬 디스크의 block live migration은 디스크 복사량만큼 대역폭·시간·목적지 공간이 필요하다. 옵션을 무작정 추가하기보다 현재 microversion과 backend의 동작을 먼저 확인한다.
openstack server show "$SERVER_ID" \
-c id -c status -c OS-EXT-SRV-ATTR:host -c OS-EXT-STS:task_state
openstack server migration list --server "$SERVER_ID"Host가 목적지로 바뀌고 task state가 정리되었는지 확인한 뒤 게스트 접속, 볼륨 I/O, 네트워크, 애플리케이션까지 검증한다.
--wait가 반환되었다는 사실만으로 서비스 정상 여부를 판단하지 않는다. Live migration에는 별도 confirm이 필요 없다.다수 VM은 위 검증을 반복하며 제한된 수로 이동한다. 전체 목록을 순회해 요청만 일괄 전송하는 방식은 실패·미완료를 놓치기 쉬우므로 이 글에서는 자동 삭제와 연결하지 않는다.
B. 정상 노드: Cold migration
다운타임을 허용할 수 있고 해당 VM의 cold migration을 환경에서 지원한다면 다음 경로를 사용할 수 있다.
openstack server migrate --wait "$SERVER_ID"
openstack server show "$SERVER_ID"
# VERIFY_RESIZE 상태에서 목적지의 VM·애플리케이션을 확인한 뒤 실행
openstack server migration confirm "$SERVER_ID"
# 확인 중 문제가 발견되었을 때는 confirm 대신 revert
# openstack server migration revert "$SERVER_ID"Cold migration은 같은 flavor를 사용하는 resize 방식으로 처리된다. confirm 전에는 원본 자원 정리가 끝나지 않을 수 있다. Confirm과 revert는 서로 다른 선택지이며, confirm 이후에는 단순 revert로 되돌릴 수 없다. 목적지를 지정하는 cold migration은 Compute API
2.56 이상 등 추가 조건을 확인해야 한다.C. 장애·초기화된 노드: Evacuation
Evacuation 전에 원본 VM이 절대 실행되지 않도록 fencing한다.
서비스의
down 표시만 믿지 말고 전원 차단 등으로 원본 VM의 재실행을 방지한다. 공유 디스크를 사용하는 VM이 두 노드에서 동시에 실행되면 데이터가 손상될 수 있다. --disable은 fencing이 아니다.Evacuation은 장애 노드의 VM을 다른 노드에서 재생성하는 작업이다. 원본 nova-compute 서비스가 down인 상태에서 관리자 권한으로 수행한다.
디스크 구성 | Evacuation 시 판단 |
접근 가능한 공유 root 디스크 | 재사용 가능 여부와 backend 상태 확인 |
Boot-from-volume | Cinder root volume 재사용 및 attachment 상태 확인 |
비공유 로컬 root 디스크 | 원본 Glance image로 재생성되므로 기존 root 변경분은 보존되지 않음 |
로컬 ephemeral 디스크 | 장애·초기화로 데이터가 유실될 수 있으므로 별도 백업 필요 |
공유 스토리지나 Cinder를 사용하더라도 backend 자체가 정상이고 목적지에서 접근 가능해야 한다. 로컬 디스크 데이터가 필요하고 원본 장비에 아직 남아 있다면 추가 초기화를 멈추고 데이터 복구 가능성부터 확인한다.
openstack compute service list --host "$HOST" --service nova-compute
# 원본 노드 fencing과 down 상태 확인 후, VM별로 실행
SERVER_ID='<instance-uuid>'
openstack server evacuate --wait "$SERVER_ID"
openstack server show "$SERVER_ID" \
-c id -c status -c OS-EXT-SRV-ATTR:host -c OS-EXT-STS:task_stateCompute API
2.14 이상에서는 공유 스토리지 여부를 자동 판별하므로 예전 예제의 --shared-storage 옵션을 그대로 붙이지 않는다. API 버전에 따라 evacuation 후 VM의 전원 상태도 달라질 수 있으니 ACTIVE를 무조건 기대하지 말고 실제 상태를 확인해 필요한 전원 조작과 서비스 검증을 수행한다.4단계: 원본 노드에 남은 작업이 없는지 확인
openstack server list --all-projects --host "$HOST" --long
openstack server migration list --host "$HOST"- 원본 노드에 남아 있는 인스턴스가 없어야 한다. 정지된 VM,
ERRORVM도 검토한다.
- 진행 중인 migration과 미확정 cold migration을 정리한다. 완료된 migration 이력이 남는 것은 정상이다.
- 목적지 VM의 접속·서비스·볼륨 I/O를 확인한다.
- DHCP·L3 agent 등 겸용 역할이 있다면 네트워크·라우터를 다른 agent로 이관하고 검증한다.
원본 노드의 VM이 없다는 사실만으로 Placement allocation도 없다고 단정해서는 안 된다. 특히 evacuation 후에는 원본 allocation이 남아 서비스 삭제를 막을 수 있다.
5단계: 대상 노드 서비스 중지 및 inventory 정리
Kolla Ansible 환경
Kolla 배포 서버에서, 대상이 inventory에 아직 존재하는 상태로 실행한다.
# 실제 inventory와 대상 host로 수정
INVENTORY='/path/to/multinode'
INVENTORY_HOST='dms-compute4'
# limit이 의도한 노드 하나에만 매칭되는지 먼저 확인
ansible -i "$INVENTORY" "$INVENTORY_HOST" --list-hosts
kolla-ansible stop -i "$INVENTORY" \
--yes-i-really-really-mean-it \
--limit "$INVENTORY_HOST"--limit을 생략하면 inventory의 다른 노드까지 중지될 수 있다.명령의 limit은 Nova의 Host가 아니라 Ansible inventory의 host 이름·패턴에 적용된다. 대상 개수가 의도와 다르면 중지 명령을 실행하지 않는다. 겸용 노드라면 해당 노드의 다른 서비스도 중지된다는 점에 주의한다.
중지가 끝나면 inventory의 해당 host와 관련 그룹·host_vars 참조를 정리한다. 같은 장비를 다른 역할로 계속 사용할 예정이라면 host 전체를 지우지 말고 유지할 역할을 기준으로 배포 구성을 별도로 검토한다. 향후 deploy로 제거한 compute가 재배포되지 않도록 설정도 확인한다.
대상 서버가 이미 초기화되어 접근할 수 없다면 Kolla stop은 성공할 수 없다. 이 경우 재기동·재접속으로 원본 VM이나 서비스가 되살아나지 않도록 격리한 뒤 inventory와 등록 정보를 정리한다.
패키지 설치 환경
Kolla 명령 대신 대상 compute 노드에서 실제 서비스 unit을 확인해 중지·비활성화한다. Ubuntu 패키지 설치 환경의 예시는 다음과 같다.
sudo systemctl disable --now nova-computeNeutron agent 등은 실제 backend와 겸용 역할에 맞게 처리한다. 인스턴스 이동 전에 libvirt나 네트워크 서비스를 무작정 중지하지 않는다.
6단계: Neutron agent와 Nova 서비스 등록 삭제
서비스가 다시 등록되지 않도록 대상 프로세스를 중지하거나 장비를 격리한 뒤 진행한다. 아래 명령은 등록 정보를 삭제하는 작업이므로, 먼저 목록을 확인하고 ID를 한 개씩 지정한다.
Neutron agent
openstack network agent list --host "$HOST"
# 종류·Host·겸용 역할과 이관 완료 여부를 확인한 ID만 삭제
AGENT_ID='<confirmed-agent-uuid>'
openstack network agent delete "$AGENT_ID"OVS·Linux Bridge agent와 달리 OVN 환경에서는 chassis 등 별도 정리가 필요할 수 있다. OVN의 표시 항목이 일반 Neutron agent와 동일하게 삭제된다고 가정하지 말고, 해당 릴리스의 OVN 운영 절차를 따른다. 공유 network·router·port 자체를 일괄 삭제하는 작업은 아니다.
Nova compute service
openstack --os-compute-api-version 2.53 compute service list \
--host "$HOST" --service nova-compute
SERVICE_ID='<confirmed-nova-compute-service-uuid>'
openstack --os-compute-api-version 2.53 compute service delete "$SERVICE_ID"2.53은 서비스 ID를 UUID로 다루기 위한 예시다. 실제 환경에서 지원하는 microversion과 출력 ID 형식을 확인한다. 이 단계에서 충돌이 발생하면 DB 행을 직접 지우지 말고 인스턴스, migration, Placement allocation부터 점검한다.7단계: Placement 잔여 allocation 점검
일반적인 서비스 삭제가 정상적으로 끝났다면 관련 resource provider 정리가 반영되었는지 확인한다. Resource provider 수동 삭제를 모든 노드 제거의 필수 단계로 실행하지 않는다.
아래 명령은
osc-placement 플러그인이 필요하다. Resource provider 이름은 Nova Host와 다를 수 있고, GPU·PCI·네트워크 자원은 child provider를 포함할 수 있으므로 실제 목록과 provider tree를 기준으로 확인한다.openstack resource provider list
RP_UUID='<confirmed-source-resource-provider-uuid>'
openstack resource provider show --allocations "$RP_UUID"Evacuation 후 원본 allocation이 남은 경우
원본과 목적지의 allocation을 구분해야 정상 VM이 사용하는 자원을 실수로 삭제하지 않는다.
SERVER_ID='<evacuated-instance-uuid>'
openstack server show "$SERVER_ID" -c OS-EXT-SRV-ATTR:host
openstack --os-placement-api-version 1.12 \
resource provider allocation show "$SERVER_ID"목적지에서 VM이 정상이고 진행 중인 migration이 없으며, 원본 provider의 할당만 잔여 정보임을 확인한 경우에만 아래처럼 원본 provider에 대한 allocation만 제거한다. 먼저 allocation 출력을 작업 기록으로 보관한다.
# osc-placement 1.8.0 이상에서 지원
openstack --os-placement-api-version 1.12 \
resource provider allocation unset \
--provider "$RP_UUID" "$SERVER_ID"
# 목적지 allocation이 보존되었는지 재확인
openstack --os-placement-api-version 1.12 \
resource provider allocation show "$SERVER_ID"resource provider allocation delete <server>를 무심코 사용하지 않는다.이 명령은 목적지에서 사용 중인 allocation까지 모두 제거할 수 있다.
heal_allocations도 vGPU 등 모든 nested resource 구성을 복구하는 만능 도구는 아니다. 원본 provider와 child provider의 실제 사용 여부를 확인하지 못했다면 수동 정리를 중단한다.Allocation과 child provider 등 삭제 제약이 모두 해소되었는데도 source provider가 남은 경우에만 수동 삭제를 검토하고, 실패했던 compute service 삭제를 재시도한다.
# 잔여 provider임을 확인한 경우에만 실행
openstack resource provider delete "$RP_UUID"8단계: 최종 검증과 롤백 지점
openstack compute service list --host "$HOST"
openstack network agent list --host "$HOST"
openstack server list --all-projects --host "$HOST" --long
openstack hypervisor list
openstack resource provider list제거 대상의 인스턴스·compute service와 해당 backend에서 정리해야 할 agent·provider가 남지 않았는지 확인한다. 추가로 남은 노드에서 테스트 VM 생성, 네트워크 통신, 볼륨 attach·I/O, 실제 애플리케이션 상태를 점검한다.
작업 지점 | 되돌릴 때의 기준 |
Disable만 수행 | 원본 노드 정상 확인 후 openstack compute service set --enable "$HOST" nova-compute |
Cold migration confirm 전 | VM 상태 확인 후 server migration revert 검토 |
Live migration 완료 또는 cold confirm 후 | 원본이 정상이라면 별도 역방향 migration 계획 필요 |
Kolla stop 후, 등록 삭제 전 | 백업 inventory·설정을 기준으로 대상 한정 재배포 및 검증 필요 |
서비스·provider 삭제 또는 디스크 초기화 후 | 단순 enable로 복구 불가. 재등록·재배포·데이터 복구 절차 필요 |
장애 노드를 fencing한 경우에는 위 표의 일반적인 재배포 경로를 그대로 적용하지 않는다. 기존 VM의 중복 실행 위험과 데이터 정합성을 먼저 해소해야 한다.
트러블슈팅: 어디부터 확인할까?
증상 | 우선 확인할 항목 | 대응 방향 |
초기화한 노드에 VM 정보가 남음 | 실제 VM 생존 여부, root/ephemeral 위치, 백업 | fencing 후 evacuation 또는 백업 복구. 서비스 삭제부터 하지 않음 |
Migration 실패·No valid host | 용량, CPU, NUMA, aggregate/AZ, PCI 제약 | 목적지 조건 및 scheduler 로그 확인 |
Migration 요청 후 원본 자원이 남음 | task state, migration 상태, VERIFY_RESIZE | 작업 완료·confirm 여부 확인 |
Compute service 삭제 시 충돌 | 잔여 VM, 진행 중 migration, source allocation | 원인 정리 후 삭제 재시도. DB 직접 수정 금지 |
삭제한 서비스·agent가 다시 나타남 | 프로세스·컨테이너 실행 여부, inventory 재배포 | 원본 실행 차단과 inventory 정리 |
Evacuation 후 네트워크·볼륨 오류 | port binding, Cinder attachment, backend 접근 | Nova·Neutron·Cinder 및 스토리지 로그를 함께 점검 |
Kolla 배포에서는 일반적으로
/var/log/kolla/ 아래 로그를 먼저 확인한다. 컨테이너 이름·런타임·경로는 배포 설정에 따라 다르다.# 해당 서비스가 실행되는 노드에서: Kolla 로그 예시
sudo tail -n 200 /var/log/kolla/nova/nova-compute.log
sudo tail -n 200 /var/log/kolla/nova/nova-scheduler.log
sudo tail -n 200 /var/log/kolla/nova/nova-conductor.log
# 패키지 설치 환경: compute 노드의 예시
sudo journalctl -u nova-compute --since '30 minutes ago'Migration·evacuation 실패 시에는 instance UUID와 request ID를 기준으로 source/destination compute, scheduler, conductor 로그를 연결해서 본다.
NoValidHost, MigrationError, Allocation, PortBindingFailed 같은 키워드는 출발점이며, 마지막 오류 메시지 하나만으로 원인을 단정하지 않는다.핵심 정리
- Disable은 신규 배치 차단이지 VM 이동이나 fencing이 아니다.
- 정상 노드는 migration, 장애 노드는 fencing 후 evacuation으로 구분한다.
- 로컬 디스크 초기화 후에는 evacuation으로 기존 데이터를 복구할 수 없다.
- 이동·서비스 검증을 끝내고,
--limit으로 대상 노드만 중지한다.
- 등록 정보 삭제는 마지막에 수행하고, Placement 잔여 할당은 필요할 때만 정밀하게 정리한다.
재발 방지 체크리스트
실제 Nova Host와 Ansible inventory host를 확인했다.
겸용 역할과 남은 클러스터 용량을 검토했다.
신규 스케줄링을 차단하고 VM 데이터 백업을 확보했다.
VM별 디스크 위치와 migration 지원 조건을 확인했다.
장애 경로에서는 원본 VM의 재실행을 방지했다.
이동 완료·cold migration confirm·서비스 정상 동작을 검증했다.
Kolla stop의
--limit 대상이 정확히 일치했다.Inventory와 관련 설정에서 제거 대상을 정리했다.
필요한 agent·compute service와 잔여 allocation을 정리했다.
남은 노드에서 생성·네트워크·볼륨 테스트를 마쳤다.
최종 승인 이후에만 장비 초기화·회수를 진행한다.
참고 자료
공식 문서
- Kolla Ansible — Adding and removing hosts: 컴퓨트 노드 제거의 기본 순서, 대상 제한 중지, 서비스 정리
- OpenStackClient — Server commands: migration·evacuation 명령과 microversion 조건
- Nova — Configure live migrations: 공유 스토리지·block migration 및 사전 요구사항
- Nova — Evacuate instances: 장애 노드 evacuation과 데이터 보존 조건
- Nova — Orphaned resource allocations: evacuation 이후 잔여 allocation 및 안전한 provider별 정리