Mirroring the system drive

[Jan van den Ende]

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

[Jon Pinkley]

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.

[John Travell]

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:

[Volker Halle]

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.

[Jan van den Ende]

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