Wartungsfenster in Azure SQL Managed Instance

  • Artikel

Gilt für:Azure SQL Managed Instance

Die Funktion „Wartungsfenster“ ermöglicht Ihnen das Konfigurieren von Wartungszeitplänen für Ressourcen in Azure SQL Managed Instance, sodass beeinträchtigende Wartungsereignisse vorhersehbar werden und weniger störend für Ihre Workloads sind.

Hinweis

Das Wartungsfensterfeature schützt nur vor geplanten Auswirkungen von Upgrades oder geplanten Wartungen. Es schützt jedoch nicht vor allen Failover-Ursachen, also Ausnahmen, die außerhalb eines Wartungsfensters zu kurzen Verbindungsunterbrechungen führen könnten, einschließlich Hardwarefehlern und anderen Neukonfigurationen.

Vorabbenachrichtigungen bieten dem Kunden die Möglichkeit, Benachrichtigungen so zu konfigurieren, dass sie bis zu 24 Stunden vor einem geplanten Ereignis gesendet werden.

Übersicht

Azure führt regelmäßig eine geplante Wartung von Ressourcen in SQL Managed Instance durch. Während eines Wartungsereignisses sind SQL Managed Instances voll verfügbar, können aber im Rahmen der Verfügbarkeits-Vereinbarung zum Service Level (SLA) für SQL Managed Instance kurzzeitig rekonfiguriert werden.

Das Wartungsfenster ist für Produktionsworkloads vorgesehen, die gegenüber Neukonfigurationen von Instanzen nicht resilient sind und keine kurzen Verbindungsunterbrechungen durch geplante Wartungsereignisse auffangen können. Durch die Wahl eines von Ihnen bevorzugten Wartungsfensters können Sie die Auswirkungen geplanter Wartung minimieren, indem Sie sie außerhalb Ihrer Hauptgeschäftszeiten einplanen. Stabile Workloads und Nicht-Produktions-Workloads sind möglicherweise von der Azure SQL-Standardwartungsrichtlinie abhängig.

Das Wartungsfenster ist kostenlos und kann bei der Erstellung oder für vorhandene Ressourcen konfiguriert werden. Sie kann über das Azure-Portal, PowerShell, CLI oder Azure-API konfiguriert werden.

Wichtig

Das Konfigurieren des Wartungsfensters ist ein zeitintensiver, asynchroner Vorgang, ähnlich dem Ändern der Dienstebene der Azure SQL-Ressource. Die Ressource bleibt während des Vorgangs verfügbar – mit Ausnahme einer kurzen Neukonfiguration, die am Ende des Vorgangs erfolgt und normalerweise etwa 8 Sekunden dauert (auch bei unterbrochenen zeitintensiven Transaktionen). Wenn Sie die Auswirkungen der Neukonfiguration minimieren möchten, sollten Sie den Vorgang außerhalb der Spitzenzeiten durchführen.

Mehr Vorhersehbarkeit bei Wartungsfenstern

Die meisten bedeutsamen Updates werden durch die Azure SQL-Wartungsrichtlinie standardmäßig täglich zwischen 8 und 17 Uhr Ortszeit blockiert, um Unterbrechungen während der normalen Hauptgeschäftszeiten zu vermeiden. Die Ortszeit wird durch die Azure-Region bestimmt, in der die Ressource gehostet wird, und die Sommerzeit könnte gemäß der Definition der lokalen Zeitzone berücksichtigt werden.

Während der Wartung bleiben die Datenbanken verfügbar, aber einige Aktualisierungen können einen Failover erfordern. Das Standard-Wartungsfenster des Systems (17.00 bis 8.00 Uhr) beschränkt die meisten Aktivitäten auf diese Zeit, dringende Updates können jedoch auch außerhalb dieses Zeitfensters erfolgen. Um sicherzustellen, dass alle Aktualisierungen nur während des Wartungsfensters erfolgen, wählen Sie eine andere als die Standardoption.

Sie können Fenster für Wartungsupdates weiter auf eine für Ihre Azure SQL-Ressourcen geeignete Zeit anpassen, indem Sie zwischen zwei nicht standardmäßigen Wartungsfenstern wählen:

  • Wartungsfenster Wochentag: 22 Uhr bis 6 Uhr Ortszeit, Montag bis Donnerstag
  • Wartungsfenster Wochenende: 22 Uhr bis 6 Uhr Ortszeit, Freitag bis Sonntag

In den aufgelisteten Tagen des Wartungsfensters wird der Starttag jedes achtstündigen Wartungsfensters angegeben. „22:00 Uhr bis 6:00 Uhr Ortszeit, Montag bis Donnerstag“ bedeutet beispielsweise, dass die Wartungsfenster an jedem Tag (Montag bis Donnerstag) um 22:00 Uhr Ortszeit beginnen und am folgenden Tag (Dienstag bis Freitag) um 6:00 Uhr Ortszeit abgeschlossen sind.

Nach Auswahl des Wartungsfensters und nach Abschluss der Dienstkonfiguration werden alle geplanten Wartungen nur im von Ihnen ausgewählten Wartungsfenster ausgeführt. Wartungsereignisse werden in der Regel innerhalb eines einzelnen Fensters abgeschlossen, einige Wartungsereignisse könnten sich jedoch über zwei oder mehr angrenzende Fenster erstrecken.

Wichtig

Die Azure SQL Managed Instance folgt einer sicheren Bereitstellungsmethode, bei der Azure-Regionen garantiert nicht gleichzeitig bereitgestellt werden. Es ist jedoch nicht möglich vorherzusagen, für welche Region zuerst ein Upgrade ausgeführt wird, sodass die Reihenfolge der Bereitstellung nicht garantiert werden kann. Manchmal wird das Upgrade zuerst für Ihre primäre Instanz, manchmal zuerst für die sekundäre Instanz durchgeführt.

  • In Situationen, in denen Ihre verwaltete SQL Managed Instance über Failovergruppen verfügt und die Gruppen nicht mit der Azure-Regionskopplung abgestimmt sind, sollten Sie unterschiedliche Wartungsfensterzeitpläne für Ihre primäre und sekundäre SQL Managed Instance wählen. Sie können beispielsweise das Wartungsfenster Werktag für Ihre geo-sekundäre Instanz und das Wartungsfenster Wochenende für Ihre geo-primäre SQL Managed Instance auswählen.

  • In sehr seltenen Fällen, in denen eine Verschiebung von Aktionen zu schwerwiegenden Auswirkungen führen könnte, wie z. B. das Anwenden eines wichtigen Sicherheitspatches, könnte das konfigurierte Wartungsfenster vorübergehend außer Kraft gesetzt werden.

Vorabbenachrichtigungen

Wartungsbenachrichtigungen können konfiguriert werden, damit Sie über bevorstehende geplante Wartungsereignisse für Ihre Azure SQL Managed Instance benachrichtigt werden. Die Warnungen treffen 24 Stunden vor dem Beginn des Wartungsfensters und am Ende des Wartungsfensters ein. Weitere Informationen finden Sie unter Vorabbenachrichtigungen.

Verfügbarkeit von Funktionen

Unterstützte Subscriptiontypen

Das Konfigurieren und Verwenden des Wartungsfensters ist für die folgenden Angebotstypen verfügbar: Nutzungsbasierte Bezahlung, Cloud Solution Provider (CSP), Microsoft Enterprise Agreement oder Microsoft-Kundenvereinbarung.

Angebote, die auf die Dev/Test-Nutzung beschränkt sind, sind nicht berechtigt (z. B. Dev/Test Pay-As-You-Go oder Enterprise Dev/Test).

Hinweis

Ein Azure-Angebot ist der Typ der Azure-Subscription, die Sie besitzen. Zum Beispiel handelt es sich bei Subscriptions des Typs Nutzungsbasierte Bezahlung (Pay-As-You-Go), Azure in Open und Visual Studio Enterprise insgesamt um Azure-Angebote. Jedes Angebot bzw. jeder Plan hat unterschiedliche Vorteile und unterliegt unterschiedlichen Bestimmungen. Ihr Angebot bzw. Ihr Plan wird in der Subscriptionübersicht angezeigt. Wie Sie mit Ihrer Subscription zu einem anderen Angebot wechseln können, erfahren Sie unter Ändern Ihrer Azure-Subscription in ein anderes Angebot.

Unterstützte Servicelevelziele

Die Auswahl eines anderen Wartungsfensters als des Standardfensters ist für alle SLOs außer für Azure SQL Managed Instance-Pools möglich.

Unterstützung der Azure SQL Managed Instance-Region für Wartungsfenster

Die Auswahl eines anderen Wartungsfensters für Azure SQL Managed Instance anstelle des Standardwartungsfensters ist derzeit in folgenden Regionen verfügbar:

  • Australien, Mitte 1
  • Australien, Mitte 2
  • Australien (Osten)
  • Australien, Südosten
  • Brasilien Süd
  • Brasilien, Südosten
  • Kanada, Mitte
  • Kanada, Osten
  • Indien, Mitte
  • USA (Mitte)
  • China, Osten 2
  • China, Norden 2
  • East US
  • USA (Ost) 2
  • Asien, Osten
  • Frankreich, Mitte
  • Frankreich, Süden
  • Deutschland, Westen-Mitte
  • Deutschland, Norden
  • Japan, Osten
  • Japan, Westen
  • Korea, Mitte
  • Korea, Süden
  • USA Nord Mitte
  • Nordeuropa
  • Norwegen, Osten
  • Norwegen, Westen
  • Südafrika, Norden
  • Südafrika, Westen
  • USA Süd Mitte
  • Indien (Süden)
  • Asien, Südosten
  • Schweiz, Norden
  • Schweiz, Westen
  • VAE, Mitte
  • Vereinigte Arabische Emirate, Norden
  • UK, Süden
  • UK, Westen
  • US Gov Arizona
  • US Gov Texas
  • US Government, Virginia
  • USA, Westen-Mitte
  • Europa, Westen
  • Indien, Westen
  • USA (Westen)
  • USA, Westen 2
  • USA, Westen 3

Gatewaywartung

In Azure SQL Managed Instance werden die Gateway-Knoten innerhalb des virtuellen Clusters gehostet und haben das gleiche Wartungsfenster wie die SQL Managed Instance.

Wichtig

Die Umleitungsrichtlinie wird empfohlen, um die Anzahl der Unterbrechungen während des Wartungsereignisses zu minimieren, siehe Verbindungstypen.

Hinweise zu Azure SQL Managed Instance

Azure SQL Managed Instance besteht aus Servicekomponenten, die auf einem dedizierten Satz isolierter virtueller Computer gehostet werden, die innerhalb des Subnetzes des virtuellen Netzwerks eines Kunden laufen. Diese virtuellen Computer sind in Gruppen organisiert und bilden einen virtuelle Cluster, in dem mehrere verwaltete Instanzen gehostet werden können. Da ein Wartungsfenster, das für Instanzen im selben Subnetz konfiguriert ist, die Anzahl der Gruppen virtueller Computer innerhalb des virtuellen Clusters und die Verwaltungsvorgänge des virtuellen Clusters beeinflussen kann, sind vor der Konfiguration des Wartungsfensters einige Dinge zu beachten.

Die Konfiguration des Wartungsfensters ist ein zeitintensiver Vorgang

Alle Instanzen, die in derselben Gruppe virtueller Computer gehostet werden, verwenden dasselbe Wartungsfenster. Standardmäßig werden alle verwalteten Instanzen in einer Gruppe mit einem Standard-Wartungsfenster gehostet. Wenn Sie ein anderes Wartungsfenster angeben, entweder während Sie die Instanz erstellen oder nachdem sie bereits erstellt wurde, wird die Instanz in eine separate Computergruppe mit einem entsprechenden Wartungsfenster eingeordnet. Wenn keine solche Gruppe im Cluster vorhanden ist, wird eine neue Gruppe erstellt, um die neue Konfiguration der Instanz aufzunehmen. Wenn Sie weitere Instanzen im virtuellen Cluster so konfigurieren, dass sie dasselbe Wartungsfenster verwenden, werden diese Instanzen ebenfalls der Gruppe hinzugefügt, was bedeutet, dass die Größe der Gruppe möglicherweise angepasst werden muss. Das Hinzufügen von Instanzen zu einer neuen Computergruppe und die Größenänderung bestehender Computergruppen kann die Dauer des Vorgangs zur Konfiguration eines Wartungsfensters verlängern.

Eine Orientierungshilfe zur Berechnung der erwarteten Dauer der Konfiguration des Wartungsfensters für eine verwaltete Instanz finden Sie unter Geschätzte Dauer von Verwaltungsvorgängen für Instanzen.

Wichtig

Wenn Sie ein Wartungsfenster konfigurieren, erfordert der letzte Schritt des Vorgangs eine Neukonfiguration der Instanz, die in der Regel bis zu 8 Sekunden dauert, auch wenn dadurch lange laufende Transaktionen unterbrochen werden. Um die Auswirkungen zu minimieren, konfigurieren Sie ein Wartungsfenster außerhalb der Hauptgeschäftszeiten.

Anforderungen an den IP-Adressraum

Für jede neue virtuellen Computergruppe im Subnetz sind zusätzliche IP-Adressen gemäß der IP-Adresszuordnung des virtuellen Clusters erforderlich. Die Änderung eines Wartungsfensters für eine bestehende verwaltete Instanz erfordert ebenfalls vorübergehend zusätzliche IP-Kapazität, ähnlich wie bei der Skalierung der Anzahl der virtuellen Kerne für die jeweilige Dienstebene.

Änderung der IP-Adresse

Durch die Konfiguration oder Änderung eines Wartungsfensters wird die IP-Adresse der Instanz auf eine andere IP-Adresse innerhalb des IP-Adressbereichs des Subnetzes geändert.

Wichtig

Stellen Sie sicher, dass Netzwerksicherheitsgruppe- (NSG) und Firewall-Regeln den Datenverkehr nach einer IP-Adressänderung nicht blockieren.

Serialisierung von Verwaltungsvorgängen für virtuelle Cluster

Vorgänge, die sich auf den virtuellen Cluster auswirken, wie z. B. Service-Upgrades oder die Größenänderung des virtuellen Clusters (z. B. das Hinzufügen neuer oder das Entfernen ungenutzter Serverknoten), werden serialisiert. Daher kann ein neuer virtueller Cluster-Vorgang erst gestartet werden, wenn der vorherige Vorgang abgeschlossen ist. Wenn sich das Wartungsfenster schließt, bevor die laufende Wartung abgeschlossen ist, wird die laufende Wartung bis zum nächsten Wartungsfenster zurückgestellt. Andere Verwaltungsvorgänge, die während dieser Zeit eingereicht werden, werden ebenfalls in die Warteschleife verschoben und während oder nach dem nächsten Wartungsfenster wieder aufgenommen, nachdem der ursprüngliche laufende Wartungsvorgang abgeschlossen ist. Es ist nicht üblich, dass ein Wartungsvorgang länger als ein einziges Wartungsfenster pro Gruppe virtueller Computer innerhalb eines Clusters dauert, aber bei sehr komplexen Wartungsvorgängen kann dies dennoch vorkommen.

Die Serialisierung von Verwaltungsvorgängen für virtuelle Cluster ist ein allgemeines Verhalten, das auch für die Standardwartungsrichtlinie gilt. Wenn ein Wartungsfensterplan konfiguriert wird, kann der Zeitraum zwischen zwei angrenzenden Fenstern einige Tage betragen. Dies ist zwar selten, aber wenn sich die Wartungsarbeiten über zwei Zeitfenster erstrecken, können neu eingereichte Vorgänge für mehrere Tage auf die Warteliste gesetzt werden, was möglicherweise Vorgänge blockiert, die zusätzliche Serverknoten erfordern, wie z. B. die Erstellung einer neuen oder die Größenänderung einer bestehenden Instanz.

Abrufen einer Liste mit Wartungsereignissen

Azure Resource Graph ist ein Azure-Dienst zum Erweitern der Azure-Ressourcenverwaltung. Der Azure Resource Graph-Explorer bietet eine effiziente, leistungsstarke Ressourcenuntersuchung mit der Fähigkeit, nach Bedarf für eine bestimmte Gruppe von Subscriptions Abfragen durchzuführen, sodass Vorgaben effektiv in Ihrer Umgebung durchgesetzt werden können.

Sie können den Azure Resource Graph-Explorer verwenden, um Wartungsereignisse abzufragen. Eine Einführung in das Ausführen dieser Abfragen finden Sie unter Schnellstart: Ausführen Ihrer ersten Resource Graph-Abfrage mithilfe des Azure Resource Graph-Explorers.

Um die Wartungsereignisse für alle SQL Managed Instance in Ihrer Subscription zu überprüfen, verwenden Sie die folgende Beispielabfrage im 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

Die vollständige Referenz dieser Beispielabfragen sowie Informationen zu ihrer Verwendung mit Tools wie PowerShell oder Azure CLI finden Sie unter Azure Resource Graph-Beispielabfragen für Azure Service Health.

Zugehöriger Inhalt