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:
- Bepaal de vereiste subnetgrootte en -bereik voor Azure SQL Managed Instance.
- Kies tussen het verplaatsen van het exemplaar naar een nieuw subnet of het gebruik van een bestaand subnet.
- Gebruik beheerbewerkingen om automatisch nieuwe beheerde exemplaren te implementeren, exemplaareigenschappen bij te werken of exemplaren te verwijderen. Het is mogelijk om deze beheerbewerkingen te bewaken .
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 .
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.
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.
Volgende stappen
- Zie de Quickstart-gids voor meer informatie over het maken van uw eerste beheerde exemplaar.
- Zie algemene SQL-functies voor een lijst met functies en vergelijkingen.
- Zie VNet-configuratie van SQL Managed Instance voor meer informatie over VNet-configuratie.
- Zie Beheerd exemplaar maken voor een quickstart waarmee u een beheerd exemplaar kunt maken en een database vanuit een back-upbestand kunt herstellen.
- Zie Migratie van SQL Managed Instance met behulp van Database Migration Service voor een zelfstudie over Azure Database Migration Service voor migratie.