About expanding system disk

[Lionel Liu]

Hello

We have two nodes cluster system, system disk dkc106 and dkd106 are shadowed. Because there are not enough free space left. we have two new disks dkc107 and dkd107, we are going to copy image from dkc106 to dkc107, boot up system from dkc107 and shadowed dkd107 back.

when system boot up from the new system disk, I remember that we have to run tcpip and decnet reconfiguration even without change any paramter. but I am not quite sure.

we don't want to change any tcpip and decnet parameter, do we have to run tcpip and decnet configuration script?

if we have to run, how can we keep all tcpip and decnet parameter unchanged?

Thanks in advance

Lionel

[Steven Schweda]

> [...] do we have to run tcpip and decnet
> configuration script?

I don't think so. I can't see why you would.

On simpler (non-clustered, non-shadowed)
systems, I've certainly replaced a system
disk without touching anything in the
configuration. I just did it in October on
my main XP1000 Alpha system.

[Hein van den Heuvel]

What OpenVMS version? (and to a lesser extend, what system).

Shadow dis-similar device + dynamic volume expansion may enable you to do this without any downtime.

And in any case, there should be no dependence for network configs and startup scripts at all unless someone did something silly with physical names for files/devices instead of logical names.

You can potential have dkc106 joins the shadowset, drop dkc106 when done, then join dkd107 and when that's done merging drop dkc107. When all is quiet again, you have an image for a small disk on a big disk.
Now grow the volume!
Hopefully things like maxfiles are adequat.

Our friend Bob Gezelter has presented the above scheme at the HP Tech Forum in Las Vegas, back in June (amongst others).

For his detailed presentation (and his contact info) check out:
http://www.rlgsc.com/hptechnologyforum/2007/1512.html

hth,
Hein.

[Robert Gezelter · Accepted solution]

Hein,

Thank you, the reference to my presentation is appreciated!

Lionel,

There should be no reason to do any reconfiguration of TCPIP. I have done the operation that you describe many times without needing to do anything other than reboot.

I would look to doing this using dissimilar device support, if for nothing else than avoiding the downtime issue.

There are some complexities when one is dealing with a system disk, as opposed to a user disk, but there is nothing that should present an unavoidable problem.

I have not checked my documentation, but certainly if you are running 7.3-2, dis-similar device support should be, as Hein has noted, extremely helpful.

I will be happy to take a couple of minutes and speak about my experiences.

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

[Robert Gezelter]

Lionel,

I hit send too soon.

Management may find the presentations on this from this past (2007) HP Technology Symposium and the one in 2005 reassuring. Both presentations are available from our www site:

2007: http://www.rlgsc.com/hptechnologyforum/2007/1512.html

2005: http://www.rlgsc.com/hptechnologyforum/2005/1146.html

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

[Dean McGorrill]

Hi Lionel, "walking" the system disk over to
the new disks as Hein suggested should work. Though I have not, as yet done dynamic volume expanstion. Hi to Hein, Bob, Steven.
I've been off here for a while. The company
I was working for is going belly up, so most all including me got laid off. I may be contracting back to them. But we are also
bidding for more contract work. life goes
on! Dean

[Lionel Liu]

Thanks very much, appreciate to all of you
Lionel

[Jan van den Ende]

Lionel,

I regret to have to contradict some previous posters, but, Dynamic Volume Expansion is _ONLY_ possible with devices that have previously been INITed with the /LIMIT qualifier. And having read your original question I seriously doubt that that was available when you did THAT.
So, at this time it will NOT be that simple.
However, IF you prefer/have a need for NO down time, you CAN do a rolling "upgrade".
- INIT one of your new drives with /LIMIT (or all members at once using /SHADOW as well)
- Take this possibility to get the cluster size right. The default of 3 (probably the current cluster size , right?) is OPTIMALLY WRONG! If you are now on, or _may_ in the (far) future be moving toward, SAN storage, then choose 16 or a multiple. (If you seriously have trouble with the wasted space, at least pick 8 or even 4)
Now make an /IMAGE backup of your old system disk to the new disk (-set). Do NOT forget /NOINIT on your BACKUP restore command!
If you have used physical disk names, now is the time to cure that. They MUST be changed now, in contrast to logical names, where you just replace the definition.
Shut down one node, and boot it from the new disk/shadow set.
Repeat for the other system.

hth

Success.

Proost.

Have one on me.

jpe