There has been lots of material on the web recently concerning NetApp being able to backup ExaData. The purpose of this blog is to respond to that content, and state why NetApp's offering is rather lame, and actually offers nothing new.
The items on the web produced by NetApp are easy to find. I will not increase their Google hit rate by linking to them here. Suffice it to say, Neil Gerren's blog contains the principle content to which I will respond here. There is also NetApp technical report TR 4022, a 34 page tome, which I have read thoroughly. I think I completely understand what NetApp has produced (which they thought so much of to produce a press release on the subject), and, believe me, there is nothing new or unique in NetApp's offering.
I will summarize the solution here. To avoid any issues with NetApp copyrights, I have recreated the graphics describing the solution. However, the gist is identical to that contained in TR 4022. The solution consists of two parts:
- Backup
- Disaster recovery / remote replication
Backup
Let's start with the backup component. What NetApp proposes is the following:
The fundamental gist of the solution is:
- Connect ExaData to a NetApp filer using 10 GbE.
- Backup the Oracle database on the ExaData to the NetApp filer using RMAN.
I ask you: Is there anything interesting or unique here? In fact, I would state for the record that it would be manifestly better to do the following:
In other words, an EMC Data Domain deduplication array is capable of connecting to an ExaData box and backing it up using RMAN in exactly the same manner as a NetApp filer. I find this statement so obvious that it seems self-evident. But, again, NetApp's material on the subject makes it necessary to point this out.
Data Domain has many advantages over NetApp in the area of Oracle backup. But I will not belabor that point. Suffice it to say, we can do the same thing that NetApp can in the area of backing up Oracle ExaData via 10 GbE. And we certainly have a product which is very suited to backing up Oracle database data, and commonly used for this purpose.
Disaster Recovery / Remote Replication
Let's turn now to the disaster recovery / remote replication solution. What NetApp proposes for a disaster recovery / remote replication solution looks like this:
The fundamental gist of the solution is:
- Replicate the production Oracle databse on ExaData using Oracle Data Guard with physical standby. The target platform consists of generic Intel x86 servers running Linux. (Remember that the RAC compute nodes in the ExaData are nothing more than relatively typical x86 / Linux servers. Thus, Oracle Data Guard with physical standby to a similar non-Oracle server will work just fine, it being an identical platform from an Oracle point of view.)
- The target database server is connected to a NetApp filer using standard protocols (e.g. FC or NFS).
- Once the database copy is on the NetApp filer, normal NetApp tools can be used to snap, clone, etc. the target database.
Again. it seems rather patently obvious that the following is also possible:
And in terms of the ability to perform snaps, clones, and so forth of the Oracle database once it is on our array, EMC's arrays contain features that easily meet those offered by NetApp.
So, again, NetApp's highly touted offering concerning storing ExaData offers nothing new or unique. Each and every feature offered by NetApp is available from EMC, and many features offered by EMC are superior to those provided by NetApp.
Comments to this post are welcome.
"And in terms of the ability to perform snaps, clones, and so forth of the Oracle database once it is on our array, EMC's arrays contain features that easily meet those offered by NetApp."
Really? Since when have EMC arrays been able to offer hundreds of zero-overhead clones of the database that can be used for testing with virtually zero additional disk space requirements (using FlexClone).
Posted by: Steve | March 22, 2012 at 11:32 PM