~/blog/OpenStack-Build-4
Published on

OpenStack 구축기 #4: Self-Service Network 내부 구조와 트래픽 흐름

672 words4 min read–––
Views
Authors
  • avatar

초기 구축에 참고했던 메뉴얼에서는 OpenStack 환경에서 Provider Network를 활용해 외부 네트워크와 인스턴스를 연결하는 가장 기본적인 네트워크 구성을 진행했다.

하지만 실제 운영되는 클라우드 환경에서는 Provider Network만으로는 현실적인 한계에 부딪히게 된다. 가장 근본적인 문제는 확장성과 보안이다.

먼저, 확장성 측면에서 Provider Network는 인스턴스가 물리 네트워크 대역에서 직접 IP를 할당받는 구조이기 때문에 IP 자원이 빠르게 부족해질 수 있다. 예를 들어 192.168.0.0/24 대역을 사용한다면 최대 254개의 IP만 제공 가능하며, 이는 수십, 수백 대의 VM을 운영해야 하는 클라우드 환경에서는 명백한 한계다. 더불어 VLAN 기반 Provider 모델은 VLAN ID가 0~4094 범위로 제한되어 있어 프로젝트나 서비스가 늘어날수록 네트워크 확장이 불가능해진다.

보안 측면에서도 Provider Network는 위험하다. 모든 인스턴스가 외부 네트워크와 같은 대역에서 동작하기 때문에 네트워크가 분리되지 않아 외부에서 접근하기 쉬워지는 이슈가 생긴다. 이렇게되면 보안이 중요한 내부 시스템을 안전하게 운영하기 어렵다.

이러한 이유로 OpenStack은 Self-Service Network라는 별도의 네트워크 구조를 지원한다. 이는 VXLAN/Geneve 같은 오버레이 네트워크를 활용해 테넌트 별 독립적인 가상 네트워크를 제공하며, 외부 통신은 NAT + Floating IP로 제어할 수 있다.

이번 포스트에서는 Self-Service Network 내부 구조와 트래픽 흐름에 대해서 정리해보겠다. 아래 이미지는 OpenStack 공식 문서에서 제공하는 Self-Service Network 구성도이다.

1. 내부 구조

OVS 환경에서는 VXLAN 기반의 Overlay 네트워크로 Self-Service Network를 구성하며, 라우팅과 NAT 처리는 L3 Agent가 네트워크 노드에서 중앙 집중식으로 처리한다. 반면 OVN 환경에서는 Geneve 기반 Overlay를 사용하고, 분산 라우팅(DVR) 구조를 지원하여 성능과 확장성 측면에서 보다 효율적인 네트워크 구조를 제공한다. OVN은 OVS 위에 확장되어 동작하는 SDN 기반 네트워크 가상화 시스템으로, 네트워크 구성과 운영 복잡도를 줄이고 안정적인 대규모 클라우드 네트워크 구성을 가능하게 한다.

왜 OVN 환경에서 단일 NIC 구성이 위험한가 - localnet 추가 후 br-ex 관리망이 끊긴 이유 이 글을 보면, OVN 환경에서 Self-Service Network를 구축할 때 2개의 물리 NIC가 필요하다는 것을 알 수 있다. 그렇다면 각 NIC가 어떤 네트워크에 연결되는지 구조를 살펴보자.

  • NIC 1 – 관리망(Management Network)
    관리망은 OpenStack의 내부 통신을 담당하며, 컨트롤 플레인 서비스 간 통신(Keystone API, Neutron RPC, MariaDB, RabbitMQ 등)과 SSH 접속을 처리한다. 그림에서 🔴 빨간색 네트워크의 Interface 1 에 해당한다.

  • NIC 2 – Provider/External Network
    외부 인터넷과 통신하기 위한 네트워크 인터페이스이며, Floating IP가 바인딩되는 네트워크이다. 그림에서는 🟢 초록색 네트워크의 Interface 2 에 해당한다.

반면, 🟣 Self-Service Network는 물리 NIC와 직접 연결되지 않는다. 이 네트워크는 Geneve/VXLAN 기반 오버레이 네트워크로 구현되며, VM 간 통신은 터널(Tunnel)을 통해 전달된다. 캡슐화된 오버레이 트래픽은 Underlay로 지정한 NIC(전용 터널 NIC가 이상적이며, 실습 환경에선 관리망 NIC를 겸용하기도 함)를 통해 호스트 간 전달된다. 물리 경로를 공유하더라도, 캡슐화와 OVN의 논리 스위치/라우터 구조 덕분에 Self-Service Network는 관리망과 논리적으로 격리된 상태로 동작한다.

2. 트래픽 흐름

Self-Service Network에서 트래픽은 다음과 같이 흐른다.

  1. 내부 통신 (VM ↔ VM)
    같은 테넌트 안에서는 Geneve/VXLAN 터널을 통해 노드 간 패킷이 전달된다.

    VM1 (10.0.0.5) → br-int → Geneve/VXLAN Tunnel → br-int → VM2 (10.0.0.6)

    Geneve 기반 Overlay 터널링의 패킷 처리 과정을 자세히 살펴보면 다음과 같다.
    이때 어느 물리 NIC로 나가느냐는 ovn-encap-ip 에서 설정한다.

    VM1 (tap)
-> br-int (OVS/OVN)
   -> Geneve 캡슐화
      -> (선택된 Underlay NIC의 IP로 송신: NIC-TUN 또는 NIC-MGMT)
        -> 물리 스위치/라우터 경유
      -> (상대 호스트의 Underlay NIC 도착)
   -> 디캡슐화
-> br-int
-> VM2 (tap)

  2. 내부 → 외부 통신 (VM → Internet)
    Router Namespace에서 SNAT 수행하여 내부 IP(10.x.x.x)가 Provider Network IP(203.x.x.x)로 변경된다.

    VM (10.0.0.5)
   ↓
Self-Service Network
   ↓
tap 인터페이스 (가상 NIC)
   ↓
br-int (Integration Bridge)
   ↓
qr-xxxxx (Router 내부 인터페이스)
   ↓ Router Namespace (qrouter)
   ↓ SNAT 수행 (10.x → 203.x 변환)
   ↓
qg-xxxxx (라우터 외부 게이트웨이 인터페이스)
   ↓
br-ex (External Bridge)
   ↓
Provider Network
   ↓
Internet

  3. 외부 → 내부 접속 (Internet → VM)
    Router Namespace에서 DNAT 수행하여 Provider Network IP(203.x.x.x)가 내부 IP(10.x.x.x)로 변경된다.

    Internet
   ↓
Provider Network
   ↓
br-ex (External Bridge)
   ↓
qg-xxxxx (라우터 외부 게이트웨이 인터페이스)
   ↓ Router Namespace (qrouter)
   ↓ DNAT 수행 (Floating IP → Private IP 변환)
   ↓
qr-xxxxx (라우터 내부 인터페이스)
   ↓
br-int (Integration Bridge)
   ↓
tap 인터페이스 (가상 NIC)
   ↓
Self-Service Network
   ↓
VM (10.0.0.5)

Self-Service Network 구축은 이론보다 훨씬 까다로웠다. 다음 글부터는 실제 구축 과정에서 발생한 각종 네트워크 문제들을 하나씩 해결해 나갔던 경험을 공유하겠다.