Dela via

Konfigurera SQL Server AlwaysOn-tillgänglighetsgrupp för hög tillgänglighet i Linux

  • Artikel

gäller för:SQL Server – Linux

Den här artikeln beskriver hur du skapar en SQL Server AlwaysOn-tillgänglighetsgrupp (AG) för hög tillgänglighet i Linux. Det finns två konfigurationstyper för AG:er. En hög tillgänglighet konfiguration använder en klusterhanterare för att tillhandahålla affärskontinuitet. Den här konfigurationen kan också inkludera repliker för lässkala. Det här dokumentet förklarar hur du skapar AG med hög tillgänglighet.

Du kan också skapa en tillgänglighetsgrupp utan klusterhanterare för lässkalning. Läsgrupperna för skalning tillhandahåller endast skrivskyddade repliker för utskalning av prestanda. De tillhandahåller inte hög tillgänglighet. Information om hur du skapar en tillgänglighetsgrupp för lässkalning finns i Konfigurera en SQL Server-tillgänglighetsgrupp för lässkalning i Linux.

Konfigurationer som garanterar hög tillgänglighet och dataskydd kräver antingen två eller tre synkrona incheckningsrepliker. Med tre synkrona repliker kan AG automatiskt återställas även om en server inte är tillgänglig. Mer information finns i Hög tillgänglighet och dataskydd för konfigurationer av tillgänglighetsgrupper.

Alla servrar måste vara fysiska eller virtuella och virtuella servrar måste finnas på samma virtualiseringsplattform. Det här kravet beror på att fäktningsagenterna är plattformsspecifika. Se principer för gästkluster.

Översikt

Stegen för att skapa en tillgänglighetsgrupp på Linux-servrar för hög tillgänglighet skiljer sig från stegen i ett Windows Server-redundanskluster. I följande lista beskrivs de övergripande stegen:

  1. Installationsvägledning för SQL Server på Linux.

    Viktig

    Alla tre servrarna i AG (tillgänglighetsgruppen) måste finnas på samma plattform – fysisk eller virtuell – eftersom hög tillgänglighet i Linux använder stängningsagenter för att isolera resurser på servrar. Fäktningsagenterna är specifika för varje plattform.

  2. Skapa AG. Det här steget beskrivs i den här aktuella artikeln.

  3. Konfigurera en klusterresurshanterare, till exempel Pacemaker.

    Hur du konfigurerar en klusterresurshanterare beror på den specifika Linux-distributionen. Se följande länkar för distributionsspecifika instruktioner:

    Viktig

    Produktionsmiljöer kräver en fäktningsagent för hög tillgänglighet. Exemplen i den här artikeln använder inte fäktningsagenter. De är endast till för testning och validering.

    Ett Pacemaker-kluster använder stängsling för att återställa klustret till ett känt tillstånd. Hur du konfigurerar staket beror på distributionen och miljön. Fäktning är för närvarande inte tillgängligt i vissa molnmiljöer. Mer information finns i supportprinciper för RHEL-kluster med hög tillgänglighet – virtualiseringsplattformar.

    För SLES, se SUSE Linux Enterprise High Availability Extension.

  4. Lägg till tillgänglighetsgruppen som en resurs i klustret.

    Hur du lägger till tillgänglighetsgruppen som en resurs i klustret beror på Linux-distributionen. Se följande länkar för distributionsspecifika instruktioner:

Överväganden för flera nätverkskort (NIC)

Information om hur du konfigurerar en tillgänglighetsgrupp för servrar med flera nätverkskort finns i relevanta avsnitt för:

Förutsättningar

Innan du skapar tillgänglighetsgruppen måste du:

  • Ange din miljö så att alla servrar som ska vara värdar för tillgänglighetsrepliker kan kommunicera.
  • Installera SQL Server.

I Linux måste du skapa en tillgänglighetsgrupp innan du lägger till den som en klusterresurs som ska hanteras av klustret. Det här dokumentet innehåller ett exempel som skapar tillgänglighetsgruppen.

  1. Uppdatera datornamnet för varje värd.

    Varje SQL Server-instansnamn måste vara:

    • 15 tecken eller färre.
    • Unikt i nätverket.

    Om du vill ange datornamnet redigerar du /etc/hostname. Med följande skript kan du redigera /etc/hostname med vi:

    sudo vi /etc/hostname

  2. Konfigurera värdfilen.

    Not

    Om värdnamn registreras med deras IP-adress på DNS-servern behöver du inte utföra följande steg. Kontrollera att alla noder som är avsedda att ingå i konfigurationen av tillgänglighetsgruppen kan kommunicera med varandra. (En ping till värdnamnet ska svara med motsvarande IP-adress.) Kontrollera också att filen /etc/hosts inte innehåller en post som mappar localhost-IP-adressen 127.0.0.1 med nodens värdnamn.

    Värdfilen på varje server innehåller IP-adresser och namn på alla servrar som ska delta i tillgänglighetsgruppen.

    Följande kommando returnerar IP-adressen för den aktuella servern:

    sudo ip addr show

    Uppdatera /etc/hosts. Med följande skript kan du redigera /etc/hosts med vi:

    sudo vi /etc/hosts

    I följande exempel visas /etc/hosts på node1 med tillägg för node1, node2och node3. I det här exemplet refererar node1 till den server som är värd för den primära repliken och node2 och node3 referera till servrar som är värdar för de sekundära replikerna.

    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

Installera SQL Server

Installera SQL Server. Följande länkar pekar på installationsanvisningar för SQL Server för olika distributioner:

Aktivera AlwaysOn-tillgänglighetsgrupper

Aktivera AlwaysOn-tillgänglighetsgrupper för varje nod som är värd för en SQL Server-instans och starta sedan om mssql-server. Kör följande skript:

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

Aktivera AlwaysOn_health-händelsesessionen

Du kan också aktivera utökade händelser (XE) för att hjälpa till med rotorsaksdiagnos när du felsöker en tillgänglighetsgrupp. Kör följande kommando på varje instans av SQL Server:

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

Mer information om den här XE-sessionen finns i Konfigurera utökade händelser för tillgänglighetsgrupper.

Skapa ett certifikat

SQL Server-tjänsten i Linux använder certifikat för att autentisera kommunikationen mellan speglingsslutpunkterna.

Följande Transact-SQL skript skapar en huvudnyckel och ett certifikat. Sedan säkerhetskopieras certifikatet och filen skyddas med en privat nyckel. Uppdatera skriptet med starka lösenord. Anslut till den primära SQL Server-instansen. Skapa certifikatet genom att köra följande Transact-SQL skript:

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>'
);

I det här läget har din primära SQL Server-replik ett certifikat på /var/opt/mssql/data/dbm_certificate.cer och en privat nyckel på var/opt/mssql/data/dbm_certificate.pvk. Kopiera dessa två filer till samma plats på alla servrar som ska vara värdar för tillgänglighetsrepliker. Använd mssql-användaren eller ge behörighet till mssql-användaren för att få åtkomst till dessa filer.

På källservern kopierar till exempel följande kommando filerna till måldatorn. Ersätt <node2> värden med namnen på de SQL Server-instanser som ska vara värd för replikerna.

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

Ge mssql-användaren behörighet att komma åt certifikatet på varje målserver.

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

Skapa certifikatet på sekundära servrar

Följande Transact-SQL skript skapar en huvudnyckel och ett certifikat från säkerhetskopian som du skapade på den primära SQL Server-repliken. Uppdatera skriptet med starka lösenord. Dekrypteringslösenordet är samma lösenord som du använde för att skapa filen .pvk i ett tidigare steg. Skapa certifikatet genom att köra följande skript på alla sekundära servrar:

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>'
);

I föregående exempel ersätter du <private-key-password> med samma lösenord som du använde när du skapade certifikatet på den primära repliken.

Skapa databasspeglingsslutpunkter på alla repliker

Databasspeglingsslutpunkter använder TCP (Transmission Control Protocol) för att skicka och ta emot meddelanden mellan de serverinstanser som deltar i databasspeglingssessioner eller repliker för värdtillgänglighet. Databasens speglingsslutpunkt lyssnar på ett unikt TCP-portnummer.

Följande Transact-SQL skript skapar en lyssnande slutpunkt med namnet Hadr_endpoint för tillgänglighetsgruppen. Den startar slutpunkten och ger anslutningsbehörighet till certifikatet som du skapade. Innan du kör skriptet ersätter du värdena mellan < ... >. Du kan också inkludera en IP-adress LISTENER_IP = (0.0.0.0). Lyssnarens IP-adress måste vara en IPv4-adress. Du kan också använda 0.0.0.0.

Uppdatera följande Transact-SQL skript för din miljö på alla SQL Server-instanser:

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;

Observera

Om du använder SQL Server Express Edition på en nod som värd för en replik med endast konfiguration är det enda giltiga värdet för ROLEWITNESS. Kör följande skript i 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;

TCP-porten i brandväggen måste vara öppen för lyssnarporten.

Viktig

För SQL Server 2017 (14.x) är den enda autentiseringsmetod som stöds för databasens speglingsslutpunkt CERTIFICATE. Alternativet WINDOWS är inte tillgängligt.

Mer information finns i SQL Server(Database Mirroring Endpoint).

Skapa AG

Exemplen i det här avsnittet beskriver hur du skapar tillgänglighetsgruppen med Transact-SQL. Du kan också använda guiden för tillgänglighetsgrupper i SQL Server Management Studio. När du skapar en AG med guiden returneras ett fel när du ansluter replikerna till AG:n. Åtgärda detta genom att bevilja ALTER, CONTROLoch VIEW DEFINITIONS till Pacemaker på AG på alla repliker. När behörigheterna har beviljats för den primära repliken ansluter du noderna till tillgänglighetsgruppen via guiden, men för att HA ska fungera korrekt beviljar du behörighet för alla repliker.

För en konfiguration med hög tillgänglighet som säkerställer automatisk redundans kräver tillgänglighetsgruppen minst tre repliker. Någon av följande konfigurationer har stöd för hög tillgänglighet:

Mer information finns i Hög tillgänglighet och dataskydd för konfigurationer av tillgänglighetsgrupper.

Not

Tillgänglighetsgrupperna kan innehålla ytterligare synkrona eller asynkrona repliker.

Skapa tillgänglighetsgruppen för hög tillgänglighet i Linux. Använd CREATE AVAILABILITY GROUP med CLUSTER_TYPE = EXTERNAL.

  • Tillgänglighetsgrupp: CLUSTER_TYPE = EXTERNAL.

    Anger att en extern klusterentitet hanterar tillgänglighetsgruppen. Pacemaker är ett exempel på en extern klusterentitet. När AG-klustertypen är extern,

  • Ange primära och sekundära repliker: FAILOVER_MODE = EXTERNAL.

    Anger att repliken interagerar med en extern klusterhanterare, till exempel Pacemaker.

Följande Transact-SQL skript skapar en hög tillgänglighetsgrupp med namnet ag1. Skriptet konfigurerar AG-replikerna med SEEDING_MODE = AUTOMATIC. Den här inställningen gör att SQL Server automatiskt skapar databasen på varje sekundär server. Uppdatera följande skript för din miljö. Ersätt värdena <node1>, <node2>eller <node3> med namnen på de SQL Server-instanser som är värdar för replikerna. Ersätt <5022> med den port som du har angett för dataspeglingsslutpunkten. Skapa AG (tillgänglighetsgruppen) genom att köra följande Transact-SQL på SQL Server-instansen som är värd för primärreplikan.

Viktig

I den aktuella implementeringen av SQL Server-resursagenten måste nodnamnet matcha egenskapen ServerName från din instans. Om nodnamnet till exempel är node1kontrollerar du att SERVERPROPERTY("ServerName") returnerar node1 i SQL Server-instansen. Om det uppstår en inkonsekvens kommer dina repliker att hamna i ett upplösningstillstånd efter att pacemakerresursen har skapats.

Ett scenario där den här regeln är viktig är när du använder fullständigt kvalificerade domännamn. Om du till exempel använder node1.yourdomain.com som nodnamn under klusterkonfigurationen kontrollerar du att SERVERPROPERTY("ServerName") returnerar node1.yourdomain.comoch inte bara node1. Möjliga lösningar på det här problemet är:

  • Byt namn på värdnamnet till det fullständiga domännamnet och använd procedurerna sp_dropserver och sp_addserver store för att säkerställa att metadata i SQL Server matchar ändringen.
  • Använd alternativet addr i kommandot pcs cluster auth för att matcha nodnamnet med värdet SERVERPROPERTY("ServerName") och använda en statisk IP-adress som nodadress.

Kör bara en av följande skript:

Skapa tillgänglighetsgrupp med tre synkrona repliker

Skapa tillgänglighetsgruppen med tre synkrona repliker:

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;

Viktig

Efter att du har kört föregående skript för att skapa en AG (tillgänglighetsgrupp) med tre synkrona repliker, kör du inte följande skript:

Skapa tillgänglighetsgrupp med två synkrona repliker och en konfigurationsreplik

Skapa AG med två synkrona repliker och en konfigurationsreplik:

Viktig

Med den här arkitekturen kan valfri utgåva av SQL Server vara värd för den tredje repliken. Den tredje repliken kan till exempel finnas på SQL Server Express Edition. I Express Edition är den enda giltiga slutpunktstypen 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;

Skapa tillgänglighetsgrupp med två synkrona repliker

Skapa AG med två synkrona repliker

Inkludera två repliker med synkront tillgänglighetsläge. Följande skript skapar till exempel en AG med namnet ag1. node1 och node2 värdar repliker i synkront läge, med automatisk seeding och automatisk failover.

Viktig

Kör endast följande skript för att skapa en AG med två synkrona repliker. Kör inte följande skript om du körde något av föregående skript.

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;

Du kan också konfigurera en tillgänglighetsgrupp med CLUSTER_TYPE=EXTERNAL med hjälp av SQL Server Management Studio eller PowerShell.

Koppla sekundära repliker till AG

Pacemaker-användaren kräver ALTER, CONTROLoch VIEW DEFINITION behörighet till tillgänglighetsgruppen på alla repliker. Om du vill bevilja behörigheter kör du följande Transact-SQL skript när tillgänglighetsgruppen har skapats på den primära repliken och varje sekundär replik omedelbart efter att de har lagts till i tillgänglighetsgruppen. Innan du kör skriptet ersätter du <pacemakerLogin> med namnet på Pacemaker-användarkontot. Om du inte har någon inloggning för Pacemaker skapa en SQL Server-inloggning för Pacemaker.

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

Följande Transact-SQL-skript kopplar en SQL Server-instans till en tillgänglighetsgrupp (AG) med namnet ag1. Uppdatera skriptet för din miljö. Kör följande Transact-SQL för att ansluta sig till tillgänglighetsgruppen på varje SQL Server-instans som är värd för en sekundär replik.

ALTER AVAILABILITY GROUP [ag1] JOIN WITH (CLUSTER_TYPE = EXTERNAL);

ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;

Lägga till en databas i tillgänglighetsgruppen

Kontrollera att databasen som du lägger till i tillgänglighetsgruppen finns i den fullständiga återställningsmodellen och har en giltig loggsäkerhetskopia. Om databasen är en testdatabas eller en nyligen skapad databas ska du göra en säkerhetskopia av databasen. På den primära SQL Server kör du följande Transact-SQL-skript (T-SQL) för att skapa och säkerhetskopiera en databas med namnet db1:

CREATE DATABASE [db1];
GO

ALTER DATABASE [db1]
    SET RECOVERY FULL;
GO

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

På den primära SQL Server-repliken kör du följande T-SQL-skript för att lägga till en databas med namnet db1 i en tillgänglighetsgrupp med namnet ag1:

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

Kontrollera att databasen har skapats på de sekundära servrarna

På varje sekundär SQL Server-replik kör du följande fråga för att se om db1-databasen skapades och synkroniseras:

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

Viktig

När du har skapat tillgänglighetsgruppen måste du ställa in integration med en klusterteknik som Pacemaker för att säkerställa hög tillgänglighet. Från och med SQL Server 2017 (14.x), behöver du inte konfigurera ett kluster för en lässkalningskonfiguration med hjälp av AG:er.

Om du har följt stegen i det här dokumentet har du en AG som ännu inte är klustrad. Nästa steg är att lägga till klustret. Den här konfigurationen är giltig för scenarier med lässkalning/belastningsutjämning. Den är inte fullständig för hög tillgänglighet. För hög tillgänglighet måste du lägga till AG som en klusterresurs. Se relaterat innehåll för instruktioner.

Anmärkningar

Viktig

När du har konfigurerat klustret och lagt till tillgänglighetsgruppen som en klusterresurs kan du inte använda Transact-SQL för att redundansväxla tillgänglighetsgruppens resurser. SQL Server-klusterresurser i Linux är inte lika nära kopplade till operativsystemet som i ett Windows Server-redundanskluster (WSFC). SQL Server-tjänsten känner inte till förekomsten av klustret. All orkestrering sker via klusterhanteringsverktygen. I RHEL eller Ubuntu använder du pcs. I SLES använder du crm.

Viktig

Om tillgänglighetsgruppen är en klusterresurs finns det ett känt problem i den aktuella versionen där tvingad redundansväxling med dataförlust till en asynkron replik inte fungerar. Detta kommer att åtgärdas i den kommande versionen. Manuell eller automatisk redundansväxling till en synkron replik lyckas.

Relaterat innehåll