I am in need of a NetApp-based solution design that will provide a CIFS-based file share for a single volume to windows-based application servers located in two data centers separated on opposite ends of the United States. The application run-time requirements mandate that both sets of application servers utilize a single shared set of files with as short of a replication lag as possible. Replication will need to be bi-directional and synchronous.
The disk volume should reside in both data centers to satisfy high-availability and access latency requirements.
An initial recommendation of MS File Servers utilizing DFS was made and rejected as NetApp Filers are specified for use in the data centers.
What would the appropriate NetApp solution / architecture be? Initial investigation into SnapMirror capabilities indicates it is a non-real-time DR solution.
Obviously, network capacity and latency concerns will be factored when provisioning the long-haul WAN. Cisco WAAN appliances may be considered.
Any thoughts on this would be appreciated as well.
Regarding your project requirements as mentioned above, Peer Software offers a solution for Business File Sharing and Collaboration on NetApp and Windows systems that fits your needs. The company's enterprise file collaboration product is named PeerLink, which includes DFSR+ technology that allows for the following key capabilities:
Real-time bi-directional synchronization
Block-level synchronization (i.e. only the changed portions of a file are replicated to save on WAN bandwidth)
Multi-threaded synchronization (i.e. parallel processing of multiple file events for faster updating)
Version conflict prevention through distributed file locking (i.e. when a file is opened on one site for WRITE access, PeerLink locks down the synchronized copy for READ ONLY access on the other sites)
Supports NetApp Data ONTAP v7.3.5 (and higher) as well as Microsoft Windows Server 2000, 2003, 2003 R2, 2008, and 2008 R2
I Think the problem is whoever wrote the project breif was trying to spec the solution.
In my mind you simply cannot do this with NetApp alone - If the project breif say's you must use NetApp Filers then you are going to have do two things:
A) Use NetApp Filers
B) Put something infront of them to provide the functionallity that is required
Optional: C) Sack the solutions architect.
If you can't add additional servers then you are going to have to publish a DFS Namespace either as a standalone root on the application servers or publish it into AD if you have this available - or use other software to accomplish this.
Eitherway it doesnt matter what is written in your project breif as far as I am aware there is simply no way you can have replication occuring between two filers running ontap whilst they are both R/W - not unless you want to get involved with developing drivers / software.
David's option B could specifically be Windows servers utilizing DFS but using NetApp filers for block storage (FC or iSCSI). We have a very large domain based DFS structure that provides a single namespace for company-wide team shares but only one target for each leaf is R/W. I am very skeptical you can use DFS to provide R/W for the same data at both locations without running into performance and/or save conflict issues. DFS does provide the distribute write capability but in my experience it is best used for data is that mostly read and rarely write access.
Without knowing the application and the reason for the geographic split it's tough to get more specific about other possible solutions.
Firstly, are you sure the application in question can operate on two copies of data in two locations? For vast majority of existing apps that is not the case & they have one active data plex plus one or more passive plexes (these in some cases can be used for reads only).
Secondly, whether certain form of replication can be real-time (or near-real-time) depends on the link characteristics - its bandwidth & latency. In fact NetApp SnapMirror can operate in either synchronous or asynchronous mode (not sure whether semi-sync has been already droped or not). But even if you use async mode, in theory you can replicate every minute if a) you have relatively small data change and/or b) your pipe has massive bandwidth.
Bear in mind though that SnapMirror target volumes are read-only, so changinging anything within them (without breaking the mirror) is out of the question.
The application can not operate on two separate copies of the file-based data. It must have one copy. Data will be accessed via CIFS share, but storage must be actively distributed across multiple filers in separate data centers in real-time. Application servers in either data center should be able to use the CIFS share via NetApp appliance that is co-located in the same data center. Mirroring for DR purposes does not provide the required functionality.
We have done this using DFS to provide a single CIFS share path to a distributed / clustered application while the data available behind the share was available on disks in multiple data centers. This project mandates use of NetApp equipment.
What would the infrastructure architecture look like for the NetApp equipment to provide this functionality?
Assume for the purposes of this discussion that we have WAN provisioned to provide sufficient bandwith and low-latency connectivity.