2011-08-11 02:49 PM
Hello to all,
This is George from Greece.
Can you please answer to me at the following questions?
Customer is having 4 sites. One is called primary -in athens- and it will have Nseries 6210 or N6240 .
There are also 3 more sites in athens which will have N3400.All those 4 sites are near in a distance of 5-10 Kms maximum.
Also there will be a disaster Site again with N6210 or N6240 (same as primary's site Nseries) around 30 Km maximum distance from the most far away site.
Plan is as follows.
Primary site with N6240/N6210 will be doing synchronous snapmirror to the Disaster site over FC.
All the other 3 sites which have N3400 will be doing asynchronous replication to the Disaster site again over Ethernet.
This is what our salesmen have told to the customer.
My questions are..
Does synchronous snapmirror support distances like this?Around 30 Kms..?If yes is there anything which we should be aware
of according to the performance?Like fine tuning, or anything else we should know in order to achieve maximum performance?
Since the other 3 N3400 will be doing asyncronous snapmirror to disaster N6210/N6240 also, do you know if this is a supported
scenario?I mean replicating from N3400 to N6240/N6210 is supported?I believe yes...
Is there any other better solution that that?LIke having metrocluster or synchronous Snapmirror for the primary and disaster site and all the other 3 sites
to do asyncrhronous snapmirror to the primary site?....By that all the sites will be directed from Primary site to Disaster over syncrhronous mirror...or Metrocluster.
But then again, if we follow this scenario, Primary Site will accept too much I/O in order to accept copies from the 3 other sites , do also the production work of the company and synchronous replication at the same time...
Thank you very much.Best Regards George.
2011-08-11 03:46 PM
AFAIK distance shouldn't be an issue as long as you meet the other prerequisites:
SnapMirror replication from an N3400 to an N62XX is supported, again as long as you meet the prerequisites. Volume SnapMirror is block based and Qtree SnapMirror is file based, the filer model doesn't make a difference:
The setup you have sounds good, obviously MetroCluster is the best solution but it comes with the associated high costs so it depends on your budget. Whether Async SnapMirror from the N3400s to the DR site is suitable comes down to your RPO and whether you have the budget and infrastructure to use Sync SnapMirror.
2011-08-15 03:01 AM
Hello and thanks for your quick reply.I insist in asking the same question , because both our techline and technical lead of NAS europe of my company keep saying that there are performance problems using Sunchronous Snapmirror.
This is our last reply we got from Techical Lead Nas of europe
"I would strongly recommend to use MetroCluster. Please be aware that for MetroCluster you need dedicated fibre (2 lines) between the sites.
SnapMirror Sync over 30KM is not a good choice: delays, possible freeze situations for the client is case of the slightest interlink problem. Performance, according to NetApp's TR, is hit by factor 2.2. Meaning: if you use SM-sync your system will be factor 2.2 more utilzed."
Are you aware of any customers having problems like the ones decribed above?
Do you know which TR(s) are describing the 2.2 more utilized situation of the Nseries while using Synchronous Snapmirror?
Thanks you again!
2011-08-15 04:43 PM
I personally am not aware of the factor 2.2 statement and TBH it doesn't really sound correct. SnapMirror uses any CPU cycles available hence the fact that `sysstat` output on a system with active SnapMirror replications will show high CPU utilisation. This doesn't necessarily mean it'll cause a performance issue, just that it'll grab CPU cycles not in use by more high priority operations.
Due to the distances involved it is crucial that the network infrastructure is up to the job, therefore correct planning and testing would be essential.
This TR contains information on SnapMirror Sync and Semi-Sync Design and Considerations:
2011-08-16 02:57 AM
MetroCluster & synchronous SnapMirror are two, fundamentally different setups (as you are probably already aware).
The question is: what do the customer expect? Rapid recovery in a case of site-level outage? If the answer is yes, then nothing can beat MetroCluster.
If they simply want to make sure there is no data loss (or minimal loss) in a case of the actual disaster, then SnapMirror will do just fine. It is a subject to further discussion whether synchronous mode is really needed. Maybe semi-sync will do? Or async with aggressive schedule (say every 5 minutes for database logs, if that's relevant at all)?