IBM Support

Rolling Update Standalone fix packs using IBM Installation Manager

How To


Summary

This document explains detailed steps for updating XS standalone server.

Environment

Note: Extract XS-upgrade-script-files.zip, attached at the bottom of this article, for the following files.
  • collectConfigFiles.bat
  • restoreConfigFiles.bat
  • collectConfigFiles.sh
  • restoreConfigFiles.sh

Steps

I. Upgrade the catalog service tier, repeating the following steps for each catalog server in the data grid.

Upgrade the catalog service tier before upgrading any container servers . Individual catalog servers can interoperate with version compatibility, so you can apply upgrades to one catalog server at a time without interrupting service.

  1. If you are running with quorum mechanism enabled, check for a healthy quorum status. Run the following command:

    xscmd -c showQuorumStatus

    This result indicates that all the catalog servers are connected.

  2. If you are using multi-master replication between two catalog service domains, dismiss the link between the two catalog service domains while you are upgrading the catalog servers.

    xscmd –c dismissLink –cep host:2809 -fd domain_name
    You only need to run this command from one of the catalog service domains to remove the link between two catalog service domains.
  3. Shut down one of the catalog servers.
    You can use the stopOgServer or stopXsServer command, the xscmd -c teardown command, or shut down the application server that is running the catalog service in WebSphere Application Server. There are no requirements for the order in which you stop the catalog servers, but shutting down the primary catalog server last reduces turnover. To determine which catalog server is the primary, look for the CWOBJ8106 message in the log files. Under normal conditions when the quorum mechanism is enabled, quorum is maintained when a catalog server is shut down, but it is a best practice to query quorum status after each shutdown with the xscmd -c showQuorumStatus command.
    You can provide a specific list of servers to stop to the stopOgServer or stopXsServer command, or the xscmd -c teardown commands.
    For example:
    stopOgServer server_name
    stopXsServer server_name
    xscmd –c teardown -sl server_name
    With the previous examples, the stopOgServer or stopXsServer, or xscmd -c teardown commands are completing the same shutdown tasks. However, you can filter the servers to stop with the xscmd -c teardown command. See Stopping servers gracefully with the xscmd utility for more information about filtering the servers by zone or host name. The teardown command filters out the matching servers and asks if the selected servers are correct.
  4. Take the backup of configurations by running the following command with quotes: 
    
collectConfigFiles.sh "<InstallPath>" "<path to place the backup files>"
    or
    
collectConfigFiles.bat "<InstallPath>" "<path to place the backup files>"
  5. Uninstall Standalone from Installation Manager and delete the installation folder <InstallPath>.
  6. Install the Standalone 8.6.2.0 refresh pack on the catalog serverr.
    Note: Install in the same path as previous installation.
  7. Restore the backup files by running the following command with quotes: 
    
restoreConfigFiles.sh "<path of collected_files.tar.gz>" "<InstallPath>"
    or
    
restoreConfigFiles.sh "<path of collected_files.tar.gz>" "<InstallPath>"
  8. Update the JAVA_HOME environment variable to point to a supported Java™ Development Kit (JDK) installation. For supported JDK versions and instructions on updating the JDK, see Java SE considerations.
  9. Restart the catalog server.
    If you are using a stand-alone environment, see Starting a stand-alone catalog service that uses the IBM eXtremeIO (XIO) transport for more information. If you are using a WebSphere Application Server environment, see Starting and stopping servers in a WebSphere Application Server environment for more information.
    The catalog server runs in compatibility mode until all the catalog servers are moved to the same level. Compatibility mode mostly applies to major release migrations because new functions are not available on the servers that are not migrated. No restrictions exist on how long catalog servers can run in compatibility mode, but the best practice is to migrate all catalog servers to the same level as soon as possible.
  10. Verify that the catalog server started successfully.
    Ensure that the following xscmd commands return valid results:
    xscmd -c routetable -cep cathost:2809
    xscmd -c showMapSizes -cep cathost:2809
    Important: These commands must contain the -cep <catalog_server_host>:<listener_port> value for the restarted catalog server.
  11. Apply updates to the remaining catalog servers in your configuration.
II. Upgrade the container servers, repeating the following steps for each container server in the data grid.
You can upgrade container servers in any order.
  1. Stop the container servers that you want to upgrade.
    You can stop the container servers that you want to updgrade with the stopOgserver or stopXsServer command, or with the xscmd -c teardown command. For more information, see Stopping stand-alone servers that use the ORB transport,Stopping stand-alone servers that use the IBM eXtremeIO transport, and Stopping servers gracefully with the xscmd utility.
    By running the xscmd -c teardown or stopOgserver or stopXsServer commands to handle multiple servers in parallel, the placement mechanism can move shards in larger groups. However, do not to take down too many servers at the same time. The resources of servers that remain might become overloaded.
  2. Verify that the container servers were stopped and removed from the data grid. Run the following xscmd commands and verify that the results do not contain the stopped container servers.
    xscmd -c routetable
    xscmd -c showMapSizes
    If these commands are run too soon after container servers are stopped, correct results might not be returned. Wait a few minutes and try running the commands again.
  3. Take the backup of configurations by running  the following command: 
    
collectConfigFiles.sh <InstallPath> <path to place the backup files>
    
collectConfigFiles.bat <InstallPath> <path to place the backup files>
  4. Uninstall Standalone from Installation Manager and delete the installation folder <InstallPath>.
  5. Install the Standalone 8.6.2.0 refresh pack on the catalog server.
    Note: Install in the same path as previous installation.
  6. Restore the backup files by running the following command: 
    restoreConfigFiles.sh <path of collected_files.tar.gz> <InstallPath>
    or
    restoreConfigFiles.sh <path of collected_files.tar.gz> <InstallPath>
  7. Update the JAVA_HOME environment variable to point to a supported Java Development Kit (JDK) installation. For supported JDK versions and instructions on updating the JDK, see Java SE considerations.
  8. Restart your container servers.
  9. Verify that the container servers were restarted and added to the data grid.
  10. Run the following xscmd commands and verify that the results contain the restarted container servers.
    xscmd -c routetable
    xscmd -c showMapSizes
    If these commands are run too soon after container servers are started, correct results might not be returned. Wait a few minutes and try running the commands again.
  11. Upgrade any remaining container servers in your configuration.
III. Reconnect your catalog service domains, if you usemulti-master replication.
Use the xscmd -c establishLink command to reconnect the catalog service domains.
  
xscmd –c establishLink -cep host:2809 -fd dname -fe fdHostA:2809,fdHostB:2809
IV. Check that all servers are using the new version of WebSphere eXtreme Scale
Run the following command:
xscmd –c showinfo

Document Location

Worldwide

[{"Type":"MASTER","Line of Business":{"code":"LOB77","label":"Automation Platform"},"Business Unit":{"code":"BU048","label":"IBM Software"},"Product":{"code":"SSTVLU","label":"WebSphere eXtreme Scale"},"ARM Category":[{"code":"a8m50000000L2AFAA0","label":"IBM WebSphere Extreme Scale"}],"ARM Case Number":"","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"8.6.2"}]

Document Information

Modified date:
26 September 2025

UID

ibm17246116

Page Feedback