This article is part of an Essential Guide, our editor-selected collection of our best articles, videos and other content on this topic. Explore more in this guide:
1. - Designing a high availability and disaster avoidance plan: Read more in this section
- The case for OS-level high availability
- Balancing your approach to high availability
- Does resiliency dictate hypervisor performance?
- How do you protect critical VMs from hardware failure?
- Which is the best high-availability approach: SRM or vMSC?
Explore other sections in this guide:
- 2. - Virtual recovery and backup planning strategies
- 3. - Using snapshots as part of your virtual recovery and backup plan
How do I choose between vSphere Metro Storage Cluster and VMware Site Recovery Manager?
First, it's important to understand that vSphere Metro Storage Cluster (vMSC) and Site Recovery Manager (SRM) aren't designed to perform the same basic function. Both will help your organization limit downtime, but they work in fundamentally different ways.
VSphere Metro Storage Cluster is a configuration option that allows the use of stretched clusters, where servers within a cluster are spread across geographical locations (usually only a short distance). This configuration allows organizations to perform load balancing and nondisruptive migrations between active data centers.
VMware Site Recovery Manager, on the other hand, takes a traditional disaster recovery approach with primary and backup sites. When a data center outage occurs, SRM enables automated failover to the recovery site with minimal disruption.
The basic difference between the two is disaster avoidance versus disaster recovery. VSphere Metro Storage Cluster will allow you to vMotion workloads between two locations to proactively prevent downtime, while SRM focuses on automating the recovery process of workloads that unexpectedly fail.
Choosing which approach is right for you will depend on your organization's needs. The high availability that vSphere Metro Storage Cluster offers will only help you prevent disruptions you can see coming. However, it allows for near-zero recovery point and recovery time objectives for organizations that cannot tolerate downtime. SRM typically fails over an entire site rather than individual components or VMs and requires slightly longer recovery times. But, it is typically the less-expensive option and allows organizations to automate and test their disaster recovery plans.