데스크톱 가상화: 가상 환경 보살피기

Wes Miller

가상화는 과거 생소하고 변칙적인 기술이었지만 이제는 대부분의 사람들에게 없어서는 안 될 실용적인 기술로 발전했습니다. 여러분은 품질 보증 테스트, 개발, 웹 디자인 또는 교육 등에 가상화를 사용 중일 수도 있습니다. 여러분은 가상 인프라를 배포하며 추세를 이끄는 선구자에 속하거나, Amazon.com, Rackspace Inc. 또는 다른 클라우드 공급업체의 “클라우드” 가상화를 사용하는 집단에 속할 수도 있습니다.

가상화를 어떤 방법으로 사용 중이든, 사용 기간에 관계없이 사용 경험이 있다면 실제 하드웨어를 유지 관리하는 일에 나름의 난관이 있듯이, 가상화에도 가상화만의 과제가 뒤따른다는 사실을 알고 있을 것입니다. 두 환경의 문제는 서로 다른 부분도 많지만 비슷한 부분도 있습니다.

하이퍼바이저 다루기

“하이퍼바이저”라는 용어를 들어본 적이 있을 것입니다. 하이퍼바이저는 요즘 가상화 분야에서 잘 나가는 용어지만 새로운 것은 아닙니다. VM(가상 컴퓨터)만큼이나 오래 전부터 사용되고 있는 용어입니다. 사실 IBM은 1970년대에 하이퍼바이저라는 용어를 만들었습니다.

하이퍼바이저는 일련의 가상화된 하드웨어를 갖춘 시스템에서 “가상으로” 실행되는 게스트를 제공하는 소프트웨어로, 게스트 OS를 위한 실제 하드웨어를 추상화합니다. 혼란이 발생한 것은 몇 년 전 x86 플랫폼에서 실행되는 “유형 1 하이퍼바이저”가 대대적으로 추진되면서부터입니다. 여기에는 Microsoft Hyper-V 및 VMware ESX Server가 포함됩니다. 대부분의 사람들이, 특히 클라이언트 시스템에 사용하는 하이퍼바이저는 “유형 2 하이퍼바이저”라고 합니다. 둘의 차이는 무엇일까요?

  1. 유형 1 하이퍼바이저는 호스트 하드웨어에서 직접 실행되며 “호스트 OS”를 필요로 하지 않습니다. Microsoft Hyper-V 및 VMware ESX Server가 유형 1 하이퍼바이저의 일반적인 예입니다.
  2. 유형 2 하이퍼바이저의 경우 작동을 위해 호스트 OS가 필요합니다. 일반적으로, 유형 2 하이퍼바이저는 호스트 OS에서 주로 사용자 모드 응용 프로그램으로 실행됩니다. Microsoft Virtual PC 및 VMware Workstation이 유형 2 하이퍼바이저의 일반적인 예입니다.

많은 경우 가상화된 SQL 또는 파일 서버와 같이 “항상 가동되는” 작업 부하에 대해서는 유형 1 하이퍼바이저가 선호됩니다. 적어도 유형 2보다는 리소스를 덜 사용하기 때문입니다. 그러나 호스트에 따라 시작하기 위해 사용자 로그온이 필요할 수 있는데, 이는 핵심 업무용 시스템에서는 적절한 옵션이 아닙니다. 반면 유형 2 하이퍼바이저는 “주문형” VM에 더 적합합니다. 이러한 역할 유형에는 테스트, 응용 프로그램 호환성 또는 보안 액세스를 위한 VM이 포함됩니다.

가상화로 무엇을 절약할 수 있는가?

뻔한 답은 가상화가 하드웨어 비용을 줄여 준다는 것이지만, 그렇게 단순하지 않습니다. 물론 랙 탑재형 1U 폼 팩터의 서버 시스템이 두 대가 있는데, 이 두 가지 동일한 작업 부하를 하나의 1U 시스템에 얹는다면 하드웨어 비용을 확실히 아낄 수 있습니다. 그러나 여기에는 함정이 있습니다. 동일한 이 두 개의 서버 시스템을 보면 두 개의 1U 서버에서 각각 아무 문제 없이 작동합니다. 각 서버에는 듀얼 코어 CPU, 2GB RAM, 그리고 160GB SATA 하드 디스크가 있습니다.

그런데 이 두 개를 동일한 하드웨어 구성의 서버 하나에 올릴 경우 리소스를 반씩 나눠야 합니다. 여러분이라면 반씩 나누시겠습니까? 보통 유형 2 하이퍼바이저에는 리소스가 더 많이 필요합니다.

그렇다면 실제에서 가상으로 작업 부하를 통합하는 방안을 생각할 때 고려해야 하는 CPU, RAM 및 HDD 비용을 확인해 보십시오. 가상화된 통합은 OEM의 실제 시스템에 n개에 대한 종속성을 없애 주므로 “시스템을 옆으로 확장하지 않고 위로 쌓아올리는 것”이라고 표현하는 경우가 많습니다. 이렇게 되면 하나의 개별 시스템에 가상화 이전보다 훨씬 더 많은 것을 요구하게 됩니다. 이로 인해 많은 조직에서 성급하게 가상화를 추진할 때 간과하는 시스템 관리 문제가 발생합니다.

가상화의 비용은?

과거 양질의 가상화 소프트웨어는 가격이 상당히 높았지만 시간이 지나고 시장이 발달하면서 이제는 저렴한 가격에 다양한 유형의 가상화 소프트웨어를 구할 수 있게 되었습니다. 그러나 호스트 OS 또는 하이퍼바이저를 포함한 핵심 엔터프라이즈 기능에는 여전히 많은 비용이 소요됩니다.

VM에서 실행하려는 작업 부하에 따라 장애 조치를 모색해야 할 수도 있습니다. 종종 게스트가 손상되거나 호스트 하드웨어가 고장 날 수 있기 때문입니다. 가상화가 하드웨어를 더 안정적으로 만들어 주지는 않습니다. 단지 양상이 바뀔 뿐입니다. 핵심 업무용 시스템의 경우 VM 컨테이너 자체의 백업 여부(물론 절대적으로 백업하는 것이 좋음) 또는 그 안에 포함된 파일 시스템의 백업 여부와 관계없이 여전히 게스트 OS를 백업할 계획을 세워야 합니다.

테스트 또는 개발을 위해 유형 2 하이퍼바이저에서 다수의 게스트 OS를 가상화하는 경우라도 호스트 OS 위에서 이러한 게스트를 동시에 하나 이상 실행하는 데 충분한 RAM을 할당해야 합니다. 가상화 관리에서 가장 빈번하게 간과되는 문제는 디스크 공간 소모입니다.

필자는 보안 테스트 기반으로 꽤 오래 전부터 가상화를 사용하고 있습니다. VM에서 잠재적인 악용을 실행해서 그 영향을 확인하고, 하이퍼바이저의 실행 취소 또는 스냅숏 기능을 사용하여 이전 버전으로 되돌려 다시 테스트하는 편리함은 비할 데가 없습니다. 이렇게 변경 실행 취소를 하나하나 쌓아올리는 방식에서 정작 중요한 부분은 디스크 공간이 빠른 속도로 소비될 수 있다는 점입니다. 나중에는 게스트 OS 자체의 실제 하드 디스크 크기를 훨씬 더 초과하게 될 수 있습니다.

필자가 정기적으로 사용하는 VM 중 하나의 하드 디스크 이미지 크기는 50GB입니다. 이미지를 옮기기 위해 확인하기 전까지는 얼마나 커졌는지 미처 인지하지 못했는데, 6개의 VMware 스냅숏이 포함된 디스크의 크기는 125GB를 훌쩍 넘어선 상태였습니다.

 가상화의 영향/비용을 최소화하기 위한 최선의 방법을 몇 가지 살펴보면 다음과 같습니다.

  • “실행 취소” 기능이 있는 유형 2 하이퍼바이저에서 Windows 클라이언트 OS를 사용하는 경우 반드시 Windows 시스템 복원을 해제합니다. 그렇지 않을 경우 시스템을 변경할 때마다 디스크 사용량이 증가합니다.
  • 1단계를 수행할 경우 실행 취소 지점을 만들 시점을 철저히 엄격하게 결정합니다.
  • 보안/악용 테스트를 수행하는 경우 이전 시점으로 롤백하는 기능을 Windows에 의존하면 안 됩니다. 하이퍼바이저의 실행 취소 기능을 사용하십시오. 복원 지점은 감염될 수 있지만 하이퍼바이저 실행 취소 기능은 일반적인 방식으로는 감염되지 않습니다.
  • 필요한 최소한의 리소스로 게스트 OS를 실행합니다.
  • 클라이언트 OS가 수시로 RAM을 디스크로 스와핑하지 않도록 RAM을 충분히 할당하십시오. 스와핑은 호스트와 모든 게스트의 속도를 **저하시킬 수 있습니다.
  • 게스트 내부적으로 조각 모음을 한 다음 외부적으로 조각 모음을 수행하십시오(뒷부분 조각 모음 섹션 참조). 두 가지 모두 어느 정도 규칙적으로 수행해야 합니다.

VM 증가

여기서 볼 수 있듯이 VM 관리는 금방 문제가 될 수 있습니다. VM 복제의 간편함은 큰 장점이 될 수 있지만 이로 인해 게스트를 관리 및 보호하고 Windows의 OS 라이센스를 추적하고(Windows Vista 이전) 영업 비밀이 유출되지 않도록 지키는 데 따르는 문제가 커질 수 있습니다. 나쁜 의도를 가진 직원은 데스크톱 시스템 전체를 들고 나갈 필요 없이 USB 플래시 드라이브 또는 USB 하드 드라이브를 통해 훨씬 더 간단히 VM을 가지고 나갈 수 있습니다.

VM 증가는 가상화의 내부 구조를 잘 아는 고도의 기술자들 사이에서 훨씬 더 문제가 됩니다. 또한 일반적으로 VM 증가는 가상화된 서버 게스트가 아닌 클라이언트 게스트 사이에서 더 만연합니다.

시스템 관리

모든 기업들은 가상화된 시스템에 대한 제어 능력을 되찾는 데 집중하기 시작했습니다. Microsoft와 VMware는 모두 의식적으로 가상화 자체의 가치보다는 시스템 관리로 중심을 옮겼습니다. 시스템을 없애는 것이 아니라 가상화할 뿐이므로 시스템 관리는 중요합니다.

많은 시스템 관리 제품은 VM에서 완벽하게 기능을 수행하지만 일부 새로운 기능은 가상화된 시스템에 대한 더 지능적인 관리를 가능하게 합니다. 게스트가 대기 모드인 경우 업데이트가 실패하지 않도록 먼저 깨운 후 업데이트하는 기능이 그 예입니다. 제로 데이 악용이 만연한 시대에 이는 중요한 기능입니다. 드물게 사용되는 VM이 회사 네트워크의 로컬 봇넷이 되는 상황은 절대로 피해야 하기 때문입니다.

시스템 관리에 접근할 때는 호스트와 게스트가 있다는 점을 감안하여 각각 적절히 업데이트되도록 하고, 서로의 역할을 인지하도록 해야 합니다. 잘못 설계된 패치 관리 솔루션이 하이퍼바이저 업데이트를 맡아 일과 시간 중에 재부팅을 위해 하이퍼바이저를 해체하고 그 과정에서 4개의 핵심 업무용 게스트도 함께 다시 부팅시키는 상황은 결코 원하지 않을 것입니다.

또한 이러한 시스템은 복구에 접근할 때는 과거와 같은 방법을 사용해야 합니다. 시스템이 가상화되었다고 해서 레지스트리 손상이나 전체 VM 손상으로 인한 시스템 손실로부터 안전한 것은 아니기 때문입니다. 이러한 위험은 상존합니다. 실제 시스템에 적용하는 것과 같은 수준으로 세심하게 백업해야 합니다.

부가적으로 고려해야 할 한 가지는 하이퍼바이저가 실행 취소 기능을 제공하는지 여부입니다. 패치 관리를 수행할 때 이 점을 유의하십시오. 정기 패치일(화요일) 후 수요일에 게스트를 업데이트했다가 월요일의 실행 취소 지점으로 롤백할 경우 이론적으로는 “보호된” 제로 데이에 의해 공격당하기 쉽습니다. 실행 취소 기술은 하이퍼바이저에서 전체 디스크를 이전 시점으로 롤백하는 방법으로 동작하기 때문에 모든 Windows 및 응용 프로그램 패치와 바이러스 백신 서명을 잃게 된다는 것을 의미하므로 이는 큰 문제입니다.

보안 소프트웨어

실행 취소 기능과는 별개로 가상화된 게스트에는 실제 컴퓨터와 동일한 수준의 보안 보호를 제공해야 하며, 그 이상의 보안도 필요합니다. 내부적인 위협에 대해 VM은 실제 컴퓨터와 똑같이 취약합니다.

그러나 큰 차이점이 있다면 바로 비핵심적인 VM(항상 켜져 있지는 않은 VM)은 패치와 AV 업데이트가 지연되는 경우가 많다는 것입니다. 그 결과 이러한 VM은 추적할 수 없는 커다란 제로 데이 악용 대상이 될 수 있습니다. 따라서 이러한 부분을 고려해서 가상 시스템을 패치할 수 있는 성숙한 시스템 관리 솔루션을 사용해야 합니다.

외부 위협은 또 다른 문제입니다. VM은 지적 재산 도둑의 출입구가 될 수 있습니다. 제어되지 않는 호스트에서 실행되는 VM은 데이터 유출 경로가 될 수 있으므로 이러한 점을 반드시 잘 이해해야 합니다. 첫째, 가상 환경을 손쉽게 복사할 수 있다면 문제가 됩니다. 특히 데이터 액세스를 제어하는 규정 준수 요구 사항이 있는 경우에는 더욱 그렇습니다(지난 2008년 필자의 기사(https://technet.microsoft.com/magazine/2008.06.desktopfiles)에서 설명한 적이 있음).

둘째, RMS 및 IRM에 대한 필자의 기사에서도 언급했듯이(https://technet.microsoft.com/magazine/2008.11.desktopfiles), 이러한 제어는 OS에 의존하여 화면 캡처, 인쇄 등을 차단합니다. 그러나 이러한 제어는 하이퍼바이저까지 확장되지 않습니다. 즉, RMS로 보호되는 콘텐츠가 게스트 OS에 표시될 경우 호스트 OS에서 여전히 개별 스크린샷을 인쇄하거나 화면을 비디오로 캡처할 수 있습니다.

기술적으로 아날로그는 아니지만 “아날로그 구멍”과 크게 다르지 않습니다. 필자가 알기로는 DRM 제어 콘텐츠를 이런 방식의 악용으로부터 보호할 방법은 없습니다. 현실적으로 그럴 방법이 있다고 해도, 카메라와 비디오 카메라를 사용해서 같은 방법으로 “악용”할 수 있는 사용자를 상대로 시스템을 보호해야 한다는 문제로 돌아가게 됩니다.

디스크 조각 모음

디스크 조각 모음은 다음과 같은 여러 가지 이유로 VM에서 독특한 과제입니다.

  1. 일반적으로 두 가지 수준의 조각화가 발생합니다. 하나는 가상화된 디스크 컨테이너 자체 내의 조각화(각각의 게스트에서 보이는 조각화로, 필자는 “주 조각화”라고 함), 다른 하나는 호스트 OS의 디스크에서 가상화된 디스크를 포함하는 실제 파일의 조각화(또는 “부 조각화”)입니다.
  2. 필요한 최소 공간을 두고 “요청 시” 용량이 확장되는 디스크가 있는 가상화 제품에서는 부 조각화가 발생할 수 있습니다.
  3. 실행 취소 기능은 디스크 공간을 소비할 뿐만 아니라 대량의 부 조각화도 발생시킵니다. 호스트 OS 디스크 공간을 추가로 소비함에 따라 각 게스트에서 가용한 섹터를 두고 경쟁을 시작하기 때문입니다.
  4. 요청 시 확장되는 디스크는 대부분 요청이 줄어들 때 축소되는 기능은 제공하지 않습니다. 40GB를 할당하고 처음에는 10GB만 사용하다가 확장되어 35GB가 필요하게 되더라도 디스크는 자동으로 공간을 복구하지 않습니다. 즉, 부 조각화가 발생할 가능성이 매우 높은 큰 파일이 만들어집니다.

가상 디스크의 크기, 디스크가 축소 또는 확장되는 속도, 그리고 두 가지 유형의 조각화가 쉽게 발생한다는 사실을 고려할 때 가상 디스크는 실제 시스템보다 더욱 세심한 주의를 기울여 관리해야 합니다.

파일을 보호하기 위한 한 가지 방법은 다음과 같습니다.

  1. 자동 실행 취소 기술은 전체적인 디스크 파일의 크기를 지나치게 늘리고, 호스트에서 가상 디스크를 구성하는 파일을 조각 모음할 수 있지만 게스트에서 바로 조각 모음을 할 수 없으므로 사용을 최소화합니다.
  2. 우선 게스트에서 좋은 디스크 조각 모음 제품을 사용하고 정기적으로 실행합니다.
  3. 요청 시 디스크 확장 기술을 사용하는 경우:
    a. 다음과 같이 Sysinternals sdelete.exe 유틸리티를 사용합니다. sdelete –c drive_letter 여기서 drive_letter는 소거하려는 볼륨입니다. 예를 들어 **sdelete –c C:**는 조각 모음 후 사용되지 않는 디스크 공간을 모두 소거합니다.
    b. 가상 디스크 축소 기술(공급업체가 제공하는 경우)을 사용하여 가상 디스크 컨테이너를 최소 크기로 줄입니다.
  4. VM이 포함된 호스트 OS의 볼륨을 조각 모음합니다.

많은 사람들이 디스크 조각 모음을 무시합니다. 2007년 기사에 대해 필자가 받은 엄청난 양의 독자 메일을 보면 오해되는 경우가 많은 주제이지만 무시해서는 안 되며, 가상 시스템에서도 마찬가지입니다.

가상화의 중요성이 커지고 사용이 폭증함에 따라 가상화의 비용과 특유의 복잡성에 대한 이해 없이 “통합” 유행에 휩쓸리기 쉽습니다. 이 기사는 가상화로 마이그레이션하거나 가상화를 사용하면서 고려해야 하는 부가적인 추가 비용을 파악하는 데 도움이 될 것입니다.

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

관련 콘텐츠