Image save and restore of shadowed disk volume

[Robert Davidson_1]

In a few weeks we will be upgrading a shadowset to increase its size. The last time I missed a step and had to restore each directory (only 6 thankfully). I have another disk volume I can save the smaller disk structure to. What I am looking for are the commands to backup the disk and then the commands to use once the new disks are ready to be mounted back on the system.
I have looked at the backup documentation and I still have questions.
I am running open VMS7.3-2 and the disks are on fiber connected HSG80s (3). Swapping the disks is not a problem, getting the proper steps to restore the files in one step that is where I had a problem before.

thanks
bob

[Robert Gezelter]

Bob,

I am not clear on the phrasing in your post. Do you mean "increasing the size of the volume" or "changing the geometry" of the underlying disks.

Also, is the "shadowing" provided by the HSG80 or are you using the host-based volume shadowing (HBVS) component of OpenVMS.

For examples of increasing the size of the disk volumes hosting a shadow set, without interrupting system operation, I can refer you to my presentation at the 2005 HP Enterprise Technology Symposium, "Migrating OpenVMS Storage Environments without Interruption/Disruption". The slides from that presentation are at: http://www.rlgsc.com/hptechnologyforum/2005/1146.html

My recollection is that I tested these examples on OpenVMS 7.3-2.

- Bob Gezelter, http://www.rlgsc.com

[Karl Rohwedder]

The safest way to ensure integrity on the disk is to shutdown all applications and dismount the shadowset, then remount just one volume,e.g.
- dism [/cluster] dsa100
- moun/over=id dka100

DKA100 gets mounted readonly, since it was a shadowset member.
If you can ready the disks for the new shadowset, just
- mount/for dka200 ! new bigger disk
- back/image/ign=nobackup dka100: dka200:

Backup inits the disks like the sourcedisk.
You may init the disk DKA200 before mounting with 'better' characteristics (e.g. clustersize, preallocate the INDEXF.SYS...), but then you mutst do a BACKUP/IMAGE/NOINIT.

Then dismount DKA200 and create the new shadowset:
- dismount dka200
- mount/Sys dsa100 /shad=$1$dka200 label

If o.k. add the 2nd member.
regards Kalle

[Robert Gezelter]

Bob,

Upon re-reading my response, I should clarify one item.

Dissimilar device support (which is relatively recent) allows devices of different sizes to be used in the same shadowset. Dynamic volume expansion (also recent, I believe 7.3-2, but I would have to check) allows you to dynamically expand volumes.

The use of these as described in the session I referenced in my previous posting is fully supported. As I noted, it allows expansion without the need to interrupt users.

- Bob Gezelter, http://www.rlgsc.com

[Jan van den Ende]

Bob,

the answers by Bob G and Kalle are valuable, but: it requires a one-time previous INIT with appropriate params, which were only introduced in 7,2 and in a patch to 7.3-2.
My bet is, your disks were INITed earlier.

So, my prefered route would be along the lines of Kalle, BUT, make sure that this is the last time you need this detour.

- INIT (one member of) the target drive, (or possibly all members at once) with a clustersize of 16 or multiple (for SAN IO performance) or AT LEAST 8 (if you expect "many" tiny files. This also allows to set /LIMIT=(1Tb). Be a little generous on /HEADER and /MAXFILES.
- mount as a shadowset
( if you have enough drives, form the shadowset now for performance; not needed for functionality)
- do the restore /NOINIT (!!!!)

Now, if you need a bigger disk, just extend it on the SAN and
$ SET VOLUME/SIZE
If in /SIZE value given, it will assume the available size.

Alternately, (non-SAN solution) you can add a bigger member, after copy complete remove a small member and add another big one. Remove the last small one and $ SET VOLUME/SIZE.

Lo & behold: the disk has grown, all online, without any interruption. GREAT for 365 * 24 operations!

hth

Proost.

Have one on me.

jpe

[Robert Davidson_1]

Thanks for the quick replies. Now I have even more questions.

The disks are on three HSG80's, 3 physical disks on each controller and each controller being one member of the shadowset and OpenVMS is doing the shadowing. The disks were initialize on VMS 7.3 and I am not running VMS7.3-2. The 9G disks would be swaped out with 18G disks.

I did a show device on the all shadowsets and the cluster size varies from 52 to 409 and seems to be related to the size of the shadowset. The application uses Cache and on the shadowset in questions only has a few directories most with just one file and one with a very large and growing file.

Reading over the answers it sound like I might be able to dismount one member of the shadowset and swap out its phyiscal disks on the HSG80 controller and do the required controller setup and then mount this larger member as part of the shadowset and let the shadow copy put all the files on the disk. Then when that process finishes repeat the process with the other members of the shadow set until all three members have been upgraded.

Am I understanding this correctly? That would make life much easier. Also did I get the cluster size right off the show device dsa15/full command correctly?

Thanks for the quick responses and once I get this all straight in my mind I will assign points.
bob davidson

[Robert Gezelter]

Bob,

The latest post in this thread includes the comment: "The disks were initialize on VMS 7.3 and I am not running VMS7.3-2.". If this is correct you may be limited in your options.

If you are running a release of OpenVMS without the dissimilar device support in shadowing and without the dynamic volume expansion capability, you are faced with two choices:

- do without them (and do the upgrade the hard way)
- do the update to 7.3-2 (which is really a rollup of patches) to get the capabilities.

Presuming that the update of functionality cannot be done, I would do the transition in the following way:

- create a scratch mirror set on one of the HSG80 systems, it should be large enough to hold an image saveset of the shadowset volume
- shut down use of the shadowset (dismount it as a public volume; remount it as a private volume)
- do a BACKUP/IMAGE/VERIFY of the shadowset with the saveset going to the scratch mirror set
- dismount the shadowset completely
- plug the new 18gb drives into the HSG80 and do the appropriate commands to make them appear in place of the 9gb drives
- INITIALIZE the disks to create a shadow set
- do a BACKUP/INIT of the previous saveset on an image basis to the new drive (this will create all of the directoriesm etc.)
- dismount the shadowset from private use
- mount the shadowset publicly

To build confidence in the procedure, I would use the LDdrv (Logical Disk) to create a small scale mock-up and practice the evolution on it before scheduling downtime. While it will not give an information on timing, it will build confidence that the procedures are solid and increase comfort.

Second, I use the shadowset for the BACKUP on both sides to avoid the problem caused by a disk failure during this process. There is no benefit to creating a single copy, and then doing shadow copies, only a increased exposure to risk.

Third, I recommend a mirror set for the interim saveset for a similar reason: If something fails during this process, the evolution need not be aborted.

I hope that the above is helpful. If I have been unclear, or can be of assistance, please let me know.

- Bob Gezelter, http://www.rlgsc.com

[Robert Davidson_1]

Bob,
The last message should have stated I am "now" running VMS 7.3-2 and the "not" was a typo.

bob davidson

[Robert Brooks_1]

Bob wrote . . .

- do the update to 7.3-2 (which is really a rollup of patches) to get the capabilities.

---

This is a minor nit, but the notion that a dashed release is simply a rollup of patch kits is simply not true. An UPDATE kit *is* a rollup of existing patch kits (no new patches are ever included in an UPDATE kit).

There is new functionality in every dashed release. Some of it may be relatively small (new item codes for system services, for example); some of it may be large
(mini copy for shadowing in V7.2-2).

For that matter, a patch kit can have new functionality (I was quite aggressive in backporting $GETDVI item codes whenever possible).

In any event, read the release notes and new features documents for the details.

-- Rob

[Robert Gezelter]

Rob,

My apologies for the error.

Bob,

If you are running 7.3-2, then the option of online extension MAY be viable. The details would have to be checked.

- Bob Gezelter, http://www.rlgsc.com

[Robert Davidson_1]

I have checked the cluster size and it is 52 according to sho dev DSA15: /Full

If the "SET VOLUME DSA15: /LIMIT" command was never issued on the volume Can I use the SET VOLUME /SIZE command on that volume?

Can I dismount the volume and mount it privately and issue the SET VOLUME /LIMIT command without affecting the data integrity and mount the volume for system use? Then use the SET VOLUME /SIZE command later when the disks are upgraded?

bob

[Hein van den Heuvel]

I want to re-enforce Jan's suggestion of picking a cluster size being 16 or an other nice power of two. Certain SAN storage like the 'aligned' Logical IOs better, but also the XFC likes virtual IOs lined up on multiples of 16, and a nice (round :-) cluster size with help increase those odds (notably for RMS indexed files).

>> The application uses Cache and on the shadowset in questions only has a few directories most with just one file and one with a very large and growing file.

Now that's important information!

Does the Cache database benefit from an occasion 'refresh'. You may want to take the downtime opportunity to (oracle terms) export the DB, create fresh, and import instead of a file copy. Check with cache
documentation/support. Be sure you DBA's know you are about to do this and perhpas exploit the opportunity.


18GB is not that much these days. And the HSG can to more than just present disks. Does the DB span multiple drives? You may want to STRIPE those (since you already to HBS) instead of presenting individually in order to balance IO more easily.

The large DB file plus large other file input would make me lean toward real big cluster sizes: 512 ? 768 ? 1024?

>> did a show device on the all shadowsets and the cluster size varies from 52 to 409 and seems to be related to the size of the shadowset

The default is (and the minimum for alder systems) is the disk size divided by a million (1024*1024) as BITMAP.SYS was limited to 256 block of 4096 bits (8*512) each. The volume expansion folks talk about drops this limitation.

Hope this helps some,
Hein van den Heuvel (at gmail dot com)
HvdH Performance Consulting

[Jan van den Ende]

Bob,

to get back to Hein's remarks on cluster size.

For the moment (and foreseeable future), max IO transfer size is 127 blocks. SAN's _REALLY_ prefer 16-block chunks, which together allow for 112 as blocking unit.
So if you wanna go big cluster size (like Hein said, that IS indicated here!) please choose a multiple of 112. (and mostly for gut-feeling, and some back-view experiences I would choose a power of 2 as "multiple")

Proost.

Have one on me.

jpe

[Jan van den Ende]

Bob,

re-reading the whole thread in one pass has raised some questions.

Do you need/intend to grow your SYSTEM disk of your Cache DATA disk? (or might the Cache data be _ON_ the system disk? I hope not.)

Really, for the SYSTEM disk I would go for a cluster size not bigger than 16 (I would even consider 8, but that is open for discussion).

Depending on the possibility of scheduled downtime, a straightforward INIT with the desired qualifiers for the new target drive(s), followed by a BACKUP/IMAGE/NOINIT.

If downtime is difficult to schedule, it is somewhat more complicated, but it can be done: we did it that way.

Supply more detail, and you will get more detailed help.

Proost.

Have one on me.

jpe

[Robert Gezelter]

Bob,

Hein brings up a good point, one that I alluded to earlier, but probably got lost amid the larger issues.

Just switching to larger disks addresses the size/capacity issue, but a review of all of the parameters is likely in order. The HSG80 can do many things besides just present disk "bricks", and those capabilities, together with proper selection of file system parameters (e.g., cluster size) make a significant difference in determining achievable performance).

The presentation I cited previously about transitioning storage without interruption/disruption implicitly assumes that these questions have been addressed at some point. If they have not been addressed (or recently reviewed), then this represents an opportunity to address this issue. Some transitions, as I did point out in the talk, do need to be addressed during an interruption, which is regrettable but necessary. The more appropriate goal is extracting the greatest benefit from each unavoidable downtime.

A performance review of the system may also be in order, to provide input and documentation for these changes. As I am sure both Hein and myself have seen in our consulting practices, such reviews can yield dramatic increases in performance.

- Bob Gezelter, http://www.rlgsc.com

[Hoff]

General thoughts...

Disk cluster size of 16 blocks, or a multiple of 16, for all disk initializations going forward. (This per the the OpenVMS Storage I/O Team Leader's recommendations. This for several reasons, including aligned transfer performance. Disks are also headed toward 4KB sectors. At the disk level, geometry is basically synthetic.)

Enable dynamic volume expansion (DVE) and DDS dissimilar device shadowing (DDS).

I'd start toward replacing the HSG80 controllers with another and newer controller. I'd look at the MSA series or a low-end EVA. The HSG80 iron is several generations back, and comparatively slow.

I'd be looking at V8.3 with ECOs. That will likely be eligible for CVS or PVS through 2011 or so, based on current HP practices and the current roadmap. V7 to V8 is not a major upgrade on OpenVMS Alpha.

I'd also tend to initialize the disks with a /GPT, if you're on V8 and have any potential to move over to Integrity servers.

Here's a Disk Initialization article:
http://64.223.189.234/node/193

Stephen Hoffman
HoffmanLabs LLC