MOUNTING A RAM DISK IN A CLUSTER

[Ana M. García Olivencia]

Hi all.

Openvms V8.3-1H1.

I have a cluster with four nodes. I have defined a ram disk in one of them following the recommendations given in the manual:
NODE1 $ MC SYSMAN
SYSMAN> IO CONNECT MDA0:/DRIVER=SYS$MDDRIVER/NOADAPTER
NODE1 $ INIT $1$MDA0: RAMDISK/SIZE=90000/STRUC=5
NODE1 $ MOUNT/CLUSTER $1$MDA0: RAMDISK

Now I have:

NODE1 $ SHOW DEV MD
Device Device Error Volume Free Trans Mnt
Name Status Count Label Space Count Cnt
$1$MDA0: (NODE1) Mounted 2 RAMDISK 97.42MB 1 1

In the second node I have connected the device:

NODE2 $ MC SYSMAN
IO CONNECT MDA0:/DRIVER=SYS$MDDRIVER/NOADAPTER
NODE2 $ SHOW DEV MD
Device Device Error Volume Free Trans Mnt
Name Status Count Label Space Count Cnt
$1$MDA0: (NODE2) Mounted 0 (remote mount) 1

If I try to cluster mount this device in the second node I get the following error:

NODE2 $ MOUNT/CLUSTER $1$MDA0: RAMDISK
%MOUNT-F-FORMAT, invalid media format

I have found this error reported and it seems that one of the possible solutions would be to increase the S2_SIZE parameter to the ram disk size. I have increased from 0 to 500M (five times the disk size), rebooted and the same error message.


Is the process I am following correct?.

Another question: Is it really necessary a license to create and use a ram disk with this operating system version?. I have seen reported that it's necessary but I have no license and I've been able to create and use a ram disk in a standalone node.

Thank you very much in advance.

Regards.

Ana

[P Muralidhar Kini · Accepted solution]

Hi Ana,

>> Is the process I am following correct?.
The following set of commands is what i use when trying to use a RAMDISK cluster-wide

You have to use the /SERVE qualifier when creating a RAMDISK.
This way RAMDISK created on one node will be visible to another node.

Node1 - Create a RAMDISK
-----
NODE1>>mc mdmanager create disk mdb90/capacity=1000/serve
NODE1>>init MDB90 RAMDISK
NODE1>>mount MDB90 RAMDISK
%MOUNT-I-MOUNTED, RAMDISK mounted on _$7$MDB90: (NODE1)
NODE1>>

Note: The /SERVE qualifier would make the RAMDISK device MDB90 to be
visible on the other node.

Node2 - Use RAMDISK created on Node1
-----
NODE2>>show dev mdb

Device Device Error Volume Free Trans Mnt
Name Status Count Label Blocks Count Cnt
$7$MDB90: (NODE1) Mounted alloc 0 (remote mount) 1
NODE2>>
NODE2>>mount/system $7$MDB90: RAMDISK
%MOUNT-I-MOUNTED, RAMDISK mounted on _$7$MDB90: (NODE2)
NODE2>>

In your case, the problem is not because of the S2_SIZE size but rather looks
like with the procedure used to create a RAMDISK.

In the procedure that you have used, have you created the RAMDISK MDA0:
with /SERVE qualifier ?

>> MC SYSMAN IO CONNECT MDA0:/DRIVER=SYS$MDDRIVER/NOADAPTER
I dont think this will make Node2 to use the same MDA0 device that was
created on Node1. Node2 is trying to use a different MDA0 device and hence is
failing.

Hope this helps.

Regards,
Murali

[Shriniketan Bhagwat]

Hi Ana,

I basically use below commands to create the ram disks.

$ decram :== $sys$system:mdmanager.exe
$ IF .NOT. F$GETDVI("MDA0:","EXISTS") THEN decram create disk mda0/capacity=zzz
$ IF .NOT. F$GETDVI("MDA1:","EXISTS") THEN decram create disk mda1/capacity=zzz
$ IF .NOT. F$GETDVI("MDA2:","EXISTS") THEN decram create disk mda2/capacity=zzz


Regards,
Ketan

[Volker Halle]

Ana,

regarding licensing:

from an answer by Guy P. in comp.os.vms:

Starting with V8.2 DECRAM is shipping as part as the base O/S Just install VMS, have a valid license (either DECRAM or EOE)
and you should be set.


Volker.

[P Muralidhar Kini]

Hi Ana,

From the output you have provided -
Node1 is referring to $1$MDA0: device on NODE1.
Node2 is referring to $1$MDA0: device on NODE2.

i.e. Both the nodes are reffering to different devices.

Node1
-----
NODE1 $ SHOW DEV MD
...
$1$MDA0: (NODE1) Mounted 2 RAMDISK 97.42MB 1 1
...
NODE1 $

Node2
-----
NODE2 $ SHOW DEV MD
...
$1$MDA0: (NODE2) Mounted 0 (remote mount) 1
...
NODE2 $

But then intrestingly the allocation class of the devices on Node1 and Node2
are both same i.e. 1. Is it that the two nodes are having the same allocation class ??

Provide the output of the following command from both Node1 and Node2
$MC SYSGEN SHOW ALLOCLASS

Note that each node in the cluster should have different values of allocation
class so that each device on a every node is unique through out the cluster.

Hope this helps.

Regards,
Murali

[Ana M. García Olivencia]

Thanks all for your answers.

>>>In the procedure that you have used, have >>>you created the RAMDISK MDA0:
>>>with /SERVE qualifier ?

No, I haven't used the /SERVE qualifier. Through the procedure I have used (SYSMAN IO CONNECT) there was no /SERVE option or similar.

>>>Provide the output of the following >>>command from both Node1 and Node2
>>>$MC SYSGEN SHOW ALLOCLASS

ALLOCLASS=1 , the same for the four nodes.

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?

As soon as I can test your proposals I'll let you know.

Thanks.

Ana

[Volker Halle]

Ana,

couldn't you also use different MDA device names (like MDA1:) to allow the RAM-disks on the different nodes to get cluster-wide unique devices names ?

Also note that the others seem to have used MDMANAGER commands to create DECRAM disk devices. Please consider to have a look at the DECRAM documentation.

Volker.

[The Brit]

Ana,
I would avoid using ALLOCLASS values 1,2,3,... "1" is used for SAN volumes, "2" is used for SAN Tapedrives and Libraries, etc.

I suggest you use 10, 20, 30, etc. for individual nodes,

Dave.

[Bhadresh]

Hi Ana,

>> No, I haven't used the /SERVE qualifier. Through the procedure I have used (SYSMAN IO CONNECT) there was no /SERVE option or similar.

/SERVE Qualifier is used for whether or not disk serving is enabled for the cluster system.

Once /SERVE Qualifier is used it cannot be selected as /NOSERVE. For cluster wide mount you need to create the DECram disk using /SERVE qualifier.

For more details have a look at DECram userâ s manual:

http://h71000.www7.hp.com/doc/731final/documentation/pdf/decram_v31_users_gd.pdf

Regards,
Bhadresh

[P Muralidhar Kini]

Hi Ana,

>> No, I haven't used the /SERVE qualifier. Through the procedure I have used
>> (SYSMAN IO CONNECT) there was no /SERVE option or similar.
If you want to use a DECRAM device cluster-wide then you have use the
/SERVE qualifier when you are creating the DECRAM device.

For more information about the /SERVE qualifier, refer the DCL help
COEREF>>mc mdmanager
DECRAM> help create disk/serve
CREATE

DISK

/SERVE

/[no]SERVE

This qualifier is not required and defaults to /NOSERVE. It
controls whether or not disk serving is available for the
VMSCluster. When /SERVE is selected, the disk is MSCP
served. Once a disk is selected /SERVE it cannot be selected
/NOSERVE.

Note that /nopersist and /serve are mutually exclusive. Also
note that served device numbers cannot exceed 9999.


If you want to use the DECRAM device in a cluster environment then you can
use the example given in my previous response. That should solve your problem.

Regards,
Murali

[P Muralidhar Kini]

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

[Richard Brodie_1]

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]

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]

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

[Volker Halle]

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]

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

[Ana M. García Olivencia]

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