On Wed, 16 Dec 2009, Andrew Deason wrote:
On Wed, Dec 16, 2009 at 3:19 PM, Richard Brittain
<[email protected]> wrote:
We have some large data volumes not backed up in any way other than
a daily replicate to a different server. The users normally access
the volume via an explicit RW mount point.
So, do you need them to actually be normal RO volumes? This sounds more
like a use case for shadow volumes, but you need to be a little careful
with those.
I initially looked at shadow volumes, but then I realized that all we were
doing fit completely within the functionality of traditional replicates.
We leave the RO mounted in a separate tree so that users can fix their own
oopses (in theory). I see how it would only make sense to try this with a
single replicate.
My question is, if I want to drain a volume of all RW volumes so I
can do kernel updates etc. without a user-visible outage, is there
any way to effectively swap the RW and RO volumes.
Something like:
Lock RW
Release to bring RO in sync
Make RW 'offline'
Promote RO to RW in the VLDB
Demote old RW to RO in the VLDB
Unlock
You can sorta do part of that with 'vos convertROtoRW', but it's not a
VLDB-only operation; you gotta change disk metadata, too. Can't convert
an RW back to an RO, though.
I could imagine a tool which took the volume offline, rewrote the
volume header, changed the VLDB entry to invert the IDs, and put it
back online. There's no such tool that I know of now.
And I think there'd be problems if you tried to use such a thing with
more than one RO.
However, once they're in sync, you might be able to vos clone the
readonly on the non-rw site to an rw, then update the vldb. i'd have
to read code/try it.
I thought something about the way we COW made cloning a bit one-way. At
the very least, the vol header would indicate the clone as a non-RW, I
think.
--
Richard Brittain, Research Computing Group,
Kiewit Computing Services, 6224 Baker/Berry Library
Dartmouth College, Hanover NH 03755
[email protected] 6-2085
