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.

Before you begin

You must have the binary file for the major version release or maintenance that you want to apply. You can get the latest information about the available releases and maintenance packages from the IBM support portal for WebSphere eXtreme Scale.

About this task

To upgrade without service interruption, you must first upgrade catalog servers, then upgrade the container servers, and lastly client servers.

[Version 8.6 only] To support enterprise data grid configurations, you must upgrade your transport mechanism from Object Request Broker (ORB) to IBM eXtremeIO (XIO). If you are not already using XIO, all of your servers and clients must be migrated to version 8.6 before you can switch to using the XIO transport. Your servers and clients can use the ORB transport while you are upgrading. When the upgrade is complete, you can move to XIO.

Procedure

  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. 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, 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.

      If you use the xscmd -c teardown command, you can filter the server names. The stopOgServer or stopXsServer command requires an exact server name or list of server names to stop in parallel to be entered. You should group the shutdown process instead of calling the stop or teardown process for many servers in parallel. By grouping the servers to be shut down, the data grid can react to the servers that are being shut down by moving shards around the data grid. You can use one of the following commands to shut down your servers:

      You can provide a specific list of servers to stop to the stopOgServer or xscmd -c teardown commands:

      stopOgServer <server_name>[,<server_name>]

      [Version 8.6 and later]
      stopXsServer <server_name>[,<server_name>]
      xscmd –c teardown -sl <server_name>[,<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:
    5. [Version 8.6 and later] 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. 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. However, consider updating the servers first, then the clients, if you are using new functions in the upgrade.
    1. Stop the container servers that you want to upgrade. You can stop the container server tier in groups with the stopOgserver or stopXsServer command or the teardown command. By batching teardown operations and running start server operations in parallel, the placement mechanism can move shards in larger groups.
      xscmd -c teardown -z DefaultZone
      
      Connecting to Catalog service at localhost:1099
      
      Processing filter options for Server teardown
      
      The following servers will be torn down: 
      
        container00
        container01
        container02
        container03
        container04
      
      
      Do you want to tear down the listed servers? (Y/N)
    2. 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:
    3. [Version 8.6 and later] 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.
    4. Restart your container servers.
    5. 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 installations.

    [.net programming language only][Version 8.6.0.2 and later] If your environment includes WebSphere eXtreme Scale Client for .NET, see Upgrading WebSphere eXtreme Scale Client for .NET.

What to do next