Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

MOUNTING A RAM DISK IN A CLUSTER

 
SOLVED
Go to solution
P Muralidhar Kini
Honored Contributor

Re: MOUNTING A RAM DISK IN A CLUSTER

Hi Ana,

>> If I'd change the ALLOCLASS parameter with a different value in
>> each node (for example, 1, 2, 3 and 4, respectively), would this
>> change have any effect on the SAN disks shared among them that
>> are referred to as $1$DGAxxx?
Thats a good point.

When you have a set of disks, Allocation class is the unique ID for
one or more disks that support multiple paths.

You will find a good documentation about this at -
http://labs.hoffmanlabs.com/node/349

You are using a SAN shared disk and hence, all the nodes should be using the
same Allocation class because all of them refer to the same device.
Also as Dave has pointed out, for SAN shared disks, its recommended to have
the allocation class value set to of 1. You need to keep the Allocation Class
value as it is on all nodes in the cluster.

You can try out the RAMDISK commands that i had given (with the /SERVE
qualifier) and let us know how that goes.

Good luck.

Regards,
Murali
Let There Be Rock - AC/DC
Richard Brodie_1
Honored Contributor

Re: MOUNTING A RAM DISK IN A CLUSTER

Murali, as Dave said already, the allocation class for SAN disks is always 1, regardless of the setting of ALLOCLASS.

This means that you can safely set the ALLOCLASS parameter to 10,20,30,40 etc. This means that local devices, such as RAM disks will have unique names, without affecting the names of SAN devices.



Hoff
Honored Contributor

Re: MOUNTING A RAM DISK IN A CLUSTER

Short answer: this looks to be an incorrect allocation class configuration. And bad allocation class configurations can lead to pain and corruptions.

I wouldn't expect the hosts here to be in the same allocation class as the disks and tapes out on the SAN controller(s), and I wouldn't tend to configure hosts into the same allocation class as any other hosts or any storage unless those hosts shared local shared storage; shared SCSI, for instance. And maybe not then.

Given the better flexibility provided, I'd look to use port or disk allocation classes or (where available) controller-level allocation classes, and would tend to reserve the big-hammer host allocation class setting for those cases where most or all of the associated disk and tape devices are shared with another host.

The FC SAN stuff co-opts both $1$ and $2$, which means that sites will usually have the host and port or disk allocation classes in some other allocation class.

Given host-based volume shadowing (HBVS), allocation class zero isn't permissible; HBVS member volumes need to have non-zero allocation classes.

To put this another way, having the hosts in $1$ here looks to be problematic, and it also looks that there are multiple different disks all representing themselves as $1$MDA0:. Contrary to what the HP replies here Neither case would be recommend.

P Muralidhar Kini
Honored Contributor

Re: MOUNTING A RAM DISK IN A CLUSTER

Richard,
>> as Dave said already, the allocation class for SAN disks is always 1,
>> regardless of the setting of ALLOCLASS.
Thanks for this information. Now this thing is clear to me.
(I should have paid attention to the $1$... disk on my test system with
ALLOCLASS of 8)

Ana,
The SAN shared disk will always show up as $1$.... even if the ALLOCLASS
is set to a different value. Also when using the ALLOCLASS, its better to
have ALLOCLASS set to a value other than 1 so that the value of 1 always
represents a SAN shared disk.

Hence the ALLOCLASS parameter that is set to 1 on all nodes is definitely not
recommeneded as it can lead to corruptions. If Node1 has a its DKA0 and
Node2 has its DKA0, both would appear as $1$DKA0 because the value of
ALLOCLASS SYSGEN parameter is 1 on both the nodes.

You have to change the value of ALLOCLASS parameter so that every node has
a unique value.

To change the ALLOCLASS parameter -
$MC SYSGEN
SYSGEN>USE CURRENT
SYSGEN>SET ALLOCLASS 10 !Give a value
SYSGEN>WRITE CURRENT
SYSGEN>EXIT

Note that once the ALLOCLASS SYSGEN parameter is changed, you need to
reboot all the nodes in the cluster so that all the other nodes are aware of it.

You need to use the above set of commands to change the value of
ALLOCLASS sysgen parameter on all nodes of the cluster.

Regards,
Murali
Let There Be Rock - AC/DC
Volker Halle
Honored Contributor

Re: MOUNTING A RAM DISK IN A CLUSTER

Murali,

when suggesting system parameters changes with SYSMAN/SYSGEN (like ALLOCLASS in your previous reply), do not forget to advise also changing the parameter value in MODPARAMS.DAT ! Otherwise you're up for a big surprise after the reboot after the next AUTOGEN.

Volker.
P Muralidhar Kini
Honored Contributor

Re: MOUNTING A RAM DISK IN A CLUSTER

Volker,

>> when suggesting system parameters changes with SYSMAN/SYSGEN (like
>> ALLOCLASS in your previous reply), do not forget to advise also
>> changing the parameter value in MODPARAMS.DAT
Thats a very good point.

SYSGEN would change the file ALPHAVMSSYS.PAR (Alpha) and
IA64VMSSYS.PAR (Integrity). Whereas AUTOGEN would use the MODPARAMS.DAT file.

Hence as you said, if any parameter is modified using SYSGEN/SYSMAN then
one has to add entries for the modified parameter to MODPARAMS.DAT file.
This would preseve the value of the modified parameter in case a AUTOGEN
is run and system reboots.

Thanks for this information.

Regards,
Murali
Let There Be Rock - AC/DC
Ana M. García Olivencia
Regular Advisor

Re: MOUNTING A RAM DISK IN A CLUSTER

Hi all.

Thanks all for the valuable information that has clarified me some doubts I had about ALLOCLASS parameter in the SAN environment (although it wasn't the main topic of this note).

Fortunately, my cluster is not still at production level so I can change the parameters. I'll give NODE1, 2, 3 and 4 the ALLOCLASS values 10, 20, 30 and 40, respectively. I'll reboot the four nodes and I'll create a decram device with the command and attributes you advised me, and I'll let you know.

Thanks again.

Ana