Ora che i gruppi di disponibilità stanno diventando sempre più diffusi, ho pensato di affrontare un argomento che potrebbe essere trascurato durante la pianificazione iniziale e l'installazione di SQL Server in questo tipo di ambiente. Per avere una configurazione veramente tollerante agli errori, è necessario pensare e pianificare l'impostazione della connettività del database.
Non entrerò nei dettagli della configurazione del tuo ambiente AlwaysOn in questo post, ma per ulteriore aiuto ti suggerisco di dare un'occhiata al post di Aaron Bertrand, "Risoluzione dei problemi di AlwaysOn - A volte ci vogliono molte serie di occhi". Dopo aver configurato l'ambiente, il passaggio successivo per fornire la connettività al database consiste nel creare un listener del gruppo di disponibilità utilizzando SQL Management Studio o T-SQL:
ALTER AVAILABILITY GROUP [GroupName] ADD LISTENER N'ListenerName' (WITH IP ((N'10.x.x.x', N'255.255.255.0')), PORT=1433);
Stringhe di connessione del listener AG
Il tuo nome di rete virtuale (VNN) è registrato in DNS ed è sempre di proprietà dell'istanza di SQL Server in cui risiede la replica primaria. Tutti gli indirizzi IP forniti durante la configurazione dell'AG Listener sono registrati in DNS con lo stesso nome di rete virtuale.
Dopo aver creato il tuo AG Listener, devi assicurarti che i tuoi clienti possano connettersi. La connessione dell'applicazione funziona nello stesso modo in cui ha sempre funzionato, tuttavia, invece di puntare verso un server specifico nella stringa di connessione, punta verso AG Listener.
I listener AG possono essere collegati solo tramite TCP e vengono risolti dal DNS locale nell'elenco di indirizzi IP e porte TCP mappati sulla VNN. Il tuo client tenterà di connettersi a ciascuno degli indirizzi IP a turno fino a quando non ottiene una connessione o fino a quando non raggiunge un timeout di connessione. Un importante parametro della stringa di connessione da considerare è MultiSubnetFailover. Se questo parametro è impostato su true, il client tenterà le connessioni in parallelo consentendo una connettività più rapida e, se necessario, failover client più rapidi:
Server=tcp:MyAgListener,1433;Database=Db1;IntegratedSecurity=SSPI; MultiSubnetFailover=True
Quando si verifica un failover, le connessioni client vengono reimpostate e la proprietà dell'AG Listener si sposta sull'istanza di SQL Server che assume il ruolo di replica primaria. L'endpoint VNN viene quindi associato ai nuovi indirizzi IP e alle porte TCP della nuova istanza di replica primaria. A seconda del client, si verificherà una riconnessione automatica all'AG oppure l'utente potrebbe dover riavviare manualmente l'applicazione o la connessione interessata.
Intento dell'applicazione
Uno dei motivi principali per implementare i gruppi di disponibilità è fornire la possibilità di sfruttare gli ambienti di backup o ripristino di emergenza per alleggerire il lavoro dall'ambiente di produzione. Questi server possono ora essere utilizzati per backup, analisi, query e report ad hoc o qualsiasi altra operazione in cui è sufficiente disporre di una copia di sola lettura del database.
Per fornire l'accesso in sola lettura alle repliche secondarie, viene utilizzato il parametro della stringa di connessione ApplicationIntent. È possibile configurare un elenco di routing di sola lettura facoltativo degli endpoint di SQL Server in ogni replica. Questo elenco viene utilizzato per reindirizzare le richieste di connessione client che utilizzano il parametro ApplicationIntent=ReadOnly alla prima replica secondaria disponibile che è stata configurata con un filtro dell'intento dell'applicazione appropriato.
Server=tcp:MyAgListener,1433;Database=Db1;IntegratedSecurity=SSPI; MultiSubnetFailover=True;ApplicationIntent=ReadOnly;
Filtro dell'intento dell'applicazione
Per facilitare l'intento dell'applicazione dai client che si connettono al gruppo di disponibilità, ogni istanza di SQL Server nel gruppo deve essere configurata con un filtro dell'intento dell'applicazione appropriato. Il filtro determina quali tipi di connessioni accetterà ciascuna replica.
Una replica primaria configurata per avere Connessioni nel ruolo principale di "Consenti tutte le connessioni" accetterà tutte le connessioni effettuate tramite AG Listener. Una replica primaria configurata come "Consenti connessioni in lettura/scrittura" rifiuterà qualsiasi connessione che specifichi "ApplicationIntent=ReadOnly".
Quando si configurano le repliche, è necessario definire anche se ciascuna sarà o meno una secondaria leggibile. Una replica configurata come "No" rifiuterà tutte le connessioni. Si presume che questa replica venga utilizzata solo per il failover in una situazione di ripristino di emergenza. Se la replica secondaria è configurata come "Sì", tutte le connessioni saranno consentite, ma solo per l'accesso in lettura, anche se "ApplicationIntent=ReadOnly" non è specificato. Infine, se il secondario è configurato come "Intento di sola lettura", solo i client che specificano "ApplicationIntent=ReadOnly" potranno connettersi.
Routing di sola lettura
Ora che sappiamo come configurare l'intento dell'applicazione sulle istanze del server e creare le stringhe di connessione necessarie, dobbiamo configurare il routing di sola lettura del gruppo di disponibilità. Quando ci si connette all'AG Listener utilizzando la stringa di connessione come definito sopra, il listener interroga l'istanza di replica primaria e determina se la connessione deve essere effettuata al primario (lettura/scrittura) oa un secondario di sola lettura. A tal fine, è necessario creare un elenco di instradamento per OGNI replica di disponibilità che viene utilizzata se e quando la replica assume il ruolo di primaria. In genere, la procedura consigliata consiste nell'includere ogni URL di routing di sola lettura per ogni replica secondaria di sola lettura con l'URL della replica locale alla fine dell'elenco. Le richieste di connessione con intento di lettura vengono instradate al primo secondario leggibile disponibile nell'elenco di routing, non c'è bilanciamento del carico tra i secondari.
Innanzitutto, modifica ogni replica per fornire l'URL di instradamento di sola lettura:
ALTER AVAILABILITY GROUP [Group1] MODIFY REPLICA ON N'COMPUTER01' WITH (SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY)); ALTER AVAILABILITY GROUP [Group1] MODIFY REPLICA ON N'COMPUTER01' WITH (SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://COMPUTER01.mydomain.com:1433')); ALTER AVAILABILITY GROUP [Group1] MODIFY REPLICA ON N'COMPUTER02' WITH (SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY)); ALTER AVAILABILITY GROUP [Group1] MODIFY REPLICA ON N'COMPUTER02' WITH (SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://COMPUTER02.mydomain.com:1433'));
In secondo luogo, modifica ogni replica per fornire l'elenco di routing di sola lettura da utilizzare quando la replica specificata è nel ruolo principale:
ALTER AVAILABILITY GROUP [Group1] MODIFY REPLICA ON N'COMPUTER01' WITH
(PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=('COMPUTER02','COMPUTER01')));
ALTER AVAILABILITY GROUP [Group1] MODIFY REPLICA ON N'COMPUTER02' WITH
(PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=('COMPUTER01','COMPUTER02'))); L'URL di instradamento deve essere sotto forma di "TCP://:". Per assistenza nella determinazione del tuo URL, consulta questo blog e lo script creato da Matt Neerincx.
Conclusione
Con il tuo routing di sola lettura configurato, AG Listener creato e le tue applicazioni client che utilizzano le stringhe di connessione corrette, dovresti disporre di una connessione completamente tollerante ai guasti per il tuo gruppo di disponibilità. Assicurati di dedicare un po' di tempo a testare la tua connettività e la capacità delle tue applicazioni di seguire i tuoi server in caso di failover.
