You’re a cloud operator for an Azure Stack Integrated system and for whatever reason you have the task of deploying the App Services Resource provider…
In this blog series, I’m going to take you through the considerations and deployment processes I went through for the App Services resource provider on an Azure Stack Integrated System. This will work on an ASDK but it’d get fairly crowded on your single server instance if you follow the HA design all the way through.
Other posts in this series:
Highly Available App Service 1.4 on Azure Stack – Step 1: Design considerations (this blog)
Highly Available App Service 1.4 on Azure Stack – Step 2: Deployment
Highly Available App Service 1.4 on Azure Stack – Step 3: Post-deployment setup (in process)
Highly Available App Service 1.4 on Azure Stack – Step 4: Updating App Service (in process)
As an Azure Stack Cloud Operator we’re responsible for various operations, decisions and tasks. When the decision to offer your tenants a new resource has been made, there are often many things to consider. These include design, deployment and management of the various resource providers.
Edit: A worthwhile read from fellow MVP, Thomas Maurer, on the Considerations on deploying apps and services on Azure Stack: https://www.thomasmaurer.ch/2018/12/considerations-using-azure-stack/
You’re back? Great, let’s continue…
This blog is about the design considerations specific to the App Service resource provider.
Firstly, what is App Service? This is part of how Microsoft answer that question:
“Azure App Service on Azure Stack is a platform-as-a-service (PaaS) offering of Microsoft Azure available to Azure Stack. The service enables your internal or external customers to create web, API, and Azure Functions applications for any platform or device.”
The key takeaways from the above are PaaS offering of Web Apps, API Apps and Azure Functions on Azure Stack.
For any of you that had exposure to Windows Azure Pack (served me well for many years) you would be familiar with Azure Pack Websites. i.e. a Web Farm managed by Azure Pack. At the heart, this is where App Services started but has grown up to be what we see available in Azure Stack today
Before we continue, a quick prerequisites check – DNS
Make sure your Azure Stack DNS is configured correctly. This is one part of an Azure Stack implementation that is sometimes overlooked. The DNS zone management for the region zone should be delegated to Azure Stack DNS servers.
A very important note from the docs is this quote:
“In scenarios where you specified your external Azure Stack DNS Zone to look like a child domain of your corporate domain name, conditional forwarding cannot be used. DNS delegation must be configured.”
More information on Azure Stack DNS integration can be found here:
https://docs.microsoft.com/en-us/azure/azure-stack/azure-stack-integrate-dns
Side note: If you’re using Azure DNS and want to know how to delegate a child zone, I’ve noted this process down in this blog
Design Considerations
For the App Service resource provider, there are a couple of design considerations that had to be made, High Availability and Scale
High Availability (HA) – This deployment (and blog series) are targeted at a 4-node scale unit used as production. This means HA is a must. (If you’re running on ASDK, then HA might not be a concern as this can have an impact on the available resources no the node.)
Scale – Once the service is deployed, we will be offering this to our tenants. Using the default install process we have the option to deploy a number of shared web workers but no dedicated workers. We need to consider this in our post install steps
Additionally, scale is not limited to the web workers. The scale of the deployment can dictate how many of each other role we need. Because I was really unsure how much the service will be utilized, I decided to stick with the defaults and will monitor accordingly.
Infrastructure roles (SQL & File)
For App Service to run we need a SQL instance and a File server already deployed. There are a couple of ways to achieve this; manually, ARM template or a mixture of the two
For non-HA deployments there is a ready to go ARM template available for the file server https://aka.ms/appsvconmasdkfstemplate and for a non-HA SQL Server you can deploy a marketplace item and configure accordingly.
You don’t necessarily need to use a VM on Azure Stack to provide the File service, there are several supported scenarios:
- Windows file server
- Windows file server cluster
- Non-Windows file server
- Non-Windows file server cluster
- NAS (Network Attached Storage) device
Because our deployment is HA we are going to use the recently published HA QuickStart template available on GitHub https://github.com/Azure/AzureStack-QuickStart-Templates/tree/master/appservice-fileserver-sqlserver-ha. We’ll cover more of this on the next blog post.
Using the defaults, this table shows the compute requirements for this template
| Infra Role | vCPU | Memory |
|---|---|---|
| Domain Controller | 1 | 3.5 GB |
| Domain Controller | 1 | 3.5 GB |
| Storage Node | 2 | 7 GB |
| Storage Node | 2 | 7 GB |
| SQL Server Node | 2 | 7 GB |
| SQL Server Node | 2 | 7 GB |
| Total | 10 | 35 GB |
If you’re comfortable for your Azure Stack deployment to be dependent on external resources then it would save resources on the scale unit to move the tasks off stamp. For my deployment, I am hosting the entire App Service infrastructure on Azure Stack.
App Service roles
There are several roles in the App Service provider that need to be considered. Because we’ve already determined that our deployment needs to be HA, this will be the default moving forward
The App Service core roles:
- Controller role – the controllers are essentially responsible for managing and deploying the other roles in the farm
- Front-end role – The front end routes requests to web workers depending on web worker availability.
- Management role – The Azure App Service management role is responsible for the App Service Azure Resource Manager and API endpoints, portal extensions (admin, tenant, Functions portal), and the data service.
- Publisher role – The publisher only handles FTP/FTPS traffic. This is for upload/download of source content
- Web worker role – This is the server that runs the websites code. CPU and Memory are important to monitor
More detail on each role can be found here
A good visual overview of the App Services roles can be borrowed from the Azure Pack Websites blog: Windows Azure Pack (WAP): Web Sites Overview https://technet.microsoft.com/en-au/library/dn457747.aspx
The docs give a default configuration that would meet the initial requirements of most HA deployments. We will use these values in our deployment as they will meet our HA and Scale needs, at least initially.
| App Service server role | Number of instances | Compute SKU |
|---|---|---|
| Controller | 2 | A2 (2vCPU, 3.5GB) |
| Front End | 2 | A1 (1vCPU, 1.75GB) |
| Management | 2 | A3 (4vCPU, 7GB) |
| Publisher | 2 | A1 (1vCPU, 1.75GB) |
| Web Workers - shared | 2 per tier | A1 (1vCPU, 1.75GB) |
| Web Workers - dedicated* | 2 per tier | A1 (1vCPU, 1.75GB) |
*the App Service installer does not include these and must be deployed in the post deployment setup
Based on my experience on the WAP Websites, for the Controller, management and publisher I never had any instances where I felt (or the numbers added up to) more than 2 instances for each role were required. I will use this baseline for now and review from time to time.
For the Front Ends, these are important to keep optimised as each transaction traverse these resources. Slow Front Ends would slow every published App down so keep an eye on these guys.
For the Web worker roles, I recommend to scale out not up. i.e. have more instances rather than bigger VM sizes. If your workers are over worked then the app services they host will be affected. The Web worker sizing considerations on the capacity planning site have a great formula to go by.
Now that we know what we will be deploying, how much resources are required:
| App Service Role | vCPU | Memory |
|---|---|---|
| Controller | 2 | 3.5 GB |
| Controller | 2 | 3.5 GB |
| Front End | 1 | 1.75 GB |
| Front End | 1 | 1.75 GB |
| Management | 4 | 7 GB |
| Management | 4 | 7 GB |
| Publisher | 1 | 1.75 GB |
| Publisher | 1 | 1.75 GB |
| Web Workers - shared | 1 | 1.75 GB |
| Web Workers - shared | 1 | 1.75 GB |
| Web Workers - dedicated | 1 | 1.75 GB |
| Web Workers - dedicated | 1 | 1.75 GB |
| Total | 20 | 35 |
Summary totals:
Infrastructure roles – 10 vCPU & 35 GB
App Service roles – 20 vCPU & 35 GB
When combining the App Service resource requirements to the Infrastructure Role requirements we have a total usage of 30 vCPU and 70GB of Memory. In a smaller spec’d 4-node scale unit, that may have more of an impact that you’d notice in a beefy 16-node implementation, but it’s still not all that much in the grand scheme of things.
Some thoughts on Monitoring:
For the ongoing review I’ve mentioned monitoring the resource usage to ensure everything is humming along nicely. There are many ways you could do this but for me, I have an instance of System Center Operations Manager (SCOM) running that is used to monitor Azure Stack. So for this deployment, we will enable monitoring of the App Services infrastructure by SCOM and review performance metrics from there.
Now that we’ve reviewed our design considerations and made some decisions, it’s time to get going on our deployment.
See you in the next post 🙂
Happy Stacking!
Dan
Next post in this series: Highly Available App Service 1.4 on Azure Stack – Step 2: Deployment