After doing the Microsoft Cloud Show interview with Andrew Connell I thought it might be a good idea to write some of my tips and tricks for running SharePoint 2013 on Azure IAAS. Some of the stuff in this post are discussed in more depth in the interview and some things we just didn’t have time to talk about (or I forgot). I really recommend you to listen to the podcast as well and not just read this post.
Disks, disks and disks
As mentioned on the Microsoft Cloud Show interview more than once, one of the first things you should look into is your disk configuration for your Azure VM’s.
Use a lot of disks
One of the first things you must look into is the performance of disks. As you should be aware of SharePoint and SQL requires fast disks to operate with decent performance. When running an on-premises installation (virtual or physical) you have almost full control of the disk performance – you can choose from fast spinning disks to SSDs to different RAID configurations. But you cannot do that in Microsoft Azure. The virtual disks in Azure uses the blob storage for storing the VHD files, as blobs. Disk performance are often measured in IOPS (input/output operations per second) and in with the VHD files in the Azure blob storage we are limited to 500 IOPS per disk. Also worth noticing is that if you run the VM using the Basic tier offering, the limit is 300 IOPS per disk.
TechNet contains a couple of article about calculating IOPS and the need for IOPS. For instance in the article called “Storage and SQL Server capacity planning and configuration (SharePoint Server 2013)” we can see that a content database requires up to 0.5 IOPS per GB. If we translate that into an Azure VHD we see that we can only have about 5 content databases per disk, assuming that they grow to 200GB each (a total of 1.000 GB). The Search Service Application, specifically the crawl and link databases has high IOPS requirements, so they should be on dedicated disks and so on. This is exactly the same as on any SharePoint installation – in the cloud or on your own metal. But the hard limit on 500 IOPS per VHD makes it even more obvious, given that we do not have a choice.
So, when deciding which machine you are going to use for SharePoint and SQL, choose one with a lot of disks. For instance choose A4/A7 to get 16 disks or A3/A6 to get 8 disks.
Read and Write caching
A very important thing to configure for the Azure IAAS disks are the read and write caching, it is turned off by default on data disk – leave it like that!
SQL Server Filegroups and multiple data files
SQL Server has a concept called Filegroups which can be used to increase performance of databases. You can for a database in the primary file group add multiple data files and have them reside on different disks. (Thanks to Trevor Seward for the tip).
Disk striping
The maximum size of a VHD in Azure is 1TB (1.000GB), and the limitation is in the Azure blob storage. If you need larger volumes/disks in your Azure VMs then you need to stripe multiple disks into a single volume. Just add the VHDs and then use the Disk Manager to configure the disk striping.
Disk size
Create large disk files! You only pay for the space you actually use. If you store 1MB on a 500GB disk, you pay for 1MB. Reconfiguring disks cost you more!
SQL specific stuff
When running SQL on an Azure VM or any kind of virtual or physical hardware – do not forget to format the disk using 64K allocation unit size and do not forget to give the SQL Server service account “Perform Volume Maintenance Tasks” right. These two things makes a huge difference!
Examples (and just examples nothing else!)
For a single SQL Server this could look something like this:
Disk/Volume
Purpose
1
OS (default)
2
Temporary (default)
3
SQL Server binaries
4
Temp DB
5
Temp DB log files
6
Default SQL Server DBs
7
Default SQL Server DB log files
8
Search DBs
9
Search DB log files
10
Content DBs 1
11
Content DBs 1 log files
12
Content DBs 2
13
Content DBs 2 log files
14
Service Application DBs
15
Service Application DB log files
16
Backup 1
And for a SharePoint machine it could look like this:
Disk/Volume
Purpose
1
OS (default)
2
Temporary (default)
3
SharePoint binaries
4
Blob cache
5
Log files
6
Index files
7
ASP.NET Temporary files
8
Tools
9
Visual Studio (dev machine)
10
Project files (dev machine)
Note: do NOT store anything of value on the Temporary (default) disk, it will be wiped whenever Microsoft decides to. I would not even recommend storing SharePoint log files there (which I’ve heard recommendations of) since you might want to go back in time and search the logs eventually.
Virtual Machine size
Choosing the Virtual Machine size is one of the tricky questions; do you need RAM, CPU, Memory etc. “Fortunately” we do not have that much of a choice in Azure IAAS (compared to other vendors). We can choose from A0 to A9 – all the details here: “Virtual Machines Pricing Details”.
If we’re talking about SharePoint and SQL we’re even further limited – A3 to A7 are the ones with sufficient RAM/CPU for that scenario, but we can almost exclude A5 which only has CPU two cores and only support 4 data disks. There is no “perfect machine” here, it depends. With regards to running SharePoint you might want a lot of cores for search machines etc etc. A4, A5 and A6 are good candidates for SharePoint in my opinion. A3 might do for a simple dev machine.
Plan for High Availability
Let’s assume we’re setting up a SharePoint + SQL production environment in Azure, then you need to start to think about HA (High Availability). Part from the usual ways to do it (see my SPC 2014 presentation on the topic) there are a couple of other things that we must think of in Azure IAAS.
Location
Location should be fairly obvious. Do you want your stuff in North America, Asia, Northern Europe etc. It doesn’t have much with HA to do, but more about latencies and costs! Yes, if you want to be cost efficient check out the pricing in the different locations, it’s quite a difference.
Affinity Groups
Affinity Groups are a very important construct in Azure. Affinity Groups allows you to make sure that your cloud services, storage, virtual networks etc are placed “together”. Remember the data centers might be several football fields in size and you don’t want your machines scattered across all that space, that would only cause unwanted latencies. An Affinity Group makes sure that all your stuff in Azure are as close to each other as possible. Also this reduced our costs, since we don’t get any cross datacenter communication. An Affinity Group exists in one Location.
Cloud Services
“Cloud Services” are used in Azure to “group” instances together. Cloud Services have features such as end-points, load balancing and auto-scale. For SharePoint and SQL don’t even think about auto-scale though.
It is very important to note that if you are using SQL Server Always-On Availability Groups, this SQL Server setup must be in its own Cloud Service, separate from the clients accessing it.
Availability Sets
Availability sets are a logical construct that allows you to specify a group of instances/roles. Whenever Microsoft must reboot one of your VMs for maintenance or other purposes, they will respect the Availability Sets and make sure that only one of the machines within an Availability Set are down at a time. For instance grouping all SharePoint Web Servers into one Availability Set, makes sense.
An example
Here is one example that I’ve shown when presenting this that gives you an idea of how an Azure IAAS SharePoint and SQL infrastructure might look like, once again just an example!
SQL Server optimizations
I will not dig too deep into tips and tricks with SQL Server specifically but instead urge you to read the really good article “Performance Best Practices for SQL Server in Azure Virtual Machines”. That article gives you all the details and a nifty check list.
Short notes
Here are some other small things for you to remember:
- Office Web Apps 2013/Office Online/WAC are NOT supported on Azure IAAS at the moment – hybrid with a site-to-site VPN is your way if you want WAC.
- Always set your machine in High Performance mode .
- If you’re using the public IP of the Cloud Service, remember to always have a machine running in that Cloud Service, otherwise the IP will change. Or use the Azure static DNS offering.
- For development SharePoint machines and SQL – do not use the Azure SQL images, instead use your MSDN SQL Server Development Edition. If you don’t you will be billed for the SQL Server resource usage and that is even more expensive than running the actual VM.
Summary
That was a mouthful of tips and tricks and I hope you get something out of this. Of course there are plenty more, don’t be shy and use the comments for your best tips and tricks. I might update the post with your best tips or other things that I find. And also note, that these are in no way the official tips and tricks from Microsoft and the Azure Team, just my experience from working with it.