2010-06-22 09:00 AM
The volumes in question are the NFS volumes being presented to VMware vSphere to store the virtual machines C:\ drive OS directory. We do not have SMVI so I do not see any benefit to using native snapshots for the volume, because there would be no way to restore a virtual machine should something happen. Am I wrong for thinking that way and missing something? To revert back to a snapshot would mean to revert back the entire volume. The volume however, will be replicated to our DR site with SnapMirror so do snapshots need to be enabled on a volume to accomplish this? Thanks.
2010-06-22 09:03 AM
Asynchornous SnapMirror uses snapshots so you will be moving snapshots from the source to the destination side.
Sync or semi-sync don't necessarily move snapshots.
2010-06-22 09:17 AM
Snapshots do not need to be enabled (aka scheduled) in order for SnapMirror to replicate the data to a DR filer.
Now for Snapshots on the primary… You are not required to have SMVI in order backup and restore, though it makes it much easier and also puts the guest OS in a consistent state. If you enable snapshots on the primary NFS volume the VMDKs will be in a crash consistent state, which can be used 99% of the time. If you have a SnapRestore license then you don’t need to restore an entire volume, you can restore a single VMDK (or whatever) using snap restore –t file /vol/nfsvol/vm1/vm1.vmdk and it will prompt you with a list of snapshots to use.
2010-06-22 09:22 AM
Asynchronous SnapMirror would be replication say on a schedule at a set time during the day. Sync and semi-sync is just a constant stream of the volume always replicating the changes as they happen. Correct? You also say "don't necessarily move snapshots." Can you elaborate? Thanks for the quick reply too.
2010-06-22 09:30 AM
Sorry about the necessarily, a bad verbal habit of mine.
Sync and semi-sync stream consistency points which are kind of like snapshots but not. But for all practical purposes, they don't. You won't see any snapshots on the volumes with sync or semi-sync.
The trick with those technologies is that if the latency of the link between the systems drops too far (I forget the current limit at the time, it's not in front of me), it will rever to async until it can ramp it back up.
You don't need to enable snapshots specifically to make async work, it just takes them anyway.
2010-06-22 09:48 AM
Thank you for the immediate responses, this is awesome. Just to summarize...
So what I've taken away from this is I should pretty much always enable snapshots on volumes even if it's just using the native snapshot technology, because if licensed for snap restore you can restore individual files from the snapshots.
Now, snapshots are not needed for SnapMirror as I guess SnapMirror does it's own thing, but if I manually enable snapshots on the volume as stated above this is a non issue.
Sync SnapMirror, which I feel is the best way to go for DR if the link can handle it, will turn to asynch if the lag time between the 2 sites begins to increase and bandwidth slow down.
2010-06-23 12:39 AM
Well, i think you should go for async Snapmirror if the volume size is not large with enabling the scheduled snapshots at the primay. In this way, you are safe if you need to restore somethng at the primary site and snapshots will be replicated to the secondary site too via snapmirror, so you are pretty much safe too in case of disaster.
Hope this helps.