Forum Discussion

mikebounds's avatar
mikebounds
Level 6
12 years ago
Solved

Clarification on what happens during a rolling SFHA upgrade

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

business continuity
Cluster Server
High availability
Solaris
Upgrade
  • arangari's avatar
    arangari
    12 years ago

    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. 

  • mikebounds's avatar
    mikebounds
    Level 6
    12 years ago

    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

  • arangari's avatar
    arangari
    Level 5
    12 years ago

    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.

  • mikebounds's avatar
    mikebounds
    Level 6
    12 years ago

    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

     

     

  • arangari's avatar
    arangari
    Level 5
    12 years ago

    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.