Creare un gruppo di disponibilità indipendente dal dominio

Si applica a:SQL Server

I gruppi di disponibilità Always On (AG) richiedono un cluster di failover di Windows Server (WSFC) sottostante. Per distribuire un cluster WSFC tramite Windows Server 2012 R2 è necessario che i server che fanno parte di un cluster WSFC, anche detti nodi, siano aggiunti allo stesso dominio. Per altre informazioni su Active Directory Domain Services, vedere questo articolo.

La dipendenza di WSFC e Active Directory Domain Services è più complessa di quella distribuita in precedenza con una configurazione di mirroring del database, dato che è possibile distribuire il mirroring del database tra più data center mediante i certificati senza tale dipendenza. Un gruppo di disponibilità tradizionale che comprende più di un data center richiede che tutti i server siano aggiunti allo stesso dominio Active Directory. Non è compatibile con domini diversi, anche se si tratta di domini attendibili. Domini diversi, anche se attendibili, non funzionano. Tutti i server devono essere nodi dello stesso cluster WSFC. La figura seguente illustra questa configurazione. SQL Server 2016 (13.x) e versioni successive hanno anche gruppi di disponibilità distribuiti che raggiungono questo obiettivo in modo diverso.

Con Windows Server 2012 R2 è stato introdotto un cluster scollegato da Active Directory, un particolare tipo di cluster di failover di Windows Server che può essere usato con i gruppi di disponibilità. Per questo tipo di cluster WSFC i nodi devono comunque essere aggiunti allo stesso dominio di Active Directory, ma in questo caso il cluster WSFC usa il DNS anziché il dominio. Dato che è ancora previsto l'uso di un dominio, un cluster scollegato da Active Directory non offre ancora un'esperienza completamente senza dominio.

Con Windows Server 2016 è stato introdotto un nuovo tipo di cluster di failover di Windows Server basato sull'elemento essenziale del cluster scollegato da Active Directory: un cluster di gruppi di lavoro. Il cluster di gruppi di lavoro permette a SQL Server di distribuire un gruppo di disponibilità in un cluster WSFC che non richiede Active Directory Domain Services. SQL Server richiede l'uso di certificati per la sicurezza degli endpoint, come avviene per lo scenario di mirroring del database. Questo tipo di gruppo di disponibilità è detto indipendente dal dominio. La distribuzione di un gruppo di disponibilità con un cluster di gruppi di lavoro sottostante supporta le combinazioni seguenti per i nodi che costituiranno il cluster WSFC:

• Nessun nodo è aggiunto a un dominio.
• Tutti i nodi sono aggiunti a domini diversi.
• I nodi sono misti, con una combinazione di nodi aggiunti a un dominio e nodi non aggiunti a un dominio.

La figura seguente mostra un esempio di gruppo di disponibilità indipendente dal dominio in cui i nodi del data center 1 sono aggiunti a un dominio, mentre i nodi del data center 2 usano solo il DNS. In questo caso è possibile impostare il suffisso DNS in tutti i server che costituiranno i nodi del cluster WSFC. Ogni applicazione e ogni server che accedono al gruppo di disponibilità devono visualizzare le stesse informazioni DNS.

Un gruppo di disponibilità indipendente dal dominio non si limita a scenari di ripristino di emergenza o multisito. È possibile implementarlo in un singolo data center e usarlo anche con un gruppo di disponibilità di base. Questa configurazione offre un'architettura simile a quella che era possibile usando il mirroring del database con i certificati, come illustrato.

Per implementare un gruppo di disponibilità indipendente dal dominio occorre tenere presente alcuni fattori:

• Gli unici tipi di controllo disponibili per l'uso con il quorum sono disco e cloud, introdotto con Windows Server 2016. Il disco risulta problematico, perché molto probabilmente il gruppo di disponibilità non fa uso di dischi condivisi.

• La variante cluster di gruppi di lavoro sottostante di un cluster WSFC può essere creata solo tramite PowerShell, ma successivamente può essere gestita con Gestione cluster di failover.

• Se è richiesto Kerberos, è necessario distribuire un cluster WSFC standard collegato a un dominio di Active Directory e, probabilmente, un gruppo di disponibilità indipendente dal dominio non è la scelta ideale.

• È possibile configurare un listener, ma per essere utilizzabile deve essere registrato nel DNS. Come indicato in precedenza, non è previsto alcun supporto Kerberos per il listener.

• Le applicazioni che si connettono a SQL Server devono usare principalmente l'autenticazione di SQL Server, dato che i domini potrebbero non esistere o non essere configurati per l'interazione.

• I certificati vengono usati nella configurazione del gruppo di disponibilità.

Impostare e verificare il suffisso DNS in tutti i server di replica

Per un cluster di gruppi di lavoro di un gruppo di disponibilità indipendente dal dominio è necessario un suffisso DNS comune. Per impostare e verificare il suffisso DNS in ogni istanza di Windows Server che ospiterà una replica per il gruppo di disponibilità, seguire questa procedura:

1. Usando i tasti di scelta rapida tasto WINDOWS + X, selezionare Sistema.
2. Se il nome computer e il nome completo del computer sono uguali, il suffisso DNS non è impostato. Ad esempio, se il nome computer è SERVER1, il valore del nome completo del computer non può essere semplicemente SERVER1. Dovrebbe essere simile a SERVER1.CONTOSO.LAB. CONTOSO.LAB è il suffisso DNS. Il valore del gruppo di lavoro deve essere WORKGROUP. Se è necessario impostare il suffisso DNS, selezionare Cambia impostazioni.
3. Nella finestra di dialogo Proprietà del sistema, selezionare Modifica nella scheda Nome computer.
4. Nella finestra di dialogo Cambiamenti dominio/nome computer fare clic su Altro.
5. Nella finestra di dialogo Suffisso DNS e nome NetBIOS del computer immettere il suffisso DNS comune come suffisso DNS primario.
6. Fare clic su OK per chiudere la finestra di dialogo Suffisso DNS e nome NetBIOS del computer.
7. Fare clic su OK per chiudere la finestra di dialogo Cambiamenti dominio/nome computer.
8. Verrà richiesto di riavviare il server per rendere effettive le modifiche. Fare clic su OK per chiudere la finestra di dialogo Cambiamenti dominio/nome computer.
9. Selezionare Chiudi per chiudere la finestra di dialogo Proprietà del sistema.
10. Verrà richiesto di riavviare. Se non si vuole riavviare immediatamente, fare clic su Riavvia in seguito, in caso contrario fare clic su Riavvia.
11. Dopo aver riavviato il server, assicurarsi che il suffisso DNS comune sia configurato esaminando di nuovo Sistema.

Nota

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

Creare un gruppo di disponibilità indipendente dal dominio

Attualmente non è possibile creare un gruppo di disponibilità indipendente dal dominio interamente con SQL Server Management Studio. Anche se la procedura per la creazione del gruppo di disponibilità indipendente dal dominio è sostanzialmente identica alla creazione di un gruppo di disponibilità normale, alcuni aspetti come la creazione dei certificati sono possibili solo con Transact-SQL. L'esempio seguente presuppone la configurazione di un gruppo di disponibilità con due repliche, una primaria e una secondaria.

1. Usando le istruzioni fornite da Gruppi di lavoro e cluster multidominio in Windows Server 2016, implementare un cluster del gruppo di lavoro composto da tutti i server che faranno parte del gruppo di disponibilità. Prima di configurare il cluster di gruppi di lavoro, assicurarsi che il suffisso DNS comune sia già configurato.

2. Abilitare o disabilitare la funzionalità Gruppi di disponibilità Always On in ogni istanza che farà parte del gruppo di disponibilità. È necessario riavviare ogni istanza di SQL Server.

3. Per ogni istanza che ospita la replica primaria è necessaria una chiave master del database (DMK). Se non esiste già una DMK, eseguire questo comando:

   CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'Strong Password';
   GO
   

4. Nell'istanza che fungerà da replica primaria creare il certificato che verrà usto per le connessioni in ingresso nelle repliche secondarie e per proteggere l'endpoint nella replica primaria.

   CREATE CERTIFICATE InstanceA_Cert
   WITH SUBJECT = 'InstanceA Certificate';
   GO
   

5. Eseguire il backup del certificato. È anche possibile migliorare ulteriormente la protezione con una chiave privata. Questo esempio non fa uso di una chiave privata.

   BACKUP CERTIFICATE InstanceA_Cert
   TO FILE = 'Backup_path\InstanceA_Cert.cer';
   GO
   

6. Ripetere i passaggi 4 e 5 per creare ed eseguire il backup dei certificati per ogni replica secondaria, usando nomi appropriati per i certificati, ad esempio InstanceB_Cert.

7. Nella replica primaria è necessario creare un account di accesso per ogni replica secondaria del gruppo di disponibilità. A questo account di accesso viene concessa l'autorizzazione a connettersi all'endpoint usato dal gruppo di disponibilità indipendente dal dominio. Ad esempio, per una replica denominata InstanceB:

   CREATE LOGIN InstanceB_Login WITH PASSWORD = 'Strong Password';
   GO
   

8. In ogni replica secondaria creare un account di accesso per la replica primaria. A questo account di accesso viene concessa l'autorizzazione a connettersi all'endpoint. Ad esempio, su una replica denominata InstanceB:

   CREATE LOGIN InstanceA_Login WITH PASSWORD = 'Strong Password';
   GO
   

9. In tutte le istanze occorre creare un utente per ogni account di accesso creato. Questo utente verrà usato per il ripristino dei certificati. Ad esempio, per creare un utente per la replica primaria:

   CREATE USER InstanceA_User FOR LOGIN InstanceA_Login;
   GO
   

10. Per qualsiasi replica che potrebbe essere primaria, creare un account di accesso e un utente in tutte le relative repliche secondarie.

11. Ripristinare in ogni istanza i certificati per le altre istanze per cui sono stati creati un account di accesso e un utente. Nella replica primaria ripristinare tutti i certificati delle repliche secondarie. Ripristinare il certificato della replica primaria in ogni replica secondaria e anche in qualsiasi altra replica che potrebbe essere primaria. Ad esempio:

    CREATE CERTIFICATE [InstanceB_Cert]
    AUTHORIZATION InstanceB_User
    FROM FILE = 'Restore_path\InstanceB_Cert.cer';
    

12. Creare l'endpoint che verrà usato dal gruppo di disponibilità in ogni istanza che sarà una replica. Per i gruppi di disponibilità, l'endpoint deve essere di DATABASE_MIRRORING. L'endpoint usa il certificato creato nel passaggio 4 per l'istanza di autenticazione. Di seguito è riportata la sintassi di esempio per creare un endpoint usando un certificato. Usare il metodo di crittografia appropriato e altre opzioni specifiche dell'ambiente. Per altre informazioni sulle opzioni disponibili, vedere CREATE ENDPOINT.

    CREATE ENDPOINT DIAG_EP STATE = STARTED AS TCP (
        LISTENER_PORT = 5022,
        LISTENER_IP = ALL
    )
    FOR DATABASE_MIRRORING (
        AUTHENTICATION = CERTIFICATE InstanceX_Cert, ROLE = ALL
    );
    

13. Per connettersi all'endpoint, è necessario assegnare diritti a tutti gli account di accesso creati nell'istanza nel passaggio 8.

    GRANT CONNECT ON ENDPOINT::DIAG_EP TO [InstanceX_Login];
    GO
    

14. Dopo aver configurato i certificati sottostanti e la sicurezza dell'endpoint, creare il gruppo di disponibilità usando il metodo preferito. È consigliabile eseguire manualmente il backup, copiare e ripristinare il backup usato per inizializzare la replica secondaria oppure usare l’inserimento automatico nel tabellone. L'uso della procedura guidata per inizializzare le repliche secondarie comporta l'uso di file Server Message Block (SMB), che potrebbero non funzionare con un cluster di gruppi di lavoro non aggiunto a un dominio.

15. Se si crea un listener, assicurarsi che il nome e il relativo indirizzo IP siano registrati nel DNS.

Contenuto correlato

• Usare la Creazione guidata Gruppo di disponibilità (SQL Server Management Studio)
• Usare la finestra di dialogo Nuovo gruppo di disponibilità (SQL Server Management Studio)
• Creare un gruppo di disponibilità Always On con Transact-SQL (T-SQL)