Thank you for the detailed explanation. It is very helpful to understand the issue. Is anyone successfully using SNDR with ZFS yet?
Best Regards, Jason On 1/26/07, Jim Dunham <[EMAIL PROTECTED]> wrote:
Jason J. W. Williams wrote: > Could the replication engine eventually be integrated more tightly > with ZFS? Not it in the present form. The architecture and implementation of Availability Suite is driven off block-based replication at the device level (/dev/rdsk/...), something that allows the product to replicate any Solaris file system, database, etc., without any knowledge of what it is actually replicating. To pursue ZFS replication in the manner of Availability Suite, one needs to see what replication looks like from an abstract point of view. So simplistically, remote replication is like the letter 'h', where the left side of the letter is the complete I/O path on the primary node, the horizontal part of the letter is the remote replication network link, and the right side of the letter is only the bottom half of the complete I/O path on the secondary node. Next ZFS would have to have its functional I/O path split into two halves, a top and bottom piece. Next we configure replication, the letter 'h', between two given nodes, running both a top and bottom piece of ZFS on the source node, and just the bottom half of ZFS on the secondary node. Today, the SNDR component of Availability Suite works like the letter 'h' today, where we split the Solaris I/O stack into a top and bottom half. The top half is that software (file system, database or application I/O) that directs its I/Os to the bottom half (raw device, volume manager or block device). So all that needs to be done is to design and build a new variant of the letter 'h', and find the place to separate ZFS into two pieces. - Jim Dunham > > That would be slick alternative to send/recv. > > Best Regards, > Jason > > On 1/26/07, Jim Dunham <[EMAIL PROTECTED]> wrote: >> Project Overview: >> >> I propose the creation of a project on opensolaris.org, to bring to >> the community two Solaris host-based data services; namely volume >> snapshot and volume replication. These two data services exist today >> as the Sun StorageTek Availability Suite, a Solaris 8, 9 & 10, >> unbundled product set, consisting of Instant Image (II) and Network >> Data Replicator (SNDR). >> >> Project Description: >> >> Although Availability Suite is typically known as just two data >> services (II & SNDR), there is an underlying Solaris I/O filter >> driver framework which supports these two data services. This >> framework provides the means to stack one or more block-based, pseudo >> device drivers on to any pre-provisioned cb_ops structure, [ >> http://www.opensolaris.org/os/article/2005-03-31_inside_opensolaris__solaris_driver_programming/#datastructs >> ], thereby shunting all cb_ops I/O into the top of a developed filter >> driver, (for driver specific processing), then out the bottom of this >> filter driver, back into the original cb_ops entry points. >> >> Availability Suite was developed to interpose itself on the I/O stack >> of a block device, providing a filter driver framework with the means >> to intercept any I/O originating from an upstream file system, >> database or application layer I/O. This framework provided the means >> for Availability Suite to support snapshot and remote replication >> data services for UFS, QFS, VxFS, and more recently the ZFS file >> system, plus various databases like Oracle, Sybase and PostgreSQL, >> and also application I/Os. By providing a filter driver at this point >> in the Solaris I/O stack, it allows for any number of data services >> to be implemented, without regard to the underlying block storage >> that they will be configured on. Today, as a snapshot and/or >> replication solution, the framework allows both the source and >> destination block storage device to not only differ in physical >> characteristics (DAS, Fibre Channel, iSCSI, etc.), but also logical >> characteristics such as in RAID type, volume managed storage (i.e., >> SVM, VxVM), lofi, zvols, even ram disks. >> >> Community Involvement: >> >> By providing this filter-driver framework, two working filter drivers >> (II & SNDR), and an extensive collection of supporting software and >> utilities, it is envisioned that those individuals and companies that >> adopt OpenSolaris as a viable storage platform, will also utilize and >> enhance the existing II & SNDR data services, plus have offered to >> them the means in which to develop their own block-based filter >> driver(s), further enhancing the use and adoption on OpenSolaris. >> >> A very timely example that is very applicable to Availability Suite >> and the OpenSolaris community, is the recent announcement of the >> Project Proposal: lofi [ compression & encryption ] - >> http://www.opensolaris.org/jive/click.jspa&messageID=26841. By >> leveraging both the Availability Suite and the lofi OpenSolaris >> projects, it would be highly probable to not only offer compression & >> encryption to lofi devices (as already proposed), but by collectively >> leveraging these two project, creating the means to support file >> systems, databases and applications, across all block-based storage >> devices. >> >> Since Availability Suite has strong technical ties to storage, please >> look for email discussion for this project at: <storage-discuss at >> opensolaris dot org> >> >> A complete set of Availability Suite administration guides can be >> found at: http://docs.sun.com/app/docs?p=coll%2FAVS4.0 >> >> >> Project Lead: >> >> Jim Dunham http://www.opensolaris.org/viewProfile.jspa?username=jdunham >> >> Availability Suite - New Solaris Storage Group >> >> >> 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
