Windows Server Insider Preview build 20206 kommer med disse endringene

CoreNet: Databane og transporter

• MsQuic – en åpen kildekodeimplementering av IETF QUIC-transportprotokollen driver både HTTP/3-nettbehandling og SMB-filoverføringer.

• UDP ytelsesforbedringer — UDP er i ferd med å bli en veldig populær protokoll som bærer mer og mer nettverkstrafikk. Med QUIC-protokollen bygget på toppen av UDP og den økende populariteten til RTP og tilpassede (UDP) streaming- og spillprotokoller, er det på tide å bringe ytelsen til UDP til et nivå på nivå med TCP. I Server vNext inkluderer vi spillets endring UDP Segmentation Offload (USO). USO flytter mesteparten av arbeidet som kreves for å sende UDP-pakker fra CPU til NICs spesialiserte maskinvare. Som kompliment for USO i Server vNext inkluderer vi UDP Receive Side Coalescing (UDP RSC) som samler pakker og reduserer CPU-bruk for UDP-behandling. For å gå sammen med disse to nye forbedringene, har vi gjort hundrevis av forbedringer av UDP-databanen både for sending og mottak.

• TCP ytelsesforbedringer — Server vNext bruker TCP HyStart++ for å redusere pakketap under oppstart av tilkobling (spesielt i høyhastighetsnettverk) og SendTracker + RACK for å redusere retransmit timeouts (RTO). Disse funksjonene er aktivert i transportstabelen som standard og gir en jevnere nettverksdataflyt med bedre ytelse ved høye hastigheter.
• PktMon støtte i TCPIP — Tverrkomponent nettverksdiagnoseverktøyet for Windows har nå TCPIP-støtte som gir synlighet i nettverksstakken. PktMon kan brukes til pakkefangst, pakkedråpedeteksjon, pakkefiltrering og telling for virtualiseringsscenarier, som containernettverk og SDN.

(Forbedret) RSC i vSwitch

RSC i vSwitch har blitt forbedret for bedre ytelse. Først utgitt i Windows Server 2019, Receive Segment Coalescing (RSC) i vSwitch gjør det mulig for pakker å bli koalesert og behandlet som ett større segment ved oppføring i den virtuelle svitsjen. Dette reduserer i stor grad CPU-syklusene som forbrukes ved å behandle hver byte (sykluser/byte).

I sin opprinnelige form, når trafikken forlot den virtuelle svitsjen, ville den imidlertid bli re-segmentert for reise på tvers av VMBus. I Windows Server vNext vil segmenter forbli sammenslått over hele databanen til de behandles av den tiltenkte applikasjonen. Dette forbedrer to scenarier:

– Trafikk fra en ekstern vert, mottatt av et virtuelt nettverkskort

– Trafikk fra et virtuelt nettverkskort til et annet virtuelt nettverkskort på samme vert

Disse forbedringene til RSC i vSwitch vil være aktivert som standard; det kreves ingen handling fra din side.

Lastbalanseringsstøtte for Direct Server Return (DSR) for containere og Kubernetes

DSR er en implementering av asymmetrisk nettverksbelastningsfordeling i lastbalanserte systemer, noe som betyr at forespørselen og responstrafikken bruker en annen nettverksbane. Bruken av forskjellige nettverksbaner bidrar til å unngå ekstra hopp og reduserer ventetiden som ikke bare hastigheter opp responstiden mellom klienten og tjenesten, men fjerner også noe ekstra belastning fra belastningen balanserer.

Å bruke DSR er en transparent måte å oppnå økt nettverksytelse for applikasjonene dine med små eller ingen endringer i infrastrukturen. Mer informasjon

Vi introduserer Virtual Machine (Role) Affinity/AntiAffinity-regler med Failover Clustering

Tidligere har vi stolt på gruppeegenskapen AntiAffinityClassNames for å holde roller fra hverandre, men det var ingen stedsspesifikk bevissthet. Hvis det var en DC som måtte være på ett sted og en DC som måtte være på en annen side, var det ikke garantert. Det var også viktig å huske å skrive inn riktig AntiAffinityClassNames-streng for hver rolle.

Det er disse PowerShell-cmdletene:

• New-ClusterAffinityRule = Dette lar deg lage en ny affinitets- eller antiaffinitetsregel. Det er fire forskjellige regeltyper (-RuleType)

• DifferentFaultDomain = hold gruppene på forskjellige feildomener
• DifferentNode = hold gruppene på forskjellige noder (merk kan være på forskjellige eller samme feildomene)
• SameFaultDomain = hold gruppene på samme feildomene
• SameNode = hold gruppene på samme node

• Set-ClusterAffinityRule = Dette lar deg aktivere (standard) eller deaktivere en regel

• Add-ClusterGroupToAffinityRule = Legg til en gruppe til en eksisterende regel

• Get-ClusterAffinityRule = Vis alle eller spesifikke regler

• Add-ClusterSharedVolumeToAffinityRule = Dette er for lagring Affinity/AntiAffinity der Cluster Shared Volumes kan legges til gjeldende regler

• Remove-ClusterAffinityRule = Fjerner en spesifikk regel

• Remove-ClusterGroupFromAffinityRule = Fjerner en gruppe fra en bestemt regel

• Remove-ClusterSharedVolumeFromAffinityRule = Fjerner et spesifikt klyngedelt volum fra en bestemt regel

• Move-ClusterGroup -IgnoreAffinityRule = Dette er ikke en ny cmdlet, men lar deg tvangsflytte en gruppe til en node eller feildomene som ellers ville blitt forhindret. I PowerShell, Cluster Manager og Windows Admin Center vil det vise at gruppen er i brudd som påminnelse.

Nå kan du holde ting sammen eller fra hverandre. Når du flytter en rolle, sørger affinitetsobjektet for at det kan flyttes. Objektet ser også etter andre objekter og verifiserer disse også, inkludert disker, slik at du kan ha det lagringstilhørighet med virtuelle maskiner (eller roller) og klyngedelte volumer (lagringstilhørighet) hvis ønsket. Du kan legge til roller til multipler som for eksempel domenekontrollere. Du kan angi en AntiAffinity-regel slik at DC-ene forblir i et annet feildomene. Du kan deretter angi en affinitetsregel for hver av DC-ene til deres spesifikke CSV-stasjon, slik at de kan holde sammen. Hvis du har SQL Server VM-er som må være på hvert nettsted med en spesifikk DC, kan du angi en Affinitetsregel for samme feildomene mellom hver SQL og deres respektive DC. Fordi det nå er et klyngeobjekt, hvis du skulle prøve å flytte en SQL VM fra ett nettsted til et annet, sjekker det alle klyngeobjekter knyttet til det. Den ser at det er en sammenkobling med DC på samme sted. Den ser da at DC har en regel og verifiserer den. Den ser at DC-en ikke kan være i samme feildomene som den andre DC-en, så flyttingen er ikke tillatt.

Det er innebygde overstyringer slik at du kan tvinge et trekk når det er nødvendig. Du kan også enkelt deaktivere/aktivere regler om ønskelig, sammenlignet med AntiAffinityClassNames med ClusterEnforcedAffinity hvor du måtte fjerne egenskapen for å få den til å flytte og komme opp. Vi har også lagt til funksjonalitet i Drain, der hvis det må flyttes til et annet domene og det er en AntiAffinity-regel som forhindrer det, vil vi omgå regelen. Eventuelle regelbrudd avsløres i både Cluster Admin og Windows Admin Center for gjennomgang.

Fleksibel BitLocker-beskytter for failover-klynger

BitLocker har vært tilgjengelig for Failover Clustering ganske lenge. Kravet var at klyngenodene alle må være i samme domene ettersom BitLocker-nøkkelen er knyttet til klyngenavnobjektet (CNO). Men for disse klyngene ved kanten, arbeidsgruppeklynger og multidomeneklynger, kan det hende at Active Directory ikke finnes. Uten Active Directory er det ingen CNO. Disse klyngescenarioene hadde ingen data i hvilesikkerhet. Fra og med denne Windows Server Insiders introduserte vi vår egen BitLocker-nøkkel som er lagret lokalt (kryptert) for klyngebruk. Denne tilleggsnøkkelen vil bare bli opprettet når de klyngede stasjonene er BitLocker-beskyttet etter at klyngen er opprettet.

Nye nettverkstester for Cluster Validation

Nettverkskonfigurasjoner fortsetter å bli mer og mer komplekse. Et nytt sett med Cluster Validation-tester er lagt til for å validere at konfigurasjonene er riktig angitt. Disse testene inkluderer:

• Liste nettverksberegningsrekkefølge (driverversjon)
• Valider klyngenettverkskonfigurasjon (virtuell svitsjkonfigurasjon)
• Valider IP-konfigurasjonsadvarsel
• Nettverkskommunikasjonssuksess
• Switch Embedded Teaming-konfigurasjoner (symmetri, vNIC, pNIC)
• Validere konfigurasjonen av Windows-brannmuren
• QOS (PFC og ETS) er konfigurert

(Merk angående QOS-innstillinger ovenfor: Dette betyr ikke at disse innstillingene er gyldige, bare at innstillingene er implementert. Disse innstillingene må samsvare med din fysiske nettverkskonfigurasjon, og som sådan kan vi ikke validere at disse er satt til de riktige verdiene)

Server Core Container-bilder er 20 prosent mindre

I det som burde være en betydelig gevinst for enhver arbeidsflyt som trekker Windows-beholderbilder, er nedlastingsstørrelsen til Windows Server Core-beholderen Insider-bildet redusert med 20 %. Dette er oppnådd ved å optimalisere settet med .NET forhåndskompilerte native bilder som er inkludert i Server Core-beholderbildet. Hvis du bruker .NET Framework med Windows-beholdere, inkludert Windows PowerShell, bruk en .NET Framework-bilde, som vil inkludere ytterligere .NET forhåndskompilerte native bilder for å opprettholde ytelsen for disse scenariene, samtidig som de drar nytte av en redusert størrelse.

Hva er nytt med SMB-protokollen

SMB hever sikkerhetsgrensen ytterligere, og støtter nå AES-256-kryptering. Det er også økt ytelse ved bruk av SMB-kryptering eller signering med SMB Direct med RDMA-aktiverte nettverkskort. SMB har nå også muligheten til å gjøre komprimering for å forbedre nettverksytelsen.

Personvernoversikt