Sun ZFS Storage 7320
 
Oracle ZFS Storage ZS3-BA
 
Oracle ZFS Storage Appliance Racked System ZS4-4
 
Sun Storage 7210 Unified Storage System
 
Oracle ZFS Storage ZS5-4
 
Oracle ZFS Storage ZS3-2
 
Sun Storage 7410 Unified Storage System
 
Oracle ZFS Storage ZS3-4
 
Sun ZFS Storage 7420
 
Oracle ZFS Storage ZS5-2
 
Oracle ZFS Storage ZS4-4
 
Sun Storage 7310 Unified Storage System
 
Sun ZFS Storage 7120
 
Sun Storage 7110 Unified Storage System
 

PLA-Support>Sun Systems>DISK>ZFS Storage>SN-DK: 7xxx NAS
 

In this Document

Purpose

Scope

Details

References

Applies to:

Purpose

Replication allows the ZFS appliance to move data between appliances and then incrementally update the data between the source appliance and the destination appliance indefinitely.

When designing replication layouts there are a number of things which must be considered.

This document explains key considerations which must be taken into account when laying out replication.

Scope

 This document is meant to provide a checklist of items to be considered by storage administrators as they setup replication on ZFS Storage.

Details

The following are the recommended best practices for laying out replication environments on the ZFS Storage Appliance.

1.  Configure replication actions at the project level. Avoid using share level replication.

There are two reasons for this.

First replication snapshots are always taken at the project level. Multiple share level replications in a single project can create a substantial amount of overhead and consume space on the pool.

Secondly when reversing share level replication the share is placed in it’s own project. This means that replication reversals will end up splitting the share away from the other shares in the project unless they are all replicated together.

2.  Each replication action will be a single thread and connection over the network.

In order to multi-thread the replication, use multiple replication actions on different projects.

The appliance will run up to 30 concurrent replication actions at a time and queue the rest. Scheduling replication so that 30 actions/threads are always active will achieve the best throughput over the network.

Note that active sending and receiving actions count against the 30 active threads limit on a given appliance.

3.  Some types of data won’t lend themselves well to replication.

For high throughput write applications, like database backups, replication’s serialization of the filesystem serves as a bottleneck for the movement of the data.

In these types of applications, the replication may be better served by a client synchronization or copy utility that would parallelize the transfer at the file or sub-file levels.

4.  Configure a static /32 (host-based) route on each replication partner to the other partner - specifying the interface you wish to use for replication before you establish the remote replication relationship.

The interfaces you specify must failover with the pools that replication is using. You may use traceroute or do a test replication to verify that they network routes work as expected.

5.  When prompted to enter the hostname for the remote replication partner, do not enter the hostname of the replication partner.

Enter the IP address of the interface name that you wish to use on the replication partner.

For example zfs1 may be the hostname, but you should enter the IP address of the 'zfs1-rep' network interface to use the interface that you have dedicated to replication.

The IP address will vary between configurations.

6.  Never use the loopback address (127.0.0.1) for a local replication. It will lead to BUI/CLI hang issue.

This is addressed in 2013.1.2 thanks to bug 16370858 - replication to localhost is prohibited, where an alert popup is now raised if user tries to use 127.0.0.1.

Beware that any releases before 2013.1.2 will let you use the 127.0.0.1 loopback address.

7.  For highest throughput do not use SSL.

8.  Network latency plays a key role in determining performance over the WAN. Lower latency provides better performance.

Verify that the replication is taking the lowest latency route for best performance.

9.  The replication interval schedule must be more frequent than the RPO (Recovery Point Objective).

Specifically the RPO must be greater than the sum of the replication interval time and the transfer time of the update being applied.

Partial updates to the remote system are not complete on disk, and therefore only the most recent completed replication can be used to export to clients in the event of a disaster.

NOTE: If a firewall is in use, replication requires port 216 and port 217 to be open.

After considering these points you can refer to Document 1595549.1 for the procedure to setup replication.

***Checked for relevance on 25-MAY-2018***

References

This solution has no attachment