Cloud Operations

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

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

devmes

• 조회 137

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

수집한 운영 단서에서 고객명, 내부 주소, 노드명을 제거하고 장애 흐름과 확인 순서만 남겼다.

Virtual Router 계층 문제는 사용자가 보기에는 단순 접속 장애지만, 실제로는 NAT rule, conntrack, security rule, upstream route가 같이 얽힌다. 이 글은 rule이 있는 것처럼 보이는데 통신이 실패하는 유형을 기준으로 정리했다.

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

이 글에서 다루는 케이스

케이스 초점VM 간 통신 장애를 계층별로 좁힐 때를 네트워크 경로 관점에서 좁혀 보는 케이스
정리한 주제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 중 한 지점에서 끊긴다.

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

운영 중에는 긴 설명보다 반복되는 로그 문구가 먼저 눈에 들어온다. 아래 신호는 실제 값 대신 예시 placeholder로 바꿔 흐름만 볼 수 있게 정리했다.

  • `- fail 발생 시 아래와 같이 수행 (client 재기동 두번 수행해야 함)`

처음에 나눠봐야 할 것

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

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

확인에 쓴 명령 흐름

아래 명령은 공개 가능한 형태로 일반화했다. 실제 값은 환경마다 다르므로 placeholder를 대상 리소스에 맞춰 바꿔야 한다.

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