Tag Archives: Snapshot

How to create a snapview snapshot on an existing LUN

Posted by on May 8, 2017 No comments

I apologize in advance for this (6 years or so too late) post, since it’s for creating a snapview snapshot on a LUN on a VNX. It’s simply meant as a reminder for the command line syntax:

Examples for creating snapview snapshots (it only defines it, no COFW is happening at this point):
naviseccli -h 172.16.20.96 snapview -createsnapshot 17 -snapshotname VMFS-001-SNAP
naviseccli -h 172.16.20.96 snapview -createsnapshot 18 -snapshotname VMFS-003-SNAP
naviseccli -h 172.16.20.166 snapview -createsnapshot 27 -snapshotname VMFS-002-SNAP
naviseccli -h 172.16.20.116 snapview -createsnapshot 5 -snapshotname VMFS-004-SNAP

To start an actual point in time session (and the start of COFWs):
naviseccli -h [ip address] snapview -startsession [session name] -snapshotname VMFS-001-SNAP

To stop a session:
cnaviseccli -h [ip address] snapview -stopsession [session name]

To activate a snapview session (make the data visible):
naviseccli -h [ip address] snapview -activatesnapshot [session name] -snapshotname VMFS-001-SNAP

To deactivate a snapview session (stop presenting the data to the hosts):
naviseccli -h [ip address] snapview -deactivatesnapshot [session name] -snapshotname VMFS-001-SNAP

CX or VNX Mirrorview with Snapview active on the remote side

Posted by on January 21, 2014 No comments

If you have a primary LUN which is replicated using MirrorView/S and you decide to run SnapView snapshots on the remote side, consider that writes to the secondary LUN may have to wait for the COFW activity to complete before an acknowledgement is sent back to the primary array.

So if you’re performing tests on the remote site by using SnapView snapshots, you may want to consider suspending the MirrorView session(s) first in order to guarantee performance on the production site.

A good scenario would be to create clones from the temporary fractured mirrors and as soon as the clones are fully in sync, split the clone from its primary – being the MirrorView secondary – and start the resync in MirrorView.

MirrorView has to wait for SnapViewAfter the write from the primary array (1) a COFW (Copy On First Write) (2) must take place if the write (1) overwrites a block that hasn’t been written to yet in order to maintain the point in time of the snapshot. After the COFW (2) is complete the acknowledgement (ACK) (3) can be sent back to the primary array.

So even if the snapshot isn’t used by a host, there’s already an increased activity on the remote array.

If the snapshot is in use by a host that writes to the snapshot, an unchanged block on the secondary LUN need to be copied to the RLP (Reserved LUN Pool) first before the overwrite can take place. This will also slow down any ACKs that need to be sent back to the primary array.

Conclusion

Be very careful when starting SnapView sessions on a secondary LUN and even more careful when using the secondary LUNs since it can have a severe impact on the response times of the primary LUN.

EMC VNX Replication

Posted by on October 16, 2012 No comments

I want to bring the discussion about “VNX data replication” to your attention. It’s on ECN and the URL is https://community.emc.com/thread/149825. If you want to ask about replication specifically, you can post your questions here or on ECN.

The author, Rupal Rajwar is USPEED certified and works for EMC eServices Customer Support division since 2010.