Delen via

Onderhoudsvenster in Azure SQL Managed Instance

Van toepassing op:Azure SQL Managed Instance

Met de onderhoudsvensterfunctie kunt u onderhoudsschema's configureren voor Azure SQL Managed Instance-resources , waardoor impactvolle onderhoudsevenementen voorspelbaar en minder verstorend zijn voor uw workload.

Opmerking

De onderhoudsvensterfunctie beschermt alleen tegen geplande gevolgen van upgrades of gepland onderhoud. Het beveiligt niet tegen alle failoveroorzaken; uitzonderingen die korte verbindingsonderbrekingen kunnen veroorzaken buiten een onderhoudsvenster, zijn hardwarefouten en andere herconfiguraties.

Met voorafgaande meldingen kunnen klanten configureren dat meldingen 24 uur van tevoren worden verzonden voor geplande gebeurtenissen.

Overzicht

Azure voert periodiek gepland onderhoud uit van sql Managed Instance-resources. Tijdens een onderhoudsbeurt zijn beheerde SQL-exemplaren volledig operationeel, maar kunnen korte herconfiguraties worden uitgevoerd binnen de SLA's (Service Level Agreements) voor SQL Managed Instance.

Onderhoudsvenster is bedoeld voor productieworkloads die niet bestand zijn tegen herconfiguraties van exemplaren en die geen korte verbindingsonderbrekingen kunnen absorberen die worden veroorzaakt door geplande onderhoudsevenementen. Door een onderhoudsvenster te kiezen dat u wilt, kunt u de impact van gepland onderhoud minimaliseren door deze buiten uw piekuren te plannen. Tolerante workloads en niet-productieworkloads kunnen afhankelijk zijn van het standaardonderhoudsbeleid van Azure SQL.

Het onderhoudsvenster is gratis en kan worden geconfigureerd bij het maken of voor bestaande resources. Deze kan worden geconfigureerd met behulp van Azure Portal, PowerShell, CLI of Azure API.

Belangrijk

Het configureren van het onderhoudsvenster is een langdurige asynchrone bewerking, vergelijkbaar met het wijzigen van de servicelaag van de Azure SQL-resource. De resource is beschikbaar tijdens de bewerking, behalve een korte herconfiguratie die plaatsvindt aan het einde van de bewerking en duurt meestal maximaal 8 seconden, zelfs in geval van onderbroken langlopende transacties. Als u de gevolgen van de herconfiguratie wilt minimaliseren, moet u de bewerking buiten de piekuren uitvoeren.

Meer voorspelbaarheid krijgen met onderhoudsvenster

Standaard blokkeert azure SQL-onderhoudsbeleid de meest impactvolle updates gedurende de periode 8:00 tot 17:00 uur lokale tijd elke dag om onderbrekingen tijdens typische piekuren te voorkomen. Lokale tijd wordt bepaald door de locatie van Azure-regio die als host fungeert voor de resource en mogelijk zomertijd bekijkt in overeenstemming met de lokale tijdzonedefinitie.

Tijdens onderhoud blijven databases beschikbaar, maar voor sommige updates is mogelijk een failover vereist. Het standaardonderhoudsvenster van het systeem (17:00 tot 8:00 uur) beperkt de meeste activiteiten tot nu toe, maar er kunnen dringende updates buiten plaatsvinden. Selecteer een niet-standaardoptie om ervoor te zorgen dat alle updates alleen worden uitgevoerd tijdens het onderhoudsvenster.

U kunt het venster voor onderhoudsupdates aanpassen aan een tijd die geschikt is voor uw Azure SQL-resources door te kiezen uit twee niet-standaard onderhoudsvensters:

  • weekdag venster: 10:00 tot 18:00 uur lokale tijd, maandag - donderdag
  • Weekend venster: 10:00 tot 18:00 uur lokale tijd, vrijdag - zondag

De genoemde dagen voor onderhoud geven de begindag van een onderhoudsvenster van acht uur aan. Bijvoorbeeld: '10:00 tot 18:00 uur lokale tijd, maandag - donderdag', betekent dat de onderhoudsvensters beginnen om 10:00 uur lokale tijd op elke dag (maandag tot en met donderdag) en om 6:00 uur lokale tijd op de volgende dag (dinsdag tot en met vrijdag).

Zodra de selectie van het onderhoudsvenster is gemaakt en de serviceconfiguratie is voltooid, vindt gepland onderhoud alleen plaats tijdens het venster van uw keuze. Hoewel onderhoudsgebeurtenissen doorgaans binnen één venster worden voltooid, kunnen sommige van deze gebeurtenissen twee of meer aangrenzende vensters omvatten.

Belangrijk

Azure SQL Managed Instance volgt een veilige implementatiepraktijk waarbij gekoppelde Azure-regio's gegarandeerd niet tegelijkertijd worden geïmplementeerd. Het is echter niet mogelijk om te voorspellen welke regio eerst wordt geüpgraded, dus de volgorde van de implementatie is niet gegarandeerd. Soms wordt uw primaire exemplaar eerst geüpgraded en soms zou dit secundair zijn.

  • In situaties waarin uw beheerde SQL-exemplaar failovergroepen heeft en de groepen niet zijn afgestemd op de koppeling met de Azure-regio, moet u verschillende onderhoudsvensterschema's kiezen voor uw primaire en secundaire beheerde SQL-exemplaar. U kunt bijvoorbeeld het onderhoudsvenster voor weekdagen selecteren voor uw geo-secundaire exemplaar en het onderhoudsvenster voor het weekend voor uw geo-primaire beheerde SQL-exemplaar.

  • In zeer zeldzame gevallen waarin een uitstellen van de actie ernstige gevolgen kan hebben, zoals het toepassen van een kritieke beveiligingspatch, kan het geconfigureerde onderhoudsvenster tijdelijk worden overschreven.

Meldingen vooraf

Onderhoudsmeldingen kunnen worden geconfigureerd om u te waarschuwen over geplande onderhoudsgebeurtenissen voor uw Azure SQL Managed Instance. De waarschuwingen komen 24 uur van tevoren binnen, voordat het onderhoudsvenster wordt geopend en aan het einde van het onderhoudsvenster. Zie Geavanceerde meldingenvoor meer informatie.

Beschikbaarheid van functies

Ondersteunde abonnementstypen

Het configureren en gebruiken van onderhoudsvensters is beschikbaar voor de volgende aanbiedingstypen: Betalen per gebruik, Cloud Solution Provider (CSP), Microsoft Enterprise Agreement of Microsoft-klantovereenkomst.

Aanbiedingen die zijn beperkt tot het gebruik van ontwikkelen/testen komen niet in aanmerking (zoals betalen per gebruik Dev/Test of Enterprise Dev/Test als voorbeelden).

Opmerking

Een Azure-aanbieding is het type Azure-abonnement dat u hebt. Een abonnement met tarieven voor betalen per gebruik, Azure in Openen Visual Studio Enterprise- zijn bijvoorbeeld allemaal Azure-aanbiedingen. Elke aanbieding of elk abonnement heeft verschillende voorwaarden en voordelen. Uw aanbieding of abonnement wordt weergegeven in het overzicht van het abonnement. Zie Uw Azure-abonnement wijzigen in een andere aanbiedingvoor meer informatie over het overschakelen van uw abonnement naar een andere aanbieding.

Ondersteunde serviceniveaudoelstellingen

Het kiezen van een ander onderhoudsvenster dan de standaardinstelling is beschikbaar voor alle SLO's , met uitzondering van Azure SQL Managed Instance-pools.

Ondersteuning voor Azure SQL Managed Instance-onderhoudsvensters in regio's

Het kiezen van een onderhoudsvenster voor een ander beheerd exemplaar van Azure SQL dan de standaardinstelling is beschikbaar in alle regio's.

Gatewayonderhoud

In Azure SQL Managed Instance worden de gatewayknooppunten gehost in het virtuele cluster en hebben ze hetzelfde onderhoudsvenster als het beheerde SQL-exemplaar.

Belangrijk

Het omleidingsverbindingsbeleid wordt aanbevolen om het aantal onderbrekingen tijdens de onderhoudsbeurtenis te minimaliseren. Zie verbindingstypen.

Overwegingen voor Azure SQL Managed Instance

Azure SQL Managed Instance bestaat uit serviceonderdelen die worden gehost op een toegewezen set geïsoleerde virtuele machines die worden uitgevoerd in het subnet van het virtuele netwerk van een klant. Deze virtuele machines zijn ingedeeld in groepen om een virtueel cluster te vormen dat meerdere beheerde exemplaren kan hosten. Aangezien een onderhoudsvenster dat is geconfigureerd voor exemplaren in hetzelfde subnet, invloed kan hebben op het aantal virtuele-machinegroepen binnen het virtuele cluster en beheerbewerkingen voor virtuele clusters, zijn er enkele dingen die u moet overwegen voordat u het onderhoudsvenster configureert.

Configuratie van onderhoudsvensters is een langdurige bewerking

Alle exemplaren die in dezelfde virtuele-machinegroep worden gehost, delen hetzelfde onderhoudsvenster. Standaard worden alle beheerde exemplaren gehost in een groep met een standaardonderhoudsvenster. Als u een ander onderhoudsvenster opgeeft terwijl u het exemplaar maakt of nadat het al is gemaakt, wordt het exemplaar in een afzonderlijke computergroep geplaatst met een bijbehorend onderhoudsvenster. Als er geen dergelijke groep in het cluster bestaat, wordt er een nieuwe gemaakt voor de nieuwe configuratie van het exemplaar. Als u extra exemplaren in het virtuele cluster configureert om hetzelfde onderhoudsvenster te gebruiken, worden deze exemplaren ook toegevoegd aan de groep, wat betekent dat de groep mogelijk moet worden aangepast. Als u exemplaren toevoegt aan een nieuwe machinegroep en het formaat van bestaande machinegroepen wijzigt, kan de duur van de bewerking worden verhoogd om een onderhoudsvenster te configureren.

De verwachte duur voor het configureren van een onderhoudsvenster voor een beheerd exemplaar kan worden berekend met behulp van de geschatte duur van exemplaarbeheerbewerkingen.

Belangrijk

Wanneer u een onderhoudsvenster configureert, vereist de laatste stap van de bewerking een herconfiguratie van het exemplaar dat doorgaans maximaal 8 seconden duurt, zelfs als deze langlopende transacties onderbreekt. Als u de impact wilt minimaliseren, configureert u een onderhoudsvenster buiten piekuren.

Vereisten voor IP-adresruimte

Voor elke nieuwe virtuele-machinegroep in een subnet zijn extra IP-adressen vereist op basis van de toewijzing van het IP-adres van het virtuele cluster. Het wijzigen van een onderhoudsvenster voor een bestaand beheerd exemplaar vereist ook tijdelijke extra IP-capaciteit, vergelijkbaar met bij het schalen van het aantal vCores voor de respectieve servicelaag.

IP-adreswijziging

Wanneer u een onderhoudsvenster configureert of wijzigt, wordt het IP-adres van de instantie gewijzigd naar een ander IP-adres binnen het IP-adresbereik van het subnet.

Belangrijk

Zorg ervoor dat netwerkbeveiligingsgroep (NSG) en firewallregels het gegevensverkeer niet blokkeren nadat een IP-adres is gewijzigd.

Serialisatie van beheerbewerkingen voor virtuele clusters

Bewerkingen die van invloed zijn op het virtuele cluster, zoals serviceupgrades of het wijzigen van het formaat van het virtuele cluster (zoals het toevoegen van nieuwe of het verwijderen van ongebruikte rekenknooppunten), worden geserialiseerd. Een nieuwe bewerking voor een virtueel cluster kan daarom pas worden gestart als de vorige bewerking is voltooid. Als het onderhoudsvenster wordt gesloten voordat de lopende onderhoudsbewerking is voltooid, wordt de lopende onderhoudsbewerking in bewaring geplaatst tot het volgende onderhoudsvenster. Andere beheerbewerkingen die tijdens die periode worden ingediend, worden ook in bewaring geplaatst en hervat tijdens of na het volgende onderhoudsvenster nadat de oorspronkelijke lopende onderhoudsbewerking is voltooid. Het is niet gebruikelijk dat een onderhoudsbewerking langer duurt dan één onderhoudsvenster per virtuele-machinegroep binnen een cluster, maar dit kan gebeuren voor zeer complexe onderhoudsbewerkingen.

De serialisatie van beheerbewerkingen voor virtuele clusters is een algemeen gedrag dat ook van toepassing is op het standaardonderhoudsbeleid. Wanneer u een onderhoudsvensterschema configureert, kan de periode tussen twee aangrenzende vensters enkele dagen lang zijn. Hoewel het zelden voorkomt, als de onderhoudsbewerking twee vensters omvat, kunnen nieuw ingediende bewerkingen enkele dagen worden uitgesteld, waardoor mogelijk bewerkingen worden geblokkeerd waarvoor extra rekenknooppunten nodig zijn, zoals het maken van een nieuwe instantie of het wijzigen van het formaat van een bestaande instantie.

Lijst met onderhoudsevenementen ophalen

Azure Resource Graph is een Azure-service die is ontworpen om Azure Resource Management uit te breiden. Azure Resource Graph Explorer biedt efficiënte en krachtige resourceverkenning met de mogelijkheid om query's op schaal uit te voeren voor een bepaalde set abonnementen, zodat u uw omgeving effectief kunt beheren.

U kunt De Azure Resource Graph Explorer gebruiken om query's uit te voeren op onderhoudsevenementen. Zie Quickstart: Uw eerste Resource Graph-query uitvoeren met behulp van Azure Resource Graph Explorervoor een inleiding over het uitvoeren van deze query's.

Als u wilt controleren op de onderhoudsgebeurtenissen voor alle met SQL beheerde exemplaren in uw abonnement, gebruikt u de volgende voorbeeldquery in Azure Resource Graph Explorer:

servicehealthresources
| where type =~ 'Microsoft.ResourceHealth/events'
| extend impact = properties.Impact
| extend impactedService = parse_json(impact[0]).ImpactedService
| where  impactedService =~ 'SQL Managed Instance'
| extend eventType = properties.EventType, status = properties.Status, description = properties.Title, trackingId = properties.TrackingId, summary = properties.Summary, priority = properties.Priority, impactStartTime = todatetime(tolong(properties.ImpactStartTime)), impactMitigationTime = todatetime(tolong(properties.ImpactMitigationTime))
| where eventType == 'PlannedMaintenance'
| order by impactStartTime desc

Ga naar Azure Resource Graph-voorbeeldquery's voor Azure Service Healthvoor een volledig overzicht van de voorbeeldquery's en hoe u deze kunt gebruiken voor hulpprogramma's zoals PowerShell of Azure CLI.

Verwante inhoud

  • Last updated on