Guest Cluster를 구현 하는 방법은 Shared Storage 구현 방식에 따라 3가지로 나뉠 수 있습니다.

1. iSCSI SAN 이용
2. vFC SAN 이용
3. Shared VHDX 이용 : http://technet.microsoft.com/en-us/library/dn265980.aspx

제가 생각하는 Check List는 다음과 같습니다.

- vFC SAN 구성에 대한 권장 가이드는 아래 문서를 참고 하시면 됩니다.
http://blogs.technet.com/b/privatecloud/archive/2013/07/23/hyper-v-virtual-fibre-channel-design-guide.aspx

주요 주의 사항은 다음과 같습니다.
- 간략하게 요약하자면 vSAN은 Fabric의 갯수에 맞춰서 만들어 줘야 합니다.
즉 물리 SAN Switch가 1개만 있다면 HBA의 Port갯수에 관계없이 vSAN은 1개만 만들면 됩니다.
만약 물리 SAN Switch가 2개 이상 있다면 갯수만큼 vSAN을 만들어 줘야 합니다.
다만 만약 SAN Switch 사이에 Interconnect가 있다면 이경우에는 Fabric을 하나로 봐야 함으로 vSAN은 하나가 됩니다. 그리고 마지막으로 개인적인 취향이 들어가는 부분인데, 제 경우에는 SAN Fabric을 하나로 가져가고 VM상에서 굳이 MPIO를 구현 하지 않습니다.

주의 : 잘못 설정하면 NPIV 포트 고갈로 인해 VM이 시작되지 않을 수 있습니다.
실은 HBA는 NPIV Queue를 가지고 있습니다. 일단은 제가 포트로 표현했는데… 만약 특정 VM 시작하는 시점에 이 NPIV Queue가 고갈되게 되어 할당을 못 받는 경우 VM시작이 실패하게 됩니다.

- NPIV는 HBA와 SAN 모두 활성화 해야 합니다.

- Zone을 잡으실때는 WWPN으로 잡으셔야 합니다.

1. Guest OS가 Shared VHDX를 지원 하는 경우 즉 Windows Server 2012 이상의 경우에는 관리적인 측면에서 Shared VHDX를 선호 합니다.

2. SCVMM을 이용하여 Cluster Member 간에 Antiaffinity 설정이 가능 합니다. (강력 권고)

3. 일부의 아주 가끔 발생하는 이슈인데 Guest Clustering 구현이 실패하는 경우가 있습니다.
이 경우에는 “Microsoft Failover Cluster Virtual Adapter Performance Filter” 를 Guest Cluster의 Heartbeat으로 설정한 네트워크에서 제외해 주셔야 합니다. (관련 이슈 : http://support.microsoft.com/kb/2872325)
문제가 발생하는 경우에 적용해 주시기 바랍니다.

참고:
“Microsoft Failover Cluster Virtual Adapter Performance Filter” 는 Host Cluster 상에서의 Heartbeat Communication Path을 분산 시켜주는 역활을 합니다.
이전의 Cluster의 경우 Metric Value가 작은 Network Path로만 Heartbeat 통신을 했지만 현재의 경우 Metric 뒷 4Bit을 가지고 Offset 연산을 하여 Heartbeat 네트워크 자체를 분산시키고 있습니다.

기본적으로 Storage Space를 사용하게 되면 Disk에 대해서는 이미 RAID (n-way mirror 및 페러티) 를 통해 FT(Fault Tolerance)을 제공 하고 있습니다.
물론 실제로 Storage Space를 호스팅하는 서버의 경우에는 마찮가지로 Failover Cluster를 통해 고가용성을 제공하고, 물론 Disk Pool 역시 Failover cluster에 등록되어 고가용성을 제공 하며, 마지막으로 SMB File Share 역시도 Scale-out file server 즉 Failover Cluster 기반의 SMB 전용 파일 서버 구축을 통하여 FT(Fault Tolerance)를 제공 하고 있습니다.

즉 전방위적으로 고가용성 및 Fault Tolerance를 제공하고 있는 것이죠.
그런데 잠깐? 실제 JBOD 박스 즉 Enclosure는 어떻게 될까요? 물론 지원 합니다.
만약 다음의 조건을 충족한다면요… :)

1. 적어도 3개 이상의 JBOD Enclosure로 구성하여야 합니다. (2 Way Mirror 구성인 경우)
2. Disk 생성 시 IsEnclosureAware 를 꼭 True로 설정하여야 합니다.

짦은 Tip 이였습니다.
감사합니다.

기존 Out bound A/A Team 구현 방식의 한계

- 구현 방식은 TCP Port / IP Address / Mac Address Hash 방식이 제공되었습니다 반면 현재의 Dynamic Teaming의 경우 동일한 Port일지라도 Flowlet에 따라 부하 분산이 가능하나 기존의 구현 방식은 Port 수준까지만의 부하 분산만 지원 하였습니다.

왜? TCP Port 수준 밑단까지는 부산 분산을 구현 할 수 없었을까?

- 만약 TCP Stream 상의 패킷들이 동시에 NIC를 통해 외부로 전송된다고 생각해 보자. 이렇게 전달된 패킷들은 실제의 Stream 순서대로 목적지로 전송되지 않을 확률이 큽니다. 일반적으로 이러한 경우을 Out-of-order라고 부르고 있으며 이 경우 목적지에서는 이에 대한 Packet Re-ordering을 진행하게 됩니다. 자 다시 말해 바로 하나의 스트림에 해당하는 데이터가 동시에 Team을 이루고 있는 NIC로 전송됨으로써 당연히 Out-of-order의 발생이 필연적이 되게 되는 이는 수신측의 Re-ordering 연산으로 인한 성능 저하로 이어지게 됩니다.

정말 이런 Re-ordering 이 성능에 영향을 주나요?

- 내 아래 문서를 참조하세요. (http://kb.pert.geant.net/PERTKB/PacketReordering)
In principle, applications that use a transport protocol such as TCP or SCTP don't have to worry about packet reordering, because the transport protocol is responsible for reassembling the byte stream (message stream(s) in the case of SCTP) into the original ordering. However, reordering can have a severe (심각한) performance impact on some implementations of TCP.

그렇다면 동일 TCP Stream는 여러 팀 Member 중 하나만 사용하게 되나요?

- 내 맞습니다. 문제는 TCP Stream을 과연 Team 드라이버가 인식할 수 있냐는 부분입니다. R2의 Dynamic 부하 분산 모드는 동일한 Port를 사용하더라도 TCP Stream이 다른 경우 부하 분산을 제공해 줍니다. 이는 TCP Stream을 이해 할 수 있는 알고리즘인 Flowlet 이 적용되어 있기 때문입니다.

잠깐 Flowlet은 어떻게 구현 되어 있나요?

- 수많은 TEST를 거쳐서 동일 Port를 이용하는 Traffic에 대해서 연속 스트립 여부를 확인할 수 있게 되었습니다. 결론은 시간차이인데요. 동일 스트림일때와 단일 스트림에서 다른 스트림으로 바뀔때는 약간의 시간차가 있습니다. 그리고 그 시간차를 확인하여 동일 스트림이 아닌 경우 다른 NIC 즉 다른 팀 멤버를 사용하도록 디자인 한거죠.

- 실은 자연 과학도 마찮가지지만 관찰과 직관은 꽤 멋진 결과물을 내곤 합니다. 제가 소계해 드리는 Flowlet 알고리즘 역시 그 관찰과 직관의 결과물이죠.
“흔한 예로 IBM 친구들의 최고의 발명품 중 하나인 RISC 프로세서가 있습니다.”

그 외에 다른 장점은 없나요?

- VM에서 외부로 나가는 Traffic 역시도 Dynamic 모드를 통해 Team을 이루고 있는 멤버들 모두를 이용한 부하 분산 모드를 제공하고 있습니다.

PS. 아차… 혹시 이거 쓰는데 네트워크 성능이 더 떨어진다 싶으면 스위치에 라우터 가드 기능을 끄시는게… :) 꼭 궁합이 않맞는 장비가 일부 있는거 같더라구요.

꼭 활성화 해 사용해야 하는 설정 몇 가지

0. 사용하는 RDP 버전에 맞는 RDP Client 모듈을 이용합니다.

1. 먼저 아래의 두 개 정책은 모두 사용하도록 해주세요.

Computer Configuration -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host –> Connections

2. 다음 정책은 TEST 진행 후 결과에 따라 설정해 주세요.

Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Remote Session Environment > Configure compression for RemoteFX data

3. RDGW에서 UDP 3391이 오픈되어 있는지 꼭 확인 하세요.

4. Windows 7 VM으로 구현 하는 경우 아래 정책 활성화는 필수 입니다.

Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Remote Session Environment\Enable Remote Desktop Protocol 8.0 또는 8.1

5. 필요에 따라 Windows 7 기반의 VDI의 경우에는 암호화 수준을 조정 할 필요가 있습니다.
아래의 정책을 활성화 하고 암호화 수준을 Low 즉 낮음으로 변경 합니다.

주의 : 이 경우 Client에서 보내는 모든 신호는 암호화가 되지만 서버의 경우에는 암호화 하지 않습니다.
다만 아시는 바와 같이 서버에서 보내는 트래픽은 RDP 자체가 압축되어 전송 되기 때문에 패킷을 직접 보더라도 쉽게 내용을 확인하기가 어렵습니다.

6. CRL 체크 Timeout을 1초로 줄입니다.
(절대 권고는 아닙니다.)
(해당 설정은 VM이 아닌 접속하는 Device 레벨에서 진행 하게 됩니다.)

중요 : RDS 인프라가 인터넷이 막혀 있는 경우 RDS 인프라에 해당하는 GW, CB등에도 동일 설정을 해주셔야 합니다.

CRL Check는 인증서 사용할 때 필수 입니다.
하지만 고객에 따라서 때로는 CRL을 확인 할 수 있는 방법을 URL, LDAP, 또는 파일 쉐어로 오픈을 하셔야하는데, 여희치 않는 경우가 있습니다.

이때에는 15초라는 Default Timeout 기간 동일 해당 위치에 대한 접근을 시도하게 되고 이는 초기 접속에 대한 성능 이슈를 야기 합니다. 그렇기 때문에 때대로 이 Timeout 시간을 1초로 조정해 줄 필요가 있습니다.

또한 필요에 따라 “HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\SystemCertificates\AuthRoot DisableRootAutoUpdate” 의 값을 1 즉 Disable 해야 해 줄 필요가 있는데 이 경우는 VDI에 접속하는 머신이 인터넷이 않될 경우 생각해 보실 수 있습니다.

Disk IOPS의 QoS 설정 시 Minimum은 실제 최소한 확보해야 하는 QoS 수치가 아니라 Warning이 발생함

Storage Space에서는

과반수의 디스크가 접근이 되어야 한다.
즉 2개의 JBOD로 구현하고 Pool을 각각에서 5:5로 구현한 경우 과반수 확보가 어렵기 때문에 한 JBOD가 죽게 되면 전체 디스크가 죽게 된다. 즉 JBOD는 2개 이상으로 구현해야 한다.

인증된 JBOD가 왜 좋을까?
JBOD의 인증이 제공될 때 종속된 BOX 정보 및 Disk 정보를 제공해 준다. 하지만 인증되지 못한 JBOD의 경우 운이 나쁠 경우 디스크 관리자에서 쭉 BOX와 관계 없이 디스크가 나열 되게 된다.

안녕하세요.
오늘은 좀 더 쉽지 않은 주제인 Virtual Processor에 대한 Scheduling을 다루고자 합니다.

1.1 Virtual Processor VS Logical Processor
1.2 Scheduling 첫 번째 이야기

이미 말씀드린 바와 같이 Hyper-v의 가장 중요한 역활은 바로 Scheduling 입니다.
즉 Virtual Processor를 적절하게 Logical Processor에 할당하는 것이죠. 기본적으로 우리는 VM 별로 할당 정책을 통해 중요한 VM에 대하여 많은 Logical Processor 점유률을 할당 할 수 있는데, 실은 이 뿐만이 아니라 내부적으로Hyper-v는 그보다 정말 많은 사항들 예를 들어 OS Version, Hyper-Threading, Affinity, Guest Spinlock, Physical Numa 등등을 고려하여 최선의 정책을 만들어 내고 적용 하고 있습니다.

그리고 오늘은 우리가 직접 설정할 수 있는 Scheduling Policy 이야기 이전에 그 이면에 무슨 일들이 일어나고 있는지에 대해 이야기 하고자 합니다.

Enlightenment of Scheduling

가장 먼저 우리는 VM에 할당될 Virtual Processor의 갯수를 조정할 수 있습니다.
물론 Windows Server 2012 Hyper-v 부터는 VM당 최대 64개의 Virtual Processor을 할당할 수 있죠.
(물론 실제 Logical Processor가 64개 이상일 경우지만)

하지만 아래와 같이 Windows Server 2003의 경우 최대 할당 가능한 Processor의 갯수가 2개로 명시되어 있습니다.
왜 그럴까요?

출처 :  http://technet.microsoft.com/en-us/library/hh831531.aspx

이를 이해하기 위해서는 조금 재미 있는 이야기를 해야 하는데요.
실은 Partition 입장에서는 자신은 하나의 완전한 OS이고 자신이 사용하는 Processor가 Virtual 인지 Physical인지는 중요하지 않습니다. 아니 생각 자체를 하지 않았죠.
그러다 보니 이런 OS들을 가상화 플랫폼에 올리면서 한 가지 재미 있는 사실이 있는데, 바로 VM 별로 Virtual Processor들에 대한 Scheduling을 제공하게 되면 VM 및 Virtual Processor가 증가함에 따라 성능은 Linear 하게 하락한다는 거죠.
예를 들어 LP : VP 의 비율이 1:4 면 1/4 수준의 성능이 1:8이라면 1/8 성능으로 줄어 들게 됩니다. 그런데 여기서 우리는 한가지 질문이 생깁니다.

“어~ 그러고 보니 이 VM의 VP는 8개 인데 지금 2개만 100%구 다른 녀석들은 다 노네…”

내 맞습니다. VP에 대한 Scheduling을 좀더 스마트 하게 하는 방법이 없을까 고민하게 된겁니다.
즉 고전의 OS을 기준으로 한 VM별 Scheduling은 말 그대로 비용의 낭비 즉 사용 하지 않는 LP까지를 VP에 할당함으로써 다른 VM의 Virtual Processor가 점유 할 수 있는 기회를 빼앗아 버린다는거죠.
자 그렇다고 답이 없는건 아닙니다. 이미 이야기한 것과 같이 VM에 종속성을 이야기 하지 않고 Virtual Processor 에만 집중한다면 답이 나올 수도 있죠.

다시 말해 Active 즉 Workload을 실행하는 Virtual Processor에만 Logical Processor을 제공하는 겁니다.
하지만 여전히 문제가 남아 있습니다. 도대체 어떻게 Hyper-v가 그런 Active 한 Virtual Processor 만을 알아내냐는 거죠.

그래서 아예 OS 커널을 수정했습니다. 어떻게? 바로 Hyper-v를 인식하고 Hyper-v가 적절하게 스케줄링 할 수 있도록 스케줄링 정보를 전달하도록 말이죠…
그리고 이를 우리는 Enlightenment 라고 부릅니다.
문제는 Windows Server 2003의 경우 Hyper-v 출시 이전에 출시된 OS라는 점입니다.
Hyper-v 출시 이후의 OS야 어차피 처음 설계 단계에서부터 가상화를 고려하여 디자인 되었기 때문에 위에서 말씀 드린 것과 같이 필요한 Scheduling 정보를 Hyper-v에 제공하게 됩니다. 하지만 그 이전의 OS의 경우에는 그렇지 못하겠죠. 그러다 보니 성능에 미치는 영향을 최소화하게 위해 Windows Server 2003의 경우 최대 VP의 갯수를 2개로 제한하고 있는 것이죠.

Enlihtenment의 예에는 위의 Active Virtual Processor에 대한 인식에 관한 사항 외에도 만약 VM의 특정 VP (Virtual Processor)가 Spinlock에 걸린 경우 해당 Lock이 풀릴 때까지 기다릴 수 있도록 정보를 제공하기도 합니다.

자 그리고 이렇게 Partition과 Hyper-v와의 통신을 위해서는 바로 Hypercall이 사용되게 되죠.

자 그 외에는 다른 어떤 사항들을 고려하게 될까요?

Affinity

분명히 Virtual Processor 역시 Processor 입니다.
그렇기 때문에 자주 접근되는 데이터의 경우 Processor Cache에 직접 넣어놓고 사용하게 되죠.
만약 Virtual Processor가 할당되던 Logical Processor가 바뀐다면? 당연히 이 Processor Cache는 모두 사라지게 되고 그만큼 성능에는 악 영향을 끼치겠죠?
그렇기 때문에 Hyper-v 는 Processor에 Affinity을 설정하고 항상 지정된 Logical Processor가 할당 될 수 있게 노력하게 됩니다. 물론 최대한 노력해 보고 여의치 않는 경우 다른 LP을 할당 받겠지만요.

Hyperthreading

다음으로 Hyperthreading 입니다.
실은 Hyperthreading이라는 개념은 매우 단순한데 원리는 다음과 같습니다. 실은 우리가 보는 CPU는 단순하지 않습니다. 매우 여러개의 각기 다른 역활을 하는 모듈들로 구성되어 있는데, 저는 일단 간단하게 “명령어를 읽고” “처리하고” “반환하는” 3개의 모듈로만 이루어 져 있다고 가정하고 이야기를 진행 해 보겠습니다.

문제는 이런 CPU가 매우 비싸다는 점입니다.
그럼에 불구하고 하나의 CPU가 “명령어를 읽고” 있다면 다른 모듈들 즉 “처리하고” “반환하는” 다른 모듈들은 쉬고 있다는 거죠. 그래서 과학자들은 생각한 거죠.

“아! 데이터의 흐름 즉 Pipeline을 여러 개 만들자!”

그렇게 되면 당연히 첫 번째 데이터가 처리 또는 반환 하는 동안 다른 데이터가 읽어 질 수 있을 테니깐요.
그렇게 되면 전반적인 CPU 활용률이 높아 지겠죠.
그래서 CPU를 만드는 회사에서는 이 Hyperthreading을 적극적으로 도입했고, 현재 우리가 사용하는 Intel Processor의 경우에는 2개의 Pipeline을 사용하고 있습니다.

하지만 여기에도 문제가 존재했습니다. 바로 Intel Processor가 “CISC” 기반이였다는 거죠. 실은 “CISC”는 매우 초기에 나온 Processor Type으로 이때는 메모리가 비쌌습니다. 그래서 처리하는 데이터의 길이가 최대한 메모리를 아껴쓰도록 매우 가변적 이였죠. 문제는 이런 가변적인 데이터 길이 였습니다.
(그에 비해서 RISC Processor의 경우 데이터의 길이가 일정하기 때문에 멀티 프로세싱에 매우 유리 했습니다. ㅜㅜ)

“아 스케줄링 하기 너무 힘들어”

맞습니다. CISC Processor 의 경우 공간 사용량은 매우 최적화 되어있지만 데이터의 길이가 가변적이여서 스케줄링이 쉽지가 않았습니다. 그러다보니 멀티 프로세싱은 물론 Hyperthreading에서도 때로는 극악의 성능을 보이게 된거죠. 그로인해 초기의 Intel Processor의 Hyperthreading 기능은 잠시 선을 보였다 들어가 버린거죠. 실은 Intel은 이러한 CISC의 단점을 보완 하기 위해 1995년 Micro-Operation 기반의 프로세서를 시장에 선보인 이래로 개선에 개선을 거듭했습니다. 그리고 지금의 Intel Processor는 가변적인 명령어들은 다시 한번 Micro-Operation으로 가공하여 가변성으로 인한 멀티 프로세싱의 단점을 완전히 날려 버리게 되었죠.

자 그래서 지금은 어떻냐구요? 연산의 종류에 따라 다르지만 Hyperthreading을 활성화 하게 되면 약 30% 정도의 성능 향상 효과가 있다는게 일반적인 의견이구요. 기본적으로는 성능에 문제가 발생하지 않는 이상 비활성화 하지 말라는게 제 개인적인 권고 입니다.

게다가 Hyper-v는 이렇게 Hyperthreading된 LP에는 2개의 VP 동시에 할당하여 Scheduling 처리를 합니다. 즉 Scheduling에 가해지는 부하도 줄어 들게 되겠죠. 그리고 아주 효과는 약하겠지만 전반적인 성능 향상 효과와는 별개로 Hyper-v의 Scheduling 부하도 낮춰 주는 효과가 있습니다.

물론 LP와 VP의 비율이 낮다면 단일 VM 입장에서는 할당된 Virtual Processor가 고정되어 있다는 가정하에 Hyperthreading이 비활성화 되어 있는 것이 더 좋을 수 도 있겠죠. 하지만 LP 대 VP의 비율이 높다는 당연히 Hyperthreading을 활성화 하는것이 Hyper-v 전반의 성능을 위해 좋은 효과를 발휘하겠죠.

이상으로 Scheduling의 근간이 되는 개념 몇 가지를 알아봤습니다.
하지만 여전히 Scheduling에 대해서는 할말이 너무 많습니다. 기본적인 UI 설정부터 NUMA까지…
그럼 Scheduling 두 번째 이야기로 다시 찾아 뵙도록 하겠습니다.

긴 글 읽어 주셔서 감사합니다.

참고 : http://en.wikipedia.org/wiki/RISC, http://maystyle.tistory.com/559
주의 http://maystyle.tistory.com/559 는 Windows Server 2008 R2 Hyper-v 시절에 작성된 글입니다.

안녕하세요.
Windows Server 2012 R2 가 시장에 선보인 지도 벌써 반년이 지나가고 있습니다.
오늘부터 저는 여러분들과 Hyper-v 2012 R2에 대한 학습을 하고자 합니다.
오늘은 그 첫 번째 Processor 에서도 Logical Processor와 Virtual Processor의 개념에 대한 이야기를 해 보겠습니다.

1.1 Virtual Processor VS Logical Processor

Virtual Processor
간단합니다. 바로 VM이 사용하는 Processor을 의미 하죠.
VM의 작업 관리자에서 확인 할 수 있는 그 Processor 입니다.

Logical Processor
질문 : Logical Processor는 작업 관리자에서 확인 할 수 있다?
답변 : 땡! 틀렸습니다.

Logical Processor는 Hypervisor가 직접 관리하는 실제 Processor을 의미합니다.
그런대 왜? Logical Procssor 라구 불리울까요? 실은 이 Logical Processor는 Hyperthreading 까지를 포함한 Processor의 개념을 의미 하기 때문입니다.
즉 1 소켓 머신에 4 Core CPU 그리고 Hyperthreading이 활성화 되어 있다면 총 Logical Processor의 갯수는 8개가 되는 거죠. (Hyperthreading에 대해서는 다음에 다루도록 하겠습니다.) 자 그렇다면 Hyper-v의 호스트 파티션에서는 Logical Processor을 작업 관리자에서 확인 할 수 있을까요? 정답은 당연히 확인 할 수 없다 이구요 120점 짜리 정답이 되려면 작업 관리자에서는 확인이 불가능 하지만 성능 모니터에서는 확인 할 수 있다 정도가 될꺼 같습니다. 실은 Hyper-v 상에서 Partition이라고 불리는 친구들은 바로 Hyper-v에게서 CPU (Virtual Processor) 와 메모리를 할당 받은 친구들이기 때문이죠. 그리고 Hyper-v Host 역시도 Root Partition이라고 불리우는 가장 처음 시작 되는 Partition일 뿐이기 때문 입니다.
그렇기 때문에 만약 여러분이 Logical Processor가 80개인 머신에서 Hyper-v 를 활성화 했을때, Host에서 확인 가능한 Processor의 갯수가 64개 즉 Hyper-v가 VM에 줄 수 있는 최대 Processor 갯수로 줄어 버리는 거죠.

그렇기 때문에 아래 그림과 같은 일들을 실제 종종 확인 할 수 있습니다.

보시는 작업 관리자 화면은 VM의 작업 관리자에서 확인한 CPU 사용량 즉 Virtual Processor 사용량 입니다.
100%군요!!!
 

하지만 Host에서 보면 아래와 같이 0%인 것을 볼 수 있는데 이는 당연한 결과 입니다.
결론은 둘 다 서로 각자의 Virtual Processor를 보고 있기 때문이죠.
 

그렇기 때문에 우리는 실제 Logical Processor에 가해 지는 부하를 보기 위해 성능 카운터 중 “Hyper-v Hypervisor Logical Processor” 의 Total Run Time 및 Guest Run Time, Hypervisor Run Time 등을 확인 해야 합니다.

자 이제 둘이 서로 다르다는 것을 확인 하셨나요?

실은 Hyper-v 즉 일반적으로 Hypervisor라고 불리우는 가상화 플랫폼의 가장 큰 역활 중 하나는 바로 Logical Processor를 적절하게 VM이 소유한 Virtual Processor에 할당해 주는 것입니다.
이를 우리는 스케줄링이라고 부르고 있죠. 그리고 적절한 스케줄링을 위하여 우리의 Hyper-v 는 Partition 들과 이런 저런 정보를 교환 하게 되는데, 이렇게 정보의 교환이 원활한 Partition을 우리는 Enlighten 된 Partition 이라고 부릅니다. (Guest OS의 커널이 Hyper-v 를 인지하고 Hyper-v 운영에 필요한 정보 즉 예를 들어 스케줄링에 필요한 데이터를 전달) 물론 스케줄링 알고리즘 및 위에서 설명한 Enlighten에 대해서도 다음에 다룰 생각이니 갑자기 어려운 이야기가 나왔다고 다급해 하실 필요는 없습니다… :) 그리고 이런 정보들을 Hyper-v에 전달하기 위해 사용되는 방식이 바로 Hypercall 입니다. (정확하게는 Partition과 Hypervisor 간의 통신 인터페이스를 의미 합니다.)

이미 설명 드린 바와 같이 Host Partition이 됐건 Guest Partition이 됐건 실제로 Processor에서 동작하는 Thread들은 Partition의 Virtual Processor가 Logical Processor을 할당 받게 되면 별다른 치환 이나 변경 없이 바로 실행 되게 됩니다. 그렇기 때문에 Hyper-v 즉 Hypervisor 기반의 Partition 들이 별다른 성능 저하 없이 이론적으로 만약 Logical Processor와 Virtual Processor을 1:1로 Mapping 한 경우에는 거의 100%에 가까운 성능을 낼 수 있다고 이야기 하는 이유 입니다.

그럼 다음에 Logical Processor와 Virtual Processor의 스케줄링이라는 주제로 다시 찾아 뵙겠습니다.

감사합니다.