OpenStack 네트워크·스토리지 장애를 명령 순서로 좁히는 방법

OpenStack 장애는 명령을 많이 아는 것보다 순서가 중요합니다. 네트워크가 막힌 것인지, 보안 그룹이 막은 것인지, 포트 바인딩이 끊긴 것인지, Cinder 볼륨이나 게스트 OS 안쪽 문제인지 먼저 계층을 나눠야 합니다.

1. OpenStack 리소스 관계부터 잡는다

VM, 포트, 네트워크, 서브넷, 라우터, 보안 그룹 관계를 먼저 봅니다. 포트가 어떤 네트워크에 붙어 있고 fixed IP가 정상인지 확인해야 tcpdump 결과도 해석할 수 있습니다.

openstack server show <server-id>
openstack port list --server <server-id>
openstack port show <port-id>
openstack network show <network-id>
openstack subnet show <subnet-id>
openstack router list
openstack security group rule list <security-group-id>

2. 게스트 내부에서는 인터페이스, 라우팅, DNS를 분리한다

ping 실패가 곧 전체 네트워크 장애는 아닙니다. IP, default route, DNS, TCP 접속을 각각 나눠서 확인합니다.

ip addr
ip route
resolvectl status 2>/dev/null || cat /etc/resolv.conf
ping -c 3 <gateway-ip>
curl -sv --connect-timeout 3 http://<target-ip>:<port>/
traceroute <target-ip>
mtr -rw <target-ip>

3. 패킷은 양쪽에서 본다

tcpdump는 한 지점에서만 보면 반쪽짜리 증거입니다. 게스트에서 나갔는지, compute 노드의 tap/qbr/ovs 쪽에 보이는지, provider network로 나가는지 순서대로 봅니다.

# guest
sudo tcpdump -ni eth0 host <target-ip> -w /tmp/guest.pcap

# compute node
sudo tcpdump -ni any host <vm-fixed-ip> or host <target-ip>
sudo ovs-vsctl show
sudo ovs-ofctl dump-flows br-int | head

4. 스토리지는 attach 상태와 게스트 파일시스템을 나눠 본다

Cinder에서 attached라고 보여도 게스트가 디스크를 못 잡을 수 있고, 게스트 파일시스템 문제를 OpenStack 볼륨 장애로 오해할 수도 있습니다.

openstack volume list --long
openstack volume show <volume-id>
openstack server show <server-id> -c volumes_attached
openstack volume snapshot list --volume <volume-id>

lsblk
blkid
df -h
dmesg -T | egrep -i "sd[a-z]|nvme|xfs|ext4|i/o|error"

5. 로그는 서비스별로 같은 시간을 맞춘다

nova, neutron, cinder 로그는 장애 재현 시각이나 request id를 기준으로 같이 봐야 합니다. 상태 명령으로 후보를 줄인 뒤 필요한 로그만 보는 편이 빠릅니다.

openstack compute service list
openstack network agent list
openstack volume service list

sudo tail -n 200 /var/log/nova/nova-compute.log
sudo tail -n 200 /var/log/neutron/server.log
sudo tail -n 200 /var/log/cinder/volume.log

정리

OpenStack 장애 분석은 VM 안에서 시작하지 않습니다. 리소스 관계, 게스트 네트워크, 패킷 경로, 스토리지 attach, 서비스 로그를 같은 시간축으로 묶어야 합니다.