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
