[Openstack] 오픈스택 고급 네트워킹 (SDN, NFV, 로드 밸런서) 개념 설명

오픈스택 고급 네트워킹 – SDN 및 NFV

클라우드 컴퓨팅 스택에서 네트워킹은 가장 복잡한 서비스 중 하나입니다. 클라우드 컴퓨팅의 발전은 네트워킹 서비스에 엄청난 요구사항을 부여했으며, 최신 네트워크 서비스는 임의의 엔드포인트를 연결하는 극도의 유연성을 처리하고 고성능 통신 채널을 제공하며 새로운 서비스를 빠르게 프로비저닝할 수 있어야 합니다.

 

서비스 제공업체는 네트워크 서비스에 대한 증가하는 수요를 충족하고 동시에 전력, 인프라 및 부동산 비용을 절감하기 위해 새로운 인프라를 프로비저닝하는 데 최소한의 리드 타임을 원하고 있습니다.

OpenStack은 이러한 새로운 사용 사례를 지원하기 위해 새로운 프로젝트를 수용했습니다.

세 가지 주요 고급 네트워킹 서비스

• OVN(Open Virtual Network): SDN(Software-Defined Networking) 구현으로 살펴봅니다.
• Tacker: OpenStack을 활용한 NFV(Network Function Virtualization) 플랫폼을 제공합니다.
• Octavia: 가상 어플라이언스를 사용하여 로드 밸런서 서비스를 제공하는 LBaaS(Load Balancer as a Service) v2 구현을 살펴봅니다.

---

SDN(Software-Defined Networking) 기반 네트워크 이해

https://konkukcodekat.tistory.com/283

[네트워크] SDN과 Openflow 동작 원리와 미들박스(Middlebox)

• SDN은 네트워크 장비(스위치, 라우터 등)의 동작 방식을 소프트웨어로 자유롭게 바꿀 수 있게 해주는 기술입니다.
• 기존에는 네트워크 장비마다 개별적으로 설정해야 했지만, SDN은 중앙에서 한 번에 네트워크 전체를 제어할 수 있습니다.

SDN의 핵심 구조

• 중앙 컨트롤러: 네트워크의 두뇌 역할을 하며, 전체 네트워크의 트래픽 흐름을 결정합니다.
• 스위치/라우터(데이터 플레인): 실제로 패킷을 빠르게 전달하는 역할만 담당합니다.
• 제어와 전달의 분리: 컨트롤러(제어)는 명령만 내리고, 스위치(전달)는 명령에 따라 패킷을 전달합니다.

SDN이 동작하는 방식

1. 네트워크 관리자는 컨트롤러에 네트워크 정책(규칙)을 설정합니다.
2. 컨트롤러가 네트워크 장비(스위치)에 전달 규칙을 내려줍니다.
3. 스위치는 들어오는 패킷이 규칙과 일치하는지 확인해서, 일치하면 지정된 대로 패킷을 전달합니다.

OpenFlow 개념

• OpenFlow는 SDN에서 많이 쓰이는 표준 프로토콜입니다.
• 컨트롤러가 스위치에 "이런 조건의 패킷은 어디로 보내라"는 식의 규칙(흐름 항목, 플로우 엔트리)을 설치할 때 사용합니다.
• 스위치는 패킷이 들어오면, OpenFlow 규칙에 따라 처리하거나 다음 테이블로 넘깁니다.

SDN의 장점

• 네트워크를 소프트웨어처럼 쉽게 바꿀 수 있음
• 중앙에서 전체 네트워크를 한눈에 보고 제어 가능
• 트래픽 흐름을 유연하게 바꿔서, 장애 대응이나 서비스 확장에 유리함

정리:

SDN은 네트워크의 뇌(컨트롤러)와 몸(스위치/라우터)을 분리해서, 중앙에서 소프트웨어로 네트워크를 자유롭게 설계·제어할 수 있게 해주는 기술입니다.

OpenFlow 같은 표준을 통해 컨트롤러가 스위치에 규칙을 내려주고, 스위치는 그 규칙대로 패킷을 전달합니다.

이 덕분에 네트워크를 더 유연하고 효율적으로 운영할 수 있습니다.

---

OVS(Open vSwitch) 아키텍처

Open vSwitch는 OpenFlow 사양의 흐름 프로그래밍 sementics를 사용하는 가상 스위치 구현입니다.

OVS는 OVSDB 프로토콜을 사용하여 스위치 관리를 위한 인터페이스를 노출하고, OpenFlow 사양을 사용하여 흐름 프로그래밍을 노출합니다.

OVS 인스턴스는 흐름 규칙으로 로컬에서 구성되거나, 흐름 항목을 푸시하는 SDN 컨트롤러에 연결될 수 있습니다.

OVS 스위치는 OVSDB 관리자에 연결하여 스위치 구성 데이터를 수신할 수 있는 사용자 공간 데이터베이스인 ovsdb와 SDN 컨트롤러에 연결하여 흐름 프로그래밍 데이터를 수신하는 vswitchd 데몬으로 구성됩니다.

1. 상위 제어 계층

• OpenFlow Controller
  • 네트워크 전체를 중앙에서 제어하는 SDN 컨트롤러입니다.
  • OVS 인스턴스들과 OpenFlow 프로토콜로 통신하여, 패킷 포워딩 정책(플로우 테이블 등)을 동적으로 제어합니다.
• OVSDB Manager
  • OVS의 설정 정보를 관리하는 데이터베이스(OVSDB)와 상호작용하는 관리 컴포넌트입니다.
  • 네트워크 토폴로지, 포트, 브리지 등의 설정 정보를 동기화합니다.

2. 사용자 공간(User Space) 구성요소

• ovsdb-server
  • OVS의 설정 및 상태 정보를 저장·관리하는 데이터베이스 서버입니다.
  • OVSDB 프로토콜을 통해 외부 관리 도구나 컨트롤러와 통신합니다.
• vswitchd
  • OVS의 핵심 데몬으로, 패킷 처리 논리와 플로우 테이블 관리 등 주요 네트워크 동작을 담당합니다.
  • OpenFlow 컨트롤러와 직접 통신하여, 플로우 엔트리 등 네트워크 정책을 적용합니다.

3. 커널 공간(Kernel Space) 구성요소

• openvswitch.ko
  • 리눅스 커널 모듈로, 실제 패킷 포워딩을 빠르게 처리합니다.
  • 사용자 공간의 vswitchd와 연동하여, 커널 레벨에서 네트워크 트래픽을 효율적으로 분산·전달합니다.

4. 노드 간 구조

• 그림에는 두 개의 OVS 인스턴스가 나란히 배치되어 있습니다.
  • 각 인스턴스는 ovsdb-server, vswitchd, openvswitch.ko로 구성되어 있습니다.
  • 중앙의 OpenFlow Controller와 OVSDB Manager가 각 인스턴스와 연결되어 전체 네트워크를 통합 관리합니다.

요약

• OpenFlow Controller: 네트워크 정책 및 트래픽 흐름을 중앙에서 제어
• OVSDB Manager: OVS의 설정 정보 관리
• ovsdb-server: 설정 데이터베이스
• vswitchd: 패킷 처리 및 정책 적용
• openvswitch.ko: 실제 패킷 포워딩(커널 공간)

이 구조를 통해 SDN 환경에서 네트워크를 중앙 집중적으로 제어하고, 유연하게 확장 및 관리할 수 있습니다.

---

OVN(Open Virtual Network) 아키텍처

OVN은 SDN 아키텍처를 기반으로 한 구현입니다. SDN 아키텍처가 발전함에 따라, 수백 개의 스위치가 있는 대규모 네트워크에 배포될 경우 중앙 집중식 컨트롤러가 병목 현상이 될 수 있다는 것이 분명해졌습니다. OVN 아키텍처는 여러 OVS 데이터베이스와 컨트롤러를 사용하여 프로그래밍 가능한 가상 네트워킹 솔루션을 제공함으로써 이 단점을 제거합니다.

1. 상위 계층: CMS (Cloud Management System)

• CMS는 OpenStack, Kubernetes 등과 같은 클라우드 관리 플랫폼을 의미합니다.
• 네트워크의 논리적 정의(예: 가상 네트워크, 라우터, ACL 등)를 사용자로부터 받아서 OVN에 전달합니다.

2. 중앙 제어부: Northbound DB & Southbound DB

• Northbound DB
  • CMS로부터 받은 논리적 네트워크 정보를 저장하는 데이터베이스입니다.
  • 예: 가상 스위치, 논리 라우터, ACL 정책 등.
• Northd
  • Northbound DB와 Southbound DB 사이에서 논리 정보를 실제 네트워크 구성 정보로 변환하는 핵심 데몬입니다.
• Southbound DB
  • 각 Compute Node의 ovn-controller와 통신하며, 실제 네트워크 상태 및 플로우 정보를 저장합니다.

3. 하위 계층: Compute Node 및 OVS

• ovn-controller
  • 각 Compute Node(가상머신이 실제로 구동되는 서버)에서 동작하는 에이전트입니다.
  • Southbound DB에서 받은 정보를 바탕으로, 해당 노드의 OVS에 네트워크 정책을 적용합니다.
• OVS (Open vSwitch)
  • 가상 스위치 역할을 하며, 실제 패킷 포워딩을 담당합니다.
  • 내부적으로는 ovsdb(설정 데이터베이스)와 vswitchd(패킷 처리 데몬)로 구성되어 있습니다.

데이터 흐름 요약

1. 사용자/관리자가 CMS를 통해 네트워크를 정의합니다.
2. CMS는 이 정보를 Northbound DB에 저장합니다.
3. Northd가 논리 정보를 실제 네트워크 정책으로 변환하여 Southbound DB에 반영합니다.
4. 각 Compute Node의 ovn-controller가 Southbound DB에서 정책을 받아, 해당 노드의 OVS에 적용합니다.
5. OVS는 실제 VM/컨테이너 트래픽을 논리 네트워크 정책에 따라 포워딩합니다.

---

OpenStack과 OVN의 연결 방식

• OpenStack은 네트워크 기능을 직접 처리하지 않고, OVN 같은 네트워크 시스템에 요청을 보냅니다.
• 이때 ML2 드라이버(Layer-2 네트워크용)와 L3 서비스 플러그인(라우터 등 Layer-3 기능용)을 통해 OpenStack과 OVN이 연동됩니다.
• 보안 그룹(방화벽처럼 동작하는 기능)도 함께 지원합니다.

OVN의 터널링: Geneve 프로토콜

• OVN은 여러 서버에 흩어진 VM들을 하나의 네트워크처럼 보이게 하려고 Geneve라는 터널링 기술을 사용합니다.
• Geneve의 장점:
  • 네트워크 관련 정보를 헤더에 자유롭게 추가할 수 있어, 다양한 상황에 맞게 확장성이 뛰어납니다.
  • 기존 VXLAN도 지원하지만, Geneve는 더 많은 정보를 담을 수 있습니다.
  • 무작위 소스 포트를 사용하여 네트워크 경로(ECMP)를 다양하게 활용할 수 있습니다. 즉, 트래픽 부하 분산이 더 잘 됩니다.

OVN을 사용한 가상 네트워크 구현 방식

• OpenStack에서 네트워크를 만들면, OVN에서는 다음과 같이 매핑됩니다:
  • 가상 네트워크 → 논리적 스위치(ls)
  • 가상 포트(VM이 네트워크에 연결되는 지점) → 논리적 스위치 포트(lsp)
  • 가상 라우터 → 논리적 라우터(lr)
  • 라우터 포트 → 논리적 라우터 포트(lrp)
• 사용자가 OpenStack에서 네트워크를 생성하면, 이 정보는 OVN의 northbound 데이터베이스에 저장됩니다.
• OVN-northd 데몬이 이 정보를 실제 네트워크 흐름 정보로 바꿔서 southbound 데이터베이스에 저장합니다.
• 각 서버에서는 이 정보를 받아 실제로 네트워크를 구성합니다.

즉, OpenStack에서 네트워크와 라우터를 만들면 OVN이 실제로 이를 처리하며, Geneve 터널을 통해 여러 서버에 걸쳐 가상 네트워크를 효율적으로 연결합니다. 덕분에 클라우드 환경에서 네트워크를 쉽고 유연하게 확장·관리할 수 있습니다.

---

NFV(Network Function Virtualization)

NFV의 개념

• NFV는 네트워크 장비(라우터, 방화벽, 로드밸런서 등)를 물리 장비가 아니라 소프트웨어(VNF, Virtual Network Function)로 만들어 서버에서 실행하는 기술입니다.
• 예전에는 새로운 네트워크 서비스를 추가하려면 장비를 구매하고, 설치하고, 전원과 공간을 따로 마련해야 했습니다.
• NFV를 쓰면 서버에 소프트웨어만 설치해서 네트워크 기능을 빠르게 추가하거나 삭제할 수 있습니다.
• 필요할 때 VNF 인스턴스를 늘려서 확장하고, 사용하지 않으면 줄여서 자원을 아낄 수 있습니다.

SDN과 NFV의 차이

• SDN은 네트워크의 트래픽 흐름을 소프트웨어로 유연하게 제어하는 기술입니다.
• NFV는 네트워크 기능 자체를 가상화해서, 하드웨어가 아닌 소프트웨어로 서비스할 수 있게 하는 기술입니다.

NFV의 핵심 구성요소(MANO)

NFV 환경을 관리하고 자동화하는 표준 구조를 MANO(Management and Orchestration)라고 부릅니다. 주요 구성요소는 다음과 같습니다:

구성요소	역할
VIM (Virtual Infrastructure Manager)	컴퓨트, 네트워크, 스토리지 등 인프라 자원을 관리 (예: OpenStack)
VNFM (VNF Manager)	VNF(가상 네트워크 기능) 소프트웨어의 설치, 삭제, 상태 관리
NFVO (NFV Orchestrator)	여러 VNF를 조합해 서비스로 만들고, 전체 라이프사이클을 관리

TOSCA 템플릿

• TOSCA는 네트워크 서비스(VNF 등)를 설명하는 표준 템플릿 언어입니다.
• 예를 들어, "이 VNF는 CPU 2개, 메모리 4GB, 특정 이미지 필요"처럼 자원 요구사항과 네트워크 연결 구조를 코드로 정의할 수 있습니다.

OpenStack Tacker 프로젝트

• OpenStack Tacker는 OpenStack 환경에서 NFV를 쉽게 쓸 수 있게 해주는 오픈소스 프로젝트입니다.
• Tacker는 VIM(OpenStack), VNFM, NFVO 역할을 모두 지원합니다.
• VNF를 만들려면:
  1. VIM(예: OpenStack)을 등록
  2. TOSCA 템플릿으로 VNF를 정의(온보딩)
  3. 정의한 VNF를 실제로 배포

NFV는 네트워크 장비를 소프트웨어(VNF)로 바꿔서, 서버에서 쉽게 설치·확장·삭제할 수 있게 해줍니다.

MANO 구조(VIM, VNFM, NFVO)로 전체 NFV 환경을 효율적으로 관리하고,

TOSCA 템플릿으로 네트워크 서비스 구성을 코드로 정의할 수 있습니다.

OpenStack의 Tacker 프로젝트를 활용하면, 이 모든 과정을 자동화해서 클라우드에서 NFV를 쉽게 운영할 수 있습니다.

---

Octavia를 사용한 LBaaS(Load Balancer as a Service) 배포

Neutron의 로드 밸런서 서비스는 v2 API로 발전했습니다. 새로운 LBaaS API는 단일 로드 밸런서 IP에서 여러 리스너를 생성할 수 있도록 합니다. Octavia는 LBaaS v2 API의 구현이며, 로드 밸런서 서비스를 제공하기 위해 가상 어플라이언스 기반 접근 방식을 사용합니다.

Octavia 구성은 neutron.conf 파일에서 서비스 플러그인을 업데이트하여 수행됩니다.

로드 밸런서 생성 과정은 다음과 같습니다:

1. 실제 서비스를 실행할 두 개의 서버 인스턴스를 생성합니다.
2. 로드 밸런서 인스턴스를 생성합니다. 이 단계에서 LBaaS 서비스를 제공하는 가상 어플라이언스가 시작됩니다.
3. 로드 밸런서 서비스가 활성화되면 로드 밸런서에 대한 리스너를 생성합니다.
4. 리스너와 연결된 풀(pool)을 생성합니다. 풀을 생성할 때 로드 밸런싱 전략을 지정해야 합니다(예: ROUND_ROBIN).
5. 풀에 실제 서비스를 실행할 서버를 추가합니다.
6. Nova 인스턴스에서 서비스를 시작합니다.
7. 로드 밸런서 IP의 포트 80에 연결하여 로드 밸런서를 테스트할 수 있습니다. ROUND_ROBIN 알고리즘을 사용하므로 연속적인 클라이언트 요청은 다른 서버에서 처리됩니다.
8. 로드 밸런서에 헬스 모니터(healthmonitor)를 연결할 수 있습니다.