Combine physical and virtual infrastructure with SRM

Although less common than it used to be, some of our customers still have their physical and virtual environments tightly bound together. For the sake of argument (and my example), let’s say the database runs on a Solaris or AIX box, but the applications accessing that database are on VMware. Such configurations typically run a two-phase commit, where a successful transaction requires both the application and database portions to succeed. The two-phase commit ensures consistency across devices since if one portion (infrastructure) fails, the entire transaction is rolled back. Where this becomes a challenge is when architecting for disaster recovery. Fortunately, with the use of consistency and composite groups in SRDF, we can ensure a legitimate copy on the remote site. But if I want automation in my DR solution can I achieve that with disparate infrastructures?

Physical infrastructure with the SRDF SRA

When using replication technology like SRDF for DR in this combined environment, you might assume the only way to achieve automation is through scripting because VMware solutions like SRM can’t work with physical boxes; but fortunately you’d be wrong. The SRDF SRA has had the ability to handle this use case for as long as I can remember. The reason we can is because SRM knows nothing about the physical devices or what we are doing on the back-end. As long as the SRA acts upon the devices that VMware does know about, VMware is happy. Let’s walk through a simple example of how this works in practice which I think will best illuminate the solution.

PowerMax setup

This test involves four SRDF device pairs, two for VMware, two for AIX (or Solaris whatever you prefer). Since each set of two are presented to different hosts, ESXi and AIX, they are in different storage groups. The SRDF mode is asynchronous – SRDF/A.

Each set of pairs are in their own SRDF group because there may be circumstances where we want to keep the virtual separate from the physical. Recall that when using SRDF/A, you cannot manipulate only some of the devices in a group (unlike SRDF/S). Therefore if we ever want to failover virtual but not physical or vice versa, we need them in separate groups. Therefore the ESXi devices are in group 5, the AIX devices in group 6.

I presented (masking view) my virtual devices to my vCenter configured with SRM, created two datastores and two VMs.

Similarly I presented (masking view) my AIX devices to a physical server.

VMware SRM and the SRDF SRA

So we’ve built our production environment, let’s take the next steps for SRM and the SRDF SRA.

Having written many blog posts and docs on the SRA I’m just going to carry on with what we need to do as part of the configuration without great elaboration. So:

• I’ve paired my 8.4 SRM servers with my vCenters
• Installed the latest hot fix Docker SRDF SRA which is 9.2.0.1
• Configured two Solution Enabler environments

Before discovering the virtual SRDF pairs, I need to create consistency groups (composite) on each Solutions Enabler environment – R1 and R2. And it is at this point where we incorporate our physical devices because the SRA is coded to act upon all devices in a consistency group. Now though we have two different SRDF groups, we want to put all devices from groups 5 and 6 in the same composite group so the SRA sees them all. So on the R1:

symcg create composite_async -type R1 -rdf_consistency
symcg -cg composite_async add devs 75 -sid 357
symcg -cg composite_async add devs 76 -sid 357
symcg -cg composite_async add devs 9D -sid 357
symcg -cg composite_async add devs 97 -sid 357

And R2:

symcg create composite_async -type R2 -rdf_consistency
symcg -cg composite_async add devs 30 -sid 357
symcg -cg composite_async add devs 31 -sid 357
symcg -cg composite_async add devs 2B -sid 357
symcg -cg composite_async add devs 2A -sid 357

Finally, we enable multi-session consistency on the group which is required:

symcg -cg composite_async enable -nop

Run the discover devices in SRM. Remember SRM only knows about the virtual devices so we just see the two pairs below.

Everything else proceeds as normal. Create a protection group and recovery plan for these pairs.

Test

Rather than run the actual failover, I’m going to run a test which will create snapshot copies of the R2s. I am using the SRA’s ability to create the target devices for me (AutoTargetDevice=Yes). If you need to control which snapshot target devices the SRA uses, that is possible also. I’ll use a demo for this since I can show you more. While I run the test, I’m going to tail the SRA log file so you can watch the creation of the target devices and see how they are added to both physical and virtual storage groups.

And there it is, controlling both your physical and virtual DR solution from VMware SRM.

I should mention that if you do not want to add the target devices to the R2 group, you can specify a different storage group. It’s a more advanced configuration which I cover in the documentation.

NB

You can find the information I’ve covered here in the SRDF SRA TechBook. One additional capability I did not include here is when you need to use a previous snapshot of physical and virtual devices in testing. This is achieved using the parameter IgnoreActivatedSnapshots. A quick search in the book will get you to the section, or I also have a blog post on it though just for all-virtual (theory is the same though).

Advertisement