ARM concepts in Azure Stack for the WAP Administrator – Multi-tier applications
Hello Readers! This blog is part 6 of the series "ARM concepts in Azure Stack for the WAP Administrator." In this post we'll discuss how the deployment of multi-tier applications concepts you are familiar with in Windows Azure Pack (WAP) map to Microsoft Azure Stack Technical Preview 1.
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 post so that you'll find it easier to navigate across the series:
Table of contents
- Introductory post, and some first information on the Azure Stack POC architecture and ARM's role
- Cloud Service Delivery
- Plans, offers, and subscriptions
- Resource Deployment
- Packaging and publishing templates on Azure Stack
- Multi-tier applications – this post
- In-guest configuration with ARM, and technologies such as Virtual Machines Extensions, including PowerShell Desired State Configuration (DSC)
- Troubleshooting IaaS deployments in Azure Stack
We will update the post with links to the new posts, as we publish them. With no more delay, let's get started!
Multi-tier applications in WAP
As we discussed in previous post from this series, WAP tenants can deploy two types of virtual machines:
- A Standalone Virtual Machine, which basically is a virtual machine with an operating system installed, such as a sysprepped Windows Server 2012 R2 or a specific Linux distribution.
- A Virtual Machine Role, which is typically a virtual machine with an operating system installed and with an application installed and configured, such as a domain controller, a SQL Server, or a VM with SharePoint installed.
But out-of-the-box, WAP does not offer tenants the possibility to deploy multi-tier applications, such as SharePoint, Exchange or Lync, where the different components are installed across multiple servers.
As the WAP tenant portal only allows tenants to deploy one virtual machine at the time, then it's up to the tenant to rely on an automation platform to coordinate and execute the deployment of the multi-tier application in the right sequence, and make sure dependencies are properly handled. But wait a second, System Center Service Management Automation (SMA) allows you to execute runbooks that could coordinate these activities, and also integrates with WAP? So couldn't tenants use SMA to automate the deployment of their multi-tier applications?
Well, while SMA indeed allows the execution of runbooks and also integrates with WAP, its functionality is only exposed to the WAP admin. In other words, WAP tenants cannot directly call SMA from the WAP tenant portal. The picture below depicts the WAP tenant portal and you can see that no SMA functionality is available to tenants:
And the picture below shows the WAP admin portal with SMA registered and integrated:
So, is there still a way to benefit from SMA when executing actions as a tenant?
The answer is yes! As part of the SMA integration with WAP, you can register SMA with the VM Clouds resource provider, and this will allow you to link an activity or event in the VM Clouds resource provider to a SMA Runbook. For example, when a subscription is deleted you might want to remove all tenant objects related to that subscription, such as virtual machines and virtual networks:
Given that SMA is only exposed to WAP admins, they can leverage the SMA integration with WAP to offer plans to their tenants which includes the deployment of multi-tier applications such as Exchange, SharePoint or Skype for Business. Charles Joy wrote a great series of blog post describing how a WAP admin can offer plans which fully automate the tenant environment deployment, such as creating a virtual network, creating a domain controller, and then deploying workloads such as Exchange, SharePoint and Lync via VM Roles. The key technologies to enable this solution are:
- SMA – For end-to-end automation
- VM Roles – For provisioning the VMs
- DSC – For the deployment and configuration of the application
Also, the Private Cloud Solutions team at Microsoft wrote a series of multi-tier workloads for the Cloud Platform System (CPS), leveraging the three technologies described above. Even if you don't have a CPS stamp in your garage, you can download these samples and modify them to suit your WAP deployment! You can learn more about these CPS workloads using these links:
- Automated Workload Provisioning with the Azure Pack and Windows PowerShell
- Self-service deployment of Microsoft workloads on Cloud Platform System (and other systems with Windows Azure Pack) – Part 1
- Self-service deployment of Microsoft workloads on Cloud Platform System (and other systems with Windows Azure Pack) – Part 2
- Self-service deployment of Microsoft workloads on Cloud Platform System (and other systems with Windows Azure Pack) – Part 3
- Self-service deployment of Microsoft workloads on Cloud Platform System (and other systems with Windows Azure Pack) – Part 4
And as described on the links above, you can get these multi-tier CPS workloads via the Web PI:
Multi-tier applications in Azure Stack
By now we know that Azure Stack is consistent with Microsoft Azure. If I sign in to the Azure Portal (as a tenant obviously) I see that I've multi-tier applications available to deploy right from the Azure Marketplace!
If I choose to deploy the SharePoint 2013 non-HA Farm application, the wizard asks me to provide the details of the different VMs that are required for this deployment. In the picture below you can see that this SharePoint farm requires three VMs (for the domain controller, SQL Server and SharePoint).
But also, you may have noticed the button on the Summary blade that says: Download template
Wait a minute! Is this an ARM JSON template that I can use to deploy my application in a declarative way as we discussed on this previous blog post?
Absolutely! When you click OK, Azure Resource Manager (ARM) will start the deployment of the application (in this case a SharePoint farm) as described in the JSON template and taking as parameters the inputs provided on the wizard. If you download and review the template you can understand how SharePoint will be deployed, and of course, you can modify the template to suit your specific needs. I've downloaded the JSON template and opened with Visual Studio so that I can review its contents. If I check the Resources section in the JSON outline, I can see the resources that are created:
As you can see the template will deploy a set of required resources for this application, such as a storage account, a virtual network, load balancers, network interfaces and three virtual machines (AD, SQL and SharePoint). To ensure resources are deployed in the right order, resources can use the dependsOn property to indicate which resources should be deployed beforehand. Resources that don't have the dependsOn property then are deployed first concurrently (for example, storage account, public IP addresses and the virtual network). Other resources like the VMs have to be deployed in correct sequence because the ARM model requires that specific objects must be in place before creating a VM as described in the following picture:
But also, it's important to coordinate how the VMs are deployed and configured, because for this particular scenario, while you can deploy the three VMs at the same time, you need to configure Active Directory Directory Services (AD DS) on the DC VM first, then you need to install and configure SQL Server on the SQL VM, and finally, you can install and configure SharePoint on the SharePoint VM. These dependencies are properly defined in our SharePoint JSON template. If you check the code for the ProvisioningADDomainController, ProvisioningSQLServerVM and ProvisioningSharepointVM resources in the JSON template, they are of type Microsoft.Resources/deployments, meaning that they'll deploy another template to provision the AD, SQL and SharePoint VMs. You can find the template they'll use checking the template URI property. For example, for the AD VM, it references a variable:
"templateLink": {
"uri": "[variables('ProvisioningADDomainControllerUrl')]",
"contentVersion": "1.0.0.0"
},
If we check the ProvisioningADDomainControllerUrl variable in the template, it references a parameter:
"ProvisioningADDomainControllerUrl": "[concat(parameters('baseUrl'),'/provisioningDomainController.json')]",
If we check the baseUrl parameter:
"baseUrl": {
"type": "string",
"metadata": {
"artifactsBaseUrl": "",
"description": "URL to acquire other templates"
},
"defaultValue": "https://gallery.azure.com/artifact/20151001/sharepoint2013.sharepoint2013farmsharepoint2013-nonha.1.0.9/Artifacts"
}
So, the template that will be used for deploying the DC VM is:
And using a similar procedure, the templates used to deploy the SQL VM is:
And for the SharePoint VM:
Also, checking the JSON template, you'll notice that the three VMs will be provisioned at the same time, given that they don't depend on each other. The only dependencies they have are on resources that are required such as NICs or the storage account:
"dependsOn": [
"Microsoft.Resources/deployments/SettingUpStorageAccount",
"Microsoft.Resources/deployments/CreatingNetworkInterfaces",
"Microsoft.Resources/deployments/CreatingAvailabilitySets",
"Microsoft.Resources/deployments/SettingUpLoadBalancers"
],
If you check the template deployment for the DC VM, you'll see that besides deploying the VM, it will also be configured as a domain controller leveraging the DSC Extension (to be covered in details in our next blog post):
"type": "Microsoft.Compute/virtualMachines/extensions",
"name": "[concat(parameters('adVMName'),'/InstallDomainController')]",
"apiVersion": "2015-06-15",
"location": "[parameters('location')]",
"dependsOn": [
"[resourceId('Microsoft.Compute/virtualMachines', parameters('adVMName'))]"
],
"properties": {
"publisher": "Microsoft.Powershell",
"type": "DSC",
"typeHandlerVersion": "2.13",
So basically, once the ProvisioningADDomainController resource deployment is completed, we'll have a domain controller up & running.
The next step is to configure DNS in the environment, so that the VMs use the DNS provided by the DC VM and not the one provided by Azure. This is done by the UpdatingDNStoPrimaryADVM resource deployment. You'll notice that ARM will wait until the DC is up & running and the SQL and SharePoint VMs are deployed before doing this configuration:
"name": "UpdatingDNStoPrimaryADVM",
"type": "Microsoft.Resources/deployments",
"apiVersion": "2015-01-01",
"dependsOn": [
"Microsoft.Resources/deployments/ProvisioningADDomainController",
"Microsoft.Resources/deployments/ProvisioningSQLServerVM",
"Microsoft.Resources/deployments/ProvisioningSharepointVM"
The next activity to do is to configure SQL Server in the SQL VM. You can see that ARM will do this in the proper order (after DNS is configured) using this dependency on the ConfiguringSQLServerVM resource deployment:
"name": "ConfiguringSQLServerVM",
"type": "Microsoft.Resources/deployments",
"apiVersion": "2015-01-01",
"dependsOn": [
"Microsoft.Resources/deployments/UpdatingDNStoPrimaryADVM"
],
And the final step is to configure SharePoint on the SharePoint VM. This is done on the ConfiguringSharepointVM resource deployment and as before, ARM will make sure this is done right at the end given that this resource has a dependency on having SQL Server configured beforehand:
"name": "ConfiguringSharepointVM",
"type": "Microsoft.Resources/deployments",
"apiVersion": "2015-01-01",
"dependsOn": [
"Microsoft.Resources/deployments/ConfiguringSQLServerVM"
],
I've described the process above in the following diagram, where you can see in detail the resources that are created first (the ones that don't have dependencies) and how the resources that depend on them cannot be created but until all the required dependencies are deployed, having the last resource deployed the SharePoint configuration on the SharePoint VM:
Great! After you deploy the template above you'll have a SharePoint farm in your Azure subscription. But what about Azure Stack? As a tenant, can I deploy a multi-tier application as the SharePoint farm we discussed above?
Of course J !!!
Remember, Azure Stack is also powered by ARM. You can use the template and adjust it to use on your Azure Stack TP1 installation (TIP – You can use this script to facilitate checking if your template have compatibility issues with Azure Stack) or you can leverage some of the sample multi-tier applications that have been already tested to work with Azure Stack getting them from the Azure Stack Quick Start GitHub repository. For example, you can find here a SharePoint farm JSON template similar to the one we reviewed for Azure, but this one has been tested to work with Azure Stack. And as usual with ARM (Azure and Azure Stack), you can deploy the JSON template via the portal, or via Visual Studio, PowerShell or the Azure CLI. You can refer here for more guidance, or also, you can check this short video as well.
This is great for tenants! Now they can deploy multi-tier applications leveraging the out-of-the-box functionality provided by ARM! But hey, what about Azure Stack admins? Can they still provide curated multi-tier applications to their tenants? Absolutely! Azure Stack administrators can create Azure Stack Marketplace items to offer them the applications required. You can find here detailed guidance about the Azure Stack Marketplace and for creating and publishing marketplace items in Azure Stack. For example, as an Azure Stack administrator, I've created and published the multi-tier SharePoint application described above and made it available to tenants to easily deploy a SharePoint farm in their subscriptions:
And in case you may be wondering, yes, Azure Stack tenants can use automation solutions such as Azure Automation for deploying and configuring their applications. For example, an Azure Stack tenant could configure the DSC extension on their VMs to be registered as a DSC Pull Server in Azure Automation using this JSON template. Once in Azure Automation, the Azure Stack tenant could apply DSC Configurations to configure their VMs are required. For example, the picture below shows my Azure Automation account with 4 DSC nodes, two from my Azure subscription (VM01 and VM02) and two from my Azure Stack subscription (AZVM01 and AZVM02). All four Azure and Azure Stack VMs were registered as DSC Pull Nodes using the same JSON template with a very simple cmdlet:
New-AzureRmResourceGroupDeployment
-Name
AADSCPullSvrDeployment01
-ResourceGroupName
WinVMRG01
-TemplateUri
"https://raw.githubusercontent.com/Azure/azure-quickstart-templates/master/dsc-extension-azure-automation-pullserver/azuredeploy.json"
-TemplateParameterFile
C:\Scripts\dsc-extension-azure-automation-pullserver\azuredeploy.parameters.json
-Verbose
Summary
While WAP does not offer an out-of-the-box mechanism for tenants to deploy multi-tier applications, some alternatives that can be implemented are:
- As a tenant, use WAP PowerShell cmdlets or an automation solution such as System Center Orchestrator to automate deployment of VMs, and leverage DSC for in-guest configuration.
- As a WAP admin, leverage SMA for end-to-end automation, VM Roles for provisioning the VMs and PowerShell DSC for the in-guest configuration.
Azure Stack offers out-of-the-box capabilities to deploy multi-tier applications via ARM. ARM is the deployment and orchestration engine that makes sure complex deployments are executed in the right sequence by:
- Using dependencies (dependsOn) in JSON templates for making sure resources are deployed in the right order and
- Leveraging the DSC VM Extension for in-guest configuration.
Azure Stack admins can publish multi-tier applications using templates and DSC extension in the Azure Stack Marketplace, or Azure Stack tenants can build their own multi-tier applications using JSON templates such as the ones published in the Azure Stack Quick Start repository.
Additionally, Azure Stack tenants could use the DSC Extension available on Azure and Azure Stack VMs to register them as DSC Pull Nodes in Azure Automation and then assign them DSC Configurations and/or use Azure Automation Runbooks to create/configure complex hybrid deployments!
We'll go into more details on future pots, but this is it for now! Until next blog!
Tiander and Victor