Multiple snapshot problem.

[Stuart Remphrey - Sun Computer Systems SE - QLD Australia]

Richard et al,

Sorry to push a product on this alias (even if it is a Sun one :-)
but you might want to have a look at Solaris Instant Image,
announced yesterday.  It's independent of Volume Mgr, from memory:

Allows more flexible snapshots, including between different
disk groups, refresh in either direction, both copies are
read/write, either full independent copies which both have
all the data or dependent copies where the copy only contains
the original values of the changed blocks, and defers to the
master for unchanged blocks (the latter can't be moved to
another host system though, and if when the former is moved
you do lose the fast refresh option as you lose bitmap sync).

It may meet your need, saves mucking around with multiple
snapshot volumes and/or disassembling diskgroups etc.

No idea what it costs in your part of the world though;
licensing is based on system size (<E3000, E3000-E5500,
E6x00, E1000; I can't get to the announcement at the moment).

As to your original question, I haven't played with multiple
snapshots to know which gets chosen when etc.  [Mike??]

Stuart.



` Please use a fixed-width font to read this.
` 
` Three independent systems, abc, def, ghi, which have local file systems
` abc1, def1, ghi1 - these contain Ingres databases. System def is connected
` to the SSA of abc and the A5200 of ghi, which each contain sufficient extra
` disks to mirror def's local file system def1:
` 
`            abc                   ---def---                   ghi
`           /  \        .---------'  /  \   '----------.        |
`          /    \      /            /    \              \       |
`  +------+     +------+     +------+     +------+       +------+------+
`  | Root=========Root |     | Root=========Root |       | Root===Root |
`  |      |     |      |     |      |     |      |       |             |
`  | abc1=========abc1 |  =====def1=========def1=====    | ghi1===ghi1 |
`  |      |     |      | //  |      |     |      |  \\   |             |
`  |      |     | def1====   | def2=========def2 |   ======def1        |
`  +------+     +------+     +------+     +------+       |             |
`    SSA          SSA          SSA          SSA          | def1===def1 |
`                                                        +------+------+
`                                                             A5200
` 
` The aim of our procedure is to copy and transfer def1 onto abc and ghi
` for read access. The picture above shows the situation at transfer
` time. The == denote mirrors or snapshots (N.B. UFS). def1 on ghi exists
` as a mirrored volume for about 23hrs 59 mins of the day. def1 on abc
` exists for about 22 1/2 hours of each day - in the picture, it belongs
` to def.
` 
` So:
` 
` At transfer time, the disks  which comprise the snapshot plex of def1
` and are on abc'c SSA are snapshotted and transferred to the control of
` abc, where they are mounted and used. At a certain time the disks go
` back to def for snapstart.
` 
` Just after, the snapshot plex of def1 on the A5200 of ghi is snapshotted,
` and control of these disks is passed to ghi; the database server running
` on the already existing volume of def1 is stopped, the existing volume
` sidelined, the new snapshot is mounted, and the database server started.
` The old mirrors of def1 on ghi are then used to mirror the new snapshot
` volume of def1; when that operation is finished, the snapshot disks are
` removed again and "sent back" to system def for snapstart.
` 
` But:
` 
` There is a problem. def1 runs with two mirrors and two snapshots. At
` snapshot time, sometimes the procedure that transfers the disks between
` def and ghi grabs the snapshot destined for abc, and breaks. The procedure
` that transfers the snapshot between def and abc then can't access its
` disks, and breaks as well.
` 
` Is it possible to predict which snapshot plex will be taken by a snapshot
` where there are multiple snapshots on a volume? It seems to be first in,
` first out, but something still goes awry! Could this be because of the
` difference in disks? The SSAs use 4.2GB drives (10 per plex), the A5200
` uses 9GB drives (five per mirror/snapshot of def1).
` 
` 
` I'm testing on an old SSA on a single system with a mixture of disks, but
` any ideas will be welcome.
` 
` 
` Richard.
` -- 
` The Open University is not responsible for content herein, which may
` be incorrect and is used at reader's own risk.



---------------------------------------------------------------------
 ,-_|\  Sun Microsystems Australia  Stuart Remphrey, Systems Engineer
/     # P.O. Box 86, Albert St    stuart.remphrey@Aus.Sun.COM x.56308
\_,-\_/ Level 10, 80 Albert St   Ph (07) 3238 8308 Fax (07) 3238 8320
     v  Brisbane  QLD  4002       +61 7  3238 8308   +61 7  3238 8320
---------------------------------------------------------------------