Mobile Enterprise Gateway (MEG) in High Availability (HA) mode

The Mobile Enterprise Gateway (MEG) runs in Active-Active mode in a clustered High Availability (HA) configuration, where all gateways are active and handling requests.

If one gateway server fails, the other gateways in the cluster handle traffic and prevent an outage. A gateway server in High Availability (HA) mode can handle 10,000 devices, serving up to 200 devices per second with an average response size of 50 KB. If you want to use the Enterprise Gateway feature for more than 10,000 devices, use more gateways.

The following table provides a sample of scaling requirements for the Mobile Enterprise Gateway (MEG) module in a clustered High Availability (HA) configuration.
Device counts Scaling recommendation
Non-HA gateway is less than 10,000 devices One gateway is sufficient. High Availability (HA) is not available.
HA gateway is less than 10,000 devices Two gateways that are running in clustered mode. Even though one gateway can handle the load, from a High Availability (HA) perspective, provide an additional gateway.
HA gateway is less than 10,000 and less than 20,000 devices Three gateways that are running in clustered mode. If an outage occurs on one of the gateways, then the other two gateways can handle the load.
For every 10,000 device increments One gateway per 10000 devices and one clustered gateway to handle outage load. For example, 50000 devices require six gateways.

High Availability (HA) architecture (Relay Access Mode)

The following diagram illustrates the Mobile Enterprise Gateway (MEG) High Availability (HA) architecture for Relay Access Mode.
  • In relay clustered mode, all gateways talk to a shared database.
  • The relay server automatically balances the load among the active gateways.
  • You do not have to set up a load balancer on your network.
    High Availability (HA) architecture (Relay Access Mode)

High Availability (HA) architecture (Direct Mode)

The following diagram illustrates the Mobile Enterprise Gateway (MEG) High Availability (HA) architecture for Direct Mode.
  • In direct clustered mode, all gateways talk to a shared database.
  • Must implement a load-balancer in your network to actively balance the incoming traffic among active gateways.
  • Might need to set up SSL certificates for device-to-load-balancer SSL communication.
  • Might need to set up SSL certificates for traffic between the load-balancer and the gateway. Using SSL is not mandatory, since data packets between the load-balancer and gateway are always encrypted, even over HTTP.
    High Availability (HA) architecture (Direct Mode)

Database requirements for High Availability (HA)

For High Availability (HA), the Mobile Enterprise Gateway (MEG) requires a shared database among active gateways that share configuration and authentication information. Set up a database on your database server. Mobile Enterprise Gateway (MEG) supports the following database requirements.
Table 1. Database requirements for High Availability (HA)
Requirement Description
Database servers Microsoft SQL 2008 or higher
MySQL 5.6.22+ v DB2 10.5.500.107
Database integration Follow these steps to integrate the databases with the gateway:
  1. Identify and set up the database server that integrates with the gateways. Provide the hostname and the port that is used by database the server for integration.
  2. Create a blank database within the database server. Provide a database name for integration, and configure the new database to be case-insensitive.
  3. You must have a local SQL server account or a Windows NT account for database access. The account must have the following permissions on the database.
    • create table
    • alter table
    • drop table
    • read
    • write
    When the gateway service starts, the service automatically creates the database tables that are required for the gateway to function.
Database sizing 10 KB per device (the number of devices that are multiplied by 10 KB).

If your environment also uses Kerberos authentication for your websites, the database size increases significantly depending on the Kerberos token size and the number of websites that use Kerberos authentication. For sizing, assume 50 KB per site per user.