Windows Server-redundanskluster med SQL Server på virtuella Azure-datorer

  • Artikel

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

Den här artikeln beskriver skillnaderna när du använder funktionen Windows Server-redundanskluster med SQL Server på virtuella Azure-datorer för hög tillgänglighet och haveriberedskap (HADR), till exempel för AlwaysOn-tillgänglighetsgrupper (AG) eller redundansklusterinstanser (FCI).

Mer information om själva Windows-funktionen finns i dokumentationen om Windows Server-redundanskluster.

Översikt

SQL Server-lösningar med hög tillgänglighet i Windows, till exempel AlwaysOn-tillgänglighetsgrupper (AG) eller redundansklusterinstanser (FCI) förlitar sig på den underliggande WSFC-tjänsten (Windows Server Failover Clustering).

Klustertjänsten övervakar nätverksanslutningar och hälsotillståndet för noder i klustret. Den här övervakningen är utöver de hälsokontroller som SQL Server gör som en del av tillgänglighetsgruppen eller funktionen för redundansklusterinstans. Om klustertjänsten inte kan nå noden, eller om ag- eller FCI-rollen i klustret blir felaktig, initierar klustertjänsten lämpliga återställningsåtgärder för att återställa och koppla program och tjänster online, antingen på samma eller på en annan nod i klustret.

Övervakning av klusterhälsa

För att tillhandahålla hög tillgänglighet måste klustret säkerställa hälsotillståndet för de olika komponenter som utgör den klustrade lösningen. Klustertjänsten övervakar hälsotillståndet för klustret baserat på ett antal system- och nätverksparametrar för att identifiera och svara på fel.

Det är viktigt att ange tröskelvärdet för att deklarera ett fel för att uppnå en balans mellan att snabbt svara på ett fel och undvika falska fel.

Det finns två strategier för övervakning:

Övervakning Beskrivning
Aggressiv Ger snabb felidentifiering och återställning av svåra fel, vilket ger högsta tillgänglighetsnivå. Klustertjänsten och SQL Server är båda mindre förlåtande för tillfälliga fel och kan i vissa situationer i förtid redundansväxla resurser när det uppstår tillfälliga avbrott. När felet har identifierats kan den korrigerande åtgärden som följer ta extra tid.
Avslappnad Ger mer förlåtande felidentifiering med större tolerans för korta tillfälliga nätverksproblem. Undviker tillfälliga fel, men medför också risk för att fördröja identifieringen av ett verkligt fel.

Aggressiva inställningar i en klustermiljö i molnet kan leda till för tidiga fel och längre avbrott. Därför rekommenderas en avslappnad övervakningsstrategi för redundanskluster på virtuella Azure-datorer. Mer information finns i metodtips för kluster för att justera tröskelinställningarna.

Kluster pulsslag

De primära inställningarna som påverkar hjärtslag i klustret och hälsoidentifiering mellan noder:

Inställning Beskrivning
Fördröjning Detta definierar hur ofta klustrets pulsslag skickas mellan noder. Fördröjningen är antalet sekunder innan nästa pulsslag skickas. I samma kluster kan det finnas olika fördröjningsinställningar som konfigurerats mellan noder i samma undernät och mellan noder som finns i olika undernät.
Tröskelvärde Tröskelvärdet är det antal pulsslag som kan missas innan klustret vidtar återställningsåtgärder. I samma kluster kan det finnas olika tröskelinställningar som konfigurerats mellan noder i samma undernät och mellan noder som finns i olika undernät.

Standardvärdena för de här inställningarna kan vara för låga för molnmiljöer och kan leda till onödiga fel på grund av tillfälliga nätverksproblem. Om du vill vara mer tolerant använder du avslappnade tröskelinställningar för redundanskluster på virtuella Azure-datorer. Mer information finns i metodtips för kluster.

Kvorum

Även om ett kluster med två noder fungerar utan en kvorumresurs är kunderna strikt skyldiga att använda en kvorumresurs för att ha produktionsstöd. Klusterverifieringen skickar inget kluster utan en kvorumresurs.

Tekniskt sett kan ett kluster med tre noder överleva en enskild nodförlust (ned till två noder) utan en kvorumresurs. Men när klustret är nere på två noder finns det en risk att klustrade resurser går offline för att förhindra ett scenario med delad hjärna om en nod går förlorad eller om det uppstår ett kommunikationsfel mellan noderna. Om du konfigurerar en kvorumresurs kan klusterresurserna förbli online med endast en nod online.

Diskvittnet är det mest motståndskraftiga kvorumalternativet, men om du vill använda ett diskvittne på en SQL Server på en virtuell Azure-dator måste du använda en Delad Azure-disk som medför vissa begränsningar för lösningen med hög tillgänglighet. Använd därför ett diskvittne när du konfigurerar din redundansklusterinstans med Azure Shared Disks, annars använder du ett molnvittne när det är möjligt.

I följande tabell visas de kvorumalternativ som är tillgängliga för SQL Server på virtuella Azure-datorer:

Molnvittne Diskvittne Filresursvittne
Operativsystem som stöds Windows Server 2016+ Allt Allt
Beskrivning Ett molnvittne är en typ av kvorumvittne för redundanskluster som använder Microsoft Azure för att rösta om klusterkvorum. Standardstorleken är cirka 1 MB och innehåller bara tidsstämpeln. Ett molnvittne är perfekt för distributioner på flera platser, flera zoner och flera regioner. Använd ett molnvittne när det är möjligt, såvida du inte har en redundansklusterlösning med delad lagring. Ett diskvittne är en liten klustrad disk i gruppen Klustertillgänglig lagring. Den här disken är mycket tillgänglig och kan redundansväxla mellan noder. Den innehåller en kopia av klusterdatabasen med en standardstorlek som är mindre än 1 GB. Diskvittnet är det föredragna kvorumalternativet för alla kluster som använder Delade Azure-diskar (eller någon delad disklösning som delad SCSI, iSCSI eller fiberkanal-SAN). En klustrad delad volym kan inte användas som diskvittne. Konfigurera en delad Azure-disk som diskvittne. Ett filresursvittne är en SMB-filresurs som vanligtvis konfigureras på en filserver som kör Windows Server. Den underhåller klustringsinformation i en witness.log-fil, men lagrar inte en kopia av klusterdatabasen. I Azure kan du konfigurera en filresurs på en separat virtuell dator i samma virtuella nätverk. Använd ett filresursvittne om ett diskvittne eller molnvittne inte är tillgängligt i din miljö.

Information om hur du kommer igång finns i Konfigurera klusterkvorum.

Namn på virtuellt nätverk (VNN)

Om du vill matcha den lokala upplevelsen för att ansluta till din tillgänglighetsgruppslyssnare eller redundansklusterinstans distribuerar du dina virtuella SQL Server-datorer till flera undernät i samma virtuella nätverk. Att ha flera undernät gör att du inte behöver det extra beroendet av en Azure Load Balancer för att dirigera trafik till DIN HADR-lösning. Mer information finns i Ag för flera undernät och FCI för flera undernät.

I en traditionell lokal miljö förlitar sig klustrade resurser som redundansklusterinstanser eller AlwaysOn-tillgänglighetsgrupper på det virtuella nätverksnamnet för att dirigera trafik till rätt mål – antingen redundansklusterinstansen eller lyssnaren för tillgänglighetsgruppen AlwaysOn. Det virtuella namnet binder IP-adressen i DNS och klienter kan använda antingen det virtuella namnet eller IP-adressen för att ansluta till sitt mål för hög tillgänglighet, oavsett vilken nod som för närvarande äger resursen. VNN är ett nätverksnamn och en adress som hanteras av klustret och klustertjänsten flyttar nätverksadressen från nod till nod under en redundanshändelse. Under ett fel tas adressen offline på den ursprungliga primära repliken och aktiveras på den nya primära repliken.

På virtuella Azure-datorer i ett enda undernät krävs ytterligare en komponent för att dirigera trafik från klienten till namnet på det virtuella nätverket för den klustrade resursen (redundansklusterinstansen eller lyssnaren för en tillgänglighetsgrupp). I Azure innehåller en lastbalanserare IP-adressen för det VNN som klustrade SQL Server-resurser förlitar sig på och är nödvändig för att dirigera trafik till lämpligt mål för hög tillgänglighet. Lastbalanseraren identifierar också fel med nätverkskomponenterna och flyttar adressen till en ny värd.

Lastbalanseraren distribuerar inkommande flöden som kommer till klientdelen och dirigerar sedan trafiken till de instanser som definieras av serverdelspoolen. Du konfigurerar trafikflödet med hjälp av belastningsutjämningsregler och hälsoavsökningar. Med SQL Server FCI är serverdelspoolinstanserna de virtuella Azure-datorer som kör SQL Server, och med tillgänglighetsgrupper är serverdelspoolen lyssnaren. Det finns en liten redundansfördröjning när du använder lastbalanseraren, eftersom hälsoavsökningen utför kontroller var 10:e sekund som standard.

Lär dig hur du konfigurerar Azure Load Balancer för en redundansklusterinstans eller en tillgänglighetsgrupp för att komma igång.

Operativsystem som stöds: Alla
SQL-version som stöds: Alla
HADR-lösning som stöds: Redundansklusterinstans och tillgänglighetsgrupp

Konfigurationen av det virtuella nätverket kan vara besvärlig, det är ytterligare en felkälla, det kan orsaka en fördröjning i felidentifieringen och det finns en omkostnad och kostnad som är associerad med att hantera den extra resursen. För att åtgärda vissa av dessa begränsningar introducerade SQL Server stöd för funktionen Distributed Network Name.

Namn på distribuerat nätverk (DNN)

Om du vill matcha den lokala upplevelsen för att ansluta till din tillgänglighetsgruppslyssnare eller redundansklusterinstans distribuerar du dina virtuella SQL Server-datorer till flera undernät i samma virtuella nätverk. Om du har flera undernät krävs det extra beroendet av ett DNN för att dirigera trafik till DIN HADR-lösning. Mer information finns i Ag för flera undernät och FCI för flera undernät.

För virtuella SQL Server-datorer som distribueras till ett enda undernät är funktionen för distribuerat nätverksnamn ett alternativt sätt för SQL Server-klienter att ansluta till SQL Server-redundansklusterinstansen eller tillgänglighetsgruppens lyssnare utan att använda en lastbalanserare. DNN-funktionen är tillgänglig från och med SQL Server 2016 SP3, SQL Server 2017 CU25, SQL Server 2019 CU8, på Windows Server 2016 och senare.

När en DNN-resurs skapas binder klustret DNS-namnet med IP-adresserna för alla noder i klustret. Klienten försöker ansluta till varje IP-adress i den här listan för att hitta vilken resurs som ska anslutas till. Du kan påskynda den här processen genom att MultiSubnetFailover=True ange i anslutningssträngen. Den här inställningen instruerar providern att prova alla IP-adresser parallellt, så att klienten kan ansluta till FCI eller lyssnaren direkt.

Ett distribuerat nätverksnamn rekommenderas över en lastbalanserare när det är möjligt eftersom:

  • Lösningen från slutpunkt till slutpunkt är mer robust eftersom du inte längre behöver underhålla lastbalanserarens resurs.
  • Om lastbalanserarens avsökningar elimineras minimeras redundansvaraktigheten.
  • DNN förenklar etablering och hantering av redundansklusterinstansen eller tillgänglighetsgruppens lyssnare med SQL Server på virtuella Azure-datorer.

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

Operativsystem som stöds: Windows Server 2016 och senare
SQL-version som stöds: SQL Server 2019 CU2 (FCI) och SQL Server 2019 CU8 (AG)
HADR-lösning som stöds: Redundansklusterinstans och tillgänglighetsgrupp

Kom igång genom att lära dig att konfigurera en resurs för distribuerat nätverksnamn för en redundansklusterinstans eller en tillgänglighetsgrupp.

Det finns ytterligare överväganden när du använder DNN med andra SQL Server-funktioner. Mer information finns i FCI- och DNN-samverkan och AG- och DNN-samverkan .

Återställningsåtgärder

Klustertjänsten vidtar korrigerande åtgärder när ett fel identifieras. Detta kan starta om resursen på den befintliga noden eller redundansväxla resursen till en annan nod. När korrigerande åtgärder har initierats tar det lite tid att slutföra dem.

En omstartad tillgänglighetsgrupp är till exempel online enligt följande sekvens:

  1. Lyssnarens IP-adress är online
  2. Lyssnarnätverkets namn är online
  3. Tillgänglighetsgruppen är online
  4. Enskilda databaser genomgår återställning, vilket kan ta lite tid beroende på ett antal faktorer, till exempel längden på den omgjorda loggen. Anslutningar dirigeras endast av lyssnaren när databasen har återställts helt. Mer information finns i Beräkna redundanstid (RTO)..

Eftersom återställningen kan ta lite tid kan aggressiv övervakningsuppsättning för att identifiera ett fel på 20 sekunder leda till avbrott i minuter om en tillfällig händelse inträffar (till exempel minnesbevarande underhåll av virtuella Azure-datorer). Om du ställer in övervakningen på ett mer avslappnat värde på 40 sekunder kan du undvika ett längre avbrott i tjänsten.

Mer information finns i metodtips för kluster för att justera tröskelinställningarna.

Nodplats

Noder i ett Windows-kluster på virtuella datorer i Azure kan vara fysiskt åtskilda i samma Azure-region, eller så kan de finnas i olika regioner. Avståndet kan medföra nätverksfördröjning, ungefär som att klusternoder sprids mellan platser i dina egna anläggningar. I molnmiljöer är skillnaden att du inom en region kanske inte känner till avståndet mellan noder. Dessutom finns det andra faktorer som fysiska och virtuella komponenter, antal hopp osv. kan också bidra till ökad svarstid. Om svarstiden mellan noderna är ett problem kan du överväga att placera noderna i klustret inom en närhetsplaceringsgrupp för att garantera nätverksnärhet.

Resursbegränsningar

När du konfigurerar en virtuell Azure-dator fastställer du gränserna för beräkningsresurser för PROCESSOR, minne och I/O. Arbetsbelastningar som kräver mer resurser än den köpta virtuella Azure-datorn eller diskgränser kan orsaka prestandaproblem för virtuella datorer. Prestandaförsämring kan resultera i en misslyckad hälsokontroll för klustertjänsten eller för funktionen för hög tillgänglighet för SQL Server. Resursflaskhalsar kan göra att noden eller resursen visas ned till klustret eller SQL Server.

Intensiva SQL IO-åtgärder eller underhållsåtgärder som säkerhetskopieringar, index eller statistikunderhåll kan göra att den virtuella datorn eller disken når IOPS - eller MBPS-dataflödesgränser , vilket kan göra att SQL Server inte svarar på en IsAlive/LooksAlive-kontroll .

Om din SQL Server har oväntade redundansväxlingar kontrollerar du att du följer alla metodtips för prestanda och övervakar servern för disk- eller VM-nivå.

Underhåll av Azure-plattformen

Precis som andra molntjänster uppdaterar Azure regelbundet sin plattform för att förbättra tillförlitligheten, prestandan och säkerheten för värdinfrastrukturen för virtuella datorer. Syftet med dessa uppdateringar är att uppdatera programvarukomponenter i värdmiljön för att uppgradera nätverkskomponenter eller inaktivera maskinvara.

De flesta plattformsuppdateringar påverkar inte kundernas virtuella datorer. När en uppdatering utan påverkan inte är möjlig väljer Azure den uppdateringsmekanism som är minst påverkande för kundernas virtuella datorer. De flesta underhåll som inte har någon påverkan pausar den virtuella datorn i mindre än 10 sekunder. I vissa fall använder Azure minnesbevarande underhållsmekanismer. Dessa mekanismer pausar den virtuella datorn i upp till 30 sekunder och bevarar minnet i RAM-minnet. Den virtuella datorn återupptas sedan och klockan synkroniseras automatiskt.

Minnesbevarande underhåll fungerar för mer än 90 procent av de virtuella Azure-datorerna. Det fungerar inte för G-, M-, N- och H-serien. Azure använder i allt högre grad tekniker för direktmigrering och förbättrar minnesbevarande underhållsmekanismer för att minska pausvaraktigheterna. När den virtuella datorn livemigreras till en annan värd kan vissa känsliga arbetsbelastningar som SQL Server visa en liten prestandaförsämring under de få minuter som leder fram till att den virtuella datorn pausas.

En resursflaskhals under plattformsunderhållet kan göra att tillgänglighetsgruppen eller FCI visas ned till klustertjänsten. Mer information finns i avsnittet resursbegränsningar i den här artikeln.

Om du använder aggressiv klusterövervakning kan en utökad vm-paus utlösa en redundansväxling. En redundansväxling orsakar ofta mer stilleståndstid än underhållspausen, så vi rekommenderar att du använder avslappnad övervakning för att undvika att utlösa en redundansväxling medan den virtuella datorn pausas för underhåll. Mer information om hur du anger klustertrösklar på virtuella Azure-datorer finns i metodtipsen för klustret.

Begränsningar

Tänk på följande begränsningar när du arbetar med FCI eller tillgänglighetsgrupper och SQL Server på virtuella Azure-datorer.

MSDTC

Azure Virtual Machines stöder Microsoft Distributed Transaction Coordinator (MSDTC) på Windows Server 2019 med lagring på klustrade delade volymer (CSV) och Azure Standard Load Balancer eller på virtuella SQL Server-datorer som använder delade Azure-diskar.

På virtuella Azure-datorer stöds MSDTC inte för Windows Server 2016 eller tidigare med klustrade delade volymer eftersom:

  • Den klustrade MSDTC-resursen kan inte konfigureras för att använda delad lagring. Om du skapar en MSDTC-resurs i Windows Server 2016 visas ingen delad lagring tillgänglig för användning, även om lagring är tillgänglig. Det här problemet har åtgärdats i Windows Server 2019.
  • Den grundläggande lastbalanseraren hanterar inte RPC-portar.

Nästa steg

Nu när du har bekantat dig med skillnaderna när du använder ett Windows-redundanskluster med SQL Server på virtuella Azure-datorer kan du lära dig mer om tillgänglighetsgrupper för funktioner med hög tillgänglighet eller redundansklusterinstanser. Om du är redo att komma igång bör du granska metodtipsen för konfigurationsrekommendationer.