Cloud Operations

Virtual Router 네트워크: VM 간 통신 장애를 계층별로 좁힐 때 - DB 상태 관점

VM 간 통신 장애를 계층별로 좁힐 때를 DB 상태 관점에서 좁혀 보는 케이스. Virtual Router / Network 계층의 증상, 확인 명령, 조치 전 판단, 복구 기준을 정리했다.

devmes

• 조회 153

Virtual Router 네트워크: VM 간 통신 장애를 계층별로 좁힐 때 - DB 상태 관점 케이스를 다룬다. 핵심은 VM 간 통신 장애를 계층별로 좁힐 때를 DB 상태 관점에서 좁혀 보는 케이스다.

장애를 좁힐 때는 증상, 영향 범위, 대상 리소스, 최근 변경, 로그 시점을 먼저 맞춘다.

Virtual Router 계층 문제는 사용자가 보기에는 단순 접속 장애지만, 실제로는 NAT rule, conntrack, security rule, upstream route가 같이 얽힌다. rule이 있는데도 통신이 실패하면 각 계층의 상태와 패킷 흐름을 같은 시간대 기준으로 대조한다.

네트워크 장애는 가장 쉽게 방향을 잃는다. VM 안에서는 정상처럼 보이고, Virtual Router에는 rule이 있는 것처럼 보이며, upstream 구간에서는 패킷이 일부만 보이는 식이다. 그래서 이 유형은 한 장비의 출력보다 같은 시간대의 양방향 증거가 더 중요하다.

이 글에서 다루는 케이스

케이스 초점VM 간 통신 장애를 계층별로 좁힐 때를 DB 상태 관점에서 좁혀 보는 케이스
정리한 주제Virtual Router / Network
주요 계층Virtual Router, NAT, port forwarding, overlay/network path
운영 단서주제 프로파일과 장애 흐름 기준으로 재구성

겉으로 보이는 증상

  • port forwarding, static NAT, 내부 CIP 통신, 외부 접속이 간헐적으로 실패한다.
  • job pending이 누적되면서 router rule 반영이 지연된다.
  • ping은 되지만 TCP 세션, NAT, conntrack, firewall rule 중 한 지점에서 끊긴다.

로그에서 먼저 눈에 들어오는 신호

운영 중에는 긴 설명보다 반복되는 로그 문구가 먼저 눈에 들어온다. 같은 문구가 어느 컴포넌트에서 반복되는지와 직전 상태 변화를 먼저 확인한다.

  • Virtual Router / Network 계층에서 증상이 시작되지만 실제 원인은 다른 계층에 있을 수 있다.
  • 눈에 보이는 에러보다 장애 시각, 대상 리소스, 직전 변경 이력을 먼저 맞추는 편이 빠르다.
  • 읽기 전용 확인과 상태 변경 작업을 분리하면 급한 상황에서도 판단이 흐려지지 않는다.

처음에 나눠봐야 할 것

이 케이스는 한 번에 해결 명령을 찾기보다, 아래 기준으로 계층을 나누는 것이 먼저다.

  • VM OS, security group/firewall, virtual router, upstream network를 같은 시간대 기준으로 본다.
  • router 안의 iptables NAT/filter rule과 CloudStack job 상태를 같이 대조한다.
  • 단방향 문제가 의심되면 양쪽에서 tcpdump를 동시에 잡는다.

확인에 쓴 명령 흐름

명령은 현재 환경의 노드명, 리소스 ID, 서비스 이름을 확인한 뒤 대상에 맞게 실행한다.

ip -br addr
ip route
iptables -t nat -S
iptables -S
conntrack -S
conntrack -L | head

tcpdump -ni any host <client-ip> and port <service-port>
curl -v --connect-timeout 5 http://<public-ip>:<port>/
traceroute <target-ip>

grep -E 'AsyncJob|port forwarding|StaticNat|pending' /var/log/cloudstack/management/management-server.log

조치 전에 판단할 지점

  • 동일 VR에 rule 변경 job이 몰린 경우 신규 변경을 멈추고 pending job부터 정리한다.
  • NAT/port forwarding은 CloudStack DB 값보다 실제 router rule 반영 여부를 우선 확인한다.
  • conntrack table이 가득 찼거나 특정 세션만 남아 있으면 영향 범위를 좁혀 정리한다.

복구됐다고 판단하는 기준

  • 외부에서 public IP:port로 접속하고, VM 내부에서 응답 로그를 확인한다.
  • router rule과 conntrack 상태가 변경 후에도 유지되는지 확인한다.
  • CloudStack async job이 Success/Completed로 종료되었는지 본다.

운영하면서 남은 교훈

이 케이스는 조치 자체보다 대상 식별이 더 중요하다. 같은 “VM이 안 된다”는 증상이어도 VM guest, compute host, storage attachment, virtual router, management service 중 어디가 기준점인지에 따라 명령과 위험도가 완전히 달라진다.

장애 시각, 대상 리소스, 직전 변경 이력, 확인 명령, 실제 조치, 검증 결과를 같은 순서로 남겨두면 다음 장애에서 단순 기억이 아니라 판단 근거로 다시 쓸 수 있다.

BGM EVER