BMC Remedy ITSM - Mobility multi-tenancy and clustering
This topic describes BMC Remedy ITSM - Mobility multi-tenancy and clustering. The following diagram illustrates a Multi-tenency Mobility Cluster Deployment. 
One mobility server cluster works with different versions of backend systems for different tenants.
The BMC Remedy ITSM - Mobility platform supports multi-tenancy. One BMC Mobility server or one cluster of BMC Mobility servers is able to handle requests for multiple tenants. A key benefit of using a multi-tenancy environment in the cloud is that it simplifies the deployment process. Supporting a new tenant for BMC Mobility is as simple as setting-up the configuration for the tenant. Cloud administrators are not required to build a new system for each BMC Mobility tenant.
All resources in multi-tenancy BMC Mobility server are organized using a tenant ID as the key. When a BMC Mobility client app such as Approvals or Incident Management contacts the BMC Mobility server, the host header used in the client request indicates the tenancy. This allows the BMC Mobility server to retrieve information that is particular to that tenant, and perform the API call with that information.
When performing push notifications, the notification received from the back-end data store contains a tenant ID. Using the tenant ID, the BMC Mobility server retrieves notification resources (a notification certification and user device token) of the tenant, and delivers the alert to the tenant's mobile client.
Mobility Administration Server
The configuration information for the the Mobility server cluster is stored in a centralized repository, which is called Mobility Administration Server. It hosts the Mobility Administration Console, which provides an interface for Mobility administrators and tenants to apply Mobility configurations. The Mobility Administration Console application is implemented as a BMC Remedy AR System deployable application.
The purpose of a centralized configuration repository is to simplify cluster management. All configuration changes only need to be made in one place, and they are distributed to all servers in the cluster automatically.
All tenant configurations are separated by tenant ids, with row level security enforced on shared forms. This ensures that each tenant can only see their own configurations. The console form can be accessed by both the Mobility Administrator role and the Mobility role. The Mobility role has read and write access only to Mobility application configurations. The Mobility Administrator role has read and write access to cluster and tenant configurations, as well as to to Mobility application configurations.
In a production or testing environment, the Mobility role can be mapped to the Mobility Group, and the Mobility Administrator role can be mapped to the Mobility Administrator Group. Each tenant user belongs to both their own Tenant Group, and to the Mobility Group. The Mobility administrator belongs to the Mobility Administrator Group. The installer for the Mobility Server creates the Mobility Administrator Group and the Mobility Group.
Related Topics