Windows Server의 Hyper-V 네트워크 가상화 기술 세부 정보

적용 대상: Windows Server 2022, Windows Server 2019, Windows Server 2016, Azure Stack HCI, 버전 21H2 및 20H2

서버 가상화를 사용하면 단일 실제 호스트에서 동시에 여러 서버 인스턴스를 실행할 수 있지만 서버 인스턴스는 서로 격리됩니다. 각 가상 머신은 기본적으로 해당 가상 머신이 실제 컴퓨터에서 실행되는 유일한 서버인 것처럼 작동합니다.

네트워크 가상화는 동일한 실제 네트워크 인프라에서 여러 가상 네트워크(잠재적으로 겹치는 IP 주소 포함)가 실행되고 각 가상 네트워크가 공유 네트워크 인프라에서 실행되는 유일한 가상 네트워크인 것처럼 작동하는 유사한 기능을 제공합니다. 그림 1에서는 이 관계를 보여 줍니다.

Server virtualization versus network virtualization

그림 1: 서버 가상화 대 네트워크 가상화

Hyper-V 네트워크 가상화 개념

HNV(Hyper-V 네트워크 가상화)에서 고객 또는 테넌트는 엔터프라이즈 또는 데이터 센터에 배포된 IP 서브넷 집합의 "소유자"로 정의됩니다. 고객은 네트워크 격리가 필요한 개인 데이터 센터의 여러 부서 또는 사업부가 있는 기업 또는 기업이거나 서비스 공급자가 호스팅하는 공용 데이터 센터의 테넌트일 수 있습니다. 각 고객은 데이터 센터에 하나 이상의 가상 네트워크를 가질 수 있으며 각 가상 네트워크는 하나 이상의 가상 서브넷으로 구성됩니다.

Windows Server 2016에는 HNVv1 및 HNVv2라는 두 가지 HNV 구현이 있습니다.

  • HNVv1

    HNVv1은 Windows Server 2012 R2 및 System Center 2012 R2 VMM(Virtual Machine Manager)과 호환됩니다. HNVv1에 대한 구성은 WMI 관리 및 Windows PowerShell cmdlet(System Center VMM을 통해 촉진됨)을 사용하여 격리 설정 및 CA(고객 주소) - 가상 네트워크 - PA(물리적 주소) 매핑 및 라우팅을 정의합니다. Windows Server 2016에서는 추가 기능이 HNVv1에 추가되지 않았으며 새로운 기능은 계획되지 않았습니다.

    • SET 팀 및 HNV V1은 플랫폼에서 호환되지 않습니다.

    o HA NVGRE 게이트웨이를 사용하려면 사용자가 LBFO 팀 또는 No 팀을 사용해야 합니다. 또는

    o SET 팀 스위치를 사용하여 네트워크 컨트롤러 배포 게이트웨이를 사용합니다.

  • HNVv2

    Hyper-V 스위치의 Azure VFP(가상 필터링 플랫폼) 전달 확장을 사용하여 구현되는 HNVv2에는 많은 수의 새로운 기능이 포함되어 있습니다. HNVv2는 SDN(소프트웨어 정의 네트워킹) 스택에 새 네트워크 컨트롤러를 포함하는 Microsoft Azure Stack과 완전히 통합됩니다. 가상 네트워크 정책은 RESTful NorthBound(NB) API를 사용하여 Microsoft 네트워크 컨트롤러 를 통해 정의되며 OVSDB를 포함한 여러 SBI(SouthBound Interfaces)를 통해 호스트 에이전트에 배관됩니다. 호스트 에이전트는 적용되는 Hyper-V 스위치의 VFP 확장에서 정책을 프로그래밍합니다.

    Important

    이 항목에서는 HNVv2에 중점을 둡니다.

가상 네트워크

  • 각 가상 네트워크는 하나 이상의 가상 서브넷으로 구성됩니다. 가상 네트워크는 가상 네트워크 내의 가상 머신이 서로만 통신할 수 있는 격리 경계를 형성합니다. 일반적으로 이 격리는 분리된 IP 주소 범위와 802.1q 태그 또는 VLAN ID가 있는 VLAN을 사용하여 적용되었습니다. 그러나 HNV를 사용하면 고객 또는 테넌트 간에 IP 서브넷이 겹칠 수 있는 오버레이 네트워크를 만들기 위해 NVGRE 또는 VXLAN 캡슐화를 사용하여 격리가 적용됩니다.

  • 각 가상 네트워크에는 호스트에 고유한 RDID(라우팅 Do기본 ID)가 있습니다. 이 RDID는 대략 리소스 ID에 매핑되어 네트워크 컨트롤러에서 가상 네트워크 REST 리소스를 식별합니다. 가상 네트워크 REST 리소스는 추가된 리소스 ID와 함께 URI(Uniform Resource Identifier) 네임스페이스를 사용하여 참조됩니다.

가상 서브넷

  • 가상 서브넷은 동일한 가상 서브넷 내의 가상 컴퓨터에 대해 계층 3 IP 서브넷 의미 체계를 구현합니다. 가상 서브넷은 브로드캐스트를 형성하고기본(VLAN과 유사) NVGRE TNI(테넌트 네트워크 ID) 또는 VXLAN 네트워크 식별자(VNI) 필드를 사용하여 격리를 적용합니다.

  • 각 가상 서브넷은 RDID(단일 가상 네트워크)에 속하며 캡슐화된 패킷 헤더의 TNI 또는 VNI 키를 사용하여 고유한 VSID(가상 서브넷 ID)가 할당됩니다. VSID는 데이터 센터 내에서 고유해야 하며 범위는 4096에서 2^24-2입니다.

가상 네트워크 및 라우팅의 주요 장점은기본 고객이 자체 네트워크 토폴로지(예: IP 서브넷)를 클라우드로 가져올 수 있다는 것입니다. 그림 2에서는 Contoso Corp에 별도의 두 네트워크 파란색 연구개발부 넷과 파란색 영업부 넷이 있는 예를 보여 줍니다. 이러한 네트워크는 서로 다른 라우팅 도메인 ID를 가지기 때문에 서로 상호 작용할 수 없습니다. 즉, Contoso R&D Net은 Contoso Corp. Contoso R&D Net에 세 개의 가상 서브넷이 포함되어 있어도 Contoso Sales Net에서 격리됩니다. RDID와 VSID는 둘 다 데이터 센터 내에서 고유합니다.

Customer networks and virtual subnets

그림 2: 고객 네트워크 및 가상 서브넷

계층 2 전달

그림 2에서 VSID 5001의 가상 머신은 Hyper-V 스위치를 통해 VSID 5001에 있는 가상 머신으로 패킷을 전달할 수 있습니다. VSID 5001의 가상 머신에서 들어오는 패킷은 Hyper-V 스위치의 특정 VPort로 전송됩니다. 수신 규칙(예: 캡슐화) 및 매핑(예: 캡슐화 헤더)은 이러한 패킷에 대한 Hyper-V 스위치에 의해 적용됩니다. 그런 다음, 패킷은 Hyper-V 스위치의 다른 VPort(대상 가상 머신이 동일한 호스트에 연결된 경우) 또는 다른 호스트의 다른 Hyper-V 스위치로 전달됩니다(대상 가상 머신이 다른 호스트에 있는 경우).

계층 3 라우팅

마찬가지로 VSID 5001의 가상 머신은 각 Hyper-V 호스트의 VSwitch에 있는 HNV 분산 라우터에 의해 VSID 5002 또는 VSID 5003의 가상 머신으로 패킷을 라우팅할 수 있습니다. Hyper-V 스위치에 패킷을 전달하면 HNV는 들어오는 패킷의 VSID를 대상 가상 머신의 VSID로 업데이트합니다. 이러한 상황은 두 VSID가 동일한 RDID에 있는 경우에만 발생합니다. 따라서 RDID1이 있는 가상 네트워크 어댑터는 게이트웨이를 트래버스하지 않고 RDID2를 사용하여 가상 네트워크 어댑터에 패킷을 보낼 수 없습니다.

참고 항목

위의 패킷 흐름 설명에서 "가상 머신"이라는 용어는 실제로 가상 머신의 가상 네트워크 어댑터를 의미합니다. 일반적인 경우는 가상 머신에 가상 네트워크 어댑터가 하나뿐인 경우입니다. 이 경우 "가상 머신" 및 "가상 네트워크 어댑터"라는 단어는 개념적으로 동일한 것을 의미할 수 있습니다.

각 가상 서브넷은 VLAN과 유사한 계층 3 IP 서브넷 및 L2(계층 2) 브로드캐스트 도메인 경계를 정의합니다. 가상 머신이 패킷을 브로드캐스트할 때 HNV는 UR(유니캐스트 복제)을 사용하여 원래 패킷의 복사본을 만들고 대상 IP 및 MAC을 동일한 VSID에 있는 각 VM의 주소로 바꿉니다.

참고 항목

Windows Server 2016이 출시되면 유니캐스트 복제본(replica)tion을 사용하여 브로드캐스트 및 서브넷 멀티캐스트가 구현됩니다. 서브넷 간 멀티캐스트 라우팅 및 IGMP는 지원되지 않습니다.

브로드캐스트 도메인인 것 외에 VSID는 격리를 제공합니다. HNV의 가상 네트워크 어댑터는 포트(virtualNetworkInterface REST 리소스) 또는 해당 포트가 속한 VSID(가상 서브넷)에 직접 ACL 규칙을 적용하는 Hyper-V 스위치 포트에 연결됩니다.

Hyper-V 스위치 포트에는 ACL 규칙이 적용되어야 합니다. 이 ACL은 ALLOW ALL, DENY ALL 또는 5 튜플(원본 IP, 대상 IP, 원본 포트, 대상 포트, 프로토콜) 일치를 기반으로 특정 유형의 트래픽만 허용하도록 보다 구체적일 수 있습니다.

참고 항목

Hyper-V 스위치 확장은 새 SDN(소프트웨어 정의 네트워킹) 스택에서 HNVv2에서 작동하지 않습니다. HNVv2는 다른 타사 스위치 확장과 함께 사용할 수 없는 Azure VFP(가상 필터링 플랫폼) 스위치 확장을 사용하여 구현됩니다.

Hyper-V 네트워크 가상화의 전환 및 라우팅

HNVv2는 실제 스위치 또는 라우터가 작동하는 것처럼 작동하도록 올바른 L2(계층 2) 전환 및 계층 3(L3) 라우팅 의미 체계를 구현합니다. HNV 가상 네트워크에 연결된 가상 머신이 동일한 VSID(가상 서브넷)에서 다른 가상 머신과의 연결을 설정하려고 하면 먼저 원격 가상 머신의 CA MAC 주소를 학습해야 합니다. 원본 가상 머신의 ARP 테이블에 대상 가상 머신의 IP 주소에 대한 ARP 항목이 있는 경우 이 항목의 MAC 주소가 사용됩니다. 항목이 없는 경우 원본 가상 머신은 반환할 대상 가상 머신의 IP 주소에 해당하는 MAC 주소에 대한 요청과 함께 ARP 브로드캐스트를 보냅니다. Hyper-V 스위치는 이 요청을 가로채서 호스트 에이전트로 보냅니다. 호스트 에이전트는 로컬 데이터베이스에서 요청된 대상 가상 머신의 IP 주소에 해당하는 MAC 주소를 찾습니다.

참고 항목

OVSDB 서버 역할을 하는 호스트 에이전트는 VTEP 스키마의 변형을 사용하여 CA-PA 매핑, MAC 테이블 등을 저장합니다.

MAC 주소를 사용할 수 있는 경우 호스트 에이전트는 ARP 응답을 삽입하고 이를 가상 머신으로 다시 보냅니다. 가상 머신의 네트워킹 스택에 필요한 모든 L2 헤더 정보가 있으면 프레임이 V-스위치의 해당 Hyper-V 포트로 전송됩니다. 내부적으로 Hyper-V 스위치는 V-포트에 할당된 N 튜플 일치 규칙에 대해 이 프레임을 테스트하고 이러한 규칙에 따라 프레임에 특정 변환을 적용합니다. 가장 중요한 것은 네트워크 컨트롤러에 정의된 정책에 따라 NVGRE 또는 VXLAN을 사용하여 캡슐화 헤더를 생성하기 위해 캡슐화 변환 집합이 적용됩니다. 호스트 에이전트에서 프로그래밍한 정책에 따라 CA-PA 매핑을 사용하여 대상 가상 머신이 상주하는 Hyper-V 호스트의 IP 주소를 확인합니다. Hyper-V 스위치는 올바른 라우팅 규칙과 VLAN 태그가 외부 패킷에 적용되어 원격 PA 주소에 도달하도록 합니다.

HNV 가상 네트워크에 연결된 가상 머신이 다른 VSID(가상 서브넷)에서 가상 머신과의 연결을 만들려는 경우 그에 따라 패킷을 라우팅해야 합니다. HNV는 CA 공간에 모든 IP 접두사(하나의 기본 경로/게이트웨이 의미)에 도달하기 위해 다음 홉으로 사용되는 IP 주소가 하나만 있는 별 토폴로지라고 가정합니다. 현재 단일 기본 경로에 제한이 적용되며 기본 경로가 아닌 경로는 지원되지 않습니다.

가상 서브넷 간의 라우팅

실제 네트워크에서 IP 서브넷은 컴퓨터(가상 및 물리적)가 서로 직접 통신할 수 있는 계층 2(L2)기본. L2 do기본는 모든 인터페이스에서 브로드캐스트되는 ARP 요청을 통해 ARP 항목(IP:MAC 주소 맵)이 학습되고 ARP 응답이 요청 호스트로 다시 전송되는 브로드캐스트 do기본입니다. 컴퓨터는 ARP 응답에서 학습된 MAC 정보를 사용하여 이더넷 헤더를 포함하여 L2 프레임을 완전히 구성합니다. 그러나 IP 주소가 다른 L3 서브넷에 있는 경우 ARP 요청은 이 L3 경계를 넘지 않습니다. 대신 원본 서브넷의 IP 주소를 사용하는 L3 라우터 인터페이스(다음 홉 또는 기본 게이트웨이)는 자체 MAC 주소를 사용하여 이러한 ARP 요청에 응답해야 합니다.

표준 Windows 네트워킹에서 관리자는 정적 경로를 만들고 이를 네트워크 인터페이스에 할당할 수 있습니다. 또한 "기본 게이트웨이"는 일반적으로 기본 경로(0.0.0.0/0)로 향하는 패킷이 전송되는 인터페이스의 다음 홉 IP 주소로 구성됩니다. 특정 경로가 없는 경우 패킷이 이 기본 게이트웨이로 전송됩니다. 이는 일반적으로 실제 네트워크에 사용되는 라우터입니다. HNV는 모든 호스트의 일부이며 모든 VSID에 인터페이스가 있는 기본 제공 라우터를 사용하여 가상 네트워크에 대한 분산 라우터를 만듭니다.

HNV는 별 토폴로지를 가정하므로 HNV 분산 라우터는 동일한 VSID 네트워크의 일부인 가상 서브넷 간에 진행되는 모든 트래픽에 대한 단일 기본 게이트웨이 역할을 합니다. 기본 게이트웨이로 사용되는 주소는 기본적으로 VSID에서 가장 낮은 IP 주소로 설정되며 HNV 분산 라우터에 할당됩니다. 이 분산 라우터를 사용하면 각 호스트가 중간자 없이도 트래픽을 적절한 호스트로 직접 라우팅할 수 있으므로 VSID 네트워크 내의 모든 트래픽을 적절하게 라우팅할 수 있습니다. 이는 동일한 VM 네트워크에 있지만 가상 서브넷이 서로 다른 두 개의 가상 컴퓨터가 동일한 실제 호스트에 있는 경우에 특히 유용합니다. 이 섹션의 뒷부분에 설명되어 있는 것처럼, 패킷이 실제 호스트에서 나갈 필요가 없습니다.

PA 서브넷 간의 라우팅

각 VSID(가상 서브넷)에 대해 하나의 PA IP 주소를 할당한 HNVv1과 달리, HNVv2는 이제 SET(Switch-Embedded Teaming) NIC 팀 구성원당 하나의 PA IP 주소를 사용합니다. 기본 배포는 2-NIC 팀을 가정하고 호스트당 두 개의 PA IP 주소를 할당합니다. 단일 호스트에는 동일한 VLAN의 동일한 PA(공급자) 논리 서브넷에서 할당된 PA IP가 있습니다. 동일한 가상 서브넷에 있는 두 개의 테넌트 VM은 실제로 서로 다른 두 공급자 논리 서브넷에 연결된 두 개의 서로 다른 호스트에 있을 수 있습니다. HNV는 CA-PA 매핑을 기반으로 캡슐화된 패킷에 대한 외부 IP 헤더를 생성합니다. 그러나 기본 PA 게이트웨이의 경우 호스트 TCP/IP 스택을 ARP에 의존한 다음 ARP 응답에 따라 외부 이더넷 헤더를 빌드합니다. 일반적으로 이 ARP 응답은 호스트가 연결된 물리적 스위치 또는 L3 라우터의 SVI 인터페이스에서 제공됩니다. 따라서 HNV는 공급자 논리 서브넷/VLAN 간에 캡슐화된 패킷을 라우팅하기 위해 L3 라우터를 사용합니다.

Virtual Network 외부 라우팅

대부분의 고객 배포에는 HNV 환경에서 HNV 환경에 속하지 않는 리소스로의 통신이 필요합니다. 두 환경 간의 통신을 허용하기 위해서는 네트워크 가상화 게이트웨이가 필요합니다. HNV 게이트웨이가 필요한 인프라에는 프라이빗 클라우드 및 하이브리드 클라우드가 포함됩니다. 기본적으로 HNV 게이트웨이는 내부 및 외부(NAT 포함) 네트워크 간 또는 IPSec VPN 또는 GRE 터널을 사용하는 여러 사이트 및/또는 클라우드(프라이빗 또는 퍼블릭) 간에 계층 3 라우팅에 필요합니다.

게이트웨이는 다양한 실제 폼 팩터로 제공될 수 있습니다. Windows Server 2016에서 빌드하거나, VXLAN 게이트웨이 역할을 하는 TOR(Top of Rack) 스위치에 통합하거나, 부하 분산 장치에서 보급한 VIP(가상 IP)를 통해 액세스하거나, 다른 기존 네트워크 어플라이언스 배치하거나, 새로운 독립 실행형 네트워크 어플라이언스 수 있습니다.

Windows RAS 게이트웨이 옵션에 대한 자세한 내용은 RAS 게이트웨이를 참조하세요.

패킷 캡슐화

HNV의 각 가상 네트워크 어댑터는 다음의 두 IP 주소와 연관되어 있습니다.

  • CA(고객 주소 ) 인트라넷 인프라에 따라 고객이 할당한 IP 주소입니다. 이 주소를 사용하면 고객이 공용 또는 프라이빗 클라우드로 이동하지 않은 것처럼 가상 머신과 네트워크 트래픽을 교환할 수 있습니다. CA는 가상 머신에 표시되며 고객은 CA에 접근할 수 있습니다.

  • PA(공급자 주소 ) 호스팅 공급자 또는 데이터 센터 관리자가 실제 네트워크 인프라를 기반으로 할당한 IP 주소입니다. PA는 네트워크에서 가상 머신을 호스팅하는 Hyper-V 실행 서버와 교환되는 패킷에 나타납니다. PA는 실제 네트워크에 표시되지만, 가상 머신에는 표시되지 않습니다.

CA는 PA에 의해 구현된 대로 고객의 네트워크 토폴로지(가상화되었으며 실제 기본 실제 네트워크 토폴로지 및 주소에서 분리됨)를 유지 관리합니다. 다음 다이어그램은 네트워크 가상화 결과로 생성된, 가상 머신 CA와 네트워크 인프라 PA 간의 개념적 관계를 보여줍니다.

Conceptual diagram of network virtualization over physical infrastructure

그림 6: 실제 인프라에서 네트워크 가상화의 개념적 다이어그램

다이어그램에서 고객 가상 머신은 자체 가상 네트워크 또는 "터널"을 통해 물리적 네트워크 인프라를 트래버스하는 CA 공간에서 데이터 패킷을 전송합니다. 위의 예제에서 터널은 왼쪽의 원본 호스트에서 오른쪽의 대상 호스트로 배달될 녹색 배송 레이블(PA 주소)이 있는 Contoso 및 Fabrikam 데이터 패킷 주변의 "봉투"로 간주할 수 있습니다. 핵심은 호스트가 Contoso 및 Fabrikam CA에 해당하는 "전달 주소"(PA)를 결정하는 방법, 패킷 주위에 "봉투"를 배치하는 방법, 대상 호스트가 패킷 래프 해제 및 Contoso 및 Fabrikam 대상 가상 머신에 올바르게 배달하는 방법입니다.

이 간단한 비유는 네트워크 가상화의 핵심적인 면을 잘 나타내 줍니다.

  • 각 가상 머신 CA는 실제 호스트 PA에 매핑됩니다. 여러 CA를 동일한 PA에 연결할 수 있습니다.

  • 가상 머신은 매핑을 기반으로 PA 원본 및 대상 쌍을 사용하여 "봉투"에 배치되는 CA 공간에 데이터 패킷을 보냅니다.

  • CA-PA 매핑은 호스트가 서로 다른 고객 가상 컴퓨터에 대한 패킷을 구분할 수 있도록 해야 합니다.

따라서 네트워크를 가상화하는 메커니즘은 가상 컴퓨터에 사용되는 네트워크 주소를 가상화하는 것입니다. 네트워크 컨트롤러는 주소 매핑을 담당하며 호스트 에이전트는 MS_VTEP 스키마를 사용하여 매핑 데이터베이스를 기본. 다음 섹션에서는 주소 가상화의 실제 메커니즘에 대해 설명합니다.

주소 가상화를 통한 네트워크 가상화

HNV는 NVGRE(네트워크 가상화 제네릭 라우팅 캡슐화) 또는 VXLAN(Virtual eXtensible Local Area Network)을 사용하여 오버레이 테넌트 네트워크를 구현합니다. VXLAN이 기본값입니다.

VXLAN(가상 eXtensible Local Area Network)

VXLAN(Virtual extensible Local Area Network)(RFC 7348) 프로토콜은 Cisco, Brocade, Arista, Dell, HP 등과 같은 공급업체의 지원을 받아 시장에서 널리 채택되었습니다. VXLAN 프로토콜은 UDP를 전송으로 사용합니다. VXLAN에 대한 IANA 할당 UDP 대상 포트는 4789이며 UDP 원본 포트는 ECMP 확산에 사용할 내부 패킷의 정보 해시여야 합니다. UDP 헤더 뒤에는 예약된 4 바이트 필드가 포함된 패킷에 VXLAN 헤더가 추가되고 VNI(VXLAN 네트워크 식별자) VSID에 대한 3 바이트 필드와 다른 예약된 1 바이트 필드가 추가됩니다. VXLAN 헤더 후에는 원래 CA L2 프레임(CA 이더넷 프레임 FCS 제외)이 추가됩니다.

VXLAN packet header

NVGRE(제네릭 라우팅 캡슐화)

이 네트워크 가상화 메커니즘은 터널 헤더의 일부로 NVGRE(제네릭 라우팅 캡슐화)를 사용합니다. NVGRE에서 가상 머신의 패킷은 다른 패킷 내에 캡슐화됩니다. 이 새 패킷의 헤더에는 그림 7에 표시된 것처럼 GRE 헤더의 키 필드에 저장된 가상 서브넷 ID 외에 적절한 원본 및 대상 PA IP 주소가 포함되어 있습니다.

NVGRE encapsulation

그림 7: 네트워크 가상화 - NVGRE 캡슐화

가상 서브넷 ID를 사용하면 패킷의 PA와 CA가 겹칠 수 있더라도 호스트가 지정된 패킷에 대한 고객 가상 머신을 식별할 수 있습니다. 이를 통해 그림 7에 표시된 것처럼 동일한 호스트의 모든 가상 컴퓨터가 단일 PA를 공유할 수 있습니다.

PA 공유는 네트워크 확장성에 큰 영향을 줍니다. 네트워크 인프라에서 알아야 하는 IP 및 MAC 주소 수를 상당히 줄일 수 있습니다. 예를 들어, 모든 최종 호스트에 평균 30대의 가상 컴퓨터가 있는 경우 네트워크 인프라에서 알아야 하는 IP 및 MAC 주소 수는 인수 30으로 줄어듭니다. 또한 패킷에 포함된 가상 서브넷 ID를 통해 쉽게 실제 고객과 패킷 간의 상관 관계를 알 수 있습니다.

Windows Server 2012 R2에 대한 PA 공유 체계는 호스트당 VSID당 하나의 PA입니다. Windows Server 2016의 경우 이 체계는 NIC 팀 구성원당 하나의 PA입니다.

Windows Server 2016 이상에서는 HNV가 NVGRE 및 VXLAN을 완전히 지원합니다. NIC(네트워크 어댑터), 스위치 또는 라우터와 같은 새 네트워크 하드웨어를 업그레이드하거나 구매할 필요가 없습니다. 이러한 유선 패킷은 오늘날의 네트워크 인프라와 호환되는 PA 공간의 일반 IP 패킷이기 때문입니다. 그러나 최상의 성능을 얻으려면 작업 오프로드를 지원하는 최신 드라이버에서 지원되는 NIC를 사용합니다.

다중 테넌트 배포 예

다음 다이어그램은 네트워크 정책에 의해 정의된 CA-PA 관계를 사용하여 클라우드 데이터 센터에 있는 두 고객의 배포 예제를 보여 줍니다.

Multi-tenant deployment example

그림 8: 다중 테넌트 배포 예

그림 8의 예를 살펴보십시오. 호스팅 공급자의 공유 IaaS 서비스로 이동하기 전:

  • Contoso Corp는 IP 주소 10.1.1.11에서 SQL Server(이름: SQL)를 실행하고, IP 주소 10.1.1.12에서 웹 서버(이름: Web)를 실행합니다. 이 주소에서는 데이터베이스 트랜잭션에 해당 SQL Server를 사용합니다.

  • Fabrikam Corp는 SQL Server(이름: SQL)를 실행하고 IP 주소 10.1.1.11을 할당했으며, IP 주소 10.1.1.12에서 웹 서버(이름: Web)를 실행하고 데이터베이스 트랜잭션에 해당 SQL Server를 사용합니다.

호스팅 서비스 공급자가 이전에 네트워크 컨트롤러를 통해 해당 물리적 네트워크 토폴로지와 일치하는 PA(공급자) 논리 네트워크를 만들었다고 가정합니다. 네트워크 컨트롤러는 호스트가 연결된 논리 서브넷의 IP 접두사에서 두 개의 PA IP 주소를 할당합니다. 또한 네트워크 컨트롤러는 IP 주소를 적용할 적절한 VLAN 태그를 나타냅니다.

Contoso Corp 및 Fabrikam Corp는 네트워크 컨트롤러를 사용하여 호스팅 서비스 공급자가 지정한 공급자(PA) 논리 네트워크에 의해 지원되는 가상 네트워크 및 서브넷을 만듭니다. Contoso Corp와 Fabrikam Corp는 각각 해당 SQL Server 및 웹 서버를 동일한 호스팅 공급자의 공유 IaaS 서비스로 이동하고 동시에 Hyper-V 호스트 1에서 SQL 가상 컴퓨터를 실행하고 Hyper-V 호스트 2에서 Web(IIS7) 가상 컴퓨터를 실행합니다. 모든 가상 컴퓨터는 원래 인트라넷 IP 주소(해당 CA)를 유지합니다.

두 회사 모두 아래와 같이 네트워크 컨트롤러에서 다음 VSID(가상 서브넷 ID)를 할당받습니다. 각 Hyper-V 호스트의 호스트 에이전트는 네트워크 컨트롤러에서 할당된 PA IP 주소를 수신하고 기본이 아닌 네트워크 구획에 두 개의 PA 호스트 vNIC를 만듭니다. 네트워크 인터페이스는 아래와 같이 PA IP 주소가 할당되는 각 호스트 vNIC에 할당됩니다.

  • Contoso Corp의 가상 머신 VSID 및 PA: VSID 는 5001, SQL PA 는 192.168.1.10, 웹 PA 는 192.168.2.20

  • Fabrikam Corp의 가상 머신 VSID 및 PA: VSID 는 6001, SQL PA 는 192.168.1.10, 웹 PA 는 192.168.2.20

네트워크 컨트롤러는 모든 네트워크 정책(CA-PA 매핑 포함)을 SDN 호스트 에이전트에 연결하여 영구 저장소(OVSDB 데이터베이스 테이블)에서 정책을 기본.

Hyper-V 호스트 2의 Contoso Corp 웹 가상 머신(10.1.1.12)이 10.1.1.11에서 SQL Server에 대한 TCP 연결을 만들면 다음이 발생합니다.

  • 대상 MAC 주소 10.1.1.11에 대한 VM ARP

  • vSwitch의 VFP 확장은 이 패킷을 가로채 SDN 호스트 에이전트로 보냅니다.

  • SDN 호스트 에이전트는 해당 정책 저장소에서 MAC 주소 10.1.1.11을 찾습니다.

  • MAC이 발견되면 호스트 에이전트는 ARP 응답을 VM에 다시 삽입합니다.

  • MAC을 찾을 수 없는 경우 응답이 전송되지 않고 10.1.1.11에 대한 VM의 ARP 항목에 연결할 수 없는 것으로 표시됩니다.

  • 이제 VM은 올바른 CA 이더넷 및 IP 헤더를 사용하여 TCP 패킷을 생성하고 vSwitch로 보냅니다.

  • vSwitch의 VFP 전달 확장은 패킷이 수신된 원본 vSwitch 포트에 할당된 VFP 계층(아래 설명)을 통해 이 패킷을 처리하고 VFP 통합 흐름 테이블에 새 흐름 항목을 만듭니다.

  • VFP 엔진은 IP 및 이더넷 헤더를 기반으로 각 계층(예: 가상 네트워크 계층)에 대한 규칙 일치 또는 흐름 테이블 조회를 수행합니다.

  • 가상 네트워크 계층에서 일치하는 규칙은 CA-PA 매핑 공간을 참조하고 캡슐화를 수행합니다.

  • 캡슐화 유형(VXLAN 또는 NVGRE)은 VSID와 함께 VNet 계층에 지정됩니다.

  • VXLAN 캡슐화의 경우 외부 UDP 헤더는 VXLAN 헤더에서 VSID 5001로 생성됩니다. 외부 IP 헤더는 SDN 호스트 에이전트의 정책 저장소를 기반으로 Hyper-V 호스트 2(192.168.2.20) 및 Hyper-V 호스트 1(192.168.1.10)에 할당된 원본 및 대상 PA 주소를 사용하여 생성됩니다.

  • 그런 다음, 이 패킷은 VFP의 PA 라우팅 계층으로 흐릅니다.

  • VFP의 PA 라우팅 계층은 PA 공간 트래픽 및 VLAN ID에 사용되는 네트워크 구획을 참조하고 호스트의 TCP/IP 스택을 사용하여 PA 패킷을 Hyper-V 호스트 1에 올바르게 전달합니다.

  • 캡슐화된 패킷을 받으면 Hyper-V 호스트 1은 PA 네트워크 구획에서 패킷을 수신하고 vSwitch에 전달합니다.

  • VFP는 해당 VFP 계층을 통해 패킷을 처리하고 VFP 통합 흐름 테이블에 새 흐름 항목을 만듭니다.

  • VFP 엔진은 가상 네트워크 계층의 수신 규칙과 일치하고 외부 캡슐화된 패킷의 이더넷, IP 및 VXLAN 헤더를 제거합니다.

  • 그런 다음 VFP 엔진은 대상 VM이 연결된 vSwitch 포트에 패킷을 전달합니다.

Fabrikam Corp WebSQL 가상 컴퓨터 간의 트랙픽에 대해 비슷한 프로세스에서는 Fabrikam Corp의 HNV 정책 설정을 사용합니다. 결과적으로, Fabrikam Corp와 Contoso Corp 가상 컴퓨터는 HNV를 통해 원래의 인트라넷에서와 같이 상호 작용합니다. Fabrikam Corp 가상 컴퓨터와 Contoso Corp 가상 컴퓨터는 동일한 IP 주소를 사용하고 있더라도 서로 상호 작용할 수 없습니다.

별도의 주소(CA 및 PA), Hyper-V 호스트의 정책 설정 및 인바운드 및 아웃바운드 가상 머신 트래픽에 대한 CA와 PA 간의 주소 변환은 NVGRE 키 또는 VLXAN VNID를 사용하여 이러한 서버 집합을 격리합니다. 또한 가상화 매핑과 변환에서는 실제 네트워크 인프라에서 가상 네트워크 아키텍처를 분리합니다. Contoso SQLWeb과 Fabrikam SQLWeb이 고유 CA IP 서브넷(10.1.1/24)에 상주하더라도 실제 배포는 각각 서로 다른 PA 서브넷의 두 호스트 192.168.1/24 및 192.168.2/24에서 수행됩니다. 여기에 함축된의미는 HNV를 통해 서브넷 간 가상 머신 프로비저닝 및 실시간 마이그레이션이 가능하다는 것입니다.

Hyper-V 네트워크 가상화 아키텍처

Windows Server 2016에서 HNVv2는 Hyper-V 스위치 내의 NDIS 필터링 확장인 Azure VFP(가상 필터링 플랫폼)를 사용하여 구현됩니다. VFP의 주요 개념은 네트워크 정책을 프로그래밍하기 위해 SDN 호스트 에이전트에 노출되는 내부 API가 있는 일치 작업 흐름 엔진의 개념입니다. SDN 호스트 에이전트 자체는 OVSDB 및 WCF SouthBound 통신 채널을 통해 네트워크 컨트롤러에서 네트워크 정책을 받습니다. 가상 네트워크 정책(예: CA-PA 매핑)은 VFP를 사용하여 프로그래밍될 뿐만 아니라 ACL, QoS 등의 추가 정책도 프로그래밍됩니다.

vSwitch 및 VFP 전달 확장의 개체 계층 구조는 다음과 같습니다.

  • vSwitch

    • 외부 NIC 관리

    • NIC 하드웨어 오프로드

    • 전역 전달 규칙

    • 포트

      • 모발 고정을 위한 송신 전달 계층

      • 매핑 및 NAT 풀에 대한 공간 목록

      • 통합 흐름 테이블

      • VFP 계층

        • 흐름 테이블

        • 그룹

        • 규칙

          • 규칙은 공백을 참조할 수 있습니다.

VFP에서 계층은 정책 유형(예: Virtual Network)에 따라 생성되며 규칙/흐름 테이블의 제네릭 집합입니다. 이러한 기능을 구현하기 위해 특정 규칙이 해당 계층에 할당될 때까지는 내장 기능이 없습니다. 각 계층에는 우선 순위가 할당되고 계층은 우선 순위를 오름차순으로 포트에 할당합니다. 규칙은 주로 방향 및 IP 주소 패밀리에 따라 그룹으로 구성됩니다. 그룹에도 우선 순위가 할당되며, 그룹의 한 규칙이 지정된 흐름과 일치할 수 있습니다.

VFP 확장을 사용하는 vSwitch에 대한 전달 논리는 다음과 같습니다.

  • 수신 처리(포트로 들어오는 패킷의 관점에서 수신)

  • 전달

  • 송신 처리(포트를 나가는 패킷의 관점에서 송신)

VFP는 NVGRE 및 VXLAN 캡슐화 유형뿐만 아니라 외부 MAC VLAN 기반 전달에 대한 내부 MAC 전달을 지원합니다.

VFP 확장에는 패킷 통과를 위한 느린 경로 및 빠른 경로가 있습니다. 흐름의 첫 번째 패킷은 각 계층의 모든 규칙 그룹을 트래버스하고 비용이 많이 드는 규칙 조회를 수행해야 합니다. 그러나 흐름이 통합 흐름 테이블에 작업 목록(일치하는 규칙에 따라)으로 등록되면 모든 후속 패킷은 통합 흐름 테이블 항목에 따라 처리됩니다.

HNV 정책은 호스트 에이전트에 의해 프로그래밍됩니다. 각 가상 머신 네트워크 어댑터는 IPv4 주소로 구성됩니다. 이는 가상 컴퓨터가 서로 통신하는 데 사용되는 CA이며, 가상 컴퓨터에서 IP 패킷으로 전달됩니다. HNV는 호스트 에이전트의 데이터베이스에 저장된 네트워크 가상화 정책을 기반으로 PA 프레임에 CA 프레임을 캡슐화합니다.

HNV Architecture

그림 9: HNV 아키텍처

요약

클라우드 기반 데이터 센터는 향상된 확장성 및 보다 우수한 리소스 사용률과 같은 여러 이점을 제공할 수 있습니다. 이러한 잠재적 이점을 실현하려면 기본적으로 동적 환경에서 다중 테넌트 확장성 문제를 해결하는 기술이 필요합니다. HNV는 실제 네트워크 토폴로지에 대해 가상 네트워크 토폴로지를 분리하여 이러한 문제를 해결하고 데이터 센터의 운영 효율성을 개선하도록 설계되었습니다. 기존 표준을 기반으로 하는 HNV는 오늘날의 데이터 센터에서 실행되며 기존 VXLAN 인프라와 함께 작동합니다. 이제 HNV를 사용하는 고객은 데이터 센터를 프라이빗 클라우드로 통합하거나 하이브리드 클라우드를 사용하여 데이터 센터를 호스팅 서버 공급자의 환경으로 원활하게 확장할 수 있습니다.

HNVv2에 대한 자세한 내용은 다음 링크를 참조하세요.

내용 유형 참조
커뮤니티 리소스 - 프라이빗 클라우드 아키텍처 블로그
-질문: cloudnetfb@microsoft.com
Rfc - NVGRE 초안 RFC
- VXLAN - RFC 7348
관련 기술 - Windows Server 2012 R2의 Hyper-V 네트워크 가상화 기술 세부 정보는 Hyper-V 네트워크 가상화 기술 세부 정보를 참조하세요 .
- 네트워크 컨트롤러