After reading Mike Watson and Todd Klint's take on SQL Mirroring in SharePoint 2010 and the new Failover Database Server option, it got me thinking how I would do disaster recovery in our environment. SharePoint used to just be for collaboration but now is a critical part of daily operations (ie storing DR process docs), incident response workflows, and the list goes on. With this new functionality and the DR options of visualization platforms, there are new and cheaper ways to provide recovery. I still haven't see a good fit for virtualizing SQL unless it is a small or non-prod farm so we typically still use physical database servers. The typical recovery process requires finding a few servers, building a SQL server and SharePoint farm, then mounting and attaching databases just isn't an option to meet the SLA's users demand these days. Here is an option that I though of which could provide an RPO/RTO from a few minutes to a few hours depending on your infrastructure.
High-Level Design
- Virtualize your web front ends (wfe's) and application server
- Setup SQL mirroring or use a product like AvePoint HA to get your content to the second database server/datacenter
- Use VMware SRM or Hyper-V Multisite functionality to bring up your SharePoint farm in the second datacenter
- With the Failover Database Server configured, the farm will be all set.
Benefits
- Leverages infrastructure you may already have
- Microsoft licensing can transfer reduce software costs
Things to consider
- Network latency and bandwidth between datacenters for SQL Mirroring
- DR testing in your environment may differ and you'll need to determine how would would test failing over AND failing back.
- This design is for actual recoveries and not a weekend failover so you can avoid an outage.
While mocking this up in Visio doesn't prove it will work, this is a viable option and one to consider for larger, critical SharePoint 2010 implementations.
0 comments:
Post a Comment