AlwaysOn-tillgänglighetsgrupp på SQL Server på virtuella Azure-datorer

  • Artikel

Gäller för:SQL Server på en virtuell Azure-dator

Den här artikeln introducerar AlwaysOn-tillgänglighetsgrupper (AG) för SQL Server på virtuella Azure-datorer (VM).

Information om hur du kommer igång finns i självstudien om tillgänglighetsgrupp.

Översikt

AlwaysOn-tillgänglighetsgrupper på virtuella Azure-datorer liknar AlwaysOn-tillgänglighetsgrupper lokalt och förlitar sig på det underliggande Windows Server-redundansklustret. Men eftersom de virtuella datorerna finns i Azure finns det några ytterligare överväganden, till exempel redundans för virtuella datorer och routningstrafik i Azure-nätverket.

Följande diagram visar en tillgänglighetsgrupp för SQL Server på virtuella Azure-datorer:

Availability Group

Kommentar

Nu är det möjligt att lyfta och flytta din tillgänglighetsgruppslösning till SQL Server på virtuella Azure-datorer med Hjälp av Azure Migrate. Mer information finns i Migrera tillgänglighetsgrupp .

Redundans för virtuella datorer

För att öka redundansen och hög tillgänglighet bör virtuella SQL Server-datorer antingen finnas i samma tillgänglighetsuppsättning eller i olika tillgänglighetszoner.

Att placera en uppsättning virtuella datorer i samma tillgänglighetsuppsättning skyddar mot avbrott i ett datacenter som orsakas av utrustningsfel (virtuella datorer i en tillgänglighetsuppsättning delar inte resurser) eller från uppdateringar (virtuella datorer i en tillgänglighetsuppsättning uppdateras inte samtidigt).

Tillgänglighetszoner skyddar mot fel i ett helt datacenter, där varje zon representerar en uppsättning datacenter i en region. Genom att se till att resurser placeras i olika tillgänglighetszoner kan inga avbrott på datacenternivå ta alla dina virtuella datorer offline.

När du skapar virtuella Azure-datorer måste du välja mellan att konfigurera tillgänglighetsuppsättningar och tillgänglighetszoner. En virtuell Azure-dator kan inte delta i båda.

Även om tillgänglighetszoner kan ge bättre tillgänglighet än tillgänglighetsuppsättningar (99,99 % jämfört med 99,95 %), bör prestanda också vara ett övervägande. Virtuella datorer i en tillgänglighetsuppsättning kan placeras i en närhetsplaceringsgrupp som garanterar att de är nära varandra, vilket minimerar nätverksfördröjningen mellan dem. Virtuella datorer som finns i olika tillgänglighetszoner har större nätverksfördröjning mellan dem, vilket kan öka den tid det tar att synkronisera data mellan de primära och sekundära replikerna. Detta kan orsaka fördröjningar på den primära repliken samt öka risken för dataförlust i händelse av en oplanerad redundansväxling. Det är viktigt att testa den föreslagna lösningen under belastning och se till att den uppfyller serviceavtalen för både prestanda och tillgänglighet.

Anslutning

Om du vill matcha den lokala upplevelsen för att ansluta till din tillgänglighetsgruppslyssnare distribuerar du dina virtuella SQL Server-datorer till flera undernät i samma virtuella nätverk. Att ha flera undernät nektar behovet av det extra beroendet av en Azure Load Balancer eller ett distribuerat nätverksnamn (DNN) för att dirigera trafiken till lyssnaren.

Om du distribuerar dina virtuella SQL Server-datorer till ett enda undernät kan du konfigurera ett virtuellt nätverksnamn (VNN) och en Azure Load Balancer eller ett distribuerat nätverksnamn (DNN) för att dirigera trafik till tillgänglighetsgruppens lyssnare. Granska skillnaderna mellan de två och distribuera sedan antingen ett distribuerat nätverksnamn (DNN) eller ett virtuellt nätverksnamn (VNN) för din tillgänglighetsgrupp.

De flesta SQL Server-funktioner fungerar transparent med tillgänglighetsgrupper när du använder DNN, men det finns vissa funktioner som kan kräva särskild hänsyn. Mer information finns i AG- och DNN-samverkan .

Dessutom finns det vissa beteendeskillnader mellan funktionerna i VNN-lyssnaren och DNN-lyssnaren som är viktiga att notera:

  • Redundans: Redundansväxlingstiden är snabbare när du använder en DNN-lyssnare eftersom det inte finns någon anledning att vänta tills nätverkslastbalanseraren identifierar felhändelsen och ändrar dess routning.
  • Befintliga anslutningar: Anslutningar som görs till en specifik databas i en redundansväxla tillgänglighetsgrupp stängs, men andra anslutningar till den primära repliken förblir öppna eftersom DNN är online under redundansväxlingen. Detta skiljer sig från en traditionell VNN-miljö där alla anslutningar till den primära repliken vanligtvis stängs när tillgänglighetsgruppen redundansväxlar, lyssnaren kopplas från och den primära repliken övergår till den sekundära rollen. När du använder en DNN-lyssnare kan du behöva justera programanslutningssträngarna för att säkerställa att anslutningar omdirigeras till den nya primära repliken vid redundansväxling.
  • Öppna transaktioner: Öppna transaktioner mot en databas ien tillgänglighetsgrupp stängs och återställs och du måste återansluta manuellt . I SQL Server Management Studio stänger du till exempel frågefönstret och öppnar ett nytt.

För att konfigurera en VNN-lyssnare i Azure krävs en lastbalanserare. Det finns två huvudsakliga alternativ för lastbalanserare i Azure: extern (offentlig) eller intern. Den externa (offentliga) lastbalanseraren är internetuppkopplad och är associerad med en offentlig virtuell IP-adress som är tillgänglig via Internet. En intern lastbalanserare stöder endast klienter i samma virtuella nätverk. För någon av lastbalanserarna måste du aktivera Direct Server Return.

Du kan fortfarande ansluta till varje tillgänglighetsreplik separat genom att ansluta direkt till tjänstinstansen. Eftersom tillgänglighetsgrupper är bakåtkompatibla med databasspeglingsklienter kan du ansluta till tillgänglighetsrepliker som databasspeglingspartners så länge replikerna konfigureras på samma sätt som databasspegling:

  • Det finns en primär replik och en sekundär replik.
  • Den sekundära repliken konfigureras som icke-läsbar (läsbart sekundärt alternativ anges till Nej).

Följande är ett exempel på en klientanslutningssträng som motsvarar den här databasspeglingsliknande konfigurationen med hjälp av ADO.NET eller SQL Server Native Client:

Data Source=ReplicaServer1;Failover Partner=ReplicaServer2;Initial Catalog=AvailabilityDatabase;

Mer information om klientanslutning finns i:

Ett enskilt undernät kräver lastbalanserare

När du skapar en tillgänglighetsgruppslyssnare på ett traditionellt lokalt Windows Server-redundanskluster (WSFC) skapas en DNS-post för lyssnaren med den IP-adress du anger, och den här IP-adressen mappar till MAC-adressen för den aktuella primära repliken i ARP-tabellerna med växlar och routrar i det lokala nätverket. Klustret gör detta med hjälp av Gratuitous ARP (GARP), där det sänder den senaste IP-till-MAC-adressmappningen till nätverket när en ny Primär väljs efter redundansväxling. I det här fallet är IP-adressen för lyssnaren och MAC:en är av den aktuella primära repliken. GARP tvingar fram en uppdatering av ARP-tabellposterna för växlar och routrar, och till alla användare som ansluter till lyssnarens IP-adress dirigeras sömlöst till den aktuella primära repliken.

Av säkerhetsskäl är sändning i ett offentligt moln (Azure, Google, AWS) inte tillåtet, så användning av IP-adresser och GARP:er i Azure stöds inte. För att lösa den här skillnaden i nätverksmiljöer förlitar sig virtuella SQL Server-datorer i en enda undernätstillgänglighetsgrupp på lastbalanserare för att dirigera trafik till lämpliga IP-adresser. Lastbalanserare konfigureras med en IP-adress för klientdelen som motsvarar lyssnaren och en avsökningsport tilldelas så att Azure Load Balancer regelbundet söker efter status för replikerna i tillgänglighetsgruppen. Eftersom endast den primära sql server-datorn för replikering svarar på TCP-avsökningen dirigeras inkommande trafik sedan till den virtuella dator som svarar på avsökningen. Dessutom konfigureras motsvarande avsökningsport som WSFC-kluster-IP, vilket säkerställer att den primära repliken svarar på TCP-avsökningen.

Tillgänglighetsgrupper som konfigurerats i ett enda undernät måste antingen använda en lastbalanserare eller ett distribuerat nätverksnamn (DNN) för att dirigera trafik till rätt replik. För att undvika dessa beroenden konfigurerar du tillgänglighetsgruppen i flera undernät så att tillgänglighetsgruppens lyssnare konfigureras med en IP-adress för en replik i varje undernät och kan dirigera trafiken på rätt sätt.

Om du redan har skapat tillgänglighetsgruppen i ett enda undernät kan du migrera den till en miljö med flera undernät.

Lånemekanism

För SQL Server avgör tillgänglighetsgruppens resurs-DLL hälsotillståndet för tillgänglighetsgruppen baserat på tillgänglighetsgruppens lånemekanism och AlwaysOn-hälsoidentifiering. Tillgänglighetsgruppens resurs-DLL exponerar resurshälsan via IsAlive-åtgärden . Resursövervakaren avsöker IsAlive med klustrets pulsslagsintervall, som anges av värdena CrossSubnetDelay och SameSubnetDelay i klusteromfattande. På en primär nod initierar klustertjänsten redundans när IsAlive-anropet till resurs-DLL returnerar att tillgänglighetsgruppen inte är felfri.

Tillgänglighetsgruppens resurs-DLL övervakar statusen för interna SQL Server-komponenter. Sp_server_diagnostics rapporterar hälsotillståndet för dessa komponenter till SQL Server enligt ett intervall som styrs av HealthCheckTimeout.

Till skillnad från andra redundansmekanismer spelar SQL Server-instansen en aktiv roll i lånemekanismen. Lånemekanismen används som en LooksAlive-validering mellan klusterresursvärden och SQL Server-processen. Mekanismen används för att säkerställa att de två sidorna (klustertjänsten och SQL Server-tjänsten) är i frekvent kontakt, kontrollerar varandras tillstånd och slutligen förhindrar ett scenario med delad hjärna.

När du konfigurerar en tillgänglighetsgrupp på virtuella Azure-datorer finns det ofta ett behov av att konfigurera dessa tröskelvärden på ett annat sätt än vad som skulle konfigureras i en lokal miljö. Information om hur du konfigurerar tröskelinställningar enligt metodtips för virtuella Azure-datorer finns i metodtipsen för klustret.

Nätverkskonfiguration

Distribuera dina virtuella SQL Server-datorer till flera undernät när det är möjligt för att undvika beroendet av en Azure Load Balancer eller ett distribuerat nätverksnamn (DNN) för att dirigera trafik till tillgänglighetsgruppens lyssnare.

I ett redundanskluster för virtuella Azure-datorer rekommenderar vi ett enda nätverkskort per server (klusternod). Azure-nätverk har fysisk redundans, vilket gör ytterligare nätverkskort onödiga i ett redundanskluster för virtuella Azure-datorer. Även om klusterverifieringsrapporten utfärdar en varning om att noderna endast kan nås i ett enda nätverk, kan den här varningen ignoreras på ett säkert sätt i redundanskluster för virtuella Azure-datorer.

Grundläggande tillgänglighetsgrupp

Eftersom grundläggande tillgänglighetsgrupp inte tillåter mer än en sekundär replik och det inte finns någon läsåtkomst till den sekundära repliken kan du använda anslutningssträngarna för databasspegling för grundläggande tillgänglighetsgrupper. Med hjälp av anslutningssträngen eliminerar du behovet av att ha lyssnare. Att ta bort lyssnarberoendet är användbart för tillgänglighetsgrupper på virtuella Azure-datorer eftersom det eliminerar behovet av en lastbalanserare eller måste lägga till ytterligare IP-adresser i lastbalanseraren när du har flera lyssnare för ytterligare databaser.

Om du till exempel uttryckligen vill ansluta med TCP/IP till AG-databasen AdventureWorks på antingen Replica_A eller Replica_B av en grundläggande tillgänglighetsgrupp (eller en tillgänglighetsgrupp som bara har en sekundär replik och läsåtkomsten inte tillåts i den sekundära repliken) kan ett klientprogram tillhandahålla följande anslutningssträng för databasspegling för att ansluta till tillgänglighetsgruppen

Server=Replica_A; Failover_Partner=Replica_B; Database=AdventureWorks; Network=dbmssocn

Distribueringsalternativ

Dricks

Eliminera behovet av en Azure Load Balancer eller ett distribuerat nätverksnamn (DNN) för din AlwaysOn-tillgänglighetsgrupp genom att skapa dina virtuella SQL Server-datorer i flera undernät i samma virtuella Azure-nätverk.

Det finns flera alternativ för att distribuera en tillgänglighetsgrupp till SQL Server på virtuella Azure-datorer, vissa med mer automatisering än andra.

Följande tabell innehåller en jämförelse av tillgängliga alternativ:

Azure-portalen, Azure CLI / PowerShell Snabbstartsmallar Manuell (enskilt undernät) Manuell (flera undernät)
SQL Server-version 2016 + 2016 + 2016 + 2012 + 2012 +
SQL Server-utgåva Enterprise Enterprise Enterprise Enterprise, Standard Enterprise, Standard
Windows Server-version 2016 + 2016 + 2016 + Allt Allt
Skapar klustret åt dig Ja Ja Ja No No
Skapar tillgänglighetsgruppen och lyssnaren åt dig Ja No Nej Nej No
Skapar lyssnare och lastbalanserare separat Inte tillgänglig No Nej Ja Ej tillämpligt
Går det att skapa DNN-lyssnare med den här metoden? Inte tillgänglig No Nej Ja Ej tillämpligt
WSFC-kvorumkonfiguration Molnvittne Molnvittne Molnvittne Allt Allt
Haveriberedskap med flera regioner No Nej Nej Ja Ja
Stöd för flera undernät Ja No No Inte tillgänglig Ja
Stöd för en befintlig AD Ja Ja Ja Ja Ja
Haveriberedskap med flera zoner i samma region Ja Ja Ja Ja Ja
Distribuerad tillgänglighetsgrupp utan AD No Nej Nej Ja Ja
Distribuerad tillgänglighetsgrupp utan kluster No Nej Nej Ja Ja
Kräver lastbalanserare eller DNN No Ja Ja Ja No

Nästa steg

Kom igång genom att läsa hadr-metodtipsen och sedan distribuera tillgänglighetsgruppen manuellt med hjälp av självstudien om tillgänglighetsgrupp.

Du kan läsa mer här: