Interoperabilità delle funzionalità con gruppo di disponibilità e listener DNN

  • Articolo

Si applica a: SQL Server su VM di Azure

Suggerimento

Esistono molti metodi per distribuire un gruppo di disponibilità. Semplificare la distribuzione ed eliminare la necessità di un servizio di Azure Load Balancer o di un nome di rete distribuito (DNN) per il gruppo di disponibilità AlwaysOn creando le macchine virtuali (VM) di SQL Server in più subnet all'interno della stessa rete virtuale di Azure. Se il gruppo di disponibilità è già stato creato in una singola subnet, è possibile eseguirne la migrazione a un ambiente con più subnet.

Esistono alcune funzionalità di SQL Server che si basano su un nome di rete virtuale hardcoded (VNN). Di conseguenza, quando si usa il listener DNN (nome di rete distribuito) con il gruppo di disponibilità AlwaysOn e SQL Server su macchine virtuali di Azure in una subnet singola, potrebbero esserci alcune considerazioni aggiuntive.

Questo articolo illustra in dettaglio le funzionalità di SQL Server e l'interoperabilità con il listener DNN del gruppo di disponibilità.

Differenze di comportamento

Esistono alcune differenze di comportamento importanti tra la funzionalità del listener VNN e il listener DNN:

  • Tempo di failover: il tempo di failover è più veloce quando si usa un listener DNN perché non è necessario attendere che il servizio di bilanciamento del carico di rete rilevi l'evento di errore e modifichi il routing.
  • Connessioni esistenti: le connessioni effettuate a un database specifico all'interno di un gruppo di disponibilità con failover vengono chiuse, ma altre connessioni alla replica primaria restano aperte perché il nome di rete distribuita rimane online durante il processo di failover. Non si tratta di un ambiente VNN tradizionale, dove tutte le connessioni alla replica primaria in genere si chiudono quando il gruppo di disponibilità esegue il failover, il listener passa offline e la replica primaria passa al ruolo secondario. Quando si usa un listener DNN, potrebbe essere necessario modificare le stringa di connessione dell'applicazione per assicurarsi che le connessioni vengano reindirizzate alla nuova replica primaria al momento del failover.
  • Transazioni aperte: le transazioni aperte su un database in un gruppo di disponibilità con failover si chiudono ed eseguono il rollback, per cui sarà necessario riconnettersi manualmente. Ad esempio, in SQL Server Management Studio, è necessario chiudere la finestra della query e aprirne una nuova.

Driver client

Per i driver ODBC, OLEDB, ADO.NET, JDBC, PHP e Node.js, gli utenti devono specificare in modo esplicito il nome e la porta del listener DNN come nome del server nella stringa di connessione. Per garantire una connettività rapida al failover, aggiungere MultiSubnetFailover=True alla stringa di connessione se il client SQL lo supporta.

Strumenti

Gli utenti di SQL Server Management Studio, sqlcmd, Azure Data Studio e SQL Server Data Tools devono specificare in modo esplicito il nome e la porta del listener DNN come nome del server nella stringa di connessione per connettersi al listener.

La creazione del listener DNN tramite l'interfaccia utente grafica di SQL Server Management Studio (SSMS) non è attualmente supportata.

Gruppi di disponibilità e istanza del cluster di failover (FCI)

È possibile configurare un gruppo di disponibilità Always On usando un'istanza del cluster di failover (FCI) come una delle repliche. Affinché questa configurazione funzioni con il listener DNN, anche l'istanza del cluster di failover deve usare il listener DNN perché non è possibile inserire l'indirizzo IP virtuale dell'istanza del cluster di failover nell'elenco IP del DNN del gruppo di disponibilità.

In questa configurazione, l'URL dell'endpoint del mirroring per la replica dell'istanza del cluster di failover deve usare il listener DNN dell'istanza del cluster di failover. Analogamente, se l'istanza del cluster di failover viene usata come replica di sola lettura, il routing di sola lettura alla replica dell'istanza del cluster di failover deve usare il listener DNN FCI.

L'endpoint del mirroring è nel formato: ENDPOINT_URL = 'TCP://<FCI DNN DNS name>:<mirroring endpoint port>'.

Ad esempio, se il nome DNS del listener DNN dell'istanza del cluster di failover è dnnlsnr, e 5022 è la porta dell'endpoint del mirroring dell'istanza del cluster di failover, il frammento di codice Transact-SQL (T-SQL) per creare l'URL dell'endpoint è simile al seguente:

ENDPOINT_URL = 'TCP://dnnlsnr:5022'

Allo stesso modo, il formato per l'URL di routing di sola lettura è: TCP://<FCI DNN DNS name>:<SQL Server instance port>.

Ad esempio, se il nome DNS del listener DNN è dnnlsnr, e 1444 è la porta usata dall'istanza del cluster di failover di SQL Server di sola lettura, il frammento di codice T-SQL per creare l'URL del routing di sola lettura è simile al seguente:

READ_ONLY_ROUTING_URL = 'TCP://dnnlsnr:1444'

È possibile omettere la porta nell'URL se si tratta della porta 1433 predefinita. Per un'istanza denominata, configurare una porta statica per l'istanza denominata e specificarla nell'URL del routing di sola lettura.

Gruppi di disponibilità distribuiti

Se il listener per il gruppo di disponibilità è stato configurato utilizzando un nome di rete distribuito (DNN), la configurazione di un gruppo di disponibilità distribuito al di sopra del gruppo di disponibilità non è supportata.

Replica

Le repliche di tipo transazionale, merge e snapshot supportano tutte la sostituzione del listener VNN con il listener e la porta DNN negli oggetti di replica che si connettono al listener.

Per altre informazioni su come usare la replica con i gruppi di disponibilità, vedere Autore e gruppo di disponibilità, Sottoscrittore e gruppo di disponibilità, e Distributore e gruppo di disponibilità.

MSDTC

Il servizio MSDTC è supportato sia in locale che in cluster, ma l'MSDTC usa una porta dinamica che richiede un'istanza standard di Azure Load Balancer per configurare la porta a disponibilità elevata. Di conseguenza, la macchina virtuale deve usare una prenotazione IP standard oppure non può essere esposta a Internet.

Definire due regole, una per la porta mapper di endpoint RPC 135 e una per la porta MSDTC reale. Dopo il failover, modificare la regola di bilanciamento del carico nella nuova porta MSDTC dopo la modifica nel nuovo nodo.

Se il servizio MSDTC è locale, assicurarsi di consentire la comunicazione in uscita.

Query distribuite

La query distribuita si basa su un server collegato, che può essere configurato usando il listener e la porta DNN del gruppo di disponibilità. Se la porta non è la 1433, scegliere l'opzione Usa altra origine dati in SQL Server Management Studio (SSMS) durante la configurazione del server collegato.

FILESTREAM

FILESTREAM è supportato ad esclusione degli scenari in cui gli utenti accedono alla condivisione file con ambito usando l'API File di Windows.

FileTable

FileTable è supportato ad esclusione degli scenari in cui gli utenti accedono alla condivisione file con ambito usando l'API File di Windows.

Server collegati

Configurare il server collegato usando il nome e la porta del listener DNN del gruppo di disponibilità. Se la porta non è la 1433, scegliere l'opzione Usa altra origine dati in SQL Server Management Studio (SSMS) durante la configurazione del server collegato.

Domande frequenti

Quale versione di SQL Server offre il supporto del listener DNN del gruppo di disponibilità?

SQL Server 2019 unità di capacità 8 e versioni successive.

Qual è il tempo di failover previsto quando viene usato il listener DNN?

Per il listener DNN, il tempo di failover corrisponde al tempo di failover del gruppo di disponibilità, senza tempi di inattività aggiuntivi (come nel caso del tempo di probe quando si usa Azure Load Balancer).

Esiste un requisito di versione per i client SQL per supportare il listener DNN con OLEDB e ODBC?

È consigliabile un MultiSubnetFailover=True supporto con stringa di connessione per il listener DNN. Disponibile solo a partire da SQL Server 2012 (11.x).

Sono necessarie modifiche alla configurazione di SQL Server per l'uso del listener DNN?

SQL Server non richiede alcuna modifica di configurazione per l'uso del listener DNN, ma alcune funzionalità di SQL Server potrebbero richiedere una maggiore considerazione.

Il listener DNN supporta cluster con subnet multipli?

Sì. Il cluster associa il listener DNN in DNS agli indirizzi IP fisici di tutte le repliche nel gruppo di disponibilità, indipendentemente dalla subnet. Il client SQL prova tutti gli indirizzi IP del nome DNS indipendentemente dalla subnet.

Il listener DNN del gruppo di disponibilità supporta il routing di sola lettura?

Sì. Il routing di sola lettura è supportato con il listener DNN.

Contenuto correlato