AVS depends on strict procedure to work. it does not let you do whatever comes in mind (such as what you are doing) because if doing the wrong thing during a disaster, then you end up loosing your data. hence procedures must surround any actions an operator might do, while preventing the same operator from doing stupid actions (such as replicating the wrong side)..AVS is not a toy for admin/operators that like to type quickly what comes in mind, but it forces one to follow a strict procedure of actions. from your description, DRDB seems very flexible, but flexibility is not what you want in the event of a disaster..you want strict controlled procedures
s. On Sun, Aug 10, 2008 at 1:58 AM, Maurice Volaski <[EMAIL PROTECTED]>wrote: > >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. > > I'm not sure how your points relate to the points I'm raising. For > example, DRBD is also filesystem, database and application agnostic. > In fact, DRBD depends on that design to replicate any block-based > Linux filesystem, even ZFS running on Linux FUSE. > > DRBD does have knowledge that the volumes being replicated are in > use. It sits under the filesystem so that it can intercept I/O and > redirect it to other system and vice versa if the primary system has > failed. > > AVS seems to have this ability as well according to page 60 of the > administration guide, which describes its ability to substitute the > secondary's volumes for the primary one, so it must have this > knowledge as well. > > >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. > > I don't see what an admin could do to control its behavior. What > facility can make it change the designation of primary and secondary > on the fly? This is trivial to do in DRBD. In fact, high availability > in Linux essentially depends on it. > > To me, the real difference was the conscious, design decision to have > AVS rigged to consider the primary and secondary as fixed > designations and to assume that admins will always want replication > in one direction. Perhaps, in the future, you'll consider > reevaluating this approach. > > That being said, I'm wondering whether I've identified three bugs in > AVS. It doesn't make sense to me in any circumstance that turning on > autosync on the primary should not be a state shared by the > secondary, that it must be turned on both systems, and that switching > to logging mode should cause the state of autosync to be misreported > as off (it can't, of course, autosync in this mode, but that's an > action [autosynchronizing], not a property) or that the output of > dsstat on the two systems should ever disagree. > -- > > Maurice Volaski, [EMAIL PROTECTED] > Computing Support, Rose F. Kennedy Center > Albert Einstein College of Medicine of Yeshiva University > _______________________________________________ > storage-discuss mailing list > [email protected] > http://mail.opensolaris.org/mailman/listinfo/storage-discuss > -- ------------------------------------------------------ Blog: http://fakoli.blogspot.com/
_______________________________________________ storage-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/storage-discuss
