Brent Jones wrote: > *snip* >>> a 'zfs send' on the sending host >>> monitors the pool/filesystem for changes, and immediately sends them to >>> the >>> receiving host, which applies the change to the remote pool. >> This is asynchronous, and isn't really different from running zfs send/recv >> in a loop. Whether the loop is in userland or in the kernel, either way >> you're continuously pushing changes across the wire. >> >>> presumably, if fishworks is based on (Open)Solaris, any new ZFS features >>> they >>> created will make it back into Solaris proper eventually... >> Replication in the 7000 series is mostly built _on top of_ the existing ZFS >> infrastructure. > > Sun advertises Active/Active replication on the 7000, how is this > possible? Can send/receive operate bi-directional so changes on either > reflect on both sides? > I always visualized send/receive only being beneficial in > Active/Passive situations, where you must only perform operations on > the primary, and should fail over occur, you switch to the secondary. >
I think you're confusing our clustering feature with the remote replication feature. With active-active clustering, you have two closely linked head nodes serving files from different zpools using JBODs connected to both head nodes. When one fails, the other imports the failed node's pool and can then serve those files. With remote replication, one appliance sends filesystems and volumes across the network to an otherwise separate appliance. Neither of these is performing synchronous data replication, though. For more clustering, I'll refer you to Keith's blog: http://blogs.sun.com/wesolows/entry/low_availability_clusters -- Dave -- David Pacheco, Sun Microsystems Fishworks. http://blogs.sun.com/dap/ _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss