SR-IOV 적용 가이드를 기반으로 다른 플랫폼에서 테스트를 완료 했고, 실제 서비스 HOST/VM에 SR-IOV 의 할당을 받도록 적용 했지만, 안타깝게도 CPU 사용률은 떨어지지 않았습니다. i350 기가비트의 VF 스펙이 최대 6개 였고 서비스 VM이 6개 이상 올라갔기 때문에, 트래픽이 가중되는 공인(Public)망 쪽 pNIC 및 SR-IOV 가상 스위치를 2개로 나누어 두었는데, 실제 적용 후 모니터링을 해보니 각 SR-IOV 스위치 1/2에 실리는 트래픽이 전혀 다른 상태을 보여줬었습니다.
vSwitch_Public_SR-IOV_1 의 가상 스위치와, HP 366FLR_6 번이 논리적으로 맵핑 된 한 세트이고, vSwitch_Public_SR-IOV_2 와 HP 366FLR_5 번이 나머지 다른 한 세트입니다. 서버를 SR-IOV 1/2 로 각각 50%씩 나뉘어 할당을 했는데요. 실제 SR-IOV1에 할당 된 VM 에서 SR-IOV 활설 상태의 메시지를 확인 했지만, 실제로는 SR-IOV 의 VF/i350 로 통신을 하는 것이 아니고, Hyper-V 호스트 입장에서는 VMBUS를 통한 기존의 가상 스위치로 네트워크 트래픽이 실리는 것이 확인 되었습니다.
이를 반대의 상황인 SR-IOV 가 정상적으로 구성 되었다고 보이는 VM의 내부에서 살펴 보면, 일반적인 SR-IOV 구성으로는 TCP/IP -> Hyper-V 네트워크 어댑터 -> VF Miniport 드라이버 -> VF로 연결이 되기 때문에, 실제로 보이는 트래픽(sent, receive byte)이 가 i350 VF에는 보이지 않더라도 pps 항목의 카운터는 Hyper-V 네트워크 어댑터의 pps 수준과 같거나 비슷한 수치로 표기가 되는 것이 정상입니다. 다시 원래대로 돌아가서 SR-IOV가 적용되지 않은 VM 의 구성을 살펴봤었는데, 여기서는 i350 VF 에서 Hyper-V 네트워크 어댑터에 실리는 네트워크 트래픽을 처리하지 않고 바로 VMBUS/가상스위치로 통신을 하는 것으로 확인이 되었습니다. 각각 SR-IOV1 과 SR-IOV2 스위치에 할당 된 VM 의 차이가 무엇일까? 하고 고민 해봤는데...
SR-IOV 가상 스위치를 생성하기 위한 작업을 시행 했을 때, 담당 작업자가 기존의 VM에 할당 된 가상 스위치를 삭제하기 위해, 일부 VM 에서 vNIC 인터페이스를 삭제를 했던 것이 원인이었습니다. (가상 스위치가 vNIC에 할당(assign)되어있으면 가상 스위치가 삭제 되지 않습니다. 그래서 가상 스위치를 제거가 필요할 때는 vNIC 의 매핑을 '연결 되지 않음'으로 변경하여 할당을 모두 해제하여 작업 합니다)
나머지, 일부 VM은 '연결 되지 않음'의 상태로 할당을 해지하여 작업을 하였고, 문제가 되었던 초기의 일부 VM 은 vNIC (Hyper-V 네트워크 어댑터 #1/#2) 제거 / vNIC (Hyper-V 네트워크 어댑터 #3/#4) 추가의 과정을 거쳤기 때문에 Hyper-V 호스트 상에서는 실제로는 사용하지 않는 Hyper-V 네트워크 어댑터 #1/#2의 고스트 네트워크 어댑터로 SR-IOV 하트비트를 주며 SR-IOV 활성 상태라고 인지하고 있었지만, 실제로 VM 내부에서는 #3/#4번의 Hyper-V 네트워크 어댑터와 VMBus를 통해 네트워크 통신을 하고 있었습니다.
일반적인 작업/과정이라면 이러한 문제가 전혀 발생 하지 않을 가능성도 크지만 (실제로 적용 전 선행 테스트에서는 이러한 상황/버그가 발생 하지 않았습니다) Hyper-V 에서 VM 내부의 상황을 100% 이해하지 못하고 VMBus를 통해 한정적인 정보만을 통신하기 때문에, 이와같이 SR-IOV가 활성화 된 것으로 오인하는 상황이 발생 할 수 있을 것으로 보입니다. Hyper-V 네트워크 어댑터 #1/#2를 삭제하는 과정은 VM 내부에서 cmd / set devmgr_show_nopresetn_devices=1 , devmgmt.msc (보기 - 숨김장치 표시)의 디바이스 관리자에서 비활성화 된 Hyper-V 네트워크 어댑터 #1/#2 를 각각 삭제하는 것으로 해결이 되었습니다.
트러블슈팅 과정만 보면 굉장히 논리적인 추측으로 구간 별로 부드럽게 측정, 진행 되었다고 보일 수도 있지만, 실제로는 SR-IOV 로 연결된 구조 / 네트워크 흐름도를 모두 파악하고 구간 별로 위치한 디바이스를 성능 모니터링의 카운터를 통해 원인을 유추하는 과정이 쉽지 많은 않은 과정입니다. 다만 중요한 것은 이 모든 과정을 시행할 수 있도록 성능 모니터를 통해 부담 스러울만큼 많은 모니터링 요소를 제공 해준다는 사실입니다. 일반적인 작업 과정으로 트러블슈팅 없이 SR-IOV가 한번에 적용 되었다면 결과적으로는 만족했겠지만, 그 만큼 SR-IOV를 더 잘 이해할 수 없었거나, 단순한 옵션 체크 박스 하나로만 인지할 가능성이 높았기 때문입니다.
VMWare vSphere 에서의 SR-IOV 구성도
references
http://blogs.technet.com/b/privatecloud/archive/2012/05/14/increased-network-performance-using-sr-iov-in-windows-server-2012.aspx
http://blogs.technet.com/b/jhoward/archive/2012/03/12/everything-you-wanted-to-know-about-sr-iov-in-hyper-v-part-1.aspx
http://blogs.technet.com/b/koalra/archive/2012/08/07/windows-server-2012-hyper-v-io-sr-iov.aspx
https://msdn.microsoft.com/en-us/library/windows/hardware/hh451362(v=vs.85).aspx
https://msdn.microsoft.com/en-us/library/windows/hardware/hh440238(v=vs.85).aspx
https://msdn.microsoft.com/ko-kr/library/hh440150(v=vs.85).aspx
https://www.youtube.com/watch?v=hRHsk8Nycdg
http://h20565.www2.hp.com/hpsc/doc/public/display?docId=emr_na-c03514877
http://www.intel.com/content/dam/www/public/us/en/documents/technology-briefs/ethernet-sr-iov-microsoft-windows-brief.pdf
http://www.windowsnetworking.com/articles-tutorials/windows-server-2012/single-root-io-virtualization.html
