Project Vs. Share Replication - Oracle ZFS Storage Appliance Administration Manual

Remote Replication Concepts
knowledge of the storage configuration on the target. It does not keep track of which pool the
action is being replicated to, nor is it updated with storage configuration changes on the target.
When the target is a clustered system, the chosen storage pool must be one owned by same
controller which owns the IP address used by the source for replication because only those
pools are always guaranteed to be accessible when the source contacts the target using that
IP address. This is exactly analogous to the configuration of NAS clients, for example, NFS
or SMB, where the IP address and path requested in a mount operation must follow the same
constraint. When performing operations that change the ownership of storage pools and IP
addresses in a cluster, administrators must consider the impact to sources replicating to the
cluster. There is currently no way to move packages from one storage pool to another.
Related Topics
"Remote Replication Workflow" on page 470
■
"Remote Replication" on page 469
■

Project vs. Share Replication

Although it is possible to configure remote replication on both the project level and share level,
project-level replication is recommended for these reasons. The appliance allows administrators
to configure remote replication on both the project and share level.
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.
When reversing share-level replication, the share is placed in its 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.
Like other properties configurable on the Shares screen, each share can either inherit or override
the configuration of its parent project. Inheriting the configuration means not only that the
share is replicated on the same schedule to the same target with the same options as its parent
project is, but also that the share will be replicated in the same stream using the same project-
level snapshots as other shares inheriting the project's configuration. This may be important
for applications which require consistency between data stored on multiple shares. Overriding
the configuration means that the share will not be replicated with any project-level actions,
though it may be replicated with its own share-level actions that will include the project. It is
not possible to override part of the project's replication configuration and inherit the rest.
More precisely, the replication configuration of a project and its shares define some number
of replication groups, each of which is replicated with a single stream using snapshots taken
simultaneously. All groups contain the project itself (which essentially just includes its
532 Oracle ZFS Storage Appliance Administration Guide, Release OS8.6.x • September 2016