Sun Microsystems 3 manual Choosing Between Synchronous and Asynchronous Replication

Page 21

Choosing Between Synchronous and Asynchronous Replication

In synchronous mode, a write operation is not confirmed as complete until the remote volume has been updated. Generally, synchronous mirroring is limited to relatively short distances (that is, tens of kilometers) because of the detrimental effect of round-trip propagation delay on I/O response times. However, there are applications such as web server replication that can tolerate relatively slow remote updates and operate in a synchronous mode over long stretches.

With synchronous mirroring, the remote copy always matches the local host’s view of committed writes. Should the local primary site be rendered inoperative, the remote secondary copy can be used to continue operations after the user community and the applications are switched to the alternate site.

What if the link goes down while running in synchronous mode? Should the local I/O remain incomplete until the link comes back up? Some applications require that the primary and secondary sites be exactly in sync and therefore would desire that the I/O not complete. However, many mission-critical customers decide not to block local access to the data upon encountering intersite transmission errors. Instead, software keeps track of these writes at the primary site and then updates the recovery site when the remote service is reliably restored. If configured this way, disaster recovery procedures must take into account loss of in-flightand logged data. That is, data might have been committed to the local application but never had a chance to arrive at the backup site.

Asynchronous mirroring affirms primary I/O completion to the originating host before updating the remote image. This type of mirroring is often used when the distance and relatively low bandwidth telecommunications lines of 45 Mbps or less between primary and secondary sites would introduce prohibitive latencies if performed synchronously. Here, the long-distance pipe becomes the bottleneck, forcing local writes to be queued for later transmission. Consequently, there is a higher possibility of losing buffered and in-flight data if the primary system fails.

Chapter 2 Configuration Considerations 11

Image 21
Contents Sun StorEdge Network Data Replicator Configuration Guide Please Recycle Contents Page Before You Read This Book PrefaceDocumentation Conventions Using Unix CommandsRelated Documentation Shell PromptsApplication Title Part Number Accessing Sun Documentation Online Ordering Sun DocumentationSun Welcomes Your Comments Page Sun Sndr Software Description OverviewPage TCP/IP Connection Hardware Components Supported Hardware and SoftwareNetwork Multipathing Architecture ApplicationsSdbc Volumes Eligible for Replication Configuration ConsiderationsChoosing Volume Level Protection Bitmap Volumes for Scoreboard LogsATM Link Advantages Choosing a Connection Medium to Link My SitesLink Security Configuring Redundant Links Between SitesChoosing Between Synchronous and Asynchronous Replication Configuring The Sun Sndr Software for Mutual Replication When To Suspend Replication to the Secondary SiteSync Order-Dependent Writes and Volume Set GroupingRecovery Considerations Recovering the Primary or Secondary SiteFailing Over to the Secondary Site Choosing the Resynchronization Type Update or Full Using The Sun Sndr and Sun StorEdge Instant Image Software Sun Sndr Software and Sun StorEdge Fast Write Cache Software Dev/rdsk/c0t0d0s9 One-to-Many and Multihop Volume SetsUsing The Sun Sndr Software in a Firewall Environment
Related manuals
Manual 368 pages 47.9 Kb