SharePoint Virtualized = Excellent For Production

Though it goes against my better nature, as it is not like me to go against what some really big brains say, I’m tired of hearing from many people as well as ‘company lines’ that SharePoint and SQL Server are not good candidates for virtualization.  It’s easy to sell it that way, but it’s just not true.

The simulations and production deployments that I have been a part of speak otherwise, along with candidate architectures and testing that have been conducted by EMC.  As a matter of fact, I would say that SharePoint and SQL Server are excellent candidates for virtualization, as every production implementation should consider their COOP (Continuity of Operations) and DR (Disaster Recovery) scenarios as a major point of design.

[ad#Google Adsense-1]

Using VMware virtualization, EMC hardware, and Microsoft SharePoint produces a combination of scalability, reliability, and ease of maintenance that is hard, make that extremely difficult, to match in both functionality, initial costs, and long term investment.

SharePoint on its own is a scalable environment.  The ability to add servers, currently focusing on Microsoft Office SharePoint Server (MOSS), to a farm environment is exceptional.  This farm, being back-ended by a SQL Server cluster makes the environment pretty fault-tolerant. With the addition of a load-balancer, ie. ISA Server array, running as the front firewall / load-balancer, provides for a single site, very fault tolerant implementation.  Add to this picture, an EMC SAN for high-performance, fault-tolerant storage, and your single site implementation is about as textbook immaculate as it can get.

In comes the virtualization aspect.  Scaling MOSS and SQL with an all physical environment results in high hardware costs, power consumption, and maintenance.  For example, if you have a 5 server MOSS farm, and 2 servers dedicated to the SQL cluster, you’ll likely find that at least 2 of the 5 servers are underutilized.  If not, you still have the concern of managing, storing, and powering 7 physical boxes.  This same environment can likely be built out as 3 VMware ESX/vSphere servers.  If you’re not aware of it, VMware has VMotion technology that will allow the servers to migrate from one host server to another if there is a hardware failure.  These 3 servers will mitigate potentially losing your MOSS index server or one of your load-balanced web front ends, and even your SQL Server cluster.  Imagine having a hardware failure, and still maintaining your software redundancy, though maybe at reduced performance.

These virtual servers, backed by a proper EMC SAN, and proper storage architecture for the servers and applications, most importantly SQL, will provide a highly performant environment with a lot less headache. I work for EMC, so if you see many references to EMC hardware, well, can you blame me? 🙂

Now you have the issue of handling DR and COOP operations, not just fault tolerance.  Have you ever dealt with MOSS farms spanning geographies?  Or attempting to restore a farm in an alternate location, including SQL Servers?  It can be a ton of work and requires many steps in a DR scenario.  It can involve database mounting, DNS management, network management, IP address management, firewall changes, and a number of other things not listed.  Using VMware SRM (Site Recovery Manager) technology, SAN replication, and your already in-place SharePoint implementation, recovery time can be reduced to minutes with most of the tasks being automated.  Keep in mind, as with any IT initiative, you have to consider your requirements, and you have to spend the proper time planning your architecture.

Done properly, in my opinion and experience, the implementation itself is less complex, less expensive, easier to manage and test, easier to maintain, and far less likely to let you down in worse-case scenarios.

[ad#Google Adsense-1]

Many people will try to sell you on the idea the SharePoint and SQL Server are poor candidates for virtualization, but I will flat out say that they are wrong.  Poorly architected solutions and lack of experience in the product space will lead them to say this.  Eventually, even these nay-sayers, though it may take some time, will come around to realizing that virtualization is extremely powerful and has risen to the challenge of keeping resource intensive applications running smoothly.

I hope this post will help decision makers, stakeholders, and architects keep an open mind when it comes to choosing the right path for themselves and/or their clients.  Oh and also, virtualization is also perfect for development, test, and stage environments. 😉

Disclaimer: This isn’t, in any way, an official EMC statement or document.  It is my opinion and based on my experience and research.

Have questions?  Hit me on the comments.  And yes, I do respect intelligent bashing, so try to teach me something if you’d like. 😉

Advertisements

3 thoughts on “SharePoint Virtualized = Excellent For Production”

  1. An excellent article that address alot of issues that we have been thinking the impact performance along with DR and business continuity. The only thing that our SAN is not using EMC, we are planning to use Clarion SAN for this implementation. I dont know if there is performance impacts. Keep the work up!

  2. Can you give us a sample configuration of a Sharepoint installation using ESX virtualized hosts? I am trying to sell this to management, and would like some examples that I could use in a test environment to help make my case.

    Thanks

  3. Joel, here’s a link to a sample MOSS architecture on ESX hosts, but could also be used in a similar configuration on any other virtualization platform, of course without Fault-Tolerance, HA, and DRS.

    http://d3planet.com/rtfb/files/2010/02/Sample-Virtualized-Architecture.pdf

    Here I’ve used 2 ESX hosts, configuring a redundant MOSS deployment (2-Node SQL Cluster, 2 MOSS web front-ends, and 1 MOSS app server/indexer). Each SQL node would be bound to a particular host. The others could be configured to utilize DRS so that depending on server load, vSphere would move a server (like the indexer for example) to a different host. This deployment can also be done on a single ESX Host server in a lab, and SQL clustering is not required but I wanted to show the ability to deploy that way. It just depends on how deep you need your proof-of-concept to be. MANY orgs are running MOSS environments completely virtualized. 🙂

    Hope this helps, and let me know if you need anything else and I’ll see what I can do.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s