1. 장애 증상
OpenStack Horizon 웹 접속 시 다음과 같은 오류 화면이 발생했다.
프로젝트 > Compute > 인스턴스 접속 시 아래 에러 발생
처음에는 Horizon 자체 장애처럼 보였지만, 컨테이너 상태를 확인해보니 Horizon 컨테이너는 정상 상태였다.
확인 결과:
즉, Horizon 프로세스 자체가 죽은 것은 아니었다.
2. 최초 컨테이너 상태 확인
전체 OpenStack 컨테이너 상태를 확인했다.
이때 주요 장애 컨테이너는 다음과 같았다.
nova_scheduler Exited (1)
nova_api Up ... unhealthy
nova_metadata Up ... unhealthy
placement_api Up ... unhealthy
cinder_api Up ... unhealthy
반면 Keystone, MariaDB, RabbitMQ, Memcached, HAProxy 등은 대체로 healthy 상태였다.
초기 상태에서는 Horizon은 healthy였지만 Nova, Placement, Cinder API가 unhealthy 또는 exited 상태였기 때문에 Horizon이 내부 API 호출 중 오류를 표시한 것으로 판단했다.
3. 장애 분석 순서
OpenStack 웹 오류가 발생했을 때는 Horizon만 보지 말고 다음 순서로 확인하는 것이 좋다.
3.1 컨테이너 상태 확인
문제 컨테이너만 필터링하려면:
또는 이번처럼 주요 서비스만 확인한다.
3.2 OpenStack CLI 인증 확인
source /etc/kolla/admin-openrc.sh
openstack token issue
토큰 발급이 정상이라면 Keystone 인증 자체는 동작하고 있는 것이다.
3.3 주요 서비스 상태 확인
openstack volume service list
openstack network agent list
openstack endpoint list
이번 장애에서는 openstack token issue는 정상 동작했지만, openstack volume service list 실행 시 다음 오류가 발생했다.
503 Service Unavailable: No server is available to handle this request.
이 메시지는 CLI가 HAProxy까지는 접근했지만, 뒤쪽의 Cinder API 백엔드가 정상 서비스 상태가 아니라는 의미로 볼 수 있다.
4. 핵심 로그 분석
4.1 Nova conductor / scheduler 로그
Nova 쪽에서는 다음 에러가 반복되었다.
The placement service for 192.168.111.130:RegionOne exists but does not have any supported versions.
nova_conductor, nova_scheduler 모두 Placement API를 정상적으로 조회하지 못하면서 종료되었다.
처음에는 Placement 버전 discovery 문제처럼 보이지만, 실제 원인은 그 앞단에 있었다.
4.2 Placement API 로그
Placement API 로그에서는 다음 에러가 확인되었다.
(9001, 'Max connect timeout reached while reaching hostgroup 0 after 12019ms')
즉, Placement API가 DB에 연결하지 못하고 있었다.
Kolla-Ansible 구조에서는 OpenStack 서비스들이 일반적으로 MariaDB에 직접 붙지 않고, ProxySQL을 통해 DB에 연결한다.
따라서 이 에러는 다음 흐름으로 해석할 수 있다.
4.3 Nova API 로그
Nova API에서도 동일한 DB 연결 문제가 확인되었다.
(pymysql.err.OperationalError)
(9001, 'Max connect timeout reached while reaching hostgroup 0 after 10254ms')
즉 Nova API도 DB 연결 실패로 정상 초기화되지 못했다.
4.4 Cinder API 로그
Cinder API 역시 동일한 유형의 DB 연결 에러가 발생했다.
(pymysql.err.OperationalError)
(9001, 'Max connect timeout reached while reaching hostgroup 0 after 12639ms')
Cinder API는 uWSGI 프로세스 자체는 올라왔지만, 내부 Cinder WSGI 애플리케이션 초기화 과정에서 DB 연결에 실패했다. 이 때문에 컨테이너는 Up 상태로 보였지만 health check는 unhealthy가 되었다.
5. 실제 장애 원인 정리
이번 장애는 단일 서비스 장애라기보다 DB 연결 문제로 인한 연쇄 장애였다.
장애 흐름은 다음과 같다.
↓
Placement API DB 연결 실패
↓
Placement API unhealthy
↓
Nova conductor / scheduler가 Placement API discovery 실패
↓
nova_conductor, nova_scheduler Exited
↓
nova_api, nova_metadata unhealthy
↓
Horizon에서 내부 API 호출 실패
↓
웹 화면 오류 발생
Cinder도 별도로 같은 DB 연결 문제를 겪었다.
↓
cinder_api unhealthy
↓
HAProxy에서 Cinder API 백엔드 사용 불가 판단
↓
openstack volume service list 실행 시 503 발생
따라서 Horizon 오류의 직접 원인은 Horizon 자체가 아니라 Nova / Placement / Cinder API 서비스 비정상이었다.
6. 문제 해결 순서
이번 장애에서는 무작정 모든 컨테이너를 재시작하는 것보다, 의존성 순서대로 재시작하는 것이 중요했다.
OpenStack API 서비스들의 주요 의존성은 대략 다음과 같다.
RabbitMQ
Keystone
Placement
Nova
Cinder
HAProxy
Horizon
이번에는 DB/ProxySQL 연결 문제가 핵심이었기 때문에 다음 순서로 조치하는 것이 효과적이었다.
7. 권장 재시작 순서
7.1 DB / ProxySQL 먼저 재시작
sleep 40
docker restart proxysql
sleep 30
MariaDB가 완전히 올라오기 전에 API 서비스를 먼저 올리면 동일한 DB timeout 문제가 재발할 수 있기 때문에 sleep을 두는 것이 좋다.
7.2 Placement API 재시작
sleep 30
상태 확인:
정상 기준:
mariadb Up ... healthy
proxysql Up ... healthy
7.3 Nova API / Metadata 재시작
sleep 30
상태 확인:
정상 기준:
nova_metadata Up ... healthy
placement_api Up ... healthy
7.4 Nova conductor / scheduler 재시작
sleep 30
상태 확인:
이번 조치 후 최종적으로 다음처럼 정상화되었다.
nova_api Up ... healthy
nova_scheduler Up ... healthy
placement_api Up ... healthy
실제로 nova_conductor, nova_api, nova_scheduler, placement_api가 모두 healthy 상태로 전환되었다.
7.5 Cinder API 재시작
Nova/Placement가 정상화된 후에도 Cinder API는 unhealthy 상태였다.
Cinder 로그에서도 DB 연결 실패 기록이 남아 있었다.
따라서 Cinder API를 별도로 재시작했다.
sleep 30
상태 확인:
이후 다시 Cinder 서비스 조회:
7.6 HAProxy 재시작이 필요한 경우
Cinder API가 healthy로 올라왔는데도 CLI에서 계속 503이 발생하면 HAProxy가 아직 백엔드를 정상으로 인식하지 못하고 있을 수 있다.
이 경우 HAProxy를 재시작한다.
sleep 10
openstack volume service list
8. 최종 점검 명령어
8.1 컨테이너 unhealthy / exited 확인
아무것도 출력되지 않으면 컨테이너 관점에서는 정상에 가깝다.
8.2 Nova 서비스 확인
openstack compute service list
openstack hypervisor list
정상 기준:
nova-conductor enabled up
nova-compute enabled up
8.3 Cinder 서비스 확인
정상 기준:
cinder-volume enabled up
cinder-backup enabled up 또는 down
cinder-backup은 백업 백엔드 구성이 없거나 별도 설정이 부족하면 down일 수 있다.
하지만 cinder-api가 정상이라면 openstack volume service list 명령 자체는 503 없이 출력되어야 한다.
8.4 Network 서비스 확인
정상 기준:
DHCP agent alive
L3 agent alive
Metadata agent alive
8.5 Horizon 재시작
백엔드 서비스가 모두 정상화되었는데도 Horizon 화면 오류가 남아 있으면 Horizon 세션 또는 캐시 문제일 수 있다.
브라우저 캐시를 비우거나 시크릿 창에서 다시 접속하는 것도 도움이 된다.
9. 로그 확인 명령어 정리
전체 문제 컨테이너 로그에서 에러만 보기
echo ""
echo "==================== $c ===================="
docker logs "$c" --tail 500 2>&1 | egrep -i "error|critical|traceback|exception|failed|denied|refused|unhealthy|fatal|cell|placement|database|mysql|rabbit|amqp" | tail -n 100
done
Nova 로그 확인
tail -n 120 /var/log/kolla/nova/nova-scheduler.log
tail -n 120 /var/log/kolla/nova/nova-api.log
에러만 보기:
egrep -i "error|critical|traceback|exception|failed|placement|database|mysql|rabbit|amqp" /var/log/kolla/nova/nova-scheduler.log | tail -n 80
Placement 로그 확인
에러만 보기:
Cinder 로그 확인
에러만 보기:
MariaDB / ProxySQL 로그 확인
tail -n 150 /var/log/kolla/proxysql/proxysql.log
에러만 보기:
egrep -i "error|failed|timeout|connect|mysql|hostgroup|offline|shun|denied|monitor" /var/log/kolla/proxysql/proxysql.log | tail -n 120
10. 이번 장애에서 배운 점
이번 장애에서 가장 중요한 포인트는 healthy / unhealthy만 보고 단순히 해당 컨테이너만 재시작하면 안 된다는 점이다.
예를 들어 nova_conductor와 nova_scheduler가 죽어 있었지만, 실제 원인은 Nova 자체가 아니라 Placement API discovery 실패였다.
또 Placement API의 discovery 실패 원인은 다시 DB 연결 실패였다.
따라서 실제 분석 순서는 아래처럼 가야 한다.
2. Horizon 컨테이너 상태 확인
3. Horizon이 healthy면 백엔드 API 확인
4. Nova / Placement / Cinder 상태 확인
5. 죽은 컨테이너의 로그 확인
6. 로그에서 DB / RabbitMQ / Keystone / Placement 의존성 확인
7. 가장 앞단 의존 서비스부터 재시작
8. API 서비스 재시작
9. HAProxy 재시작
10. OpenStack CLI로 최종 검증
11. 최종 조치 요약
이번 장애의 실질적인 복구 흐름은 다음과 같다.
docker restart mariadb
sleep 40
docker restart proxysql
sleep 30
# 2. Placement 재시작
docker restart placement_api
sleep 30
# 3. Nova API 재시작
docker restart nova_api nova_metadata
sleep 30
# 4. Nova conductor / scheduler 재시작
docker restart nova_conductor nova_scheduler
sleep 30
# 5. Cinder API 재시작
docker restart cinder_api
sleep 30
# 6. 필요 시 HAProxy 재시작
docker restart haproxy
sleep 10
# 7. 필요 시 Horizon 재시작
docker restart horizon
최종 확인:
openstack compute service list
openstack hypervisor list
openstack volume service list
openstack network agent list
docker ps -a --format "table {{.Names}}\t{{.Status}}" | egrep -i "unhealthy|exited|dead|restarting"
12. 결론
이번 문제는 Horizon 자체 장애가 아니라, MariaDB/ProxySQL 연결 지연 또는 초기화 타이밍 문제로 인해 Placement, Nova, Cinder API가 순차적으로 비정상화된 장애였다.
핵심 로그는 다음 두 가지였다.
첫 번째는 DB 연결 문제이고, 두 번째는 그 결과로 Placement API가 정상 discovery되지 못해 Nova 서비스가 죽은 것이다.
따라서 이런 유형의 장애에서는 Horizon만 재시작하지 말고, 반드시 다음 순서로 확인해야 한다.
→ Placement
→ Nova API
→ Nova conductor / scheduler
→ Cinder API
→ HAProxy
→ Horizon
이 순서를 지키면 원인 파악과 복구 시간을 크게 줄일 수 있다.
'시스템 엔지니어 일상 > OPENSTACK' 카테고리의 다른 글
| OpenStack Kolla 환경에서 Horizon Compute 정보 조회 실패 및 Nova/Placement 장애 분석 (0) | 2026.04.29 |
|---|---|
| OpenStack(Kolla-Ansible) 점검 체크리스트 정리 (0) | 2026.04.28 |