Updating eXtreme Scale servers

You can upgrade WebSphere® eXtreme Scale to a new version, either by applying maintenance or installing a new version, without interrupting service.

1. 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 or clients. 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:

      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. Install the updates on the catalog server.
      You can either migrate the catalog server to a new major release of the product or apply a maintenance package. See the following topics for more information:

      • To migrate from a Version 7.1.x installation: Migrating to WebSphere eXtreme ScaleVersion 8.6
      • To migrate from a Version 8.5 installation: Installing fix packs using IBM Installation Manager.
   5. 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.
   6. Restart the catalog server.

      If you are using a stand-alone environment, see Starting a stand-alone catalog service that uses the ORB transportor 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.

   7. 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.
   8. Apply updates to the remaining catalog servers in your configuration.
2. 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. Install the updates on the container servers.
      You can either migrate the container servers to a new major release of the product or apply a maintenance package. See the following topics for more information:

      • To migrate from a Version 7.1.x installation: Migrating to WebSphere eXtreme ScaleVersion 8.6
      • To migrate from a Version 8.5 installation: Installing fix packs using IBM Installation Manager.
   4. 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.
   5. Restart your container servers.
   6. Verify that the container servers were restarted and added to the data grid.
      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.
   7. Upgrade any remaining container servers in your configuration.
3. If you are using multi-master replication, reconnect your catalog service domains.
   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

4. To check that all servers are using the new version of WebSphere eXtreme Scale, issue the xscmd -c showinfo command.

   xscmd –c showinfo
   

5. Upgrade the client-only installations.

   If your environment includes WebSphere eXtreme Scale Client for .NET, see Upgrading WebSphere eXtreme Scale Client for .NET.