sql >> Databasteknik >  >> RDS >> Sqlserver

Konfigurera AlwaysOn Availability Groups på SQL Server

INTRODUKTION

Det här dokumentet beskriver stegen och ytterligare information som krävs för att konfigurera AlwaysOn Availability Groups för HA och DR på MS SQL Server. AlwaysOn Availability Groups är en HA-DR-lösning introducerad i SQL Server 2012, designad som en kombination av transaktionsloggfrakt och databasspegling.

AlwaysOn AG implementerar HA på databasnivå, även om noderna som är värd för SQL-instanser och deltar i konfigurationen är en del av ett Windows Failover-kluster. Vi hänvisar till varje nod som en tillgänglighetsreplik.

I en typisk konfiguration finns det en primär replika och en eller flera skrivskyddade sekundära repliker. En grupp databaser konfigurerade i en Tillgänglighetsgrupp kan misslyckas över till en alternativ replik tillsammans.

FÖRSKRIFTER

1.1 Förutsättningar

1.1.1 Två eller fler Windows 2012 eller senare servrar (Enterprise Edition) med de senaste patcharna
1.1.2 Servicekonton för SQL Server-instanser
1.1.3 En filresurs på en annan betrodd server än servrarna som deltar i klustret
1.1.4 SQL 2012 eller högre installationsmedium tillsammans med Service Packs
1.1.5 Två extra IP-adresser förutom de offentliga IP-adresserna för de deltagande servrarna
1.1.6 En DBA, en Windows AD-administratör, en nätverksadministratör

SAMMANFATTNING

1.2 Konfigurationsproceduren innefattar följande steg:

1.2.1 Aktivera klustring på alla noder
1.2.2 Validera noderna för klustring
1.2.3 Skapa ett kluster
1.2.4 Konfigurera kvorum
1.2.5 Installera SQL Server på alla noder
1.2.6 Aktivera AlwaysOn-tillgänglighetsgrupper på alla instanser
1.2.7 Skapa en tillgänglighetsgrupp
1.2.8 Lägg till en AG-lyssnare

PROCEDUR

1.3 Aktivera klustring på alla noder

1.3.1 Öppna Serverhanteraren på Windows

1.3.2 Starta Lägg till roller och funktioner Wizard

Windows Failover Clustering är en Windows-funktion. Du kan aktivera det via guiden.

1.3.3 Acceptera standardinställningarna tills du når funktionsstadiet.

I detta skede måste vi välja en server att konfigurera. I det här scenariot har vi att göra med den lokala servern (se figur 4).

Vi har gömt servernamnen av säkerhetsskäl, men du kommer att se det i den nedre rutan (Figur 4).

För närvarande planerar vi inte att konfigurera en roll. Så vi klickar på NÄSTA och följer tills vi kommer till Funktioner (Figur 6).

Aktivera kryssrutan för Failover Clustering. Klicka sedan på INSTALLERA.

1.3.4 Välj Failover Clustering i Funktionsstadiet

1.3.5 Stäng guiden när den är klar

1.4 Validera servrarna för klustring

Vi har aktiverat klustring genom att följa stegen i föregående avsnitt. Vi måste upprepa dessa steg för varje server som ska delta i failover-klustret.

Windows stöder för närvarande upp till 64 noder i ett failover-kluster. Windows 2019 förbättrar användbarheten av detta stora antal genom att tillhandahålla en funktion som kallas klusteruppsättningar. Att validera potentiella medlemsservrar i ett kluster innebär att kontrollera om de alla har konfigurerats på lämpligt sätt för att delta i klustret.

1.4.1 Öppna Failover Cluster Manager

1.4.2 Öppna Validera konfiguration Wizard till höger.

1.4.3 På Välj servrar steg, ange alla servrar avsedda för klustret. Återigen har vi gömt utvalda servrar.

Vi kan lägga till alla deltagande servrar från den här skärmen.

1.4.4 Acceptera standardalternativet "Kör alla tester".

1.4.5 Ignorera de diskrelaterade varningarna. Du behöver inte delade diskar för AlwaysOn-konfiguration.

1.4.6 Slutför guiden

Vid det här laget kan du granska valideringsrapporten. Om det skulle uppstå några problem kan du rätta till dem innan du fortsätter. Vissa varningar kan ignoreras, men se till att undersöka deras innebörd.

1.5 Skapa ett kluster

1.5.1 På Failover Cluster Manager, starta Skapa kluster Wizard.

1.5.2 Lägg till alla servrar avsedda för klustring.

Den här skärmen är som Validera en konfiguration Skärm . Vi kan också lägga till alla nödvändiga noder på en gång.

För att lägga till servrar, klicka på Bläddra knappen.

1.5.3 Ange önskat klusternamn och en associerad IP-adress

Detta namn fungerar för att skapa ett Computer Name Object på domänen. Därför behöver du behörighet för att skapa datorobjekt för kontot som utför installationen. Observera också att alla IP-adresser som används för alla medlemmar i klustret måste finnas i samma undernät, förutom om du skapar ett kluster med flera platser.

När vi skapar ett failover-kluster för AlwaysOn-tillgänglighetsgrupper behöver vi inte lägga till diskar i klustret. Så lämna alternativet omarkerat (se figur 19).

1.5.4 Slutför Skapa kluster Wizard

1.6 Konfigurera kvorum

Quorum anger antalet klustermedlemmar som måste vara online för att ange vilket kluster som är tillgängligt. Microsoft tillåter olika kvorumalternativ. Vissa av dem låter diskarna eller filresurserna vara klustermedlemmar.

Vanligtvis bör det vara ett udda antal medlemmar. Vissa konfigurationer tillåter oss dock att använda ett jämnt tal och ta bort rösträtter från en nod. Ett vittne är ett icke-serverobjekt som du kan använda för att göra upp det udda antalet väljare. Ett fildelningsvittne får företräde i AlwaysOn-konfigurationen eftersom det inte finns någon delad disk i en AlwaysOn-konfiguration.

1.6.1 Skapa en resurs på en pålitlig server som inte deltar i klustret. Ge sedan fullständiga behörigheter till Computer Name Object bär samma namn som ditt kluster (steg 4.3.3).

1.6.2 Högerklicka på klustret du just har skapat och välj Fler åtgärder> Konfigurera klusterkvoruminställningar.

1.6.3 Välj alternativet för att konfigurera ett kvorumvittne

1.6.4 Välj alternativet för att konfigurera ett fildelningsvittne

1.6.5 Välj fildelning (se 4.4.1):

1.6.6 Slutför Witness-konfigurationen

1.7 Installera SQL Server

Installera enstaka instanser av SQL Server på alla servrar som deltar i klustret. Det är möjligt att slutföra denna konfiguration framgångsrikt, även om den tidigare SQL Server-konfigurationen ägde rum innan klustret skapades.

Observera att SQL Server-instanserna inte är klustrade i en AlwaysOn-konfiguration. Du konfigurerar och hanterar HA på databasnivå för databasgrupperna. Se den relevanta dokumentationen för installation av SQL Server.

1.8 Aktivera AlwaysOn-tillgänglighetsgrupper

1.8.1 Öppna SQL Server Configuration Manager på varje nod

1.8.2 Högerklicka på SQL Server-tjänsten. Öppna fliken AlwaysOn High Availability.

1.8.3 Välj Aktivera AlwaysOn-tillgänglighetsgrupper kryssrutan

Observera att du redan i det skedet får identifiering av det tidigare konfigurerade klustret. På så sätt förstärker du ordningen på stegen. Du måste aktivera klustring på varje klusternod innan du aktiverar AlwaysOn på varje SQL Server-instans.

1.8.4 Starta om SQL Server Service

1.9 Skapa en ny tillgänglighetsgrupp

1.9.1 Öppna SQL Server Management Studio

1.9.2 Högerklicka på AlwaysOn High Availability> Tillgänglighetsgrupper och välj New Availability Group Wizard .

1.9.3 Följ guiden

1.9.4 Ange namnet på tillgänglighetsgruppen. Detta namn kommer att användas för att skapa en klusterroll.

Tillgänglighetsgruppens namn är också ett virtuellt namnobjekt med en post i Microsoft Active Directory. Alltså, innan detta fungerar, används datornamnsobjektet som klusternamn måste ha behörighet att (1) Skapa datorobjekt och (2) Läs alla egenskaperActive Directory .

1.9.5 Välj de databaser som du vill ingå i denna tillgänglighetsgrupp. Det kan finnas flera tillgänglighetsgrupper i en uppsättning instanser. De involverade databaserna måste konfigureras med Full Recovery Model , och du måste ta en säkerhetskopia. Guiden söker efter dessa förutsättningar.

1.9.6 Välj de instanser som ska fungera som sekundära repliker

Bestäm om du behöver synkron eller asynkron replikering och automatisk eller manuell failover. Detaljer om dessa vals konsekvenser finns i Microsoft-dokumentationen som definieras i slutet av detta dokument.

Normalt är Synchronous-Commit Mode med Automatic Failover för lokal motståndskraft, och Asynchronous-Commit Mode är för att använda AlwaysOn som en DR-lösning på grund av latensproblem.

1.9.7 Skapa en filresurs för den första säkerhetskopieringen

Denna filresurs används för att initiera replikeringen. SQL Server-tjänstkontot bör ha fullständiga behörigheter för denna filresurs. Det tas för givet att SQL Server-instanserna som deltar i denna konfiguration använder samma domänkonto som SQL Server-tjänstkontot.

1.9.8 Välj resursen som skapades i steg 4.7.9 som den första platsen för säkerhetskopiering av databasen.

1.9.9 Granska valideringsstadiet. Observera att lyssnaren inte har skapats. Du kan göra det senare.

1.9.10 Granska sammanfattningen av alternativ och slutför konfigurationen

1.10 Lägg till en AG-lyssnare

En Availability Group Listener låter applikationer ansluta till den primära, oavsett vilken nod som för närvarande spelar denna roll. Det hjälper till att göra failovers transparenta för applikationer.

1.10.1 Högerklicka på AlwayOn High Availability> Availability Group Listener och välj Lägg till lyssnare .

En Availability Group Listener är också ett virtuellt namnobjekt (VNO) som du skapar på domänen. Därför kräver den en associerad IP-adress.

Som nämnts tidigare måste det klusternamnsobjekt (CNO) som anges när klustret skapades ha två behörigheter på Active Directory-domänen för att detta ska fungera:

i. Skapa datorobjekt
ii. Läs alla egenskaper

1.10.2 Konfigurationen är klar. Du kan se instrumentpanelen:

1.11 Uppstår problem

Klusterlagring

Under den första körningen av klusterskapandet läggs alla diskar på klusternoderna till i klustret. Det är inte det önskade tillståndet för AlwaysOn Availability Groups.

Lösningen var att förstöra klustret följt av rensning och återskapa det med kryssrutan Lägg till all kvalificerad lagring i klustret rensas i steg 4.3.3.

Det var omöjligt att återskapa klustret förrän du rensat noderna med Clear-ClusterNode PowerShell Commandlet.

Automatisk failover

Att testa Automatic Failover genom att stoppa SQL Server Service från SQL Server Configuration Manager fungerade inte. PowerShell Commandlet Get-ClusterLog genererade klusterloggen -Node -TimeSpan 10, och det identifierade följande fel:

000007f4.00002320::2016/07/07-06:10:59.654 VARNA [RCM] Misslyckas inte över gruppen EPG-SERVER-AG, failoverCount 25, failoverThresholdSetting 20, lastFailover 1601/01/00:

Lösningen var att ändra "maximala fel" under den angivna perioden för tillgänglighetsgruppklusterrollen till ett mycket högre värde.

1.12 Referenser

  1. AlwaysOn-tillgänglighetsgrupper
  2. Failover och Failover-lägen
  3. Tillgänglighetslägen

  1. SQL (ORACLE):ORDER BY och LIMIT

  2. FEL 1044 (42000):Åtkomst nekad för användare ''@'localhost' till databasen 'db'

  3. Oracle-markör för tilldelning

  4. Vad händer egentligen med det sökandet?