본문
SR-IOV(Single Root I/O Virtualization)에 대하여 #1. 소개
SR-IOV(Single Root I/O Virtualization)에 관한 자료는 많다. Windows Server 2012에서부터 공식적으로 지원되기 때문이다. SR-IOV는 다수의 가상머신이 하나의 I/O PCI Express 하드웨어 인터페이스를 공유할 수 있도록 하며, 이는 PCI-SIG(Peripheral Component Interconnect Special Interest Group)에서 공식적으로 표준화가 진행되고 있는 기술이다.
SR-IOV를 사용하면 가상머신 입장에서는 마치 PCI 장치가 직접 연결된것같은 효과를 가지며, 따라서 가상화로인한 성능 하락을 방지할 수 있다. 대개 가상머신에서 호스트 장치를 사용하기 위해서는 가상화환경을 지원하는 드라이버를(emulated/paravirtualized drivers) 사용해야 하지만, SR-IOV는 장치를 직접 엑세스하는 만큼 기존 드라이버를 사용할 수 있다. 대신 역으로, 장치 드라이버가 SR-IOV를 고려해서 개발되어야 하고 하드웨어도 이를 뒷받침해야 하기 때문에 일부 장치에서만 이 기능을 사용할 수 있다.
[그림 1] Child 1의 VM 이 SR-IOV를 타지 않는 구조이고, Child 2가 SR-IOV가 적용 된 연결 구성도 [1]
SR-IOV를 설명하기 위하여 PF(Physical Function)과 VF(Virtual Function)을 이해할 필요가 있다. PF는 물리적인 PCI카드를 나타낸다. SR-IOV를 지원하는 PF는 다수의 VF, 즉, 다수의 가상 PCI 카드를 생성할 수 있다. 따라서 가상머신에서 사용하는 장치는 결국 PF처럼 보이는 VF인 것이다. 다수의 VF가 하나의 PF상에서 동작하기 위해 내부적으로 큐를 사용하여 요청을 제어하는데, 만약 하나의 큐를 사용하는 경우 SR(Single Root), 다수의 큐를 사용할 경우는 MR-IOV(Multi Root IOV)라고 한다.
일차적으로 서버의 BIOS 설정에서 SR-IOV의 항목을 Enable 해주어야 합니다. SR-IOV 기술 자체가 PCI-SIG를 통해 제정 되긴 했지만, 기본적으로는 인텔의 VT-D를 이용한 기술입니다. 이는 물리 서버의 PCIe 레인에 설치 된 하드웨어 (여기서 정확히는 pNIC)를 VM레벨에서 물리(PCI-Passthrough) 혹은 가상의 디바이스(SR-IOV/VF)로 인식 시켜주는 기술이므로 하드웨어 설정의 도움을 받아야 합니다 (실제로 SR-IOV가 Passthrough로 작동하는 것은 아닙니다) [1]
Intel과 AMD 모두 자사의 새로운 프로세서 아키텍처에서 장치 passthrough에 대한 지원과 하이퍼바이저를 지원하는 새로운 명령어를 제공한다. Intel에서는 이 옵션을 VT-d(Virtualization Technology for Directed I/O))라고 부르고 AMD에서는 IOMMU(I/O Memory Management Unit)라고 부른다. 두 경우 모두 새 CPU가 PCI의 실제 주소를 게스트의 가상 주소에 맵핑한다. 이 맵핑이 발생하면 하드웨어가 액세스를 보호하게 되며, 결과적으로 게스트 운영 체제에서는 가상화되지 않은 시스템인 것처럼 장치를 사용할 수 있다. 게스트를 실제 메모리에 맵핑하는 기능 외에도 다른 게스트(또는 하이퍼바이저)의 액세스를 차단하는 분리 기능이 제공된다. [2] => DMA
이러한 장점이 있는 만큼, 아래에 설명된 대로 단점, 제약사항도 존재한다. 특히 NFV에서 구현해야할 동작으로 Live Migration이 있는데, 만약 가상머신에서 VF를 사용중인 경우에는 이 연결을 끊고 다시 맺어야 하는 문제가 발생한다. 물론 이를 우회하는 MacVTap등의 방법과 상용화된 솔루션이 있긴 하지만 보편적인 방법은 아니다.
The upside of all this DMA is also its downside, in that anything and everything between the interface and the VM is now bypassed. Even though the Juno release of OpenStack extended Neutron and Nova to support SR-IOV for network devices, thereby reducing the chance of provisioning errors and opening this data plane acceleration option up to the NFV management and orchestration (MANO) layer, the DMA techniques it employs still ultimately results in traffic bypassing the Hypervisor vSwitch. This raises questions about SR-IOV’s ability to support the portability, flexibility, QoS, complex traffic steering (including network service headers for service function chaining, if the VNFs are middleboxes) and the expected cloud network virtualization demands of NFV.[4]
SR-IOV는 pNIC의 프로세서를 사용하는 하드웨어 장치이기 때문에, pNIC의 스펙에 대한 의존성을 갖고 있습니다. 이게 무슨 말인가하면 기가비트 기반의 Intel i350 에서는 6개의 VF (Virtual Function)을 제공하고 있는데, 이를 해석하면 1개의 pNIC 포트에는 최대 6개의 VM 밖에 할당하지 못한다는 이야기 입니다. 스펙으로 확인한 대부분의 10GbE pNIC 에서는 62개 대역의 VF를 갖고 있으나, 기가빗 기반의 이더넷 pNIC 들은 이러한 스펙상의 한계를 갖고 있습니다. [1]
[그림 2] Bare Metal, SR-IOV, OVS-DPDK에 대한 성능비교. 높을수록 좋다.[4]
[그림 1]에 나와있는 각각의 요소들에 대한 자세한 설명은 [3]에서 확인할 수 있다. 이번 글은 인용이 많았다. 좋은 글들이 이미 많이 나와있기 때문이다. 대신 이 글은 그 글들에서 핵심만 쏙 뽑고 훌륭한 Reference만 기록하는 목적으로 작성되었다. 다음으로는 PCI Passthrough, VMDq, VM-FEX, 그리고 VM Mobility에 대해 다룰까 한다.
[2] http://jowon.blogspot.kr/2010/01/linux-pci-passthrough.html
[3] https://msdn.microsoft.com/en-us/library/windows/hardware/hh440238%28v=vs.85%29.aspx[4] http://www.metaswitch.com/the-switch/accelerating-the-nfv-data-plane
댓글