시스템 관리_48 VMware ESXi 호스트 vCenter Server 연결 끊김 Not Responding 오류 원인 분석 및 완벽 복구 가이드

 
  • 출처 / 참고: VMware Broadcom Knowledge Base (ESXi host disconnects from vCenter Server with Not Responding status - KB 1003409, Troubleshooting agent (vpxa and hostd) issues on ESXi - KB 1006160)

명령어: /etc/init.d/hostd, /etc/init.d/vpxa, esxcli, nc, vmkping, tail
키워드: ESXi Host Disconnecting, vCenter Server, Not Responding, vpxa, hostd, UDP 902 Heartbeat, Port 443, vpxuser, Ramdisk Full
사용처: vSphere Client에서 특정 ESXi 호스트가 ‘응답 없음(Not Responding)’ 또는 ‘연결 끊김(Disconnected)’ 상태로 빠지는 장애 긴급 진단 및 에이전트 복구


실행예제

vCenter Server 인벤토리에서 특정 ESXi 호스트가 갑자기 응답 없음(Not Responding) 또는 연결 끊김(Disconnected) 상태로 전환되었을 때, ESXi 호스트 콘솔(SSH)에서 관리 에이전트 데몬 상태, 램디스크 용량 고갈, 그리고 vCenter 간 포트 통신 상태를 진단합니다.

# 1. ESXi 호스트 관점: 핵심 관리 에이전트(hostd, vpxa) 실행 상태 확인
$ /etc/init.d/hostd status
# hostd is running.
$ /etc/init.d/vpxa status
# vpxa is running.
# -> 데몬이 죽어있거나(dead) 락에 걸려 응답하지 않는 상태인지 확인

# 2. ESXi 램디스크(tmp, var, root) 100% 포화 여부 확인 (에이전트 크래시 주원인)
$ vdf -h
# Filesystem   Size   Used  Available Use% Mounted on
# /dev/vdrz     32M    32M         0B 100% /var/run
# /dev/vdrz    286M   286M         0B 100% /tmp
# -> 램디스크 가용 공간이 0B이면 vpxa/hostd가 PID 및 소켓을 생성하지 못해 즉각 크래시됨

# 3. vpxa 로그에서 vCenter 연결 끊김 및 하트비트 유실 내역 확인
$ tail -n 50 /var/log/vpxa.log | grep -iE "error|failed|disconnect|heartbeat"
# [출력 예시]
# [Originator@6876 sub=Heartbeat] Missed 3 heartbeats from server
# [Originator@6876 sub=Default] Failed to connect to vCenter server 192.168.1.50: Connection timed out
# -> vCenter로 보내는 UDP 902 하트비트 유실 또는 네트워크 단절 확인

# 4. hostd 로그에서 리소스 고갈 및 스레드 행(Hang) 확인
$ tail -n 30 /var/log/hostd.log | grep -iE "warning|error|panic"

# 5. ESXi 호스트에서 vCenter Server로의 필수 통신 포트 도달 가능 여부 테스트
# TCP 443 (vCenter 관리 포트), UDP 902 (하트비트 수신 포트)
$ nc -zv 192.168.1.50 443
# Connection to 192.168.1.50 443 port [tcp/https] succeeded!
$ nc -zvu 192.168.1.50 902
# Connection to 192.168.1.50 902 port [udp] succeeded!

   

스크립트

ESXi 호스트 셸에서 실행되어 hostd 및 vpxa 에이전트의 구동 상태, 램디스크 디렉터리 포화 여부, vCenter IP 설정 확인 및 양방향 네트워크 핑/포트 연결성을 단계별로 자동 검증하고 안전하게 관리 에이전트를 재시작하는 쉘 스크립트입니다.

#!/bin/sh
# diagnose_esxi_vcenter_disconnect.sh - Diagnose ESXi to vCenter disconnection and agent health

VCENTER_IP=${1:-""}

echo "=========================================="
echo " [ESXi 호스트 vCenter 연결 끊김 정밀 진단]"
echo "=========================================="

# 1. vCenter IP 파싱 (인자 미입력 시 vpxa.cfg에서 자동 추출)
VPXA_CFG="/etc/vmware/vpxa/vpxa.cfg"
if [ -z "$VCENTER_IP" ] && [ -f "$VPXA_CFG" ]; then
    VCENTER_IP=$(grep "<serverIp>" "$VPXA_CFG" | sed -e 's/.*<serverIp>//' -e 's/<\/serverIp>.*//' | tr -d ' \t\r\n')
fi

echo "  - 감지된 vCenter IP: ${VCENTER_IP:-"미지정/미감지"}"

# 2. ESXi 램디스크(RAM Disk) 용량 고갈 검사
echo -e "\n[1] 램디스크(RAM Disk) 여유 공간 점검:"
RAMDISK_FULL=0
for MP in /tmp /var/run /var/log; do
    USAGE_PCT=$(df -k "$MP" | tail -n 1 | awk '{print $5}' | tr -d '%')
    AVAIL_KB=$(df -k "$MP" | tail -n 1 | awk '{print $4}')
    printf "  - 마운트 경로 %-10s : 사용률 %3d%% (여유: %s KB)\n" "$MP" "$USAGE_PCT" "$AVAIL_KB"
    if [ "$USAGE_PCT" -ge 100 ]; then
        RAMDISK_FULL=1
    fi
done

if [ "$RAMDISK_FULL" -eq 1 ]; then
    echo "  [치명적 위험] 램디스크가 100% 가득 찼습니다!"
    echo "  -> 관리 에이전트가 정상 작동하지 못하는 핵심 원인입니다. 오래된 로그나 코어 덤프 정리가 필요합니다."
else
    echo "  [정상] 램디스크 공간이 확보되어 있습니다."
fi

# 3. 호스트 관리 에이전트 상태 점검
echo -e "\n[2] ESXi 관리 에이전트(hostd, vpxa) 상태:"
HOSTD_STATUS=$(/etc/init.d/hostd status 2>&1)
VPXA_STATUS=$(/etc/init.d/vpxa status 2>&1)

echo "  - hostd 데몬 : ${HOSTD_STATUS}"
echo "  - vpxa 데몬  : ${VPXA_STATUS}"

# 4. vCenter 네트워크 도달 가능성 검증
if [ -n "$VCENTER_IP" ]; then
    echo -e "\n[3] vCenter 통신 및 포트 연결성 점검:"
    
    # Management VMkernel을 통한 ping 테스트
    if vmkping -c 2 -s 64 "$VCENTER_IP" >/dev/null 2>&1; then
        echo "  - vmkping (ICMP) : [성공] vCenter IP에 정상 도달 가능"
    else
        echo "  - vmkping (ICMP) : [실패] vCenter와 네트워크 단절 감지"
    fi
    
    # TCP 443 포트 확인
    if nc -zv -w 3 "$VCENTER_IP" 443 >/dev/null 2>&1; then
        echo "  - TCP 443 포트   : [열림] HTTPS 제어 세션 연결 성공"
    else
        echo "  - TCP 443 포트   : [차단/실패] 중간 방화벽 또는 vCenter 서비스 확인 필요"
    fi
    
    # UDP 902 포트 확인 (하트비트)
    if nc -zvu -w 3 "$VCENTER_IP" 902 >/dev/null 2>&1; then
        echo "  - UDP 902 포트   : [열림] 하트비트 송신 포트 연결 성공"
    else
        echo "  - UDP 902 포트   : [경고] UDP 902 포트 확인 불가 (하트비트 유실 위험)"
    fi
fi

# 5. 권장 조치 가이드
echo -e "\n[4] 긴급 복구 권장 조치:"
echo "  1) 관리 에이전트 재시작 (가상 머신 운영에 영향 없음):"
echo "     -> /etc/init.d/hostd restart && /etc/init.d/vpxa restart"
echo "  2) vCenter vSphere Client에서 호스트 우클릭 > Connection > Connect 수행"

echo -e "\n=========================================="
echo " [진단 완료]"
echo "=========================================="

   

해설

vSphere 환경에서 ESXi 호스트가 응답 없음(Not Responding) 또는 연결 끊김(Disconnected) 상태로 빠지는 현상은 하이퍼바이저 머신 자체가 죽은 것이 아니라, vCenter Server와 ESXi 호스트 상호 간의 관리 통신 채널(Management Channel)이 끊어졌을 때 발생합니다. 이 상태에서도 ESXi 위에서 구동 중인 가상 머신(VM)들의 서비스는 정상 동작합니다.

1. vCenter-ESXi 관리 통신 구조와 하트비트(Heartbeat)

  1. hostd (Host Daemon):
    • ESXi 내부의 가상 머신 생성, 전원 제어, 스토리지/네트워크 자원을 총괄하는 핵심 호스트 데몬입니다.
  2. vpxa (vCenter Server Management Agent):
    • vCenter Server의 vpxd 프로세스와 통신하기 위해 ESXi에 상주하는 중계 에이전트입니다.
    • vCenter의 지시를 받아 로컬의 hostd로 전달합니다.
  3. UDP 902 하트비트 메커니즘:
    • ESXi 호스트는 매 10초마다 vCenter Server의 UDP 902번 포트로 하트비트 패킷을 발송합니다.
    • vCenter가 특정 호스트로부터 하트비트를 연속으로 수신하지 못하면(기본 60초 초과), vCenter는 해당 호스트를 “응답 없음(Not Responding)” 상태로 전환합니다.

2. 주요 발생 원인

  1. 네트워크 방화벽에 의한 UDP 902 또는 TCP 443 차단:
    • 네트워크 점검이나 방화벽 정책 변경 후, ESXi와 vCenter 간의 UDP 902 패킷이 차단되면 호스트 관리 웹 접속(443)은 되는데 vCenter에서는 주기적으로 호스트가 끊어지는 현상이 발생합니다.
  2. ESXi 램디스크(RAM Disk) 용량 100% 고갈:
    • 서드파티 드라이버(Cisco enic, HPE storcli 등)의 디버그 로그 누적이나 코어 덤프로 인해 ESXi의 메모리 파일시스템(/var/run, /tmp)이 100% 차면 vpxa가 메모리를 할당받지 못해 비정상 크래시됩니다.
  3. hostd 데몬의 스레드 행(Hang) / 디스크 락(Lock):
    • 스토리지 APD(All Paths Down) 상태나 응답 없는 NFS 데이터스토어로 인해 hostd가 스토리지 쿼리 대기 상태에 빠지면 vpxa의 호출에 응답하지 못해 vCenter 연결이 끊어집니다.
  4. vpxuser 계정 동기화 실패 또는 만료:
    • vCenter가 호스트를 관리하기 위해 자동 생성하는 내부 계정인 vpxuser의 비밀번호가 꼬였거나 비활성화된 경우.

3. 단계별 복구 및 해결 방법

1) ESXi 호스트 관리 에이전트 재시작

가장 빠르고 표준적인 해결책입니다. 서비스 재시작 중에도 가상 머신(VM)의 네트워크와 디스크 I/O는 전혀 중단되지 않습니다.

# hostd 및 vpxa 동시 재시작
/etc/init.d/hostd restart
/etc/init.d/vpxa restart

# 또는 일괄 서비스 재시작 명령
services.sh restart

2) 램디스크 가득 참(100%) 긴급 정리

/tmp나 /var/run이 100%인 경우 대용량 로그나 불필요한 파일을 제거합니다.

# 크기가 큰 파일 검색
find /var/log /tmp -type f -size +10M -exec ls -lh {} \;

# 비정상 누적 로그 정리 후 에이전트 재시작
rm -f /var/log/hp-snmp-agents.log  # 예시
/etc/init.d/vpxa restart

3) vSphere Client에서 수동 재연결(Reconnect)

에이전트가 복구되면 vSphere Client에서 해당 호스트 우클릭 $\rightarrow$ 연결(Connection) $\rightarrow$ 연결(Connect)을 실행합니다.

   

주의사항

  1. 호스트가 ‘응답 없음’일 때 절대로 호스트 강제 재부팅 금지:
    • 호스트가 Not Responding으로 표시되어도 내부 가상 머신들은 정상 운영 중입니다. 관리 통신 두절을 서버 다운으로 오인하여 물리 전원 버튼을 누르거나 서버를 강제 리부팅하면 대규모 서비스 장애로 이어집니다. 반드시 SSH 콘솔로 접속하여 에이전트 상태를 먼저 확인해야 합니다.
  2. vSphere HA 설정 환경에서의 격리(Isolation) 오인 주의:
    • vCenter와의 통신 두절과 관리 네트워크(VMkernel) 전체의 통신 두절은 다릅니다. 하트비트 데이터스토어(Datastore Heartbeat)가 정상 동작하고 게스트 트래픽이 흐르고 있다면 vSphere HA가 잘못 격리 주소 응답 실패로 VM을 재기동하지 않도록 HA 격리 응답 정책(das.usedatastoreheartbeats)을 사전에 검증해 두어야 합니다.
  3. MTU 사이즈 불일치(Jumbo Frame) 확인:
    • 관리 네트워크의 스위치 포트나 VMkernel 포트의 MTU 설정을 9000(점보 프레임)으로 변경했으나 물리 스위치 장비가 1500으로 남아 있는 경우, 대용량 SSL 핸드셰이크 패킷이 드롭되어 vCenter 연결이 간헐적으로 끊기는 현상이 발생할 수 있습니다.