Wartung für VMs in Azure

Gilt für: ✔️ Virtuelle Linux-Computer ✔️ Virtuelle Windows-Computer ✔️ Flexible Skalierungsgruppen ✔️ Einheitliche Skalierungsgruppen

Azure aktualisiert seine Plattform regelmäßig, um die Zuverlässigkeit, Leistung und Sicherheit der Hostinfrastruktur für virtuelle Computer zu verbessern. Der Zweck dieser Updates reicht von Patches für Softwarekomponenten in der Hostumgebung über Upgrades für Netzwerkkomponenten bis hin zur Außerbetriebsetzung von Hardware.

Updates wirken sich kaum auf die gehosteten virtuellen Computer aus. Wenn Updates Auswirkungen haben, wählt Azure das Verfahren mit den geringsten Auswirkungen für Updates aus:

• Wenn die Aktualisierung keinen Neustart erfordert, wird die VM angehalten, während der Host aktualisiert wird, oder die VM wird live auf einen bereits aktualisierten Host migriert.

• Wenn für das Update ein Neustart erforderlich ist, benachrichtigt Azure Sie über die geplante Wartung. Azure räumt Ihnen außerdem ein Zeitfenster ein, in dem Sie die Wartung zu einem Zeitpunkt Ihrer Wahl selbst starten können. Das Selbstwartungsfenster hängt von der Art der Wartung ab:

  • Außerbetriebnahme von Hardware: Das Selbstwartungsfenster beträgt in der Regel 14 Tage.
  • Hostwartung: Das Selbstwartungsfenster beträgt in der Regel 35 Tage, es sei denn, die Wartung ist dringend.

  Azure investiert in Technologien, um die Anzahl der Fälle zu verringern, in denen geplante Plattformwartung die virtuellen Computer neu starten muss. Anweisungen zum Verwalten der geplanten Wartung finden Sie unter Behandeln geplanter Wartungsbenachrichtigungen mithilfe der Azure CLI, PowerShell oder des Portals.

Auf dieser Seite erfahren Sie, wie Azure die beiden Wartungsarten durchführt. Weitere Informationen zu ungeplanten Ereignissen (Ausfällen) finden Sie unter Verfügbarkeitsoptionen für virtuelle Computer in Azure bzw. im entsprechenden Artikel für Linux.

In einer VM können Sie mithilfe von Scheduled Events für Windows oder Linux Benachrichtigungen zu bevorstehender Wartung erhalten.

Keinen Neustart erfordernde Wartung

Die meisten Plattformupdates wirken sich nicht auf Kunden-VMs aus. Ist es nicht möglich, ein Update ohne Auswirkungen durchzuführen, wählt Azure den Updatemechanismus aus, der die geringsten Auswirkungen auf die Kunden-VMs hat.

Wenn Wartungsmaßnahmen erforderlich sind, die sich auf eine VM auswirken, muss eine VM weniger als 10 Sekunden lang angehalten werden. In seltenen Fällen – nicht häufiger als alle 18 Monate bei universellen VM-Größen – verwendet Azure einen Mechanismus, der die VM für etwa 30 Sekunden anhält. Nach jedem Anhalten wird die VM-Uhr beim Fortsetzen automatisch synchronisiert.

Wartung mit Speicherbeibehaltung funktioniert für mehr als 90% der virtuellen Azure-Computer. Es funktioniert nicht für die Serie G, L, N und H. Weitere Informationen finden Sie unter den VM-Größen, die speichererhaltende Wartung unterstützen. Azure verwendet in zunehmendem Maß Technologien zur Livemigration und bessere Mechanismen zur Erhaltung des Arbeitsspeichers, um die Anhaltedauer zu verringern.

Diese Wartungsvorgänge, die keinen Neustart erfordern, werden jeweils auf eine Fehlerdomäne angewendet. Sie werden beendet, wenn sie Integritätswarnsignale von Plattformüberwachungstools erhalten. Wartungsvorgänge, die keinen Neustart erfordern, können gleichzeitig in gekoppelten Regionen oder Verfügbarkeitszonen auftreten. Für eine bestimmte Änderung werden die Bereitstellung hauptsächlich über Verfügbarkeitszonen und über Regionenpaare sequenziert, aber es kann sich bei der Tail überlappen.

Diese Typen von Updates können sich auf einige Anwendungen auswirken. Wenn der virtuelle Computer live zu einem anderen Host migriert wird, ist einige Minuten vor dem Anhalten der VM bei einigen empfindlichen Workloads unter Umständen eine geringfügige Leistungsbeeinträchtigung feststellbar. Versuchen Sie, Scheduled Events für Windows oder Linux für solche Anwendungen zu verwenden, um die VM-Wartung vorzubereiten und Auswirkungen der Azure-Wartung zu reduzieren.

Zur besseren Kontrolle sämtlicher Wartungsaktivitäten, einschließlich Aktualisierungen ohne Auswirkungen und Neustart, können Sie eine Wartungskonfiguration erstellen. Mit einer Wartungskonfiguration können Sie Plattformupdates überspringen und diese zu einem Zeitpunkt Ihrer Wahl anwenden. Weitere Informationen finden Sie unter Verwalten von Plattformupdates mit Wartungskonfigurationen.

Livemigration

Die Livemigration erfordert keinen Neustart und behält den Arbeitsspeicherinhalt virtueller Computer bei. Sie bewirkt eine Pause oder ein Einfrieren; dies dauert in der Regel höchstens 5 Sekunden. Mit Ausnahme der Serien G, L, N und H sind alle IaaS-VMs (Infrastructure-as-a-Service) für die Livemigration geeignet. Die Livemigration ist in den meisten M-Series-SKUs verfügbar. Geeignete virtuelle Computer machen mehr als 90 Prozent der IaaS-VMs aus, die in der Azure-Flotte bereitgestellt werden.

Die Azure-Plattform löst die Livemigration in den folgenden Szenarien aus:

• Geplante Wartung
• Hardwarefehler
• Zuordnungsoptimierungen

Einige Szenarien mit geplanter Wartung nutzen die Livemigration, und Sie können Scheduled Events verwenden, um im Voraus zu wissen, wann Livemigrationsvorgänge gestartet werden.

Die Livemigration kann auch verwendet werden, um VMs zu verschieben, wenn Azure Machine Learning-Algorithmen eine ausstehende Hardwarefehler- oder VM-Zuordnungsoptimierung vorhersagen. Weitere Informationen zur Vorhersagemodellierung, die Instanzen von beeinträchtigter Hardware erkennt, finden Sie unter Improving Azure Virtual Machine resiliency with predictive ML and live migration (Verbessern der Resilienz von virtuellen Azure-Computern mit Machine Learning zur Vorhersage und Livemigration). Livemigrationsbenachrichtigungen werden im Azure-Portal in den Monitor- und Service Health-Protokollen sowie in Scheduled Events angezeigt, wenn Sie diese Dienste verwenden.

TCP-Verbindungsresilienz während der Livemigration

Anwendungen, die langlebige TCP-Verbindungen verwalten, z. B. Datenbankserver, Nachrichtenbroker und Zwischenspeicherungsebenen, können während der Livemigration Verbindungsunterbrechungen verursachen. Während die VM-Pause in der Regel unter 5 Sekunden liegt, kann das TCP-Stapelverhalten während und nach der Pause die Wiederherstellungszeit auf Anwendungsebene verlängern, wenn dies nicht behoben wird.

Auswirkungen der Livemigration auf TCP-Verbindungen:

• Während der Pause werden IN-Flight-TCP-Segmente von der migrierenden VM nicht bestätigt.
• Die Senderseite (Client oder Integritätsprüfung des Load Balancers) beginnt die TCP-Neuübertragung mit exponentiellem Backoff.
• Azure Load Balancer Standard sendet einen TCP RST an Leerlaufverbindungen, die das konfigurierte Leerlauftimeout überschreiten. Bei aktiven Verbindungen mit In-Flight-Daten sendet der Lastenausgleich während der Migrationspause jedoch keinen TCP-RST. Die Verbindung bleibt geöffnet, reagiert jedoch nicht, und der Client weist kein sofortiges Signal des Fehlers auf.
• Ohne Optimierung auf Anwendungsebene kann das standardmäßige TCP-Retransmissionsverhalten (tcp_retries2 = 15 unter Linux) die Erkennung von Verbindungsfehlern um ca. 15 Minuten verzögern.

Reduzieren Sie den Strahlradius mit Bereitstellungen mit mehreren Instanzen:

Bevor Sie Entschärfungen auf TCP-Ebene anwenden, sollten Sie die Architekturbasis berücksichtigen. Die Livemigration betrifft jeweils nur eine VM innerhalb einer Verfügbarkeitsgruppe oder einer VM-Skalierungsgruppe. Das Verteilen von Verbindungen über mehrere Back-End-Instanzen beschränkt die Auswirkungen eines einzelnen Migrationsereignisses:

• Eine Skalierungsgruppe mit drei Instanzen bedeutet, dass jedes Migrationsereignis höchstens ein Drittel der aktiven Verbindungen betrifft.
• Durch die Bereitstellung über Verfügbarkeitszonen wird sichergestellt, dass Migrationen in verschiedenen Zonen nicht überlappen.
• Clients mit Verbindungspools, die auf mehrere Backends verteilt sind, erholen sich schneller, da unbeeinträchtigte Verbindungen Anfragen sofort weiter bedienen.

Während der VM-Pause schlagen auch die Integritätsprüfungen des Azure Load Balancer Standard für das angehaltene Back-End fehl. Das Lastenausgleichsmodul markiert das Back-End innerhalb von ca. 10 Sekunden als fehlerhaft (zwei aufeinander folgende Probefehler im Standardintervall von 5 Sekunden) und beendet das Routing neuer Verbindungen. Diese Bedingung bedeutet, dass neue Verbindungen natürlich geschützt sind. Die in diesem Artikel beschriebenen TCP-Entschärfungen behandeln vorhandene Verbindungen, die bereits vor Beginn der Migration eingerichtet wurden.

Empfohlene Risikominderungsmaßnahmen:

Die folgenden Gegenmaßnahmen ergänzen sich. Bei der gemeinsamen Implementierung reduzieren sie die Auswirkungen eines Livemigrationsereignisses von Minuten potenzieller Ausfallzeiten auf Sekunden der automatischen Wiederherstellung.

Abhilfemaßnahme 1: TCP_USER_TIMEOUT (schnellste Erkennung)

TCP_USER_TIMEOUT steuert, wie lange der Kernel auf die Bestätigung der übertragenen Daten wartet, bevor eine Verbindung inaktiv deklariert wird. Durch Festlegen dieser Einstellung auf 30 Sekunden (30000 ms) pro Socket wird die Erkennungszeit erheblich reduziert.

// Per-socket (recommended)
int timeout = 30000; // 30 seconds in milliseconds
setsockopt(fd, IPPROTO_TCP, TCP_USER_TIMEOUT, &timeout, sizeof(timeout));

Alternativ können Sie die systemweite Anzahl der erneuten Übertragungen reduzieren:

# /etc/sysctl.conf — reduces retransmit ceiling to ~25-50 seconds
net.ipv4.tcp_retries2 = 5

Windows Überlegungen:

Die TCP_USER_TIMEOUT Socketoption ist spezifisch für Linux. Bei Windows wird das TCP-Retransmissionsverhalten anders gesteuert:

• Windows verwendet standardmäßig 5 Neuübertragungen (TcpMaxDataRetransmissions), die bereits ohne jegliche Anpassung eine Erkennungszeit von etwa 25–50 Sekunden bereitstellen.
• Um die Erkennungszeit für Windows weiter zu reduzieren, passen Sie die Registrierung an:

# Reduce TCP retransmissions (system-wide, requires reboot)
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters" `
    -Name "TcpMaxDataRetransmissions" -Value 3 -Type DWord

Bei TcpMaxDataRetransmissions Festlegung auf 3 reduziert sich die Erkennungszeit je nach dem anfänglichen Timeout der Erneutübertragung auf etwa 10 bis 20 Sekunden.

Abhilfemaßnahme 2: Geplante Ereignisse (proaktive Entleerung)

Der Dienst Geplante Ereignisse kündigt eine Livemigration im Voraus an. Anwendungen können auf Freeze-Ereignisse lauschen und Verbindungen proaktiv leerlaufen lassen, bevor die Pause eintritt.

GET http://169.254.169.254/metadata/scheduledevents?api-version=2020-07-01
Headers: Metadata: true

Ein Livemigrationsereignis wird angezeigt als:

{
  "EventType": "Freeze",
  "ResourceType": "VirtualMachine",
  "Resources": ["myVM"],
  "EventStatus": "Scheduled",
  "NotBefore": "2026-04-29T18:00:00Z"
}

Wenn ein Freeze Ereignis erkannt wird:

1. Beenden Sie die Annahme neuer Verbindungen auf dem betroffenen Knoten.
2. Bestehende Verbindungen abbauen (Clients signalisieren, dass sie sich mit anderen Knoten neu verbinden sollen).
3. Warten Sie, bis die laufenden Operationen mit einem festgelegten Timeout abgeschlossen sind.
4. Bestätigen Sie das Ereignis optional, indem Sie die EventId zurücksenden.

Abhilfemaßnahme 3: Optimierung der TCP-Keepalive-Einstellungen

TCP-Keepalive-Probes erkennen Verbindungen, die nach dem Migrationsereignis inaktiv werden:

net.ipv4.tcp_keepalive_time = 30      # seconds before first probe (default: 7200)
net.ipv4.tcp_keepalive_intvl = 10     # seconds between probes (default: 75)
net.ipv4.tcp_keepalive_probes = 3     # probes before declaring dead (default: 9)

Bei diesen Einstellungen wird innerhalb von 60 Sekunden eine veraltete Leerlaufverbindung erkannt (30 + 10 x 3). Keepalive Probes zählen auch als Aktivität für das Load Balancer Standard Leerlauftimeout, hindert das Lastenausgleichsmodul daran, Leerlaufverbindungen unabhängig voneinander auszublenden.

Maßnahme 4: clientseitige Wiederholungslogik

Durch erneute Verbindung und Wiederholungslogik auf Anwendungsebene wird die Wiederherstellung unabhängig von der Fehlererkennungsmethode sichergestellt:

1. Verbindungsfehler erkennen (Timeout, RST oder Verbindung verweigert).
2. Schließen Sie die inaktive Verbindung, und entfernen Sie sie aus dem Verbindungspool.
3. Öffnen Sie eine neue Verbindung mit demselben oder einem anderen Knoten.
4. Wiederholen Sie den Vorgang mit exponentiellem Backoff.

Aktivieren Sie für Datenbank-SDKs und Verbindungspools regelmäßige Integritätsprüfungen (z. B. ein einfaches Ping alle 10-15 Sekunden), um Verbindungen proaktiv zu überprüfen.

Konfiguration des Verbindungspools:

Verbindungspools, die langlebige Verbindungen beibehalten, profitieren von einer maximalen Lebensdauereinstellung. Diese Einstellung erzwingt regelmäßiges Wiederverwenden von Verbindungen und stellt sicher, dass keine einzige Verbindung ungebundenes Risiko aus zukünftigen Migrationsereignissen anhäuft:

Das Festlegen einer maximalen Lebensdauer von 30 Minuten bedeutet, dass Verbindungen selbst ohne aktive Zustandsprüfungen automatisch ausgetauscht werden, bevor sie über längere Zeit unbemerkt veralten können.

Überwachung und Beobachtbarkeit:

Verwenden Sie die folgenden Ansätze, um die Auswirkungen von Livemigrationsereignissen auf TCP-Verbindungen zu erkennen und zu messen:

• Azure Monitor Metrik für die VM-Verfügbarkeit (Vorschau): Fällt während der VM-Pause auf 0. Erstellen Sie eine Warnungsregel VmAvailabilityMetric mit einem Schwellenwert von weniger als 1, um Migrationsereignisse zu erkennen.
• Aktivitätsprotokoll für geplante Ereignisse: Ereignisse der Livemigration werden im Aktivitätsprotokoll unter dem Anbieter Microsoft.Compute mit dem Vorgangsnamen Microsoft.Compute/virtualMachines/liveMigration/action oder als Freeze-Ereignisse angezeigt, wenn sie über den Metadatendienst abgefragt werden.
• Fehlerrate der Verbindung auf Anwendungsebene: Überwachen Sie die Anzahl der TCP-Verbindungszurücksetzungen, Timeouts und die Anzahl der erneuten Verbindungen in den Anwendungsmetriken. Ein Anstieg der Verbindungsfehler, der mit einem Rückgang der VM-Verfügbarkeit korreliert, bestätigt die Auswirkungen der Migration.
• TCP-Retransmissionszähler: Unter Linux können Sie das Feld /proc/net/netstatTCPTimeouts überwachen oder ss -ti verwenden, um die Anzahl der Neuübertragungen bei einzelnen Sockets zu beobachten. Erhöhte Übertragungen während eines bekannten Wartungsfensters deuten darauf hin, dass Verbindungen betroffen waren.

# Linux: Check TCP timeout statistics
cat /proc/net/netstat | grep -i timeout
# Or per-socket retransmission info
ss -ti | grep -i retrans

Das Einrichten eines Basisplans für diese Metriken während des normalen Betriebs erleichtert die Quantifizierung der Auswirkungen von Migrationsereignissen und die Überprüfung, ob Ihre Gegenmaßnahmen erwartungsgemäß funktionieren.

Workloads ohne jegliche Toleranz für Unterbrechungen bei der Live-Migration

Für Workloads, die keinerlei Unterbrechung durch Livemigration tolerieren, sollten Sie den Einsatz von Azure Dedicated Hosts mit Wartungskonfigurationen in Betracht ziehen. Dedizierte Hosts ermöglichen Ihnen die Kontrolle darüber, wann die Wartung auf Hostebene erfolgt, wodurch Überraschungs-Livemigrationsereignisse vermieden werden.

Einen Neustart erfordernde Wartung

Im seltenen Fall, dass virtuelle Computer für eine geplante Wartung neu gestartet werden müssen, werden Sie darüber im Voraus informiert. Die geplante Wartung hat zwei Phasen: die Self-Service-Phase und eine Phase für die geplante Wartung.

Während der Self-Service-Phase, die in der Regel vier Wochen dauert, starten Sie die Wartung auf Ihren virtuellen Computern. Im Rahmen des Self-Service können Sie die einzelnen virtuellen Computer abfragen, um ihren Status zu ermitteln und die Ergebnisse Ihrer letzten Wartungsanforderung zu prüfen.

Wenn Sie die Self-Service-Wartung starten, wird Ihre VM auf einem bereits aktualisierten Knoten neu bereitgestellt. Da die VM neu bereitgestellt wird, geht der temporäre Datenträger verloren und die mit der virtuellen Netzwerkschnittstelle verbundenen öffentlichen dynamischen IP-Adressen werden aktualisiert.

Falls im Rahmen der Self-Service-Wartung ein Fehler auftritt, wird der Vorgang beendet, der virtuelle Computer wird nicht aktualisiert, und Sie erhalten die Möglichkeit, die Self-Service-Wartung erneut durchzuführen.

Wenn die Self-Service-Phase endet, beginnt die Phase der geplanten Wartung. Während dieser Phase können Sie zwar weiterhin die Wartungsphase abfragen, die Wartung aber nicht mehr selbst starten.

Weitere Informationen zum Verwalten von Wartungsvorgängen, die einen Neustart erfordern, finden Sie unter Behandlung von Benachrichtigungen der geplanten Wartung über die Azure-Befehlszeilenschnittstelle, PowerShell bzw. das Portal.

Überlegungen zur Verfügbarkeit während einer geplanten Wartung

Wenn Sie bis zur Phase für die geplante Wartung warten möchten, sollten Sie einige Dinge berücksichtigen, um eine möglichst hohe Verfügbarkeit Ihrer virtuellen Computer zu gewährleisten.

Regionspaare

Jede Azure-Region ist mit einer anderen Region innerhalb desselben geografischen Gebiets gekoppelt. Zusammen bilden sie ein Regionspaar. Während der Phase der geplanten Wartung aktualisiert Azure nur die virtuellen Computer in einer einzelnen Region eines Regionspaars. Wenn z.B. die VMs in der Region „USA, Norden-Mitte“ aktualisiert werden, aktualisiert Azure nicht gleichzeitig die VMs in der Region „USA, Süden-Mitte“. Andere Regionen wie Nordeuropa können jedoch gleichzeitig mit „USA, Osten“ gewartet werden. Sie sollten mit der Funktionsweise von Regionspaaren vertraut sein, um Ihre virtuellen Computer besser auf Regionen verteilen zu können. Weitere Informationen finden Sie unter Geschäftskontinuität und Notfallwiederherstellung: Azure-Regionspaare.

Verfügbarkeitszonen

Verfügbarkeitszonen sind eindeutige physische Standorte in einer Azure-Region. Jede Zone besteht aus mindestens einem Rechenzentrum, dessen Stromversorgung, Kühlung und Netzwerkbetrieb unabhängig funktionieren. Zur Gewährleistung der Resilienz sind in allen aktivierten Regionen mindestens drei separate Zonen vorhanden.

Eine Verfügbarkeitszone ist eine Kombination aus einer Fehlerdomäne und einer Updatedomäne. Wenn Sie drei oder mehr virtuelle Computer über drei Zonen verteilt in einer Azure-Region erstellen, werden Ihre virtuellen Computer effektiv auf drei Fehlerdomänen und drei Updatedomänen verteilt. Die Azure-Plattform erkennt diese Updatedomänen übergreifende Verteilung, um sicherzustellen, dass virtuelle Computer in unterschiedlichen Zonen nicht gleichzeitig aktualisiert werden.

Jedes Infrastrukturupdate wird innerhalb einer einzelnen Region zonenweise ausgeführt. Sie können jedoch die Bereitstellung in Zone 1 und eine andere Bereitstellung in Zone 2 gleichzeitig ausführen. Bereitstellungen werden nicht alle serialisiert. Eine einzelne Bereitstellung, die einen Neustart erfordert, wird jedoch nur für jeweils eine Zone auf einmal ausgeführt, um Risiken zu verringern. Im Allgemeinen werden Updates, die einen Neustart erfordern, vermieden, und Azure versucht, Live Migration zu verwenden oder Kundensteuerung bereitzustellen.

VM-Skalierungsgruppen

VM-Skalierungsgruppen im Orchestrierungsmodus Flexibel sind eine Azure Compute-Ressource und ermöglichen Ihnen das Kombinieren der Skalierbarkeit von VM-Skalierungsgruppen im Orchestrierungsmodus „Uniform“ (einheitlich) mit den regionalen Verfügbarkeitsgarantien von Verfügbarkeitsgruppen.

Bei der flexiblen Orchestrierung können Sie auswählen, ob Ihre Instanzen auf mehrere Zonen oder auf Fehlerdomänen innerhalb einer einzelnen Region verteilt werden.

Verfügbarkeitsgruppen und einheitliche (Uniform) Skalierungsgruppen

Wenn Sie eine Workload auf virtuellen Azure-Computern bereitstellen, können Sie die virtuellen Computer in einer Verfügbarkeitsgruppe erstellen, um die Hochverfügbarkeit der Anwendung zu erreichen. Mit Verfügbarkeitsgruppen können Sie sicherstellen, dass während eines Ausfalls oder Wartungsereignissen, die einen Neustart erfordern, mindestens ein virtueller Computer verfügbar ist.

Innerhalb einer Verfügbarkeitsgruppe werden einzelne VMs auf bis zu 20 Updatedomänen verteilt. Während einer geplanten Wartung wird zu einem gegebenen Zeitpunkt immer nur jeweils eine Updatedomäne aktualisiert. Updatedomänen werden nicht unbedingt in ihrer Reihenfolge aktualisiert.

VM-Skalierungsgruppen im Orchestrierungsmodus Uniform (einheitlich) sind eine Azure Compute-Ressource, mit der Sie eine Gruppe identischer virtueller Computer als Einzelressource bereitstellen und verwalten können. Die Skalierungsgruppe wird automatisch Updatedomänen übergreifend bereitgestellt – genau wie virtuelle Computer in einer Verfügbarkeitsgruppe. Genau wie bei Verfügbarkeitsgruppen wird auch bei einheitlichen (Uniform) Skalierungsgruppen während einer geplanten Wartung immer nur jeweils eine Updatedomäne (UD) aktualisiert.

Weitere Informationen zur Einrichtung Ihrer VMs, Hochverfügbarkeit zu erreichen, finden Sie unter Verfügbarkeitsoptionen für virtuelle Computer in Azure bzw. im entsprechenden Artikel für Linux.

Nächste Schritte

Verwenden Sie zum Verwalten der geplanten Wartung die Azure CLI, Azure PowerShell oder das Portal.