The SharePoint Swiss Army Knife

I’ve finally succumbed to the awesomeness that is cloud computing and have fallen in love with the possibilities of spinning up virtual machines at a moments notice. Can you imagine that? In minutes, you can practically host a virtual machine any where in the world!

Being a SharePoint guy, I thought, “Whoa, cool! Does that mean I can geo-distribute my WFEs around the globe to better serve my end-users around the world?” Unfortunately, the answer is no… Although stretched farms are supported, there are 2 support requirements documented by Microsoft:

1. Latency between your web front ends and database servers must prove to average < 1 millisecond over a ten-minute period.

2. Bandwidth between your datacenters must be at least 1 gigabit per second.

Given that we haven’t been able to bend the laws of physics just yet, meeting these numbers prove to be a task that isn’t quite possible at the moment. So my dreams of having a geo-distributed SharePoint collaboration farm were crushed leaving me with a centralized farm to ponder about. But where in the world should this centralized farm be hosted?

Ping… ping… ping…tcping!

If you’ve been working with Azure then you probably already knew this, but if you didn’t, you’ll probably come to a day when you’re trying to ping various public websites only to receive “Request timed out” messages.

Does the internet not exist in the cloud? Yes it does, except the Azure team decided that it’s best to not enable certain types of traffic like outbound ping and tracert for various security reasons. Funny thing is, you can still ping bing.com though 🙂

A little bit of searching led me to a post by Rob Blackwell that describes using Eli Fulkerson’s tcping instead. Also inspired by Rob’s post, I was able to use tcping to record latency metrics (in milliseconds) between each of the Azure datacenters as well as from my office location in Aliso Viejo, CA.

The process I used was this:

1. Created a Small VM using the SharePoint template in each Azure datacenter. I used the SharePoint VM image because it already has IIS set up so I don’t have to fudge with setting up a default website to test. Also of note was the inability to create VMs in the US-North and US-South datacenters. I guess they don’t support VMs there.

2. Configured public/private endpoints for port 80 on each VM.

3. Logged onto each VM and ran tcping 20 times against each site including one hosted in my local office’s datacenter. Example:

tcping.exe -n 20 hostname > C:\AzureLatency\USWest-USEast.txt

4. Logged all the data in Excel for analysis.

Although this data isn’t going to be entirely representative of what the end users will experience, it gives us the ability to ball park the level of experience that users around the globe can expect in terms of latency. And if I’m not interpreting this data incorrectly, it looks like the US West datacenter will provide the best overall experience to a global set of end-users based on having the combination of lowest latency average to other geo-locations, lowest standard deviation of latency between the geo-locations and lowest maximum latency that was experienced during my testing.

So there you have it. Go west!