Start a Conversation

Unsolved

This post is more than 5 years old

560

December 1st, 2009 05:00

srdf s or celrra replicator.

Customer is looking for pro's or con's for either replication strategy.Plent of pipe to use srdf.Strictly for site recocvery not individual vdm's etc.

Moderator

 • 

285 Posts

December 1st, 2009 08:00

I see you speaking about a customer; please understand that this is the external customer-facing forum; there is no EMC Confidential information on this forum.

That said, this is still an important topic for everyone to understand, so we will address it here.

Celerra RDF/S: This is a disaster recovery technology that uses SRDF (Symmetrix Remote Data Facility) in a Synchronous mode.  This means that before the write is acknowledged to the Celerra, it has been written on both the primary and secondary Symm devices.  This provides guaranteed data writes to the destination, perfect for a situation where it is critical that no data be lost in the failover process.

ADVANTAGES: Provides guaranteed data writes on both the source and destination.  When a write is confirmed, you can be assured that it is stored on both sides. Is a backend replication, does not impact customer network.

DISADVANTAGES: A DR (smoking hole) solution only.  Works on Symmetrix only.  Requires Synchronous distances (less than 60(?) km).  Can't fail over individual filesystems or Data Movers; failover is for the whole cabinet (all or nothing).  EMC-configurable only (customer normally can't set up their own SRDF config)

Celerra Replicator: This replication technology uses IP to replicate filesystems across virtually any distance.  This is not a synchronous replication; there will always be some amount of data unabailable on the destination side as it uses a point-in-time system to deliver updates to the destination.  When the source side reaches a certain number of bytes updated or after a certain amount of time, it will send the deltaset across to the destination.

ADVANTAGES: Can use any Celerra system with any backend, so long as the NAS code versions match, can replicate across virtually any distance.  Customer-configurable; can fail over a single filesystem at a time if desired. Can have other uses besides DR. Has a "switchover" solution for DR testing or planned switchovers which does not lose any data.

DISADVANTAGES: Not real time; there will always be data missing on the destination (during a DR situation).  Uses bandwidth on the IP network.

Let me know if I missed anything or if you have any other questions.

95 Posts

December 1st, 2009 11:00

Bill,

Please clarify this point in celerra instance "there will always be data missing on the destination (during a DR situation)."

14 Posts

December 1st, 2009 11:00

Hi Bill

     By customer I meant I am a contractor on a project.

     Thanks for you input.With all things being the same and for smoking hole DR only.Which would be the EMC best practice RDF or Replicator.

Moderator

 • 

285 Posts

December 1st, 2009 15:00

Which would be the EMC best practice RDF or Replicator.

Either one is acceptable.  It depends on your particular needs.  You may not have access to two Symmetrix arrays and two Celerras with a RDF link in between.  You may want to fail over an individual filesystem instead of the entire array.  Your solution may have no tolerance for data loss, or maybe you can lose 5 minutes of data and still be OK.  It really depends on your individual needs and your infrastructure.

Moderator

 • 

285 Posts

December 1st, 2009 15:00

Please clarify this point in celerra instance "there will always be data missing on the destination (during a DR situation)."

A synchronous DR solution is one in which you are always up to date in terms of writes.  For Celerra RDF, a write happens in four steps:

1.  Celerra issues write to source Symmetrix.

2.  Source Symmetrix commits the write locally, issues the write to target Symmetrix.

3.  Target Symmetrix commits write, sends acknowledgement back to source Symmetrix

4.  Source Symmetrix then acknowledges write to Celerra.

As you can see, when the Symm acknowledges that the write has completed, the write has been committed on both the source and target Symmetrix.  This is what you would consider a lossless solution.

An asynchronous DR solution is one that is not always current.  In Symmetrix, this means that writes are "one track behind."  A typical SRDF/A write process would look like this:

1.  Celerra issues write to source Symmetrix

2.  Source Symmetrix commits the write locally.

3.  Source Symmetrix acknowledges write to Celerra.

4.  Source Symmetrix issues the write to target Celerra, monitors for completion of write.

This allows for faster acknowledgement when distance precludes a synchronous solution, because the round trip time (RTT) of the destination write would adversely affect the performance of the Celerra.

In the case of IP Replication, it is an asynchronous solution, but it is a "point in time" copy that is replicated to the destination.  It uses "deltasets" to send bursts of data across the link at predetermined thresholds.  A typical setup would have a timeout (TO) of 300 seconds (5 minutes) and a high watermark (HWM) of 300 MB.  If either of those thresholds is met, the source side will send the deltaset in a burst to the destination.  So at any one time, the destination side could have data that is either up to 5 minutes behind or up to 300 MB that has not yet been delivered to the destination.

IP Replication has two failover models.  In a "switchover" mode, used for DR testing, the source side will be quiesced and a deltaset will be sent.  When it is received, then the source is marked as R/O and the destination is marked as R/W.  This would be used in a non-emergency situation, like a planned DR test.  In a "failover" mode (or if the source is no longer present), no deltaset is sent.  The source (if it is available) is immediately marked as R/O and the destination is immediately marked as R/W, making the destination live with whatever data it has.  So when it fails over, it won't have the curent deltaset, so it will always be behind.

Please let me know if you have more questions.

No Events found!

Top