도록태가 뭔가요
cookis

Recent Comment

2015.06.20 18:06 softwares/quick reference

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

posted by cookis
2015.06.19 23:37 softwares/quick reference

일반적으로 서버 가상화 환경에 올라가는 어플리케이션들의 종류를 보면 대부분 웹이나 게임 서버 등의 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
....
IovSupport                                : True
IovSupportReasons                         : {OK}
VMHost 에서 SR-IOV 지원 여부 확인, BIOS 설정이 안 되어있을 경우 IovSupportReasons 에서 표기


PS C:\Windows\system32> get-netadaptersriov
....
Name                 : Public_SR-IOV_1
InterfaceDescription : HP Ethernet 1Gb 4-port 366FLR Adapter #6
Enabled              : True
SriovSupport         : Supported
SwitchName           : DefaultSwitchName
NumVFs               : 6
VMHost 에 장착 된 pNIC 의 스펙 및 VF 개수 확인

PS C:\Windows\system32> get-netadaptersriovvf

Name                           FunctionID VPortID MacAddress        VmID                           VmFriendlyName
----                           ---------- ------- ----------        ----                           --------------
Public_SR-IOV_2                0          {1}     00-15-5D-07-B9-0D 35C08A38-AB24-46D8-A415-A03... VMTEST11
Public_SR-IOV_2                1          {2}     00-15-5D-07-B9-11 3C7B056A-866F-4CD9-8687-495... VMTEST22
Public_SR-IOV_2                2          {3}     00-15-5D-07-B9-12 7BDE3915-1251-4912-8744-EA0... VMTEST33
Public_SR-IOV_2                3          {4}     00-15-5D-07-B9-0F 13959A5D-164B-4203-8CB5-E06... VMTEST44
SR-IOV 어댑터에 할당 된 VF 포트 및 VM 네임을 확인

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를 지원하지 않음

posted by cookis