Clustering su più subnet di SQL Server

Si applica a: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 diverso di subnet. Queste subnet possono trovarsi nella stessa posizione o in siti dislocati in località geografiche diverse. I cluster in siti geograficamente distribuiti vengono talvolta definiti cluster estesi. 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. Quando si replicano i dati, sono disponibili più copie dei dati. Pertanto, oltre a una disponibilità elevata, un cluster di failover su più subnet offre una soluzione di ripristino di emergenza.

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

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

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:

• Nell'istanza del cluster di failover SQLCLUST1 di SQL Server sono inclusi i nodi Node1 e Node2. Node1 è connesso a Subnet1. Node2 è connesso a Subnet1. 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 SQLCLUST2 include Node1, Node2 e Node3. Node1 e Node2 sono connessi a Subnet1. Node3 è 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 garantisce un'elevata disponibilità locale aggiuntiva.

• L'istanza del cluster di failover di SQL Server SQLCLUST3 include Node1 e Node2. Node1 si trova in Subnet1. Node2 è su 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 SQLCLUST4 include Node1 e Node2. Node1 è connesso a Subnet1 e a Subnet2. Anche Node2 è connesso a Subnet1 e a Subnet2. Il programma di installazione di SQL Server imposta la dipendenza della risorsa indirizzo IP su AND.

  Nota

  Questa configurazione non è considerata una configurazione del cluster di failover su più subnet perché i nodi in cluster 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 (11.x), è 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.

Nota

Nelle versioni di SQL Server precedenti a SQL Server 2012 (11.x), è stata usata una tecnologia V-LAN estesa nelle configurazioni cluster multisito per esporre un singolo indirizzo IP per il failover tra siti. Ora che SQL Server può raggruppare nodi in subnet diverse, è possibile configurare cluster di failover di SQL Server in più siti senza implementare la tecnologia V-LAN estesa.

Considerazioni sulla risorsa indirizzo IP O sulle dipendenze

È possibile considerare il comportamento di failover seguente se si imposta la dipendenza della risorsa indirizzo IP su OR:

• Quando si verifica un errore di uno degli indirizzi IP nel nodo proprietario del gruppo di risorse cluster di SQL Server, un failover non viene attivato automaticamente fino a quando non si verificano errori di tutti gli indirizzi IP validi in tale nodo.

• Quando si verifica un failover, SQL Server viene online se può essere associato ad almeno un indirizzo IP valido nel nodo corrente. Gli indirizzi IP che non sono stati 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 numeri di porta TCP negli indirizzi IP. I conflitti si verificano in genere quando due istanze del motore di database sono 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 impedisce un conflitto imprevisto di indirizzi IP/porte TCP che blocca l'avvio di un'istanza quando un'istanza del cluster di failover di SQL Server non riesce al nodo di standby.

Latenza di ripristino del client durante il failover

Per impostazione predefinita, un'istanza del cluster di failover su più subnet abilita la risorsa cluster RegisterAllProvidersIP per il nome di rete. In una configurazione con più subnet, gli indirizzi IP online e offline del nome di rete vengono entrambi 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 sequenza. Quando il client usa il parametro facoltativo MultiSubnetFailover=True nella stringa di connessione, tenta invece gli indirizzi IP contemporaneamente e si connette al primo server che risponde. Questa configurazione consente di ridurre al minimo la latenza di ripristino del client quando si verificano failover. Per altre informazioni, vedere Connettività client Always On (SQL Server) e Creare o configurare un listener del gruppo di disponibilità (SQL Server).

Con librerie client legacy o provider di dati non Microsoft, non è possibile usare il parametro MultiSubnetFailover nella stringa di connessione. Per assicurarsi che l'applicazione client funzioni in maniera ottimale con FCI su più subnet in SQL Server, provare a regolare il timeout di connessione nella stringa di connessione client di 21 secondi per ogni indirizzo IP aggiuntivo. Questa configurazione garantisce che il tentativo di riconnessione del client non si verifichi prima che possa scorrere tutti gli indirizzi IP nell'istanza del cluster di failover su più subnet.

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

Nota

Se si usano più subnet e si dispone di un DNS statico, è necessario disporre di un processo per aggiornare il record DNS associato al listener prima di eseguire un failover. In caso contrario, il nome della rete non verrà online.

Contenuti correlati

Description	Article
Installare un cluster di failover di SQL Server	Creare un nuovo cluster di failover di SQL Server (programma di installazione)
Aggiornamento sul posto del cluster di failover di SQL Server esistente	Aggiornare un'istanza del cluster di failover di SQL Server (programma di installazione)
Gestire il cluster di failover di SQL Server	Aggiungere o rimuovere nodi in un cluster di failover di SQL Server (programma di installazione)
Usare lo snap-in Gestione cluster di failover per visualizzare gli eventi e i log del cluster di failover di Windows Server	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 di Windows Server	cmdlet del cluster di failoverGet-ClusterLog