Felsökning AlwaysOn – Ibland krävs många uppsättningar ögon

För några veckor sedan började jag konfigurera en demomiljö med flera konfigurationer av AlwaysOn Availability Groups. Jag hade ett WSFC-kluster med 5 noder – varje nod hade en fristående namngiven instans av SQL Server 2012, och det fanns också två Failover Cluster Instances (FCI) som sattes upp ovanpå dessa noder. Ett snabbt diagram:

Så du kan se att det finns 5 fristående namngivna instanser (.\AGDEMO på varje nod), och sedan två FCI:er – en med möjliga ägare VM-AARON-1 och VM-AARON-2 (AGFCI1\AGFCI1 ), och sedan en med möjliga ägare VM-AARON-3, VM-AARON-4 och VM-AARON-5 (AGFCI2\AGFCI2 ). Nu, manuellt diagram av detta skulle behöva bli betydligt mer komplicerat (mer om det senare), så jag kommer att undvika det av uppenbara skäl. Kravet var i huvudsak att ha flera typer av AG-konfigurationer:

• Primär på en FCI med en replik på en eller flera fristående instanser
• Primär på en FCI med en replik på en annan FCI
• Primär på en fristående instans med en replik på en eller flera FCI:er
• Primär på en fristående instans med en replik på en eller flera fristående instanser
• Primär på en fristående instans med repliker på både fristående instanser och FCI:er

Och sedan kombinationer (där det är möjligt) av synkron vs. asynkron commit, manuell vs. automatisk failover, och skrivskyddade sekundärer. Det finns några tekniska begränsningar som skulle begränsa de möjliga permutationerna här, till exempel:

• Manuell failover är nödvändigt med alla repliker som finns på en FCI
• Ingen WSFC-nod kan vara värd för – eller ens vara möjliga ägare till – flera instanser, vare sig de är fristående eller klustrade, som är involverade i samma tillgänglighetsgrupp. Du får det här felmeddelandet:Det gick inte att skapa, gå med i eller lägga till replika till tillgänglighetsgruppen 'MyGroup', eftersom noden 'VM-AARON-1' är en möjlig ägare för både repliken 'AGFCI1\AGFCI1' och 'VM-AARON-1\ AGDEMO'. Om en replik är failover-klusterinstans tar du bort den överlappade noden från dess möjliga ägare och försöker igen. (Microsoft SQL Server, fel:19405)

De flesta scenarier jag försökte representera är inte praktiska i verkliga scenarier, men de är till stor del och teoretiskt möjliga . Om du inte har gissat vid det här laget, ställs den här miljön upp explicit för att testa ny funktionalitet kring tillgänglighetsgrupper som vi planerar att erbjuda i en framtida version av SQL Sentry. Vi gav en tjuvtitt på en del av denna teknik under vår keynote med Fusion-io vid den nyligen genomförda SQL Intersection-konferensen i Las Vegas.

Hinder #1

Att ställa in tillgänglighetsgrupper med hjälp av guiden i SSMS är ganska enkelt. Om du till exempel inte har heterogena filsökvägar. Guiden har validering som säkerställer att samma data och loggsökvägar finns på alla repliker. Detta kan vara jobbigt om du använder standarddatasökvägen för två olika namngivna instanser, eller om du har olika enhetsbeteckningskonfigurationer (vilket ofta händer när FCIs är inblandade).

Följande mappplatser finns inte på serverinstansen som är värd för sekundär replika VM-AARON-1\AGDEMO:

P:\MSSQL11.AGFCI2\MSSQL\DATA;
(Microsoft.SqlServer.Management.HadrTasks)

Nu borde det vara självklart att du inte vill ställa upp det här scenariot i någon form av miljö som behöver stå emot tidens tand. Saker och ting kommer att gå söderut väldigt snabbt om du till exempel senare lägger till en ny fil i någon av databaserna. Men för en test-/demomiljö, proof of concept eller en miljö som du förväntar dig att vara stabil under en längre tid, oroa dig inte:du kan fortfarande göra detta utan guiden.

Tyvärr, för att lägga förolämpning till skada, låter guiden dig inte skriva det. Du kan inte gå förbi valideringsfelet och det finns inget Script knapp:

Så detta betyder att du måste koda den själv (eftersom DDL inte utför någon "användbar" validering åt dig). Om du har andra instanser där samma sökvägar finns kan du göra detta genom att följa samma guide, gå förbi valideringsskärmen och sedan klicka på Script istället för Finish , och ändra servernamnen och lägg till med WITH MOVE alternativ till den första återställningen. Eller så kan du bara skriva din egen från början, något i stil med detta (skriptet förutsätter att du redan har slutpunkterna och behörigheterna konfigurerade och att alla instanser har funktionen Tillgänglighetsgrupper aktiverad):

-- Använd SQLCMD-läge och avkommentera :CONNECT-kommandona-- eller kör bara de två segmenten separat / ändra anslutning-- :CONNECT Server1 SKAPA TILLGÄNGLIGHETSGRUPP [Gruppnamn] MED (AUTOMATED_BACKUP_PREFERENCE =SEKUNDÄR) FÖR DATABAS [Databas1] -- , ... REPLICA PÅ -- primär:N'Server1' WITH (ENDPOINT_URL =N'TCP://Server1:5022', FAILOVER_MODE =MANUAL, AVAILABILITY_MODE =ASYNKRONÖS_KOMMITTÉ, BACKUP_PRIORITY =50, SEKUNDÄR_INGEN)(SECONDARY_NOCTION)( - sekundärt:N'Server2' WITH (ENDPOINT_URL =N'TCP://Server2:5022', FAILOVER_MODE =MANUAL, AVAILABILITY_MODE =ASYNCHRONOUS_COMMIT, BACKUP_PRIORITY =50, SEKUNDÄR_ROLE(TILLÅT =_INGEN)); ALTER AVAILABILITY GROUP [Gruppnamn] LÄGG TILL LYSARE N'ListenerName' (MED IP ((N'10.x.x.x', N'255.255.255.0')), PORT=1433); BACKUP DATABASE Database1 TO DISK ='\\Server1\Share\db1.bak' MED INIT, COPY_ONLY, KOMPRESSION; BACKUP LOG Database1 TO DISK ='\\Server1\Share\db1.trn' MED INIT, KOMPRESSION; -- :CONNECT Server2ALTER AVAILABILITY GROUP [Gruppnamn] JOIN; ÅTERSTÄLL DATABAS Databas1 FRÅN DISK ='\\Server1\Share\db1.bak' MED REPLACE, NORRECOVERY, NOUNLOAD, FLYTTA 'data_file_name' TILL 'P:\path\file.mdf', FLYTTA 'log_file_name' TILL 'P:\path \file.ldf'; ÅTERSTÄLL LOGG Databas1 FROM DISK ='\\Server1\Share\db1.trn' MED NORRECOVERY, NOUNLOAD; ALTER DATABASE Database1 SET HADR AVAILABILITY GROUP =[Gruppnamn];

Hinder #2

Om du har flera instanser på samma server kan du upptäcka att båda instanserna inte kan dela port 5022 för deras databasspeglingsslutpunkt (vilket är samma slutpunkt som används av tillgänglighetsgrupper). Det betyder att du måste släppa och återskapa slutpunkten för att ställa in den på en tillgänglig port istället.

SLIPPA ENDPOINT [Hadr_endpoint];GO CREATE ENDPOINT [Hadr_endpoint] STATE =STARTAD SOM TCP (LISTENER_PORT =5023) FÖR DATABAS_SPEGLING (ROLE =ALLA);

Nu kunde jag ange en instans med en slutpunkt på ServerName:5023 .

Hinder #3

Men när jag gjorde detta, när jag skulle komma till det sista steget i skriptet ovan, efter exakt 48 sekunder – varje gång – fick jag det här ohjälpsamma felmeddelandet:

Detta fick mig att jaga alla möjliga möjliga problem – kolla brandväggar och SQL Server Configuration Manager, till exempel, för allt som skulle blockera portarna mellan instanserna. Nada. Jag hittade olika fel i SQL Servers fellogg:

Inloggningsförsök med databasspegling misslyckades med fel:'Anslutningshandskakning misslyckades. Ett OS-anrop misslyckades:(80090303) 0x80090303(Det angivna målet är okänt eller går inte att nå). Tillstånd 66.'.

En anslutningstimeout har inträffat vid försök att upprätta en anslutning till tillgänglighetsrepliken 'VM-AARON-1\AGDEMO' med id [5AF5B58D-BBD5-40BB-BE69-08AC50010BE0]. Antingen finns det ett nätverks- eller brandväggsproblem, eller så är slutpunktsadressen som angetts för repliken inte den databasspeglande slutpunkten för värdserverinstansen.

Det visar sig (och tack vare Thomas Stringer (@SQLife)) att detta problem orsakades av en kombination av symtom:(a) Kerberos var inte korrekt inställt och (b) krypteringsalgoritmen för hadr_endpoint som jag skapade var standard till RC4. Det här skulle vara okej om alla fristående instanser också använde RC4, men det var de inte. Lång historia kort, jag tappade och återskapade slutpunkterna igen , i alla fall. Eftersom det här var en labbmiljö och jag egentligen inte behövde Kerberos-support (och eftersom jag redan hade investerat tillräckligt med tid i de här frågorna så att jag inte ville jaga Kerberos-problem också), satte jag upp alla slutpunkter för att använda Negotiate med AES:

SLIPPA ENDPOINT [Hadr_endpoint];GO CREATE ENDPOINT [Hadr_endpoint] STATE =STARTAD SOM TCP ( LISTENER_PORT =5023 ) FÖR DATABAS_MIRRORING (AUTENTIKERING =WINDOWS FÖRHANDLA, KRYPTERING =KRÄVS ALLT i förväg,); 

 (Ted Krueger (@onpnt) bloggade nyligen också om ett liknande problem.)
 

 Nu, äntligen, kunde jag skapa tillgänglighetsgrupper med alla de olika krav jag hade, mellan noder med heterogena filsökvägar och använda flera instanser på samma nod (bara inte i samma grupp). Här är en titt på hur en av våra AlwaysOn Management-vyer kommer att se ut (klicka för att förstora för en mycket bättre översikt):
 

 
 

 Nu, det är bara lite av en retas, och det är helt avsiktligt. Jag kommer att blogga mer om den här funktionen under de kommande veckorna!
 
Slutsats
 

 När du spenderar tillräckligt länge med att titta på ett problem kan du förbise några ganska uppenbara saker. I det här fallet fanns det några uppenbara problem gömda av några direkt ointuitiva felmeddelanden. Jag vill tacka Joe Sack (@JosephSack), Allan Hirt (@SQLHA) och Thomas Stringer (@SQLife) för att de har släppt allt för att hjälpa en annan gemenskapsmedlem i nöd.