Clustering su più subnet di SQL Server (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 differente di subnet. Queste subnet possono trovarsi nella stessa posizione o in siti dislocati in località geografiche diverse. Il clustering tra siti dislocati in diverse località geografiche viene talvolta definito come cluster esteso. Poiché non esiste alcuna archiviazione condivisa a cui possono accedere tutti i nodi, i dati devono essere replicati tra le archiviazioni dati nelle diverse subnet. Grazie alla replica dei dati risultano 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.

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

Nella figura seguente è illustrata un'istanza di cluster di failover (FCI) con due nodi e due subnet in SQL Server.

Configurazioni di istanze di cluster di failover su più subnet

Di seguito sono riportati alcuni esempi di FCI di SQL Server in cui vengono usate 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. L'installazione di SQL Server riconosce tale configurazione come cluster con più subnet e imposta la dipendenza delle risorse di indirizzo IP su OR.

• Nell'istanza del cluster di failover SQLCLUST1 di SQL Server sono inclusi i nodi Node1, Node2 e Node3. Node1 e Node2 sono connessi a Subnet1. Node3 è connesso a Subnet2. L'installazione di SQL Server riconosce tale configurazione come cluster con più subnet e imposta la dipendenza delle risorse di indirizzo IP su OR. Poiché Node1 e Node2 si trovano nella stessa subnet, questa configurazione garantisce un'elevata disponibilità locale aggiuntiva.

• Nell'istanza del cluster di failover SQLCLUST1 di SQL Server sono inclusi i nodi Node1 e Node2. Node1 si trova in Subnet1. Node2 è su Subnet1 e Subnet2. L'installazione di SQL Server riconosce tale configurazione come cluster con più subnet e imposta la dipendenza delle risorse di indirizzo IP su OR.

• Nell'istanza del cluster di failover SQLCLUST1 di SQL Server sono inclusi i nodi Node1 e Node2. Node1 è connesso a Subnet1 e a Subnet2. Anche Node2 è connesso a Subnet1 e a Subnet2. La dipendenza delle risorse di indirizzo IP viene impostata su AND dall'installazione di SQL Server.

  Nota

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

Considerazioni relative alle risorse di indirizzo 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 delle risorse di indirizzo IP su OR. Questa operazione consente a SQL Server di essere online quando è presente almeno un indirizzo IP valido a cui possa associarsi.

Considerazioni sulla dipendenza OR delle risorse di indirizzo IP

Se la dipendenza delle risorse di indirizzo IP viene impostata su OR, è opportuno considerare il seguente comportamento di failover:

• Quando si verifica un errore in uno degli indirizzi IP del nodo che attualmente possiede il gruppo di risorse del cluster di SQL Server, il failover non viene attivato automaticamente finché tutti gli indirizzi IP validi in quel nodo non avranno esito negativo.

• Quando si verifica un failover, SQL Server viene portato 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 saranno elencati nel log degli errori.

Quando si esegue un'installazione side-by-side di una FCI di SQL Server con un'istanza autonoma del motore di database di SQL Server, prestare attenzione per evitare conflitti del numero di porta TCP negli indirizzi IP. Di solito i conflitti si verificano quando due istanze del motore di database sono entrambe configurate per usare la porta TCP predefinita (1433). Per evitare conflitti, configurare un'istanza in modo che venga utilizzata una porta fissa non predefinita. La configurazione di una porta fissa è di solito più facile nell'istanza autonoma. Configurare il motore di database in modo che vengano usate porte diverse per evitare un conflitto di indirizzo IP/porta TCP non previsto che blocca l'avvio di un'istanza quando si verifica un errore di una FCI di SQL Server nel nodo di standby.

Latenza di recupero del client durante i failover

Una FCI su più subnet abilita per impostazione predefinita la risorsa cluster RegisterAllProvidersIP per il nome di rete. In una configurazione con più subnet, sia gli indirizzi IP online che offline del nome di rete verranno registrati sul server DNS. L'applicazione client recupera quindi tutti gli indirizzi IP registrati dal server DNS e tenta di connettersi agli indirizzi in sequenza o in parallelo. Ciò significa che il tempo di recupero del client nei failover con più subnet non dipende più dalle latenze di aggiornamento DNS. Per impostazione predefinita, il client prova gli indirizzi IP in sequenza. Quando il client utilizza il nuovo parametro MultiSubnetFailover=True facoltativo nella stringa di connessione, prova invece gli indirizzi IP simultaneamente e si connette al primo server che risponde. In questo modo è possibile ridurre la latenza di recupero del client quando si verificano i 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 di terze parti non è possibile utilizzare 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. In questo modo non si verifica il timeout del tentativo di riconnessione del client prima che siano stati scorsi tutti gli indirizzi IP nella FCI su più subnet.

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

Contenuto correlato