Virtualizing Sharepoint - How about saving 74% of your power?

Folks - we have talked a lot in the past about Exchange 2007 workloads on VMware Infrastructure here (net: Exchange 2007 on VMware works GREAT, you can get more users per server than you can on physical, you can get all the goodness of the new Exchange 2007 features without the server sprawl they create, and still get all the storage savings).   Some folks have asked where they can get the detailed doc, including performance data.  Read on for directions on how to find ALL the solutions docs(i.e. "teach someone to fish") - but if you're lazy, just download it here (also to just to stop the "EMC doesn't share detailed info" doubters out there). 

BTW - there is more to come on that front - we still shattering our own current records of 16K users per ESX server (configured as 8 mailbox server role VMs each with 2K users) as new server platforms hit the market (last round was with the R900 series server with 64GB of RAM).

Now on to another "Tier 1 app".... Sharepoint is another great app, and a great app to virtualize since it's one that often has a lot of server components (like like Exchange 2007) and people were asking about our experiences running it on VMware.   Curious?   Read on....

So - first of all... a shout out to my brothers/sisters at the Cork Solutions Center (storagezilla has a great post on that crazy gang here).  In particular - James Baldwin - an all-round all-star.   Any customer who has called in for Replication Manager support knows, James is fantastic.   He's off doing solution testing now, and here are his findings:

The results:

In terms of performance, (omitting the SQL backend - which has been virtualized in other tests showing EXCELLENT performance), across 3 baseline tests, on average:

• Our Virtualized SharePoint server infrastructure farm out-performed the physical SharePoint farm by 4%,
• But only used 26% of the electrical power (watts) required to power the physical server infrastructure - put another way, that’s a 74% power saving over physical, put yet another way, going physical means 380% more power.  
• 1017 Watts versus 3952 Watts. 6 Power cords versus 22

Physical config:

 

Virtual Config:

 

 

And the comparison table:

 

Here are some excerpts from the upcoming Integration guide available to EMC and EMC partners...

Storage Layout:

 

ESX performance data:

Guest performance data:

 

Storage performance info:

Q: Where do I get stuff like this?!!

A: If you're a customer, EMC Partner (including strategic Alliance Partners), or an EMC Employee, it's right there on powerlink (screenshots of how to get there).

The documents come in several types:

• Reference Architecture Guides - these are around 10 pages long, and are kinda glossy.   Useful for a pointy haired boss, but still useful as a summary - they say "we tested this configuration, and it worked within these boundary conditions".  It provides a parts list, and all software versions if you want to recreate it.
• Best Practices Guides/Integration Guides/Applied Technolgoy Guides - These are usually 50-100 pages long, and contain the "do's and don'ts" (i.e. "configure the storage this way").   Sometimes where it's not self evident, they include the data that supports the conclusion.  Otherwise, they point to the Validation Test Report (below)
• Validation Test Reports - these are around 100-300 pages long, and contain all the data from the tests - ALL THE DATA, including failures (which is just as important as the successes).   There's little interpretation - it's left up to the
• Build Documents: step-by-step (with screenshots) of how we constructed the test (if someone wants to replicate it).

To give you an idea, here's a screenshot when I click on Exchange 2007:

I highlighted a couple things:

1. there are 33 different reference architectures (and this is just in the "mid-size enterprise" category - i.e. configs that cost tens of thousands of dollars) - there's one that reflects YOU.
2. Note we've done it for all sorts of platforms, and protocol types (iSCSI, FC, NFS datastores)
3. Note we've done it in remote replication and "local only" configurations. 
4. Note we've done it with our own (it's on the next screen) and 3rd party software (like other backup apps and tools from Ontrack, Quest and others)

If you're not a customer (or a competitor looking for something to help you because your company doesn't take the "end-to-end" solutioneering as importantly as we do) - just ask me, I'll provide anything you are looking for :-)

So here's the question of the day... 

"Why would anyone deploy in physical vs. VMware (except the obvious "it's not a supported guest OS type" or it's "not an x86-64 workload")."

Challenge to you:

"Please comment with an ask: "what's EMC's perspective on virtualizing mission-critical app _____ and do you have data to support that?" - I bet you I have it, and can post it... and if I don't have it yet, I can tell you which global solutions lab is building it :-)"

Comments

[Arno Nel]

Hi there

I am the editor and creator of SharePoint Magazine, an online magazine dedicated to the world of SharePoint and related Information Worker Technologies.

Would you be keen to guest author some articles? I specifically liked this post and would be keen on you to futher explore...

http://sharepointmagazine.net

[Dan]

Reason why not to virtualise with ESX ?

MS do not provide any support for MOSS running on VMWare infrastructure, only using MS Virtual Server. Sucks but reality.

[Virgil]

Please see this document:

7. For customers who purchase VMware products directly (or from an authorized reseller) and who have a Microsoft Premier-level support agreement, Microsoft will provide “commercially reasonable efforts” to support its software running within VMware virtual machines. However, after such efforts are exhausted, Microsoft support specialists may request that customers replicate the issue on a physical machine to proceed with the investigation. This request to replicate issues on alternative hardware (physical or virtual) is used to verify that the problem exists in the Microsoft software rather than in the underlying platform.

http://www.vmware.com/support/policies/ms_support_statement.html

[dcs]

On MS support, which is non-trivial, there are other routes besides Premier-level support. OEM licenses of VMWare ESX from HP, IBM, Dell and others provide another avenue to Microsoft support.

For instance, from the same page linked above:

For customers who purchase VMware products bundled with HP hardware and/or HP Services (Consulting & Integration & HP Outsourcing) and have a current HP support and subscription agreement on VMware and Microsoft, HP provides end-to-end support — including the VMware software and any licensed Microsoft software that is run within virtual machines.

[Jake]

If I read this article correctly these are the products that are now supported by Microsoft on VMWare. The list does include sharepoint.
http://support.microsoft.com/kb/957006/

[Damian Jauregui]

Firstly, I heavily disagree with the findings and can back this up with 4 weeks in the Dell scalability labs in Limerick, with both MS and VMWare guys there.

We were there to do a like for like comparison between Dell blades (2* dual core Xeon, 4GB RAM, 2* 36GB SCSI disks and SAN attached) * 20, and a bunch of VMs loaded on to Dell 6950s (4 * quad core Xeon, 32GB RAM, 5 * 73GB local RAID 5, SAN attached for VMs).

Using more realistic user scenarios, rather than just browse, search, modify, we studied how it stacked up with proper upload/download, check out/in, etc. thrown in to the mix, in other words, one heck of a lot more network based traffic to and from user to VM, VM to SQL, and back again.

We found that we suffered a 90% reduction in user count loaded on to each VM, from 5,500 concurrent connections per blade to only 500 concurrent users per ESX host before the dreaded '500 - Internal Server error' showed and the load injectors backed up.

During this period there was much reconfiguration of the hosts, con calls with the US VMWare teams, etc. No change.

With that said, we found 1:1 success on virtualising the SQL platform, which provides resilience through V Motion, but in regards to MOSS, don't bother unless you only have to deal with small workloads, or just casual browsing of basic content.

Regarding MS supportability for MOSS virtualised environments; there's a lot of shouting about it by MVPs and clever consultants, but MS will just tell you that you have to repeat the issue in a supported structure before they can help you. Not the end of the world really.

[Chad Sakac]

Damian - any chance you're going to be at VMworld Europe?

We're doing a joint VMware/EMC session on this topic (AP02).

I'd like to compare notes, as your findings do NOT jibe with what we found (including all the use cases you describe). We found the opposite... that SQL CPU utilization sometimes was VERY high to unnecessary complex and expensive SQL queries during document modification, check in/check out and recursive “listitem" operations (another reason why we didn't virtualize the backend, in this case it was a 16-way SQL Server config.

There's been even more since, and we're ramping up to do the same test with the next major release with 8vCPU and 256GB support with a virtualized SQL Server back-end.

[Werner Ladders]

Are they supported by Microsoft???