Verschieben von Azure SQL Managed Instance zwischen Subnetzen

Gilt für:Azure SQL Managed Instance

Azure SQL Managed Instance muss in einem dedizierten Subnetz in einem virtuellen Azure-Netzwerk bereitgestellt werden. Die Anzahl der verwalteten Instanzen, die im Subnetz bereitgestellt werden können, hängt von der Größe des Subnetzes (dem Subnetzbereich) ab.

In diesem Artikel erfahren Sie, wie Sie Ihre verwaltete Instanz aus einem Subnetz in ein anderes (im selben VNet oder in einem anderen) verschieben, ähnlich wie beim Skalieren virtueller Kerne oder Ändern der Dienstebene der Instanz. SQL Managed Instance ist während der Verschiebung verfügbar, mit Ausnahme einer kurzen Ausfallzeit, die durch ein Failover am Ende des Updates verursacht wird. Diese Ausfallzeit dauert in der Regel bis zu 10 Sekunden, auch wenn Transaktionen mit langer Ausführungszeit 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 die zugrunde liegende Infrastruktur im Zielsubnetz oder ändert ihre Größe.
• Der virtuelle Cluster wird im Quellsubnetz entfernt oder defragmentiert.

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.

Anforderungen und Einschränkungen

Um eine verwaltete Instanz bereitzustellen oder in ein anderes Subnetz zu verschieben, muss das Zielsubnetz bestimmte Netzwerkanforderungen erfüllen.

Subnetzbereitschaft

Vergewissern Sie sich vor dem Verschieben Ihrer verwalteten Instanz, dass das Subnetz als Bereit für verwaltete Instanz markiert ist.

In der Benutzeroberfläche des virtuellen Netzwerks im Azure-Portal werden virtuelle Netzwerke, die die Voraussetzungen für eine verwaltete Instanz erfüllen, als Bereit für verwaltete Instanz kategorisiert. Virtuelle Netzwerke, in denen Subnetze mit bereits bereitgestellten verwalteten Instanzen vorhanden sind, zeigen ein SQL Managed Instance-Symbol vor dem Namen des virtuellen Netzwerks an. Für leere Subnetze, die für eine verwaltete Instanz bereit sind, wird ein Symbol für das Subnetz des virtuellen Netzwerks angezeigt.

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 Ressourcenanbieter Microsoft.Sql/managedInstances
• Anfügen einer Routingtabelle
• Anfügen einer Netzwerksicherheitsgruppe

Für den Fall, dass das Subnetz Teil eines anderen Virtual Network ist, gilt die folgende zusätzliche Anforderung

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

Nachdem alle Anforderungen erfüllt wurden, wechselt das Subnetz aus der Kategorie Nicht bereit in die Kategorie Bereit für verwaltete Instanz und kann für eine verwaltete Instanz verwendet werden.

Ein Subnetz, das bereits verwendet wird (für Instanzbereitstellungen verwendete Subnetze dürfen keine anderen Ressourcen enthalten), oder ein Subnetz, das über eine andere DNS-Zone (Einschränkung für die subnetzübergreifende Instanzverschiebung) verfügt, gehören immer zur 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 verwaltete Instanzen, und jede Änderung am Subnetz kann 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

¹ Der Konfiguration des Quellsubnetzes hinzugefügte benutzerdefinierte Regeln 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 zu verschiebenden Instanz übereinstimmen. Diese Einschränkung gilt, wenn Sie zu einem nicht leeren Subnetz wechseln möchten.

  • Sie können das Zielsubnetz speziell so vorbereiten, dass die DNS-Zone von SQL Managed Instance beibehalten wird, die verschoben wird. Zur Vorbereitung können Sie eine neue Instanz von SQL Managed Instance in einem leeren Subnetz erstellen und den dnsZonePartner-Parameter in der Erstellungsanforderung angeben. Dieser Parameter als Wert akzeptiert die ID von SQL Managed Instance, und in diesem Fall können Sie die Instanz verwenden, die später in das neue Subnetz verschoben wird¹.

Hinweis

¹ Abgesehen von diesem Ansatz gibt es keine andere Möglichkeit, die DNS-Zone von SQL Managed Instance zu bestimmen, 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 automatischen 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 (NSG) für Verbindungen aus dem anderen verwalteten Instanz-Subnetz (der einen, der das Failovergruppenreplikat enthält), um Replikationsdatenverkehr zwischen den beiden Instanzen zu ermöglichen.
  • 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 Instanzen.

Auszuführende Schritte

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 das Seeding der Daten ausgeführt oder die Datenbankdateien erneut angefügt wurden, bereitet das System das Failover vor. Wenn alles bereit ist, führt das System ein Failover mit einer kurzen Ausfallzeit aus, die in der Regel weniger als 10 Sekunden beträgt.
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-Verwaltungsvorgänge

Verschieben der Instanz

Eine subnetzübergreifende Instanzverschiebung ist Teil des Instanzaktualisierungsvorgangs. Die vorhandene Instanzaktualisierungs-API, Azure PowerShell und Azure CLI-Befehle wurden um eine 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 zusätzlichen 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 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 prepartion 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 verwaltete Instanz durch Angeben der Subnetz-ID in ein anderes Subnetz verschoben:

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 verwaltete Instanz durch Angeben des Namens des virtuellen Netzwerks und des Subnetznamens in ein anderes Subnetz verschoben:

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

Nächste Schritte

• Im Schnellstarthandbuch erfahren Sie, wie Sie Ihre erste verwaltete Instanz erstellen.
• Eine Liste der Features und einen Funktionsvergleich finden Sie unter Allgemeine SQL-Features.
• Weitere Informationen zur VNET-Konfiguration finden Sie unter Konfigurieren eines VNET für SQL Managed Instance.
• Eine Schnellstartanleitung, in der eine verwaltete Instanz erstellt und eine Datenbank aus einer Sicherungsdatei wiederhergestellt wird, finden Sie unter Erstellen einer verwalteten Azure SQL-Datenbank-Instanz.
• Ein Tutorial zur Verwendung des Azure Database Migration Service für die Migration finden Sie unter SQL Managed Instance-Migration mithilfe des Database Migration Service.