Windows Server Insider Preview build 20206 vine cu aceste modificări

CoreNet: Calea datelor și transporturi

• MsQuic – o implementare open source a protocolului de transport IETF QUIC alimentează atât procesarea web HTTP/3, cât și transferurile de fișiere SMB.

• Îmbunătățiri ale performanței UDP — UDP devine un protocol foarte popular care transportă tot mai mult trafic de rețea. Cu protocolul QUIC construit pe baza UDP și popularitatea tot mai mare a protocoalelor de streaming și joc personalizate (UDP) și RTP, este timpul să aducem performanța UDP la un nivel egal cu TCP. În Server vNext includem schimbarea jocului Descărcarea segmentării UDP (USO). USO mută cea mai mare parte a muncii necesare pentru a trimite pachete UDP de la CPU la hardware-ul specializat al NIC. Pentru a completa USO în Server vNext, includem UDP Receive Side Coalescing (UDP RSC) care unește pachetele și reduce utilizarea procesorului pentru procesarea UDP. Pentru a merge împreună cu aceste două noi îmbunătățiri, am adus sute de îmbunătățiri ale căii de date UDP atât de transmisie, cât și de recepție.

• Îmbunătățiri de performanță TCP - Server vNext utilizări TCP HyStart++ pentru a reduce pierderea de pachete în timpul pornirii conexiunii (în special în rețelele de mare viteză) și SendTracker + RACK pentru a reduce Retransmit Timeouts (RTO). Aceste caracteristici sunt activate în stiva de transport în mod implicit și oferă un flux de date de rețea mai fluid, cu performanțe mai bune la viteze mari.
• PktMon suport în TCPIP — Instrumentul de diagnosticare a rețelei între componente pentru Windows are acum suport TCPIP, oferind vizibilitate în stiva de rețea. PktMon poate fi folosit pentru capturarea pachetelor, detectarea căderii pachetelor, filtrarea pachetelor și numărarea pentru scenarii de virtualizare, cum ar fi rețeaua de containere și SDN.

(Îmbunătățit) RSC în vSwitch

RSC în vSwitch a fost îmbunătățit pentru o performanță mai bună. Lansat pentru prima dată în Windows Server 2019, Receive Segment Coalescing (RSC) în vSwitch permite ca pachetele să fie reunite și procesate ca un segment mai mare la intrarea în comutatorul virtual. Acest lucru reduce foarte mult ciclurile CPU consumate procesând fiecare octet (Ciccuri/octet).

Cu toate acestea, în forma sa inițială, odată ce traficul ieșea din comutatorul virtual, acesta va fi re-segmentat pentru călătoria prin VMBus. În Windows Server vNext, segmentele vor rămâne unite pe întreaga cale de date până când sunt procesate de aplicația dorită. Acest lucru îmbunătățește două scenarii:

– Trafic de la o gazdă externă, primit de o NIC virtuală

– Trafic de la o NIC virtuală la o altă NIC virtuală pe aceeași gazdă

Aceste îmbunătățiri ale RSC în vSwitch vor fi activate implicit; nu este necesară nicio acțiune din partea dvs.

Suport pentru echilibrarea încărcăturii Direct Server Return (DSR) pentru Containers și Kubernetes

DSR este o implementare a distribuției asimetrice a sarcinii de rețea în sistemele echilibrate, ceea ce înseamnă că traficul de cerere și răspuns utilizează o cale de rețea diferită. Utilizarea diferitelor căi de rețea ajută la evitarea hopurilor suplimentare și reduce latența cu care nu numai viteze crește timpul de răspuns dintre client și serviciu, dar elimină și o încărcare suplimentară din încărcare echilibrist.

Utilizarea DSR este o modalitate transparentă de a obține o performanță crescută a rețelei pentru aplicațiile dvs., cu puține modificări ale infrastructurii. Mai multe informatii

Prezentarea regulilor de afinitate/antiaffinitate pentru mașină virtuală (rol) cu clustering de failover

În trecut, ne-am bazat pe proprietatea grupului AntiAffinityClassNames pentru a menține rolurile separate, dar nu a existat o conștientizare specifică site-ului. Dacă a existat un DC care trebuia să fie pe un site și un DC care trebuie să fie pe alt site, nu era garantat. De asemenea, a fost important să ne amintim să introduceți șirul corect AntiAffinityClassNames pentru fiecare rol.

Există aceste cmdleturi PowerShell:

• New-ClusterAffinityRule = Aceasta vă permite să creați o nouă regulă de afinitate sau AntiAffinity. Există patru tipuri de reguli diferite (-RuleType)

• DifferentFaultDomain = păstrați grupurile pe diferite domenii de eroare
• DifferentNode = păstrați grupurile pe noduri diferite (nota ar putea fi pe un domeniu diferit sau pe același domeniu de eroare)
• SameFaultDomain = păstrați grupurile pe același domeniu de eroare
• SameNode = păstrați grupurile pe același nod

• Set-ClusterAffinityRule = Aceasta vă permite să activați (implicit) sau să dezactivați o regulă

• Add-ClusterGroupToAffinityRule = Adăugați un grup la o regulă existentă

• Get-ClusterAffinityRule = Afișează toate regulile sau anumite reguli

• Add-ClusterSharedVolumeToAffinityRule = Acesta este pentru stocare Affinity/AntiAffinity unde volumele partajate ale clusterului pot fi adăugate la regulile curente

• Remove-ClusterAffinityRule = Elimină o anumită regulă

• Remove-ClusterGroupFromAffinityRule = Elimină un grup dintr-o anumită regulă

• Remove-ClusterSharedVolumeFromAffinityRule = Elimină un anumit volum partajat de cluster dintr-o anumită regulă

• Move-ClusterGroup -IgnoreAffinityRule = Acesta nu este un cmdlet nou, dar vă permite să mutați forțat un grup într-un nod sau un domeniu de eroare care altfel ar fi împiedicat. În PowerShell, Cluster Manager și Windows Admin Center, ar arăta că grupul încalcă drept memento.

Acum puteți păstra lucrurile împreună sau separate. Când mutați un rol, obiectul de afinitate se asigură că acesta poate fi mutat. Obiectul caută și alte obiecte și le verifică și pe acestea, inclusiv discuri, astfel încât să le puteți avea afinitate de stocare cu mașinile virtuale (sau roluri) și volumele partajate de cluster (afinitate de stocare) dacă dorit. Puteți adăuga roluri la mai multe, cum ar fi controlere de domeniu, de exemplu. Puteți seta o regulă AntiAffinity, astfel încât DC-urile să rămână într-un alt domeniu de eroare. Apoi, puteți seta o regulă de afinitate pentru fiecare dintre DC-urile pe unitatea lor CSV specifică, astfel încât să poată rămâne împreună. Dacă aveți mașini virtuale SQL Server care trebuie să fie pe fiecare site cu un anumit DC, puteți seta o regulă de afinitate pentru același domeniu de eroare între fiecare SQL și DC respectiv. Deoarece acum este un obiect cluster, dacă ar fi să încercați să mutați un VM SQL de la un site la altul, acesta verifică toate obiectele cluster asociate cu acesta. Vede că există o asociere cu DC pe același site. Apoi vede că DC are o regulă și o verifică. Vede că DC nu poate fi în același domeniu de eroare ca și celălalt DC, așa că mutarea este interzisă.

Există modificări încorporate, astfel încât să puteți forța o mișcare atunci când este necesar. Puteți, de asemenea, să dezactivați/activați cu ușurință regulile, dacă doriți, în comparație cu AntiAffinityClassNames cu ClusterEnforcedAffinity, unde a trebuit să eliminați proprietatea pentru ca aceasta să se mute și să apară. Avem și funcționalitate adăugată în Drain, unde dacă trebuie să se mute într-un alt domeniu și există o regulă AntiAffinity care îl împiedică, vom ocoli regula. Orice încălcare a regulilor este expusă atât în ​​Cluster Admin, cât și în Windows Admin Center, pentru examinare.

Protector BitLocker flexibil pentru clustere de failover

BitLocker este disponibil pentru failover Clustering de ceva timp. Cerința era că nodurile clusterului trebuie să fie toate în același domeniu în care cheia BitLocker este legată de obiectul numelui clusterului (CNO). Cu toate acestea, pentru acele clustere de la margine, clustere de grup de lucru și clustere multidomeniu, Active Directory poate să nu fie prezent. Fără Active Directory, nu există CNO. Aceste scenarii de cluster nu aveau securitatea datelor în repaus. Începând cu acest Windows Server Insiders, am introdus propria noastră cheie BitLocker stocată local (criptată) pentru utilizare în cluster. Această cheie suplimentară va fi creată numai atunci când unitățile în cluster sunt protejate BitLocker după crearea clusterului.

Noi teste de rețea de validare a clusterelor

Configurațiile de rețea continuă să devină din ce în ce mai complexe. Un nou set de teste de validare a clusterelor a fost adăugat pentru a ajuta la validarea setării corecte a configurațiilor. Aceste teste includ:

• Listă ordinea valorii rețelei (versiune driver)
• Validați configurația rețelei cluster (configurarea comutatorului virtual)
• Avertismentul de validare a configurației IP
• Succesul în comunicare în rețea
• Comutare configurații de echipă încorporate (simetrie, vNIC, pNIC)
• Validați succesul configurării paravanului de protecție Windows
• QOS (PFC și ETS) au fost configurate

(Notă cu privire la setările QOS de mai sus: aceasta nu înseamnă că aceste setări sunt valide, ci doar că setările sunt implementate. Aceste setări trebuie să se potrivească cu configurația fizică a rețelei și, ca atare, nu putem valida dacă acestea sunt setate la valorile corespunzătoare)

Imaginile Server Core Container sunt cu 20 la sută mai mici

În ceea ce ar trebui să fie un câștig semnificativ pentru orice flux de lucru care extrage imagini containere Windows, dimensiunea de descărcare a imaginii Insider container Windows Server Core a fost redusă cu 20%. Acest lucru a fost realizat prin optimizarea setului de imagini native .NET pre-compilate incluse în imaginea containerului Server Core. Dacă utilizați .NET Framework cu containere Windows, inclusiv Windows PowerShell, utilizați a Imagine .NET Framework, care va include imagini native .NET pre-compilate pentru a menține performanța pentru acele scenarii, beneficiind în același timp de o dimensiune redusă.

Ce este nou cu protocolul SMB

Ridicând și mai mult bara de securitate, SMB acceptă acum criptarea AES-256. Există, de asemenea, performanță crescută atunci când utilizați criptarea SMB sau semnarea cu SMB Direct cu plăci de rețea compatibile RDMA. SMB are acum și capacitatea de a face compresie pentru a îmbunătăți performanța rețelei.

Privire de ansamblu asupra confidențialității