Azure Stack: Deploying A Highly Available App Service Solution Series

So for my next few blogs, I am going to document how we deployed Azure Stack’s App Service in a Highly Available deployment in our multi-node Stack.  This multi-part blog will consist of deploying all the pre-requisites for App Services including the file servers, the SQL servers, and the actually App Service itself.

I will be discussing several different topics as I publish the next few blogs.  Below is a high-level list of items we will cover.

  • Planning
  • Creating Certificates
  • Creating Resource Groups
  • Creating vNets and NSG’s
  • Deploying the File Server Cluster
  • Deploying the Always ON SQL Servers
  • Creating Azure Active Directory Application
  • Deploying App Service

For this blog, I will talk about what we had to do to plan for our HA App Service deployment.  Let’s say that my original plan changed greatly as I actually started to document and test deploy on various ASDK servers I spun up.

Part I:  Planning For A Highly Available App Service Deployment

First of all, start by reviewing all the Microsoft Documentation online for deploying App Service on Azure stack.  Run through the entire deployment several times on an ASDK just to get the basic understanding of what will be needed before you even begin installing the App Service RP.

https://docs.microsoft.com/en-us/azure/azure-stack/azure-stack-app-service-overview

Capacity Planning

The Azure Stack that I am deploying App Service to currently is only a 4 node stamp that we received from Dell EMC.  The nodes are their medium level nodes so they are pretty decent sized with RAM and Storage, etc.  However, a 4 node solution is the smallest you can get and for the long run won’t handle very many tenants.  This stamp we will be using for POC as a Service.  Once Microsoft releases the features soon to be able to expand an existing Stack to 16 nodes we will plan on expanding this stack from 4 to 16. So I need to do some capacity planning based off what we have currently and also making sure we have in place a scalable solution to handle a workload of 16 nodes some day.

The link below will help guide you in your capacity planning:

https://docs.microsoft.com/en-us/azure/azure-stack/azure-stack-app-service-capacity-planning

For myself, I started with the Minimum recommended number of instances for a production environment with some changes.

The Controller role:

I went with the recommended minimum of two instances.  This way when the App Service install creates these two VM’s they will also be created in an Availability Set as well for high availability.  I used two A1 standards VM’s as recommended as well.

Front End role:

Again, went with the recommended minimum of two instances using A1 Standard VM’s.  I had thought about bumping this up to bigger VM’s at first but for a POC as a Service solution, I doubt that we will hit more than 100 requests per core on each VM.  If we would use this stack for more than POC’s I might scale these VM sizes larger or even add more than two.  I want to research what would be better, larger VM sizes with more cores, or more smaller VM’s.

Management role:

For the management role, I went outside the recommendations.  I used a slightly larger VM size than the recommend A3 standard.  This was in planning for adding more nodes later.   I still only deployed the two recommended servers.

Publisher role:

For the publisher role, I kept the standard A1 VM instances.  I don’t see the need or the workload being too big in the FTP/FTPS traffic area for our POC environment.

Web worker role:

I deployed 4 instances of the A1 Standard for the Web worker role. I do plan on deploying more worker roles for the dedicated work role down the road.  I will keep an eye on the workload that we have and make that call later.

 

Before We Start Deploying App Service

I have been pretty successfully deploying App Service now sine about TP3.  All of them have been on the ASDK after TP3 of course and this was going to be my first multi-node stack.  So in previous deployments, I didn’t care about HA of all the subsystems that App Service depends on.  So planning for this brought out some issues I hadn’t had to deal with on Stack yet up to this point.

Before we get started there is some task that needs to be completed beforehand.

  • Certificates
  • File Server role
  • SQL Server

https://docs.microsoft.com/en-us/azure/azure-stack/azure-stack-app-service-before-you-get-started

Certificates for Azure Stack App Service

In the past, I have blogged about certificates.  I don’t think I had included the ones for App Service.  I will write another blog dedicated to App Service certificates and some lessons I learned.  I made a mistake of getting too many wildcard certificates that ended up costing about 550.00 a piece.  Ended up not using 3 of them and having to go back and get a wildcard cert that supported multiple SAN names.

https://docs.microsoft.com/en-us/azure/azure-stack/azure-stack-pki-certs#optional-paas-certificates

File Share and SQL Server

In my situation with my current multi-node stack, there is no Express Route configured or a VPN connection to extend an Active Directory environment to VM’s running at this time.  Since our POC as a Service won’t offer that right at the start we haven’t been in an urgent rush to get our Stack connected that way to Azure or on-premise networks.  So I ran into an issue trying to build the two clusters I needed for the FileShare and for the SQL Always On group.  I did some research and did discover that with Windows Server 2016 there was a way to create failover clusters without Active Directory.  However, the purpose of this exercise was to try and document and make possible redeployments of the same solution across many stacks in the future.  So I needed an AD environment within Stack so my FileShare and SQL servers could join and be managed.  I will be honest, I am not sure this was the best way or the recommended way.  I would love to hear back from others that have gone another direction for HA.  However, this is how I went and it worked for me.

I deployed a two VM Active Directory solution using Availability Sets.  I then deployed VM’s for my FileShare cluster, and another two VM’s for my SQL Server Always On Group.  Each cluster within its own subnet within the same vNet. This I will go into detail in my next few blogs in this series.

  • The High-Level Architecture
    • Resource Groups, vNets, NSG’s, etc.
  • Deploying Active Directory
  • Deploying a FileShare Cluster
  • Deploying a SQL Always On Group
  • Deploy the actually App Service
  • Monitoring and Backing up App Service

 

In the next blog in this series, I will go more into detail about how I deployed the supporting infrastructure for App Service.  I will blog about my App Service Certificates, Deploying Active Directory in Azure Stack VM’s, deploying a 2 node file cluster for the file share, and deploying a 2 node SQL Alway On group. Then at the end, I will actually blog about deploying App Service itself.

Part 2:  The High-Level Architecture

Tagged with: , , , , ,
Posted in App Services, Azure Stack

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s

Follow Kristopher Jon Turner on WordPress.com
Categories
Archives
%d bloggers like this: