Video Screencast Help
Symantec Appoints Michael A. Brown CEO. Learn more.

Clarification on what happens during a rolling SFHA upgrade

Created: 26 Feb 2013 • Updated: 30 Apr 2013 | 5 comments
mikebounds's picture
This issue has been solved. See solution.

Prior to 5.1SP1, the way I upgraded SFHA was to:

  1. Force stop VCS leaving applications running, unload GAB and LLT and upgrade VCS on ALL nodes
  2. Upgrade SF on inactive node
  3. Switch SGs from one llive node to upgraded node and upgrade node that have SGs were moved from

The problems with this is that:

  1. If there was an issue with VCS upgrade as all nodes are upgraded, you may have to backout, where as if you could upgrade VCS on one node at a time, then you could switch services to non-upgraded node if there was an issue with new VCS version.
  2. This procedure didn't work with CVM as you can't unload GAB and LLT

The way rolling upgrades was explained to me by Symantec Product Management when 5.1SP1 came out was that VCS now had the ability to communicate on different versions and so for instance a VCS node on 5.1SP1 could co-exist in a cluster with a node at 5.1SP1RP1 meaning you could upgrade the whole stack including VCS one node at a time. 

However, I have a customer who applied RP3 to 5.1SP1RP1 on Solaris one node at a time and he got error:

Local node leaving cluster before joining as engine versions differ. Local engine version: 0x5010a1e; Current cluster version: 0x5010a00

So I am now wandering if only LLT and GAB support communicating on different versions and VCS does not and therefore the rolling upgrade procedure is:

Upgrade LLT, GAB, Xxfs and Vxvm using "installer -upgrade_kernelpkgs inactive_node_name" on node at a time when node is inactive

Upgrade VCS on all nodes using "installer -upgrade_nonkernelpkgs node1 node2 ..." on all nodes at the same time where I am guessing VCS is forced stop to leave applications running.

Can anyone clarify?

Thanks

Mike

Operating Systems:

Comments 5 CommentsJump to latest comment

sfha_user's picture

HI MIke

Your outline is correct.

The exact Rolling upgrade procedure is on page 163 of the rp3 install guide.

ftp://ftp.veritas.com/pub/support/patchcentral/Solaris/5.1/sfha/sfha-sol_sparc-5.1SP1RP3-patches.tar.gz_doc/sfha_notes_51sp1rp3_sol.pdf

Product releases have the steps in the Rolling Upgrade Chapters in their install guide.

https://sort.symantec.com/documents

 

Doug

mikebounds's picture

Doug, thanks for your reply.

The stuff I have read in the docs doesn't give any more info than I gave in my opening post - i.e run installer, but doesn't explain in detail what it is doing.  I don't like using scripts and prefer to do thing manually as for instance in the past, scripts have frozen groups in a "preupgrade" and then unfrozen groups in a "postupgrade" and if you had any groups that were already intentionally frozen, then these too became unfrozen, so I prefer to have control on what is happening.

I seems to me that "rolling upgrades" offers no advantages over traditonal approach for non-CVM clusters and the difference is just:

Traditional approach: Upgrade SF on each node and then LLT, GAB, VCS on all nodes while App is online

Rolling Upgrade: Upgrade SF, LLT GAB on each node and then VCS on all nodes while App is online

Mike

UK Symantec Consultant in VCS, GCO, SF, VVR, VxAT on Solaris, AIX, HP-ux, Linux & Windows

If this post has answered your question then please click on "Mark as solution" link below

arangari's picture

Mike,

The VCS was 'never' a rolling-upgradable. That means, two versions of VCS will not talk to each other on same LLT/GAB network. 

I think the input to our installer about remembering 'user frozen' service groups and keep them frozen after upgrade is valuable. This should resolve your concern about 'control' on what is happening.

There is a 'phased upgrade' option of installer will handle the upgrade of subset of nodes. The applications from these nodes would be already moved to other node prior to upgrade.

Thanks and Warm Regards,

Amit Rangari

If this post helped you resolving the issue, please mark it as solution. _____________________________________________________________________________

mikebounds's picture

Amit,

The 5.1SP1 release notes say:

 

Support to enable rolling upgrades in future releases
VCS 5.1 adds support to enable rolling upgrades in future releases. These changes
will help you upgrade to future versions of VCS with a minimal downtime of your
infrastructure and applications during the upgrade process.

So can you clarify what you mean by:

The VCS was 'never' a rolling-upgradable. That means, two versions of VCS will not talk to each other on same LLT/GAB network. 

Are you saying that just VRTSvcs does not support rolling upgrade, but VRTSgab and VRTSllt do, or are you saying "VCS" including VRTSvcs, VRTSgab and VRTSllt do not support rolling upgrade - that is, LLT/GAB will not communicate on 2 different versions and if this is the case, then what is the rolling upgrade feature that was introduced in 5.1SP1.

Mike

 

 

UK Symantec Consultant in VCS, GCO, SF, VVR, VxAT on Solaris, AIX, HP-ux, Linux & Windows

If this post has answered your question then please click on "Mark as solution" link below

arangari's picture

indeed - only LLT/GAB handles the rolling upgrade. VRTSvcs will not. 

I will look into the 5.1 SP1 release notes and see if it needs more clarification. 

Thanks and Warm Regards,

Amit Rangari

If this post helped you resolving the issue, please mark it as solution. _____________________________________________________________________________

SOLUTION