The Desktop Files: Deploying Windows in a Virtual World

아티클
08/24/2016

The Desktop Files가상 세계에서의 Windows 배포

Wes Miller

가상 컴퓨팅은 모든 곳에 존재합니다. 아직 가상 컴퓨팅을 활용하고 있지 않다면 지금부터라도 활용하는 것이 좋습니다. 가상화는 기본적으로 고유의 하드웨어 추상 계층을 생성하여 Windows Server 또는 Windows 클라이언트 운영 체제 등과 같은 여러 게스트 시스템을 호스트 시스템 사이에서 옮길 수 있게 함으로써 하드웨어 의존성을 줄여줍니다.

물론, 가상화는 게스트의 프로세서를 흉내 내는 것이 아니라는 점에서 에뮬레이션과는 다릅니다. 가상화는 단순히 호스트 시스템의 리소스를 게스트 시스템에서 액세스할 수 있는 방식으로 표시할 뿐입니다. 따라서 게스트 시스템은 호스트 시스템을 일반 시스템처럼 사용할 수 있습니다. 즉, 특정 OEM이 제작한 시스템에서 다른 OEM이 제작한 시스템으로 가상 게스트를 옮길 수 있으며, 이때 일반적으로 호스트의 하드웨어는 문제가 되지 않습니다. 그러나 몇 가지 유의할 점이 있습니다. 예를 들어 AMD CPU 공급업체의 프로세서를 사용하는 하드웨어에서 Intel의 CPU 프로세서를 사용하는 하드웨어로 게스트를 옮길 경우에는 사용 중인 가상화 기술에 따라 문제가 발생할 수 있습니다. 이러한 문제는 가상 컴퓨팅 기술이 호스트와 게스트 사이에 정보만 전달하기 때문입니다. 즉, PowerPC 기반 Macintosh에서 실행되는 Microsoft® Virtual PC의 경우처럼 게스트의 특정 CPU를 에뮬레이트하지는 않습니다.

다만 가상화는 주요 하드웨어 구성 요소를 게스트로 에뮬레이트합니다. 대부분의 경우, 이러한 에뮬레이션은 네트워킹, 비디오(일반적으로 에뮬레이트된 고급 GPU를 포함하지 않는 매우 제한된 장치), 대용량 저장 장치 등으로 한정됩니다. 이는 모두 여러 유형의 소프트웨어적으로 에뮬레이트된 장치를 게스트에 제공하는 방식으로 기능합니다. 필자가 작성한 칼럼을 오래전부터 읽어왔다면 이러한 장치들이 Windows® PE에서 관리하는 장치들과 같다는 점을 파악하실 것입니다. 가상화에서 그러한 장치들은 Windows에서 원하는 작업을 실제로 처리하기 위해서 반드시 갖춰야 하는 유형의 장치들입니다. 또한 모든 가상화 기술은 반드시 BIOS를 에뮬레이트해야 합니다. 가상화 기술은 또한 EFI(Extensible Firmware Interface)를 에뮬레이트할 수 있지만 현재 EFI 기반 운영 체제를 선택하는 경우는 극히 드물므로 활용도 또한 낮습니다. 이러한 모든 에뮬레이션을 통해 가상 게스트의 부팅이 가능해집니다. BIOS와 각 장치는 실제 장치를 소프트웨어적으로 에뮬레이트하여 게스트에 제공합니다. 이는 에뮬레이트된 장치들도 실제 장치들에 필요한 드라이버와 동일한 드라이버(Windows에서 제공하는 드라이버가 아닐 수도 있음)를 필요로 함을 의미합니다. 이 개념은 반드시 기억해둬야 합니다.

일부 가상화 기술에서는 USB 또는 USB 2.0 장치와의 연결도 가능하지만 여기에서는 자세히 다루지 않겠습니다. 그와 같은 USB 장치에 드라이버(프린터, USB 무선 NIC 등) 또는 일부 DirectX® 지원(대부분의 가상화 기술에서는 일반적으로 제공하지 않음)이 필요하다는 점을 제외하면, 그 작동에 있어 반드시 필요한 요건은 그리 많지 않습니다. 물론, USB 또는 기타 에뮬레이트되지 않는 장치에 대한 지원은 사용 중인 가상화 기술에 따라 다르다는 점을 유념해야 합니다. 새로운 장치를 함께 사용하기 전에 현재 사용 중인 가상화 제품의 한계(분명한 경계)를 반드시 알고 있어야 합니다.

현재 Windows에 대한 주요 가상화 기술 공급업체는 Microsoft와 VMware(vmware.com)입니다. 그리고 Parallels(parallels.com)와 같은 새롭고 유망한 공급업체들도 있습니다.

지금까지 가상화의 핵심적인 개념을 설명했으므로 이제부터는 가상화를 설정하는 방법, 흔히 발생하는 문제를 방지하는 방법, 사용자 환경의 여러 시스템에 가상화를 배포하는 방법에 대해 설명하겠습니다.

가상 배포

가상 시스템의 배포가 물리적 시스템의 배포와 꼭 달라야 할 이유는 없습니다. 그러나 곧 설명하겠지만 두 배포 방식이 서로 달라지는 중요한 이유들이 몇 가지 있습니다.

Windows NT® 초기 시절에는 설치 과정을 거쳐 배포해야 했습니다. 스크립트 처리도 가능했지만, 어쨌든 전체 과정을 거쳐야 했습니다. 설치한 후 해당 이미지를 여러 시스템에 복사하는 작업은 매우 편리한 개념이지만 전혀 지원되지 않았습니다.

그러나 마침내 Microsoft는 Windows NT 시스템의 디스크 복제를 지원하는 것이 합리적이라는 결정을 내렸습니다. 따라서 오늘날에는 물리적 시스템 배포에 활용할 수 있는 모든 방법을 가상 시스템 배포에도 적용할 수 있습니다. 따라서 Winnt32(또는 Windows Vista®와 Windows Server® 2008의 경우 setup.exe), Windows PE(1.x 또는 2.x, 이전 칼럼에서 설명한 것처럼 배포 중인 클라이언트에 따라 다름), RIS(원격 설치 서비스) 또는 WDS(Windows 배포 서비스), 또는 Sysprep(Windows NT 4.0에 도입된 배포를 위한 시스템 준비 도구) 및 선호하는 디스크 복제 기술(예: ImageX)을 사용할 수 있습니다.

그러나 물론, 그러한 작업은 특정 OS를 처음 배포할 때만 필수적입니다. 그 후에는 그냥 복사만 하기를 원할 수도 있을 것입니다. 그러나 제가 방금 언급한 것과 같은 디스크 기반 복제 방법에는 문제가 하나 있습니다.

Sysprep 사용

애초에 Microsoft에서 디스크 기반 복제를 지원하지 않기로 결정하게 된 데에는 Windows NT SID(보안 식별자)가 주된 요인으로 작용했습니다. 다행히 Sysprep을 통해 그 문제를 해결할 수 있습니다. 먼저 이 문제부터 살펴보겠습니다. support.microsoft.com/kb/314828에서 설명했듯이 SID는 개별 Windows 기반 컴퓨터를 식별하는 SID 구조 수정 번호(일반적으로 GUID)로 이루어집니다. 그리고 이 ID는 모든 로컬 계정에 대한 식별자의 루트 부분으로 사용됩니다. 로컬 계정은 RID(상대 식별자)라는 자체 고유 식별자를 가집니다. RID는 SID의 끝에 계정 ID가 연결되는 방식으로 구성됩니다. 따라서 두 ID의 조합이 로컬 계정의 ID가 됩니다.

이것이 왜 문제가 되는지는 Administrator SID S-1-5-21-191058668-193157475-1542849698-500을 예로 들어 설명하겠습니다. 여기서 S-1-5는 SID를 나타내는 설명자(S는 SID의 텍스트 표현의 대표 문자)이며 1과 5는 각각 Windows NT SID 수정 번호와 인증 기관 ID 값(여기서는 Windows Security)을 나타냅니다. 잘 알려진 Windows Administrator 계정 SID를 나타내는 500을 포함하여 나머지가 실제 SID입니다. 모든 Windows 설치에서 기본적으로 생성되며 삭제할 수 없는 Administrator 계정은 500으로 끝나는 SID를 가집니다. 설치 후 Windows에 추가되는 로컬 사용자 계정은 1000 이상 번호의 SID를 가집니다.

Windows Sysinternals에서 제공되는 PSGetSID를 사용하면 시스템의 특정 사용자 SID나 시스템의 SID를 열거할 수 있습니다. Windows Sysinternals는 PSTools에 관해 필자가 작성한 칼럼(technetmagazine.com/issues/2007/03/DesktopFiles)에 설명되어 있습니다. 그림 1에는 PSGetSID에서 필자의 가상 시스템 SID와 사용자 계정 SID인 1003이 출력된 결과가 나와 있습니다.

그림 1 가상 시스템 SID 및 사용자 계정 SID인 1003에 대한 PSGetSID의 출력

그림 1** 가상 시스템 SID 및 사용자 계정 SID인 1003에 대한 PSGetSID의 출력 **(더 크게 보려면 이미지를 클릭하십시오.)

로컬 계정 RID가 이 SID에 기반을 두므로 시스템을 디스크 복제하거나 가상 시스템 이미지를 복사할 때 어떤 문제가 발생할지는 쉽게 예상할 수 있습니다. Sysprep에는 여러 유용한 기능이 많지만 주요 기능인 SID를 유지하는 기능을 통해 Windows 시스템이 고유하게 유지되는 주요 구성 요소 사본을 얻을 수 있습니다. 시스템 A와 시스템 B의 Administrator SID가 같다면 각 시스템의 사용자가 스스로를 같은 사용자로 아무 문제없이 식별할 것입니다. 시스템 A와 B의 모든 로컬 계정이 상대 시스템에 자신을 인증할 때도 같은 원칙이 적용됩니다. 더욱 문제가 되는 것은, 이 시스템들이 Active Directory®에 제공될 때도 같은 SID를 갖는다는 점입니다. 따라서 시스템 A에는 도메인 리소스에 대한 인증을 허용하되 시스템 B에는 허용하지 않을 경우 충돌이 발생하게 됩니다. B를 거절하도록 설정할 경우, 실제로는 A 역시 거절될 것입니다.

따라서 Sysprep을 사용하여 시스템의 SID를 재생성하는 것이 매우 중요합니다. 특히 시스템 이미지를 아주 쉽게 전파할 수 있는 가상 시스템 시나리오에서는 반드시 그렇게 해야 합니다. 또한 타사의 SID 변경 도구가 아닌, 오직 Sysprep만 사용해야 합니다. Sysprep은 가상 시스템을 포함한 시스템 복제 준비 용도로 Microsoft에서 설계, 테스트, 지원하는 도구입니다. 그림 2에는 시스템의 SID를 변경하기 전 Sysprep의 모습이 예로 나와 있습니다. 다음 단계에 시스템이 복제되도록 준비하는 경우라면 "Don't regenerate security identifiers(보안 식별자를 다시 생성하지 않음)" 옵션은 항상 해제되어 있어야 합니다.

그림 2 복제를 준비하는 경우 해제되어 있어야 하는 "Don't regenerate security identifiers" 옵션

그림 2** 복제를 준비하는 경우 해제되어 있어야 하는 "Don't regenerate security identifiers" 옵션 **

또한 Sysprep은 SID를 새로운 ID로 업데이트할 뿐만 아니라 SID와 컴퓨터 이름을 반영하고 새로운 SID에 맞게 암호화를 변경하도록 인식되는 모든 개인 데이터 저장소를 수정합니다. IIS 메타베이스의 예약된 작업 데이터 저장소와 값(IIS가 설치된 경우)을 예로 들 수 있습니다.

Sysprep은 또한 시스템의 모든 NIC를 강제로 삭제하고 네트워크 구성 데이터로 대체합니다. 네트워크 구성으로 인해 레지스트리에서 NIC가 삭제되고, 해당 NIC의 관계는 NIC의 하드웨어 ID를 기반으로 하므로(가상 시스템에서 가상 시스템으로 이동하는 경우 외에는 깨질 경우가 많음) Sysprep은 이러한 일반적으로 버려진 데이터를 지웁니다.

Sysprep은 또한 시스템에서 모든 Active Directory 구성원 정보를 지웁니다. 따라서 그 작업 과정에서 불가피하게 시스템을 도메인에서 제거해야 합니다. 이를 통해 방금 새로운 SID를 받은 시스템을 도메인에 안전하게 가입시킬 수 있습니다. 일부 SID 변경 유틸리티에서는 시스템을 도메인에서 제거하지 않고 SID를 변경할 수 있지만 이 방식은 안정적이지 않으며 안전하지도 않습니다. 도메인 구성원인 컴퓨터에서 반드시 Sysprep을 실행해야 하는 상황이라면 Sysprep을 실행하기 전에 도메인에서 컴퓨터를 제거하거나 Sysprep을 실행하여 대신 처리하도록 하십시오.

DC(도메인 컨트롤러)를 가상화하는 경우 이와 관련하여 유념해야 할 한 가지 사항은 DC로 승격되지 않았으며 도메인에 가입되지 않은 독립 실행형 서버 시스템은 복제해야 한다는 것입니다. Windows Server 2003 Small Business Server Edition을 제외하고는 DC를 안전하게 디스크 복제할 수 없습니다. 새로운 DC를 안전하게 만들려면 도메인에 가입되고 DC로 승격될 준비가 된 서버의 디스크 이미지를 만들어야 합니다. 단일 포리스트/단일 서버인 매우 특수화된 SBS 인스턴스의 경우를 제외하고 Sysprep은 DC의 SID를 안전하게 변경하는 방법을 알지 못합니다.

마지막으로 Sysprep은 SID를 변경하고 도메인에서 시스템을 제거하는 작업 외에도 시스템의 이름을 변경합니다.

가상 시스템의 이미지를 생성하거나 단순히 복사하는 경우에도 위의 작업을 모두 수행해야 한다는 것은 다소 부담스럽게 들릴 수도 있습니다. 그러나 이러한 작업은, 특히 네트워크에서 같은 도메인에 속한 다른 물리적 또는 가상 시스템과 함께 또는 자신의 사본과 함께 이러한 시스템을 사용하는 경우에는 더욱 중요합니다.

가상 시스템을 복제할 때 Sysprep을 사용하지 않는다면 수많은 문제(Active Directory 또는 기타 네트워킹 충돌)가 발생할 것이 거의 확실하며, 그 가운데 상당수는 예상치 못한 문제일 것입니다. 예를 들어, 가상 이미지가 해킹에 매우 취약하게 됩니다. 하나가 해킹되면 다른 이미지에도 액세스가 허용될 것이기 때문입니다.

드라이버 및 하드웨어 추상화 계층

가상 이미지에 포함된 가상 장치는 Windows용 "기본 제공(in-box)" 드라이버를 갖고 있지 않을 수 있다고 언급한 바 있습니다. 따라서, 한 저장소 버스 드라이버에서 다른 저장소 버스 드라이버로 가상 이미지를 옮길 때 심각한 0x0000007B 드라이버 오류가 물리적 하드웨어를 다룰 때와 마찬가지로 쉽게 발생할 수 있으므로 배포 작업을 수행할 때 또는 Sysprep을 이용하여 디스크 이미지를 배포할 때는 장치에 맞는 드라이버를 항상 준비해 두어야 합니다. 이것은 NIC의 경우에도 마찬가지입니다. 대부분의 가상화 제품은 비교적 보편적인 가상 장치를 제공하고자 하지만 추가 드라이버는 여전히 필요할 것입니다.

복잡한 HAL(하드웨어 추상화 계층) 역시 무시할 수 없습니다. 가상화 기술에서 지원하여 ACPI(고급 구성 및 전원 인터페이스) 다중 프로세서(intel.com/technology/iapc/acpi 참조)를 지원하는 가상 시스템을 만들 수 있다면 이상적이겠지만, HAL 사이에서의 변환은 일반적으로 지원되지 않습니다(구체적인 내용은 support.microsoft.com/kb/309283 참조). 그러나 일부 가상화 기술이나 더욱 중요하게도 많은 마이그레이션 기술에서는 비 ACPI Windows 설치를 ACPI Windows 설치로, 그리고 그 반대로도 안전하게 옮길 수 있다고 주장합니다. 그것은 사실이 아니며 이렇게 설치된 Windows는 문제 발생 시 Microsoft에서 지원하지 않습니다. 앞에서 언급한 지원 웹 페이지에 나와 있는 제한 사항은 가상화된 시스템에도 똑같이 적용됩니다. 그림 3에는 ACPI 유니프로세서 HAL을 사용하여 실행되는 가상 시스템의 장치 관리자에서 HAL이 어떻게 표시되는지 예가 나와 있습니다. 이것은 다중 프로세서 시스템과 교환이 가능하므로 단일 프로세서와 혼동하지 말아야 합니다.

그림 3 가상 시스템의 장치 관리자에 표시된 HAL

그림 3** 가상 시스템의 장치 관리자에 표시된 HAL **(더 크게 보려면 이미지를 클릭하십시오.)

기타 변경 사항

변경할 수 있는 것은 변경하고 변경할 수 없는 것은 받아들일 것

물리적 시스템과 가상 시스템 사이의 마이그레이션을 고려할 때는 변경할 수 있는 것과 할 수 없는 것을 기억해야 합니다. Windows 설치에서 변경할 수 있는 사항은 다음과 같습니다.

HAL - 단, 유니프로세서와 다중 프로세서 사이에서 마이그레이션할 경우에만 가능하며, 이 경우에도 전원 구성은 동일하게 유지해야 합니다.
대용량 저장소 컨트롤러 - 쉽지는 않지만 대부분의 물리-가상 마이그레이션 솔루션에서는 이미 자체적으로 이를 시도하고 있습니다. 대부분의 공급업체에서는 IDE 및 SCSI 저장소 솔루션을 제공하고 있습니다. 한 시스템에서 다른 시스템으로의 이전이 그렇게 쉬운 것은 아니므로 배포 시 현명하게 선택하십시오. 일반적으로, SCSI를 선택하는 것이 장치 안정성이 더 높습니다. 대부분의 SCSI 장치 에뮬레이션 구현 시스템에서 그러합니다.
네트워크 컨트롤러 - 가상-가상 마이그레이션 시나리오에서는 같은 공급업체의 기술을 사용하는 경우에만 일반적으로 네트워크 컨트롤러가 동일한 것으로 처리됩니다.

Windows 설치에서 변경할 수 없는 사항은 다음과 같습니다.

HAL - 동일한 전원 구성을 사용하는 경우 위에서 언급한 경우를 제외하고는 변경이 불가능합니다. 변경이 가능한 마이그레이션 솔루션을 사용하여 변경하더라도 Windows 설치가 안정적이라고 간주해서는 안 됩니다. 게다가 이러한 설치는 Microsoft의 지원을 받을 수 없습니다.

SID와 컴퓨터의 이름 외에도, 사용 중인 가상 컴퓨팅 기술에 특정한 일부 값도 변경해야 합니다. 특히 MAC 주소(네트워크 장치의 고유 ID)를 변경해야 합니다. 또한 많은 가상 응용 프로그램 역시 고유 식별자를 갖고 있습니다. 대부분은 자체 컴퓨터 구성 파일에 이러한 정보를 저장하므로, 그 항목들을 조작하고 유효성을 유지하는 방법이 궁금할 것입니다. PXE(Pre-Boot eXecution Environment)를 지원하는 대부분의 가상화 제품들은 고유 ID를 기반으로 SMBIOS UUID를 조정하므로, 시스템을 도메인에 가입시키고자 한다면 고유 ID를 변경하거나, (지원될 경우) 가상화 소프트웨어에서 대신 변경하도록 할 필요성이 더 커집니다. 그렇지 않으면 GUID가 충돌하는 경우 WDS 또는 RIS 클라이언트 시스템을 관리하는 것이 불가능해질 수 있습니다. 필자가 다뤄본 가상화 솔루션의 대부분은 MAC 주소가 중복될 경우 심각한 네트워킹 문제를 일으킬 수 있으므로 가상 시스템을 단순히 옮기는 것이 목적이 아니라면, 가상화 소프트웨어에서 자동으로 지원하지 않을 경우에는 MAC 주소를 변경하는 것이 매우 중요합니다.

배포할 가상 시스템을 준비할 때 유념해야 할 다른 구성 요소로는 연결된 디스크 또는 스냅숏이 있습니다. 이들은 사용하는 가상화 솔루션에 따라 차등 디스크 또는 기타 다른 이름으로 불릴 수도 있습니다. 그러나 Sysprep을 실행하여 시스템을 준비하고 가상 시스템과 관련하여 스냅숏을 갖고 있거나 기타 되돌릴 수 있는 기술이 있다면 복제할 때 이미지의 안전성과 안정성, 보안성을 유지하기 위해 이들을 반드시 없애야 합니다. 스냅숏 또는 기타 "디스크 변경 취소" 기술을 활용하는 경우 스냅숏을 되돌리는 작업은 원본 가상 시스템을 기반으로 생성된 하나 이상의 시스템이 다른 시스템 또는 원본 소스 시스템과 충돌하는 상황으로 퇴행하는 것을 의미할 수 있습니다. 따라서 스냅숏 또는 차등 디스크가 관련된 경우에는 미리 Sysprep이 실행되도록 해야 합니다.

최적화

대부분의 가상화 기술에는 호스트에서 게스트와 상호 작용하는 성능과 환경을 개선하는 데 도움이 되는 가상 시스템 추가 기능 또는 도구가 있습니다. 여기에는 일반적으로 마우스 및 키보드 입력을 최적화하는 작업 등을 통해 성능을 향상시키며 복사 및 붙여넣기 또는 기타 호스트와 게스트 간의 상호 작용을 개선하는 기능이 포함됩니다. 배포 전에 가상 시스템에 이러한 도구의 최신 버전을 설치하십시오.

또한 클라이언트 메모리를 게스트 OS에 최적으로 구성하는 것뿐만 아니라 게스트 OS가 배포될 호스트의 환경에도 맞게 구성해야 합니다. 1GB의 RAM을 사용하도록 설정된 Windows XP 이미지를 그 정도의 RAM이 없는 호스트 시스템에 배포하는 상황은 원치 않을 것입니다.

또한 오늘날 대부분의 가상화 기술이 갖고 있는 한계도 기억해야 합니다. 사용자에게는 가상 시스템에 연결된 주변 기기와의 상호 작용 방식뿐만 아니라 게스트 OS에서 실행 가능한 응용 프로그램이 어느 것이냐 하는 문제(예를 들어 대부분 DirectX 9 또는 10을 지원하지 않거나 기존 버전을 제한적으로 지원함)도 중요하기 때문입니다. 사용자들은 이러한 문제가 무엇을 의미하는지 또는 어떤 식으로 드러나는지 모를 수 있습니다. 일부 응용 프로그램은 이러한 문제를 제대로 처리하지 못합니다.

호스트 문제

호스트에서 실행되는 것이 정식 운영 체제인지 아니면 하드웨어에서 직접 실행되는 Type 1 Hypervisor인지 하는 문제에 관계없이, 가상화 기술이 실행되는 호스트 PC와 관련해서는 신경 써야 할 일이 일반적으로는 그리 많지 않습니다. 대부분의 가상화 기술은 게스트 OS가 호스트를 전혀 또는 거의 알 필요가 없도록 설계됩니다. 그러나 한 호스트에서 다른 호스트로 옮겨진 게스트에 문제가 발생할 경우에 대비하여 어느 호스트가 사용되고 있는지는 파악해야 합니다. 또한 사용 중인 가상화 공급업체의 제품이 특정 플랫폼에서 어떠한 한계를 갖고 있는지도 알고 있어야 합니다. 한 호스트에서 다른 호스트로 옮길 수 있지만 그 과정에서 호스트 OS의 Type 2 Hypervisor(가상화 응용 프로그램)의 일부 기능을 잃거나 얻을 수도 있습니다.

기타 배포 메커니즘

추가 리소스