Konfiguration af et dedikeret netværk til tilgængelighedsgruppekommunikation

SQL Server 2012 AlwaysOn-tilgængelighedsgrupper kræver et databasespejlingsendepunkt for hver SQL Server-instans, der skal være vært for en tilgængelighedsgruppereplika og/eller databasespejlingssession. Dette SQL Server-instansslutpunkt deles derefter af en eller flere tilgængelighedsgruppereplikaer og/eller databasespejlingssessioner og er mekanismen til kommunikation mellem den primære replika og de tilknyttede sekundære replikaer.

Afhængigt af dataændrings-arbejdsbelastningerne på den primære replika kan kravene til tilgængelighedsgruppemeddelelsesgennemstrømning være ikke-trivielle. Denne aktivitet er også følsom over for trafik fra samtidig ikke-tilgængelig gruppeaktivitet. Hvis gennemstrømningen lider på grund af forringet båndbredde og samtidig trafik, kan du overveje at isolere tilgængelighedsgruppetrafikken til sin egen dedikerede netværksadapter for hver SQL Server-instans, der hoster en tilgængelighedsreplika. Dette indlæg vil beskrive denne proces og også kort beskrive, hvad du kan forvente at se i et scenarie med forringet gennemstrømning.

Til denne artikel bruger jeg en fem node virtuel gæst Windows Server Failover Cluster (WSFC). Hver node i WSFC har sin egen selvstændige SQL Server-instans, der bruger ikke-delt lokal lagring. Hver node har også en separat virtuel netværksadapter til offentlig kommunikation, en virtuel netværksadapter til WSFC-kommunikation og en virtuel netværksadapter, som vi vil dedikere til tilgængelighedsgruppekommunikation. I forbindelse med dette indlæg vil vi fokusere på de nødvendige oplysninger til tilgængelighedsgruppens dedikerede netværksadaptere på hver node:

Opsætning af en tilgængelighedsgruppe ved hjælp af et dedikeret NIC er næsten identisk med en delt NIC-proces, kun for at "binde" tilgængelighedsgruppen til et specifikt NIC, skal jeg først udpege LISTENER_IP argument i CREATE ENDPOINT kommando ved at bruge de førnævnte IP-adresser til mine dedikerede NIC'er. Nedenfor viser oprettelsen af ​​hvert endepunkt på tværs af de fem WSFC-noder:

:CONNECT SQL2K12-SVR1
 
USE [master];
GO
 
CREATE ENDPOINT [Hadr_endpoint] 
    AS TCP (LISTENER_PORT = 5022, LISTENER_IP = (192.168.20.31))
    FOR DATA_MIRRORING (ROLE = ALL, ENCRYPTION = REQUIRED ALGORITHM AES);
GO
 
IF (SELECT state FROM sys.endpoints WHERE name = N'Hadr_endpoint') <> 0
BEGIN
    ALTER ENDPOINT [Hadr_endpoint] STATE = STARTED;
END
GO
 
USE [master];
GO
 
GRANT CONNECT ON ENDPOINT::[Hadr_endpoint] TO [SQLSKILLSDEMOS\SQLServiceAcct];
GO
 
:CONNECT SQL2K12-SVR2
 
-- ...repeat for other 4 nodes...

Efter at have oprettet disse endepunkter forbundet med det dedikerede NIC, er resten af ​​mine trin i opsætning af tilgængelighedsgruppetopologien ikke anderledes end i et delt NIC-scenarie.

Efter oprettelse af min tilgængelighedsgruppe, hvis jeg begynder at køre datamodifikationsbelastning mod de primære replika-tilgængelighedsdatabaser, kan jeg hurtigt se, at tilgængelighedsgruppens kommunikationstrafik flyder på det dedikerede NIC ved hjælp af Task Manager på netværksfanen (det første afsnit er gennemstrømningen for den dedikerede tilgængelighedsgruppe NIC):

Og jeg kan også spore statistikken ved hjælp af forskellige præstationstællere. På billedet nedenfor er Inetl[R] PRO_1000 MT Network Connection _2 min dedikerede tilgængelighedsgruppe NIC og har størstedelen af ​​NIC-trafik sammenlignet med de to andre NIC'er:

At have et dedikeret NIC til tilgængelighedsgruppetrafik kan nu være en måde at isolere aktivitet og teoretisk forbedre ydeevnen på, men hvis dit dedikerede NIC ikke har tilstrækkelig båndbredde, vil ydeevnen lide, som du måske forventer, og tilgængelighedsgruppens topologi forringes.

For eksempel ændrede jeg den dedikerede tilgængelighedsgruppe NIC på den primære replika til en 28,8 Kbps udgående overførselsbåndbredde for at se, hvad der ville ske. Det er overflødigt at sige, at det ikke var godt. Tilgængelighedsgruppens NIC-gennemstrømning faldt betydeligt:

Inden for få sekunder forværredes de forskellige replikas helbred, og et par af replikaerne flyttede til en tilstand "ikke synkroniserer":

Jeg øgede den dedikerede NIC på den primære replika til 64 Kbps, og efter et par sekunder var der også en indledende indhentningsspids:

Mens tingene blev bedre, så jeg periodiske afbrydelser og sundhedsadvarsler ved denne lavere NIC-gennemstrømningsindstilling:

Hvad med de tilhørende ventestatistikker på den primære replika?

Da der var masser af båndbredde på det dedikerede NIC, og alle tilgængelighedsreplikaer var i en sund tilstand, så jeg følgende fordeling under mine dataindlæsninger over en periode på 2 minutter:

HADR_WORK_QUEUE repræsenterer en forventet baggrundsarbejdertråd, der venter på nyt arbejde. HADR_LOGCAPTURE_WAIT repræsenterer endnu en forventet ventetid på, at nye logposter bliver tilgængelige og forventes ifølge Books Online, hvis logscanningen fanges eller læser fra disken.

Da jeg reducerede gennemstrømningen af ​​NIC nok til at få tilgængelighedsgruppen til en usund tilstand, var ventetypefordelingen som følger:

Vi ser nu en ny top ventetype, HADR_NOTIFICATION_DEQUEUE . Dette er en af ​​de "kun til intern brug" ventetyper som defineret af Books Online, der repræsenterer en baggrundsopgave, der behandler WSFC-meddelelser. Det interessante er, at denne ventetype ikke peger direkte på et problem, og alligevel viser testene, at denne ventetype stiger til tops i forbindelse med forringet tilgængelighed af gruppemeddelelser.

Så bundlinjen er at isolere din tilgængelighedsgruppeaktivitet til et dedikeret NIC, hvilket kan være fordelagtigt, hvis du leverer et netværksgennemløb med tilstrækkelig båndbredde. Men hvis du ikke kan garantere god båndbredde, selv ved at bruge et dedikeret netværk, vil din tilgængelighedsgruppetopologi lide det.