Hyper-V 환경을 설치하는 여러 이유에 대해서는 잘 알고 있을 것입니다. 그리고 이러한 특정한 관심 중에는 테스트 환경에서 64비트 호환성을 저해하지 않고도 Hyper-V를 사용하여 제품 평가와 교육을 용이하게 하고 환경에 대해 배우려는 목적이 포함되어 있습니다. CPU의 성능이 충분하며 하드웨어 가상화를 지원하는 최신 BIOS로 업데이트한 경우 Hyper-V는 보급형 64비트 하드웨어에서도 실행됩니다. 이를 통해 Microsoft Exchange Server 2007의 64비트 버전과 같이 완전히 지원되는 소프트웨어 버전에 기반을 두는 전면적인 테스트 환경의 배포를 간단하게 수행할 수 있습니다. 또한 배포를 설정한 후에는 새 제품을 살펴보거나 새 교육 과정을 시작하는 등의 경우 손쉽게 처음부터 다시 배포할 수 있습니다.
간단하게 DC(도메인 컨트롤러) 둘, SQL Server를 실행하는 컴퓨터 하나, SharePoint 프런트 엔드 서버 둘, Exchange 2007 사서함 서버 하나, 허브 전송 서버 하나, 그리고 클라이언트 액세스 서버 하나를 갖춘 고객을 위해 테스트 환경을 배포하는 데도 많은 노력이 필요합니다. 예를 들어 VM(가상 컴퓨터) 600개를 포함하는 등의 이보다 훨씬 큰 환경이 있다고 가정해 보십시오. 매주 또는 새 랩 환경이 필요할 때마다 이러한 VM을 다시 설치하는 것이 가능할까요? 이러한 배포를 자동화하는 방안이 필수적이며 바로 이러한 부분에 Hyper-V가 큰 도움이 됩니다.
Hyper-V는 Windows 기술이며 이를 WMI(Windows Management Instrumentation), Windows PowerShell, WDS(Windows 배포 서비스), Windows AIK(자동 설치 키트) 및 Windows PE(사전 설치 환경) 2.0과 결합하여 전면적인 배포를 크게 간소화하거나 적어도 작업이 지나치게 많이 필요하지 않도록 만들 수 있습니다. 시스템 배포와 구성이 수행되는 동안 설치 화면과 진행 표시줄을 보고 있을 수도 있지만 다른 중요한 일이 있다면 그럴 필요가 없습니다.
이 기사에서는 WDS, 사용자 지정 설치 이미지, unattend.xml 파일 및 WMI 스크립트를 사용하여 관리자 상호 작용 없이 Hyper-V 서버, VM, 게스트 운영 체제 및 서버 응용 프로그램을 배포하는 방법을 소개하겠습니다. 핵심 개념은 WDS 환경을 한 번만 미리 구성하고 교육 환경 다시 설치, 다른 구성에서 복잡한 문제 해결, 사용자 지정 솔루션 개발 및 테스트와 같은 필요가 있을 때마다 테스트 시스템을 다시 설치한다는 것입니다.
배포 과정에 필요한 유일한 상호 작용은 F12 키를 눌러서 PXE(Preboot eXecution Environment)를 시작하는 것이지만 TechNet 기사 "완전 자동화된 설치 디자인 배경"에 설명된 것처럼 WDS 구성에서 기본 Startrom.com 부트 파일 대신 Startrom.n12를 사용하면 이 단계도 제거할 수 있습니다.
Hyper-V VM이 자동으로 시작되도록 한 다음에는 WDS, AIK 및 WMI가 남은 작업을 처리합니다.실제 설치 이미지는 너무 크기 때문에 포함되지 않았지만 함께 제공되는 파일을 여러분의 랩 환경에 맞게 수정할 수 있을 것입니다.
배포 아키텍처
필자의 랩 배포 인프라의 핵심에는 AD DS(Active Directory 도메인 서비스), DNS(Domain Name System), DHCP(Dynamic Host Configuration Protocol), 그리고 물론 WDS를 실행하는 WDS 서버가 있습니다. 이 밖에도 관리 편의를 위한 AIK와 이 서버에서 원격 관리를 위한 Hyper-V 도구도 설치했습니다. 이것이 Hyper-V 배포 효율을 위한 준비의 전부입니다. 중복을 통한 고가용성이 중요한 경우에는 WDS 서버를 추가할 수 있지만 필수적인 것은 아닙니다. 남은 실제 컴퓨터는 그림 1에 나와 있는 것처럼 WDS를 통해 배포되며 실제 테스트 환경을 구성하는 VM을 호스팅하는 Hyper-V 서버입니다.
그림 1 Hyper-V와 가상 컴퓨터에 기반을 두는 전면적인 랩 환경
WDS 서버를 배포하는 데 대한 지침을 보려면 앞서 언급한 동일한 다운로드 사이트에서 첨부 워크시트 "Windows 배포 서비스 배포"를 참조하십시오. 설치 과정은 간단합니다. 반면에 Hyper-V 호스트 배포와 구성은 다소 까다로우며 이에 대한 내용은 조금 뒤에 다시 다루겠습니다.
WDS 기반 Hyper-V 배포
Hyper-V용 WDS를 배포하여 얻을 수 있는 장점 중 하나는 Windows Server 2008 설치 미디어 업데이트를 간소화할 수 있다는 것입니다. 원래 미디어에는 Hyper-V 시험판 버전만 포함되어 있기 때문에 미디어 업데이트는 필수적입니다. 실제 릴리스 버전은 Microsoft 다운로드 센터에서 별도 업데이트로 제공됩니다.
수행할 단계의 핵심을 정리하면, 참조 컴퓨터에 Windows Server 2008 설치, 최신 Hyper-V 파일로 설치 업데이트, Hyper-V 설치, Sysprep.exe를 사용하여 설치 일반화, 일반화된 설치 이미지를 WDS 서버로 캡처 및 업로드, 실제 인프라에서 모든 호스트에 대한 기본 Hyper-V 배포 자동화로 요약할 수 있습니다. 필자는 Hyper-V용으로 Windows Server 2008 Server Core를 사용하는 것을 선호합니다. 필자의 Hyper-V 서버는 VM을 호스팅을 위한 전용 서버이며 Server Core는 보안, 안정성 및 관리 효율성의 장점을 제공하는 것은 물론 운영 체제 크기가 작기 때문입니다. 그리고 설치 이미지를 캡처하는 데는 물론 WDS를 사용합니다. 첨부 워크시트 "Windows 배포 서비스를 사용하여 기본 Hyper-V 호스트 배포"를 보면 업데이트된 Hyper-V 설치 이미지를 생성, 업로드 및 사용하는 것이 얼마나 쉬운지 확인할 수 있습니다. 직접 확인해 보십시오.
아직까지는 문제가 없습니다. WDS를 기반으로 사용하여 Hyper-V를 배포하기는 어렵지 않습니다. 문제는 자동 구성 부분입니다. 설치 이미지를 캡처 및 업로드하기 전에 Sysprep.exe를 실행하여 참조 설치를 일반화해야 하지만 Sysprep.exe를 사용하면 일반화된 Hyper-V 이미지에서 구성 정보가 제거됩니다.
무엇보다 Sysprep.exe는 BCD(부팅 구성 데이터)를 일반화하고 BCD 저장소에서 하이퍼바이저 시작 지시문을 제거합니다. BCD는 펌웨어에 대해 독립적이지만 Hyper-V는 그렇지 않습니다. 하이퍼바이저는 기반 하드웨어와 BIOS의 가상화 기능을 사용하므로 설치 이미지를 일반화하려면 하이퍼바이저 시작 지시문이 실행되어야 합니다. Sysprep 일반화 이후에 BCD 저장소를 오프라인으로 수정하는 것은 가능하지만 이것은 해결책이 아닙니다.
AIK에 포함된 도구인 ImageX.exe를 사용하여 설치 이미지를 탑재하면 BCDEdit.exe를 사용하여 시작 지시문을 다시 입력할 수 있지만 실제 설치 루틴의 일반화 단계에서 Windows 설치 프로그램이 다시 이 지시문을 제거합니다. 즉, 원점으로 돌아가게 됩니다.
하이퍼바이저를 시작하려면 시작 지시문이 필요하기 때문에 다소 까다로운 상황입니다. 하이퍼바이저를 실행하지 않으면 Hyper-V 서버가 작동하지 않습니다. 그림 2에는 부트 구성을 조정하지 않은 상태에서 사용자 지정 설치 이미지를 사용하여 배포한 Hyper-V 서버에서 VM을 시작하려고 시도할 때 표시되는 오류 메시지가 나와 있습니다.
그림 2 하이퍼바이저가 실행 중이 아니기 때문에 가상 컴퓨터를 시작할 수 없음
하이퍼바이저 시작 지시문을 다시 입력하는 한 가지 방법은 서버 설치 후에 다음 명령을 실행하여 수동으로 추가하는 것입니다.
그런 다음 Hyper-V 서버를 다시 시작하면 됩니다. 그러나 이러한 수동 단계는 테스트 랩 배포를 완전하게 자동화하는 데 심각한 장애물이 됩니다. 다행스럽게도 AIK에 포함된 Windows 시스템 이미지 관리자를 사용하면 WDS가 설치 중에 자체 WDSClientUnattend.xml 파일과 함께 적용하는 설치 이미지에 대한 unattend.xml 파일을 만들 수 있습니다. 이 unattend.xml 파일에서 설치 프로그램이 WDS 클라이언트가 제공한 관리자 자격 증명으로 Windows에 자동으로 로그온하고 하이퍼바이저 시작 지시문을 BCD 저장소에 삽입하는 스크립트를 실행한 다음 서버를 다시 시작하도록 지정할 수 있습니다.
일반적인 방법은 그림 3에 나와 있으며 unattend.xml 파일의 전체 버전과 완전한 hypervconfig.vbs 스크립트는 첨부 자료에 포함되어 있습니다. 설치 중에 사용이 가능하도록 설치 이미지에 직접 hypervconfig.vbs 스크립트를 포함시킬 수 있습니다. 이렇게 하려면 "Hyper-V 배포 사용자 지정"에 나와 있는 것처럼 ImageX.exe를 사용하여 이미지를 탑재하면 됩니다.
그림 3 하이퍼바이저 다시 구성 및 시작
WMI 기반 Hyper-V 구성
하이퍼바이저를 다시 활성화하기는 그리 어렵지 않지만 필자의 hypervconfig.vbs 스크립트를 분석해 보면 이러한 단순한 5줄 이상의 코드가 있는 것을 알 수 있습니다. 시작 지시문 외에도 전체 Hyper-V 환경을 구성해야 하며 이것이 배포 과정에서 까다로운 부분입니다.
단순하게 이미지 캡처 전에 참조 시스템에서 VM을 만들고, 설치 이미지에 이를 포함시킨 다음, 하이퍼바이저 시작 지시문을 수정하는 방법은 올바르게 작동하지 않습니다. 서버에는 물론 VM이 있겠지만 하드웨어 종속성이 누락된 상태이기 때문입니다.
이미지 일반화를 수행하면 실제 NIC(네트워크 인터페이스 카드)에서 VM의 이더넷 포트 연결이 끊어지며, 기본 하드 디스크와 CD/DVD 장치에서 통과 드라이브 연결이 끊어집니다. 일반화를 생략할 수 있지만 설치 이미지에 미리 설치된 VM을 포함하는 것은 좋지 않습니다. VM을 미리 설치하면 이미지의 크기가 매우 커지는 문제가 있고, 배포된 테스트 서버의 평가판 라이선스는 언젠가는 만료되며, Active Directory 도메인을 오랫동안 오프라인으로 설정하는 것도 좋지 않습니다. 여러 달 전에 설치한 VM의 백업을 사용하여 랩 환경을 복원하면 Active Directory 인증 및 복제 문제를 경험하게 될 가능성이 상당히 높습니다. 이보다는 매번 새로 시작하는 것이 좋습니다.
따라서 테스트 랩의 실제 배포에 들어가기에 앞서 Hyper-V 환경에 VM과 NIC, 하드 디스크 및 DVD와 같은 연관된 리소스를 프로비전하는 과정을 알아보겠습니다. 짐작할 수 있겠지만 이러한 가상 리소스를 프로비전하는 것은 hypervconfig.vbs 스크립트의 주요 작업입니다.
방법은 상당히 간단합니다. 스크립트는 로컬 Hyper-V 서버의 이름을 확인한 다음 VM의 호스트별 집합을 구성합니다. 각 VM에는 서버별 .iso 파일과 일반 설치 .iso 파일에 매핑되는 두 개의 가상 DVD 드라이브가 할당됩니다. 서버별 .iso 파일은 부팅 DVD에 해당합니다. 여기에는 특정 랩 서버를 자동 설치하는 데 필요한 모든 필수 스크립트와 구성 파일이 포함되어 있습니다.
일반 설치 파일은 실제 설치 미디어를 제공합니다. 서버의 모든 VM 간에 일반 .iso 파일을 공유하면 Hyper-V 설치 이미지의 크기를 제어하는 데 어느 정도 도움이 됩니다. .iso 파일을 네트워크 서버에 배치할 수도 있지만 최종적으로는 설치를 위해 Hyper-V 서버로 파일을 복사해야 하기 때문에 이를 설치 이미지에 직접 포함시키기로 결정했습니다. 이렇게 하면 필요할 때마다 로컬에서 .iso 파일을 사용할 수 있습니다. 즉, 예를 들어 전체 랩 환경을 분해하지 않고도 추가 구성 요소를 설치하거나 특정 VM을 다시 설치하는 등의 작업을 수월하게 처리할 수 있습니다.
서버별 설치 DVD에 대해서는 조금 뒤에 설명하기로 하고 우선 WMI 기반 스크립트를 사용하여 Hyper-V 인프라를 구성하는 과정을 집중적으로 살펴보겠습니다. 그림 4에 나와 있는 것처럼 내부 및 외부 스위치 포트가 있는 가상 스위치, 자체 가상 이더넷 카드가 있는 VM, VHD(가상 하드 디스크) 파일에 연결된 가상 IDE 드라이브, 그리고 게스트 운영 체제와 서버 응용 프로그램 설치를 위해 .iso 파일에 연결된 가상 DVD 드라이버를 포함하여 다양한 가상 리소스를 프로비전해야 합니다.
그림 4 랩 환경을 위한 가상 리소스 프로비전
또한 VM의 자동 시작 설정을 조정하여 가상 디스크 드라이브를 먼저 사용한 다음 서버별 .iso 파일에 연결된 가상 DVD 드라이브를 사용하도록 부팅 순서를 변경해야 합니다. 이 구성에서 VM은 가상 하드 디스크에 OS가 설치되기 전까지 설치 DVD에서 부팅합니다. 이러한 순서는 최신 개인용 컴퓨터에서는 표준적인 절차이므로 익숙하게 느껴질 것입니다.
hypervconfig.vbs 스크립트는 실제 컴퓨터가 시작되면 자동으로 시작되도록 VM을 구성하므로 VM은 HypervisorLaunchType이 다시 부팅된 후에 온라인이 됩니다. 이것이 랩 설치가 시작되는 방법입니다. 최종적으로 VM은 자체 게스트 운영 체제의 설치 루틴으로 부팅됩니다. 이것이 완전한 자동 랩 배포의 핵심입니다.
VM 구성에 있어서는 대부분 여러 IDE 컨트롤러에 여러 드라이브가 연결된 실제 컴퓨터를 구성할 때 고려하는 것과 동일한 원칙을 따른다고 할 수 있습니다. 한편 가상 스위치는 동일한 Hyper-V 서버에 있는 여러 VM 사이, 그리고 컴퓨터 네트워크에 분산된 서버에 있는 VM 사이에서 통신을 가능하게 하는 핵심이므로 이에 대한 추가적인 설명이 필요합니다. 기본적으로 가상 스위치는 실제 스위치와 비교할 수 있습니다. CreatedVirtualSwitch 메서드를 호출하여 가상 스위치를 만들 수 있지만 포트가 없는 스위치는 그다지 쓸모가 없습니다.
스위치를 실제 네트워크에 연결하려면 CreateSwitchPort 메서드를 호출하고 이 포트를 서버에서 사용 가능한 이더넷 네트워크 카드에 연결하여 스위치 포트를 만들어야 합니다. 실제 네트워크 카드는 하나의 가상 스위치에만 연결할 수 있지만 직접 또는 라우터 소프트웨어를 실행하는 VM을 통해 여러 스위치를 서로 연결할 수 있습니다. 그러나 이 기사에서는 네트워크 라우터가 없는 기본적인 LAN 환경으로 충분하므로 사용 가능한 첫 번째 실제 이더넷 카드에 연결된 각 Hyper-V 서버에 단일 가상 스위치를 구성했습니다.
또한 VM을 가상 스위치에 연결해야 합니다. 이번에도 CreateSwitchPort를 호출하여 각 VM을 위한 별도의 스위치 포트를 만들어야 합니다. 그런 다음 각 스위치 포트를 VM의 가상 네트워크 어댑터에 연결할 수 있습니다. 외부 네트워크 연결을 제공하려면 부모 파티션을 가상 스위치에 연결하는 것도 잊지 않아야 합니다. 외부 및 내부 스위치 포트, 사용 가능한 실제 이더넷 카드에 대한 참조, 그리고 고유 장치 이름과 표시 이름을 매개 변수로 받는 SetupSwitch 메서드를 호출하여 이 작업을 편리하게 수행할 수 있습니다.
첨부 자료의 hypervconfig.vbs 스크립트를 보면 알 수 있지만 SetupSwitch 메서드를 호출하면 개인 스위치에서 가상 스위치를 외부 스위치로 변환할 수 있습니다. 스크립트에는 VM의 외부 네트워크 연결을 설정하기 위한 모든 세부 사항이 포함되어 있습니다. 자세한 내용은 MSDN에서 가상화 WMI 공급자 설명서를 참조하십시오. 필자의 hypervconfig.vbs 스크립트의 많은 부분이 "가상화 WMI 공급자 사용"에서 제공되는 샘플에 기반을 두고 있습니다.
가상 랩 배포
이제 Hyper-V 배포가 완료되었으며 시스템을 시작할 때마다 VM이 부팅되므로 랩 환경의 실제 배포에 집중할 수 있게 되었습니다. 교육 센터에서는 가상 네트워크 인프라와 게스트 운영 체제만 배포하고 나머지 서버 응용 프로그램은 나중에 학생이 설치하도록 해도 충분할 것입니다. 그러나 개발, 테스트 및 평가 목적으로는 랩 환경의 전체 배포를 자동화하는 것이 좋습니다.
전반적인 방식은 Hyper-V 방식과 비슷합니다. OS를 자동 설치한 다음, 자동으로 관리자 계정 로그온을 수행하고 추가 설치 명령을 실행하면 됩니다. 그러나 배포를 조율해야 합니다.
모든 VM은 사실상 거의 동시에 자체 설치 루틴으로 부팅하지만 일부 서버는 다른 서버를 사용하므로 모든 설치를 동시에 수행할 수는 없습니다. 예를 들어 AD DS를 설치해야 도메인에 다른 서버를 추가할 수 있으며, Exchange Server 2007도 AD DS를 필요로하고, SharePoint 서버 팜은 SQL Server를 필요로 합니다. 따라서 여러분의 시나리오에서 Windows 설치 프로그램을 즉시 실행할 수 있는 유일한 VM은 DC01.Litware.com입니다. 다른 모든 VM은 DC가 준비되고 실행될 때까지 대기해야 합니다.
설치 순서를 구현하는 몇 가지 방법이 있습니다. VM의 부팅 지연 시간을 구성할 수 있지만 이 기술은 안정성이 매우 떨어집니다. Active Directory 설치가 항상 15분 이내에 완료된다고 장담할 수 있겠습니까? 그런 다음 Exchange Server를 처음 설치하는 데는 얼마나 걸릴까요?
다른 가능성은 WMI 기반 스크립트를 사용하여 설치 필수 구성 요소가 허용하는 경우 VM에서 전환하는 것입니다. 이것은 더 나은 방법이기는 하지만 분산된 VM 배포 환경에서 중앙 집중화된 스크립트 실행을 조율해야 합니다. 이보다는 그림 5에 나와 있는 것처럼 각각의 개별 설치 루틴을 사용자 지정하고 VM이 해당 Windows 설치 프로그램 루틴을 시작하기 전에 정해진 설치 필수 구성 요소를 확인하도록 하는 방법이 덜 복잡합니다.
그림 5 설치 필수 구성 요소를 바탕으로 배포 시퀀스 구현
Windows PE를 사용하면 이러한 사용자 지정 설치 루틴을 구현할 수 있습니다. Windows PE는 최소한의 서비스를 포함하는 Win32 운영 체제이지만 WScript(Windows 스크립트 호스트), WMI 및 MDAC(Microsoft Data Access Component)를 지원합니다. 사용자 지정된 Windows PE 이미지를 만들고, 필요한 Windows 기능 패키지를 추가하고, 사용자 지정 스크립트를 포함시킨 다음, Windows PE 이미지의 %SYSTEMROOT%\System32에 있는 Startnet.cmd 파일을 편집하여 사용자 지정 스크립트를 실행하기만 하면 됩니다.
첨부 워크시트 "서버 배포용 사용자 지정 부트 이미지 만들기"에는 테스트 랩 환경의 각 서버를 위한 사용자 지정된 Windows PE 이미지를 만드는 방법이 나와 있습니다. 그림 6에는 이 기술을 사용하여 두 번째 DC의 배포를 조율하는 기술이 나와 있습니다.
그림 6 테스트 랩에서 두 번째 도메인 컨트롤러의 배포 조율
Startnet.cmd 파일에는 VM의 네트워크 인터페이스에 정적 IP 주소를 할당하고 StartSetup 스크립트를 호출하는 netsh 명령이 포함되어 있습니다. netsh 명령을 반드시 DHCP 지원 환경에서 실행해야 하는 것은 아니지만 이렇게 하면 네트워크 관련 오류를 확인하는 데 도움이 됩니다. 예를 들어 Hyper-V 구성 스크립트에서 VM에 레거시 네트워크 카드(Microsoft Emulated Ethernet Port) 대신 표준 네트워크 카드(Microsoft Synthetic Ethernet Port)를 프로비전하면 netsh 명령은 Windows PE가 NIC를 인식할 수 없다는 것을 알려 줍니다.
StartSetup 스크립트는 네트워크 리소스에 액세스하려고 시도할 때 이 문제에 대해 알려 주지 않습니다. 이것은 런타임 오류가 발생하더라도 On Error Resume Next 문 덕분에 스크립트가 유지될 수 있기 때문입니다. 어떤 이유에서든지 DC01을 사용할 수 없으면 연결 시도가 실패하고 스크립트가 무한 루프에 빠집니다. 이 루프는 연결 시도가 성공하거나 DC01이 글로벌 카탈로그 서버인 경우에만 종료되며 이것은 AD DS가 설치되었음을 의미합니다.
루프가 종료되면 스크립트는 unattend.xml 파일과 서버별 구성 설정을 지정하고 실제 Setup 명령을 호출합니다. 그림 6의 다이어그램에는 글로벌 카탈로그 서버가 온라인이 될 때까지 대기하는 방법이 나와 있지만 파일 공유나 SQL Server 데이터베이스의 가용 여부를 확인하는 것과 같은 다른 시나리오에도 동일한 원칙을 적용할 수 있습니다. 리소스에 액세스하려고 시도하고 시도가 성공하면 루프를 종료하면 됩니다.
서버 응용 프로그램 배포
이제 남은 유일한 작업은 unattend.xml 파일을 구성하여 도메인에 서버를 추가하고, TCP/IP 설정을 구성한 다음, RDP(Remote Desktop Protocol)를 활성화하고, 원하는 서버 응용 프로그램 설치를 위해 <FirstLogonCommands>를 구성하는 것입니다. 대부분의 Microsoft 서버 응용 프로그램은 무인 배포를 지원합니다.
AD DS의 경우에는 Microsoft 기술 자료 문서 "Windows Server 2008 기반 도메인 컨트롤러에서 무인 모드를 사용하여 Active Directory 도메인 서비스를 설치하고 제거하는 방법"에 설명대로 응답 파일을 제공해야 합니다. Exchange Server 2007의 경우에는 명령줄 매개 변수를 사용해야 합니다(온라인 도움말에서 "Exchange 2007을 무인 모드로 설치하는 방법" 참조). SQL Server 2008의 경우에는 "방법: 명령 프롬프트에서 SQL Server 2008 설치"에 나와 있는 온라인 도움말 지침을 따라야 합니다. Windows SharePoint Services 3.0의 경우에는 "Windows SharePoint Services를 위한 Config.xml 참조"에 나오는 내용을 참조하십시오.
요구 사항의 복잡성은 다양하지만 운영자 상호 작용을 전혀 거치지 않고 이러한 시스템을 배포할 수 있습니다. 마지막 작업은 F12 키를 눌러서 WDS 기반 배포 시스템을 시작하는 것입니다.
결론
Hyper-V는 흥미로운 기술입니다. 완벽한 64비트 호환성이 제공되므로 64비트 버전을 사용할 수 있는 경우에는 더 이상 평가나 교육 목적을 위해 32비트 소프트웨어 버전을 배포할 필요가 없습니다. 게다가 Windows 기술이므로 WDS, AIK 및 Windows PE를 배포에 완벽하게 활용할 수 있습니다. 또한 배포 프로세스 중에 리소스와 VM을 프로비전하는 것을 포함하여 가상화된 환경의 모든 측면을 관리하는 데 사용할 수 있는 가상화 WMI 공급자를 통해 WMI와 Windows PowerShell을 지원합니다. VMM(Virtual Machine Monitor) 대신 하이퍼바이저를 사용하여 고성능을 제공하고 확장성을 개선하며 Windows Server 2008에 포함되어 있으므로 추가 비용 없이 사용할 수 있습니다.
Hyper-V 기반 환경은 배포하기에 비교적 복잡하지 않습니다. 몇 번의 마우스 조작으로 첫 번째 VM을 시작할 수 있으며 Windows 배포 기술과 결합하여 아무리 복잡한 시나리오라도 손쉽게 자동화할 수 있습니다.
필자가 확인한 유일한 단점은 가상화 WMI 공급자의 온라인 설명서가 아직은 미흡한 수준이며 샘플 코드에서도 관련된 모든 작업을 다루고 있지 않다는 것입니다. 그러나 결과는 노력한 만큼 가치가 있습니다. VM이 600개보다 훨씬 적더라도 IT 환경이 스스로 배포하는 것을 구경하는 것은 상당히 재미있습니다.
필자소개
Fergus Strachan 은 영국의 기업 고객을 대상으로 Microsoft 서버 인프라 디자인과 구현을 지원하는 독립 컨설턴트이며 런던을 중심으로 활동하고 있습니다. Fergus는 Microsoft의 서버 기술에 대한 기술 기사를 연재하고 있으며 Integrating ISA Server 2006 with Microsoft Exchange 2007을 집필했고 Microsoft Exchange Server 2003 Resource Kit 의 공동 저자이기도 합니다.
출처 : 마이크로소프트 테크넷
제공 : DB포탈사이트 DBguide.net
댓글