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

Reply via email to