Listener del gruppo di disponibilità, connettività client e failover dell'applicazione (SQL Server)

  • Articolo

In questo argomento sono contenute informazioni sulla funzionalità di failover delle applicazioni e sulla connettività client di Gruppi di disponibilità AlwaysOn.

[!NOTA]

Per la maggior parte delle configurazioni comuni del listener, è possibile creare il listener del primo gruppo di disponibilità tramite cmdlet di PowerShell o istruzioni Transact-SQL. Per ulteriori informazioni, vedere Attività correlate più avanti in questo argomento.

Contenuto dell'argomento:

  • Listener del gruppo di disponibilità

  • Utilizzo di un listener per connettersi alla replica primaria

  • Utilizzo di un listener per connettersi a una replica secondaria di sola lettura (routing di sola lettura)

    • Per configurare repliche di disponibilità per il routing di sola lettura

    • Finalità dell'applicazione di sola lettura e routing di sola lettura

  • Ignorare i listener del gruppo di disponibilità

  • Comportamento delle connessioni client al failover

  • Supporto del failover su più subnet del gruppo di disponibilità

  • Listener del gruppo di disponibilità e certificati SSL

  • Listener del gruppo di disponibilità e nomi entità server (SPN)

  • Attività correlate

  • Contenuto correlato

Listener del gruppo di disponibilità

È possibile fornire la connettività client al database di un determinato gruppo di disponibilità creando un listener del gruppo di disponibilità. Un listener del gruppo di disponibilità è un nome di rete virtuale (VNN, Virtual Network Name) a cui i client possono connettersi per accedere a un database in una replica primaria o secondaria di un gruppo di disponibilità AlwaysOn. Un listener del gruppo di disponibilità consente a un client di connettersi a una replica di disponibilità senza conoscere il nome dell'istanza fisica di SQL Server a cui il client si deve connettere. Non è necessario modificare la stringa di connessione client per connettersi al percorso corrente della replica primaria corrente.

Un listener del gruppo di disponibilità è composto da un nome listener DNS, dal numero di porta e da uno o più indirizzi IP. Solo il protocollo TCP è supportato dal listener del gruppo di disponibilità. È inoltre necessario che il nome DNS del listener sia univoco nel dominio e in NetBIOS. Alla sua creazione, il listener del gruppo di disponibilità diventa una risorsa di un cluster con un nome di rete virtuale (VNN) e un indirizzo IP virtuale (VIP) associati, oltre alla dipendenza del gruppo di disponibilità. Un client utilizza il DNS per risolvere il VNN in più indirizzi IP e quindi tenta di connettersi a ogni indirizzo, fino a che una richiesta di connessione riesce o fino a che le richieste di connessione non scadranno.

Se il routing di sola lettura viene configurato per uno o più repliche secondarie leggibili, connessioni client con finalità di lettura alla replica primaria vengono reindirizzate a una replica secondaria leggibile. Inoltre, se la replica primaria viene portata offline su un'istanza di SQL Server e una nuova replica primaria viene portata online su un'altra, il listener del gruppo di disponibilità abilita i client a connettersi alla nuova replica primaria.

Per informazioni essenziali sui listener dei gruppi di disponibilità, vedere Creare o configurare un listener del gruppo di disponibilità (SQL Server).

Contenuto della sezione:

  • Configurazione del listener del gruppo di disponibilità

  • Selezione della porta per il listener del gruppo di disponibilità

Configurazione del listener del gruppo di disponibilità

Il listener del gruppo di disponibilità è definito dagli elementi seguenti:

  • Nome DNS univoco
    È noto anche come nome di rete virtuale (VNN). Si applicano le regole di denominazione di Active Directory per i nomi host DNS. Per ulteriori informazioni, vedere l'articolo della Knowledge Base Convenzioni di denominazione di Active Directory per computer, domini, siti e unità organizzative.

  • Uno o più indirizzi IP virtuali (VIP)
    Indirizzi IP virtuali configurati per una o più subnet su cui è possibile eseguire il failover del gruppo di disponibilità.

  • Configurazione dell'indirizzo IP
    Per un listener del gruppo di disponibilità specifico, nell'indirizzo IP vengono utilizzati il protocollo DHCP (Dynamic Host Configuration Protocol) o uno o più indirizzi IP statici.

    • DHCP (Dynamic Host Configuration Protocol)

      Se un gruppo di disponibilità risiede in una sola subnet, è possibile configurare tutti gli indirizzi IP del listener del gruppo di disponibilità per l'utilizzo di DHCP. Per gli ambienti di pre-produzione, tramite DHCP viene offerta una semplice installazione per un gruppo di disponibilità per cui non è richiesto il ripristino di emergenza su un sito remoto in una subnet separata. Tuttavia, non è consigliabile utilizzare DHCP insieme a un listener del gruppo di disponibilità in un ambiente di produzione, poiché in caso di inattività, se il lease IP DHCP scade, per la registrazione del nuovo indirizzo IP DHCP associato al nome DNS del listener viene richiesto tempo aggiuntivo. Il tempo aggiuntivo causerà un errore di connessione del client.

    • Indirizzi IP statici

      Negli ambienti di produzione è consigliabile che nei listener del gruppo di disponibilità vengano utilizzati indirizzi IP statici. Inoltre, nel caso in cui i gruppi di disponibilità si estendano su più subnet di un dominio, nel listener di un gruppo di disponibilità devono essere utilizzati indirizzi IP statici.

    Le configurazioni di rete ibride e DHCP su più subnet non sono supportate per i listener del gruppo di disponibilità. Quando si verifica un failover è di fatto possibile che un indirizzo IP dinamico scada o venga rilasciato, compromettendo la disponibilità elevata complessiva.

Selezione della porta per il listener del gruppo di disponibilità

Quando si configura un listener del gruppo di disponibilità, è necessario specificare una porta. È possibile configurare la porta predefinita su 1433 per non rendere troppo complesse le stringhe di connessione client. Se si intende utilizzare la porta 1433, non è necessario specificare un numero di porta in una stringa di connessione. Inoltre, poiché ogni listener del gruppo di disponibilità dispone di un nome di rete virtuale separato, ogni listener del gruppo di disponibilità configurato su un solo cluster WSFC può essere configurato per fare riferimento alla stessa porta predefinita 1433.

È inoltre possibile specificare una porta del listener non standard. Ciò significa, tuttavia, che è necessario specificare in modo esplicito una porta di destinazione nella stringa di connessione ogni volta che ci si connette al listener del gruppo di disponibilità. Sarà inoltre necessario aprire un'autorizzazione sul firewall per la porta non standard.

Se si utilizza la porta predefinita 1433 per il nome di rete virtuale del listener del gruppo di disponibilità, è necessario assicurarsi che nessuno altro servizio sul nodo cluster utilizzi questa porta, cosa che provocherebbe un conflitto tra porte.

Se una delle istanze di SQL Server è già in attesa sulla porta TCP 1433 attraverso il listener dell'istanza e nessun altro servizio, incluse istanze aggiuntive di SQL Server, nel computer è in attesa sulla porta 1433, non si verificherà alcun conflitto tra porte con il listener del gruppo di disponibilità. Il motivo è dato dal fatto che il listener del gruppo di disponibilità può condividere la stessa porta TCP nello stesso processo del servizio. È tuttavia opportuno non configurare più istanze di SQL Server (side-by-side) per l'attesa sulla stessa porta.

Icona freccia utilizzata con il collegamento Torna all'inizio[Inizio pagina]

Utilizzo di un listener per connettersi alla replica primaria

Per utilizzare un listener del gruppo di disponibilità per connettersi alla replica primaria per l'accesso in lettura e scrittura, nella stringa di connessione è necessario specificare il nome DNS del listener del gruppo di disponibilità. Se una nuova replica diventa la replica primaria del gruppo di disponibilità, le connessioni esistenti che utilizzano il nome di rete del listener del gruppo di disponibilità vengono interrotte. Le nuove connessioni al listener del gruppo di disponibilità vengono quindi indirizzate alla nuova replica primaria. Di seguito è riportato un esempio di una stringa di connessione di base per il provider ADO.NET (System.Data.SqlClient).

Server=tcp: AGListener,1433;Database=MyDB;IntegratedSecurity=SSPI

È ancora possibile scegliere di fare riferimento direttamente all'istanza del nome SQL Server della replica primaria o delle repliche secondarie anziché utilizzare il nome server del listener del gruppo di disponibilità, tuttavia se si sceglie di procedere in questo modo le nuove connessioni non verranno indirizzate automaticamente alla replica primaria corrente, perdendo così un notevole vantaggio. Verranno meno anche i vantaggi derivanti dal routing in sola lettura.

Icona freccia utilizzata con il collegamento Torna all'inizio[Inizio pagina]

Utilizzo di un listener per connettersi a una replica secondaria di sola lettura (routing di sola lettura)

Routing in sola lettura: SQL Server è in grado di indirizzare le connessioni in ingresso dirette a un listener del gruppo di disponibilità a una replica secondaria configurata per il supporto dei carichi di lavoro in sola lettura. Una connessione in ingresso che fa riferimento a un nome del listener del gruppo di disponibilità può essere automaticamente indirizzata a una replica in sola lettura qualora sussistano le condizioni seguenti:

  • Almeno una replica secondaria viene impostata sull'accesso di sola lettura e ogni replica secondaria di sola lettura e la replica primaria vengono configurate per supportare il routing di sola lettura. Per ulteriori informazioni, vedere Per configurare repliche di disponibilità per il routing di sola lettura, più avanti in questa sezione.

  • La stringa di connessione fa riferimento a un listener del gruppo di disponibilità e la finalità dell'applicazione della connessione in ingresso è impostata su sola lettura, ad esempio tramite la parola chiave Application Intent**=**ReadOnly nelle stringhe di connessione ODBC o OLEDB o proprietà o attributi di connessione. Per ulteriori informazioni, vedere Finalità dell'applicazione di sola lettura e routing di sola lettura, più avanti in questa sezione.

Per configurare repliche di disponibilità per il routing di sola lettura

Un amministratore del database deve configurare le repliche di disponibilità come segue:

  1. Per ogni replica di disponibilità che si desidera configurare come replica secondaria leggibile, un amministratore del database deve configurare le impostazioni seguenti che vengono applicate solo nel ruolo secondario:

    • È necessario impostare l'accesso alla connessione su "tutto" o "sola lettura".

    • È necessario specificare l'URL del routing di sola lettura.

  2. Per ognuna di queste repliche, è necessario specificare un elenco di routing di sola lettura per il ruolo primario. Specificare uno o più nomi di server come destinazioni del routing.

Attività correlate

Finalità dell'applicazione di sola lettura e routing di sola lettura

La proprietà della stringa di connessione della finalità dell'applicazione esprime la richiesta dell'applicazione client di essere indirizzata a una versione in lettura e scrittura o in sola lettura del database del gruppo di disponibilità. Per utilizzare un routing di sola lettura, un client deve utilizzare la finalità dell'applicazione di sola lettura nella stringa di connessione per connettersi al listener del gruppo di disponibilità. Senza la finalità dell'applicazione di sola lettura, le connessioni al listener del gruppo di disponibilità sono indirizzate al database sulla una replica primaria.

L'attributo della finalità dell'applicazione viene archiviato nella sessione del client durante l'accesso. L'istanza di SQL Server elaborerà questa finalità e determinerà come procedere in base alla configurazione del gruppo di disponibilità e allo stato in lettura e scrittura corrente del database di destinazione nella replica secondaria.

Di seguito è riportato un esempio di una stringa di connessione per il provider ADO.NET (System.Data.SqlClient) che specifica la finalità dell'applicazione in sola lettura.

Server=tcp:AGListener,1433;Database=AdventureWorks;IntegratedSecurity=SSPI;ApplicationIntent=ReadOnly

In questo esempio, il client tenta di connettersi al listener del gruppo di disponibilità denominato AGListener sulla porta 1433. (È possibile omettere la porta se il listener del gruppo di disponibilità è in attesa sulla porta 1433). La stringa di connessione contiene la proprietà ApplicationIntent impostata su ReadOnly, rendendola una stringa di connessione con finalità di lettura. Senza questa impostazione, il server non avrebbe tentato di eseguire il routing in sola lettura della connessione.

Il database primario del gruppo di disponibilità elabora la richiesta di routing in sola lettura in ingresso e tenta di trovare una replica online in sola lettura che sia stata aggiunta alla replica primaria e configurata per il routing in sola lettura. Il client riceve nuovamente le informazioni di connessione dal server della replica primaria e si connette alla replica in sola lettura identificata.

La finalità dell'applicazione può essere inviata da un driver client a un'istanza di livello inferiore di SQL Server. In questo caso, la finalità dell'applicazione di sola lettura viene ignorato e la connessione procede normalmente.

È possibile ignorare il routing in sola lettura non impostando la proprietà di connessione della finalità dell'applicazione su ReadOnly (se non viene specificata alcuna proprietà, il valore predefinito è ReadWrite durante l'accesso) oppure connettendosi direttamente all'istanza della replica primaria di SQL Server anziché utilizzare il nome del listener del gruppo di disponibilità. Il routing in sola lettura non può avvenire se la connessione viene eseguita direttamente a una replica in sola lettura.

Attività correlate

Icona freccia utilizzata con il collegamento Torna all'inizio[Inizio pagina]

Ignorare i listener del gruppo di disponibilità

Se i listener dei gruppi di disponibilità consentono il supporto per il reindirizzamento del failover e il routing in sola lettura, le connessioni client non devono utilizzarli. Una connessione client può anche fare riferimento all'istanza di SQL Server anziché stabilire la connessione al listener del gruppo di disponibilità.

Per l'istanza di SQL Server è irrilevante se una connessione effettua l'accesso tramite il listener del gruppo di disponibilità o un altro endpoint dell'istanza. L'istanza di SQL Server verificherà lo stato del database di destinazione e consentirà o meno la connettività in base alla configurazione del gruppo di disponibilità e lo stato corrente del database sull'istanza. Ad esempio, se un'applicazione client si connette direttamente a un'istanza della porta di SQL Server e a un database di destinazione ospitato in un gruppo di disponibilità e il database di destinazione si trova nello stato primario ed è online, la connettività ha esito positivo. Se il database di destinazione è offline o si trova in uno stato transizionale, la connettività al database ha esito negativo.

In alternativa, durante la migrazione dal mirroring del database a Gruppi di disponibilità AlwaysOn, le applicazioni possono specificare la stringa di connessione per il mirroring del database purché esista una sola replica secondaria e non siano consentite le connessioni utente. Per ulteriori informazioni, vedere Utilizzo delle stringhe di connessione per il mirroring del database con Gruppi di disponibilità, più avanti in questa sezione.

Utilizzo delle stringhe di connessione per il mirroring del database con Gruppi di disponibilità

Se un gruppo di disponibilità include solo una replica di disponibilità e non è configurato per consentire l'accesso in lettura alla replica secondaria, i client possono connettersi alla replica primaria tramite una stringa di connessione per il mirroring del database. Questo approccio può essere utile durante la migrazione di un'applicazione esistente dal mirroring del database a un gruppo di disponibilità, a condizione che il gruppo di disponibilità sia limitato a due repliche di disponibilità (una replica primaria e una replica secondaria). Se si aggiungono altre repliche di disponibilità, è necessario creare un listener per il gruppo di disponibilità e aggiornare le applicazioni affinché utilizzino il nome DNS del listener del gruppo di disponibilità.

Quando si utilizzano le stringhe di connessione per il mirroring del database, il client può utilizzare SQL Server Native Client o il provider di dati .NET Framework per SQL Server. La stringa di connessione fornita da un client deve specificare almeno il nome di un'istanza del server, ovvero il nome del partner iniziale, per identificare l'istanza del server che ospita inizialmente la replica di disponibilità alla quale si desidera connettersi. Facoltativamente, la stringa di connessione può fornire anche il nome di un'altra istanza del server, il nome del partner di failover, per identificare l'istanza del server che ospita inizialmente la replica secondaria come nome del partner di failover.

Per ulteriori informazioni sulle stringhe di connessione per il mirroring del database, vedere Connessione di client a una sessione di mirroring del database (SQL Server).

Icona freccia utilizzata con il collegamento Torna all'inizio[Inizio pagina]

Comportamento delle connessioni client al failover

Quando si verifica un failover del gruppo di disponibilità, le connessioni persistenti esistenti al gruppo di disponibilità vengono terminate e il client deve stabilire una nuova connessione per poter continuare a utilizzare lo stesso database primario o il database secondario in sola lettura. Nel corso di un failover sul lato server, la connettività al gruppo di disponibilità potrebbe non essere disponibile, di conseguenza l'applicazione client potrebbe tentare di riconnettersi finché il database primario non viene riportato online.

Se il gruppo di disponibilità viene riportato online durante un tentativo di connessione dell'applicazione client, ma prima del periodo di timeout della connessione, è possibile che il driver client si connetta correttamente durante uno di questi tentativi interni senza che si verifichi alcun errore.

Icona freccia utilizzata con il collegamento Torna all'inizio[Inizio pagina]

Supporto del failover su più subnet del gruppo di disponibilità

Se si utilizzano librerie client che supportano l'opzione di connessione MultiSubnetFailover nella stringa di connessione, è possibile ottimizzare il failover del gruppo di disponibilità su un'altra subnet impostando MultiSubnetFailover su “True” o "Yes", a seconda della sintassi del provider utilizzato.

[!NOTA]

È consigliabile utilizzare questa impostazione per le connessioni con una o più subnet a listener di gruppi di disponibilità e a istanze del cluster di failover di SQL Server. Abilitando questa opzione si aggiungono ulteriori ottimizzazioni, anche per scenari con una sola subnet.

L'opzione di connessione MultiSubnetFailover funziona unicamente con il protocollo di rete TCP ed è supportata solo in caso di connessione a un listener del gruppo di disponibilità e per qualsiasi nome di rete virtuale che si connette a SQL Server 2012.

Di seguito è riportato un esempio di una stringa di connessione per il provider ADO.NET (System.Data.SqlClient) che consente il failover su più subnet.

Server=tcp:AGListener,1433;Database=AdventureWorks;IntegratedSecurity=SSPI; MultiSubnetFailover=True

L'opzione di connessione MultiSubnetFailover deve essere impostata su True anche se il gruppo di disponibilità si estende su una sola subnet. In questo modo è possibile preconfigurare nuovi client affinché supportino l'espansione futura su più subnet senza necessità di modificare la stringa di connessione client, oltre a ottimizzare le prestazioni dei failover su una sola subnet. Sebbene l'opzione di connessione MultiSubnetFailover non sia obbligatoria, accelera il failover su subnet. Il driver client tenta infatti di aprire un socket TCP per ogni indirizzo IP in parallelo associato al gruppo di disponibilità. Il driver client attende che il primo indirizzo IP risponda, quindi utilizza tale risposta per la connessione.

Icona freccia utilizzata con il collegamento Torna all'inizio[Inizio pagina]

Listener del gruppo di disponibilità e certificati SSL

Quando ci si connette a un listener del gruppo di disponibilità, se le istanze di SQL Server utilizzano i certificati SSL insieme alla crittografia della sessione, il driver client che tenta la connessione deve supportare il Nome soggetto alternativo nel certificato SSL per forzare la crittografia. Il supporto del driver SQL Server per il Nome soggetto alternativo del certificato è pianificato per ADO.NET (SqlClient), Microsoft JDBC e SQL Native Client (SNAC).

È necessario configurare un certificato X.509 per ogni nodo server che partecipa nel cluster di failover con un elenco di tutti i listener dei gruppi di disponibilità impostati nel Nome soggetto alternativo del certificato.

Ad esempio, se il cluster WSFC dispone di tre listener con i nomi AG1_listener.Adventure-Works.com, AG2_listener.Adventure-Works.com e AG3_listener.Adventure-Works.com, il Nome soggetto alternativo per il certificato deve essere impostato nel modo seguente:

CN = ServerFQDN
SAN = ServerFQDN,AG1_listener.Adventure-Works.com, AG2_listener.Adventure-Works.com, AG3_listener.Adventure-Works.com

Icona freccia utilizzata con il collegamento Torna all'inizio[Inizio pagina]

Listener del gruppo di disponibilità e nomi entità server (SPN)

Un amministratore di dominio deve configurare un nome entità server (SPN) in Active Directory per ogni nome di listener del gruppo di disponibilità per abilitare Kerberos per la connessione client al listener del gruppo di disponibilità. Per registrare il nome SPN, è necessario utilizzare l'account del servizio dell'istanza del server che ospita la replica di disponibilità. Per fare in modo che il nome SPN funzioni su tutte le repliche, è necessario riutilizzare lo stesso account del servizio per tutte le istanze nel cluster WSFC che ospita il gruppo di disponibilità.

Utilizzare lo strumento della riga di comando di Windows setspn per configurare il nome SPN. Ad esempio, per configurare un nome SPNr per un gruppo di disponibilità denominato AG1listener.Adventure-Works.com ospitato in un set di istanze di SQL Server configurate per essere eseguite nell'account di dominio corp/svclogin2:

setspn -A MSSQLSvc/AG1listener.Adventure-Works.com:1433 corp/svclogin2

Per ulteriori informazioni sulla registrazione manuale di un nome SPN per SQL Server, vedere Registrazione di un nome dell'entità servizio per le connessioni Kerberos.

Icona freccia utilizzata con il collegamento Torna all'inizio[Inizio pagina]

Attività correlate

Icona freccia utilizzata con il collegamento Torna all'inizio[Inizio pagina]

Contenuto correlato

Icona freccia utilizzata con il collegamento Torna all'inizio[Torna all'inizio]

Vedere anche

Concetti

Panoramica di Gruppi di disponibilità AlwaysOn (SQL Server)

Connettività client AlwaysOn (SQL Server)

Informazioni sull'accesso alla connessione client per le repliche di disponibilità (SQL Server)

Repliche secondarie attive: Repliche secondarie leggibili (Gruppi di disponibilità AlwaysOn)

Connessione di client a una sessione di mirroring del database (SQL Server)