Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Van toepassing op:
Azure SQL Managed Instance
In dit artikel wordt uitgelegd hoe u Azure SQL Managed Instance verplaatst van het ene subnet naar het andere subnet in hetzelfde virtuele netwerk of een ander virtueel netwerk. De bewerking is vergelijkbaar met het schalen van vCores of het wijzigen van de servicelaag van het exemplaar. Tijdens de verplaatsing blijft SQL Managed Instance beschikbaar, met uitzondering van een korte downtime wanneer de failover plaatsvindt, 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.
Vereisten en beperkingen
U moet SQL Managed Instance implementeren in een toegewezen subnet in een virtueel Azure-netwerk. De grootte van het subnet (subnetbereik) bepaalt hoeveel beheerde SQL-exemplaren u binnen het subnet kunt uitrollen. Als u een met SQL beheerd exemplaar wilt implementeren of naar een ander subnet wilt verplaatsen, moet het doelsubnet voldoen aan bepaalde netwerkvereisten.
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. U kunt deze beheerbewerkingen bewaken .
Gereedheid van subnet
Controleer voordat u het beheerde SQL-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 met SQL beheerd exemplaar gecategoriseerd als Gereed voor beheerd exemplaar. Virtuele netwerken met subnetten met sql managed instances die al 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 met SQL 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. Als u wilt weten waarom het subnet niet gereed is en of het subnet aan de netwerkvereisten kan voldoen, gebruikt u het infopictogram rechts van de naam van het subnet. Deze vereisten omvatten:
- delegeren aan de
Microsoft.Sql/managedInstancesresourceprovider - een routetabel koppelen
- een netwerkbeveiligingsgroep koppelen
Als het subnet deel uitmaakt van een ander virtueel netwerk, hebt u het volgende nodig:
- Bidirectionele peering tussen het huidige virtuele netwerk en het doelnetwerk.
- Huidige en doelsubnetten maken gebruik van afzonderlijke routetabellen en netwerkbeveiligingsgroepen.
Nadat u aan deze vereisten hebt voldaan, wordt het subnet verplaatst van de categorie Niet gereed naar de categorie Gereed voor beheerd exemplaar en kan het worden gebruikt voor een met SQL beheerd exemplaar.
Subnetten die al in gebruik zijn (subnetten die worden gebruikt voor exemplaarimplementaties kunnen geen andere resources bevatten) of subnetten met 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 correcties aangebracht. Deze subnetten bevatten al beheerde SQL-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 regels toe die nodig zijn, maar ontbreken. Aangepaste regels die u aan de configuratie van het bronsubnet toevoegt, worden niet gekopieerd naar het doelsubnet. U moet elke aanpassing van de configuratie van het bronsubnet handmatig repliceren naar het doelsubnet. Een manier om deze replicatie 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:
U kunt SQL Managed Instance verplaatsen naar een subnet dat een van de volgende opties is:
- In hetzelfde virtuele netwerk als het huidige gebruikte netwerk, of
- 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 is van toepassing als u van plan bent om over te stappen op een niet-mptig subnet.
U kunt het doelsubnet speciaal voorbereiden om de DNS-zone van het door SQL beheerde exemplaar te behouden dat u verplaatst. Bereid het subnet voor door een nieuw met SQL beheerd exemplaar te maken in een leeg subnet en de
dnsZonePartnerparameter op te geven in de create-aanvraag. 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 subnet zou worden verplaatst.Afgezien van deze benadering is er geen andere manier om de DNS-zone van SQL Managed Instance te dicteren, omdat deze willekeurig wordt gegenereerd. Op dit moment is er 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 SQL-exemplaar (het subnet dat de failovergroepreplica 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. U wilt MI1 verplaatsen naar subnet S3. Subnet S3 kan geen overlappend adresbereik met subnet S2 hebben.
Zie Geo-replicatie tussen met SQL beheerde exemplaren inschakelen voor meer informatie over het configureren van het netwerk voor failovergroepen.
Bewerkingsstappen
Het verplaatsen van een exemplaar van het ene subnet naar het andere omvat veel stappen. Afhankelijk van hoe uw met SQL beheerde exemplaar is geconfigureerd, kan de verplaatsingsbewerking 30 minuten tot 6 uur duren.
In de volgende tabel worden de stappen beschreven die plaatsvinden tijdens het verplaatsen van een exemplaar:
| Stapnaam | Beschrijving van stap |
|---|---|
| Aanvraagvalidatie | Valideert de ingediende parameters. Als er een onjuiste configuratie wordt gedetecteerd, mislukt de bewerking met een fout. |
| Resizen of aanmaken van een virtueel cluster | Afhankelijk van de status van het doelsubnet wordt het virtuele cluster gemaakt of aangepast. |
| Nieuwe instantie opstarten | Het SQL-proces wordt gestart op het geïmplementeerde virtuele cluster in het doelsubnet. |
| Databasebestanden seeden of databasebestanden bijvoegen | Afhankelijk van de servicelaag wordt de database geseed of worden de databasebestanden bijgevoegd. |
| Failover en failover voorbereiden | Nadat gegevens zijn geseed of databasebestanden opnieuw zijn gekoppeld, bereidt het systeem zich voor op failover. Wanneer alles klaar is, voert het systeem een failover uit met een korte downtime, meestal minder dan 10 seconden. |
| Oude SQL-instantie opschonen | Hiermee verwijdert u het oude SQL-proces uit het virtuele broncluster. |
| Verwijderen van virtueel 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. |
Zie De duur van beheerbewerkingen in Azure SQL Managed Instance voor een gedetailleerde uitleg van de bewerkingsstappen.
Het exemplaar verplaatsen
Een exemplaarverplaatsing over subnets maakt deel uit van de updatebewerking van het exemplaar. Bestaande api voor het bijwerken van exemplaren, Azure PowerShell en Azure CLI-opdrachten worden uitgebreid met een eigenschap subnet-id.
Gebruik in Azure Portal het subnetveld in het deelvenster 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 voor een volledig overzicht van opdrachten voor exemplaarbeheer de Managed API-naslaginformatie voor Azure SQL Managed Instance.
U kunt het exemplaarsubnet kiezen in het deelvenster Netwerken van Azure Portal. Zodra u een subnet hebt geselecteerd en uw wijzigingen hebt opgeslagen, wordt de verplaatsingsbewerking van de instantie gestart.
De verplaatsingsbewerking bereidt eerst het doelsubnet voor op de implementatie. Dit kan enkele minuten duren. Nadat het subnet gereed is, wordt de beheerbewerking voor het verplaatsen van exemplaren gestart en weergegeven in Azure Portal.
U kunt de verplaatsingsbewerkingen van exemplaren bewaken vanuit het deelvenster Overzicht van de Azure Portal. Selecteer de melding om een ander deelvenster te openen dat informatie bevat over de huidige stap, de totale stappen en een knop om de bewerking te annuleren.
