Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?


Cluster Migration Strategy


The easiest way to replace an existing cluster with an upgraded cluster is to fully install and configure the new cluster and then simply cut over to the new install.

This causes a brief service disruption that can be mitigated if both clusters run online in parallel long enough for existing sessions to naturally drop off the old cluster as they end. Because no new sessions are added to the old cluster, after some period of time, most active sessions are managed by the new cluster. Any remaining long-term sessions are terminated when the old cluster is brought down. When they reconnect to the network, they connect to the new cluster.

Some sites may have a problem implementing this strategy because it requires enough servers to support two clusters, and not all sites have that many machines available.

Using a Transition Server

Using a Transition Server

To address this, we developed a migration strategy that uses a transition server. A single transition server temporarily takes the place of your entire existing cluster while the servers in your existing cluster are taken offline, upgraded with new SBRC Session State Register software, and then brought back online.


We recommend using a transition server to mitigate downtime when performing any upgrade. The examples shown here depict the use of a transition server during an upgrade from SBR/HA 5.5 to a Release 8.6.0 Session State Register (SSR) cluster. However, we also recommend using a transition server when upgrading from previous releases of SBR Carrier software to Release 8.6.0.

The SBRC Temporary Cluster, also termed the transition server, is an exceptional node in the sense that it executes all processes on one machine. The transition server is assigned the node type= smdt. The and configuration of pool(s) must be done manually on a transition server, just like in a cluster.

Use a transition server (fifth machine) in addition to the four servers that a basic cluster installation requires to ensure redundancy. The additional fifth machine performs the work of the entire cluster while the four existing cluster servers are taken offline, updated, and brought online in a SSR Starter Kit configuration.

If an additional fifth machine is not available and you must work only with the four servers that currently make up your cluster, the transition server strategy can be adapted and one server in the existing cluster can be borrowed from the existing cluster and used as the transition server. This increases the risk of cluster failure during the switchover because some level of redundancy or capacity is removed from the existing, working cluster when a machine is taken offline.

Figure 18: SBR Migration Using the Transition Server Four-Server Strategy
SBR Migration Using the Transition Server Four-Server

Four-Server Strategy Only

If you must use the four-server strategy, look for special labels in the margin note area beside critical paragraphs in this chapter, like this one. They identify extra steps required if the transition server was part of an existing cluster and the cluster is running on three nodes. The step identified by the Four-Server Strategy Only label is not required if you use the five-node strategy (extra fifth machine) and leave the existing cluster fully functional.

The transition takes at least several hours and may take longer. The amount of time varies from site to site and depends upon:

  • The number of servers involved.

  • Whether the servers require a Solaris upgrade. Many SBR/HA Release 5.5 servers ran on Solaris 9 but Steel-Belted Radius Carrier Release 8.6.0 requires Solaris or later.

  • Whether a Release 8.6.0 test environment that replicates the production environment exists and can be moved to the production cluster, or the production environment needs to be created and tested.

  • Whether one person or crew is installing one server at a time, or several are being installed in parallel.

Individual Node Migration Guidelines

Individual Node Migration Guidelines

Before beginning an upgrade that reuses your existing cluster servers, confirm that all machines can meet the Release 8.6.0 server requirements in Before You Install Software. In addition, observe these guidelines:

  • Migration of SBR/HA Release 5.5 data nodes or management nodes is not supported. These nodes must be taken offline, existing software removed, and new software installed.

  • No server may host both SBR/HA Release 5.5 software and Release 8.6.0 SSR software at the same time. Just one version may be installed at any time.

  • Migration of SBR/HA Release 5.5 RADIUS node configuration files to Release 8.6.0 SBR Carrier (S) nodes is not supported because of the significant differences between SBR/HA Release 5.5 and Release 8.6.0.

  • If an existing Release 8.6.0 environment exists, perhaps one used for testing, you can use the configuration files from those SBR Carrier (S) nodes for the production installation.