MSA2012i - Volume Copy Question

[mull]

Hi,
we have a MSA2012i Dual I/O with 2 enclosures. On enclosure one there are our datas in luns which are connected to a W2K3-Server.
Now we want to copy the volumes to enlosure two with the Volume Copy License.
Is this possible?

Mull

[Rob_69_1]

Hi Mull, it is possible to do what you ask.

The only limitations are:

- The Destination Virtual Disk where the copy of your LUN will be created, must belong to the same Controller as the Volume (LUN) that you are copying.

- When you perform a Volume Copy (physical clone) of your LUN, you must first stop all I/O to that LUN (e.g. shutdown the Server using it) to avoid data corruption. This was not written in the docs, and when I discovered it myself I was very upset to know it, so maybe you'll be happy to know about it before you buy.

- If you have a Snapshot license, you can take snapshots without stopping I/O to the LUN, but what you get IS NOT a physical copy. It's just something that you can use to rollback the original LUN to the point-in-time where you took the snapshot, but if you loose the original LUN, the Snapshot is useless

- I think that you can combine "Snapshot license" and "Volume Copy license" so that you create a physical clone from a snapshot, but I'm not sure of it as I just have Volume Copy for now.

HTH

[mull]

Hi,
many thanks for your fast answer. That is what i want to know. In the offical description of a MSA2000i G2 its different. HP describes that is only possible to make volume copies on the same array.

But im confused with your statement to turn off the server during volume copy about heavy io.
I cant turn off the server!!! :-)

Mull

[Rob_69_1]

I'm quite sure (not 1000% though) that when they say "on the same array" they refer to ALL the enclosures connected together by a SAS cable. This should be true for MSA2000i G2 too... Pls anybody correct me if I'm wrong with this statement.

The word "array" should refer to the whole "thing".

Regarding the fact that you have to stop I/O prior cloning: it's not written anywhere.

But, when you try to make a clone, an alert window pops up, warning you that if you don't stop I/O to the LUN, the cloning will lead to data corruption (it does not specify if on the original LUN, on the Destination LUN, or both).

It says exactly this, nothing more and nothing less...

Right now I'm waiting for a Snapshot 8 license to be delivered. I want to try the combination of the 2. When I'll have tried (license delivery should be next week), I'll update this thread.

[mull]

Hi Rob,
the HP support tells me that all is possible that i want. But volume copies only possible when the volumes/vdisk are on the same controller.
On the next weekend i shut down all vm´s and reconfigure all vdisk to controller A. Also the backup vdisk!

Please give me a feedback when you have tried out the combination with volume copy and snapshot.

Many thanks.
Mull

[Rob_69_1]

Hi, glad to hear you received confirmation that the operation is possible.

My license has not arrived yet.

I will be back with the snap+clone test results as soon as I'll be able to put my hands on the licence. I did not forget about it though.

Bye for now!

[Rob_69_1]

Hi again Mull. I was finally able to get the snapshot license and do some testing.

The Snapshot8 license allows you to have a maximum of 8 snapshots on the storage at the same time.

First of all you must define a snap pool on the same controller as the volume(s) you want to use for this and you must snapshot-enable them (making them Master Volumes).

When you take a snapshot, it's immediately created, and YOU DON'T NEED TO STOP I/O to the Volume to succesfully make it.

Then there is another option regarding ALREADY EXISTING snapshots: you can "reset" them, meaning that you can update them with all the changed data since the snapshot was taken. But it's very strange: apparently, resetting a snapshot is something that requires to stop I/O to the "real" Volume it belongs to, to avoid data corruption.

This is a bit weird, because if you just delete the old snapshot and take a new one, you can get to the same result without having to stop the I/O, so I'm not really sure why it works this way.

Now, on to the "volume copy": it is possible, starting from an existing Snapshot, to perform a physical copy of the Data at the time the snapshot was taken, using the "Volume Copy" license.

This is possible WITHOUT stopping I/O to the ORIGINAL volume the snapshot belongs to. This way you can create a physical clone of the volume. You can then present this clone to a host and do wathever you want with it.

There is one more option available when you perform a "Volume Copy" (physical clone): you can "include changed data". This is mostly like the "reset snapshot" I was mentioning before. At the same way, looks like to use this option you need to stop I/O to the ORIGINAL volume prior executing the procedure.

Anyway: everything seems to be satisfactory enough. I can now take a snapshot and, immediately after, launch a Volume Copy from that snapshot. Without stopping any I/O.

To automate the procedure, there is a scheduler inside the SMU. But I'm experimenting scripting the commands using "expect" (a tool that allows to remotely execute CLI commands on the Array).

HTH

[mu_4]

Hi Rob,

now we are ready to test something on the MSA. We have created the needed volumes and the snap pools for volume copies.
After long discussions with the HP-Support we have two problems:
The copied volumes are not mapped to any host.
The iSCSI-Initiator cant mount automatically volumes from the MSA.
In last case i write a batch with iscscli and that works fine.
In first case i dont know what to do.

Now i have read your answers and you say that the application "expect" can do command automatically with the cli of the MSA. Is this right? I hope i can map copied volumes to a host with expect.

So, when this dont work the only way to backup our datas is the backupexec-agent on the file server with the mountet volumes.
Not good, because i want this "LAN-free!"

Please, give me a short answers with your thoughts.

Many thanks.

Mull