Ben,
I've been playing with replication of a ZFS Zpool using the recently released AVS. I'm pleased with things, but just replicating the data is only part of the problem. The big question is: can I have a zpool open in 2 places?
No. The ability to have a zpool open in two place would required "shared
ZFS". The semantics of remote replication can be viewed to that of two
Solaris hosts looking at the same SAN or dual-ported storage. Today, ZFS
detects this with both SNDR and shared storage, as part of "zpool
import", warning that the pool is active elsewhere.
What I really want is a Zpool on node1 open and writable (production storage)
and a replicated to node2 where its open for read-only access (standby storage).
The best you can do for this to use the II portion of Availability Suite
to take a snapshot of the active SNDR replica on the remote node,
getting a snapshot of the ZFS filesystem being replicated. In this case,
ZFS on the remote node will see and detect replicated disk blocks
changing in the zpool it is reading from.
This is an old problem. I'm not sure its remotely possible. Its bad enough
with UFS, but ZFS maintains a hell of a lot more meta-data. How is node2
supposed to know that a snapshot has been created for instance. With UFS you
can at least get by some of these problems using directio, but thats not an
option with a zpool.
I know this is a fairly remedial issue to bring up... but if I think about what I want Thumper-to-Thumper replication to look like, I want 2 usable storage systems. As I see it now the secondary storage (node2) is useless untill you break replication and import the pool, do your thing, and then re-sync storage to re-enable replication.
Am I missing something? I'm hoping there is an option I'm not aware of.
No. Also just to be clear, after you " ... do your thing, and then
re-sync storage ... " the re-sync is keep all of the data on the SNDR
primary OR keep all the data on the SNDR secondary.There is no means to
combine writes that occurred in two separate ZFS filesystems, back into
one filesystem. The remote ZFS filesystem is essentially a clone of the
original filesystem, and once a write I/O occurs to either side, the two
filesystems take on a life of their own.
Of course this is not unique to the ZFS filesystem, as the same is true
for all others, and this underlying storage behavior is not unique to
SNDR as it happens with other host-based replication and
controller-based replication.
Jim
benr.
This message posted from opensolaris.org
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
