Please note: this is a "cross posting" of sorts, from a post I made;
http://groups.google.com/group/comp.unix.solaris/browse_thread/thread/a8bd4aab3918b7a0/528dacb05c970748
It was suggested that I mention it here. so I am doing so.
For convenience, here is mostly a duplicate of what I posted, with a
couple of minor updates.
Please note: I'm not asking for technical help on "how" to do it. I'm
soliciting feature requests now, so I can incorporate appropriate ones
into the initial user interface design.
This will be a single-executable program
WIP: design doc for "zrep", a zfs based replication program.
This goes one step beyond other replication utils I've seen, in that
it is explicitly targetting the concept of production "failover".
This is meant to be "enterprise product" quality, rather than merely
a sysadmin's tool.
# Design goals:
# 1. Easy to configure
# 2. Easy to use
# 3. As robust as possible
# 3.1 will not be harmful to run every minute, even when WAN is down.
# (Will need safety limits on # of snapshots and filesystem space free?)
# 4. Well documented
# Limitations(mostly for ease-of-use reasons):
# Uses "short hostname", not FQDN, in snapshot names. automatically truncates.
# Only one copy destination per filesystem-remotehost combination allowed
# Stores configuration in filesystem properties of snapshots.
# Need to figure out some sort of "locking", for during sync and changes.
## Possibly via filesystem properties?? or other zfs commands
Usage:
zrep -i/init ZFSfs remotehost destfs == create initial snapshot.
should do lots of sanitychecks. both local and remote.
SHOULD it actually do first sync as well? ....
Should it allow hand-created snapshot,?
If so, specify snap as ZFSfs arg.
Extra options....
SHOULD IT SET READ-ONLY ON REMOTE SIDE??!
Should it DEFAULT to read-only? (probably?)
(Should it CREATE fs in pool? or just leave that to sync
zrep -S/sync ZFSfs remote destfs # copy/sync after initial snapshot created
zrep -S/sync all #special case, copies all zfs fs's that have been
# initialized.
zrep -C/changedest ZFSfs remotehost destfs #changes configs for given ZFS
zrep -l/list (ZFSfs ...)#list existing configured filesystems, and their config
# Should also somehow list INCOMING zrep synced stuff?
# or use separate option for that? Possibly -L
zrep -s/status (ZFSfs) ?
zrep clear ZFSfs #clear all configured replication for that fs.
zrep clear ZFSfs remotehost #clear configs for just that remotehost
zrep failover ZFSfs@snapname # Changes sync direction to non-master
# Can be run from EITHER side? or should make it context-sensitive?
Initial concept of "failover"
Ensures first of all, that that snapshot exists on both sides.
(should it allow hand-created snapshots?)
Then configures snapshot on non-master side, with proper naming/properties.
Renames snapshot pair to reflect new direction.
REMOVES other snapshots for old outoging direction.
At completion of this operation ,there will be only 1 zrep-recognized
snapshot on either side, that will serve as the initial point of synch.
###########################################
# zrep fs properties
#
# zrep:dest-fs where this get zsend to
#
# zrep:lock ? no, use zfs hold instead?
#
#
###########################################
# snapshot format:
#
# fs@zrep_host1_host2_#seq#
# fs@zrep_host1_host2_#seq#_sent
# a snapshot will be one or the other of the above.
# Once a snapshot has been successfully copied, it should be auto-renamed,
# so you can know without seeing the other side, whether something has been
# synced.
# After initialization, when normal operations has started, there should
# always be at least TWO snapshots:
# the latest "full", and the most recently sent incremental.
# There can also be some number of "just in case" incrementals
#
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
