Verschieben von Azure SQL Managed Instance zwischen Subnetzen

Gilt für:Azure SQL Managed Instance

In diesem Artikel wird erläutert, wie Azure SQL Managed Instance von einem Subnetz in ein anderes in dasselbe virtuelle Netzwerk oder ein anderes verschoben wird. Der Vorgang ähnelt der Skalierung von vCores oder dem Ändern der Instanzdienstebene. Während der Verschiebung bleibt sql Managed Instance verfügbar, mit Ausnahme einer kurzen Ausfallzeit, wenn das Failover auftritt – in der Regel bis zu 10 Sekunden, auch wenn lange ausgeführte Transaktionen unterbrochen werden.

Das Verschieben der Instanz in ein anderes Subnetz löst die folgenden Vorgänge für virtuelle Cluster aus:

• Der virtuelle Cluster erstellt oder ändert die Größe der zugrunde liegenden Infrastruktur im Zielsubnetz.
• Der virtuelle Cluster wird im Quellsubnetz entfernt oder defragmentiert.

Voraussetzungen und Einschränkungen

SQL Managed Instance muss in einem dedizierten Subnetz in einem virtuellen Azure-Netzwerk bereitgestellt werden. Die Anzahl der verwalteten SQL-Instanzen, die innerhalb des Subnetzes bereitgestellt werden können, hängt von der Größe des Subnetzs (Subnetzbereich) ab. Um eine von SQL verwaltete Instanz bereitzustellen oder in ein anderes Subnetz zu verschieben, muss das Zielsubnetz bestimmte Netzwerkanforderungen aufweisen.

Bevor Sie Ihre Instanz in ein anderes Subnetz verschieben, sollten Sie sich mit den folgenden Konzepten vertraut machen:

• Bestimmen von Subnetzgröße und -bereich für Azure SQL Managed Instance.
• Wählen zwischen dem Verschieben der Instanz in ein neues Subnetz oder der Verwendung eines vorhandenen Subnetzes.
• Verwenden von Verwaltungsvorgängen, um neue verwaltete Instanzen automatisch bereitzustellen, Instanzeigenschaften zu aktualisieren oder Instanzen zu löschen. Es ist möglich, diese Verwaltungsvorgänge zu überwachen.

Subnetzbereitschaft

Bevor Sie Ihre verwaltete SQL-Instanz verschieben, vergewissern Sie sich, dass das Subnetz als "Bereit für verwaltete Instanz" markiert ist.

In der Benutzeroberfläche des virtuellen Netzwerks des Azure-Portals werden virtuelle Netzwerke, die die Voraussetzungen für eine von SQL verwaltete Instanz erfüllen, als "Ready for Managed Instance" kategorisiert. Virtuelle Netzwerke mit Subnetzen mit sql verwalteten Instanzen, die bereits für sie bereitgestellt wurden, zeigen vor dem Namen des virtuellen Netzwerks ein Symbol für die verwaltete SQL-Instanz an. Leere Subnetze, die für eine verwaltete SQL-Instanz bereit sind, zeigen ein Subnetzsymbol für virtuelle Netzwerke an.

Subnetze, die als Nicht bereit gekennzeichnet sind, erfüllen nicht alle Anforderungen für die SQL Managed Instance-Bereitstellung. Verwenden Sie das Infosymbol rechts neben dem Subnetznamen, um zu erfahren, warum das Subnetz nicht bereit ist und ob das Subnetz die Netzwerkanforderungen erfüllen kann. Folgende Anforderungen müssen erfüllt sein:

• Delegieren an den Microsoft.Sql/managedInstances Ressourcenanbieter
• Anfügen einer Routingtabelle
• Anfügen einer Netzwerksicherheitsgruppe

Für den Fall, dass das Subnetz Teil eines anderen virtuellen Netzwerks ist, sind zusätzliche Anforderungen:

• Bidirektionales Peering zwischen dem aktuellen virtuellen Netzwerk und dem virtuellen Zielnetzwerk.
• Aktuelle und Zielsubnetze verwenden separate Routingtabellen und Netzwerksicherheitsgruppen.

Nachdem alle Anforderungen erfüllt sind, wechselt das Subnetz von der Kategorie "Nicht bereit " zur Kategorie "Ready for Managed Instance " und kann für eine verwaltete SQL-Instanz verwendet werden.

Subnetze, die bereits verwendet werden (Subnetze, die für Instanzenbereitstellungen verwendet werden, dürfen keine anderen Ressourcen enthalten) oder Subnetze, die eine andere DNS-Zone (eine Verschiebungsbeschränkung für cross-subnet instance move limitation) aufweisen, sind immer Teil der Kategorie "Nicht bereit ".

Abhängig vom Subnetzstatus und -ziel können die folgenden Anpassungen am Zielsubnetz vorgenommen werden:

• Bereit für verwaltete Instanz (enthält vorhandene SQL Managed Instance): Es werden keine Anpassungen vorgenommen. Diese Subnetze enthalten bereits SQL-verwaltete Instanzen, und änderungen am Subnetz können sich auf vorhandene Instanzen auswirken.
• Bereit für verwaltete Instanz (leer) : Der Workflow überprüft alle erforderlichen Regeln in der Netzwerksicherheitsgruppe und der Routingtabelle und fügt alle erforderlichen, aber fehlenden Regeln hinzu. ¹

Hinweis

¹ Benutzerdefinierte Regeln, die der Quellsubnetzkonfiguration hinzugefügt wurden, werden nicht in das Zielsubnetz kopiert. Jede Anpassung der Konfiguration des Quellsubnetzes muss manuell in das Zielsubnetz repliziert werden. Eine Möglichkeit, dies zu erreichen, ist die Verwendung derselben Routingtabelle und Netzwerksicherheitsgruppe für das Quell- und Zielsubnetz.

Einschränkungen des Zielsubnetzes

Beachten Sie bei der Auswahl eines Zielsubnetzes für eine vorhandene Instanz die folgenden Einschränkungen:

• SQL Managed Instance kann in das Subnetz verschoben werden, das einem der folgenden Kriterien entspricht:

  • Das Subnetz befindet sich im selben virtuellen Netzwerk wie das derzeit verwendete.
  • Das Subnetz findest sich in einem virtuellen Netzwerk mit Peering, wenn Sie zu einem Subnetz in einem anderen virtuellen Netzwerk wechseln.

• Die DNS-Zone der Instanzen im Zielsubnetz muss mit der DNS-Zone der instanz übereinstimmen, die verschoben wird. Diese Einschränkung gilt, wenn Sie beabsichtigen, zu einem nicht zu verwendenden Subnetz zu wechseln.

  • Sie können das Zielsubnetz speziell vorbereiten, um die DNS-Zone der sql-verwalteten Instanz beizubehalten, die verschoben wird. Die Vorbereitung kann erfolgen, indem eine neue verwaltete SQL-Instanz in einem leeren Subnetz erstellt und der dnsZonePartner Parameter in der Erstellungsanforderung bereitgestellt wird. Dieser Parameter als Wert akzeptiert die ID der verwalteten SQL-Instanz, und in diesem Fall können Sie die Instanz verwenden, die später in das neue Subnetz¹ verschoben würde.

Hinweis

¹ Abgesehen von diesem Ansatz gibt es keine andere Möglichkeit, die DNS-Zone der verwalteten SQL-Instanz zu diktieren, da sie zufällig generiert wird. Außerdem gibt es derzeit keine Möglichkeit, die DNS-Zone einer bestehenden SQL Managed Instance-Instanz zu aktualisieren.

Wenn Sie eine SQL Managed Instance mit einer Failovergruppe migrieren möchten, gelten die folgenden Voraussetzungen:

• Das Zielsubnetz muss dieselben Sicherheitsregeln aufweisen, die für die Failovergruppenreplikation wie das Quellsubnetz erforderlich sind:

  • Öffnen Sie sowohl eingehende als auch ausgehende Ports 5022 und den Bereich 11000~11999 in der Netzwerksicherheitsgruppe (Network Security Group, NSG) für Verbindungen aus dem anderen verwalteten SQL-Instanzsubnetz (das subnetz, das das Failovergruppenreplikat enthält), um replikationsdatenverkehr zwischen den beiden Instanzen zuzulassen.

• Das Zielsubnetz kann keinen überlappenden Adressbereich mit dem Subnetz haben, das das sekundäre Instanzreplikat der Failovergruppe enthält.

  • Wenn sich MI1 beispielsweise in Subnetz S1 befindet, ist die sekundäre Instanz in der Failovergruppe MI2 in Subnetz S2. Wir möchten MI1 in Subnetz S3 verschieben. Subnetz S3 kann keinen überlappenden Adressbereich mit Subnetz S2 aufweisen.

Weitere Informationen zum Konfigurieren des Netzwerks für Failovergruppen finden Sie unter "Aktivieren der Georeplikation zwischen verwalteten SQL-Instanzen".

Auszuführende Schritte

Das Verschieben einer Instanz von einem Subnetz zu einem anderen umfasst viele Schritte, und je nachdem, wie Ihre verwaltete SQL-Instanz konfiguriert ist, kann zwischen 30 Minuten und 6 Stunden dauern.

In der folgenden Tabelle werden die Vorgangsschritte aufgeführt, die während des Instanzverschiebevorgangs ausgeführt werden:

Schrittname	Beschreibung des Schritts
Anforderungsvalidierung	Überprüft die übermittelten Parameter. Wenn eine Fehlkonfiguration erkannt wird, schlägt der Vorgang mit einer Fehlermeldung fehl.
Änderung der Größe/Erstellung eines virtuellen Clusters	Je nach Status des Zielsubnetzes wird der virtuelle Cluster entweder erstellt oder seine Größe geändert.
Start der neuen Instanz	Der SQL-Prozess wird im bereitgestellten virtuellen Cluster im Zielsubnetz gestartet.
Seeding/Anfügen von Datenbankdateien	Je nach Dienstebene wird entweder Seeding für die Datenbank ausgeführt, oder die Datenbankdateien werden angefügt.
Failovervorbereitung und -durchführung	Nachdem Daten seeded oder Datenbankdateien neu angefügt wurden, bereitet sich das System auf das Failover vor. Wenn alles bereit ist, führt das System ein Failover mit einer kurzen Ausfallzeit aus, das ist in der Regel weniger als 10 Sekunden.
Bereinigung der alte SQL-Instanz	Entfernt den alten SQL-Prozess aus dem virtuellen Quellcluster.
Löschung eines virtuellen Clusters	Wenn es sich um die letzte Instanz innerhalb des Quellsubnetzes handelt, wird der virtuelle Cluster im letzten Schritt synchron gelöscht. Andernfalls wird der virtuelle Cluster asynchron defragmentiert.

Eine ausführliche Erläuterung der Vorgangsschritte finden Sie in der Übersicht über azure SQL Managed Instance Management Operations.

Verschieben der Instanz

Eine subnetzübergreifende Instanzverschiebung ist Teil des Instanzaktualisierungsvorgangs. Vorhandene Instanzaktualisierungs-API, Azure PowerShell und Azure CLI-Befehle werden mit einer Subnetz-ID-Eigenschaft erweitert.

Verwenden Sie im Azure-Portal das Subnetzfeld im Bereich Netzwerk, um die Instanz in das Zielsubnetz zu verschieben. Wenn Sie Azure PowerShell oder die Azure CLI verwenden, geben Sie im Aktualisierungsbefehl eine andere Subnetz-ID an, um die Instanz aus einem vorhandenen Subnetz in das Zielsubnetz zu verschieben.

Eine vollständige Referenz der Instanzverwaltungsbefehle finden Sie unter Verwaltungs-API-Referenz für Azure SQL Managed Instance.

Portal

Die Option zum Auswählen des Instanzsubnetzes befindet sich im Bereich Netzwerk des Azure-Portals. Der Instanzverschiebevorgang wird gestartet, wenn Sie ein Subnetz auswählen und Ihre Änderungen speichern.

Der erste Schritt des Verschiebevorgangs besteht darin, das Zielsubnetz für die Bereitstellung vorzubereiten. Dies kann einige Minuten dauern. Sobald das Subnetz bereit ist, wird der Verwaltungsvorgang zum Verschieben der Instanz gestartet und wird im Azure-Portal sichtbar.

Überwachen Sie Instanzverschiebevorgänge im Bereich Übersicht des Azure-Portals. Wählen Sie die Benachrichtigung aus, um einen anderen Bereich mit Informationen zum aktuellen Schritt, den Gesamtschritten und einer Schaltfläche zum Abbrechen des Vorgangs zu öffnen.

PowerShell

Verwenden Sie den Azure PowerShell-Befehl Set-AzSqlInstance, um eine Instanz zu verschieben, nachdem Sie Ihr Subnetz in demselben virtuellen Netzwerk wie Ihr Zielsubnetz erstellt haben. Wenn Sie ein vorhandenes Subnetz verwenden möchten, geben Sie diesen Subnetznamen im PowerShell-Befehl an.

Die PowerShell-Beispielbefehle in diesem Abschnitt bereiten das Zielsubnetz für die Instanzbereitstellung vor und verschieben die verwaltete SQL-Instanz.

Verwenden Sie den folgenden PowerShell-Befehl, um Ihre Parameter anzugeben:

### PART 1 - DEFINE PARAMETERS

#Generating basic parameters
$currentSubscriptionID = 'subscription-id'
$sqlMIResourceGroupName = 'resource-group-name-of-sql-mi'
$sqlMIName = 'sql-mi-name'
$sqlMIResourceVnetName = 'vnet-name-of-sql-mi'
$destinationSubnetName = 'name-of-the-destination-subnet-for-sql-mi'

Überspringen Sie diesen Befehl, wenn in Ihrem Subnetz bereits Instanzen bereitgestellt wurden. Wenn Sie ein neues Subnetz verwenden, verwenden Sie den folgenden Azure PowerShell-Befehl, um Ihr Subnetz vorzubereiten:

### PART 2 - PREPARE DESTINATION SUBNET

#Loading the url of script used for preparing the subnet for SQL MI deployment
$scriptUrlBase = 'https://raw.githubusercontent.com/Microsoft/sql-server-samples/master/samples/manage/azure-sql-db-managed-instance/delegate-subnet'

#Generating destination subnet parameters
$parameters = @{
    subscriptionId = $currentSubscriptionID
    resourceGroupName = $sqlMIResourceGroupName
    virtualNetworkName = $sqlMIResourceVnetName
    subnetName = $destinationSubnetName
}

#Initiating subnet preparation script
Invoke-Command -ScriptBlock ([Scriptblock]::Create((iwr ($scriptUrlBase+'/delegateSubnet.ps1?t='+ [DateTime]::Now.Ticks)).Content)) -ArgumentList $parameters

Hinweis

Weitere Informationen zum Skript, das das Subnetz vorbereitet, finden Sie unter Konfigurieren eines vorhandenen virtuellen Netzwerks für Azure SQL Managed Instance.

Der folgende Azure PowerShell-Befehl verschiebt die Instanz in das Quellsubnetz:

### PART 3 - MOVE INSTANCE TO THE NEW SUBNET

Set-AzSqlInstance -Name $sqlMIName -ResourceGroupName $sqlMIResourceGroupName `
-SubnetId "/subscriptions/$currentSubscriptionID/resourceGroups/$sqlMIResourceGroupName/providers/Microsoft.Network/virtualNetworks/$sqlMIResourceVnetName/subnets/$destinationSubnetName"

Der folgende Azure PowerShell-Befehl verschiebt die -Instanz und bietet auch eine Möglichkeit, den Status zu überwachen:

### PART 3 EXTENDED - MOVE INSTANCE AND MONITOR PROGRESS

# Extend the Set-AzSqlInstance command with -AsJob -Force parameters to be able to monitor the progress or proceed with script execution as moving the instance to another subnet is long running operation
Set-AzSqlInstance -Name $sqlMIName -ResourceGroupName $sqlMIResourceGroupName `
-SubnetId "/subscriptions/$currentSubscriptionID/resourceGroups/$sqlMIResourceGroupName/providers/Microsoft.Network/virtualNetworks/$sqlMIResourceVnetName/subnets/$destinationSubnetName" -AsJob -Force

$operationProgress = Get-AzSqlInstanceOperation -ManagedInstanceName $sqlMIName -ResourceGroupName $sqlMIResourceGroupName
#checking the operation step status
Write-Host "Checking the ongoing step" -ForegroundColor Yellow
$operationProgress.OperationSteps.StepsList

Azure-Befehlszeilenschnittstelle

Verwenden Sie den Azure CLI-Befehl az sql mi update, um Ihre Instanz in ein anderes Subnetz zu verschieben.

Geben Sie das Ziel an, indem Sie entweder die Subnetz-ID als --subnet-Eigenschaft oder den Namen des virtuellen Netzwerks als --vnet-name-Eigenschaft und den Subnetznamen als --subnet-Eigenschaft angeben.

Im folgenden Beispiel wird die von SQL verwaltete Instanz in ein anderes Subnetz verschoben, indem die Subnetz-ID angegeben wird:

az sql mi update -g myResourceGroup -n mySqlManagedInstance --subnet /subscriptions/xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/myResourceGroup/providers/Microsoft.Network/virtualNetworks/myVirtualNetworkName/subnets/destinationSubnetName

Im folgenden Beispiel wird die von SQL verwaltete Instanz in ein anderes Subnetz verschoben, indem der Name des virtuellen Netzwerks und der Subnetzname angegeben wird:

az sql mi update -g myResourceGroup -n mySqlManagedInstance --vnet-name myVirtualNetworkName --subnet destinationSubnetName

Verwenden Sie den folgenden Befehl, um den Status des Verwaltungsvorgangs zu überwachen:

az sql mi op list -g myResourceGroup --mi mySqlManagedInstance

Verwandte Inhalte

• Schnellstart: Erstellen einer verwalteten Azure SQL-Instanz
• Vergleich der Features: Azure SQL-Datenbank und azure SQL Managed Instance
• Konnektivitätsarchitektur für Azure SQL Managed Instance
• Migration von verwalteten SQL-Instanzen mithilfe des Datenbankmigrationsdiensts