October 2008 October 2008
Virtualization: Windows Server 2008의 Hyper-V 소개
Hyper-V가 출시됨에 따라 IT 환경에서 가상화가 더욱 매력적인 솔루션이 되었습니다.햔제 기상화 시장에 대한 개요를 확인하고 Hyper-V가 가상화의 관리 효율성, 안정성 및 보안을 어떻게 개선하는지 알아보십시오. Rajiv Arunkundram
Virtualization: VMM 2008로 가상 환경 관리
System Center Virtual Machine Manager는 조직 전체의 가상 인프라를 관리하기 위한 통합된 인터페이스입니다.최신 버전에는 Windows Server 2008 Hyper-V는 물론 VMware 가상 컴퓨터에 대한 지원까지 추가되었습니다.새로운 기능에 대해 알아보고 VMM을 사용하여 관리 작업을 중앙 집중화하는 데 대한 개요를 살펴보겠습니다. Edwin Yuen
Virtualization: Microsoft Application Virtualization 시작
App-V(Microsoft Application Virtualization)를 사용하면 사용자의 조직에서 클라이언트 시스템에 가상화된 데스크톱을 제공할 수 있습니다.이를 통해 시스템 관리를 간소화하고 자신의 데스크톱이 아니더라도 자유롭게 업무를 할 수 있습니다.App-V가 작동하는 방법과 사용자의 조직에 이를 배포하는 방법을 자세히 살펴보겠습니다. Anthony Kinney
Virtualization: Hyper-V의 고가용성 실현
서버를 적은 수의 실제 컴퓨터로 통합하면 많은 장점이 제공되지만 시스템의 고가용성을 유지하기 위한 계획이 매우 중요합니다.여기에서는 Windows Server 2008 장애 조치(failover) 클러스터링을 통해 Hyper-V 가상 컴퓨터에서 고가용성을 확보하는 방법을 알아보겠습니다. Steven Ekren
Virtualization: 서버 가상화를 위한 백업 및 재해 복구
가상화는 재해 복구에 중대한 변화를 몰고 왔습니다.여기에서는 Microsoft 가상화 플랫폼을 재해 복구 계획에 활용하는 방법을 소개하고 Windows Server 2008 Hyper-V의 백업 및 복원 옵션과 고려 사항을 자세히 살펴보겠습니다. Adam Fazio
Virtualization: 가상 인프라 계획을 위한 필수 도구
여러분의 인프라는 가상화를 위한 준비가 되어 있습니까?네트워크 수준의 인프라 평가 도구인 Microsoft Assessment and Planning Toolkit를 사용하면 IT 인프라를 더 잘 이해하고 시스템이 가상화를 포함한 다양한 기술로 업그레이드 또는 마이그레이션할 준비가 되어 있는지 확인할 수 있습니다. Jay Sauls and Baldwin Ng
Columns
From the Editor: 본격화된 가상화 환경: | Letters: 독자의 목소리: | 도구 상자: IT 전문가를 위한 신제품:
SQL Q&A: 대용량 트랜잭션 로그, 복구 사용 시점 및 기타 정보: 이번 칼럼에서 Paul Randal은 백업과 복원에 대한 질문에 답하고, 로그 전달과 데이터베이스 미러링 간의 차이점을 살펴보고, 복구 기능을 최후의 수단으로만 사용해야 하는 이유에 대해 설명합니다.Paul S. Randal | Utility Spotlight: Offline Virtual Machine Servicing Tool: 오프라인으로 저장되는 가상 컴퓨터는 지속적인 보안과 규정 준수를 위해 필요한 업데이트를 자동으로 수신하지 못합니다.그 결과 전체 IT 환경이 위험에 노출될 수 있습니다.무료로 제공되는 Offline Virtual Machine Servicing Tool을 사용하여 가상 컴퓨터 업데이트 프로세스를 자동화하는 방법을 알아보십시오.Peter Skjøtt Larsen and Suveen Kumar Reddy Vuppala | Windows PowerShell: 프로필의 유용성: Windows PowerShell을 실행할 때 필요에 맞는 작업 환경이 추가되면 좋겠다는 생각을 한 적이 있으십니까?Don Jones가 프로필을 사용하여 Windows PowerShell 셸을 사용자 지정하는 방법을 설명합니다.Don Jones
Hey, Scripting Guy!: 뜬금없는 명언: Scripting Guys가 소크라테스에 대해 논하고 XML 파일 쿼리라는 주제를 다시 살펴봅니다.이번에는 XML 파일의 구조상 자식 노드를 사용하는 대신 추가 속성 값을 특성으로 구성합니다.The Microsoft Scripting Guys | The Desktop Files: Windows 배포 서비스 사용자 지정: Wes Miller가 조직의 필요에 맞게 WDS를 사용자 지정하고 구성하는 방법을 보여 주면서 Windows 배포 서비스에 대해 자세히 설명합니다.Wes Miller | Security Watch: 10가지 불변의 보안 법칙 돌아보기, 1부: 10가지 불변의 보안 법칙 이 처음 발표된 후 약 8년이 지났고 그 동안 많은 변화가 있었습니다.3부로 구성된 연재물 중 첫 번째인 이번 호에서 Jesper Johansson은 이러한 법칙을 오늘날의 관점에서 분석하여 여전히 유효한지 알아봅니다.Jesper M. Johansson
Field Notes: 고용량 컬러 바코드: Gavin Jancke는 색과 삼각형을 사용하여 기존의 흑백 바코드에 비해 데이터 용량을 훨씬 더 늘린 새로운 바코드를 개발했습니다.이 고용량 컬러 바코드에 대해 자세히 살펴보겠습니다.Gavin Jancke | Windows Confidential: 현명하게 일하지 말고 그냥 힘들게 일하라?: Raymond Chen과 함께 버그와 오류 간의 비대칭 관계에 대해 살펴보고, 프로그래머의 성과 못지 않게 그 과정의 고생스러움을 중요시하는 사람들의 심리를 알아봅니다.Raymond Chen


Virtualization
Windows Server 2008의 Hyper-V 소개
Rajiv Arunkundram
한 눈에 보기:
  • 가상화의 정의
  • 세 가지 가상화 아키텍처
  • 마이크로 커널식과 모놀리식 하이퍼바이저 비교
  • Hyper-V의 역할

목차
서버 가상화 시장
서버 가상화 작동 원리
가상화 솔루션의 유형
Windows 하이퍼바이저
부모 파티션
장치 공유 아키텍처
통합 구성 요소
Hyper-V 기능 집합
확장성
고가용성
보안
관리 효율성
요약
최근 가상화에 대한 논의가 크게 늘어났으며 이러한 논의는 대부분 서버 가상화에 대한 것이었습니다. 이것은 업계의 가장 흥미로운 경향이며, 앞으로 몇 년에 걸쳐 IT 시스템이 배포되는 방법에 대한 패러다임을 변화시킬 수 있는 잠재력을 가지고 있습니다. 그러나 서버 가상화는 시스템 사용률에 대한 IT 관리자와 설계자의 생각을 변화시키는 데서 그치지 않고 더욱 빠르게 동적으로 바뀌고 있는 환경을 관리하는 데 사용되는 프로세스와 도구에도 영향을 줄 것입니다.
가상화는 비교적 오래된 기술이지만 기술은 여전히 발전하고 있습니다. 사실 용어 자체도 사람에 따라 다른 의미로 이해됩니다. 포괄적인 용어로 보면 가상화는 기술 스택의 한 계층을 다음 계층으로부터 추상화하는 것을 의미합니다. 예를 들어 서버로부터 저장소를 추상화하거나 응용 프로그램으로부터 OS를 추상화하는 것이 이에 해당됩니다. 다양한 계층을 추상화하면 통합이 가능해지고 관리가 용이해집니다.
개념상으로 가상화는 저장소, 네트워크, 서버, 응용 프로그램 및 액세스에 적용됩니다. 저장소와 네트워크를 보면 가상화의 목표는 다른 장치의 집합을 집계하여 리소스의 전체 풀이 단일 엔터티처럼 보이고 작동하도록 하는 것입니다. 예를 들어 20개의 2TB 저장소 장치 대신에 40TB 저장소 솔루션 하나를 구성할 수 있습니다. 그러나 다른 구성 요소의 경우에는 반대 방향으로 가상화를 작동하여 여러 시스템이 있는 것처럼 나타나도록 단일 시스템을 만들 수 있습니다. 이러한 가장 일반적인 예로는 단일 서버에서 여러 OS 인스턴스와 환경을 호스트하는 서버 가상화가 있습니다.
Microsoft는 서버 가상화, 응용 프로그램 가상화, 프레젠테이션 가상화 및 데스크 가상화 부문에서 데스크톱에서 데이터 센터에 이르기까지 여러 다른 수준에서 가상화에 접근하고 있습니다. 이러한 모든 항목의 공통적인 스레드는 Microsoft System Center를 통한 관리 기능입니다. 이 기사에서는 서버 가상화 구성 요소에 초점을 맞추고 동적 데이터 센터 환경에서 Windows Server 2008의 핵심 기능인 Hyper-V가 어떠한 역할을 하는지 자세히 살펴보겠습니다.

서버 가상화 시장
먼저 현재 환경에는 어떤 것들이 있으며 전반적인 시장의 발전 방향이 어떻게 진행되고 있는지 살펴보면 도움이 될 것입니다. 연구에 따라 다소 차이는 있지만 일부 분석가는 현재 판매되고 있는 실제 서버의 5–9%는 가상화 호스트로 사용되고 있다고 예상하고 있습니다. 매년 900만대 이상 판매되는 실제 서버 시장에서 상당히 많은 부분을 차지하고 있음을 알 수 있습니다. 한 가지 분명한 것은 가상화에 익숙해지고 이를 적용하려는 사용자가 증가함에 따라 시장에 막대한 기회가 있다는 것입니다.
가상화가 사용되는 분야에 대해서도 아는 것이 중요합니다. 엔터프라이즈 고객은 분명 얼리어답터로서 테스트에 활발하게 참여했습니다. 한편 중소기업에서 가상화 배포도 증가 추세에 있습니다. 비즈니스 응용 프로그램에서 웹과 전자 메일 관리에 이르기까지 광범위한 워크로드에 대해 가상화가 도입되고 있습니다.
그렇다면 가상화가 주목을 끌고 있는 이유는 무엇일까요? 여기에는 몇 가지 요인이 있지만 타이밍과는 관련이 없습니다. 몇 가지 핵심적인 업계의 요인이 동시에 영향을 발휘하여 가상화 도입을 가속화했습니다. 이러한 업계 요인에는 64비트 컴퓨팅으로의 전환, 다중 코어 프로세서, 그리고 시스템 사용률 개선을 위한 지속 가능한 컴퓨팅으로의 움직임이 포함됩니다.
시스템은 점차 커지고 있으며 이에 따라 가상화와 같은 기술을 통해야만 시스템 기능을 완전하게 사용할 수 있게 되었습니다. 무어의 법칙과 같은 핵심 기술 덕분에 시스템이 사용할 수 있는 이상으로 처리 용량이 늘어났지만 환경적인 영향이나 전원 요구 사항, 냉각 비용 등에 대한 우려도 늘었습니다.
이러한 모든 요인과 함께 가상화를 도입하여 기대할 수 있는 ROI(투자 수익률) 가치 덕분에 대규모 기업은 물론 소규모 기업에서도 가상화 도입이 가속화되었습니다. 이에 따라 우리와 같은 IT 전문가들은 시장의 모든 주요 기업들이 앞으로 몇 년간 지속적으로 이 기술에 투자하여 특성과 기능을 향상시킬 것임을 예상할 수 있습니다.

서버 가상화 작동 원리
일반적으로 말해 서버 가상화를 사용하면 단일 실제 장치에 잠재적으로 다른 ID와 응용 프로그램 스택 등을 가지는 둘 이상의 OS 환경을 설치하고 동시에 실행할 수 있습니다. Hyper-V는 안정적이고 확장성 있는 플랫폼 기능을 제공하는 차세대 64비트 하이퍼바이저 기반 가상화 기술입니다. Hyper-V는 System Center와 함께 실제 및 가상 리소스 모두를 위한 통합된 단일 관리 도구 집합을 제공합니다.
이러한 모든 작업을 통해 비용 감소, 사용률 향상, 인프라 최적화를 실현하고 기업이 더 신속하게 새로운 서버를 제공할 수 있게 됩니다. Hyper-V의 아키텍처를 더 잘 이해할 수 있도록 먼저 몇 가지 다른 유형의 가상화 솔루션을 살펴보겠습니다.

가상화 솔루션의 유형
그림 1에 나와 있는 것처럼 서버 가상화에는 일반적으로 세 가지 아키텍처가 사용됩니다. 이러한 유형의 근본적인 차이점은 가상화 계층과 실제 하드웨어 간의 관계에 있습니다. 여기서 가상화 계층이란 가상 컴퓨터 모니터(VMM, 즉 Virtual Machine Manager와 혼동하지 않도록 주의)를 호출하는 소프트웨어 계층을 의미하며 동일한 기반 하드웨어 리소스를 공유하는 여러 고립된 인스턴스를 만들 수 있는 기능을 제공하는 계층입니다.
그림 1 가상화의 세 가지 아키텍처 (더 크게 보려면 이미지를 클릭하십시오.)
Type-2 VMM 아키텍처의 대표적인 예가 Java Virtual Machine입니다. 여기에서 가상화의 목표는 프로세스가 호스트 시스템에 의존하지 않고 명령 집합을 실행할 수 있는 런타임 환경을 만드는 것입니다. 이 경우에 고립은 다른 프로세스를 위한 것이며 단일 응용 프로그램이 OS 종속성에 대해 걱정할 필요 없이 다른 OS에서 실행될 수 있도록 합니다. 서버 가상화는 이 범주에 속하지 않습니다.
Type-1 VMM과 하이브리드 VMM은 현재 가장 흔하게 볼 수 있는 두 가지 방법입니다. 하이브리드 VMM은 VMM과 호스트 OS가 함께 실행되어 가상 컴퓨터를 만들 수 있는 무대를 제공합니다. 하이브리드 VMM의 예로는 Microsoft Virtual Server, Microsoft Virtual PC, VMware Workstation, 및 VMware Player가 있습니다. 이러한 유형의 솔루션은 일부 시간에만 가상 컴퓨터를 실행하는 클라이언트 시나리오에도 매우 유용하지만 VMM이 적지 않은 오버헤드를 더하기 때문에 리소스 사용량이 많은 워크로드에는 적합하지 않습니다.
Type-1 VMM 아키텍처에서 VMM 계층은 하드웨어 위에서 직접 실행됩니다. 이를 하이퍼바이저 계층이라고 하는 경우가 많습니다. 이러한 아키텍처는 원래 1960년 IBM에 의해 메인프레임 시스템을 위해 디자인되었으며 최근에 Windows Server 2008 Hyper-V를 포함한 다양한 솔루션을 통해 x86/x64 플랫폼에서도 사용할 수 있게 되었습니다.
하이퍼바이저가 펌웨어의 일부로 삽입되는 솔루션도 있지만 이것은 단순히 패키징 옵션이며 기본 기술을 변경하는 것은 아닙니다.
Type-1 VMM을 보면 알 수 있지만 하이퍼바이저 솔루션을 설계하는 데는 마이크로 커널식과 모놀리식이라는 두 가지 주요 방법이 있습니다. 이러한 두 가지 방법은 그림 2에 나와 있는 것처럼 실제 하드웨어에 직접 하이퍼바이저가 설치되는 진정한 Type-1 VMM입니다.
그림 2 하이퍼바이저 솔루션을 설계하는 두 가지 방법 (더 크게 보려면 이미지를 클릭하십시오.)
모놀리식 하이퍼바이저 방식은 커널, 장치 드라이버 및 I/O 스택과 같은 필요한 구성 요소 대부분을 포함하는 단일 계층에 하이퍼바이저/VMM을 호스트합니다. 이것은 VMware ESX 및 기존 메인프레임 시스템과 같은 솔루션에서 사용되는 방식입니다.
마이크로 커널식 방식은 파티션 격리와 메모리 관리를 보장하는 핵심 작업만 수행하는 매우 간소하고 특수화된 하이퍼바이저를 사용합니다. 이 계층에는 I/O 스택이나 장치 드라이버는 포함되지 않습니다. 이 방식은 Hyper-V에서 사용되는 방식이기도 합니다. 이 아키텍처에서 가상화 스택과 하드웨어별 장치 드라이버는 부모 파티션이라는 특별한 파티션에 위치합니다.

Windows 하이퍼바이저
여러 OS 간의 강력한 분할은 가상 프로세서, 메모리, 타이머 및 인터럽트 컨트롤러를 생성하여 보장할 수 있습니다. OS는 이러한 가상 리소스를 실제 리소스를 사용하는 것처럼 사용합니다.
Hyper-V의 일부인 Windows 하이퍼바이저는 다음과 같은 작업을 수행합니다.
  • 논리 파티션을 만듭니다.
  • 게스트 OS를 위해 메모리와 프로세스 예약을 관리합니다.
  • 입출력을 가상화하고 파티션을 통해 통신할 수 있는 메커니즘을 제공합니다.
  • 메모리 액세스 규칙을 적용합니다.
  • CPU 사용량을 위한 정책을 적용합니다.
  • Hypercall이라고 하는 간단한 프로그래밍 방식 인터페이스를 공개합니다.
Windows 하이퍼바이저는 마이크로 커널식 방식을 사용하므로 크기가 1MB 미만입니다. 이러한 초소한의 공간 사용을 통해 시스템의 전반적인 보안이 개선됩니다.
Hyper-V를 실행하기 위한 요구 사항 중 하나는 Intel VT나 AMD-V 기술을 지원하는 x64 시스템을 사용해야 한다는 것입니다. x64 기술을 통해 더 많은 주소 공간에 액세스할 수 있으며 더 많은 메모리로 시스템을 지원할 수 있기 때문에 단일 호스트 시스템에서 가상 컴퓨터를 더 많이 지원할 수 있습니다. Intel VT와 AMD-V는 링 아키텍처의 권한이 매우 높은 계층을 제공하여 하이퍼바이저의 실행 환경을 시스템의 나머지 부분과 분리하도록 지원하는 하드웨어 지원 가상화 솔루션입니다. 또한 Hyper-V가 수정되지 않은 게스트 OS에서 심각한 에뮬레이션 성능 패널티 없이 실행될 수 있도록 허용합니다.

부모 파티션
Hyper-V는 기본적으로 특수 또는 권한이 부여된 액세스가 있는 가상 컴퓨터인 하나의 부모 파티션으로 구성됩니다. 이것이 하드웨어 리소스에 직접 액세스할 수 있는 유일한 가상 컴퓨터입니다. 게스트 파티션이라고 하는 다른 모든 가상 컴퓨터는 부모 파티션을 통해 해당 장치에 액세스합니다.
부모 파티션의 존재는 투명하게 유지됩니다. Hyper-V 설치를 시작할 때 가장 먼저 할 일은 실제 시스템에 Windows Server 2008 x64 Edition을 설치하는 것입니다. 그런 다음 서버 관리자로 이동하여 Hyper-V 역할을 활성화한 다음 시스템을 다시 시작해야 합니다. 시스템이 다시 시작되면 Windows 하이퍼바이저가 먼저 로드되며 스택의 나머지 부분이 부모 파티션으로 변환됩니다.
부모 파티션은 호스트 서버에 연결된 키보드, 마우스, 비디오, 디스플레이 및 다른 장치의 소유권을 가지만 하이퍼바이저가 사용하는 타이머와 인터럽트 컨트롤러를 직접 제어할 수 없습니다.
부모 파티션에는 자식 파티션을 대신하여 하드웨어 관련 작업을 수행하는 가상화 스택을 비롯하여 가상화된 환경의 모든 측면을 원활하게 관리할 수 있도록 도와주는 WMI(Windows Management Instrumentation) 공급자가 포함되어 있습니다. 또한 호스트 시스템 하드웨어에 필요한 모든 IHV(Independent Hardware Vendor) 드라이버는 부모 파티션에 포함되며 Windows Server 2008 x64 버전용으로 개발한 모든 드라이버도 부모 파티션에서 작동합니다.

장치 공유 아키텍처
Hyper-V의 혁신적인 아키텍처 구성 요소 중 하나는 각 게스트 OS에서 에뮬레이션 장치와 합성 장치를 지원하는 새로운 장치 공유 아키텍처입니다. 장치 에뮬레이션은 이전 세대의 장치 드라이버를 위해 디자인된 이전의 OS를 지원하는 데 유용합니다. 예를 들어 Hyper-V에는 이전의 여러 OS가 출시될 당시 DEC 21140 네트워크 어댑터라고 불리던 Intel 21140 네트워크 어댑터의 에뮬레이션이 포함되어 있습니다.
일반적으로 장치 에뮬레이션은 느리고 확장이 쉽지 않습니다. 그러나 에뮬레이션은 Hyper-V에서 대부분의 x86 OS를 실행할 수 있도록 해 주므로 여전히 중요합니다. 가상화는 이제 주로 테스팅과 개발을 위한 틈새 기술에서 프로덕션 환경을 위한 핵심 기술로 발전하고 있으며 이에 따라 사용자 들은 더 큰 워크로드를 실행하기 위한 높은 성능을 요구하고 있습니다. 에뮬레이션된 장치로는 더 이상 이러한 높아지고 있는 요구를 충족할 수 없게 되었습니다.
이에 대한 다른 솔루션은 Hyper-V 합성 장치를 사용하는 것입니다. 합성 장치는 실제 장치로 직접 매핑되는 가상 장치입니다. 에뮬레이트된 장치와는 달리 합성 장치는 레거시 하드웨어를 에뮬레이트하지 않습니다. Hyper-V 하드웨어 공유 모델을 사용하면 지원되는 게스트 OS가 해당하는 실제 장치가 없는 합성 장치와 직접 상호 작용할 수 있습니다. 이러한 OS는 게스트 OS 내에서 장치 드라이버처럼 작동하는 VSC(Virtual Service Client)를 사용합니다.
VSC는 실제 하드웨어에 직접 액세스하는 대신 고속 메모리 내 버스인 VMBus를 사용하여 부모 파티션의 VSP(Virtual Service Provider)에 액세스합니다. 부모 파티션 VSP는 그림 3에 나와 있는 것처럼 기본 실제 하드웨어에 대한 액세스를 관리합니다. 합성 장치의 가장 중요한 장점은 VMBus를 통한 합성 장치의 성능이 가상화되지 않은 실제 하드웨어 장치와 비슷하다는 것입니다.
그림 3 VSC는 기본 실제 하드웨어에 대한 액세스를 관리하는 VSP에 액세스하는 데 VMBus를 사용 (더 크게 보려면 이미지를 클릭하십시오.)

통합 구성 요소
Hyper-V는 하나의 컴퓨터에서 실행되는 여러 인스턴스 간에 강력한 경계를 제공하도록 만들어졌습니다. Hyper-V는 게스트 OS와 호스트 OS 간의 상호 작용을 가능하게 하고 지원되는 게스트 OS에 몇 가지 추가 기능을 제공하기 위해 통합 구성 요소를 제공합니다.
Hyper-V 통합 구성 요소는 다음과 같은 기능을 지원합니다.
  • 시간 동기화
  • VSS(Volume Shadow Copy Service)
  • 하트비트 기능
  • 게스트 종료
  • 키 값 쌍 교환(게스트 OS 레지스트리에 액세스하는 데 사용)
  • OS 식별
Hyper-V 기능 집합
가상화 플랫폼이 실제 서버와 비슷하게 작동할수록 조직에서 가상 워크로드를 배포하고 사용하기 편해집니다. 필자의 관점에서는 가상화 플랫폼의 다양한 특성을 볼 수 있는 네 가지 핵심 영역이 있습니다.
현재 대부분의 하이퍼바이저 기반 가상화 솔루션은 특성과 기능면에서 서로 상당히 비슷합니다. 더 자세히 살펴보면 TCO(총 소유 비용)와 사용 편의성과 같은 요소가 핵심적인 차이점입니다. 그리고 관리 솔루션 분야에서도 기업의 요구를 충족할 수 있도록 유연한 인프라를 구현하고 자동화와 관리 효율을 개선하는 모델과 정책이 마련되는 동적인 IT 환경의 비전에 조금 더 가까워질 수 있도록 투자와 개발이 계속될 것입니다.

확장성
마이크로 커널식 하이퍼바이저 아키텍처와는 달리 Hyper-V는 CPU 오버헤드가 매우 낮기 때문에 워크로드를 가상화할 수 있는 여유가 많습니다. Hyper-V는 가상 컴퓨터가 다중 코어 기술, 개선된 기스크 액세스 및 더 많은 메모리와 같은 강력한 기능과 하드웨어를 활용할 수 있도록 함으로써 가상화 플랫폼의 확장성과 성능을 개선했습니다.
Hyper-V는 Windows Server 2008의 다른 기능을 함께 사용하여 단일 컴퓨터에서 32비트와 64비트 워크로드를 포함하여 대부분의 워크로드를 통합할 수 있습니다. 또한 여러분의 환경에서 이미 사용되고 있는 32비트 워크로드를 지속적으로 지원과 64비트 기술 도입의 균형을 맞출 수 있도록 지원합니다.
Hyper-V는 하드웨어 지원 가상화를 위해 64비트 호스트 시스템을 필요로 하므로 호스트 시스템에서 대규모의 메모리 리소스 풀에 액세스할 수 있습니다. Hyper-V는 호스트에서 최대 1TB 메모리를 지원하며 각 가상 컴퓨터에 64GB의 메모리를 제공할 수 있습니다. 이러한 특성은 Exchange Server 및 SQL Server와 같은 메모리 사용량이 많은 워크로드를 가상화하려고 계획하는 사용자에게 매우 중요합니다.
Hyper-V는 또한 호스트 시스템에서 최대 16개의 논리 프로세서를 지원하여 다중 코어를 갖춘 가장 일반적인 2소켓 및 4소켓 시스템으로 확장할 수 있습니다. 이 밖에도 다중 프로세서 기능을 활용해야 하는 워크로드를 지원할 수 있도록 최대 4개까지의 가상 프로세서를 갖춘 가상 컴퓨터를 만들 수 있습니다.
Hyper-V를 통해 서버를 통합하면 이러한 서버는 VLAN, NAT(Network Address Translation), NAP(Network Access Protection) 정책(격리)을 포함한 강력한 네트워킹 지원을 사용할 수 있게 됩니다. 그리고 Hyper-V는 Windows Server 2008 기능이므로 BitLocker 및 Windows PowerShell과 같은 다른 Windows Server 기능과 함께 잘 작동합니다..

고가용성
고가용성은 Hyper-V와 호스트 클러스터링 기능을 함께 활용하여 업무 연속성과 재해 복구 필요성을 충족할 수 있도록 지원하는 시나리오입니다. 업무 연속성은 예정 및 비예정 가동 중지 시간을 최소화할 수 있는 능력입니다. 여기에는 유지 관리 및 백업과 같은 일상적인 기능은 물론 예상치 못한 정전등으로 인한 시간 손실도 포함됩니다.
재해 복구는 업무 연속성의 중요한 요소입니다. 자연 재해, 악의적인 공격 및 소프트웨어 충돌과 같은 간단한 구성 문제는 관리자가 문제를 해결하고 데이터를 복원하기 전까지 서비스와 응용 프로그램의 기능을 저하시킵니다. 안정적인 비즈니스 및 재해 복구 전략이라면 최소한의 데이터 손실을 보장하고 강력한 원격 관리 기능을 제공해야 합니다.
고가용성에 대해 고려할 때는 예정 가동 중지 시간, 비예정 가동 중지 시간 및 백업의 세 가지 다른 범주를 고려해야 합니다. 예정 가동 중지 시간에 대한 보호는 일반적으로 호스트 시스템에서 가상 컴퓨터를 옮겨서 하드웨어 유지 관리를 수행하거나 호스트 시스템이나 가상화 플랫폼에 패치를 적용(다시 부팅이 필요할 수 있음)하는 데 필요합니다.
대부분의 조직에는 계획된 유지 관리 시간대가 있으며 여기에서 실질적으로 원하는 것은 호스트 시스템을 유지 관리를 위해 중지시킨 동안 가상 컴퓨터를 사용할 수 없는 시간을 최소화 또는 제거하는 것입니다. 빠른 마이그레이션 기능을 사용하면 실행 중인 가상 컴퓨터를 한 실제 노드에서 몇 초 안에 다른 노드로 이동할 수 있습니다. 따라서 원본 호스트에서 유지 관리를 수행하는 동안에도 가상 컴퓨터를 프로덕션에 사용할 수 있습니다. 유지 관리가 완료되면 빠른 마이그레이션으로 가상 컴퓨터를 원래 호스트 시스템으로 돌려 놓을 수 있습니다.
비예상 가동 중지 시간은 예상할 수 없는 가동 중지 시간입니다. 여기에는 천재 지변에 의한 것이나 누군가 전원을 실수로 뽑아서 서버를 끄는 실수에 의한 것이 있습니다. 실제로는 일어날 것 같지 않지만 필자는 Tech•Ed, VMworld 및 다른 컨퍼런스에서 동료가 실수로 서버를 끄는 상황을 경험한 사용자들을 많이 만났습니다.
Hyper-V를 사용하면 다른 호스트 시스템에 대한 호스트 클러스터를 설정하고 모든 가상 컴퓨터를 리소스로 구성하여 호스트 중 하나가 실패하면 다른 시스템으로 장애 조치(failover)를 수행할 수 있습니다. Windows Server 2008의 다중 사이트 클러스터링 기능을 사용하면 기본 데이터 센터가 실패하는 경우 원격 데이터 센터로 다른 가상 컴퓨터를 복구할 수 있는 지역적으로 분산된 클러스터를 설정할 수 있습니다.
이 기능은 모든 지점을 보호하는 데도 유용합니다. Hyper-V에서 지원하는 비예정 가동 중지 시간의 장점은 게스트 OS에 종속되지 않는다는 것입니다. 즉, 고가용성 장점을 Linux 가상 컴퓨터 및 이전 버전의 Windows Server으로 확장하여 이러한 시스템을 비슷하게 보호하고 복구할 수 있습니다.
비예정 가동 중지 시간에서 중요한 점은 복구의 경우 시스템의 전원을 끄고 다시 시작하는 것과 동일하므로 모든 상태 정보를 손실한다는 것입니다. 이것은 가상 컴퓨터에서 실행 중인 워크로드에 따라 문제가 되거나 그렇지 않을 수 있습니다. 바로 이것이 백업을 고가용성의 컨텍스트에서 보아야 하는 이유입니다.
Hyper-V는 각 가상 컴퓨터를 백업하거나 VSS를 사용하여 가상 컴퓨터가 실행 중인 동안 모든 VSS 인식 가상 컴퓨터를 일관성 있게 백업할 수 있습니다. VSS를 사용하면 지정한 간격으로 백업을 수행하도록 설정하여 프로덕션 워크로드 가용성에는 영향을 주지 않고도 계획하지 않은 가동 중지 시간이 발생하는 경우 손쉽게 상태를 복구할 수 있도록 지원하는 연속적인 백업 계획을 보장할 수 있습니다. Hyper-V를 사용한 고가용성 솔루션에 대한 자세한 내용은 이번 호 TechNet Magazine에서 Steven Ekren의 "Hyper-V의 고가용성 실현"(technet.microsoft.com/magazine/cc837977) 기사를 참조하십시오.

마이크로 커널식 하이퍼바이저 아키텍처는 특히 Hyper-V가 Hyper-V 역할로서 구현되어 있을 때 공격 노출 영역을 최소화하고 보안을 향상시키기 위해 디자인되었습니다. Server Core는 Windows Server 2008의 설치 옵션입니다. 하이퍼바이저는 가상 컴퓨터 실행을 위한 안정적이고 간소하며 안전한 기반을 제공하기 위해 장치 드라이버나 타사 코드는 포함하지 않고 있습니다. Hyper-V는 또한 Active Directory 통합을 통해 강력한 역할 기반 보안을 제공합니다. Hyper-V는 또한 가상 컴퓨터의 보안을 더욱 개선할 수 있도록 MX(execute disable) 비트와 같은 하드웨어 수준 보안 기능을 활용할 수 있도록 허용합니다.
Hyper-V는 나머지 Windows Server 구성 요소와 마찬가지로 SDL(Security Development Lifecycle)을 거쳤으며 광범위한 위협 모델링과 분석을 거쳐 매우 안전한 가상화 플랫폼이 되었습니다. Hyper-V를 배포할 때는 Windows Server 2008 배포를 위한 최선의 방법과 Hyper-V를 위한 최선의 방법을 따라야 합니다. 여러분의 계획에 바이러스 백신과 맬웨어 방지 솔루션은 물론 Active Directory를 포함시켜야 합니다. 또한 Hyper-V 호스트를 위한 관리자 액세스 권한을 적절하게 사용할 수 있도록 위임된 관리 기능을 사용하십시오.

관리 효율성
사소한 서버 문제가 중대한 가상 서버로 이어지는 경우가 많습니다. 이러한 문제의 원인은 가상 컴퓨터를 배포하기가 매우 쉽기 때문입니다. 또한 가상 컴퓨터의 이동성이 늘어날수록 다른 가상 컴퓨터가 정확히 어디에서 실행되고 있는지 알아야 하고 해당 보안 컨텍스트를 추적하는 등의 책임이 있습니다.
다행스럽게도 Hyper-V를 사용하면 가상 환경을 위한 별도의 관리 인프라를 만들 필요가 없습니다. 이러한 관리 인프라는 타사 관리 도구는 물론 Microsoft 관리 도구, System Center Virtual Machine Manager 및 Microsoft System Center Operations Manager와 통합됩니다. 이를 통해 사용자의 실제 및 가상 리소스를 모두 한 콘솔에서 관리할 수 있습니다. System Center Virtual Machine Manager 2008에 대한 자세한 내용은 이번 호TechNet Magazine에서 Edwin Yuen의 기사 "VMM 2008로 가상 환경 관리"(technet.microsoft.com/magazine/cc836456)를 참조하십시오. 또한 Windows PowerShell 지원을 통해 작업을 손쉽게 자동화할 수 있습니다.
Hyper-V는 또한 제공되는 하드웨어를 사용하기 위한 이전에 없던 수준의 기능을 가상 컴퓨터에 제공합니다. 부모 파티션에서는 모든 WHQL(Windows Hardware Quality Lab) 인증 드라이버가 실행될 수 있으므로 Hyper-V는 드라이버와 장치에 대한 광범위한 호환경을 제공하여 환경에서 실행되는 다양한 드라이버를 손쉽게 관리할 수 있습니다.

요약
앞서 언급한 것처럼 관리는 개발과 차별화의 핵심 영역이 될 것입니다. 앞으로 몇 년간 이 영역에 많은 활동이 있을 것이며 가상화가 메인스트림 역할에 들어섬에 따라 매우 흥미로운 변화를 목격할 수 있을 것입니다. 아직 Hyper-V를 사용해 보지 않았다면 microsoft.com/Hyper-V에서 자세한 내용을 볼 수 있습니다.
Rajiv Arunkundram은 Microsoft 서버 마케팅 부서에서 서버 가상화를 담당하는 수석 프로그램 관리자입니다. Rajiv의 주요 업무는 고객과 파트너가 기술과 업무 측면에서 Microsoft의 가상화 전략과 솔루션을 이해할 수 있도록 지원하는 것입니다.


Virtualization
VMM 2008로 가상 환경 관리
Edwin Yuen

이 문서는 Virtual Machine Manager 2008의 시험판 버전을 기준으로 작성되었습니다. 여기에 포함된 모든 정보는 변경될 수 있습니다.
한 눈에 보기:
  • VMware VM에 대한 지원
  • Windows PowerShell 기반 스크립팅 및 자동화
  • 통합, 중앙 관리
  • 설치 절차

목차
Virtual Machine Manager 2008 소개
System Center와의 통합
Virtual Machine Manager 2008 설치
VMware ESX 호스트 추가
VMotion 마이그레이션
결론
Microsoft는 작년 Microsoft Virtual Server 2005를 실행하는 가상 인프라 관리를 위한 통합 인터페이스를 제공하는 System Center Virtual Machine Manager 2007을 발표했습니다. 그리고 올해는 새로운 Windows Server 2008 Hyper-V 하이퍼바이저와 VMM(Virtual Machine Manager) 새 버전을 함께 발표했습니다. System Center Virtual Machine Manager 2008은 Microsoft Virtual Server 2005 및 Windows Server 2008 Hyper-V 설치를 관리할 수 있으며 VMware Infrastructure 3(ESX/ESXi) 서버에 대한 확장된 지원도 갖추고 있습니다. 이제 VMM을 통해 Microsoft와 VMware 시스템을 포함하여 전체 가상 인프라에 사용할 수 있는 통합 관리 인터페이스가 마련되었습니다.
VMM은 모든 기존의 가상화 작업을 지원하며 이러한 작업에는 템플릿과 미리 구성된 VM으로부터 신속한 VM(가상 컴퓨터) 배포, P2V(실제 컴퓨터를 가상 컴퓨터로 변환), 가상 인프라 개체의 중앙 라이브러리, VMware 가상 컴퓨터(VMX 구성 파일과 VMDK 가상 디스크)를 Hyper-V VM으로 변환하는 V2V(가상 컴퓨터를 가상 컴퓨터로 변환)가 포함됩니다. 게다가 나머지 System Center 제품군과의 VMM 통합을 통해 실제 시스템과 가상 시스템을 한곳에서 관리할 수 있게 되었습니다.
이 기사에서는 VMM 2008에 대해 살펴보고 IT 관리자가 사용할 수 있는 새로운 기능을 확인할 것입니다. 그런 다음 VMM 설치를 수행하기 위한 요구 사항과 단계를 설명하고, 마지막으로 VMM 2008의 몇 가지 새로운 기능을 사용하는 방법을 자세히 살펴보겠습니다.

Virtual Machine Manager 2008 소개
System Center Virtual Machine Manager 2008은 Microsoft Virtual Server 2005 R2 SP1, Windows Server 2008 Hyper-V, Microsoft Hyper-V Server 2008 및 VMware Infrastructure 3 (ESX/ESXi) 환경에서 실행되는 가상 컴퓨터에 대한 중앙 엔터프라이즈 수준 관리를 제공하는 독립 실행형 응용 프로그램입니다. VMM은 다른 System Center 제품군과 함께 포괄적인 실제 및 가상 인프라 관리를 제공합니다. 그림 1에는 Virtual Machine Manager의 아키텍처 레이아웃이 나와 있습니다.
그림 1 System Center Virtual Machine Manager 2008 아키텍처 (더 크게 보려면 이미지를 클릭하십시오.)
VMM 2007에 익숙한 사용자는 VMM 2008의 VMM 시스템에 인터페이스가 크게 늘어났다는 것을 알 수 있을 것입니다(그림 1 참조). 왼쪽 위 상자는 VMM 2008을 나타내며 오른쪽 위 상자는 System Center Operations Manager 2007을 나타냅니다. 밑에는 관리된 시스템과 인터페이스가 있습니다. 빨간색 상자는 관리 서버를 나타내며 파란색 상자는 시스템 입력을 보여 주고 노란색으로 표시된 관리 개체를 포함하는 초록색 상자는 관리된 호스트 시스템입니다.
왼쪽 위의 빨간색 상자는 Virtual Machine Manager 2008 서버 서비스를 나타냅니다. 이 위에는 서비스로 통하는 인터페이스인 관리자 콘솔, Windows PowerShell 인터페이스, 그리고 위임된 사용자 액세스가 있는 셀프 서비스 웹 포털이 있습니다. Windows PowerShell은 VMM 서버에 대한 모든 액세스의 기반입니다. VMM 관리 콘솔은 완전히 Windows PowerShell을 기반으로 작성되었으므로 간단히 VMM 서버 서비스가 실행하는 Windows PowerShell 스크립트를 만들 수 있습니다. 즉, VMM 2008용 공용 API는 Windows PowerShell이며 모든 프로그램이 Windows PowerShell을 통해 VMM을 활용할 수 있습니다. 이러한 좋은 예로 완전히 Windows PowerShell을 통해 수행된 Citrix의 XenDesktop Desktop Delivery Controller와 Virtual Machine Manager의 통합이 있습니다.
VMM을 지원하는 역할은 SQL Server 2005 또는 SQL Server 2008 데이터베이스가 담당합니다. 데이터베이스에는 전체 설치를 사용할 수 있으며 다른 데이터베이스가 없는 경우에는 SQL Server Express Edition을 사용할 수도 있습니다. 다이어그램에서는 Operations Manager와 Virtual Machine Manager가 모두 SQL Server를 가리키고 있지만 두 프로그램이 데이터베이스를 공유하는 것은 아니며 동일한 버전의 SQL Server에서 실행되고 있는 것뿐입니다. Virtual Machine Manager와 Operations Manager 간의 실질적인 통합은 VMM을 통해 사용 가능한 커넥터를 통해 이루어집니다. 이 커넥터는 VMM과 OpsMgr이 데이터를 공유함으로써 가상화 정보를 OpsMgr로 가져오고 작업을 위해 OpsMgr 데이터를 VMM으로 가져오도록 허용합니다.
다이어그램의 아래쪽 절반에는 관리 호스트가 나와 있습니다. VMM 2008은 VMM 2007과 마찬가지로 Virtual Server 2005 R2 SP1 가상 컴퓨터 호스트와 중앙 라이브러리 공유를 관리합니다. VMM에서 라이브러리 공유는 특수한 파일 저장소나 서버가 아니라 단순히 VMM이 관리하는 Windows 파일 공유입니다. 사용자는 VMM을 통해 라이브러리를 관리하거나 파일 공유에서 파일을 복사 및 삭제하고 VMM이 변경 내용을 감지하도록 할 수 있습니다. 여러 개의 라이브러리를 사용하는 것도 가능하며 이 기능은 위임된 서버 집합 및 원격 사무실에 있는 서버의 경우에 유용합니다.
VMM 2008에는 Hyper-V 및 ESX 하이퍼바이저를 관리하는 기능이 새로 추가되었습니다. WinRM(Windows 원격 관리)과 WMI(Windows Management Instrumentation) 인터페이스를 사용하여 Hyper-V 호스트를 관리할 수 있습니다. 실제로 잠재적인 Hyper-V 호스트가 추가될 때 Windows Server 2008에서 Hyper-V 역할이 활성화되지 않은 경우 VMM이 자동으로 관리자에 대한 이 역할을 활성화합니다. 이 기능은 Windows Server 2003 시스템에서 잠재적인 Virtual Server 호스트의 경우에도 사용 가능합니다.
VMware VI3 ESX 호스트 관리는 VMware VirtualCenter 서버를 통해서 수행됩니다. VMM 2008은 VirtualCenter 웹 서비스 API를 통해 VirtualCenter와 인터페이스를 수행합니다. 따라서 VMware 관리에는 VirtualCenter 서버가 필요하며 대부분의 VMware 엔터프라이즈 설치에는 적어도 하나 이상의 VirtualCenter 서버가 있습니다. VMM 2008에는 여러 VirtualCenter 서버를 관리하는 공유한 기능이 있습니다. VMM은 여러 VirtualCenter 서버를 추가하여 관리자가 전체 VMware 인프라를 집계함으로써 이전에는 불가능했던 단일 엔터프라이즈 뷰를 만들 수 있는 기반을 제공합니다.
VMM은 System Center 제품군의 일부이므로 관리자 콘솔에서 System Center 또는 Outlook 스타일의 인터페이스를 사용합니다. VMM 관리자 콘솔은 MMC 스냅인이 아니며 Windows PowerShell 1.0을 기반으로 Microsoft .NET Framework를 사용하여 작성된 완전히 새로운 응용 프로그램입니다. 실제로 앞에서 언급한 것처럼 관리자 콘솔에서 작업을 수행하면 작업과 연결된 Windows PowerShell 명령이 호출되므로 UI가 실제로 Windows PowerShell을 사용합니다. 관리자 콘솔에서 수행할 수 있는 명령이나 함수는 모두 Windows PowerShell의 명령줄을 통해서도 수행할 수 있습니다.
또한 관리자 콘솔의 각 마법사에는 실행하려는 명령에 연결된 Windows PowerShell 스크립트를 표시하는 스크립트 보기 단추가 있습니다. 이 스크립트를 보면 Windows PowerShell과 VMM이 어떻게 연관되는지 이해하는 데 도움이 됩니다. VMM 2008에 새로 추가된 스크립트 보기 작업을 사용하면 이러한 스크립트를 메모장에서 열 수 있으므로 VMM에서 곧바로 손쉽게 스크립트를 편집할 수 있습니다. VMM 2008에는 편집한 스크립트를 저장하여 VMM 라이브러리에서 다시 사용하는 기능도 추가되었습니다. VMM 2007의 cmdlet은 VMware 서버 지원을 포함하여 VMM 2008에 맞게 업데이트되었습니다. 또한 New-VM과 같은 cmdlet이 Microsoft와 VMware 시스템에서 모두 작동하도록 다른 가상화 플랫폼 간에 동일한 cmdlet을 사용할 수 있도록 했습니다. 즉, IT 관리자는 하나의 cmdlet 집합을 사용하여 Virtual Server, Hyper-V 및 VMware ESX 호스트를 관리할 수 있습니다.
Virtual Machine Manager 2008은 IT 관리자에게 다음과 같은 세 가지 중요한 혜택을 제공하도록 디자인되었습니다.
  • 리소스 극대화
  • 유연성 향상
  • 기존 기술 활용
이러한 혜택은 여러 특성과 기능을 통해 더욱 커집니다. 첫째, VMM은 하이퍼바이저에 관계없이 사용자의 전체 가상 인프라 관리를 통합함으로써 리소스를 극대화할 수 있도록 지원합니다. VMM 2008은 Microsoft와 VMware 시스템을 통합함으로써 그림 2에 나와 있는 것처럼 모든 호스트와 가상 컴퓨터를 단일 보기에서 보여 주고, 관리자가 호스트, 운영 채제, 소유자, 추가한 날짜 등의 매개 변수로 자신의 시스템을 필터링하고 볼 수 있도록 해 줍니다.
그림 2 통합된 Microsoft 및 VMware 관리를 보여 주는 VMM 콘솔 (더 크게 보려면 이미지를 클릭하십시오.)
VMM은 또한 P2V 및 V2V와 같은 변환으로 손쉬운 서버 통합을 가능하게 하여 시스템 리소스 극대화를 지원합니다. P2V를 사용하여 기존의 실제 컴퓨터를 가상 컴퓨터로 통합할 수 있으며 이러한 컴퓨터를 다시 설치할 필요가 없습니다. P2V를 통해 하나의 실제 하드웨어에 기존의 실제 컴퓨터 여러 개를 배치하여 리소스를 극대화할 수 있으므로 하드웨어 사용률이 낮은 컴퓨터를 변환하는 경우에 특히 유용합니다. P2V는 VMM의 통합된 기능이며 추가 소프트웨어나 서버 없이도 사용할 수 있습니다. VMM 2008에서는 Windows Vista, Windows Server 2008 및 x64 호스트를 포함하여 많은 수의 실제 시스템에 대한 지원이 추가되었습니다. VMM의 P2V 기능은 서버 통합을 위한 후보 식별을 지원하는 MAP(Microsoft Assessment and Planning) 도구(이번 호 TechNet Magazine에서 Baldwin Ng와 Jay Sauls의 기사 참조)와 같은 계획 수립 도구의 훌륭한 동반자입니다.
VMware VMDK 형식의 가상 컴퓨터가 이미 있는 경우 VMM의 V2V 변환 기능을 사용하여 기존 VMDK를 VHD 형식으로 변환할 수 있습니다. 이는 오프라인 프로세스이며 V2V 프로세스가 실제 VMDK 파일을 VHD로 변환하므로 VMware VM을 종료해야 합니다. 실행 중인 VMware VM을 P2V 기능을 사용하여 변환할 수도 있습니다. 다소 혼란스러울 수 있지만 가상 컴퓨터는 가상화되었지만 역시 하나의 컴퓨터입니다. 다른 모든 시스템과 마찬가지로 VMM의 P2V 기능 역시 VM을 실행 중인 컴퓨터로 보며, 가상화 소프트웨어에서 실행 중인 VM을 Microsoft VHD로 변환할 수 있습니다.
VMM은 몇 가지 기능을 통해 IT 관리자에게 상당한 민첩성을 제공합니다. VMM의 핵심 기능 중 하나는 한 호스트에서 다른 호스트로 VM을 마이그레이션하는 기능이며 이를 통해 높은 가용성과 서버 최적화를 이룰 수 있습니다. Hyper-V 호스트와 VMM 2008은 단 몇 초간의 가동 중지 시간 내에 Hyper-V 호스트 사이에서 VM을 이동하는 빠른 마이그레이션을 지원합니다. 이 기능을 사용하려면 Windows Server 2008 클러스터와 공유 저장소가 필요하지만 VMM이 관리와 구성을 도와 줍니다.
VMware ESX 호스트와 VMM 2008은 사용자가 인식할 수 없을 정도로 짧은 가동 중지 시간 내에 VM을 이동하는 VMware 기능인 VMware VMotion을 지원합니다. 이 경우에는 빠른 마이그레이션과 마찬가지로 클러스터 및 SAN 백 엔드인 VMotion 지원 VMware ESX 호스트가 필요합니다. 이 기사 뒷부분에서 VMM 2008에서 VMotion을 사용하는 과정을 살펴보겠습니다.
마지막으로 VMM 2008은 기존 Virtual Server 2005 VM을 Hyper-V 호스트로 마이그레이션하며 마이그레이션에 필요한 모든 업그레이드와 변환을 자동으로 수행할 수 있습니다.
VMM은 변환이나 새로운 배포를 통해 시작되는 모든 VM 배포(앞에서 설명한 마이그레이션 포함)의 일부로서 지능형 배포라고 하는 프로세스를 사용하여 VM을 호스트에 배포합니다. VMM은 또한 지능형 배포를 통해 자신이 관리하는 모든 가상 컴퓨터 호스트를 쿼리하고 이러한 호스트의 리소스 가용성에 대한 몇 가지 매개 변수를 검색한 다음 VM을 배포하는 데 적합한 권장 호스트 가중치 목록을 반환합니다. 그림 3에 나와 있는 것처럼 지능형 배포는 Microsoft와 VMware 호스트를 해당 저장소 구성을 포함하여 지원합니다. VMM 2008의 지능형 배포는 플랫폼과 구성을 모두 인식할 수 있습니다. 따라서 올바른 호스트 플랫폼에 맞는 호스트만 권장하며 고가용성이 필요한 경우에는 클러스터형 호스트만, 그리고 x64 VM의 경우에는 x64 가능 호스트만 권장합니다.
그림 3 사용 가능한 모든 호스트를 분석하는 지능형 배포 (더 크게 보려면 이미지를 클릭하십시오.)

System Center와의 통합
VMM 2008의 핵심 기능 중 하나는 System Center Operations Manager 2007과의 통합입니다. VMM 2007에도 Operations Manager와의 통합에 대한 지원이 어느 정도 있었지만 VMM 2008에는 통합의 기능을 크게 개선하는 Operations Manager용 제품 커넥터가 포함되어 있습니다. VMM은 Operations Manager와의 통합을 통해 관리 콘솔에서는 물론 PRO(성능 및 리소스 최적화)라는 새로운 기능을 사용하여 통합된 작업 관리자 보고서를 제공할 수 있습니다.
VMM 2008은 PRO를 통해 PRO 팁이라고 하는 알림을 생성할 수 있으며 Operations Manager에서의 모니터링 매개 변수를 바탕으로 자동 해결 작업을 수행할 수도 있습니다. 그림 4에는 몇 가지 PRO 팁 예가 나와 있습니다. VMM 2008은 PRO 사용 관리 팩(PRO pack)을 사용하여 VM을 마이그레이션하는 작업은 물론 호스트, 하이퍼바이저, 하드웨어, 그리고 심지어 워크로드 기반 성능 매개 변수를 바탕으로 새로운 VM을 생성하는 작업을 처리할 수 있습니다.
그림 4 가상 인프라에서 발생한 문제에 대한 알림과 해결을 제공하는 PRO 팁 (더 크게 보려면 이미지를 클릭하십시오.)

Virtual Machine Manager 2008 설치
System Center VMM 2008 설치를 수행하는 데 필요한 몇 가지 필수 구성 요소와 새로운 시스템 요구 사항이 있습니다. 첫째, VMM 2008 서버에는 Windows Server 2008 x64가 필요합니다. 서버는 Windows Server 2003이나 x86 버전의 Windows Server 2008에는 설치되지 않습니다. 관리 콘솔과 다른 구성 요소는 여전히 Windows Server 2003 및 Windows XP 또는 Windows Vista(콘솔의 경우)에 설치할 수 있으며 VMM 2007과 동일한 요구 사항과 설치 절차가 적용됩니다.
둘째, VMM 2008은 자체 보안 모델을 위해 Active Directory 도메인에 설치해야 합니다. VMM 2008은 VMM 2008에 새로 추가된 도메인이 아닌 시스템에 대한 P2V를 포함하여 경계 네트워크(도메인에 가입하지 않은) 호스트의 관리를 지원합니다. 설치 플랫폼으로 Windows Server 2008을 사용할 때의 장점 중 하나는 VMM을 위한 필수 구성 요소(예: .NET Framework 3.0, WinRM 및 Windows PowerShell 1.0)가 대부분 이미 기본 제공된다는 것입니다. 마지막으로 VMM 2008 설치 관리자에 설치 파일이 포함되어 있기는 하지만 VMM 2008에는 WAIK(Windows Automated Installation Kit) 3.0이 필요합니다.
프로덕션 환경에서는 각 VMM 구성 요소를 별도의 서버에 설치하는 것이 좋지만 여기에서는 단일 서버 설치에 대해 설명하겠습니다. VMM 서버 설치 시 권장 하드웨어는 2GB 이상의 RAM이 설치되어 있고 2.8GHz 이상 속도로 실행되는 x64 기반 서버입니다. 여기서는 로컬 SQL 데이터베이스가 포함된 단일 서버 설치를 사용하므로 하드 디스크 공간 7GB가 필요합니다. 원격 데이터베이스를 사용하는 경우 VMM 설치 자체에는 하드 디스크 공간이 1GB면 충분합니다. 여기에 로컬 라이브러리 설치를 위해 추가 디스크 공간 80GB를 확보하는 것이 좋습니다.
앞서 언급했듯이 VMM은 Windows Server 2008 x64 설치에서 실행됩니다. 추가 소프트웨어 요구 사항으로는 .NET Framework 3.0, Windows PowerShell 1.0, WinRM이 있으며 셀프 서비스 포털을 위해 IIS 6.0 이상이 필요합니다. Microsoft MSXML 6.0 파서도 필요하지만 .NET Framework 3.0의 일부로 포함되어 있습니다.
VMM 설치를 시작하면 Virtual Machine Manager 서버, 관리자 콘솔, 셀프 서비스 포털, 로컬 에이전트, 그리고 Operations Manager 관리 팩을 구성하는 모두 5가지 옵션이 제공됩니다. 언급한 것처럼 여기에서는 VMM 서버부터 시작하여 모든 구성 요소를 단일 컴퓨터에 설치할 것입니다. 설치가 시작되면 첫 번째 화면에서는 시스템 필수 구성 요소를 검사합니다.
이전에 언급한 요구 사항 외에도 컴퓨터는 반드시 도메인에 속해 있어야 합니다. VMM 서버 설치는 자동으로 기본 제공 기능을 활성화하므로 사용자가 수동으로 이를 활성화할 필요가 없습니다.
설치 관리자를 시작한 다음에는 Windows Update 옵션을 사용하여 VMM 2008이 최신 버전인지 확인하는 것이 좋습니다. 그런 다음 설치 관리자는 주로 SQL 데이터베이스 설치와 관련된 옵션들을 검토합니다. 여기서는 SQL Server 2005 Express Edition을 사용하겠습니다.
그런 다음 마법사는 중앙 라이브러리의 위치를 지정하도록 요구합니다. 이 위치는 VMM 서버의 로컬 디렉터리(이 경우 해당 디렉터리에 대한 공유가 생성됨)이거나 기존 파일 공유의 디렉터리일 수 있습니다. 기본 위치는 C:\ProgramData\Virtual Machine Manager Library Files입니다.
다음은 포트를 할당하는 단계이며 여기에서는 관리자 콘솔이 핵심 VMM 서버 서비스에 연결하는 데 사용할 포트(기본값 포트 8100), WinRM이 관리 기능을 수행하는 데 사용할 포트(기본값 포트 80), BITS(Background Intelligent Transfer Service)가 파일을 가상 컴퓨터 호스트로 이동하는 데 사용할 포트(기본값 포트 443)를 구성합니다. 이러한 정보를 모두 입력하면 요약 화면이 표시되고 서버 설치를 마칠 수 있습니다.
다음은 관리자 콘솔을 설치할 차례이며 이 항목의 시스템 필수 구성 요소는 VMM 서버와 비슷합니다. 설치 디렉터리를 제외하고 제공되는 유일한 구성 옵션은 VMM 서버 서비스에 연결하는 데 사용되는 통신 포트를 확인하는 것입니다. 이 포트는 VMM 서버 설치 시 구성한 포트 8100입니다.
설치 마지막 단계에서 관리자 콘솔의 바탕 화면 바로 가기를 만드는 옵션과 설치 프로그램을 닫으면 콘솔을 여는 옵션이 표시됩니다. 두 가지를 모두 선택하는 것이 좋습니다. 처음으로 관리자 콘솔을 열면 서버에 연결한다는 메시지가 표시됩니다. 단일 서버 설치의 경우에는 로컬 호스트의 포트 8100이 사용되며 간단히 Enter 키를 눌러 콘솔을 시작할 수 있습니다.
마지막으로 셀프 서비스 포털을 설치할 차례입니다. 이를 위한 필수 구성 요소는 IIS 6.0이나 7.0, .NET Framework 3.0, 그리고 Windows PowerShell 1.0입니다. Windows PowerShell이 필요한 이유는 셀프 서비스 포털이 말하자면 Windows PowerShell을 사용하는 핵심 VMM 서비스에 대한 인터페이스이기 때문입니다. Windows Server 2008의 경우에는 VMM 2008 설치를 시작하기 전에 IIS 역할을 활성화해야 합니다. 이때 다음과 같은 IIS 역할 서비스가 활성화되어 있는지 확인해야 합니다.
  • 일반 HTTP 기능(정적 콘텐츠, 기본 문서, 디렉터리 검색, HTTP 오류)
  • 응용 프로그램 개발 (ASP.NET, .NET 확장성, ISAPI 확장, ISAPI 필터)
  • 보안(요청 필터링)
  • IIS 6.0 관리 기능
이러한 역할 서비스가 활성화되어 있으면 설치의 필수 구성 요소 검사가 성공하여 설치를 계속할 수 있습니다. 설치 중에 구성 옵션은 셀프 서비스 포털이 사용하는 포트만 처리합니다. 먼저 관리자 콘솔을 설치할 때와 마찬가지로 핵심 VMM 서비스에 연결하는 데 사용할 포트로 8100을 지정합니다. 다음은 포털을 실행할 포트를 지정해야 하며 기본값은 포트 80이지만 이 포트가 이미 사용 중인 구성이 많고 이러한 경우 VMM 설치 관리자가 경고를 표시합니다. 필요한 경우 8080과 같이 열려 있는 다른 포트로 변경합니다. 이제 설치 관리자는 Microsoft System Center Virtual Machine Manager 2008 Self-Service Portal Home이라고 하는 웹 사이트를 생성합니다. 구성은 Server Manager에서 변경할 수 있습니다.
IIS 설치가 완료되면 Internet Explorer에서 http://localhost:8080으로 이동하여 간단하게 웹 사이트를 열 수 있습니다. 웹 사이트를 열 때 Internet Explorer 보안 설정으로 인해 인증 요청 메시지가 표시될 수 있습니다. 셀프 서비스 포털은 Internet Explorer에서 인트라넷 컨텍스트로 실행되어야 하므로 Internet Explorer에서 인트라넷 사이트 목록에 VMM 서버를 추가해야 할 수도 있습니다. 이러한 구성을 완료하고 나면 VMM 2008에서 셀프 서비스 사용 VM을 만들고 사용할 수 있습니다.

VMware ESX 호스트 추가
VMM 2008에는 새로운 기능이 많이 있지만 가장 많은 기대를 모았던 것은 아마도 VMware ESX 호스트 관리 지원의 추가일 것입니다. 이 지원이 추가됨에 따라 이제 VMM은 엔터프라이즈 IT 부서에서 가상 많이 사용되는 가상 인프라를 관리할 수 있게 되었습니다.
ESX 호스트를 Virtual Machine Manager 2008에 추가하는 과정을 상당히 간단합니다. 앞에서 언급한 것처럼 VMM 2008은 VirtualCenter 서버를 통해 VMware 호스트를 관리하며 이때 VirtualCenter 서버는 버전 2.0.1이거나 2.5여야 합니다. VMware ESX 서버를 관리 콘솔에 추가하려면 작업 창 오른쪽 위에 있는 Add VMware VirtualCenter Server(VMware VirtualCenter 서버 추가) 작업을 사용하여 VirtualCenter 서버를 추가할 수 있습니다.
마법사가 시작되면 VirtualCenter 서버의 관리 계정과 함께 VirtualCenter 서버의 컴퓨터 이름을 입력합니다. 그러면 VMM은 VirtualCenter의 기존 호스트 그룹 구조를 포함하여 ESX 호스트를 VMM 인터페이스에 추가합니다. 이 과정은 몇 분이 걸릴 수 있지만 VMM 작업 메뉴에서 진행 과정을 모니터링할 수 있습니다.
모든 서버를 가져온 다음에는 VirtualCenter에서와 마찬가지로 VMM에서도 동일한 VMware ESX 호스트 서버 구조를 볼 수 있게 됩니다. 다른 VirtualCenter 서버를 추가하려면 간단히 과정을 반복하면 됩니다. 호스트 구조를 VMM에 추가한 다음에는 VMware 이외 서버를 동일한 그룹 구조에 추가할 수 있습니다. 물론 VMware 이외 서버는 VirtualCenter에는 표시되지 않습니다.
VMM 2008은 VirtualCenter를 사용하여 ESX 호스트를 관리하지만 V2V, 상태 저장, ESX 호스트에서 VM 복제와 같은 일부 기능을 위해서는 ESX 호스트 자체에 직접 액세스해야 합니다. 따라서 VMM에 VirtualCenter 서버가 추가되면 호스트는 양호(제한됨)로 표시됩니다. 완전한 관리를 활성화하려면 VMM에서 개발 ESX 호스트의 속성 페이지로 이동한 다음 서버를 직접 관리하는 데 필요한 적절한 호스트 자격 증명을 제공해야 합니다.

VMotion 마이그레이션
Virtual Machine Manager 2008에서의 VMware 관리에 대해 논의할 때마다 VMM이 VMotion 및 다른 VirtualCenter 기능을 수행할 수 있는지에 대한 질문을 받게 되는 경우가 있습니다. VMM은 VMware 관리를 위해 VirtualCenter를 사용하므로 이 질문에 대한 대답은 예입니다!
VMM은 기능상으로 VMotion을 다른 마이그레이션과 마찬가지로 처리합니다. VMotion을 시작하려면 먼저 이동하려는 VM을 선택한 다음 VMM의 오른쪽에 있는 작업 창에서 가상 컴퓨터 마이그레이션 옵션을 선택합니다. 이를 완료하면 VMM은 그림 5에 나와 있는 것처럼 해당 VM에 대한 지능형 배포 창을 열고 전송 형식이 라이브인 잠재적인 대상 호스트를 보여 줍니다. 지능형 배포는 VM의 올바른 대상 호스트를 선택하는 데 도움을 제공합니다. 이것은 Hyper-V 호스트를 사용하여 빠른 마이그레이션을 수행하는 것과 동일한 프로세스입니다.
그림 5 VMotion에서 지능형 배포 사용 (더 크게 보려면 이미지를 클릭하십시오.)
VM에 대한 대상 호스트(이 경우에는 cqaesxi003.contoso.com이라는 서버)를 선택하고 다음을 클릭합니다. 그림 6에 나온 최종 요약 창에는 요청된 작업이 표시됩니다.
그림 6 VMotion 요약 창 (더 크게 보려면 이미지를 클릭하십시오.)
앞서 언급했듯이 VMM의 각 마법사에는 작업의 Windows PowerShell 스크립트를 메모장에서 볼 수 있는 스크립트 보기 단추가 있습니다. 이 기능을 사용하면 VMM 2008에서 Windows PowerShell과 VMware가 어떻게 연동되는지 알아볼 수 있습니다. 다음은 이 작업을 위한 스크립트입니다.
$VM = Get-VM -VMMServer localhost -Name "MyVM" |
  where {$_.VMHost.Name -eq "cqaesxi003.contoso.com"}
$VMHost = Get-VMHost -VMMServer localhost |   where {$_.Name -eq "cqaesxi003.contoso.com"}
Move-VM -VM $VM -VMHost $VMHost –RunAsynchronously
세 개의 간단한 명령이 이 시스템을 위한 VMotion을 수행합니다. 이 예에서 필자는 MyVM이라는 VM을 VMware 서버 cqaesxi003.contoso.com에서 cqaesxi001.contoso.com으로 옮기고 있습니다. 첫 번째 명령은 VMotion을 통해 마이그레이션할 가상 컴퓨터를 식별합니다. 여기에서 볼 수 있듯이 이 명령줄에서 필자는 변수 $VM에 가상 컴퓨터 값을 할당했습니다.
$VM = Get-VM -VMMServer localhost -Name "MyVM" |
  where {$_.VMHost.Name -eq " cqaesxi003.contoso.com"}
두 번째 명령은 VM에 대한 대상 ESX 호스트 시스템을 식별합니다. 이 줄에서 변수 $VMHost에 ESX 호스트 cqaesxi003.contoso.com을 할당합니다.
$VMHost = Get-VMHost -VMMServer localhost | where
  {$_.Name -eq " cqaesxi003.contoso.com"}
마지막으로 최종적으로 Move-VM 명령을 사용하여 VM을 이동합니다. 다은 Move-VM의 완전한 명령줄과 매개 변수입니다.
Move-VM [-VM] [<String VM>] -VMHost [<String Host>]
  [-JobGroup <Guid>] [-JobVariable <String>] [-Path
  <String>] [-PROTipID] [-RunAsynchronously]
  [-StartVMOnTarget <Boolean>] [-UseLAN <Boolean>]
  [<CommonParameters>]
이 명령은 Virtual Machine Manager의 다른 유형 관리 개념에 따라 특정 공급업체나 소프트웨어 전용이 아니라는 것을 알 수 있습니다. VMotion을 완료하는 데는 다음 명령을 수행합니다.
Move-VM -VM $VM -VMHost $VMHost –RunAsynchronously
이 명령은 $VM의 VM에 대해 Move-VM을 실행하여 $VMHost의 호스트 시스템을 이동하며 이러한 작업을 비동기적으로 실행하도록 VMM에 알려 줍니다. 작업이 시작되면 VMM의 작업 창에서 전체 프로세스를 모니터링할 수 있습니다. 이 경우에도 Hyper-V 클러스터에서 빠른 마이그레이션에 이 같은 기본 명령을 수행할 수 있으며 비클러스터형 호스트에도
여기에서 볼 수 있듯이 System Center Virtual Machine Manager 2008은 새로운 관리 플랫폼과 새로운 기능으로 Virtual Machine Manager 2007의 훌륭한 특성과 기능을 확장했습니다. 설치 프로세스와 두 가지 기능을 살펴봄으로써 VMM 2008에서 여러 하이퍼바이저를 얼마나 쉽게 관리할 수 있는지를 이해하는 기회가 되었기를 바랍니다.
VMM 2008은 Microsoft와 VMware의 실제 컴퓨터와 가상 컴퓨터를 단일화하는 가상화용 통합 관리 소프트웨어로 디자인되었습니다. 이 새로운 버전의 Virtual Machine Manager를 통해 VMware 관리자, Microsoft Virtual Server 2005 관리자, 그리고 새로운 Hyper-V 관리자는 단일 도구와 단일 스크립팅 인터페이스, 그리고 무엇보다 가상 인프라를 위한 단일 관리 프로세스를 활용할 수 있게 되었습니다.

Edwin Yuen은 Windows Enterprise Management 부서에서 System Center Virtual Machine Manager의 기술 제품 관리자로 근무하고 있으며, 2006년 7월 Microsoft가 Softricity를 인수함에 따라 Microsoft에서 근무하게 되었습니다. Edwin은 기업 및 정부 산하 기관에서 13년간 기술 자문 업무를 담당했으며, Johns Hopkins 대학에서 전기 공학 학사 학위를 받았습니다.


Virtualization
Microsoft Application Virtualization 시작
Anthony Kinney

이 문서는 App-V의 시험판 버전을 기준으로 작성되었습니다. 여기에 포함된 모든 정보는 변경될 수 있습니다.
한 눈에 보기:
  • App-V 아키텍처
  • 가상 응용 프로그램 관리
  • App-V 시퀀서 사용
  • 구성 관리자로 App-V 통합

목차
App-V 아키텍처
App-V 전체 인프라 작동 원리
가상 응용 프로그램 업데이트
시퀀스
버전 4.5
필자에게 Microsoft Application Virtualization(또는 App-V)은 매우 중요한 의미가 있습니다. App-V는 이전에는 SoftGrid로 알려졌으며 개발사인 Softricity를 Microsoft가 인수함에 따라 필자도 Microsoft로 자리를 옮겼습니다. 인수 이후로 많은 것이 달라졌기 때문에 TechNet Magazine에서 새로운 기사를 쓸 수 있는 기회를 갖게 되어 상당히 흥분됩니다.
App-V에 접근하는 가장 좋은 방법은 IT 전문가가 기업을 관리하는 데 당면한 과제에 대해 이야기하는 것입니다. 오늘날 비즈니스 데스크톱은 응용 프로그램으로 가득 차있습니다. 응용 프로그램을 설치하려면 그전에 시스템에 설치되어 있는 다른 응용 프로그램과 공존하고 다른 응용 프로그램이 올바르게 실행하는 데 영향을 주지 않는지 확인하는 장시간의 회기 테스트를 수행해야 합니다. 응용 프로그램은 프로덕션 단계에 이르기 전에 일련의 배포 프로세스를 거쳐야 합니다. 또한 기본적으로 설치된 위치에서만 응용 프로그램을 사용할 수 있기 때문에 사용자가 특정 컴퓨터에 묶이게 됩니다. 이러한 문제 때문에 OS와 운영 체제 마이그레이션, 보안 갱신 및 재해 복구 계획과 같은 복잡한 프로젝트가 더욱 복잡해집니다.
App-V로 이러한 모든 문제를 해결할 수 있습니다. App-V를 사용하면 데스크톱 관리를 리소스가 소비되고 시간이 걸리는 일련의 복잡한 단계가 아니라 간단하고 자동화된 프로세스로 만들 수 있습니다. 또한 응용 프로그램을 더 쉽고 효과적으로 배포, 패치, 업데이트 및 종료할 수 있습니다.
App-V를 사용하면 사용자가 어떤 데스크톱에서도 자신의 응용 프로그램에 액세스할 수 있습니다. 응용 프로그램은 주문형으로 제공되지만 로컬에 설치된 것처럼 실행됩니다. 따라서 응용 프로그램 구성 요소를 설치하거나 호스트 장치를 변경할 필요가 없습니다.
이렇게 가상화를 사용하면 IT 전문가가 데스크톱을 관리하는 방법을 크게 변화시킬 수 있습니다. 호스트 장치를 변경할 필요가 없이 가상화된 응용 프로그램을 실행할 수 있기 때문에 다음을 포함한 다양한 장점이 있습니다.
  • 응용 프로그램 충돌이 감소합니다.
  • 응용 프로그램 업데이트가 신속하고 쉬워집니다.
  • 같은 응용 프로그램의 여러 버전을 함께 실행할 수 있습니다.
  • 온라인과 오프라인에 사용자를 따라다니는 유연한 응용 프로그램이 가능합니다.
  • 응용 프로그램-응용 프로그램 회귀 테스트가 감소합니다.

App-V 아키텍처
다음은 App-V 플랫폼 내부에서 어떤 일이 일어나는지 살펴보겠습니다. 플랫폼은 시퀀서, 데이터베이스, 클라이언트, 관리 서버, 스트리밍 서버 및 관리 콘솔의 몇 가지 주요 구성 요소로 이루어져 있습니다(그림 1 참조).
그림 1 App-V 환경 레이아웃 (더 크게 보려면 이미지를 클릭하십시오.)
App-V 시스템의 핵심에는 App-V 클라이언트가 있습니다. 클라이언트에는 터미널 서버 클라이언트와 데스크톱 클라이언트의 두 가지 유형이 있습니다. 모든 데스크톱과 가상 응용 프로그램을 배포하려는 터미널 서버에 둘 중 한 가지 클라이언트를 설치해야 합니다. 클라이언트는 비교적 적은 디스크 공간을 차지합니다. 클라이언트는 드라이버 하나를 설치하며 트레이 표시기로 표시되는 시각적인 사용자 런타임 구성 요소를 포함합니다.
클라이언트는 App-V 관리 서버에서 가상 응용 프로그램 목록을 수집하고 사용 가능한 가상 응용 프로그램을 표시합니다. 또한 이러한 응용 프로그램 시작(사용자가 시작할 때)을 처리하고 클라이언트 쪽 캐시를 관리합니다. 클라이언트는 또한 가상 런타임 환경 생성을 관리하는 역할을 담당하며 각 환경이 자체 가상 버블 내에서 실행되도록 보장합니다. 이 가상 환경에는 가상 레지스트리, 가상 파일 시스템 및 가상 서비스 관리자를 포함하여 몇 가지 구성 요소가 포함됩니다.
App-V 4.5에서는 전체 인프라, 경량 인프라 및 독립 실행형 모드의 세 가지 인프라 배포 옵션을 사용할 수 있습니다. 전체 인프라를 배포하면 백 엔드에 App-V 관리 서버와 App-V 스트리밍 서버(새로운 구성 요소로서 뒷부분에서 설명)가 포함됩니다. App-V 관리 서버는 중앙 집중화된 가상 응용 프로그램을 호스트하고 제공하며 패치나 업데이트가 제공되며 가상 응용 프로그램을 업데이트합니다.
이 관리 서버는 가상 응용 프로그램의 구성과 설정을 포함하는 App-V 데이터베이스를 호스트하기 위해 SQL Server를 사용합니다. 가상 응용 프로그램 프로비전 및 사용 권한 제어를 위한 중앙 관리 도구로는 Active Directory 그룹을 사용해야 합니다.
App-V 플랫폼은 IIS가 설치되어 있으면 동일한 서버에서 로드하여 설정과 구성을 관리할 수 있는 Microsoft .NET Framework 웹 서비스를 제공합니다. 이 웹 서비스는 MMC(Microsoft Management Console) 스냅인인 App-V 관리 콘솔과 App-V 데이터베이스 간의 연락망 역할을 합니다. 관리자는 이 콘솔을 사용하여 가상 응용 프로그램을 게시 및 관리하고, Active Directory 그룹을 할당하며, 서버 설정을 제어하는 것은 물론 가상화된 응용 프로그램 사용에 대한 보고서를 실행할 수 있습니다(그림 2 참조).
그림 2 관리 콘솔(더 크게 보려면 이미지를 클릭하십시오.)
경량 인프라에는 활성/패키지 업그레이드와 같은 스트리밍 기능을 활성화하는 App-V 스트리밍 서버가 포함됩니다. 이 옵션은 Active Directory나 SQL Server를 요구하지 않으며, 데스크톱 구성 서비스는 없고, 라이선스 및 측정 기능이 빠져 있습니다. 그러나 경량 인프라를 사용하더라도 SCCM(System Center Configuration Manager) 및 다른 타사 ESD(엔터프라이즈 소프트웨어 배포) 솔루션에 스트리밍 기능을 추가할 수 있습니다.
독립 실행형 모드에서 App-V 시퀀서는 가상 응용 프로그램 추가를 자동화하는 MSI 파일을 생성할 수 있습니다(그림 3 참조). MSI 파일에는 모든 ESD 시스템에서 인식하고 가상화된 응용 프로그램을 제어할 수 있는 메타데이터가 포함되어 있습니다. 이 모드에서는 클라이언트를 가상 응용 프로그램의 MSI 기반 업데이트만 허용되는 독립 실행형 모드로 전환해야 하며, 독립 실행형 모드에서는 스트리밍은 허용되지 않습니다. 이 모드는 조직에 App-V 격리 기능을 사용할 수 있는 기능을 제공합니다.
그림 3 App-V 시퀀서 (더 크게 보려면 이미지를 클릭하십시오.)
MSI 파일은 매우 유연하며 App-V 클라이언트만 있으면 완전히 독립 실행형으로 실행할 수 있고 서버 구성 요소를 전혀 요구하지 않습니다. 따라서 MSI 파일을 디스크를 사용하거나 기존의 배포 도구를 사용하여 수동으로 배포할 수 있습니다.
App-V 4.5에서는 이제 스트리밍에 HTTP와 HTTPS 프로토콜이 지원됩니다. 이에 따라 널리 사용되는 프로토콜를 통해 특히 보안 WAN(광역 네트워크)와 인터넷을 통한 스트리밍에서 스트리밍의 성능을 개선할 수 있습니다.

App-V 전체 인프라 작동 원리
사용자가 클라이언트(App-V 터미널 서비스 또는 데스크톱 클라이언트) 중 하나가 설치된 장치에 로그온하면 클라이언트는 현재 사용자에 할당된 응용 프로그램 목록을 서버에 요청합니다. 서버는 Active Directory와 통신하여 사용자가 어떤 그룹의 구성원인지 확인하고 응용 프로그램 목록을 클라이언트에 반환합니다. 클라이언트는 해당하는 특정 사용자에 할당된 가상 응용 프로그램에 대한 광고를 작성하기 시작합니다.
이 게시 프로세스에서 몇 가지 작업이 수행됩니다.
  • 구성 파일이 복사됩니다.
  • 데스크톱 아이콘이 생성됩니다.
  • 보내기 링크가 생성됩니다.
  • 시작 메뉴 폴더가 생성됩니다.
  • 파일 형식이 구성됩니다.
이 프로세스는 매우 신속하게 수행되며 무엇보다 중요한 것은 사용자는 예상하는 것과 시각적으로 완전히 동일한 환경을 보장한다는 것입니다. 가상 응용 프로그램은 로컬에 설치된 것처럼 작동하지만 물론 호스트 컴퓨터를 변경하지는 않습니다. 아이콘은 Program Files 디렉터리에 있는 실행 파일을 가리키는 것이 아니라 해당 구성을 위해 실행 관리자 파일(OSD 파일)을 사용하는 App-V 클라이언트를 가리킵니다.
중요한 것은 이 프로세스는 기존의 소프트웨어 배포와는 달리 설치되는 요소가 없기 때문에 네트워크에 미치는 영향이 매우 적다는 것입니다. 이 방식은 사용자에게 응용 프로그램을 제공하면서도 응용 프로그램이 시작되기 전까지는 아무것도 전달하지 않으므로 로밍 사용자 환경에 특히 유용합니다. 또한 App-V의 주문형 및 로밍 응용 프로그램 기능을 제공하는 것도 이러한 광고 방식입니다.
사용자가 응용 프로그램을 시작하면 클라이언트는 로컬 컴퓨터에 저장된 OSD 구성 파일을 읽습니다. 클라이언트는 구성 파일에서 App-V 관리 서버와 통신할 때 어떤 프로토콜을 사용해야 하며 응용 프로그램이 어떤 서버에 있는지에 대한 정보를 얻습니다.
해당 서버는 클라이언트에 초기 시작 임계값을 스트리밍 전송하여 응답하며 이것은 일반적으로 전체 응용 프로그램의 20–40%에 해당하는 양입니다. 전체 시작 임계값이 스트리밍되면(이번에도 응용 프로그램의 20–40%) 가상 응용 프로그램을 실행할 준비가 됩니다.
스트리밍은 App-V를 통해 도입된 패러다임의 전환에 중요한 핵심 요소 중 하나입니다. 이를 통해 귀중한 네트워크 대역폭을 낭비하지 않고 응용 프로그램을 실행하는 데 필요한 만큼만 전송할 수 있습니다. 클라이언트로 전달되는 모든 데이터는 장치의 로컬 캐시 파일에 보관되며 이후에 응용 프로그램을 시작하면 이 로컬 캐시에서 시작하므로 추가적인 네트워크 트래픽이 발생하지 않습니다.
가상 응용 프로그램 스트리밍이 완료되면 클라이언트는 응용 프로그램이 로컬 컴퓨터를 변경하는 것을 방지하는 격리된 환경을 만듭니다. 다른 말로 하면 응용 프로그램은 클라이언트에 흔적을 남기지 않습니다. 그러나 클라이언트는 가상 응용 프로그램이 파일을 저장하거나 편집할 때 로컬 파일 시스템에 액세스할 수 있도록 허용하며, 사용자가 로컬 시스템에 적절한 사용 권한이 있는 경우에는 인쇄와 같은 로컬 서비스와 상호 작용하는 것도 허용합니다. 그러나 가상 응용 프로그램이 로컬 시스템의 파일과 레지스트리에 수행한 변경 내용은 가상화된 환경으로 리디렉션되어 호스트 장치는 변경되지 않습니다.
응용 프로그램이 실행될 때 이전에 사용되지 않은 기능은 필요할 때 전달되며 이후 사용을 위해 캐시됩니다. 이 방식의 장점은 초기 시작 시에 사용자에게 필요한 기능만 로드되며 필요하지 않은 기능은 네트워크 리소스를 소비하지 않는다는 것입니다. 새로운 버전은 더 영리한 캐시 이용과 배경 스트리밍을 지원하는 몇 가지 클라이언트 쪽 캐싱 기능 향상을 제공합니다.
Microsoft Office Word를 예로 들어 보겠습니다. Word의 맞춤법 검사기(이 기능이 없었으면 이 기사도 쓰지 못했을 것입니다!)는 거의 모든 사용자가 사용하므로 이 기능은 초기 시작에 포함되어야 합니다. 하지만 Word의 도움말 기능은 어떻습니까? 이 기능을 사용하는 사용자는 그리 많지 않기 때문에 이 기능은 초기 시작 시에 전달할 필요가 없으며 사용자가 처음 사용하려고 할 때 전송하면 됩니다.
사용자가 응용 프로그램 사용을 마치고 종료하면 클라이언트는 가상 환경을 분해하며 다음 시작 시에 환경을 유지하고 다시 구성할 수 있도록 모든 사용자 설정을 사용자별 위치에 저장합니다. 스트리밍된 가상 응용 프로그램의 부분은 스트리밍된 비율에 관계없이 로컬 캐시에 유지되며 다음 시작 시에 사용할 수 있습니다. 다른 사용자가 동일한 호스트 시스템에 로그온하여 동일한 가상 응용 프로그램을 시작하면 이 사용자는 캐시에 저장된 응용 프로그램의 혜택을 볼 수 있습니다.
가상 응용 프로그램 광고를 제거하려면 해당 Active Directory 그룹에서 사용자를 제거하면 됩니다. 그리고 데스크톱에서 가상 응용 프로그램을 완전히 제거하려면 간단히 캐시를 삭제하면 됩니다. 응용 프로그램이 로컬에 설치된 것이 아니기 때문에 "이 공유 구성 요소를 제거하시겠습니까?"와 같은 성가신 메시지는 표시되지 않습니다.
가상 응용 프로그램이 캐시에 저장되어 있지만 모든 사용자가 이를 사용할 수 있는 것은 아닙니다. 사용자가 권한이 없더라도 간단히 실행 파일을 검색하거나 찾아볼 수 있는 설치된 응용 프로그램의 경우와는 달리 Active Directory 그룹을 통해 사용자에게 명시적으로 권한이 부여되지 않으면 가상 프로그램이 존재한다는 시각적 또는 물리적인 증거는 없습니다.

가상 응용 프로그램 업데이트
업데이트는 시퀀서를 사용하여 수행됩니다. 업데이트를 포함하도록 응용 프로그램이 수정되면 App-V 관리 서버에서 이전 버전 바로 다음에 업데이트가 저장됩니다. 서버는 다음 시작 시에 변경 내용이 있다는 것을 클라이언트에 알려 줍니다. 이전 버전이 아직 사용 중인 경우에는 가상 응용 프로그램을 종료할 때까지 해당 버전에 액세스할 수 있습니다. 다음 시작 시에 업데이트를 구성하는 델타가 클라이언트로 스트리밍되고 캐시에 로드되어 응용 프로그램이 업데이트 버전이 됩니다.
Word 2000을 사용하는 사용자가 1,000명이 있다고 가정해 보겠습니다. 관리자는 Word 2000(word2K.sft)을 Word 2000 SP3으로 업데이트해야 하며 이를 위해 스퀀스 스테이션에 word2K.sft 파일을 복사하고 시퀀서에서 Open for Package Upgrade(패키지 업그레이드를 위해 열기)를 선택합니다. Open for Package Upgrade(패키지 업그레이드를 위해 열기)를 선택하면 관리자는 마지막 패키지 상태로부터 작업을 시작합니다. 그런 다음 관리자는 DLL을 복사하고 업데이트를 실행하거나 가상 응용 프로그램 내에서 패치를 실행하여 Word 2000 SP3으로 업데이트할 수 있습니다. 관리자는 이 업데이트된 패키지를 저장할 수 있습니다.
시퀀서는 파일 이름이 중복되는 것을 방지하고 시퀀스 버전을 나타내기 위해 새로운 파일 이름으로 word2K_2.sft를 할당합니다. 이 새로운 패키지는 App-V 관리 서버에서 기존 패키지와 같은 디렉터리에 배치되므로 결국에는 Word 2000(word2K.sft)과 Word 2000 SP3(word2K_2.sft)이 같은 디렉터리에 저장됩니다. 관리자는 App-V 관리 콘솔을 사용하여 이러한 SFT 파일 두 개를 하나로 연결합니다.
클라이언트 쪽에서 SP3이 없는 Word 2000의 활성 세션을 열어 놓은 사용자는 계속에서 정상적으로 사용할 수 있습니다. 관리자가 이 연결을 수행한 후에 사용자가 응용 프로그램의 새로운 세션을 시작하면 변경 내용이 검색되었음을 알리는 메시지가 표시됩니다. 클라이언트는 word2K.sft 및 word2K_2.sft 간의 델타 변경 내용만을 스트리밍하고 자동으로 응용 프로그램을 Word 2000 SP3으로 업데이트합니다.
가상 응용 프로그램의 동적인 특성 덕분에 롤백도 상당히 쉽게 수행할 수 있습니다. 롤백하려면 간단하게 App-V 관리 콘솔에서 새로 추가된 버전을 제거하면 됩니다. 이렇게 하면 클라이언트가 다음 시작 시에 이전 버전으로 롤백합니다. 패키지 데이터에 혼선이 생기지 않도록 클라이언트는 자동으로 캐시를 제거하고 올바른 SFT 파일을 다시 스트리밍합니다. 기존의 소프트웨어 배포 도구를 사용하여 물리적으로 설치한 응용 프로그램 업데이트를 롤백하려는 경우 수행해야 하는 작업을 고려한다면 이 정도는 충분히 감수할 만한 수준입니다.

App-V의 장점을 체감하려면 가상 응용 프로그램 패키지를 만들어야 합니다. 이 작업에는 App-V 시퀀서가 사용됩니다. 스크립팅 및 기존 소프트웨어 배포 도구용 패키지 작성에 대한 지식과 경험이 있으면 시퀀스로 전환이 다소 수월해집니다. 여기에서 한 가지 지적할 것은 시퀀스가 기사 하나로 다루어야 할 만큼 만만치 않은 내용이라는 것입니다.
대부분의 소프트웨어 배포 솔루션을 사용하면 응용 프로그램 자체가 설치되는 방법을 캡처하고 이 프로세스를 다른 컴퓨터에서 복제할 수 있으므로 각각의 컴퓨터에서 직접 응용 프로그램을 설치하거나 업데이트할 필요가 없습니다. 응용 프로그램이 설치된 후에는 일반적인 소프트웨어 배포 도구는 더 이상 패키지에 관여하지 않습니다. 그런 다음에는 여러분이 응용 프로그램이 사용하는 종속성을 설치하고, 다른 스크립트를 실행하며, 필요에 맞게 응용 프로그램을 구성하는 수동 단계를 수행해야 합니다.
App-V의 근본적인 변화는 이미 설치되어 있는 응용 프로그램을 해당 종속성과 구성을 포함하여 이미지로 생성하는 시퀀스 프로세스입니다. 이 이미지는 재생되는 장치를 변경하지 않고 App-V 클라이언트에서 "재생"될 수 있습니다.
시퀀서는 다양한 파일을 생성하며 이 중에서 가장 중요한 것은 응용 프로그램 자산, 종속성 및 구성 정보를 포함하는 SFT 파일입니다. SFT에 여러 응용 프로그램이 포함될 수도 있으며 파일이 상당히 커질 수도 있습니다. 몇 가지 압축 옵션이 있지만 이를 사용하려면 네트워크와 장치 성능에 대한 세부적인 지식이 필요합니다. 시퀀서가 생성한 아이콘 파일(.ico)은 가상 응용 프로그램이 로컬에 설치된 것처럼 광고하는 데 사용됩니다.
OSD 파일 역시 매우 중요하며 이 파일의 옵션은 무한합니다. 기본적으로 이 파일은 App-V 클라이언트에 가상 응용 프로그램을 시작하는 방법을 알려 주는 데 사용되는 XML 기반 파일입니다. OSD 파일을 수정하여 가상 응용 프로그램이 시작 및 실행되는 방법을 구성하고 제어할 수도 있습니다. OSD 파일에서 사용되는 속성과 값에 익숙해질 수 있도록 Sequencing Admin Guide 및 Sequencing Best Practices 문서를 읽어 보도록 하십시오.
마지막으로 manifest.xml 파일은 패키지 기반 구성 정보를 포함하며 타사 ESD 솔루션 및 MSI 배포와의 통합에 사용될 수 있습니다. 시퀀서는 또한 가상 응용 프로그램 패키지용 MSI 파일을 생성할 수 있으며 이러한 MSI 파일은 독립 실행형 클라이언트(서버를 사용하지 않는)에 가상 응용 프로그램을 로드하고 ESD 시스템을 통과하는 데 사용될 수 있습니다.
시퀀서 자체는 응용 프로그램을 설치하고 이를 가상 응용 프로그램으로 변환하는 프로세스를 처리하는 포장기 사용을 안내하는 마법사 기반 도구입니다. 첫 번째 단계에서는 패키지의 기본 속성을 구성할 수 있습니다. OSD 파일에 저장되는 이러한 속성은 패키지 이름과 주석을 포함합니다. 일부 고급 설정으로는 스트리밍을 수행할 서버, 콘텐츠 디렉터리, 그리고 패키지가 지원할 운영 체제를 지정할 수 있습니다.
그림 4 시퀀스 마법사 (더 크게 보려면 이미지를 클릭하십시오.)
두 번째 단계는 응용 프로그램을 설치, 구성 및 테스트하는 것입니다. 설치 중 시퀀서는 파일 시스템, 레지스트리 및 시스템을 포함하여 로컬 시스템에 적용되는 모든 변경 내용을 캡처합니다. 이 마법사에는 예를 들어 Windows Update와의 통합을 지원하는 몇 가지 유틸리티가 있습니다.
다음 단계는 파일 형식 연결을 구성하고 바로 가기를 배치할 위치를 지정하는 것입니다. 표준 배치에는 시작 메뉴, 바탕 화면 및 빠른 실행 표시줄이 포함되지만 사용자 지정 위치를 만들 수도 있습니다.
그런 다음에는 응용 프로그램을 시작하고 초기 시작 임계값을 구성해야 합니다. 이 단계는 응용 프로그램 시작을 허용하기까지 클라이언트에 전송해야하는 응용 프로그램의 초기 부분을 App-V가 결정하는 단계입니다.
일반적으로 Feature Block 1 또는 FB1이라고 하는 이 초기 코드를 구성하려면 응용 프로그램을 시작하고 사용자에게 가장 일반적으로 필요한 기능을 사용하면 됩니다. 예를 들어 Word를 시작하고 맞춤법 검사기를 시작합니다. 이 단계에서 응용 프로그램이 호출하는 모든 DLL, 파일 또는 레지스트리 키는 자동으로 FB1의 부분으로 지정됩니다. 이 시점에 사용되지 않는 모든 파일, 설정 또는 구성 요소는 FB2에 추가됩니다. 그리고 응용 프로그램이 사용될 때 클라이언트는 FB1이 시작 및 중지되는 위치와 FB2에서 다른 파일이 있는 위치를 나타내는 SFT 파일의 맵을 수신하여 응용 프로그램에 이러한 파일이 필요할 때 이를 검색할 수 있습니다.
시퀀스 프로세스의 마지막 단계는 모든 항목이 올바르게 구성되었는지 확인하는 것입니다. 시퀀서는 그림 5와 같이 SFT를 표시하고 사용자가 최종적으로 패키지에 추가 또는 변경할 수 있는 대화 상자를 보여 줍니다.
그림 5 최종 패키지 확인 및 조정 (더 크게 보려면 이미지를 클릭하십시오.)

버전 4.5
2년간의 개발 기간을 거쳐 올해 App-V 4.5가 출시될 예정입니다. 버전 4.5는 Microsoft에서 출시되는 첫 번째 버전이며 동적 가상 응용 프로그램 상호 작용, 확장된 확장성, 그리고 Microsoft 국제화 및 보안 요구 사항 준수 개선과 같은 여러 핵심 개선 사항을 도입함으로써 응용 프로그램 가상화의 발전을 약속하고 있습니다.
동적 가상 응용 프로그램 상호 작용은 가상화된 응용 프로그램이 서로 상호 작용할 수 있도록 해 줍니다. 이 상호 작용을 DSC(Dynamic Suite Composition)라고 합니다. DSC는 동일한 패키지에 여러 응용 프로그램을 추가하는 기능을 대체하기 위한 것은 아니며 여러 가상 응용 프로그램에서 공유되는 종속성, 미들웨어 및 플러그 인을 통합하는 새로운 방법을 제공합니다.
관리자는 어떤 가상화된 응용 프로그램이 서로 상호 작용할 수 있는지 지정할 수 있습니다. 예를 들어 동일한 Java 버전이 필요한 웹 응용 프로그램 5개가 있다고 가정해 보겠습니다. App-V 4.1에서는 이를 위해 별도의 패키지 5개에 동일한 Java 버전을 추가해야 했습니다. 게다가 이러한 Java 버전에 패치가 필요하게 되면 관리자는 5개의 패키지를 별도로 패치해야 했습니다. DSC를 사용하면 Java를 한 번만 패키징하고 5개의 웹 응용 프로그램이 모두 이를 사용하도록 패키지를 구성할 수 있습니다. 따라서 Java를 패치하려는 경우에도 관리자는 Java 패키지를 한 번만 패치하면 됩니다.
미들웨어와 플러그 인의 경우에도 동일한 시나리오가 적용됩니다. Microsoft에서 최종 릴리스 일정이 가까워지고 추가 기능이 확정되면 다른 사례 시나리오에 대한 내용을 블로그에서 다룰 예정입니다.
확장성 향상은 스트리밍과 백 엔드 인프라에 모두 적용됩니다. 클러스터링과 장애 조치(failover) 시나리오 지원을 개선하도록 백 엔드 구성 요소가 수정되었으며 스트리밍은 WAN 및 LAN에 친화적으로 수정되었습니다. 기능 향상은 몇 가지 핵심 기능 추가를 통해 가능해졌습니다.
첫 번째로 소개할 기능은 Active Directory 및 SQL Server로 구성된 백 엔드 인프라 없이도 스트리밍을 수행하는 스트리밍 서버 구성 요소입니다. 과중한 백 엔드 요구 사항 없이도 주문형 전달과 패키지 업데이트의 중앙 집중화라는 중요한 혜택을 모두 누릴 수 있습니다. 이러한 구성은 지점 시나리오 및 ESD 솔루션과의 통합에서 널리 사용될 것입니다.
App-V 클라이언트에도 몇 가지 기능 향상이 추가되었습니다. 예를 들어 클라이언트는 이제 모든 사용량 정보를 로컬에 저장하므로 클라이언트 시스템이 네트워크에 연결되어 있는지 여부에 관계없이 이 정보를 추적할 수 있습니다. 클라이언트 캐시도 확장되고 개선되어 디스크 공간이 제한된 시나리오에서 성능이 개선되었습니다. 이 밖에도 영어 이외 언어 버전의 운영 체제에서 실행되는 영어 이외 언어 버전의 응용 프로그램에 대한 시퀀스 지원과 여러 다른 언어로의 지역화 지원이 추가되었습니다.

구성 관리자로 App-V 통합
App-V 4.5의 몇 가지 기능 향상과 새로운 기능은 App-V를 SCCM 2007 R2와 통합하기 위해 디자인되었습니다. 이미 설명한 것처럼 가상화와 스트리밍은 기존 소프트웨어 배포 도구로는 불가능한 방법으로 응용 프로그램을 전달하는 몇 가지 기능을 제공합니다. 그러나 App-V는 이러한 도구를 대체하기 위한 것이 아니라 보완하고 확장하기 위한 것입니다.
이러한 통합을 통해 SCCM의 모든 확장성, 보고, 장치 인식 및 WAN 기능과 함께 App-V의 모든 스트리밍 및 격리 기능을 사용할 수 있습니다. 다음은 이러한 두 기술을 통합함으로써 혜택을 볼 수 있는 몇 가지 영역의 예입니다.
응용 프로그램 전달 − SCCM R2 통합은 주문형 전달, 응용 프로그램 로밍, 초기 시작 임계값 및 클라이언트 PC 변경 없이 응용 프로그램 배포를 포함하는 모든 기능을 지원합니다.
업데이트 − SCCM DP(배포 지점)는 패키지가 업데이트되면 가상 응용 프로그램의 델타 변경 내용만 배포할 수 있습니다. 이를 통해 한 번의 클릭으로 가상화된 응용 프로그램을 이전 버전으로 되돌릴 수 있는 중앙 집중화된 기능이 가능해집니다.
관리 버전 R2에는 관리자가 단일 콘솔에서 가상화된 응용 프로그램은 물론 기존 소프트웨어 패키지와 광고를 배포할 수 있는 새로운 가상 응용 프로그램 광고 마법사가 도입되었습니다.
패키징 – App-V를 SCCM과 통합할 때 응용 프로그램을 다시 패키징할 필요가 없습니다. 응용 프로그램 초기 시퀀스는 SCCM 외부에서 App-V를 사용하여 수행되어야 하지만 관리자는 SCCM을 사용하여 기존 패키지를 업데이트할 수 있습니다.
라이선스 – SCCM에 있는 기존 도구를 사용하여 가상 응용 프로그램에 대한 라이선스 부여 및 측정을 추적할 수 있습니다.
BITS – SCCM은 가상화된 응용 프로그램을 업계 표준 BITS 프로토콜을 사용하여 App-V로 배포하는 새로운 방법을 제공합니다. SCCM DP는 스트리밍할 수 있지만 가상화된 응용 프로그램 배포에 스트리밍이 최적의 방법이 아닌 경우가 있습니다. SCCM을 통해 배포할 때는 표준 스트리밍을 사용하거나 BITS의 QoS(서비스 품질) 기능을 사용하여 제어가 훨씬 용이한 방법으로 배포하는 두 가지 옵션이 있습니다. 이 기능은 사용자가 가상 응용 프로그램을 시작하기 전에 캐시를 미리 로드하려는 시나리오에도 유용합니다.
컴퓨터 배포 – SCCM은 가상화된 응용 프로그램을 특정한 컴퓨터에 배포하는 기능을 제공하는 것은 물론 App-V 플랫폼의 사용자 기반 대상 지정 방법도 계속 지원합니다. 이 기능은 가상 응용 프로그램을 랩톱, 키오스크 및 실험실 컴퓨터에 배포할 때 유용합니다. 또한 명명된 사용자가 아니라 장치가 소프트웨어 라이선스를 관리하는 라이선스 제어를 지원할 때도 유용합니다.
확장성 – 공통적인 부분이 많은 별도의 두 도구를 배포해야 한다는 점에서 일반적인 우려가 있었습니다. SCCM의 확장성과 WAN 기능의 장점을 App-V의 격리와 스트리밍 기능의 장점과 통합함으로써 복잡성을 더하지 않고도 관리와 배포를 모두 처리하는 단일 도구를 제공하는 기존 SCCM을 사용할 수 있습니다.

Anthony Kinney는 Microsoft Desktop Optimization Pack 부문의 기술 세일즈 전문가 업무를 맡고 있으며 2006년 Microsoft가 Softricity를 인수함에 따라 Microsoft에서 근무하게 되었습니다. Softricity에서 근무하는 동안 Anthony는 첫 번째 SoftGrid(지금은 App-V) 교육용 프로그램을 개발하고 디자인했습니다. 문의 사항이 있으면 Anthony.kinney@microsoft.com으로 연락하시기 바랍니다.


Virtualization
Hyper-V의 고가용성 실현
Steven Ekren
한 눈에 보기:
  • Hyper-V를 사용하여 서버 통합
  • 가상 컴퓨터의 고가용성 확보
  • Windows Server 2008 장애 조치(failover) 설정

목차
고가용성
호스트와 게스트
게스트 가용성
고가용성 VM 구현
필수 구성 요소
HA 단계별 안내
고려 사항
Windows Server 2008의 Hyper-V는 엔터프라이즈 IT 부서에 상당한 반향을 불러일으킨 서버 가상화를 현실화하는 기술입니다. 물리적 컴퓨터를 적은 수로 유지하여 서버를 구성하면 리소스와 비용을 크게 절감할 수 있지만 이렇게 하려면 계획 프로세스 중에 두 가지 핵심 요인을 고려해야 합니다. 메시징 및 공동 작업 플랫폼과 같은 도구와 기간 업무(LOB) 응용 프로그램을 포함하는 소프트웨어의 가용성에 대한 사용자의 기대치는 점차 높아지고 있습니다. 게다가 서버에 문제나 오류가 발생하면 작업이 더욱 큰 영향을 받습니다. Windows Server 2008과 Hyper-V를 사용하면 가상 컴퓨터(VM)에서 고가용성(HA)을 제공하고 VM 내에서 워크로드를 호스트하는 솔루션을 구축할 수 있습니다.

고가용성
가용성이란 사용자가 시스템에 액세스하여 작업을 수행할 수 있음을 의미합니다. 가용성이 높다는 것은 시스템이 운영 연속성을 제공하도록 디자인 및 구현되었음을 의미하므로 사용자는 항상 시스템에 액세스할 수 있다고 기대하게 됩니다.
Hyper-V의 고가용성은 Windows Server 2008 장애 조치(failover) 클러스터 기능을 사용함으로써 구현됩니다. 고가용성은 계획 및 비계획 가동 중지 시간에 모두 영향을 받으며 장애 조치(failover) 클러스터링으로 이러한 두 가지 범주에서 가상 컴퓨터의 가용성을 크게 높일 수 있습니다.
장애 조치(failover) 클러스터를 통해 가상 컴퓨터를 관리할 수 있으며 가상 컴퓨터 내부에서 장애 조치(failover) 클러스터를 사용하여 VM에서 호스트되는 워크로드를 모니터링하거나 이동할 수도 있습니다. 여기에서는 이러한 두 가지 구성 시나리오를 모두 설명하겠지만 이 기사의 중점 내용은 가상 컴퓨터를 관리하는 데 대한 것입니다. 시작하기에 앞서 "유용한 Hyper-V 용어" 추가 기사를 살펴보십시오.

호스트와 게스트
Hyper-V 시스템에서는 여러 운영 체제를 실행할 수 있기 때문에 계층이나 OS를 명확하게 지칭하기가 어렵습니다. 필자는 Hyper-V VM 내의 자식 파티션에서 실행되는 OS와 환경을 "게스트"라고 용어로 부르며 Hyper-V 부모 파티션의 OS에 의해 관리되는 실제 컴퓨터를 "호스트"라는 용어로 부릅니다.
호스트 가용성은 서버 통합에 의해 "모든 달걀을 한 바구니에 담는 상황"에 따른 문제를 해결합니다. Hyper-V 부모 파티션(호스트)에서 Hyper-V 자식 파티션(가상 컴퓨터나 게스트)의 상태를 모니터링하고 클러스터 노드 간을 이동하도록 Windows Server 2008 장애 조치(failover) 클러스터를 구성할 수 있습니다. 이 구성에는 다음과 같은 핵심적인 장점이 있습니다.
  • Hyper-V와 VM이 실행 중인 실제 컴퓨터에 업데이트, 변경 또는 다시 부팅이 필요한 경우 VM을 클러스터의 다른 노드로 이동하고 실제 컴퓨터를 다시 사용할 수 있게 되면 VM을 다시 원래 위치로 이동할 수 있습니다.
  • Hyper-V와 VM이 실행 중인 실제 컴퓨터에 오류가 발생(예: 메인보드 고장)하거나 심각한 작동 저하가 발생하는 경우 Windows 장애 조치(failover) 클러스터의 다른 구성원이 VM의 소유권을 넘겨받아 자동으로 온라인 상태로 만들 수 있습니다.
  • VM에 오류가 발생하는 경우 동일한 Hyper-V 서버에서 다시 시작하거나 다른 Hyper-V 서버로 이동할 수 있습니다. Windows Server 장애 조치(failover) 클러스터는 이러한 작업을 감지하고 VM의 리소스 속성의 설정에 따라 자동으로 복구 단계를 수행합니다. 감지와 복구 자동화 덕분에 작동 중단 시간이 최소화됩니다.
그림 1에는 이러한 경우에 어떤 일이 발생하는지 보여 줍니다. VM2는 처음에는 호스트 A에 있다가 호스트 B로 이동합니다. 이러한 이동 중에 SAN 저장소 LUN 2는 호스트 A에서 호스트 B로 변경됩니다. 여러분의 고가용성 솔루션이 가용성 요구를 충족할 수 있도록 VM의 위치를 신중하게 고려해야 하며 용량과 성능을 모두 감안해야 합니다.
그림 1 새로운 호스트로 이동하는 가상 컴퓨터와 해당 저장소 (더 크게 보려면 이미지를 클릭하십시오.)
노드의 용량은 모든 VM을 호스트하고 x개의 노드가 실패하거나 활성 클러스터 참여에서 x개의 노드를 제거하도록 허용할 만큼 충분해야 합니다. 여기에서 x는 클러스터에서 손실되더라도 모든 VM을 호스트할 수 있는 노드의 수를 나타냅니다. 용량을 결정할 때는 일부 노드가 정식으로 VM을 호스트하지 않고 예약 상태로 유지하도록 선택할 수 있습니다. 또는 x개의 노드가 실패하는 경우 각 노드가 성공적으로 소유권을 가져오고 VM을 시작할 수 있는 충분한 공간을 확보하도록 VM을 모든 노드에 걸쳐 분산시키는 방법도 있습니다.
일상적인 작업의 성능을 감안하면 VM을 클러스터의 모든 노드에 걸쳐 분산시키는 것이 좋습니다. 노드가 예약되고 VM을 전혀 호스트하지 않는 경우 VM을 호스트하는 노드가 리소스를 더 많이 사용하며 VM은 물론 관리 파티션의 성능이 저하될 수 있습니다. 노드에 걸쳐 VM을 분산시키면 각 노드에 적용되는 부하가 줄어들며 VM과 관리 파티션의 성능이 개선됩니다. 그러나 용량 계획은 더 까다로워집니다. System Center Virtual Machine Manager 2008과 같은 관리 소프트웨어를 사용하면 노드 실패와 VM 배치를 위한 용량 계산을 수행하는 데 도움이 됩니다.

게스트 가용성
게스트 가용성은 VM 내에서 실행되는 워크로드의 가용성을 높게 만드는 데 초점을 맞춥니다. 일반적인 워크로드에는 파일 및 인쇄 서버, IIS 및 LOB 응용 프로그램이 있습니다. VM 내의 고가용성 요구와 워크로드를 위한 솔루션을 분석하는 과정은 독립 실행형 서버에서와 동일합니다. 솔루션은 특정 워크로드에 의존하게 됩니다.
일부 네트워크는 여러 서버가 공용 네트워크 이름을 통해 풀의 일부가 될 수 있도록 허용하는 Windows NLB(Network Load Balance)를 통해 고가용성을 달성할 수 있습니다. 클라이언트는 가상 네트워크 이름을 사용하여 요청을 수행하며 NLB 클러스터의 노드 중 하나에 연결합니다. NLB 클러스터링을 사용하는 일반적인 시나리오로는 각 개별 시스템에 같은 웹 페이지가 있고 같은 데이터에 액세스하는 IIS로 웹 팜을 구성하는 예가 있습니다. NLB는 관리를 위해서나 서버에 문제가 발생했을 때 멤버 자격에서 서버를 제공하는 기능은 물론 부하 분산을 제공하여 높은 수준의 가용성을 보장합니다. Hyper-V VM이 Windows Server 2008(또는 NLB를 포함하는 Windows Server 이전 버전)에서 실행 중인 경우 게스트는 NLB 클러스터의 구성원일 수 있으며 이때 다른 게스트는 동일 또는 다른 Hyper-V 호스트에 있을 수 있습니다.
Windows Server 2008을 실행하는 게스트는 Windows 장애 조치(failover) 클러스터 기능을 사용하여 자체 워크로드에 고가용성을 제공할 수 있습니다. 게스트 내에서 Windows 장애 조치(failover) 클러스터링을 사용(게스트 클러스터링)하면 몇 가지 장점이 있습니다.
워크로드 상태 모니터링 Windows 장애 조치(failover) 클러스터의 리소스 모니터는 클러스터와 연결된 리소스 DLL에 대한 호출을 수행합니다. 각 리소스에는 리소스가 관리하는 응용 프로그램이나 서비스가 올바르게 작동하는지 테스트하는 상태 모니터링이 있습니다. 이러한 검사를 일반적으로 isAlive/looksAlive 검사라고 합니다. 리소스의 이러한 호출 중 하나가 실패하면 발생하면 리소스 자체가 실패합니다. 이 경우 리소스는 해당 속성 구성에 따라 서비스나 응용 프로그램을 다시 시작하려고 시도하거나 Windows 장애 조치(failover) 클러스터의 다른 노드로 이동할 수 있습니다.
가상 컴퓨터 유지 관리 VM의 구성을 변경해야 하거나 OS나 소프트웨어를 업데이트 또는 변경해야 하는 경우, 워크로드를 클러스터의 다른 노드로 이동하여 최종 사용자의 작업 중단을 최소화하면서 VM을 종료하거나 업데이트할 수 있습니다.
호스트 컴퓨터 유지 관리 Hyper-V VM을 호스팅하는 실제 컴퓨터에 유지 관리나 소프트웨어 업데이트가 필요하며 Windows 장애 조치(failover) 클러스터의 다른 구성원이 다른 Hyper-V 호스트에 있는 경우 VM의 워크로드를 클러스터의 다른 노드로 이동하고 실제 서버의 변경이나 다시 부팅을 위해 VM을 종료할 수 있습니다.
가상 컴퓨터나 호스트 컴퓨터 오류 실제 Hyper-V 호스트나 가상 컴퓨터 게스트에 오류가 발생하면 Windows 장애 조치(failover) 클러스터의 다른 노드가 해당 클러스터 구성원이 더 이상 응답하지 않거나 클러스터에 참여하지 않는다는 것을 감지하고 남아 있는 노드가 오류가 발생한 VM에서 실행 중이던 응용 프로그램이나 서비스를 온라인으로 만듭니다.

유용한 Hyper-V 용어
다음은 고가용성 Hyper-V 시스템(호스트 클러스터)의 구성 요소나 기능을 정의하는 데 도움이 되는 용어 목록입니다.
부모 파티션 하이퍼바이저 서버에서 실행되는 모든 운영 체제에는 RAM, CPU 및 다른 시스템 구성 요소를 포함하는 하드웨어 리소스가 할당됩니다. Hyper-V에서 하이퍼바이저와 시스템 리소스의 구성을 관리하는 파티션을 부모 파티션이라고 부르는 경우가 많습니다. Hyper-V 역할이 구성되고 서버가 다시 부팅되면 시스템의 네이티브 OS였던 Windows Server 2008 설치가 Hyper-V 서버의 부모 파티션에서 OS가 됩니다.
자식 파티션 게스트 운영 체제를 저장하고 해당 운영 체제에 하드웨어 리소스를 제공하도록 구성된 Hyper-V 서버 상의 격리된 환경
Hyper-V 호스트 Hyper-V와 부모 파티션 내에서 실행되는 운영 체제를 호스팅하는 실제 서버
Hyper-V 가상 컴퓨터 Hyper-V 자식 파티션을 부팅하고 실행하는 데 사용되는 Hyper-V 구성 정보 및 데이터입니다. 여기에는 자식 파티션과 VHD 파일 또는 해당 데이터를 포함하는 통과 디스크를 만들기 위한 구성 정보가 포함됩니다.
통과 디스크 Hyper-V 게스트에서 독점적으로 사용하도록 할당되며 디스크 관리에서 실제 디스크로 공개되는 저장소 장치입니다. Hyper-V 게스트는 디스크를 탑재하고 로컬에 연결된 저장소 장치처럼 디스크를 사용합니다.
VHD(가상 하드 디스크) Hyper-V 자식 파티션에 연결되며 운영 체제에는 저장소 장치(디스크)로 공개되는 파일입니다. .vhd 파일은 부모 파티션에 의해 탑재되는 저장소 장치에 위치하며 직접 연결 저장소 장치이거나 SAN, NAS 또는 SMB를 통해 연결되는 저장소일 수 있습니다.
고가용성 VM 구현
장애 조치(failover) 클러스터 관리에서 HA 역할 마법사를 사용하면 간단하게 가상 컴퓨터를 고가용성으로 구성할 수 있습니다. Hyper-V 가상 컴퓨터를 고가용성으로 관리하기 위해 고려해야 하는 몇 가지 핵심 구성 요소가 있습니다. 몇 가지 중요한 개념과 일반적인 필수 구성 요소를 살펴보겠습니다.
장애 조치(failover) 클러스터 노드 장애 조치(failover) 클러스터를 구성하는 각 실제 서버를 노드라고 합니다. 호스트 클러스터링의 경우 장애 조치(failover) 클러스터 서비스는 Windows Server 2008에서 Hyper-V 시스템의 부모 파티션 상에서 실행됩니다. 이를 통해 동일한 실제 서버의 자식 파티션에서 실행 중인 VM을 고가용성 가상 컴퓨터로 구성할 수 있습니다. HA로 구성된 가상 컴퓨터는 장애 조치(failover) 클러스터 관리 콘솔에 리소스로 표시됩니다.
HA 저장소 VHD(가상 하드 디스크), 통과 디스크 및 차이점 보관용 디스크를 사용하도록 고가용성 가상 컴퓨터를 구성할 수 있습니다. 장애 조치(failover) 클러스터 노드 간에 가상 컴퓨터가 이동할 수 있도록 하려면 장애 조치(failover) 클러스터 서비스에서 관리되며 VM을 호스트하는 모든 노드가 액세스할 수 있는 저장소(디스크 관리에 디스크로 표시됨)가 필요합니다. 통과 디스크는 장애 조치(failover) 클러스터에 디스크 리소스로 추가해야 하며 VHD 파일은 장애 조치(failover) 클러스터에 디스크 리소스로 추가된 디스크에 있어야 합니다.
가상 컴퓨터 리소스 가상 컴퓨터를 나타내는 장애 조치(failover) 클러스터 리소스 유형입니다. 가상 컴퓨터 리소스가 온라인 상태가 되면 Hyper-V가 자식 파티션을 만들고 가상 컴퓨터의 OS가 시작됩니다. 가상 컴퓨터 리소스의 오프라인 기능이 호스팅된 노드 상의 Hyper-V에서 VM을 제거하며 자식 파티션은 Hyper-V 호스트에서 제거됩니다. 가상 컴퓨터가 종료, 중지 또는 저장된 상태가 되면 이 리소스는 오프라인 상태가 됩니다.
가상 컴퓨터 구성 리소스 VM의 구성 정보를 관리하는 데 사용되는 장애 조치(failover) 클러스터 리소스 유형입니다. 각 가상 컴퓨터에 대한 가상 컴퓨터 구성 리소스는 하나입니다. 이 리소스의 속성에는 가상 컴퓨터를 Hyper-V 호스트에 추가하는 데 필요한 모든 정보가 있는 구성 파일에 대한 경로가 포함되어 있습니다. 가상 컴퓨터 리소스를 시작하려면 구성 파일을 사용할 수 있어야 합니다. 구성은 별도의 리소스가 관리하므로 VM이 오프라인인 동안에도 VM 리소스의 구성을 수정할 수 있습니다.
가상 컴퓨터 서비스 및 응용 프로그램 그룹 장애 조치(failover) 클러스터링을 통해 서비스나 응용 프로그램을 고가용성으로 유지하려면 같은 장애 조치(failover) 클러스터 노드에 여러 리소스를 호스트해야 합니다. 이러한 리소스가 항상 같은 노드에 있도록 하고 올바르게 상호 운용될 수 있도록 하기 위해 리소스는 Windows Server 2008 장애 조치(failover) 클러스터가 "서비스 또는 응용 프로그램"이라고 참조하는 그룹에 넣어집니다. 가상 컴퓨터 리소스와 VM의 가상 컴퓨터 구성 리소스는 항상 같은 서비스 또는 응용 프로그램 그룹에 있습니다. 서버 또는 응용 프로그램 그룹에는 VHD나 구성 파일을 포함하는 하나 이상의 실제 디스크(또는 다른 저장소 유형) 리소스나 통과 디스크도 있을 수 있습니다.
리소스 종속성 가상 컴퓨터 리소스가 온라인(시작)이 되기 전에 가상 컴퓨터 구성 리소스를 온라인으로 만들고, 가상 컴퓨터 리소스를 오프라인(중지)이 된 후에 가상 컴퓨터 구성 리소스를 오프라인으로 만드는 것이 중요합니다. 가상 컴퓨터 구성 리소스에 종속되도록 가상 컴퓨터 리소스의 속성을 설정하면 이러한 온라인/오프라인 순서를 보장할 수 있습니다. 가상 컴퓨터 구성 리소스나 가상 컴퓨터 리소스의 파일을 포함하는 저장소 리소스가 있는 경우 리소스가 해당 저장소 리소스에 종속되도록 해야 합니다. 예를 들어 가상 컴퓨터가 디스크 G:에 있는 VHD 파일과 디스크 H를 사용하는 경우 가상 컴퓨터 리소스는 디스크 G:에 있는 구성 파일 리소스와 리소스, 그리고 디스크 H에 있는 리소스에 종속되도록 해야 합니다.

필수 구성 요소
다음은 Windows Server 2008 장애 조치(failover) 클러스터 기능을 사용하여 Hyper-V 가상 컴퓨터를 고가용성으로 만들기 위한 세 가지 필수 구성 요소입니다.
  1. 클러스터의 각 노드에 대해 Windows Server 2008 장애 조치(failover) 클러스터 기능을 구성해야 합니다. 장애 조치(failover) 클러스터 구성 및 관리에 대한 자세한 내용은 "Hyper-V 리소스" 추가 기사를 참조하십시오.
  2. Hyper-V 역할을 설치해야 합니다. Hyper-V 업데이트를 설치해야 하며 장애 조치(failover) 클러스터의 각 노드에 역할을 구성해야 합니다. 마찬가지로 "Hyper-V 리소스" 추가 기사를 참조하십시오. Hyper-V에는 Hyper-V 서버 구성 요소를 설치하는 업데이트 패키지와 Hyper-V 관리 콘솔을 설치하는 업데이트 패키지가 있습니다. Hyper-V 서버 구성 요소용 업데이트를 설치한 다음에는 서버 관리자나 ServerManagerCMD를 통해 역할을 추가할 수 있습니다.
  3. 가상 컴퓨터에서 공유 저장소를 사용할 수 있도록 해야 합니다. 저장소는 장애 조치(failover) 클러스터에 의해 기본 제공 실제 디스크 리소스 유형으로서 관리될 수 있으며 타사 솔루션을 사용하여 공유 스토리지를 관리할 수도 있습니다. 물론 타사 솔루션은 Windows Server 2008 장애 조치(failover) 클러스터를 지원해야 합니다.

HA 단계별 안내
다음은 고가용성 솔루션을 설정하는 방법을 살펴보겠습니다. 첫 번째 단계는 가상 컴퓨터를 설정하는 것입니다. 장애 조치(failover) 클러스터에서 Hyper-V 역할이 설치된 노드 중 하나에서 Hyper-V 관리자를 사용하여 가상 컴퓨터를 구성합니다(그림 2 참조). 이때 수동으로 새로운 VM을 구성하거나 기존 VM을 가져올 수 있습니다. VHD는 Windows Server 2008 장애 조치(failover) 클러스터에 의해 관리되며 VM이 구성되고 있는 노드 상에서 현재 온라인 상태인 디스크에 있어야 합니다.
그림 2 가상 컴퓨터 구성 (더 크게 보려면 이미지를 클릭하십시오.)
이제 가상 컴퓨터를 종료하거나 끄거나 또는 저장 상태로 설정하여 중지된 상태로 만듭니다. 장애 조치(failover) 클러스터는 가상 컴퓨터가 중지된 상태가 되어야만 관리를 위해 구성할 수 있습니다.
Windows Server 2008 장애 조치(failover) 클러스터 역할을 실행하는 임의의 서버에서 또는 RSAT(원격 서버 관리 도구)를 실행하는 Windows Vista 클라이언트에서 장애 조치(failover) 클러스터 관리 콘솔(그림 3 참조)을 엽니다. 클러스터 관리… 작업을 선택하고 노드나 클러스터 이름을 선택하거나 콘솔이 실행 중인 노드의 클러스터에 연결하는 옵션을 선택하여 장애 조치(failover) 클러스터에 연결합니다.
그림 3 장애 조치(failover) 클러스터 관리의 가상 컴퓨터 (더 크게 보려면 이미지를 클릭하십시오.)
장애 조치(failover) 클러스터 관리 콘솔에서 서비스 또는 응용 프로그램 구성… 작업을 선택합니다. 이렇게 하면 장애 조치(failover) 클러스터에서 관리되는 서비스, 응용 프로그램 또는 가상 컴퓨터를 구성하는 과정을 안내하는 고가용성 마법사가 열립니다. 마법사의 서비스 또는 응용 프로그램 선택 페이지에서 가상 컴퓨터를 선택하고 다음을 선택합니다.
가상 시스템 선택 페이지에는 장애 조치(failover) 클러스터의 임의의 노드에 구성된 모든 가상 컴퓨터가 표시됩니다. 가상 컴퓨터를 선택하고 다음을 선택합니다. 모든 경고나 오류를 보여 주는 마법사의 확인 페이지가 표시됩니다. 이 단계에서는 HA 리소스로 구성할 수 있는지 확인하고 노드가 이를 호스트할 수 있는지 확인하기 위해 가상 컴퓨터 구성이 검사됩니다. 이제 다음을 선택하면 가상 컴퓨터가 고가용성 리소스로서 장애 조치(failover) 클러스터에 추가됩니다.
요약 페이지에는 모든 경고를 포함하여 가상 컴퓨터를 고가용성 리소스로 추가한 결과에 대한 정보가 표시됩니다. 보고서 보기… 단추를 클릭하면 모든 경고나 오류를 포함하여 가상 컴퓨터를 고가용성으로 만드는 작업에 대한 세부 정보를 볼 수 있습니다. 마지막으로 마침을 선택하면 고가용성 마법사가 닫힙니다.
그림 3의 창에 나와 있는 것처럼 장애 조치(failover) 클러스터 관리 콘솔은 왼쪽 창에서 클러스터 이름과 서비스 또는 응용 프로그램 아래에 Virtual Machine(x)이라는 기본 이름으로 개체를 나열합니다. 해당 트리 구조에서 가상 컴퓨터를 선택하면 서비스 또는 응용 프로그램 그룹의 일부인 리소스가 콘솔의 가운데 창에 표시됩니다. 선택된 것과 동일한 저장소에 해당 파일이 있는 가상 컴퓨터가 있으면 해당 항목도 그룹에 추가됩니다. 그룹에 추가된 각 가상 컴퓨터에 해당하는 가상 컴퓨터 및 가상 컴퓨터 구성 리소스가 표시됩니다.
서비스 또는 응용 프로그램 그룹의 정보 창에는 그룹의 상태, 알림, 기본 설정 소유자 및 현재 소유자 정보가 표시됩니다. 소유자 노드는 가상 컴퓨터가 현재 구성되거나 실행 중인 가상 컴퓨터입니다. 가상 컴퓨터를 오프라인으로 만든 다음 다른 노드에서 온라인으로 만들려면 가상 컴퓨터를 다른 노드로 이동 작업을 선택합니다. 장애 조치(failover) 클러스터 내에서 VM을 호스트할 수 있는 각 노드에 VM을 이동하여 이동이 성공하고 VM이 시작되고 실행되는지 확인하는 것이 일반적으로 최선의 방법입니다.

Hyper-V 리소스
  • Windows Server 2008용 Hyper-V 기술의 릴리스 버전을 위한 업데이트에 대한 설명
  • Hyper-V 단계별 가이트: Hyper-V 및 장애 조치(failover) 클러스터링 테스트
  • Windows Server 2008 Failover Clustering 소개(Chuck Timon, TechNet Magazine, 2008년 7월)
  • Windows Server 2008 Hyper-V 가상 컴퓨터에서 예상대로 수렴되지 않는 NLB 호스트
  • Win2008 클러스터 웹캐스트
  • Windows Server 2008 장애 조치(failover) 클러스터에 대한 Microsoft 지원 정책
고려 사항
다음은 가상 컴퓨터를 고가용성으로 설정할 때 기억해야 할 몇 가지 핵심 요점입니다.
저장소 가상 컴퓨터의 VHD 파일이 동일한 공유 디스크에 있는 경우 동일한 디스크의 다른 볼륨에 있다고 하더라도 동일한 서비스 또는 응용 프로그램 그룹에 포함됩니다. 디스크를 공유하는 데 따르는 장점 중 하나는 공유 저장소 공간을 더욱 잘 사용할 수 있다는 것입니다.
그러나 가상 컴퓨터의 문제에 따른 자동 복구에 의한 것이든 또는 관리자의 선택에 의한 것이든 가상 컴퓨터가 이동할 때마다 그룹 내의 모든 가상 컴퓨터가 이동한다는 것이 단점입니다.
드라이버 문자와 GUID 드라이브 문자를 할당하지 않고도 볼륨을 만들 수 있습니다. 가상 컴퓨터에서 이러한 볼륨을 사용할 수 있으며 장애 조치(failover) 클러스터에서 볼륨을 관리할 수 있습니다. 디스크 리소스에 드라이브 문자 대신 GUID를 사용하는 볼륨이 있으면 클러스터 관리에 해당 GUID가 표시됩니다. 가상 컴퓨터를 만들고 VHD의 경로를 지정할 때는 경로의 GUID가 클러스터 관리에서 볼륨에 표시되는 GUID와 일치하도록 하는 것이 매우 중요합니다. GUID가 일치하지 않으면 가상 컴퓨터가 장애 조치(failover) 클러스터의 다른 노드에서 올바르게 시작(온라인)할 수 없습니다.
GUID가 일치하지 않게 되는 몇 가지 상황이 있습니다. 볼륨을 장애 조치(failover) 클러스터 관리 디스크 리소스로 추가하기 전에 노드에서 온라인으로 만들면 볼륨이 각 노드에서 다른 GUID를 가지게 됩니다. 단일 노드에서 한 볼륨이 여러 GUID를 가지는 경우도 있습니다. 디스크가 장애 조치(failover) 클러스터에 실제 디스크 리소스로 추가되면 온라인 상태인 디스크가 있는 노드에서 사용 중인 볼륨 GUID가 디스크 리소스의 속성에 표시됩니다.
디스크 리소스가 온라인이 되면 볼륨의 GUID가 노드에 추가됩니다. 이를 통해서 장애 조치(failover) 클러스터가 볼륨에 대해 지정한 특정 GUID가 디스크를 온라인으로 만든 모든 노드에서 유효한 경로가 되도록 보장할 수 있습니다. 해당 노드는 동일한 볼륨에 연결된 다른 GUID를 가질 수도 있습니다. 따라서 해당 노드의 볼륨에 유효한 GUID와 장애 조치(failover) 클러스터가 다른 노드의 볼륨에 사용되는 것으로 보장하는 GUID가 서로 다른 경우가 발생할 수 있습니다. 이 문제의 증상은 가상 컴퓨터 리소스, 그중 일반적으로 구성 리소스를 온라인으로 만드는 작업이 실패하고 경로가 잘못되었음을 알려 주는 오류 메시지가 표시되는 것입니다. 오류 메시지의 경로는 볼륨에 대한 클러스터 관리 GUID가 아닌 GUID를 보여 줍니다.
탑재 지점 Hyper-V와 장애 조치(failover) 클러스터에서는 드라이브 문자를 지정하거나 GUID를 사용하지 않고 다른 볼륨의 폴더에 볼륨을 탑재하는 것이 허용됩니다. 탑재된 볼륨과 탑재 지점을 호스팅하는 볼륨이 동일한 장애 조치(failover) 클러스터 노드에 있어야 하므로 탑재 지점을 구성하는 모든 디스크가 동일한 장애 조치(failover) 클러스터 서비스 또는 응용 프로그램 그룹에 있어야 합니다.
볼륨이 동일한 디스크에 있으면 문제가 되지 않지만 볼륨이 다른 디스크에 있는 경우에는 확실히 문제가 됩니다. 당연하지만 탑재되는 볼륨과 탑재 지점의 호스트가 장애 조치(failover) 클러스터가 관리하도록 구성된 공유 저장소여야 한다는 것은 다시 확인할 필요가 있습니다.
차이점 보관용 디스크 차이점 보관용 디스크를 구성하는 모든 VHD 파일은 차이점 보관용 디스크를 사용하는 VM과 동일한 서비스 또는 응용 프로그램 그룹의 공유 저장소에 있어야 합니다. 가장 단순한 구성의 경우 차이점 보관용 디스크에는 기본으로 사용되는 데이터의 집합을 포함하는 부모 역할을 하는 VHD와 부모에 연결된 자식 역할을 하는 VHD의 두 개의 VHD가 포함됩니다.
차이점 보관용 디스크는 처음 사용될 때는 부모와 동일합니다. 데이터가 부모에 있으면 VHD에서 데이터를 읽습니다. 모든 쓰기 작업은 자식 VHD에 수행됩니다. 데이터가 자식에 있으면 해당 데이터에 대한 읽기는 자식 VHD를 참조합니다.
자식 VHD는 공유 저장소에 있지만 부모 VHD는 동일한 그룹의 공유 저장소가 아닌 다른 곳에 있도록 VM이 구성되거나 로컬에 연결된 저장소 장치에 있는 경우 다른 노드로 옮겨지면 VM이 시작(온라인)하지 못하게 됩니다. 고가용성 마법사는 VM에서 이 구성이 올바른지 확인하고 이 문제가 발견되면 오류 메시지를 보여 주지만 VM 구성이 변경된 경우 요구 사항을 확인해 보는 것도 가치가 있습니다.

Steven Ekren는 Windows 서버 장애 조치(failover) 클러스터 및 고가용성 팀의 수석 프로그램 관리자이며 12년간 Microsoft 지원 부서에서 엔터프라이즈 고객이 Windows Hyper-V, System Center Virtual Machine Manager, Microsoft Virtual Server 및 Microsoft 가상 PC를 포함한 Windows 서버 장애 조치(failover) 클러스터 및 가상화 기술을 구현하고 문제를 해결하는 과정을 지원해왔습니다.


Virtualization
서버 가상화를 위한 백업 및 재해 복구
Adam Fazio
한 눈에 보기:
  • 재해 복구 계획을 위한 고려 사항
  • 재해 복구를 위한 고가용성 솔루션
  • Windows Server Backup을 사용한 백업 및 복원

목차
재해 복구 계획 101
재해 복구 및 가상화
실제 컴퓨터를 가상 컴퓨터로 변환
가상 컴퓨터 스냅숏
Hyper-V 백업
Windows Server 백업
WSB로 VM 백업
고려 사항
WSB로 VM 복원
Data Protection Manager
스크립트를 사용한 백업
DiskShadow
요약
서버 가상화 기술이 발전하고 업계 도입이 증가함에 따라 여러 조직에서는 인프라 비용 절감과 IT 민첩성 향상이라는, 가장 널리 알려진 가상화의 장점 이외에도 더 많은 혜택이 있음을 인식하고 있습니다. 다음 개척지는 DR(재해 복구)을 구현 또는 강화하기 위한 방편으로 가상화 플랫폼을 사용하는 것입니다.
DR 준비도가 계속해서 IT 업계 최대의 화두 중 하나로 꼽히는 이유는 무엇일까요? 연구에 따르면 시스템 가동이 한 시간 중지될 때마다 기업이 입는 평균 손실액은 80,000달러에서 90,000달러에 이르며, 심각한 데이터 손실을 입은 회사가 장기적으로 생존하는 경우는 극소수에 불과합니다. 이 기사에서는 Microsoft 가상화 플랫폼을 사용한 DR을 소개하고 Windows Server 2008 Hyper-V의 백업 및 복원 옵션과 고려 사항을 자세히 살펴보겠습니다.

재해 복구 계획 101
DR은 시스템 가동이 중단되었을 때 중요한 서비스를 복원하는 프로세스이며, 모든 회사는 재해 발생 중 또는 그 이후 어떻게 회사 기능을 지속할지를 정의하는 비즈니스 연속성 계획의 일부로 DR을 포함해야 합니다. 이러한 계획은 모든 DR 이니셔티브의 토대입니다.
일부 공급업체는 자사의 DR 자동화 기술이 충분한 시연을 거친 세부적인 계획의 필요성을 최소화하거나 아예 없애 준다고 주장합니다. 자동화를 통해 복구 시간을 단축하고 사용자 조작에 대한 의존성을 낮출 수 있는 것은 분명 사실이지만 잘 알려진 바와 같이 기술만으로 재해를 완화할 수는 없으며 사람과 프로세스도 기술 못지않게 중요합니다.
실제로 DR 계획 프로세스의 모든 제약과 목표에 대한 지식이 없으면 올바른 기술을 선택하는 것조차 거의 불가능하다는 것을 알 수 있습니다. 이 기사에서 전체 DR 계획을 정의할 수는 없지만 올바른 기술과 구현을 선택하는 데 필요한 이러한 요소를 집중적으로 살펴볼 것입니다. 우선 DR 계획과 관련된 몇 가지 중요한 기술 동력을 간단히 알아보겠습니다.
서비스 정의 및 우선 순위 여러분이 보호하려는 전체 서비스와 조직에 있어서 이러한 서비스의 중요도를 정의하는 요소는 정확히 무엇일까요? 그림 1에는 모든 DR 계획에 일반적으로 포함되는 회사 서비스의 예가 나와 있습니다.
그림 1 서비스 정의 및 우선 순위 예
서비스 | 주 구성 요소 | 종속성 | 업무 용도 | SLA
공용 웹 사이트 | 네트워크 부하 분산 장치, 웹 서버 3개, 데이터베이스 서버 2개 | DNS, 네트워크, 방화벽, 디렉터리, SAN(저장 영역 네트워크) 저장소 | 제품 구입 및 주문 추적, 전자 상거래, 고객 지원 포털, 회사 정보 | 99.99%
재무 시스템 | 데이터베이스 서버 2개, 응용 프로그램 서버 1개 | DNS, 네트워크 | 법 규정에 따라 회사 수익 기록 | 99.99%
전자 메일 시스템 | 전자 메일 서버 3개, 웹 서버 1개 | DNS, 네트워크, 방화벽, 디렉터리 | 회사 통신, 고객 지원 | 99.5%
서비스를 정의한 다음에는 어떤 유형의 DR 전략을 위해 어떤 시스템과 종속성을 대상으로 해야 하는지를 알아낼 수 있습니다. 예를 들어 전체 서비스와 종속성 집합을 살펴본 후 모든 중요 업무용 서비스를 위한 단일 DR 솔루션은 비용이 너무 많이 들고 복잡하므로 몇 가지 다른 DR 기능 수준을 고려할 필요가 있음을 알게 될 수 있습니다.
SLA(서비스 수준 계약) SLA는 서비스 공급자(IT)와 고객(조직) 간에 지정된 서비스의 가용성 목표를 정의하는 협약 또는 계약입니다. SLA는 길수도, 짧고 간결할 수도 있습니다. 예를 들어 "전자 메일 시스템은 일반적인 업무 시간에는 99.95% 사용 가능하고 일반적이지 않은 업무 시간에는 98% 사용 가능합니다. 단, 매월 측정되는 예약된 유지 관리 시간은 계산에서 제외합니다."와 같이 정의할 수 있습니다. 일반적으로 SLA는 IT 서비스를 할당할 수 있는 여러 계층으로 분할되며 미리 정의된 기간에 걸쳐 측정됩니다.
OLA(운영 수준 계약) OLA는 기본적으로 SLA를 지원하기 위해 작업하는 여러 IT 그룹 간의 계약을 기술합니다. 이 계약에는 해당 서비스 제공을 위한 처리 및 응답 시간이 포함됩니다. 예를 들어 중요 업무용 웹 사이트의 SLA 목표는 99.99%이지만 이 사이트의 콘텐츠를 제공하기 위해 사용되는 데이터베이스의 가용성 목표는 95%일 수 있습니다. OLA는 이러한 불일치를 밝혀내고 IT 팀이 같은 목표를 향하도록 조율합니다.
RPO(복구 지점 목표) 및 RTO(복구 시간 목표) RTO는 연속성이 끊어지기 전까지 허용되는 서비스 중단 시간을 정의하며 RPO는 조직에서 수용할 수 있다고 간주하는 데이터 손실의 수준을 정의합니다. 예를 들어 매달 측정하는 SLA가 99%라면 RTO는 7시간 18분입니다. 이를 가령 24시간 RPO와 조합하면 백업 기술과 일정을 정확하게 정의할 수 있습니다.
데이터 보존 정책 조직의 데이터 보존 정책은 백업을 저장해 두는 기간 및 그 위치를 지정합니다. 데이터 보존 정책은 일반적으로 법률 및 규정 요구 사항에 따라 결정됩니다.
데이터 분류 데이터의 성격에 대해서도 고려해야 합니다. 데이터를 범주별로 분류해 보면 모든 데이터에 대해 같은 수준으로 DR을 고려할 필요는 없다는 사실을 금방 알 수 있습니다. 예를 들어 단일 데이터베이스의 가용성 요구 사항은 각각 디렉터리 복제본을 포함하는 여러 개의 도메인 컨트롤러가 있는 Active Directory의 가용성 요구 사항과는 다를 것입니다. 마찬가지로, 파일 서버 데이터를 복원하는 절차는 CRM 데이터를 복원하는 절차와는 많은 부분에서 다를 것입니다.
재해 시나리오 각 시나리오는 복원 절차, 비즈니스에 미치는 영향 및 관련 비용이 서로 다르므로 계획하려는 모든 시나리오를 정의하는 것이 중요합니다. 환경에 맞는 DR 계획을 수립할 때는 가능한 모든 시나리오를 살펴보고 대상 시나리오를 결정하는 방법이 도움이 됩니다.
  • 전체 사이트 손실
  • 단일 데이터 센터 손실
  • 시스템 손실(운영 체제 또는 하드웨어 오류)
  • 데이터 손실(데이터 삭제 또는 손상)
  • 중요 종속성 손실
물론 전체 사이트 손실을 복구할 때의 고려 사항은 단일 시스템을 복구할 때와는 판이하게 다릅니다. 또한 SLA를 기반으로 복구 임계값도 정의해야 합니다. 예를 들어 대규모 ISP 네트워크 중단으로 인해 전체 사이트가 오프라인 상태가 되었다고 가정해 보겠습니다. 영향을 받는 서비스에 대한 SLA가 서비스 복원에 8시간, 데이터 복원에 48시간인 경우 아마 여러분은 백업 사이트로의 장애 조치 절차는 수행하겠지만 다시 프로덕션 사이트로의 전환이 신속히 이루어지리라 예상하고 데이터 복구 프로세스는 실행하지 않을 것입니다.
이런! 이렇게 많은 내용을 다루었는데 정작 기술에 대한 내용은 시작도 하지 못했네요. 계획의 중요성을 과소평가해서는 안 됩니다. 문서화된 계획이 없는 DR 구현은 단지 "DR 희망 사항"일 뿐입니다.

재해 복구 및 가상화
이것으로 DR 계획에 대한 기본 사항은 모두 설명했습니다. 여기에서 가상화는 어떤 역할을 할까요? 많은 회사에서는 실제 서버의 복원 시간이 일 또는 주 단위인데 반해 가상화된 서버를 이용할 경우의 복원 시간은 분 단위에 불과한 것으로 보고하고 있습니다. 가상화된 서버에서는 전체 서버 운영 체제가 기본 실제 하드웨어로부터 추상화된 단순한 파일 집합에 불과하므로 복구 기능에 있어 새로운 문이 열리게 됩니다.
현재 일반적인 이론은 HA(고가용성) 솔루션으로 일부 또는 모든 DR 목표를 달성할 수 있다는 것입니다. 여기에서의 기본 개념은 분리된 물리적 위치에 클러스터 노드가 있고 두 사이트 간에 데이터가 동기화된다면 오류가 발생할 경우 패시브 노드가 작업을 다시 시작하므로 거의 실시간으로 복구가 가능하다는 것입니다.
이는 사실이지만 앞에서 정의한 재해 시나리오를 감안하면 모든 재해 시나리오에 대한 솔루션은 아니라는 점을 알 수 있습니다. 모든 시나리오에 대비하려면 여러 기술을 조합해야 하며 일반적으로 여기에는 일종의 정기적인 백업이 포함됩니다. HA가 가능한 모든 가동 중단에 대한 보호를 제공하는 것은 아니며 백업 전략의 필요성을 완전히 없애는 것도 아닙니다.
Hyper-V를 포함하는 HA에서는 저장소 계층을 신중하게 계획해야 합니다. 저장소 계층은 복구 기능을 사용하기 위한 핵심 요소이기 때문입니다. 예를 들어 공유 저장소가 있는 2노드 Hyper-V 클러스터의 경우 클러스터 노드가 별도의 데이터 센터에 있는 경우라도 저장소 하위 시스템과 데이터가 여전히 단일 실패 지점입니다.
그러나 비공유 저장소를 사용하는 2노드 Hyper-V 클러스터는 둘 중 한 노드에 저장소 손실이나 데이터 손실이 발생하더라도 유지될 수 있습니다. 이를 위해서는 저장소를 동기화하기 위한 복제 기술이 필요하며 이에 따른 복잡성이 추가됩니다(그림 2 참조).
그림 2 다중 사이트 Hyper-V 클러스터 (더 크게 보려면 이미지를 클릭하십시오.)
데이터 복제 및 동기화 영역에는 몇 가지 매우 흥미로운 개발이 진행 중이지만 현재 Microsoft에서 제공하는 것은 아닙니다. Windows Server 2008 다중 사이트 클러스터링 페이지(microsoft.com/windowsserver2008/en/us/clustering-multisite.aspx)에 소개된 파트너 업체를 확인해 보십시오. 또한 Windows Server 카탈로그(windowsservercatalog.com 참조)에는 Windows Server 2008 인증을 받은 복제 기술을 제공하는 저장소 공급업체 목록이 나열되어 있습니다.
여기에서 볼 수 있듯이 가능한 HA와 저장소 구성은 많습니다. 이 부분 역시 비즈니스 요구 사항을 먼저 정의하고 여기에 맞추어 기술 요구 사항을 정의해야지 그 반대로 하면 안 되는 이유입니다.

실제 컴퓨터를 가상 컴퓨터로 변환
가상화는 몇 가지 뛰어난 복구 민첩성을 제공하지만 가상화에 적합하지 않은 실제 시스템의 경우에는 어떻게 해야 할까요? SCVMM(System Center Virtual Machine Manager)에는 실행 중인 Windows 서버에 대해 P2V(실제 컴퓨터에서 가상 컴퓨터로) 변환을 수행하여 실제 원본 서버의 완전한 복사본인 부팅 가능 Hyper-V VM(가상 컴퓨터)을 만드는 기능이 포함되어 있습니다. 이 VM을 해당 가상화 항목과 마찬가지로 한 부지 또는 전국에 걸쳐 복제하여 비슷한 복구 시간을 달성할 수 있습니다.
이 방법은 복구 위치에 프로덕션 위치와 같은 수 또는 유형의 실제 시스템이 필요 없다는 점에서 기존 BMR(Bare Metal Restore)과 다릅니다. 따라서 복구 하드웨어를 추가 구독하여 재해의 영향에 따라 필요한 만큼 이를 확장할 수 있습니다.
SCVMM에는 P2V 변환을 위한 스케줄러가 포함되어 있지 않지만 GUI가 완전히 Windows PowerShell을 기반으로 실행되므로 New-P2V cmdlet을 사용하여 간단하게 스크립트로 작성할 수 있습니다. 사실 SCVMM의 모든 마법사는 작업을 실행하는 데 사용하는 코드를 보여 주므로 여러분 환경의 테스트 P2V에서 코드를 복사하고 향후 자동화 작업에서 수정하여 사용할 수 있습니다. 그림 3에는 일부 샘플 코드가 나와 있습니다. SCVMM P2V 마법사를 여러분의 환경에서 실행하여 고유하고 사용자 지정이 가능한 Windows PowerShell 스크립트를 얻을 수 있습니다.
그림 3 SCVMM P2V 마법사에 의해 생성된 코드
$Credential = get-credential

New-MachineConfig -VMMServer <VMM SERVER> -SourceComputerName "<SOURCE P2V SERVER>"
-Credential $Credential -RunAsynchronously

$VMHost = Get-VMHost -VMMServer <VMM SERVER> | where {$_.Name -eq "<TARGET HYPER-V HOST>"}
$MachineConfig = Get-MachineConfig -VMMServer <VMM SERVER> | where {$_.Name -eq "<SOURCE P2V SERVER>"}

New-P2V -VMMServer <VMM SERVER> -VMHost $VMHost -RunAsynchronously -JobGroup
e823f50d-dbc7-4a41-9087-fb01bb44dc26 -SourceNetworkConnectionID "00:14:D1:3C:66:2F"
-PhysicalAddress "00:14:D1:3C:66:2F" -PhysicalAddressType Static -VirtualNetwork "External"
-MachineConfig $MachineConfig

$VMHost = Get-VMHost -VMMServer <VMM SERVER> | where {$_.Name -eq "<TARGET HYPER-V HOST>"}
$MachineConfig = Get-MachineConfig -VMMServer <VMM SERVER> | where {$_.Name -eq "<SOURCE P2V SERVER>"}

New-P2V -VMMServer <VMM SERVER> -VMHost $VMHost -RunAsynchronously -JobGroup
e823f50d-dbc7-4a41-9087-fb01bb44dc26 -VolumeDeviceID "C" -Dynamic -IDE -Bus 0 -LUN 0 -MachineConfig $MachineConfig

$Credential = get-credential
$VMHost = Get-VMHost -VMMServer <VMM SERVER> | where {$_.Name -eq "<TARGET HYPER-V HOST>"}
$MachineConfig = Get-MachineConfig -VMMServer <VMM SERVER> | where {$_.Name -eq "<SOURCE P2V SERVER>"}

New-P2V -Credential $Credential -VMMServer <VMM SERVER> -VMHost $VMHost -Path
"C:\ProgramData\Microsoft\Windows\Hyper-V" -Owner "DOMAIN\username" -RunAsynchronously -JobGroup
e823f50d-dbc7-4a41-9087-fb01bb44dc26 -Trigger -Name "<SOURCE P2V SERVER>" -MachineConfig
$MachineConfig -CPUCount 1 -MemoryMB 512 -RunAsSystem -StartAction NeverAutoTurnOnVM
-UseHardwareAssistedVirtualization $false -StopAction SaveVM

가상 컴퓨터 스냅숏
VM 스냅숏은 기술적으로 말해 백업은 아니지만 차이점 보관용 디스크와 VM 구성 파일 복사본을 사용하여 되돌릴 수 있는 특정 시점을 제공합니다. 재해가 발생하여 VM 내의 데이터가 뜻하지 않게 삭제된 경우 VM이 스냅숏으로 롤백을 수행하여 피해를 복원할 수 있으므로 이를 DR 기능으로 볼 수 있습니다. VSS(볼륨 섀도 복사본 서비스) 스냅숏에 대해서는 조금 뒤에 살펴보겠습니다.

Hyper-V 백업
호스트 기반 백업 서버 가상화의 흥미로운 이점 중 하나는 가상화된 시스템을 더 이상 개별적으로 백업할 필요가 없어질 수 있다는 가능성입니다. 이러한 시스템은 호스트의 파일 시스템에 위치한 파일에 불과하므로 이러한 파일을 백업하면 끝나는 것 아닐까요? 그렇지 않습니다. 이러한 시스템은 메모리 내 데이터, 디스크의 데이터, 시스템 구성, 열려 있는 파일 등으로 구성된 실제 작동 중인 컴퓨터이므로 몇 가지 고려해야 할 사항이 있습니다. 이렇게 유동적인 부분들로 구성되어 있는데 어떻게 백업 데이터 일관성을 보장할 수 있을까요?
Windows Server 백업에 있어 중요한 발전은 Windows Server 2003과 VSS의 등장에 따라 이루어졌습니다. VSS는 VSS 기록기(일관적인 섀도 복사본을 제공하는 데 도움이 되는 응용 프로그램과 서비스에 연결)가 열려 있는 파일과 응용 프로그램의 백업을 만드는 데 사용하는 확장 가능 API의 표준 집합을 제공합니다. 백업 응용 프로그램은 VSS 서비스, 공급자 및 기록기의 도움을 받아 특정 시점의 볼륨 복사본을 매우 신속하게 생성할 수 있으며 응용 프로그램에서는 이 복사본을 인식하고 적절하게 처리할 수 있습니다.
Hyper-V는 소프트웨어 개발 업체가 강력한 백업 솔루션을 만들 수 있도록 지원하는 자체 VSS 기록기를 제공합니다. 백업 응용 프로그램에서는 이 기록기를 사용하여 실행 중인 VM의 호스트 기반 VSS 백업을 얻을 수 있습니다. VM 내에서 실행 중인 운영 체제에 Hyper-V 통합 구성 요소와 VSS 서비스(Windows XP SP1 및 Windows Server 2003 이상에서 제공)가 설치되어 있는 경우 호스트 기반 백업은 게스트 내에서 실행되는 경우와 동일하게 수행됩니다. 백업은 VM 실행 중에 수행되며 데이터 일관성이 확보됩니다(그림 4 참조).
그림 4 VSS 백업(더 크게 보려면 이미지를 클릭하십시오.)
그러나 게스트 운영 체제가 통합 구성 요소나 VSS를 지원하지 않는 경우 백업 프로세스를 위해서는 게스트 컴퓨터를 저장된 상태로 전환해야 하며 VM 데이터 파일로부터 특정 시점 복구에 사용할 수 있는 호스트 기반 VSS 스냅숏을 만들어야 합니다. 저장된 상태의 VSS 스냅숏은 데이터의 VSS 복사본을 대상으로 전체 테이프 백업 절차를 수행하며 약간의 VM 가동 중지 시간(일반적으로 5분에서 10분)을 유발합니다.
게스트 기반 백업 실제 환경에서 서버와 응용 프로그램은 별도로 백업되어야 하며 이러한 백업은 가상화된 데이터 센터에서 확실히 지속이 가능합니다. 이러한 상황에서는 VM을 백업할 때 네트워크 기반 백업을 위한 네트워크 용량 요구 사항, 백업 시간 중 시스템의 성능에 미치는 영향과 같은 동일한 고려 사항을 참작해야 합니다. 게스트 기반 백업의 경우 모든 게스트가 사용하는 가상 네트워크에 바인딩되는 전용 실제 NIC를 호스트에서 사용할 수 있습니다.

Windows Server 백업
Windows Server 2008에 포함된 VSS 지원 WSB(Windows Server 백업)를 사용하면 Hyper-V 호스트 및 게스트 기반의 VM 백업을 수행할 수 있습니다. VSS를 완벽하게 지원하므로 실행 중인 VM의 호스트 기반 백업(당연히 둘 중에 이 방식이 더 바람직함)을 수행할 수 있습니다.
그러나 VM에 통합 구성 요소가 설치되지 않은 경우에는 VSS가 사용되지 않습니다. 이 경우에는 두 가지 옵션 중에서 선택할 수 있습니다. 여기에서도 WSB를 사용하여 통합 구성 요소가 설치되지 않은 VM을 백업할 수 있습니다. 이는 VM의 상태가 저장되고, 그 이후 백업이 VM의 가상 디스크와 구성 파일을 가져옴을 의미합니다.
그러나 이 방법은 Exchange와 같은 응용 프로그램에서는 바람직하지 않습니다. 백업이 실행되었음을 응용 프로그램이 인식하지 못하고, 응용 프로그램 로그가 잘리지 않기 때문입니다. 게다가 VM에 가동 중지 시간이 발생합니다. 이 시간은 백업 수행에 소요되는 시간에 따라 달라집니다.
다른 방법은 VM의 OS에 따라 NTBackup 또는 WSB를 사용하여 VM 내에서 실제 컴퓨터인 것처럼 백업을 실행하는 것입니다. 통합 구성 요소가 설치된 지원되는 게스트에 WSB를 사용하는 방법을 살펴보겠습니다.

WSB로 VM 백업
Hyper-V는 WSB에서 사용하도록 VSS 기록기를 자동으로 등록하지는 않습니다. 그림 5에 나와 있는 레지스트리 키와 값을 수동으로 추가해야 WSB가 Hyper-V 백업을 지원합니다. 다음과 같이 명령줄을 사용하여 이러한 항목을 추가할 수 있습니다.
reg add "HKLM\Software\Microsoft\windows nt\
  currentversion\WindowsServerBackup\Application
  Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}"
reg add "HKLM\Software\Microsoft\windows nt\
  currentversion\WindowsServerBackup\Application
  Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}" /v
  "Application Identifier" /t REG_SZ /d Hyper-v
그림 5 Hyper-V VSS 기록기를 등록하기 위한 키와 값
경로 | 레지스트리 키 또는 값 | 종류
HKLM\Software\Microsoft\windows nt\currentversion\WindowsServerBackup\ Application Support\ {66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE} | 키 | 해당 없음
HKLM\Software\Microsoft\windows nt\currentversion\WindowsServerBackup\ Application Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}\Application Identifier | 값 | REG_SZ(예: Hyper-V)
WSB는 백업 런타임에 이 키/값을 검색하므로 다시 부팅은 필요 없습니다. 다음 명령은 항목이 설정되었는지를 표시합니다.
reg query "HKLM\Software\Microsoft\windows nt\
  currentversion\WindowsServerBackup\Application
  Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}" /s
WSB를 설치하는 방법은 다음과 같습니다. 시작 | 서버 관리자를 클릭합니다. 왼쪽 창에서 기능을 클릭하고 오른쪽 창에서 기능 추가를 클릭합니다. 기능 선택 페이지에서 Windows Server 백업 기능을 확장하고 Windows Server 백업 및 명령줄 도구의 확인란을 선택합니다. 이제 다음 단계를 수행하여 백업을 구성합니다.
  1. 시작 | 관리 도구 | Windows Server 백업으로 이동합니다.
  2. 원격 호스트를 백업하는 경우 다른 컴퓨터에 연결을 선택하고 Hyper-V 호스트를 입력합니다.
  3. 한 번 백업 또는 백업 일정을 선택합니다.
  4. 백업 구성(전체 서버 또는 사용자 지정)을 선택합니다. 사용자 지정을 선택하는 경우 VM 구성 데이터, 가상 디스크 및 스냅숏을 포함하여 백업 중인 VM과 관련된 데이터가 포함된 모든 볼륨을 지정해야 합니다.
  5. 백업을 저장할 위치를 선택합니다.
  6. VSS 전체 백업 또는 복사본 백업을 선택합니다. 다른 VM 백업은 수행되지 않는 호스트 기반 백업의 경우 VSS 전체 백업을 선택합니다.
  7. 세부 정보를 확인한 다음 백업을 선택합니다.
고려 사항
  • VHD(가상 하드 디스크), VM 구성 파일 및 스냅숏을 포함하여 VM과 관련된 모든 볼륨을 백업해야 합니다.
  • 백업 일정을 만드는 경우 포맷하여 WSB에만 사용할 전용 로컬 볼륨을 사용해야 합니다. 반면 한 번 백업 작업을 수행하는 경우 전용이 아닌 로컬 볼륨, 이동식 장치 또는 네트워크 공유에 백업을 저장할 수 있습니다.
  • 백업되는 VM 내에 통합 구성 요소가 설치되지 않은 경우 WSB는 백업 데이터 일관성을 보장하기 위해 실행 중인 VM의 상태를 저장합니다.
  • 완료된 후 백업 세트는 이식이 가능하며 모든 Hyper-V 호스트에서 사용할 수 있습니다.
WSB로 VM 복원
WSB에는 개별 파일을 복원하는 기능이 있지만 이 기능은 VSS를 사용하지 않기 때문에 백업이 수행된 시점에 VM이 실행 중이었다면 일관성이 없는 복원 결과를 얻을 수 있습니다. 실행 중인 VM을 복원하려면 전체 볼륨을 복원해야 합니다.
이를 위해서는 시작 | 관리 도구 | Windows Server 백업으로 이동한 다음 작업 창에서 복구를 선택합니다. 복구할 데이터가 있는 서버(WSB 백업 데이터가 있는 위치)를 선택하고 데이터를 복원할 날짜를 선택합니다. 이제 복구 유형을 선택할 수 있습니다.
여기에서 한 가지 결정을 내려야 합니다. 구성, 스냅숏 및 가상 디스크를 포함한 전체 VM이 필요한 경우(예를 들어 호스트 전체적인 문제가 발생한 경우)에는 그림 6에 나와 있는 것처럼 응용 프로그램 복원, Hyper-V를 차례로 선택합니다. 이 경우에는 개별 파일을 복원하는 옵션은 없으며 해당 백업 세트에 포함된 모든 항목을 복원해야 합니다. 이렇게 해도 기존 백업 이후에 변경된 VM 구성 데이터와 Hyper-V는 덮어쓰지 않습니다.
그림 6 Hyper-V 백업 복원(더 크게 보려면 이미지를 클릭하십시오.)
VHD 자체만 필요하고 VM의 구성 데이터와 스냅숏에는 문제가 없는 경우 파일 및 폴더를 선택하고 필요한 개별 VHD 파일을 선택할 수 있습니다. 이 프로세스에는 VSS 기록기가 사용되지 않으므로 이를 염두에 두고 VM의 상태를 먼저 저장하고 백업해야 합니다.
전체 시스템과 데이터가 손실되어 Windows Server 2008 운영 체제와 그 내부에서 실행되는 모든 VM을 포함하여 Hyper-V 호스트 자체를 복구해야 하는 경우 Windows 복구 환경으로 부팅하고 그곳에서 복원을 수행해야 합니다. 이 작업은 Windows Server 2008 설치 디스크 또는 미리 구성된 디스크 파티션에서 수행할 수 있습니다.

Data Protection Manager
지금까지 안정적인 무료 기본 제공 WSB를 사용하여 Hyper-V 호스트와 게스트를 백업 및 복원하는 과정과 고려 사항을 살펴보았습니다. 그러나 WSB는 엔터프라이즈급 데이터 보호 솔루션은 아닙니다. WSB로 해결되지 않는 기능은 DPM(Data Protection Manager) 2007 SP1을 사용할 수 있습니다. 2008년 말에 출시될 예정인 DPM SP1은 Hyper-V를 지원하며 다음과 같은 몇 가지 매력적인 기능을 제공합니다.
  • 모든 Hyper-V 호스트 및 게스트에 대한 단일 관리 콘솔
  • 최대 15분 간격으로 VSS 기반 스냅숏을 만들고 프로세스에서 변경된 비트만 처리하여 연속적으로 데이터 보호
  • Hyper-V 클러스터 인식 기능을 통해 백업이 클러스터 노드 사이를 이동하는 VM을 추적 가능
  • DPM 서버에서 DPM 서버로의 복제
  • 디스크 및 테이프 미디어 지원(디스크-디스크, 디스크-테이프 또는 디스크-디스크-테이프)
  • Hyper-V 호스트와 게스트를 포함하는 모든 유형의 데이터를 포괄하는 백업 및 복원 기능, 실행 중인 게스트의 에이전트 없는 VSS 백업, 개별 VM 복원 지원, 장애 조치(failover) 클러스터 데이터, SQL Server, Exchange, SharePoint, Hyper-V 및 가상 서버를 위한 동급 최상의 응용 프로그램별 기능
  • 백업 전 및 백업 후 스크립팅
현재 타사 백업 솔루션을 사용하고 있다면 응용 프로그램 업데이트를 확인하십시오. 대부분의 공급업체에서는 Hyper-V 호스트 기반 솔루션 출시를 추진 중입니다.

스크립트를 사용한 백업
WSB에는 스크립팅에 사용하기 위한 Windows PowerShell cmdlet 집합과 명령줄 인터페이스인 WBadmin.exe가 포함되어 있습니다. 이러한 기능을 사용할 때는 앞서 설명한 백업 규칙이 동일하게 적용되며 레지스트리를 통해 Hyper-V VSS 기록기를 수동으로 등록해야 합니다.
그림 7은 몇 가지 WBAdmin 명령을 보여 줍니다. 전체 WBAdmin 설명서를 보려면 go.microsoft.com/fwlink/?LinkId=124380을 참조하십시오. 여기에서 볼 수 있듯이 WBAdmin에는 백업 정책 자체를 구성하기 위한 항목이 없지만 이러한 설정을 관리하기 위한 Windows PowerShell 스냅인이 있습니다. 다음 명령을 사용하면 이 스냅인이 등록되었는지 테스트할 수 있습니다.
Get-PSSnapin -Registered
그림 7 WBAdmin 명령
WBAdmin 명령 | 설명
ENABLE BACKUP | 예약된 매일 백업을 활성화하거나 수정합니다.
DISABLE BACKUP | 예약된 매일 백업의 실행을 비활성화합니다.
START BACKUP | 백업을 실행합니다.
STOP JOB | 현재 실행 중인 백업이나 복구를 중지합니다.
GET VERSIONS | 특정 위치에서 복구 가능한 백업의 세부 정보를 나열합니다.
GET ITEMS | 백업에 포함된 항목을 나열합니다.
START RECOVERY | 복구를 실행합니다.
GET STATUS | 현재 실행 중인 작업의 상태를 보고합니다.
GET DISKS | 현재 온라인 상태인 디스크를 나열합니다.
START SYSTEMSTATERECOVERY | 시스템 상태 복구를 실행합니다.
START SYSTEMSTATEBACKUP | 시스템 상태 백업을 실행합니다.
DELETE SYSTEMSTATEBACKUP | 시스템 상태 백업을 삭제합니다.
또한 다음 명령을 사용하여 Windows.ServerBackup 스냅인을 로드할 수 있습니다.
Add-PSSnapin windows.serverBackup
스냅인이 로드되면 그림 8에 나온 것과 같은 WSB용 Windows PowerShell cmdlet을 사용할 수 있습니다. 각 cmdlet에 대한 자세한 설명을 보려면 다음 명령을 실행하십시오.
Get-Command -PSSnapin windows.serverBackup | select name | get-help –full
그림 8 Windows Server 백업 cmdlet
cmdlet | 설명
Add-WBBackupTarget | 백업 대상을 백업 정책에 추가합니다.
Add-WBVolume | 볼륨을 백업 정책에 추가합니다.
Get-WBBackupTarget | 정책에서 백업 대상을 가져옵니다.
Get-WBDisk | 모든 디스크를 가져옵니다.
Get-WBPolicy | 현재 백업 정책을 가져옵니다.
Get-WBSchedule | 정책에서 백업 일정을 가져옵니다.
Get-WBSummary | 백업 기록과 요약을 가져옵니다.
Get-WBVolume | 모든 볼륨을 가져옵니다.
New-WBBackupTarget | 새 백업 대상을 만듭니다.
New-WBPolicy | 빈 정책을 새로 만듭니다.
Remove-WBBackupTarget | 정책에서 백업 대상을 제거합니다.
Remove-WBPolicy | 백업 정책을 삭제합니다.
Remove-WBVolume | 정책에서 볼륨을 제거합니다.
Set-WBPolicy | WBPolicy 개체를 저장하여 예약된 백업을 만듭니다.
Set-WBSchedule | 백업 정책에 일정을 설정합니다.

Windows Server 2008에는 Hyper-V VSS 작성기를 사용할 수 있고 스크립팅 옵션에 약간의 유연성을 더해주는 다른 유틸리티가 기본 제공됩니다. DiskShadow.exe를 사용하면 섀도 복사본을 만들어 드라이브로 탑재할 수 있으므로 관리자가 WSB를 사용할 때보다 더 선택적으로 백업을 만들 수 있습니다. DiskShadow는 Windows PowerShell 파이프라인 입력을 받지 않으므로 다음과 비슷한 형식으로 스크립트를 통해 명령을 전달해야 합니다.
Delete Shadows Volume C:
Set Context Persistent
Begin Backup
Writer Verify {66841cd4-6ded-4f4b-8f17-fd23f8ddc3de}
Add Volume C: ALIAS MyShadow
Create
End Backup
Expose %MyShadow% X:
Exit
이 스크립트는 먼저 드라이브 C:의 기존 섀도 복사본을 모두 삭제한 다음 DiskShadow가 실행된 후에 섀도 복사본이 유지되도록 합니다. 그런 다음 트랜잭션 블록을 만듭니다. 즉, 하나의 단계라도 실패하면 전체 프로세스가 실패합니다. 이 블록에서 DiskShadow는 Hyper-V의 작성기가 로드되었는지 확인하고 백업할 드라이브 목록에 드라이브 C:를 추가합니다.
드라이브 C:는 식별을 위한 GUID를 받고, 이 GUID는 "MyShadow"라는 환경 변수에 저장됩니다. 이 과정이 완료되면 섀도 복사본이 생성됩니다.
백업은 환경 변수를 사용하여 드라이브 X:로 노출됩니다. X:의 데이터에 대해 다양한 작업을 수행할 수 있으며 Unexpose X: 명령으로 DiskShadow를 다시 실행하여 드라이브를 제거할 수 있습니다.
DiskShadow를 통해 백업한 Hyper-V VM을 복원하는 과정은 현재로서는 수동 프로세스이므로 VM을 다시 만들어야 하고 스냅숏은 유지되지 않습니다. 여기에는 확실히 몇 가지 단점이 있지만 데이터는 보호됩니다.
요약
DR은 끝이 보이지 않는 험난한 프로세스가 될 수 있습니다. 그러나 서버 가상화를 사용하면 기술과 이 기술로 인한 저렴한 진입점 덕분에 새로운 가능성이 열리게 됩니다. Microsoft는 가상화뿐만 아니라 전체적인 환경을 제공합니다. 서버 가상화 플랫폼과 System Center 제품군은 DR을 포함하여 오늘날 조직이 당면한 날로 복잡해지는 과제에 대한 전체적인 솔루션을 제공합니다.
이 기사를 작성하는 데 도움을 준 James O'Neill에게 감사의 뜻을 전합니다.

Adam Fazio는 2년 전부터 Microsoft Consulting Services에서 업무를 시작했으며 현재는 공공 부문 업무를 당담하고 있습니다. 그는 IT 업계에서 10년 이상 활동하면서 Fortune 100대 기업부터 인터넷 업체에 이르기까지 다양한 인프라 프로젝트와 데이터 센터 운영에 참여했습니다. 현재는 Microsoft에서 글로벌 Virtualization Rapid Deployment 프로그램의 기술 강화 부문 책임자입니다.


Virtualization
가상 인프라 계획을 위한 필수 도구
Jay Sauls와 Baldwin Ng
한 눈에 보기:
  • 비용 절감
  • 컴퓨터 인벤토리 작성
  • CPU, 디스크 I/O 및 네트워크 사용률 확인

목차
도구 개요
기존 환경 조사
현재 사용률 확인
서버 배치 권장 사항
가상 컴퓨터 구성
배치 제약 조건
옵션 고려
요구 사항
요약
가상화는 새로운 기술은 아니지만 1960년대 IBM에서 처음 개발한 플랫폼 가상화를 멀리 뛰어넘어 여러 새로운 영역으로 확산되고 있습니다. 이러한 급격한 성장의 가장 중요한 원동력은 데이터 센터와 다양한 IT 작업에서 비용 절감에 도움을 주는 가상화 기술의 가능성입니다. 에너지 비용이 상승하고 조직 내의 여러 부서에서 요구하는 IT 서비스가 끊임없이 증가함에 따라 관리자는 운영 비용을 억제하면서 서버 확장을 유지해야 한다는 어려운 상황에 처하게 되었습니다. 가상화가 이 상황에 도움이 될 수 있습니다. Microsoft 및 여타 소프트웨어 개발 업체에서는 서버, 데스크톱, 응용 프로그램 가상화를 비롯하여 가상 리소스를 더 광범위하게 사용할 수 있는 새로운 기술을 개발해왔습니다.
이 기사에서는 가상화 프로젝트에 도움이 되는 도구 집합인 MAP(Microsoft Assessment and Planning)에 대해서 살펴보겠습니다. MAP는 Microsoft Solution Accelerator 제품군에 속합니다. Solution Accelerator는 간단히 말해 거의 모든 IT 프로젝트에 필요한 자동화 도구와 지침입니다. Solution Accelerator는 데스크톱에서 서버까지, 실제 환경에서 가상 환경까지 IT 인프라를 사전에 계획, 제공 및 운영하는 데 도움이 되는 권위 있는 무료 리소스입니다.
업계 전문가와의 협력을 통해 개발되어 실제 고객 환경에서 테스트를 거친 Solution Accelerator는 불필요한 작업 없이 높은 성능을 달성하고 제품 간 IT 인프라를 구축하기 위한 최적 수준의 규범적 지침과 자동화를 제공합니다. 이러한 리소스는 인프라 평가 및 계획, 가상화, 통신 및 공동 작업, 보안 및 규정 준수와 같이 모든 규모의 회사에 해당되는 핵심적인 사안에 중점을 둡니다.

도구 개요
새로 출시된 MAP Toolkit 3.1(그림 1)은 네트워크 수준 인프라 평가 도구로, 현재 서버 및 데스크톱이 Hyper-V, Microsoft Application Virtualization, Windows Server 2008, Windows Vista, Office 2007 및 SQL Server와 같은 기술로 업그레이드 또는 마이그레이션할 준비가 되었는지를 비롯한 기본적인 정보를 신속하게 제공하는 데 도움이 되도록 디자인되었습니다.
그림 1 Microsoft Assessment and Planning Toolkit 3.1 (더 크게 보려면 이미지를 클릭하십시오.)
그림 2에서 볼 수 있듯이 MAP는 준비도 평가 보고서와 제안을 자동으로 생성하여 사용자가 해야 할 일을 많이 덜어 줍니다. MAP Toolkit 3.1은 Windows Vista 업그레이드를 위한 데스크톱 컴퓨터 평가와 Microsoft Application Virtualization 롤아웃 계획을 포함하여 서버와 데스크톱 시나리오를 모두 지원합니다.
그림 2 자동 생성된 마이그레이션 제안 샘플 (더 크게 보려면 이미지를 클릭하십시오.)
서버 가상화 계획에서는 도구의 세 가지 핵심 기능, 즉 서버 인벤토리, 성능 메트릭 수집, 그리고 가상화 배치 권장 기능을 사용하여 적합한 후보 컴퓨터를 확인할 수 있습니다. 지금부터 시나리오를 통해 이러한 기능을 사용하여 사용자의 현재 환경에 대한 세부적인 그림을 그리고 가상화 전환을 계획하는 방법을 살펴보겠습니다.

기존 환경 조사
대기업에는 System Center Operations Manager와 같은 일종의 서버 관리 인프라가 구축되어 있는 경우가 많습니다. 이중에는 그다지 활발하게 관리되지 않는 환경도 있습니다. 현재 사용 중인 환경에 어떤 서버가 있는지, 또는 이러한 서버가 무엇을 실행하고 있는지 확실히 알지 못하는 경우에는 서버 인벤토리 기능을 사용하여 신속하게 명확한 정보를 얻을 수 있습니다. 서버 인벤토리는 Active Directory, IP 주소 범위 검사 또는 플랫 파일에서 컴퓨터 목록을 가져오는 간단한 방법으로 현재 환경에 있는 컴퓨터를 검색할 수 있습니다. 또한 그림 3에서 볼 수 있듯이 여러 검색 방법을 함께 사용하여(예: Active Directory와 IP 주소 범위 검사) Active Directory에 있어야 하지만 그렇지 않은 컴퓨터를 찾을 수도 있습니다.
그림 3 컴퓨터 검색 방법 선택 (더 크게 보려면 이미지를 클릭하십시오.)
컴퓨터를 검색하는 동안 MAP Toolkit 3.1은 각 컴퓨터에 연결하고 WMI(Windows Management Instrumentation)를 통해 50가지 이상의 데이터를 검색합니다. 이 데이터를 바탕으로 여러 가지 종류의 보고서를 생성할 수 있습니다. 가상화를 사용한 서버 통합에서 가장 관심이 가는 보고서는 특정 역할 및 서비스를 Windows Server 2008로 마이그레이션하도록 선택할 때 생성되는 보고서입니다.
지금 당장 Windows Server 2008로 마이그레이션하지 않더라도 이 시나리오에서 생성되는 두 가지 보고서는 사용자 환경에 있는 하드웨어의 종류(프로세서 유형 및 속도, 디스크 크기, 설치된 메모리 등), 각 서버에 할당한 소프트웨어 역할(DNS 서버, 도메인 컨트롤러 및 터미널 서비스)을 알아내는 데 유용합니다.
이러한 보고서는 Microsoft Excel 통합 문서로 제공되므로 Excel의 정렬과 필터링 도구를 사용하여 손쉽게 사용자 환경에서 어떤 컴퓨터가 가상화에 알맞은 후보인지 정확히 알아낼 수 있습니다.
서버 인벤토리 보고서는 가상화할 서버를 선택할 때 고려할 수 있는 여러 특성에 대한 데이터를 제공합니다. 예를 들어 가상화하려는 컴퓨터가 Hyper-V 가상화 플랫폼에서 지원하는 OS를 실행하고 있는지 확인할 수 있습니다. 서버 인벤토리 프로세스에서 생성된 WS2008HardwareAssessment Excel 통합 문서에서 Server Inventory(서버 인벤토리) 탭을 열고 Current Operating System(현재 운영 체제)과 Service Pack(서비스 팩) 열을 보면 업그레이드가 필요한 시스템을 알 수 있습니다.

현재 사용률 확인
가상화 후보를 찾는 다음 단계에서는 실제 컴퓨터의 사용률을 측정합니다. MAP Toolkit 3.1의 Performance Metrics Wizard(성능 메트릭 마법사)(그림 4 참조)는 가상화 후보로 식별된 컴퓨터 목록에서 성능 카운터를 기록합니다. 나중에 검토할 수 있도록 CPU 사용률, 디스크 I/O 사용률 및 네트워크 사용률이 모두 캡처됩니다.
그림 4 Performance Metrics Wizard(성능 메트릭 마법사) (더 크게 보려면 이미지를 클릭하십시오.)
이 기능은 상당히 긴 시간 동안(최대 한 달) 컴퓨터를 관찰하도록 설계되었으므로 사용하는 방법에 있어 어느 정도의 유연성이 제공됩니다. 현재 환경에서 사용률이 가장 높은 시간을 이미 잘 알고 있다면(예: 주별 일괄 처리 시간) 이 시간에 해당하는 몇 시간 동안만 마법사를 실행하도록 설정할 수 있습니다. 사용률이 가장 높은 시간을 확실히 모르거나 사용률이 가장 높은 시간이 각기 다른 여러 컴퓨터를 관찰하려는 경우에는 며칠 또는 몇 주 동안 마법사를 실행하도록 설정하여 컴퓨터의 데이터를 기록할 수 있습니다. 이렇게 하면 도구에서는 광범위한 데이터 집합을 통해 자동으로 최고 사용률을 찾습니다.
이전 인벤토리에서 얻은 정보를 바탕으로 Excel의 정렬과 필터링 기능을 이용하면 모니터링하려는 컴퓨터의 목록을 만들 수 있습니다. Performance Metrics Wizard(성능 메트릭 마법사)는 한 줄당 하나의 컴퓨터 이름이 있는 플랫 파일로 이 목록을 받습니다. Excel의 컴퓨터 이름 목록을 메모장의 새로운 빈 텍스트 파일로 복사하고 이 파일을 저장합니다. 메시지가 표시되면 이 파일을 마법사로 가져오고 성능 메트릭 수집 기간의 종료 시간을 설정합니다. 그러면 마법사는 데이터 수집 모드로 전환되어 지정된 컴퓨터에서 5분 간격으로 성능 카운터를 수집합니다.
Performance Metrics Wizard(성능 메트릭 마법사)가 완료되면 모든 관찰 대상 컴퓨터와 다양한 사용률 범주(CPU, 실제 디스크, 논리 디스크 및 네트워크)에 대한 모든 성능 메트릭을 나열하는 세부적인 Excel 보고서가 생성됩니다. 이 정보를 사용하면 가상화를 위한 후보 목록을 더 정리할 수 있습니다.
사용률이 극히 낮은 여러 컴퓨터를 대상으로 하여 이러한 컴퓨터를 단일 호스트의 VM(가상 컴퓨터)으로 통합하거나 이 정보를 인벤토리 데이터와 결합하여 고가용성이 필요한, 업무에 필수적인 서비스가 있는 컴퓨터를 찾을 수 있습니다. 고가용성 환경에 향상된 재해 복구 기능을 제공하는 데 가상화를 사용할 수 있습니다. 분석이 완료되면 가상 컴퓨터 배치 권장 사항을 생성하는 마지막 단계로 진행할 수 있습니다.

서버 배치 권장 사항
Server Virtualization and Consolidation Wizard(서버 가상화 및 통합 마법사)를 사용하면 CPU, 네트워크, 디스크 하위 시스템 및 메모리 측면에서 가정에 근거한 가상 호스트 컴퓨터 구성을 지정할 수 있습니다. Server Virtualization and Consolidation Wizard(서버 가상화 및 통합 마법사)는 Performance Metrics Wizard(성능 메트릭 마법사)를 통해 수집한 성능 데이터를 사용하여 VM 게스트에서 VM 호스트로의 적절한 매핑을 계산하고 최대 사용량 시간에 과도하게 사용되는 일 없이 각 호스트가 적당하게 사용되도록 보장합니다.
Server Virtualization and Consolidation Wizard(서버 가상화 및 통합 마법사)가 완료되면 게스트 VM에서 실제 호스트로의 권장 매핑을 포함하는 세부적인 Excel 스프레드시트가 생성됩니다. 이 보고서는 각 VM과 호스트에 대한 예상 디스크 I/O, 네트워크 I/O 및 CPU 사용률을 보여 줍니다. 조정 프로세스 동안 실제 호스트 컴퓨터에 게스트 VM이 추가되며 이전 호스트의 용량이 모두 차면 새 호스트가 할당됩니다. 새 호스트가 할당될 때마다 그 이유를 설명하는 메시지가 표시됩니다.
여러 호스트에서 동일한 메시지가 표시되는 경우 다른 호스트 구성으로 Placement Wizard(배치 마법사)를 실행하여 각 호스트에 할당되는 게스트의 수를 늘리는 방법을 고려할 수 있습니다. 예를 들어 여러 호스트에서 메모리 한계에 도달했다는 메시지가 표시되는 경우 마법사를 다시 실행하고 호스트 구성에 더 많은 RAM을 지정할 수 있습니다. 이렇게 하면 각 호스트에 할당할 수 있는 게스트의 수가 늘어납니다.

가상 컴퓨터 구성
Server Virtualization and Consolidation Wizard(서버 가상화 및 통합 마법사)의 각 페이지에서 VM 호스트 컴퓨터의 용량을 모델링하는 데 사용될 가정에 근거한 컴퓨터 구성의 주요 구성 요소를 구성할 수 있습니다. Virtual Server 2005 R2 및 Hyper-V용 모델이 모두 제공되며 마법사의 첫 번째 페이지에서 사용할 가상화 기술을 선택할 수 있습니다(그림 5 참조).
그림 5 배치 권장에 사용되는 가상화 기술 선택 (더 크게 보려면 이미지를 클릭하십시오.)
CPU 구성 페이지에는 여러 AMD 및 Intel CPU 제품군의 모델이 제공됩니다. 사용 중인 CPU와 정확히 일치하는 모델이 없으면 가장 비슷한 항목을 선택하십시오. 이 페이지에서 실제 프로세서, 코어, 그리고 코어당 하이퍼스레드의 수를 구성할 수 있습니다. 가상화 플랫폼으로 Hyper-V를 선택하면 64비트 CPU만 사용할 수 있습니다(그림 6 참조).
그림 6 호스트 CPU 구성 (더 크게 보려면 이미지를 클릭하십시오.)
마법사의 세 번째 페이지에서는 디스크 드라이브의 수와 RAID 기술을 기준으로 디스크 하위 시스템을 구성하여 호스트에서 사용 가능한 전체 디스크 공간과 디스크 하위 시스템의 처리량 값을 계산할 수 있습니다. 처리량 값은 선택한 인터페이스 기술, 디스크 RPM(분당 회전 수) 속도를 바탕으로 자동으로 제공됩니다.
MAP Toolkit 3.1은 SAN(저장소 영역 네트워크) 및 NAS(Network Attached Storage) 디스크 솔루션 모델링을 위한 직접적인 지원은 제공하지 않습니다. 대략적인 예측이 필요하면 SCSI 디스크 기술을 선택하고 비슷한 속도의 디스크로 사용자의 SAN 구성과 비슷한 RAID 수준을 구성하면 됩니다. 초기 계획에 도움이 되려면 이 대략적인 예측 값이 실제 값과 충분히 근접해야 합니다.

배치 제약 조건
가상화된 게스트 컴퓨터가 실제 호스트에 매핑되는 동안 게스트가 호스트 컴퓨터의 남은 용량에 들어갈 수 있는지 확인하기 위해 다음 6개의 요소가 고려됩니다.
  • CPU 사용률
  • 네트워크 I/O 사용률
  • 디스크 하위 시스템 I/O 사용률
  • 메모리
  • 디스크 공간
  • 지정된 가상화 기술의 게스트 OS 지원
CPU, 네트워크 및 디스크 하위 시스템 사용률은 무척 간단합니다. 실제 가상화 게스트 후보에서 측정된 사용률은 가상화 호스트 컴퓨터의 해당 사용률로 변환되며 이 값이 호스트의 기존 사용률에 더해집니다. 해당 리소스에 대해 이 호스트에 할당된 모든 게스트의 전체 사용률이 임계값 제한보다 낮으면 게스트가 호스트에 할당됩니다. 그렇지 않으면 이 게스트는 배치되지 않고, 다른 게스트로 시도하여 여기에 맞는지 확인하는 작업이 수행됩니다.
예를 들어 CPU 사용률이 32%인 1.2GHz Pentium 4 CPU를 장착한 컴퓨터의 성능 메트릭을 수집했다고 가정해 보겠습니다. 쿼드 코어 Intel Xeon 5300 시리즈 CPU로 가상화 호스트를 구성하는 경우 잠재적 게스트 컴퓨터의 원래 CPU 사용률을 기초로 호스트 컴퓨터에 해당하는 예상 사용률이 추정됩니다. 이 새로운 사용률은 새로운 CPU 아키텍처, CPU 클럭 속도 차이, 그리고 더 많은 코어 수로 인해 원래 측정된 값보다 낮게 나옵니다.
이와 반대로 게스트보다 성능이 낮은 CPU로 호스트 컴퓨터를 구성하는 경우 호스트에 대해 추정된 예상 사용률이 더 높아집니다. 두 경우 모두 게스트를 할당할 때 호스트 컴퓨터의 전체 사용량을 계산하는 데는 새로 추정된 CPU 사용률이 사용됩니다.
메모리와 디스크 공간의 사용률이 계산되는 방법에 대해서도 간단하게 설명할 필요가 있습니다. 각각의 잠재적 가상화 게스트에 설치된 실제 메모리의 전체 크기가 호스트 컴퓨터에서 예약됩니다. 여기에 호스트 자체를 위한 약간의 추가 메모리(512 MB)가 예약됩니다. 게스트 할당과 호스트 오버헤드로 인해 호스트의 전체 메모리가 소진되면 해당 호스트 컴퓨터에는 더 이상 가상화 게스트를 배치할 수 없습니다.
디스크 공간도 비슷하게 처리됩니다. 각각의 잠재적 가상화 게스트에 설치된 실제 디스크의 전체 크기가 호스트 컴퓨터에서 예약됩니다. 여기에 가상화 호스트에서 사용하기 위한 50GB의 디스크 공간이 추가로 예약됩니다. 호스트에 할당된 모든 게스트의 전체 디스크 사용량과 호스트 자체에 예약된 공간을 합친 크기가 호스트 구성에 지정된 크기에 도달하면 게스트가 더 이상 할당되지 않습니다.
게스트 컴퓨터에서 실행 중인 OS가 실제로 가상화 플랫폼에서 지원되는지 확인하는 검사가 선택된 가상화 플랫폼을 바탕으로 수행됩니다. 예를 들어 64비트 OS는 Virtual Server 2005 R2에서 게스트로 지원되지 않으므로 가상화 기술로 이를 선택해도 배치되지 않습니다.

옵션 고려
Server Virtualization and Consolidation Wizard(서버 가상화 및 통합 마법사)를 여러 번 실행하면 가상화 호스트 컴퓨터에 대한 다양한 하드웨어 선택의 결과를 손쉽게 비교할 수 있습니다. 마법사를 실행할 때마다 다른 CPU, 디스크 및 메모리 옵션을 선택하여 현재 환경에 가장 알맞은 솔루션을 찾을 수 있습니다.
서버 통합 Excel 통합 문서에서 Consolidation Recommendations(통합 권장 사항) 탭에 있는 Last Placement Failed Reason(마지막 배치 실패 원인) 열을 주의하여 살펴보십시오. 이러한 원인을 보면 특정 호스트에 게스트 컴퓨터를 추가로 배치할 수 없는 이유를 알 수 있습니다. 예를 들어 게스트의 메모리 사용량이 호스트에서 사용할 수 있는 메모리를 초과한다는 것이 여러 호스트에서 공통적인 원인으로 표시되는 경우 호스트 구성에서 메모리 양을 늘리면 필요한 전체 호스트의 수를 줄일 수도 있습니다.

요구 사항
MAP Toolkit 3.1의 장점 중 하나는 인벤토리 대상 컴퓨터에 소프트웨어를 설치할 필요가 없다는 것입니다. 모든 작업은 원격으로 수행됩니다. 그러나 모든 것이 올바르게 작동하도록 하려면 몇 가지 요인을 고려해야 합니다.
Inventory Wizard(인벤토리 마법사)와 Performance Metrics Wizard(성능 메트릭 마법사)가 올바르게 작동하려면 대상 컴퓨터에서 일부 TCP 포트가 열려 있어야 하며 MAP Toolkit가 설치된 컴퓨터에서 이러한 포트에 액세스할 수 있어야 합니다. 이 요구 사항에 대해서는 시작 가이드에 자세히 나와 있습니다. 요약하자면 인벤토리 대상 컴퓨터에서 인증, DCOM 및 WMI를 위한 포트는 반드시 열려 있어야 합니다. MAP Toolkit 3.1을 실행하는 컴퓨터와 인벤토리 대상 사이의 네트워크에 방화벽이 설치된 경우에는 이 트래픽이 통과할 수 있도록 방화벽을 구성해야 합니다.
MAP Toolkit 3.1은 최대 100,000대의 컴퓨터로 구성된 환경에서 인벤토리를 작성하고 한 번에 최대 3,000대의 컴퓨터에서 성능 메트릭을 수집하도록 만들어졌습니다. 기본적으로 이 도구는 SQL Server 2005 Express Edition의 전용 인스턴스를 설치합니다. SQL Server Express의 경우 데이터베이스 파일 크기가 4GB로 제한되므로 이 구성에서는 파일 크기 제한을 초과하지 않는 선에서 약 20,000대의 컴퓨터를 인벤토리로 작성할 수 있습니다. 인벤토리 중에 더 많은 컴퓨터를 사용하려면 몇 가지 기본값을 수정해야 합니다.
더 큰 환경에서 작업하려면 SQL Server 2005 Standard Edition과 같은 정식 버전의 SQL Server를 사용해야 합니다. MAP Toolkit를 설치하기 전에 새 SQL Server 2005 인스턴스를 설치하고 인스턴스 이름을 "MAPS"로 지정하십시오. 그런 다음 이 컴퓨터에서 평상시와 같이 MAP Toolkit 설치 프로그램을 실행하면 됩니다. MAP Toolkit에는 SQL Server 로컬 인스턴스가 필요하며, 설치 프로그램은 데이터베이스 서버의 로컬 "MAPS" 인스턴스를 자동으로 인식하고 SQL Server Express Edition을 설치하는 대신 여기에 도구를 설치합니다.
더욱 큰 환경의 경우에는 확장 기능을 사용할 수 있습니다. 확장 기능을 사용하면 MAP Toolkit가 설치된 여러 대의 도우미 컴퓨터가 협력하여 대규모 인벤토리 작업을 실행하고 수집한 모든 데이터를 하나의 중앙 데이터베이스에 저장할 수 있습니다. 이 구성에서도 4GB 파일 크기 제한을 피하려면 SQL Server Standard Edition을 사용해야 합니다.
이 구성에서 이 도구를 설치하는 방법과 이 모드에 맞게 데이터베이스 연결 문자열을 편집하는 방법에 대한 자세한 내용은 시작 가이드를 참조하십시오. 확장 기능은 MAP Toolkit가 설치된 컴퓨터가 아닌 다른 컴퓨터에 SQL Server를 배치하려는 경우에도 사용할 수 있습니다.

요약
Microsoft Assessment and Planning Toolkit와 같은 Solution Accelerator는 IT 프로젝트의 힘든 작업을 여러분 대신 처리하기 위한 도구입니다. 지금까지 많은 사용자가 MAP Toolkit를 활용하여 Hyper-V 배포를 위한 IT 계획에서 많은 시간을 절약했습니다. 이제 여러분이 직접 시도해 보십시오.
직접 사용해 보려면 microsoft.com/map에서 무료로 Microsoft Assessment and Planning Toolkit를 다운로드하거나 microsoft.com/vsa에서 다른 Virtualization Solution Accelerator를 다운로드할 수 있습니다. 또한 MAP Toolkit 팀 블로그(blogs.technet.com/mapblog)에 방문하면 팁과 데모 비디오도 볼 수 있습니다.

Jay Sauls는 Microsoft Solution Accelerators 그룹의 선임 프로그램 관리자이며 Windows Vista Hardware Assessment 및 Microsoft Assessment and Planning Toolkit와 같은 도구의 디자인과 구현을 담당하고 있습니다. 이전에는 Microsoft Commerce Server, Microsoft BizTalk 및 System Center Capacity Planner를 포함한 다양한 Microsoft 제품 팀에서 일했습니다.

Baldwin Ng는 Microsoft Solution Accelerators Core Engineering 팀의 선임 프로그램 관리자이며 현재 Microsoft Assessment and Planning Toolkit와 Virtualization Solution Accelerators를 포함한 여러 프로젝트를 진행 중입니다. Baldwin은 Microsoft, Corbis 및 Alltel에서 16년 이상 IT, 전자 상거래, 무선 인터넷 서비스 분야의 제품 관리 및 개발 업무를 진행했습니다. 또한 blogs.technet.com/MAPBLOG에서 활발하게 블로그를 운영하고 있습니다.


From the Editor 본격화된 가상화 환경
Joshua Hoffman

이제 가상화는 우리 곁에 있습니다. 칼럼의 서두를 장식할 만한 거창한 문구는 아니지만 사실입니다. 기반 하드웨어 리소스에서 운영 체제를 분리하는 가상화의 개념은 1967년 IBM CP/CMS 운영 체제가 발표되면서 처음 소개되었으며 확고하게 정립된 기반 위에서 40여 년간 많은 변화가 있었습니다.
2008년 현재 우리는 컴퓨터 가상화의 전환기를 맞고 있습니다. 더 강력한 다중 코어 프로세서와 새로운 하이퍼바이저 기술이 현실화되고, 비용 절감, 관리 간소화, 그리고 지속 가능한 컴퓨팅 관례에 대한 필요가 대두됨에 따라 가상화가 전면에 나서야 할 때가 되었습니다. TechNet Magazine 이번 호에서 중점적으로 다루는 내용이 바로 이것입니다. 이를 위해 Windows Server 2008의 새롭고 흥미로운 Hyper-V 플랫폼, 가상 환경을 관리하기 위한 도구, 그리고 가상 응용 프로그램 배포를 위한 기술에 대한 기사를 마련했습니다.
개인적으로는 전체 TechNet Magazine 직원을 대신하여 유명한 Microsoft Scripting Guys의 객원 편집자인 Greg Stemp와 Jean Ross에게 감사 인사를 전하고 싶습니다. 아마도 Microsoft Scripting Guys가 실제로는 작은 키에 유난히 큰 머리, 한 손에는 실험관을 다른 손에는 스크립트를 들고 Microsoft 복도를 뛰어다니는 사람이 절대 아니라는 것을 알면 다소 놀라실 것 같습니다. 사실 지난 3년간은 Greg와 Jean이 TechNet Magazine의 Hey, Scripting Guy! 칼럼을 진행하면서 전 세계적으로 선풍적인 반응을 얻었습니다. Hey, Scripting Guy!는 단지 유명한 칼럼이 되는 데 그치지 않고 많은 상을 수상했으며 계속되는 성원과 셀 수 없을 만큼 많은 독자 전자 메일을 받았습니다.
여러 가지 이유가 있겠지만 특히 이 두 명이 사랑받는 필자였기 때문에 Greg와 Jean이 이달 부로 작별을 고한다는 사실에 TechNet Magazine의 모든 직원들은 아쉬운 마음을 금할 수가 없습니다. 어쩔 수 없는 일이기는 하지만 Greg와 Jean은 더 나은 제안을 받아서 자리를 옮기게 되었습니다. 다행스러운 것은 앞으로도 레드먼드 본사에서 Microsoft 고객을 대상으로. 이들이 재능을 발휘하는 모습을 볼 수 있다는 것입니다. 이들의 앞길에 좋은 일만 있기를 바라며 지면을 통해서 다시 만날 수 있기를 기대합니다.
당분간은 존경받는 Scripting Guys 기고가 중 한 명인 Dean Tsaltas가 Hey, Scripting Guy!를 맡기로 결정되었으며 차세대 Scripting Guys를 찾는 동안 우리를 도울 예정입니다. Dean은 다음 달 WMI(Windows Management Instrumentation)에 대한 내용을 가지고 독자 여러분에게 인사를 드릴 예정입니다. 놓치지 마십시오! —Joshua Hoffman

도움을 주신 Microsoft 기술 전문가: Karri Alexion-Tiernan, Carmen Asher, Scott Culp, Steve Ekren, Trina Gorman, Michael Michael, Mike Mitchell, Michael Murgolo, Rob Polly, Dan Reger, Jez Sadler, Bill Scheidel, Bryon Surace, Jim Truher.


Letters 독자의 목소리

SQL 데이터베이스 관리
2008년 8월호 "SQL Server: 효과적인 데이터베이스 유지 관리를 위한 유용한 팁" 기사(technet.microsoft.com/magazine/cc671165)에 대한 감사 인사입니다. SQL 섹션에도 마침내 SQL Server를 호출하는 응용 프로그램이 실행 및 백업되는지만 확인하기를 원하는, 우리와 같은 "본의가 아니게 DBA가 된 운영자"를 위한 기사가 실려서 정말 다행입니다.
그리고 바로 다음 페이지에서 "Windows Administration: 서버 성능 평가"(technet.microsoft.com/magazine/cc718984)를 볼 수 있어서 정말 좋았습니다. 이 두 기사를 잡지에서 오려서 보관해 두었습니다. 디지털 잡지에서는 할 수 없는 일이지요. 따로 오려둔 기사들은 앞으로도 자주 볼 예정입니다. 앞으로도 좋은 정보 부탁드립니다.
두 기사가 마음에 드셨다니 다행입니다. 내용이 유용했다는 의견은 언제나 우리에게 큰 힘이 됩니다. 그러나 불만 사항이 있다면 이 역시 알려 주십시오. 앞으로 다루어졌으면 하는 다른 주제가 있으면 이에 대한 내용도 알려 주십시오. 항상 독자 여러분의 의견에 귀를 기울이고 있습니다.
—Joshua Hoffman, 편집장

Image X와 Windows PE
ImageX와 Windows PE를 사용하여 이전 운영 체제를 배포하는 방법을 다룬 칼럼("Windows XP와 Windows PE 2.0 이중 부팅," 2008년 2월, technet.microsoft.com/magazine/cc194422)을 잘 보았습니다. 저는 작년에 이러한 도구의 잠재력을 발견했으며 그때부터 우리 회사에서 사용하던 이미징 도구(Acronis Snap Deploy)를 대체하기 위한 실험을 했었습니다. 그리고 6개월 전부터는 제가 원하는 기능을 모두 사용할 수 있게 되어 현재는 이 이미징 도구만 사용하고 있습니다.
그러던 중 이 기사를 읽으면서 bootsect.exe /n52 옵션을 추가하라는 조언을 보았습니다. 이 옵션은 처음 보는 것이었습니다. 지금까지는 이미지를 적용하기 전에 포함된 스크립트(commands.txt)로 DiskPart를 사용하여 하드 드라이브를 삭제하기만 했었습니다. 아직까지는 문제가 없었지만 앞으로 문제가 생길 수도 있는 것일까요?
이전에는 이 명령이 필요했었습니다. 그런데 기사가 나가고 나서 팀원에게 이 명령이 더는 필요 없다는 이야기를 들었습니다. 이제는 새로운 스타일의 부트 관리자 코드를 찾고 이것이 없는 경우 오류를 발생시키기 전에 NTLDR을 수행하는 논리가 부트 코드에 추가되었기 때문입니다. 따라서 이제는 명령을 사용하지 않더라도 아무런 문제가 없습니다.
—Wes Miller(The Desktop Files 칼럼니스트)

이미지 환경 테스트
ImageX 도구를 사용하여 이미지를 구현하고 WDS(Windows 배포 서비스)를 통해 멀티캐스트를 활성화하는 내용을 다룬 Desktop Files 칼럼("Windows XP와 Windows PE 2.0 이중 부팅")을 읽었습니다. 테스트 환경을 탑재하려고 하는 데 정확히 어떤 도구가 필요한지 알고 싶습니다. 멀티캐스트를 구현하려면 Windows Server 2008을 설치해야 할까요? 그리고 이미지를 미러링하려면 ImageX를 활용해서 Deployment 4 또는 WAIK(Windows 자동 설치 키트)와 WDS를 설치해야 합니까?
WDS를 사용해서 멀티캐스트를 활용하려면 Windows Server 2008이 설치되어 있어야 합니다. Windows Server 2003에는 멀티캐스트 구성 요소가 없으며 앞으로도 제공되지 않을 예정입니다.
멀티캐스트를 활용하는 데 Deployment 4는 필요 없습니다. 이를 사용하려면 Windows Server 2008과 Windows Server 2008용 WAIK 릴리스 버전이 필요합니다. WAIK 릴리스 버전에는 처음으로 Windows PE에 대한 멀티캐스트를 제공하는 데 필요한 기능이 포함되어 있습니다.
—Wes Miller

WDS 멀티캐스트
ImageX를 사용하여 컴퓨터에 대한 이미지를 복제하려고 했었는데 ImageX가 멀티캐스트 전송을 지원하지 않는다는 문제가 있었습니다. 멀티캐스트 전송을 지원하는 WDS 서버를 사용하여 동일한 작업을 하려고 합니다. 이것이 가능할까요? Wdsmcast 명령을 사용하면 가능할 것 같기는 하지만 WDS 클라이언트가 WDS 서버에 다운로드할 이미지를 알려 주려면 어떻게 해야 할까요?
ImageX 자체는 멀티캐스트를 처리할 수 없습니다. 서버에서 이를 시작한 다음에는 Windows Server 2008 WAIK에 있는 Wdsmcast를 사용하여 연결할 전송을 지정해야 합니다. "전송 서버 사용"(technet.microsoft.com/library/cc725964)이라는 백서에 Wdsmcast를 사용하여 연결하는 방법에 대한 정보가 잘 정리되어 있습니다. "Wdsmcast.exe를 사용하여 클라이언트 서버를 네임스페이스에 연결하는 방법" 섹션을 읽어 보십시오.
—Wes Miller

문의처 보내 주실 의견이 있으십니까? tnmag@microsoft.com으로 전자 메일을 보내거나 blogs.technet.com/tnmag에 있는 블로그 포럼에 방문해 주십시오.


Toolbox IT 전문가를 위한 신제품
Greg Steen

여기에 기재된 가격은 2008년 8월 19일에 확인한 것이므로 변경될 수 있습니다. 이 칼럼에 언급된 의견은 전적으로 저자의 개인적인 의견이며 항상 Microsoft의 의견을 반영하지는 않습니다.

휴대용 응용 프로그램
PortableApps.com
PortableApps.com
IT 전문가라면 시스템을 여기저기 옮겨 다니는 경우가 많을 것입니다. 그리고 이때 당장 사용할 수 있는 나만의 표준 응용 프로그램, 도구 및 문서 집합이 있었으면 좋겠다는 생각도 들 것입니다. 이러한 요구 사항을 충족시킬 수 있는 한 가지 간단한 방법은 PortableApps.com에서 제공하는 시작 관리자 플랫폼으로 시작하는 것입니다. 이 사이트에서는 무료 공개 소스 PortableApps.com Platform뿐만 아니라 USB 플래시 드라이브, 메모리 카드, 휴대용 하드 드라이브 또는 디지털 음악 플레이어에서 단독으로 실행할 수 있는 많은 휴대용 응용 프로그램도 제공합니다.
PortableApps.com Suite도 있습니다. 이 간편한 다운로드에는 사용 가능한 휴대용 응용 프로그램 번들과 기반 플랫폼 모두가 하나의 설치 관리자 안에 포함되어 있습니다. PortableApps.com Suite에는 두 가지 버전이 있습니다. Suite Light에는 Mozilla Firefox, Thunderbird 및 Sunbird와 ClamWin 바이러스 백신 프로그램, 인스턴트 메시징에 사용되는 Pidgin, Sumatra PDF 리더, KeePass 암호 관리자, AbiWord 워드 프로세서 및 간단한 게임이 포함되어 있습니다. Suite Standard에는 이러한 응용 프로그램은 물론 Writer, Calc, Impress, Base 및 Draw가 포함된 OpenOffice.org Office 제품군도 기본 제공되어 있습니다.
또한 이 사이트에는 FTP용 FileZilla, 텔넷 및 SSH용 PuTTY, SFTP 및 SCP용 WinSCP, 빠른 목록용 PNotes 및 Task Coach, 보관용 7-Zip, 명령 프롬프트, 파일 정리용 Eraser, CD/DVD 굽기용 InfraRecorder, 디스크의 내용을 시각화하기 위한 WinDirStat, 파일을 확인하기 위한 winMd5Sum, 파일 및 디렉터리 비교를 위한 WinMerge 등 "휴대용"으로 만들어진 기타 공개 소스 응용 프로그램들도 많습니다. (필자의 Toolbox 칼럼을 자주 보는 독자라면 필자가 이전 호에서 이러한 응용 프로그램들을 많이 다루었다는 사실을 알 수 있을 것입니다.)
WinPCap 및 Wireshark와 같은 네트워크 유틸리티의 휴대용 버전을 사용하고 있는 매우 활동적인 사용자 커뮤니티도 있습니다. (이러한 두 도구는 관리 작업과 문제 해결 작업에서 매우 유용할 수 있습니다.) 포럼에는 휴대용으로 만들 응용 프로그램을 제안하는 목적으로만 사용되는 공간도 제공되어 있습니다.
이러한 응용 프로그램은 사용하는 저장 장치에서 독립적으로 실행됩니다. 이 응용 프로그램은 레지스트리에 쓰기 작업을 수행하거나 "디스크 외부" 액세스가 필요한 경우 이러한 작업을 종료하자 마자 모든 것을 실행 이전의 상태로 되돌립니다. 그리고 PortableApps.com Platform 없이도 응용 프로그램을 실행할 수 있습니다. 응용 프로그램이 고유한 설치 프로그램에 래핑된 상태로 제공되기 때문입니다. 그러나 이와는 별개로 Platform의 기능을 사용해야 하는 경우가 많을 것입니다. Suite는 휴대할 수 있는 사용자 지정 환경을 만들기 위한 훌륭한 출발점입니다.
PortableApps.com Platform은 자동 실행되도록 설정되어 있습니다. 따라서 Windows 호스트 컴퓨터에 USB 플래시 또는 휴대용 드라이브를 넣으면 플랫폼 응용 프로그램을 실행하기 위한 옵션이 표시됩니다. 플랫폼을 시작하면 시스템 트레이 아이콘이 표시됩니다. 이 아이콘을 클릭하면 Windows 시작 메뉴와 비슷한 메뉴가 나타납니다. 이 응용 프로그램 시작 관리자는 사용자의 모든 휴대용 응용 프로그램에 대한 빠른 링크와 휴대용 드라이브의 문서 폴더에 대한 링크, 드라이브에 남아 있는 여유 공간을 알려주는 표시기, 드라이브의 문서에 대한 백업 유틸리티, 검색 도구 및 새로운 휴대용 응용 프로그램을 설치하기 위한 링크를 제공합니다. 이 인터페이스를 사용자 지정하고 30개 이상의 인터페이스 언어 중 하나를 선택할 수 있습니다.
이 플랫폼으로 잠시 동안 작업해 보면 응용 프로그램을 수정하여 휴대용으로 만들 수 있는 방법에 대해 관심이 생길 것입니다. PortableApps.com 웹 사이트에는 이러한 방법을 제공하는 활동적인 Portable App Development 포럼도 있습니다. 모든 사항을 고려할 때 PortableApps.com Platform은 하나의 휴대용 패키지에 포함된 매우 유용한 도구 집합입니다.

가격: 무료.
도구를 휴대할 수 있게 해 주는 PortableApps

원격 시스템 문제 해결
TeamViewer
teamviewer.com
응용 프로그램 문제를 해결하거나, 제품 데모와 자습서를 제공하거나, 사용자의 질문을 이해하려고 할 때 .컴퓨터 바로 앞에 앉아서 작업하는 것보다 좋은 방법은 없습니다. 그러나 불가능한 경우가 종종 있습니다. 차선책은 실제로 컴퓨터 앞에 앉아 있지 않고도 "컴퓨터 앞에 있도록" 도와주는 도구를 사용하는 것입니다. TeamViewer GmbH의 TeamViewer가 바로 그것입니다.
이 유틸리티의 설치 프로세스는 매우 간단하여,1 원격 시스템에 빠르게 연결할 수 있습니다. TeamViewer에서 지원하는 기본 작동 모드에는 네 가지가 있습니다. 하나는 원격 시스템을 제어하여 문제를 해결하고, 작업과 유지 관리에 도움을 주고, 사용자에게 특정 작업을 안내할 수 있는 Remote Support입니다. 그리고 원격 사용자의 시스템에 로컬 사용자의 바탕 화면을 표시하여 작업을 시연하거나 프레젠테이션을 제공할 수 있는 Presentation도 있습니다. 또 다른 모드는 데스크톱을 실제로 공유하지 않고도 두 시스템이 서로 파일을 주고받을 수 있는 File Transfer입니다. 그리고 마지막으로 로컬 사용자와 호스트 컴퓨터 간 인스턴트 가상 사설망을 만들 수 있는 VPN이 있습니다(이 모드에서는 TeamViewer VPN 어댑터 설치 옵션을 사용합니다).
보안의 경우 이 응용 프로그램은 RSA 키 교환 및 256비트 AES 세션 인코딩을 사용합니다. 키 교환을 사용하면 "man in the middle(메시지 가로채기)"(예: TeamViewer 라우팅 서버)이 데이터 스트림을 가로채지 못합니다. 또한 Supporter 세션(Supporter는 세션을 호스팅하는 주체를 지칭하는 데 사용되는 용어임)에 연결하면 세션 ID와 암호가 생성되고, 원격 사용자는 이를 입력하여 이 세션에 연결해야 합니다. 다른 한쪽 끝에 사람이 없는 상태에서 서버 관리 등을 위해 시스템에 연결하려는 경우 TeamViewer를 시스템 서비스로 설치하면 계속해서 파일을 쉽게 전송하고, 원격 제어 기능을 사용하고, VPN을 만들고, 원격 시스템을 다시 부팅할 수 있습니다.
또 다른 멋진 기능은 TeamViewer QuickSupport 모듈(또는 Customer 모듈)입니다. 이 기능은 지원 또는 프레젠테이션을 위해 응용 프로그램을 사용하려는 경우에 특히 유용합니다. 이 모듈은 실행할 원격 시스템에 소프트웨어를 설치하지 않아도 되고, 이 시스템에 대한 설치 권한도 필요 없는 비교적 작은 실행 파일입니다. 최종 사용자는 .exe 파일을 두 번 클릭하고 세션 ID와 암호를 입력하기만 하면 로컬 세션을 원격 시스템에 손쉽게 연결할 수 있습니다.
TeamViewer에는 몇 가지 매우 유용한 구성 옵션이 있습니다. 먼저 디스플레이에서 공유되는 수많은 색을 최적화하거나, 디스플레이에서 원격 배경 무늬를 제거하거나, Windows Vista Aero 투명 효과를 설정한 상태로 유지하도록 설정할 수 있습니다. 그리고 로컬 세션의 일반 품질/또는 속도 설정을 조정할 수 있습니다. 또한 원격 제어, 파일 전송, VPN 연결, 원격 키보드 및 마우스 입력, 로컬 및 원격 호스트 간 제어 전환 및 원격 화면 보기 등 다양한 기능을 허용할지 여부를 제어할 수 있습니다.
나중에 재생하거나 감사하기 위해 세션을 기록할 수 있으며 보안 구성 등으로 인해 TeamViewer의 서버로 라우팅하지 않으려는 경우 TeamViewer가 LAN 연결만 사용하여 라우팅되도록 선택할 수도 있습니다.
무제한 Supporter 설치를 지원하는 Premium 버전에는 CD 또는 USB 플래시 드라이브에 저장하여 도구를 휴대할 수 있게 해 주는 Portable 버전도 포함되어 있습니다. Premium 버전에는 세션 정보를 기록하고, 파트너 정보를 저장할 수 있게 해 주는 TeamViewer Manager도 포함되어 있습니다. 이 두 기능은 클라이언트를 추적하고, 클라이언트에 보고하고, 클라이언트에게 송장을 보내는 데 유용합니다. TeamViewer는 Mac OS X에서도 사용할 수 있고, 플랫폼 간 액세스를 지원하므로 로컬 Windows 시스템에서 Mac에 연결할 수 있습니다.

가격: 비상업용의 경우 무료. Business 버전은 Supporter 설치 하나당 699달러부터 시작합니다. Premium 버전은 1,399달러이며 무제한 Supporter 설치를 지원합니다.
TeamViewer를 통해 원격 시스템에 연결

서평
End-to-End Network Security: Defense-in-Depth
오늘날의 네트워크 보안에는 문제에 대한 노출을 줄이고 네트워크 인프라의 내부 및 외부에서 침해 가능성을 제한하기 위해 다층적 사전 대응 기술이 통합되어 있습니다. Omar Santos의 저서 End-to-End Network Security: Defense-in-Depth(Cisco Press, 2007)는 점점 더 복잡해지고 있는 네트워크 보안을 이해하는 데 도움을 줍니다.
이 책은 Cisco Press에서 출판되었으므로 물론 Cisco 장비에 치우쳐 설명하고 있지만 상당히 많은 일반화된 보안 정보를 제공하므로 인프라 보안에 관심이 있는 네트워크 전문가나 시스템 관리자에게 훌륭한 참고 자료가 될 것입니다.
이 책은 먼저 방화벽 및 VPN부터 침입 감지/방지 기술 및 ID 관리까지 네트워크 보안 기술에 대해 전체적으로 살펴봅니다. 그런 다음 보안 문제를 처리하기 위한 6단계 방법론인 준비, 식별(보안 위협 요소), 분류(보안 위협 요소), 역추적, 대응 및 사후 평가에 대해 자세히 설명합니다.
이 책은 계속해서 IDS/IPS, NAC, AAA, SNMP, Syslog 및 VLAN을 포함한 다양한 장치 및 도구를 사용하는 사전 대응 보안 프레임워크에 대해 살펴봅니다. 그런 다음 Cisco의 심층적인 방어 기술로 넘어가서 무선 네트워크, IP 전화 통신, 데이터 센터 보안 및 IPv6 보안에 대해 주로 살펴봅니다. 왜냐하면 이 책은 이러한 네트워크 보안 영역에 대한 Cisco의 솔루션과 관련되어 있기 때문입니다. 이 책의 마지막 부분에서는 세 가지 사례 연구를 통해 실제 소규모, 중규모, 대규모 기업 보안 솔루션에 대해 설명합니다.

가격: 49.50달러(직판가)

장치 ID 확인
PCIDatabase.com
PCIDatabase.com
시스템을 업그레이드할 때 한두 개의 장치가 "PCI ㅈkdcl"라는 것 외에 어떤 설명도 없는 알 수 없는 장치로 표시되어 컴퓨터 케이스를 뜯어내고 손전등으로 내부를 비춰보지 않고서는 이 장치가 어떤 장치인지 알 수 없거나 드라이버를 어떻게 구할지 몰랐던 적이 있으십니까? 또는 알려진 장치의 기본 칩셋이 무엇인지 알아내려고 했던 적도 있었을 것입니다. 바로 이럴 때 유용한 무료 서비스가 PCIDatabase.com입니다.
이 사용자 지원 데이터베이스를 사용하면 공급업체, 장치 이름, 장치 ID를 조건으로 검색하여 자세한 정보를 얻을 수 있습니다. Device Manager를 열고 해당 장치를 마우스 오른쪽 단추로 클릭하고 Properties를 선택한 후 Details 탭을 누른 다음 Hardware ID 속성을 선택하기만 하면 됩니다. 여기에는 "VEN_"(공급업체의 경우) 및 "DEV_"(장치의 경우)가 앞에 오는 몇 가지 16진수 값이 포함된 문자열 집합이 표시됩니다.
이 사이트에서는 조회한 장치에 사용할 수 있는 드라이버가 있는지 파악하는 데 도움이 되는 여러 유용한 리소스에 대한 링크를 제공합니다(그리고 물론 제조업체의 웹 사이트를 확인하는 것도 잊지 마십시오).
PCIDatabase.com에서 제공하는 또 다른 유용한 기능은 특정 공급업체를 조회하는 경우에 본사 주소, 전화번호, 관련 웹 사이트, 연락처, PCI 장치 공급업체의 16진수 ID가 나열된 페이지와 사이트에 등록된 모든 공급업체 장치의 목록이 표시되는 기능입니다. 그리고 이 사이트는 사용자 지원 사이트이므로 여러분이 알고 있는 지식을 추가하도록 장려합니다.

가격: 무료.
PCIDatabase.com에서 공급업체 및 장치 정보 확인(더 크게 보려면 이미지를 클릭하십시오.)

감사 및 인벤토리 자산
CCS Network Inventory
crowcanyon.com
책상 앞에 가만히 앉아서 클라이언트 컴퓨터 중 하나에 무엇이 설치되어 있지를 확인할 수 있다면 상당한 시간을 절약할 수 있습니다. 그리고 사실 시간별로 이러한 자산을 추적하는 일은 여러분의 임무 중 하나입니다. Crow Canyon Systems에서 제공하는 CCS Network Inventory 솔루션을 사용하면 이러한 작업을 수행하는 데 도움이 됩니다.
이 응용 프로그램은 에이전트가 없는 인벤토리이자 LAN에서 하드웨어, 소프트웨어, 서비스 및 사용자 정보를 수집하는 워크스테이션을 검색하는 감사 도구입니다. CCS Network Inventory에서는 원격 에이전트를 사용하지 않으므로 로컬 실행 컨텍스트에 RPC, Computer Browser 서비스, Remote Registry 서비스, 파일 및 프린터 공유, 인벤토리 목록을 작성할 시스템에 대한 ADMIN$ 공유 액세스가 필요합니다(대부분의 다른 에이전트 없는 인벤토리 제품과 똑같음).
이 응용 프로그램은 쿼리에 대해 대체 자격 증명을 사용할 수 있도록 지원하므로 여러 도메인을 검색할 때 유용합니다. 이 응용 프로그램을 설치하면 IP 주소 범위를 검색하거나, Windows 네트워크 검색을 사용하거나, 시스템 목록을 가져오거나, 인벤토리 목록을 작성할 Windows 워크스테이션 목록을 수동으로 지정할 수 있습니다.
CCS Network Inventory가 무엇을 검사하는지에 대해 살펴보자면, 이 응용 프로그램은 설치된 응용 프로그램, 적용된 핫픽스, 시스템에 설치된 OS 및 서비스 팩 및 설치된 글꼴 등의 소프트웨어 정보를 수집합니다. 시스템 구성의 경우 실행 중인 서비스 및 기타 프로세스, 공유되는 폴더, 드라이브 매핑, 환경 변수, 사용자 계정, 예약 작업, 시작 명령 및 실행 중인 네트워크 프로토콜을 확인할 수 있습니다. 그리고 하드웨어의 경우 연결된 모니터, 프린터, 하드 디스크(크기 및 파티션 포함), CD 및 DVD 드라이브 정보, 프로세서, 메모리 등의 정보를 볼 수 있습니다. 또한 레지스트리 값, 파일 개수(예: 가장 많은 mp3 파일이 들어 있는 곳) 및 드라이브의 여유 공간에 대한 사용자 지정 검사를 설정할 수 있습니다.
이러한 모든 정보는 응용 프로그램의 사용자 지정 데이터베이스에 저장되며 보고서를 만들기 위한 데이터로 사용될 수 있습니다. CCS Network Inventory에서는 감사 및 보고의 목적으로 데이터를 시각화하고 전송하기 위해 많은 기본 제공 보고서를 제공합니다. 기본 제공 보고서 및 쿼리 정보에 필요한 정보가 포함되어 있지 않은 경우 기본 제공 SQL 쿼리 작성기 도구를 사용하여 데이터에 대해 더욱 자세한 또는 구체적인 쿼리를 작성하고 실행할 수 있습니다.
시간의 흐름에 따른 변경 내용을 확인할 수 있도록 환경 스냅숏을 만드는 것이 좋습니다. CCS Network Inventory를 사용하면 정보 데이터베이스의 두 인스턴스를 비교하여 이러한 변경 사항을 확인할 수 있습니다. 예를 들어 1년 전에 수행된 검사와 현재 검사를 비교하여 Windows Vista로 전환된 워크스테이션의 개수, 작년에 하드웨어 구성 요소가 업데이트된 워크스테이션의 개수 또는 경고를 받은 후에도 지원되지 않는 소프트웨어를 계속해서 실행한 사용자를 확인할 수 있습니다.
이 문서를 작성할 당시에는 CCS Network Inventory가 Windows 2008 Server를 완전히 지원하지 않았지만 기타 Windows 버전부터 Windows Vista까지 지원했습니다.

가격: 최대 25개 노드를 지원하는 버전의 경우 235달러
CCS Network Inventory로 원격 자산 관리

Toolbox로 의견 보내기 여기에서 다루었으면 하는 도구나 유틸리티가 있으면 tntools@microsoft.com 주소로 저자에게 알려 주십시오.

Greg Steen은 사업가이자 열성적인 기술 전문가로, IT 전문가들의 운영, QA 및 개발 업무에 도움을 줄 수 있는 새로운 도구를 끊임없이 연구하고 있습니다.


SQL Q&A 대용량 트랜잭션 로그, 복구 사용 시점 및 기타 정보
Paul S. Randal

Q: 백업과 관련해서 이상한 동작이 있는데 설명을 부탁드립니다. 저희는 응용 프로그램 개발자들이 사용하는 데이터를 새롭게 갱신하기 위해 빈번하게 62GB 용량의 프로덕션 데이터베이스를 백업합니다. 기존 복사본은 새 복사본을 복원하기 전에 항상 삭제합니다. 복원된 복사본의 크기는 프로덕션 데이터베이스와 동일하고, 데이터 자체도 같은 것으로 보이는데 복원 프로세스에 걸리는 시간이 백업 프로세스 시간에 비해 너무 깁니다. 왜 그럴까요? 백업보다 복원에 훨씬 더 많은 시간이 소요되는 이유는 무엇입니까?
A: 이상한 일이 아닙니다. 환경에 따라 다르긴 하지만 일반적으로 자연스러운 현상입니다. 백업과 복원에 필요한 시간의 차이는 각 프로세스에서 수행해야 하는 단계에 따라 발생합니다.
데이터베이스 백업은 두 단계로 구성됩니다. 기본적으로 보면 그저 데이터베이스에서 IO를 읽고 백업 장치에서 IO를 쓰는 것입니다.
백업 1단계 데이터 파일에서 모든 할당된 데이터를 읽어 백업 장치에 씁니다.
백업 2단계일부 트랜잭션 로그를 읽어 백업 장치에 씁니다.
필요한 트랜잭션 로그의 정확한 크기는 경우에 따라 상당히 달라지는데, 이 크기는 복원된 데이터베이스를 일관된 시점으로 복구하기 위해 필요한 만큼의 크기입니다. 이에 대한 더 심층적인 설명은 sqlskills.com/blogs/paul/2008/01/31/MoreOnHowMuchTransactionLogAFullBackupIncludes.aspx의 블로그 게시물에서 볼 수 있습니다.
반면 데이터베이스 복원은 최대 4단계로 구성될 수 있습니다. 또한 필요한 작업도 단순히 IO를 읽고 쓰는 것보다 더 복잡합니다.
복원 1단계 데이터베이스 파일이 존재하지 않으면 만듭니다.
복원 2단계 백업에서 모든 데이터 및 트랜잭션 로그를 읽어 해당되는 데이터베이스 파일에 씁니다.
복원 3단계 트랜잭션 로그에서 복구의 다시 실행 단계를 실행합니다.
복원 4단계트랜잭션 로그에서 복구의 실행 취소 단계를 실행합니다.
백업의 두 단계에 소요되는 전체 시간은 복원 2단계에 필요한 시간과 얼추 비슷합니다(하드웨어 및 서버가 비슷하고 사용자 활동이 없다고 가정할 경우). 데이터 파일이 크고 0으로 초기화되어야 하는 경우(SQL Server 2000의 동작이며 SQL Server 2005에서는 기본 동작) 복원 1단계에 걸리는 시간이 길어질 수 있습니다.
이를 방지하려면 복원을 시작하기 전에 기존 파일을 삭제하지 마십시오. 또는 즉시 초기화를 사용하여 파일이 매우 빠른 속도로 만들어지도록 합니다. 이에 대한 자세한 내용은 msdn.microsoft.com/library/ms175935.aspx를 참조하십시오.
복원 3단계와 4단계는 복원된 데이터베이스가 트랜잭션 측면에서 일관성을 갖도록 하기 위해 복구를 실행하는 단계입니다. 이 프로세스는 크래시 복구 동안 데이터베이스에서 수행되는 프로세스와 동일합니다. 복구에 소요되는 시간은 처리해야 하는 트랜잭션 로그의 양에 따라 달라집니다. 예를 들어 백업이 이루어진 시점에 상당히 오랫동안 실행되는 트랜잭션이 활성 상태였다면 해당 트랜잭션에 대한 모든 트랜잭션 로그가 백업에 포함되어 롤백되어야 합니다.

Q: 프로덕션 데이터베이스의 여유 복사본을 제공하기 위해 로그 전달과 데이터베이스 미러링 중 하나를 선택하려고 합니다. 특히 매일 밤 실행하는 인덱스 재작성 작업에서 서버 간에 전송해야 하는 트랜잭션 로그의 양이 걱정됩니다. 미러링에서는 트랜잭션 로그가 아닌 실제 재작성 명령이 전송되고 미러에서 재작성이 수행된다고 들었습니다. 정말인가요? 그렇다면 BULK_LOGGED 복구 모델을 사용한 로그 전달보다도 미러링이 더 좋은 방법인 것 같은데요, 그렇지 않나요?
A: 사실과 다른 이야기를 들으셨네요. 데이터베이스 미러링은 주 데이터베이스에서 미러 서버로 실제 트랜잭션 로그 레코드가 전송되고, 전송된 트랜잭션 로그 레코드가 미러 데이터베이스에서 "재생"되는 방식으로 동작합니다. 여기에서는 어떤 종류의 변환이나 필터링, 또는 미러링된 데이터베이스에 대한 T-SQL 명령 가로채기도 수행되지 않습니다.
데이터베이스 미러링은 FULL 복구 모델만 지원하며 이는 인덱스 재작성 작업이 항상 완전히 로그에 기록됨을 의미합니다. 즉, 이는 관련 인덱스의 크기에 따라 상당한 양의 트랜잭션 로그가 생성되고, 그에 따라 주 데이터베이스와 로그 파일이 커지고, 미러로 로그 레코드를 전송하기 위한 네트워크 대역폭 사용량이 높아질 수 있음을 의미합니다.
데이터베이스 미러링은 실시간 로그 전달이라고 보면 됩니다. 사실 SQL Server 2005 개발 작업 초기에는 실시간 로그 전달이라는 이름이 사용되었습니다. 로그 전달에서는 주 데이터베이스 트랜잭션 로그의 백업이 정기적으로 보조 서버로 전달되어 보조 데이터베이스에서 복원됩니다.
로그 전달은 FULL 복구 모델과 BULK_LOGGED 복구 모델을 지원합니다. FULL 복구 모델을 사용하는 로그 전달 데이터베이스의 인덱스 재작성 작업에서는 미러링된 데이터베이스에 대해 생성되는 양과 동일한 양의 트랜잭션 로그가 생성됩니다. 그러나 로그 전달 데이터베이스 시나리오에서 데이터는 지속적인 흐름이 아닌 하나의 로그 백업(또는 일련의 로그 백업)으로 중복 데이터베이스로 전송됩니다.
인덱스 재작성이 수행될 때 로그 전달 데이터베이스에 BULK_LOGGED 복구 모델이 사용되는 경우에는 최소한의 트랜잭션 로그만 생성됩니다. 그러나 다음 트랜잭션 로그 백업에는 최소한으로 로그에 기록된 인덱스 재작성 작업에 의해 변경된 모든 데이터 파일 익스텐트도 포함됩니다. 이는 BULK_LOGGED 복구 모델에서 인덱스 재작성을 포함하는 로그 백업의 크기가 FULL 복구 모델에서 인덱스 재작성을 포함하는 로그 백업의 크기와 거의 비슷하다는 사실을 의미합니다.
따라서 여유분의 데이터베이스로 전송되어야 하는 정보의 양은 미러링된 데이터베이스의 인덱스 재작성에 대해서나 로그 전달 데이터베이스의 인덱스 재작성에 대해서나 동일합니다. 실질적인 차이는 정보가 전송되는 방법, 즉 지속적으로 전송되느냐 일괄 처리로 전송되느냐에 있습니다.
이 두 가지 접근 방법 중 하나를 선택할 때는 다른 많은 요소도 고려해야 합니다(1회분의 SQL Q&A에서 다루기에는 너무 많음). 결정을 내리기 전에 이러한 모든 요소가 현재 요구 사항에 어떻게 부합하는지 파악해야 합니다(예: 허용 가능한 데이터 손실 제한선, 허용 가능한 가동 중지 시간).

Q: SQL Server 2005를 실행 중인데 데이터베이스 중 하나의 트랜잭션 로그가 계속 커집니다. 데이터베이스는 전체 복구 모드로 설정되어 있으며 트랜잭션 로그 백업을 수행하고 있습니다. 이렇게 하면 트랜잭션 로그가 커지는 현상을 막을 수 있다고 생각했습니다. 정확히 어떤 부분이 잘못되었습니까?
A: 전체 복구 모드에서는 트랜잭션 로그 백업을 수행하는 것이 중요하다는 점은 맞습니다. 그러나 다른 요소들도 트랜잭션 로그의 증가를 유발할 수 있습니다. 관건은 트랜잭션 로그가 필요하도록 만드는 요소, 또는 트랜잭션 로그가 활성 상태일 것을 요구하는 요소가 무엇이냐입니다. 트랜잭션 로그 백업의 부족 외에 이 문제의 원인이 되는 다른 일반적 요소로는 복제, 데이터베이스 미러링, 활성 트랜잭션 등이 있습니다.
복제는 트랜잭션 로그 레코드를 비동기적으로 읽은 다음 트랜잭션을 로드하여 별도의 배포 데이터베이스로 복제하는 방식으로 이루어집니다. 아직 복제 로그 판독기 작업에서 읽지 않은 트랜잭션 로그 레코드는 해제될 수 없습니다. 현재 작업 부하가 많은 양의 트랜잭션 로그 레코드를 생성하고 복제 로그 판독기가 실행되는 간격이 길게 설정되어 있는 경우 많은 레코드가 누적되어 트랜잭션 로그의 증가를 유발할 수 있습니다.
비동기 데이터베이스 미러링을 실행 중인 경우 주 데이터베이스에서 미러 데이터베이스로 아직 전송되지 않은 트랜잭션 로그 레코드의 백로그가 존재할 수 있습니다(데이터베이스 미러링 SEND 큐라고 함). 트랜잭션 로그 레코드는 성공적으로 전송될 때까지 해제될 수 없습니다. 트랜잭션 로그 레코드가 생성되는 속도가 빠른 상태에서 네트워크 대역폭이 제한적이거나 다른 하드웨어 문제가 있는 경우 백로그의 크기가 상당히 커지면서 트랜잭션 로그의 증가를 유발할 수 있습니다.
마지막으로, 사용자가 명시적인 트랜잭션을 시작한 후에(예: BEGIN TRAN 문 사용) 수정 작업을 실행하는 경우(예: DDL 문 또는 삽입/업데이트/삭제 작업) 생성되는 트랜잭션 로그 레코드는 사용자가 트랜잭션을 커밋하거나 롤백할 때까지 유지되어야 합니다. 이는 다른 트랜잭션에 의해 생성되는 이후의 모든 트랜잭션 로그 레코드 역시 해제될 수 없음을 의미합니다. 트랜잭션 로그는 선택적으로 해제할 수 없기 때문입니다. 예를 들어 이 사용자가 트랜잭션을 완료하지 않고 퇴근할 경우 트랜잭션 로그 레코드는 계속 생성되는데 해제는 되지 않으므로 트랜잭션 로그는 계속 커지게 됩니다.
다음과 같이 sys.databases 시스템 카탈로그 뷰를 쿼리하고 log_reuse_wait_desc 열을 검사하면 트랜잭션 로그가 해제될 수 없는 이유를 찾을 수 있습니다.
SELECT name AS [Database],
  log_reuse_wait_desc AS [Reason]
FROM master.sys.databases;
원인이 활성 트랜잭션으로 밝혀질 경우 DBCC OPENTRAN 문을 사용하여 해당 트랜잭션에 대한 더 자세한 정보를 얻을 수 있습니다.
DBCC OPENTRAN ('dbname')

Q 손상된 상태에서 복구할 때는 백업에서 복원하는 방법을 사용하고 REPAIR_ALLOW_DATA_LOSS는 최후의 수단으로 사용해야 한다고 들었습니다. "repair for SQL Server 2005"를 사용하면 안 되는 이유와, 이것이 그렇게 "위험하다면" 제품에 포함된 이유는 무엇인지 설명해 주십시오.
A 먼저 말씀드리자면 SQL Server 2005용 repair 옵션을 작성한 사람은 바로 접니다. REPAIR_ALLOW_DATA_LOSS(이하 간단히 '복구'로 지칭함)의 문제는 동작 방식이 명확하지 않다는 데 있습니다. 이 복구 옵션의 이름을 이렇게 정한 이유는 실행할 경우 데이터베이스에서 데이터가 손실될 수 있음을 알리기 위해서입니다. 일반적으로 이 기능은 데이터베이스에서 손상된 구조를 삭제한 후 삭제된 구조를 참조했거나 이 구조에 의해 참조된 다른 모든 요소를 수정하는 방식으로 손상된 데이터베이스 구조를 복구합니다. 복구는 데이터베이스를 구조적 측면에서 일관되게 만들기 위한 최후의 수단으로 고안되었지 사용자 데이터를 살리기 위한 기능은 아닙니다. 복구는 굳이 사용자 데이터를 삭제하지는 않지만 굳이 사용자 데이터를 살리지도 않습니다.
무책임한 복구 방식으로 보일지 모르겠지만 이 옵션이 필요한 상황에서는 가장 빠르고 가장 안정적인 손상 복구 방법을 제공합니다. 재해 복구 상황에서는 속도가 가장 중요하며 정확성이 절대적으로 요구됩니다. 모든 경우에 대해 빠르고 정확하게 동작함을 입증할 수 있는 더 복잡한 복구 알고리즘을 엔지니어링하기란 거의 불가능합니다. 예를 들어 복구 코드에는 두 개의 인덱스에 동일한 페이지 또는 익스텐트가 할당된 경우를 해결하기 위한 몇 가지 복잡한 알고리즘이 있지만 알고리즘은 대부분 복구 + 수정입니다.
어쨌든 복구에는 알아야 할 몇 가지 문제가 있습니다.
  • 복구는 손상된 구조를 삭제할 때 외래 키 제약 조건을 고려하지 않으므로 다른 테이블과 외래 키 관계를 가진 테이블에서 레코드를 삭제할 수 있습니다. 복구를 실행한 후에 DBCC CHECKCONSTRAINTS를 실행하지 않고는 이러한 삭제가 발생했는지 여부를 확인할 방법이 없습니다.
  • 복구는 응용 프로그램 수준에서 정의된 기본 비즈니스 논리 또는 데이터 관계를 고려하지 않으며, 고려할 수도 없습니다. 이러한 비즈니스 논리 또는 데이터 관계는 일부 데이터가 삭제될 경우 깨질 수 있습니다. 마찬가지로 응용 프로그램에 기본 제공되는 일관성 확인을 실행하지 않고는 깨진 항목이 있는지 여부를 확인할 방법이 없습니다.
  • 일부 복구 작업은 복제할 수 없습니다. 피어 투 피어 토폴로지의 게시자 또는 노드에서 복구를 실행하면 토폴로지 내에 불일치가 발생할 수 있습니다. 이러한 불일치는 수동으로 수정해야 합니다.
이러한 이유로 손상으로부터 복구할 때는 복구 옵션을 실행하는 것보다 백업을 사용하는 편이 항상 더 좋은 방법입니다. 그럼에도 제품에 복구 기능이 제공되는 이유는 데이터베이스가 손상되었지만 백업은 없고 데이터베이스를 신속하게 온라인 상태로 되돌려야 하는 경우가 발생할 가능성이 상존하기 때문입니다.

Q: 얼마 전 DBA로 새 직장에 들어가면서 여러 응용 프로그램과 이들의 백 엔드 데이터베이스를 담당하게 되었습니다. 그런데 응용 프로그램 중 하나의 업데이트 성능이 상당히 떨어집니다. 조사 결과 응용 프로그램에서 사용하는 테이블 각각에 엄청나게 많은 수의 인덱스가 있다는 사실을 알게 되었습니다. 알아보니 이전 DBA가 습관적으로 각 테이블 열의 인덱스에 몇 가지 조합을 더해 추가했던 것 같습니다. 이 인덱스가 전부 필요하다고는 생각하지 않습니다. 삭제해도 안전한 인덱스를 구분할 수 있는 방법이 있습니까? 현재 SQL Server 2005를 실행하고 있습니다.
A: 짐작하신 대로 많은 수의 인덱스는 열악한 성능의 주 원인일 가능성이 큽니다. 테이블에서 행이 삽입, 업데이트 또는 삭제될 때마다 모든 비클러스터형 인덱스에서 해당 작업이 수행되어야 합니다. 이는 I/O, CPU 사용률 및 트랜젝션 로그 생성 측면에서 많은 오버헤드를 일으킵니다.
SQL Server 2000에서는 어떤 인덱스가 사용 중인지 확인하는 유일한 방법은 프로파일링을 사용하여 쿼리 계획을 검사하는 것이었습니다. SQL Server 2005에는 인덱스 사용을 추적하는 새로운 DMV(동적 관리 뷰)인 sys.dm_db_index_usage_stats가 있습니다.
이 DMV는 자신이 속한 데이터베이스가 시작된 이후 인덱스가 사용될 때마다 그 시점과 사용된 방법을 추적합니다. 모든 데이터베이스에 대한 통계는 SQL Server가 종료될 때 손실되며 단일 데이터베이스에 대한 통계는 해당 데이터베이스가 닫히거나 분리될 때 손실됩니다. 요점은 인덱스가 출력에 나타나지 않으면 데이터베이스가 시작된 이후 이 인덱스는 사용되지 않았다는 것입니다.
시간 경과에 따른 인덱스 사용을 추적하는 간단한 방법은 정기적으로 DMV 출력 스냅숏을 만든 다음 이 스냅숏들을 서로 비교하는 것입니다. 많은 사람들이 놓치는 부분은 전체 비즈니스 주기에 걸쳐 인덱스 사용을 추적해야 한다는 점입니다. 하루에 해당하는 스냅숏만 만든 경우 사용되지 않은 인덱스가 여러 개 발견될 수 있습니다. 그러나 예를 들어 이러한 인덱스가 월말 보고서 실행 속도를 높이기 위해 사용된다면 이 인덱스는 제거하면 안 됩니다. 인덱스가 전체 비즈니스 주기 동안 사용되지 않았다면 이를 삭제하여 공간과 성능을 확보할 수 있습니다.
필자의 블로그 게시물(sqlskills.com/blogs/paul/2007/10/05/IndexesFromEveryAngleHowCanYouTellIfAnIndexIsBeingUsed.aspx)에서 정기적으로 DMV 스냅숏을 만드는 데 사용할 수 있는 간단한 코드를 볼 수 있습니다.

Paul S. Randal은 SQLskills.com의 관리 이사이자 SQL Server MVP이며 SQL Server 2005용 DBCC CHECKDB/repair를 작성했고 SQL Server 2008 개발 과정에서 핵심 저장소 엔진 부분을 담당했습니다. 재해 복구, 고가용성 및 데이터베이스 유지 관리 분야의 전문가인 Paul은 각종 컨퍼런스의 단골 발표자이기도 합니다. 블로그 주소는 SQLskills.com/blogs/paul입니다.


Utility Spotlight Offline Virtual Machine Servicing Tool
Peter Skjøtt Larsen, Suveen Kumar Reddy Vuppala

목차
보안 악몽
내부 동작
서비스 인프라
도구 사용
마침
컴퓨터 작업 부하 가상화란 VM(가상 컴퓨터)을 사용하여 기반 하드웨어의 작업 부하를 덜어 주는 것을 의미합니다. 오늘날의 IT 부서는 다음과 같은 다양한 상황에서 VM을 유용하게 활용합니다.
작업 부하 전환 VM을 사용하면 리소스 사용량 요구의 변화에 따라 하드웨어를 변경하지 않고도 여러 장치의 작업 부하 대역폭을 손쉽게 늘리거나 줄일 수 있습니다.
응용 프로그램 개발 및 테스트 전용 하드웨어 없이 응용 프로그램이 지원해야 하는 각 구성을 나타내는 여러 VM을 만들 수 있습니다.
소프트웨어 업그레이드 VM을 사용하면 동일한 하드웨어에서 기존 버전을 오프라인으로 내리고 새 버전의 소프트웨어 패키지를 온라인으로 가져올 수 있습니다.
소프트웨어 배포 미리 테스트된 패키지에 일관적으로 소프트웨어를 조합해 넣은, 기간 업무(LOB) 응용 프로그램을 위한 배포 단위로 VM을 사용할 수 있습니다.

보안 악몽
VM 사용에 따른 장점 중 하나는 VM 이미지를 통해 VM을 오프라인 상태로 저장할 수 있다는 것입니다. 이후 필요할 때 이러한 VM을 "가동하여" 이에 상응하는 하드웨어를 배포할 때보다 훨씬 더 빠르게 배포할 수 있습니다.
그러나 오프라인에서 대기하는 컴퓨팅 환경이 증가하면 유지 관리 문제가 발생합니다. 소프트웨어 업데이트 메커니즘은 업데이트 확인 또는 자동 업데이트 수신을 위해 온라인 상태가 되어야 하는 시스템에 의존하는 경우가 많습니다.
온라인 상태가 아닌 VM은 컴퓨터에 저장된 파일에 불과하므로 어떠한 업데이트 메커니즘과도 상호 작용이 불가능합니다. 따라서 몇 개월 동안 오프라인 상태로 머물렀다가 온라인 상태가 된 VM은 네트워크에 위협이 되거나 네트워크로부터 위협을 받을 수 있습니다.
단순히 OS 업데이트 누락에 의한 문제가 아닙니다. 오랫동안 업데이트되지 않은 응용 프로그램 또는 바이러스 프로필은 VM을 취약하게 하거나 회사 기준에 부합하지 않도록 만들 수 있습니다.
오프라인 VM을 최신 상태로 유지하는 데 따르는 어려움을 해결하는 데 도움을 주기 위해 Microsoft Solution Accelerator 팀에서는 Offline Virtual Machine Servicing Tool을 만들었습니다. 이 도구는 SCCM(System Center Configuration Manager) 2007, WSUS(Windows Server Update Services) 3.0 및 System Center VMM(Virtual Machine Manager) 2007과 함께 동작하여 저장된 VM의 업데이트 작업을 조율합니다. 그림 1은 이 도구의 개념과 다양한 외부 구성 요소로의 연결 방식에 대한 개념을 보여 줍니다.
그림 1 Offline Virtual Machine Servicing Tool의 작동 방식(더 크게 보려면 이미지를 클릭하십시오.)
이 도구는 VM 업데이트를 위해 VMM을 사용하여 유지 관리 호스트에 임시로 VM을 배포합니다. 일반적으로 유지 관리 호스트는 한 번에 여러 VM을 실행하는 데 충분한 CPU와 메모리를 갖추고 있으므로 이 도구는 VM을 일괄 처리로 관리할 수 있습니다.
유지 관리 호스트에서 VM이 활성 상태가 되는 즉시 SCCM 또는 WSUS에서 이 VM에 필요한 업데이트를 제공할 수 있습니다. 업데이트가 적용된 후 도구는 VMM을 사용하여 VM을 오프라인 상태로 되돌립니다. 이 도구는 VMM으로 관리되는 VM만 지원한다는 점에 유의하십시오.

내부 동작
Offline Virtual Machine Servicing Tool은 Windows WF(Workflow Foundation)를 사용하여 VM 업데이트 프로세스를 조율합니다. 이 프로세스에는 적절한 업데이트 관리 시스템 선택부터 시작해 해당 VM에 알맞은 가용한 다음 유지 관리 호스트 선정, 업데이트 수행 확인, 마지막으로 예외 처리에 이르기까지 몇 가지 사용자 의사 결정이 필요한 부분이 있습니다.
Windows WF 기반 솔루션을 사용한 덕분에 개발 팀은 이 프로세스를 유연하게 변경하고 다듬을 수 있습니다. 또한 Windows WF 기반 솔루션은 특정 요구 사항을 충족하도록 맞춤 제작할 수 있는 강력한 솔루션을 사용자에게 제공합니다. 기본 제공되는 사전 및 사후 워크플로 단계가 프로세스의 중요 지점에서 사용자 지정을 위한 여지를 제공합니다.
이 도구는 Windows PowerShell을 사용하여 워크플로 수준 아래의 개별 작업을 구현하며, 이는 VMM에서 제공하는 Windows PowerShell API와 매끄럽게 연계됩니다. 또한 Microsoft .NET Framework 기반 UI는 System Center 제품과 모양 및 느낌이 비슷하므로 새 사용자에게도 친숙하게 느껴집니다.

서비스 인프라
서비스 인프라의 기본 원칙 중 하나는 업데이트 프로세스 중에 VM에 위해가 가해지지 않도록 네트워크 보안을 구성하는 것입니다. 이 도구의 버전 1.0에서는 VPN(가상 사설망)을 사용하고 VMM 및 적절한 업데이트 시스템(WSUS 또는 SCCM)을 여기에 연결하여 이러한 보안을 구성했습니다. VMM 라이브러리에 가장 적합한 인프라는 파이버 채널로 연결된 SAN(저장 영역 네트워크)입니다. 이러한 SAN은 VM 이미지를 유지 관리 호스트에 빠르게 전송하기 위한 수단을 제공합니다.
모든 VM은 Active Directory 및 DNS를 사용하는 동일한 도메인의 멤버여야 합니다. VMM, WSUS, SCCM 및 VMM 라이브러리 전용으로 각각 별도의 서버를 둘 수 있지만 소규모 환경에서는 가상 서버 조합도 사용할 수 있습니다. 물론 유지 관리 호스트는 실제 서버여야 합니다.

도구 사용
서비스 인프라를 구축한 다음에는 도구 사용이 가능하도록 특정 설정이 제대로 되어 있는지 확인해야 합니다. VMM이 모든 해당 VM을 관리하는지, 각 VM에 적절한 업데이트 클라이언트가 설치되었는지, 필요한 업데이트 패키지가 WSUS 또는 SCCM에 구성되었는지 확인해야 합니다. 필요하다면 VMM에 유지 관리 호스트 그룹이 구성되었는지도 확인합니다.
준비를 마쳤으면 Offline Virtual Machine Servicing Tool을 시작합니다. 시작 자체에도 몇 가지 구성 단계가 있습니다. 먼저 VMM 서버와 적절한 WSUS 또는 SCCM 서버를 지정한 후 사용할 유지 관리 호스트 그룹(유지 관리 호스트가 그룹화되어 있는 경우)과 이 그룹에서 사용할 유지 관리 호스트를 지정해야 합니다(그림 2 참조). 관리할 VM 그룹을 구성할 수도 있지만 이는 선택 사항입니다.
그림 2 Offline Virtual Machine Servicing Tool 구성(더 크게 보려면 이미지를 클릭하십시오.)
도구를 구성하고 나면 서비스 작업을 만듭니다. 서비스 작업에는 WSUS와 SCCM 중 업데이트에 사용할 항목, VMM 서버 및 WSUS 또는 SCCM 서버의 위치, 관리할 VM의 ID, 프로세스에 사용할 네트워크의 유형 및 ID, 사용할 유지 관리 호스트의 ID, VM, VMM 서버, WSUS 또는 SCCM 서버에 액세스하는 데 필요한 계정 자격 증명, 그리고 마지막으로 서비스 작업 실행을 위한 일정(즉시 실행 또는 특정 날짜 및 시간에 실행) 등 도구가 특정 VM을 관리하기 위해 사용하는 모든 정보가 포함됩니다.
서비스 작업에 날짜 및 시간을 지정하면 Windows 작업 스케줄러에서 시작 시점을 확인합니다. 서비스 작업이 실행되면 Offline Virtual Machine Servicing Tool은 각 VM에 대해 다음 절차를 따릅니다.
  • VMM 라이브러리에서 다음 VM을 선택합니다.
  • 가장 적절한 유지 관리 호스트를 VMM에 쿼리합니다.
  • 유지 관리 호스트에 VM을 배포합니다.
  • VM이 올바른 네트워크에 연결되는지 확인합니다.
  • VM을 시작합니다.
  • VM에 적절한 업데이트 클라이언트가 설치되어 있는지 확인합니다.
  • 업데이트 프로세스를 시작합니다.
  • 업데이트 프로세스가 완료될 때까지 기다립니다.
  • VM을 종료합니다.
  • VM을 VMM 라이브러리에 다시 저장합니다.
VM 라이브러리를 업데이트하는 데 소요되는 시간은 유지 관리 호스트의 수 및 용량, VMM 라이브러리 저장소의 액세스 속도, 그리고 업데이트의 특성에 따라 크게 달라집니다.
마침
현재 버전(1.0)의 Offline Virtual Machine Servicing Tool은 네트워크에서 VM을 보호하는 데 있어 상당히 효과적일 것으로 보이는 NAP(네트워크 액세스 보호)를 지원하지 않습니다. 또한 Windows Server 2008의 Hyper-V 기술이나 Windows Server 2008을 클라이언트 OS로 사용하는 기능도 지원하지 않습니다.
곧 새로운 버전의 SCCM, WSUS 및 VMM이 나올 예정이고 Offline Virtual Machine Servicing Tool 버전 2.0은 이를 지원하게 될 것입니다. 또한 Hyper-V, 그리고 클라이언트에서 Windows Server 2008을 사용하는 기능도 지원하게 됩니다. 더불어 네트워크 격리를 위한 NAP도 지원할 예정입니다. Offline Virtual Machine Servicing Tool은 technet.microsoft.com/cc501231에서 다운로드할 수 있습니다.

Peter SkjØtt Larsen은 Microsoft의 수석 제품 관리자로, Microsoft에 합류하기 전에는 통신 운영 소프트웨어 시스템 아키텍처 및 개발과 무선 서비스 표준화 및 개발에 참여했습니다.
Suveen Kumar Reddy Vuppala는 Microsoft의 수석 소프트웨어 개발 엔지니어로, 이전에는 7년간 Microsoft를 위한 실시간 모니터링 도구 및 배포 솔루션 설계와 개발에 참여했습니다.


Windows PowerShell 프로필의 유용성
Don Jones

목차
셸, 호스트 및 프로필
프로필 사용
사용자 지정 콘솔 만들기
프로필 기술 더 보기
프로필 주의 사항
이 칼럼을 정기적으로 읽는 독자라면 Windows PowerShell이 프로필 시스템을 지원한다는 사실은 알고 있을 것입니다. 프로필은 기본적으로 셸을 실행할 때 자동으로 실행되는 셸 스크립트이며 파일 확장명은 .ps1입니다. 예를 들면 프로필을 통해 사용자 지정 별칭을 편리하게 정의할 수 있습니다. 셸을 실행할 때마다 프로필이 자동으로 별칭을 정의하도록 하면 셸을 사용할 때 언제든지 별칭을 사용할 수 있습니다.
셸은 다음과 같은 네 가지 프로필을 정의합니다.
  • 컴퓨터의 모든 사용자 및 모든 셸에 적용되는 프로필
  • 모든 사용자에게 적용되지만 Microsoft PowerShell 셸에만 적용되는 프로필
  • 현재 사용자 및 모든 셸에 적용되는 프로필
  • 현재 사용자에게 적용되면서 Microsoft PowerShell 셸에만 적용되는 프로필
여기서 "모든 셸"이란 개념이 혼동스러울 수 있습니다. 이 용어의 기원은 최종 제품이 완성되기 전의 초창기 Windows PowerShell 개발 개념으로 거슬러 올라갑니다. 지금은 "모든 호스트"라는 용어가 더 적절하겠습니다.

비디오
프로필을 만들어 Windows PowerShell 셸을 사용자 지정하는 방법에 대한 Don Jones의 설명을 볼 수 있습니다.

셸, 호스트 및 프로필
Windows PowerShell 자체는 Microsoft .NET Framework 어셈블리의 집합입니다. 셸의 이 부분에는 일반적으로 Windows PowerShell로 간주되는 기능이 포함되어 있으므로 필자는 이 부분을 Windows PowerShell 엔진이라고 지칭합니다. 다만 사용자가 이 엔진과 상호 작용할 수 있는 방법은 기본적으로 제공되지 않습니다. 실제로 셸을 사용하려면 호스팅 응용 프로그램 또는 호스트로 엔진을 로드해야 합니다.
여러분이 종종 실행하는 powershell.exe 응용 프로그램도 이러한 호스트 중 하나입니다. Windows PowerShell 2.0 CTP(Community Technology Preview)에 포함된 gpowershell.exe 응용 프로그램 역시 이러한 호스트입니다. 호스트와 셸의 관계는 여기에 나온 것만큼 간단하지는 않지만 겉으로 나타나는 동작은 이러한 간략한 설명을 통해 이해할 수 있습니다.
텍스트 기반 명령줄 인터페이스를 통해 셸과 상호 작용하는 경우 powershell.exe 호스트를 사용한다는 점을 알아두어야 합니다. Exchange 관리 셸과 같은 다른 응용 프로그램에 의해 설치된 바로 가기를 사용하여 셸을 시작하는 경우에도 마찬가지입니다. Exchange 관리 셸은 다른 셸 또는 호스팅 응용 프로그램이 아니며 미리 로드할 스냅인 및 스크립트 집합을 지정하는 바로 가기를 사용하여 시작하는 일반적인 powershell.exe 호스트일 뿐입니다. 이러한 스냅인은 셸 내에서 Exchange 관리 기능을 활성화하는 요소입니다. 하지만 여전히 동일한 셸을 사용하는 것입니다.
Windows Vista에서 powershell.exe 호스트에 대한 프로필 위치는 다음과 같습니다.
  • %windir%\system32\WindowsPowerShell\v1.0\profile.ps1 컴퓨터의 모든 사용자 및 모든 셸에 해당됩니다.
  • %windir%\system32\WindowsPowerShell\v1.0\Microsoft.PowerShell_profile.ps1 컴퓨터의 모든 사용자에게 해당되지만 Microsoft.PowerShell 셸에만 해당됩니다.
  • %UserProfile%\Documents\WindowsPowerShell\profile.ps1 현재 사용자와 모든 셸에 해당됩니다.
  • %UserProfile%\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1 현재 사용자에게만, 그리고 Microsoft.PowerShell 셸에만 해당됩니다.
이러한 프로필은 기본적으로 생성되지 않으므로 필요한 경우 직접 만들어야 합니다.
각 호스팅 응용 프로그램은 올바른 프로필을 로드 및 실행하는 역할을 담당합니다. 특정 호스팅 응용 프로그램이 프로필을 로드하지 않기로 "결정"한다면 실제로 로드할 필요가 없는 것입니다. 프로필은 Windows PowerShell 엔진에 의해 자동으로 실행되지 않습니다.
이러한 부분을 모두 추적하기 위한 가장 쉬운 방법은 셸을 열고 $profile을 입력한 다음 Enter 키를 누르는 것입니다. 이렇게 하면 셸이 "주" 프로필로 사용하려고 시도하는 프로필(사용자별 셸 특정 프로필)의 전체 경로를 얻을 수 있습니다. 그런 다음 이 스크립트를 생성 또는 수정하면 셸이 시작될 때마다 이 스크립트가 실행됩니다.

프로필 사용
앞서 소개했듯이 프로필의 일반적 용도 중 하나는 사용자 지정 별칭 정의입니다. 또는 사용자 지정 PSDrive(기본적으로 Windows PowerShell 내에 존재하는 매핑된 드라이브)를 추가할 수도 있습니다. 그다지 일반적이지는 않지만 사용자 환경에서 사용 중인 소프트웨어 제품을 기반으로 필요한 관리 작업을 수행할 수 있는 일종의 고급 셸을 만들기 위한 용도로도 사용됩니다. 고급 셸 개념을 설명하려면 우선 약간의 배경 정보가 필요합니다.
Windows PowerShell을 만드는 Microsoft 내의 제품 그룹은 MMC(Microsoft Management Console)를 비롯한 여러 가지 다른 핵심 관리 기술을 담당합니다. MMC에는 Windows PowerShell의 작동 방식과 유사한 부분이 있습니다. mmc.exe를 실행하면 빈 콘솔이 시작되는데 이는 그다지 유용하지 않습니다. 기능 콘솔을 만들려면 MMC 스냅인을 추가해야 합니다.
콘솔을 원하는 방식으로 구성한 후에는 확장명이 .msc인 파일에 콘솔을 저장합니다. 이 저장된 콘솔 파일을 통해 언제든지 신속하게 사용자 지정 콘솔을 다시 로드할 수 있습니다.
많은 관리자들은 사용자 지정 MMC 콘솔을 만들기보다 그저 관리 대상 제품과 함께 설치되는 콘솔에 의지합니다. 예를 들어 Exchange Server는 Exchange Server 스냅인만 포함된 콘솔을 만듭니다. Active Directory 사용자 및 컴퓨터 역시 단일 스냅인이 포함된 미리 만들어진 콘솔입니다.
Windows PowerShell도 거의 같은 방식으로 작동합니다. Exchange Server 2007 관리 도구와 함께 설치되는 Exchange 관리 셸 아이콘은 실제로 콘솔 파일을 로드하기 위한 명령이 들어 있는 powershell.exe에 대한 바로 가기입니다. 셸 콘솔 파일은 .psc1 확장명을 가지며 미리 로드할 스냅인 목록을 포함합니다(.msc 파일이 MMC가 미리 로드할 스냅인 목록을 포함하는 것과 유사). 그러나 미리 생성된 셸 콘솔만 사용할 수 있는 것은 아닙니다. MMC에서와 마찬가지로 사용자 지정 콘솔을 만들어 이를 모든 관리 작업에 사용할 수 있습니다. 이를 가능하게 하는 데 있어 프로필이 중요한 역할을 합니다.

사용자 지정 콘솔 만들기
사용자 지정 콘솔을 만들려면 먼저 사용할 각 스냅인의 전체 이름을 찾아야 합니다. 필요한 관리 도구가 모두 컴퓨터에 설치되어 있는지 확인합니다. 그런 다음 Windows PowerShell에서 Get-PSSnapin -registered를 실행합니다. 이렇게 하면 언로드된 상태의 사용 가능한 모든 등록된 스냅인이 나열됩니다. 적절한 Windows PowerShell 프로필을 생성하거나 편집합니다. Add-PSSnapin 명령을 추가하여 항상 사용할 수 있도록 하려는 각 스냅인을 로드합니다. 여기에는 Exchange Server, System Center 제품용 스냅인 및 타사 스냅인이 포함될 수 있습니다(예: PowerShell Community Extensions). 프로필을 저장하고(Windows PowerShell 실행 정책에서 요구하는 경우 프로필에 디지털 서명을 해야 함) 셸을 닫습니다. 셸을 다시 열면 프로필에 나열된 모든 스냅인이 자동으로 로드됩니다.
또 다른 방법은 Add-PSSnapin과 스냅인의 이름을 사용하여 모든 스냅인을 셸에 로드한 다음 Export-Console을 실행하여 현재 사용 중인 모든 스냅인이 포함된 .psc1 콘솔 파일을 만드는 것입니다. 그러면 이 .psc1 콘솔 파일을 사용하여 PSConsoleFile 매개 변수 및 사용자 지정 .psc1 파일을 지정하는 새로운 Windows PowerShell 바로 가기를 만들 수 있습니다. 이 바로 가기는 사용자의 콘솔을 사용하여 지정된 모든 스냅인을 자동으로 로드하게 됩니다.

프로필 기술 더 보기
필자는 셸을 시작할 때마다 여러 기타 유용한 작업들이 수행되도록 하는 데 Windows PowerShell 프로필을 사용합니다. 필자의 시스템에서 셸이 시작될 때 수행되는 작업은 다음과 같습니다.
  1. 도메인 관리자 계정용 Get-Credential을 실행하고 그 결과를 $cred라는 변수에 저장합니다. 이렇게 하면 $cred를 셸 전반에 걸쳐 사용할 수 있게 됩니다. Get-WmiObject cmdlet과 같은 다양한 cmdlet의 –credential 매개 변수에 이를 전달할 수 있습니다. $cred에는 암호가 저장되므로 암호를 입력하지 않고도 이러한 cmdlet을 사용할 수 있습니다.
  2. Cd C:\를 실행하여 필자 컴퓨터의 C: 드라이브 루트에서 셸이 시작되도록 합니다.
  3. New-Alias of Out-File을 실행하여 "of"라는 별칭을 만듭니다. 그러면 "Out-File" 대신 "of"를 사용할 수 있게 됩니다. 필자는 이 방법을 자주 사용하므로 짧은 별칭을 정의해 두면 무척 유용합니다.
레지스트리의 HKEY_LOCAL_MACHINE 부분을 나타내는 셸의 HKLM: 드라이브에서 테스트 키를 만들어 봅니다. 오류가 발생하면 셸이 상승된 권한 없이 시작되었음을 알 수 있습니다. 필자의 작업에는 일반적으로 상승된 권한이 필요한데, 이를 통해 본격적인 작업에 들어가기 전에 상승된 권한이 있는지 여부를 신속히 알아볼 수 있습니다.
컴퓨터 이름 또는 IP 주소를 받아 컴퓨터가 ping 테스트를 통과하는지에 따라 True 또는 False 값을 반환하는 Ping-Address라는 사용자 지정 함수를 정의합니다. 필자는 작업에서 이 함수를 자주 사용하므로 셸 전역에서 사용할 수 있도록 프로필에 정의해 둡니다.

이달의 cmdlet: Get-WmiObject
눈치 빠른 독자라면 이 cmdlet을 예전에 다룬 적이 있다는 사실을 알겠지만 이 cmdlet이 제공하는 훌륭한 기능을 한 번 더 소개하겠습니다. 필자는 다음과 같은 방법을 사용하여 텍스트 파일에 이름이 나열된 여러 컴퓨터에서 WMI(Windows Management Instrumentation) 정보를 검색하려고 시도하는 관리자를 자주 봅니다.
Get-Content c:\computers.txt | ForEach-Object
  { Get-WmiObject Win32_Service –comp $_ }
이 방법은 작동은 하지만 Get-WmiObject가 –computerName 매개 변수에 대한 컴퓨터 이름 배열을 받을 수 있기 때문에 실제로는 필요가 없습니다. 다음과 같이 하여 동일한 결과를 얻을 수 있습니다.
Get-WmiObject Win32_Service –comp (Get-Content
  c:\computers.txt)
Get-Content 명령을 괄호 안에 입력하면 셸에서 명령을 실행하여 그 결과(컴퓨터 이름 배열)를 –computerName 매개 변수에 저장합니다.
프로필 주의 사항
Microsoft.PowerShell 프로필 또는 모든 셸 프로필을 로드하는 응용 프로그램이 powershell.exe만 있는 것은 아닙니다. SAPIEN Technologies의 PrimalScript, Quest Software의 PowerGUI, ShellTools의 PowerShell Plus를 비롯하여 Windows PowerShell을 지원하는 많은 IDE(통합 개발 환경)가 이러한 프로필을 로드하여 powershell.exe 호스트와 유사한 환경을 제공합니다.
많은 스냅인을 로드하는 큰 프로필의 경우 호스팅 응용 프로그램에서 사용할 수 있도록 준비하는 과정에서 Windows PowerShell 엔진이 많은 명령을 실행해야 하므로 이러한 응용 프로그램의 시작 속도가 느려질 수 있습니다. 실행할 프로필 스크립트가 매우 큰 경우에는 powershell.exe를 시작하는 데에도 꽤 많은 시간이 소요될 수 있습니다.
동일한 이름으로 cmdlet을 정의하는 여러 스냅인이 충돌을 일으킬 수도 있습니다. 예를 들어 두 개의 스냅인이 Get-User라는 이름의 cmdlet을 정의하는 경우 Windows PowerShell은 사용자가 cmdlet의 정규화된 이름을 사용하여 원하는 항목을 지정할 때까지는 어느 cmdlet도 실행하지 않습니다. 스냅인 이름이 길 경우 이 정규화된 이름은 지저분해 보일 수 있습니다. 이 문제에 직면하는 경우 필자는 보통 이 두 스냅인을 동시에 로드한다는 생각을 버립니다. 대신 필자는 프로필에서 가장 많이 사용하는 스냅인 하나만 로드한 후 다른 스냅인을 로드하여 사용해야 할 경우에는 별도의 "새로운" 셸을 사용합니다.
Windows PowerShell 프로필은 셸의 편의성을 크게 높여 줄 수 있습니다. 그러나 맬웨어에 의해 악의적으로 편집되는 경우 큰 손상을 입힐 수도 있다는 점을 명심하십시오. 프로필을 보호하려면 프로필에 디지털 서명을 하고 AllSigned 실행 정책을 사용하도록 Windows PowerShell을 구성하거나, 모든 프로필의 NTFS 파일 권한을 수정하여 일반 사용자 계정으로는 이를 수정할 수 없도록 하면 됩니다.

Don Jones는 Windows PowerShell: TFM and VBScript, WMI, and ADSI Unleashed의 저자입니다. 문의 사항이 있으면 PowerShellCommunity.org 웹 사이트를 통해 연락하시기 바랍니다.


Hey, Scripting Guy! 뜬금없는 명언
Microsoft Scripting Guys

제가 태어나기 훨씬 전인 기원전 399년에 사망한 소크라테스는 "시험하지 않는 삶은 살 가치가 없다"는 말로 유명합니다. 이 격언을 모르는 사람은 거의 없습니다. 그런데 놀랍게도 최근 Scripting Guys는 소크라테스가 "시험하지 않는 삶은 살 가치가 없다"는 말을 한 적이 없다는 사실을 알아냈습니다. 사실 이 말은 수백 년 전 중세시대의 한 서기에 의해 잘못 번역되었습니다. 원래 소크라테스가 한 말은 "시험하지 않는 XML 파일은 가지고 있을 가치가 없다"입니다.
이제야 그럴듯한 철학적 격언이 되었군요! XML의 인기는 나날이 높아지는 추세입니다. Scripting Guys의 테스트용 컴퓨터 한 대에서 잠깐 검색해 보니 다양한 시스템 또는 응용 프로그램에 사용되는 XML 파일의 수가 500개 넘게 발견되었습니다.
익히 알려진 바와 같이, 요즘은 중요한 데이터의 상당수가 XML 형식으로 저장됩니다. 좋은 일이지요. 단, 데이터가 시험을 거친다는 가정하에 말입니다. 그런데 슬프게도 많은 경우 데이터는 시험을 거치지 않습니다. 그 이유 중 하나는 XML 파일을 어떻게 시험해야 하는지 방법조차 모르는 사람이 많다는 데 있습니다. 구체적으로 보면 XML 파일을 쿼리하고 검색하는 방법을 모릅니다.
참고로, 그리스 철학자에 대해 잘 모르는 사람을 위해 말하자면 소크라테스는 사물에 대한 대화를 강력히 지지했지만 행동에 대해서는 그만큼 열성적이지 않았습니다. 사실 그의 아내 크산티페는 소크라테스를 가리켜 "쓸모없는 게으르뱅이"라고 말했습니다. Scripting Guys가 소크라테스에게 동질감을 느끼는 이유를 아시겠지요?
물론 이 글을 읽는 여러분 중 몇몇은 "가만, Scripting Guys 이전 칼럼 "자동차 뒤쫓기… 그리고 XML"(technet.microsoft.com/magazine/cc162506)에서 이미 XML 파일 검색에 대해 설명하지 않았나? 그런데 왜 그 주제를 지금 다시 꺼내지? 똑같은 칼럼을 쓰고 또 쓰고 할 만큼 Scripting Guys가 게으른 것인가?"라는 생각을 하실 수도 있습니다.
믿거나 말거나지만 사실 우리는 그것보다 더 게으릅니다. 다만 우리가 이 주제를 다시 꺼낸 데는 게으름보다 더 중요한 이유가 있습니다. 이전 칼럼에서 우리는 그림 1의 코드와 같은 구조를 가진 XML 파일을 사용한 작업에 대해 설명했습니다. 여기에서 각 속성 값은 하나의 노드를 나타냅니다.
그림 1 노드만으로 이루어진 XML 파일
<?xml version='1.0'?>
  <INVENTORY>
    <COMPUTER>
      <os>Windows XP</os>
      <department>Human Resources
      </department>
      <name>atl-ws-001</name>
    </COMPUTER>
    <COMPUTER>
      <os>Windows XP</os>
      <department>Finance</department>
      <name>atl-ws-002</name>
    </COMPUTER>
    <COMPUTER>
      <os>Windows Vista</os>
      <department>Finance</department>
      <name>atl-ws-003</name>
    </COMPUTER>
  </INVENTORY>
이 방식에 문제는 없지만 사람들이 지적했듯이 XML 파일은 이것 외의 다른 구조도 가질 수 있습니다. 위의 예에서 파일의 각 컴퓨터에는 각자의 노드가 있고, 이러한 노드에는 각기 여러 자식 노드(os, department 및 name)가 있습니다. 그런데 각 노드에 자식 노드가 없고, 대신 추가 속성 값이 특성으로 구성되는 형태로 XML 파일을 작성하는 방법도 가능합니다. 그림 2의 파일처럼 말이지요.
그림 2 특성이 사용된 XML 파일
<?xml version='1.0'?>
  <HARDWARE>
      <COMPUTER os="Windows XP" department="Human Resources">atl-ws-001</COMPUTER>
      <COMPUTER os="Windows XP" department="Finance">atl-ws-002</COMPUTER>
      <COMPUTER os="Windows Server 2003" department="IT">atl-fs-003</COMPUTER>
      <COMPUTER os="Windows Vista" department="IT">atl-ws-004</COMPUTER>
      <COMPUTER os="Windows Vista" department="Human Resources">atl-ws-005</COMPUTER>
      <COMPUTER os="Windows Vista" department="Finance">atl-ws-006</COMPUTER>
      <COMPUTER os="Windows XP" department="Sales">atl-ws-007</COMPUTER>
      <COMPUTER os="Windows Server 2008" department="IT">atl-fs-008</COMPUTER>
      <COMPUTER os="Windows XP" department="Human Resources">atl-ws-009</COMPUTER>
      <COMPUTER os="Windows Vista" department="Sales">atl-ws-010</COMPUTER>
  </HARDWARE>
이것이 문제일까요? 사실 문제입니다. 까마득한 옛날에 Scripting Guys가 여러분에게 제시한, 아주 오래된 스크립트는 그림 2와 같은 구조의 XML 파일에서 동작하지 않습니다. 네, 절대 동작하지 않지요. 그리고 이러한 유형의 XML 파일을 읽어야 하는 사람들이 워낙 많으니 확실히 문제라고 해야겠습니다.
여러분은 그저 질문을 하고 Scripting Guys가 문제를 해결할 때까지 1년 반만 기다리시면 됩니다.
깊이 들어가기에 앞서 문제의 XML 파일을 더 자세히 살펴보겠습니다. 이 파일에는 HARDWARE라는 주 노드가 있고 각 개별 컴퓨터는 HARDWARE의 자식 노드로 존재합니다. 또한 각 노드에는 한 쌍의 특성이 있습니다. 바로 os(컴퓨터에 설치된 운영 체제의 이름을 저장하는 데 사용)와 department(컴퓨터를 소유한 부서의 이름을 저장하는 데 사용)입니다.
예를 들어 Windows XP를 실행하는 모든 컴퓨터 목록을 구하려는 경우를 가정해 보겠습니다. 스크립트를 사용해서 원하는 결과를 얻을 수 있을까요? 당연히 가능합니다.
Set xmlDoc = _
  CreateObject("Microsoft.XMLDOM")

xmlDoc.Async = "False"
xmlDoc.Load("HARDWARE.xml")

Set colNodes=xmlDoc.selectNodes _
  ("//HARDWARE/COMPUTER[@os='Windows XP']")

For Each objNode in colNodes
  Wscript.Echo objNode.Text
Next
자세히 살펴봅시다. 먼저 Microsoft.XMLDOM 개체의 인스턴스를 만듭니다. 이름에서 알 수 있듯이 이 개체는 XML 파일을 사용할 수 있게 해 줍니다. 이 개체를 만들고 나면 다음으로 Async 속성을 False로 설정하여 문서를 비동기적이 아니라 동기적으로 로드해야 함을 스크립트가 알 수 있도록 합니다. 스크립트가 왜 이 부분에 신경을 쓰냐구요? 솔직히 말해 신경 안 쓰겠죠. 어쨌거나 스크립트는 무생물인데요(Scripting Guys처럼).
그렇지만 여러분은 신경을 써야 합니다. 문서를 비동기적으로 로드할 경우 문서가 완전히 로드되지 않은 상태에서 스크립트가 계속 실행될 수 있기 때문입니다. 이는 좋지 않은 현상입니다. 아직 생성되지도 않은 문서에 작업을 수행하려는 경우 발생할 문제를 생각해 보십시오. XML 파일을 동기적으로 로드하면 파일이 완전히 로드된 후에 스크립트가 진행되도록 보장됩니다.
어떻게 하다 보니 이제 XML 파일을 로드할 시점이군요. 이를 위해 Load 메서드를 호출하고 C:\Scripts\HARDWARE.xml 파일을 엽니다. 그러면 다음과 같은 코드를 볼 수 있습니다.
Set colNodes=xmlDoc.selectNodes _
  ("//HARDWARE/COMPUTER[@os='Windows XP']")
지금 우리가 하는 일은 SelectNodes 메서드를 사용하여 XML 파일을 쿼리하고 가져오고자 하는 XML 노드를 스크립트에 알리는 것입니다. 이 코드의 구문은 확실히 다소 특이합니다.
먼저 XML 파일 내에 경로부터 지정해야 합니다. 문제의 XML 파일에는 HARDWARE라는 최상위 노드가 있고 그 다음 두 번째 수준에 일련의 COMPUTER 노드가 있습니다. 이 두 번째 수준의 각 노드는 XML 데이터 파일에서 하나의 레코드를 나타냅니다. 이러한 이유로 selectNodes 쿼리는 다음과 같이 시작됩니다.
//HARDWARE/COMPUTER
이 부분에서 다음과 같은 구조를 볼 수 있습니다.
[@os='Windows XP']
이 쿼리 부분은 표준 SQL 쿼리의 WHERE 절과 비슷합니다. SQL에서는 다음과 같이 이것과 비슷한 데이터베이스 쿼리를 사용하여 Windows XP 운영 체제를 실행하는 모든 컴퓨터 목록을 검색할 수 있습니다.
SELECT Name FROM Hardware
    WHERE OS = 'Windows XP'
SelectNodes 메서드를 사용하여 수행하는 작업도 비슷합니다. 즉, os 특성(@os)이 Windows XP인 모든 컴퓨터의 목록을 가져오도록 요청합니다. 이 부분이 WHERE 절임을 나타내기 위해 전체 절을 대괄호 안에 넣습니다.
참고 이러한 유형의 쿼리를 XPath 쿼리라고 합니다. XPath에 대한 자세한 내용은 msdn.microsoft.com/library/ms256115.aspx를 참조하십시오.
앞서 언급했듯이 약간 이상하지만 어쨌든 동작은 합니다. Finance 부서에 속하는 모든 컴퓨터 목록을 얻으려면 어떻게 해야 할까요? 간단합니다. 다음과 같이 selectNodes를 호출하면 됩니다.
Set colNodes=xmlDoc.selectNodes _
  ("//HARDWARE/COMPUTER" & _
   "[@department='Finance']")
이번에도 WHERE 절은 대괄호로 묶고 @ 기호를 붙여 특성 이름(department)을 앞에 쓴 다음 원하는 값을 지정합니다.
간단하지요?
selectNodes 메서드를 호출한 후에는 다음과 같이 반환된 값 모음을 돌면서 Text 속성을 출력하는 간단한 방법으로 컴퓨터 이름을 출력할 수 있습니다.
For Each objNode in colNodes
  Wscript.Echo objNode.Text
Next
그렇다면 이를 통해 어떤 종류의 정보를 얻게 될까요? 사실 다음과 같은 정보를 얻게 됩니다.
atl-ws-001
atl-ws-002
atl-ws-007
atl-ws-009
즉, 여전히 Windows XP를 실행하는 모든 컴퓨터의 이름이 반환됩니다.
덧붙여 말하자면 컴퓨터 이름만 반환할 수 있는 것은 아닙니다. 컴퓨터 이름은 각 노드의 "기본값"이기 때문에 Text 속성을 참조할 경우 바로 컴퓨터 이름을 얻게 됩니다.
또는 정확히 어떤 특성이 반환되기를 원하는지 지정할 수 있습니다. 예를 들어 다음과 같이 수정된 For Each 루프를 보십시오.
For Each objNode in colNodes
    Wscript.Echo objNode.Text
    Wscript.Echo objNode.Attributes. _
      getNamedItem("department").Text
    Wscript.Echo
Next
보시는 바와 같이 이 루프에서도 여전히 Text 속성의 값을 출력하지만 우리는 여기에 다음과 같은 코드도 덧붙였습니다.
Wscript.Echo objNode.Attributes. _
  getNamedItem("department").Text
여기에서는 getNamedItem 메서드를 사용하여 department 특성의 값을 가져옵니다. 그런 다음 이 특성에 대한 Text 속성을 출력합니다. 이와 같은 방법으로 화면에 출력할 특성 값과 출력하지 않을 특성 값을 지정할 수 있습니다. 레코드 사이에 빈 줄을 넣기 위해 Wscript.Echo 명령도 추가했습니다. 이 스크립트를 실행하면 다음과 같은 결과를 얻게 됩니다.
atl-ws-001
Human Resources

atl-ws-002
Finance

atl-ws-007
Sales

atl-ws-009
Human Resources
물론 필요한 경우 더 복잡한 쿼리를 작성할 수 있습니다. 예를 들어 Windows XP 또는 Windows Vista를 실행하는 모든 컴퓨터 목록이 필요하다고 가정해 보십시오. SQL에서는 OR 쿼리를 사용하면 됩니다. 물론 XML 파일을 쿼리하는 방법으로도 똑같은 일을 할 수 있습니다.
Set colNodes=xmlDoc.selectNodes _
    ("//HARDWARE/COMPUTER" & _
     "[@os='Windows XP' or " & _
     "@os='Windows Vista']")
한번 볼까요? 한 쌍의 대괄호 안에 @os='Windows XP' or @os='Windows Vista'라는 두 개의 조건을 제시했습니다. 그게 전부입니다. 그러면 그림 3과 같은 보고서를 얻게 됩니다.
그림 3 OR 쿼리의 결과
atl-ws-001
Human Resources

atl-ws-002
Finance

atl-ws-004
IT

atl-ws-005
Human Resources

atl-ws-006
Finance

atl-ws-007
Sales

atl-ws-009
Human Resources

atl-ws-010
Sales
XML 파일을 다시 확인해 보면 Windows XP 또는 Windows Vista를 실행하는 컴퓨터는 출력에 포함되고 Windows Server 2003 또는 Windows Server 2008을 실행하는 컴퓨터는 출력에 포함되지 않음을 알 수 있습니다. 당연히 출력에 포함되면 안 되지요.
질문이 있나요? Windows XP를 실행하고 Finance 부서에 속하는 컴퓨터만 반환하는, 보다 한정된 쿼리를 작성하고 싶나요? 이미 짐작하겠지만 간단합니다. 다음과 같이 AND 쿼리만 작성하면 됩니다.
Set colNodes=xmlDoc.selectNodes _
    ("//HARDWARE/COMPUTER" & _
     "[@os='Windows XP' and " & _
     "@department='Finance']")
그러면 다음과 같은 데이터 집합이 반환됩니다.
atl-ws-002
Finance
왜 항목이 하나밖에 없을까요? 맞습니다. Finance 부서에는 Windows XP를 실행하는 컴퓨터가 한 대뿐이기 때문입니다.
이러한 유형의 XML 파일을 다루는 데 있어 이 칼럼이 도움이 되면 좋겠습니다. 혹시 또 다른 유형의 XML 파일이 발견된다면 그건 알아서 잘 해결하세요.
이번 달 칼럼은 유명한 격언으로 시작했으니 끝낼 때도 비슷하게 하는 편이 좋겠습니다. 그런 의미에서 Scripting Guys가 마음속에 새겨두고 있는 카이저 빌헬름 2세의 말로 칼럼을 마치겠습니다. "이로써 나는 프로이센 왕위, 그리고 이와 함께 독일 제국의 왕위를 영원히 포기하노라."
Dr. Scripto의 Scripting Perplexer
매달 퍼즐 풀기 실력뿐만 아니라 스크립팅 능력까지 시험해 볼 수 있는 문제입니다.

2008년 10월: VBScript 빈 칸 채우기
이 퍼즐을 풀려면 VBScript 함수의 이름으로 각 행을 채우면 됩니다. 다 채웠으면 파란색 사각형 안의 문자를 짜맞춰 함수 이름을 하나 더 찾으십시오.

정답:
Dr. Scripto의 Scripting Perplexer
정답: 2008년 10월: VBScript 빈 칸 채우기

The Scripting Guys(Greg Stemp와 Jean Ross)는 Microsoft 직원들입니다.


The Desktop Files Windows 배포 서비스 사용자 지정
Wes Miller

목차
기존의 배포 기술 대체
배포 단계 살펴보기
네트워크 부팅 프로그램
WDS PXE 공급자
TFTP Daemon
부팅 구성 데이터 저장소
Windows PE
전송 서버
사용자 지정 멀티캐스트
요약
지난 3개월에 걸쳐 WDS(Windows 배포 서비스)의 기원, 개요에 대해 차례로 살펴본 후 WDSUtil, 멀티캐스팅과 같은 일부 고급 항목에 대해서도 자세히 설명했습니다. 연재물의 마지막인 이번 호에서는 조직의 필요에 맞게 WDS를 사용자 지정하고 구성할 수 있는 위치와 방법에 대해 알아보겠습니다. 대부분의 Microsoft 도구는 어느 정도 구성이 용이하게 만들어져 있습니다. 그러나 실제로 사용할 시점이 되면 도구가 요구 사항에 맞는지, 아니면 여러분의 시나리오에 사용하기 위해 약간의 수정이 필요한지(후자가 더 흔함)를 확인해야 합니다.

기존의 배포 기술 대체
최근 독자들로부터 많이 받는 질문은 "x(기존의 배포 기술)를 사용하고 있는데 WDS를 사용해도 될까요? x만큼 다양한 기능을 제공하나요?"입니다. ADS(자동 배포 서비스)가 더 이상 사용되지 않으면서 대량의 서버를 신속하게 배포하거나 다시 구축하려면 어떻게 해야 하는지, 그리고 WDS로 이 작업을 수행 가능한지가 사람들의 주 관심사가 되었습니다.
WDS는 ADS를 1:1로 대체하기 위한 기술이 아니고 사실 대체에 필요한 주요 구성 요소 몇 가지가 빠져 있지만 약간의 작업만 거치면 WDS로 ADS를 대체할 수 있습니다. 마찬가지로 WDS의 기본 상태가 요구 사항에 맞지 않는다면 많은 구성 요소를 필요에 따라 대체할 수 있습니다. 물론 이를 위한 작업의 복잡성과 필요한 기술 수준은 그때그때 상당히 다릅니다. 그러면 WDS를 통한 배포에 대해 살펴보고 사용자 지정해야 할 부분과 그 방법에 대해 알아보겠습니다.

배포 단계 살펴보기
그림 1에서는 WDS 배포 프로세스의 구성 요소를 보여 줍니다. 이러한 각 단계는 어느 정도까지 사용자 지정할 수 있습니다. 각 단계는 해당 단계의 대체 또는 사용자 지정 작업에 수반되는 복잡성(일반적으로 개발 기술)에 따라 색으로 구분되어 있습니다. 파란색이 어두울수록 사용자 지정하기가 더 어려운 단계입니다.
그림 1 WDS 사용자 지정 작업의 복잡성
물론 각 단계별 사용자 지정 작업의 난이도는 팀의 기술(개발 또는 스크립팅) 수준, 그리고 WDS, WIM(Windows 이미징 형식), Active Directory 또는 기타 통합하려는 다른 기술(예: SQL 또는 ADSI)에 대한 이해도에 따라 달라집니다. 이러한 각 단계를 살펴보고 이를 사용자 지정할 방법과 여기에 사용할 방법에 대해 생각해 보십시오.

네트워크 부팅 프로그램
WDS에서 기본 제공하는 NBP(네트워크 부팅 프로그램)를 대체하는 사용자 지정 NBP를 만들 일은 사실 거의 없겠지만 어쨌든 가능하긴 합니다. WDS에는 헤드리스 시스템(일반적으로 서버) 또는 F12 입력을 요구하거나 요구하지 않는 시스템 등에서 사용할 수 있는 NBP가 포함되어 있습니다. 이러한 NBP를 WDSUtil을 사용하여 Active Directory에 사전 준비해 넣거나 사전 준비되지 않은 모든 시스템에 대해 Startrom.com을 원하는 NBP로 대체할 수 있습니다(예: 모든 시스템이 헤드리스 시스템인 경우 또는 F12 입력을 요구하지 않으려는 경우).
아쉽게도 사용자 지정 NBP를 만드는 방법에 대한 문서는 그리 많지 않습니다(msdn.microsoft.com/library/bb870970.aspx 참조). NBP는 매우 작은 16비트 실행 파일이며 매우 제한적이고 특정 프로그래밍 기술을 요구합니다. 특정 요구 사항을 충족해야 하고 적절한 기술을 갖춘 개발팀이 있는 경우를 제외하면 일반적으로 WDS에 제공되는 기존 NBP를 사용하는 것이 좋습니다.

WDS PXE 공급자
RIS(원격 설치 서비스)와 관련하여 고객들로부터 많이 받은 의견은 Active Directory 외의 다른 데이터 저장소를 사용하여 클라이언트 시스템 정보를 저장하고 싶다는 것이었는데, 그중에서 SQL Server를 사용하고 싶다는 의견이 가장 많았습니다. WDS의 경우 디자인에 PXE(Pre-Boot eXecution Environment) 공급자용 플러그형 인프라가 포함되어 있습니다. 이는 개발 작업에서 Active Directory 외의 다른 지원 저장소에 PXE 정보를 저장할 수 있음을 의미합니다.
WDS에는 Active Directory를 사용하는 고유한 공급자가 기본 제공됩니다. 또한 이제 SCCM(System Center Configuration Manager)도 WDS에 연결되고 자체 공급자를 구현합니다. 고유한 공급자를 작성하는 방법에 대한 문서는 극히 드물고 샘플 코드도 많지 않으므로(Windows SDK에서 일부 문서와 몇 가지 샘플을 제공하긴 하지만) 작업이 쉽지는 않습니다. 다시 한 번 말하지만 부팅 프로세스의 이러한 측면에 대해 특정 요구 사항이 있는 경우를 제외하면 사용자 지정 PXE 공급자는 시도하지 않는 편이 좋습니다.

TFTP Daemon
WDS가 나오기 전에 일부 고객은 고유의 TFTPD(Trivial File Transfer Protocol Daemon)에 투자했습니다. PXE 서버 여러 대는 매끄럽게 동작하지 않으므로 많은 경우 이는 한 대에만 의존하게 됨을 의미합니다.
필자의 경험상 일반적으로 이를 위해서는 기존 TFTPD(일반적으로 Linux 기반 TFTPD)를 가져와 다른 OS를 부팅하도록 손을 써야 합니다. RIS가 사용했던 원래의 인프라에서는 이렇게 할 수 없습니다. 그러나 RAMDisk 부팅이 표준이 된다면 이렇게 할 수 있습니다. 또한 WDS 기반 부팅 이미지를 사용하는 방법도 여전히 가능합니다.
한 가지 염두에 두어야 할 점은 이로써 여러분은 Microsoft에서 기술적으로 지원하지 않는 영역, 또한 진단하기 어려운 문제를 유발할 가능성이 높은 영역으로 들어가게 된다는 점입니다. 또한 WDS의 향상된 TFTPD를 사용하면 성능 개선과는 동떨어진 결과를 얻을 수 있습니다. 이상적으로 보면 기존 서버를 수정하는 대신 기존 WDS TFTPD를 사용하고 PXE 시간 제한, 사전 준비 및/또는 네트워크 경계를 사용하여 어떤 클라이언트가 어떤 PXE 서버에서 부팅될지를 정의하는 것이 좋습니다.

부팅 구성 데이터 저장소
RIS의 경우 부팅 수준에서 부팅해야 할 대상을 지정할 수가 없었습니다. 항상 OS 선택기를 사용하여 옵션(설치 프로그램, Windows PE(Windows 사전 설치 환경) 등)을 선택해야 했습니다. WDS는 완벽한 네트워크 부팅 로더를 사용하므로 클라이언트에게 제공되는 BCD(부팅 구성 데이터) 저장소의 사용자 지정도 지원합니다. 각 아키텍처의 기본 BCD는 RemoteInstall\Boot\<arch>\Default.bcd 아래에 위치하며 여기서 <arch>는 부팅되는 시스템의 특정 아키텍처입니다.
각 클라이언트별로 이러한 BCD를 사용자 지정할 수 있으며 클라이언트는 부팅 시에 이를 사용하게 됩니다. 예를 들어 한 BCD 항목은 설치를 시작하도록 설정하고, 다른 항목은 WinRE(Windows 복구 환경)를 실행하도록 설정하고, 또 다른 항목은 메모리 테스트를 실행하도록 설정할 수 있습니다. 또는 완전히 자동화된 설치 항목을 기본값으로 두고 수동(또는 사용자 지정 설치 환경)을 사용자가 선택 가능한 옵션으로 설정할 수 있습니다. 자세한 내용은 "Bcdedit를 사용하여 BCD 저장소를 수정하는 방법"(go.microsoft.com/fwlink/?LinkId=115267)을 참조하십시오.

물론 WDS의 주요 작업 대부분은 Windows PE에서 수행되므로 필요에 맞게 Windows PE를 조정하는 작업이 사용자 지정 환경에서 가장 중요한 부분일 수 있습니다. WDS는 기본적으로 완전한 설치 환경이 포함된 극히 표준적인 설치 템플릿을 제공합니다. 배포 요구 사항에 따라 이러한 템플릿을 사용할 수 없는 경우도 있습니다. 이러한 경우 사용자 고유의 Windows PE 부팅 이미지를 만들 수 있습니다. 그러면 기본적인 것부터 시작해 보겠습니다.
BCD를 통해 사용할 이미지를 지정하는 것 외에도 Active Directory에서 컴퓨터에 대해 MAO(컴퓨터 계정 개체)를 사용자 지정하는 방식으로 이미지를 지정할 수도 있습니다. RIS에서는 특정 MAO 특성이 각 항목(사용할 Startrom 및 Unattend(SIF) 파일)을 저장했습니다. WDS에서는 이러한 항목이 netBootMirrorDataFile 항목에 이름-값 쌍으로 저장됩니다. 예를 들어 특정 컴퓨터에서 사용할 부팅 이미지와 Unattend 파일이 이 항목에 저장됩니다. 이러한 항목의 형태는 세미콜론으로 구분된 이름-값 쌍 목록입니다. 부팅 이미지와 Unattend 파일을 수정하는 항목은 각각 BootImage와 UnattendFilePath입니다.
물론 기존의 설치 환경을 완전히 삭제하고 사용자 고유의 환경을 구축해야 할 수도 있습니다. 더 높은 수준의 구성 용이성과 더 많은 자동화 기능이 필요하거나 SQL Server에 의해 자동화된 빌드가 필요한 경우가 있습니다. 초기에 일부 고객이 RIS 및 Windows PE를 사용하여 했던 것처럼 설치를 위한 사용자 고유의 프런트 엔드를 구축할 수도 있습니다. 어떤 설치 환경을 작성하든 관계없이 수행해야 할 주요 작업은 다음과 같습니다.
  • 컴퓨터별 또는 사용자별 정보 확인. 이 정보는 사용자 입력, SQL Server 또는 텍스트 파일 등에서 확인할 수 있습니다.
  • 클라이언트 시스템에 설치 이미지 복사 및 적용. 이 작업을 수행하려면 직접 설치 프로그램을 사용하거나 ImageX를 사용하여 네트워크 공유에서, 또는 멀티캐스트를 통해 이미지를 적용하면 됩니다(ImageX를 통해 이미지를 복사하고 적용하기만 하면 됨).
  • Unattend 파일(배포 중인 Windows 버전에 따라 Unattend.xml 또는 sysprep.inf)을 제공하여 설치를 완료합니다.
  • 수행할 모든 설치 후 마이그레이션 단계(Windows Server 2008의 경우 역할을 적용하기 위한 모든 단계)를 자동화합니다.
ADS는 한 대 이상의 컴퓨터에 반복 가능한 단계를 할당할 수 있는 작업 시퀀스 개념을 도입했습니다. ADS는 Windows XP에서 사용하도록 디자인되지 않았고 지원되지도 않으므로 OS를 배포하는 데 사용할 수 없습니다. 그러나 ADS 작업 시퀀스는 사실 구조화된 스크립트일 뿐이며 사용자 지정 설치 프로세스를 사용하면 이와 동일한 단계를 수행할 수 있습니다.
필자는 오래 전부터(SQL Server 6.5 릴리스 이후부터) Microsoft SQL Server의 팬이었으므로 이러한 구조를 작성할 때 습관적으로 SQL을 사용합니다. 물론 이렇게 하려면 Windows PE 빌드에 SQL 기능을 추가해야 합니다. 이를 기반으로 고유의 GUI(HTA(HTML 응용 프로그램) 또는 컴파일된 실행 파일)를 작성하거나 WSH(Windows 스크립트 호스트)를 사용하여 가장 간단한 명령줄 전용 설치 환경을 구축할 수 있습니다. HTA 또는 WSH 역시 사용하려면 Windows PE에 추가해야 합니다.
고유의 설치 환경을 설계하는 데 따르는 복잡성은 전적으로 사용자의 기술 수준과 구상에 따라 달라집니다. 필자는 SQL 및 WSH 또는 HTA만 사용하여 정의된 상당히 훌륭한 시스템을 여럿 보았습니다. 이러한 기술은 비교적 익히기 쉽습니다. 그러나 필자가 이전 칼럼에서 언급했던 제한 사항을 반드시 염두에 두어야 합니다.
  • Windows PE에서는 WOW(Windows on Windows) 하위 시스템을 제공하지 않으므로 지원하려는 각 아키텍처에 대해 한 번씩 컴파일을 수행해야 합니다.
  • x64 또는 IA64 Windows PE를 통해 배포해야 하는 경우에는 Visual Basic 6.0을 사용할 수 없습니다.
  • Visual Studio 2005 또는 2008을 사용하여 응용 프로그램을 구축할 수 있지만 Windows PE에서 지원되는 Microsoft .NET Framework 버전이 없으므로 관리되지 않는 Visual C++ 응용 프로그램을 작성해야 합니다.
  • .NET Framework를 사용할 수 없으므로 자동화에 Windows PowerShell을 사용할 수도 없습니다.
물론 사용자 고유의 설치 환경을 작성하려는 경우에는 WDS를 통해 타사 이미징 유틸리티를 사용할 수 있습니다. 필자는 WIM 형식과 ImageX가 대부분의 배포 시나리오를 충족할 수 있다고 생각하지만 사용 중인 기존 이미징 도구가 충족하는 특정 요구 사항이 있을 수 있습니다.
마찬가지로 사용자 지정 파티션 분할이 필요한 시나리오가 있을 수 있습니다. 예를 들어 BitLocker를 사용하여 Windows Vista를 배포하는 경우, 또는 Windows XP 시스템을 구축하고 두 번째 볼륨에 프로필 데이터를 저장하는 경우, 또는 Windows Server 시스템을 배포하고 동일한 디스크에 로깅을 위한 별도의 볼륨을 만들려는 경우가 있습니다. 이러한 시나리오에서는 DiskPart를 자동화해야 합니다. 이렇게 하려면 이전 버전에서와 마찬가지로 실행하려는 명령이 포함되어 있고 DiskPart를 종료하는 exit 명령으로 끝나는 스크립트(파일 형식 무관)를 DiskPart에 제공하면 됩니다.
고유한 설치 환경을 만드는 작업은 결코 간단하지 않습니다. 기본적으로 이를 위해서는 설치 실행 파일을 재작성(또는 적어도 그 기능을 미러링)해야 하고 여기에 상당히 많은 디자인 및 구축 작업이 필요할 수 있기 때문입니다. 그러나 이는 기본적으로 구축해 넣으려는 기능이 얼마나 많고, 무엇(HTA 또는 WSH 또는 컴파일된 프로그래밍 언어)을 사용하여 구축하느냐에 따라 달라집니다.

전송 서버
WDS의 기본 기능(예: Active Directory) 대부분을 거의 사용하지 않거나 사용자 고유의 솔루션 일체를 작성하려는 경우에는 전송 서버가 불필요한 요구 사항을 수반하지 않으면서 필요한 사항을 충족할 수 있습니다. 그림 2의 표(원본은 go.microsoft.com/fwlink/?LinkID=115298의 "전송 서버 사용")에서는 WDS 전송 서버 역할의 일부로 포함된 항목을 설명합니다.
그림 2 배포 서버와 전송 서버 비교
 | 배포 서버 | 전송 서버
서버 요구 사항 | 환경에 ADDS(Active Directory 도메인 서비스), DHCP(Dynamic Host Configuration Protocol) 및 DNS(Dynamic Name System)가 필요합니다. | 환경에 다른 서버가 필요하지 않습니다.
PXE | 기본 PXE 공급자를 통한 PXE 부팅을 지원합니다. | PXE 공급자가 설치되지 않으므로 사용자 지정 PXE 공급자를 만들어야 합니다.
이미지 서버 | Windows 배포 서비스 이미지 서버가 포함됩니다. | Windows 배포 서비스 이미지 서버가 포함되지 않습니다.
전송 방식 | 유니캐스팅과 멀티캐스팅을 모두 허용합니다. | 멀티캐스팅만 허용합니다.
관리 도구 | Windows 배포 서비스 MMC 스냅인 또는 WDSUTIL 명령줄 도구 중 하나를 사용하여 관리할 수 있습니다. | WDSUTIL 명령줄 도구를 통해서만 관리할 수 있습니다.
클라이언트 컴퓨터의 응용 프로그램 | Windows 배포 서비스 클라이언트(기본적으로 Setup.exe 및 지원 파일), Wdsmcast.exe(Windows AIK에 포함됨) 또는 사용자 지정 멀티캐스트 응용 프로그램을 사용합니다. | Wdsmcast.exe 또는 사용자 지정 응용 프로그램만 사용합니다.
전송 서버가 구현하기 복잡한 항목이라는 말은 역할 그 자체가 어렵다는 의미는 아닙니다. 물론 배포하기도 쉽습니다(그림 3 참조). 어려운 부분은 바로 전송 서버를 중심으로 한 사용자 지정 설치 구현입니다. 전송 서버 역할을 사용하면 역할로서 WDS에 기본 제공되는 사용의 용이함이 사실상 대부분 제거됩니다.
그림 3 사용자 지정 배포 시나리오에 유용한 전송 서버(더 크게 보려면 이미지를 클릭하십시오.)

사용자 지정 멀티캐스트
전송 서버 역할을 사용하는지 여부에 관계없이(그러나 사용하는 경우에 특히) 다중 시스템 배포를 수행할 때는 멀티캐스트를 사용할 만한 충분한 이유가 있습니다. ADS에서 제공했던 매우 강력한 멀티캐스트 기능을 WDS에서 멀티캐스트를 사용하여 그대로 모방할 수 있습니다. WDS도 자체적으로 멀티캐스트 기능을 제공하지만 고유한 사용자 지정 솔루션을 구축하고 있는 경우 필자가 지난 호에서 언급한 WDSMCast를 사용하여 멀티캐스트를 활용할 수 있습니다(그림 4 참조). 유의해야 할 점은 배포할 이미지 파일을 먼저 전송한 다음 적용해야 한다는 것입니다. 이는 보통 로컬 디스크에 이미지를 저장하고 적용하기에 충분한 공간이 있어야 함을 의미합니다.
그림 4 WDSMCast 실행(더 크게 보려면 이미지를 클릭하십시오.)

요약
WDS는 자체로도 상당히 강력한 기능을 제공하므로 많은 조직의 요구 사항을 충족하는 데 충분합니다. 그러나 WDS의 경계를 뛰어넘는 사용자 고유의 솔루션을 구축하고자 한다면 얼마든지 그렇게 할 수 있습니다. 여러분의 구상, 일정, 그리고 기술 수준 외의 다른 제한은 없습니다.

Wes Miller는 텍사스주 오스틴에 위치한 CoreTrace(CoreTrace.com)에서 기술 제품 수석 관리자를 맡고 있으며, 이전에는 Winternals Software에서 근무했고, Microsoft에서 프로그램 관리자로도 일했습니다. 문의 사항이 있으면 technet@getwired.com으로 연락하시기 바랍니다.


Security Watch 10가지 불변의 보안 법칙 돌아보기, 1부
Jesper M. Johansson

Scott Culp는 2000년에 "10 Immutable Laws of Security"라는 에세이를 발표했습니다. 이 글은 필자가 읽어 본 가장 훌륭한 보안 관련 에세이 중 하나입니다. Scott Culp가 이 글에서 제공한 정보는 지금까지 모든 정보 보안 관련 작업의 기초로 사용되고 있습니다. 아직 읽지 않았다면 지금 읽어 보고, 필요하다면 인쇄도 해 두시기 바랍니다. 이 글은 microsoft.com/technet/archive/community/columns/security/essays/10imlaws.mspx에서 볼 수 있습니다.
이 에세이에 대한 독자의 반응은 다양합니다. 어떤 이들은 Microsoft에서 심각한 문제로 알려진 여러 문제를 수정하지 않기 위해 게시한 글이라고 비판했고, 다른 이들은 보안에 대한 가장 근원적인 글로 생각했으며 너무 중요하다고 생각한 나머지 마음대로 도용하기도 했습니다. 그러나 필자에게 가장 큰 인상을 준 반응은 이 글에 고무된 사람들이 나름대로의 목록을 만들었다는 점입니다. edgeblog.net/2006/10-new-immutable-laws-of-it-security에서 그중 한 예를 볼 수 있습니다.
이 에세이가 발표된 후 8년 동안 보안 분야에서는 많은 일이 일어났습니다. 악명을 떨친 웜이 속출했고 조직 범죄, 정치적 단체 등과 함께 정보 전쟁 국면에 접어들었습니다. 피싱, 파밍, 봇넷, 스파이웨어, 사이트 간 요청 위조 공격과 같은 다양한 신조어가 일반적인 용어로 사용되기 시작했습니다. Windows에서 실행되는, 과거와는 비교할 수 없이 정교한 루트킷이 등장했습니다. 보안 위주의 새로운 OS 릴리스가 나온 반면 아직도 대부분의 보안이 무시되는 다른 운영 체제도 있습니다.
사회 공학은 심각한 위협으로 발전했습니다. 한 유력 소매업체에서 9,400만 명의 신용카드 번호가 유출되었다는 등의 데이터 침해 관련 소식도 이제 흔한 뉴스가 되었습니다. 이런 사건이 터져도 사람들은 이 소매점에서 계속 물건을 구입합니다. 미국과 영국 정부의 불찰로 엄청나게 많은 개인 정보가 유출되었지만 그래도 사람들은 이 정부에 개인 정보를 계속 제출하고 있습니다. 그리고 우리의 일상, 그리고 공항에 엄청난 보안 전시 행정이 자리를 잡았습니다.
필자는 이제 이 법칙을 재조명할 시기가 왔다고 생각합니다. 앞서 살펴본 모든 변화가 이번 세기의 초반에 발생했음을 고려할 때, 과연 지금도 이러한 보안 법칙이 불변의 법칙이라고 주장할 수 있을까요? 이 법칙이 불변의 법칙이라면(지난 8년 동안 유효했다면) 앞으로도 10년 동안 유효하다고 말할 수 있을 것입니다.
3부로 구성된 이 연재물에서 필자는 10가지 법칙 각각을 비판적인 시각으로 살펴볼 것입니다. 이번 달에는 제1 ~ 3 법칙에 대해 알아보고 다음 달에는 제4 ~ 7 법칙을 살펴보겠습니다. 그런 다음 마지막 호에서는 제8 ~ 10 법칙을 검토하고, 이 법칙이 2000년 처음 작성된 이후 발생한 일들에 비추어 볼 때 합리적이라고 판단되는 의견과 추가로 생각해 볼 문제를 제시할 것입니다.
제1 법칙: 악의적 의도를 가진 누군가가 사용자를 유도하여 자신이 만든 프로그램을 사용자의 컴퓨터에서 실행하도록 할 수 있다면 해당 컴퓨터는 더 이상 사용자의 것이 아니다.
이 법칙은 사실상 사용자가 컴퓨터에서 실행하는 모든 소프트웨어가 해당 컴퓨터를 제어할 수 있는 것으로 명시합니다. 이 불변의 법칙이 처음 나왔을 당시 Microsoft 운영 체제는 Windows 98, Windows Me 및 Windows NT 4.0이었습니다. 지금은 Windows Vista와 Windows Server 2008입니다.
Windows 98과 Windows Me에서는 사용자가 실행하는 모든 소프트웨어가 컴퓨터에 대해 전적인 제어 권한을 가졌습니다. Windows NT 4.0에는 매우 견고한 기본 보안 모델이 있었지만 이를 관리자로 실행할 경우 Windows NT 4.0의 격리 모델은 사실상 Windows 98과 Windows Me의 격리 모델로 다운그레이드되었습니다. 관리자가 아닌 사용자로 Windows NT 4.0을 실행할 수도 있었지만 상당히 불편했기 때문에 실제로 이 방법을 사용한 조직은 거의 없었습니다(열 손가락 안에 꼽을 정도).
관리자가 아닌 사용자로 Windows NT 4.0을 실행했다고 가정해 보겠습니다. 그래도 제1 법칙이 작성된 당시 이 법칙은 유효했을까요? 대답은 "유효했다"입니다. 먼저 Windows NT 4.0에는 중대한 결함이 많았습니다. 예를 들어 사용 권한을 더 엄격하게 했어야 할 부분들이 있습니다. 특히 커널 개체와 레지스트리에서 이런 부분이 두드러집니다. 또한 그 당시에는 아직 발견되지 않았지만 전문가들이 발생할 것이라 예상한 공격 유형도 많았습니다. 예를 들어 1999년 당시 사람들은 대화형 데스크톱에서 높은 권한의 사용자로 실행 중인 프로세스가 컴퓨터에 손상을 가할 수 있다는 사실을 인식하지 못했습니다. 이러한 사실이 널리 알려진 것은 2002년 Chris Paget이 파편 공격(Shatter attack)에 대한 백서 "Win32 API 악용"(seclists.org/bugtraq/2002/Aug/0102.html)을 발행한 이후였습니다.
제1 법칙의 초안이 작성된 당시 Microsoft는 파편 공격을 예상했을까요? 그렇지 않습니다. Microsoft는 다만 컴퓨터에서 실행 중인 응용 프로그램이 해당 컴퓨터를 장악하지 못하도록 하는 진정한 보안 경계는 거의 없다는, 단순한 사실만 인식하고 있었을 뿐입니다.
Windows Vista와 Windows Server 2008은 Windows NT 4.0과 두 세대 차이가 납니다. Windows Vista와 Windows Server 2008로 인해 제1 법칙이 무효화되었을까요? 아니면 이 법칙을 무효화한 다른 운영 체제가 있을까요? 상황에 따라 다릅니다. 새로운 OS에는 분명 더 견고한 보안 경계가 있고, 2000년에는 적절한 보안 경계를 가진 몇 가지 실험적 운영 체제도 있었습니다. 그러나 여전히 이러한 경계는 소수에 불과합니다. 예를 들어 Microsoft .NET Framework의 코드 액세스 보안은 보안 경계입니다. 이 경계는 샌드박스 내에서 실행되는 코드가 기본 운영 체제에 영향을 주지 않도록 하기 위한 목적으로 디자인되었습니다.
Internet Explorer의 Iframes는 또 다른 보안 경계를 제공합니다. 그러나 Iframes는 OS 자체에 대한 액세스에는 영향을 주지 않고 웹 페이지에서 각 콘텐츠 부분 간의 액세스에만 영향을 줍니다. 그림 1에 나와 있는 Internet Explorer의 보호 모드는 OS 수준의 보안 경계입니다. 이 경계의 목적은 사용자 작업 없이 브라우저 내에서 실행되는 코드가 기본 운영 체제에 영향을 주지 못하도록 하는 것입니다. 몇 가지 경계가 더 있는데, 그중 표준 사용자 계정은 사용자 계정이 기본 OS 또는 다른 사용자에게 영향을 주지 못하도록 하기 위한 경계입니다.
그림 1 Internet Explorer 7에는 보호 모드라는 보안 경계가 사용됨(더 크게 보려면 이미지를 클릭하십시오.)
"보안 경계"라는 용어의 의미를 이해하는 것이 무척 중요합니다. 완전한 격리를 무한대로 보장하는 불가침의 벽이 있다는 의미는 아닙니다. 이 용어가 실제 의미하는 바는 Microsoft와 같은 소프트웨어 공급업체가 보안 패치를 통해 이 경계의 침해 행위를 해결할 책임이 있다는 것입니다. 앞으로도 소프트웨어에서 버그는 항상 존재하고, 우리는 계속해서 더 많은 침해 행위를 발견하고, 소프트웨어 공급업체는 계속해서 패치를 제공할 것입니다. 소프트웨어 공급업체는 이러한 취약점을 미연에 방지하기 위해 소프트웨어를 점점 더 개선해 나가야 합니다. 이것이 바로 제1 법칙이 여전히 유효함을 입증하는 증거라고 볼 수 있습니다.
한편 고려해야 할 중요한 부분이 한 가지 더 있습니다. 앞부분에 보면 "사용자 작업 없이"라는 구절이 나옵니다. 제1 법칙은 사실 소프트웨어의 결점이나 취약점에 대한 법칙이 아닙니다. 바로 사람들의 취약점에 대한 법칙입니다. 이 법칙에서 핵심적인 부분은 "유도하여"입니다. 악의적 의도를 가진 누군가가 자신의 프로그램을 실행하도록 사용자를 유도할 때는 필시 프로그램에 높은 권한이 부여되도록 상황을 만든 상태에서 사용자를 유도할 것입니다.
사용자에게 관리자 권한이 없어도 상관 없습니다. 표준 사용자도 은행 거래 파일, 연애 편지, 사진, 동영상 및 회사 기밀 정보와 같은 여러 가지 중요 정보에 액세스할 수 있습니다. 이러한 정보는 공격자에게 흥미로울테고, 모두 높은 권한이 없어도 읽을 수 있습니다. 사용자가 컴퓨터에서 관리하는 정보 측면에서 보면 악성 프로그램을 실행할 경우 사용자의 모든 것이 공격자에게 넘어가게 됩니다. 따라서 "사용자의 컴퓨터"를 "사용자가 컴퓨터에서 관리하는 데이터"로 정의한다면 권한에 대해 설명한 모든 내용은 무시하고 제1 법칙이 유효하다고 간단히 결론을 내릴 수 있습니다.
"사용자의 컴퓨터"에 대한 정의를 꼬치꼬치 따지지 않더라도 제1 법칙은 시간이 지난 지금까지 유효한 것으로 보입니다. 제1 법칙의 요지는 컴퓨터의 운영자인 사용자가 해당 컴퓨터에서 실행되는 소프트웨어에 대해 책임을 져야 한다는 사실입니다. 악의적인 드라이버나 악의적인 비디오 코덱을 설치하는 것은 해당 컴퓨터의 모든 제어 권한을 범죄자에게 넘겨 주는 것입니다!
소프트웨어 공급업체는 의도하지 않은 손상을 방지하기 위해 여러 가지 일을 할 수 있고, 실제로 보안 경계도 이러한 맥락에 따른 것이지만 의식적으로 악성 소프트웨어를 실행할 경우 이러한 보호 조치는 대부분 물거품이 됩니다. 이러한 사실이 바로 사용자에게 관리 작업을 수행할 권한이 있어서는 안 되는 이유이자 사용자 교육이 중요한 이유입니다. 그러므로 제1 법칙은 지금도 유효하다고 말할 수 있습니다. 다만 이를 위해서는 사용자 컴퓨터의 정의를 약간 수정해야 할 수도 있습니다.
제2 법칙: 악의적 의도를 가진 누군가가 사용자 컴퓨터의 OS를 변경할 수 있다면 해당 컴퓨터는 더 이상 사용자의 것이 아니다.
언뜻 이 법칙은 아주 간단해 보입니다. 악의적 의도를 가진 누군가가 사용자 컴퓨터의 운영 체제를 변경할 수 있다면 해당 컴퓨터를 더 이상 신뢰할 수 없는 것은 당연합니다. 그러나 컴퓨팅 요구 사항이 발전하면서 OS가 의미하는 바도 달라졌습니다. 필자는 수년 전에 The Blackwell Encyclopedia of Management(managementencyclopedia.com)라는 백과사전에서 OS라는 용어에 대한 정의를 작성했습니다. 이 정의에는 입력 및 출력 장치에 대한 액세스, 하드웨어에 대한 액세스 등을 관리하는 OS에 대한 내용이 포함되어 있었습니다. 지금은 이 백과사전을 구할 수 없고 필자가 제출한 내용도 역사 속으로 사라진 상태이지만 확실한 사실은 OS에 카드놀이, 태블릿 입력 시스템 및 비디오 트랜스코더가 포함된다는 언급은 하지 않았다는 점입니다.
컴퓨팅이 점점 더 복잡해짐에 따라 OS도 더 많은 기능을 지원하도록 확장되었습니다. 게다가 OEM은 유용한 것부터 극히 유해한 것에 이르기까지 온갖 종류의 자체적인 추가 소프트웨어를 OS에 넣는 경우가 많고, 이로 인해 문제는 더욱 복잡해집니다. 이러한 추가 소프트웨어의 기능 일부는 이미 핵심 운영 체제에 기본 제공되는 기능과 중복되기도 합니다.
예를 들어 Windows Server 2008 Enterprise Edition 기본 설치는 5GB 이상의 디스크 공간을 차지합니다. Windows Vista Ultimate Edition에는 10GB 이상의 공간을 차지하는 58,000개 이상의 파일이 포함되어 있습니다. 또한 OS를 구성하는 파일 외에도 수천 개의 구성 설정과 데몬 또는 서비스가 있습니다.
이러한 것도 모두 OS의 일부입니다. OS는 모든 파일, 모든 구성 설정, 모든 서비스, 그리고 파일 및 구성 설정에 의해 만들어지는 모든 런타임 개체(세마포, 명명된 파이프, RPC 끝점)까지 포괄하는 집합적 용어입니다. 시스템 시간과 같은 매우 추상적인 구성체, 그리고 이벤트 로그 내용과 같은 특정 데이터 유형도 OS의 일부로 간주해야 합니다.
OS가 얼마나 확장되고 발전했는지 고려할 때, 이러한 파일 중 하나라도 수정하면 정말 컴퓨터를 신뢰할 수 없게 될까요? 우선 직접적인 대답은 '아니요'입니다. 예를 들어 Windows Vista에는 MS-DOS의 오래된 줄 편집기인 edlin.exe가 기본 제공됩니다. 단언할 수는 없지만 Windows Vista가 출시된 이후 이 운영 체제가 설치된 모든 시스템을 통틀어 edlin.exe가 호출된 횟수는 단 두 번이라는 데 맛있는 커피 한 잔 정도는 기꺼이 걸겠습니다. 두 번의 호출은 모두 약 3분 전 구문을 기억해 내려고 애쓰던 중 필자가 실행한 것입니다. 누군가 edlin.exe 또는 아무도 사용하지 않는 다른 파일을 수정했다고 해서 해당 컴퓨터는 더 이상 사용자의 것이 아니라고 말할 수 있을까요?
edlin.exe는 분명히 운영 체제의 일부입니다. 그러나 아무도 이 파일을 실행하지 않는다면 이 파일에 대한 수정이 어떻게 컴퓨터 손상으로 이어질 수 있을까요? 물론 대답은 컴퓨터가 손상되지 않는다입니다. 운영 체제에서 사용되지 않는 부분이라면 수정된다 해도 컴퓨터에 피해를 주지 못합니다. 그리고 OS에서 사용되지 않는 부분은 많습니다.
그러나 간접적인 대답은 '예'입니다. 단순히 누군가 파일을 실행하는지 그렇지 않은지만으로 이 파일에 대한 수정이 컴퓨터에 손상을 주는지 여부를 판단할 수는 없기 때문입니다. 문제는 이것보다 좀 더 복잡합니다. 그림 2에 나와 있는 edlin.exe의 ACL(액세스 제어 목록)을 살펴보십시오.
그림 2 매우 제한적인 edlin.exe의 ACL(더 크게 보려면 이미지를 클릭하십시오.)
edlin.exe의 ACL은 매우 제한적입니다. 이 실행 파일을 수정할 권한은 TrustedInstaller 서비스에만 있습니다. 이러한 사실은 매우 중요합니다. 사용자 컴퓨터에서 이 파일을 수정하는 악의적 의도를 가진 누군가에게 간접적인 영향을 미치기 때문입니다. edlin.exe를 수정하는 행위는 해당 컴퓨터가 더 이상 사용자의 것이 아님을 의미합니다. 여기서 핵심은 악의적인 사용자가 edlin.exe를 수정할 수 있다는 점입니다. 악의적 의도를 가진 누군가가 이 파일을 수정할 수 있다면 이는 사용자가 더 이상 컴퓨터의 어떠한 부분도 신뢰할 수 없음을 의미합니다.
OS는 스스로를 보호합니다. 서비스와 구성 설정은 무단 수정을 할 수 없도록 보호됩니다. 디스크의 파일도 무단으로 수정할 수 없도록 보호되며 운영 체제에서 사용하는 세마포와 RPC 끝점도 무단으로 수정할 수 없도록 보호됩니다. 이렇게 보호되는 개체 중 하나라도 공격자가 수정할 수 있다면 이 공격자는 다른 모든 개체도 수정할 수 있으며 이미 수정했을 가능성이 높습니다.
이 부분은 상당히 중요합니다. 여러 불변의 법칙에서는 어떤 행위를 두고 컴퓨터의 손상 여부를 판단하지 않습니다. 중요한 점은 누군가에게 무엇을 할 권한이 있는가, 그것 뿐입니다. 이 부분은 간과해서는 안 됩니다. 컴퓨터 보안에서는 동작의 실제 수행보다 그 동작을 할 수 있다는 사실 자체가 훨씬 더 중요한 경우가 많다는 점을 항상 기억해야 합니다.
컴퓨터가 인터넷에 완전히 개방되어 있고 몇 달 동안 패치가 적용되지 않은 상태로 유지된다면 이 컴퓨터를 신뢰할 수 있을까요? 아닙니다. 이 컴퓨터는 손상된 것으로 간주해야 합니다. 손상되었을 가능성이 있는 시스템에서는 아무것도 신뢰할 수 없습니다. (필자는 5년 전 쓴 "도움말: 해킹을 당한 경우 대처 방법"(technet.microsoft.com/library/cc512587)에서도 이와 똑같은 말을 했었습니다.) 공격자의 기술이 뛰어나다면 손상된 시스템에 손상 징후가 전혀 나타나지 않을 수 있습니다. 시스템은 평상시와 똑같아 보입니다.
의문의 여지 없이 제2 법칙은 아직 유효합니다. 공격자가 사용자 컴퓨터의 보호되는 개체를 수정할 수 있다면 해당 컴퓨터는 더 이상 사용자의 것이 아닙니다. 중요한 것은 실제로 공격을 당했는지 여부가 아니라 이러한 개체를 수정할 수 있는지 여부임을 기억하십시오.
제3 법칙: 악의적 의도를 가진 사람이 아무런 제한 없이 사용자의 컴퓨터에 물리적으로 액세스할 수 있다면 이 컴퓨터는 더 이상 사용자의 것이 아니다.
이 법칙은 2000년에 매우 중요한 법칙이었습니다. 이 당시 대부분의 사람들은 시스템에 물리적으로 액세스하여 무엇을 수행할 수 있는지 제대로 알지 못했습니다. 사실 더 많은 것을 알고 있어야 했던 일부 정부 기관조차도 이러한 기본적인 부분을 놓쳤습니다. 당시 보안 지침에서는 로그온하지 않은 채로 종료를 허용하는 옵션을 비활성화할 것을 권장했습니다. 이렇게 하면 로그온 화면에서 Shut down…(종료...) 단추가 회색으로 비활성화됩니다. 이러한 지침이 만들어진 배경은 컴퓨터를 종료하려는 사용자는 누가 시스템을 종료했는지에 대한 감사 기록이 남도록 먼저 로그온해야 한다는 이론이었습니다.
이는 잘못된 생각에 대한 사례 연구입니다. 로그온 화면에서 Shut down…(종료...) 단추에 액세스하려면 실제로 콘솔 앞에 앉아 있어야 합니다. 그리고 콘솔 앞에 앉아 있고 컴퓨터의 전원을 꼭 꺼야 하는 상황이라면 일반적으로 컴퓨터의 앞쪽에 있는 크고 둥근 전원 단추를 사용하면 되고 전원 코드를 뽑아도 합니다. 시스템이 종료되고 감사 추적은 없습니다.
Windows 2000에는 로그온할 필요 없이 도킹 해제 허용이라는 보안 설정이 제공되며 이 옵션은 Windows Vista에서도 계속 사용할 수 있습니다(그림 3 참조). 원리는 같습니다. 랩톱을 도킹 스테이션에서 도킹 해제하려면 먼저 시스템에 로그온해야 합니다.
그림 3 컴퓨터와 도킹 스테이션을 둘 다 훔치면? (더 크게 보려면 이미지를 클릭하십시오.)
이 설정의 실질적인 보안 가치는 매우 불분명합니다. 필자가 보기에 이 이론은 누군가 랩톱에 접근하여 도킹을 해제할 수만 있다면 컴퓨터를 쉽게 훔칠 수 있다는 의미라고 생각합니다. 필자가 랩톱을 훔칠 일은 없겠지만 만일 훔치려고 마음만 먹는다면 이와 같은 도난 방지 대책은 전혀 방해가 되지 않을 것입니다. 랩톱과 도킹 스테이션을 통째로 훔쳐가면 되니까요. 게다가 네트워크 케이블과 전원 코드까지 덤으로 가져가게 되겠군요. 완전히 쓸모없는 보안 수단입니다.
Petter Nordahl-Hagen이 오프라인 NT 암호와 레지스트리 편집기를 만들었을 때야 비로소 물리적 액세스의 핵심이 제대로 인식되기 시작했습니다. 그가 만든 것은 NTFS 볼륨에 대한 읽기/쓰기 액세스를 허용하는 실험용 NTFS 파일 시스템 드라이버가 포함된 Linux 부팅 디스크에 불과했습니다. 부팅 디스크의 소프트웨어는 레지스트리를 로컬 시스템에 탑재하고 SAM(소프트웨어 자산 관리) 하이브에 관리자 계정을 위한 새 암호를 썼습니다. 사용자가 해야 할 일은 시스템에 물리적으로 액세스하고 1 ~ 2분 정도 기다리는 것이 전부였습니다.
바로 이와 같은 도구 때문에 제3 법칙이 등장하게 되었습니다. 사실 Nordahl-Hagen의 도구는 많은 데모에서 사용되었습니다. 안타깝게도 대부분의 사용자들은 핵심을 제대로 파악하지 못했습니다. 필자는 개인적으로 몇 가지 데모에서 이 도구를 사용했지만 "사용자들이 이런 도구를 모르게 하려면 어떻게 해야 합니까?", 그리고 "Microsoft에서는 이 문제를 해결하기 위해 어떤 노력을 하고 있습니까?"라는 질문을 받는 데 지쳐 사용을 그만두게 되었습니다. 놀라울 정도로 많은 IT 업계 종사자들이 물리적 액세스가 다른 어떤 것보다 중요하다는 사실을 인정하거나 이해하려 하지 않았습니다.
이러한 환경에서 제3 법칙은 매우 중요한 의미를 제시했습니다. 그러나 비평가들은 이 법칙을 맹렬히 공격했습니다. 사람들은 Microsoft가 물리적 액세스와 아주 조금이라도 관련된 모든 문제를 수정하지 않기 위해 만든 법칙이라며 비웃었습니다. 실제로 제3 법칙은 여러 사례에서 취약점 보고(예: 오프라인 NT 암호 및 레지스트리 편집기 해킹)를 인정하지 않는 근거로 사용되었습니다. 그러나 시스템에 물리적으로 액세스할 수 있는 공격자를 차단하는 방법은 오로지 이들이 어떤 것에도 접근하지 못하게 하는 방법밖에는 없습니다.
바로 여기에 제3 법칙의 잠재적인 허점이 있습니다. 불변의 법칙이 작성된 후로 전체 디스크 암호화 기술이 바람직한 솔루션으로 부상했습니다. 전체 하드 디스크 암호화, 좀 더 정확한 용어로 전체 볼륨 암호화를 사용하면 전체 볼륨(운영 체제에 따라 파티션이라고도 함)을 암호화할 수 있습니다. 전체 부팅 볼륨(즉, OS가 위치한 볼륨)이 암호화된다면 제3 법칙이 여전히 유효한가에 대한 질문이 남습니다.
대답은 '그렇다고 볼 수 있다'입니다. 첫째, 암호 해독 키를 어딘가에 저장해야 합니다. 가장 손쉬운 보관 장소이자 BitLocker의 기본 옵션은 컴퓨터의 신뢰할 수 있는 플랫폼 모듈 칩입니다. 이렇게 하면 컴퓨터는 알아서 부팅됩니다. 일단 컴퓨터가 부팅되고 나면 해당 컴퓨터에 대한 영구적인 물리적 제어 권한이 있는, 기략이 뛰어나고 자본이 탄탄한 공격자는 이 컴퓨터를 마음껏 공격할 수 있습니다. 이제 컴퓨터를 임의 네트워크에 연결할 수 있으므로 네트워크와 관련된 방법을 통해 시스템을 공격할 수도 있습니다.
예를 들어 공격자는 USB 플래시 드라이브와 같은 DMA(직접 메모리 액세스) 장치를 사용하여 메모리를 읽거나 쓸 수 있습니다. 컴퓨터가 실행 중인 경우에는 공격자가 이 컴퓨터에 물리적으로 액세스할 수 있다면 모든 방책이 무효화됩니다.
암호 해독 키가 컴퓨터 자체에 저장되어 있지 않은 경우에는 공격자가 이러한 키를 얻거나 추측할 수 있는지 여부에 따라 공격 여하가 결정됩니다. PIN 코드가 컴퓨터 부팅에 사용되는 경우 공격자는 비교적 적은 노력을 들여 코드를 추측해 낼 수 있습니다. USB 플래시 드라이브 또는 일회용 암호 저장소와 같은 별도의 하드웨어 장치에 암호 해독 키가 저장되어 있거나 여기서 키가 파생되는 경우 공격자는 이러한 별도의 장치에 액세스할 수 있어야 합니다. PIN 코드보다 더 많은 노력이 필요하긴 하지만 이러한 키를 얻는 방법, 또는 이러한 키에 대한 액세스 권한이 있는 사람을 속이는 방법도 확실히 있습니다.
제3 법칙을 약간 다른 관점에서 "공격자가 사용자 컴퓨터에 물리적으로 액세스할 수 있다면 컴퓨터는 도난된 상태일 가능성이 높고 사용자가 되찾을 가능성은 거의 없다."로도 해석할 수 있습니다. 이 관점에서 볼 때 컴퓨터는 정말로 더 이상 사용자의 것이 아닙니다. 또한 이 관점에서 보면 사용자 컴퓨터의 데이터에 액세스할 수 있는지 여부는 공격자에게 중요한 문제가 아닐 수도 있습니다. 그러나 이는 제3 법칙이 의미하는 바가 아닙니다. 이 법칙은 공격자가 컴퓨터 자체뿐만 아니라 컴퓨터의 데이터도 액세스할 수 있음을 의미했습니다.
모든 사항을 고려할 때 제3 법칙은 여전히 유효합니다. 오늘날 사용되는 기술 중 일부는 물리적 액세스 권한이 있는 많은 공격자를 저지하고, 이로써 안전 장치가 탑재된 컴퓨터의 데이터에 액세스할 수 있는 공격자의 수를 최소화하는 데 있어 상당한 발전을 이룬 것이 사실입니다. 즉, 공격자가 실제로 얼만큼의 성과를 거둘 수 있는지는 항상 공격자의 권한에 따라 정해지며 새로운 기술이 10가지 불변의 법칙 상당수를 어느 정도 해결해 주고 있습니다. 그러나 조금 더 복잡하다 해도 여전히 물리적 액세스는 시스템 침투 방법을 제공합니다.
지금까지 살펴본 바로 불변의 보안 법칙은 기술 발전과 시간의 흐름에 매우 탄력적으로 적응하는 것으로 입증되었습니다. 처음 세 가지 법칙 중 제3 법칙은 일부 사례에서 여전히 유효성을 유지하고 있지만 기반이 가장 불안합니다. 하지만 이 법칙은 즉시 사용 가능한 강력한 완화책을 가진 법칙이기도 합니다. 다음 2회의 TechNet Magazine에서는 이번 호에 이어서 제4 법칙 ~ 제10 법칙이 아직 불변한지를 확인해 보겠습니다.

Jesper M. Johansson은 보안 소프트웨어 분야의 소프트웨어 설계자이며 TechNet Magazine의 객원 편집자로서, 정보 관리 시스템 분야 박사 학위와 20여 년 이상의 보안 관련 경력을 보유한 엔터프라이즈 보안 영역의 Microsoft MVP(Most Valuable Professional)입니다. 그의 최근 저서로는 Windows Server 2008 Security Resource Kit가 있습니다.


Field Notes 고용량 컬러 바코드
Gavin Jancke

우리는 모두 바코드에 너무 익숙한 나머지 많은 경우 의식조차 하지 못합니다. 바코드는 일상 생활의 도처에 존재하며 음식 포장지부터 배송 레이블에 이르기까지 모든 곳에 사용됩니다. 1974년 소매 산업에 등장한 첫 1D 바코드는 각기 폭이 다른 여러 수직 막대로 구성되었으며 12자리 숫자를 저장했습니다. 컴퓨팅 성능이 향상되면서 바코드는 발전을 거듭하여 80년대 후반에는 흑백 2D 바코드(매트릭스 코드)가 개발되었습니다. 이 바코드는 몇 자리의 숫자에 불과했던 데이터 밀도를 수백 바이트로 늘렸습니다.
필자는 2003년 위조 방지 생체 ID 카드와 관련된 Microsoft Research 프로젝트에서 작업을 시작했습니다. 당시 필자는 이름, 나이와 같은 암호화 데이터뿐만 아니라 지문 또는 홍채 스캔 템플릿도 저장해야 했습니다. 기존의 흑백 바코드를 사용하여 필요한 데이터를 모두 저장하려면 바코드가 ID 카드 자체보다 커지는 문제가 발생했고 따라서 새로운 접근 방식이 필요했습니다.
필자는 흑백 2D 바코드의 표준이었던 기호 하나당 1비트를 뛰어넘어 더 많은 정보를 저장할 방법을 찾아야 했습니다. 흑백 대신 컬러를 사용하는 방법으로 저장되는 데이터 용량을 2비트(4색 사용) 또는 3비트(8색 사용)로 늘릴 수 있었습니다.
또한 필자는 스캔 시 등록 성능을 떨어뜨리지 않으면서 기호를 더 촘촘하게 채워 넣을 수 있는지 확인하기 위해 기호의 모양도 실험했습니다. 처음에는 6각형이 괜찮아 보였지만 모양이 서로 겹치면서 컴퓨터가 이를 명확히 인식하지 못하는 문제가 발생했습니다.
필자는 결국 삼각형으로 결정했습니다. 삼각형은 좁은 공간에서 엇갈려 배치하기 편하면서도 각기 개별적인 모양으로 ID를 잘 유지했습니다. 여러 색의 삼각형으로 이루어진 행을 사용하면서 필자는 밀도 용량을 3D로 늘리는 데 성공했습니다.
이 작업에는 고민해야 할 변수가 많았습니다. 색 사용에 따른 가장 큰 과제 중 하나는 인쇄 사양과 조명 조건에 따른 편차입니다. 사람의 눈으로는 쉽게 색을 구분할 수 있지만(색맹이 아니라면) 컴퓨터 입장에서는 그렇게 명확히 구분이 되지 않습니다.
필자는 소프트웨어에서 정확히 색을 읽도록 하기 위해 여러 가지 접근 방법을 사용했습니다. 실제 바코드에 사용된 기준 색이 포함된 팔레트를 거의 알아볼 수 없을 정도로 작게 만들어 바코드 내에 넣었습니다. 이 팔레트는 예를 들어 특정 빨간색을 구성하는 요소를 정확히 지정하는 조정 메커니즘을 제공했습니다. 또한 필자는 색 공간 이론을 사용하여 색을 집합으로 분류하는, 가벼운 사용자 지정 색 묶음 알고리즘과 같은 고급 기술도 시험했습니다. 이 두 가지 접근 방법은 모두 잘 동작했고 서로를 보완했습니다.
이 프로젝트에서 필자의 목표 중 하나는 휴대폰에서 바코드를 읽을 수 있도록 하는 프로그램을 작성하는 것이었습니다. 휴대폰의 경우 열악한 조명, 그리고 고정 초점 길이의 흐릿한 렌즈를 고려해야 합니다. 더 어려운 문제는 이 컴퓨터 시각 구현 작업을 정수 기반의 느린 휴대폰 CPU에서 수행해야 한다는 점이었습니다. 따라서 팀은 최소한의 픽셀만 처리하면서 이미지의 바코드를 탐지하는 방법에 대한 신뢰할 수 있는 이론을 제시해야 했습니다. 스캔은 밝고 선명한 LCD 패널부터 어둡고 흐릿한 인쇄물에 이르기까지 다양한 판독 대상 품질에 걸쳐 동작해야 했습니다.
최종 알고리즘은 실시간 카메라 비디오 프레임의 바코드 이미지를 실제 프레임 속도보다 더 빠르게 해독합니다(200Mhz CPU에서 약 10ms). 이미지에서 감지가 가능한 선에서 최소한의 데이터 페이로드로 바코드를 만들 수 있는 최소한의 픽셀 수는 약 45 x 45 픽셀입니다.
다양한 조건에서 이러한 모든 기능이 동작하도록 다듬는 데는 2년 이상이 걸렸습니다. 이 기술은 최근 타사로 라이선스되었는데, 올해 하반기에는 몇 가지 흥미로운 응용 사례가 나올 것입니다.
Gavin Jancke는 Microsoft Research의 엔지니어링 책임자이며 Advanced Development Group과 Web Experience 팀을 이끌고 있습니다. 이전에는 SQL Server의 소프트웨어 엔지니어, 제품 지원 엔지니어로 일했으며 Bill Gates 기술 자문 참모진의 일원으로 활동했습니다.


Windows Confidential 현명하게 일하지 말고 그냥 힘들게 일하라?
Raymond Chen

소프트웨어 개발자에게 Windows 오류 보고의 커다란 장점 중 하나는 이를 통해 프로그램의 오류 양상에 대한 실제 환경의 정보를 수집할 수 있다는 것입니다. 소프트웨어 공급업체는 winqual.microsoft.com에서 온라인으로 등록만 하면 이 오류 보고를 이용할 수 있습니다. 물론 테스트 환경에서 철저히 테스트를 실행할 수도 있지만 테스트 환경의 조건과 실제 환경의 조건 사이에는 항상 차이가 있습니다. 이러한 차이로 인해 테스트에서는 나타나지 않는 버그가 고객을 괴롭히곤 합니다.
필자는 몇 년 전에 제품 안정성 팀이 요청한 일을 의뢰 받은 한 프로그래머의 이야기를 들었습니다. 제품 안정성 팀은 특정 구성 요소에서 충돌 및 기능 중단을 유발하는 핵심 원인을 해결하고자 했습니다. 양쪽은 약간의 협상을 거쳐 이러한 유형의 오류 수를 절반으로 줄인다는 목표점을 세우는 데 합의했습니다. 이들은 Windows 오류 보고의 측정에 따라 해당 구성 요소에서 발생하는 충돌 및 기능 중단의 원인 중 최소 50%에 해당하는 버그를 수정하고자 했습니다.
누구나 알듯이 오류는 골고루 분산되지 않습니다. 상대적으로 말하자면 어떤 오류는 드물고, 어떤 오류는 흔하고, 어떤 오류는 도처에 만연할 정도로 발생합니다. 엔지니어링에는 타협이 수반됩니다. 즉, 자원(시간, 비용, 인력)은 한정되어 있으므로 가장 큰 효과를 낼 수 있는 부분에 이러한 자원을 집중해야 합니다. 여기서의 목표는 충돌과 기능 중단의 횟수를 줄이는 것이므로 합리적인 접근 방식은 Windows 오류 보고에서 보고되는 가장 일반적인 오류를 연구하고 그 근본 원인을 파악한 후 이러한 일반적 오류를 수정하는 것입니다.
프로그램 오류에 대한 실제 환경 정보를 제공하는 Windows 오류 보고 (더 크게 보려면 이미지를 클릭하십시오.)
이 프로그래머는 오류 데이터를 연구했고 5가지 충돌 및 기능 중단이 보고의 60% 이상을 차지한다는 사실을 파악했습니다. 이 5가지 오류를 유발하는 버그를 수정한다면 충돌 및 기능 중단의 횟수를 목표인 절반을 넘어 2/5까지 줄일 수 있다는 이야기입니다.
Microsoft 자체에서 Windows 오류 보고 데이터를 분석한 결과 Windows 충돌 및 기능 중단에는 약 20%의 버그가 오류의 80%를 일으킨다는 Pareto의 법칙이 신기할 정도로 잘 들어맞았습니다. 그런데 더욱 놀라운 사실도 발견되었습니다. 바로 1%의 버그가 50%의 오류를 일으킨다는 것입니다. 모든 버그가 애초에 균등하지 않다고는 하지만 그 분포의 불균형은 놀라울 정도입니다.
이 5가지 오류를 더 신중하게 살펴본 프로그래머는 5가지 오류 모두 원인은 하나라는 사실을 밝혀냈습니다. 모든 충돌과 기능 중단은 똑같은 버그의 각기 다른 발현이었던 것입니다. 이 프로그래머는 픽스를 개발해 테스트한 후 품질 보증 팀 직원들과 함께 이 픽스를 다음 패치에 넣기 위한 단계에 착수했습니다. 이 하나의 버그 픽스를 통해 해당 구성 요소의 문제 발생률은 이론적으로 2/5로 낮아졌습니다. 프로그래머는 하나의 간단한 코드 픽스만으로 업무를 완수했습니다.
필자는 이 이야기를 들었을 때 그 구성 요소에 대한 오류 분포 곡선의 불균형이 Windows 곡선의 불균형 더 심하다는 사실에 놀라움을 느꼈습니다. 모든 충돌 및 기능 중단의 절반 이상이 하나의 버그로 인해 유발된 것입니다. 이러한 사실은 Windows 오류 보고 등을 통해 수집되는 데이터가 없다면 결코 알 수 없는 부분입니다.
아마도 제품 안정성 팀은 그렇게 빨리 목표를 달성했다는 사실이 몹시 기뻤을 것입니다. 상호 합의된 목표가 불과 2주만에, 하나의 픽스로 초과 달성되었으니까요. 그런데 사실 제품 안정성 팀은 몹시 언짢았다고 합니다.
두 달에 걸쳐 진행될 것으로 예상했는데 너무 일찍, 쉽게 끝났기 때문이라나요. 아마 이들은 프로그래머가 머리를 쓰기보다는 그냥 고생스럽게 일하기를 바랐던 모양입니다.
Raymond Chen은 자신의 웹 사이트 The Old New Thing에서 Windows의 역사와 Win32 프로그래밍에 대해 다루고 있으며 동명의 저서에서도 이에 대해 다루었습니다. 그는 20%의 옷이 전체 세탁물의 80%를 차지한다고 합니다.