Przenoszenie wystąpienia zarządzanego Azure SQL między podsieciami

Dotyczy:Azure SQL Managed Instance

W tym artykule wyjaśniono, jak przenieść usługę Azure SQL Managed Instance z jednej podsieci do innej w tej samej sieci wirtualnej lub innej. Operacja jest podobna do skalowania rdzeni wirtualnych lub zmiany warstwy usługi wystąpienia. Podczas przenoszenia usługa SQL Managed Instance pozostaje dostępna, z wyjątkiem krótkiego przestoju, gdy nastąpi przejście w tryb failover — zwykle trwa do 10 sekund, nawet jeśli długotrwałe transakcje zostaną przerwane.

Przeniesienie wystąpienia do innej podsieci wyzwala następujące operacje klastra wirtualnego:

• Klaster wirtualny tworzy lub zmienia rozmiar podstawowej infrastruktury w podsieci docelowej.
• Klaster wirtualny jest usuwany lub defragmentowany w podsieci źródłowej.

Wymagania i ograniczenia

Wystąpienie zarządzane SQL musi zostać wdrożone w dedykowanej podsieci w sieci wirtualnej platformy Azure. Liczba wystąpień zarządzanych SQL, które można wdrożyć w podsieci, zależy od rozmiaru podsieci (zakresu podsieci). Aby wdrożyć wystąpienie zarządzane SQL lub przenieść je do innej podsieci, podsieć docelowa musi mieć określone wymagania dotyczące sieci.

Przed przeniesieniem wystąpienia do innej podsieci rozważ zapoznanie się z następującymi pojęciami:

• Określ wymagany rozmiar i zakres podsieci dla usługi Azure SQL Managed Instance.
• Wybierz między przeniesieniem wystąpienia do nowej podsieci lub użyciem istniejącej podsieci.
• Użyj operacji zarządzania, aby automatycznie wdrażać nowe wystąpienia zarządzane, aktualizować właściwości wystąpienia lub usuwać wystąpienia. Można monitorować te operacje zarządzania.

Gotowość podsieci

Przed przeniesieniem wystąpienia zarządzanego SQL upewnij się, że podsieć jest oznaczona jako Gotowa dla wystąpienia zarządzanego.

W interfejsie użytkownika sieci wirtualnej witryny Azure Portal sieci wirtualne spełniające wymagania wstępne dla wystąpienia zarządzanego SQL są klasyfikowane jako Gotowe do wystąpienia zarządzanego. Sieci wirtualne, które mają podsieci z już wdrożonymi wystąpieniami zarządzanymi SQL, wyświetlają ikonę wystąpienia zarządzanego SQL przed nazwą sieci wirtualnej. Puste podsieci, które są gotowe do wystąpienia zarządzanego SQL, wyświetlają ikonę podsieci sieci wirtualnej.

Podsieci oznaczone jako Nieprzygotowane nie spełniają wszystkich wymagań dotyczących wdrożenia usługi SQL Managed Instance. Użyj ikony informacji po prawej stronie nazwy podsieci, aby dowiedzieć się, dlaczego podsieć nie jest gotowa i czy podsieć może spełniać wymagania sieciowe. Te wymagania obejmują:

• delegowanie do dostawcy Microsoft.Sql/managedInstances zasobów
• dołączanie tabeli tras
• dołączanie sieciowej grupy zabezpieczeń

W przypadku, gdy podsieć jest częścią innej sieci wirtualnej, dodatkowe wymagania są następujące:

• Dwukierunkowa komunikacja równorzędna między bieżącą i docelową siecią wirtualną.
• Bieżące i docelowe podsieci używają oddzielnych tabel tras i sieciowych grup zabezpieczeń.

Po spełnieniu wszystkich wymagań podsieć przechodzi z kategorii Nie gotowe do wystąpieniazarządzanego i może być używana dla wystąpienia zarządzanego SQL.

Podsieci, które są już używane (podsieci używane na potrzeby wdrożeń wystąpień nie mogą zawierać innych zasobów) lub podsieci, które mają inną strefę DNS (ograniczenie przenoszenia wystąpienia między podsieciami), są zawsze częścią kategorii Nie gotowe .

W zależności od stanu i oznaczenia podsieci można wprowadzić następujące zmiany w podsieci docelowej:

• Gotowe do użycia w usłudze Managed Instance (zawiera istniejące wystąpienie zarządzane SQL): nie są wprowadzane żadne korekty. Te podsieci zawierają już wystąpienia zarządzane SQL i wprowadzenie wszelkich zmian w podsieci może mieć wpływ na istniejące wystąpienia.
• Gotowe do wystąpienia zarządzanego (puste): przepływ pracy weryfikuje wszystkie wymagane reguły w sieciowej grupie zabezpieczeń i tabeli tras oraz dodaje wszystkie reguły, które są niezbędne, ale brakujące. ¹

Uwaga

^{1 Reguły} niestandardowe dodane do konfiguracji podsieci źródłowej nie są kopiowane do podsieci docelowej. Wszelkie zmiany w konfiguracji podsieci źródłowej muszą zostać zreplikowane ręcznie w podsieci docelowej. Można to zrobić, korzystając na przykład z tej samej tabeli routingu i sieciowej grupy zabezpieczeń w przypadku źródłowej i docelowej podsieci.

Ograniczenia podsieci docelowej

Podczas wybierania podsieci docelowej dla istniejącego wystąpienia należy wziąć pod uwagę następujące ograniczenia:

• Wystąpienie zarządzane SQL można przenieść do podsieci, która jest:

  • W tej samej sieci wirtualnej co aktualnie używana,
  • W równorzędnej sieci wirtualnej, jeśli przejdziesz do podsieci w innej sieci wirtualnej.

• Strefa DNS wystąpień w podsieci docelowej musi być zgodna ze strefą DNS przenoszonego wystąpienia. To ograniczenie ma zastosowanie, jeśli planujesz przejść do podsieci nonempty.

  • Możesz specjalnie przygotować podsieć docelową, aby zachować strefę DNS przenoszonego wystąpienia zarządzanego SQL. Przygotowanie można wykonać, tworząc nowe wystąpienie zarządzane SQL w pustej podsieci i podając dnsZonePartner parametr w żądaniu tworzenia. Ten parametr jako wartość akceptuje identyfikator wystąpienia zarządzanego SQL, a w tym przypadku można użyć wystąpienia, które później zostanie przeniesione do nowej podsieci¹.

Uwaga

^{1 Oprócz} tego podejścia nie ma innego sposobu, aby dyktować strefę DNS wystąpienia zarządzanego SQL, ponieważ jest on generowany losowo. Obecnie nie istnieje również sposób aktualizowania strefy DNS istniejącego wystąpienia zarządzanego SQL.

Jeśli chcesz przeprowadzić migrację wystąpienia zarządzanego SQL z grupą trybu failover, obowiązują następujące wymagania wstępne:

• Podsieć docelowa musi mieć te same reguły zabezpieczeń wymagane do replikacji grupy trybu failover co podsieć źródłowa:

  • Otwórz porty przychodzące i wychodzące 5022 oraz zakres 11000~11999 w sieciowej grupie zabezpieczeń dla połączeń z innej podsieci wystąpienia zarządzanego SQL (repliki grupy trybu failover), aby zezwolić na ruch replikacji między dwoma wystąpieniami.

• Podsieć docelowa nie może mieć nakładających się zakresów adresów z podsiecią, która zawiera replikę wystąpienia pomocniczego grupy trybu failover.

  • Jeśli na przykład mi1 znajduje się w podsieci S1, wystąpienie pomocnicze w grupie trybu failover to MI2 w podsieci S2. Chcemy przenieść mi1 do podsieci S3. Podsieć S3 nie może mieć nakładających się zakresów adresów z podsiecią S2.

Aby dowiedzieć się więcej na temat konfigurowania sieci dla grup trybu failover, zobacz Włączanie replikacji geograficznej między wystąpieniami zarządzanymi SQL.

Kroki operacji

Przeniesienie wystąpienia z jednej podsieci do innej obejmuje wiele kroków i w zależności od konfiguracji usługi SQL Managed Instance może potrwać od 30 minut do 6 godzin.

W poniższej tabeli przedstawiono kroki operacji wykonywane podczas operacji przenoszenia wystąpienia:

Nazwa kroku	Opis kroku
Weryfikacja żądania	Sprawdza poprawność przesłanych parametrów. Jeśli zostanie wykryta nieprawidłowa konfiguracja, operacja zakończy się niepowodzeniem z powodu błędu.
Zmiana rozmiaru/tworzenie klastra wirtualnego	W zależności od stanu podsieci docelowej klaster wirtualny jest tworzony lub zmieniany rozmiar.
Uruchamianie nowego wystąpienia	Proces SQL rozpoczyna się w wdrożonym klastrze wirtualnym w podsieci docelowej.
Rozmieszczanie plików bazy danych / dołączanie plików bazy danych	W zależności od warstwy usługi baza danych jest rozmieszczana lub pliki bazy danych są dołączone.
Przygotowywanie trybu failover i trybu failover	Po ponownym dołączeniu danych lub ponownym dołączeniu plików bazy danych system przygotowuje się do przejścia w tryb failover. Gdy wszystko jest gotowe, system wykonuje tryb failover z krótkim przestojem, zazwyczaj jest to mniej niż 10 sekund.
Czyszczenie starego wystąpienia SQL	Usuwa stary proces SQL ze źródłowego klastra wirtualnego.
Usuwanie klastra wirtualnego	Jeśli jest to ostatnie wystąpienie w podsieci źródłowej, ostatni krok powoduje synchroniczne usunięcie klastra wirtualnego. W przeciwnym razie klaster wirtualny jest asynchronicznie defragmentowany.

Szczegółowe wyjaśnienie kroków operacji można znaleźć w temacie Omówienie operacji zarządzania usługą Azure SQL Managed Instance.

Przenoszenie wystąpienia

Przenoszenie wystąpienia między podsieciami jest częścią operacji aktualizacji wystąpienia. Istniejące polecenia interfejsu API aktualizacji wystąpień, programu Azure PowerShell i interfejsu wiersza polecenia platformy Azure są ulepszone za pomocą właściwości identyfikatora podsieci.

W witrynie Azure Portal użyj pola podsieci w okienku Sieć , aby przenieść wystąpienie do podsieci docelowej. W przypadku korzystania z programu Azure PowerShell lub interfejsu wiersza polecenia platformy Azure podaj inny identyfikator podsieci w poleceniu aktualizacji, aby przenieść wystąpienie z istniejącej podsieci do podsieci docelowej.

Aby uzyskać pełną dokumentację poleceń zarządzania wystąpieniami, zobacz Dokumentacja interfejsu API zarządzania dla usługi Azure SQL Managed Instance.

Portal

Opcja wyboru podsieci wystąpienia znajduje się w okienku Sieć w witrynie Azure Portal. Operacja przenoszenia wystąpienia rozpoczyna się po wybraniu podsieci i zapisaniu zmian.

Pierwszym krokiem operacji przenoszenia jest przygotowanie podsieci docelowej do wdrożenia, co może potrwać kilka minut. Gdy podsieć będzie gotowa, zostanie uruchomiona operacja zarządzania przenoszeniem wystąpienia i stanie się widoczna w witrynie Azure Portal.

Monitorowanie operacji przenoszenia wystąpienia z okienka Przegląd witryny Azure Portal. Wybierz powiadomienie, aby otworzyć inne okienko zawierające informacje o bieżącym kroku, łączne kroki i przycisk, aby anulować operację.

Program PowerShell

Użyj polecenia programu Azure PowerShell Set-AzSqlInstance , aby przenieść wystąpienie po utworzeniu podsieci w tej samej sieci wirtualnej co docelowa podsieć. Jeśli chcesz użyć istniejącej podsieci, podaj tę nazwę podsieci w poleceniu programu PowerShell.

Przykładowe polecenia programu PowerShell w tej sekcji przygotowują podsieć docelową do wdrożenia wystąpienia i przenoszą wystąpienie zarządzane SQL.

Użyj następującego polecenia programu PowerShell, aby określić parametry:

### 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'

Pomiń to polecenie, jeśli podsieć ma już wdrożone wystąpienia. Jeśli używasz nowej podsieci, użyj następującego polecenia programu Azure PowerShell, aby przygotować podsieć:

### 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

Uwaga

Aby dowiedzieć się więcej na temat skryptu, który przygotowuje podsieć, zobacz Konfigurowanie istniejącej sieci wirtualnej dla usługi Azure SQL Managed Instance.

Następujące polecenie programu Azure PowerShell przenosi wystąpienie do podsieci źródłowej:

### 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"

Następujące polecenie programu Azure PowerShell przenosi wystąpienie, a także umożliwia monitorowanie postępu:

### 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

Interfejs wiersza polecenia platformy Azure

Użyj polecenia az sql mi update interfejsu wiersza polecenia platformy Azure, aby przenieść wystąpienie do innej podsieci.

Podaj miejsce docelowe, określając identyfikator podsieci jako --subnet właściwość lub określając nazwę sieci wirtualnej jako --vnet-name właściwość i nazwę podsieci jako --subnet właściwość.

Poniższy przykład przenosi wystąpienie zarządzane SQL do innej podsieci, określając identyfikator podsieci:

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

Poniższy przykład przenosi wystąpienie zarządzane SQL do innej podsieci, określając nazwę sieci wirtualnej i nazwę podsieci:

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

Użyj następującego polecenia, aby monitorować postęp operacji zarządzania:

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

Treści powiązane

• Szybki start: tworzenie usługi Azure SQL Managed Instance
• Porównanie funkcji: Azure SQL Database i Azure SQL Managed Instance
• Architektura łączności dla usługi Azure SQL Managed Instance
• Migracja wystąpienia zarządzanego SQL przy użyciu usługi Database Migration Service