Workflow der klassischen VM-Architektur von Microsoft Azure

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

Das folgende Diagramm zeigt die Architektur von Azure-Ressourcen.

Grundlagen des Workflows

A. RDFE/FFE ist der Kommunikationspfad vom Benutzer zur Netzwerkstruktur. 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 RDFE. Das FFE (Fabric Front End) ist die Ebene, die Anforderungen von RDFE in Fabricbefehle übersetzt. Alle Anfragen vom RDFE gehen durch das FFE, 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 Fabric-OS und sendet Informationen wie die Version des Gastbetriebssystems, das Service-Paket, die Service-Konfiguration und den Service-Status.

C. Der Host-Agent befindet sich auf dem Hostbetriebssystem und ist für die Einrichtung des Gastbetriebssystems verantwortlich. Es kümmert sich außerdem um die Kommunikation mit dem Gast-Agenten (WindowsAzureGuestAgent), um die Rolle auf einen gewünschten Zielzustand zu aktualisieren und Heartbeat-Prüfungen mit dem Gast-Agenten auszuführen. Wenn der Host-Agent zehn Minuten lang keine Heartbeat-Antwort 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 des WaHostBootstrappers und dessen Überwachung, 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
• Überwachung aller seiner untergeordneten Prozesse.
• Auslösen des StatusCheck-Events 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 regulären Aufgabe abgeschlossen ist, und beendet sich anschließend selbst, wodurch es dem Hostbootstrapper ermöglicht wird, die Verarbeitung fortzusetzen. Bei diesem Prozess können die Diagnose und der RDP-Zugriff vor dem Start der Rollenprozesse konfiguriert werden (über die Aufgabe „/blockStartup“). Zudem erlaubt dieser Prozess, dass Diagnose und RDP-Zugriff auch nach Abschluss der Startaufgaben durch den Host-Bootstrapper weiter ausgeführt werden können, was über den "Normal-Task" erfolgt.

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 der Hostprozess für den Einstiegspunktscode von Webrollen, die Full IIS verwenden. 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 den IISConfigurator konfigurierten App-Pool 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. Anfragen können über das Azure-Portal oder Tools gesendet werden, die die API für das klassische Bereitstellungsmodell verwenden, z. B. die Veröffentlichungsfunktion von Visual Studio. 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, um sicherzustellen, dass die Rolle auf ihren Zielzustand hinarbeitet.
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 Simple-Startup-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 die Website auf E:\Sitesroot\<index> zu verweisen, wobei <index> ein auf null basierender Index für die Anzahl der für den Dienst definierten <Sites>-Elemente ist.
9. „WaHostBootstrapper“ startet den Hostprozess je nach Rollentyp:
   1. Workerrolle: „WaWorkerHost.exe“ wird gestartet. WaHostBootstrapper führt die OnStart()-Methode aus. Nachdem sie zurückkehrt, startet WaHostBootstrapper die Ausführung der Run()-Methode und markiert die Rolle gleichzeitig als „Bereit“ und fügt sie der Lastenausgleichsrotation hinzu (wenn Inputendpunkte definiert sind). Anschließend überprüft WaHostBootstrapper in einer Schleife den Rollenstatus.
   2. Voller IIS-Webrolle: aIISHost ist gestartet. WaHostBootstrapper führt die OnStart()-Methode aus. Nachdem es zurückkehrt, beginnt es, die Run()-Methode auszuführen und markiert gleichzeitig die Rolle als „Bereit“ und fügt sie dem Lastenausgleich hinzu. Anschließend überprüft WaHostBootsrapper in einer Schleife den Status der Rolle.
10. Eingehende Webanforderungen an eine Webrolle mit der IIS-Vollversion veranlassen IIS, den W3WP-Prozess zu starten und die Anforderung zu verarbeiten, so wie es in einer lokalen IIS-Umgebung der Fall wäre.

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