Windows Server Insider Preview build 20206 zawiera te zmiany

CoreNet: Ścieżka danych i transport

• MsQuic – implementacja protokołu transportowego IETF QUIC o otwartym kodzie źródłowym obsługuje zarówno przetwarzanie internetowe HTTP/3, jak i przesyłanie plików SMB.

• Ulepszenia wydajności UDP — UDP staje się bardzo popularnym protokołem przenoszącym coraz większy ruch sieciowy. Dzięki protokołowi QUIC zbudowanemu na bazie UDP oraz rosnącej popularności RTP i niestandardowych (UDP) protokołów przesyłania strumieniowego i gier nadszedł czas, aby podnieść wydajność UDP do poziomu porównywalnego z TCP. W Server vNext uwzględniamy zmianę gry Odciążanie segmentacji UDP (USO). USO przenosi większość pracy wymaganej do wysłania pakietów UDP z procesora na wyspecjalizowany sprzęt karty sieciowej. W uzupełnieniu USO w Server vNext dodaliśmy UDP Receive Side Coalescing (UDP RSC), który łączy pakiety i zmniejsza użycie procesora do przetwarzania UDP. Aby dostosować się do tych dwóch nowych ulepszeń, wprowadziliśmy setki ulepszeń w ścieżce danych UDP, zarówno nadawania, jak i odbierania.

• Ulepszenia wydajności TCP — Zastosowania serwera vNext TCP HyStart++ w celu zmniejszenia utraty pakietów podczas uruchamiania połączenia (szczególnie w sieciach o dużej szybkości) i SendTracker + STOJAK w celu zmniejszenia limitów czasu retransmisji (RTO). Te funkcje są domyślnie włączone w stosie transportowym i zapewniają płynniejszy przepływ danych w sieci z lepszą wydajnością przy dużych prędkościach.
• PktMon obsługa w TCPIP — Narzędzie do diagnostyki sieci wieloskładnikowej dla systemu Windows obsługuje teraz protokół TCPIP, zapewniając wgląd w stos sieciowy. PktMon może być używany do przechwytywania pakietów, wykrywania porzucania pakietów, filtrowania pakietów i liczenia w scenariuszach wirtualizacji, takich jak sieci kontenerowe i SDN.

(Poprawiono) RSC w vSwitch

RSC w vSwitch został ulepszony dla lepszej wydajności. Wydana po raz pierwszy w systemie Windows Server 2019 funkcja Receive Segment Coalescing (RSC) w przełączniku vSwitch umożliwia łączenie pakietów i przetwarzanie ich jako jednego większego segmentu po wejściu do przełącznika wirtualnego. To znacznie zmniejsza cykle procesora zużywane podczas przetwarzania każdego bajtu (cykle/bajt).

Jednak w swojej pierwotnej formie, gdy ruch opuszcza wirtualny przełącznik, zostanie on ponownie posegmentowany w celu podróżowania przez VMBus. W systemie Windows Server vNext segmenty pozostaną połączone w całej ścieżce danych, dopóki nie zostaną przetworzone przez zamierzoną aplikację. Poprawia to dwa scenariusze:

– Ruch z zewnętrznego hosta, odbierany przez wirtualną kartę sieciową

– Ruch z wirtualnej karty sieciowej do innej wirtualnej karty sieciowej na tym samym hoście

Te ulepszenia RSC w vSwitch będą domyślnie włączone; nie musisz nic robić.

Obsługa równoważenia obciążenia Direct Server Return (DSR) dla kontenerów i Kubernetes

DSR to implementacja asymetrycznego rozkładu obciążenia sieciowego w systemach równoważenia obciążenia, co oznacza, że ​​ruch żądań i odpowiedzi wykorzystuje inną ścieżkę sieciową. Korzystanie z różnych ścieżek sieciowych pomaga uniknąć dodatkowych przeskoków i zmniejsza opóźnienia, dzięki którym nie tylko zwiększa prędkość zwiększa czas odpowiedzi między klientem a usługą, ale także usuwa dodatkowe obciążenie z obciążenia stabilizator.

Korzystanie z DSR to przejrzysty sposób na zwiększenie wydajności sieci dla aplikacji przy niewielkich lub zerowych zmianach infrastruktury. Więcej informacji

Przedstawiamy reguły powinowactwa/antypowinowactwa maszyny wirtualnej (role) z klastrowaniem pracy awaryjnej

W przeszłości korzystaliśmy z właściwości grupy AntiAffinityClassNames, aby rozdzielić role, ale nie było świadomości specyficznej dla witryny. Jeśli istniał kontroler domeny, który musiał znajdować się w jednej lokacji, a kontroler domeny, który musi znajdować się w innej lokacji, nie było to gwarantowane. Ważne było również, aby pamiętać o wpisaniu prawidłowego ciągu AntiAffinityClassNames dla każdej roli.

Istnieją następujące polecenia cmdlet PowerShell:

• New-ClusterAffinityRule = Umożliwia utworzenie nowej reguły Affinity lub AntiAffinity. Istnieją cztery różne typy reguł (-RuleType)

• DifferentFaultDomain = utrzymuj grupy w różnych domenach błędów
• DifferentNode = utrzymuj grupy w różnych węzłach (uwaga może znajdować się w innej lub tej samej domenie błędów)
• SameFaultDomain = utrzymuj grupy w tej samej domenie błędów
• SameNode = trzymaj grupy w tym samym węźle

• Set-ClusterAffinityRule = Pozwala włączyć (domyślnie) lub wyłączyć regułę

• Add-ClusterGroupToAffinityRule = Dodaj grupę do istniejącej reguły

• Get-ClusterAffinityRule = Wyświetl wszystkie lub określone reguły

• Add-ClusterSharedVolumeToAffinityRule = To jest dla magazynu Affinity/AntiAffinity, gdzie można dodać udostępnione woluminy klastra do bieżących reguł

• Remove-ClusterAffinityRule = Usuwa określoną regułę

• Remove-ClusterGroupFromAffinityRule = Usuwa grupę z określonej reguły

• Remove-ClusterSharedVolumeFromAffinityRule = Usuwa określony udostępniony wolumin klastra z określonej reguły

• Move-ClusterGroup -IgnoreAffinityRule = To nie jest nowe polecenie cmdlet, ale umożliwia wymuszone przeniesienie grupy do domeny węzła lub domeny błędów, które w przeciwnym razie byłyby uniemożliwione. W PowerShell, Cluster Manager i Windows Admin Center pokaże, że grupa narusza zasady, jako przypomnienie.

Teraz możesz trzymać rzeczy razem lub osobno. Podczas przenoszenia roli obiekt koligacji zapewnia, że ​​można go przenieść. Obiekt wyszukuje również inne obiekty i również je weryfikuje, w tym dyski, dzięki czemu możesz mieć powinowactwo magazynu z maszynami wirtualnymi (lub rolami) i udostępnionymi woluminami klastra (powinowactwo magazynu), jeśli pożądany. Możesz dodać role do wielu, na przykład kontrolerów domeny. Można ustawić regułę AntiAffinity, aby kontrolery domeny pozostały w innej domenie błędów. Następnie możesz ustawić regułę koligacji dla każdego kontrolera domeny do konkretnego dysku CSV, aby mogły pozostać razem. Jeśli masz maszyny wirtualne SQL Server, które muszą znajdować się w każdej lokacji z określonym kontrolerem domeny, możesz ustawić regułę koligacji tej samej domeny błędów między każdym kodem SQL a odpowiednim kontrolerem domeny. Ponieważ jest to teraz obiekt klastra, jeśli spróbujesz przenieść maszynę wirtualną SQL z jednej lokacji do drugiej, sprawdza ona wszystkie powiązane z nią obiekty klastra. Widzi, że istnieje parowanie z DC w tej samej witrynie. Następnie widzi, że DC ma regułę i weryfikuje ją. Widzi, że kontroler domeny nie może znajdować się w tej samej domenie błędów, co drugi kontroler domeny, więc ruch jest niedozwolony.

Są wbudowane override, dzięki czemu w razie potrzeby możesz wymusić ruch. W razie potrzeby można również łatwo wyłączyć/włączyć reguły, w porównaniu do AntiAffinityClassNames z ClusterEnforcedAffinity, gdzie trzeba było usunąć właściwość, aby została przeniesiona i pojawiła się. Dodaliśmy również funkcjonalność w Drain, gdzie jeśli musi przenieść się do innej domeny i istnieje reguła AntiAffinity, która temu zapobiega, pominiemy tę regułę. Wszelkie naruszenia reguł są widoczne do wglądu zarówno w Administratorze klastra, jak iw Centrum administracyjnym Windows.

Elastyczna ochrona funkcji BitLocker dla klastrów pracy awaryjnej

Funkcja BitLocker jest dostępna dla klastra pracy awaryjnej od dłuższego czasu. Wymaganie było takie, że wszystkie węzły klastra muszą znajdować się w tej samej domenie, w której klucz funkcji BitLocker jest powiązany z obiektem nazwy klastra (CNO). Jednak w przypadku tych klastrów na obrzeżach, klastrów grup roboczych i klastrów wielodomenowych usługa Active Directory może nie być obecna. Bez Active Directory nie ma CNO. Te scenariusze klastrowe nie miały zabezpieczenia danych w spoczynku. Począwszy od niejawnych testerów systemu Windows Server, wprowadziliśmy nasz własny klucz BitLocker przechowywany lokalnie (zaszyfrowany) do użytku w klastrze. Ten dodatkowy klucz zostanie utworzony tylko wtedy, gdy dyski klastrowane będą chronione funkcją BitLocker po utworzeniu klastra.

Nowe testy sieci Cluster Validation

Konfiguracje sieciowe stają się coraz bardziej złożone. Dodano nowy zestaw testów sprawdzania poprawności klastra, aby pomóc w sprawdzeniu poprawności ustawień konfiguracji. Testy te obejmują:

• Wyświetl kolejność metryk sieci (wersja sterowników)
• Sprawdź poprawność konfiguracji sieci klastra (konfiguracja przełącznika wirtualnego)
• Ostrzeżenie o weryfikacji konfiguracji IP
• Sukces komunikacji sieciowej
• Konfiguracje wbudowanego zespołu przełączników (symetria, vNIC, pNIC)
• Sprawdź poprawność konfiguracji Zapory systemu Windows
• Skonfigurowano QOS (PFC i ETS)

(Uwaga dotycząca powyższych ustawień QOS: nie oznacza to, że te ustawienia są prawidłowe, po prostu, że ustawienia są zaimplementowane. Te ustawienia muszą być zgodne z fizyczną konfiguracją sieci i dlatego nie możemy sprawdzić, czy są ustawione na odpowiednie wartości)

Obrazy Server Core Container są o 20 procent mniejsze

Co powinno być znaczącą wygraną dla każdego przepływu pracy, który pobiera obrazy kontenerów systemu Windows, rozmiar pobierania obrazu Insider kontenera systemu Windows Server Core został zmniejszony o 20%. Zostało to osiągnięte przez optymalizację zestawu wstępnie skompilowanych obrazów natywnych platformy .NET zawartych w obrazie kontenera Server Core. Jeśli używasz .NET Framework z kontenerami Windows, w tym Windows PowerShell, użyj a Obraz .NET Framework, który będzie zawierał dodatkowe wstępnie skompilowane obrazy natywne platformy .NET w celu utrzymania wydajności w tych scenariuszach, przy jednoczesnym zmniejszeniu rozmiaru.

Co nowego w protokole SMB

Podnosząc poprzeczkę bezpieczeństwa jeszcze bardziej, SMB obsługuje teraz szyfrowanie AES-256. Zwiększa się również wydajność podczas korzystania z szyfrowania SMB lub podpisywania za pomocą SMB Direct z kartami sieciowymi obsługującymi RDMA. SMB ma teraz również możliwość wykonywania kompresji w celu poprawy wydajności sieci.

Przegląd prywatności