Delen via


Azure SQL Managed Instance verplaatsen tussen subnetten

Van toepassing op: Azure SQL Managed Instance

Azure SQL Managed Instance moet worden geïmplementeerd in een toegewezen subnet binnen een virtueel Azure-netwerk. Het aantal beheerde exemplaren dat binnen het subnet kan worden geïmplementeerd, is afhankelijk van de grootte van het subnet (subnetbereik).

In dit artikel leert u hoe u uw beheerde exemplaar verplaatst van het ene subnet naar het andere (in hetzelfde VNet of een ander), vergelijkbaar met het schalen van vCores of het wijzigen van de servicelaag van het exemplaar. SQL Managed Instance is beschikbaar tijdens de verplaatsing, behalve tijdens een korte downtime die wordt veroorzaakt door een failover aan het einde van de update, meestal tot 10 seconden, zelfs als langlopende transacties worden onderbroken.

Als u het exemplaar naar een ander subnet verplaatst, worden de volgende virtuele clusterbewerkingen geactiveerd:

  • Het virtuele cluster bouwt of wijzigt de grootte van de onderliggende infrastructuur in het doelsubnet.
  • Het virtuele cluster wordt verwijderd of gedefragmenteerd in het bronsubnet.

Voordat u uw exemplaar naar een ander subnet verplaatst, kunt u uzelf vertrouwd maken met de volgende concepten:

Vereisten en beperkingen

Als u een beheerd exemplaar wilt implementeren of naar een ander subnet wilt verplaatsen, moet het doelsubnet bepaalde netwerkvereisten hebben.

Gereedheid van subnet

Controleer voordat u het beheerde exemplaar verplaatst of het subnet is gemarkeerd als Gereed voor beheerd exemplaar.

In de gebruikersinterface van het virtuele netwerk van Azure Portal worden virtuele netwerken die voldoen aan de vereisten voor een beheerd exemplaar gecategoriseerd als Gereed voor beheerd exemplaar. Virtuele netwerken met subnetten met beheerde exemplaren die al op deze netwerken zijn geïmplementeerd, geven een pictogram van SQL Managed Instance weer vóór de naam van het virtuele netwerk. Lege subnetten die gereed zijn voor een beheerd exemplaar, geven een subnetpictogram voor een virtueel netwerk weer.

Subnetten die zijn gemarkeerd als Niet gereed , voldoen niet aan alle vereisten voor sql Managed Instance-implementatie. Gebruik het infopictogram aan de rechterkant van de subnetnaam om te zien waarom het subnet niet gereed is en of het subnet aan de netwerkvereisten kan voldoen. Deze vereisten zijn onder andere:

  • delegeren aan de resourceprovider Microsoft.Sql/managedInstances
  • een routetabel koppelen
  • een netwerkbeveiligingsgroep koppelen

In het geval dat subnet deel uitmaakt van een ander virtueel netwerk, zijn er extra vereisten

  • Bidirectionele peering tussen het huidige virtuele netwerk en het doelnetwerk.
  • Huidige en doelsubnetten maken gebruik van afzonderlijke routetabellen en netwerkbeveiligingsgroepen.

Nadat aan alle vereisten is voldaan, wordt het subnet verplaatst van de categorie Niet gereed naar de categorie Gereed voor beheerd exemplaar en kan het worden gebruikt voor een beheerd exemplaar.

Subnet dat al wordt gebruikt (subnetten die worden gebruikt voor exemplaarimplementaties kunnen geen andere resources bevatten), of het subnet heeft een andere DNS-zone (een beperking voor verplaatsing van meerdere subnettenexemplaren) maken altijd deel uit van de categorie Niet gereed .

Screenshot of the Azure SQL Managed Instance subnet options.

Afhankelijk van de status en aanduiding van het subnet kunnen de volgende aanpassingen worden aangebracht in het doelsubnet:

  • Gereed voor beheerd exemplaar (bevat bestaande SQL Managed Instance): er worden geen aanpassingen aangebracht. Deze subnetten bevatten al beheerde exemplaren en het aanbrengen van wijzigingen in het subnet kan van invloed zijn op bestaande exemplaren.
  • Gereed voor beheerd exemplaar (leeg): de werkstroom valideert alle vereiste regels in de netwerkbeveiligingsgroep en routetabel en voegt alle regels toe die nodig zijn, maar ontbreken. 1

Notitie

1 Aangepaste regels die zijn toegevoegd aan de configuratie van het bronsubnet, worden niet gekopieerd naar het doelsubnet. Elke aanpassing van de configuratie van het bronsubnet moet handmatig worden gerepliceerd naar het doelsubnet. Een manier om dit te bereiken is door dezelfde routetabel en netwerkbeveiligingsgroep te gebruiken voor het bron- en doelsubnet.

Beperkingen van doelsubnet

Houd rekening met de volgende beperkingen bij het kiezen van een doelsubnet voor een bestaand exemplaar:

  • SQL Managed Instance kan worden verplaatst naar het subnet dat een van de volgende opties is:

    • In hetzelfde virtuele netwerk als het momenteel gebruikte,
    • Als u in een virtueel peernetwerk overstapt naar een subnet in een ander virtueel netwerk.
  • De DNS-zone van de exemplaren in het doelsubnet moet overeenkomen met de DNS-zone van het exemplaar dat wordt verplaatst. Deze beperking geldt als u van plan bent over te stappen op een niet-leeg subnet.

    • U kunt het doelsubnet speciaal voorbereiden om de DNS-zone van SQL Managed Instance te behouden die wordt verplaatst. Voorbereiding kan worden uitgevoerd door een nieuw met SQL beheerd exemplaar te maken in een leeg subnet en de parameter dnsZonePartner op te geven in de aanvraag voor maken. Deze parameter als een waarde accepteert de id van SQL Managed Instance. In dit geval kunt u het exemplaar gebruiken dat later naar het nieuwe subnet1 wordt verplaatst.

Notitie

1 Afgezien van deze benadering is er geen andere manier om de DNS-zone van SQL Managed Instance te dicteren, omdat deze willekeurig wordt gegenereerd. Vanaf nu bestaat er ook geen manier om de DNS-zone van een bestaand met SQL beheerd exemplaar bij te werken.

  • Als u een met SQL beheerd exemplaar wilt migreren met een failovergroep, zijn de volgende vereisten van toepassing:
    • Het doelsubnet moet dezelfde beveiligingsregels hebben die nodig zijn voor replicatie van failovergroepen als het bronsubnet: Open zowel binnenkomende als uitgaande poorten 5022 en het bereik 11000~11999 in de netwerkbeveiligingsgroep (NSG) voor verbindingen van het andere subnet van het beheerde exemplaar (het subnet dat de replica van de failovergroep bevat) om replicatieverkeer tussen de twee exemplaren toe te staan.
    • Het doelsubnet kan geen overlappend adresbereik hebben met het subnet dat de secundaire exemplaarreplica van de failovergroep bevat. Als MI1 zich bijvoorbeeld in subnet S1 bevindt, is het secundaire exemplaar in de failovergroep MI2 in subnet S2. We willen MI1 verplaatsen naar subnet S3. Subnet S3 kan geen overlappend adresbereik met subnet S2 hebben.

Zie Geo-replicatie tussen beheerde exemplaren inschakelen voor meer informatie over het configureren van het netwerk voor failovergroepen.

Bewerkingsstappen

In de volgende tabel worden de bewerkingsstappen beschreven die optreden tijdens de verplaatsingsbewerking van het exemplaar:

Stapnaam Beschrijving van stap
Aanvraagvalidatie Valideert de ingediende parameters. Als er een onjuiste configuratie wordt gedetecteerd, mislukt de bewerking met een fout.
Grootte van virtuele clusters wijzigen/virtuele clusters maken Afhankelijk van de status van het doelsubnet wordt het virtuele cluster gemaakt of gewijzigd.
Nieuw exemplaar opstarten Het SQL-proces wordt gestart op het geïmplementeerde virtuele cluster in het doelsubnet.
Databasebestanden seeden/databasebestanden koppelen Afhankelijk van de servicelaag wordt de database geseed of worden de databasebestanden bijgevoegd.
Failover voorbereiden en uitvoeren Nadat gegevens zijn geseed of databasebestanden opnieuw zijn gekoppeld, bereidt het systeem zich voor op failover. Wanneer alles gereed is, voert het systeem een failover uit met een korte downtime, meestal minder dan 10 seconden.
Opschonen van oud SQL-exemplaar Hiermee verwijdert u het oude SQL-proces uit het virtuele broncluster.
Verwijderen van virtuele cluster Als dit het laatste exemplaar in het bronsubnet is, verwijdert de laatste stap het virtuele cluster synchroon. Anders wordt het virtuele cluster asynchroon gedefragmenteerd.

Een gedetailleerde uitleg van de bewerkingsstappen vindt u in het overzicht van beheerbewerkingen van Azure SQL Managed Instance

Het exemplaar verplaatsen

Een verplaatsing van een subnetexemplaren maakt deel uit van de updatebewerking van het exemplaar. Bestaande API voor het bijwerken van exemplaren, Azure PowerShell en Azure CLI-opdrachten zijn uitgebreid met een eigenschap subnet-id.

Gebruik in Azure Portal het subnetveld op de blade Netwerken om het exemplaar naar het doelsubnet te verplaatsen. Wanneer u Azure PowerShell of de Azure CLI gebruikt, geeft u een andere subnet-id op in de updateopdracht om het exemplaar van een bestaand subnet naar het doelsubnet te verplaatsen.

Zie beheer-API-naslaginformatie voor Azure SQL Managed Instance voor een volledig overzicht van opdrachten voor exemplaarbeheer.

De optie voor het kiezen van het subnet van het exemplaar bevindt zich op de blade Netwerken van Azure Portal. De verplaatsingsbewerking van het exemplaar wordt gestart wanneer u een subnet selecteert en uw wijzigingen opslaat.

De eerste stap van de verplaatsingsbewerking is het voorbereiden van het doelsubnet voor implementatie, wat enkele minuten kan duren. Zodra het subnet gereed is, wordt de beheerbewerking voor het verplaatsen van exemplaren gestart en wordt deze zichtbaar in Azure Portal.

How to select subnet on SQL Managed Instance networking blade

Bewaak bewerkingen voor het verplaatsen van exemplaren vanaf de blade Overzicht van Azure Portal. Selecteer de melding om een extra blade te openen met informatie over de huidige stap, de totale stappen en een knop om de bewerking te annuleren.

Screenshot shows the Overview page where you can monitor the move operation and cancel it.

Volgende stappen