Hyper-V – Konfiguracja sieci najlepsze praktyki

Microsoft w Hyper-V dokonuje ciągle wielu postępów w sposobie, w jaki obsługuje warstwę sieciową dla maszyn wirtualnych działających na Hyper-V. Ma cechy, które występują tylko tutaj, w porównaniu z innymi hiperwizorami.

Sieci wirtualne są najważniejszym elementem Hyper-V, które umożliwiają wirtualizację zasobów serwera. W świecie sieci nastąpiło wiele zmian, które są możliwe dzięki wirtualizacji i abstrakcji zasobów sieciowych od podstawowego sprzętu.

Przyjrzyjmy się podstawom sieci Hyper-V, infrastrukturze przełączników wirtualnych, klastrom Hyper-V i nowym funkcjom sieciowym dostępnym w systemie Windows Server 2019.

Podobnie jak w przypadku innych komponentów wirtualizowanej infrastruktury serwerowej, istnieje punkt, w którym świat wirtualny musi spotkać się z fizycznym. Może to być fizyczny procesor/pamięć i pamięć masowa, ale obejmuje to również sieć. W pewnym momencie pakiety z maszyn wirtualnych działających w Hyper-V muszą zostać skierowane do sieci fizycznej.

Wirtualna sieć Hyper-V

Hyper-V tworzy wirtualne karty sieciowe i wykorzystuje również wirtualne przełączniki jako konstrukcję, do której te wirtualne karty sieciowe są podłączane. Na obu frontach wirtualne karty sieciowe są bardzo podobne do fizycznych kart sieciowych, działając przy użyciu tych samych mechanizmów. Wirtualne przełączniki to zwirtualizowane wersje przełączników sieciowych. Mają wszystkie cechy, które można znaleźć w przełączniku fizycznym z funkcjami warstwy 2, takimi jak sieci VLAN itp.

Wtyczka wirtualnych kart sieciowych do przełączników wirtualnych i fizyczne karty sieciowe w hoście Hyper-V to łącze w górę od przełącznika wirtualnego do przełącznika fizycznego.

Schemat sieci Hyper-V

Typy przełączników wirtualnych Hyper-V

Hyper-V oferuje różne typy przełączników wirtualnych, aby dopasować je do różnych przypadków użycia. Umożliwia również elastyczność w sposobie łączenia sieci wirtualnej z siecią fizyczną.

Istnieją trzy różne typy przełączników wirtualnych Hyper-V, które są używane do łączenia kart sieciowych maszyn wirtualnych Hyper-V:

  • Zewnętrzny przełącznik wirtualny (External Virtual Switch).
  • Wewnętrzny przełącznik wirtualny (Internal Virtual Switch).
  • Prywatny przełącznik wirtualny (Private Virtual Switch).

Zewnętrzny przełącznik wirtualny

Takie rozwiązanie jest zdecydowanie najpopularniejszym przełącznikiem wirtualnym używanym w infrastrukturze sieci wirtualnej Hyper-V. Zewnętrzny przełącznik wirtualny to typ przełącznika wirtualnego używanego do łączenia maszyn wirtualnych z siecią fizyczną.

Charakterystyka zewnętrznego przełącznika wirtualnego obejmuje:

  • Możliwość łączenia maszyn wirtualnych z siecią fizyczną.
  • Umożliwia maszynom wirtualnym komunikowanie się ze sobą na tym samym hoście Hyper-V lub różnych hostach Hyper-V.
  • Domyślna opcja podczas tworzenia nowego wirtualnego przełącznika Hyper-V.

Zewnętrzny przełącznik wirtualny zapewnia łączność z ruchem sieci LAN i WAN zgodnie z trasą/segmentacją w sieci fizycznej.

Wewnętrzny przełącznik wirtualny

Jak można sobie wyobrazić, wewnętrzny przełącznik wirtualny intuicyjnie nie zapewnia dostępu zewnętrznego do hosta Hyper-V. Wewnętrzny przełącznik wirtualny umożliwia maszynom wirtualnym podłączonym do przełącznika komunikację ze sobą, a także z hostem Hyper-V.

Dobrym sposobem myślenia o internetowym przełączniku wirtualnym jest myślenie o przełączniku fizycznym, który nie jest połączony z żadnym innym przełącznikiem. Każde urządzenie podłączone do przełącznika może komunikować się ze sobą, ale nie może komunikować się z innymi urządzeniami zewnętrznymi. Wewnętrzny przełącznik wirtualny nie jest obsługiwany przez fizyczną kartę sieciową na hoście Hyper-V.

Wewnętrzny przełącznik wirtualny ma idealny przypadek użycia, w którym chcesz odizolować ruch wokół grupy maszyn wirtualnych. Pozwala to na łatwe dostarczanie odizolowanych środowisk laboratoryjnych, w których maszyny wirtualne mogą komunikować się tylko ze sobą lub wzmacnianie bezpieczeństwa sieci w niektórych przypadkach użycia, takich jak zgodność. Wewnętrzny wirtualny przełącznik zapewnia sposób na bezpieczne i pewne replikowanie podsieci produkcyjnych w odizolowanym środowisku dla laboratoriów, testów, POC itp.

Możesz wyprowadzać ruch z wewnętrznego wirtualnego przełącznika za pomocą routera lub innego urządzenia, które może kierować ruchem między segmentami sieci.

Poniżej znajduje się przykład wykorzystania routera VM do kierowania ruchem między maszynami wirtualnymi znajdującymi się na wewnętrznym wirtualnym przełączniku i tymi, które znajdują się na zewnętrznym wirtualnym przełączniku. Dotyczy to w równym stopniu kierowania ruchem do zewnętrznych maszyn wirtualnych lub maszyn fizycznych poza samym hostem Hyper-V.

Używanie routera do kierowania ruchem pomiędzy zewnętrznymi i wewnętrznymi zasobami przełącznika wirtualnego

Prywatny przełącznik wirtualny

Prywatny przełącznik wirtualny jest zasadniczo taki sam jak wewnętrzny przełącznik wirtualny, z tym wyjątkiem, że nawet system operacyjny zarządzania nie może komunikować się z maszynami wirtualnymi znajdującymi się na prywatnym przełączniku wirtualnym. Oznacza to, że nie jest w stanie podłączyć się do przełącznika wirtualnego za pomocą wirtualnego adaptera sieciowego.

Jaki przypadek użycia byłby odpowiedni do użycia tego typu przełącznika wirtualnego Hyper-V?

Chociaż nie jest to bardzo powszechne, klasterowanie gościnne zapewnia możliwość rozszerzenia dostępności oferowanej przez sam Hyper-V pod względem wysokiej dostępności aplikacji. Klastry gościnne wykorzystują specjalną sieć do sprawdzania dostępności VM, która powinna być używana tylko do komunikacji między maszynami wirtualnymi.

Używając prywatnego przełącznika wirtualnego, gwarantuje się, że tylko hosty klastra gościnnego mogą komunikować się przez tę sieć, nawet bez wprowadzania ruchu przez system operacyjny zarządzania. Jest to idealny przypadek użycia w celu zapewnienia ruchu między maszynami wirtualnymi w odizolowanym segmencie sieci.

Łączność systemu operacyjnego zarządzania

Jeśli zauważysz, że podczas tworzenia nowego zewnętrznego przełącznika wirtualnego Hyper-V zobaczysz opcję „Zezwalaj systemowi operacyjnemu zarządzania na współdzielenie tej karty sieciowej (Allow management operating system to share this network adapter.)”. Co to oznacza?

Oznacza to zasadniczo, że system operacyjny zarządzania zostanie podłączony do przełącznika wirtualnego Hyper-V.

Wybieranie opcji zezwalającej systemowi operacyjnemu zarządzania na udostępnianie tej karty sieciowej

Gdy zdecydujesz się zezwolić systemowi operacyjnemu zarządzania na współdzielenie tego ustawienia karty sieciowej, zobaczysz wyspecjalizowane karty sieciowe w konfiguracji kart sieciowych na hoście Hyper-V. Są one wymienione jako vNetwork z dołączoną nazwą zewnętrznego wirtualnego przełącznika Hyper-V.

Adapter zarządzający podłączony do zewnętrznych wirtualnych przełączników Hyper-V

To samo dotyczy odznaczenia tego pola. Po odznaczeniu wyspecjalizowane interfejsy vNetwork są automatycznie usuwane. Zauważysz, że masz możliwość zaznaczenia tego pola tylko na zewnętrznym przełączniku wirtualnym. Dzieje się tak, ponieważ zewnętrzny przełącznik wirtualny jest powiązany z fizycznymi kartami sieciowymi Hyper-V.

W przypadku wewnętrznych i prywatnych przełączników wirtualnych fizyczne karty sieciowe obecne na hoście Hyper-V nie są używane, ponieważ te dwa typy przełączników wirtualnych są izolowane, co opisałem powyżej.

Hyper-V NIC Teaming

Jedną z ciekawszych funkcji sieciowych wprowadzonych od czasu systemu Windows Server 2016 i nowszych wersji Hyper-V jest konwergentna sieć.

Dzięki konwergentnej sieci zniesiono ograniczenia dotyczące korzystania z dedykowanych fizycznych kart sieciowych udostępnianych przez usługi z włączonym zdalnym dostępem do pamięci (RDMA) używane przez system operacyjny zarządzania i dedykowanych fizycznych kart sieciowych obsługujących wirtualne przełączniki Hyper-V. Teraz te same fizyczne karty sieciowe mogą być używane przez oba typy usług, co pozwala maszynom wirtualnym Hyper-V na korzystanie z tych udostępnionych kart sieciowych RDMA do normalnej komunikacji TCP/IP.

Jest to realizowane przez system Windows Server 2016 i nowsze udostępniające RDMA za pośrednictwem wirtualnej karty sieciowej partycji hosta, co pozwala usługom partycji hosta na korzystanie z RDMA z tymi samymi kartami sieciowymi co goście maszyn wirtualnych Hyper-V. Usługi RDMA są udostępniane procesom hosta za pomocą RDMA przez konwergentną sieć Ethernet (RoCE).

Czy wymagany jest fizyczny dostęp do karty sieciowej?

W przeciwieństwie do tworzenia NIC Teaming w poprzednich wersjach systemu Windows Server, funkcja konwergentnej sieci nie wymaga dostępu do fizycznego urządzenia. Podczas gdy można używać NIC Teaming, wprowadzono nowe podejście o nazwie Switch Embedded Teaming lub SET.

Dzięki SET fizyczne karty sieciowe na hoście Hyper-V są połączone i zespołowe za pomocą wirtualnego przełącznika. Zakłada to pewne wymagania wstępne:

  • Dwa serwery z systemem Windows Server 2016 Datacenter lub Windows Server 2016 Standard.
  • Jedna karta sieciowa z obsługą RDMA, certyfikowana, zainstalowana na każdym serwerze.
  • Rola serwera Hyper-V zainstalowana na każdym serwerze.

Klastry Hyper-V i dodatkowe wymagania sieciowe

Oprócz tradycyjnych wymagań dotyczących sieci maszyn wirtualnych w środowisku Hyper-V i wykorzystania różnych przełączników wirtualnych Hyper-V w celu zapewnienia łączności sieciowej maszynom wirtualnym Hyper-V, w przypadku klastrów Hyper-V należy wziąć pod uwagę dodatkowe kwestie związane z ruchem sieciowym.

Czym jest klaster Hyper-V?

Klaster Hyper-V umożliwia wysoką dostępność maszyn wirtualnych Hyper-V poprzez umieszczenie roli Hyper-V na klastrze Windows Failover z co najmniej dwoma skonfigurowanymi hostami Hyper-V. W ten sposób, jeśli pojedynczy host Hyper-V ulegnie awarii z powodu problemów sprzętowych lub innych, maszyny wirtualne działające w ramach konfiguracji roli wysokiej dostępności zostaną ponownie uruchomione na sprawnym hoście, aby przywrócić maszynę wirtualną do działania.

Istnieje kilka kluczowych wymagań infrastrukturalnych, które to umożliwiają, takich jak posiadanie „podobnie” skonfigurowanych hostów (najlepiej identycznych, a także współdzielonej pamięci masowej. Pliki maszyn wirtualnych muszą znajdować się w pamięci masowej, do której mają dostęp wszystkie węzły klastra, aby każdy węzeł mógł przejąć własność maszyny wirtualnej Hyper-V w przypadku wystąpienia awarii.

Poza normalną komunikacją sieciową maszyn wirtualnych, która odbywa się na trzech typach przełączników wirtualnych Hyper-V, jaki dodatkowy ruch sieciowy jest potrzebny w klastrze Hyper-V?

Elementy klastra Hyper-V

Istnieje wiele typów wyspecjalizowanego ruchu, który umożliwia działanie klastra Hyper-V. Są one związane z podstawowym klastrem Windows Failover, pamięcią masową i komunikacją migracji maszyn wirtualnych. Są to:

Cluster Network – Windows Failover Cluster używa specjalnej komunikacji klastra do wymiany informacji między węzłami klastra. Termin heartbeat został wymyślony jako określenie tego procesu. Heartbeaty to małe pakiety (134 bajty), które podróżują przez port UDP 3343 we wszystkich sieciach skonfigurowanych do użytku klastra między wszystkimi węzłami.

Jaki jest cel tej specjalnej komunikacji sieciowej?

  • Ustala, czy sieć klastra jest włączona czy wyłączona.
  • Sprawdza trasy między węzłami.
  • Kontroluje kondycję węzła klastra, określając, czy jest w dobrym czy złym stanie.
  • Ten wyspecjalizowany ruch jest niezwykle istotny dla stabilności klastra Hyper-V. Nawet jeśli węzeł jest sprawny i z jakiegoś powodu nie można nawiązać komunikacji klastra z węzłem, pozostałe węzły w klastrze zakładają, że występuje problem i oddzielą dotkniętego hosta.
  • Klastry trybu failover systemu Windows wykorzystują wszystkie możliwe sieci do komunikacji między sobą. Jeśli jedna z sieci jest niedostępna, spróbuje innej sieci, aby nawiązać komunikację klastra. Możesz skonfigurować to zachowanie w Menedżerze klastra trybu failover. Ustawienie Zezwalaj na komunikację sieciową klastra w tej sieci wpływa na to zachowanie i pozwala administratorom wybrać, które sieci komunikacja klastra ma być dostępna dla tego procesu

Sieć pamięci masowej (Storage Network) – w samodzielnej konfiguracji serwera Hyper-V z pamięcią masową bezpośrednio podłączoną (DAS) nie jest potrzebna żadna specjalna sieć do dedykowanej sieci komunikacyjnej pamięci masowej, ponieważ wszystko to jest obsługiwane wewnętrznie. Sieć pamięci masowej jest niezwykle ważną siecią, jeśli chodzi o klastry trybu failover systemu Windows. Jak wspomniałem wcześniej, jednym z kluczowych wymagań klastra Hyper-V jest współdzielona pamięć masowa.

Dzięki temu węzły obliczeniowe w klastrze Hyper-V mogą po prostu przejąć moc obliczeniową/pamięć dla maszyny wirtualnej bez zmiany pamięci masowej. Jest to obsługiwane albo przez zewnętrzną macierz pamięci masowej dostępną za pomocą iSCSI, SMB itp., albo przez pamięć masową zdefiniowaną programowo za pomocą Storage Spaces Direct, zapewniającą współdzieloną pamięć masową między węzłami klastra Hyper-V. Pamięć masowa jest zazwyczaj wrażliwa na przepustowość i opóźnienia. Jeśli przepustowość zmniejszy się lub wzrośnie opóźnienie, szybko pojawią się problemy z wydajnością. Dostępność pamięci masowej Storage Spaces Direct, kodowanie wymazywania i inne mechanizmy opierają się na niezwykle szybkiej sieci między hostami. Współdzielona pamięć masowa za pomocą zewnętrznej macierzy pamięci masowej wymaga również pamięci masowej o wysokiej wydajności.

Udostępnione woluminy klastra (Cluster Shared Volumes CSV) – umożliwiają wszystkim hostom w klastrze Hyper-V dostęp do tej samej pamięci masowej przeznaczonej dla maszyn wirtualnych jednocześnie. CSV wymaga wymiany i aktualizacji metadanych między hostami. Ten specjalny typ komunikacji sieciowej jest częścią ogólnej komunikacji pamięci masowej wymaganej w klastrze Hyper-V.

Migracja na żywo (Live Migration) – jest to specjalistyczna sieć, która służy do przesyłania informacji o stanie pamięci z jednego hosta na inny host dla maszyny wirtualnej. Umożliwia to przenoszenie maszyny wirtualnej między hostami bez przestoju. Jest to główna funkcja, która umożliwia wykonywanie operacji konserwacyjnych na konkretnym hoście poprzez proste Live Migrating VMs z hosta na inne hosty w klastrze.

Najlepsze praktyki konfiguracji sieci Hyper-V

Przyjrzyjmy się najlepszym praktykom sieciowym Hyper-V, o których należy pamiętać podczas projektowania i tworzenia infrastruktury Hyper-V.

  • Jeśli to możliwe, zainstaluj lub uaktualnij do najnowszej wersji systemu Windows Server. W każdej wersji systemu Windows Server pojawiają się nowe i ulepszone możliwości związane z Hyper-V.
  • Używaj aktualnych fizycznych kart sieciowych obsługiwanych przez firmę Microsoft, które mają możliwość korzystania z funkcji Remote Direct Memory Access (RDMA).
  • Upewnij się, że używasz najnowszych sterowników kart sieciowych i oprogramowania układowego.
  • Używaj kolejki maszyn wirtualnych lub kart sieciowych z włączoną funkcją VMQ — zapewnia to korzyści wirtualizacji sprzętu, które umożliwiają wydajniejszą łączność sieciową dla protokołów TCP/IP/iSCSI i FCoE.
  • Używaj szybkich sieci między hostami Hyper-V w klastrze Hyper-V — używaj co najmniej sieci 10 GbE między hostami Hyper-V, aby zapewnić spełnienie wymagań dotyczących przepustowości i wydajności między hostami klastra.
  • Włącz ramki Jumbo — ramki Jumbo umożliwiają wydajniejszą komunikację sieciową w aplikacjach o wysokiej wydajności, ponieważ umożliwiają większe ramki transmisji i zmniejszają wykorzystanie procesora na hostach. Ramki Jumbo mają zazwyczaj 9000 bajtów lub więcej w przeciwieństwie do standardowego rozmiaru ramki Ethernet 1500 bajtów.
  • Nie używaj funkcji TCP Chimney Offloading ani IPsec Offloading w systemie Windows Server 2016. Technologie te zostały wycofane w systemie Windows Server 2016 i mogą mieć wpływ na wydajność serwera i sieci. Aby wyłączyć funkcję TCP Chimney Offload, uruchom następujące polecenia z podwyższonego poziomu wiersza polecenia:
    • Netsh int tcp show global – wyświetla bieżące ustawienia TCP.
    • netsh int tcp set global fireplace=disabled – wyłącza funkcję TCP Chimney Offload, jeśli jest włączona.
  • Upewnij się, że używasz redundantnych ścieżek między hostami klastra Hyper-V, aby mieć pewność, że w przypadku awarii jednej ścieżki istnieje inna ścieżka, która może zostać użyta do komunikacji.
  • Zaplanuj sieci Hyper-V – szczególnie w przypadku klastrów Hyper-V planowanie sieci jest niezbędne. Upewnij się, że masz oddzielne zakresy IP/podsieci, sieci VLAN itp. dla sieci specyficznych dla klastra (migracja na żywo, klaster, pamięć masowa, sieci maszyn wirtualnych).
  • Nie używaj ReFS z woluminami współdzielonymi klastra (CSV) – obecnie, gdy jest używany z CSV, ReFS powoduje, że klaster działa w trybie przekierowania systemu plików, który wysyła wszystkie dane wejścia/wyjścia przez sieć klastra do węzła koordynującego dla woluminu. Może to znacząco wpłynąć na wydajność.
  • Sieć klastra i jej wykorzystanie – powinieneś włączyć wiele sieci do komunikacji klastra, ponieważ zapewnia to wbudowaną odporność komunikacji klastra, pomagając zapewnić HA tej ważnej komunikacji sieciowej w klastrze Hyper-V.
  • Włączaj dostęp do systemu operacyjnego zarządzania tylko w sieciach, które są niezbędne. Zrozum, jak tworzone jest wyspecjalizowane połączenia vNetwork na hoście Hyper-V.
  • Używana sieć konwergentna – sieć konwergentna umożliwia znacznie wydajniejsze wykorzystanie fizycznych adapterów na hoście Hyper-V, a także dostępnej przepustowości.
  • Używana funkcja Switch Embedded Teaming – dzięki funkcji Switch Embedded Teaming można tworzyć zespół sieciowy za pośrednictwem przełącznika wirtualnego zamiast używać zespołu fizycznego.
  • Jeśli używasz systemu Windows Server 2019, skorzystaj z funkcji Receive Segment Coalescing (RSC) w celu poprawy wydajności obciążeń wirtualnych.
  • W przypadku systemu Windows Server 2019 użyj szyfrowanych sieci – umożliwia to szyfrowanie całej komunikacji sieciowej w sieciach wirtualnych w celu szyfrowania w trakcie przesyłania.

Podsumowanie

W tym wpisie zająłem się kwestią siecią, która jest krwoobiegiem środowiska Hyper-V. Niezależnie od tego czy mówimy o sieci fizycznej czy wirtualnej. Warto wdrożyć opisane elementy, aby wydajność, ciągłość oraz niezawodoność infrastruktury była możliwe jak najwyższa.


Dziękuję Ci, za poświęcony czas na przeczytanie tego artykułu. Jeśli był on dla Ciebie przydatny, to gorąco zachęcam Cię do zapisania się na mój newsletter, jeżeli jeszcze Cię tam nie ma. Proszę Cię także o “polubienie” mojego bloga na Facebooku oraz kanału na YouTube – pomoże mi to dotrzeć do nowych odbiorców. Raz w tygodniu (niedziela punkt 17.00) otrzymasz powiadomienia o nowych artykułach / projektach zanim staną się publiczne. Możesz również pozostawić całkowicie anonimowy pomysł na wpis/nagranie.

Link do formularza tutaj: https://beitadmin.pl/pomysly

Pozostaw również komentarz lub napisz do mnie wiadomość odpisuję na każdą, jeżeli Masz jakieś pytania:).

Dodaj komentarz

beitadmin.pl - Droga Administratora IT