Maystyle :
Admin : New post
Guestbook
Local
media
Catergories
Recent Articles
Recent Comments
Recent Trackbacks
Calendar
Tag
Archive
Link
Search
 
해당되는 게시물 2건
  Hyper-v 2012 R2 기본 부터 고급까지 1. Processor : Scheduling 1st Story 
작성일시 : 2013. 12. 26. 23:55 | 분류 : Cloud/Hypervisor

안녕하세요.
오늘은 좀 더 쉽지 않은 주제인 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
image

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

하지만 아래와 같이 Windows Server 2003의 경우 최대 할당 가능한 Processor의 갯수가 2개로 명시되어 있습니다.
왜 그럴까요?
image
출처 :  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 시절에 작성된 글입니다.

Name   Password   Home   Secret   Submit
  Hyper-V 2012 R2 기본 부터 고급 까지 1. Processor : Virtual Processor VS Logical Processor 
작성일시 : 2013. 12. 20. 23:57 | 분류 : Cloud/Hypervisor

안녕하세요.
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%군요!!!
 image

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

그렇기 때문에 우리는 실제 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의 스케줄링이라는 주제로 다시 찾아 뵙겠습니다.

감사합니다.

Name   Password   Home   Secret   Submit