Clustering di SQL Server su più subnet (SQL Server)

Un cluster di failover su più subnet di SQL Server è una configurazione in cui ogni nodo del cluster di failover è connesso a una subnet diversa o a un set di subnet diverso. Queste subnet possono trovarsi nella stessa posizione o in siti geograficamente dispersi. Il clustering tra siti geograficamente dispersi si definisce talvolta cluster stretch. Poiché non esiste alcuna risorsa di archiviazione condivisa a cui tutti i nodi possono accedere, i dati devono essere replicati tra l'archiviazione dei dati in più subnet. Con la replica dei dati è disponibile più di una copia dei dati. Pertanto, un cluster di failover su più subnet offre una soluzione di ripristino di emergenza oltre alla disponibilità elevata.

Cluster di failover su più subnet di SQL Server (due nodi, Two-Subnets)

La figura seguente rappresenta un'istanza di cluster di failover a due nodi e due subnet in SQL Server 2014.

Architettura multisubnet con failover su multisubnet

Configurazioni dell'istanza del cluster di failover su più subnet

Di seguito sono riportati alcuni esempi di istanze del cluster di failover di SQL Server che usano più subnet:

• L'istanza del cluster di failover di SQL Server SQLCLUST1 include Node1 e Node2. Node1 è connesso a Subnet1. Node2 è connesso a Subnet2. Il programma di installazione di SQL Server vede questa configurazione come cluster su più subnet e imposta la dipendenza della risorsa indirizzo IP su OR.

• L'istanza del cluster di failover (FCI) di SQL Server SQLCLUST1 include Node1, Node2 e Node3. Node1 e Node2 sono connessi a Subnet1. Il nodo 3 è connesso a Subnet2. Il programma di installazione di SQL Server vede questa configurazione come cluster su più subnet e imposta la dipendenza della risorsa indirizzo IP su OR. Poiché Node1 e Node2 si trovano nella stessa subnet, questa configurazione offre disponibilità elevata locale aggiuntiva.

• L'istanza di cluster di failover di SQL Server, SQLCLUST1, include Node1 e Node2. Node1 si trova in Subnet1. Node2 si trova in Subnet1 e Subnet2. Il programma di installazione di SQL Server vede questa configurazione come cluster su più subnet e imposta la dipendenza della risorsa indirizzo IP su OR.

• L'istanza del cluster di failover di SQL Server SQLCLUST1 include i nodi Node1 e Node2. Node1 è connesso a Subnet1 e Subnet2. Node2 è connesso anche a Subnet1 e Subnet2. La dipendenza della risorsa indirizzo IP è impostata su AND dal programma di installazione di SQL Server.

  Annotazioni

  Questa configurazione non è considerata una configurazione di cluster di failover su più subnet perché i nodi raggruppati si trovano nello stesso set di subnet.

Considerazioni sulle risorse degli indirizzi IP

In una configurazione del cluster di failover su più subnet, gli indirizzi IP non sono di proprietà di tutti i nodi del cluster di failover e potrebbero non essere tutti online durante l'avvio di SQL Server. A partire da SQL Server 2012, è possibile impostare la dipendenza della risorsa indirizzo IP su OR. In questo modo SQL Server può essere online quando è presente almeno un indirizzo IP valido a cui può essere associato.

Annotazioni

Nelle versioni di SQL Server precedenti a SQL Server 2012 è stata usata una tecnologia V-LAN estesa nelle configurazioni cluster multisito per esporre un singolo indirizzo IP per il failover tra siti. Con la nuova capacità di SQL Server di raggruppare nodi in subnet diverse, è ora possibile configurare i cluster di failover di SQL Server in più siti senza implementare la tecnologia V-LAN distribuita.

Considerazioni sulla risorsa indirizzo IP o sulle dipendenze

Se si imposta la dipendenza della risorsa indirizzo IP su OR, è opportuno prendere in considerazione il comportamento di failover seguente:

• Quando si verifica un guasto a uno degli indirizzi IP sul nodo che possiede attualmente il gruppo di risorse cluster di SQL Server, un failover non viene innescato automaticamente fino a quando tutti gli indirizzi IP validi su quel nodo non falliscono.

• Quando si verifica un failover, SQL Server verrà online se può essere associato ad almeno un indirizzo IP valido nel nodo corrente. Gli indirizzi IP non associati a SQL Server all'avvio verranno elencati nel log degli errori.

Quando un'istanza del cluster di failover di SQL Server viene installata side-by-side con un'istanza autonoma del motore di database di SQL Server, prestare attenzione a evitare conflitti di numero di porta TCP negli indirizzi IP. I conflitti si verificano in genere quando due istanze del motore di database sono entrambe configurate per l'uso della porta TCP predefinita (1433). Per evitare conflitti, configurare un'istanza per l'uso di una porta fissa non predefinita. La configurazione di una porta fissa è in genere più semplice nell'istanza autonoma. La configurazione del motore di database per l'uso di porte diverse impedirà un conflitto imprevisto di indirizzo IP/porta TCP che blocca l'avvio di un'istanza quando un'istanza del cluster di failover di SQL Server passa al nodo di standby.

Latenza di ripristino client durante il failover

Per impostazione predefinita, un FCI su più subnet abilita la risorsa del cluster RegisterAllProvidersIP per il nome di rete. In una configurazione su più subnet, sia gli indirizzi IP online che offline del nome di rete verranno registrati nel server DNS. L'applicazione client recupera quindi tutti gli indirizzi IP registrati dal server DNS e tenta di connettersi agli indirizzi in ordine o in parallelo. Ciò significa che il tempo di ripristino del client nei failover su più subnet non dipende più dalle latenze degli aggiornamenti DNS. Per impostazione predefinita, il client prova gli indirizzi IP in ordine. Quando il client usa il nuovo parametro facoltativo MultiSubnetFailover=True nella stringa di connessione, tenterà invece gli indirizzi IP contemporaneamente e si connette al primo server che risponde. Ciò consente di ridurre al minimo la latenza di ripristino del client quando si verificano failover. Per altre informazioni, vedere Connettività client AlwaysOn (SQL Server) e Creare o configurare un listener per i gruppi di disponibilità (SQL Server).

Con librerie client legacy o provider di dati di terze parti, non è possibile usare il MultiSubnetFailover parametro nella stringa di connessione. Per garantire che l'applicazione client funzioni in modo ottimale con l'istanza del cluster di failover su più subnet in SQL Server 2014, provare a modificare il timeout della connessione nella stringa di connessione client di 21 secondi per ogni indirizzo IP aggiuntivo. In questo modo si garantisce che il tentativo di riconnessione del client non vada in timeout prima di riuscire a scorrere tutti gli indirizzi IP nell'istanza FCI su più subnet.

Il periodo di timeout di connessione client predefinito per SQL Server Management Studio e sqlcmd è di 15 secondi.

Contenuto correlato

Descrizione del contenuto	Argomento
Installazione di un cluster di failover di SQL Server	Creare un nuovo cluster di failover di SQL Server (installazione)
Aggiornamento sul posto del cluster di failover di SQL Server esistente	Aggiornare un'istanza del cluster di failover di SQL Server (installazione)
Gestione del cluster di failover di SQL Server esistente	Aggiungere o rimuovere nodi in un cluster di failover di SQL Server (programma di installazione)
Cluster di failover di Windows	Migliori pratiche per i cluster di failover multisito di Microsoft Windows
Usare lo snap-in per la gestione dei cluster di failover per visualizzare gli eventi e i log di WSFC	Visualizzare eventi e log per un cluster di failover
Usare Windows PowerShell per creare un file di log per tutti i nodi (o un nodo specifico) in un cluster di failover WSFC	cmdlet del cluster di failoverGet-ClusterLog