Hyper-v 2012 R2 기본 부터 고급까지 1. Processor : Scheduling 1st Story

안녕하세요.
오늘은 좀 더 쉽지 않은 주제인 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 시절에 작성된 글입니다.