Configurazione di una rete dedicata per la comunicazione del gruppo di disponibilità

I gruppi di disponibilità AlwaysOn di SQL Server 2012 richiedono un endpoint di mirroring del database per ogni istanza di SQL Server che ospiterà una replica del gruppo di disponibilità e/o una sessione di mirroring del database. Questo endpoint dell'istanza di SQL Server viene quindi condiviso da una o più repliche del gruppo di disponibilità e/o sessioni di mirroring del database ed è il meccanismo per la comunicazione tra la replica primaria e le repliche secondarie associate.

A seconda dei carichi di lavoro di modifica dei dati sulla replica primaria, i requisiti di velocità effettiva di messaggistica del gruppo di disponibilità possono non essere banali. Questa attività è anche sensibile al traffico proveniente da attività simultanee di gruppi di non disponibilità. Se la velocità effettiva è ridotta a causa della riduzione della larghezza di banda e del traffico simultaneo, puoi considerare di isolare il traffico del gruppo di disponibilità nella propria scheda di rete dedicata per ogni istanza di SQL Server che ospita una replica di disponibilità. Questo post descriverà questo processo e descriverà anche brevemente ciò che potresti aspettarti di vedere in uno scenario di velocità effettiva ridotta.

Per questo articolo, sto usando un cluster di failover di Windows Server (WSFC) guest virtuale a cinque nodi. Ogni nodo in WSFC dispone di una propria istanza di SQL Server autonoma che utilizza l'archiviazione locale non condivisa. Ogni nodo ha anche una scheda di rete virtuale separata per la comunicazione pubblica, una scheda di rete virtuale per la comunicazione WSFC e una scheda di rete virtuale che dedicheremo alla comunicazione del gruppo di disponibilità. Ai fini di questo post, ci concentreremo sulle informazioni necessarie per gli adattatori di rete dedicati al gruppo di disponibilità su ciascun nodo:

La configurazione di un gruppo di disponibilità utilizzando una NIC dedicata è quasi identica a un processo NIC condiviso, solo per "associare" il gruppo di disponibilità a una NIC specifica, devo prima designare il LISTENER_IP argomento nel CREATE ENDPOINT comando, utilizzando gli indirizzi IP di cui sopra per le mie schede di rete dedicate. Di seguito viene mostrata la creazione di ciascun endpoint nei cinque nodi WSFC:

: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...

Dopo aver creato questi endpoint associati alla NIC dedicata, il resto dei miei passaggi per configurare la topologia del gruppo di disponibilità non è diverso da uno scenario NIC condiviso.

Dopo aver creato il mio gruppo di disponibilità, se inizio a guidare il carico di modifica dei dati rispetto ai database di disponibilità della replica primaria, posso vedere rapidamente che il traffico di comunicazione del gruppo di disponibilità scorre sulla scheda di rete dedicata utilizzando Task Manager nella scheda di rete (la prima sezione è la velocità effettiva per il gruppo di disponibilità dedicato NIC):

E posso anche tenere traccia delle statistiche usando vari contatori di prestazioni. Nell'immagine seguente, Inetl[R] PRO_1000 MT Network Connection _2 è il mio gruppo di disponibilità NIC dedicato e ha la maggior parte del traffico NIC rispetto alle altre due NIC:

Ora avere una NIC dedicata per il traffico del gruppo di disponibilità può essere un modo per isolare l'attività e migliorare teoricamente le prestazioni, ma se la tua NIC dedicata ha una larghezza di banda insufficiente, poiché potresti aspettarti che le prestazioni ne risentiranno e l'integrità della topologia del gruppo di disponibilità peggiorerà.

Ad esempio, ho modificato la scheda di rete del gruppo di disponibilità dedicata sulla replica primaria con una larghezza di banda di trasferimento in uscita di 28,8 Kbps per vedere cosa sarebbe successo. Inutile dire che non era buono. Il throughput della scheda di rete del gruppo di disponibilità è diminuito in modo significativo:

Nel giro di pochi secondi, lo stato di salute delle varie repliche è peggiorato, con un paio di repliche che sono passate a uno stato di "non sincronizzazione":

Ho aumentato la NIC dedicata sulla replica primaria a 64 Kbps e dopo alcuni secondi si è verificato anche un picco di recupero iniziale:

Mentre le cose sono migliorate, ho assistito a disconnessioni periodiche e avvisi di integrità con questa impostazione di velocità effettiva della scheda di rete inferiore:

Che dire delle statistiche di attesa associate sulla replica primaria?

Quando c'era molta larghezza di banda sulla scheda di rete dedicata e tutte le repliche di disponibilità erano in uno stato integro, ho visto la seguente distribuzione durante i miei caricamenti di dati in un periodo di 2 minuti:

HADR_WORK_QUEUE rappresenta un thread di lavoro in background previsto in attesa di nuovo lavoro. HADR_LOGCAPTURE_WAIT rappresenta un'altra attesa prevista per la disponibilità di nuovi record di registro e, in base alla documentazione in linea, è prevista se la scansione del registro viene recuperata o viene eseguita la lettura dal disco.

Quando ho ridotto il throughput della scheda di rete a sufficienza per portare il gruppo di disponibilità a uno stato non integro, la distribuzione del tipo di attesa era la seguente:

Ora vediamo un nuovo tipo di attesa principale, HADR_NOTIFICATION_DEQUEUE . Questo è uno di quei tipi di attesa "solo per uso interno" definiti dalla documentazione in linea, che rappresentano un'attività in background che elabora le notifiche WSFC. La cosa interessante è che questo tipo di attesa non punta direttamente a un problema, eppure i test mostrano che questo tipo di attesa sale al vertice in associazione con una velocità effettiva di messaggistica del gruppo di disponibilità ridotta.

Quindi, la linea di fondo è isolare l'attività del tuo gruppo di disponibilità su una scheda di rete dedicata può essere utile se stai fornendo un throughput di rete con larghezza di banda sufficiente. Tuttavia, se non puoi garantire una buona larghezza di banda anche utilizzando una rete dedicata, l'integrità della topologia del tuo gruppo di disponibilità ne risentirà.