Windows Server Insider Preview build 20206 идва с тези промени

CoreNet: Път на данни и транспорт

• MsQuic – реализация с отворен код на IETF QUIC транспортния протокол захранва както HTTP/3 уеб обработката, така и SMB прехвърлянето на файлове.

• Подобрения в производителността на UDP — UDP се превръща в много популярен протокол, пренасящ все повече и повече мрежов трафик. С протокола QUIC, изграден върху UDP и нарастващата популярност на RTP и персонализираните (UDP) протоколи за стрийминг и игри, е време да доведем производителността на UDP до ниво, равно на TCP. В Server vNext включваме промяната на играта Разтоварване на UDP сегментиране (USO). USO премества по-голямата част от работата, необходима за изпращане на UDP пакети от процесора към специализирания хардуер на NIC. В допълнение към USO в Server vNext ние включваме UDP Receive Side Coalescing (UDP RSC), което обединява пакети и намалява използването на процесора за UDP обработка. За да продължим с тези две нови подобрения, направихме стотици подобрения в пътя на UDP данни, както за предаване, така и за получаване.

• Подобрения в производителността на TCP - Сървър vNext използва TCP HyStart++ за намаляване на загубата на пакети по време на стартиране на връзката (особено при високоскоростни мрежи) и SendTracker + РАКА за намаляване на времето за изчакване на повторно предаване (RTO). Тези функции са активирани в транспортния стек по подразбиране и осигуряват по-плавен поток от мрежови данни с по-добра производителност при високи скорости.
• PktMon поддръжка в TCPIP - Инструментът за междукомпонентна мрежова диагностика за Windows вече има поддръжка за TCPIP, осигуряваща видимост в мрежовия стек. PktMon може да се използва за улавяне на пакети, откриване на падане на пакети, филтриране на пакети и броене за сценарии за виртуализация, като контейнерна мрежа и SDN.

(Подобрен) RSC в vSwitch

RSC в vSwitch е подобрен за по-добра производителност. Публикувано за първи път в Windows Server 2019, Receive Segment Coalescing (RSC) във vSwitch позволява пакетите да бъдат обединени и обработени като един по-голям сегмент при влизане във виртуалния комутатор. Това значително намалява циклите на процесора, изразходвани за обработка на всеки байт (цикли/байт).

Въпреки това, в първоначалния си вид, след като трафикът излезе от виртуалния комутатор, той ще бъде повторно сегментиран за пътуване през VMBus. В Windows Server vNext сегментите ще останат обединени по целия път на данни, докато не бъдат обработени от предвиденото приложение. Това подобрява два сценария:

– Трафик от външен хост, получен от виртуална NIC

– Трафик от виртуална NIC към друга виртуална NIC на същия хост

Тези подобрения на RSC във vSwitch ще бъдат активирани по подразбиране; не се изискват никакви действия от ваша страна.

Поддръжка за балансиране на натоварването за директно връщане на сървъра (DSR) за контейнери и Kubernetes

DSR е реализация на асиметрично разпределение на мрежовото натоварване в системи с балансирано натоварване, което означава, че трафикът на заявка и отговор използват различен мрежов път. Използването на различни мрежови пътища помага да се избегнат допълнителни скокове и намалява латентността, с която не само се ускорява увеличава времето за реакция между клиента и услугата, но също така премахва допълнително натоварване от натоварването балансьор.

Използването на DSR е прозрачен начин за постигане на повишена производителност на мрежата за вашите приложения с малки или никакви промени в инфраструктурата. Повече информация

Представяне на правила за афинитет/антиафинитет на виртуална машина (роля) с клъстериране при отказ

В миналото разчитахме на груповото свойство AntiAffinityClassNames, за да държим ролите разделени, но нямаше специфична за сайта информираност. Ако имаше DC, който трябваше да бъде в един сайт, и DC, който трябва да бъде в друг сайт, това не беше гарантирано. Също така беше важно да запомните да въведете правилния низ AntiAffinityClassNames за всяка роля.

Има тези командлети на PowerShell:

• New-ClusterAffinityRule = Това ви позволява да създадете ново AffinityRule или AntiAffinityrule. Има четири различни типа правила (-RuleType)

• DifferentFaultDomain = запазване на групите в различни домейни на грешки
• DifferentNode = запазване на групите на различни възли (забележката може да е в различен или същия домейн на грешка)
• SameFaultDomain = запазване на групите в един и същ домейн за грешка
• SameNode = запази групите на един и същ възел

• Set-ClusterAffinityRule = Това ви позволява да активирате (по подразбиране) или деактивирате правило

• Add-ClusterGroupToAffinityRule = Добавете група към съществуващо правило

• Get-ClusterAffinityRule = Показване на всички или конкретни правила

• Add-ClusterSharedVolumeToAffinityRule = Това е за съхранение Affinity/AntiAffinity, където споделените томове на клъстерите могат да се добавят към текущите правила

• Remove-ClusterAffinityRule = Премахва конкретно правило

• Remove-ClusterGroupFromAffinityRule = Премахва група от конкретно правило

• Remove-ClusterSharedVolumeFromAffinityRule = Премахва конкретен споделен том на клъстер от конкретно правило

• Move-ClusterGroup -IgnoreAffinityRule = Това не е нов командлет, но ви позволява принудително да преместите група към възел или домейн за грешка, които иначе биха били предотвратени. В PowerShell, Cluster Manager и Windows Admin Center това ще покаже, че групата е в нарушение като напомняне.

Сега можете да държите нещата заедно или разделени. При преместване на роля обектът на афинитет гарантира, че може да бъде преместен. Обектът също търси други обекти и ги проверява, включително дискове, за да можете да имате афинитет на съхранение с виртуални машини (или роли) и клъстерни споделени томове (афинитет към съхранение), ако желано. Можете да добавяте роли към множества, като например контролери на домейн. Можете да зададете правило AntiAffinity, така че DC да останат в различен домейн на грешка. След това можете да зададете правило за афинитет за всеки от DC към тяхното конкретно CSV устройство, за да могат да останат заедно. Ако имате SQL Server VM, които трябва да бъдат на всеки сайт с конкретен DC, можете да зададете правило за афинитет със същия домейн на грешка между всеки SQL и съответния им DC. Тъй като вече е клъстерен обект, ако се опитате да преместите SQL VM от един сайт на друг, той проверява всички клъстерни обекти, свързани с него. Вижда, че има сдвояване с DC в същия сайт. След това вижда, че DC има правило и го проверява. Той вижда, че DC не може да бъде в същия домейн на грешка като другия DC, така че преместването е забранено.

Има вградени замени, така че можете да принудите движение, когато е необходимо. Можете също така лесно да деактивирате/активирате правила, ако желаете, в сравнение с AntiAffinityClassNames с ClusterEnforcedAffinity, където трябваше да премахнете свойството, за да го накарате да се премести и да се появи. Също така сме добавили функционалност в Drain, където ако трябва да се премести в друг домейн и има правило AntiAffinity, което го предотвратява, ние ще заобиколим правилото. Всички нарушения на правилата се излагат както в Cluster Admin, така и в Центъра за администриране на Windows за вашия преглед.

Гъвкава защита на BitLocker за отказоустойчиви клъстери

BitLocker е наличен за отказоустойчив клъстер от доста време. Изискването беше, че всички възли на клъстера трябва да са в същия домейн, тъй като ключът BitLocker е свързан с обекта с име на клъстер (CNO). Въпреки това, за тези клъстери на ръба, клъстери на работни групи и клъстери с множество домейни, Active Directory може да не присъства. Без Active Directory няма CNO. Тези клъстерни сценарии нямаха сигурност на данните в покой. Започвайки с този Windows Server Insiders, ние въведохме нашия собствен ключ BitLocker, съхраняван локално (криптиран) за използване на клъстер. Този допълнителен ключ ще бъде създаден само когато клъстерираните устройства са защитени с BitLocker след създаването на клъстер.

Нови мрежови тестове за валидиране на клъстер

Мрежовите конфигурации продължават да стават все по-сложни. Добавен е нов набор от тестове за валидиране на клъстери, които помагат да се провери дали конфигурациите са зададени правилно. Тези тестове включват:

• Списък на реда на мрежовите метрики (версия на драйвери)
• Потвърдете конфигурацията на клъстерната мрежа (конфигурация на виртуален превключвател)
• Предупреждение за проверка на IP конфигурацията
• Успех в мрежовата комуникация
• Превключете вградени конфигурации за групиране (симетрия, vNIC, pNIC)
• Проверете успешното конфигуриране на защитната стена на Windows
• QOS (PFC и ETS) са конфигурирани

(Забележка относно настройките за QOS по-горе: Това не означава, че тези настройки са валидни, просто настройките са внедрени. Тези настройки трябва да съответстват на вашата физическа мрежова конфигурация и като такива не можем да потвърдим, че са зададени на подходящите стойности)

Изображенията на Server Core Container са с 20 процента по-малки

В това, което би трябвало да бъде значителна печалба за всеки работен процес, който изтегля изображения на контейнери на Windows, размерът на изтегляне на вътрешното изображение на контейнера на Windows Server Core е намален с 20%. Това е постигнато чрез оптимизиране на набора от .NET предварително компилирани естествени изображения, включени в изображението на контейнера на сървърното ядро. Ако използвате .NET Framework с Windows контейнери, включително Windows PowerShell, използвайте a Изображение на .NET Framework, който ще включва допълнителни .NET предварително компилирани естествени изображения, за да поддържа производителността за тези сценарии, като същевременно ще се възползва от намаления размер.

Какво е новото с протокола SMB

Вдигайки още повече лентата за сигурност, SMB вече поддържа AES-256 криптиране. Има също така повишена производителност при използване на SMB криптиране или подписване с SMB Direct с RDMA активирани мрежови карти. SMB вече има и възможността да прави компресия, за да подобри производителността на мрежата.

Преглед на поверителността