Dela via


Konfigurera en redundansgrupp för Azure SQL Managed Instance

Gäller för:Azure SQL Managed Instance

I den här artikeln lär du dig hur du konfigurerar en redundansgrupp för Azure SQL Managed Instance med hjälp av Azure-portalen och Azure PowerShell.

Ett PowerShell-skript från slutpunkt till slutpunkt för att skapa båda instanserna i en redundansgrupp finns i Lägg till instans i en redundansgrupp.

Förutsättningar

Tänk på följande förutsättningar:

  • Den sekundära hanterade instansen måste vara tom, d.v.s. inte innehålla några användardatabaser.
  • De två instanserna av SQL Managed Instance måste ha samma tjänstnivå och samma lagringsstorlek. Även om det inte behövs rekommenderar vi starkt att två instanser har samma beräkningsstorlek för att se till att den sekundära instansen kan bearbeta ändringarna som replikeras från den primära instansen på ett hållbart sätt, inklusive perioder med hög aktivitet.
  • IP-adressintervallet för det virtuella nätverket för den primära instansen får inte överlappa adressintervallet för det virtuella nätverket för den sekundära hanterade instansen eller något annat virtuellt nätverk som är peerkopplat med det primära eller sekundära virtuella nätverket.
  • När du skapar den sekundära hanterade instansen måste du ange den primära instansens DNS-zon-ID som värdet för parametern DnsZonePartner . Om du inte anger något värde för DnsZonePartnergenereras zon-ID:t som en slumpmässig sträng när den första instansen skapas i varje virtuellt nätverk och samma ID tilldelas till alla andra instanser i samma undernät. När DNS-zonen har tilldelats kan du inte ändra den.
  • Regler för nätverkssäkerhetsgrupper (NSG) på värdinstansen för undernät måste ha port 5022 (TCP) och portintervallet 11000–11999 (TCP) öppen för inkommande och utgående anslutningar från och till undernätet som är värd för den andra hanterade instansen. Detta gäller både undernät som är värdar för den primära och sekundära instansen.
  • Sorteringen och tidszonen för den sekundära hanterade instansen måste matcha den primära hanterade instansens.
  • Hanterade instanser bör distribueras i parkopplade regioner av prestandaskäl. Hanterade instanser som finns i geo-kopplade regioner drar nytta av en betydligt högre geo-replikeringshastighet jämfört med obetalda regioner.

Adressutrymmesintervall

Om du vill kontrollera adressutrymmet för den primära instansen går du till den virtuella nätverksresursen för den primära instansen och väljer Adressutrymme under Inställningar. Kontrollera intervallet under Adressintervall:

Screenshot of the address space for the primary virtual network in the Azure portal.

Ange den primära instansens zon-ID

När du skapar den sekundära instansen måste du ange zon-ID för den primära instansen DnsZonePartnersom .

Om du skapar den sekundära instansen i Azure-portalen går du till fliken Ytterligare inställningar och under Geo-replikering väljer du Ja för att använda som sekundär redundans och väljer sedan den primära instansen i listrutan:

Screenshot of the Azure portal specifying the primary managed instance as a failover secondary on the additional settings page.

Aktivera anslutning mellan instanserna

Anslut mellan det virtuella nätverkets undernät som är värd för den primära och sekundära instansen måste upprättas för avbrott i trafikflödet för geo-replikering. Det finns flera sätt att upprätta anslutningar mellan hanterade instanser i olika Azure-regioner, inklusive:

Global peering för virtuella nätverk rekommenderas som det mest högpresterande och robusta sättet att upprätta anslutning mellan instanser i en redundansgrupp. Global peering för virtuella nätverk ger en privat anslutning med låg svarstid och hög bandbredd mellan peer-kopplade virtuella nätverk med hjälp av Microsofts staminfrastruktur. Inget offentligt Internet, gatewayer eller ytterligare kryptering krävs i kommunikationen mellan de peerkopplade virtuella nätverken.

Viktigt!

Alternativa sätt att ansluta instanser som omfattar ytterligare nätverksenheter kan komplicera felsökningen av problem med anslutning eller replikeringshastighet, eventuellt kräva aktiv inblandning av nätverksadministratörer och eventuellt avsevärt förlänga lösningstiden.

Oavsett anslutningsmekanism finns det krav som måste uppfyllas för att geo-replikeringstrafiken ska flöda:

  • Routningstabeller och nätverkssäkerhetsgrupper som tilldelats hanterade instansundernät delas inte mellan de två peer-kopplade virtuella nätverken.
  • NSG-reglerna (Network Security Group) på undernätet som är värd för den primära instansen tillåter:
    • Inkommande trafik på port 5022 och portintervall 11000-11999 från undernätet som är värd för den sekundära instansen.
    • Utgående trafik på port 5022 och portintervall 11000-11999 till undernätet som är värd för den sekundära instansen.
  • NSG-reglerna (Network Security Group) på undernätet som är värd för den sekundära instansen tillåter:
    • Inkommande trafik på port 5022 och portintervall 11000-11999 från undernätet som är värd för den primära instansen.
    • Utgående trafik på port 5022 och portintervall 11000-11999 till undernätet som är värd för den primära instansen.
  • IP-adressintervall för virtuella nätverk som är värdar för den primära och sekundära instansen får inte överlappa varandra.
  • Det finns ingen indirekt överlappning av IP-adressintervall mellan de virtuella nätverk som är värdar för den primära och sekundära instansen, eller andra virtuella nätverk som de peerkopplas med via peering för lokala virtuella nätverk eller på annat sätt.

Om du använder andra mekanismer för att tillhandahålla anslutning mellan instanserna än den rekommenderade globala peeringen för virtuella nätverk måste du dessutom se till att följande:

  • Alla nätverksenheter som används, till exempel brandväggar eller virtuella nätverksinstallationer (NVA), blockerar inte trafik på de portar som nämnts tidigare.
  • Att routningen är korrekt konfigurerad och att inte asymmetrisk routning används.
  • Om du distribuerar redundansgrupper i en nav-och-eker-nätverkstopologi mellan regioner bör replikeringstrafiken gå direkt mellan de två hanterade instansundernäten i stället för att dirigeras via hubbnätverken. Det hjälper dig att undvika problem med anslutning och replikeringshastighet.
  1. I Azure-portalen går du till resursen Virtuellt nätverk för din primära hanterade instans.
  2. Välj Peerings under Inställningar och välj sedan + Lägg till.

Screenshot of peerings page for virtual network A in the Azure portal.

  1. Ange eller välj värden för följande inställningar:

    Inställningar beskrivning
    Det här virtuella nätverket
    Namn på peeringlänk Namnet på peering måste vara unikt i det virtuella nätverket.
    Trafik till fjärranslutet virtuellt nätverk Välj Tillåt (standard) för att aktivera kommunikation mellan de två virtuella nätverken via standardflödet VirtualNetwork . Genom att aktivera kommunikation mellan virtuella nätverk kan resurser som är anslutna till något av de virtuella nätverken kommunicera med varandra med samma bandbredd och svarstid som om de var anslutna till samma virtuella nätverk. All kommunikation mellan resurser i de två virtuella nätverken sker via det privata Azure-nätverket.
    Trafik som vidarebefordras från ett fjärranslutet virtuellt nätverk Både Tillåten (standard) och Alternativet Blockera fungerar för den här självstudien. Mer information finns i Skapa en peering
    Virtuell nätverksgateway eller routningsserver Välj Ingen. Mer information om de andra tillgängliga alternativen finns i Skapa en peering.
    Fjärranslutet virtuellt nätverk
    Namn på peeringlänk Namnet på samma peering som ska användas i det virtuella nätverket som är värd för den sekundära instansen.
    Distributionsmodell för virtuellt nätverk Välj Resurshanterare.
    Jag känner till mitt resurs-ID Låt kryssrutan vara avmarkerad.
    Prenumeration Välj Azure-prenumerationen för det virtuella nätverket som är värd för den sekundära instans som du vill peer-koppla med.
    Virtuellt nätverk Välj det virtuella nätverk som är värd för den sekundära instans som du vill peer-koppla med. Om det virtuella nätverket visas men är nedtonat kan det bero på att adressutrymmet för det virtuella nätverket överlappar adressutrymmet för det virtuella nätverket. Om adressutrymmen för virtuella nätverk överlappar varandra kan de inte peer-kopplas.
    Trafik till fjärranslutet virtuellt nätverk Välj Tillåt (standard)
    Trafik som vidarebefordras från ett fjärranslutet virtuellt nätverk Både Tillåten (standard) och Alternativet Blockera fungerar för den här självstudien. Mer information finns i Skapa en peering.
    Virtuell nätverksgateway eller routningsserver Välj Ingen. Mer information om de andra tillgängliga alternativen finns i Skapa en peering.
  2. Välj Lägg till för att konfigurera peering med det virtuella nätverk som du har valt. Efter några sekunder väljer du knappen Uppdatera så ändras peeringstatusen från Uppdatera till Anslut ed.

    Screenshot of the Virtual network peering status on peerings page in Azure portal.

Skapa redundansgruppen

Skapa redundansgruppen för dina hanterade instanser med hjälp av Azure-portalen eller PowerShell.

Skapa redundansgruppen för dina SQL Managed Instances med hjälp av Azure-portalen.

  1. Välj Azure SQL på den vänstra menyn i Azure-portalen. Om Azure SQL inte finns med i listan väljer du Alla tjänster och skriver sedan Azure SQL i sökrutan. (Valfritt) Välj stjärnan bredvid Azure SQL för att lägga till den som ett favoritobjekt i det vänstra navigeringsfältet.

  2. Välj den primära hanterade instans som du vill lägga till i redundansgruppen.

  3. Under Inställningar navigerar du till Instans redundansgrupper och väljer sedan Lägg till grupp för att öppna sidan för att skapa instansens redundansklustergrupp.

    Screenshot of adding a failover group page in Azure portal.

  4. På sidan Redundansgrupp för instans skriver du namnet på redundansgruppen och väljer sedan den sekundära hanterade instansen i listrutan. Välj Skapa när du vill skapa redundansgruppen.

    Screenshot to create failover group in Azure portal.

  5. När distributionen av redundansklustergruppen är klar tas du tillbaka till sidan Redundansgrupp .

Redundanstest

Testa redundans för din redundansgrupp med hjälp av Azure-portalen eller PowerShell.

Testa redundans för redundansgruppen med hjälp av Azure-portalen.

  1. Gå till den sekundära hanterade instansen i Azure-portalen och välj Instansredundansgrupper under inställningar.

  2. Anteckna hanterade instanser i den primära och sekundära rollen.

  3. Välj Redundans och välj sedan Ja på varningen om att TDS-sessioner kopplas från.

    Screenshot to fail over the failover group in Azure portal.

  4. Anteckna hanterade instanser i den primära och sekundära rollen. Om redundansväxlingen lyckades bör de två instanserna ha växlade roller.

    Screenshot of the failover group status of switched instance roles after failover.

Viktigt!

Om rollerna inte växlade kontrollerar du anslutningen mellan instanserna och relaterade NSG- och brandväggsregler. Fortsätt med nästa steg först efter att rollerna har växlats.

  1. Gå till den nya sekundära hanterade instansen och välj Redundans igen för att återställa den primära instansen till den primära rollen.

Hitta lyssnarslutpunkten

När redundansgruppen har konfigurerats uppdaterar du anslutningssträng för programmet till lyssnarens slutpunkt. Programmet är anslutet till lyssnaren för redundansgruppen i stället för den primära databasen, den elastiska poolen eller instansdatabasen. På så sätt behöver du inte uppdatera anslutningssträng manuellt varje gång databasentiteten redundansväxlar och trafiken dirigeras till den entitet som för närvarande är primär.

Lyssnarens slutpunkt är i form av fog-name.database.windows.netoch visas i Azure-portalen när du visar redundansgruppen:

Screenshot where to find the failover group connection string in the Azure portal.

Skapa grupp mellan instanser i olika prenumerationer

Du kan skapa en redundansgrupp mellan SQL Managed Instances i två olika prenumerationer, så länge prenumerationer är associerade med samma Microsoft Entra-klientorganisation.

  • När du använder PowerShell API kan du göra det genom att ange parametern PartnerSubscriptionId för den sekundära SQL Managed Instance.
  • När du använder REST API kan varje instans-ID som ingår i parametern properties.managedInstancePairs ha ett eget prenumerations-ID.
  • Azure-portalen stöder inte skapande av redundansgrupper i olika prenumerationer.

Viktigt!

Azure-portalen stöder inte skapande av redundansgrupper i olika prenumerationer. För redundansgrupper i olika prenumerationer och/eller resursgrupper kan redundans inte initieras manuellt via Azure-portalen från den primära SQL-hanterade instansen. Starta från den geo-sekundära instansen i stället.

Förhindra förlust av kritiska data

På grund av den långa svarstiden för nätverk i stora områden använder geo-replikering en asynkron replikeringsmekanism. Asynkron replikering gör risken för dataförlust oundviklig om den primära replikeringen misslyckas. För att skydda kritiska transaktioner mot dataförlust kan en programutvecklare anropa den sp_wait_for_database_copy_sync lagrade proceduren omedelbart efter att transaktionen har genomförts. Anrop sp_wait_for_database_copy_sync blockerar den anropande tråden tills den senast checkade transaktionen har överförts och härdats i transaktionsloggen för den sekundära databasen. Det väntar dock inte på att de överförda transaktionerna ska spelas upp igen (görs om) på den sekundära. sp_wait_for_database_copy_sync är begränsad till en specifik geo-replikeringslänk. Alla användare med anslutningsrättigheter till den primära databasen kan anropa den här proceduren.

Kommentar

sp_wait_for_database_copy_sync förhindrar dataförlust efter geo-redundans för specifika transaktioner, men garanterar inte fullständig synkronisering för läsåtkomst. Fördröjningen som orsakas av ett sp_wait_for_database_copy_sync proceduranrop kan vara betydande och beror på storleken på den ännu inte överförda transaktionsloggen på den primära vid tidpunkten för anropet.

Ändra den sekundära regionen

Anta att instans A är den primära instansen, instans B är den befintliga sekundära instansen och instans C är den nya sekundära instansen i den tredje regionen. Gör övergången genom att följa dessa steg:

  1. Skapa instans C med samma storlek som A och i samma DNS-zon.
  2. Ta bort redundansgruppen mellan instanserna A och B. Försök att logga in börjar misslyckas eftersom SQL-aliasen för lyssnarna för redundansgruppen har tagits bort och gatewayen inte känner igen namnet på redundansklustergruppen. De sekundära databaserna kopplas från primärvalen och blir skrivskyddade databaser.
  3. Skapa en redundansgrupp med samma namn mellan instans A och C. Följ anvisningarna i guiden Konfigurera redundansgrupp. Det här är en datastorleksåtgärd som slutförs när alla databaser från instans A är seedade och synkroniserade.
  4. Ta bort instans B om det inte behövs för att undvika onödiga avgifter.

Kommentar

Efter steg 2 och tills steg 3 har slutförts förblir databaserna i instans A oskyddade från ett oåterkalleligt fel i instans A.

Ändra den primära regionen

Anta att instans A är den primära instansen, instans B är den befintliga sekundära instansen och instans C är den nya primära instansen i den tredje regionen. Gör övergången genom att följa dessa steg:

  1. Skapa instans C med samma storlek som B och i samma DNS-zon.
  2. Anslut till instans B och manuellt redundansväxla den primära instansen till B. Instans A blir automatiskt den nya sekundära instansen.
  3. Ta bort redundansgruppen mellan instanserna A och B. Nu börjar inloggningsförsök med slutpunkter för redundansgrupper att misslyckas. De sekundära databaserna på A är frånkopplade från primärvalen och blir skrivskyddade databaser.
  4. Skapa en redundansgrupp med samma namn mellan instans B och C. Följ anvisningarna i guiden för redundansgrupper. Det här är en datastorleksåtgärd som slutförs när alla databaser från instans A är seedade och synkroniserade. Nu slutar inloggningsförsöken att misslyckas.
  5. Redundansväxla manuellt för att växla C-instansen till primär roll. Instans B blir automatiskt den nya sekundära instansen.
  6. Ta bort instans A om det inte behövs för att undvika onödiga avgifter.

Varning

Efter steg 3 och tills steg 4 har slutförts förblir databaserna i instans A oskyddade från ett oåterkalleligt fel i instans A.

Viktigt!

När redundansgruppen tas bort tas även DNS-posterna för lyssnarens slutpunkter bort. Då finns det en sannolikhet som inte är noll för att någon annan ska skapa en redundansgrupp med samma namn. Eftersom namn på redundanskluster måste vara globalt unika hindrar detta dig från att använda samma namn igen. Använd inte generiska redundansklusternamn för att minimera den här risken.

Aktivera scenarier som är beroende av objekt från systemdatabaserna

Systemdatabaser replikeras inte till den sekundära instansen i en redundansgrupp. Om du vill möjliggöra scenarier som är beroende av objekt från systemdatabaserna ska du skapa samma objekt i den sekundära instansen och hålla dem synkroniserade med den primära instansen.

Om du till exempel planerar att använda samma inloggningar på den sekundära instansen måste du skapa dem med samma SID.

-- Code to create login on the secondary instance
CREATE LOGIN foo WITH PASSWORD = '<enterStrongPasswordHere>', SID = <login_sid>;

Mer information finns i Replikering av inloggningar och agentjobb.

Synkronisera instansegenskaper och instanser av kvarhållningsprinciper

Instanser i en redundansgrupp förblir separata Azure-resurser och inga ändringar som görs i konfigurationen av den primära instansen replikeras automatiskt till den sekundära instansen. Se till att utföra alla relevanta ändringar både på den primära och sekundära instansen. Om du till exempel ändrar redundans för lagring av säkerhetskopior eller långsiktig kvarhållningsprincip för säkerhetskopiering på den primära instansen måste du även ändra den på den sekundära instansen.

Skalningsinstanser

Du kan skala upp eller skala ned den primära och sekundära instansen till en annan beräkningsstorlek inom samma tjänstnivå eller till en annan tjänstnivå. När du skalar upp inom samma tjänstnivå rekommenderar vi att du skalar upp den geo-sekundära först och sedan skalar upp den primära. När du skalar ned inom samma tjänstnivå ändrar du ordningen: skala ned den primära först och skala sedan ned den sekundära. När du skalar instansen till en annan tjänstnivå framtvingas den här rekommendationen.

Den här sekvensen rekommenderas särskilt för att undvika problemet där den geo-sekundära instansen med en lägre SKU blir överbelastad och måste dirigeras om under en uppgradering eller nedgradering.

Behörigheter

Behörigheter för en redundansgrupp hanteras via rollbaserad åtkomstkontroll i Azure (Azure RBAC).

Skrivåtkomst för Azure RBAC krävs för att skapa och hantera redundansgrupper. Rollen SQL Managed Instance-deltagare har alla behörigheter som krävs för att hantera redundansgrupper.

I följande tabell visas specifika behörighetsomfång för Azure SQL Managed Instance:

Åtgärd Behörighet Definitionsområde
Skapa en redundansgrupp Skrivåtkomst för Azure RBAC Primär hanterad instans
Sekundär hanterad instans
Uppdatera redundansgrupp Skrivåtkomst för Azure RBAC Redundansgrupp
Alla databaser i den hanterade instansen
Redundansväxlingsgrupp Skrivåtkomst för Azure RBAC Redundansgrupp på ny primär hanterad instans

Begränsningar

Tänk på följande begränsningar:

  • Redundansgrupper kan inte skapas mellan två instanser i samma Azure-region.
  • Det går inte att byta namn på redundansgrupper. Du måste ta bort gruppen och återskapa den med ett annat namn.
  • En redundansgrupp innehåller exakt två hanterade instanser. Det går inte att lägga till ytterligare instanser i redundansgruppen.
  • En instans kan bara delta i en redundansgrupp när som helst.
  • Det går inte att skapa en redundansgrupp mellan två instanser som tillhör olika Azure-klientorganisationer.
  • Det går inte att skapa en redundansgrupp mellan två instanser som tillhör olika Azure-prenumerationer med Hjälp av Azure-portalen eller Azure CLI. Använd Azure PowerShell eller REST API i stället för att skapa en sådan redundansgrupp. När den har skapats visas redundansgrupper mellan prenumerationer regelbundet i Azure-portalen och alla efterföljande åtgärder, inklusive redundansväxlingar, kan initieras från Azure-portalen eller Azure CLI.
  • Databasbyte stöds inte för databaser i redundansgrupper. Du måste tillfälligt ta bort redundans för att kunna byta namn på en databas.
  • Systemdatabaser replikeras inte till den sekundära instansen i en redundansgrupp. Därför kräver scenarier som är beroende av objekt från systemdatabaser som serverinloggningar och agentjobb att objekt skapas manuellt på de sekundära instanserna och även synkroniseras manuellt efter ändringar som gjorts på den primära instansen. Det enda undantaget är Tjänstens huvudnyckel (SMK) för SQL Managed Instance som replikeras automatiskt till sekundär instans när redundansgruppen skapas. Eventuella efterföljande ändringar av SMK på den primära instansen replikeras dock inte till den sekundära instansen. Mer information finns i Aktivera scenarier som är beroende av objekt från systemdatabaserna.
  • Redundansgrupper kan inte skapas mellan instanser om någon av dem finns i en instanspool.

Hantera redundansgrupper programmatiskt

Redundansgrupper kan också hanteras programmatiskt med hjälp av Azure PowerShell, Azure CLI och REST API. I följande tabeller beskrivs vilken uppsättning kommandon som är tillgängliga. Redundansgrupper innehåller en uppsättning Azure Resource Manager-API:er för hantering, inklusive Azure SQL Database REST API och Azure PowerShell-cmdletar. Dessa API:er kräver användning av resursgrupper och stöder rollbaserad åtkomstkontroll i Azure (Azure RBAC). Mer information om hur du implementerar åtkomstroller finns i Rollbaserad åtkomstkontroll i Azure (Azure RBAC).

Cmdlet beskrivning
New-AzSqlDatabaseInstanceFailoverGroup Det här kommandot skapar en redundansgrupp och registrerar den på både primära och sekundära instanser
Set-AzSqlDatabaseInstanceFailoverGroup Ändrar konfigurationen av en redundansgrupp
Get-AzSqlDatabaseInstanceFailoverGroup Hämtar konfigurationen för en redundansgrupp
Switch-AzSqlDatabaseInstanceFailoverGroup Utlöser redundans för en redundansgrupp till den sekundära instansen
Remove-AzSqlDatabaseInstanceFailoverGroup Tar bort en redundansgrupp

Nästa steg

Anvisningar för hur du konfigurerar en redundansgrupp finns i guiden Lägg till en hanterad instans i en redundansgrupp .

En översikt över funktionen finns i Redundansgrupper. Information om hur du sparar på licenskostnader finns i Konfigurera standby-replik.