The Design and Implementation of Open vSwitch 4

 해당 포스트는 NSDI '15 https://www.usenix.org/system/files/conference/nsdi15/nsdi15-paper-pfaff.pdf 를 번역해서 정리한 포스트입니다.

 

7. 평가

7.1 성능

 저자는 Open vSwitch의 성능을 Rakespace가 운영하는 multi-tenant 상업용 데이터센터의 대규모 하이퍼바이저 위에서 24시간 측정하였다. 1,000개의 하이퍼바이저에서 10분 단위로 측정하여 통계를 산출하였다.

 

Cache Size

 활성화된 megaflow의 개수는 실제로 Open vSwitch의 cache size를 어떻게 조절해야 할 지 가늠자가 된다. Figure 4는 실험 관측 시간동안 최소, 중앙값, 최대 megaflow 개수를 CDF로 나타낸다. 해당 그래프는 적은 megaflow cache도 실제에서는 충분함을 보여준다. 하이퍼바이저의 절반은 107개 혹은 그 이하의 flow를 중앙값으로 갖고 있었으며, maximum 결과에서 백분위 99%는 7,033 개의 flow를 갖고 있었다. 즉, 하이퍼바이저 환경에서의 Open vSwitch userspace는 충분한 kernel cache를 갖고 있음을 의미한다. (최신 Open vSwitch mainstream version의 maximum kernel flow는 200,000개로 세팅되어 있다.)

 

Cache hit rate

 Figure 5는 caching의 효과를 보여준다. 실선은 모든 환경에서 10분 단위로 cache hit rate를 측정한 결과를 나타낸다. 전체 cache hit rate는 97.7%였다.

 점선(.......)은 packet forward가 적었던 시기 (네트워크가 한가한 환경, 하위 25%)의 기간에 대하여 결과이다.  이 때는 cache의 효과가 상대적으로 적어 74.4%의 hit rate를 보였다. 직관적으로, cache를 할 것이 적은 상황에서 cache는 상대적으로 그 효과가 덜 할 것이다.

 반대로 cache 할 내용이 많을 때 그 효과가 가장 많을 것이며, 네트워크 작업량이 상위 25%에 해당하는 시기의 hit rate는 98.0%를 보였다.

 

 대부분의 하이퍼바이저는 상당한 작업량의 네트워크 상황을 겪지는 않는다. Figure 6에서 보이듯, 99%의 하이퍼바이저가 초당 79,000개의 packet 혹은 그 이하의 작업량을 갖고 있었고, 이들은 대부분 cache hit였다. 그리고 cache miss로 인해 userspace로 부터 초당 1,500개의 flow setup이 발생했다.

 

CPU 사용량

 실험에서 Open vSwitch kernel load만을 정확하게 측정할 수 없어서 Open vSwitch가 userspace에서 사용하는 CPU에 집중하였다. Section 7.2에서 다루겠지만, megaflow의 CPU 사용량은 Linux bridging과 동일하므로 우려사항이 아니다. 대신 Open vSwitch에서 userspace의 부하는 Figure 7이 보여주듯 대부분 kernel의 cache miss때문에 발생한다. (multi-thread이므로 CPU 사용량이 100%를 초과할 수 있음) 저자는 80%의 하이퍼바이저에서 ovs-vswitchd가 평균적으로 5% 또는 그 이하의 CPU 사용량을 가짐을 확인했다. 50% 이상의 하이퍼바이저는 2%의 CPU 혹은 그 이하를 사용했다.

 

Outlier

 Figure 7의 우측 상단에서는 많은 양의 cache miss로 인해 userspace의 CPU 사용량이 많아진 하이퍼바이저를 볼 수 있다. 여기서 24시간 동안 CPU 사용량이 100%를 넘긴6개의 극단적인 케이스를 일일이 조사하였다. 그 결과, 이들의 모든 하이퍼바이저에서는 prefix tracking의 구현에 있어서 알려지지 않은 버그가 존재했다. 해당 버그는 Open vSwitch 2.3에서 수정한 것으로 알고 있지만, data center에 배포하지 않아서 발생한 일이다.

 

 

7.2 Caching Microbenchmarks

 저자들은 caching-aware packet 분류 알고리즘의 이익을 잘 보여줄 수 있는 간단한 flow table을 구성하여 microbenchmark 실험을 진행했다. Flow table 구조는 다음과 같고, actions는 중요하지 않으므로 생략했다. 하위로 갈수록 우선순위가 낮다.

Simple Microbenchmark Flow Table

 Caching-aware packet 분류 알고리즘이 없다면, TCP packet은 테이블의 (3)에 의해서 megaflow는 항상 TCP의 source와 destination port 번호를 포함하여 생성될 것이다. 앞선 section 5의 최적화를 각각 적용하면 다음과 같다:

 > Section 5.2의 우선순위 정렬이 적용된다면, (2)에 먼저 매칭되는 packet들은 (3)을 건너 뛸 것이다.

 > Section 5.3의 Staged lookup이 적용된다면, 9.1.1.1로 향하지 않는 IP packet들은 tcp_src와 tcp_dst를 검사하지 않는다. L3이 매칭되지 않으므로 L4를 검사하지 않는 것. 

 > Section 5.2의 prefix tracking이 적용된다면, megaflow가 생성될 때 IP destination에서 일부 bits를 무시할 수 있게 한다. (3)은 IP 주소의 32bit 매치를 요구하는데도 말이다.

 

 Cache 성능과 최적화 효과

 실험 환경: 8 cores, 2.0 GHz Xeon 프로세서 2개, 인텔 10 Gb NICs 2개를 가진 Linux server에서 진행, 많은 connection을 생성하기 위하여 "TCP connection을 생성하고 1 byte 교환 후 close"하는 과정을 반복하는 Netperf의 TCP_CRR test를 실행하였다. 결과는 transactions per second (tps)로 표현된다. Netperf는 한 번에 1개의 연결을 수립하므로, 400개의 Netperf session을 동시에 실행시켜 합산하였다.

 

Megaflow의 효과

 > Baseline을 측정하기 위해, ovs-vswitchd에서 megaflow caching을 비활성화 하였다. 즉, 오로지 datapath에 microflow만 존재한다. 해당 상황에서는 100만개의 kernel flow entry와 함께 37 ktps의 결과를 보였으며, 거의 1개의 core를 전부 사용하였다.

 > No optimizations는 megaflow를 활성화하되 section 5의 각종 classifier 최적화를 적용하지 않은 결과이다. 

 > Priority sorting only, Prefix tracking only, Staged lookup only는 각각 하나씩 section 5의 최적화를 적용해본 결과이다. 각각의 최적화는 kernel의 flow개수를 줄였다. 다르게 말해 flow를 setup하기 위해서는 kernel과 userspace간 정보 교환을 요구하고 상당한 CPU를 사용하는데, 이를 상당히 절약한 것이다. Kernel flow의 개수가 줄어들수록 tuple (Mask)수는 증가하여 kernel 내에서 packet 분류 비용이 증가하지만, userspace와의 정보 교환이 상당히 절약되어 CPU 사용량은 전체적으로 이득인 결과를 보였다.

 

Microflow의 효과

 Microflow 성능의 효과를 분석하기 위하여 Megaflow는 다시 활성화하고 Microflow만 비활성화 하였다. 이를 기존과 비교했을 때, 120 ktps에서 92ktps로 줄어든 것을 확인할 수 있다. 3열과 4열을 비교하면 classifier (section 5)의 최적화를 비활성화 했을 때, microflow의 사용 여부는 별 차이가 없음을 볼 수 있다. 이는 최적화 비활성화로 인해 userspace와의 정보 교환이 많아지면서 microflow 자체가 무용지물이 되기 때문이다.

 

In-kernel Switch와의 비교

 Linux kernel 내부에 모든 기능을 구현한 ethernet switch인 Linux bridge와 비교한 결과, 단순한 설정에서는 거의 동일한 성능(18.8 Gbps throughput)과 TCP_CRR 결과(688 ktps for Linux bridge, 696 ktps for OvS)를 보였다. 단, OvS가 161%, Linux bridge가 48%로 OvS가 더 많은 CPU를 사용했다. 하지만, OvS가 flow를 하나 추가했을 때 OvS의 성능과 CPU 사용량은 기존과 비슷했지만, Linux bridge는 512 ktps로 성능이 감소했고 CPU 사용량은 26배인 1,279%로 급증했다. 이는 built-in kernel 함수들이 per-packet overhead를 갖고 있는 반면, OvS의 overhead는 per-megaflow로 고정되어 있다는 점에서 차이가 발생했다. 추가된 flow는 STP BPDU packet을 drop하는 하나의 flow였지만, 다른 비슷한 기능들에도 유사한 양상을 보이리라고 기대한다.

 

8. 계획된 기능 및 관련 연구

 (2015년 당시의 내용이다보니 현재에는 많이 구현된 듯 합니다. 8.1~8.3 까지 각각의 subsection에 대해 내용과 관련된 크를 걸어두었습니다.)

8.1. Stateful Packet 처리

 OpenFlow는 stateful packet 처리를 지원하지 않아서 per-connection 혹은 per-packet forwarding status의 경우에는 컨트롤러가 가담해야 한다. 이를 위한 목적으로 Open vSwitch는 하이퍼바이저에서 컨트롤러를 구동할 수 있도록 지원한다. 이 local 컨트롤러는 임의의 프로그램이기때문에 어떠한 양의 state라도 처리할 수 있다. 다만, 이 방식은 성능에 치명적이다. 수신된 packet이 kernel에서 userspace의 ovs daemon으로 올라가야 하고, local socket (via kernel)을 통해 다시 다른 프로세스 (local 컨트롤러) 에게 전달되어야 하기 때문. (packet ---> kernel datapath ---> userspace ovs-vswitchd ---> kernel IPC ----> local controller)

 

 그래서 성능이 중요한 상황에서의 stateful packet 처리를 위하여 Open vSwitch는 kernel networking 기능을 이용하기도 한다. 예를 들어, IP 터널링을 위해서는 stateful IP reassembly 기능을 요구한다.

 또 다른 사례로, L2/L3 처리 이후에는 방화벽 보안 정책과 같은 L4 connection tracking의 기능을 요구한다. 하지만 OpenFlow는 정적인 ACL 구현이 가능하지만 stateful ACL은 지원하지 않는다. 이를 위해 OpenFlow가 kernel module을 이용해 connection state (new, established, related)를 확인 및 기록할 수 있도록 action에 기능을 추가하는 작업을 진행중이다. 이 "connection tracking"은 많은 방화벽 어플라이언스에 적용된 기술이기도 하다. 

 

보충 내용:

https://docs.openvswitch.org/en/latest/tutorials/ovs-conntrack/

OVS Conntrack Tutorial — Open vSwitch 3.2.90 documentation

 

8.2 Userspace Networking

 Userspace networking을 이용해 성능을 향상시키는 방법은 NFV (Network Function Virtualization) 등의 사례로 인해 시기 적절한 주제이다. 이 구조에서는 packet이 최소한의 하이퍼바이저 간섭과 함께 NIC에서 곧바로 VM으로 전송된다. 현재 DPDK와 netmep 등의 프레임워크를 Open vSwitch가 지원하도록 작업이 진행중이다. 초기 테스트에서는 Open vSwitch userspace caching 구조가 기존 kernel flow cache의 이점을 유사하게 가져갈 수 있는 것으로 확인했다.

 

보충 내용:

https://docs.openvswitch.org/en/latest/intro/install/dpdk/

Open vSwitch with DPDK — Open vSwitch 3.2.90 documentation

 

 

8.3 Hardware Offloading

 TCP checksum offload와 segmentation offload와 같이 공통적이면서도 host의 CPU를 과도하게 사용하는 기능들을 NIC에 offloading하는 방향으로 트렌드가 흘러가고 있다. Open vSwitch도 지원되는 가상화 환경과 관련된 기능들을 포함하여 다양한 offload를 사용하고 있다. 

 Virtual switching을 전부 하드웨어에 offloading하는 것은 반복되고 있는 주제이다. 이는 성능을 향상시키지만 flexibility를 포기해야 한다. (간단하고 고정된 기능을 지닌 하드웨어 스위치는 소프트웨어 스위치의 기능 확장가능성을 포기하면 효과적으로 대체할 수 있다.) 이 시점 기준 저자들이 찾고 있는 가장 유망한 offloading 방식은 NIC에 kernel flow classification을 활성화하는 것이라고 한다. 몇몇 Intel NIC에서 Flow Director feature를 활용해 queue에다가 packet을 분류하는 방법이 유용하다는 것을 보여주고 있다. 이 기능을 강화하여, queue를 고르는 대신에 matching rule를 고르게 한다면 megaflow classification이 가능할 것이라고 예상한다. TCAM (Ternary Content Access Memory)의 크기가 적을지라도, 혹은 TCAM이 datapath가 관여하는 모든 field에 대해 기능을 지원하지 못하더라도, hash table 조회의 수를 줄임에 따라서 software classification을 가속할 수 있을 것이다.

 

보충 내용:

https://docs.nvidia.com/networking/display/mlnxenv23070512/ovs+offload+using+asap%C2%B2+direct 

OVS Offload Using ASAP² Direct - NVIDIA Docs

 

 

9. 결론

지금까지 오픈소스이며, 여러 플랫폼을 지원하는 OpenFlow virtual switch인 Open vSwitch의 디자인과 구현에 대하여 다루었다. Open vSwitch의 출발점은 단순했지만, multi-tenant 데이터센터의 작업에서 요구하는 성능을 충족하기 위해 최적화를 거듭하여 디자인이 복잡해졌다. 현재 주어진 운영 환경 하에서는 더이상 이 디자인에 대한 변화가 필요 없을 것이라 예상하며, 시간이 지날수록 기존 전통방식의 네트워크 어플라이언스와 차이점이 두드러질 것이라고 기대한다.