Neustarts der Rolleninstanz durch Azure VM-Betriebssystemupgrades

In diesem Artikel werden die Auswirkungen von Betriebssystemupgrades des virtuellen Microsoft Azure-Computers (VM) auf den Neustart von Rolleninstanzen erläutert. Es enthält Details zu Upgradezeitplänen für Betriebssystem- und Gast-Agent, Dienstwirkungen und Anforderungen, Benachrichtigungen, Erkennung und Behebung häufiger Probleme.

Aktualisieren von -Zeitplänen

Auf etwa monatlicher Basis veröffentlicht Microsoft eine neue Gastbetriebssystem-Version für Azure-Plattform as a Service (PaaS)-VMs. Der genaue Zeitplan variiert, und der historische Trend kann in den Azure-Gastbetriebssystemversionen und der SDK-Kompatibilitätsmatrix angezeigt werden. Während dieses Rollouts führt der Azure Fabric Controller zwei Übergaben durch (einen Hostbetriebssystemdurchlauf und einen Gastbetriebssystemdurchlauf) über alle Rechenzentren. Ein regelmäßiges Update des Azure-Gast-Agents wird auch innerhalb Ihrer VM ausgeführt.

Die folgenden Abschnitte enthalten weitere Details zu den beiden Upgradedurchläufen und zum Upgrade des Gast-Agents.

Pass 1: Hostbetriebssystem

Der erste Durchlauf aktualisiert das Hostbetriebssystem. Das Hostbetriebssystem startet Rolleninstanzen neu, und der Fabric-Controller stellt sicher, dass jeweils nur Instanzen aus einer Upgradedomäne neu gestartet werden. Während dieses Neustarts durchlaufen Ihre Rolleninstanzen den standardmäßigen Herunterfahrenprozess. Anschließend wird das RoleEnvironment.OnStop Ereignis ausgeführt, um Ihnen die Möglichkeit zu geben, die Instanz ordnungsgemäß herunterzufahren.

Das Hostbetriebssystemupdate kann mehrere Tage dauern, bis die Fabric die Upgrades für alle verschiedenen gehosteten Dienste und Upgradedomänen innerhalb eines Rechenzentrums koordiniert. In der Regel werden verschiedene Instanzen Ihrer Bereitstellung mehrere Stunden voneinander entfernt aktualisiert.

Weitere Informationen zum Upgradeprozess des Hostbetriebssystems finden Sie in den Azure-Hostupdates: Warum, wann und wie Azure-Blogartikel.

Pass 2: Gastbetriebssystem

Nachdem das Hostbetriebssystem das Upgrade über das Rechenzentrum abgeschlossen hat, wird das Gastbetriebssystem für Dienste aktualisiert, die für die Verwendung von automatischen Gastbetriebssystemversionen konfiguriert sind. Dieses Upgrade wird fortgesetzt, indem Standardmäßige Upgradedomänenregeln für Ihren Dienst verwendet werden. Ihre VM wird neu gestartet, und die Windows-Partition (das D-Laufwerk) wird mithilfe des aktualisierten Betriebssystems neu abbildet.

Der Aktualisierungsprozess des Gastbetriebssystems ist viel schneller als das Hostbetriebssystemupdate. Dies liegt daran, dass die Fabric nur das Update innerhalb Ihres gehosteten Diensts und Ihrer Upgradedomänen koordinieren muss. Die Dauer des Aktualisierungsprozesses des Gastbetriebssystems für Ihren Dienst hängt weitgehend von den folgenden Faktoren ab:

• Die Anzahl der Rolleninstanzen
• Die Anzahl der Upgradedomänen
• Wie viel Zeit ihr Dienst zum Herunterfahren benötigt (Stopping und OnStop Ereignisse)
• Wie viel Zeit ihr Dienst benötigt, um zu starten (Startaufgaben und das OnStart Ereignis)

Gast-Agent

Der Azure-Gast-Agent wird monatlich aktualisiert. Wenn der Gast-Agent aktualisiert wird, treten die folgenden Aktionen auf:

• Der Hostprozess, der Ihre Rolle ausführt (in der Regel WaWorkerHost oder WaWebHost), wird ordnungsgemäß heruntergefahren.
• Der Gast-Agent aktualisiert sich selbst.
• Der Hostprozess wird erneut gestartet.

Weitere Informationen zum Prozess des Gast-Agents und zur Interaktion mit Ihrem Dienst finden Sie unter Workflow der klassischen Vm-Architektur von Windows Azure.

Auswirkungen und Anforderungen des Diensts

In der folgenden Liste werden die Auswirkungen und Anforderungen für Ihren Clouddienst beschrieben:

• Wenn eine Ihrer Rollen nur eine Instanz aufweist, kann der Dienst ausfallzeiten auftreten. Sie sollten mindestens zwei Instanzen jeder Rolle haben, da für den Servicelevelvertrag (SLA) eine Betriebszeit von 99,95 Prozent erforderlich ist.

• Erwarten Sie, dass Ihre Rolleninstanzen für das Hostbetriebssystem-Update ungefähr einmal pro Monat neu gestartet werden. Wenn Sie über automatische Gastbetriebssystemupdates verfügen, erwarten Sie, dass Ihre Instanzen erneut gestartet werden. In der Regel sind die Neustarts mehrere Stunden voneinander entfernt. Dieser Zeitrahmen kann sich jedoch je nach Make-up der verschiedenen Dienste ändern, die innerhalb eines Rechenzentrums vorhanden sind.

• Ihre Rolle muss die Regeln einhalten, die Hostbetriebssystemupdates regeln. Insbesondere sollten Rolleninstanzen den Ready Status innerhalb von 30 Minuten nach dem Starten der Startaufgaben erreichen. Weitere Informationen zu dieser Einschränkung finden Sie unter Fortsetzen eines Upgrades.

• Das Hostbetriebssystemupgrade verursacht einen Neustart Ihrer Rolleninstanz, und das Gastbetriebssystemupgrade bewirkt das Äquivalent einer Neuimage Ihrer Instanz. Aufgrund dieser Ereignisse müssen Ihre Rolleninstanzen in der Lage sein, die folgenden Verfahren zu behandeln:

  • Neu starten
  • Reimaging durchführen
  • Neu starten

Benachrichtigung

Derzeit bietet die Azure-Plattform keine proaktiven Benachrichtigungen an, wenn ein Betriebssystemupgrade auftritt. Ihre Rolleninstanzen erhalten ein RoleEnvironment.Stopping Ereignis, bevor sie heruntergefahren werden. Sie können dieses Ereignis verwenden, um alle Aufgaben, die die Rolleninstanz ausführt, ordnungsgemäß zu beenden oder einen Administrator darüber zu benachrichtigen, dass eine Instanz heruntergefahren wird.

Sie können den RSS-Feed für Azure OS-Updates abonnieren. Dieser Feed sollte am selben Tag aktualisiert werden, an dem die Betriebssystemupdates beginnen, für das Rechenzentrum bereitzustellen. Der Feed gibt in der Regel keine erweiterte proaktive Benachrichtigung, hilft Ihnen jedoch, zu erkennen, wann die Updates auftreten. Der Updatevorgang kann mehrere Tage dauern. Daher müssen Sie möglicherweise einen oder mehrere Tage zwischen dem Aktualisieren des RSS-Feeds warten, und Ihr gehosteter Dienst beginnt mit der Aktualisierung.

Die Azure Guest OS Release List und die Liste der Betriebssystemversionen, die für die Auswahl in der Azure-Portal verfügbar sind, werden beide in der Regel aktualisiert, nachdem das Rollout des Gastbetriebssystems abgeschlossen wurde. Sie sollten den neuesten Eintrag in diesen Listen nicht als Hinweis verwenden, wann die Betriebssystemupdates ausgeführt werden.

Erkennung

Derzeit gibt es keine direkte Möglichkeit, ein Hostbetriebssystemupgrade zu erkennen. Sie können jedoch die Nachweise für den Neustart in den Protokollen auf dem virtuellen Computer sehen. Führen Sie dazu eine der folgenden Aktionen aus:

• Durchsuchen Sie in der Ereignisanzeige-App die Systemereignisprotokolle nach der Ereignisquelle USER32, Ereignis-ID 1074. Dieses Ereignis enthält die folgende Meldung:

  Der Prozess D:\Packages\GuestAgent\WaAppAgent.exe (RD00155D50206D) hat das Herunterfahren des Computers RD00155D50206D im Namen der NT AUTHORITY\SYSTEM des Benutzers aus dem folgenden Grund initiiert: Herunterfahren der Legacy-API

  Diese Meldung gibt an, dass der Azure Fabric-Gast-Agent (WaAppAgent.exe) ein Herunterfahren der VM initiiert hat.

• Durchsuchen Sie in einem Text-Editor eine alte App-Agent-Laufzeitprotokolldatei (AppAgentRuntime.log.old) nach einer _Context_Start Nachricht, in der der Context Wert gleich StopContainer()ist. Weitere Informationen zum Untersuchen von Kontexteinträgen im Laufzeitprotokoll des App-Agents finden Sie unter Problembehandlung von Szenario 6 – Rollenwiederverwendung nach einiger Zeit im Azure-Blogarchiv.

Allgemeine Probleme und Lösungen

In den folgenden Abschnitten werden einige häufig auftretende Probleme erläutert, bei denen Es sich um Neustarts von Rolleninstanzen handelt und wie Sie diese beheben können. Weitere Informationen zu den ausgeführten Prozessen und zum Speicherort von Protokolldateien, die Sie zur Problembehandlung verwenden können, finden Sie unter Workflow der klassischen Windows Azure-VM-Architektur.

Problem 1: Startaufgaben oder Code können nach einem Neustart des Hostbetriebssystems nicht zum zweiten Mal ausgeführt werden.

Startaufgaben oder der Code in der OnStart Oder-Funktion Run schlägt möglicherweise das zweite Mal nach einem Neustart des Hostbetriebssystems fehl. Der Neustart soll ihre Startaufgaben aufrufen, um sie erneut auszuführen. Dieser Fehler verhindert, dass die Rolleninstanz den Ready Zustand erreicht.

Was geschieht, wenn Sie etwas in einer Startaufgabe ausführen und dann einen Befehl ausführen, der nach der zweiten Ausführung einen Fehler zurückgibt? In diesem Fall schlägt die Startaufgabe fehl und führt dazu, dass Ihre Rolleninstanz wiederverwertt wird. Wenn Sie beispielsweise den Befehl "APPCMD set config" verwenden, um einen Konfigurationsabschnitt in Internetinformationsdienste (IIS) hinzuzufügen, schlägt der Befehl bei der zweiten Ausführung fehl. Der Befehl generiert die Fehlermeldung "Neues Add-Objekt fehlt erforderliche Attribute. Doppelter Sammlungseintrag vom Typ kann nicht hinzugefügt werden..." Anschließend beginnt die Rolleninstanz mit dem Recycling.

Lösung 1: Herstellen einer Verbindung mit dem virtuellen Computer und Debuggen des Start- oder Codefehlers remote

Verwenden Sie Remotedesktopprotokoll (RDP), um eine Remoteverbindung mit dem virtuellen Computer herzustellen, um diese Art von Fehlern zu beheben. Überprüfen Sie die Ereignisprotokolle auf Fehler, und überprüfen Sie die WaHostBootstrapper.log Datei auf Fehler beim Startvorgang. Während Des typischen Entwicklungs- und Testprozesses sollten Sie proaktiv einen Neustart Ihrer Rolleninstanzen aus dem Azure-Portal initiieren. Mit diesem Schritt können Sie Ihren Dienst testen, um sicherzustellen, dass er in diesem Szenario ordnungsgemäß funktioniert.

Ein gängiger Fix für Startaufgabenfehler besteht darin, am Ende des Startaufgabenskripts einen exit /b 0 Befehl hinzuzufügen. Dieser Beendigungsbefehl beendet das Skript mithilfe eines Exitcodes, der den Erfolg angibt. Weitere Informationen dazu, warum dieser Befehl erforderlich ist, finden Sie unter Konfigurieren und Ausführen von Startaufgaben für einen Azure Cloud Service (klassisch).

Problem 2: Startaufgabe oder Code wird nicht ausgeführt, nachdem die Windows-Partition umimaged wurde

Die Windows-Partition (D-Laufwerk) ist in der Regel der Ort, an dem Programminstallationen und Registrierungsänderungen gespeichert werden. Während des Gastbetriebssystems eines Updates wird die Windows-Partition neu abbilden. Dies kann dazu führen, dass diese Installationen und Änderungen verloren gehen. Wenn der Startcode versehentlich davon ausgeht, dass bestimmte Registrierungsänderungen noch vorhanden sind, nachdem die Windows-Partition neu formatiert wurde, funktioniert die Rolleninstanz möglicherweise nicht ordnungsgemäß. Dieser Fehler verhindert, dass die Rolleninstanz den Ready Zustand erreicht.

Die Startaufgabe kann z. B. eine Registrierungsänderung vornehmen. Anschließend wird ein Datensatz dieser Änderung auf dem Laufwerk C oder E gespeichert, um sicherzustellen, dass die Registrierungsänderung nicht ein zweites Mal ausgeführt wird. Die Registrierungsänderung auf dem D-Laufwerk geht jedoch aufgrund der Neuerstellung verloren, und die Startaufgabe stellt diese Registrierungsänderung nicht wieder her, da die Aufgabe nicht der Meinung ist, dass sie erforderlich ist. Die fehlende Registrierungsänderung kann schließlich dazu führen, dass der Rest der Startaufgabe fehlschlägt.

Lösung 2: Testen der Neuerstellung von Rolleninstanzen aus dem Azure-Portal

Während Ihres typischen Entwicklungs- und Testprozesses sollten Sie proaktiv eine Neuimage Ihrer Rolleninstanzen aus dem Azure-Portal initiieren. Mit diesem Schritt können Sie Ihren Dienst testen und sicherstellen, dass er in diesem Szenario ordnungsgemäß funktioniert.

Problem 3: Der Startcode dauert mehr als 30 Minuten, bis der Startvorgang abgeschlossen ist.

Wenn der Startcode mehr als 30 Minuten dauert, verfügen Sie möglicherweise über mehrere Rolleninstanzen, die nicht mehr als dienstfrei sind. Dieses Szenario tritt am häufigsten auf, wenn eine Startaufgabe eine der folgenden Aktionen ausführt:

• Installiert ein Programm oder Feature.
• Herunterladen von Cachedaten
• Download-Websiteinformationen

Lösung 3: Überprüfen der Auswirkungen und Anforderungen des Diensts

Überprüfen Sie den Abschnitt "Dienstwirkungen und Anforderungen ", um zu wissen, was Sie erwarten müssen, und wie Sie Startverzögerungen verhindern oder mindern können.

Problem 4: Azure startet den Host oder das Gastbetriebssystem nach einem Update nicht neu.

In seltenen Fällen startet Azure das Host- oder Gastbetriebssystem nach einem Update möglicherweise nicht neu. In diesem Szenario wird wahrscheinlich eine Meldung "Auf Host warten" im Portal angezeigt, die sich nach 30 Minuten oder mehr nicht ändert.

Lösung 4a: Beheben des Startcodes

Wenn Sie das Remotedesktopprotokoll (RDP) zum Herstellen einer Verbindung mit der Rolleninstanz verwenden können, tritt möglicherweise ein Fehler im Startcode auf, den Sie beheben können. Weitere Informationen zum Beheben des Startcodes finden Sie unter Lösung 1: Herstellen einer Verbindung mit dem virtuellen Computer und Debuggen des Start- oder Codefehlers remote.

Lösung 4b: Löschen der Bereitstellung

Wenn Sie RDP nicht zum Herstellen einer Verbindung mit der Rolleninstanz verwenden können, besteht wahrscheinlich die einzige Möglichkeit zum Wiederherstellen der Instanz darin, die Bereitstellung zu löschen.

Problem 5: Eine oder mehrere Rolleninstanzen sind während des Betriebssystemupgrades nicht verfügbar.

Wenn rolleninstanzen während des Betriebssystemupgrades nicht verfügbar sind, kann dies zu einer Verringerung der Dienstkapazität führen. Angenommen, Sie haben zwei Instanzen einer Webrolle, und beide Instanzen werden in der Regel bei einer CPU-Auslastung von 75 Prozent ausgeführt. Wenn eine Instanz während des Upgrades neu gestartet wird, wird der Datenverkehr an die verbleibende Instanz umgeleitet. Diese Instanz kann die zusätzliche Last nicht verarbeiten. Dies führt zu einer Verringerung der Dienstverfügbarkeit.

Lösung 5: Halten Sie genügend Überkapazitäten in Ihrem Dienst

Stellen Sie sicher, dass Ihr Dienst über ausreichende Überkapazitäten verfügt, um einen bestimmten Prozentsatz der Rolleninstanzen zu absorbieren, die nicht verfügbar sind. Um die Menge an Überkapazitäten zu berechnen, die Sie zur Verfügung stellen müssen, dividieren Sie die Zahl 1 durch die Anzahl der Upgradedomänen. Wenn Sie beispielsweise über zwei Upgradedomänen verfügen, benötigen Sie 1/2 = 50 Prozent Überkapazität, um eine Upgradedomäne zu verarbeiten, die nicht mehr verfügbar wird. Wenn Sie über fünf Upgradedomänen verfügen, benötigen Sie 1/5 = 20 Prozent Überkapazität, um den Verfügbarkeitsverlust in einer der fünf Upgradedomänen zu bewältigen.

Problem 6: Kunden erleben Ausfalle oder Timeouts, da Ihre Website zu lange dauert, um sich aufzuwärmen

Dauert das Aufwärmen Ihrer Website mehrere Minuten? (Websitewärme kann z. B. aus standardmäßigem IIS oder ASP.NET Vorkompilierung und Modulladevorgang bestehen, oder es kann ein Cache oder andere appspezifische Aufgaben aufwärmen.) In diesem Fall kann es zu einem Ausfall oder zufälligen Timeouts kommen.

Nachdem eine Rolleninstanz neu gestartet wurde und der OnStart Code die Ausführung abgeschlossen hat, wird Die Rolleninstanz in der Drehung des Lastenausgleichs wiederhergestellt. Die Rolleninstanz beginnt dann mit dem Empfangen eingehender Anforderungen. Wenn Sich Ihre Website immer noch aufwärmet, werden alle diese eingehenden Anforderungen in die Warteschlange gestellt und zeitüberschreitungen. Angenommen, Sie haben nur zwei Instanzen Ihrer Webrolle. In diesem Fall empfängt die IN_0 Instanz 100 Prozent der eingehenden Anforderungen, während die IN_1 Instanz für das Gastbetriebssystemupdate neu gestartet wird. IN_0 Die Instanz wird jedoch immer noch aufgewärmt. Dieses Szenario kann zu einem vollständigen Ausfall Ihres Diensts führen, bis Ihre Website auf beiden Instanzen aufwärmet.

Lösung 6: Verhindern, dass eine Rolleninstanz eingehende Anforderungen empfängt, bis das Warmup abgeschlossen ist

Es wird empfohlen, den OnStart Ereignisbehandlungscode für Ihre Rolleninstanz so lange abzuschließen, bis die Website den Aufwärmevorgang abgeschlossen hat. Um diesen Ereignisprozess zu implementieren, können Sie den folgenden Beispielcode verwenden:

public class WebRole : RoleEntryPoint {
    public override bool OnStart () {
        // For information about handling configuration changes, see the article
        // "Customize the Lifecycle of a Web or Worker role in .NET" at
        // https://learn.microsoft.com/azure/cloud-services/cloud-services-role-lifecycle-dotnet.
        IPHostEntry ipEntry = Dns.GetHostEntry (Dns.GetHostName ());
        string ip = null;
        foreach (IPAddress ipaddress in ipEntry.AddressList) {
            if (ipaddress.AddressFamily.ToString () == "InterNetwork") {
                ip = ipaddress.ToString ();
            }
        }
        string urlToPing = "https://" + ip;
        HttpWebRequest req = HttpWebRequest.Create (urlToPing) as HttpWebRequest;
        WebResponse resp = req.GetResponse ();
        return base.OnStart ();
    }
}

Weitere Informationen

• Rolleninstanzneustarts von Azure VM-Betriebssystemupgrades – Häufig gestellte Fragen

Kontaktieren Sie uns für Hilfe

Wenn Sie Fragen haben oder Hilfe mit Ihren Azure-Gutschriften benötigen, dann erstellen Sie beim Azure-Support eine Support-Anforderung oder fragen Sie den Azure Community-Support. Sie können auch Produktfeedback an die Azure Feedback Community senden.