mounting hard drive on cluster

[nipun_2]

Hello all,

I have clustered a 3rnd node as a satellite to 2 node cluster over ethernet lan. It is a common environment with V7.3-1, Lancp and Decenet Plus.

Currently I see that the new node clustered (SIZZLE) has in reality two hard drives

dka0 and dka100.
dka0: Also contains V7.3-2 that it uses for standalone boot
dka100: Is where I would backup the above system.


Question 1:
When I am logging in the node (when clustered) and I give show mounted device I only see
dka0 with volume label sizzle_XXXX
and I don't see dka100 Why?

Question 2:
I would like to know if it would safe if I give

$mount /cluster sizzle_xxxx logical name

If the above will mount ONLY the volum sizzle_xxxx does that mean that the area where V7.3-2 is located is not affected. Basically how does it handle the disk usage.

Question 3:
What happens in case of dka100:

How does it handle the already backed up v7.3-2 as a foreign volume?

[Ian Miller.]

Q1 - DKA100 is present but not mounted so does not show in SHOW DEV/MOUNT because you only asked for mounted disks.

Q2 if you mounted dka0 cluster wide then all the nodes have access to that disk as if it is local and according to the access rights each user has.

Q3 - DKA100 won't be touched unless you mount it or ran a program that accesses unmounted drives e.g INITIALZE. What do you mean about a foreign volume?

[nipun_2]

Hi Ian,
Thanks for the reply

My basic objective for mounting dka0 and dka100 is that
1) I can add more hard drive space to the current cluster

2) Not overwrite on the system files of V 7.3-2 on dka0 and backed up copy on dka100:

I have read and planning to implement the following (this is from V7.3-2 installation manual).


# Mount the system disk and the target device on which you will make the backup copy. For example, if your system disk is on DKA0: and the target device is on DKA100:, you might use the following commands. The /OVERRIDE qualifier used in this example allows you to mount the system disk without typing its volume label. The /FOREIGN qualifier is required for the target disk when using the BACKUP /IMAGE command.

$ MOUNT /OVERRIDE=IDENTIFICATION DKA0:
$ MOUNT /FOREIGN DKA100:

# Enter the BACKUP command to back up the system disk to the target device. For example, if your system disk is on DKA0: and your target disk is on DKA100:, you might use the following command:

$ BACKUP /IMAGE DKA0: DKA100:



After the above, I plan to then boot the EV68(SIZZLE) as the clustered node and then mount the disks for all clusters

[Robert Atkinson · Accepted solution]

Moving the system disk from DKA0 to DKA100 seems fine. I assume DKA0 is a larger disk than DKA100.

A couple of points to note. Is order to serve DKA0 out to the rest of the cluster members, you need to have SYSGEN parameters set.

MSCP_LOAD should be set to 1
MSCP_SERVE_ALL should be set to 2 (Serve all local, non-HSxx disks)

If you have any other locally attached disks in the cluster with an ID of DKA0, there will be a clash and you won't be able to see your other disk from that node. You'll have to rename one of them to a cluster-unique ID.

Also, if you shut down the node serving the disk, the other nodes will no longer be able to see it. This may impact on your production environment, so you should think carefully about what data you put on the disk.

Robert.

[Jan van den Ende]

Nipun,

yes, you can quite easily make a copy of any disk, and then use them each independantly.

First, since in your cluster you have disks with the same name ( eg, DKA0 ), you should make them unique.
You can do that by putting $ in front of it, or, preferably, by giving each node a unique ALLOCLASS, Then the device name gets $$ prepended.

You should have the input disk mounted, and the output disk mounted/foreign

$ BACKUP/IMAGE : :

Before you can mount those drives /SYSTEM or /CLUSTER, you should make sure they have unique labels.

$ MOUNT SIZZLE$DKA100: /OVERRIDE=ID
$ SET VOLUME SIZZLE$DKA100: /LABEL=
$ DISM SIZZLE$DKA100:
$ MOUNT/CLUSTER SIZZLE$DKA100:

Now you can access the disk from any node, just like any data disk.

Note: Even if SIZZLE$DKA0: (and now DKA100:)
contain the DATA that allows it to be a system disk, if you did not BOOT of those disks, they are _NOW_ not system disks!
But as long as you do not ruin their structure, the WILL remain able to FUNCTION as system disk!

Success.

Proost.

Have one on me.

Jan