Running Mobility XE In A Geographically Distributed Configuration
Technical Note 2233
Last Reviewed 15-Dec-2008Applies to:
Mobility XE server version 8.x
Printer-friendly versionSummary
This technical note lists the guidelines that must be followed when running Mobility XE in a geographically distributed deployment, where Mobility servers that are members of the same pool are deployed in separate physical locations. Deploying a distributed pool in a manner not consistent with these guidelines is not supported and response times may be unsatisfactory.
Guidelines for Geographically Distributed Configurations
- See the Guidelines for Supported Mobility XE Deployments for a complete list of requirements.
- NetMotion Wireless supports pools where all server components are connected only with high availability links, with no less than 10 Megabits per second of throughput, and with no more than 150 milliseconds of latency.
- Each geographic region must be configured to be in a separate zone. The latencies frequently seen within distributed deployments can significantly increase some of the delays seen by client devices and in the management user interface (the web-based console), notably with any features that store or retrieve data from the Mobility warehouse.
- If mass failover capacity between geographic locations is needed, the pool must have enough excess capacity so that the remaining servers in the pool are able to support the client load if any one geographic site is out of communication.
In the example above, if any one zone fails, the other two zones have enough excess capacity to absorb the load, and if Zone 3 plus another zone both fail, the remaining zone has two Mobility servers to serve 2500 clients which is an acceptable load.
Geographically distributed pools must be designed so that remaining zones are not loaded past maximum capacity if one zone fails. As a result, deploying a pool across geographic regions lowers the total supported pool capacity.
| Total Pool Capacity (concurrent sessions) |
Zones |
Mobility Servers per Zone |
Mobility Servers per Pool |
Clients per Zone (equally distributed) |
Comments |
| 15,000 |
1 |
12 |
12 |
15,000 |
The pool can handle no more than 2 Mobility servers failing before reaching maximum capacity. |
| 9,000 |
2 |
6 |
12 |
4,500 |
If one zone fails, the remaining zone will be running at maximum capacity to absorb the load. |
| 12,000 |
3 |
4 |
12 |
4,000 |
Assumes only one failed zone. The remaining zones will be running at maximum capacity to absorb the load. |
Note: In the examples below, increasing the latency by 50 milliseconds causes an increase in the time it takes 5000 devices to connect by at least 15 minutes. Note that though the examples have slightly different configurations, the latency results are the same.
Example 1: Mobility XE pool without Analytics (pre-v8.5):
Example 2: Mobility XE pool with Analytics Module(v8.5):
- This example represents 5000 clients connecting at once as if in a failover situation (moving from one 6-server zone to another 6-server zone in another geographic region), at 50 milliseconds of round-trip latency. All clients connect in less than 20 minutes. Doubling the latency to 100 milliseconds doubles the time that it takes all 5000 clients to connect to 40 minutes, and increasing it to 150 milliseconds of latency trickles the connections in over a 50-minute period.
- In geographically separated pools or zones, management of the pool should be performed over a separate management network. Additionally, it should be performed over the lowest latency link possible.
As examples of the management delays that are seen at higher latencies, listed below are load times for the main administrative status page of the management console, for a pool where 6 of the servers are local and 6 are in another geographic region:
- 0 ms latency = 0.6 second load time
- 50 ms latency = 22 second load time
- 100 ms latency = 45 second load time
- 150 ms latency = 68 second load time
Known Issues with Higher Latency Deployments
- When adding new servers to a pool, it can take 20 minutes or more for the new server to come online.
- The management web interface can be slow at points, and searching the connection list can take up to an hour in some circumstances.
- Client actions such as, but not limited to, NAC and Policy that require server interaction with the Mobility warehouse will take longer amounts of time as the latency between the server and the primary warehouse is increased.
- Mass failover connect times are increased as latency increases.
Related Information
Please comment on this technical note.
