While EMC users benefit from Replication Manager, NetApp users NEED SnapManager

Posted on by

This is a follow up to my recent post NetApp and EMC: Replication Management Tools Comparison, in which I discussed the differences between EMC Replication Manager and NetApp SnapManager.

————

As a former customer of both NetApp and EMC, and now as an employee of EMC, I noticed a big difference between NetApp and EMC as far as marketing their replication management tools. As a customer, EMC talked about Replication Manager several times and we purchased it and deployed it. NetApp made SnapManager a very central part of their sales campaign, sometimes skipping any discussion of the underlying storage in favor of showing off SnapManager functionality. This is an extremely effective sales technique and NetApp sales teams are so good at this that many people don’t even realize that other vendors have similar, and in my opinion EMC has better, functionality.  One of the reasons for this difference in marketing strategy is that NetApp users NEED SnapManager, while EMC users do not always need Replication Manager.

The reason why is both simple and complex…

EMC storage arrays (Clariion, Symmetrix, RecoverPoint, Invista) all have one technology in common that NetApp Filers do not–Consistency Groups. A consistency group allows the storage system to take a snapshot of multiple LUNs simultaneously, so simultaneous in fact that all of the snapshots are at the exact same point in time down to the individual write. This means that, without taking any applications offline and without any orchestration software, EMC storage arrays can create crash-consistent copies of nearly any kind of data at any time.

The EMC Whitepaper “EMC CLARiiON Database Storage Solutions: Oracle 10g/11g with CLARiiON Storage Replication Consistency” downloadable from EMC’s website has the following explanation of consistency groups in general…

“…Consistent replication operates on multiple LUNs as a set such that if the replication action fails for one member in the set, replication for all other members of the set are canceled or stopped.  Thus the contents of all replicated LUNs in the set are guaranteed to be identical point-in-time replicas of their source and dependent-write consistency is maintained…”

“…With consistent replication, the database does not have to be shut down or put into “hot backup mode.”  Replicates created with SnapView or MV/S (or MV/A, Timefinder, SRDF, Recoverpoint, etc) consistency operations, without first quiescing or halting the application, are restartable point-in-time replicas of the production data and guaranteed to be dependent-write consistent.”

Consistency is important for any application that is writing to multiple LUNs at the same time such as SQL database and log volumes. SnapManager and Replication Manager actually prepare the application by quiescing the database during the snapshot creation process. This process creates “application-consistent” copies which are technically better for recovery compared with “storage-consistent” copies (also known as crash-consistent copies).

So, while I will acknowledge that quiescing the database during a snapshot/replication operation provides the best possible recovery image, that may not be realistic in some scenarios.  The first issue is that the actual operation of quiescing, snapping, checking the image, then pushing an update to a remote storage array takes some time.  Depending on the size of the dataset, this operation can take from several minutes to several hours to complete.  If you have a Recovery Point Objective (RPO) of 5 minutes or less, using either of these tools is pretty much a non-starter.

Another issue is one of application support.  EMC Replication Manager and NetApp SnapManager have very wide support for the most popular operating systems, filesystems, databases, and applications, they certainly don’t support every application.  A very simple example is a Novell Netware file server with a NSS pool/volume spanning multiple LUNs.  Neither NetApp nor EMC have support for Novell Netware in their replication management tools.  While you can certainly replicate all of the LUNs with NetApp SnapManager, SnapManager has no consistency technology built-in to keep the LUNs write-order consistent.  The secondary copy will appear completely corrupt to the Netware server if a recovery is attempted.  Through the use of consistency groups with MirrorView/Async, the replication of each LUN is tracked as a group and all of the LUNs are write-order consistent with each other, keeping the filesystem itself consistent.  You would need to have either array-level consistency technology, or support for Netware in the replication management tool in order to replication such a server..  Unfortunately, NetApp provides neither.

You may have complex applications that consist of Oracle and SQL databases, NTFS filesystems, and application servers running as VMs.  Using array-based consistency groups, you can replicate all of these components simultaneously and keep them all consistent with each other.  This way you won’t have transactions that normally affect two databases end up missing in one of the two after a recovery operation, even if those databases are different technologies (Oracle and MySQL, or PostgreSQL for example).

EMC Storage arrays provide consistency group technology for Snapshots and Replication in Clariion and Symmetrix storage arrays.  In fact, with Symmetrix, consistency groups can span multiple arrays without any host software.  By comparison, NetApp Filers do not have consistency group technology in the array.  Snapshots are taken (for local replicas and for SnapMirror) at the FlexVolume level.  Two FlexVolumes cannot be snapped consistently with each other without SnapManager.

There are a couple workarounds for NetApp users–you can snapshot an aggregate, but that is not recommended by NetApp for most customers, or you can put multiple LUNs in the same FlexVol, but that still limits you to 16TB of data including snapshot reserve space, and both options violate best practices for database designs of keeping data and logs in separate spindles for recovery.  Even with these workarounds, you cannot gain LUN consistency across the two controllers in an HA Filer pair, something the CLARiiON does natively, and can help for load balancing IO across the storage processors.

In general, I recommend that EMC customers use EMC Replication Manager and NetApp customers use SnapManager for the applications that are supported, and for most scenarios.  But when RPO’s are short, or the environment falls outside the support matrix for those tools, consistency groups become the best or only option.

Incidentally, with EMC RecoverPoint, you get the best of both worlds.  CDP or near-CDP replication of data using consistency groups for zero or near-zero RPOs plus application-consistent bookmarks made anytime the database is quiesced.  Recovery is done from the up-to-the-second version of the data, but if that data is not good for any reason, you can roll back to another point in time, including a point-in-time when the database was quiesced (a bookmark).

So, while EMC has, in Replication Manager, an equivalent offering to NetApp’s SnapManager, EMC customers are not required to use it, and in some cases they can achieve better results using array-based consistency technologies.

Category: comparisons, solutions, technologies | Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

26 comments on “While EMC users benefit from Replication Manager, NetApp users NEED SnapManager”

  1. Hello, D from NetApp here.

    Crash consistent != app consistent. Oracle recovers nicely, many other apps not so much.

    Oh, and NetApp supports consistency group crash consistent snaps even across hordes of controllers.

    We do this for some DBs that are hundreds of TB large where handshaking with oracle takes too long.

    Check here:

    http://blogs.netapp.com/dropzone/2010/05/large-scale-data-protection.html

    D

    • Hello D, thank you for the link… I absolutely agree with you that Crash-Consistent is not the same as App-Consistent, and I acknowledged that in the post. And I should probably have made it clear, as you said, that some apps handle this well (Oracle, SQL, Exchange, etc) and others don’t. As with anything in life, there are always caveats.

      Mike’s post is very informative and extolls the virtues of NetApp’s software portfolio with SnapManager and Protection Manager. Creating application consistent snapshots/images of extremely large databases can be done with Replication Manager much as Mike described in his post. But the solution he describes still leverages host-based software to manage the quiesce and snapshot process. I have, to date, seen no information that ONTap can perform snapshots of multiple LUNs, spread across multiple aggregates and flexvols, in a consistency group without any host software what-so-ever. And that was the essence of the post. I would love to see documentation to the contrary.

      • Mike from NetApp here.

        You are incorrect. The 600+TB database solution I worked on in the past uses NetApp consistency group CG technology to take crash consistent snapshots across 8 different controllers. There was no NetApp SnapManager software on the Oracle host or host interaction of any type during the snapshots.

        The SnapManager products are not needed for consistency group functionality, but the benefits they provide in terms of manageability make them the obvious choice for customers and the reason why they are the center of the spotlight.

        Regardless of how the CGs are done, they are a viable and highly scalable alternative to customers who have reached the limits of EMC’s data protection solutions.

        http://www.backupcentral.com/content/view/322/47/

        • Mike, can you explain how a NetApp customer can (with standard array management tools, ie: FilerView, CLI, Systems Manager) create a consistency group of multiple LUNs in different aggregates, and replicate them as a set using SnapMirror/Async, on a schedule with a 5 minute update interval? I know a customer that would actually be interested in doing that, since they were doing it with MirrorView/Async in the Navisphere Manager native UI before purchasing a Filer for a different application.

      • NetApp consistency groups across multiple controllers without the need for SnapManager or SnapDrive have been around for a while through the use of APIs that you can easily call in a variety of ways.

        We even have a cool framework called SnapCreator that allows easy app snaps for things not supported by SnapManager – you know, like those weird DBs that pop up from time to time… which covers your other question about apps not under the SnapManager/Replication Manager umbrella.

        We’ve been doing this for a while…

        Since you were a NetApp customer, you probably were not large enough to have a DB spanning many controllers and the DB be so big that it’s quicker to do a crash-consistent consistency group snap across many controllers.

        If you were in that boat, your NetApp team would have offered the option.

        SnapManager is offered because it’s always app-consistent, integrates with mirroring and easy to use, but that doesn’t mean other, less elegant avenues are not available 🙂

        Let me flip your question:

        How does EMC (or indeed any other vendor) allow crash-consistent consistency groups for multi-PB DBs ACROSS ARRAYS without ANY software OR RecoverPoint?

        RecoverPoint is good but pretty darn expensive and intrusive and has its own set of limitations, especially if not sized right.

        Let me also say I was a user of various kinds of storage for many years and also sold EMC (among others) for a living for several years after that, before joining NetApp…

        D

        • SnapCreator appears to be a set of scripts that can be run on a host to create application consistent snapshots of a set of applications that are not directly supported by SnapManager. It can be used independent of SM it seems as well. I agree, that is a useful tool, but it’s still host based, and you are still scheduling database quiesces. Can I get a 60 second RPO with SnapMirror/Async?

          I posed a question in my reply to Mike, how would a NetApp administrator, using FilerView, Systems Manager, or the CLI, create a consistency group across LUNs in different aggregates, and replicate them with SnapManager/Async on a 5 minute update interval?

          To answer your question.. Symmetrix Timefinder (timefinder is the snapshot technology in Symmetrix) can create consistency groups across multiple Symmetrix frames and snapshot, clone, and replicate (with SRDF) those groups. RecoverPoint can do so across multiple heterogenous storage arrays. RecoverPoint/SE for Clariion customers is actually very reasonably priced and outperforms pretty much every mid-range replication offering available. Everything has sizing limitations, it comes down to the customer requirements.

  2. hi,

    it’s a requirement to perform the application consistent snaps/clones in MS environment. this is why VSS there for and vendors integrate their solutions with VSS. I don’t belive MS would support any snap tech lacking of such functionality.

    • It really depends on what the end goal is.. If you want to take snapshots or clones of a SQL database to be mounted onto another host for backup or reporting use, then VSS or VDI integrated solutions are a best bet. If you want to replicate that database to a remote site (asynchronously) for disaster recovery purposes you can leverage that same technology. But your recovery point (amount of data lost in the event of a failure and restore) is dependent on how often you perform the VSS integrated snapshot. Even though snapshots are short and VSS/VDI is integrated, it is not without performance impact to the database. If the database is extremely busy, quiescing too often can overrun the database in some cases. They also allow you to get recovery points down into the minutes and seconds depending on bandwidth, rate of change, distance, etc.

      On Support, MS states that storage array functionality must preserve write-order fidelity, which is what EMC Consistency Groups provide. They don’t even really support VSS/VDI fully. MS will support the VSS API, but if you are using SnapManager to perform VSS integrated snapshots, you need to call NetApp for support.

      • > They don’t even really support VSS/VDI fully.

        Microsoft fully support VSS/VDI. I’m not sure why you think they wouldn’t…

        > MS will support the VSS API, but if you are using SnapManager to perform VSS integrated snapshots, you need to call NetApp for support.

        Last time I checked, Microsoft only supports their own technology. If a given problem with restore, or whatever, occurs, Microsoft will troubleshoot their own stuff and in the event that it’s proven it’s another vendors issue, the case gets handed off to them.

        Or are you saying that Microsoft will end-to-end support a customer of EMC where, for example, the replication went bad and the crash recovery won’t recover?

        • Paul, with regard to Microsoft support, I was alluding to the same thing you stated, that MS supports their own portion of the technology. I was actually on a call, highly escalated, dealing with a VSS issue with Exchange. The end result was that the VSS API reported that it was OK (it in fact was not) and Microsoft passed us off to EMC. In the end, EMC had to troubleshoot the issue and pull 3 different Microsoft KB articles up specifically related to VSS issues in Windows 2003 with procedures to fix. I’m merely pointing out that using Microsoft VSS doesn’t always put you in a better position, it’s up to the storage vendors (all of them) to make good on any promises they make to a customer about functionality and recoverability.

  3. Consistency groups at the array or FlexVol level inside ONTAP would be a good addition, certainly.

    A nitpick on the ‘separation of spindles’ point: Aggregates are multiple spindles, so multiple LUNs inside a single FlexVol will give you that. The performance will match the aggregate containing the FlexVol.

  4. Crash consistent backups generally implies “not consistent”, “point in time” and “data loss”. The time you *need* your data to be usable (after a failure) is not the time you want the customer to discover that their last “crash consistent” backup won’t restore. This is what tools like the SnapManager suite are designed to protect from.

    Additionally there is a saying “Backup flatters… Restore matters.” The whole idea of the SnapManager suite is not to provide great backups but instead provide great restores. Any amount of clever foo to perform a crash consistent backup doesn’t mean a thing if there is no simple, easy, janitor-proof way of restoring. That is the power of the SnapManager products and the demos of which you speak.

    Who wants to see a demo of a backup? Not me… now a demo of a restore from nasty corruption without tons of effort and mistakes from the user… that is interesting.

    > You may have complex applications that consist of Oracle and SQL databases…

    If the customer is unlucky enough to have such an application and has no sensible way of backing it up… e.g. no application level consistent tool then the customer is in an unhappy place regardless of the technology used.

    > Depending on the size of the dataset, this operation can take from several minutes to several hours to complete.

    How would the customer perform a safe backup with tape in this environment? Are you saying that some application vendor has written this app with no sensible way to perform backups at all?

    If you are saying that your version of consistency groups can spread across tens of arrays, potentially across multiple data centres, with arrays from different vendors (hey… you’ve got application stacks from different vendors…) then I’d be interested in that. If your level of granularity is just a single vendors single platform from a single data centre then is that really worth a blog post over?

    Aggregate snapshots aren’t designed for end customers to use for backup purposes, so they aren’t a work around. You can’t mirror at that level.

    > Neither NetApp nor EMC have support for Novell Netware in their replication management tools.

    We don’t? There is no SnapManager for Novell product. SnapManager isn’t a single product but a suite of products designed for the applications that they support. But our replication management tools (protection manager, for example) can quite happily support replicating volumes containing Novell luns.

    > but that still limits you to 16TB of data including snapshot reserve space

    Not as of nearly a year ago. The current limit is about 100TB, including snapshot reserve space. BTW – you only need snapshot reserve space for user files, not applications or databases.

    > and both options violate best practices for database designs of keeping data and logs in separate spindles for recovery.

    I think the 1980s would like their best practices back. This old style of thinking made sense in ye olde times when customers were told that they should have RAID-5 for database and RAID-1 for logs, but since all modern storage arrays support some form of RAID-6 where the resilience is much higher than this method, physically splitting the logs onto different disks doesn’t add anything in terms of availability or recoverability.

    And anyway, in the event you need to restore… and are lucky enough to have the logs, surely you’ll just be moving over to the “crash consistent” DR copy anyway rather than wait the (potentially) hours or days to get the database back on the production site…

    Regards

    Paul

    • Restore is the real requirement, Backup is a means to an end, I’ve previously blogged on that topic, and the point about crash-consistent vs app-consistent has been made. In an asynchronous replication scenario, data-loss is understood to be a factor. The question becomes how much data can I lose? Crash-consistent copies are restartable copies and are extremely useful, and I would argue necessary, for low-RPO asynchronous replication. If you are replicating asynchronously with updates in the seconds or minutes, you most likely won’t be able to create an app-consistent snapshot for each update. As an example, you may be able to quiesce a database once every hour or two. If you have a failure at the primary site and restart your application from the secondary site, using an app-consistent copy could mean data loss is up to an hour (or whatever the quiesce interval was). If the replicated copies are crash-consistent (with write-order fidelity), the data loss is only up to the last update that occurred. For one of my customers, 1 hour of data loss equals $10 million in revenue, they’d much rather have the “option” to first recover from crash-consistent copies, than guarantee that they will lose up to 1 hour (and $10 million) going back to their last app-consistent copy.

      In the event of a local recovery, DBAs will want to recover to the most recent transactions using the logs, if available. They are not always available however. For example, if you have a 100TB aggregate of 600GB FC disks (well over 100 disks in the group) and you have a triple disk failure, (much more likely as the disk counts increase) what happens to the logs if the DB and Logs are stored in the same aggregate? Snapshots in general won’t help in that case, but app-consistent (or) crash-consistent Snapview Clones, Mirrorview/Async replicas, etc will provide the quickest restore with the least data-loss possible.

      There are myriad applications, being used in enterprise environments, that have no place hosting business critical applications, but they are doing it nonetheless and protecting them can be a real challenge.

      • > If you are replicating asynchronously with updates in the seconds or minutes, you most likely won’t be able to create an app-consistent snapshot for each update.

        Sure you can.
        Async: You take an app consistent snapshot for the database and crash consistent backups of the logs. On failover / recovery you use the application vendors verification tools to check the last log entry to ensure that the log isn’t corrupt, and then use the app vendors recovery apis to replay all the logs.
        Sync: As async, but logs are sync mirrored. This places much less stress on the entire infrastructure.

        > they’d much rather have the “option” to first recover from crash-consistent copies

        You missed the word “attempt’ from this 🙂 Plus all the delays while you attempt to roll back an entire groups of applications spread across Oracle, SQL, front ends etc., hoping that they *all* recover from this “backup”.

        > For example, if you have a 100TB aggregate of 600GB FC disks (well over 100 disks in the group) and you have a triple disk failure, (much more likely as the disk counts increase)

        I’m not sure about triple disk failures. Certainly if that happens a lot with any customers environment they’ll be changing vendors quickly regardless of whether they can recover or not.

        Since you create an aggregate out of many raid sets / raid groups, the odds of a treble disk failure (double + an unrecoverable sector error) in a single raid set are so high that it’s not a practical concern. E.g. 100 disks spread across 14+2 raid sets mean you could survive 14 concurrent disk failures in the same aggregate… and for the customers who demand more you could always do RAID 6+1 and then still have data consistency in a (14+2)x2 RAID set that can survive 5 concurrent failures. All without needing to go offsite for a DR copy.

        When disks get bigger and it becomes one, we’ll all move to RAID-TP (or whatever the standards body ends up calling it).

        > There are myriad applications, being used in enterprise environments, that have no place hosting business critical applications, but they are doing it nonetheless and protecting them can be a real challenge.

        I concur. Everything we can do to help all customers through these sorts of challenges is a good thing.

    • Paul, I don’t understand what you mean when you stated “BTW – you only need snapshot reserve space for user files, not applications or databases.”

      So are you saying that snapshots of application and database LUNs on NetApp don’t use ANY space for change tracking? How do you track the updates to the source LUN while the snapshot is being kept? Or are you saying that you don’t have to reserve any space? But when snapshot data needs to be stored, where is it going to go? I don’t follow.

      • We use magic 😉

        Seriously, though, our best practices set the *reserve* for these to zero since there is no point in reserving space using “snap reserve” when all space in the volume is the space that can be consumed by the snapshots, and that is controlled automatically when the volume is created.

        If, by reserve, you just meant having some space set consumed by snapshots, then surely all arrays from all vendors need them somehow?

        • Ah, got caught up in semantics, free space must be available in the flexvol and/or aggregate to store snapshot data, whether it’s reserved or not. Good or bad (ie: pros and cons exist to both), NetApp stores snapshot data in the flexvol with the primary data, and EMC stores snapshot data in a separate storage area, usually on different physical disks. In NetApp’s case, it must be considered when sizing aggregates for data when snapshots are going to be used.

  5. (JohnFul from NetApp replies)

    It would help if you read the manual.

    http://now.netapp.com/NOW/knowledge/docs/snapdrive/relunix40/html/software/install_ibm_aix/protecting/concept/c_sd_prot_crash-consistcy-with-dot72-and-later.html for example, although you’ll find the same statement in all the SDU manuals.

    “Data ONTAP versions 7.2 and greater provide support for consistency groups and storage system fencing. ”

    Now what does that mean? In means that APIs are implemented in ONTAP starting in 7.2, specifically cg-start, cg-commit, and cg-delete, to support consistency groups.

    No, you don’t have to use SnapDrive to call the APIs; you can call them from anything you want. If you’d take the time to download the NetApp Manageability SDK http://communities.netapp.com/docs/DOC-1152 you’d find that one of the examples is creating a consistency group from a Perl script. Now don’t get me wrong; SnapDrive and the SnapManager Suite are very nice to have, they’re just not required as you state:

    1. NetApp’s Data ONTAP has supported consistency groups since 7.2

    2. SnapManager (where’d you get that?) or even SnapDive is not required.

    So what was the premise of your post again?

    Thanks

    J

    • Unfortunately, the SDK docs are locked without SDK access in NOW so I cannot read those. I found the comment in the SnapDrive document you mentioned (UNIX) but could not find anything similar in the Windows version of SnapDrive. Why?

      What I find interesting is that the API has had these features since ONTap 7.2, but as of ONTap 7.3.2, I could find no way to create or manage consistency groups (and no mention of) in FilerView, Systems Manager, or the CLI. How does a NetApp customer use this feature without SnapDrive/SnapManager? PERL? What if I just want to right-click on a set of LUNs and snapshot them? Does the PERL script support SnapMirror?

      • If I recall correctly we used to make the NOW site available to competitors but it was abused in sales situations, unfortunately.

  6. “What if I just want to right-click on a set of LUNs and snapshot them?”

    So where exacly does the replication manager interface run? Timefinder? Seems that your premise is you need a client based component that supports calling the APIs. Is it the same for EMC? If I don’t buy Replication Manager or Timefider from EMC, do I get a GUI to click?

    NetApp provides SDKs for customers and partners to access any ONTAP API (and a lot more). Does EMC do that?

    System Manager is a small .Net app that leverages the ONTAP API, and is available for free. Does EMC do that?

    Further, there’s the Data ONTAP PowerShell Toolkit, http://bit.ly/aDcEgL which is also free. Even RedHat provides PowerShell support to their APIs http://bit.ly/bsFYER . Does EMC do that?

    That’s the beauty of APIs, there is no “one” way to access them. Do you want access to consisteny groups via PowerShell? All you have to do is ask http://communities.netapp.com/thread/8970 . Does EMC do that?

    J

    • The essence of the post was to point out the benefits of in-array consistency groups. Replication Manager is similar to SnapManager in that it is a separate tool, running on a set of hosts, managing array features. SnapView, MirrorView, TimeFinder are in-array features (like NetApp snapshots and SnapMirror, for example) and are managed with the array element manager (ie: Unisphere) which runs from the array itself, much like FilerView. So yes, you get a GUI to manage the entire EMC Unified Array, hosted by the array itself, that allows you to 1.) create a persistent consistency group, and 2.) replicate that group to another array, asynchronously on a schedule, or synchronously, with a few mouse clicks–without any other tools, software, scripts, etc.

      API access to functionality is definitely a good thing and I think everyone should do as much as they can in that department.

  7. Our feature accessibility is driven by our customer demands. They typically don’t approach us with questions about how to create consistency groups between arrays.

    Rather, they present an application they would like a certain level of data protection on and we work with them to create a solution. They respond very well to the SnapManager product suite because of this and, their response is why SnapManagers are such a focus for us. Customers focus on application recovery, our products focus on application recovery.

    There are some applications we don’t support directly with SnapManager products and this is why we created both the NetApp SDK and the SnapCreator framework (which supports consistency groups, snap retention, snapmirror and snapvaulting). This gives customers the broadest amount of options in application data protection.

    It seems like you won’t back down from the incorrect premise of your blog. Perhaps you could have titled your blog “I think EMC is best”, left out all the misleading content and made your opinions clear with a lot less effort?

  8. > The StorageSavvy blog is intended to be a vendor neutral discussion about old and new technologies related to storage, and when and how to use those technologies to solve problems.

    It might be worth changing / removing this since looking back over the blog entries over time I notice that this hasn’t really been the case.

    • The whole point is in regards to the value of the ability to create consistent copies at the storage level. Consistency Groups / Crash Consistent backups are essential for several use cases. For instance while working with VLDB’s /data warehouses the customer often do not run in Archive Log mode. So a consistent split based backup/ remote replication is perhaps the only way other than doing a cold backup (bringing down the database) or using RMAN. With EMC-RM we can do a consistent split and mount the database on an another host and do RMAN backups. The other use cases can be with ERP applications like SAP where the landscape spans different databases, also for preserving the consistency of the Java stack. EMC has a unique solution for cloning SAP Java stack without downtime leveraging the consistency technologies….

  9. […] While EMC users benefit from Replication Manager, NetApp users NEED SnapManager June 2010 25 comments 5 […]