New to VMware SRM

[UoGsys]

Hi All - new to SRM so be gentle!

Looking to setup a new secondary server room which will also act as our DR platform with an SRM instance to our primary cluster running vSphere 4.1.

If I setup a new cluster which will house a 4.1 enterprise plus instance as well as SRM, how reliant is SRM on similar hardware between clusters? I'm guessing not that much as its almost like long range HA? Our primary cluster runs X5550 chips based around HP EVA 6400 storage. With the secondary cluster I'd like to purchase more recent kit which may be based around a different model of EVA.

- Is using different Intel chipsets an issue to SRM?

- The secondary site will utilise different VLAN's, assuming we would just have to write some rules to change server IP's in a DR scenario?

- We use the vDS in our primary cluster, is this a problem in an SRM failover scenario?

- If we don't go for enterprise plus in our SRM cluster, can SRM failover from a vDS to a standard vSwitch (rules again?)?

In terms of licensing SRM, has the model now changed to per VM instead of per host?

Thanks in advance!

[mbaecke]

- Is using different Intel chipsets an issue to SRM?

No you can have a recovery site with different hardware. Intel chipset no problem. The VM will be booted during a failover on the recovery site.

- The secondary site will utilise different VLAN's, assuming we would just have to write some rules to change server IP's in a DR scenario?

In Inventory Mapping you'll have to define which network will be paired between the protected and recovery site. So no problem. Renumbering sever is supported within SRM, although I do advise to use a strechted VLAN to reduce complexity.

- We use the vDS in our primary cluster, is this a problem in an SRM failover scenario?

No. vDS is configured per vCenter. You can create another vDS in your recovery vCenter and map the network with Inventory Mapping in SRM.

- If we don't go for enterprise plus in our SRM cluster, can SRM failover from a vDS to a standard vSwitch (rules again?)?

Don't know for sure, but I think it should be possible.

In terms of licensing SRM, has the model now changed to per VM instead of per host?

You now pay for SRM in terms op protected VMs in bundles of 25 protected VMs per instance.

[mal_michael]

Hi,

dotNL

- If we don't go for enterprise plus in our SRM cluster, can SRM failover from a vDS to a standard vSwitch (rules again?)?

- Don't know for sure, but I think it should be possible.

Works for sure.

UoGsys

If you go for a different models of storage arrays, make sure you can configure replication between them.

Michael.

[UoGsys]

Thanks again both, one last question.

What happens if my primary site runs ESX 4.1 and the secondary ESXi 4.1 - does this affect SRM?

Cheers!

[mal_michael]

No, it is OK.

I believe you will have more questions after you start working with SRM .

Michael.

[UoGsys]

You're correct already!

How does SRM work in terms of licensing and configuration if we wanted to host a set of VM's at our secondary site, then use SRM to fail then over to our primary site in the event of a disaster?

Does this complicate things?

Thanks again!

[mbaecke]

You only have to pay for SRM protected VMs. So in normal situation (protected -> recovery) you only pay for the VMs on the protected site.

If failover occurs and you setup SRM on the recovery site, your recovery site will become a protected site. So you'll have to have licensenses for the VMs. You can you the same licenseses as you used for your "old" protected site which has been failover-ed.

For bi-directional SRM protection you have to pay for the protected VMs on both sites.

In general : Count all VMs that you want to protect using SRM that are active at the same time.

[mal_michael]

The licensing part of your question has been answered already

Regarding the configuration, you will need to have enough capacity at each site to run "local" + recovered VMs.

You will need to configure SRM (Inventory mappings, protection groups, recovery plans, etc) on both sides.

Very annoying issue with this configuration is that placeholder VMs appear in vCenter's inventory and look like regular VMs. May be confusing for operators not familiar with SRM. Consider to put the placeholders in separate resource pool / folder.

Michael.