Condividi tramite

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

  • Articolo

Si applica a: SQL Server - 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 solo repliche di sola lettura per lo scale-out 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, vedi 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. Linee guida per l'installazione di SQL Server in Linux.

    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. Gli esempi in questo articolo non usano agenti di isolamento. Sono illustrati solo a scopo di test e convalida.

    Un cluster Pacemaker 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:

Considerazioni per più schede di interfaccia di rete

Per informazioni sulla configurazione di un gruppo di disponibilità per i server con più schede di interfaccia di rete, vedi le sezioni pertinenti per:

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.
  • Installa SQL Server.

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à.

  1. Aggiornare il nome del computer per ogni host.

    Ogni nome di istanza di SQL Server deve essere:

    • 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 indirizzi 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. Se si effettua 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 mappa l'indirizzo IP di localhost 127.0.0.1 al 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 mostra /etc/hosts in node1 con l'aggiunta di node1, node2 e node3. In questo esempio node1 indica il server che ospita la replica primaria, mentre node2 e node3 indicano i 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

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

Abilitare i gruppi di disponibilità Always On

Abilitare i gruppi di disponibilità Always On in ogni nodo che ospita un'istanza di SQL Server e riavviare mssql-server. Eseguire lo script seguente:

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 (Extended Events, XE) per diagnosticare più facilmente la causa radice durante la risoluzione dei problemi relativi ai gruppi 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 di eventi estesi, vedere Configurare gli eventi estesi per i gruppi di disponibilità.

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 usata 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 (14.x), l'unico metodo di autenticazione supportato per l'endpoint di mirroring del database è CERTIFICATE. L'opzione WINDOWS non è disponibile.

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 ALTERCONTROL 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, vedi 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.

  • Gruppo di disponibilità: CLUSTER_TYPE = EXTERNAL.

    Specifica 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,

  • Imposta le repliche primarie e secondarie: FAILOVER_MODE = EXTERNAL.

    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 i valori di <node1>, <node2> e <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.

Importante

Nell'implementazione corrente dell'agente di risorse SQL Server, il nome del nodo deve corrispondere alla proprietà ServerName dell'istanza. Ad esempio, se il nome del nodo è node1, assicurarsi che SERVERPROPERTY('ServerName') restituisca node1 nell'istanza di SQL Server. In caso di mancata corrispondenza, le repliche passeranno a uno stato di risoluzione dopo la creazione della risorsa Pacemaker.

Questa regola è importante negli scenari che prevedono l'utilizzo di nomi di dominio completi. Ad esempio, se si usa node1.yourdomain.com come nome del nodo durante l'installazione del cluster, assicurarsi che SERVERPROPERTY('ServerName') restituisca node1.yourdomain.com e non solo node1. Le possibili soluzioni alternative per questo problema sono:

  • Rinominare il nome host con il nome di dominio completo e usare le stored procedure sp_dropserver e sp_addserver per assicurarsi che la modifica si rifletta nei metadati in SQL Server.
  • Usare l'opzione addr nel comando pcs cluster auth per abbinare il nome del nodo al valore SERVERPROPERTY('ServerName') e usare un indirizzo IP statico come indirizzo del nodo.

Eseguire solo uno degli script seguenti:

Creare un gruppo di disponibilità con tre repliche sincrone

Crea 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

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

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, sostituisci <pacemakerLogin> con il nome dell'account utente di Pacemaker. Se non è disponibile un account di accesso per Pacemaker, crea 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à

Verifica che il database che aggiungi 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 (T-SQL) seguente per creare ed eseguire il backup di un database denominato db1:

CREATE DATABASE [db1];
GO

ALTER DATABASE [db1]
SET RECOVERY FULL;
GO

BACKUP DATABASE [db1]
TO DISK = N'/var/opt/mssql/data/db1.bak';

Nella replica primaria di SQL Server eseguire lo script T-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;
GO

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. Per istruzioni, vedi Contenuto correlato.

Osservazioni:

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.

Contenuto correlato