Proxmox VE 클러스터 운영 중 Web UI가 전면 차단되는 장애는 관리 플랫폼癱瘓을 의미하며, 특히 다중 노드 환경에서 빠른 원인 규명이 필수적이다. 본 문서는 실제 운영 환경에서 발생한 pvedaemon 비정상 상태로 인한 Web UI 단절 사건을 바탕으로, 진단부터 복구까지의 체계적인 접근 방식을 다룬다.

증상 개요 및 영향 범위 식별

장애 발생 시점의 핵심 증상은 다음과 같다.

• 모든 노드의 https://<노드_IP>:8006 접속 불가 (Connection refused/Timeout)
• SSH 접속 및 가상 머신·컨테이너 실행 상태는 정상
• 비즈니스 트래픽에는 영향 없음

이러한 패턴은 데이터 플레인과 제어 플레인의 분리를 명확히 보여주며, pveproxy → pvedaemon → pvestatd로 이어지는 관리 서비스 체인 내 문제임을 시사한다.

1단계: 네트워크 계층 및 포트 바인딩 확인

외부 클라이언트에서 TCP 연결 가능성을 먼저 검증한다.

# 외부 클라이언트에서 실행
$ nmap -p 8006 192.168.50.10
# 또는
$ timeout 3 bash -c "echo > /dev/tcp/192.168.50.10/8006" && echo "Open" || echo "Closed"

연결 실패 시 노드 내부에서 리스닝 상태를 점검한다.

# IPv4/IPv6 동시 확인
$ ss -tlnp 'sport = :8006'

# 예상 정상 출력
LISTEN 0 4096 0.0.0.0:8006    users:(("pveproxy",pid=1234,fd=3))
LISTEN 0 4096 [::]:8006       users:(("pveproxy",pid=1234,fd=4))

주의: /etc/hosts 내 hostname 해석이 127.0.1.1로 잘못 설정된 경우, pveproxy가 루프백 주소에만 바인딩될 수 있다. 각 노드의 관리 네트워크 IP가 정확히 매핑되어 있는지 확인해야 한다.

2단계: 서비스 의존성 및 프로세스 상태 점검

Proxmox 관리 서비스는 계층적 의존 관계를 가진다. 단일 서비스 재시작보다 전체 의존성을 파악하는 것이 중요하다.

# 서비스 상태 일괄 확인
$ for svc in pveproxy pvedaemon pvestatd pve-cluster corosync; do
    echo "=== $svc ==="
    systemctl is-active $svc
    systemctl is-failed $svc
done

# 프로세스 상세 정보
$ ps aux | grep -E 'pve(proxy|daemon|statd)|corosync'

이번 사례에서는 pveproxy는 active (running) 상태였으나, pvedaemon이 failed 상태로 전환되어 API 요청을 처리하지 못하고 있었다. pveproxy는 HTTP 리버스 프록시 역할만 수행하므로, 실제 API 로직은 pvedaemon에 의존한다.

3단계: 로그 기반 근본 원인 분석

관련 로그를 시간 순서대로 분석한다.

# pvedaemon 로그 (Journal 기반)
$ journalctl -u pvedaemon --since "2024-01-15 02:00" --until "2024-01-15 04:00" -o short-iso

# pveproxy 에러 로그
$ journalctl -u pveproxy --since "2024-01-15 02:00" -n 100

# 클러스터 통신 로그
$ journalctl -u pve-cluster --since "2024-01-15 02:00"

로그 분석 결과, pvedaemon 프로세스가 다음과 같은 예외를 반복 발생시키며 크래시되고 있었다.

Jan 15 02:34:12 pve-node01 pvedaemon[4567]: unable to create inbox '/var/run/pveproxy/pvedaemon.inbox.1234' - File exists
Jan 15 02:34:12 pve-node01 pvedaemon[4567]: IPC socket cleanup failed, retrying...
Jan 15 02:34:15 pve-node01 systemd[1]: pvedaemon.service: Main process exited, code=killed, status=9/KILL

원인은 이전 비정상 종료 시 Unix domain socket 파일(*.inbox.*)이 잔여로 남아있어, 후속 프로세스가 소켓 생성에 실패한 것이다. 이는 노드 간 클러스터 통신 타임아웃으로 인한 pvedaemon 비정상 종료 후 발생한 것으로, Corosync 일시적 불안정이 트리거가 되었다.

4단계: 정밀 복구 절차

4.1 잔여 소켓 파일 정리

# pveproxy 실행 디렉터리 내 여 파일 확인
$ ls -la /var/run/pveproxy/

# 안전하게 잔류 소켓 제거 (서비스 중지 상태에서)
$ systemctl stop pveproxy pvedaemon
$ rm -f /var/run/pveproxy/*.inbox.* /var/run/pveproxy/pvedaemon.*

4.2 서비스 순차 재시작

의존성을 고려하여 하위 서비스부터 순차적으로 기동한다.

# 하위 서비스부터 순차 기동
$ systemctl start pvestatd
$ systemctl start pvedaemon
$ systemctl start pveproxy

# 최종 상태 검증
$ systemctl status pveproxy pvedaemon pvestatd --no-pager

4.3 클러스터 동기화 확인

# 클러스터 멤버십 상태
$ pvecm status

# 모든 노드의 온라인 상태
$ pvecm nodes

# 저장소 접근성 확인
$ pvesm status

5단계: 재발 방지를 위한 모니터링 강화

동일 장애의 조기 감지를 위해 다음 메트릭을 모니터링 대상으로 추가하였다.

추가 고려사항: 다중 노드 동시 장애 시

이번 사례는 단일 노드에서 시작되었으나, 클러스터 상태 불일치로 인해 전파될 수 있다. 다음 원칙을 준수해야 한다.

• 쿼럼 유지 우선: 3노드 클러스터에서 2노드 이상 정상 시에만 리소스 조작 수행
• 순차 복구: 모든 노드를 동시에 재시작하지 않고, 한 노드씩 복구 후 클러스터 동기화 확인
• fence 장치 활용: STONITH 구성으로 스플릿 브레인 예방

이번 장애를 통해 확인한 핵심은 pveproxy의 정상 실행 상태가 Web UI 가용성을 보장하지 않으며, 실제 API 처리를 담당하는 pvedaemon의 건강도가 필수적이라는 점이다. 서비스 간 계층적 의존 관계를 이해하고, 소켓 기반 IPC 메커니즘의 특성을 고려한 진단이 빠른 복구의 핵심이었다.