시작하기 전에go.microsoft.com/fwlink/?LinkID=119707에서 최신 버전을 다운로드해야 합니다.

우선 중요한 두 가지 사항을 밝혀 두겠습니다. CTP는 Microsoft가 다음 버전의 응용 프로그램에서 지향해야 할 방향에 대해 적극적인 사용자들로부터 의견을 듣기 위해 제공하는 사전 베타 코드입니다. 각 CTP 버전 또는 드롭(업계 용어)은 이전 드롭과 완전히 다를 수 있습니다. 개발 팀에서 피드백을 수집하여 철저하게 검토한 후 이러한 사용자 피드백을 기준으로 응용 프로그램을 변경하기 때문입니다. 이러한 방식에서는 CTP 사용과 관련하여 유리한 혜택을 받을 수 있고 주의해야 할 경고도 있습니다.

유리한 혜택이란 CTP를 사용할 때 connect.microsoft.com 웹 사이트를 통해 제품에 대한 피드백을 제공할 수 있다는 것입니다. 그러면 개발 팀에서 개발 중 해당 피드백에 대해 조치를 취할 수 있습니다! 베타 또는 RC(Release Candidate) 단계까지 기다릴 경우 피드백을 적용하기가 더욱 어려워집니다. CTP 중에는 모든 것이 가능하고, 개발 팀에서는 필요한 경우 대대적이고 완전한 변경 작업을 수행할 수 있습니다.

반면 경고도 따릅니다. CTP는 생산 준비가 되지 않은 버전입니다. 물론, Windows PowerShell™ 2.0 CTP2는 지금까지 발표된 사전 릴리스 코드 중 가장 안정적인 버전일 수 있지만, 다음 번 CTP 드롭은 완전히 다른 응용 프로그램이 될 수도 있습니다. 따라서 다음 버전에서 처음부터 다시 시작해야 할 수 있으므로 CTP2에 너무 의존하지는 마십시오.

CTP는 Windows PowerShell 1.0과 함께 설치할 수 없습니다. 최상의 설치를 위해 시스템에 Microsoft® .NET Framework 3.5도 설치되어 있어야 모든 기능을 사용할 수 있습니다. 그렇지 않으면 일부 기능이 제한됩니다.

또한, CTP는 매우 초기의 코드이므로 Microsoft는 지금까지 Windows Vista® 및 Windows Server® 2008을 비롯한 최신 운영 체제에서 작동하는 응용 프로그램에 중점을 두고 있습니다. 현재의 OS 호환성은 최종 발표될 코드의 OS 호환성을 나타내지는 않습니다. 이전 버전과의 호환성은 개발 주기의 후반에 적용됩니다.

두 가지 유형의 원격

원격 관리에는 대개 팬 인(fan-in)과 팬 아웃(fan-out)의 두 가지 유형의 원격 기능이 있습니다. 팬 인(Fan-in) 원격 기능은 단일 서버에 여러 관리자가 보안 셸 연결을 합니다. Windows PowerShell은 보안 분할 방식으로 이 기능을 사용할 수 있도록 설계되었습니다. 따라서, Exchange Server로 회사를 호스팅할 경우 고객에게 서버의 일부에 대한 관리 액세스를 제공할 수 있습니다. 팬 인 원격 기능을 사용하면 원격 서버에 설치된 Windows PowerShell(버전 2.0만 해당)에 원격으로 보안이 유지되는 대화형 액세스가 가능합니다.

팬 아웃(Fan-out) 원격 기능을 사용하면 전체 원격 서버 그룹에 대해 일련의 명령을 한 번에 실행할 수 있습니다. 실행된 명령은 워크스테이션에서 서버 그룹에 동시에 전파됩니다. 명령은 각 서버에서 실행되고, 결과는 Windows PowerShell 개체의 형태로 워크스테이션에 반환되므로 결과를 검토하고 작업을 수행할 수 있습니다. Windows PowerShell은 팬 아웃 원격 기능을 위한 두 가지 핵심 기술인 Windows® Management Instrumentation(WMI)과 Windows Server 2008에서 처음 도입된 후 Windows PowerShell 2.0 CTP에서 업데이트된 Windows Remote Management(WinRM)를 지원합니다.

동기와 비동기

실제로 Windows PowerShell 1.0에도 WMI와 연결된 기본적인 팬 아웃 기능이 있었습니다. 예를 들어, 컴퓨터 이름 배열을 만든 다음 각각에서 WMI 클래스를 쉽게 검색할 수 있었습니다.

$names = @("server1","server2","server2")

Get-WmiObject Win32_OperatingSystem

–computer $names

버전 1.0에서는 WMI 메서드를 한 번에 실행할 수 있는 방법을 제공하지 않았기 때문에 컴퓨터 재부팅과 같은 메서드 실행에는 좀 더 많은 작업이 필요했습니다. 하지만 버전 2.0 CTP에서 Invoke-WmiMethod cmdlet를 도입하면서 바뀌었습니다.

$names = @("server1","server2","server2")

Get-WmiObject Win32_OperatingSystem –computer $names | `

Invoke-WmiMethod Reboot

이 기술에도 문제는 있습니다. 작업이 동기로 수행되므로 각 컴퓨터가 한 번에 하나씩 연결되고 다른 명령을 실행할 수 있으려면 각 명령이 완료될 때까지 기다려야 합니다. 그러나 CTP에서는 이와 같은 명령을 백그라운드에서 실행할 수 있도록 백그라운드 작업이라는 새로운 개념을 도입했습니다. 간단히 –AsJob 매개 변수만 추가하면 백그라운드에서 WMI 명령을 실행할 수 있습니다.

$names = @("server1","server2","server2")

Get-WmiObject Win32_OperatingSystem –computer $names -asjob

결과 작업의 상태는 Get-PSJob을 실행하여 검토할 수 있으며, 작업의 최종 결과는 Receive-PSJob을 실행하여 볼 수 있습니다. 다음 칼럼에서 작업 관리에 대해 더 자세히 살펴보도록 하겠습니다. 하지만 Invoke-Command cmdlet은 다음과 같이 백그라운드에서 명령을 실행할 수 있는 더 좋은 방법을 제공합니다.

$command = { Get-WmiObject Win32_OperatingSystem }

$names = @("server1","server2","server2")

Invoke-Command –command $command –computer $names –asjob

이 명령은 지정된 각 컴퓨터에 Get-WmiObject 명령을 보낸 다음 로컬에서 실행합니다. 일반적으로 실행 속도가 더 빠르며 WMI 원격 프로시저 호출(RPC) 연결에 의존할 필요도 없습니다. 대신 Invoke-Command는 기본적으로 포트 80 또는 443을 사용하는 WinRM을 활용합니다. 이러한 포트는 방화벽을 손쉽게 탐색할 수 있게 해주며 전체적으로 구성이 가능합니다. 또한 Invoke-Command는 대체 자격 증명 및 제한을 위한 추가 매개 변수를 지원하여 수백 대의 컴퓨터를 대상으로 하지만 일부만 병렬로 실행할 수 있습니다. 따라서 정체 및 과도한 오버헤드를 피할 수 있습니다.

재사용 가능한 실행 영역

특정 컴퓨터 그룹을 두 번 이상 원격으로 관리할 계획이라면 단순한 컴퓨터 이름 목록이 아닌 실행 영역을 사용해 보도록 합니다. Windows PowerShell에서 실행 영역은 컴퓨터의 셸 콘솔 창에서 로컬로 실행되거나 원격 컴퓨터에서 백그라운드로 실행되거나 상관없이 단순히 셸 엔진의 인스턴스입니다. 원격 실행 영역을 시작하는 방법은 간단합니다.

$names = @("server1","server2","server2")

New-RunSpace –computer $names

실행 영역에서도 WinRM을 사용하므로 기본적으로 포트 80(또는 –UseSSL 매개 변수를 지정할 경우 443)을 사용합니다. 또한 대체 인증서 등도 허용할 수 있습니다. 결과 실행 영역 개체를 검색할 경우 Invoke-Command로 전달할 수 있으며, Windows PowerShell은 이러한 실행 영역이 존재하는 컴퓨터로 명령을 보냅니다.

$command = { Get-WmiObject Win32_OperatingSystem }

$rs = Get-Runspace

Invoke-Command –command $command –runspace $rs –asjob

여기서 이점은 셸이 열려 있는 동안에는 실행 영역이 활성 상태로 유지되어 추가 명령에 대해 간단히 재사용할 수 있다는 것입니다.

팬 인(Fan-In) 원격

실행 영역은 팬 인 원격 기능에서도 중요합니다. 예를 들어, 그림 1에서는 원격 컴퓨터에서 실행 영역을 만들고 해당 실행 영역에 대한 참조를 검색한 후 Push-Runspace cmdlet을 사용하여 실행 영역을 활성화했습니다. 여기서 SSH 또는 기타 원격 셸 유틸리티와 유사하게 원격 컴퓨터에서 명령을 실행합니다. Pop-Runspace를 실행하면 원래의 "로컬" 실행 영역으로 돌아오고, 셸 프롬프트를 통해 현재 어느 위치에 있는지 알 수 있습니다.

그림 1 실행 영역을 사용하여 원격 컴퓨터에서 명령 실행

실행한 정확한 명령 시퀀스는 다음과 같습니다.

PS C:\>new-runspace -computer "WIN-YFZXQMHXAWM"

PS C:\>$server2 = get-runspace -sessionid 2

PS C:\>push-runspace $server2

[win-yfzxqmhxawm]: PS C:\Windows\System32> pop-runspace

PS C:\>

이 기술은 여러 관리자가 동시에 동일한 서버에서 대화형 원격 실행 영역을 열 수 있고 개별 워크스테이션에서 서버로 들어올 수 있으므로 팬 인이라고 합니다. Windows PowerShell 2.0의 새로운 보안 모델을 통해 제한적인 셸과 cmdlet를 만들어 각 관리자가 전역 수정을 하지 못하게 할 수 있습니다. 각 관리자는 자신의 고유 셸로만 제한됩니다. 이러한 새로운 보안 기술에는 .NET Framework 대상 언어로 몇 가지 사용자 지정 소프트웨어를 개발해야 합니다. 이 내용은 Windows PowerShell 칼럼의 범위를 벗어나지만 이러한 기능이 있다는 사실을 알아두는 것이 좋습니다.

2.0의 핵심 응용 프로그램

Windows PowerShell 2.0 CTP에는 여러 가지 놀라운 새로운 기능이 포함되어 있으나 제 생각으로는 원격 기능이 핵심 응용 프로그램입니다. 거의 모든 환경의 모든 관리자는 원격 기능을 통해 이점을 누릴 수 있습니다.

WDS는 재작성된 원격 설치 서비스(RIS)라고 생각할 수 있습니다. 둘 다 몇몇 주요 구성 요소를 공유하고 실제로 Windows Server® 2003의 WDS 버전에는 RIS와 기능적으로 동일한 레거시 모드가 있지만, 기본 모드 및 50% 혼합 모드에서 실행되는 WDS의 실제 인프라는 완전히 새로운 것입니다.

Windows Server 2003의 WDS

Windows Vista®가 출시되었을 때 WDS도 동시에 제공되었습니다. Windows Vista 설치는 Windows® Imaging Format(WIM) 아키텍처를 사용하여 완전히 재설계되었기 때문에 RIS를 통해서는 Windows Vista(및 Windows Server 2008)를 배포할 수 없게 되었으므로 이 단계가 필요했습니다. 그 이후 Windows Server 2003 SP1을 실행하는 고객들은 WDS를 선택적으로 다운로드할 수 있게 되었습니다. SP2에서는 RIS가 WDS로 완전히 대체되었습니다.

Windows Server 2003의 WDS는 이전 버전과 완벽하게 호환되므로 Windows Server 2003 SP2 시스템에 WDS를 설치할 때 기본 모드로 전환하지 않아도 됩니다. 계속해서 레거시 모드로 실행(기능적으로 RIS 서버로 실행)하거나 WDS 또는 RIS를 시작할 수 있는 혼합 모드로 실행할 수 있습니다.

Windows Vista 및 Windows Server 2008을 배포할 수 있을 뿐 아니라 기본 모드 또는 50% 혼합 모드로 실행되는 WDS에는 여러 가지 추가 기능이 있습니다. 지난 달에 설명한 Windows 커널 모드 설치 엔진 및 기존의 설치 코어(technet.microsoft.com/magazine/cc645015)를 사용하는 대신, WDS에서는 Windows PE를 부트스트랩 사전 설치 환경으로 사용하고 RISetup 또는 RIPrep 기반 설치를 사용하는 대신 WIM 기반 이미지를 배포합니다. 이를 통해 배포가 더욱 빨라지고 쉬워지며 안정성이 높아집니다.

또한, Windows PE는 Windows 전체 설치와 동일한 문자 집합을 표시할 수 있으므로 ANSI(American National Standards Institute) 기반 문자를 사용해야 한다는 등의 지난 달에 언급했던 많은 제한 사항이 없습니다.

WDS에는 RIS에 없는 관리 지원을 위한 Microsoft® Management Console(MMC) 스냅인 및 RIS에 비해 구성 기능을 확장하는 포괄적인 명령줄 구성 도구 등 몇 가지 도구가 포함되어 있습니다.

레거시와 혼합 모드에서 모두 RISetup 및 RIPrep 기반 Windows 이미지 배포가 가능하므로 한 가지 사항을 염두에 둘 필요가 있습니다. RIS에서는 디스크의 이미지 저장을 최적화하기 위해 SIS(단일 인스턴스 저장소)라는 구성 요소를 사용했습니다. 나중에 Windows Storage Server 2003의 일부로 제공된 SIS는 RIS(및 WDS) 서버에서 백그라운드로 실행되어 동일한 파일을 찾는 Groveler라는 서비스를 사용했습니다. 파일의 크기와 해시가 일치하면 SIS는 복사본을 SIS Common Store 폴더에 저장한 다음 찾은 각 원본 버전에 대한 하드 링크를 만듭니다.

SIS는 프로세서 사용률에 대한 영향을 최소화하면서 저장 공간 절약이 가능하도록 설계되었습니다. 이러한 개념은 RIS에서 처음으로 사용된 다음 Windows Server 플랫폼에서 널리 사용되었습니다. 그러나 SIS는 WDS에서 더 이상 사용되지 않습니다.

기본 모드로 실행되는 Windows Server 2003의 WDS(및 Windows Server 2008의 경우 항상)는 설치를 위해 WIM 이미지를 사용하므로 고유의 압축 및 더욱 중요한 고유의 단일 인스턴스 파일 저장 모델이 있으며 SIS는 전혀 사용하지 않습니다. 이미지 저장소는 WDS를 위한 새로운 WIM 기반 설계로 RIS에서 사용되는 저장 모델을 대체합니다. SIS에 대한 자세한 내용은 go.microsoft.com/fwlink/?LinkId=120302를 참조하십시오.

Windows Server 2008의 WDS

Windows Server 2008에서 WDS는 Windows Server 2003 기능의 상위 집합이며 또한 하위 집합입니다. 이제 EFI(Extensible Firmware Interface) 기반 x64 시스템을 지원하고, 향상된 설치 메트릭 보고 기능을 갖춘 뛰어난 성능의 신형 TFTP(Trivial File Transfer Protocol) 서버인 전송 서버를 사용하여 독립 실행형 모드에서 멀티캐스트를 통해 이미지를 배포할 수 있습니다. 이러한 기능에 대해서는 다음 달 칼럼에서 설명하겠습니다.

Windows Server 2008의 WDS에는 Windows Server 2003에 있었던 레거시 설치 지원 기능이 없습니다. RISetup/RIPrep 이미지 배포 기능 또는 레거시 RIS OS 선택기를 사용하여 설치를 시작하는 기능은 더 이상 사용할 수 없습니다.

선택

Windows Server 2008이 출시된 이후 가장 자주 듣는 질문 중 하나는 "어떤 버전의 WDS를 사용해야 할까요?"입니다. 대답은 Windows Vista 이전의 Windows 버전을 배포하는지 여부와 그러한 경우 RISetup 및/또는 RIPrep 기반 이미지에서 전환하여 WIM 기반 설치를 사용할 준비가 되어 있는지 여부에 따라 달라집니다.

WDS는 Windows Server 2008에서도 WIM 이미지라면 Windows 2000 버전까지 모든 이전 버전의 Windows를 배포할 수 있으며, 멀티캐스트를 사용하여 작업을 수행할 수 있습니다. 따라서 지금 RIS에서 WDS로 전환하고, 인프라에 Windows Server 2008을 생각하고 있으며, RIS 기반에서 WDS 기반 이미지로 마이그레이션할 의향이 있다면 Windows Server 2008의 WDS로 마이그레이션이 적절할 수 있습니다.

Windows Server 2003 시스템 자체에서도 RIS에서 WDS로 마이그레이션하고(SP2를 설치할 경우 기본), WDS 기반 이미지로 전환할 수 있습니다. 그런 다음 Windows Server 2008 WDS로 업그레이드할 수 있습니다.

하지만 이것은 제가 권장하는 모델이 아닙니다. 2008 이전에 많은 버전의 Windows Server가 있으므로 Microsoft에서는 한 버전의 Windows Server에서 다른 버전으로 마이그레이션(업그레이드와 대비)하는 것을 권장합니다.

그리고 이전에 언급한 대로 인프라에서 Windows Server 2008 x64 버전을 고려하는 것이 Windows Server 2003 x64 버전을 고려하는 것보다 훨씬 낫습니다. 이러한 전환을 할 경우 Windows Server 2003에서 Windows Server 2008로 WDS의 서버 간 마이그레이션 작업이 업그레이드 작업에 비해 비교적 쉽고 훨씬 안정적입니다.

고려 사항

WDS 배포 작업에서 고려해야 할 몇 가지 사항이 있습니다. 실제로 WDS에 대한 새로운 요구 사항은 아닙니다. RIS의 경우에도 이와 동일한 여러 고려 사항이 있었습니다. 하지만 단일 WDS 서버를 구축하든지, 전체 인프라를 구축하든지 다음 사항을 염두에 둘 필요가 있습니다.

권한 WDS 서버를 관리할 때 기억해야 할 두 가지 기본 사항이 있습니다. Active Directory®에서 RIS와 마찬가지로 WDS 서버에 권한을 부여해야 합니다. 이렇게 하려면 포리스트의 루트 도메인에서 도메인 관리자 또는 엔터프라이즈 관리자이거나 적절한 권한이 위임되어야 합니다. 또한 WDS 서버를 관리하려면 도메인 관리자여야 하고, 물론 WDS 서버 자체의 관리자이기도 해야 합니다.

가상화 Microsoft Virtual PC 또는 Virtual Server상의 가상화된 Windows Server 2003 또는 Windows Server 2008 인스턴스에서 실행하고 Virtual PC 또는 Virtual Server가 설치되어 있는 동일한 클라이언트 PC와 통신할 경우, PXE 부팅 시 경합 상태가 발생하여 클라이언트가 매우 느려지거나 멈출 수 있습니다. 클라이언트 또는 서버를 가상화할 수 있지만 둘 다 가상화하는 것은 권장되지 않습니다. 특히, 동일한 호스트 시스템에서는 더욱 그렇습니다. 개인적으로 프로덕션 환경에서 WDS 서버를 가상화하는 것은 권장하지 않는데, 주로 다음과 같은 고려 사항 때문입니다.

기타 서비스 WDS는 RIS와 마찬가지로 다른 프로덕션 서비스와 항상 잘 작동하는 것은 아닙니다. 특히, Microsoft Exchange Server, Systems Management Server(SMS) 및 System Center Configuration Manager(SCCM)가 실행 중인 프로덕션 시스템에서 실행할 경우 RIS/WDS에 문제가 발생하는 것을 목격했습니다.

일반적으로 5대가 넘는 클라이언트에 대한 프로덕션 환경에서 WDS를 사용하는 경우 서버에서 WDS가 유일한 역할이 되도록 하는 것이 좋습니다. WDS뿐만 아니라 Windows 서버 제품의 역할을 함께 사용할지 여부를 신중히 고려하고 배포 전에 테스트해야 합니다.

느리거나 대기 시간이 긴 링크 RIS와 마찬가지로 WDS는 위성 링크와 같은 낮은 대역폭 연결이나 대기 시간이 긴 연결을 통해 사용하도록 설계되지 않았습니다. PXE 핸드셰이크에서 문제가 발생할 수 있으며, 작동된다고 해도 이미지 다운로드에 상당히 많은 시간이 소요될 수 있습니다.

WDS 시작

WDS에 대한 추가 정보

• Windows Server 2003의 WDS에 대한 단계별 안내서
• Windows 배포 서비스 단계별 안내서(Windows Server 2008)
• Windows Server 2003에서 WDS 업데이트 배포 및 관리
• Windows Server 2008에서 Windows 배포 서비스 설명서
• 기술 참조: Windows 배포 서비스(Windows Server 2008)

• 부팅 이미지: 일반적으로 Windows Server 2008 또는 Windows Vista SP1 설치 DVD에서 복사된 Windows PE 2.x를 포함하는 이미지입니다. 멀티캐스트를 사용하는 경우 부팅 이미지로 Windows Server 2008의 \Sources\Boot.wim 파일을 사용할 수 있습니다(Windows Vista 또는 레거시 운영 체제를 배포하는 경우에도 해당). 부팅 이미지는 대개 Windows PE, Windows Setup.exe 및 기타 종속 구성 요소로 구성됩니다.
• 설치 이미지: 일반적으로 Windows Vista 또는 Windows Server 2008의 \Sources\Install.wim 파일인 Windows OS 이미지로 구성됩니다. 기본 부팅 이미지 또는 기본 설치 이미지를 추가하는 단계는 거의 동일합니다. 이미지 유형을 마우스 오른쪽 단추로 클릭하고 해당 유형의 이미지를 추가하도록 선택하여 각 프로세스를 시작합니다. 설치 이미지의 경우 이미지 그룹 이름을 지정해야 합니다(Windows DVD의 기본 WIM에는 둘 이상의 OS 유형이 포함되어 있음). 그런 다음 추가하려는 해당 boot.wim 또는 install.wim으로 이동하고 열기를 클릭합니다. 설치 이미지의 경우 WDS 서버에 추가하지 않으려는 볼륨 이미지(OS 이미지)의 선택을 취소할 수 있습니다. 마지막으로 이러한 기본 이미지를 사용하여 클라이언트에 대해 PXE-install을 수행할 수 있습니다.
  
  캡처 이미지
  사용자 지정 OS 이미지를 만들려면 캡처 이미지(Windows 시스템을 WIM 이미지로 캡처할 수 있도록 설계된 Windows PE 이미지)를 만들어야 합니다. 가장 쉬운 방법은 이전에 설치한 boot.wim 이미지를 사용하는 것입니다. 원하는 이미지를 마우스 오른쪽 단추로 클릭하고 캡처 부팅 이미지 만들기를 클릭합니다. 이미지에 대해 사용할 이름과 설명을 지정하고, 캡처 이미지를 배포할 때 네트워크 연결 문제 발생을 대비하여 .wim 파일의 로컬 복사본을 저장할 위치를 지정합니다. 그런 다음 마법사의 지시에 따라 완료하고 마침을 클릭합니다. 이제 WDS MMC에서 Boot Image 폴더를 마우스 오른쪽 단추로 클릭하고 부팅 이미지 추가를 클릭합니다. 이전과 같이 마법사의 지시를 따릅니다. 작업을 마쳤으면 Windows 설치 이미지를 캡처할 준비가 완료된 것입니다.
  
  캡처 101
  운영 체제 이미지를 캡처하기 전에 물론 Windows를 설치하고 원하는 모든 응용 프로그램, 사용자 지정 및 업데이트가 포함되도록 해야 합니다. 다음으로 해야 할 일은 시스템에서 Sysprep를 실행하는 것입니다. Sysprep로 준비된 시스템에서만 Windows 설치 이미지를 캡처할 수 있기 때문입니다. 손상 가능성을 방지하기 위해 새 이미지 및 *.wim 확장명을 저장할 유효한 로컬 위치를 지정해야 합니다. 시스템을 구성하고 올바른 버전의 sysprep.exe를 시스템에 복사했으면 다음 단계를 따라야 합니다.

1. 참조 컴퓨터에 있는 명령 프롬프트에서 sysprep.exe가 있는 디렉터리로 변경합니다.
2. Sysprep를 시작합니다(sysprep.exe를 두 번 클릭하고 수동으로 옵션을 지정하여 시작할 수도 있음). Windows Vista 또는 Windows Server 2008을 실행하는 컴퓨터의 경우 sysprep /oobe /generalize /reboot 명령을 실행합니다. 이전 버전의 Windows를 실행하는 컴퓨터의 경우 sysprep -mini –reseal –reboot를 실행합니다.
3. 컴퓨터가 다시 시작되면 PXE 부팅합니다(이 프로세스는 클라이언트 시스템에 따라 다를 수 있음).
4. 부팅 메뉴에서 WDS 캡처 이미지를 선택하고 다음을 클릭합니다.
5. 이미지에 대한 드라이브 및 이름과 설명을 선택합니다.
6. 설명한 대로 Sysprep로 준비된 시스템만 보입니다. 이것은 계획적으로 설정된 것으로 우회할 수 있는 방법은 없습니다.
7. 찾아보기를 클릭한 다음 캡처된 설치 이미지를 저장할 로컬 폴더로 이동합니다. 매핑된 네트워크 드라이브를 선택할 수도 있습니다.
8. WDS 서버에 이미지 업로드를 선택합니다.
9. WDS 서버의 이름을 입력한 다음 연결을 클릭합니다.
10. 이미지 그룹 목록에서 이미지를 저장할 이미지 그룹을 선택한 다음 마침을 클릭합니다. 이 이미지는 이제 WDS 서버에서 배포할 준비가 되었습니다. 그런데 이쯤에서 RIS 전문가의 지적이 있을 수 있습니다. 여기에서는 이 Windows 이미지를 라이브로 캡처하지 않았기 때문입니다. WDS의 경우 캡처되는 시스템이 오프라인 상태여야 합니다. RIS의 경우 RIPrep는 온라인 시스템을 캡처할 수 있었습니다(사실, 그렇게 해야만 했습니다). 이 프로세스는 매우 불안정했습니다. WDS의 캡처 프로세스가 비교적 쉽고 더 강력하다는 사실을 알 수 있습니다.
    
    이미지 마이그레이션
    RIS를 사용한 적이 있다면 사용했던 이미지가 있을 것입니다. RISetup 기반 이미지(스크립트 설치)의 수명은 끝났습니다. 하지만 RIPrep 이미지를 WDS WIM 기반 이미지로 마이그레이션할 수 있습니다. 사실, WDS에서는 WDSUtil을 통한 이미지 마이그레이션도 가능합니다(다음 달에 자세히 설명할 예정). 일반적으로 이 작업은 이미지에 많은 시간과 노력을 투자했고 이를 잃고 싶지 않은 경우에만 수행하는 것이 좋습니다. 프로세스는 비교적 잘 수행되지만, 변환 중 오류가 약간 발생할 수도 있습니다. 그러면 이미지를 처음부터 다시 만들어야 합니다.
    
    무인 설치
    앞에서 설명한 대로 이미지를 만들면 수동으로 설치할 수 있는 이미지가 만들어집니다. 더 자동화되거나 완전히 자동화된 설치를 위해서는 두 가지 무인 설치 파일을 사용해야 합니다. WDS 자체에는 WDS 설치 프로세스를 자동화하는 응답 파일(WDS 서버의 \RemoteInstall\WDSClientUnattend 디렉터리에 있는 unattend.xml)이 필요합니다. 두 번째 파일은 실제 이미지 unattend 파일입니다. Windows Vista 및 이후 버전의 경우 unattend.xml 파일에 해당됩니다. 이전 버전 Windows 이미지의 경우 $OEM$ 디렉터리 구조 또는 각 이미지 디렉터리의 \Unattend에 있는 sysprep.inf 파일입니다. 이 파일은 WDS가 완료된 후 Windows의 실제 설치를 자동화하는 데 사용됩니다. WDS Unattend 파일을 만들려면 WAIK를 사용하여 WDS에 대한 unattend.xml을 만듭니다. 이 파일을 RemoteInstall 디렉터리나 하위 디렉터리에 복사합니다. unattend 파일을 사용하려는 설치 이미지를 마우스 오른쪽 단추로 클릭하고 속성을 클릭합니다. 클라이언트 탭에서 무인 설치 사용을 선택하고 앞에서 지정한 unattend.xml 파일을 지정합니다. Windows Vista 이전 버전의 이미지에 대해 이미지 unattend 파일을 만들려면 sysprep.inf 파일을 이미지의 $OEM$ 디렉터리에 복사합니다(예: D:\RemoteInstall\Images\Windows XP\SP2\$OEM$\$1\sysprep\sysprep.inf). Windows Vista 이미지의 경우 연결할 이미지를 지정하고 속성을 클릭한 다음 일반 탭에서 무인 모드에서 이미지 설치 허용을 클릭합니다. 그런 다음 설치에 사용할 unattend.xml 파일을 지정합니다. 이제 절반 정도 진행되었습니다. 이 칼럼을 통해 WDS를 구성하고 실행할 수 있게 되었습니다. 다음 달에는 WDSUtil, 이미지 저장소 특성 및 멀티캐스트에 대해 자세히 다룰 예정입니다. 그런 다음 WDS을 기반으로 사용자 지정 배포 솔루션 구현을 고려해야 하는 이유와 그 방법에 대해 자세히 설명하면서 이번 시리즈를 마무리할 예정입니다. 그 때까지 이 칼럼과 함께 제공되는 "WDS에 대한 추가 정보" 추가 기사를 살펴보십시오.

월요일 아침에 출근했더니 한 직원이 서버 속도가 너무 느리다고 불평을 합니다. 이를 위해 무엇부터 시작하시겠습니까? 성능 모니터는 Windows®에 기본적으로 포함되어 있는 편리한 도구로서, 문제를 진단하도록 도와 줍니다.

성능 모니터는 명령 프롬프트에서 perfmon을 입력하거나 관리 도구 메뉴에서 성능 또는 안정성 및 성능 모니터(Windows Vista® 및 Windows Server® 2008의 경우)를 선택하여 열 수 있습니다. 모니터링할 성능 카운터 및 개체를 추가하려면 더하기 기호를 클릭하고 선택 가능한 항목 중에서 선택하기만 하면 됩니다.

그렇다면 서버의 성능을 어떻게 측정하겠습니까? 60개 이상의 기본 성능 개체가 있으며, 각 개체에는 여러 카운터가 포함되어 있습니다. 이 문서에서는 서버의 중요한 상태를 나타내는 카운터를 소개하고, Microsoft® Service Support 엔지니어가 성능 관련 문제를 해결하는 데 가장 많이 사용하는 일반적인 샘플링 간격에 대해 설명합니다.

물론 기준은 문제 해결 시 참조할 수 있는 참조 포인트를 제공합니다. 서버 부하는 업무 요구 사항에 따라 달라지고 업무 주기별 시간마다 바뀌므로 일정 기간 동안 표준 작업 부하로 결정된 기준을 설정하는 것이 중요합니다. 이를 통해 변동 사항을 주시하고 추세를 파악할 수 있습니다.

더욱 신뢰할 수 있는 결과 생성

서버의 중요한 상태를 나타내는 카운터를 본격적으로 설명하기 전에 성능 모니터를 사용하여 서버의 주요 상태를 쉽게 측정할 수 있는 두 가지 팁을 소개하겠습니다. 이러한 팁은 Windows Vista 및 Windows Server 2008에서는 필요하지 않지만, 이전 버전의 Windows에서 성능 모니터를 실행하는 경우 매우 유용할 수 있습니다.

첫째, 추세 선의 그래픽 보기를 방해하는 모든 샘플 요소를 제거할 수 있습니다. Windows Vista 및 Windows Server 2008의 경우 성능 모니터는 그래픽 보기에 최대 1000개의 데이터 포인트를 표시할 수 있습니다. 이전 버전의 Windows에서는 최대 100개의 데이터 포인트로 제한됩니다. 100개가 넘는 데이터가 있을 경우 성능 모니터는 데이터 포인트를 버킷화합니다. 하나의 버킷은 버킷에 포함된 샘플 포인트의 최소값, 평균 및 최대값을 나타내는 수직선으로 표시됩니다.

그림 1의 그래프를 보면 알 수 있듯이 너무 많은 데이터가 동시에 표시되면 추세 선을 파악하기가 어렵습니다. 그림 2 그래프는 불필요한 모든 시각적 정보를 없앨 경우 얼마나 간편하고 쉽게 데이터를 파악할 수 있는지를 보여 줍니다. 이러한 수직선이 표시되지 않도록 하는 방법에 대한 자세한 내용은 support.microsoft.com/kb/283110 기술 자료 문서를 참조하십시오.

그림 1 쉼표 없이 산만한 버킷으로 표시된 성능 데이터(크게 보려면 이미지 클릭)

그림 2 쉼표로 구분되어 보기 좋은 데이터(크게 보려면 이미지 클릭)

두 번째 팁은 숫자에 쉼표 구분 기호를 추가하여 카운터에 표시된 값을 더 쉽게 읽을 수 있도록 하는 것입니다. Windows Vista 및 Windows Server 2008에서는 기본적으로 쉼표 구분 기호가 사용됩니다. 하지만 이전 버전의 Windows의 경우 성능 모니터에서 기본적으로 쉼표를 사용하지 않습니다.

별다른 차이가 없을 것처럼 느껴지지만, 쉼표 없이 성능 카운터를 표시하는 그림 1과 쉼표를 사용하여 카운터를 표시하는 그림 2를 비교해 보십시오. 두 번째 그림이 더 읽기 쉽다는 것을 알 수 있습니다. Windows XP에서 성능 카운터에 쉼표 구분 기호를 추가하는 방법은 support.microsoft.com/kb/300884 기술 자료 문서를 참조하십시오.

측정 대상 및 시기

리소스가 한도에 도달할 경우 전체 시스템 성능이 느려질 수 있는 병목 현상이 발생합니다. 병목 현상은 대체로 리소스 부족이나 잘못된 구성, 구성 요소 오작동 및 리소스에 대한 프로그램의 잘못된 요청 등으로 인해 발생합니다.

병목 현상을 유발하고 서버 성능에 영향을 줄 수 있는 주요 리소스 영역은 물리적 디스크, 메모리, 프로세스, CPU, 네트워크 등의 5가지입니다. 이러한 리소스가 과도하게 사용되면 서버 또는 응용 프로그램이 현저하게 느려지거나 충돌이 발생할 수 있습니다. 이 문서에서는 이러한 5가지의 각 영역에서 사용해야 하는 카운터에 대해 소개하고 서버의 상태를 측정하는 데 권장되는 임계값을 제공합니다.

샘플링 간격은 로그 파일의 크기 및 서버 부하에 많은 영향을 주므로, 문제가 다시 발생하기 전에 기준을 설정할 수 있도록 문제가 발생하는 데 걸리는 평균 기간을 기준으로 샘플 간격을 설정해야 합니다. 그러면 문제로 이어지는 경향을 파악할 수 있습니다.

일반적인 작업 중 기준을 설정하기 위한 권장 시간은 15분입니다. 문제가 발생하는 데 걸리는 평균 시간이 약 4시간이라면 샘플 간격을 15초로 설정합니다. 문제가 발생하는 데 걸리는 시간이 8시간 이상이라면 샘플링 간격을 5분 이상으로 설정합니다. 그렇지 않으면 로그 파일이 너무 커져서 데이터를 분석하는 데 어려울 수 있습니다.

하드 디스크 병목 현상

디스크 시스템은 서버에서 프로그램 및 데이터를 저장하고 처리하므로 디스크 사용량 및 속도에 영향을 미치는 병목 현상은 서버의 전체적인 성능에 큰 영향을 줍니다.

디스크 개체가 서버에서 비활성화된 경우 명령줄 도구 Diskperf를 통해 활성화해야 합니다. 또한 % Disk Time은 100%를 초과할 수 있으므로 대신 % Idle Time, Avg. Disk sec/Read 및 Avg. Disk sec/write를 사용하면 하드 디스크가 얼마나 많이 사용되고 있는지 좀더 정확하게 파악할 수 있습니다. % Disk Time에 대한 자세한 내용은 support.microsoft.com/kb/310067 기술 자료 문서를 참조하십시오.

다음은 Microsoft Service Support 엔지니어가 디스크 모니터링을 위해 사용하는 카운터입니다.

LogicalDisk\% Free Space 선택한 논리 디스크 드라이브에서 사용할 수 있는 공간의 백분율을 측정합니다. 이 카운터가 15% 아래로 떨어지면 OS에서 중요 파일을 저장하기 위한 여유 공간이 부족할 수 있습니다. 이 경우 확실한 해결책은 디스크 공간을 늘리는 것입니다.

PhysicalDisk\% Idle Time 샘플 간격 중 디스크가 유휴 상태였던 시간 백분율을 측정합니다. 이 카운터가 20% 아래로 떨어지면 디스크 시스템이 포화 상태인 것입니다. 현재 디스크 시스템을 더 빠른 디스크 시스템으로 교체하는 것이 좋습니다.

PhysicalDisk\Avg. Disk Sec/Read 디스크에서 데이터를 읽는 데 걸리는 평균 시간(초)을 측정합니다. 값이 25ms(밀리초)보다 크면 디스크에서 읽을 때 디스크 시스템에 지연 현상이 발생하고 있음을 의미합니다. SQL Server® 및 Exchange Server를 호스팅하는 중요 업무 서버의 경우 허용 가능한 임계값은 10ms 미만입니다. 여기에서 가장 현명한 해결책은 현재 디스크 시스템을 더 빠른 디스크 시스템으로 교체하는 것입니다.

PhysicalDisk\Avg. Disk Sec/Write 디스크에 데이터를 쓰는 데 걸리는 평균 시간을 측정합니다. 이 시간이 25ms보다 크면 디스크에 쓸 때 디스크 시스템에 지연 현상이 발생하고 있음을 의미합니다. SQL Server 및 Exchange Server를 호스팅하는 중요 업무 서버의 경우 허용 가능한 임계값은 10ms 미만입니다. 여기에서 현명한 해결책은 디스크 시스템을 더 빠른 디스크 시스템으로 교체하는 것입니다.

PhysicalDisk\Avg. Disk Queue Length 얼마나 많은 I/O 작업이 하드 드라이브를 사용할 수 있을 때까지 대기하고 있는지 나타냅니다. 여기에서 값이 스핀들 수 + 2보다 크면 디스크 자체에 병목 현상이 있음을 의미합니다.

Memory\Cache Bytes 파일 시스템 캐시에 사용되고 있는 메모리의 양을 나타냅니다. 이 값이 200MB보다 크면 디스크 병목 현상이 발생할 수 있습니다.

메모리 병목 현상

메모리 부족은 대체로 RAM 부족, 메모리 누수 또는 boot.ini의 메모리 스위치 등으로 인해 발생합니다. 메모리 카운터를 소개하기 전에 먼저 /3GB 스위치에 대해 설명하겠습니다.

메모리가 많을수록 디스크 I/O 작업이 줄고 응용 프로그램 성능이 높아집니다. /3GB 스위치는 사용자 모드 프로그램에 더 많은 메모리를 제공하기 위한 방법으로 Windows NT®에서 도입되었습니다.

Windows에서는 4GB의 가상 주소 공간을 사용하며 이는 시스템의 물리적 RAM과는 무관합니다. 기본적으로 하위 2GB는 사용자 모드 프로그램을 위해 사용되고, 상위 2GB는 커널 모드 프로그램을 위해 사용됩니다. /3GB 스위치를 사용하면 사용자 모드 프로세스에 3GB가 제공됩니다. 그러면 물론 커널 메모리가 가상 주소 공간의 1GB만 남게 되므로 영향을 받습니다. 이 경우 페이징되지 않은 바이트 풀링, 페이징된 바이트 풀링, 사용 가능한 시스템 페이지 테이블 항목 및 데스크톱 힙이 모두 이 1GB 공간 안에 들어가야 하므로 문제가 발생할 수 있습니다. 따라서 /3GB 스위치는 해당 환경에서 충분한 테스트를 거친 후에만 사용해야 합니다.

메모리 관련 병목 현상이 발생하는 경우 이 스위치를 의심해 볼 수 있습니다. /3GB 스위치가 문제의 원인이 아니라면 다음 카운터를 사용하여 잠재적인 메모리 병목 현상을 진단할 수 있습니다.

Memory\% Committed Bytes in Use 커밋된 바이트와 커밋 한도의 비율, 즉 가상 메모리의 사용량을 측정합니다. 이 값이 80%보다 크면 메모리가 부족함을 나타냅니다. 이 경우 확실한 해결책은 메모리를 추가하는 것입니다.

Memory\% Available Mbytes 프로세스 실행을 위해 사용할 수 있는 실제 메모리의 양(메가바이트)을 측정합니다. 이 값이 총 물리적 RAM의 5%보다 작으면 메모리가 부족함을 나타내며 이로 인해 페이징 작업이 늘어날 수 있습니다. 이 문제를 해결하려면 메모리를 추가해야 합니다.

Memory\Free System Page Table Entries 시스템에서 현재 사용되지 않는 페이지 테이블 항목의 수를 나타냅니다. 이 숫자가 5,000보다 작으면 메모리 누수가 있을 수 있습니다.

Memory\Pool Non-Paged Bytes 페이징되지 않은 풀의 크기(바이트)를 측정합니다. 디스크에 쓸 수 없고 대신 실제 메모리에 남아 있어야 하는 할당된 개체에 대한 시스템 메모리 영역입니다. 이 값이 175MB(또는 /3GB 스위치의 경우 100MB)보다 크면 메모리 누수 가능성이 있습니다. 일반적인 이벤트 ID 2019가 시스템 이벤트 로그에 기록됩니다.

Memory\Pool Paged Bytes 페이징된 풀의 크기(바이트)를 측정합니다. 사용되고 있지 않을 때 디스크에 쓸 수 있는 개체에 대한 시스템 메모리 영역입니다. 이 값이 250MB(또는 /3GB 스위치의 경우 170MB)보다 크면 메모리 누수 가능성이 있습니다. 일반적인 이벤트 ID 2020이 시스템 이벤트 로그에 기록됩니다.

Memory\Pages per Second 하드 페이지 결함을 해결하기 위해 디스크에서 페이지를 읽거나 쓰는 속도를 측정합니다. 과도한 페이징으로 인해 이 값이 1,000보다 크면 메모리 누수 가능성이 있습니다.

프로세서 병목 현상

프로세서 병목 현상은 프로세서 자체의 성능이 나빠서 발생하거나 비효율적인 응용 프로그램으로 인해 발생할 수 있습니다. 실제 메모리 부족으로 인해 프로세서가 페이징에서 많은 시간을 보내지 않는지 다시 확인해야 합니다. 잠재적인 프로세서 병목 현상을 조사할 때 Microsoft Service Support 엔지니어는 다음 카운터를 사용합니다.

Processor\% Processor Time 프로세서가 비유휴 스레드 실행에 소비하는 경과 시간의 백분율을 측정합니다. 이 백분율이 85%보다 크면 프로세서에 병목 현상이 발생하고 서버에 더 빠른 프로세서가 필요할 수 있습니다.

Processor\% User Time 프로세서가 사용자 모드에서 소비하는 경과 시간의 백분율을 측정합니다. 이 값이 높으면 서버에서 응용 프로그램이 많이 실행되고 있음을 나타냅니다. 한 가지 가능한 해결책은 프로세서 리소스를 많이 사용하는 응용 프로그램을 최적화하는 것입니다.