[Dongclee의 2012년 3월 8번째 포스팅 (no Step-By-Step 가이드)] Windows Server 8 Hyper-V Advanced 기능 2 : Network Virtualization

  • Article

계속해서 Hyper-V 8의 Network Virtualization 기능을 소개합니다.

Hyper-V Network Virtualization ( https://technet.microsoft.com/en-us/library/hh831395.aspx )

가상화 데이터 센터가 성공하기 위해서, “IT 조직” 및 “호스팅 제공자 (colocation 또는 물리적 서버 임대를 제공하는 사업자)”는 고객이 요청하는 시점에 서버를 쉽게 제공할 수 있는 유연한 가상화 인프라를 제공해야 합니다. 이러한 서비스를 최근에 “IaaS (Infrastructure as a Service)” 라고 합니다. Windows Server 8에서, 기업 고객이 사설 클라우드 구축 및 IaaS 운영으로 전환하기 위해 필요한 모든 플랫폼 기능을 제공됩니다. 또한, 호스트 제공자가 공용 클라우드 구축 및 고객에게 IaaS 솔루션을 제공하기 위해 필요한 모든 플랫폼 기능을 Windows Server 8이 제공합니다.

Windows Server 8의 네트워크 가상화는 policy-based 및 software-controlled 네트워크 가상화 기능을 제공합니다. 기업 고객들이 전용 IaaS 클라우드를 확장하고자 할 때, policy-based 및 software-controlled 네트워크 가상화는 기업 고객들이 직면한 관리 오버헤드를 상당 부분 감소시킬 수 있습니다. 또한, 네트워크 가상화는 “클라우드 호스트 사업자를 위한 더 나은 유연성”, “가상 기계 관리를 위한 확장성”, “높은 자원 사용률” 과 같은 장점을 제공합니다.

Problem)

전용 클라우드 또는 호스티드 클라우드 상의 다중 가상 기계들이 존재하는 IaaS는 네트워크 상에서 가상 기계들의 “안전한 고립 (secure isolation)”이 중요합니다. 이러한 상황을 해결하기 위해, IaaS 사업자들은 대부분 VLAN을 사용합니다. VLAN은 이더넷 프레임에서 명백한 태깅을 사용합니다. 가상 기계의 고립을 설정하기 위해서, VLAN은 이더넷 스위치의 협조가 반드시 필요합니다. 또한, 동일 태그를 소유한 가상 기계들의 트래픽 제한도 역시 이더넷 스위치의 협조가 필요합니다.

VLAN 사용의 단점은 아래와 같습니다:

  • 데이터 센터 내에서 가상 기계의 이동 또는 “고립 경계 (isolation boundary)”의 변경이 있을 경우에, 상용 이더넷 스위치의 재구성으로 인한 전체 시스템의 다운타임 증가
  • 전형적인 스위치는 1,000 VLAN ID 이상(최대 4,094)을 지원하지 못 하기 때문에 발생하는 확장성 제한
  • VLAN은 다중 논리적 서브넷으로 확장될 수 없습니다. 다중 논리적 서브넷은 단일 VLAN 내에서 노드 개수를 제한합니다. 또한, 다중 논리적 서브넷은 물리적 위치에 기반한 가상 기계의 배치를 제한합니다. VLAN이 물리적인 인트라넷 상에서 확장할 수 있더라도, 확장된 VLAN은 모두 동일 서브넷에 있어야 합니다.

VLAN 사용의 단점 이외에, 가상 기계 IP 주소 할당은 아래와 같은 중요한 문제점을 유발합니다:

  • 가상 기계를 클라우드 플랫폼으로 이동은 정상적인 서비스를 위한 IP 주소의 재할당 작업이 요구됩니다.
  • 기존 가상 기계에 할당되었던 각종 IP 주소 관련 정책(ex, 보안, 관리 기타 등등)을 다시 설정해야 합니다.
  • 가상 기계가 존재하는 “물리적인 위치(ex, Hyper-V 호스트 랙 위치)”에 따라 가상 기계 IP 주소를 지정해야 합니다. 즉, 기존 가상 기계에 할당된 IP 주소를 사용할 수 없으므로, 데이터 센터 내의 Hyper-V 호스트 위치에 따라 IP 주소를 재할당해야 합니다.

Solution)

Windows Server 8의 네트워크 가상화는 앞서 살펴본 VLAN의 제약 사항을 해결할 수 있습니다. 또한, 가상 기계의 IP 주소 할당에서 발생하는 전통적인 문제점도 상당 부분 해결할 수 있습니다. 네트워크 가상화를 사용하면, 고객에게 IaaS 클라우드 컴퓨팅 구축을 쉽게 제공합니다. 또한, 호스팅 사업자 및 데이터 센터 관리자에게 손 쉬운 IaaS 클라우드 컴퓨팅 관리를 제공합니다. 추가적으로, 네트워크 가상화는 필수 multitenant 고립 및 보안 요구 사항을 관리할 수 있습니다. Windows Server 8의 네트워크 가상화의 장점은 아래와 같습니다:

  • Uncouples workloads from internal IP addresses. 서비스를 공유 Iaas 클라우드 플랫폼으로 이동하는 동안, 가상 기게 내부 IP 주소를 그대로 유지할 수 있습니다. 이러한 내부 IP 주소로부터 서비스를 분리하는 것은 IP 주소, DNS 이름, 보안 정책 및 가상 기계 설정과 같은 구성 변경 사항을 최소화할 수 있는 장점이 있습니다.
  • Decouples server and network administration. 서비스의 마이그레이션 및 배치는 물리적 네트워크 구성과는 독립적이기 때문에, 서버의 서비스 배치는 단순화됩니다. 서버 관리자는 서비스 및 서버의 관리에 집중할 수 있는 장점도 제공합니다. 반면에, 네트워크 관리자는 전체 네트워크 인프라 및 트래픽 관리에 집중할 수 있습니다. 즉, 네트워크 관리자 및 서버 관리자는 가상 기계의 네트워크 설정과 같은 업무에서 해방될 수 있습니다.
  • Removes the tenant isolation dependency on VLANs. 정책 기반 및 소프트웨어 정의 기반의 데이터 센터 네트워크에서, 네트워크 트래픽 고립은 더 이상 VLAN에 의존하지 않습니다. Multitenant 고립 정책에 기반한 Hyper-V 호스트를 사용하여 네트워크 트래픽 고립을 구현할 수 있습니다. 네트워크 관리자는 물리적 인프라 트래픽 관리를 위해 여전히 VLAN을 사용할 수도 있습니다.
  • Enables flexible workload placement. 서비스 및 워크로드는 데이터 센터 내의 임의의 서버에 위치 및 마이그레이션 될 수 있습니다. 서비스 및 워크로드는 자신의 IP 주소를 유지할 수 있고, 물리적 IP 서브넷 또는 VLAN 구성에 구애 받지 않습니다.
  • Simplifies the network and improves server and network resource utilization. 물리적 네트워크 인프라 상의 가상 기계 배치 종속성 및 VLAN 의 엄격함은 overprovisioning 및 underutilization 을 초래합니다. 이러한 종속성을 깨뜨림으로써, 가상 가계 워크로드 배치의 유연성 확대는 네트워크 관리를 단순화할 수 있고, 서버 및 네트워크 자원 사용률을 증가시킬 수 있습니다.
  • Works with existing infrastructure and emerging technology. 네트워크 가상화는 현재 데이터 센터 환경 내에서도 구축할 수 있습니다. “Flat Network” 기술과 네트워크 가상화는 호환됩니다. “Flat Network” 기술의 대표적인 예는 바로 Transparent Interconnection of Lots of Links (TRILL) 입니다.
  • Supports configuration by using Windows PowerShell and WMI. 관리 업무의 자동화 및 스크립팅 활성화를 위해 Windows PowerShell을 사용할 수 있습니다.

Windows Server 8의 네트워크 가상화는 Windows Server 8의 Hyper-V 역할만 활성화하면 구성할 수 있습니다.

통상적으로, 서버 가상화는 단일 가상화 호스트에서 여러 개의 가상 기계를 동시에 운영하는 것을 의미합니다. 이러한 서버 가상화에서, 각 가상 기계들이 마치 물리적인 서버들과 같이 각기 서버들이 서로 분리되어 운영됩니다. 네트워크 가상화는 이러한 서버 가상화와 유사한 개념입니다. 관리자는 다중 가상 네트워크 인프라를 운영할 수 있습니다. 다중 가상 네트워크 인프라를 운영하기 때문에, 동일 물리적 네트워크 상에서 IP 주소가 겹칠 수도 있습니다. 네트워크 가상화를 사용하게 되면, 하나의 물리적 네트워크 인프라를 각 가상 네트워크 인프라는 자신의 전용 네트워크 인프라처럼 사용할 수 있습니다. 다음 그림이 네트워크 가상화의 개념도입니다.

 

Windows Server 8의 네트워크 가상화를 사용하기 위해서는, 각 가상 기계는 2개의 IP 주소가 할당됩니다.

  • CA (Customer Address) IP 주소 : CA는 가상 기계를 사용하는 고객들이 할당하는 IP 주소입니다. 이 주소는 고객들의 가상 기계에 할당되어, 가상 기계들이 서로 네트워크 트래픽을 교환하는데 사용됩니다. 즉, 이 주소는 가상 기계가 공용 및 사설 클라우드로 옮겨지더라도 지속적으로 유지되는 고객들의 전용 IP 주소입니다. 이 CA IP 주소는 가상 기계에서만 확인할 수 있고, 고객들만이 접근 가능합니다.
  • PA (Provider Address) IP 주소 : PA IP 주소는 호스팅 사업자에 의해 제공됩니다. 즉, 호스팅 사업자의 물리적 네트워크 인프라에서 할당되는 주소입니다. 이 주소는 물리적 네트워크 즉, Hyper-V 호스트에서만 보여지고, 가상 기계에서는 확인할 수 없는 주소입니다.

CA IP 주소는 네트워크 가상화를 통해 할당된 가상 네트워크 인프라에서만 유지되는 주소이고, 실제 물리적 네트워크 또는 물리적 네트워크 주소와는 완전히 별개로 유지됩니다.

가상 기계의 IP 주소를 가상화하기 위해서는 2개 기술이 있습니다. 하나의 기술은 “IP Rewrite” 입니다. 네트워크 패킷이 실제 네트워크를 통해 전송되기 전에, 가상 기계의 CA IP를 통해 보내지는 네트워크 패킷을 수정하는 것이 “IP Rewrite” 기술입니다. IP Rewrite 기술은 VMQ (Virtual Machine Queue)와 같은 네트워크 오프로딩 기술을 사용하기 때문에 성능 측면에서 장점이 있습니다.

또 다른 기술은 “IP Encapsulation (IP 압축) ” 입니다. 네트워크 패킷이 실제 네트워크를 통해 전송되기 전에, 가상 기계의 모든 패킷이 새로운 헤더를 가진 패킷으로 encapsulate 됩니다. 특정 Hyper-V 호스트 상의 모든 가상 기계는 동일 사업자 IP 주소를 공유하기 때문에, “IP Encapsulation” 기술은 확장성 측면에서 장점이 있습니다. “가상 기계 (세입자:Tenant)”들은 압축 패킷의 헤더를 조사함으로써 구분될 수 있고, 압축 패킷의 헤더는 각 가상 기계의 네트워크 ID가 포함되어 있습니다. 모든 가상 기계들이 사업자 IP 주소를 공유하기 때문에, 스위칭 인프라는 실제 물리적 네트워크에서 유지하는 IP 주소만 고려하면 됩니다. 즉, 스위치가 이러한 사업자 IP 주소만을 유지함으로써, 스위치가 유지하는 IP/MAC 테이블의 크기가 감소됩니다. 대형 IP/MAC 테이블의 스위치 성능 감소의 가장 결정적인 요소입니다. 결국, 대형 IP/MAC 테이블을 유지하기 위해서는 값비싼 고성능의 스위치가 필요합니다.

Windows Server 8의 네트워크 가상화를 사용하게 되면, 임의의 가상 기계는 별도의 네트워크 수정 없이 임의의 물리적 네트워크로 손 쉽게 이동할 수 있습니다. 이러한 네트워크 가상화를 구성하기 위해서, CA IP 주소와 PA IP 주소를 매핑하는 정책 설정이 Windows Server 8의 Hyper-V 에서 필요합니다. 이러한 네트워크 가상화는 아래와 같은 장점이 제공됩니다.

    • 서브넷 간의 라이브 마이그레이션 : 라이브 마이그레이션 후에 필요할 수 있는 네트워크 설정이 필요없음
    • 호스팅 사업자는 IPv6 주소를 유지하고, 고객들의 가상 기계는 IPv4 주소만을 유지할 때도, 가상 기계는 IPv6 주소로 통신할 수 있고, 이러한 환경의 vice-versa 도 가능합니다. 즉, IPv6 네트워크 와 IPV4 네트워크 간의 통신도 별도의 네트워크 수정이 필요없음
    • CA IP 주소의 겹침 현상도 전혀 문제가 되지 않음

위 그림을 통해, 예제 네트워크 가상화를 살펴 보도록 하겠습니다.

호스팅 사업자의 공용 IaaS 서비스로 서버들을 옮기기 전에, Blue Corp 및 Red Corp는 다음과 같은 서버를 운영하고 있습니다. 즉, Blue Corp 및 Red Corp 는 각기 아래와 같이 동일한 네트워크 이름 및 IP 주소를 사용하고 있는 상황입니다.

  • A SQL Server (named SQL) at the IP address 10.1.1.1.
  • A web server (named WEB) at the IP address 10.1.1.2, that uses its SQL Server for database transactions.

Blue Corp 및 Red Corp는 위 서버들을 공용 IaaS 서비스로 옮기기로 결정했고, 위 그림과 같이 Hyper-V Host1 에는 각 사의 SQL 서버가 위치하고, Hyper-V Host2 에는 각 사의 WEB 서버가 위치합니다. Iaas 서비스로 각 사의 서버가 옮겨진 이후에도, 여전히 각 서버는 자신의 IP, 즉 CA IP 주소를 그대로 유지합니다. 호스팅 사업자는 Blue Corp 및 Red Corp 사의 각 서버들을 위해 아래와 같이 PA IP 주소를 각각 할당합니다.

  • Provider addresses for Blue Corp virtual machines: SQL is 192.168.1.10, WEB is 192.168.1.12
  • Provider addresses for Red Corp virtual machines: SQL is 192.168.1.11, WEB is 192.168.1.13

호스팅 사업자는 이러한 환경에서 Blue Corp 및 Red Corp 사의 서버에 별도의 네트워크 수정 없이 실제 서비스를 할 수 있도록 네트워크 가상화를 제공합니다. 네트워크 가상화를 제공하기 위해, 앞서 언급한 대로 Hyper-V Host 1 및 Hyper-V Host 2를 위한 “정책 설정”이 필요합니다. 아래 테이블의 본 예제 환경을 위한 “정책 설정”입니다.

 

위와 같이 “Blue Corp” 및 “Red Corp” 이라는 “고립 그룹 (Isolation Group)”을 생성하고, 각 “고립 그룹”에는 위 가상 기계의 네트워크 통신을 위한 CA IP 주소와 PA IP 주소 매핑 설정이 포함됩니다.

Hyper-V Host 2 상의 Blue Corp WEB 가상 기계가 10.1.1.1 주소를 가진 SQL 서버에 질의하게 되면, 아래와 같은 네트워크 패킷 흐름이 발생합니다:

 

  1. “정책 설정”에 기반하여, Hyper-V Host 2는 패킷의 전송을 아래와 같이 시작합니다:
    • Source: 10.1.1.2 (the customer address of Blue Corp WEB)
    • Destination: 10.1.1.1 (the customer address of Blue Corp SQL)
  2. Hyper-V Host 2 는 위 CA 주소를 아래와 같이 PA IP 주소로 전환합니다:
    • Source: 192.168.1.12 (the provider address for Blue Corp WEB)
    • Destination: 192.168.1.10 (the provider address for Blue Corp SQL)
  3. “정책 설정”에 기반하여, Hyper-V Host 1 이 패킷을 받았을 때, 패킷이 아래와 같이 전달됩니다:
    • Source: 192.168.1.12 (the provider address for Blue Corp WEB)
    • Destination: 192.168.1.10 (the provider address for Blue Corp SQL)
  4. Hyper-V Host 1 는 위 3번의 PA IP 주소를 아래와 같이 CA IP 주소로 전환합니다:
    • Source: 10.1.1.2 (the customer address of Blue Corp WEB)
    • Destination: 10.1.1.1 (the customer address of Blue Corp SQL)
  5. Hyper-V Host 1 는 Blue Corp SQL 가상 기계에 패킷을 전달합니다.

 

Hyper-V Host 1 상의 Blue Corp SQL 가상 기계가 위 질의에 대한 응답을 할 때, 아래와 같은 네트워크 흐름이 발생합니다:

 

  1. “정책 설정”에 기반하여, Hyper-V Host 1는 패킷의 전송을 아래와 같이 시작합니다:
    • Source: 10.1.1.1 (the customer address of Blue Corp SQL)
    • Destination 10.1.1.2 (the customer address of Blue Corp WEB)
  2. Hyper-V Host 1 는 위 CA 주소를 아래와 같이 PA IP 주소로 전환합니다:
    • Source: 192.168.1.10 (the provider address for Blue Corp SQL)
    • Destination: 192.168.1.12 (the provider address for Blue Corp WEB)
  3. “정책 설정”에 기반하여, Hyper-V Host 2 이 패킷을 받았을 때, 패킷이 아래와 같이 전달됩니다:
    • Source: 192.168.1.10 (the provider address for Blue Corp SQL)
    • Destination: 192.168.1.12 (the provider address for Blue Corp WEB)
  4. Hyper-V Host 2 는 위 3번의 PA IP 주소를 아래와 같이 CA IP 주소로 전환합니다:
    • Source: 10.1.1.1 (the customer address of Blue Corp SQL)
    • Destination: 10.1.1.2 (the customer address of Blue Corp WEB)
  5. Hyper-V Host 2 는 Blue Corp WEB 가상 기계에 패킷을 전달합니다.

 

위와 같이 네트워크 가상화를 사용하게 되면, Blue Corp 및 Red Corp 의 가상 기계들은 마치 자신의 전용 네트워크 인프라에서 운영되는 것처럼 보여집니다. Blue Corp 및 Red Corp의 가상 기계들의 CA IP 주소가 동일하더라도, 네트워크 통신에 전혀 문제가 없습니다. 또한, Blue Corp 및 Red Corp 가상 기계들은 VLAN 설정이 없더라도 자사 가상 기계들의 네트워크 트래픽은 철저하게 고립되어 통신됩니다.