OVS/OVN과 SDN의 이해

개요

이번에는 오픈스택 Neutron 네트워크의 동작원리를 탐구하며 OVS/OVN에 대해 정리를 해보고자 한다.

OVS

Architecture

전체 아키텍쳐

OVS 개요

OVS(OpenvSwitch)에 오픈소스 가상 네트워킹을 제공한다.
제공하는 L2/3 가상 네트워킹 기술

• 논리적 스위치와 라우터 기능
• 보안그룹 (Security groups)
• L2~L4 ACL 기능
• 다양한 환경의 터널링 기술 (Geneve, STT, VXLAN)

아래 플랫폼에서 동작

• 리눅스( KVM, Xen )
• 컨테이너 ( Docker, Podman, lxc )
• DPDK
• Hyper-V

OpenStack과 그 이외 CMS와 통합됨.

OVN

Architecture

전체 아키텍쳐

CMS (Cloud Management System)

• OVN의 논리 네트워크 관리 및 물리 네트워크와의 통합(Integration).
• CMS는 오픈스택과 같은 플랫폼에서 네트워크 구성에 사용되는 Neutron 을 의미.
• CMS Plugin은 Neutron에서 ml2/ovn 플러그인에 해당한다.

OVN Databases

OVN의 논리 네트워크 및 물리 네트워크 정보를 저장.

Southbound DB
Southbound DB에서는 아래 정보를 가지고 있다.

• 논리 포트의 위치.
• 물리적 엔드포인트의 위치.
• 런타임 상태와 설정값을 기반으로 생성된 논리적 파이프라인 정보.

Northbound DB
Northbound DB에서는 아래 정보를 가지고 있다.

• 논리 포트 -> 논리 스위치 -> 논리 라우터

오픈스택/CMS의 통합하는 지점으로서의 역할을 한다.

데몬

ovn-northd

• 고급 수준의 northbound DB를 런타임 레벨의 southbound DB로 변환(Convert).
• 고급 수준의 설정(Configuration)을 기반으로한 논리적 흐름(flow)을 생성.

기존 네트워크와 비교하면 이런느낌이지 않을까 싶다.

arp테이블=Chassis테이블/cef테이블=Bindings테이블

ovn-controller

• southbound db에 chassis와 VIF 정보를 등록.
• 논리적 흐름을 물리적흐름으로 변환.
• OVSDB와 OpenFlow를 통해 로컬에 존재하는 OVS 인스턴스를 대상으로 물리적 설정을 입력.

오픈스택에서의 구조

1. Northbound DB에 논리 설정
2. ovn-northd가 가진 논리정보를 기반으로 Southbound DB에 논리적 엔드포인트를 정의.
3. ovn-controller는 Southbound DB의 엔드포인트를 기반으로 통신.

OVN Database HA구성

ovsdb-server를 기반으로 HA를 구성한다.(전체 아키텍쳐의 그림 참조)
primary/backup 모드를 지원한다.
pacemaker를 이용하여 관리.

퍼포먼스 비교

RHOSP v13 vs v16

이번 포스팅을 시작하게 된 계기인 “naleejang’s Blog” 포스팅을 보고 OVN과 neutron의 동작원리가 궁금해졌는데, 드디어 정리를 해본다.

RHOSP v13

RHOSP v16

v13과 v16의 neutron 변화
v13에서는 controller노드에 neutron-server가 있고 컴퓨트노드에 neutron-ovs-agent 가 있었는데 v16에서는 ovn-northd/ovn-controller … ovn으로 통합 되었다.

기존 neutron 메커니즘은 중앙관리를 위해 ovsdb-server를 controller에 설치 한듯 보인다.
ovs-vswitch는 next-hop을 모르니 데이터 처리를 위해 ovsdb-server로 데이터를 보내고, ovsdb-server에서 br-ex로 이어주는 역할을 한다.

v16에 와서는 컴퓨트노드마다 ovsdb-server를 설치하여 br-ex 인터페이스를 가질수 있게 되었으며 ovn을 통해 네트워크 통합관리 하도록 구조변경을 해냈다. 이로인해 데이터의 병목이 사라지고 컴퓨트노드는 컨트롤러를 경유하지 않고도 직접 외부로 통신을 할 수 있게 되었다.

참고로 br-int는 internal의 약자가 아니라 integration(통합)의 약자

변경점 정리

• Neutron이 백엔드로 OVN로 대체됨
• 다양한 인터페이스 지원
  • ML2 메커니즘 드라이버
  • L3 서비스 플러그인
  • QoS Notification 드라이버
  • Trunk 드라이버
• OVSDB 프로토콜을 python-ovs 라이브러리을 통해 OVN 설정가능.

OVS vs OVN Control Plane

• ML2/OVS
  • RPC over Message queue
  • Neutron 에이전트
  • 파이썬 기반제작
• OVN
  • Database 이용
  • Neutron 에이전트를 OVN으로 대체
  • C언어 기반제작

OVS vs OVN 성능비교

OVS vs OVN Data Plane

• 분산 라우팅지원(Distributed Routing)
• ACL 및 NAT에 연결 추적기능 (native connection tracking functionality)
  • 리눅스: Netfilter conntrack kernal module
  • DPDK: New ovs userspace connection tracker

Geneve vs VxLAN

• OVN은 하이퍼바이저 연결방식에 Geneve와 STT를 지원
  • VxLAN은 metadata 공간이 제한됨.
• 일부 NIC에 대해 Geneve-offloading을 지원

헤더 비교

GENEVE Variable필드

SDN

SDN 개요

Overlay SDN

Overlay는 OpenStack, Kubernetes, KVM, Xen, Container와 같이 수평적으로 환경에서 사용하는 기술이다.
192.168.0.0/24 네트워크 대역을 하이퍼바이저의 리소스(Cpu/Memory)의 한계로 1대에 모든 대역폭을 사용하는 것은 불가능하다.
또한 물리 네트워크에서 직접 IP를 관리를 하면 가상PC의 mac주소를 물리스위치에서 학습을 하는데, 쿠버네티스로 엄청난 갯수의 컨테이너를 배포하는 환경이라면? 물리 스위치에서 1대에서 감당할 수 없는 양의 mac주소를 학습해야하는 상황이 생긴다.

이는 기업에 있어서 네트워크 자원의 낭비 혹은 고갈로 이어질 수 있다. 이를 해결하기 위해 생겨난것이 VXLAN/GENEVE 패킷이다.
VXLAN/GENEVE 패킷을 이용해 수평관계에 있는 컴퓨팅노드와 터널링을 하여 네트워크 통합을 이루어 낼 수 있으며, IPSec VPN과는 다르게 오버헤드가 적다.

Underlay SDN

Underlay SDN는 물리적 스위치에 SDN을 구현하는 기술이다.
실제로 사용해본 적이 없기에 자료를 찾아보는중이다.
추후 내용을 추가해보도록 함.

SDN 특징

1. 제어계층(Control Plane)과 데이터전송 계층(Data Plane)을 분리.
2. API를 활용하여 네트워크 구성 요소를 프로그래밍을 통해 관리가능.
3. 네트워크 경로/구성을 커스터 마이징 가능.

인프라의 변화

왼쪽이 기존의 3계층 기반의 인프라 구조 (Core-Dist-Access)
오른쪽은 기존 인프라 구조의 문제점을 개선한 차세대 구조 (Spine & Leaf)

소프트웨어 정의 데이터센터

SDDC는 아래 3가지 환경으로 이루어진 환경을 뜻한다.

• SDN - 네트워크 가상화
• SDC - 서버 가상화
• SDS - 스토리지 가상화

마치며

앞으로 SDN도 알아야하는 시대가 오고있다는게 느껴집니다.
이번 포스팅에서 다루고 있지 않지만, 조사하면서 5G와 연관성이 높다는 것을 알게 됬습니다.

참고자료

• OpenVSwitch
• Open Virtual Network
• naleejang’s Blog
• SDN 입문
• all-tunnels-lead-to-geneve