Hyper-V 내부 구조 들여다 보기

안녕하세요? sankim 입니다. 본의 아니게 오랜만에 블로깅을 하게 되었습니다. ^^;

오늘은 클라우드의 핵심기술이라 불리는 가상화(Virtualization)에서 Microsoft의 Hypervisor을 구현하는 Hyper-V의 Archtecture에 대해서 이야기 할까 합니다.

아래 그림 1)은 기본적으로 Windows를 설치 했을 때 윈도우의 내부 구조를 보여 줍니다,  Windows는 기본으로 커널모드(Kernel Mode)와 유저모드(User Mode)로 나뉩니다, 커널모드는 주로 하드웨어 자원을 이용하기 위한 Component들로 구성되어 있는데 대표적으로 Windows Kernel과 디바이스 드라이버(device driver)가 있습니다, 유저모드에서는 .exe 같은 사용자 어플리케이션이 구동됩니다. 일반적으로 유저모드의 어플리케이션에서 네트워크나 디스크 액세스 같이 하드웨어 이용이 필요하면 유저모드에서 커널모드를 통해 그 요청을 하드웨어에 넘겨 데이타를 주고 받으며 처리합니다.

그림1)  Clean Install에서 Windows Archtecture

아래 그림 2)는 Hyper-V를 설치했을 때 Windows 구조입니다. Hyper-V가 설치된 실제 물리적인 컴퓨터는 부모 파티션(Parent Partition)이 됩니다, 이 부모 파티션(Parent Partition)에서는 자식 파티션(Child Partition)이라 불리는 가상 머신(VM 혹은 Guest machine이라고도 함)을 만들고 관리하는 역할을 합니다. 윈도우에 VM이 올라간다고 해서 이전 에뮬레이션 방식으로 오해하시는 분들이 계시는데, Hyper-V의 Hypervisor는 부모 파티션도 VM과 같이 일종의 파티션으로 인식하고 있으며, 에뮬레이션과 같이 부모 파티션의 영향이나 간섭을 받지 않습니다. 단 Hyprt-V가 지원하지 않는 OS의 VM의 경우 에뮬레이션 사용합니다.

그림 2)를 보면 H/W위에 Hypervisor(Ring -1)이라는 것이 추가 되었는데, 이는 CPU에서 가상화를 위해 지원하는 Ring -1 모드 의미 합니다. 일반적으로 CPU는 Ring 0, 1, 2, 3으로 나누고, Kernel Mode는 Ring 0, User Mode는 Ring 3에서 구동되는데, 근 몇 년 전부터 나온 X64 CPU에서는 가상화를 위해 Ring -1이 새로 추가 되었고, Hyper-V의 Hypervisor는 이 Ring -1을 이용해 가상화를 구현 합니다.

그림2)  Hyper-V 설치 후 Windows Archtecture

위 그림에서와 같이 부모 파티션(Parent partition)에서 새로 추가된 구성을 보면 VMBus, VSP, VSC, WMI Provider, Worker Process이 있습니다. 이 추가 구성들을  통해 VM들을 생성하고 관리할 수 있게 됩니다.

-WMI Provider: VM들을 모니터링하고 관리하기 위한 WMI Provider
-Worker Process: 각 VM 관리 서비스를 지원하며, 각 VM마다 Parent partition에서 자신의 Worker Process를 생성합니다.

-VMBus: In-Memory Bus로 Child partition과 Parent partition간의 데이터가 오고 가는 통로 역할을 합니다. 각 Child partition마다 각각의 VMBus를 생성해 사용합니다.
-VSP (Virtualization Service Provider) : Parent partition의 Device를 Child partition이 사용 (다른 VM들과 공유)하도록 지원합니다
-VSC (Virtualization Service Client) : Child partition의 Device 요청을 VMBus를 통해 VSP와 통신하는 역할을 하며 각 장치마다 드라이버(.sys) 형태로 존재합니다.

VM은 하드웨어에 직접 액세스(Access)하지 않고 VM과 하드웨어 사이에 위치한 부모 파티션(Parent Partition)을 통해 액세스 하게 됩니다.  Hyper-V의 hypervisor는 부모 파티션에만 드라이버를 설치하면 모든 자식 파티션이 그 장치를 사용할 수 있어 별도로 자식 파티션을 위해 Hypervisor에 특화된 디바이스 드라이버(Device Driver)를 별도로 탑재 시켜야 할 필요가 없습니다. 이러한 구조는 Hypervisor를 최소화 하여 Bug인한 문제의 가능성을 최소화 시켜주고 관리적 이점을 최대화 합니다.

조금 더 쉽게 설명하기 위해 아래와 같이 Hyper-V에서 VM이 디스크 액세스를 과정을 예로 들겠습니다.

그림3)  Synthetic Type

1)    User mode의 Application이 디스크 요청을 Kernel Mode에있는 Storage Stack에게 보냅니다.
2)    Storage Stack의 VSC(Storflt.sys)에서 VMBus로 요청을 보냅니다
3)    VSC에서 받은 요청은 VMBus를 통해 VSP에게 전달됩니다
4)    VSP는 받은 요청을 내부 Storage Stack에게 보내 H/W에 액세스 합니다.

이와 같은 Type을 SyntheticType이라고 합니다. 이런 Type을 실행하기 위해서는 Hyper-V가 지원하는 OS이어야 합니다. 지원 OS를 확인하시려면 여기를 클릭하십시오.

그렇다면 Hyper-V가 지원하지 않는 OS의 경우는 어떻게 할까요? 앞에서 말씀 드렸듯이 에뮬레이터 방식을 이용해야 하는데 이를 Emulated type이라고 합니다. 그 구조는 아래와 같습니다.

그림4)  Emulated Type

1)User mode의 Application이 디스크 요청을 Kernel Mode에있는 Storage Stack에게 보냅니다.
2)Storage Stack의 VSC(Storflt.sys)에서 VMBus로 요청을 보냅니다
3)VSC에서 받은 요청은 VMBus를 통해 VSP에게 전달됩니다
4) VSP는 User Mode에 있는 IDE Emulator에게 해당 내용을 에뮬레이팅 하고 그것을 다시 받아 다음 요청으로 보냅니다
5) VSP는 Emulating된 요청을 내부 Storage Stack에게 보내 H/W에 액세스 합니다.

이와 같이 에뮬레이션으로 인한 Cost이외에도 Kernel Mode에서 User Mode로 변환되면서 Context Switch가 발생되어 성능 하락을 가져오게 됩니다. Context Switch가 궁금하신 분들은 이전에 포스팅한 “Windows 성능 옵션(프로그램 vs 백그라운드 서비스)을 이해하다”를 참고 하시기 바랍니다.

첨부터 깊게(?)들어가면 가독력이 떨어질 것 같아서 간단하게 Hyper-V의 구조와 VM이 하드웨어와 통신하는 구조를 설명 드렸습니다, 자세한 내용은 차츰 올리도록 하겠습니다. 그럼 다음 포스팅을 기대해 주세요~

p.s. 글을 쓰는 지금도 마지막 장맛비가 거세게 내리는 군요.. 벌써부터 비가 그치고 올 더위가 두렵다는..