호스트 안의 가상 스위치 플랫폼 (VFP, NSDI 2017)

출처

참고 이 페이지는 원문 번역이 아니라 한국어 해설이에요. 정확한 표현과 수치는 원문을 확인하세요.

한눈에

• Azure 는 VM 의 네트워크 정책(가상 네트워크 터널링, NAT, 상태 있는 ACL, QoS)을 스위치가 아니라 각 호스트의 가상 스위치에서 처리하는 "호스트 SDN" 방식을 씁니다.
• VFP(Virtual Filtering Platform)는 Hyper-V 가상 스위치 확장으로, 여러 독립 컨트롤러가 각자 자기 계층(layer)의 매치 액션 테이블만 프로그래밍하게 합니다.
• 첫 패킷만 모든 계층을 거쳐 "헤더 변환(Header Transposition)"을 계산하고, 결과를 통합 흐름 테이블(UFT)에 캐시해 나머지 패킷은 한 번의 조회로 처리합니다.
• 2012년 이후 21번의 주요 릴리스를 거쳐 100만 대 이상의 호스트에서 쓰였고, 이 흐름 캐시 구조가 다음 논문의 하드웨어 오프로드로 이어졌습니다.

왜 나왔나

퍼블릭 클라우드의 VM 은 고객이 정한 주소 공간의 가상 네트워크에 붙고, 공인 IP 와 부하 분산기를 거쳐 들어오며, 보안 그룹 규칙으로 걸러져야 합니다. Azure 는 VL2 와 Ananta 같은 이전 연구에서 이런 기능을 물리 스위치 대신 호스트에서 처리하는 방향을 택했습니다. 문제는 이 정책을 프로그래밍하는 컨트롤러가 여럿이라는 점입니다. 가상 네트워크 컨트롤러, 부하 분산 컨트롤러, 방화벽 컨트롤러가 서로 독립적으로 규칙을 바꾸는데, 하나의 흐름 테이블에 모두 섞이면 서로 충돌하고 조정이 어렵습니다.

2장은 설계 목표를 처음 목표와 운영 경험에서 얻은 목표로 나눕니다. 처음 목표는 여러 독립 컨트롤러 지원, 연결(커넥션) 단위 상태를 다루는 매치 액션 테이블, 컨트롤러가 정의하는 정책이었습니다. 운영 경험에서는 재부팅 없는 업데이트 같은 서비스 용이성, 캐시를 통한 높은 패킷 처리율, NIC 하드웨어 오프로드가 더해졌습니다. 반대로 이식성, 특정 와이어 프로토콜 내장, 규칙 충돌 자동 검출은 목표에서 뺐습니다.

3장은 Open vSwitch(OVS)와 비교합니다. OVS 도 OpenFlow 기반 매치 액션 모델이지만, 여러 컨트롤러가 계층을 나눠 쓰는 모델과 상태 있는 규칙을 기본 요소로 두지 않았고, 느린 경로로 빠질 때의 비용이 크다는 점을 차이로 듭니다.

핵심 아이디어

포트와 계층

5장의 프로그래밍 모델에서 가장 중요한 개념은 계층입니다. VM 의 가상 NIC 하나가 포트 하나이고, 포트마다 계층들이 쌓입니다. 그림 4의 예에서는 아래에서부터 다음 순서입니다.

들어오는 패킷과 나가는 패킷은 계층을 서로 반대 순서로 지납니다. 그래서 각 계층은 자기 위치에서 보이는 주소 공간만 보고 규칙을 쓰면 되고, 다른 컨트롤러와 조율할 필요가 없습니다. 계층 안에는 규칙 묶음인 그룹이 있고, 규칙은 조건과 액션으로 이루어집니다. 상태 있는 규칙은 나가는 연결을 허용하면 그 응답도 자동으로 허용하는 식으로 흐름을 짝지어 기억합니다.

헤더 변환과 통합 흐름 테이블

6장의 패킷 처리기가 성능의 핵심입니다. VFP 는 패킷의 헤더들을 파싱해 통합 FlowID(UFID)라는 키를 만듭니다. 각 계층의 규칙이 헤더에 하는 일은 헤더 변환(HT)으로 표현되는데, 헤더 단위 동작은 Push(헤더 추가), Modify(필드 변경), Pop(헤더 제거), Ignore(통과) 네 가지입니다(표 2). 캡슐화, 캡슐 해제, NAT 가 모두 이 조합으로 표현됩니다(표 3).

새 흐름의 첫 패킷은 느린 경로로 갑니다. 변환 엔진이 계층을 하나씩 지나며 그 계층의 규칙으로 분류하고, 매칭된 규칙의 변환을 차례로 합성해 하나의 HT 를 만듭니다. 이 결과를 UFID 를 키로 통합 흐름 테이블(UFT)에 저장합니다. 이후 같은 흐름의 패킷은 빠른 경로에서 UFT 를 한 번 조회해 합성된 HT 를 바로 적용합니다. 계층과 규칙이 몇 개든 빠른 경로 비용은 같습니다.

정책이 바뀌면 포트의 세대 번호를 올리고, 오래된 세대의 흐름은 다음에 패킷이 올 때 다시 계산해 바뀐 경우에만 갱신합니다(6.3절). TCP 상태도 추적해 연결이 끝나면 흐름을 정리합니다. 규칙 분류에는 트라이, 구간 트리, 해시 테이블을 조건 종류에 맞게 씁니다.

운영 기능

8장은 운영 측면입니다. VM 을 멈추지 않고 VFP 를 업데이트하는 재부팅 없는 업데이트는 보통 1초 미만에 끝나며, 흐름 상태를 저장하고 복원해 VM 라이브 마이그레이션에도 연결을 유지합니다. 300개가 넘는 성능 카운터와 진단 도구도 갖췄습니다.

하드웨어 오프로드

9장은 NIC 의 도움을 받는 방법입니다. 캡슐화 패킷에 대한 체크섬, 분할, 수신 분산 같은 상태 없는 오프로드로 40Gbps 라인 레이트를 냈고, 더 나아가 UFT 의 정확 일치 흐름을 NIC 하드웨어로 내려 SR-IOV 로 VM 이 NIC 를 직접 쓰게 하면 25Gbps 이상과 가상 네트워크 안 종단 간 TCP 지연 25마이크로초 미만을 얻었다고 적습니다. 이 방향이 다음 논문인 Azure 가속 네트워킹입니다.

실험과 결과

• 성능(그림 9): 2.9GHz Xeon Sandy Bridge 에서 TCP SYN 부하를 걸었을 때, 분류기가 선형 탐색보다 10배에서 100배 빨랐습니다. 200개 규칙의 계층 하나만 있어도 UFT 캐시가 효과가 있었고 계층이 늘수록 효과가 커졌습니다. 잠금이 있던 VFPv1 은 CPU 8개로 늘려도 처리량이 늘지 않았지만 UFT 는 잘 확장되었습니다. PacketDirect 를 쓰면 초당 수신 패킷 수가 60% 넘게 늘었습니다.
• 운영 규모(10장): 한 배포에 계층 10~20개, 계층당 그룹 수백 개, 그룹당 규칙 최대 약 5만 개, 포트당 동시 TCP 연결 최대 50만 개를 처리합니다. 그림 8은 VM 당 활성 흐름 수, 새 연결 속도, 상태 저장 복원 시간의 분포를 보여 줍니다.
• 교훈(10.2절): L4 흐름 캐시만으로 충분했고 다단계 캐시는 필요 없었다, 상태 있는 연결은 처음부터 기본 요소여야 한다, 계층 분리는 강제되어야 한다(GOTO 는 해롭다), 캡슐화까지 모두 액션으로 모델링한 것이 단일 조회와 하드웨어 오프로드를 가능하게 했다, 상용 NIC 는 SDN 에 이상적이지 않았다 같은 내용입니다.

지금 Azure 에서는

VFP 는 Azure 가상 네트워크(VNet), 네트워크 보안 그룹(NSG), Azure Load Balancer 의 NAT 같은 기능이 각 호스트에서 실제로 적용되는 데이터 평면입니다. 계층 구조 덕분에 VNet, 부하 분산, 보안 규칙을 서로 다른 컨트롤러가 독립적으로 관리할 수 있습니다. VFP 의 흐름 캐시는 이후 SmartNIC 로 오프로드되어 가속 네트워킹(Accelerated Networking)이 되었습니다. Windows Server 의 SDN 스택도 같은 VFP 를 Hyper-V 가상 스위치 확장으로 사용합니다.

함께 읽기

• VNet, 서브넷, NSG: 이 사이트의 기능 문서
• Azure 가속 네트워킹: VFP 의 흐름 테이블을 FPGA SmartNIC 로 내린 후속 논문
• USENIX ;login: 2017 가을호 저자 기고
• Microsoft Research 논문 페이지