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

Dotyczy:Azure SQL Managed Instance

Wystąpienie zarządzane Azure SQL należy wdrożyć w dedykowanej podsieci w sieci wirtualnej platformy Azure. Liczba wystąpień zarządzanych, które można wdrożyć w podsieci, zależy od rozmiaru podsieci (zakresu podsieci).

W tym artykule przedstawiono sposób przenoszenia wystąpienia zarządzanego z jednej podsieci do innej (w tej samej sieci wirtualnej lub innej), podobnie jak w przypadku skalowania rdzeni wirtualnych lub zmiany warstwy usługi wystąpienia. Wystąpienie zarządzane SQL jest dostępne podczas przenoszenia, z wyjątkiem krótkiego przestoju spowodowanego przejściem w tryb failover na końcu aktualizacji — 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 utworzy lub zmieni rozmiar podstawowej infrastruktury w podsieci docelowej.
• Klaster wirtualny jest usuwany lub defragmentowany w podsieci źródłowej.

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.

Wymagania i ograniczenia

Aby wdrożyć wystąpienie zarządzane lub przenieść je do innej podsieci, podsieć docelowa musi mieć określone wymagania sieciowe.

Gotowość podsieci

Przed przeniesieniem wystąpienia zarządzanego upewnij się, że podsieć jest oznaczona jako Gotowa do 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 są klasyfikowane jako Gotowe do wystąpienia zarządzanego. Sieci wirtualne z podsieciami z już wdrożonymi wystąpieniami zarządzanymi wyświetlają ikonę wystąpienia zarządzanego SQL przed nazwą sieci wirtualnej. Puste podsieci, które są gotowe do wystąpienia zarządzanego, 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 zasobów Microsoft.Sql/managedInstances
• 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 Nieprzygotowane do wystąpienia zarządzanego i może być używana dla wystąpienia zarządzanego.

Podsieć, która jest już używana (podsieci używane na potrzeby wdrożeń wystąpień nie mogą zawierać innych zasobów), lub podsieć ma inną strefę DNS (ograniczenie przenoszenia wystąpienia między podsieciami) jest 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 i wprowadzanie 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

¹ 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 niepustej podsieci.

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

Uwaga

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

• Jeśli chcesz przeprowadzić migrację usługi SQL Managed Instance 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 i zakres 11000~11999 w sieciowej grupie zabezpieczeń dla połączeń z innej podsieci wystąpienia zarządzanego (tej, która zawiera replikę grupy trybu failover), aby zezwolić na ruch replikacji między tymi 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.

Kroki operacji

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, zwykle krótszym 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 omówieniu 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 zostały rozszerzone o właściwość 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ć dodatkowe 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.

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

Następne kroki

• Aby dowiedzieć się, jak utworzyć pierwsze wystąpienie zarządzane, zobacz Przewodnik Szybki start.
• Aby zapoznać się z listą funkcji i porównania, zobacz typowe funkcje SQL.
• Aby uzyskać więcej informacji na temat konfiguracji sieci wirtualnej, zobacz Konfiguracja sieci wirtualnej usługi SQL Managed Instance.
• Aby uzyskać przewodnik Szybki start, który tworzy wystąpienie zarządzane i przywraca bazę danych z pliku kopii zapasowej, zobacz Tworzenie wystąpienia zarządzanego.
• Aby zapoznać się z samouczkiem dotyczącym używania usługi Azure Database Migration Service do migracji, zobacz Migracja wystąpienia zarządzanego SQL przy użyciu usługi Database Migration Service.