2015-07-28 06:31 AM - edited 2015-07-28 06:36 AM
Hope someone can assist me and point me in the right direction.
We have had our NetApp systems in for about 14 months now (FAS8020 in production and FAS2240-4 at DR site) both seperate sites using a 100mb WAN link.
To cut a long story short we have created an issue where our WAN link is saturated causing by our SnapMirror and Snapvault relationships. We recently had a health check done by our reseller who stated the following:
"Company name are using both snapmirrro and snapvaults to the same aggregate on the DR controllers, this will impact the performance of the controllers as it needs to handle both mirrors and vaults separely causing exceess read/writes and also increasing the traffic being transferred over the 100mb WAN link. Company name could opt to 'cascade' the mirrors and vaults to reduce the operations on the production controllers and wan link by snap mirroring from production to DR then from the snap mirror destination either snap vault to another aggregate or controller."
Whilst we now have our SAN replication using snapmirror every 12 hours and longer retentions using snapvault, the issue is because we have 2 seperate entities running from source and destination this is causing huge bandwidth issues and it was recomended that the cascading approach would work better and it also means that our destination filer will deal with snapvaults and the production source filer can just deal with snapmirror and serve the data out to the environment. So it was proposed to stop all snapvaults running from source and just run these from the destination using the snapmirror snapshots to create longer retentions.
Due to the support the company have taken out with our NetApp resellers we only have a break fix contract so queries like this they are unable to help with.
So I am about to embark on a piece to sort this out based on the recommendation but am struggling how best to do this without requiring a new baseline and without losing the existing retentions that we have currently built up on the destination Snap Vault location. I attach snapmirror.conf files that are on our HA filer over at DR site.
Before performing this on our live volumes I have created a test volume which I have snap vaulted over the last 2 weeks and so I have built up enough retentions. There is also a snapmirror relationship for this volume however this goes to a separate volume on the destination. So this mirrors how our live volumes are setup and backed up to the destination NetApp
In my head how I picture the new setup is we only setup snap mirrors from our source flex volumes on our (Production FAS8200) which mirror to destination (DR FAS2240) using the 100mb WAN link and then somehow the snapmirror destinations on the FAS2240 then write to a separate volume on that same filer to a new aggregate which will then have a 1 month retention based on 7 Daily Snapvaults and 4 weekly Snapvaults which then recycle the older snapshots. Even better would be saving create a separate volume for the snapvault snapshots were If it could use the existing snapmirror destination volume and this holds both the 2 days snapmirror retention as we have setup in VSC as well as the snapvault snapshots as per 1 month period. i am not sure if this is possible though....
I am thinking the following steps may achieve what is required here but I am not sure:
Would this above steps work without snapvault creating a new baseline? If not do you know how this could be done?
Appreciate any advice anyone can provide me on this. If there other files I can supply which can help to show the exisitng setup, please let me know.
Solved! SEE THE SOLUTION
2015-07-28 06:42 AM
Being that you tagged 7-mode, I'll assume this is 7-mode. The only problem with cascading snapvault with snapmirror in 7-mode is it will use your VSM base snapshot, which means why you are vaulting there will be no snapmirror as the relationship is busy.
Are you managing the vaults with local scheduler or protection manager?
Also, if this is a new filer, it seems management didn't make the right decision on support contracts....
2015-07-28 06:56 AM
Yes both filers are running 8.2.3p3 7-mode.
Sorry I dont understand fully what you mean . The VSM base I assume is the baseline? If it means snapmirrors dont run temporarily that is fine.
I am using a mixture of CLI and Oncommand Manager to administer the SM/SV relationships. CLI I am still a bit rusty but am getting there...
I understand DFM can also perform a lot of the management for SM and SV but so far I haven't really been able to spend time with that application as our training mainly focused on OCUM. The only thing we use DFM currently is for reporting.
I agree with the support contracts but being a public sector organisation, budgets were very tight in this project to start of with, we were grateful to get this much. It has been a shame tbh, the support would have been worth while especially for the first 12 months.
2015-07-30 06:21 AM
That is something I am aware of.
The hope is because snapvaults won't be sending from the source to the destination over the WAN link, this will provide enough bandwidth for the snapmiror jobs to run, which in return should take less time and then we will schedule the snapvault jobs to run at a much later time on the destination filers and hopefully finish by the time the next snapmirror job will run.
2015-09-07 06:16 AM
Is anyone able to help with this? I am unsure how best to proceed with this. Any direction would be greatly appreciated.
One more question I had was, if I have an existing snapmirror relationship from source to destination which has a 2 day retention but want to also have a month retention using snapvault, could I target the snapvault source as the snapmirror destination?
Am I right in thinking if I have a volume I want to backup using SAN replication I have my snapmirror relationship but if I want retention I will need to target the snapvaults to a seperate snapvault destination volume? is that correct?
2015-09-07 06:35 AM
Thought it might help if I provide some further info with screenshots:
CENSLFASPROD02: Main Production site (source) filer
CENWBFASDR02: Disaster Recovery site (destination) filer
Running Data ONTAP 8.2.3P3 7-mode on ALL filers.
The two filers are connected over a WAN connection.
This is how I have got my snapmirror and snapvault relationship setup now but I am not sure if this will work as I am intending it to. At the moment I am doing testing on a test volume I created. The snapmirror schedule is created within the Virtual storage console (VSC6) plugin for VMware
A snapmirror relationship exists from source to destination filer and this is set to run on demands as VSC takes care of the schedule.
the Schedule in the snapmirror.conf for this particular volume is "CENSLFASPROD02:SnapVault_Move_Test CENWBFASDR02:SnapVault_Move_Test_SnapMirror - - - - -"
On the snapvault relationship I have created a new relationship only on the destination filer and to use the snapmirror destination as the snapvault source volume. the initial snapvault when the relationship was created was fine.
This is the snapvault schedule.
What I am unsure of is do i create a transfer or a backup job and which volume am I directing this from, is it the snapmirror destination volume or the snapvault primary volume? I am guessing it must be the snapmirror destination as its this volume I want to create retentions for?
2015-10-14 09:08 AM
hi, i have to do the same configuration. Source volume Snapmirror -> Snapvault and its not working. I did snapvault with backup and transfer mode, but still not working.
Do you have a solution?
2015-10-30 01:46 AM
Yes I have made progress with this, whether the solution I have gone for is the best I dont know but it seems to acheieve what I want to do.
So the aim was to move all snapvault tasks to our DR filer only. and only use snapmirror from source to DR filer.
This is the order that I did:
this started of a new snapvault baseline and then I just setup a schedule for snapvaulting to schedule a few hours after a snapmirror task had run to ensure SM/SV jobs didnt clash with one another.
This seems to have retained all the existing snapvault snapshots I had created before hand as the destination volume was the same volume I used before, the only difference was rather than the source coming from the primary volume on the production filer, instead the new source was the snapmirror destination volume on the DR filer. This has now cut out sending snapvault backups across the WAN link and it is now only doing snapmirror tasks.
Hope that makes sense.