DESIGN AND DEPLOY
A Consult Circle design guide covering topology, replication selection, sizing, protection group structure, recovery plan design and the mappings that decide whether a failover actually works.
A disaster recovery design fails in one of two ways. It fails loudly, when the recovery does not run, which is rare and obvious. Or it fails quietly, when the recovery runs to completion and delivers an environment nobody can use, which is common and only discovered during an invocation. Almost every quiet failure traces back to a design decision made years earlier and never revisited.
This guide covers designing and deploying VMware Live Site Recovery properly: the topology decisions, choosing between the replication options, sizing the components, structuring protection groups so they reflect the business rather than the storage layout, building recovery plans that a tired person can follow at three in the morning, and getting the mappings right.
It assumes you are either deploying fresh or revisiting a design that has been in place long enough to have drifted. Both are common, and the second is more common than most organisations admit.
What this guide covers
- Establishing recovery objectives that mean something
- Topology options and where components sit
- Choosing between array-based, host-based and Virtual Volumes replication
- Sizing and placement
- Designing protection groups
- Designing recovery plans that work under pressure
- Inventory mappings, and why they drift
- Networking at the recovery site, and the dependencies outside the plan
Start With Objectives That Mean Something
Every DR design should start with recovery objectives, and most start with a number somebody wrote in a policy document years ago. The useful version of this conversation asks three questions of each significant service, and asks them of the business rather than of infrastructure.
- How much data can we afford to lose? This sets the recovery point objective and it drives the replication decision. An answer of zero is almost never true and almost always expensive; push for the real figure.
- How long can we afford to be down? This sets the recovery time objective, and it drives recovery plan structure, ordering and how much can be automated versus paused for human judgement.
- What has to come back first? This is the question that produces useful recovery plans, and it is the one that infrastructure teams cannot answer alone. Tiering matters more than the absolute numbers.
Two things follow. Objectives should differ by service, because protecting everything to the standard of the most critical system is how DR budgets get spent badly. And the objectives you can actually meet should be tested and published, because an objective that has never been demonstrated is an aspiration. The governance side of that sits in our BC/DR planning service.
Topology
VMware Live Site Recovery is an extension to vCenter Server, deployed at both the protected and recovery sites and paired between them. The topology decisions worth making deliberately are these.
| Topology | Description | Suits |
|---|---|---|
| Active-passive | Production at one site, recovery capacity at the other | The most common design, simplest to reason about |
| Active-active | Both sites run production, each protects the other | Better capacity utilisation, more complex mappings and testing |
| Many to one | Several protected sites recovering into one | Distributed estates, branch consolidation |
| One to many | One protected site recovering to several | Regulatory or capacity-driven distribution |
| Stretched storage | Storage spanning sites, supported from 9.0 with partner solutions | Estates already running stretched storage |
Table 1 - Topology options and what they suit.
Active-active deserves a caution. It is attractive because idle recovery capacity is unpopular with finance, and it doubles the mapping and testing burden because each site is both protected and recovery. Organisations that adopt it without increasing their testing discipline typically end up with one direction well tested and the other never exercised.
Choosing the Replication Technology
VMware Live Site Recovery supports array-based replication, host-based replication through vSphere Replication, Virtual Volumes replication, or a combination of these in one environment. This is the design decision that is most expensive to reverse.
Array-based replication
Replication happens in the storage array and VMware Live Site Recovery orchestrates it through a storage replication adapter supplied by the array vendor. It suits large estates on capable, matched arrays, and it can achieve very low recovery point objectives depending on the array.
- Granularity is at the datastore or LUN level, which means protecting a datastore protects everything on it.
- It requires an adapter, and it usually requires compatible arrays at both ends.
- New adapters can be added without requiring a new VMware Live Site Recovery release, so array support is not gated on the product release cycle.
- It shifts replication load off the hosts and onto the array, which matters on dense clusters.
vSphere Replication
Host-based replication, performed by ESXi, requiring no matching arrays and no adapter. It works per virtual machine, which is the property that most often makes it the better choice.
- Per virtual machine granularity means you protect what you intend to protect and nothing else.
- It works across dissimilar storage, which suits estates where the recovery site was not built to match the protected site.
- Recovery point objectives are configurable per virtual machine, generally in minutes rather than seconds.
- It consumes host resources and network bandwidth, so it needs accounting for in cluster sizing.
Virtual Volumes replication
Supported from version 9.0.3, this gives per virtual machine granularity with the replication performed by an array that supports Virtual Volumes replication. For estates already on vVols it combines the granularity of host-based replication with the offload of array-based.
How to choose
| If | Then consider |
|---|---|
| Most of the estate needs protecting, arrays are matched and capable | Array-based replication |
| Only a subset needs protecting | vSphere Replication, to avoid replicating what you did not intend to |
| Recovery site storage differs from production | vSphere Replication |
| You already run Virtual Volumes | Virtual Volumes replication, confirming the 9.0.3 minimum |
| You run stretched storage | Confirm the partner solution position, supported from 9.0 |
| Different services have genuinely different objectives | A combination, which is supported and often correct |
Table 2 - Choosing a replication technology.
The most frequent design mistake is choosing array-based replication on an estate where only a fraction of virtual machines need protecting. Datastore granularity then means paying to replicate workloads nobody intended to protect, in both bandwidth and recovery site capacity. Mixed approaches are supported and are often the right answer.
Sizing and Placement
- Recovery site compute. Enough capacity to run what you have committed to recover, at the performance the business expects. Recovery into a site that runs everything at half speed satisfies the plan and not the objective.
- Recovery site storage. Capacity for replicated data plus the overhead of test failover, which creates temporary storage during tests.
- Bandwidth between sites. Sized for the initial synchronisation as well as ongoing change rate. Initial sync is frequently the constraint that delays a deployment, and it is the one most often forgotten in planning.
- Host resource for host-based replication. vSphere Replication consumes ESXi resource. On clusters already running close to capacity, this needs accounting for rather than absorbing.
- Management component placement. The DR management components must be available when the site is not. Placing them where a site failure takes them out is a design error that only reveals itself during an invocation.
- Protection group count and structure. With the current limit of 1500 virtual machines per protection group, structure can follow the business rather than the constraint.
Designing Protection Groups
A protection group is the unit that fails over together. That sentence should drive the design, and frequently does not.
In long-lived estates, protection groups are commonly shaped by two historical accidents: older scale limits that forced splitting, and storage layout that dictated grouping when array-based replication was chosen. Neither reflects how the business thinks about its services.
- Group by what recovers together as a business service, so a recovery plan corresponds to something a business person can name.
- Keep application tiers that depend on each other in the same group, or in groups always invoked together, so partial recovery is not possible by accident.
- Avoid groups that exist because of storage boundaries where host-based replication would allow a better grouping.
- Review group structure against the current limit of 1500 virtual machines per protection group, since many existing structures were shaped by lower limits.
- Keep the number of groups manageable. Every group is another set of mappings that can drift.
Consolidating protection groups is a change to production DR configuration and needs the same rigour as any other: planned, executed deliberately, and validated with a test failover afterwards. It is worth doing, and it is not a quiet afternoon task. The version comparison guide explains why the current scale limits make this worth revisiting.
Designing Recovery Plans That Work Under Pressure
The test of a recovery plan is not whether it is correct. It is whether somebody who did not write it can execute it at three in the morning during an actual incident, while people are asking for updates.
- Order by dependency, not by importance. Domain controllers, DNS and database tiers come up before the things that need them. Importance determines which plan runs first; dependency determines the order within it.
- Use priority groups deliberately. Everything in the top priority group is competing for the same resources at the same moment. A plan where everything is critical recovers more slowly than one that is honestly tiered.
- Put pauses where judgement is genuinely needed. A pause that exists because somebody was nervous once, and which nobody now understands, becomes a stall during an invocation.
- Audit callout scripts regularly. Scripts accumulate. They point at paths on servers that have been rebuilt and were written by people who have left. They do not fail until the plan runs.
- Write the plan for the person on call. Names in the plan should be roles. Instructions should be executable without tribal knowledge.
- Include application validation steps. Infrastructure can confirm virtual machines are running. The plan should say who confirms the service works and how.
Inventory Mappings, and Why They Drift
Mappings tell VMware Live Site Recovery how the protected site corresponds to the recovery site: which resource pool, which folder, which network, which storage policy. They are where quiet failure lives.
The reason is structural. Mappings encode a relationship between two environments that both change independently, and nothing forces the mapping to be revisited when either side changes. A network is renamed at the recovery site, a new portgroup is added at production, a folder structure is reorganised. Each change is legitimate and none of them prompts anyone to check DR configuration.
- Every network at the protected site has a current, correct mapping at the recovery site
- Test networks are genuinely isolated, so test failover cannot affect production
- Folder and resource pool mappings reflect the current structure at both sites
- Storage policy mappings deliver equivalent protection at the recovery site, verified rather than assumed
- Placeholder virtual machines exist and are current for every protected workload
- Mapping review is a scheduled activity rather than something done when something breaks
- Changes to networking at either site trigger a DR mapping review as part of the change process
The last item is the one that actually solves the problem. Mapping drift is a change management issue, not a DR issue, and the fix is to make DR configuration a consideration in the change process at both sites.
Networking and the Dependencies Outside the Plan
Two questions decide whether a recovered environment is usable, and neither is answered by the DR product.
Do addresses change on recovery?
If the recovery site uses different addressing, recovered workloads need re-addressing, which means guest customisation, DNS updates and anything with hardcoded addresses breaking. If addressing is stretched or preserved, that is a network design decision with its own implications. Either answer is workable. Not having decided is not.
What does the plan assume is already there?
Every recovery plan assumes some infrastructure exists at the recovery site before it runs: identity, DNS, certificate services, monitoring, backup infrastructure, and the management components themselves. If those are protected by the same plan, the ordering matters enormously. If they are assumed to be present, that assumption needs testing.
This is the area where DR tests most often reveal something. A test failover of an application recovery plan succeeds because the supporting infrastructure was still running at the protected site. In a real invocation it would not have been. Testing the assumption, rather than the plan, is what separates a demonstrated capability from a documented one.
Building Testing Into the Design
Test failover recovers into an isolated network without disrupting production or breaking replication. It is the capability that most justifies the product and it is consistently under-used.
- Test every plan on a schedule, not only the plan you are confident about. The untested plan is the one that gets invoked.
- Test with application owner participation, so somebody validates the service rather than the infrastructure.
- Record the result with a date and a name, so the question of when DR was last proven has an answer.
- Test the assumptions as well as the plan, particularly the availability of supporting infrastructure.
- Treat a failed test as a successful outcome. It found something before an incident did.
- Include failback in the test scope periodically, since reprotect and failback are the parts least often exercised.
Consult Circle
Designing or redesigning a DR platform?
We run design and deployment engagements covering topology, replication selection, sizing, protection group and recovery plan structure, and the mappings, and we run the test failovers that prove the objectives.
Explore our Disaster Recovery servicesFrequently Asked Questions
Should we use array-based or host-based replication?
It depends mostly on what proportion of the estate needs protecting and whether your arrays match. Array-based works at datastore granularity, so protecting a datastore protects everything on it, which is efficient when most of the estate is protected and wasteful when only a subset is. vSphere Replication works per virtual machine across dissimilar storage. Combinations are supported and are frequently the right answer.
How many protection groups should we have?
As few as cleanly express how services fail over together. Version 9.0 raised the limit to 1500 virtual machines per protection group, so structures shaped by older constraints can usually be consolidated. Fewer groups means fewer mappings to drift and simpler recovery plans.
Where should the management components sit?
Somewhere that remains available when the protected site is not. This sounds obvious and is a design error we still find, usually in environments that grew rather than being designed.
How do we size the bandwidth between sites?
For both the ongoing change rate and the initial synchronisation. Initial sync is frequently the constraint that delays a deployment, and it is the figure most often omitted from planning. Measure change rate rather than estimating it.
Do recovered virtual machines keep their IP addresses?
That is a network design decision rather than a product one. If the recovery site uses different addressing, workloads are re-addressed through customisation and anything with hardcoded addresses will break. If addressing is preserved or stretched, that carries its own network implications. What matters is having decided and tested it.
How often should we test?
Every plan, on a schedule, with application owner participation and a recorded result. The specific interval matters less than the fact that every plan is covered, because the one that is never tested is the one that will be invoked.
What is the most common design flaw you find?
Stale inventory mappings, closely followed by recovery plans that assume supporting infrastructure will be available without protecting or ordering it. Both produce failovers that complete successfully and deliver an environment that does not work.
Can Consult Circle design and deploy this for us?
Yes. We run design and deployment engagements covering topology, replication selection, sizing, protection group and recovery plan structure, and the mappings, and we run the test failovers that establish whether the recovery objectives you publish are the ones you can meet.
Where Consult Circle Fits
The difficult part of DR design is not the product. It is deciding what genuinely needs protecting, at what objective, and then building a structure that a person under pressure can execute and that survives the estate changing around it for the next five years.
We design and deploy VMware Live Site Recovery through our Disaster Recovery services, review designs that have been running for years and have drifted, and run the tests that turn a documented plan into evidence.