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.
Procedure
- 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.
- Check for a healthy quorum status. Run the
following command:
xsadmin -quorumStatus
xscmd -c showQuorumStatus
This result indicates that all the catalog servers are connected.
- 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.
xsadmin –ch host -p 1099 -dismissLink domain_name
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.
- Shut down one of the catalog servers. You
can use the stopOgServer 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 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>]
xsadmin –teardown <server_name>[,<server_name>]
xscmd –c teardown -sl <server_name>[,<server_name>]
With the previous examples, the stopOgServer ,
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.
- 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:
- Restart the catalog server.
If you are
using a stand-alone environment, see Starting a stand-alone catalog service 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.
- Apply updates to the remaining catalog servers in your
configuration.
- 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.
- Stop the container servers that you want to upgrade. You can stop the container server tier in groups with the stopOgserver 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.
xsadmin –teardown -fz DefaultZone
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)
- 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:
- Restart your container servers.
- Upgrade any remaining container servers in your configuration.
- If you are using multi-master replication, reconnect your
catalog service domains. Use the xscmd -c establishLink command to reconnect the catalog service domains.
xsadmin –ch host –p 1099 –establishLink dname fdHostA:2809,fdHostB:2809
xscmd –c establishLink -cep host:2809 -fd dname -fe fdHostA:2809,fdHostB:2809
To check that all servers are using the
new version of WebSphere eXtreme Scale,
issue the xscmd -c showinfo command. xscmd –c showinfo
- Upgrade the client installations.
What to do next
- You can also use these steps to revert to an older version or
to uninstall maintenance packages. However, if you revert to Version
7.1.0 when you are using multi-master replication, the two-way replication
might not function correctly when you re-establish the links. In this
situation, restart both catalog service domains and re-link the catalog
service domains with the establishLink command.