Windows Server 2012 Hyper-V, 보다 완벽한 멀티 테넌트를 위해, 네트워크 가상화(Network Virtualization) : IP Rewrite, NVGRE

지난 포스팅에서 멀티 테넌트를 위한 가상 네트워크의 향상, 첫번째 이야기로, PVLAN(Private VLAN)과 기본 보안 기능에 대해서 살펴보았습니다. 오늘은 조금 더 나아가, 네트워크 가상화 기술을 살펴보려고 합니다. 지금까지의 가상화는 운영 체제 레벨의 가상화를 집중하였지만, 클라우드 컨셉, 그리고 더 큰 규모의 인프라를 서비스 형태로 꾸미다보면, 네트워크 레벨에 대한 접근이 필수적으로 같이 요구됩니다. 위의 그림내 오른쪽처럼, 두개의 네트워크가 하나의 클라우드 인프라내에 입주할 경우에 여러 문제보다 가장 먼저 발생하는 이슈가 네트워크에 대한 부분입니다.

가장 좋은 예로 두 회사가 같은 네트워크 서브넷을 사용한다면 어떻게 될까요?

Windows Server 2008 R2의 Hyper-V를 이용한다면, 별도의 NIC을 분리하고, 이에 대한 스위치도 별도로 구축하는 절차를 밟아야 합니다만, Windows Server 2012의 경우에는 다른 형태의 이야기가 됩니다. 바로 네트워크 가상화를 가상 스위치 레벨에서 제공하여, 동일한 서브넷 여러 개가 같은 가상 스위치에 분리된 형태로 배치됩니다.

Hyper-V에서 네트워크 카드를 가상 스위치로 구성하게 되면, 네트워크 카드의 속성에서는 스위치 속성을 제외하곤 모두 해제가 되게 됩니다. 쉽게는 스위치가 된다고 보시면 됩니다. 그리고 물리적인 머신에도 가상의 NIC이 생성되어져서, 해당 스위치에 연결되게 되는 것이죠. 이러한 이유로 Hyper-V 관리 도구에서 가상 스위치 관리자라는 단어가 사용되는 것입니다.

Windows Server 2008 R2까지의 가상 스위치는 허브(HUB) 컨셉이었습니다. 그렇기에, VM에서 여러 모니터링 도구를 열어보면, 타 VM의 작업이 눈에 보이기도 하였고, 추가적인 스위치 기술을 적용할 수도 없었죠. Windows Server 2012의 가상 스위치는 이제 진정한 가상 스위치의 형태를 띄기에, PVLAN, 네트워크 가상화, 그리고 타 기술 벤더의 확장이 가능해진 형태가 되었습니다. 네트워크 가상화를 이용하기 위해서는 해당 가상 네트워크 스위치에 옵션에서 “Windows 네트워크 가상화 필터 드라이버”를 활성화시켜줘야 합니다. (해당 내용은 SCVMM 2012 SP1 CTP2 문서에도 나와 있습니다.)

두 회사의 경우를 예를 들어 설명하겠습니다.

BLUE의 경우에도 10.0.0.0/24, RED의 경우에도 10.0.0.0/24의 네트워크를 사용하는 형태로 클라우드 환경으로 이전되면, 두 서브넷은 완벽하게 충돌이 발생하게 됩니다. 하나의 물리적인 Hyper-V에 통합되었다면, PVLAN을 이용해서 어떻게 해볼 수 있지만, 인프라가 커져서 여러 물리적인 서버에 나눠져 배치되어 있다면, 이야기는 더 복잡해집니다. 여기서 바로 네트워크 가상화 기술이 필요합니다. 아래의 그림이 해당 예제가 됩니다.

여기서 Hyper-V는 IP 주소 처리를 위해 2가지 기술(IP Rewrite, NVGRE)와 전체 IP 대역을 총괄해주는 가상화 정책 서버(VPS, Virtualization Policy Server, 현재는 SCVMM 2012 SP1)이 필요합니다.

위의 그림에서 Address(IP 주소)가 2가지 존재합니다. 하나는 Provider Address(PA)이며, 하나는 실제 VM에서 사용하는 Customer Address(CA)입니다. 먼저 IP Rewrite를 살펴보면, NAT(Network Address Translation)과 유사한 형태입니다. 실제 물리적인 Hyper-V 머신간 사용할 수 있는 데이터 센터내 PA가 여러개인 경우, VM에서 사용하는 CA와 1:1로 맵핑해서 사용하는 방식입니다. 이 맵핑된 테이블을 VPS에서 저장하여 중간에서 조율해주는 형태이죠.

Hyper-V내에 VM에는 소속된 서브넷과 IP 정보를 가진 속성을 가지고 있습니다. 이 속성을 관리해주는 것이 바로 SCVMM이 현재 하는 일입니다.

SCVMM 2012 SP1의 클라우드 패널에 가보면, 기존 RTM 버전에는 없던 항목이 하나 더 생겨있습니다. 바로 VM Networks라는 항목입니다. 해당 네트워크를 원하는 영역 이름과 이에 소속된 서브넷 형태로 만들어 둡니다. 내부에서 사용하는 IP Pool이 앞서 설명드린 CA가 되는 것이고, 해당 네트워크에 연결되어진 Hyper-V의 NIC에서 사용하는 IP Pool이 PA가 되는 것입니다.

이렇게 만들어진 네트워크를 VM에서 연결하여 사용할 수 있도록 별도의 항목을 VM 네트워크 속성에서 추가해놓았습니다.

위의 그림은 BLUE NETWORK의 192.168.1.0 서브넷을 사용한다고 배정한 것이죠.

SCVMM PowerShell을 이용하여 GET-SCIPAddress 커맨드릿을 사용해보면, 내부 Hyper-V간 교신을 위해 PA를 배정한 모습을 볼 수 있습니다. 이런 형태로 다수의 PA와 다수의 CA를 맵핑하여, Hyper-V간 서로 네트워크를 가능하게 한 기술의 이름을 IP Rewrite라고 합니다.

이런 의문이 들 수 있습니다. PA가 몇개 없다면.. VM이 많아질수록 IP Rewrite는 PA의 숫자가 늘어나야 합니다. 이 숫자가 한정되어져 있는 경우엔 어떻게 해야 할까요? 바로 NVGRE(Network Virtualization Generic Routing Encapsulation)이 이용됩니다.

표준 방식의 GRE를 이용하여, VM간 교신 구분을 위해 GRE 키와 MAC 주소를 추가합니다. 이를 이용하여 어떤 머신간의 교신인지를 구분하여 처리해주는 것을 NVGRE라고 부릅니다.

NVGRE를 이용하기 위해서는 SCVMM PowerShell을 이용하여, 서브넷 속성을 변경해주거나, 생성시 지정해야 합니다. 바로 VMSubnetType 속성을 “GREWindowsNetworkVirtualization”으로 지정하면 동일한 형태로 구성됩니다.

네트워크 가상화를 운영하기 위해서는 Hyper-V와 더불어 전체 네트워크 테이블을 관리하는 정책 서버가 필수적입니다. 현재는 SCVMM 2012 SP1 만이 여기에 해당되지만, 차후에는 네트워크 장비나 Windows Server 2012의 IPAM(IP Address Management, 차후 포스팅 예정 )에도 기능이 제공되어, 분리된 네트워크간 라우팅이나 스위칭, 그리고 DHCP 처리등을 담당하게 될 것입니다.

네트워크 가상화로 구성되어져 있는 경우, 특정 VM에서 뿌려진 브로드캐스트 메시지는 브로드캐스트 형태로 전달되는 것이 아니라, 브로드캐스트를 시도한 것을 감지한 Hyper-V가 정책 서버에 같은 서브넷내 서버들 정보를 받아내어, 일반 1:1 교신 형태로 전달하게 됩니다. 이에 브로드캐스트를 처리해야 하는 기술, 대표적으로 DHCP의 경우엔 IP 주소를 기본 설정만으로 구성할 수가 없습니다. 따라서 브로드캐스트를 사용하는 형태(현재는 DHCP가 CTP2에 포함되어져 있습니다.)는 네트워크 가상 스위치에 DHCP 패킷을 인지하고, 넘겨주는 확장 필터를 설치해야 합니다.

SCVMM 2012 SP1 CTP2 미디어내 MSI 폴더에 들어가보면 DHCPExtension이라는 폴더가 있습니다. 이 안의 설치파일을 DHCP 패킷을 처리해줄 Hyper-V 머신에서 설치해야 하며, 설치 후, 가상 스위치 확장에서 해당 필터를 사용 가능하게 변경해야 합니다.

이 필더가 CTP1에서는 제공되지 않았기에, 네트워크 가상화 테스트 시나리오가 고정 IP만을 제시했던 것입니다.

복잡하고 긴 이야기인 네트워크 가상화에 대해서, 오늘은 살펴보았습니다. 요새 많이 느끼는 점이지만, 해당 부분은 지금까지 Windows 관리자 분들께서는 신경쓰지 않았던 네트워크에 대한 부분이지만, 클라우드 컨셉에서 네트워크와 운영 체제는 동일한 관점에서 접근해야 하기에, 필요한 부분이 많아졌습니다. 이에 조금은 네트워크에 대한 부분도 살펴보실 시점이 되었다고 생각합니다.

System Center 2012의 경우에는 SP1 버전에서 Windows Server 2012를 기본적으로 지원할 예정이며, 이는 Windows Server 2012가 정식 릴리즈후, 빠르게 SP1도 릴리즈될 것입니다. 현재는 베타 버전의 형태인 CTP2가 제공되고 있습니다. (관련 포스팅)

Comments

• Anonymous
  January 08, 2014
  가상서버가 인터넷구간을 통과 해서 client와 통신할 때에도 GRE프로토콜을 사용할 것 같진 않은데요..물리적인 한 서버에 있는 A VM, B VM이 동일 IP를 사용한다고 했을 때, client에서 오는 패킷이 A VM것인지 B VM것인지 어떻게 구분하나요?
• Anonymous
  January 08, 2014
  Anonymous님 // 안녕하세요.. 네트워크 가상화내에 있는 VM이 외부 클라이언트..와 교신하는 방법은 두가지가 있습니다. 말씀하신 인터넷 구간이라면.. 당연히 서브넷을 벗어나므로, NAT용 라우터가 필요합니다. 해당 라우터는 WS2012 R2로 구성하는 소프트웨어 방식과 네트워크 회사에서 제공하는 어플라이언스 형태가 있습니다. 두 VM이 같은 IP를 내부적으로 사용하더라도, NAT를 통과할 때, IP는 변경되게 되고, 해당 VM에 대한 정보를 NAT과 관리하므로, 클라이언트는 NAT 장비 이외의 IP 정보는 가지지 못하게 되겠죠. 클라이언트는 구분할 필요가 없으며, 해당 사항은 NAT가 해줄 일입니다.더불어, 인터넷이 아닌, 내부 네트워크내 다른 서브넷의 경우에는.. NAT 형태가 아닌 Forwarder 형태의 라우터가 필요합니다. (서브넷이 틀리므로.. 역시나 당연한.) 이 경우 A VM가 B VM은 같은 IP 주소를 가지게 되기에, 반대측 클라이언트에는 구분할 수 있는 방법이 없습니다. 이에 동일 IP로 구성된 VM의 경우 내부 네트워크에서 상호 교신.. 혹은 다른 서버나 클라이언트와 개별 교신을 직접 해야 하는 경우라면, 동일 IP를 사용해서 구성하시면 안됩니다. Forwarder 라우터의 경우에는 A VM과 B VM을 VirtualSubNetID로 구분할 수 있지만.. 대상 클라이언트나 서버에선 IP 이외 정보를 가지지 못하므로, 구분할 수 없는 형태입니다. 이는 네트워크 가상화가 아니더라도.. VLAN으로 나누어진 서브넷의 경우에도 동일한 고민을 해야 합니다.좋은 질문 감사합니다!