안녕하세요. 오픈소스컨설팅 조철진입니다.
OpenStack 제안을 하다 보면 빠지지 않고 나오는 질문이 있습니다. “NIC 연결이 꼭 추가로 필요한가요?”, 그리고 “트래픽 흐름이 어떻게 되나요?” 와 같은 질문입니다. 사실 두 질문은 하나로 이어져 있습니다. 어떤 노드에 provider network용 NIC가 필요한지는, VM을 어떤 네트워크로 구성하는가에 따라 결정되기 때문입니다.
그런데 이 답은 트래픽 유형마다 다릅니다 — VM끼리의 통신, Floating IP를 붙인 VM의 외부 통신, FIP 없는 VM의 SNAT, provider network 직접 연결이 전부 다른 경로를 탑니다. 여기에 legacy OVS(ML2/OVS + DVR) 시절의 지식과 현재 표준이 된 OVN의 동작이 섞이면서 표준적인 정리의 필요성을 느꼈습니다.
그래서 이번 글에서는 동일한 아키텍처 그림 위에 유형별 트래픽 경로를 색으로 표기해, 각 흐름이 어느 노드를 지나가는지 한눈에 비교할 수 있도록 정리해봤습니다.
모든 그림은 아래 동일한 구성을 사용합니다. 컴퓨트 노드 2대(전부 provider NIC 연결), 네트워크 노드 역할을 하는 컨트롤러 노드, provider network와 외부망 입니다. 각 노드 안에는 OVS 브리지인 내부용 br-int와 provider NIC와 연결되는 브릿지인 br-ex를 함께 표시했습니다.
IP 대역은 아래와 같이 가정합니다. 이후 그림과 설명에 나오는 주소는 모두 이 기준입니다.
| 구분 | 대역 | 용도 |
|---|---|---|
| 테넌트 네트워크 A | 10.0.1.0/24 | VM 간 내부 통신 (geneve 오버레이) |
| 테넌트 네트워크 B | 10.0.2.0/24 | 서로 다른 서브넷 간 라우팅 예시용 |
| Provider network | 111.111.111.0/24 | 인터넷 통신 용도 외부 네트워크 |
legacy OVS를 기억하시는 분이라면 br-tun이 없다고 생각할텐데 없는 게 맞습니다. OVN에서는 geneve 터널이 br-int에 직접 붙기 때문에 br-tun 계층 자체가 사라졌습니다. 그림에 br-int와 br-ex만 있는 이유입니다.
같은 테넌트 네트워크 안의 VM끼리 통신하는 가장 단순한 경우입니다. L2 스위칭이므로 라우팅 자체가 없고, 출발 노드의 br-int가 목적지 VM의 위치를 이미 알고 있어 geneve 터널로 상대 노드의 br-int까지 직행합니다.
서브넷이 다르면 라우팅이 필요합니다. Legacy 중앙집중 라우터에서는 이 트래픽이 네트워크 노드까지 갔다 와야 했지만, OVN의 논리 라우터는 모든 컴퓨트 노드의 br-int에 동일하게 존재하는 분산 라우터입니다. 라우팅 홉은 출발 노드 안의 분산 Router에서 플로우 처리로 끝나고, 그 다음은 geneve를 통해 직행합니다.
FIP 없는 VM이 외부로 나갈 때는 라우터의 external gateway IP 하나를 그 라우터 밑의 모든 VM이 공유합니다. 이 트래픽만은 게이트웨이 chassis 한 곳으로 모입니다. NAT 원리상의 제약이라 OVN이든 legacy DVR이든 동일합니다.
먼저 FIP는 외부(provider)와 내부 서브넷을 잇는 라우터가 있어야 할당할 수 있습니다. 그 라우터의 external gateway port는 게이트웨이 chassis(네트워크 노드)에 위치합니다. 그림에서 우측 게이트웨이 쪽 회색 점선이 그것입니다. 즉 네트워크 노드는 이 구성의 전제로서 항상 연결되어 있습니다. 다만 FIP 데이터 트래픽은 그 port를 우회합니다.
FIP는 VM 하나에 1:1로 매핑되는 고유한 외부 IP입니다. 그래서 NAT를 VM이 떠 있는 노드에서 로컬로 처리할 수 있고, 트래픽은 그 노드의 br-ex로 즉시 나갑니다 FIP는 양방향 1:1 NAT입니다. 들어올 때도 나갈 때도 그 VM은 자기 FIP 하나로만 통신합니다. 나갈 때 라우터의 공유 SNAT IP를 쓰지 않습니다.
ML2/OVN의 enable_distributed_floating_ip 기본값은 False입니다. 즉 아무 설정 없이 배포하면 FIP 트래픽도 3번째 Flow 처럼 게이트웨이 chassis를 경유(중앙집중)합니다. 이 그림의 분산 경로는 해당 옵션을 명시적으로 켠 경우이며, “OVN이면 FIP는 무조건 분산”이 아니라는 점에 유의해야 합니다.
VM의 포트를 provider network에 직접 만들면 Neutron 라우터도, NAT도, geneve도 없습니다. VM은 외부 대역의 IP를 직접 갖고, 트래픽은 br-int의 localnet 포트를 통해 br-ex로 바로 나갑니다. 겉보기 경로는 Flow 4와 같지만 NAT 단계가 아예 없다는 점이 다릅니다.
마지막으로 로드밸런서 경유 트래픽입니다. Octavia 드라이버는 amphora 방식과 OVN provider 방식이 있는데, OVN provider는 아직 TLS나 L7 정책 미지원, 밸런싱 알고리즘 제한 등 기능 제약이 많아 여전히 amphora 드라이버를 기본으로 사용 중으로 amphora 기준으로 설명합니다.
amphora는 haproxy가 내장된 VM입니다. 그래서 새로운 경로가 아니라 앞서 본 flow들의 조합으로 생성됩니다. 클라이언트가 FIP로 접속하면 amphora 가 위치한 노드의 LB VIP에 도달하고, haproxy가 geneve 터널을 통해 멤버 VM이 속한 서브넷으로 프록시 합니다.
lb-mgmt-net은 Octavia를 컨트롤하는 서비스가 amphora를 관리하는 전용 네트워크 입니다.
Q. 모든 컴퓨트 노드에 provider NIC가 필요한 이유가 뭔가요?
A. Flow 4(FIP)와 Flow 5(직접할당) 때문입니다. 두 유형 모두 VM이 떠 있는 바로 그 노드의 br-ex에서 나가므로, 해당 VM이 어느 노드에 스케줄링 되어도 동작하려면 전 노드에 provider NIC와 bridge mapping이 있어야 합니다. 반대로 공유 SNAT(Flow 3)만 쓰는 환경이라면 게이트웨이 chassis에만 있어도 됩니다
Q. OVN은 iptables의 역할을 어떻게 대체하나요?
A. legacy ML2/OVS는 iptables가 OVS 포트에 직접 걸리지 않아서, VM마다 리눅스 브리지(qbr)와 veth 페어를 생성하고 거기에 iptables를 적용하는 구조였습니다. OVN은 OVS의 conntrack 통합 기능을 사용해 OpenFlow 룰만으로 필터링을 수행합니다 — iptables도, qbr 브리지도 없이 VM 포트가 br-int에 직결됩니다. 홉이 줄어 성능에 유리하고, 노드별 iptables 룰 관리가 사라져 운영도 단순해집니다.
Q. OVN에서는 기존 L3와 DHCP는 어떤 식으로 처리하나요?
A. legacy 에서 l3-agent와 dhcp-agent가 네임스페이스(qrouter, fip, qdhcp)를 만들어 처리하던 일을, OVN에서는 NB DB에 선언하고 각 노드의 ovn-controller가 br-int 플로우로 실체화하는 방식으로 대체합니다. L3는 본문의 flow들이 보여준 그대로 라우팅은 전 노드 분산, ext-gw만 게이트웨이 chassis 고정 이고, DHCP는 VM이 있는 노드의 br-int가 직접 응답해 DHCP 패킷이 노드 밖으로 나가지 않습니다.
Q. OVN의 보안 그룹은 어떻게 동작하나요?
A. 쓰는 방법과 동작은 기존과 똑같고, 구현 방식만 바뀌었습니다 — iptables가 하던 규칙 검사는 br-int의 OpenFlow 룰이 대신하고, stateful 처리는 OVS가 커널 conntrack을 직접 써서 유지되며, remote group 멤버 IP를 묶던 ipset은 OVN의 Address_Set이 같은 방식으로 대체합니다.
Q. 라우팅·NAT·보안그룹이 전부 “플로우”라는데, OVN은 무슨 원리로 동작하나요?
A. OVN은 SDN 구조입니다 — 제어(무엇을 할지)와 데이터(패킷 처리)가 분리되어 있습니다. Neutron이 라우터·보안그룹 같은 의도를 NB DB에 선언하면, ovn-northd가 이를 논리 플로우로 컴파일해 SB DB에 넣고, 각 노드의 ovn-controller가 자신에 해당하는 설정만 골라 OpenFlow 룰로 변환해 br-int에 설치합니다.
OpenFlow는 컨트롤러가 스위치의 플로우 테이블을 프로그래밍하는 SDN 표준 프로토콜이고, 이후 패킷 처리는 별도 프로세스 없이 이 테이블 매칭만으로 이뤄집니다. 본문에서 “라우터가 모든 노드에 존재한다”, “DHCP가 노드 로컬에서 응답한다”고 했던 것들이 전부 이 원리의 결과입니다.
지금까지 OVN으로 구성한 OpenStack의 네트워크 흐름을 유형별로 알아보았습니다. 정리해보면 공유 SNAT만 게이트웨이를 거치고, 나머지 트래픽은 모두 VM이 떠 있는 노드에서 바로 처리됩니다.
이게 가능한 건 OVN이 SDN이기 때문입니다. legacy처럼 노드마다 에이전트를 띄워 트래픽을 처리하는 게 아니라, 설정을 DB에 넣으면 각 노드의 가상 스위치가 그대로 동작합니다. 그래서 패킷이 거치는 네트워크 홉이 줄어들며 지연은 낮아지고, 네트워크 노드로 트래픽이 몰리는 부담도, 에이전트 장애로 통신이 끊기는 걱정도 예전보다 훨씬 덜합니다.
감사합니다.
