Delen via

Overzicht van beheerbewerkingen in Azure SQL Managed Instance

Van toepassing op:Azure SQL Managed Instance

Dit artikel bevat een overzicht van de verschillende bewerkingen die optreden bij het beheren van Azure SQL Managed Instance. Beheerbewerkingen zijn bewerkingen die worden uitgevoerd op de back-end wanneer u een exemplaar maakt, bijwerkt of verwijdert.

Bekijk de duur van beheerbewerkingen voor een gedetailleerde beschrijving van de stappen en de geschatte duur van elke beheerbewerking.

Wat zijn beheerbewerkingen?

Het beheren van Azure SQL Managed Instance omvat de volgende bewerkingen:

  • Maken: De bewerkingen die optreden wanneer u voor het eerst een nieuw met SQL beheerd exemplaar maakt. Dit omvat het maken van de onderliggende virtuele machinegroep (VM) en het implementeren van het SQL Database Engine-proces.
  • Update: Bewerkingen die optreden wanneer u de eigenschappen van een bestaand met SQL beheerd exemplaar wijzigt, zoals het schalen van rekenkracht of opslag, het wijzigen van de servicelaag of het bijwerken van de exemplaarconfiguratie. Het bijwerken omvat vaak het wijzigen van het formaat van de VM-groep, het seeden van gegevens en het uitvoeren van een failover naar een nieuw SQL Database Engine-proces.
  • Verwijderen: Bewerkingen die optreden wanneer u een bestaand met SQL beheerd exemplaar verwijdert, inclusief het opschonen van resources zoals de VM-groep die is gekoppeld aan het exemplaar.

Bekijk de duur van beheerbewerkingen voor een gedetailleerde beschrijving van de stappen en de geschatte duur van elke beheerbewerking.

Beheerbewerkingen voor SQL Managed Instance worden uitgevoerd via de volgende onderliggende processen:

  • Virtuele-machinegroepbewerkingen (VM): bewerkingen die betrekking hebben op het maken en beheren van de onderliggende VM-groep die als host fungeert voor het beheerde SQL-exemplaar. Dit omvat het wijzigen van het formaat van de VM-groep, het maken van nieuwe VM-groepen en het beheren van de virtuele machines binnen die groepen.
  • Seeding: de initialisatie en synchronisatie van gegevens in SQL Database Engine-processen, meestal ter voorbereiding op een failover.
  • Failover: Bewerkingen bij het uitvoeren van een failover van verkeer naar een ander SQL Database Engine-proces, in hetzelfde proces of in een nieuwe VM-groep.

Bewerkingen van VM-groepen

Sql Managed Instance is afhankelijk van virtuele clusters om implementaties binnen virtuele Azure-netwerken te ondersteunen en isolatie en beveiliging te bieden voor klanten. Het virtuele cluster vertegenwoordigt een toegewezen set geïsoleerde virtuele machines (VM's) die zijn geïmplementeerd in het subnet van uw virtuele netwerk en georganiseerd binnen VM-groepen. In wezen leidt elk met SQL beheerd exemplaar dat is geïmplementeerd in een leeg subnet tot een nieuw virtueel cluster dat de eerste VM-groep bouwt.

Volgende beheerbewerkingen op met SQL beheerde exemplaren kunnen van invloed zijn op de onderliggende VM-groepen. Wijzigingen die van invloed zijn op de onderliggende VM-groepen kunnen van invloed zijn op de duur van beheerbewerkingen, omdat het implementeren van meer virtuele machines in het virtuele cluster gepaard gaat met een overhead die u moet overwegen wanneer u nieuwe implementaties of updates voor bestaande exemplaren plant.

Zie De architectuur van het virtuele cluster voor gedetailleerde informatie over de architectuur van het virtuele cluster.

Zaaien

Seeding speelt een cruciale rol bij de werking van Azure SQL Managed Instance, met name tijdens het instellen en repliceren van databases. Seeding is het proces waarmee gegevens worden geïnitialiseerd en gesynchroniseerd tussen SQL Database Engine-processen. Dit is een cruciaal onderdeel van exemplaarbeheer. Hoewel vaak de meest tijdrovende stap in langdurige maar succesvolle bewerkingen, dient seeding als hoeksteen voor het opzetten van een gezonde en functionele sql managed instance-omgeving.

Zie voor een geschatte duur van zaaibewerkingen De duur van beheerbewerkingen.

Het seedingproces omvat doorgaans de volgende fasen, ongeacht de servicelaag:

  • Initialisatie: Het systeem identificeert de bron- en doeldatabase en start een aantal taken die de SQL Database Engine-processen voorbereiden voor gegevensoverdracht.
  • Gegevensoverdracht: werkelijke gegevenspakketten worden overgebracht van de bron naar het doel-SQL Database Engine-proces, dat een volledige of gedeeltelijke kopie van de database bevat, afhankelijk van het scenario.
  • Synchronisatie: Zodra de initiële gegevensoverdracht is voltooid, synchroniseert het systeem alle volgende updates of wijzigingen via de replicatie van transactielogboekblokken om de gegevensintegriteit te waarborgen.
  • Validatie en voltooien: het proces wordt voltooid en het doel-SQL Database Engine-proces wordt gevalideerd om een geslaagde replicatie en seeding te bevestigen. Failover vindt plaats zodat verkeer wordt doorgestuurd naar het nieuwe SQL Database Engine-proces.

Er is geen seeding van gegevens in de servicelaag Algemeen gebruik , behalve wanneer u de servicelaag wijzigt in de servicelaag Bedrijfskritiek . Beheerbewerkingen in de servicelaag Algemeen gebruik omvatten het loskoppelen van externe opslag vanuit het oude SQL Database Engine-proces en het koppelen aan het nieuwe SQL Database Engine-proces.

Omgekeerd vereist de Bedrijfskritieke servicelaag, ontworpen voor workloads met hoge prestaties, lokale opslag en de onderlinge afhankelijkheid van reken- en opslaglagen. Daarom vereist bijna elke bewerking en elk scenario in deze servicelaag seeding om de beschikbaarheid en consistentie van gegevens te garanderen.

Of seeding al dan niet wordt geactiveerd, is afhankelijk van het specifieke scenario en de servicelaag, zoals:

  • Servicelagen algemeen gebruik en servicelagen van de volgende generatie :
    • Overstappen op de servicelaag Bedrijfskritiek : gegevens moeten worden overgebracht van de externe opslag naar de lokale opslag die wordt gebruikt in de servicelaag Algemeen gebruik.
    • Zoneredundantie in- of uitschakelen: gegevens moeten worden gekopieerd naar of van de zoneredundante regio's.
  • Bedrijfskritieke servicelaag:
    • Opslag schalen: Omdat opslag fysiek is gekoppeld aan de lokale machine, moet voor elke opslagwijziging een nieuwe VM-groep worden gemaakt, zodat gegevens van de oude machine naar de nieuwe machine moeten worden overgebracht (op alle vier replica's).
    • VCores schalen: voor elke rekenschaalbewerking moet u een nieuwe VM-groep maken, zodat gegevens van de oude machine naar de nieuwe machine moeten worden gekopieerd (op alle vier replica's).
    • Venster voor hardware- of onderhoudwijziging: Als er al een VM-groep in het subnet bestaat met een overeenkomende configuratie, wordt de grootte van die VM-groep aangepast. Als dit een nieuwe configuratie is, wordt er een nieuwe VM-groep gemaakt. Gegevens moeten worden gekopieerd van de oude VM-groep naar de nieuwe VM-groep (op alle vier replica's).
    • Servicelaag wijzigen: gegevens moeten worden gekopieerd van lokale opslag naar de externe opslag die wordt gebruikt in de servicelaag Algemeen gebruik.
    • Zoneredundantie in- of uitschakelen: gegevens moeten worden gekopieerd naar of van de zoneredundante regio's.

Zaaien-snelheden

De volgende factoren zijn van invloed op de duur van het seedingproces:

  • Databasegrootte: voor grotere databases is meer tijd nodig om gegevens over te dragen en te synchroniseren tussen SQL Database Engine-processen.
  • Netwerkafhankelijkheden: netwerkbandbreedte en latentie kunnen de seedingsnelheden aanzienlijk beïnvloeden.
  • Back-up- en herstelbewerkingen: lopende back-upbewerkingen in het bronproces van de SQL Database Engine kunnen invloed hebben op het voorbereiden van gegevens die naar een ander SQL Database Engine-proces moeten worden verzonden.
  • Werkbelasting van de instantie: De werkbelasting tijdens het seeden kan vertraging veroorzaken en het proces ernstig verlengen.

Hoewel de meeste van deze factoren buiten uw controle vallen, kunt u exemplaarverkeer beheren om seedingsnelheden aanzienlijk te optimaliseren. Seeding maakt gebruik van dezelfde rekencapaciteit die het verkeer tussen instanties beheert. Intensief verkeer tijdens het zaaiproces kan de beschikbaarheid van vCores verminderen, wat leidt tot onvoldoende capaciteit, waardoor throttling optreedt.

Veel verkeer tijdens seeding kan van invloed zijn op synchronisatie, omdat seeding is ontworpen om alle momenteel opgeslagen gegevens in één bewerking te verpakken en over te dragen. Volgende gegevenswijzigingen in het oude SQL Database Engine-proces dat binnenkomt nadat seeding is gestart, moeten stapsgewijs worden gesynchroniseerd met het nieuwe SQL Database Engine-proces via replicatie van transactielogboeken voordat failover kan plaatsvinden. Als het exemplaar zwaar wordt belast, kan seeding moeite hebben met het bijhouden van binnenkomende gegevens, wat leidt tot vertragingen en mogelijke fouten in de synchronisatiefase. Continu hoog verkeer op het oude SQL Database Engine-proces nadat seeding is gestart, kan leiden tot een situatie waarbij de synchronisatiefase nooit wordt voltooid, omdat nieuwe gegevens blijven binnenkomen en moeten worden overgedragen. Dit kan resulteren in een permanente cyclus van gegevensoverdracht die failover naar het nieuwe SQL Database Engine-proces voorkomt.

Zie voor een geschatte duur van zaaibewerkingen De duur van beheerbewerkingen.

Azure-infrastructuur en kennisgevingen

Seeding is een proces dat niet nauwkeurig kan worden gekwantificeerd of strikt voorspeld, omdat het afhankelijk is van de gedeelde Azure-services. De gegevensoverdracht- en seedingbewerkingen zijn afhankelijk van verschillende interne Azure-services en -infrastructuur, die worden gedeeld in het hele Azure-ecosysteem. Deze services worden gebruikt door tal van andere niet-gerelateerde services in Azure. Alle services binnen het Azure-ecosysteem concurreren voor beschikbare resources, wat leidt tot fluctuaties in tijdelijke beschikbaarheid die worden beïnvloed door meerdere factoren. Hoewel Microsoft een bereik kan bieden waarin de capaciteit van de infrastructuur werkt, is het lastig om nauwkeurige voorspellingen te doen.

Overgang bij uitval

Failover van exemplaren is het moment waarop verkeer wordt gerouteerd van een oud SQL Database Engine-proces naar een nieuw SQL Database Engine-proces binnen de groep knooppunten in een VM-groep die het beheerde SQL-exemplaar omvat. Failover is een cruciaal onderdeel van de meeste beheerbewerkingen, met name bij het bijwerken van een instantie. Het korte moment van verbroken verbindingen terwijl verkeer wordt omgeleid naar het nieuwe SQL Database Engine-proces wordt failover genoemd.

Uw exemplaar is alleen niet beschikbaar tijdens een failover, wanneer verkeer wordt omgeleid naar het nieuwe SQL Database Engine-proces. In de servicelaag Bedrijfskritiek is uw exemplaar maximaal 20 seconden niet beschikbaar, terwijl uw exemplaar in de servicelaag Algemeen gebruik maximaal 2 minuten niet beschikbaar is. Back-endbewerkingen die zich voorbereiden op failover vanwege een beheerbewerking, zoals het opnieuw verzenden van databases in de servicelaag Bedrijfskritiek , vinden op de achtergrond plaats en hebben geen invloed op de beschikbaarheid van uw exemplaar.

Architectuurverschillen tussen servicelagen worden uitgebreid beschreven in beschikbaarheid.

Wederzijdse impact van beheerbewerkingen

Beheerbewerkingen op een met SQL beheerd exemplaar kunnen van invloed zijn op de beheerbewerkingen van andere exemplaren die in hetzelfde subnet zijn geplaatst:

  • Langdurige herstelbewerkingen in een virtueel cluster onderbreken andere bewerkingen in hetzelfde virtueel cluster, zoals maken of schaalbewerkingen.

    Voorbeeld: Als er een langdurige herstelbewerking is en ook een schaalaanvraag waarmee de VM-groep wordt verkleind, duurt het langer om de aanvraag voor verkleinen te voltooien wanneer wordt gewacht totdat de herstelbewerking is voltooid voordat de bewerking kan worden voortgezet.

  • Een volgende instantie-aanmaak- of schaalbewerkingen wordt gepauzeerd door een eerder gestarte instantie-aanmaak of schaalaanpassing die de hergrotering van de VM-groep heeft geactiveerd.

    Voorbeeld: Als er meerdere aanvragen voor maken en/of schalen in hetzelfde subnet onder dezelfde VM-groep staan en een van deze aanvragen het formaat van een VM-groep wijzigt, worden alle aanvragen die 5+ minuten na de eerste bewerkingsaanvraag zijn ingediend langer dan verwacht, omdat deze aanvragen moeten wachten totdat de grootte is voltooid voordat de grootte wordt hervat.

  • Bewerkingen voor maken/schalen die in een venster van 1 minuut worden ingediend , worden in batches uitgevoerd en parallel uitgevoerd.

    Voorbeeld: Er wordt slechts één virtueel clusterresize uitgevoerd voor alle operaties die binnen een tijdsvenster van 1 minuut worden ingediend (gemeten vanaf het moment dat de eerste aanvraag wordt ingediend). Als een andere aanvraag meer dan 1 minuut nadat de eerste aanvraag is ingediend, wacht deze totdat de grootte van het virtuele cluster is gewijzigd voordat de uitvoering wordt gestart.

Belangrijk

Beheerbewerkingen die in bewaring worden geplaatst vanwege een andere bewerking die wordt uitgevoerd, worden automatisch hervat zodra aan de voorwaarden is voldaan om door te gaan. Er is geen gebruikersactie nodig om de tijdelijk onderbroken beheerbewerkingen te hervatten.

Beheerbewerkingen bewaken

Zie Beheerbewerkingen van Azure SQL Managed Instance bewaken voor meer informatie over het volgen van de voortgang en status van beheerbewerkingen.

Beheerbewerkingen annuleren

Zie Beheerbewerkingen van Azure SQL Managed Instance annuleren voor meer informatie over het annuleren van beheerbewerkingen.

Verwante inhoud