Everyday more and more organizations are migrating some workload to Azure. Most are just dipping a toe into the cloud rather than jumping in with both feet. A workload that often is selected to be one of the first to go into the cloud is Microsoft SharePoint. When you are moving any workload to the cloud, there are always obvious questions:
“What will the configuration look like in the cloud compared to on-premises? “
Let’s begin at looking at an existing on-premises SharePoint deployment for a particular company. The environment has 3 Front End Servers, 2 Application Servers and a SQL Always On Cluster. The Front End Servers are load balanced with a pair of KEMP LoadMasters. This company has deployed 4 SharePoint Web Applications each consisting of multiple Site Collections. All traffic to the SharePoint Web Applications are encrypted.
Since the environment is running on-premises each of the 4 Web Applications will have a dedicated Virtual Service on port 443. Each Virtual Service needs a dedicated Virtual IP Address (VIP) and a certificate to encrypt the Web Application traffic.
The company is using the following URLs for the Web Applications:
You will notice that all the Real Servers are the same for each of the Web Applications. You can accomplish this with using Server Name Identity (SNI). By selecting SNI in the IIS configuration you can assign port 443 to multiple IIS websites and use the Host Name to determine which site gets the traffic. This way each SharePoint Web Server needs only a single IP address assigned.
One reason for setting up unique Virtual Service on the KEMP LoadMaster is you want to monitor the health status for each Web Application individually. Simply configure the Real Server Check Parameters to send back the necessary Host Name information to the SharePoint Server.
Now if the Application Pool for Web Application 1 (WA1 Site) goes offline, only the Real Server for that Virtual Service is taken out of service. The rest of the Virtual Services are unaffected.
So this is all well and good in an on-premises environment. Now you want to move this SharePoint environment to Azure. “Can you move SharePoint to Azure without losing this functionality?” The short answer is YES, but let’s see how this all translates in the Public Cloud.
The SharePoint configuration will be nearly identical as on-premises other than some changes to how SQL Always On cluster is deployed in Azure. A pair of LoadMasters will also be deployed in Azure but the configuration of these will be significantly different since there is a limitation to having a single private IP address assigned to each interface in Azure. In this case you can set up a single Virtual Service on port 443 and create multiple Sub Virtual Services, one for each Web Application.
The LoadMaster allows for multiple SSL Certificates to be added in a single Virtual Service so you don’t need to worry about combining these into a wildcard or SAN/UCC certificate. So whether you are access WA1.kemp.com or WA4.kemp.com, there is a certificate installed that can be used to encrypt/ decrypt that traffic.
Since the Sub Virtual Services are being leveraged in this configuration, you are still able to monitor the health status of individual Web Applications just as you did in the on-premises deployment. So if the Application Pool goes offline for Web Application 1 (WA1 Site), only that Sub Virtual Service is affected.
With this configuration all traffic comes into the KEMP LoadMaster on a single Virtual Service or Virtual IP Address (VIP). You need to tell the LoadMaster how to direct traffic to the proper Sub Virtual Services. This is accomplished with Content Rules. Four Content Matching Rules are created, one for each URL.
Now you just need to assign each Content Matching Rule to the proper Sub Virtual Service and once again, all is well and good.
So whether you are jumping in with both feet or just dipping a toe into the cloud, you will soon realize that some configuration may need adjustment but you don’t need to sacrifice functionality.