Running SharePoint farms is an increasingly popular IT workload for the cloud/Azure for all sorts of reasons. There are though some important differences in running SharePoint on-premises to on-cloud, and this is mainly what this blog-post is about.
But first, some Cloud Kool-Aid…
Why Azure Absolutely Rocks for SharePoint Farms
In short, Azure lets you spin up lots of very powerful machines if & when you need it with very little effort, very quickly. It’s not specific to Azure of course but Azure is the only IaaS (Infrastructure as a Service) solution I know in any depth, what we me being an MSFT employee and all that.
Example SharePoint Problem
Imagine your SharePoint public site goes live, running whatever super-awesome services you’ve carefully built & is suddenly hit by way more users than you planned for. This is normally great news but because of this higher-than-expected workload, performance is dropping off and users & managers alike are getting fed-up with slow response times.
On-premises solution: run around like a headless chicken trying to add extra hardware to the farm from somewhere, anywhere. I can tell you from experience this is harder to add scalability for production setups than it sounds and it’s not fun. Panic as you realise the same thing – server-grade kit doesn’t grow on trees on-premises.
Azure solution: deploy new monster virtual machines to farm; enable for roles that are bottlenecking - all within just a few minutes if you’ve scripted it nicely. The scale of the available VMs range from normal to absolutely insane – all just seconds away if you need them.
Then, once you don’t need the extra anymore, downscale the farm and delete machines instances as needed. You can have 2 server farm with x4 cores/16GB RAM per server or a 50 server farm with x32 cores/448GB RAM if you want; from one to the other and back again in no time at all if needed. Try doing that on-premises!
Azure vs. On-Premises SharePoint Farm Management
So back on-topic again; there are certain key differences in running the same SharePoint farm/environment on either on-premises or on-cloud. It’s easy to think moving SharePoint into Azure is just a case of setting-up equivalent machines in Azure and we’re done. Nearly, but there are some important differences that may bite you if you don’t have them clear & planned for.
Remember, this article is about running SharePoint on Azure Infrastructure as a Service (IaaS) so in other words, we run the hardware but you run the rest. If you want fully managed SharePoint in the Software as a Service (SaaS) flavour because you don’t want to worry about failovers, reboots, patches etc then what you want is SharePoint Online. The right tool for the job and all that.
Machine Outages – They Happen in the Cloud
This is a big one if you’re not used to working in-cloud. For on-premises SharePoint it’s not uncommon for some customers to freak-out at the idea of having servers rebooted; suspended, or anything except flawless, 5-9s operation. Normally, if a machine goes offline then SharePoint is often likely to throw its toys out the pram, especially if SharePoint + stuff is not setup with high-availability in mind, which is often the case on-premises as it’s expensive to buy real servers to run the extra roles.
In Azure on the other hand, single machines are suspended & go offline on a semi-regular basis, both planned and unplanned (unplanned service-drops also plaguing the on-premises world too btw). Yes indeed; virtual-machine hosts are patched & updated routinely and can failover too – both of which will temporarily knock offline anything running on them until service is restored.
But fear not; it’s quite ok & expected that individual machine outages happen in the cloud-world. In fact the Azure uptime SLAs of 99.95% are not guaranteed if you only have a single-machine doing one job, and that applies to SharePoint + dependencies too.
Yes indeed, this outage issue is handled quite nicely by using Azure availability sets which in short makes sure that a machine for a given role is always online. Read the article if you’re worried about machine outages – it explains better than I could why these will happen and how to work around them.
Configure Availability Sets for SharePoint Dependencies
So with this is mind, we just need to make sure we double-up & add each SharePoint dependency into availability sets. Let’s just recount what these SharePoint dependencies are:
- DNS/Active Directory
- SQL Server cluster
- App servers, covering all service-application instances used (user profiles, business data connectivity, etc)
Remember, if any one of those dependencies fail then we have an outage. The good news is of course that every part of that chain is designed to be “failover-able”, which is essentially why single outages just won’t impact SharePoint overall serviceability.
So for a high-availability SharePoint farm we need at a minimum:
- Platforms availability-set
- AD/DNS servers x2
- SQL Server availability-set
- SQL Servers in AlwaysOn cluster
- Web-Front-Ends availability-set
- X WFE servers, depending on traffic
- App-servers availability-set
- App servers x2
- Search servers availability-set if needed
All of this means of course that Azure knows it can only suspend one machine at a time in each set when updates are needed to the VM hosts, plus each machine will have its own Azure fault-domain (separate power-supply; switch; etc) so will be more resilient to failures.
And all of this means that our SharePoint farm will stay online when individual VMs go offline for any reason.
Configure High Availability for SharePoint in Azure
Most of the rest of what you’ll need to do has already been covered and is the same as on-premises – make sure there’s no single point of failure for SharePoint in Azure in just the same way.
Azure Storage Accounts & Disc IO Throughput
In Azure, storage accounts have up-to 20,000 IOPs per account, which may actually not be enough depending on the load. SharePoint SQL queries can be pretty hard on SQL disc-IO depending on what’s being read, so be aware that you may need to move SQL Server into separate storage accounts.
There are various storage performance options to play with – just be aware this may be a thing.
Remote Connectivity to SharePoint VMs
If for some reason your cloud-based Active Directory breaks then you could lose the ability to connect to your VMs without some serious work. Azure VMs (Windows) are connectable via remote-desktop and remote-PowerShell only, so if your AD is unavailable then you might be looking at this when you try and remote-desktop in:
Just bear in mind that local console access isn’t possible with Azure. You can of course rescue the virtual disks, but just make sure your AD machines are always on (and before starting any dependant machines if you must shut them down).
Static IP Allocation for Azure Virtual Servers, SharePoint or Otherwise
For the love of God, don’t set by hand private IP addresses in the control-panel for any Azure machine. If you do, you can kiss goodbye to it pretty much right away as Azure won’t be aware of it so all endpoints will fail, including remote-desktop. You’ll cut the VM off from the outside world in other words and have to kill it (although again, you can save the VHD at least).
To set a static IP for a VM, use Set-AzureStaticVNetIP instead.
SharePoint WWW Load Balancers & External URLs
Load-balancing HTTP traffic & external access to the farm is trivial in Azure – you just add network-load-balanced HTTP endpoints to the SharePoint WFE virtual machines in the cloud service that your SharePoint WFEs are on.
Go-to a WFE in the management portal, under virtual machines. Click “endpoints” and add a new one.
Add “standalone” for if it’s the 1st VM endpoint, specify the ports and you can say it’s a “load-balanced set”. Once created you’ll be able to add the same endpoint to your other web-front-ends
Like any other self-respecting network-load-balancer, the Azure cloud-services NLB will check on the health of each machine and remove it from the balancer if necessary.
Once setup, accessing your cloud-services public URL will redirect to your SharePoint WFEs. If you have a custom-domain for SharePoint (highly likely you won’t want the default Azure domain), then add that to the cloud-service & voila.
Add Cloud Services URL Alternative Access Mapping
Very important: remember to extend your application into a new IIS site that has the cloud-services host-header. If you don’t, you’ll see messages like this:
Alternate access mappings have not been configured. Users or services are accessing the site http://sp15-wfe with the URL http://sfb-cloud.cloudapp.net. This may cause incorrect links to be stored or returned to users. If this is expected, add the URL http://sfb-cloud.cloudapp.net as an AAM response URL.
Accessing a SharePoint site through any other name that’s not in the alternative access mapping isn’t supported of course, and will break things. If you don’t add a new IIS website, at least add the domain name to the list of AAMs.
That’s it for now; just a starter on running SharePoint “on-premises” in Azure. More to come; feedback is welcome.
// Sam Betts