네트워크 격리를 통해 가상 컴퓨터 복제

아티클
07/15/2016

게시: 2016년 4월

가상 랩 관리는 소프트웨어 개발 수명 주기에서 새로 떠오르는 분야입니다. Visual Studio Lab Management는 개발자 및 테스터에게 가상 랩 관리 기능을 제공해 주는 Visual Studio 제품입니다. Visual Studio Lab Management를 통해, 개발 팀은 자신의 개발 및 테스트 랩에서 가상화 기술을 이용하여 가상 컴퓨터에서 복잡한 다계층 환경을 구성할 수 있습니다. 그런 다음 이러한 환경에서 응용 프로그램 빌드를 배포하고 테스트를 실행할 수 있습니다.

개발 및 테스트 랩에서 가상화를 사용하게 되는 동기 중 하나는 파일 몇 개만 복사함으로써 배포된 가상 컴퓨터에 대해 똑같은 복사본 즉, 복제본을 만들 수 있다는 점입니다. 복제는 다양한 시나리오에서 유용합니다. 예를 들어, 문제를 다시 생성하기 위해 테스터 환경 복사본이 필요한 개발자는 해당 환경의 복제본을 만들 수 있습니다. 테스트 팀의 각 테스터는 환경 복사본을 복제한 다음 팀의 다른 동료와 테스트 활동을 조정할 수 있습니다. 복제할 경우 개발자와 테스터는 자신이 만드는 환경마다 운영 체제 및 기타 소프트웨어를 반복해서 설치할 필요가 없으므로 시간을 절약할 수 있습니다.

요구 사항

Visual Studio Enterprise, Visual Studio Test Professional

가상 환경을 복제하는 것이 쉬운 작업이긴 하지만 복제로 인한 결과는 고려해야 합니다. 복제 환경의 컴퓨터는 원본 환경의 컴퓨터와 같은 컴퓨터 이름을 갖습니다. 경우에 따라서는 IP 주소와 MAC 주소도 같을 수 있습니다. 이로 인해 복제본 중 하나에서 네트워크 연결성을 잃게 되거나 특정 복제본을 대상으로 하는 네트워크 트래픽이 다른 복제본에 전송될 수 있습니다. 결국 응용 프로그램을 특정 복제본에 배포하고 테스트는 다른 복제본에서 수행하게 되는 의도하지 않은 결과가 발생할 수 있습니다.

참고

네트워크 격리는 SCVMM 환경에서만 사용할 수 있습니다.표준 환경에서는 이 기능을 사용할 수 없습니다.

Visual Studio Lab Management를 사용하면 네트워크 격리라는 기술을 통해 이러한 문제를 해결하고 가상 환경을 편리하고 안전하게 복제할 수 있습니다. 이 항목에서는 네트워크 격리가 사용되는 방법을 알아보고 네트워크 격리가 사용된 복제와 사용되지 않은 복제를 비교해봅니다. 첫 번째 예제에서는 네트워크 격리가 사용되지 않은 경우 복제본 간에 발생할 수 있는 다양한 형태의 충돌에 대해 설명합니다. 그 다음 예제에서는 Visual Studio Lab Management를 사용하여 충돌 방지를 위한 여러 솔루션을 검토합니다.

네트워크 충돌

그림 1에는 Lab Management를 사용하여 만들 수 있는 전형적인 가상 환경이 나와 있습니다. 원본 환경이라고 하는 이 환경에는 두 대의 가상 컴퓨터(web-server 및 db-server)가 있습니다. 이러한 컴퓨터는 3계층 웹 응용 프로그램에서 각각 웹 및 데이터베이스 서버 역할을 합니다. 이 예제에서는 개발 팀의 멤버가 이 환경을 만든 다음 자신의 최신 웹 응용 프로그램 빌드를 이 환경에 배포한 것으로 가정합니다. 또한 빌드가 배포된 후 최신 빌드라고 하는 스냅숏이 이 환경에서 만들어진 것으로 가정합니다. 스냅숏은 환경에 대한 지정 시간 상태입니다. 언제든지 이 저장된 상태로 복원하여 해당 상태부터 다시 실행할 수 있습니다. 원본 환경의 두 가상 컴퓨터에 대한 컴퓨터 이름, IP 주소 및 MAC 주소가 그림에 나와 있습니다.

원본 호스트의 VM 'web-server' 및 'db-server'.

원본 환경

그림 2에는 원본 환경과 복제 환경이 나와 있습니다. 복제 후 두 환경이 시작되면 다음과 같은 유형의 네트워크 충돌이 발생할 수 있습니다.

컴퓨터 이름 충돌
IP 주소 충돌
MAC 주소 충돌

이름 충돌이 있는 복제된 VM이 포함되어 있는 호스트 2개

일반 네트워크 상의 원본 및 복제 환경

이러한 충돌 각각에 대한 정확한 결과는 가상 컴퓨터의 운영 체제, 랩의 네트워크 인프라 등의 여러 요인에 따라 다릅니다. 그림 2에서 원본 환경의 각 가상 컴퓨터에는 고정 IP 주소 및 고정 MAC 주소가 구성되어 있는 것으로 가정합니다. 따라서 환경이 복제되었을 때 복제된 가상 컴퓨터에는 동일한 IP 및 MAC 주소가 할당되었습니다.

컴퓨터 이름 충돌

컴퓨터 이름은 사용자가 네트워크에서 컴퓨터를 식별하기 위해 지정한 이름입니다. 컴퓨터 이름을 IP 주소로 확인하는 데는 일반적으로 NetBIOS와 DNS(도메인 이름 서버)라는 두 개의 프로토콜이 사용됩니다. 컴퓨터 이름이 같은 두 대의 컴퓨터가 동일한 네트워크 세그먼트에서 시작되면 NetBIOS는 이름 충돌을 감지하고 사용자에게 경고합니다. 일반적으로 NetBIOS는 컴퓨터가 동일한 네트워크 세그먼트에 있는 경우에만 충돌을 감지할 수 있습니다. 컴퓨터가 동일한 네트워크 세그먼트에 있지 않거나 경고가 무시되면 다음 수준의 충돌이 DNS에서 발생합니다. DNS는 이름을 등록할 컴퓨터의 중앙 리포지토리입니다. 컴퓨터 이름이 같은 두 컴퓨터가 DNS에 등록을 시도하면 첫 번째 컴퓨터에서 만든 항목을 두 번째 컴퓨터가 재정의할 수 있습니다. 이 경우 시작된 첫 번째 컴퓨터는 이름 확인을 통해 연결되지 않습니다.

간단한 방법으로 컴퓨터 이름 충돌을 방지하거나 수정할 수 있습니다. 환경에 대해 동일한 복사본을 만드는 대신 sysprep라는 메커니즘을 사용하여 각 본제본을 사용자 지정하여 복사본을 만들 수 있습니다. Sysprep는 Windows 운영 체제의 일부입니다. 복제 환경에 sysprep를 사용하면 이 환경의 각 가상 컴퓨터는 원본 환경의 가상 컴퓨터와 다른 고유한 컴퓨터 이름, IP 주소 및 MAC 주소를 갖게 됩니다. 그러나 복제본은 더 이상 동일하지 않습니다.

충돌 방지를 위해 sysprep를 통해서든 사용자의 수동 개입을 통해서든 각 본제본에서 고유한 컴퓨터 이름을 갖게 될 경우 그 결과는 가상 컴퓨터에 설치된 소프트웨어에 따라 다릅니다. 예제를 통해 이를 살펴 봅니다. 응용 프로그램이 환경에 배포되었을 때 web.config 파일이 웹 서버에 만들어졌습니다. 이 파일에서는 컴퓨터 이름 db-server를 연결 문자열의 일부로 구성했습니다. 이 파일의 코드 조각은 다음과 같습니다.

<?xml version="1.0"?>
<configuration>
  <appSettings>
    <add key="ConnectionString" 
      value="Persist Security Info=True;User ID=dbuser;  
        Password=password;Initial Catalog=Store;Data Source=db-server"/>
  </appSettings>
</configuration>

복제 환경에서 데이터베이스 서버의 컴퓨터 이름을 변경한 경우 다음과 같이 web.config 파일도 새 이름이 사용되도록 수동으로 변경해야 합니다(db-server2가 복제 환경의 가상 컴퓨터에 제공된 새 컴퓨터 이름임).

<?xml version="1.0"?>
<configuration>
  <appSettings>
    <add key="ConnectionString" 
      value="Persist Security Info=True;User ID=dbuser;  
        Password=password;Initial Catalog=Store;Data Source=db-server2"/>
  </appSettings>
</configuration>

또한 SQL Server의 경우에는 컴퓨터 이름이 바뀌면 추가 단계를 수행해야 합니다. 이를 위한 SQL 스크립트의 코드 조각은 다음과 같습니다.

sp_dropserver db-server
sp_addserver db-server2, local
GO

이전 예제에서는 컴퓨터 이름이 변경된 경우 응용 프로그램을 재구성하는 방법을 살펴보았습니다. 당연히 이 절차는 응용 프로그램에 따라 다릅니다. 응용 프로그램이 컴퓨터 이름을 데이터베이스 항목으로 기록한 경우에는 비슷한 방법으로 해당 항목이 변경되어야 합니다. 경우에 따라, 컴퓨터 이름이 변경된 경우 응용 프로그램을 다시 설치해야 할 수도 있습니다. 이러한 재구성 및 재설치 작업은 복제 사용을 통해 가장 먼저 피하고자 했던 작업입니다. 여기에는 컴퓨터 이름 충돌 없이 여러 복제본이 공존할 수 있으며 응용 프로그램 독립적인 더욱 강력한 솔루션이 필요합니다.

IP 주소 충돌

IP(인터넷 프로토콜) 주소는 컴퓨터가 TCP 네트워크를 통해 서로 통신하는 데 사용됩니다. IP 주소는 네트워크에서 DHCP 서버에 의해 고정 또는 동적으로 할당됩니다. 컴퓨터의 각각 연결된 네트워크 인터페이스에는 IP 주소가 있습니다. 고정 IP 주소로 구성된 가상 컴퓨터가 복제된 다음 원본 가상 컴퓨터와 동일한 네트워크에 배치되면 컴퓨터 이름 충돌 이외에 IP 주소 충돌도 발생합니다. 복제본 중 하나의 IP 주소를 변경하여 이 충돌을 수동으로 해결할 수 있습니다. 다시 설명하지만 IP 주소 변경에 따른 결과는 가상 컴퓨터에 설치된 응용 프로그램에서 고정 IP 주소가 사용되는 방법에 따라 다릅니다.

동적 IP 주소로 구성된 가상 컴퓨터 복제를 시작할 경우 잠시 동안은 네트워크 충돌이 있습니다. 첫 번째 컴퓨터가 복제된 직후, 네트워크에 연결되는 두 번째 컴퓨터가 이 충돌을 감지하고 IP 주소를 갱신하여 자체적으로 해결합니다. 복제 환경이 원본 환경에서 만들어진 스냅숏으로 복원될 때마다 마찬가지로 짧은 충돌 기간이 존재합니다. 이러한 충돌 기간은 대개 응용 프로그램에 영향을 줄만큼 길지 않습니다.

MAC 주소 충돌

MAC(Media Access Control) 주소는 컴퓨터의 각 네트워크 인터페이스에 할당되는 주소입니다. 물리적 컴퓨터의 경우에는 카드 제조업체가 각 네트워크 인터페이스에 할당합니다. 가상 컴퓨터의 경우에는 MAC 주소를 고정 또는 동적 MAC 주소로 할당할 수 있습니다. 가상 컴퓨터의 네트워크 인터페이스가 사용할 특정 MAC 주소를 지정할 수 있습니다. 이를 고정 MAC이라고 합니다. 또는 하이퍼바이저에 의해 MAC 주소가 동적으로 할당되도록 할 수도 있습니다. 이를 동적 MAC이라고 합니다. 동적 MAC 주소는 가상 컴퓨터가 시작될 때마다 Hyper-V가 MAC 주소 풀에서 골라 할당합니다. 각 호스트에는 MAC 주소를 다른 호스트의 가상 컴퓨터와 충돌하지 않게 생성하는 구성표가 있습니다.

원본 환경의 가상 컴퓨터에 고정 MAC 주소가 사용되는 경우 복제 환경의 가상 컴퓨터도 같은 MAC 주소를 갖게 됩니다. 그러면 즉시 MAC 충돌이 발생합니다. 중복 MAC 주소는 컴퓨터에서 보고되지 않는 경우도 있으므로 감지하기가 더 어렵습니다. 이러한 주소가 보고되더라도 해당 메시지는 Windows 이벤트 뷰어에 기록됩니다. 최종 사용자에게는 중복 MAC 주소로 인한 두 가지 결과가 있습니다. 한 결과는 하나 또는 양쪽 복제본에서 네트워크 연결성을 잃게 되는 것입니다. 다른 결과는 한 컴퓨터로 주소가 지정된 네트워크 패킷이 다른 컴퓨터로 전송될 수 있다는 것입니다. 원본 캄퓨터와 복제본이 같은 MAC 주소를 갖고 있다면 IP 주소도 같습니다. DHCP를 사용하여 동적 IP 주소를 가져오더라도 MAC 주소가 같으므로 DHCP서버는 동일한 IP 주소를 할당합니다.

동적 MAC 주소를 사용하여 MAC 충돌을 어느 정도 방지할 수 있습니다. 하지만 복제 환경이 원본 환경에서 만들어진 스냅숏으로 복원되면 해당 가상 컴퓨터의 전체 상태가 MAC 주소를 포함하여 롤백됩니다. 이로 인해 MAC 충돌이 다시 발생하며 복제된 가상 컴퓨터가 다시 시작되기 전에는 앞서 언급된 동일한 문제가 계속 존재합니다. 복제 환경이 다시 시작되면 하이퍼바이저가 MAC 주소를 해제하고 자체 범위의 값으로 갱신하게 됩니다.

지금까지 언급된 다양한 형태의 충돌을 감지하여 해결한 다음, 작업을 계속하기 위해 OS/응용 프로그램을 수동으로 수정하는 것은 가상 랩 관리를 자주 사용하는 사용자에게 중요하지만 시간을 소모하고 오류가 발생할 수 있는 작업입니다. 대부분의 경우 이러한 매개 변수를 변경하면 가상 환경이 너무 변경되어 버그가 재연되지 않거나 프로덕션 환경과 유사한 문제가 발생되지 않습니다. 응용 프로그램을 가상 환경에 한 번 설치한 다음 아무런 문제 없이 해당 환경을 복제하여 똑같은 복사본을 여러 개 만든다는 원리를 실현하는 데는 일반 사용자가 예상할 수 있는 것보다 더 정교한 방식이 필요합니다.

네트워크 격리

지금까지, 두 가지 요구 사항이 확인되었습니다. 첫 번째 요구 사항으로 복제 환경의 가상 컴퓨터는 원본 환경의 가상 컴퓨터와 같은 컴퓨터 이름, IP 주소 및 MAC 주소를 가져야 합니다. 하지만 동시에 이러한 복제본은 환경 외부와 독립적으로 주소를 지정할 수 있어야 합니다. 예를 들어 자신의 데스크톱에서 각 복제본에 연결하려는 사용자의 경우, 특정 복제본에 배포할 응용 프로그램의 경우 또는 특정 복제본에서 실행하려는 테스트의 경우에 이러한 사항이 요구됩니다. 이 요구 사항은 복제 환경의 가상 컴퓨터가 원본 환경의 가상 컴퓨터와 다른 고유한 컴퓨터 이름, IP 주소 및 MAC 주소도 가져야 한다는 두 번째 요구 사항으로 이어집니다. 이러한 두 가지 요구 사항을 모두 충족시키는 논리적 방법은 각 가상 컴퓨터가 두 가지 인터페이스 즉, 모든 복제본에서 컴퓨터 이름, IP 주소 및 MAC 주소가 같은 개인 인터페이스와 각 복제본마다 이러한 값이 고유한 공용 인터페이스를 갖는 것입니다.

네트워크 충돌을 방지하기 위해 개인 인터페이스는 각 복제본의 개인 네트워크에 연결되어야 합니다. 개인 네트워크는 환경 내부의 가상 컴퓨터로만 제한되는 가상 네트워크입니다. 이 네트워크는 외부 환경으로 노출되지 않으므로 동일한 컴퓨터 이름, IP 주소 및 MAC 주소가 다른 복제본에서 사용되더라도 충돌이 발생하지 않습니다. 외부 환경에서 액세스할 수 있도록 하기 위해 모든 공용 인터페이스는 일반 공용 네트워크에 연결되어야 합니다. 공용 네트워크 또는 랩 네트워크는 환경의 가상 컴퓨터가 랩의 다른 컴퓨터나 클라이언트와 상호 작용할 수 있는 네트워크입니다.

그림 3에는 개인 및 공용 인터페이스로 네트워크 충돌을 해결하는 방법이 나와 있습니다.

전용 및 공용 포트가 제공되는 VM이 있는 호스트 2개

Visual Studio Lab Management의 네트워크 격리

Visual Studio Lab Management는 각 가상 컴퓨터에 두 가지 네트워크 인터페이스를 도입함으로써 SCVMM 환경을 위한 네트워크 격리를 구현합니다. 이러한 네트워크 인터페이스 중 하나는 개인 네트워크에 연결되는 개인 인터페이스이고 다른 하나는 공용 네트워크에 연결되는 공용 인터페이스입니다.

Lab Management 소프트웨어와 각 가상 컴퓨터에 설치된 에이전트를 통해 원본 환경과 복제 환경이 충돌하지 않고 공존할 수 있습니다.

개인 네트워크의 개인 인터페이스

컴퓨터 이름, IP 주소 및 MAC 주소가 환경의 개인 인터페이스에 할당되는 방법이 아래에 요약되어 있습니다.

컴퓨터 이름: 개인 네트워크의 컴퓨터 이름은 NetBIOS를 통해 확인되며 Lab Management 소프트웨어에서의 추가 처리가 필요하지 않습니다. NetBIOS 컴퓨터 이름으로 작동되도록 구성된 응용 프로그램은 모든 복제본에서 올바르게 작동됩니다. 본 예제에서 web-server 컴퓨터는 해당 이름을 사용하는 db-server 컴퓨터를 참조합니다. 이러한 이름은 원본 및 복제 환경에서 동일합니다. 따라서 복제 환경에서 web.config 파일을 변경할 필요가 없습니다.

개인 네트워크에는 DNS 서버가 없으므로 가상 컴퓨터에서 NetBIOS 이름 대신 FQDN(정규화된 도메인 이름)을 사용하여 서로 참조하는 경우에는 이러한 상황의 문제를 해결해야 합니다. 예를 들어 web.config 파일이 db-server를 db-server.lab.contoso.com으로 참조한 경우에는 개인 네트워크의 DNS 없이는 해당 이름을 IP 주소로 확인할 수 없습니다. 이 문제를 해결하기 위해, 가상 컴퓨터에서 실행 중인 랩 에이전트가 동일한 환경의 다른 가상 컴퓨터에 해당하는 항목을 호스트 파일에 추가합니다. 호스트 파일은 이름이 특정 IP 주소로 확인되어야 함을 운영 체제에 지시하는 또 다른 방법입니다. 본 예제에서 web-server의 호스트 파일에는 다음과 같은 항목이 포함됩니다.

192.168.23.2 db-server.lab.contoso.com

IP 주소: 192.168.23.1 ~ 255 범위의 고정 IP 주소가 각 가상 컴퓨터의 개인 네트워크 인터페이스에 할당됩니다. 예를 들어 web-server의 개인 인터페이스에는 192.168.23.1이, db-server의 개인 인터페이스에는 192.168.23.2가 할당됩니다. Lab Management를 통해 web-server와 db-server는 모든 복제본에서 동일한 고정 IP 주소를 갖습니다. 따라서 web-server의 web.config 파일이 db-server의 IP 주소로 구성된 경우라도 복제 환경에서 이 파일을 다시 구성할 필요가 없습니다. 네트워크 격리로 구성되는 모든 환경에서 개인 인터페이스는 192.168.23.1부터 시작하여 동일한 범위의 IP 주소를 갖습니다. 이 범위에 필요한 최대 주소 개수는 환경의 최대 가상 컴퓨터 수와 같습니다. 이 IP 주소 집합은 개인 네트워크 외부에서 라우팅할 수 없으므로 동일한 범위가 공용 네트워크에서 사용되지 않는 한 미리 정의된 범위를 사용하는 것이 안전합니다.

MAC 주소: 네트워크 격리 환경에서 각 가상 컴퓨터의 개인 네트워크 인터페이스에는 임의의 고정 MAC 주소가 할당됩니다. 본 예제에서 원본 web-server의 개인 인터페이스에 할당된 MAC 주소는 00-15-5D-07-57-01입니다. Lab Management를 통해 이 web-server는 복제 환경에서 동일한 MAC 주소를 갖습니다. 이 MAC 주소 집합은 개인 네트워크 외부에서 라우팅할 수 없으므로 주소가 해당 호스트에서 하이퍼바이저가 사용하는 주소 범위에 포함되지 않는 한 임의의 주소를 사용하는 것이 안전합니다.

공용 네트워크의 공용 인터페이스

컴퓨터 이름, IP 주소 및 MAC 주소가 환경의 공용 인터페이스에 할당되는 방법이 아래에 요약되어 있습니다.

컴퓨터 이름: 공용 네트워크의 컴퓨터 이름을 확인하는 데 NetBIOS를 사용하면 컴퓨터 이름 충돌이 발생하므로 NetBIOS를 사용하지 않는 것이 좋습니다. 이 문제를 방지하기 위해 Lab Management는 각 가상 컴퓨터의 공용 인터페이스에 NetBIOS 브로드캐스트를 사용하지 않도록 설정합니다. NetBIOS와 마찬가지로 가상 컴퓨터가 NetBIOS 컴퓨터 이름을 DNS에 등록하지 않는 것이 좋습니다. Lab Management는 각 공용 인터페이스에 DNS 등록도 사용하지 않도록 설정합니다. NetBIOS 및 기본 DNS 등록이 없는 환경에서 가상 컴퓨터가 공용 네트워크에서 사용할 수 있는 고유한 이름을 갖는 것이 좋습니다. Lab Management는 각 가상 컴퓨터 대신 고유한 별칭 이름을 생성하여 DNS에 'A' 레코드로 등록합니다. 본 예제에서 원본 환경의 web-server는 VSLM-195ea870-34d87df83883add23-47ab86ff.lab.contoso.com와 비슷한 고유한 별칭 이름을 사용하여 등록될 수 있습니다. 복제 환경의 동일한 web-server는 VSLM-87ead667a-8787adde877919aaa-2001874d0.lab.contoso.com와 비슷한 다른 이름을 사용하여 등록됩니다.

IP 주소: 각 가상 컴퓨터의 공용 네트워크 인터페이스는 DHCP 서버에서 동적 IP 주소를 가져오도록 구성됩니다. 이를 통해 원본 및 복제 환경의 가상 컴퓨터는 고유한 IP 주소를 갖게 됩니다. 예를 들어 원본 환경의 web-server는 172.52.20.140이라는 IP 주소를, 복제 환경의 동일한 web-server는 172.52.20.205라는 IP 주소를 가질 수 있습니다.

MAC 주소: MAC 충돌을 방지하기 위해, 각 가상 컴퓨터의 공용 네트워크 인터페이스는 하이퍼바이저에서 동적 MAC 주소를 가져오도록 구성할 수 있습니다. 이러한 구성을 통해 본 예제의 web-server 컴퓨터는 원본 환경과 복제 환경에서 다른 MAC 주소를 갖게 됩니다. 하지만 앞서 설명한 대로, 복제 환경이 원본 환경에서 만들어진 스냅숏으로 복원되면 복제된 가상 컴퓨터의 MAC 및 IP 주소에는 원본과 같은 값이 사용됩니다. 예를 들어 복제 환경이 최신 빌드 스냅숏으로 복원되면 web-server의 IP 주소가 원본 환경에서의 값과 동일한 10.86.51.61이 됩니다(그림 3 참조). MAC 주소도 마찬 가지입니다. IP 주소 충돌은 DHCP에 의해 갱신될 때까지 일시적으로 존재하는 반면 MAC 충돌은 가상 컴퓨터가 다시 시작될 때까지 존재합니다. 이러한 제한으로 인해, 하이퍼바이저를 통해 동적으로 할당된 MAC 주소를 공용 인터페이스에 사용하는 방법은 적합하지 않습니다.

이 문제를 해결하기 위해 Lab Management는 자체 MAC 주소 풀을 사용합니다. 이 풀의 고유 MAC 주소가 가상 컴퓨터의 공용 인터페이스에 할당됩니다. 복제 환경이 스냅숏으로 복원될 때마다 Lab Management는 충돌을 방지하기 위해 MAC 주소를 자동으로 변경합니다. 원본 환경에 있는 web-server의 MAC 주소를 1D-D8-B7-1C-00-05, 복제 환경에 있는 web-server의 MAC 주소를 1D-D8-B7-1C-00-07이라고 가정할 경우 다음과 같은 방식으로 수행됩니다. 복제 환경이 원본 환경에서 만들어진 스냅숏으로 복원되는 순간 web-server의 MAC 주소는 일시적으로 1D-D8-B7-1C-00-05가 됩니다. 하지만 Lab Management가 이 주소를 다시 1D-D8-B7-1C-00-07로 변경하여 네트워크 충돌을 방지합니다.

네트워크 격리와의 일반적인 상호 작용

환경 내의 두 가상 컴퓨터가 서로 통신할 때는 다음과 같은 작용이 일어납니다.

Web-server는 NetBIOS 또는 호스트 파일을 사용하여 "db-server"라는 컴퓨터 이름을 db-server 개인 인터페이스의 IP 주소(192.168.23.2)로 확인합니다.
Web-server는 이 IP 주소의 db-server와 통신합니다.

외부 환경의 클라이언트가 복제 환경의 web-server와 통신해야 할 경우 다음 프로세스가 수행됩니다.

클라이언트가 복제 환경의 web-server에 대한 고유 별칭 이름을 가져오기 위해 Lab Management 소프트웨어에 쿼리합니다.
Lab Management 소프트웨어는 고유 별칭 이름으로 응답합니다.
DNS 서버는 고유 별칭 이름을 web-server 공용 인터페이스의 IP 주소(10.86.51.63)로 확인합니다.
클라이언트는 이 IP 주소의 web-server와 통신합니다.

또 다른 네트워크 격리 실현 방식

두 가지 인터페이스를 사용하는 방식 이외에 네트워크 격리 실현을 위한 다른 방식이 있습니다. 양방향 NAT를 사용하여 이와 같은 네트워크 격리를 실현할 수 있습니다. NAT는 공용 네트워크의 장치와 통신하는 데 필요한 장치의 개인 네트워크를 만들기 위한 일반적인 방법입니다. 일반적인 NAT의 통신은 항상 개인 네트워크에서 시작되어야 하지만 양방향 NAT(또는 2방향 NAT)의 경우는 한 단계 더 나아가 개인 네트워크의 컴퓨터나 공용 네트워크의 컴퓨터에서 통신을 시작할 수 있습니다.

이 방식을 사용하여 네트워크 격리를 실현하려면 2방향 NAT 서버가 환경에 도입되어야 합니다. 이를 위해 양방향 NAT 서버 역할을 전담하는 특별 가상 컴퓨터를 환경에 추가합니다. 네트워크 격리 환경이 만들어지면 가상 컴퓨터의 공용 및 개인 IP 주소가 두 가지 인터페이스 방식에서와 같은 방법으로 할당됩니다. 하지만 공용 IP 주소가 가상 컴퓨터의 네트워크 인터페이스에 할당되는 대신 해당 매핑이 2방향 NAT 서버의 NAT 테이블에 저장됩니다.

2방향 NAT를 사용하는 VM에 대한 공용 액세스

환경의 두 가상 컴퓨터가 2방향 NAT 방식을 사용하여 서로 통신하는 단계는 다음과 같이 두 가지 인터페이스 방식에서의 단계와 완전히 똑같습니다.

Web-server는 NetBIOS 또는 호스트 파일을 사용하여 db-server라는 컴퓨터 이름을 db-server 개인 인터페이스의 IP 주소(192.168.23.2)로 확인합니다.
Web-server는 이 IP 주소의 db-server와 통신합니다.

외부 환경의 클라이언트가 복제 환경의 web-server와 통신해야 할 경우에는 다음과 같이 약간 다른 단계가 수행됩니다.

NAT 방식 구현을 통해, 클라이언트가 복제 환경의 web-server에 대한 고유 별칭 이름을 가져오기 위해 Lab Management 소프트웨어에 쿼리합니다. Visual Studio Lab Management는 NAT 방식을 구현하지 않습니다.
Lab Management 소프트웨어는 고유 별칭 이름으로 응답합니다.
DNS 서버는 고유 별칭 이름을 web-server의 공용 IP 주소(10.86.51.63)로 확인합니다.
이 IP 주소는 사실상 2방향 NAT 서버의 인터페이스로 매핑됩니다. 클라이언트는 web-server와 통신한다는 가정 하에 2방향 NAT 서버와 통신합니다.
NAT 서버는 구성 테이블에 저장된 매핑을 검색하여 공용 IP 주소(10.86.51.63)를 개인 IP 주소(192.168.23.1)로 변환합니다.
NAT 서버는 개인 네트워크에 있는 클라이언트의 메시지를 web-server의 IP 주소인 192.168.23.1로 전달합니다.

두 가지 인터페이스 방식에 비해 이 방식의 이점은 환경의 가상 컴퓨터를 어떤 방법으로든 수정할 필요가 없다는 점입니다. 각 가상 컴퓨터에 추가 네트워크 인터페이스를 도입할 필요가 없습니다. 가상 컴퓨터에 추가 네트워크 인터페이스를 도입할 경우 일부 응용 프로그램이 중단될 수 있습니다.

이 방식의 또 다른 이점은 네트워크 격리 실현을 위한 전체 로직이 별도의 가상 컴퓨터에 캡슐화된다는 점입니다. 나머지 각 가상 컴퓨터에 에이전트가 있을 필요가 없습니다. 모든 패킷이 별도의 가상 컴퓨터를 통해 라우팅되므로 다음과 같은 네트워크 격리의 고급 기능을 지원하는 제어점이 추가로 제공됩니다.

외부 전용 방어: 외부 환경의 클라이언트에서 시작된 네트워크 패킷이 내부 환경의 가상 컴퓨터에 도달할 수 없도록 합니다.
외부 전용 방어(특정 포트 제외): 외부 환경의 클라이언트에서 시작된 네트워크 패킷이 내부 환경의 가상 컴퓨터에서 특정 포트로 향하도록 지정된 경우 이외에는 도달할 수 없도록 합니다.

이러한 기능은 NAT 서버에 방화벽을 도입함으로써 2방향 NAT 방식으로 손쉽게 구현할 수 있습니다. 2방향 NAT 방식의 주요 단점은 일부 응용 프로그램이 NAT을 통해 작동하지 않는다는 점입니다. 예를 들어 Windows 응용 프로그램에서 주로 사용되는 DCOM 및 .NET 원격 프로토콜은 클라이언트와 서버가 NAT 서버에 의해 분리된 경우 작동하지 않습니다. 이러한 이유로 Visual Studio Lab Management는 두 가지 인터페이스 방식을 사용합니다. 2방향 NAT 방식의 또 다른 단점으로는 각 환경에 추가 가상 컴퓨터가 필요하며 이로 인해 가상 환경에서 만들기 또는 기타 작업이 수행되는 동안 오버헤드가 추가로 발생된다는 점입니다.

기타 충돌

지금까지, 네트워크 격리를 통해 컴퓨터 이름, IP 주소 및 MAC 주소 충돌을 해결하는 방법에 대해 알아봤습니다. 환경을 복제할 경우 그 밖의 다른 형태의 충돌이 발생할 수도 있습니다. 가상 환경 외부에 있는 외부 구성 요소에 대해 종속성이 있다면 해당 환경이 복제될 때 충돌이 발생할 잠재성이 있습니다. 이 섹션에서는 그러한 충돌이 발생할 수 있는 일반적인 경우 두 가지를 살펴봅니다.

Active Directory 충돌

일반적으로 Windows 컴퓨터 및 응용 프로그램에서는 디렉터리 서비스나 사용자 인증 및 권한 부여에 AD(Active Directory)를 사용합니다. AD 그룹 정책을 사용하여 Windows 컴퓨터를 중앙에서 관리하는 것은 매우 일반적인 관례입니다. 본 예제를 사용하여 원본 환경의 web-server 및 db-server가 AD에서 관리되는 도메인에 가입된 것으로 가정합니다. AD는 외부 환경에서 호스트됩니다. 이 환경을 복제하면 동일한 web-server 복제본 두 개가 생기지만 AD에는 하나의 항목만 있습니다. 이러한 상태는 분명히 잘못된 것이며 여러 가지 문제를 일으킬 수 있습니다. 예를 들어 web-server 복제본 중 하나가 사용자 작업에 의해 도메인 가입에서 해제된 경우 나머지 복제본도 가입 해제됩니다. 한 환경을 변경하면 의도하지 않게 나머지 환경도 변경됩니다.

Active Directory 충돌을 방지하려면 AD 서버가 환경 내부의 가상 컴퓨터에서 호스트되어야 합니다. AD 서버는 외부 환경의 다른 디렉터리와 신뢰 관계가 없어야 합니다.

네트워크 격리 환경 내부에 AD를 설정하기 위해서는 다음과 같은 사항을 추가로 고려해야 합니다. 첫 번째, AD 가상 컴퓨터가 공용 네트워크에 연결되지 않아야 합니다. 두 가지 인터페이스 방식에서 이는 AD 가상 컴퓨터에 공용 인터페이스가 있지 않음을 의미합니다. 그리고 2방향 NAT 방식에서는 AD 가상 컴퓨터에 대한 매핑이 NAT 테이블에 포함되지 않음을 의미합니다.

두 번째, AD는 독립 포리스트에 속하므로 DNS 서버가 내부 환경에 있어야 합니다. 환경의 나머지 가상 컴퓨터는 AD와 올바른 통신을 위해 개인 네트워크의 이 DNS 서버를 사용해야 합니다. 예를 들어 개인 인터페이스에 DNS 서버 설정이 올바르게 구성되어 있지 않으면 가상 컴퓨터가 개인 AD의 도메인에 가입하지 못할 수 있습니다.

AD 가상 컴퓨터를 포함하도록 환경을 구성하면 Visual Studio Lab Management는 자동으로 공용 네트워크에서 AD 연결을 해제하고 DNS 설정을 사용하여 가상 컴퓨터의 개인 인터페이스를 구성합니다.

환경 내부에서 AD를 호스트할 수 없는 경우가 있을 수 있습니다. 예를 들면, 개발 중인 응용 프로그램을 기존의 다른 회사 응용 프로그램과 통합하기 위해 회사 AD를 사용해야 하는 경우에 해당합니다. 컴퓨터가 외부 환경의 도메인에 가입된 경우 환경을 안전하게 복제할 수 있는 방법은 없습니다.

데이터베이스 충돌

가상 환경은 외부 환경에 있는 응용 프로그램 데이터베이스를 호스트하는 목적으로도 일반적으로 사용됩니다. 일반적으로 데이터베이스가 너무 커서 데이터베이스를 모든 환경에 복제할 수 없는 경우가 해당됩니다. 또한 개발 중인 응용 프로그램이 다른 곳에서 호스트되는 데이터베이스와 상호 작용하는 간단한 웹 클라이언트인 경우도 해당됩니다. 이러한 경우 동일한 두 개의 복제본이 데이터베이스와 상호 작용할 때 데이터베이스 서버는 두 클라이언트의 ID를 구분할 수 없습니다.

요약

가상 환경과 동일한 복제본을 만드는 기능은 가상 랩 관리의 여러 가지 시나리오에서 필수적입니다. 하지만 동일한 복제본이 만들어지면 컴퓨터 이름, IP 주소 및 MAC 주소 충돌이 발생합니다. 컴퓨터 이름이나 IP 주소 변경 등의 간단한 기술로 이러한 충돌을 해결할 경우에는 대개 응용 프로그램을 다시 구성하거나 설치해야 하므로 결과적으로 동일한 복제본을 만드는 목적인 효율성이 무산됩니다. 네트워크 격리는 두 복제본을 동시에 만들어 실행할 수 있도록 함으로써 이 문제를 해결합니다.

다음 단계

SCVMM 환경 계획: 실행 중인 가상 컴퓨터, 저장된 가상 컴퓨터, 템플릿, 저장된 환경 및 네트워크 격리 사용 등과 같은 SCVMM 환경을 계획하기 위한 여러 가지 방법에 대해 알아봅니다. SCVMM 환경을 만들고 관리하기 위한 지침을 참조하세요.

네트워크 격리 환경 만들기: 네트워크 격리 환경을 만들 준비가 된 경우 이 항목을 사용합니다. 네트워크 격리 환경 만들기 및 사용을 참조하세요.

참고 항목

시스템 테스트 자동화

다음을 통해 공유