Snapmanger for SQl mount clone on remote server through firewall.

[JaseW]

Hi,

I wonder if anyone could point me in the right direction.

NetApp Release 8.1.4P1 7-Mode

Our environment consists of multiple SQL servers with datastores stored on VMDKs (mixture of NFS and FC). VSC is installed and along with SnapDrive and SnapManager for SQL we reqularly clone database snapshots from one SQL server to another, with good results.

We have a second environment which uses the same NetApp system but prestents to a separate vCenter with its own VSC install. The servers are in the same active directory. This environment is behind a firewall. We seem to be unable to mount a clone from a server within here to a server in the first environment. We have opened all of the ports we think are required between the source and destination servers. The clone fails with ....

Mounting snapshot:xxxxxxxxxxxxxxxxx

Snapshot mount failed.

Remote clone operation failed: Error code: 0x80004005, Error Code: 0x80004005 Object reference not set to an instance of an object.

We suspect this is a firewall issue?

Questions that I am trying to find answers to are what in the flow of traffic in a clone mount operation to a remote server. Is all the communication SQL server to SQL server or does the server communicate with the VSC of the destination server? or even the vCenter server?

Kind Regards

Jase

[georgevj]

I remember a similiar case being closed by "Adding the destination snapdrive's user account to source's local admin group". Sounds like a clue? Any observations around this point?

[JaseW]

Hi,

Thanks for responding and thinking about this. I have checked and we are using the same account for both Snapdrives which is in both local admin groups. I was wondering if it was at least possible i.e. one A VM in one VCentre to a VM in another VCentre. I have taken the support ticket route and logged a case with Netapp. They state that it is possible but I'm still waiting on a response to my last email requesting that, yes, help from a product specialist would be most welcome. I'll update this post if I find a solution.

Regards

J

[dmauro]

Cloning a database from a local or archived backup is possible, if ports are open, however the pre-requisites are quite complex and we are planning to fully document those in the Admin guide of the next release of SMSQL. (for ports usage, please check for example https://kb.netapp.com/support/index?page=content&id=3011242 , https://library.netapp.com/ecmdocs/ECMP1400523/html/GUID-115A0CD6-4C90-4D32-8395-D4D1EEE573D9.html , https://kb.netapp.com/support/index?page=content&id=3012060&locale=en_US and https://kb.netapp.com/support/index?page=content&id=3012698&locale=en_US&access=s )

here is a draft of what the Prerequisites for VMDK verification or cloning on SnapMirror destination volumes are, but please note that those steps are not fully tested and you should treat them as guideline and test them yourself before relying on them:

You can verify backup sets on SnapMirror destination volumes and you can clone databases from

SnapMirror destination volumes. If the databases that you want to verify or clone are hosted on

VMDKs, you must meet several prerequisites before you can perform either of those operations.

You can verify and clone from destination volumes when the database hosted on the VMDKs is

replicated to a site by SnapMirror and the configuration meets the following requirements:

• The virtual machine is installed on the ESX server on the secondary site.
• SQL Server, SnapDrive, and SnapManager are installed on the virtual machine.
• The ESX server is managed by another vCenter Server and the VSC server on the secondary site.
• SnapDrive is installed on the secondary virtual machine that is pointing to the VSC server on the

secondary site.

• On the primary site, you have selected the SQL Server on the secondary site as the remote

verification server.

• On both the primary and secondary VSC servers, you have created a Windows share on the VSC

repository folder where the backup metadata file resides.

• The SnapManager service account has read permission on the share at the primary site and write

and modify permissions at the share on the secondary site.

• The primary VSC server has discovered the destination storage system.
• For NFS datastores residing on clustered Data ONTAP, a datastore must exist on the SnapMirror

destination volume and the name of the destination datastore must be specified in the change list

file.

• On the primary virtual machine where the backup is initiated, the following registry settings and

values must be defined in HKEY_LOCAL_MACHINE\SOFTWARE\Network Appliance

\SnapManager for SQL Server\Server:

SMVITransformEnable

dword:00000001

SMVITransformScript

SMVI_Metadata_update.exe

SMVIDestinationServer

destination SMVI server name

SMVISourceBackupXmlUNC

\\source SMVI server name\SMVI repository share name\backups.xml

SMVIDestinationBackupXmlUNC

\\destination SMVI server name\SMVI repository share name

\backups.xml

SMVIChangeListFile

change list file name

Requirements for the change list file

The change list file is a text file that contains information about source and destination volumes. The

contents of the file must be in the following format with fields separated by a space and each

datastore beginning on a new line:

DatastoreType SourceDatastoreName DestinationDatastoreName

SourceVirtualMachineName DestinationVirtualMachineName

SourceVirtualMachineUUID DestinationVirtualMachineUUID

SourceVirtualMachineDirectoryName DestinationVirtualMachineDirectoryName

SourceStorageName DestinationStorageName SourceVolumeName

DestinationVolumeName [SourceDatastoreUUID DestinationDatastoreUUID]

In this format, Datastore Type is either NFS or VMFS and Datastore UUID is not required for

an NFS volume.

Note: For NFS datastores residing on clustered Data ONTAP, SourceStorageName and

DestinationStorageName must be the IP addresses of the source and destination NFS data

LIFs.

The following example shows the contents of a change list file:

NFS ds-nfs1 ds-nfs1-dest snapmgr-05-vm2 snapmgr-54-vm1 4211945a-124a-b7c9-

ae63-cacc07f3f4f8 420f010b-7e5a-e66e-7ed1-7bef6a357cca snapmgr-05-vm1

snapmgr-54-vm1 172.17.233.24 172.17.232.74 snapmgr05_vmw1

snapmgr05_vmw1_mir

Finding the UUID for VMFS datastore

To find the UUID for VMFS datastore, follow the steps below:

1. Break the SnapMirror relationship from the storage system.
2. Make the SnapMirror destination volumes online on which the datastore reside.
3. On the secondary SMVI server, mount the LUN in the destination volume as the destination

datastore on the secondary ESX server.

Note: When you add the storage from the destination, select the option “Resignature the

LUN”.

1. After the destination datastore is added to the secondary ESX server, note the datastore name and

UUID values.

1. Replace the destination datastore name and the destination datastore UUID with the new values

that you noted in the changelist file.