Gruppi di disponibilità Always On di SQL Server è la tecnologia più recente di Microsoft per soddisfare le esigenze di disponibilità elevata e ripristino di emergenza delle organizzazioni che utilizzano SQL Server. Un grande vantaggio di AlwaysOn è la capacità di gestire sia HA che DR in un'unica implementazione. Abbiamo riscontrato i seguenti vantaggi chiave di AlwaysOn:
Possiamo raggruppare i database correlati come parte di un unico gruppo di disponibilità e far eseguire il failover insieme nel caso fosse necessario. Ciò è particolarmente utile per le applicazioni che dipendono da più di un database, come Microsoft Office SharePoint, Microsoft Lync e Sage.
Rispetto alle istanze del cluster di failover di SQL Server, troviamo che l'archiviazione come singolo punto di errore è stata eliminata poiché ogni istanza costituisce una replica viene assegnato un proprio spazio di archiviazione.
Con AlwaysOn, è possibile configurare HA e DR contemporaneamente. Ciò si ottiene creando un cluster di failover di Windows multisito come base della configurazione AlwaysOn. L'esecuzione di un cambio di ruolo quando si utilizza AlwaysOn è molto più semplice rispetto a quando si utilizza la spedizione del registro delle transazioni.
Oggetti del computer
Active Directory (AD) è un argomento molto vasto e non approfondiremo i dettagli in questo articolo. Come puoi immaginare, Active Directory è il servizio di directory di Microsoft. In termini di reti di computer, un servizio di directory è una struttura che ci consente di registrare, identificare e gestire centralmente tutti gli oggetti all'interno di una rete. Le voci nei servizi di directory associano i nomi dei dispositivi di rete agli indirizzi IP corrispondenti e ad altre proprietà nella directory. Gli oggetti più comuni in un servizio di directory (e in AD di Microsoft) sono Utenti e Computer. Così come ogni utente del dominio può essere registrato e gestito da Active Directory, anche ogni computer del dominio può essere gestito da Active Directory. Proprio come ogni utente dovrebbe avere un account univoco in Active Directory, così è ogni computer.
In Active Directory, non tutti gli oggetti computer vengono mappati su un computer fisico. Un Oggetto Computer può rappresentare un computer fisico (stazione di lavoro o server) ma può anche rappresentare qualcosa che agisce come un computer, ad esempio il nome rappresentativo di un cluster di Windows o il nome virtuale di un servizio cluster (ruolo). Tali rappresentazioni sono anche uniche in Active Directory, proprio come i normali nomi di computer.
CNO e VNO in WSFC
Quando installi un cluster di failover di Windows, il programma di installazione crea un'entità in Active Directory denominata Computer Name Object (CNO). Questo CNO è l'entità principale creata in Active Directory per il cluster e rappresenta il "Nome server" dell'intero cluster. Successivamente, altri oggetti noti come Oggetti nome virtuale vengono creati dal CNO durante l'esecuzione di attività quali la creazione di ruoli cluster, Gruppi di disponibilità o Ascoltatori del gruppo di disponibilità . Questi CNO e VNO hanno indirizzi IP associati. È possibile specificare questi indirizzi durante l'installazione del cluster o la creazione di un nuovo ruolo Cluster o Listener. Per ogni cluster, ruolo e listener che crei, sono necessari un nome computer univoco e un indirizzo IP univoco. La Fig. 1 mostra il passaggio durante il quale si specifica il Cluster Name Object e il relativo indirizzo IP durante la configurazione di un cluster.
I nomi che usi durante la configurazione di un cluster sono completamente arbitrari. Devono solo essere unici. Tuttavia, si consiglia di seguire le convenzioni di denominazione della propria organizzazione per i normali computer durante la creazione di CNO o VNO:ciò aiuta a semplificare la gestione. Ha anche senso utilizzare un blocco specifico di indirizzi IP che coprirà tutte le esigenze di indirizzamento per l'intero cluster:il CNO e tutti i VNO (ruoli) che intendi creare.
Fig. 1 Mappatura da nome a indirizzo in un cluster
Le autorizzazioni principali del dominio
Il DBA o l'amministratore di sistema che esegue un'installazione cluster deve disporre dell'autorizzazione per Creare oggetti computer nel dominio di Active Directory. A sua volta, dopo aver creato l'oggetto nome computer, l'amministratore di dominio deve concedere le seguenti autorizzazioni all'oggetto nome computer in modo che i ruoli (che risultano in oggetti nome virtuale) possano essere creati correttamente nel cluster:
Crea oggetti del computer
Leggi tutte le proprietà
Senza queste autorizzazioni, è probabile che tu riceva messaggi di errore simili a quello riportato di seguito quando tenti di creare un ruolo (nel caso di AlwaysOn FCI ) o un Listener (nel caso di AlwaysOn AG ):
Errore durante l'installazione di MS SQL Server Cluster:
La risorsa del nome di rete del cluster 'Nome di rete SQL (EUK-SCCM-01)' non è riuscita a creare l'oggetto computer associato nel dominio 'nomedominio.com' per il motivo seguente:Impossibile creare l'account computer.
Il testo del codice di errore associato è:Accesso negato.
Questo messaggio di errore viene visualizzato nel Visualizzatore eventi poiché SQL Server non sarebbe accessibile in questo momento. Sarai anche in grado di vederlo se accedi ai file di registro degli errori SQL nella cartella LOG che si trova nella directory di installazione di SQL Server. La frase chiave è "Accesso negato ”.
Altri requisiti
Dovrei menzionare il concetto di controller di dominio. Un controller di dominio, o più precisamente un insieme di controller di dominio, fornisce servizi chiave per Active Directory come la registrazione di oggetti e l'autenticazione di utenti e computer. Per configurare correttamente un cluster o un Listener AlwaysOn, un controller di dominio deve essere raggiungibile dal computer in cui si esegue la configurazione. Ciò significa che la comunicazione dal computer al controller di dominio deve essere aperta su un intervallo di porte TCP e UDP. Microsoft lo documenta in dettaglio in questo articolo . Questo potrebbe essere un dato di fatto nella maggior parte dei casi, ma quando si risolvono i problemi di connettività, è utile sapere cosa è effettivamente necessario.
In un articolo precedente , ho anche detto che è necessario concedere autorizzazioni al CNO di un cluster durante la configurazione di un quorum di condivisione file.
Fig. 2 Autorizzazioni su una condivisione file
Una nota sulla risoluzione dei nomi
Essendo oggetti computer, CNO e VNO dipendono da Domain Name Service per risolvere il nome indicato durante l'installazione del cluster, la creazione di un ruolo o la creazione di un listener AlwaysOn. In genere ai client vengono assegnati questi nomi di computer per stabilire una connessione al cluster. In altre parole, l'indirizzo IP è trasparente per loro, semplificando la configurazione del client e astraendo i failover dagli utenti finali.
Fig. 3 Proprietà dell'ascoltatore AG per l'ascoltatore con due indirizzi IP
In un articolo precedente, ho menzionato un caso in cui questo scenario può causare problemi. Nel nostro cluster multisito, avevamo un listener per il nostro gruppo di disponibilità AlwaysOn. Questo listener è stato configurato per risolvere su due indirizzi IP. Ciò è necessario per un cluster multisito che si estende su più subnet. In una tale configurazione, il server dei nomi restituirà entrambi gli indirizzi IP mappati al listener dopo aver emesso un nslookup controllare (vedi Fig. 4). Tuttavia, durante la connessione, puoi accedere solo a uno di quegli indirizzi IP alla volta. Cluster Manager mostrerà l'altro indirizzo IP come Offline (vedi Fig. 5).
Fig. 4 Proprietà dell'ascoltatore AG per l'ascoltatore con due indirizzi IP
Fig. 5 Proprietà per ruolo cluster con due indirizzi IP in sottoreti separate
Questo è normale. Se si verifica un failover al sito alternativo, il server DNS inizia a risolvere l'indirizzo IP alternativo dopo alcuni minuti. L'implicazione di ciò è che la comunicazione dei clienti con il sito alternativo deve essere possibile. La Fig. 6 e la Fig 7 lo evidenziano ulteriormente.
Fig. 6 Percorso di comunicazione con la replica primaria a Dakar
Diamo una buona occhiata al percorso che i pacchetti attraverseranno dai computer client al cluster. Quando la replica primaria è a Dakar, il nome Listener SQL-SVR-LNR viene risolto nell'indirizzo IP 192.168.1.20 e WFCS, a sua volta, indirizza la richiesta al server 192.168.1.22 (si noti che anche questo server ha il proprio nome del computer). In caso di failover a Nairobi, abbiamo il percorso di comunicazione che passa da 192.168.2.20 e poi a 192.168.2.22. L'implicazione è che per un'esperienza cliente senza interruzioni, tutti i client in tutti i data center devono avere la comunicazione consentita su tutti i firewall coinvolti utilizzando la porta 1433.
Fig. 7 Percorso di comunicazione con la replica primaria a Nairobi
Conclusione
Sebbene il clustering di failover di Windows, Active Directory e Domain Name Service possano essere al di fuori del ruolo di amministratore del database, è utile avere una conoscenza di base del funzionamento di queste tecnologie per essere in grado di creare e risolvere i problemi di AlwaysOn Istanze del cluster di failover e gruppi di disponibilità AlwaysOn. Alcune organizzazioni hanno una rigida separazione dei compiti tra amministratori di sistema e amministratori di database, ma in caso contrario, l'amministratore di database deve essere in grado di comprendere questi concetti di Windows per avere successo come DBA.
Riferimenti
Panoramica dei gruppi di disponibilità AlwaysOn
Cluster di failover di Windows con SQL Server
Panoramica del servizio e requisiti della porta di rete per Windows
Amministrazione di oggetti del computer
