szczegóły techniczne wirtualizacji sieci Hyper-V w systemie Windows Server

Wirtualizacja serwera umożliwia jednoczesne uruchamianie wielu wystąpień serwera na jednym hoście fizycznym; jednak wystąpienia serwera są odizolowane od siebie. Każda maszyna wirtualna zasadniczo działa tak, jakby był jedynym serwerem działającym na komputerze fizycznym.

Wirtualizacja sieci zapewnia podobną funkcję, w której wiele sieci wirtualnych (potencjalnie z nakładającymi się adresami IP) działa w tej samej infrastrukturze sieci fizycznej, a każda sieć wirtualna działa tak, jakby była jedyną siecią wirtualną działającą w udostępnionej infrastrukturze sieci. Rysunek 1 przedstawia tę relację.

Rysunek 1. Wirtualizacja serwera a wirtualizacja sieci

pojęcia dotyczące wirtualizacji sieci Hyper-V

W Hyper-V wirtualizacji sieci (HNV) klient lub najemca są definiowani jako "właściciel" zestawu podsieci IP wdrożonych w przedsiębiorstwie lub centrum danych. Klient może być korporacją lub przedsiębiorstwem z wieloma działami lub jednostkami biznesowymi w prywatnym centrum danych, które wymaga izolacji sieci lub dzierżawy w publicznym centrum danych, które jest hostowane przez dostawcę usług. Każdy klient może mieć co najmniej jedną sieć wirtualną w centrum danych, a każda sieć wirtualna składa się z co najmniej jednej podsieci wirtualnej.

Istnieją dwie implementacje HNV, które będą dostępne w systemie Windows Server 2016: HNVv1 i HNVv2.

• HNVv1

  HNVv1 jest zgodny z systemami Windows Server 2012 R2 i System Center 2012 R2 Virtual Machine Manager (VMM). Konfiguracja HNVv1 opiera się na zarządzaniu usługą WMI i poleceniach cmdlet programu Windows PowerShell (ułatwianych za pośrednictwem programu System Center VMM) do definiowania ustawień izolacji oraz mapowania adresów wirtualnej sieci klienta (CA) na adresy fizyczne (PA) i routingu. Nie dodano żadnych dodatkowych funkcji do HNVv1 w systemie Windows Server 2016 i nie są planowane żadne nowe funkcje.

  • SET Teaming i HNV V1 nie są zgodne pod względem platformy.

  Aby korzystać z bram HA NVGRE, użytkownicy muszą używać zespołu LBFO lub mogą działać bez zespołu. lub

  o Użyj bram wdrożonych przez kontroler sieci z przełącznikiem zespołowym SET.

• HNVv2

  W systemie HNVv2 jest zaimplementowana znaczna liczba nowych funkcji, które są implementowane przy użyciu rozszerzenia przekazywania usługi Azure Virtual Filtering Platform (VFP) w przełączniku Hyper-V. HNVv2 jest w pełni zintegrowany z usługą Microsoft Azure Stack, która obejmuje nowy kontroler sieci w stosie sieci zdefiniowanej przez oprogramowanie (SDN). Zasady sieci wirtualnej są definiowane poprzez Kontroler Sieci firmy Microsoft, używając interfejsu API RESTful NorthBound (NB), a następnie przesyłane do agenta hosta za pośrednictwem wielu interfejsów SouthBound (SBI), w tym OVSDB. Agent hosta programuje zasady w rozszerzeniu VFP przełącznika Hyper-V, gdzie są one egzekwowane.

  Ważne

  Ten temat koncentruje się na HNVv2.

Sieć wirtualna

• Każda sieć wirtualna składa się z co najmniej jednej podsieci wirtualnej. Sieć wirtualna stanowi granicę izolacji, w której maszyny wirtualne w sieci wirtualnej mogą komunikować się tylko ze sobą. Tradycyjnie ta izolacja została wymuszona przy użyciu sieci VLAN z segregowanym zakresem adresów IP i tagiem 802.1q lub identyfikatorem sieci VLAN. Jednak w przypadku HNV izolacja jest wymuszana przy użyciu enkapsulacji NVGRE lub VXLAN w celu tworzenia sieci nakładek z możliwością nakładania się podsieci IP między klientami lub najemcami.

• Każda sieć wirtualna ma unikatowy identyfikator domeny routingu (RDID) na hoście. Identyfikator RDID w przybliżeniu odpowiada identyfikatorowi zasobu, który służy do zidentyfikowania zasobu REST sieci wirtualnej w kontrolerze sieciowym. Wirtualna sieć REST jest odwoływana za pomocą przestrzeni nazw URI, do której dołączono identyfikator zasobu.

Podsieci wirtualne

• Podsieć wirtualna implementuje semantykę podsieci IP warstwy 3 dla maszyn wirtualnych w tej samej podsieci wirtualnej. Podsieć wirtualna tworzy domenę emisji (podobną do sieci VLAN), a izolacja jest wymuszana przy użyciu pola Identyfikator sieci dzierżawy NVGRE (TNI) lub VXLAN Network Identifier (VNI).

• Każda podsieć wirtualna należy do jednej sieci wirtualnej (RDID) i ma przypisany unikatowy identyfikator podsieci wirtualnej (VSID) przy użyciu klucza TNI lub VNI w nagłówku hermetyzowanego pakietu. Identyfikator VSID musi być unikatowy w centrum danych i mieści się w zakresie od 4096 do 2^24-2.

Główną zaletą sieci wirtualnej i domeny routingu jest to, że umożliwia klientom korzystanie z własnych topologii sieci (na przykład podsieci IP) do chmury. Rysunek 2 przedstawia przykład, w którym firma Contoso Corp ma dwie oddzielne sieci: R&D Net i Sales Net. Ponieważ te sieci mają różne identyfikatory domeny routingu, nie mogą ze sobą korzystać. Oznacza to, że firma Contoso R&D Net jest odizolowana od platformy Contoso Sales Net, mimo że obie są własnością firmy Contoso Corp. Firma Contoso R&D Net zawiera trzy podsieci wirtualne. Należy pamiętać, że zarówno RDID, jak i VSID są unikatowe w centrum danych.

Rysunek 2. Sieci klienta i podsieci wirtualne

Przekazywanie w warstwie 2

Na rysunku 2 maszyny wirtualne w identyfikatorze VSID 5001 mogą przekazywać pakiety do maszyn wirtualnych, które znajdują się również w identyfikatorze VSID 5001 za pośrednictwem przełącznika Hyper-V. Pakiety przychodzące z maszyny wirtualnej w VSID 5001 są wysyłane do określonego VPortu na przełączniku Hyper-V. Reguły ruchu przychodzącego (na przykład hermetyzacja) i mapowania (na przykład nagłówek hermetyzacji) są stosowane przez przełącznik Hyper-V dla tych pakietów. Pakiety są następnie przekazywane do innego wirtualnego portu VPort na przełączniku Hyper-V (jeśli docelowa maszyna wirtualna jest dołączona do tego samego hosta) lub do innego przełącznika Hyper-V na innym hoście (jeśli docelowa maszyna wirtualna znajduje się na innym hoście).

Trasowanie warstwy 3

Podobnie maszyny wirtualne o identyfikatorze VSID 5001 mogą mieć swoje pakiety kierowane do maszyn wirtualnych o identyfikatorze VSID 5002 lub VSID 5003 za pomocą rozproszonego routera HNV, który znajduje się w każdym przełączniku VSwitch hosta Hyper-V. Po dostarczeniu pakietu do przełącznika Hyper-V, HNV aktualizuje VSID pakietu przychodzącego na VSID docelowej maszyny wirtualnej. Tak się stanie tylko wtedy, gdy oba identyfikatory VSID znajdują się w tym samym identyfikatorze RDID. W związku z tym wirtualne karty sieciowe z RDID1 nie mogą wysyłać pakietów do wirtualnych kart sieciowych z RDID2 bez konieczności przechodzenia przez bramę.

Uwaga / Notatka

W powyższym opisie przepływu pakietów termin "maszyna wirtualna" oznacza wirtualną kartę sieciową na maszynie wirtualnej. Typowym przypadkiem jest to, że maszyna wirtualna ma tylko jedną wirtualną kartę sieciową. W takim przypadku słowa "maszyna wirtualna" i "wirtualna karta sieciowa" mogą oznaczać to samo.

Każda podsieć wirtualna definiuje podsieć IP warstwy 3 i granicę domeny emisji warstwy 2 (L2) podobną do sieci VLAN. Gdy maszyna wirtualna emituje pakiet, HNV używa Unicast Replication (UR) do stworzenia kopii oryginalnego pakietu i zastąpienia docelowych adresów IP i MAC adresami każdej maszyny wirtualnej, które są w tym samym VSID.

Uwaga / Notatka

Kiedy system Windows Server 2016 zostanie wydany, emisje broadcast i multiemisje podsieci będą zaimplementowane przy użyciu replikacji unicast. Routing wielokrotnej emisji między podsieciami i protokół IGMP nie są obsługiwane.

Oprócz bycia domeną transmisji, identyfikator VSID zapewnia izolację. Wirtualna karta sieciowa w HNV jest połączona z portem przełącznika Hyper-V, który będzie miał zasady ACL stosowane bezpośrednio na port (zasób REST virtualNetworkInterface) lub na wirtualną podsieć (VSID), której jest częścią.

Port przełącznika Hyper-V musi mieć zastosowaną regułę listy kontroli dostępu (ACL). ACL może mieć wartość ALLOW ALL, DENY ALL lub być bardziej szczegółowa i zezwalać tylko na określone typy ruchu na podstawie pięcioelementowego zestawu (adres źródłowy IP, adres docelowy IP, port źródłowy, port docelowy, protokół).

Uwaga / Notatka

Hyper-V Rozszerzenia przełączników nie będą działać z HNVv2 w nowym stosie programowej sieci definiowanej (SDN). HNVv2 jest implementowany przy użyciu rozszerzenia przełącznika Azure Virtual Filtering Platform (VFP), które nie może być używane w połączeniu z żadnym innym rozszerzeniem przełącznika firmy trzeciej.

Przełączanie i routing w wirtualizacji sieci Hyper-V

HNVv2 implementuje prawidłowe przełączanie w warstwie 2 (L2) oraz semantykę routingu w warstwie 3 (L3), działając tak samo jak fizyczny przełącznik lub router. Gdy maszyna wirtualna połączona z siecią wirtualną HNV próbuje nawiązać połączenie z inną maszyną wirtualną w tej samej podsieci wirtualnej (VSID), musi najpierw ustalić adres CAM MAC zdalnej maszyny wirtualnej. Jeśli istnieje wpis ARP dla docelowego adresu IP maszyny wirtualnej w tabeli ARP źródłowej maszyny wirtualnej, używany jest adres MAC z tego wpisu. Jeśli wpis nie istnieje, źródłowa maszyna wirtualna wyśle emisję ARP z żądaniem adresu MAC odpowiadającego adresowi IP docelowej maszyny wirtualnej, który ma zostać zwrócony. Przełącznik Hyper-V przechwytuje to żądanie i wysyła je do agenta hosta. Agent hosta będzie szukać w lokalnej bazie danych odpowiedniego adresu MAC dla żądanego docelowego adresu IP maszyny wirtualnej.

Uwaga / Notatka

Agent hosta, działający jako serwer OVSDB, używa wariantu schematu VTEP do przechowywania mapowań CA-PA, tabeli MAC itd.

Jeśli adres MAC jest dostępny, agent hosta wprowadza odpowiedź ARP i wysyła je z powrotem do maszyny wirtualnej. Gdy stos sieciowy maszyny wirtualnej zawiera wszystkie wymagane informacje nagłówka L2, ramka jest wysyłana do odpowiedniego portu Hyper-V na przełączniku V-Switch. Wewnętrznie przełącznik Hyper-V testuje tę ramkę względem reguł dopasowywania krotki N przypisanych do portu V-Port i stosuje pewne przekształcenia do ramki na podstawie tych reguł. Co najważniejsze, zestaw przekształceń hermetyzacji jest stosowany do konstruowania nagłówka hermetyzacji przy użyciu protokołu NVGRE lub VXLAN, w zależności od polityki zdefiniowanej na kontrolerze sieciowym. Na podstawie zasad zaprogramowanych przez agenta hosta mapowanie CA-PA służy do określania adresu IP hosta Hyper-V, na którym znajduje się docelowa maszyna wirtualna. Przełącznik Hyper-V zapewnia stosowanie prawidłowych reguł routingu i tagów sieci VLAN do pakietu zewnętrznego, dzięki czemu dociera do zdalnego adresu PA.

Jeśli maszyna wirtualna połączona z siecią wirtualną HNV chce utworzyć połączenie z maszyną wirtualną w innej podsieci wirtualnej (VSID), pakiet musi być odpowiednio kierowany. HNV zakłada topologię gwiazdy, w której istnieje tylko jeden adres IP w przestrzeni urzędu certyfikacji używany jako następny przeskok, aby uzyskać dostęp do wszystkich prefiksów adresów IP (co oznacza jedną domyślną trasę/bramę). Obecnie wymusza to ograniczenie do pojedynczej trasy domyślnej i tras innych niż domyślne nie są obsługiwane.

Routing między wirtualnymi subnetami

W sieci fizycznej podsieć IP jest domeną warstwy 2 (L2), w której komputery (wirtualne i fizyczne) mogą komunikować się bezpośrednio ze sobą. Domena L2 to domena rozgłoszeniowa, w której wpisy ARP (mapa adresów IP:MAC) są pozyskiwane poprzez żądania ARP, które są rozsyłane do wszystkich interfejsów, a odpowiedzi ARP są przesyłane z powrotem do hosta, który złożył żądanie. Komputer korzysta z informacji MAC uzyskanych z odpowiedzi ARP, aby całkowicie skonstruować ramkę L2, w tym nagłówki Ethernet. Jeśli jednak adres IP znajduje się w innej podsieci L3, żądanie ARP nie przekracza tej granicy L3. Zamiast tego interfejs routera L3 (brama następnego przeskoku lub brama domyślna) z adresem IP w podsieci źródłowej musi odpowiadać na te żądania ARP swoim własnym adresem MAC.

W standardowej sieci systemu Windows administrator może tworzyć trasy statyczne i przypisywać je do interfejsu sieciowego. Ponadto "brama domyślna" jest zwykle skonfigurowana jako adres IP następnego przeskoku w interfejsie, w którym wysyłane są pakiety przeznaczone dla trasy domyślnej (0.0.0.0/0). Pakiety są wysyłane do tej bramy domyślnej, jeśli nie istnieją żadne określone trasy. Jest to zazwyczaj router dla sieci fizycznej. HNV używa wbudowanego routera, który jest częścią każdego hosta i ma interfejs w każdym VSID, aby utworzyć router rozproszony dla sieci wirtualnych.

Ponieważ HNV zakłada topologię gwiazdy, router rozproszony HNV działa jako pojedyncza brama domyślna dla całego ruchu przechodzącego między podsieciami wirtualnymi, które są częścią tej samej sieci VSID. Adres używany jako brama domyślna domyślnie jest ustawiany na najniższy adres IP w VSID i przypisywany do routera rozproszonego HNV. Ten router rozproszony umożliwia bardzo wydajny sposób kierowania całego ruchu wewnątrz sieci VSID, ponieważ każdy host może bezpośrednio kierować ruch do odpowiedniego hosta bez konieczności pośrednika. Jest to szczególnie istotne, gdy dwie maszyny wirtualne w tej samej sieci maszyn wirtualnych, ale różne podsieci wirtualne znajdują się na tym samym hoście fizycznym. Jak zobaczysz w dalszej części tej sekcji, pakiet nigdy nie musi opuszczać hosta fizycznego.

Routing między podsieciami PA

W przeciwieństwie do HNVv1, który przydzielił jeden adres IP PA dla każdej podsieci wirtualnej (VSID), HNVv2 używa teraz jednego adresu IP PA na Switch-Embedded zespołu kart sieciowych (SET). W przypadku wdrożenia domyślnego przyjęto założenie, że zespół z dwiema kartami sieciowymi przypisuje dwa adresy IP PA na hosta. Jeden host ma adresy IP PA przypisane z tej samej logicznej podsieci dostawcy (PA) w tej samej sieci VLAN. Dwie maszyny wirtualne dzierżawców w tej samej podsieci wirtualnej mogą być umieszczone na dwóch różnych hostach, które są połączone z dwiema różnymi podsieciami logicznymi dostawcy. HNV skonstruuje zewnętrzne nagłówki IP dla hermetyzowanego pakietu na podstawie mapowania CA-PA. Jednak polega na stosie TCP/IP hosta, aby przeprowadzić ARP dla domyślnej bramy PA, a następnie tworzy zewnętrzne nagłówki Ethernet na podstawie odpowiedzi ARP. Zazwyczaj ta odpowiedź ARP pochodzi z interfejsu SVI, znajdującego się na przełączniku fizycznym lub routerze L3, do którego podłączony jest host. HNV zatem polega na routerze L3 do routingu hermetyzowanych pakietów między logicznymi podsieciami dostawcy a sieciami VLAN.

Routing poza siecią wirtualną

Większość wdrożeń klientów wymaga komunikacji ze środowiska HNV do zasobów, które nie są częścią środowiska HNV. Bramy wirtualizacji sieci są wymagane do umożliwienia komunikacji między dwoma środowiskami. Infrastruktury wymagające bramy HNV obejmują chmurę prywatną i chmurę hybrydową. Zasadniczo bramy HNV są wymagane do routingu warstwy 3 między sieciami wewnętrznymi i zewnętrznymi (w tym NAT) lub między różnymi lokalizacjami i/lub chmurami (prywatnymi lub publicznymi), które korzystają z tunelu IPSec VPN lub GRE.

Bramy mogą mieć różne czynniki fizyczne. Można je skompilować w systemie Windows Server 2016, dołączone do przełącznika tor działającego jako brama sieci VXLAN, dostępnego za pośrednictwem wirtualnego adresu IP (VIP) anonsowanego przez moduł równoważenia obciążenia, umieścić w innych istniejących urządzeniach sieciowych lub może być nowym autonomicznym urządzeniem sieciowym.

Aby uzyskać więcej informacji na temat opcji bramy RAS systemu Windows, zobacz Brama RAS.

Hermetyzacja pakietów

Każda wirtualna karta sieciowa w usłudze HNV jest skojarzona z dwoma adresami IP:

• Adres klienta (CA) Adres IP przypisany przez klienta na podstawie infrastruktury intranetowej. Ten adres umożliwia klientowi wymianę ruchu sieciowego z maszyną wirtualną tak, jakby nie została przeniesiona do chmury publicznej lub prywatnej. Urząd certyfikacji jest widoczny dla maszyny wirtualnej i dostępny dla klienta.

• Adres dostawcy (PA) Adres IP przypisany przez dostawcę hostingu lub administratorów centrum danych na podstawie ich infrastruktury sieci fizycznej. PA pojawia się w pakietach sieciowych wymienianych z serwerem działającym na systemie Hyper-V, który hostuje maszynę wirtualną. PA jest widoczny w sieci fizycznej, ale nie dla maszyny wirtualnej.

Urzędy certyfikacji utrzymują topologię sieci klienta, która jest zwirtualizowana i oddzielona od rzeczywistej topologii i adresów sieci fizycznej, zgodnie z implementacją przez urzędy certyfikacji. Na poniższym diagramie przedstawiono koncepcyjną relację między urzędami certyfikacji (CAs) maszyn wirtualnych i władzami dostawczymi (PAs) infrastruktury sieciowej jako rezultat wirtualizacji sieci.

Rysunek 6. Diagram koncepcyjny wirtualizacji sieci za pośrednictwem infrastruktury fizycznej

Na diagramie maszyny wirtualne klienta wysyłają pakiety danych w przestrzeni urzędu certyfikacji, które przechodzą przez infrastrukturę sieci fizycznej za pośrednictwem własnych sieci wirtualnych lub "tuneli". W powyższym przykładzie tunele można traktować jako "koperty" wokół pakietów danych Contoso i Fabrikam z zielonymi etykietami wysyłkowymi (adresami PA), które mają być dostarczane z hosta źródłowego po lewej stronie do hosta docelowego po prawej stronie. Kluczem jest to, w jaki sposób hosty określają "adresy wysyłkowe" (PA) odpowiadające firmom Contoso i Fabrikam, jak "koperta" jest umieszczana wokół pakietów oraz jak hosty docelowe mogą rozpakowywać pakiety i dostarczać je poprawnie do docelowych maszyn wirtualnych firm Contoso i Fabrikam.

Ta prosta analogia podkreśliła kluczowe aspekty wirtualizacji sieci:

• Każda maszyna wirtualna CA jest przypisana do fizycznego hosta PA. Może istnieć wiele urzędów certyfikacji skojarzonych z tym samym dostawcą usług.

• Maszyny wirtualne wysyłają pakiety danych w przestrzeniach CA, które są umieszczane w "kopercie" z parą źródłową i docelową PA na podstawie mapowania.

• Mapowania CA-PA muszą zezwalać hostom na rozróżnianie pakietów dla różnych maszyn wirtualnych klienta.

W związku z tym mechanizm wirtualizacji sieci polega na wirtualizacji adresów sieciowych używanych przez maszyny wirtualne. Kontroler sieci jest odpowiedzialny za mapowanie adresów, a agent hosta utrzymuje bazę danych mapowania przy użyciu schematu MS_VTEP. W następnej sekcji opisano rzeczywisty mechanizm wirtualizacji adresów.

Wirtualizacja sieci za pośrednictwem wirtualizacji adresów

HNV implementuje sieci nakładkowe najemców, używając kapsułkowania sieciowego generującego trasy wirtualizacji sieci (NVGRE) lub wirtualnej rozszerzalnej lokalnej sieci komputerowej (VXLAN). Sieć VXLAN jest domyślna.

Wirtualna Rozszerzalna Sieć Lokalna (VXLAN)

Protokół Virtual eXtensible Local Area Network (VXLAN) (RFC 7348) został powszechnie przyjęty na rynku, z obsługą dostawców, takich jak Cisco, Brocade, Arista, Dell, HP i inne. Protokół VXLAN używa protokołu UDP jako transportu. Port docelowy protokołu UDP przypisany przez IANA dla sieci VXLAN to 4789, a port źródłowy UDP powinien być skrótem informacji z pakietu wewnętrznego, który ma być używany do rozpowszechniania ECMP. Po nagłówku UDP nagłówek sieci VXLAN jest dołączany do pakietu, który zawiera zastrzeżone pole 4 bajtów, po którym następuje pole 3-bajtowe dla identyfikatora sieci VXLAN (VNI) — VSID — a następnie kolejne zarezerwowane pole 1 bajtów. Po nagłówku VXLAN dołączona zostanie oryginalna ramka L2 CA (bez ramki Ethernet CA FCS).

Hermetyzacja routingu ogólnego (NVGRE)

Ten mechanizm wirtualizacji sieci używa hermetyzacji routingu ogólnego (NVGRE) jako części nagłówka tunelu. W programie NVGRE pakiet maszyny wirtualnej jest hermetyzowany wewnątrz innego pakietu. Nagłówek tego nowego pakietu zawiera odpowiednie adresy IP źródłowe i docelowe PA oraz identyfikator podsieci wirtualnej, który jest przechowywany w polu Klucz nagłówka GRE, jak pokazano na rysunku 7.

Rysunek 7. Wirtualizacja sieci — hermetyzacja NVGRE

Identyfikator podsieci wirtualnej umożliwia hostom identyfikację maszyny wirtualnej klienta dla dowolnego pakietu, nawet jeśli PA i CA w pakietach mogą się nakładać. Umożliwia to wszystkim maszynom wirtualnym na tym samym hoście współużytkowanie pojedynczego dostawcy dostępu, jak pokazano na rysunku 7.

Udostępnianie PA ma duży wpływ na skalowalność sieci. Liczba adresów IP i MAC, które muszą być poznane przez infrastrukturę sieci, może zostać znacznie zmniejszona. Na przykład jeśli każdy host końcowy ma średnio 30 maszyn wirtualnych, liczba adresów IP i MAC, które muszą być poznane przez infrastrukturę sieciową, jest ograniczona przez współczynnik 30.Osadzone identyfikatory podsieci wirtualnej w pakietach umożliwiają również łatwą korelację pakietów z rzeczywistymi klientami.

Schemat udostępniania PA dla systemu Windows Server 2012 R2 to jeden PA na VSID na host. W systemie Windows Server 2016 schemat to jeden PA na członka zespołu NIC.

W systemie Windows Server 2016 lub nowszym usługa HNV w pełni obsługuje protokoły NVGRE i VXLAN bez konieczności dodatkowej konfiguracji; nie wymaga aktualizacji ani zakupu nowego sprzętu sieciowego, takiego jak karty sieciowe, przełączniki czy routery. Dzieje się tak dlatego, że te pakiety w sieci są zwykłymi pakietami IP w przestrzeni PA, która jest zgodna z bieżącą infrastrukturą sieciową. Jednak aby uzyskać najlepszą wydajność, należy używać obsługiwanych kart sieciowych z najnowszymi sterownikami, które obsługują odciążenia zadań.

Przykład wdrożenia dla wielu najemców

Na poniższym diagramie przedstawiono przykładowe wdrożenie dwóch klientów znajdujących się w centrum danych w chmurze z relacją CA-PA zdefiniowaną przez zasady sieciowe.

Rysunek 8: Przykład wdrożenia z wieloma najemcami

Rozważmy przykład na rysunku 8. Przed przejściem do udostępnionej usługi IaaS dostawcy hostingu:

• Firma Contoso Corp uruchomiła program SQL Server (o nazwie SQL) pod adresem IP 10.1.1.11 i serwerem sieci Web (o nazwie Web) pod adresem IP 10.1.1.12, który używa programu SQL Server do obsługi transakcji bazy danych.

• Firma Fabrikam Corp uruchomiła program SQL Server o nazwie SQL i przypisał adres IP 10.1.1.11 oraz serwer internetowy o nazwie Web , a także pod adresem IP 10.1.1.12, który używa programu SQL Server na potrzeby transakcji bazy danych.

Przyjmujemy, że świadczeniodawca usług hostingowych wcześniej stworzył sieć logiczną dostawcy (PA) za pośrednictwem kontrolera sieci, aby dopasować ją do topologii sieci fizycznej. Kontroler sieci przydziela dwa adresy IP typu PA z prefiksu IP logicznej podsieci, do której są podłączone hosty. Kontroler sieci wskazuje również odpowiedni tag sieci VLAN, aby zastosować adresy IP.

Za pomocą kontrolera sieci firma Contoso Corp i firma Fabrikam Corp tworzą sieć wirtualną i podsieci, które są wspierane przez sieć logiczną dostawcy (PA) określoną przez dostawcę usług hostingu. Firmy Contoso Corp i Fabrikam Corp przenoszą odpowiednie serwery SQL i serwery internetowe do udostępnionej usługi IaaS tego samego dostawcy hostingu, gdzie przypadkowo uruchamiają maszyny wirtualne SQL na hoście 1 Hyper-V i maszynach wirtualnych sieci Web (IIS7) na hoście 2 Hyper-V. Wszystkie maszyny wirtualne utrzymują oryginalne intranetowe adresy IP (ich CAs).

Obie firmy otrzymują następujący identyfikator podsieci wirtualnej (VSID) od kontrolera sieciowego, jak pokazano poniżej. Agent hosta na każdym z hostów Hyper-V odbiera przydzielone adresy IP PA z kontrolera sieci i tworzy dwa vNIC hosta PA w nie-domyślnym przedziale sieci. Interfejs sieciowy jest przypisywany do każdej z tych wirtualnych interfejsów sieciowych hosta, do których przypisano adres IP PA, jak pokazano poniżej:

• Maszyny wirtualne firmy Contoso Corp VSID i PAs: VSID to 5001, SQL PA to 192.168.1.10, Web PA to 192.168.2.20

• Maszyny wirtualne Fabrikam Corp: VSID i PA: VSID to 6001, SQL PA to 192.168.1.10, Web PA to 192.168.2.20

Kontroler sieci wdraża wszystkie polityki sieciowe (w tym mapowanie CA-PA) do agenta hosta SDN, który utrzymuje te polityki w trwałym repozytorium (w tabelach bazy danych OVSDB).

Gdy maszyna wirtualna sieci Web firmy Contoso Corp (10.1.1.12) na hoście Hyper-V 2 tworzy połączenie TCP z programem SQL Server o godzinie 10.1.1.11:

• Maszyna wirtualna wysyła zapytanie ARP dla docelowego adresu MAC 10.1.1.11

• Rozszerzenie VFP w przełączniku vSwitch przechwytuje ten pakiet i wysyła go do agenta hosta SDN

• Agent hosta SDN wyszukuje w magazynie zasad adres MAC 10.1.1.11

• Jeśli zostanie znaleziony adres MAC, agent hosta przesyła odpowiedź ARP do maszyny wirtualnej.

• Jeśli komputer MAC nie zostanie znaleziony, nie zostanie wysłana odpowiedź, a wpis ARP na maszynie wirtualnej dla wersji 10.1.1.11 jest oznaczony jako nieosiągalny.

• Maszyna wirtualna tworzy teraz pakiet TCP z poprawnymi nagłówkami Ethernet i IP urzędu certyfikacji i wysyła go do przełącznika wirtualnego

• Rozszerzenie przekazywania VFP w przełączniku wirtualnym przetwarza ten pakiet za pośrednictwem warstw VFP (opisanych poniżej) przypisanych do źródłowego portu przełącznika wirtualnego, na którym odebrano pakiet i tworzy nowy wpis przepływu w tabeli ujednoliconego przepływu VFP

• Aparat VFP wykonuje dopasowywanie reguł lub wyszukiwanie tabeli przepływu dla każdej warstwy (na przykład warstwy sieci wirtualnej) na podstawie nagłówków IP i Ethernet.

• Dopasowana reguła w warstwie sieci wirtualnej odwołuje się do przestrzeni mapowania CA-PA i wykonuje hermetyzację.

• Typ hermetyzacji (VXLAN lub NVGRE) jest określony w warstwie VNet wraz z identyfikatorem VSID.

• W przypadku hermetyzacji sieci VXLAN zewnętrzny nagłówek UDP jest skonstruowany z identyfikatorem VSID 5001 w nagłówku sieci VXLAN. Zewnętrzny nagłówek IP jest skonstruowany z źródłowym i docelowym adresem PA przypisanym do hosta Hyper-V 2 (192.168.2.20) i hosta Hyper-V 1 (192.168.1.10) odpowiednio na podstawie magazynu zasad agenta hosta SDN.

• Ten pakiet następnie przepływa do warstwy routingu PA w programie VFP.

• Warstwa routingu PA w programie VFP będzie odwoływać się do przedziału sieciowego używanego dla ruchu PA-space, identyfikatora sieci VLAN i stosu TCP/IP hosta, aby poprawnie przekazać pakiet PA do Host 1 Hyper-V.

• Po otrzymaniu hermetyzowanego pakietu Hyper-V Host 1 odbiera pakiet w przedziale sieci PA i przesyła go do vSwitcha.

• VFP przetwarza pakiet przez swoje warstwy VFP i tworzy nowy wpis przepływu w ujednoliconej tabeli przepływu VFP.

• Silnik VFP dopasowuje do reguł przychodzących w warstwie sieci wirtualnej i usuwa zewnętrzne enkapsulowane nagłówki Ethernet, IP i VXLAN pakietu.

• Następnie aparat VFP przekazuje pakiet do portu przełącznika wirtualnego, do którego jest podłączona docelowa maszyna wirtualna.

Podobny proces wymiany ruchu między maszynami wirtualnymi Fabrikam Corp Web a SQL używa ustawień zasad HNV dla firmy Fabrikam Corp. Dzięki HNV, interakcja pomiędzy maszynami wirtualnymi firmy Fabrikam Corp i Contoso Corp zachodzi tak, jakby były częścią swoich oryginalnych intranetów. Nigdy nie mogą ze sobą wchodzić w interakcje, nawet jeśli używają tych samych adresów IP.

Oddzielne adresy (CA i PA), ustawienia polityki hostów Hyper-V oraz translacja adresów między adresami CA i PA dla ruchu przychodzącego i wychodzącego maszyn wirtualnych izolują te zestawy serwerów przy użyciu klucza NVGRE lub VNID VXLAN. Ponadto mapowania i transformacji wirtualizacji rozdzielają architekturę sieci wirtualnej od infrastruktury sieci fizycznej. Mimo że Contoso SQL i Web oraz Fabrikam SQL i Web znajdują się we własnych podsieciach IP o numerach 10.1.1/24, ich fizyczne wdrożenie odbywa się na dwóch hostach w różnych podsieciach PA, odpowiednio 192.168.1/24 i 192.168.2/24. To oznacza, że wdrażanie maszyn wirtualnych między podsieciami i migracja na żywo stają się możliwe dzięki HNV.

architektura wirtualizacji sieci Hyper-V

W systemie Windows Server 2016 HNVv2 jest implementowany przy użyciu wirtualnej platformy filtrowania Azure (VFP), która jest rozszerzeniem filtrowania NDIS w przełączniku Hyper-V. Kluczową koncepcją VFP jest silnik przepływu Match-Action z wewnętrznym interfejsem API uwidocznionym dla agenta hosta SDN na potrzeby programowania zasad sieciowych. Agent hosta SDN odbiera politykę sieciową od kontrolera sieci przez kanały komunikacyjne OVSDB i WCF SouthBound. Nie tylko zasady sieci wirtualnej (na przykład mapowanie CA-PA) są programowane przy użyciu VFP, ale także dodatkowe zasady, takie jak listy ACL, QoS i inne.

Hierarchia obiektów dla rozszerzenia routingu vSwitch i VFP jest następująca:

• Przełącznik wirtualny

  • Zarządzanie zewnętrzną kartą sieciową

  • Odciążania sprzętowe karty sieciowej

  • Globalne zasady przekazywania

  • Port

    • Warstwa przekazywania ruchu wychodzącego do przypinania włosów

    • Listy przestrzeni dla mapowań i pul translacji adresów sieciowych

    • Ujednolicona tabela przepływu

    • Warstwa VFP

      • Tabela przepływu

      • Grupa

      • Reguła

        • Reguły mogą odwoływać się do przestrzeni

W programie VFP tworzona jest warstwa na typ zasad (na przykład Sieć wirtualna) i jest ogólnym zestawem tabel reguł/przepływów. Nie ma żadnych funkcji wewnętrznych do momentu przypisania określonych reguł do tej warstwy w celu zaimplementowania takich funkcji. Każda warstwa ma przypisany priorytet, a warstwy są przypisywane do portu według rosnącego priorytetu. Reguły są podzielone na grupy przede wszystkim według kierunku ruchu sieciowego i rodziny adresów IP. Grupy mają również przypisany priorytet i co najwyżej jedna reguła z grupy może być zgodna z danym przepływem.

Logika przekazywania przełącznika wirtualnego z rozszerzeniem VFP jest następująca:

• Przetwarzanie ruchu przychodzącego (ruch przychodzący z punktu widzenia pakietu przychodzącego do portu)

• Przekazywanie

• Przetwarzanie ruchu wychodzącego (ruch wychodzący z punktu widzenia pakietu opuszczającego port)

VFP obsługuje wewnętrzne przekazywanie MAC dla typów hermetyzacji NVGRE i VXLAN, a także zewnętrzne przekazywanie oparte na protokole MAC VLAN.

Rozszerzenie VFP posiada ścieżki wolnego i szybkiego przejścia dla przesyłu pakietów. Pierwszy pakiet w przepływie musi przechodzić przez wszystkie grupy reguł w każdej warstwie i wykonywać wyszukiwanie reguł, które jest kosztowną operacją. Jednak po zarejestrowaniu przepływu w ujednoliconej tabeli przepływu z listą akcji (na podstawie reguł dopasowanych) wszystkie kolejne pakiety będą przetwarzane na podstawie wpisów tabeli ujednoliconego przepływu.

Zasady HNV są programowane przez agenta hosta. Każda karta sieciowa maszyny wirtualnej jest skonfigurowana przy użyciu adresu IPv4. Są to urzędy certyfikacji, które będą używane przez maszyny wirtualne do komunikowania się ze sobą i są przesyłane w pakietach IP z maszyn wirtualnych. HNV hermetyzuje ramkę CA w ramkę PA zgodnie z zasadami wirtualizacji sieci przechowywanymi w bazie danych agenta hosta.

Rysunek 9. Architektura HNV

Podsumowanie

Centra danych oparte na chmurze mogą zapewnić wiele korzyści, takich jak lepsza skalowalność i lepsze wykorzystanie zasobów. Aby zrealizować te potencjalne korzyści, wymaga technologii, która zasadniczo rozwiązuje problemy ze skalowalnością wielu dzierżaw w środowisku dynamicznym. HNV został zaprojektowany w celu rozwiązania tych problemów, a także poprawy wydajności operacyjnej centrum danych przez oddzielenie topologii sieci wirtualnej dla topologii sieci fizycznej. Opierając się na istniejącym standardzie, HNV działa w dzisiejszym centrum danych i działa z istniejącą infrastrukturą sieci VXLAN. Klienci z HNV mogą teraz konsolidować swoje centra danych w chmurze prywatnej lub bezproblemowo rozszerzać swoje centra danych do środowiska dostawcy serwerów hostingu za pomocą chmury hybrydowej.

Zobacz także

Aby dowiedzieć się więcej o HNVv2, zobacz następujące linki:

Typ zawartości	Źródła
Zasoby społeczności	- Blog architektury chmury prywatnej - Zadaj pytania: cloudnetfb@microsoft.com
RFC	- Wersja robocza dokumentu RFC NVGRE - VXLAN — RFC 7348
Powiązane technologie	— Aby uzyskać szczegółowe informacje techniczne dotyczące wirtualizacji sieci Hyper-V w systemie Windows Server 2012 R2, zobacz szczegóły techniczne wirtualizacji sieciHyper-V - Kontroler sieci