DPDK vs SR-IOV

sr-iov-nfv-tech-brief.pdf

2.15MB

DPDK(Data Plane Development Kit)

기본적으로 linux는 커널을 사용하여 패킷을 처리하므로 NIC 속도가 빠르게 증가함에 따라 커널에서 처리해야할 일이 많아진다.

커널을 우회하는 많은 기술이 있고, kernel space 대신에 user space에서 패킷을 처리하는 기술 중 하나가 DPDK 다.

Kernel space
운영체제의 핵심인 커널이 실행되는 곳. 별도의 사용자 프로세스가 자신의 메모리 공간만 조작하도록 설정.
 
User space
사용자 프로세스가 실행되는 시스템 메모리의 부분. kernel space는 시스템 호출을 통해서만 사용자 프로세스에서 엑세스 할수 있다.

일반적으로 DPDK를 사용하지 않는 환경에서 패킷은 Application에 도달하기 전에 NIC으로부터 Linux Kernel에 올라옵니다.

DPDK가 없으면 패킷 프로세싱은 인터럽트 기반 커널 네트워크 스택을 통해 이루어진다.  NIC이 들어오는 패킷을 수신할 때마다 패킷을 처리하기위한 커널 인터럽트와 kernel space에서 user space으로 컨텍스트 스위칭이 발생하며 이로인해 지연이 발생함.

 

DPDK를 사용하면 애플리케이션이 Linux kernel을  바이패스해서 NIC과 직접 통신 할 수 있게 됨.

user space에서 폴 모드 드라이버를 사용하기에 인터럽트가 필요 없다. poll 모드 드라이버는 NIC으로부터 데이터를 직접 가져올수 있으므로 kernel space를 바이패스패서 데이터의 처리 속도를 향상 시킨다.

 

DPDK with OVS

OpenvSwitch란 ?
Open vSwitch는 프로덕션 품질의 멀티 레이어 가상 스위치입니다. 이는 하이퍼바이저에서 소프트웨어로 실행되며 가상 머신의 가상 네트워킹을 활성화합니다.

Forwarding path
데이터 / 포워딩 경로는 OVS의 주요 패킷 포워딩 모듈로, 고성능을 위해 커널 공간에 구현됩니다.

Vswitchid
주요 Open vSwitch 사용자 공간 프로그램입니다.

 

OVS는 VNF 구현의 일부로 표시됩니다. OVS는 하이퍼 바이저에 있습니다. 트래픽은 그림과 같이 OVS를 통해 한 VNF에서 다른 VNF로 쉽게 전송할 수 있습니다. 실제로 OVS는 NFV의 통신 워크로드에서 작동하도록 설계되지 않았습니다. 전통적인 웹 애플리케이션은 처리량 집약적이지 않으며 OVS는이를 피할 수 있습니다.

OVS는 아무리 훌륭하더라도 앞서 설명한 Linux 네트워킹 스택과 동일한 문제에 직면 해 있습니다. OVS의 포워딩 플레인은 아래와 같이 커널의 일부이므로 처리 속도가 증가함에 따라 잠재적인 병목 현상이 발생할 수 있습니다.

Open vSwitch를 DPDK와 결합하여 더 나은 성능을 얻을 수 있으므로 DPDK 가속 OVS (OVS + DPDK)가 가능합니다.

목표는 표준 OVS 커널 전달 경로를 DPDK 기반 전달 경로로 대체하여 패킷 전달을 위해 내부적으로 DPDK를 사용하는 호스트에 사용자 공간 vSwitch를 만드는 것입니다. 이렇게하면 아래와 같이 사용자 공간에서 완전히 실행되므로 OVS 스위치의 성능이 향상됩니다.

 

 

DPDK ( OVS + VNF)

OVS 대신 VNF에서 DPDK를 실행할 수도 있습니다. 여기서 애플리케이션은 첫 번째 섹션에서 설명한대로 표준 Linux 네트워킹 스택 대신 DPDK를 활용합니다.

이 구현은 OVS에서 DPDK와 결합 될 수 있지만 이것은 또 다른 수준의 최적화입니다. 그러나 둘 다 서로 의존하지 않고 하나는 다른 하나없이 구현할 수 있습니다.

 

SR-IOV(Single Root I/O Virtualization)

핵심은 하이퍼 바이저를 완전히 배제하고 VNF가 NIC에 직접 액세스하도록하여 NIC의 line rate 성능에 가깝게 하는 것입니다.

 

PCI Passthrough 를 사용하면  하이퍼 바이저를 사용하지 않고 게스트 OS에 완전한 NIC를 제공 할 수 있습니다. VM은 NIC에 직접 연결되어 있다고 생각합니다. 여기에 표시된 것처럼 두 개의 NIC 카드와 두 개의 VNF가 있으며 각각은 NIC 카드 중 하나에 독점적으로 액세스 할 수 있습니다. 그러나 아래의 두 NIC는 VNF1 및 VNF3에 의해 독점적으로 사용됩니다. 그리고 세 번째 전용 NIC가 없으며 아래의 VNF2는 액세스 할 수 없습니다.

 

SR-IOV는 PF(단일 PCIe 이더넷 컨트롤러)를 가상화하여 VF(여러 PCIe 장치)로 표시 할 수 있습니다.

PCIe 장치의 가상 슬라이스를 생성함으로써 각 가상 슬라이스를 단일 VM / VNF에 할당 할 수 있으므로 제한된 NIC로 인해 발생하는 문제를 제거 할 수 있습니다. 여러 가상 기능 (VF)이 공유 NIC에 생성됩니다. 이러한 가상 슬라이스가 생성되어 VNF에 제공됩니다.

(PF는 물리적 기능을 의미하며 SR-IOV를 지원하는 물리적 기능입니다.)

이는 VNF의 일부로 DPDK와 추가로 결합 될 수 있으므로 DPDK 및 SR-IOV를 결합하여 활용할 수 있습니다.

 

DPDK, SR-IOV를 사용하는 경우

 

East-West 트래픽 처리 : DPDK 성능 우수

트래픽이 동일한 서버 내에서 East-West 인 경우 (동일한 서버를 반복합니다) DPDK가 SR-IOV에 대해 승리합니다. 상황은 아래 다이어그램에 나와 있습니다.

트래픽이 서버 내에서 라우팅 / 스위칭되고 NIC로 이동하지 않는 경우. SR-IOV를 가져 오는 것에는 이점이 없습니다. 오히려 SR-IOV가 병목 현상이 될 수 있으므로 (트래픽 경로가 길어지고 NIC 리소스가 활용됨) DPDK를 사용하여 서버 내에서 트래픽을 라우팅하는 것이 더 좋습니다.

 

 

North-South  트래픽 처리 :  SR-IOV 성능 우수

North-South의 트래픽 (동서이지만 한 서버에서 다른 서버로의 트래픽도 포함)에서 SR-IOV가 DPDK에 대해 승리합니다. 이 시나리오의 올바른 레이블은 한 서버에서 다른 서버로 이동하는 트래픽입니다.

트래픽이 어쨌든 NIC를 통과해야하므로 DPDK 기반 OVS를 포함하고 더 많은 병목 현상을 일으키는 이유를 해석하는 것도 쉽습니다. SR-IOV는 여기에서 훨씬 더 나은 솔루션입니다.

 

 

결론

트래픽이 서버 내에서 전환되는 경우 (VNF가 서버 내에 있음) DPDK가 더 좋습니다.

트래픽이 한 서버에서 다른 서버로 전환되면 SR-IOV가 더 좋습니다.

 

따라서 설계 및 트래픽 흐름을 알아야합니다. 잘못된 결정을 내리면 위의 그래프에서 볼 수 있듯이 낮은 처리량 측면에서 성능에 확실히 영향을 미칩니다. 한 서버 내에 마이크로 서비스를위한 서비스 체인 애플리케이션이 있다고 가정해 보겠습니다. DPDK가 솔루션입니다.

반면에 응용 프로그램이 다른 서버에 상주하는 서비스 체인 서비스가있는 경우 SR-IOV를 선택해야합니다. 그러나 SR-IOV 기반 설계를 더욱 최적화하기 위해 항상 SR-IOV를 VNF의 DPDK (위에 설명 된 OVS의 경우 DPDK가 아님)와 결합 할 수 있다는 것을 잊지 마십시오.

---

[원문] - https://telcocloudbridge.com/blog/dpdk-vs-sr-iov-for-nfv-why-a-wrong-decision-can-impact-performance/?fbclid=IwAR22Uiqvyg4Dp3Fxz92FG80L__Iw-2tRVSGRH03-PPFHCoTFHbNovz1rJa0 

DPDK vs SR-IOV for NFV? - Why a wrong decision can impact performance! -