Specify initiator group for SnapManager SQL clone destination

[PL]

We are cloning a SQL database from a physical server to a VMware virtual server. 

The clone process creates a RDM on the virtual server, a VMDK with a semi-random name each time it runs.

The problem is that when the RDM is created, it is only assigned the initiators for the VMware host server the VM is assigned to. This makes it impossible to use VMotion to relocate the virtual SQL server if there's a problem with the host. So, high availability is not possible.

Is there a way during the clone process to specify an initiator group for the new cloned LUN? 

Or, is it possible through a Powershell script to, after the clone, modify the cloned LUN so it includes an initiator group or a list of the other initiators in the VMware cluster?

[dmauro]

I doubt there is a registry key which forces Snapdrive to chose a specific igroup when snap mounting or cloning.

I agree that it would be desireble.

I do know there is a registry key to force SnapDrive use the MS sofware initiators for clones created by SnapManager. I think that will resolve your requirement with vmotion too, as long as you are happy with clones going through the guest MS iSCSI initiator...

in case you want to go for it, here is what you need to do:

the following key needs to be manually created and it allows administrators to pre-select the initiator to be used for snap mounts (during verifications) or clones initiated y SnapManager:

HKLM\System\CurrentControlSet\Services\SWSvc\Parameters\SetOfInitiatorsPerFiler

Here is how you set it up:

1. From within the Guest VM (target for your clones) create the iSCSI sessions to the storage system containing the production lun.
2. Create a registry key HKLM\System\CurrentControlSet\\Services\\SWSvc\\Parameters\\SetOfInitiatorsPerFiler
3. Under this key create a string key with storage system name and then insesrt the MSiSCSI initiator name as its value.

it will look like this:

hope that helps,

Domenico.

[PL]

Hi. The NetApp tech that I worked with also suggested this registry key. And we tested it. But it only seems to work when the source system is also a VM. 

When we try to use this key with the physical SQL instance as source, the clone process only grabs the *last* initiator listed in the key string value. If the key doesn't exist, it uses the initiators of the host that was assigned.

It's also possible that this key is iSCSI-specific (we are FC for SQL storage).

(Also, your image is a broken icon -- I would like to see what the key looks like, though; can you paste it in as text?)

[dmauro]

Hi,

here is the picture as attachment. Sorry, not sure why picture was not showing with copy paste.

the idea of this key was to (temporarily) avoid or workaround problems existing with RDM (FC or iSCSI) LUN's by forcing SnapDrive in the guest to use Microsoft Software Initiator, just like in the picture.

for the string value, replace storage system name and iqn of guest.

hope that helps,

Domenico

[PL]

So it looks like that registry key allows you to assign one specific initiator.

Problem here is that the VM is in a cluster with four servers, and thus, eight FC initiators. I wasn't able to get the process to recognize anything in that registry key beyond the last one entered in the string.

So, unless there was something wrong in the way the key was populated, it's not helping. And it's hard to find anyone at NetApp who understands the key in the first place.. 😞

[dmauro]

Like I mentioned, the key was designed to force snapdrive in guest to use ms iscsi, if you have troubles understanding that, perhaps you can call support and we explain it to you.
Feel free to ask for me during CEST normal working hours.
Domenico.

[PL]

I understand the concept well, thank you for your offer. The NetApp tech I was working with on this case suggested the registry key as a possible option (even though it wasn't indicated in our specific situation, we thought maybe it would work; no such luck.)

I'll just have to accept that it's apparently not possible to VMotion a VM that's hosting a cloned DB from a physical SQL server. It's disappointing.

[dmauro]

it's been a while I haven't played around with a physical SQL server, but I can try to set it up and test a clone on a target VM.

If I succeed today, I will let you know by posting a reply here...

Domenico.

[PL]

My SA found this link, which might apply:

http://community.netapp.com/t5/Microsoft-Cloud-and-Virtualization-Discussions/Mirroring-Igroups-Initiators-and-Lun-Mappings/td-p/55514

It's VMware, not MS Cloud, but it looks like there are some PS commands to manage Igroups and initiators?

[dmauro]

I completed my test:

production SQL server: Physical windows 2008 R2 SP1

target of clone SQL server: Virtual Machine on ESX with windows 2008 R2 SP1

Storage system: a fas 3160 with FC and iscsi with Ontap 8.2.3 7mode

SnapDrive 7.1.1 (on both servers)

SMSQL 7.2 (on both servers)

SQL prod db are FC connected to Storage (no RDM).

Clone server only has RDM and MS iSCSI lun's.

once both windows server (in same AD domain) had dns connection to the storage system and credentials were set from both of the windows servers,

I could succesfully clone a production SQL db into the target server. the clone was mounted on clone server with MSiscsi.

This was achieved even without the registry key, since my esx host which hosts the VM whcih is the target of the clone does not have FC connection to that specific storage server.

This shows you that if you force SDW to use Msiscsi, it will use it.

So unless you are doing something different, this should work and there is no disappointing limitation.

please work with your support engineering to insist on the correct implementation of the reg key and restart your snapdrive service.

hope that helps,

Domenico

[PL]

We're you able to use Vmotion to move the VM with the cloned Db to another host? That's the problem I have.

Cloning the server is not the problem. Sorry if I didn't make that clear.

[dmauro]

Yes, I know.
Since guest iscsi is used, vmotion has no problem...

[PL]

So you think that if the VM for the clone destination is iSCSI instead of FC-based, the VMotion will work after the DB is cloned?

[PL]

okay, I was finally able to confirm system behavior.

Test setup:

• Source system: two physical Windows 2008r2 Datacenter servers in a failover cluster, SQL Server 2008r2 Enterprise Ed.
• Created two SQL databases, one on a ISCSI LUN, one on a FC LUN, both "shared" for clustering. Each DB consisted of two files (MDF and LDF):
  iSCSI --  W:\SQLData\clone_test_iscsi.MDF,  W:\SQLDATA\clone_test_iscsi.LDF
  FC --  Y:\SQLData\clone_test_FC.MDF, Y:\SQLData\clone_test_FC.MDF
• Destination: Virtual machine (VSphere 5.1ud3) "VSql", Windows 2008r2, SQL Server 2008r2 EE.
  Created VMware datastore (ISCSI-based) and assigned to 4 VSphere 5.1 hosts in a VMware cluster.
  Added a VMDK on this datastore to the destination VM as drive Z: and created a folder \SMSqlMtPt for use as the mount point.

Test 1:

1. Cloned the Clone_Test_ISCSI  DB to \\VSQL 
2. Attempted to Migrate \\VSQL after the clone, and could successfully migrate to any other host in the cluster.
3. Deleted the clone_test_ISCSI DB from \\VSQL

Test 2:

1. Clone the Clone_Test_FC DB to \\VSQL
2. Attempted to migrate \\VSQL after the clone. Validation failed with the error: "Virtual disk 'Hard disk 2' is a mapped direct-access LUN that is not accessible..."
3. Even if the FC initiators for the other hosts in the destination VM cluster are added to the cloned LUN manually, it is still not possible to use VMotion to move the machine to another host.

Thus, it appears the ability to migrate a VM hosting a cloned DB from a non-VM SQL server is indeed dependent on the host database storage being ISCSI-protocol.  The clone process for ISCSI-based storage does not create RDMs, whereas a DB hosted on FC storage does create RDMs. 

The location of the mount point on the destination VM does not seem to make a difference. I acheived the same results with mount points on both FC- and iSCSI-protocol datastore LUNs on the destination VM.

The good news is that we do at least have confirmation that it is possible to migrate a VM hosting a SnapManager cloned SQL DB from a physical server; however, the source server's storage must be iSCSI based to accomplish this.  Since our DB storage is all FC, we have some work to do, but it's less work than trying to come up with another method of quickly replicating our production DB server.

[dmauro]

I had preformed your test 2 and it worked for me,  so may I kindly ask you not to post wrong conclusions for sake of the future readers.

Like I said, clone from physical instance to virtual instance works, whether FCP or ISCSI protocols are used on source and destination instance.

that error: "Virtual disk 'Hard disk 2' is a mapped direct-access LUN that is not accessible"

is because VMWARE cannot migrate a VM when an iscsi RDM lun exists in the VM with direct access configured between VM and the host where the VM was running, if your hosts have a mispresented device.

please see vmware kb in order to get some advice on that:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1016210

this has nothing to do with the test you described. you won't be able to migrate that VM regardless of whether that SQL clone exists or not, as long as you have iscsi RDM lun on that vmware guest.

If the only iscsi rdm lun is the one created per effect of the clone, then you are not applying my workaround correctly. I specifically asked you to use the guest iscsi initiator from Microsoft and not the one from the esx server (which will create an iscsi RDM lun). In case you are creating the clone with guest iscsi, then the vmware kb above should be applied.

hopefully this will make things clearer for you.

Domenico.

[PL]

I'm trying to use a FC-based SQL instance as a clone source. You keep referring me to the MS ISCSI initiator. 

Your quote: "this has nothing to do with the test you described. you won't be able to migrate that VM regardless of whether that SQL clone exists or not, as long as you have iscsi RDM lun on that vmware guest." -- please understand, the RDM LUN is being created by the SMSQL clone process, when the source SQL DB is hosted on FC storage. There is no RDM of any kind on the destination VM until the clone process completes. The VM can be migrated via vMotion with impunity until the cloned DB is created from a FC host.

If the host storage for the SQL DB is iSCSI, a RDM is not created on the clone destination VM; SnapDrive connects the DB snapshot via the MS iSCSI initiator.

In the SMSQL Clone Wizard, there is no way that I know of to tell SnapDrive to use any particular set of initiators to connect the cloned instance on the destination device.  Nor does it appear to be possible to specify this as parameters within a CL request via PS.  

The VMware KB you referenced is telling me something that I already know. The problem is with the creation of the SnapDrive cloned LUNs on the destination VM. When the source LUNs are hosted on iSCSI storage, there are no RDMs created, hence, there is no issue. When the source LUNs are FC, SMSQL creates the RDM, which can't then invoke VMotion because of that known issue you referred me to.

I have opened a NetApp case regarding this issue, which has been closed, so please feel free to refer to this. Case# 2005587856

I have come to the conclusion that this can be resolved by moving my SQL host storage to iSCSI from FC. I'd prefer not to do this, but I can't afford to lose the SMSQL clone capabilities, and I need to move the destination SQL server to a VM while maintaining something resembling HA.

You say you were able to successfully implement my "test 2" -- please confirm: 

• your source system's SQL storage was on FC in a physical cluster,
• you used SMSQL to clone the SQL DB to a VM, and
• you were then able to use VMotion to relocate said VM to another host?

If this is indeed the case, please reply with more specifics regarding your setup so I can learn what I'm doing wrong here. Because the other support tech at NA that I worked with on this case was not able to do this.

I'm not trying to spread misinformation regarding SMSQL's capabilities. I'm only trying to get this process to work in my situation.