Transferring from homogenous Cluster

[nipun_2]

Currently I have 2 node Alpha cluster(v 7.3-1) XP 1000 and DS25(carries system disk) with common system disk (I believe that is called homogenous cluster). I am in the process of adding a 3rd node (DS25).

In future a 4th node (DS25) will be added but at that point, I am thinking of keeping one server and each satellite will have it's own system disk.

My question is does individual system disk significantly improve the performance of the system?

If I go from three node common system disk setup to individual system disk do I have to purchase additional licenses and more important is the transition acutally doable (maintaining user accounts and same accessibility)?

I understand these are vague questions but any suggestions and comments will get me a better idea.

Thanks in advance

[Jan van den Ende · Accepted solution]

Nipun,


I am thinking of keeping one server and each satellite will have it's own system disk.



My question is does individual system disk significantly improve the performance of the system?

Hardly, but it for sure does degrade the performance of system management...
The issues that can become a IO bottleneck on single system disk clusters are better dealt with separately.
If you get to the situation where the pagefiles get heavily used, you can move each pagefile to its own, preferably local attached, drive. But at todays' memory prices more memory is cheaper and much more effective.
If you have very frequent image activations from the system disk, INSTALLing is much more effective than multiple sys dsks.



If I go from three node common system disk setup to individual system disk do I have to purchase additional licenses

No, exactly the same licenses


is the transition acutally doable (maintaining user accounts and same accessibility)?

Yes, it is doable, but at the expense of extra diskdrives, more complexity, and (much) more system management effort

..

Roughly think about it this way: you will have to maintain each system disk, so more disks is more effort.
And the more system disks you have not only to keep, but to keep adjusted to each other, even extra more effort is needed.

So, unless you have VERY specific reasons, I would advise stringly against it.

Of course, should you come to adding IA64 systems, then you are forced to have at least a separate system disk per architecture.

If you ever have to run multi-system-disk clusters, then we will be in for details.


Hope this helps,
Success, whatever your choice!

Proost.

Have one on me.

Jan

[Karl Rohwedder]

I would also tend to one single system disk.
A reason for 2 system disks is, that you then can perform a rolling upgrade, where 2 systems (that booted from one disk) can remain online, while the other disk is updated.

Regarding licenses: one or more systemdisks has nothing to do with licenses, you need your VMS,cluster,... licenses.

The synchronization of useraccounts etc. is done by storing the relevant files (SYSUAF...) on a special, clusteraccessible disk.

mfg Kalle

[Jan van den Ende]

Kalle,

rolling upgrade is a phantastic thing if you want to avoid downtime!

But if you run an environment that warrants the extra effort, then having your disks shadowed is obligatory. Then the temporary extra system disk for upgrade is there already, by straightforward taking one member.

Certainly not an argument to run two system disks just for upgrade!

Proost.

Have one on me.

Jan

[nipun_2]

Thanks for the replies that was excatly what I needed to know. I can now get back to the task of clustering the system. I do have specific questions which I will post as a new thread

nipun

[Robert Gezelter]

Nipun,

Looking at the earlier replies, there is an issue that was not completely addressed.

A multi-system disk cluster is not really heterogenous. Homogeniety/Heterogeneity depends on the authorization files (e.g., SYSUAF, RIGHTSLIST, PROXY), not the location of the system disk(s). For that matter, the most common usage of "heterogenous" refers to mixed-architecture clusters, which CAN share the authorization files.

I do agree with the other contributors, that moving high activity files, such as the page file, and VERY importantly, scratch files, to local devices often yields tremendous improvements in performance. Also, while it is an advanced topic, it is possible to construct procedures that automatically clone frequently used images to the local disk, without sacrificing the conveniences of a rolling upgrade (this is not a beginner's topic, I include it to make sure that the discussion is complete).

I hope that the above is helpful.

- Bob Gezelter, http://www.rlgsc.com

[Joseph Huber_1]

I have a 8-node NI-cluster (a 9th member is VAX kept from history but effectively unused), and decided to have a local system disk on all nodes, because the cluster lives in a sea of Unix and Windows systems, and can't be concentrated behind a single router/switch because of their different locations.
It improves response-time dramatically (especially in program-development).
And it is as homogenous as any cluster with the right set of cluster-common files, and all system-produres from sylogicals to syshutdwn in a common location.
System management overhead is not really that higher. And a system update does not really happen so often :-).
No need to make system-disk backups, I always have enough working copies !

[Joseph Huber_1]

Of course all my reasons for a NI cluster do NOT apply to nipuns shared SCSI cluster: here network traffic and speed is neglectible, and I also would go for a common,shadowed system disk.

[Ian Miller.]

The answer, as always, is it depends :-)
Performance can be a reason in some situations (widely distributed cluster members for example) and running different environements is another (different architectures, vms versions, some layered products and so on). The system management overhead does increase but the key is to automate and to ensure common setups as much as possible.