Freigeben über

Workflow der klassischen VM-Architektur von Microsoft Azure

  • Artikel

Wichtig

Cloud Services (klassisch) ist jetzt ab dem 1. September 2024 für alle Kunden veraltet. Alle vorhandenen ausgeführten Bereitstellungen werden beendet und von Microsoft heruntergefahren, und die Daten gehen ab Oktober 2024 dauerhaft verloren. In neuen Bereitstellungen sollte das neue auf Azure Resource Manager basierende Bereitstellungsmodell für Azure Cloud Services (erweiterter Support) verwendet werden.

Dieser Artikel bietet eine Übersicht über die Workflowprozesse, die beim Bereitstellen oder Aktualisieren einer Azure-Ressource (z. B. einer VM) stattfinden.

Hinweis

Azure verfügt über zwei verschiedene Bereitstellungsmodelle für das Erstellen und Verwenden von Ressourcen: Resource Manager-Bereitstellung und klassische Bereitstellung. Dieser Artikel befasst sich mit der Verwendung des klassischen Bereitstellungsmodells.

Das folgende Diagramm zeigt die Architektur von Azure-Ressourcen.

<Abbildung eins Azure-Workflows>

Grundlagen des Workflows

A. RDFE/FFE ist der Kommunikationspfad vom Benutzer zum Fabric. Das RDFE (RedDog-Front-End) ist die öffentlich verfügbar gemachte API, die als Front-End für das Verwaltungsportal und die API für das klassische Bereitstellungsmodell dient, beispielsweise Visual Studio, Azure MMC usw. Alle Anforderungen vom Benutzer erfolgen über das RDFE. Das FFE (Fabric-Front-End) ist die Ebene, die Anforderungen von RDFE- in Fabricbefehle übersetzt. Alle Anforderungen vom RDFE werden durch das FFE gesendet, um die Fabric Controller zu erreichen.

B. Der Fabric Controller ist für die Verwaltung und Überwachung aller Ressourcen im Rechenzentrum zuständig. Er kommuniziert mit Fabric-Host-Agents auf dem Betriebssystem des Fabrics und sendet Informationen wie z. B. die Version des Gastbetriebssystems, das Dienstpaket, die Dienstkonfiguration und den Dienstzustand.

C. Der Host-Agent befindet sich auf dem Hostbetriebssystem und ist für die Einrichtung des Gastbetriebssystems verantwortlich. Er behandelt außerdem die Kommunikation mit dem Gast-Agent (WindowsAzureGuestAgent), um die Rolle auf einen beabsichtigten Zielzustand zu aktualisieren und Heartbeatüberprüfungen mit dem Gast-Agent auszuführen. Wenn der Host-Agent zehn Minuten lang keine Heartbeatantwort empfängt, startet er das Gastbetriebssystem neu.

C2. WaAppAgent ist für die Installation, Konfiguration und Aktualisierung der Datei „WindowsAzureGuestAgent.exe“ zuständig.

D. „WindowsAzureGuestAgent“ ist für die folgenden Aufgaben zuständig:

  • Konfigurieren des Gastbetriebssystems, einschließlich Firewall, Zugriffssteuerungslisten (Access Control List, ACL), LocalStorage-Ressourcen, Dienstpaket und -konfiguration sowie Zertifikaten
  • Einrichten der Sicherheits-ID (SID) für das Benutzerkonto, unter dem die Rolle ausgeführt wird
  • Melden des Rollenstatus an das Fabric
  • Starten und Überwachen von WaHostBootstrapper, um sicherzustellen, dass sich die Rolle im Zielzustand befindet

E. WaHostBootstrapper ist für Folgendes zuständig:

  • Lesen der Rollenkonfiguration und Starten aller entsprechenden Aufgaben und Prozesse zum Konfigurieren und Ausführen der Rolle
  • Überwachen aller untergeordneten Prozesse
  • Auslösen des StatusCheck-Ereignisses im Rollenhostprozess

F. IISConfigurator wird ausgeführt, wenn die Rolle als Webrolle mit der IIS-Vollversion konfiguriert ist. IISConfigurator ist für Folgendes zuständig:

  • Starten der IIS-Standarddienste
  • Konfigurieren des Rewrite-Moduls in der Webkonfiguration
  • Einrichten des AppPool für die konfigurierte Rolle im Dienstmodell
  • Einrichten der IIS-Protokollierung, um auf den LocalStorage-Ordner „DiagnosticStore“ zu verweisen
  • Konfigurieren von Berechtigungen und ACLs
  • Die Website befindet sich in „%roleroot%:\sitesroot\0“, und der AppPool verweist zum Ausführen von IIS auf diesen Speicherort.

G. Das Rollenmodell definiert Startaufgaben, und „WaHostBootstrapper“ startet sie. Startaufgaben können zur asynchronen Ausführung im Hintergrund konfiguriert werden. Der Hostbootstrapper startet in diesem Fall die Startaufgabe und fährt dann mit der Verarbeitung anderer Startaufgaben fort. Startaufgaben können auch für die Ausführung im einfachen Modus (Standard) konfiguriert werden. Im einfachen Modus wartet der Hostbootstrapper auf den Abschluss der Startaufgabe und gibt einen Erfolgs-Exitcode (0) zurück, bevor er mit der nächsten Startaufgabe fortfährt.

H. Diese Aufgaben sind Teil des SDK und als Plug-Ins in der Dienstdefinition (.csdef) der Rolle definiert. Werden sie in Startaufgaben erweitert, weisen DiagnosticsAgent und RemoteAccessAgent die Besonderheit auf, dass sie jeweils zwei Startaufgaben definieren: eine normale und eine mit dem Parameter /blockStartup. Die normale Startaufgabe wird als Hintergrundstartaufgabe definiert, sodass sie im Hintergrund laufen kann, während die Rolle selbst ausgeführt wird. Die /blockStartup-Startaufgabe wird als einfache Startaufgabe definiert, sodass WaHostBootstrapper auf ihre Beendigung wartet, bevor er mit anderen Aufgaben fortfährt. Die /blockStartup-Aufgabe wartet, bis die Initialisierung der normalen Aufgabe abgeschlossen ist, und anschließend wird sie beendet, wodurch der Hostbootstrapper die Verarbeitung fortsetzen kann. Bei diesem Prozess können die Diagnose und der RDP-Zugriff vor dem Start der Rollenprozesse konfiguriert werden (über die Aufgabe „/blockStartup“). Zudem können bei diesem Prozess die Diagnose und der RDP-Zugriff so weiter ausgeführt werden, nachdem der Hostbootstrapper die Startaufgaben abgeschlossen hat (über die normale Aufgabe).

I. WaWorkerHost ist der Standardhostprozess für normale Workerrollen. Dieser Hostprozess hostet alle DLLs sowie den Code für den Einstiegspunkt der Rolle (z. B. „OnStart“ und „Run“).

J. WaIISHost ist für Webrollen, die die IIS-Vollversion verwenden, der Hostprozess für den Code für den Einstiegspunkt der Rolle. Der Prozess lädt die erste gefundene DLL mit der RoleEntryPoint-Klasse und führt den Code über diese Klasse aus (OnStart, Run, OnStop). Alle in der RoleEntryPoint-Klasse erstellten RoleEnvironment-Ereignisse (z. B. „StatusCheck“ und „Changed“) werden in diesem Prozess ausgelöst.

K. W3WP ist der IIS-Standardworkerprozess, der verwendet wird, wenn die Rolle zur Verwendung der IIS-Vollversion konfiguriert ist. Dieser Prozess führt den über IISConfigurator konfigurierten App-Pool (AppPool) aus. Alle RoleEnvironment-Ereignisse (z. B. „StatusCheck“ und „Changed“), die hier erstellt werden, werden in diesem Prozess ausgelöst. RoleEnvironment-Ereignisse werden sowohl in „WaIISHost“ als auch „w3wp.exe“ ausgelöst, wenn Sie Ereignisse in beiden Prozessen abonnieren.

Workflowprozesse

  1. Ein Benutzer sendet eine Anforderung (z. B. zum Hochladen von CSPKG- und CSCFG-Dateien), durch die die Beendigung einer Ressource veranlasst oder eine Konfigurationsänderung vorgenommen wird. Anforderungen können über das Azure-Portal oder Tools gesendet werden, die die API für das klassische Bereitstellungsmodellverwenden, z. B. das Visual Studio-Feature zum Veröffentlichen. Die Anforderung wird an das RDFE gesendet, das alle Aufgaben im Zusammenhang mit Abonnements ausführt und die Anforderung dann an das FFE übermittelt. In den verbleibenden Workflowschritten wird ein neues Paket bereitgestellt und gestartet.
  2. Das FFE ermittelt den richtigen Computerpool (basierend auf Kundeneingaben, z. B. Affinitätsgruppe oder geografischer Standort, sowie Eingaben vom Fabric, z. B. Verfügbarkeit der Computer) und kommuniziert mit dem Master-Fabric Controller in diesem Computerpool.
  3. Der Fabric Controller sucht nach einem Host mit verfügbaren CPU-Kernen (oder startet einen neuen Host). Das Dienstpaket und die Konfiguration werden auf den Host kopiert, und der Fabric Controller kommuniziert mit dem Host-Agent auf dem Hostbetriebssystem, um das Paket bereitzustellen (Konfigurieren von DIPs, Ports, Gastbetriebssystem usw.).
  4. Der Host-Agent startet das Gastbetriebssystem und kommuniziert mit dem Gast-Agent (WindowsAzureGuestAgent). Der Host sendet Heartbeats an den Gast-Agent, um sicherzustellen, dass die Rolle auf den Zielzustand aktualisiert wird.
  5. WindowsAzureGuestAgent richtet das Gastbetriebssystem ein (Firewall, ACLs, LocalStorage usw.), kopiert eine neue XML-Konfigurationsdatei in das Verzeichnis „c:\Config“ und startet dann den WaHostBootstrapper-Prozess.
  6. Für Webrollen mit der IIS-Vollversion startet WaHostBootstrapper den IISConfigurator-Prozess und weist ihn an, alle vorhandenen AppPools für die Webrolle aus IIS zu löschen.
  7. WaHostBootstrapper liest die Startaufgaben aus „E:\RoleModel.xml“ und beginnt mit ihrer Ausführung. „WaHostBootstrapper“ wartet, bis alle einfachen Aufgaben abgeschlossen sind und eine Erfolgsmeldung zurückgegeben wird.
  8. Für Webrollen mit der IIS-Vollversion weist WaHostBootstrapper IISConfigurator an, den IIS-AppPool zu konfigurieren, und verweist die Website an E:\Sitesroot\<index>, wobei <index> ein auf null basierender Index für die Anzahl von <Sites>-Elementen ist, die für den Dienst definiert sind.
  9. „WaHostBootstrapper“ startet den Hostprozess je nach Rollentyp:
    1. Workerrolle: „WaWorkerHost.exe“ wird gestartet. WaHostBootstrapper führt die OnStart()-Methode aus. Nach Abschluss dieser Methode startet WaHostBootstrapper die Ausführung der Run()-Methode. Danach markiert er die Rolle als „Bereit“ und fügt sie gleichzeitig der Lastenausgleichsrotation hinzu (falls Eingabeendpunkte definiert sind). Anschließend überprüft WaHostBootstrapper in einer Schleife den Rollenstatus.
    2. Webrolle mit der IIS-Vollversion: aIISHost wird gestartet. WaHostBootstrapper führt die OnStart()-Methode aus. Nach Abschluss dieser Methode startet er die Ausführung der Run()-Methode. Danach markiert er die Rolle als „Bereit“ und fügt sie gleichzeitig der Lastenausgleichsrotation hinzu. Anschließend überprüft WaHostBootstrapper in einer Schleife den Rollenstatus.
  10. Eingehende Webanforderungen an eine Webrolle mit der IIS-Vollversion lösen wie in einer lokalen IIS-Umgebung IIS aus, um den W3WP-Prozess zu starten und die Anforderung zu verarbeiten.

Speicherort der Protokolldateien

WindowsAzureGuestAgent

  • C:\Logs\AppAgentRuntime.Log
    Dieses Protokoll enthält Änderungen am Dienst, einschließlich Starts, Beendigungen und neuer Konfigurationen. Wenn der Dienst nicht geändert wird, sind in dieser Protokolldatei große Zeitlücken zu erwarten.
  • C:\Logs\WaAppAgent.Log
    Dieses Protokoll enthält Statusaktualisierungen sowie Heartbeatbenachrichtigungen und wird alle zwei bis drei Sekunden aktualisiert. Das Protokoll enthält eine historische Ansicht des Status der Instanz und gibt Aufschluss darüber, wann die Instanz nicht im Zustand „Bereit“ war.

WaHostBootstrapper

C:\Resources\Directory\<deploymentID>.<role>.DiagnosticStore\WaHostBootstrapper.log

WaIISHost

C:\Resources\Directory\<deploymentID>.<role>\WaIISHost.log

IISConfigurator

C:\Resources\Directory\<deploymentID>.<role>\IISConfigurator.log

IIS-Protokolle

C:\Resources\Directory\<guid>.<role>.DiagnosticStore\LogFiles\W3SVC1

Windows-Ereignisprotokolle

D:\Windows\System32\Winevt\Logs