일반적으로 서버 가상화 환경에 올라가는 어플리케이션들의 종류를 보면 대부분 웹이나 게임 서버 등의 TCP 소켓 기반의 연결 혹은 연결 지향형 어플리케이션들 위주로 올라가고, 빠른 반응 속도(network latency)를 위해 디자인 된 UDP 프로토콜 기반의 중계 어플리케이션들은 (ex> Dedicated 서버 혹은 Relay 서버) 애초에 가상화 대상이 아니거나 물리 기반의 서버에서만 운용을 하던 것이 대부분이었습니다. 이유를 살펴보면 TCP 프레임에 비해 상대적으로 많은 수의 패킷을 처리하고 UDP 프레임을 인코딩/디코딩 하는 과정에서 많은 CPU의 오버헤드를 발생할 수 있어서 CPU 의존도가 높아서 그렇다고 합니다만, Hyper-V 기반의 VM에서 이와 같은 '데디 혹은 릴레이' 서버의 적용을 위한 트러블 슈팅 과정이있어 구성가이드 및 트러블 슈팅기를 정리해 둡니다.
실제로 Hyper-V VM 으로 구동 되는 VM 에서 문제가 발생하기 시작한 시점은 Hyper-V의 NIC를 이용한 Virtual Switch의 업링크 인터페이스(NIC)에서 수신 150,000 (150k), 송신 300,000 (300k), 총 450,000 정도의 PPS 에서 네트워크의 지연 현상이 발생하기 시작 했습니다. Hyper-V 호스트의 유저 모드에서 특정 코어의 CPU 사용률이 100%를 기록하고 있었고, 이 CPU peak의 원인을 네트워크로 지목하게 된 이유에는 'Hyper-V Virtual Switch Processor' 의 성능 모니터를 봤을 때, Root VP (Virtual Processor) 0번 에서 물리 NIC에 실리는 전체 패킷과 동일한 양의 패킷을 처리하고 있었기 때문입니다.
이러한 가상화 환경에서 VM의 네트워크 성능을 끌어올리는 기술은 VM(d)Q 혹은 Single Root-IO Virtualization 등을 제안할 수 있습니다만, 실제로 현업 환경에 적용해 본 케이스는 없었기 때문에 테스트를 하면서도 잘 될까? (효과가 있을까?) 잘 하고 있나 하는 등의 걱정이 있었던 것은 사실입니다. VMQ에 대한 내용이나 장 단점에 대해서는 다른 글에서 기술하도록 하고, 이 글에서는 SR-IOV 에 대한 기술만 하도록 하겠습니다. SR-IOV에 대한 개념, 원리등은 아래 references 링크를 통해 확인하시면 많은 도움이 될 것 같습니다. 문서를 통해 Microsoft 에서 가이드하는 SR-IOV에 대한 성능을 향상에 대한 부분은 낮은 CPU 사용량 (최대 50%), 낮은 네트워크 레이턴시 (최대 50%), 더 높은 네트워크 대역폭 (최대 30%)로 가이드 하고 있습니다. (서비스/서버마다 어느 정도의 네트워크가 사용 될 지 알 수 없기 때문에 굉장히 보수적으로 잡은 가이드 이긴 합니다)
HP에서 제공하는 SR-IOV Implement 문서를 발췌 해보면,
일차적으로 서버의 BIOS 설정에서 SR-IOV의 항목을 Enable 해주어야 합니다. SR-IOV 기술 자체가 PCI-SIG를 통해 제정 되긴 했지만, 기본적으로는 인텔의 VT-D를 이용한 기술입니다. 이는 물리 서버의 PCIe 레인에 설치 된 하드웨어 (여기서 정확히는 pNIC)를 VM레벨에서 물리(PCI-Passthrough) 혹은 가상의 디바이스(SR-IOV/VF)로 인식 시켜주는 기술이므로 하드웨어 설정의 도움을 받아야 합니다 (실제로 SR-IOV가 Passthrough로 작동하는 것은 아닙니다) 이 설정을 함으로써 포트 별이 아닌 전체 네트워크 카드에 대해 SR-IOV 옵션이 적용 되므로, 이 옵션을 사용하기 전에 SR-IOV 를 사용하지 않은 상태로 vSwitch를 만들어 관리 IP를 등록하여 사용하였다면, SR-IOV 가 적용 됨으로써 원격에서 접근이 불가능 상태가 발생할 수 있으므로 콘솔에서 메인터넌스 작업을 하거나, 콘솔의 도움을 받는 것을 추천합니다.
BIOS에서 SR-IOV 를 활성화 하였다면, Hyper-V 관리자의 가상 스위치 관리자에서 'SR-IOV 사용' 을 확인 하여 가상 스위치를 새로 만들어 줍니다. 물리 서버에서 인식하는 pNIC의 디바이스 정보가 바뀌었기 때문에, 기존에 사용하던 가상 스위치는 사용할 수 없을 것으로 보입니다. 다만, 이렇게 기존의 가상 스위치를 삭제하고 생성하는 과정에서 VM에 할당 된 vNIC는 반드시 vNIC를 삭제하지 않고, 할당 해제 후, 가상 스위치를 삭제 하도록 합니다. (이유는 다음 트러블슈팅 글에서 다시 기술) 운영 중인 서버가 아닌 신규 셋업이라면 무시하고 바로 진행 하여도 됩니다.
각 VM 의 설정 정보에서 vNIC 의 네트워크 정보 '하드웨어 가속' 에서 SR-IOV 를 사용으로 바꿔주고 확인을 누르면, 아래의 VM 상태 창, 네트워킹 탭에서 SR-IOV 가 활성화 된 항목을 확인할 수 있습니다. SR-IOV 의 적용 유/무는 온라인 상태에서 즉시 적용 가능하며, SR-IOV 를 지원하지 않는 타 물리 서버와의 VM 이동 (migration) 호환성도 갖고 있습니다. (EVC 등의 프로세서 호환성과는 무관)
SR-IOV는 pNIC의 프로세서를 사용하는 하드웨어 장치이기 때문에, pNIC의 스펙에 대한 의존성을 갖고 있습니다. 이게 무슨 말인가하면 기가비트 기반의 Intel i350 에서는 6개의 VF (Virtual Function)을 제공하고 있는데, 이를 해석하면 1개의 pNIC 포트에는 최대 6개의 VM 밖에 할당하지 못한다는 이야기 입니다. 스펙으로 확인한 대부분의 10GbE pNIC 에서는 62개 대역의 VF를 갖고 있으나, 기가빗 기반의 이더넷 pNIC 들은 이러한 스펙상의 한계를 갖고 있습니다. (참고로 인텔 NIC 기가비트 모델에서는 GT/MT/PT/GT/VT/ET 등의 다양한 모델이 있지만, SR-IOV를 지원하는 기가빗 컨트롤러는 ET 이후 세대에서만 지원 합니다. ET 듀얼 포트 NIC의 중고가가 PT/VT 보다 두 배이상 높은 이유이기도 하고요. emulex/broadcom 등의 최근 나오는 대부분의 10GbE는 SR-IOV를 지원 합니다)
pNIC 의 포트를 더 할당하여 두 번째 SR-IOV 가상 스위치를 만들면 (당연히도 TOR 스위치에 케이블링/연결 필요) 한 대의 VMHOST 에서 6개 VF 스펙 이상의 VM 을 구동할 수 있습니다만, SCVMM 에서 VM을 자동으로 할당하고자 할 때도 정해진 가상 스위치의 이름이 아니거나, 실제 트래픽이 heavy 하는 실리는 공인/사설망 등의 분리 여부 (확인 필요) 등의 관리의 복잡성이 증가할 수 있습니다.
VM 내부에서 보면 Hyper-V 네트워크 어댑터외에 pNIC 의 장치 이름인 i350 Virtual Funtion이 확인 됩니다. 이는 VM 레벨에서는 TCP/IP - Hyper-V 네트워크 어댑터 - VF Miniport Driver - VF NIC (i350) 등의 연결 절차를 거치게 되고, SR-IOV 가 적용 되지 않은 일반적인 VM 에서는 TCP/IP - Hyper-V 네트워크 어댑터 - VMBus - Virtual Switch 등의 연결 절차를 이용하게 됩니다.
Child 1의 VM 이 SR-IOV를 타지 않는 구조이고, Child 2가 SR-IOV가 적용 된 연결 구성도 입니다. 결과적으로는 Child 1의 구성으로는 VMBus를 통한 가상 스위치 쪽에 트래픽/패킷이 몰리면 호스트 유저 모드의 특정 CPU를 사용할 가능성이 높아져서 결국은 전체 VM 네트워크의 지연 현상으로 이어지게 되었습니다. 이러한 구조의 가상 네트워크를 pNIC 기반의 하드웨어 장치로, VM 레벨에서 p/VF NIC 을 할당 하여 가상 스위치의 서비스 프로세서의 CPU 사용율을 덜어주는 기술이 바로 이 SR-IOV 입니다.
|
PS C:\Windows\system32> get-vmhost | fl
PS C:\Windows\system32> get-netadaptersriovvf Name FunctionID VPortID MacAddress VmID VmFriendlyName |
SR-IOV를 통해 실행 되는 VM을 구현하기 위한 필요 사항
1. SR-IOV / IOMMU 를 지원하는 시스템보드
2. VT-D / SLAT 를 지원하는 CPU
3. SR-IOV를 지원하는 NIC
4. Windows Server 2012 or VMWare Hypervisor
(Windows 8의 Hyper-V 는 SR-IOV를 지원하지 않습니다. VMQ는 지원)
5. 기타 : 네트워크 NIC Teaming 구성일 경우에는 SR-IOV를 지원하지 않음
