MMRNOLA
Contributor
Contributor

SRM 5 and RDMs

We are in the process of testing Recovery Plans in SRM 5 and have an issue. I was told that SRM 5 handles RDMs with ease. The issue I'm seeing is SRM shows an error with several of our VMs. These VMs have RDMs via iSCSI at the ESX host level. The error is "device not found".

The disks that its having issues with are the reference files located on the RDM placeholder datastore (VMFS). This volume is replicated and seen via the array managers section in SRM.

Any ideas?

SRM1.jpg

0 Kudos
10 Replies
kastlr
Expert
Expert

Hi,

not 100% sure if this is still correct for latest SRM, but with RDMs it was required to use identical LUN ID's on production and recovery array.

Kind regards,

Ralf



Hope this helps a bit.
Greetings from Germany. (CET)
0 Kudos
sparrowangelste
Virtuoso
Virtuoso

the volume may be replaicated via san technolgy but is the iscsi target the same?

I dont think it would be.

for a DR test, you might just be better off removing the old RDM mappings and attaching new ones for the luns on the replciated array.

--------------------- Sparrowangelstechnology : Vmware lover http://sparrowangelstechnology.blogspot.com
0 Kudos
mal_michael
Commander
Commander

Hi,

I am not aware of the identical LUN ID requirement for the replicated LUNs.

Do you see these RDM LUNs in replicated device list in Array Manager?

Michael.

0 Kudos
GreatWhiteTec
VMware Employee
VMware Employee

The LUN IDs won't be the same for the replicated RDMs. I would make sure that you place your RDM pointer files within the same folder as your VM and that all your RDMs (LUNs) are replicated as well as the datastore where the VM is located. I have seen on some SRAs, that the status of the mirrors may be shown incorrectly is the replication is in process.

0 Kudos
MMRNOLA
Contributor
Contributor

I do see where the LUNs are picked up as being replicated in the array manager

0 Kudos
MMRNOLA
Contributor
Contributor

Whats the advantage/disadvantage of doing it this way verses leaving them the placeholder datastore? Will it require downtime in order to move them to the same folder?

Thanks

0 Kudos
GreatWhiteTec
VMware Employee
VMware Employee

I don't see why you would place your RDM pointer files in your placeholder. You should place your RDM pointer files either on the same datastore as your VM or very well place it on a different datastore, but your placeholder is just that... a placeholder for SRM.

I personally like to place them in the same datastore as the VM so I don't have to be looking at different datastores for 1 VM. THis helpos when you have a bunch of VMs scattered among many vCenters, etc. I hope I'm making sense... :smileygrin:

This should help http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=100524... 

0 Kudos
mal_michael
Commander
Commander

RDM pointer files must be placed on the replicated datastore.

Placeholder datastore should never be replicated.

Additionally, putting all RDM pointers on the same datastore will cause SRM to put all of the VMs into the same protection group.

So, you should move RDM pointers away from the placeholder datastore.

Michael.

0 Kudos
MMRNOLA
Contributor
Contributor

This particular "placeholder datastore" is not for SRM. It's for RDM's used for SQL databases. When creating LUNs the pointers are stored on a shared datastore.

The SE who deployed SnapManager for SQL/Sharepoint set this up this way..

The servers that have RDMs are all on the same datastore already. Things wont change past this so having them in the same PG is not an issue.

I guess at the end of the day, I was curious to know if SRM would handle the recovery of these servers without the need for scripting or manual effort on the recovery site. It's not a problem to script this process, but it would have been nice to just "click" and be done with it. 😃

Thanks

0 Kudos
TheITHollow
Enthusiast
Enthusiast

Just a heads up, I know you're working on setting up your RDM replication for SQL, but it might be worth looking at log shipping the SQL drives.  I found that in my DR testing that SQL maintenance caused so many blocks to change that our WAN couldn't keep up.  We ended up doing log shipping on our SQL Servers to a "dummy vm" in the DR Site and then adding a script to the Recovery Plan to disconnect that drive and attach it to the correct SQL Server after the failover occurred. 

http://www.theithollow.com
0 Kudos