This sections describes the benefits of deploying more than one Mobile Controller, including deployment methods. This section contains the following topics:

If you deploy multiple Mobile Controllers, you gain the following benefits:

With more than one data center, you are not required to deploy multiple Mobile Controllers. If you have multiple data centers, but only one Mobile Controller, the SteelHead Mobiles obtains a user license from the Mobile Controller no matter in which data center the Mobile Controller is located. The Mobile Controller is not directly involved with the optimized connections. After the SteelHead Mobile has a license, it optimizes connections with the SteelHeads in the data centers where the application servers are located.

You must distinguish between a deployment of multiple Mobile Controllers for redundancy and multiple Mobile Controllers as a high-availability cluster. If you are using SteelCentral Controller for SteelHead Mobile v4.0 or later, Riverbed recommends that you use a high-availability cluster. The following table shows the differences.

The following tables show the different Mobile Controller models and concurrent user limits.

This section describes how to deploy two or more Mobile Controllers in a redundant configuration. This section requires that you be familiar with Multiple Mobile Controller Deployments.

Figure 24‑4 shows Mobile Controller A and Mobile Controller B installed in the data center and configured with a basic setup. You can install Mobile Controllers in different data centers and continue to provide redundancy.

Complete the following steps on both of the Mobile Controllers.

You can repeat these steps to add additional Mobile Controllers to the redundant configuration later. In each case, add the hostname or IP address of the additional Mobile Controllers to the Endpoint Settings in the relevant policy on all the Mobile Controllers in the redundant configuration.

To avoid clients receiving an untrusted certificate message, multiple Mobile Controllers in a redundant configuration must have the same Certificate Authority (CA) certificates. For more information, see Multiple Mobile Controllers and SSL.

This section describes how to prepare two or more Mobile Controllers to form a Mobile Controller high-availability cluster. Mobile Controller clusters work together as a single entity with respect to client policies, and some elements of the reporting. You can administer the Mobile Controller cluster from any member of the cluster.

Any client policy that you update on any cluster member automatically replicates and synchronizes with the other members of the cluster. Conflicts in which the same policy is inadvertently edited at the same time on different cluster members resolve automatically. Policies, packages, and some reporting statistics are automatically passed among cluster members. By default, this communication is though a TCP connection on port 7870.

Before a Mobile Controller can join a cluster, the Mobile Controller must:

There are no geographic or latency restrictions between the nodes of a Mobile Controller cluster, because the Mobile Controllers in a cluster use the same protocol that a Mobile Controller uses with a SteelHead Mobile. Typically, the current connection between the Mobile Controller and the SteelHead Mobiles supports round-trip times in excess of 3 seconds.

After a Mobile Controller successfully joins the cluster, it is automatically populated with the packages, policies, and other client-related settings from the existing members of the cluster, and any existing settings are deleted. If you want to retain a copy of the original settings, make sure that you back up the Mobile Controller configuration before joining it to an existing cluster. You do not need to configure existing cluster members for a new Mobile Controller to join.

To set up a cluster, make sure that all Mobile Controllers meet the requirements listed above, choose one Mobile Controller to start with, and join the remaining Mobile Controllers to the cluster one-by-one.

The members of the cluster can be different types and models of Mobile Controller. For example, it is possible to have SMC-9000, SMC-8650 and a Mobile Controller-v all in the same cluster so long as they meet the requirements previously listed.

For information about how to join the Mobile Controller to the cluster, see the SteelCentral Controller for SteelHead Mobile User’s Guide.

An HA cluster provides the ability to survive the failure of an individual Mobile Controller and potentially multiple Mobile Controller failures if you have a configuration that supports this (for example, the number of cluster members is greater than two).

Clustering also enables scalability for the number of supported endpoints. When multiple Mobile Controllers are joined together to form an HA cluster, the endpoint licenses that each Mobile Controller instance had prior to joining are put into a license pool. The license pool is available for all cluster members to use.

The following are basic guidelines to ensure a supported cluster configuration:

As a result of ongoing development and enhancements, this information is always subject to change. Riverbed recommends that you contact your Riverbed account team if you have a need to extend beyond these limits.

There are many different scenarios related to HA clusters and endpoint licensing. To have a successful deployment, you must understand how these endpoint licenses move in and out of the pool. This section contains the following topics:

Every cluster member must have some number of endpoint licenses before it joins the cluster. Generally, a new Mobile Controller has a number of endpoint licenses included by default. The actual quantity of default endpoint licenses depends on the model of the Mobile Controller. Additional endpoint licenses are supplied in packs, with each pack containing 10 licenses. For example, to add 100 licenses to a Mobile Controller, you purchase ten packs. When a Mobile Controller joins a cluster, it gives licenses to the pool if it has more than 100 licenses (this is the default setting).

For example, if a Mobile Controller has 130 licenses when it joins the cluster, it gives 30 licenses to the pool and keeps 100 licenses. If a Mobile Controller has 60 licenses, it does not give any licenses to the pool when it joins the cluster. Giving licenses to the pool is known as check in.

You can change the default of how many licenses the Mobile Controller keeps initially with the following command on the Mobile Controller CLI:

For example:

This command changes the default of licenses kept from 100 to 50. In that, when a Mobile Controller joins a cluster for the first time, if it has more than 50 endpoint licenses, it checks in the excess to the pool.

A Mobile Controller cluster member assigns a license from the cluster pool to a SteelHead Mobile client when the client requests one.

When the license count of a Mobile Controller drops below a certain threshold, the Mobile Controller takes more licenses from the pool. Taking licenses from the pool is known as check out. If there are no licenses in the pool, the Mobile Controller continues to assign licenses on request until it either runs out of licenses, or the pool is populated with more available licenses.

If there are no more licenses for the Mobile Controller and there are no licenses in the pool, the SteelHead Mobile client automatically contacts another Mobile Controller for a license (assuming the client is configured with multiple Mobile Controllers). If the other Mobile Controllers do not have an available license, the SteelHead Mobile client passes through connections while continuing to request a license at 10-second intervals. After a license is issued, any new connections are optimized.

There are a number of threshold settings related to license check out and check in.

When a Mobile Controller takes licenses from the pool, by default it checks out up to 100 licenses. You can change the default value with the following command on the Mobile Controller CLI:

For example:

This command changes the default threshold from 100 to 40. In that, when a Mobile Controller reaches its low threshold value, it checks out 40 more licenses. For more information about thresholds, see License Thresholds.

If the pool contains fewer licenses than the value for checkout-count, then the Mobile Controller takes all the remaining licenses, leaving the pool empty.

After a Mobile Controller has joined a cluster, checking in its excess licenses to the pool, it also detects how many licenses it has kept.

You can configure the Mobile Controller with two thresholds associated with the license usage. The high threshold is when a Mobile Controller has assigned most of its licenses (in other words, license usage is high) and needs to check out more licenses from the pool.

The low threshold is when the number of assigned licenses drops (in other words, license usage is low). When a client machine running the SteelHead Mobile client goes offline for a while (shuts down, hibernates, disconnects from the network, and so on) the Mobile Controller that assigned the license to the client marks the license as available for another request. When the number of assigned licenses in the Mobile Controller drops beneath the low-threshold value, the Mobile Controller has an excess of available licenses and checks in excess licenses to the pool.

The high-threshold and low-threshold values are expressed as a percentage. These two values are by default 90 and 70 respectively. You can change the default value with the following command on the Mobile Controller CLI:

and

For example:

This command changes the default value from 90% to 80%. In that, when a Mobile Controller has assigned 80% of its initial count of licenses, it checks out more licenses from the pool as specified by the checkout-count value.

One of the benefits of using multiple Mobile Controllers in a cluster rather than having them as individual (autonomous) instances is that you can pool the licenses in such a way that they remain available with one surviving member in the cluster.

When a Mobile Controller fails as part of a cluster, any licenses that it has are automatically placed in the pool and can be used by surviving Mobile Controllers in the cluster.

When the failed Mobile Controller recovers, it automatically checks out licenses as described in Endpoint License Pooling.

In a cluster of mixed Mobile Controller models that include one or more SMC-9000-BASE and one or more SMC-8650-BASE, a failure scenario might result in fewer licenses being available due to the capacity of the Mobile Controller.

For example, consider a cluster composed of two Mobile Controllers (1 x SMC-9000-BASE and 1 x SMC-8650-BASE) each with 3,000 licenses. The cluster can support 6,000 endpoints connected concurrently. But if the SMC-9000-BASE were to fail, only 4,000 licenses are available from the SMC-8650-BASE because that is its maximum capacity.

Individual Mobile Controllers that are part of an HA cluster share the same SteelHead Mobile group assignments, policies, packages and other general configuration details. This information is sent to a new cluster member at the time of joining the cluster. During the lifetime of the cluster, any changes or additions to deployment configuration data that are completed on one of the cluster members is automatically communicated to the other cluster members. Likewise, the data associated with endpoint reports is also communicated between the cluster members.

As a new cluster member joins, there can be a comparatively large amount (10s of MB) of information sent from an existing member to the new member. There is no real time limit for this transfer to complete, but if the link between the members is low bandwidth and high latency (for example, a WAN link, then the initial transfer can take some time. The new member only transitions to the Connected, Synced status after the transfer has completed. When this status is reached, the member is fully operational within the cluster.

The cluster members use a persistent connection on TCP port 7870 to send the configuration and report data. This is the same TCP port that is used by SteelHead Mobile to communicate with the Mobile Controller.

After the cluster members are all in sync, any configuration changes to one member are automatically broadcast to the other members. Even if there is no change, there is a poll every 5 minutes between random pairs of cluster members to compare the configuration between the pair. This ensures that any changes that have been missed are properly synced.