Edit

Share via

Workflow of Microsoft Azure classic Virtual Machine (VM) Architecture

  • Article

Important

Cloud Services (classic) is now deprecated for all customers as of September 1st, 2024. Any existing running deployments will be stopped and shut down by Microsoft and the data will be permanantly lost starting October 2024. New deployments should use the new Azure Resource Manager based deployment model Azure Cloud Services (extended support).

This article provides an overview of the workflow processes that occur when you deploy or update an Azure resource such as a virtual machine.

Note

Azure has two different deployment models for creating and working with resources: Resource Manager and classic. This article covers using the classic deployment model.

The following diagram presents the architecture of Azure resources.

<alt The image about Azure workflow>

Workflow basics

A. RDFE / FFE is the communication path from the user to the fabric. RDFE (RedDog Front End) is the publicly exposed API that is the front end to the Management Portal and the classic deployment model API, such as Visual Studio, Azure MMC, and so on. All requests from the user go through RDFE. FFE (Fabric Front End) is the layer that translates requests from RDFE into fabric commands. All requests from RDFE go through the FFE to reach the fabric controllers.

B. The fabric controller is responsible for maintaining and monitoring all the resources in the data center. It communicates with fabric host agents on the fabric OS sending information such as the Guest OS version, service package, service configuration, and service state.

C. The Host Agent lives on the Host OS and is responsible for setting up Guest OS. It also handles communicating with Guest Agent (WindowsAzureGuestAgent) to update the role toward an intended goal state and do heartbeat checks with the Guest Agent. If Host Agent doesn't receive heartbeat response for 10 minutes, Host Agent restarts the Guest OS.

C2. WaAppAgent is responsible for installing, configuring, and updating WindowsAzureGuestAgent.exe.

D. WindowsAzureGuestAgent is responsible for the following tasks:

  • Configuring the Guest OS including firewall, ACLs, LocalStorage resources, service package and configuration, and certificates.
  • Setting up the SID for the user account that the role runs under.
  • Communicating the role status to the fabric.
  • Starting WaHostBootstrapper and monitoring it to make sure that the role is in goal state.

E. WaHostBootstrapper is responsible for:

  • Reading the role configuration, and starting all the appropriate tasks and processes to configure and run the role.
  • Monitoring all its child processes.
  • Raising the StatusCheck event on the role host process.

F. IISConfigurator runs if the role is configured as a Full IIS web role. It's responsible for:

  • Starting the standard IIS services
  • Configuring the rewrite module in the web configuration
  • Setting up the AppPool for the configured role in the service model
  • Setting up IIS logging to point to the DiagnosticStore LocalStorage folder
  • Configuring permissions and ACLs
  • The website resides in %roleroot%:\sitesroot\0, and the AppPool points to this location to run IIS.

G. The role model defines startup tasks, and WaHostBootstrapper starts them. Startup tasks can be configured to run in the background asynchronously, and the host bootstrapper starts the startup task and then continue on to other startup tasks. Startup tasks can also be configured to run in Simple (default) mode. In Simple mode, the host bootstrapper waits for the startup task to finish running and return a success (0) exit code before continuing to the next startup task.

H. These tasks are part of the SDK and are defined as plugins in the role’s service definition (.csdef). When expanded into startup tasks, the DiagnosticsAgent and RemoteAccessAgent are unique in that they each define two startup tasks, one regular and one that has a /blockStartup parameter. The normal startup task is defined as a Background startup task so that it can run in the background while the role itself is running. The /blockStartup startup task is defined as a Simple startup task so that WaHostBootstrapper waits for it to exit before continuing. The /blockStartup task waits for the regular task to finish initializing, and then it exits and allow the host bootstrapper to continue. This process is done so that diagnostics and RDP access can be configured before the role processes start, which is done through the /blockStartup task. This process also allows diagnostics and RDP access to continue running after the host bootstrapper finishes the startup tasks, which is done through the Normal task.

I. WaWorkerHost is the standard host process for normal worker roles. This host process hosts all the role’s DLLs and entry point code, such as OnStart and Run.

J. WaIISHost is the host process for role entry point code for web roles that use Full IIS. This process loads the first DLL that is found that uses the RoleEntryPoint class and executes the code from this class (OnStart, Run, OnStop). Any RoleEnvironment events (such as StatusCheck and Changed) that are created in the RoleEntryPoint class are raised in this process.

K. W3WP is the standard IIS worker process used if the role is configured to use Full IIS. This process runs the AppPool configured from IISConfigurator. Any RoleEnvironment events (such as StatusCheck and Changed) that are created here are raised in this process. RoleEnvironment events fire in both locations (WaIISHost and w3wp.exe) if you subscribe to events in both processes.

Workflow processes

  1. A user makes a request, such as uploading ".cspkg" and ".cscfg" files, telling a resource to stop or making a configuration change, and so on. Requests can be made through the Azure portal or tools that use the classic deployment model API, such as the Visual Studio Publish feature. This request goes to RDFE to do all the subscription-related work and then communicate the request to FFE. The rest of these workflow steps are to deploy a new package and start it.
  2. FFE finds the correct machine pool (based on customer input such, as affinity group or geographical location plus input from the fabric, such as machine availability) and communicates with the master fabric controller in that machine pool.
  3. The fabric controller finds a host that has available CPU cores (or spins up a new host). The service package and configuration is copied to the host, and the fabric controller communicates with the host agent on the host OS to deploy the package (configure DIPs, ports, guest OS, and so on).
  4. The host agent starts the Guest OS and communicates with the guest agent (WindowsAzureGuestAgent). The host sends heartbeats to the guest to make sure that the role is working towards its goal state.
  5. WindowsAzureGuestAgent sets up the guest OS (firewall, ACLs, LocalStorage, and so on), copies a new XML configuration file to c:\Config, and then starts the WaHostBootstrapper process.
  6. For Full IIS web roles, WaHostBootstrapper starts IISConfigurator and tells it to delete any existing AppPools for the web role from IIS.
  7. WaHostBootstrapper reads the Startup tasks from E:\RoleModel.xml and begins executing startup tasks. WaHostBootstrapper waits until all Simple startup tasks finish and return a success message.
  8. For Full IIS web roles, WaHostBootstrapper tells IISConfigurator to configure the IIS AppPool and points the site to E:\Sitesroot\<index>, where <index> is a zero-based index into the number of <Sites> elements defined for the service.
  9. WaHostBootstrapper starts the host process depending on the role type:
    1. Worker Role: WaWorkerHost.exe is started. WaHostBootstrapper executes the OnStart() method. After it returns, WaHostBootstrapper starts to execute the Run() method, and then simultaneously marks the role as Ready and puts it into the load balancer rotation (if InputEndpoints are defined). WaHostBootsrapper then goes into a loop of checking the role status.
    2. Full IIS Web Role: aIISHost is started. WaHostBootstrapper executes the OnStart() method. After it returns, it starts to execute the Run() method, and then simultaneously marks the role as Ready and puts it into the load balancer rotation. WaHostBootsrapper then goes into a loop of checking the role status.
  10. Incoming web requests to a Full IIS web role trigger IIS to start the W3WP process and serve the request, the same as it would in an on-premises IIS environment.

Log File locations

WindowsAzureGuestAgent

  • C:\Logs\AppAgentRuntime.Log.
    This log contains changes to the service including starts, stops, and new configurations. If the service doesn't change, you can expect to see large gaps of time in this log file.
  • C:\Logs\WaAppAgent.Log.
    This log contains status updates and heartbeat notifications and is updated every 2-3 seconds. This log contains a historic view of the status of the instance and tells you when the instance wasn't in the Ready state.

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 logs

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

Windows Event logs

D:\Windows\System32\Winevt\Logs