Administration guide > Upgrade and migrating WebSphere eXtreme Scale v7.1



Update 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 for the major version release or maintenance that to apply. You can get the latest information about the available releases and maintenance packages from the IBM support portal for WebSphere eXtreme Scale.

To upgrade without service interruption, upgrade the catalog servers first. Then, upgrade the container servers and the clients.


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:

      $ bin/xsadmin.sh -quorumstatus
      
      This Administrative Utility is provided as a sample only and is not to be 
      considered a fully supported component of the WebSphere eXtreme Scale product
      
      Connecting to Catalog service at localhost:1099
      Quorum is enabled and catalog server is in normal condition
      

      This result indicates that all the catalog servers are connected. The results of the quorumstatus command also might display the following message:

      Quorum is enabled but quorum is overridden.
      

      With this message, quorum is healthy, but not all catalog servers are running.

    2. Shut down one of the catalog servers. You can use the stopOgserver command, the xsadmin -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 xsadmin -quorumstatus command.

      If you use the xsadmin -teardown command, you can filter the server names. The stopOgServer 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 the servers:

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

      stopOgServer
      <server_name>[,<server_name>]
      

      xsadmin –teardown
      <server_name>[,<server_name>]
      

      With the previous examples, the stopOgServer or xsadmin -teardown commands are completing the same shutdown tasks. However, you can filter the servers to stop with the xsadmin -teardown command. See Stop servers gracefully with the xsadmin tool 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.

    3. 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:

    4. Restart the catalog server.

      If you are using a stand-alone environment, see Start a stand-alone catalog service for more information. If you are using a WebSphere Application Server environment, see Start and stop servers in a WAS 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.

    5. 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 to upgrade. You can stop the container server tier in groups with the stopOgserver command or the xsadmin -teardown command. Batching teardown and starting servers up in parallel benefit placement activities because shards can be moved in larger groups.

      $ bin/xsadmin.sh -teardown -fz DefaultZone
      
      Connecting to Catalog service at localhost:1099
      
      Proccessing filter options for Server teardown
      
      The following servers will be torn down: 
      
        container00
        container01
        container02
        container03
        container04
      
      
      Do 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. Restart the container servers.

    4. Upgrade any remaining container servers in the configuration.


Parent topic:

Upgrade and migrating WebSphere eXtreme Scale v7.1