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:

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 .

# Get the DNS zone ID of the primary instance
$primaryManagedInstanceId = Get-AzSqlInstance -Name $primaryInstance -ResourceGroupName $resourceGroupName | Select-Object Id

# Create the secondary managed instance
New-AzSqlInstance -Name $secondaryInstance `
                  -ResourceGroupName $resourceGroupName `
                  -Location $drLocation `
                  -SubnetId $secondaryMiSubnetConfigId `
                  -AdministratorCredential $mycreds `
                  -StorageSizeInGB $maxStorage `
                  -VCore $vCores `
                  -Edition $edition `
                  -ComputeGeneration $computeGeneration `
                  -LicenseType $license `
                  -DnsZonePartner $primaryManagedInstanceId.Id
Write-host "Secondary SQL Managed Instance created successfully."

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
• Azure ExpressRoute
• VPN-gateways

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.

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.

# Create global virtual network peering
$primaryVirtualNetwork  = Get-AzVirtualNetwork `
                  -Name $primaryVNet `
                  -ResourceGroupName $resourceGroupName

$secondaryVirtualNetwork = Get-AzVirtualNetwork `
                  -Name $secondaryVNet `
                  -ResourceGroupName $resourceGroupName
                  
Write-host "Peering primary VNet to secondary VNet..."
Add-AzVirtualNetworkPeering `
 -Name primaryVnet-secondaryVNet1 `
 -VirtualNetwork $primaryVirtualNetwork `
 -RemoteVirtualNetworkId $secondaryVirtualNetwork.Id
 Write-host "Primary VNet peered to secondary VNet successfully."

Write-host "Peering secondary VNet to primary VNet..."
Add-AzVirtualNetworkPeering `
 -Name secondaryVNet-primaryVNet `
 -VirtualNetwork $secondaryVirtualNetwork `
 -RemoteVirtualNetworkId $primaryVirtualNetwork.Id
Write-host "Secondary VNet peered to primary VNet successfully."

Write-host "Checking peering state on the primary virtual network..."
Get-AzVirtualNetworkPeering `
-ResourceGroupName $resourceGroupName `
-VirtualNetworkName $primaryVNet `
| Select PeeringState

Write-host "Checking peering state on the secondary virtual network..."
Get-AzVirtualNetworkPeering `
-ResourceGroupName $resourceGroupName `
-VirtualNetworkName $secondaryVNet `
| Select PeeringState

Skapa redundansgruppen

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

# Create failover group
Write-host "Creating the failover group..."
$failoverGroup = New-AzSqlDatabaseInstanceFailoverGroup -Name $failoverGroupName `
     -Location $location -ResourceGroupName $resourceGroupName -PrimaryManagedInstanceName $primaryInstance `
     -PartnerRegion $drLocation -PartnerManagedInstanceName $secondaryInstance `
     -FailoverPolicy Manual -GracePeriodWithDataLossHours 1
$failoverGroup

Redundanstest

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

# Verify the current primary role
Get-AzSqlDatabaseInstanceFailoverGroup -ResourceGroupName $resourceGroupName `
    -Location $location -Name $failoverGroupName

# Failover the primary managed instance to the secondary role
Write-host "Failing primary over to the secondary location"
Get-AzSqlDatabaseInstanceFailoverGroup -ResourceGroupName $resourceGroupName `
    -Location $drLocation -Name $failoverGroupName | Switch-AzSqlDatabaseInstanceFailoverGroup
Write-host "Successfully failed failover group to secondary location"

# Verify the current primary role
Get-AzSqlDatabaseInstanceFailoverGroup -ResourceGroupName $resourceGroupName `
    -Location $drLocation -Name $failoverGroupName

# Fail primary managed instance back to primary role
Write-host "Failing primary back to primary role"
Get-AzSqlDatabaseInstanceFailoverGroup -ResourceGroupName $resourceGroupName `
    -Location $location -Name $failoverGroupName | Switch-AzSqlDatabaseInstanceFailoverGroup
Write-host "Successfully failed failover group to primary location"

# Verify the current primary role
Get-AzSqlDatabaseInstanceFailoverGroup -ResourceGroupName $resourceGroupName `
    -Location $location -Name $failoverGroupName

# Check role of secondary replica
Write-host "Confirming the secondary replica is secondary...." 
(Get-AzSqlDatabaseFailoverGroup `
   -FailoverGroupName $failoverGroupName `
   -ResourceGroupName $resourceGroupName `
   -ServerName $drServerName).ReplicationRole

# Failover to secondary server
Write-host "Failing over failover group to the secondary..." 
Switch-AzSqlDatabaseFailoverGroup `
   -ResourceGroupName $resourceGroupName `
   -ServerName $drServerName `
   -FailoverGroupName $failoverGroupName
Write-host "Failed failover group successfully to" $drServerName 

Write-host "Confirming the secondary server is now primary...." 
(Get-AzSqlDatabaseFailoverGroup `
   -FailoverGroupName $failoverGroupName `
   -ResourceGroupName $resourceGroupName `
   -ServerName $drServerName).ReplicationRole

# Revert failover to primary server
Write-host "Failing over failover group to the primary...." 
Switch-AzSqlDatabaseFailoverGroup `
   -ResourceGroupName $resourceGroupName `
   -ServerName $serverName `
   -FailoverGroupName $failoverGroupName
Write-host "Failed failover group successfully back to" $serverName

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:

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.

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.

Ä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.

Ä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.

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:

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).

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.