topic Re: Upgrade 7.3-2 on a Cluster. in Operating System - OpenVMS

Upgrade 7.3-2 on a Cluster.

Douglass Anderson — Mon, 03 Oct 2005 10:28:38 GMT

I have read through the 7.3-2 upgrade and installation manual but still have questions.

1) If I have a two node cluster. do I have to PRESERVE install on both nodes?

2) Do I need to remove my shadow set on both nodes and reform them after the upgrade?

Re: Upgrade 7.3-2 on a Cluster.

Ian Miller. — Mon, 03 Oct 2005 10:34:32 GMT

split the shadowed system disk and upgrade one of the memembers (the one you normally boot from would be easiest).

If you have one system disk then you only have to do the upgrade once.

Re: Upgrade 7.3-2 on a Cluster.

Andy Bustamante — Mon, 03 Oct 2005 10:57:59 GMT

Your upgrade depends on the cluster configuration.

If you have 1 system disk with 2 boot roots, you only need to do a PRESERVE install on one node. The other node needs to be shut down.

If you have two system disks, and common files on a third disk, you can upgrade one node at a time using the preserve option.

You can't upgrade a disk using host based volume shadowing (DSA device). See chapter 5 in the Upgrade and Installation Manual. You can run the upgrade on one node and recreate the shadow set, but you need to be aware of anything on the system disk that may need to be preserved. Chapter 11 of Guidlines for OpenVMS Clusters covers files which you may need to consider based on your business requirements.

Andy

Re: Upgrade 7.3-2 on a Cluster.

Douglass Anderson — Mon, 03 Oct 2005 11:09:59 GMT

I have DSA100: as follows.
---------------------------------
OSIJX2>show dev dsa100 /multi
Device Device Error Current
Name Status Count Paths path
$1$DGA351: (OSIJX2) ShadowSetMember 0 3/ 3 PGA0.5006-0482-BCC3-0A45
------------------------------
Is that just one system disk on the Shadow ?
What does that imply for my install?

Sorry new at this ....

Re: Upgrade 7.3-2 on a Cluster.

Andy Bustamante — Mon, 03 Oct 2005 13:13:41 GMT

You'll still need to break up the shadow set for for an o/s upgrade. During the upgrade process the disk being upgrade cannot be in use the the other node in your cluster.

Can you post the results of

$ show device sys$sysdevice: /full

for each each node in your cluster.

Re: Upgrade 7.3-2 on a Cluster.

Petr Spisek — Wed, 05 Oct 2005 06:10:08 GMT

Hi, it realy depends on your cluster configurations.
1) You must to know whether you have one system disk for all cluster or separate systems for each member of cluster (you can have some members of the cluster and only one system disk). If you don't use PRESERVE option, your system disk will be initialized you'll lost old configurations (as you know from the install guid).
Check this:
SHOW DEVICE SYS$SYSDEVICE (from each system of cluster) ... if you'll see the same disk, you have only one system disk in your cluster. If not, you must upgrade two systems.

2) Yes - if you have two-systems cluster. Installing vms to shadowset is not allowed. You must disable shadowing of the system disk (syspar. SHADOW_SYS_DISK) and upgrade system to one of member system shadowset. After succesful upgrade enable this and add the other member(s) to system shadowset manualy.

Don't forget to do system backup :-)
Good luck.

Petr

Re: Upgrade 7.3-2 on a Cluster.

Douglass Anderson — Wed, 05 Oct 2005 07:58:23 GMT

Here you go.
-------------------------------------
OSIJX1>show device sys$sysdevice: /full

Disk DSA100:, device type EMC SYMMETRIX, is online, mounted, file-oriented
device, shareable, available to cluster, error logging is enabled, device
supports bitmaps (no bitmaps active).

Error count 0 Operations completed 16185822
Owner process "" Owner UIC [SYSTEM]
Owner process ID 00000000 Dev Prot S:RWPL,O:RWPL,G:R,W
Reference count 9807 Default buffer size 512
Total blocks 35354880 Sectors per track 64
Total cylinders 36828 Tracks per cylinder 15

Volume label "ALPHASYS" Relative volume number 0
Cluster size 35 Transaction count 642
Free blocks 20049855 Maximum files allowed 493838
Extend quantity 5 Mount count 2
Mount status System Cache name "_DSA100:XQPCACHE"
Extent cache size 64 Maximum blocks in extent cache 2004985
File ID cache size 64 Blocks in extent cache 1610805
Quota cache size 0 Maximum buffers in FCP cache 8490
Volume owner UIC [1,1] Vol Prot S:RWCD,O:RWCD,G:RWCD,W:RWCD
Volume access control list:
(IDENTIFIER=[3360,1],ACCESS=READ)

Volume Status: ODS-2, subject to mount verification, protected subsystems
enabled, write-through caching enabled.
Volume is also mounted on OSIJX2.

Disk $1$DGA351:, device type EMC SYMMETRIX, is online, device has multiple I/O
paths, member of shadow set DSA100:, served to cluster via MSCP Server,
error logging is enabled.

Error count 0 Shadow member operation count 3018786
Current preferred CPU Id 1 Fastpath 1
WWID 01000010:6006-0480-0001-8370-0521-4441-5431-3546
Host name "OSIJX1" Host type, avail AlphaServer ES40, yes
Alternate host name "OSIJX2" Alt. type, avail AlphaServer ES40, yes
Allocation class 1

I/O paths to device 3
Path PGA0.5006-0482-BCC3-0A45 (OSIJX1), primary path, current path.
Error count 0 Operations completed 3018786
Path PGC0.5006-0482-BCC3-0A5A (OSIJX1).
Error count 0 Operations completed 0
Path MSCP (OSIJX2).
Error count 0 Operations completed 0
-------------------------------------------
OSIJX2>show device sys$sysdevice: /full

Disk DSA100:, device type EMC SYMMETRIX, is online, mounted, file-oriented
device, shareable, available to cluster, error logging is enabled, device
supports bitmaps (no bitmaps active).

Error count 0 Operations completed 6755135
Owner process "" Owner UIC [SYSTEM]
Owner process ID 00000000 Dev Prot S:RWPL,O:RWPL,G:R,W
Reference count 1337 Default buffer size 512
Total blocks 35354880 Sectors per track 64
Total cylinders 36828 Tracks per cylinder 15

Volume label "ALPHASYS" Relative volume number 0
Cluster size 35 Transaction count 618
Free blocks 20049855 Maximum files allowed 493838
Extend quantity 5 Mount count 2
Mount status System Cache name "_DSA100:XQPCACHE"
Extent cache size 64 Maximum blocks in extent cache 2004985
File ID cache size 64 Blocks in extent cache 47390
Quota cache size 0 Maximum buffers in FCP cache 4240
Volume owner UIC [1,1] Vol Prot S:RWCD,O:RWCD,G:RWCD,W:RWCD
Volume access control list:
(IDENTIFIER=[3360,1],ACCESS=READ)

Volume Status: ODS-2, subject to mount verification, protected subsystems
enabled, write-through caching enabled.
Volume is also mounted on OSIJX1.

Disk $1$DGA351:, device type EMC SYMMETRIX, is online, device has multiple I/O
paths, member of shadow set DSA100:, served to cluster via MSCP Server,
error logging is enabled.

Error count 0 Shadow member operation count 1406794
Current preferred CPU Id 1 Fastpath 1
WWID 01000010:6006-0480-0001-8370-0521-4441-5431-3546
Host name "OSIJX2" Host type, avail AlphaServer ES40, yes
Alternate host name "OSIJX1" Alt. type, avail AlphaServer ES40, yes
Allocation class 1

I/O paths to device 3
Path PGA0.5006-0482-BCC3-0A45 (OSIJX2), primary path, current path.
Error count 0 Operations completed 1406794
Path PGC0.5006-0482-BCC3-0A5A (OSIJX2).
Error count 0 Operations completed 0
Path MSCP (OSIJX1).
Error count 0 Operations completed 0

Re: Upgrade 7.3-2 on a Cluster.

Petr Spisek — Wed, 05 Oct 2005 09:01:26 GMT

It looks like you have only one system disk for your cluster (ShadowSet) DSA100: with only one ShadowMember $1$DGA351: !!! ShadowSets make sense if you have more ShadowMembers (for disaster tolerance - if one of members dies). How is configured DGA351: on controller (JBOD, mirror, ...)? It's not important for your question, but if this cluster has some important work, try to find the missing member of DSA100.

So, it looks you have 1 system disk with 2 boot roots as Andy wrotes.
P.

Re: Upgrade 7.3-2 on a Cluster.

Thomas Simpson — Sun, 09 Oct 2005 10:43:38 GMT

Your configuration is a 2-node ES40 cluster using a common system disk. Roots 0 and 1 are the current active root directories.

HBVS is enabled and running for the system disk but is not really utilized, since there is only a single disk. The volume shadowing task is being handled behind the scenes by the EMC SAN, so the HBVS shadow member was deemed unnecessary when the switch was made to the EMC SAN. The HBVS was left in place for situations (such as upgrades) when you want a "warm" backup copy of the system disk ready in case things go badly during the upgrade.

Re: Upgrade 7.3-2 on a Cluster.

Douglass Anderson — Mon, 27 Feb 2006 09:06:57 GMT

solved