DCI as an enabling framework for both Workload Mobility & Disaster Recovery using OTV and LISP

February 6, 2012 - 0 Comments

A couple of colleagues of mine wrote a  document on live Workload Mobility and Disaster Recovery for Tier-1 applications.   I think you should check it out and here’s a couple of key points that I want to highlight:

  1. A single physical Cisco, EMC, VMware infrastructure
  2. Both vMotion and SRM validated on same infrastructure
  3. Tier-1 Enterprise Applications tested

Key Point 1:

The white paper showcases a Cisco, EMC, VMware cloud-ready infrastructure with the latest Data Center Interconnect – DCI – technologies like OTV and LISP for data centers physically located in different locations. Remember, OTV simply and safely networks the data centers together while ensuring a failure in Data Center 1 does not impact Data Center 2, known as fault domain isolation.  Additionally, LISP ensures that remote users have the optimized path to the physical location of the workload (virtualized application), in whatever data center it resides.

Key Point 2:

The interesting thing with this white paper is that both live Workload Mobility and Disaster Recovery use cases are enabled on the same physical infrastructure.  So, when talking about our cloud-ready infrastructure with Cisco, EMC and VMware enabling Workload Mobility & Disaster Recovery, that means we are using:

  1. VMware’s vMotion for live Workload Mobility and EMC’s VPLEX Metro for data content availability
  2. VMware’s SRM (Site Recovery Manager) to enable Disaster Recovery automation with EMC’s RecoverPoint for storage replication

Technology and Solution Breakdown:

The live Workload Mobility use case and the Disaster Recovery use case both require different technologies as illustrated in the table. Here’s why:

1) VMware’s VMotion and VMware’s SRM have different VMware vCenter requirements.

  1. vMotion is limited to within a single instance of a VMware vCenter vDC (virtual data center that you define in the vCenter GUI).
  2. SRM requires a vCenter set in Data Center 1 and a separate vCenter set in the Disaster Recovery site in Data Center 2.
  3. vMotion is limited to 1 vCenter vDC and since SRM requires 2 separate vCenter vDC sets , you can’t enable both  features for the same set of VM’s.

2) VMware’s SRM Supports EMC RecoverPoint

  1. SRM uses something called a SRA – Storage Replication Adapter.  An SRA is analogous to a software driver and it interfaces between the VMware SRM application itself and the storage targets.  There currently is no SRA for EMC’s VPLEX so VPLEX and SRM are not supported together.
  2. Since we need to replicate data to the backup DR site  and since VPLEX is not an option when using SRM, we use EMC RecoverPoint, which VMware *does* have an SRA, to replicate the stored content between the data centers.

To get both vMotion and SRM to work on the same physical infrastructure, they defined the set of servers and applications as either part of the live Workload Mobility use case or the Disaster Recovery use case in advance when orchestrating the service.  The white paper shows that the live Workload Mobility use case is enabled for VMs in VMware ESX cluster “A” and the Disaster Recovery use case is enabled for VMs in VMware ESX clusters “B” and “C” with SRM providing the application and automation for service restoration between the two clusters (B & C).

Key Point 3:

The final key point and unique aspect of this white paper is the focus on Tier 1 virtualized applications;

  1. Microsoft Sharepoint
  2. Oracle 11g

Microsoft Sharepoint is a 3-tier deployment with a front-end web server, Sharepoint application server, and an SQL DB.  The Oracle 11g DB is a stand-alone DB providing OLTP sessions. In the white paper, you’ll see some test results experienced when running through this architecture.

In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.