Configurare un gruppo di disponibilità Always On di SQL Server per la disponibilità elevata in Linux

Si applica a: sìSQL Server (tutte le versioni supportate) - Linux

Questo articolo illustra come creare un gruppo di disponibilità Always On di SQL Server per la disponibilità elevata in Linux. Per i gruppi di disponibilità esistono due tipi di configurazione. Una configurazione per la disponibilità elevata usa un modulo di gestione cluster per garantire la continuità operativa. Questa configurazione può includere anche le repliche con scalabilità in lettura. Questo documento illustra come creare il gruppo di disponibilità per la disponibilità elevata.

È anche possibile creare un gruppo di disponibilità senza un modulo di gestione cluster per la scalabilità in lettura. Il gruppo di disponibilità per la scalabilità in lettura fornisce repliche di sola lettura per la scalabilità orizzontale delle prestazioni. Non offre disponibilità elevata. Per creare un gruppo di disponibilità per la scalabilità in lettura, vedere Configurare un gruppo di disponibilità di SQL Server con scalabilità in lettura per Linux.

Le configurazioni che garantiscono disponibilità elevata e protezione dei dati richiedono due o tre repliche con commit sincrono. Con tre repliche sincrone, il gruppo di disponibilità può essere ripristinato automaticamente anche se un server non è disponibile. Per altre informazioni, vedere Disponibilità elevata e protezione dei dati per le configurazioni del gruppo di disponibilità.

Tutti i server devono essere fisici o virtuali e i server virtuali devono trovarsi nella stessa piattaforma di virtualizzazione. Questo requisito è determinato dal fatto che gli agenti di isolamento sono specifici della piattaforma. Vedere Policies for Guest Clusters (Criteri per i cluster guest).

Roadmap

I passaggi da seguire per creare un gruppo di disponibilità sui server Linux per la disponibilità elevata sono diversi da quelli relativi a un cluster di failover di Windows Server. Nell'elenco seguente sono descritti i passaggi principali:

  1. Configurare SQL Server nei tre server del cluster.

    Importante

    Tutti e tre i server del gruppo di disponibilità devono trovarsi nella stessa piattaforma, fisica o virtuale, perché la disponibilità elevata di Linux usa gli agenti di isolamento per isolare le risorse nei server. Gli agenti di isolamento sono specifici per ogni piattaforma.

  2. Creare il gruppo di disponibilità. Questo passaggio è illustrato in questo articolo.

  3. Configurare un modulo per la gestione di risorse cluster, ad esempio Pacemaker.

    La modalità di configurazione di un modulo per la gestione di risorse cluster dipende dalla specifica distribuzione Linux. Per istruzioni specifiche per le singole distribuzioni, vedere i collegamenti seguenti:

    Importante

    Per la disponibilità elevata, negli ambienti di produzione è necessario un agente di isolamento, ad esempio STONITH. Nelle dimostrazioni di questa documentazione non vengono usati agenti di isolamento. Le dimostrazioni sono riportate solo a scopo di test e convalida.

    Un cluster Linux usa l'isolamento per ripristinare uno stato noto del cluster. La modalità di configurazione dell'isolamento dipende dalla distribuzione e dall'ambiente. Attualmente l'isolamento non è disponibile in alcuni ambienti cloud. Per altre informazioni, vedere Support Policies for RHEL High Availability Clusters - Virtualization Platforms (Criteri di supporto per il cluster RHEL a disponibilità elevata - Piattaforme di virtualizzazione).

    Per SLES, vedere SUSE Linux Enterprise High Availability Extension.

  4. Aggiungere il gruppo di disponibilità come risorsa nel cluster.

    La procedura per aggiungere il gruppo di disponibilità come risorsa nel cluster dipende dalla distribuzione Linux. Per istruzioni specifiche per le singole distribuzioni, vedere i collegamenti seguenti:

Prerequisiti

Prima di creare il gruppo di disponibilità, è necessario:

  • Impostare l'ambiente in modo che tutti i server che ospitano le repliche di disponibilità possano comunicare.
  • Installare SQL Server.

Nota

In Linux è necessario creare un gruppo di disponibilità prima di aggiungerlo come risorsa cluster, da gestire con il cluster. Questo documento propone un esempio di creazione del gruppo di disponibilità. Per istruzioni specifiche della distribuzione per creare il cluster e aggiungere il gruppo di disponibilità come risorsa cluster, vedere i collegamenti nella sezione Passaggi successivi.

  1. Aggiornare il nome del computer per ogni host.

    Ogni nome di SQL Server deve:

    • Essere composto da 15 caratteri o meno.
    • Essere univoco all'interno della rete.

    Per impostare il nome del computer, modificare /etc/hostname. Lo script seguente consente di modificare /etc/hostname con vi:

    sudo vi /etc/hostname
    
  2. Configurare il file hosts.

    Nota

    Se i nomi host sono registrati con i relativi IP nel server DNS, non è necessario eseguire i passaggi seguenti. Verificare che tutti i nodi che faranno parte della configurazione del gruppo di disponibilità possano comunicare tra loro. Eseguendo il ping del nome host si dovrebbe ottenere come risposta l'indirizzo IP corrispondente. Assicurarsi anche che il file /etc/hosts non contenga un record che esegue il mapping dell'indirizzo IP di localhost 127.0.0.1 con il nome host del nodo.

    Il file hosts in ogni server contiene gli indirizzi IP e i nomi di tutti i server che faranno parte del gruppo di disponibilità.

    Il comando seguente restituisce l'indirizzo IP del server corrente:

    sudo ip addr show
    

    Aggiornare /etc/hosts. Lo script seguente consente di modificare /etc/hosts con vi:

    sudo vi /etc/hosts
    

    L'esempio seguente illustra /etc/hosts su node1 con aggiunte per node1, node2 e node3. In questo documento node1 si riferisce al server che ospita la replica primaria. node2 e node3 si riferiscono ai server che ospitano le repliche secondarie.

    127.0.0.1   localhost localhost4 localhost4.localdomain4
    ::1       localhost localhost6 localhost6.localdomain6
    10.128.18.12 node1
    10.128.16.77 node2
    10.128.15.33 node3
    

Installare SQL Server

Installare SQL Server. I collegamenti seguenti rimandano alle istruzioni di installazione di SQL Server per varie distribuzioni:

Abilitare la funzionalità Gruppi di disponibilità Always On e riavviare mssql-server

Abilitare i gruppi di disponibilità AlwaysOn in ogni nodo che ospita un'istanza di SQL Server. Riavviare quindi mssql-server. Eseguire lo script riportato di seguito:

sudo /opt/mssql/bin/mssql-conf set hadr.hadrenabled  1
sudo systemctl restart mssql-server

Abilitare una sessione eventi AlwaysOn_health

Facoltativamente, è possibile abilitare gli eventi estesi dei gruppi di disponibilità AlwaysOn per diagnosticare più facilmente la causa radice durante la risoluzione dei problemi che interessano un gruppo di disponibilità. Eseguire il comando seguente in ogni istanza di SQL Server:

ALTER EVENT SESSION  AlwaysOn_health ON SERVER WITH (STARTUP_STATE=ON);
GO

Per altre informazioni su questa sessione XE, vedere Eventi estesi di Always On.

Creare un certificato

Il servizio SQL Server in Linux usa i certificati per autenticare la comunicazione tra gli endpoint del mirroring.

Lo script Transact-SQL seguente crea una chiave master e un certificato. Quindi esegue il backup del certificato e protegge il file con una chiave privata. Aggiornare lo script con password complesse. Stabilire la connessione all'istanza primaria di SQL Server. Per creare il certificato, eseguire lo script Transact-SQL seguente:

CREATE MASTER KEY ENCRYPTION BY PASSWORD = '**<Master_Key_Password>**';
CREATE CERTIFICATE dbm_certificate WITH SUBJECT = 'dbm';
BACKUP CERTIFICATE dbm_certificate
   TO FILE = '/var/opt/mssql/data/dbm_certificate.cer'
   WITH PRIVATE KEY (
           FILE = '/var/opt/mssql/data/dbm_certificate.pvk',
           ENCRYPTION BY PASSWORD = '**<Private_Key_Password>**'
       );

A questo punto la replica di SQL Server primaria dispone di un certificato in /var/opt/mssql/data/dbm_certificate.cer e di una chiave privata in var/opt/mssql/data/dbm_certificate.pvk. Copiare questi due file nello stesso percorso in tutti i server che ospiteranno le repliche di disponibilità. Usare l'utente mssql o concedere l'autorizzazione all'utente mssql per questi file.

Nel server di origine, ad esempio, il comando seguente copia i file nel computer di destinazione. Sostituire i valori **<node2>** con i nomi delle istanze di SQL Server che ospiteranno le repliche.

cd /var/opt/mssql/data
scp dbm_certificate.* root@**<node2>**:/var/opt/mssql/data/

In ogni server di destinazione assegnare all'utente mssql l'autorizzazione per accedere al certificato.

cd /var/opt/mssql/data
chown mssql:mssql dbm_certificate.*

Creare il certificato nei server secondari

Lo script Transact-SQL seguente crea una chiave master e un certificato dal backup creato nella replica primaria di SQL Server. Aggiornare lo script con password complesse. La password di decrittografia è la stessa password utilizzata per creare il file .pvk in un passaggio precedente. Per creare il certificato, eseguire lo script seguente in tutti i server secondari:

CREATE MASTER KEY ENCRYPTION BY PASSWORD = '**<Master_Key_Password>**';
CREATE CERTIFICATE dbm_certificate
    FROM FILE = '/var/opt/mssql/data/dbm_certificate.cer'
    WITH PRIVATE KEY (
    FILE = '/var/opt/mssql/data/dbm_certificate.pvk',
    DECRYPTION BY PASSWORD = '**<Private_Key_Password>**'
            );

Creare endpoint di mirroring del database in tutte le repliche

Gli endpoint del mirroring del database usano il protocollo TCP (Transmission Control Protocol) per inviare e ricevere messaggi tra istanze del server che partecipano a sessioni di mirroring del database o ospitano repliche di disponibilità. L'endpoint del mirroring del database è in attesa su un numero di porta TCP univoco.

Lo script Transact-SQL seguente crea un endpoint di ascolto denominato Hadr_endpoint per il gruppo di disponibilità. Avvia l'endpoint e assegna l'autorizzazione di connessione al certificato creato. Prima di eseguire lo script, sostituire i valori compresi tra **< ... >**. Facoltativamente è possibile includere un indirizzo IP LISTENER_IP = (0.0.0.0). L'indirizzo IP del listener deve essere un indirizzo IPv4. È anche possibile usare 0.0.0.0.

Aggiornare lo script Transact-SQL seguente per il proprio ambiente in tutte le istanze di SQL Server:

CREATE ENDPOINT [Hadr_endpoint]
    AS TCP (LISTENER_PORT = **<5022>**)
    FOR DATABASE_MIRRORING (
        ROLE = ALL,
        AUTHENTICATION = CERTIFICATE dbm_certificate,
        ENCRYPTION = REQUIRED ALGORITHM AES
        );
ALTER ENDPOINT [Hadr_endpoint] STATE = STARTED;

Nota

Se si usa SQL Server Express Edition in un nodo per ospitare una replica di sola configurazione, l'unico valore valido per ROLE è WITNESS. Eseguire lo script seguente in SQL Server Express Edition:

CREATE ENDPOINT [Hadr_endpoint]
    AS TCP (LISTENER_PORT = **<5022>**)
    FOR DATABASE_MIRRORING (
        ROLE = WITNESS,
        AUTHENTICATION = CERTIFICATE dbm_certificate,
        ENCRYPTION = REQUIRED ALGORITHM AES
        );
ALTER ENDPOINT [Hadr_endpoint] STATE = STARTED;

La porta TCP sul firewall deve essere aperta per la porta del listener.

Importante

In SQL Server 2017, l'unico metodo di autenticazione supportato per l'endpoint di mirroring del database è CERTIFICATE. L'opzione WINDOWS verrà abilitata in una versione futura.

Per altre informazioni, vedere Endpoint del mirroring del database (SQL Server).

Creare il gruppo di disponibilità

Gli esempi riportati in questa sezione illustrano come creare il gruppo di disponibilità con Transact-SQL. È anche possibile usare la Creazione guidata Gruppo di disponibilità di SQL Server Management Studio. Quando si crea un gruppo di disponibilità con la procedura guidata e si aggiungono le repliche al gruppo di disponibilità, viene restituito un errore. Per risolvere questo problema, concedere le autorizzazioni ALTER``CONTROL e VIEW DEFINITIONS a Pacemaker sul gruppo di disponibilità in tutte le repliche. Una volta concesse le autorizzazioni nella replica primaria, aggiungere i nodi al gruppo di disponibilità tramite la procedura guidata, ma per il corretto funzionamento della disponibilità elevata, concedere le autorizzazioni su tutte le repliche.

Per una configurazione a disponibilità elevata che garantisca il failover automatico, il gruppo di disponibilità richiede almeno tre repliche. Per il supporto della disponibilità elevata è necessaria una delle configurazioni seguenti:

Per informazioni, vedere Disponibilità elevata e protezione dei dati per le configurazioni del gruppo di disponibilità.

Nota

I gruppi di disponibilità possono includere repliche aggiuntive, sincrone o asincrone.

Creare il gruppo di disponibilità per la disponibilità elevata in Linux. Usare CREATE AVAILABILITY GROUP con CLUSTER_TYPE = EXTERNAL.

  • Impostare CLUSTER_TYPE = EXTERNAL per specificare che il gruppo di disponibilità viene gestito da un'entità cluster esterna. Un esempio di entità cluster esterna è costituito da Pacemaker. Quando il tipo di cluster del gruppo di disponibilità è esterno,

  • Impostare FAILOVER_MODE = EXTERNAL per le repliche primarie e secondarie. In questo modo, la replica interagisce con un modulo di gestione cluster esterno, ad esempio Pacemaker.

Gli script Transact-SQL seguenti creano un gruppo di disponibilità per la disponibilità elevata denominato ag1. Lo script configura le repliche del gruppo di disponibilità con SEEDING_MODE = AUTOMATIC. In base a questa impostazione, SQL Server crea automaticamente il database in ogni server secondario. Aggiornare lo script seguente per il proprio ambiente. Sostituire il valori di <node1>, <node2> o <node3> con i nomi delle istanze di SQL Server che ospitano le repliche. Sostituire <5022> con il numero della porta impostata per l'endpoint del mirroring dei dati. Per creare il gruppo di disponibilità, eseguire gli script Transact-SQL seguenti nell'istanza di SQL Server che ospita la replica primaria.

Eseguire solo uno degli script seguenti:

  • Creare un gruppo di disponibilità con tre repliche sincrone

    CREATE AVAILABILITY GROUP [ag1]
         WITH (DB_FAILOVER = ON, CLUSTER_TYPE = EXTERNAL)
         FOR REPLICA ON
             N'<node1>' 
              WITH (
                 ENDPOINT_URL = N'tcp://<node1>:<5022>',
                 AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
                 FAILOVER_MODE = EXTERNAL,
                 SEEDING_MODE = AUTOMATIC
                 ),
             N'<node2>' 
              WITH ( 
                 ENDPOINT_URL = N'tcp://<node2>:<5022>', 
                 AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
                 FAILOVER_MODE = EXTERNAL,
                 SEEDING_MODE = AUTOMATIC
                 ),
             N'<node3>'
             WITH( 
                ENDPOINT_URL = N'tcp://<node3>:<5022>', 
                AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
                FAILOVER_MODE = EXTERNAL,
                SEEDING_MODE = AUTOMATIC
                );
    
    ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;
    

    Importante

    Dopo aver eseguito lo script precedente per creare un gruppo di disponibilità con tre repliche sincrone, non eseguire lo script seguente:

  • Creare un gruppo di disponibilità con due repliche sincrone e una replica di configurazione:

    Importante

    Questa architettura consente a qualsiasi edizione di SQL Server di ospitare la terza replica. La terza replica, ad esempio, può essere ospitata in SQL Server Express Edition. In Express Edition l'unico tipo di endpoint valido è WITNESS.

    CREATE AVAILABILITY GROUP [ag1] 
        WITH (CLUSTER_TYPE = EXTERNAL) 
        FOR REPLICA ON 
         N'<node1>' WITH ( 
            ENDPOINT_URL = N'tcp://<node1>:<5022>', 
            AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, 
            FAILOVER_MODE = EXTERNAL, 
            SEEDING_MODE = AUTOMATIC 
            ), 
         N'<node2>' WITH (  
            ENDPOINT_URL = N'tcp://<node2>:<5022>',  
            AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, 
            FAILOVER_MODE = EXTERNAL, 
            SEEDING_MODE = AUTOMATIC 
            ), 
         N'<node3>' WITH ( 
            ENDPOINT_URL = N'tcp://<node3>:<5022>', 
            AVAILABILITY_MODE = CONFIGURATION_ONLY  
            );
    ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;
    

  • Creare un gruppo di disponibilità con due repliche sincrone

    Includere due repliche con modalità di disponibilità sincrona. Ad esempio, lo script seguente crea un gruppo di disponibilità denominato ag1. node1 e node2 ospitano le repliche in modalità sincrona con seeding e failover automatici.

    Importante

    Per creare un gruppo di disponibilità con due repliche sincrone eseguire solo lo script seguente. Non eseguire lo script seguente se è stato eseguito uno degli script precedenti.

    CREATE AVAILABILITY GROUP [ag1]
        WITH (CLUSTER_TYPE = EXTERNAL)
        FOR REPLICA ON
        N'node1' WITH (
           ENDPOINT_URL = N'tcp://node1:5022',
           AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
           FAILOVER_MODE = EXTERNAL,
           SEEDING_MODE = AUTOMATIC
        ),
        N'node2' WITH ( 
           ENDPOINT_URL = N'tcp://node2:5022', 
           AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
           FAILOVER_MODE = EXTERNAL,
           SEEDING_MODE = AUTOMATIC
        );
    
    ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;
    

È anche possibile configurare un gruppo di disponibilità con CLUSTER_TYPE=EXTERNAL usando SQL Server Management Studio o PowerShell.

Aggiungere le repliche secondarie al gruppo di disponibilità

L'utente di Pacemaker richiede le autorizzazioni ALTER, CONTROL e VIEW DEFINITION sul gruppo di disponibilità in tutte le repliche. Per concedere le autorizzazioni, eseguire lo script Transact-SQL seguente dopo che il gruppo di disponibilità è stato creato nella replica primaria e in ogni replica secondaria immediatamente dopo l'aggiunta al gruppo di disponibilità. Prima di eseguire lo script, sostituire <pacemakerLogin> con il nome dell'account utente di Pacemaker. Se non è disponibile un account di accesso per Pacemaker, creare un account di accesso di SQL Server per Pacemaker.

GRANT ALTER, CONTROL, VIEW DEFINITION ON AVAILABILITY GROUP::ag1 TO <pacemakerLogin>
GRANT VIEW SERVER STATE TO <pacemakerLogin>

Lo script Transact-SQL seguente aggiunge un'istanza di SQL Server a un gruppo di disponibilità denominato ag1. Aggiornare lo script per il proprio ambiente. In ogni istanza di SQL Server che ospita una replica secondaria eseguire lo script Transact-SQL seguente per aggiungerla al gruppo di disponibilità.

ALTER AVAILABILITY GROUP [ag1] JOIN WITH (CLUSTER_TYPE = EXTERNAL);
         
ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;

Aggiungere un database al gruppo di disponibilità

Verificare che il database che si aggiunge al gruppo di disponibilità sia in modalità di ripristino completa e disponga di un backup del log valido. Se si tratta di un database di prova o di un database appena creato, eseguire un backup del database. Nell'istanza primaria di SQL Server eseguire lo script Transact-SQL seguente per creare ed eseguire il backup di un database denominato db1:

CREATE DATABASE [db1];
ALTER DATABASE [db1] SET RECOVERY FULL;
BACKUP DATABASE [db1] 
   TO DISK = N'/var/opt/mssql/data/db1.bak';

Nella replica primaria di SQL Server eseguire lo script Transact-SQL seguente per aggiungere un database denominato db1 a un gruppo di disponibilità denominato ag1:

ALTER AVAILABILITY GROUP [ag1] ADD DATABASE [db1];

Verificare che il database sia creato nei server secondari

In ogni replica secondaria di SQL Server eseguire la query seguente per verificare che il database db1 sia stato creato e sia sincronizzato:

SELECT * FROM sys.databases WHERE name = 'db1';
GO
SELECT DB_NAME(database_id) AS 'database', synchronization_state_desc FROM sys.dm_hadr_database_replica_states;

Importante

Dopo aver creato il gruppo di disponibilità, è necessario configurare l'integrazione con uno strumento per la gestione di cluster come Pacemaker per la disponibilità elevata. Per una configurazione di scalabilità in lettura con gruppi di disponibilità, a partire da SQL Server 2017 (14.x), non è necessario configurare un cluster.

Se si è seguita la procedura descritta in questo documento, si ha un gruppo di disponibilità non ancora configurato in cluster. Il passaggio successivo consiste nell'aggiungere il cluster. Questa configurazione è valida per gli scenari di scalabilità in lettura/bilanciamento del carico, ma non è completa per la disponibilità elevata. Per ottenere la disponibilità elevata, è necessario aggiungere il gruppo di disponibilità come risorsa cluster. Vedere Passaggi successivi per le istruzioni.

Note

Importante

Dopo aver configurato il cluster e aggiunto il gruppo di disponibilità come risorsa cluster, non è possibile usare Transact-SQL per eseguire il failover delle risorse del gruppo di disponibilità. Le risorse cluster di SQL Server in Linux non sono strettamente associate al sistema operativo come in un cluster WSFC (Windows Server Failover Cluster). Il servizio SQL Server non è a conoscenza della presenza del cluster. Tutta l'orchestrazione viene eseguita tramite gli strumenti per la gestione di cluster. In RHEL o Ubuntu usare pcs. In SLES usare crm.

Importante

Se il gruppo di disponibilità è una risorsa cluster, nella versione corrente è stato rilevato un problema per cui il failover forzato con perdita di dati in una replica asincrona non funziona. Il problema verrà risolto nella prossima versione. Il failover manuale o automatico in una replica sincrona viene eseguito correttamente.

Passaggi successivi

Configurare un cluster Red Hat Enterprise Linux per le risorse cluster di un gruppo di disponibilità di SQL Server

Configurare un cluster SUSE Linux Enterprise Server per le risorse cluster di un gruppo di disponibilità di SQL Server

Configurare un cluster Ubuntu per le risorse cluster di un gruppo di disponibilità di SQL Server