topic Re: Mirroring the system drive in Operating System - OpenVMS

Mirroring the system drive

Jorge Cocomess — Wed, 15 Aug 2007 18:16:53 GMT

Greetings,

I just realized that my system drive (sysdisk) is a JBAUD device. Is there a way to mirror this drive after the fact or I have to recreate the mirror from the getgo? My openVMS version is currently at 7.3-2 - I have multiple controllers setup to talk to this server, which they are HSG70 & HSG80.

Please provide your advice.

Thank you in advance.

Jorge

sho dev /full $10$DKA600:

Disk $10$DKA600: (Bears), device type DEC RZ1DF-CB, is online, mounted, file-
oriented device, shareable, available to cluster, error logging is enabled.

Error count 0 Operations completed 18476655
Owner process "" Owner UIC [SYSTEM]
Owner process ID 00000000 Dev Prot S:RWPL,O:RWPL,G:R,W
Reference count 868 Default buffer size 512
Current preferred CPU Id 3 Fastpath 1
Total blocks 17773524 Sectors per track 168
Total cylinders 5290 Tracks per cylinder 20
Logical Volume Size 17769177 Expansion Size Limit 18505728
Allocation class 10

Volume label "SYSDISK" Relative volume number 0
Cluster size 18 Transaction count 616
Free blocks 6986700 Maximum files allowed 467698
Extend quantity 5 Mount count 1
Mount status System Cache name "_$10$DKA600:XQPCACHE"
Extent cache size 64 Maximum blocks in extent cache 698670
File ID cache size 64 Blocks in extent cache 38502
Quota cache size 0 Maximum buffers in FCP cache 4270
Volume owner UIC [1,1] Vol Prot S:RWCD,O:RWCD,G:RWCD,W:RWCD

Volume Status: ODS-5, subject to mount verification, protected subsystems
enabled, write-through caching enabled.

Re: Mirroring the system drive

Jorge Cocomess — Wed, 15 Aug 2007 18:40:54 GMT

Sorry about douplicate posting due to internet glitch.

Jorge

Re: Mirroring the system drive

Thomas Ritter — Wed, 15 Aug 2007 19:19:27 GMT

Jorge, you change two sysgen parameters and reboot. You will end up with a single member shadow set. And it is reversible.

From our test host where sys$sysdevice is
Name Status Count Label Space Count Cnt
DSA1: Mounted 0 TEST$SYS 3.12GB 3426 1
$1$DKA0: (TEST) ShadowSetMember 0 (member of DSA1:)
$1$DKA100: (TEST) ShadowSetMember 0 (member of DSA1:)

The system parameters required are
SHADOWING 2 0 0 2 Coded-valu
SHADOW_SYS_UNIT 1 0 0 9999 Unit

Re: Mirroring the system drive

Thomas Ritter — Wed, 15 Aug 2007 19:36:23 GMT

Forgot one.
SHADOW_SYS_DISK 1

From sysgen help execute
SYS_PARAMETERS Subtopic? SHADOW_SYS_DISK

SYS_PARAMETERS

SHADOW_SYS_DISK

A SHADOW_SYS_DISK parameter value of 1 enables shadowing of the
system disk. A value of 0 disables shadowing of the system disk.
The default value is 0.

Also specify a system disk shadow set virtual unit number with
the SHADOW_SYS_UNIT system parameter, unless the desired system
disk unit number is DSA0.

To enable minimerge on a system disk, add the value 4096 to
your existing SHADOW_SYS_DISK value. For example, if you have
SHADOW_SYS_DISK set to a value of 1, change it to 4097 to enable
minimerge. Also, be sure to set the DUMPSTYLE parameter to dump
off system disk, as described in the HP OpenVMS System Manager's
Manual.

Re: Mirroring the system drive

Jorge Cocomess — Wed, 15 Aug 2007 22:52:18 GMT

Thomas,

Thanks for your response. However, this is a bit beyond me at this point. I need more step by step instructions. Otherwise, I might have to call HP support for an assistance.

Jorge

Re: Mirroring the system drive

Jon Pinkley — Wed, 15 Aug 2007 23:07:16 GMT

Jorge,

Are you intending to use controller based mirrorsets, or host based volume shadowing?

Each has advantages and disadvantages.

If host based, you will need to reboot. If you are using a quorum disk, and it is the system disk, you will have to move it to a non-HBVS disk (but it can be on a controller based mirrorset)

I have no experience with HSG80 or HSG70 (in fact I didn't know there was such a thing as a HSG70). We have an HSZ70 (SCSCI host interface) and the drives show up as DK units like the one you listed. I would expect HSG80 devices to show up like $1$DGAxxx devices on VMS.

As long as you have the HSx mirroring license on your controller, you can convert a unit from a disk device to a mirrorset using the HSOF command:

HSZ> mirror disk-name mirrorset-name

I think the disk has to have a unit associated with it. A device can be converted to a single member mirrorset while VMS has the device mounted. In one "atomic" operation, the unit is disassociated with the disk, and associated with the mirrorset, and the disk is now the only member of the mirrror set. In this respect it is much more transparent to VMS than host based shadowset are. No reboot needed, VMS version independent (as long as the HSx is supported), nothing special needs to be done when upgrading the OS, no restrictions on quorum or DOSD, etc,

After the single member mirror is there, you can set the copy policy to none (so you can specify which device you want to be paired with the original mirrorset member, chose a disk on a different port and different shelf if possible). Then set the mirrorset member=2, the set mirrorset rep=second_disk and the copy will start. The (if you have a spareset, set copy policy so it can be automatically repaired if one of the members fails).

If you were planning to use HBVS, a reboot will be required, and if it is a shared system disks, all nodes booting from it will need to have their sysgen parameters changed and they will need to be shutdown/rebooted as well.

Off the top of my head, the following steps need to be done.

1. Have VOLSHAD license loaded and node name specified with the PAK.
2. Have sysgen parameters set in "CURRENT" (non-volatile "startup" parameters) See previous note about what those sysgen parameters are. NOTE: I would recommend creating an AGEN_SHADOW_COMMON_MODPARAMS.DAT file in sys$common:[SYSEXE] and adding a line with

AGEN$INCLUDE_PARAMS SYS$COMMON:[SYSEXE]AGEN_SHADOW_COMMON_MODPARAMS.DAT

in each of your SYS$SPECIFIC:[SYSEXE]MODPARAMS.DAT files.

The on each of your nodes using the common system disk:

$ @sys$update:autogen SAVPARAMS setparams ! if you want to new feedback to be included

or

@sys$update:autogen GETDATA setparams ! if you want to use recently saved autogen feedback

Then shutdown all nodes using the common system disk using the remove_node option, and then reboot them.

Re: Mirroring the system drive

Jon Pinkley — Wed, 15 Aug 2007 23:17:20 GMT

Jorge,

If you are looking for a step by step guide, have you considered consulting the system documentation?

A summary of the required steps is in the system install/upgrade guide under upgrading a shadowed system disk.

Also Chapter 3 of HP Volume Shadowing for OpenVMS "Preparing to Use Volume Shadowing".

The above documentation is all available in PDF format from the VMS documentation site (link at bottom of OpenVMS ITRC forum page.)

If you really mean HSx controller based mirroring, then the above is irrelevant, you should be looking for the HSOF documentation.

Re: Mirroring the system drive

Jorge Cocomess — Thu, 16 Aug 2007 10:42:49 GMT

Jon,

I meant to say HSZ70 and HSG80. We do currently have shadowing license for our environment. Also, I am planning on using controller based mirrorsets.

Since I have the System disk on the DKA, therefore, I will be using DKD for my mirrorsets.

Would you be kind enough to walk me through this process?

Regards,
Jorge

Re: Mirroring the system drive

Peter Zeiszler — Thu, 16 Aug 2007 10:59:01 GMT

Since you have a VOLSHAD license I would suggest the local Shadow disk.

Then setup another disk on the HSG80 as a mirror disk. Make that Mirror become the second member of the shadow set.

Find out what shadow devices are currnently using as unit numbers
$ show dev ds

Determine which of those are NOT in use.
Making an assumption you are NOT using the DSA50 device.
$ edit sys$sysroot:[sysexe]modparams.dat
Find anything with Shad in the name. Change those lines to be these - or add these lines. Make sure there are NOT duplicate entries for these values.
SHADOW_SYS_DISK=1
SHADOW_SYS_UNIT=50

Autogen and reboot your system. Remember to schedule with you customer/users the reboot time.
$ @sys$update:autogen savparams genparams feedback

Review the values that the autogen created.
$ type/page SYS$SYSROOT:[SYSEXE]AGEN$PARAMS.REPORT

Now if everything is looking good on that report (thats where knowing your system and values come in) you will reboot the system.
$ @sys$update:autogen reboot

When the system comes up your system disk will be DSA50 if you used the values specified.
Check out the device.
$ show dev /full dsa50

On your HSG80 or HSZ70 disk controller create another disk that is the same size as your current system disk with mirror set and assign it to be DKD400. Going to assume the device is DKD400 and the control allocation number is 7 (pulling numbers out of the air).
Determine the real allocation number of your disk controller and replace it where I assumed the allocation class of 7.

Once that disk is created and visible by the system you will want to mount it as a second shadow member.

$ mount/system /shadow=($7$DKD400:) DSA50 SYSDISK SYSDISK

You can use all kinds of qualifiers with the mount statement. We normally have the statement of "mount/system/norebuild/noassist/win=30". Read up on those and find what works best for you.

Re: Mirroring the system drive

Jan van den Ende — Thu, 16 Aug 2007 11:41:28 GMT

Jorge,

Peter gave good advise.

I would make ONE amendment, however (you could have concluded it already from a previous answer)
>>>
SHADOW_SYS_DISK=1
<<<
You will surely want to eneable HBMM (HostBasedMiniMerge), so, add 4096:

SHADOW_SYS_DISK=4097

Success!

Proost.

Have one on me.

jpe

Re: Mirroring the system drive

Jan van den Ende — Thu, 16 Aug 2007 11:49:47 GMT

Jorge,

one more.

Check your current system disk cluster size.

If it is _NOT_ 8 (or a multiple, 16 is even better), then use this opportunity to INIT a disk with that cluster size.
For good measure, add /EXTENT= .
Do NOT forget /LIMIT= <1 Tbyte>
Use a generous size for /HEADRES, /DIRECTORIES, and /MAXFILES
(those cost some diskspace, but later on you can NOT increase them without a BACKUP & Restore ).

You feel it coming: do a BACKUP/IMAGE of your system disk to this new disk. DO NOT FORGET /NOINIT !!

Now, boot from the new disk, and proceed from there.

Proost.

Have one on me.

jpe

Re: Mirroring the system drive

Jon Pinkley — Thu, 16 Aug 2007 17:48:25 GMT

Jorge,

I don't understand what you mean by "Since I have the System disk on the DKA, therefore, I will be using DKD for my mirrorsets."

Controller based mirroring does not change the VMS view of the "disks". It just adds another layer of abstraction within the HSx controller between the unit (what VMS sees as a disk) and the disk on the HSx controller. VMS has no direct knowledge that the DK device is mirrored, striped, partitioned, part of RAID5 etc.; VMS just sees something that responds to SCSI commands like a disk does.

We do not use RAID5 or controller based partitioning. In my opinion, the partitioning is too limiting (there are sound engineering reasons for the limitations; all I will say is that a unit connected to a partition is less flexible than a unit connected to a disk). And RAID5 does not allow for creating snapshots by using the reduce command. And I never use the "CLONE" command; you have no control of when the split (i.e. reduce) happens.

I am going to ask some very specific questions, and need specific answers.

1. Do you have documentation for your HSZ70 and HSG80?

2. Have you at least skimmed through it?

3. In the CLI manuals, have you looked at the section describing the MIRROR command?

4. Have you looked at the example in that section?

That source is far better than you should expect to get from ITRC.

If you read that, and you have specific questions, please ask those questions, and reference what isn't clear in the documentation.

--------

Also, are you planning to use the VMS Shadowing product (HBVS) in addition to controller based mirroring? They are independent of each other, and are unaware of each other. We are currently using both at the same time, i.e. using HBVS to create VMS "virtual" devices (the DSAxxxx devices) from members that are that have controller-based redundancy (in our case, HSZ70 mirrorsets and EVA6000 vraid1 disks).

Do you have more than 1 HSZ controller pair? Where do you see the DKD (vs. DKA)

If you expect to create storage that has redundancy, and you want the copies to be on another controller that is not part of a tightly coupled controller pair, then you will need something other than the mirroring that the HSZ70 provides. The ability to create duplicate copies of data across separate controllers is HBVS's primary advantage over controller based mirroring. For example, it will allow you to have a copy on the HSZ70 and the HSG80 at the same time.

I asked about the licensing on the controller. On the HSZ40, mirroring was an extra cost option that showed up at the bottom of the

HSZ> show this_controller full

command. When I use that command on the HSZ70, it does not show any licensing info, so I assume that mirroring and raid5 were "standard" feature on at least the version of HSOF we are running.

Host Based Volume Shadowing (HBVS) requires a License PAK for VOLSHAD to be loaded on every node in the cluster that will have visibility to the DSA devices. Normally that will mean you need a license for every cluster node, and if you are planning to shadow the system disk, it is a requirement.

1. You stated you had shadowing licenses for your environment. By that do you mean you have VMS license PAKs that have VOLSHAD on them? Or did you mean that the HSZ70 and HSG80 have the ability to create mirrorsets?

2. When you enter the following command from a VMS prompt, what do you see?

$ license show volshad

3. When you enter the following command from a VMS prompt, what do you see?

$ sysman set environment/cluster
SYSMAN> do show license volshad

Every node that you want to be able to see the protected disks must have VOLSHAD loaded.

You also need to have the non-dynamic (reboot required) sysgen parameter SHADOWING set to activate shadowing at boottime.

Re: Mirroring the system drive

John Travell — Fri, 17 Aug 2007 05:00:50 GMT

Ref. the comments made about values for SHADOW_SYS_DISK, there is a comment present on my V8.3 system that appears to conflict with the prior advice.
SHADOW_SYS_DISK
...
A value of 4096 enables CI-based minimerge. ...

Most definitely CI based minimerge is not the same as HBMM.
Is this a case of the SYSGEN help files having been overlooked when HBMM support was added, or is the help correct and this bit only controls functionality for CI controllers. ?
JT:

Re: Mirroring the system drive

Volker Halle — Fri, 17 Aug 2007 05:27:46 GMT

John,

SHADOW_SYS_DISK bit 12 (decimal 4096) enables controller-based mini-merge (aka Write Logging) on a CI-based system disk (HSC/HSJ).

HBMM is controlled via SET SHADOW commands.

Volker.

Re: Mirroring the system drive

Jan van den Ende — Fri, 17 Aug 2007 06:48:48 GMT

John, Volker: Thanks!

Jorge: that means you should ignore my previous remark. Sorry to you, but at least I have learned something again.

Proost.

Have one on me.

jpe