From: fletch@med.stanford.edu
Date: Mon May 10 2004 - 14:53:27 EDT
Hi Fellow Admins,
We have two SunFire 480's attached to A1000 running Veritas 3.5 acting
as our Oracle 9i DB Cluster.
Tonight we plan to apply the following 75 recommended Solaris 9 patches
to bring them both up to date:
112233-12 112808-06 112921-03 112960-12 113026-14 113240-06
113457-05 113575-05 114125-01 114388-03 114713-01 114971-02
116247-01 112540-21 112817-17 112922-02 112963-12 113068-04
113277-21 113476-13 113713-14 114127-03 114482-04 114721-04
115158-05 116308-01 112661-06 112834-03 112923-03 112964-07
113073-05 113278-06 113482-02 113718-02 114129-02 114495-01
114729-01 115172-01 116453-01 112764-07 112907-02 112925-03
112965-03 113077-11 113322-02 113492-04 113993-06 114332-11
114569-02 114861-01 115754-02 112785-34 112908-12 112926-05
112975-03 113096-03 113329-05 113573-04 114008-01 114361-01
114571-01 114864-02 116237-01 112807-08 112911-06 112951-08
112998-03 113226-05 113451-06 113574-03 114016-01 114363-02
114684-02 114875-01 116245-01
I have run this by a Veritas support engineer and he stock answer was
"we don't have any conflicts in general" with solaris patches - but
contact Sun.
I'd rather hear it from the user community if there are any potential
conflicts in this list?
We then plan to upgrade from 3.5 to 3.5MP2 with the following procedure:
4. Install Volume Manager, files system and VEA patches
Install VRTSvxvm patch 112392-06 on node1
# patchadd 112392-06
Install VRTSvxfs 113207-10 (Solaris 9) on node1
# patchadd 113207-10
Install VRTSob patch 113203-03 on node1
# patchadd 113203-03
Install VRTSobgui patch (if system is a VEA client) 113595-04 on
node1
# patchadd 113595-04
Install VRTSvmpro patch 113596-03 on node1
# patchadd 113596-03
Install VRTSfspro patch 113211-03 (Solaris 9) on node1
# patchadd 113211-03
5. Reboot node1 and unfreeze the services on node2 and move them over
to node1
# haconf -makerw
# hagrp -unfreeze <service_group> -persistent
# haconf -dump -makero
# hagrp grp_name -switch -to node1
6. Move all services from node2 to node1 and FREEZE the service groups.
# hagrp grp_name -switch -to node1
# haconf -makerw
# hagrp -freeze <service_group> -persistent
# haconf -dump -makero
7. Install Solaris Recommend cluster patches on node1
8. Reboot node2
*services are still frozen on node1
9. Install Volume Manager, files system and VEA patches
Install VRTSvxvm patch 112392-06 on node2
# patchadd 112392-06
Install VRTSvxfs 113207-10 (Solaris 9) on node2
# patchadd 113207-10
Install VRTSob patch 113203-03 on node2
# patchadd 113203-03
Install VRTSobgui patch (if system is a VEA client) 113595-04 on
node2
# patchadd 113595-04
Install VRTSvmpro patch 113596-03 on node2
# patchadd 113596-03
Install VRTSfspro patch 113211-03 (Solaris 9) on node2
# patchadd 113211-03
10. Reboot node2 and unfreeze the services on node1 and move services
that belong to node2 back over.
# haconf -makerw
# hagrp -unfreeze <service_group> -persistent
# haconf -dump -makero
# hagrp grp_name -switch -to node2
* If the systems move service groups back and forth successfully the
VCS patch installation can now be started.
************************ VCS MP2 update **********************
1. Offline the ClusterService service group if it is running.
On any system type:
# hagrp -offline ClusterService -sys <system>
2. Make the VCS configuration writable. On any system, type:
# haconf -makerw
3. Freeze all service groups. On any system, type:
# hagrp -freeze <service_group> -persistent
4. Save the configuration file (main.cf) with the groups frozen.
On any system, type:
# haconf -dump -makero
5. Shut down VCS. On any system, type:
# hastop -all -force
6. Confirm VCS has shut down. On each system, type:
# gabconfig -a
Output resembles:
GAB Port Memberships
=======================================
Port a gen 23dc0001 membership 01
Note the output shows no membership for port h.
7. Determine if GAB is running on any disks.
On any system, type:
# gabdiskhb -l
# gabdiskx -l
If gabdiskhb or gabdisk are running, the systems must be
rebooted following patch installation.
8. Unconfigure GAB. On each system, type:
# gabconfig -U
9. Unload GAB. On each system, perform the following steps:
a. Identify the GAB kernel module. For example:
# modinfo | grep gab
149 50cc6000 2b451 112 1 gab (GAB device 3.5)
In this example, the kernel number is 149. It appears at the far
left of the output.
b. Unload GAB using the module number:
# modunload -i 149
A message similar to the following is displayed on the console:
Jun 14 15:41:11 vcstc1 gab: GAB:20022: GAB unavailable
If GAB cannot be stopped or unloaded, the systems must be rebooted
following patch installation.
10. Unconfigure LLT. On each system, perform the following steps:
a. Type:
# lltconfig -U
The following message is displayed:
lltconfig: this will attempt to stop and reset LLT.
Confirm (y/n)?
b. Type y on each system in response to the message.
11. Unload LLT. On each system, perform the following steps:
a. Identify the LLT kernel module. For example:
# modinfo | grep llt
147 50ca4000 d6bc 110 1 llt (Low Latency Transport device 3.5)
In this example, the kernel number is 147. It appears at the far
left
of the output.
b. Unload LLT using the module number:
# modunload -i 147
A message similar to the following is displayed on the console:
Sept 14 15:41:11 vcstc1 llt: LLT Protocol unavailable
If LLT cannot be stopped or unloaded, the systems must be rebooted
following patch installation.
12. Change directory to the patch location.
13. Install the patch that corresponds to the version of the operating
system you are running:
# patchadd patch 113709-02.
14. After installation is complete, verify that the patch has been
installed.
On each system, type:
# showrev -p | grep <patch_id>
The information displayed after successful installation resembles the
following (Solaris 8 example):
Patch: 113708-02 Obsoletes: 113702-01 Requires:
Incompatibles:
Packages: VRTSvcs, VRTSvcsag, VRTSvcsw
15. If any of the following four cases occurred during installation,
reboot
each system in the cluster to restart VCS:
gabdiskhb is running
gabdiskx is running
GAB could not be stopped or unloaded
LLT could not be stopped or unloaded
If none of the previous four cases occurred, restart LLT, GAB, and
VCS.
On each system, type:
# /etc/rc2.d/S70llt start
# /etc/rc2.d/S92gab start
# /etc/rc3.d/S99vcs start
16. After VCS has started on all systems, perform the following steps:
a. Verify all resources have been probed. On any system, type:
# hastatus -summary
b. Unfreeze all service groups. On any system, type:
# haconf -makerw
# hagrp -unfreeze <service_group> -persistent
# haconf -dump -makero
c. Online the ClusterService service group, if necessary.
On any system type:
# hagrp -online ClusterService -sys <system>
-- TIA, Will summarize Fletcher Cocquyt Senior Systems Administrator fcocquyt@stanford.edu _______________________________________________ sunmanagers mailing list sunmanagers@sunmanagers.org http://www.sunmanagers.org/mailman/listinfo/sunmanagers
This archive was generated by hypermail 2.1.7 : Wed Apr 09 2008 - 23:28:37 EDT