Freigeben über

ARM concepts in Azure Stack for the WAP Administrator — Cloud Service Delivery

  • Artikel

Hello Readers! This blog is part 2 of the series "ARM concepts in Azure Stack for the WAP Administrator". In this post we'll discuss how cloud resources (virtual machines, virtual networks, web sites, etc.) are provisioned in Windows Azure Pack (WAP) and then we'll discuss how they are provisioned in Microsoft Azure Stack.

Note Some information relates to pre-released product which may be substantially modified before it's commercially released. Microsoft makes no warranties, express or implied, with respect to the information provided here.

I'm including the table of contents for this series of posts so that you'll find it easier to navigate across the series:

Table of contents

  1. Introductory post, and some first information on the Azure Stack POC architecture and ARM's role
  2. Cloud Service Delivery—this post
  3. Plans, offers, and subscriptions
  4. Resource deployment methods using the portal, Visual Studio, APIs or CLI
  5. Packaging and publishing templates on Azure Stack
  6. Multi-tier applications with ARM
  7. In-guest configuration with ARM and technologies like Virtual Machines Extensions, including PowerShell Desired State Configuration (DSC)
  8. Troubleshooting IaaS deployments in Azure Stack

We will update this post with links to the new posts, as we publish them. With no more delay, let's get started!

 

 

Windows Azure Pack

Windows Azure Pack (WAP) allows service administrators to offer cloud services, such as IaaS (virtual machines, virtual networks) and PaaS (websites, databases), to tenants. Tenants consume cloud services from WAP with an experience that is similar to the Microsoft Azure Classic Portal, which leverages the Azure Service Management platform. Figure 1 below depicts the WAP tenant portal, showing how similar it is to the Azure Classic Portal:

Figure 1: The WAP tenant portal

Before service administrators can offer cloud services to tenants, they must configure the cloud services. For example, to offer IaaS in WAP, it is necessary to deploy and configure the fabric, which is based on Windows Server 2012 R2, and the fabric management infrastructure, which is based on System Center 2012 R2. The fabric and fabric management infrastructure are required for the Virtual Machine Clouds service in WAP. This is depicted in Figure 2:

Figure 2: High-level WAP architecture

It's out of the scope of this blog post to describe how to deploy and configure all the requirements for the Virtual Machine Clouds service in WAP; for details, see Provision Virtual Machine Clouds in the WAP documentation. Once the requirements for the Virtual Machine Clouds service are met, a WAP administrator must indicate the System Center Service Provider Foundation (SPF) endpoint that exposes the System Center Virtual Machine Manager (VMM) management stamps (SPF can be configured to interact with up to 5 stamps). System Center Operations Manager can optionally be added to implement the usage capability in the Virtual Machine Clouds service.

This architecture is depicted in Figure 3:

Figure 3: WAP VM clouds management architecture

Source: How is the management portal for administrators associated with Service Provider Foundation?

Figure 4 depicts how a WAP administrator indicates the SPF endpoint to be used for the Virtual Machine Clouds service in the WAP admin portal:

Figure 4: WAP SPF endpoint

Once the SPF endpoint is registered, the WAP administrator can offer IaaS to tenants. In the next blog post, we will discuss how this experience compares with Azure Stack. Now, let's review how an IaaS resource is provisioned when a tenant requests the creation of a new resource. To show this, I'll assume that the tenant requests the creation of a new virtual machine. Here is a high level view of the process:

  1. A tenant signs in to the WAP tenant portal, and requests to create a new virtual machine.
  2. The request will be sent to the WAP Service Management API. The Service Management API will review the request, and will determine which resource provider (RP) is responsible for executing the task. In this case, the Virtual Machine Clouds RP is responsible for provisioning virtual machines.
  3. The Virtual Machine Clouds RP will send the request to provision a new virtual machine to SPF, and SPF in turn will pass the request to VMM.
  4. VMM will provision the virtual machine using the available capacity (Hyper-V hosts) defined in the VMM.
  5. Once the VM is provisioned in the Hyper-V host, the tenant receives confirmation that the virtual machine is up and running, and available for consumption.

Now let's review how cloud services are delivered in Azure Stack.

 

Microsoft Azure Stack

The cloud service delivery in Azure Stack is consistent with Microsoft Azure, since Azure Stack is fundamentally born from Microsoft Azure. In Azure Stack the cloud service delivery is very different from what you are used to in WAP. The difference in how Microsoft Azure and Azure Stack deliver services is that, while Azure operates at Hyper-Scale (having the minimum scale unit of 20 racks!), Azure Stack is designed to operate in your datacentres at an enterprise level. This is depicted in Figure 5.

Figure 5: Microsoft Azure and Azure Stack

In Figure 5, above, we can see that a user can consume Azure IaaS and PaaS services from Microsoft Azure (public cloud) or Azure Stack (private/hosted cloud) using the same set of tools (Portal, PowerShell and/or Devops tools) that they are used to, and that these tools communicate with Azure Resource Manager (ARM), which is the responsible for managing the provisioning of cloud resources in Azure and Azure Stack.

Figure 6 depicts the tenant experience in Azure Stack. As you can see, the experience is the same as the one they have in Azure:

Figure 6: Azure Stack portal

ARM enables tenants to deploy, manage and monitor all of the resources in their application as a group, rather than having to manage resources individually. You can learn more about ARM and its benefits visiting the online documentation here. In the context of IaaS, let's review how a virtual machine is defined in ARM. ARM uses three resource providers in order to provision IaaS resources:

  • Compute Resource Provider (CRP) – supports instances of virtual machines and optional availability sets and virtual machine extensions.
  • Storage Resource Provider (SRP) – supports required storage accounts that store the virtual hard drive (VHD) for virtual machines including the operating system and additional data disks.
  • Network Resource Provider (NRP) – supports required NICs, virtual machine IP addresses, and subnets within virtual networks and optional load balancers, load balance IP addresses and network security groups.

Figure 7 depicts a Simple Windows VM application from the Azure Stack Quick Start GitHub repository, modelled under ARM:

Figure 7: Simple Windows VM sample application

In Figure 7 we can see that there are three resource providers (RP) required to provision a virtual machine, there are relationships between the resources within the resource providers, and some relationships are required (solid arrows) while others are optional (dashed arrows). In summary:

  • A virtual machine references a storage account defined in the SRP to store its disks in blob storage (required).
  • A virtual machine references a NIC defined in the NRP (required).
  • A NIC references the virtual machine's assigned IP address (required) and the subnet of the virtual network for the virtual machine (required).
  • A subnet within a virtual network references a Network Security Group (optional)

When a user submits the request to provision a virtual machine in Azure or Azure Stack, ARM analyses and processes the request by communicating with the required RPs and making sure that the dependencies between them are honoured. If a tenant deploys other resources, such as a web site or a database (don't forget that Azure Stack does much more than just IaaS), ARM will orchestrate a deployment process that is similar to the one used to deploy a VM.

Let's review this process in more detail. For this, I'll take a picture (Figure 8) that describes the Azure Stack architecture from the whitepaper "Taking the cloud to your datacenter." Figure 8 is also available in the Azure Stack Technical Preview documentation, where you can find a breakdown of the Azure Stack POC architecture.

Figure 8: Simplified Azure Stack architecture

Explaining the Azure Stack architecture is out of scope of this blog post (and you can refer to the Azure Stack whitepaper for a detailed explanation), however, I want to emphasize that ARM is the key component that enables consistent cloud service delivery across Microsoft Azure and Microsoft Azure Stack. Remember, ARM in Azure Stack is the same as ARM running in Microsoft Azure. For now, let's focus on reviewing how an application (the Simple Windows VM sample) is provisioned in Azure Stack.

For this objective, I've slightly edited Figure 8 by adding some numbers that will help us understand how cloud services are provisioned in Azure Stack. The numbers in the figure correspond to the numbers in the following process:

  1. A tenant signs in to the Azure Stack Portal (or to an Azure Stack environment via PowerShell), and then deploys a new cloud resource. In this example the tenant has requested to provision virtual machine.
  2. ARM receives the request to provision a cloud resource, then it analyses the request and determines which RPs are required to provision the desired tenant resources. In the case of a virtual machine, we know from the Simple Windows VM example above that the required RPs are CRP, SRP, and NRP.
  3. These RPs are represented in the Foundational Services layer. Each of these RPs is responsible for provisioning the required resource, with ARM orchestrating the deployment and RPs waiting for each other as dependent resources are created.
  4. The RPs leverage the cloud-inspired infrastructure in Azure Stack based on Windows Server 2016. Table 1, below, describes the resources provisioned when deploying a virtual machine in Azure Stack.
Resource RP Cloud Infrastructure
IP Address NRP Network Controller / Software Load Balancer
Network Security Group NRP Network Controller
Virtual Network NRP Network Controller
Network Interface NRP Network Controller
Storage Account SRP Scale out File Server / Storage Spaces Direct
Virtual Machine CRP Hyper-V

Table 1: Resources and Resource Providers
    5. The tenant receives an update of the provisioning status of their resources, and once deployment is completed, the tenant can consume the cloud resource.

 

 

Conclusion

Windows Azure Pack and Microsoft Azure Stack use different methods to deliver cloud services.

Windows Azure Pack allows tenants to provision cloud resources with an experience similar to Azure classic, and using similar APIs. The Virtual Machine Clouds RP in Windows Azure Pack, which requires Windows Server 2012 R2 and System Center 2012 R2, allows tenants to provision IaaS resources such as virtual machines and virtual networks. All of the IaaS resources are provided by a single RP and resources are provisioned individually, hence is up to the developer to manage the dependencies between resources in order to create complex applications (for example, a SharePoint farm).

In Microsoft Azure Stack, tenants provision cloud resources in the same way as they would provision them in Microsoft Azure, with the same portal and same devops tools (such as PowerShell or Visual Studio). Applications written for Azure Stack will also work in Microsoft Azure as they're written to work with the ARM, which is the same on Azure and Azure Stack. When ARM receives a request to provision an application, let's say, a SharePoint farm, ARM will identify which resource providers are required to deploy the resources, and the dependencies between, and make sure the resource provisioning is done in the proper order by the RPs. In turn, the RPs will communicate with the underlying cloud-inspired infrastructure based on Windows Server 2016 to provision the requested resources.

In the next blog post we will review and discuss how service administrators can offer cloud services to tenants in WAP and Azure Stack.

Until next time!

Victor