Anteckning
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
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 (VM) 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 flera system- och nätverksparametrar för att utvärdera klustrets hälsotillstånd 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 | Description |
|---|---|
| Aggressive | 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-hjärtslag
De primära inställningarna som påverkar hjärtslagsövervakning i klustret och hälsokontroll mellan noder:
| Inställning | Description |
|---|---|
| Försening | 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öskel | 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 .
Beslutsmässighet
Även om ett kluster med två noder kan fungera utan en kvorumresurs, är kunderna strikt skyldiga att använda en kvorumresurs för att ha produktionsstöd. Klusterverifieringen underkänner alla 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, vilket 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 har hög tillgänglighet och kan växla över 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 fildelning på en separat virtuell maskin inom 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 Multi-subnet AG och Multi-subnet FCI.
I en traditionell lokal miljö förlitar sig klustrade resurser, såsom failover-klusterinstanser eller Always On-tillgänglighetsgrupper, på det virtuella nätverksnamnet för att dirigera trafik till rätt mål – antingen failover-klusterinstansen eller lyssnaren för Always On-tillgänglighetsgruppen. Det virtuella namnet binder IP-adressen i DNS. 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. Vid ett fel tas adressen offline på den ursprungliga primära repliken och tas online på den nya primära repliken.
På virtuella Azure-datorer i ett enda undernät är en annan komponent nödvändig för att dirigera trafik från klienten till det virtuella nätverksnamnet för den klustrade resursen (failover-klusterinstans eller lyssnaren i 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 de virtuella Azure-datorer som kan bli den primära repliken för lyssnaren. Det finns en liten redundansfördröjning när du använder lastbalanseraren, eftersom hälsoavsökningen utför kontroller var tionde 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: Failoverklusterinstans och tillgänglighetsgrupp
Konfigurationen av det virtuella nätverket kan vara besvärlig, det är en extra felkälla, det kan orsaka en fördröjning i felidentifieringen och det finns en kostnad som är associerad med att hantera en annan resurs. För att åtgärda vissa av dessa begränsningar introducerade SQL Server stöd för funktionen Distributed Network Name.
Distribuerat nätverksnamn (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.
- Övergångsvaraktigheten minimeras när lastbalanserarens sonderingar elimineras.
- 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: Failoverklusterinstans 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 fler saker att tänka på när du använder DNN med andra SQL Server-funktioner. Mer information finns i FCI- och DNN-samverkan samt AG- och DNN-samverkan.
Anmärkning
Varje tillgänglighetsgrupp eller redundansklusterinstans i samma kluster behöver en egen oberoende anslutningspunkt, oavsett om det är en VNN-lyssnare eller en DNN-lyssnare.
Återställningsåtgärder
Klustertjänsten vidtar korrigerande åtgärder när ett fel identifieras. Den här åtgärden kan starta om resursen på den befintliga noden eller felöverföra 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:
- Lyssnarens IP-adress är online
- Lyssnarnätverkets namn blir online
- Tillgänglighetsgruppen är online
- Enskilda databaser genomgår återställning, vilket kan ta lite tid beroende på flera faktorer, till exempel längden på redo-loggen. Lyssnaren dirigerar inte anslutningar förrän 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 introducera nätverksfördröjning ungefär som att klusternoder sprids mellan platser i dina egna anläggningar. I molnmiljöer är skillnaden att inom en region kanske du inte känner till avståndet mellan noder. Dessutom kan vissa andra faktorer som fysiska och virtuella komponenter, antal hopp osv. 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 med hög tillgänglighet för SQL Server. Resursflaskhalsar kan få noden eller resursen att 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 upplever oväntade failovers bör du kontrollera att du följer alla metodtips för prestanda och övervaka servern för begränsningar på 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 allt från korrigering av programvarukomponenter i värdmiljön till uppgradering av nätverkskomponenter eller avaktivering av 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 resurshinder under plattformsunderhållet kan få tillgänglighetsgruppen eller FCI att verka nedkopplad för 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 failover. En failover kan ofta orsaka mer stilleståndstid än underhållspausen. Därför rekommenderar vi 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 Metodtips för kluster.
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
Virtuella Azure-datorer 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.