Maurice,
{ All valid points, but my last sentence is key to these issues. }
> I've been playing with AVS recently and noticed what seem to be a
> number of discrepancies and deficiencies.
>
> First, page 27 of the administration guide from April 2006, Revision
> A says
>
> During logging, the Remote Mirror software updates only the bitmaps
> at the primary site.
>
> What's it talking about? What if the underlying storage is mounted
> on the secondary? I would imagine the bitmaps are being updated on
> the site where the underlying storage is mounted, which is not
> necessarily the primary site.
>
> Second, the first thing I tried after getting replication started
> was to shut down the primary and most oddly, the secondary still has
> AVS in replicating mode! Why doesn't it automatically switch to
> logging mode? What does it think it can replicate from?
>
> Third, now if it's in logging mode, and I make changes on the
> secondary, once I put AVS into replicating mode, it immediately
> syncs in the wrong direction, erasing the changes I made on the
> secondary. Certainly, if I had made changes to the primary behind
> the scenes, it'd be right to be confused about which direction to go
> in, but here, it should be pretty obvious and yet it makes the wrong
> choice.
>
> But contrary to what the manual claims, AVS had been indeed logging
> the changes on the secondary. That's because if I try again, this
> time manually running a reverse update, the changes I made there do
> show up on the primary.
>
> Fourth, but after it completes the reverse update, AVS suddenly
> decides to change states back to replicating, except that I haven't
> as yet unmounted the pool from the secondary. Should I have? I
> didn't give it any indication that the primary was ready to take
> over again in that role. This particular action complicates
> maintaining a secondary failover system that can't summarily be
> failed back to the primary. Surely, while the primary is down, the
> secondary can also fail and there is no redundancy, but once it is
> back up, it's not always convenient to fail back immediately, so
> ideally one would want it to temporarily take on the role of
> secondary, but AVS seems to be designed always go in one direction.
>
> I have a lot of experience with analogous software on Linux, DRBD,
> and with the exception of consistency groups, it has a lot of
> intelligence relative to AVS. DRBD would have done all the right
> things here without any intervention.
>
> That AVS lacks intelligence suggests to me that it is by design. But
> what is the rationale for giving the admin the task of micromanaging
> it?
AVS is filesystem, database and application agnostic. AVS has no real
knowledge that the volumes being replicated are in use, which is why
AVS can replicate UFS, QFS, ZFS, single node Oracle, Sybase and other
Solaris supported data services.
This relationship between AVS and the data service it is replicating,
is unfortunately left to those that choose to deploy AVS. AVS is a
technology, to be used in combination with other data services, as AVS
by itself is not a solution.
>
>
>
> This message posted from opensolaris.org
> _______________________________________________
> storage-discuss mailing list
> [email protected]
> http://mail.opensolaris.org/mailman/listinfo/storage-discuss
--
Jim Dunham
Storage Platform Software Group
Sun Microsystems, Inc.
_______________________________________________
storage-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
