Remedy Mid Tier as a shared service

This topic provides the following information:

Concept of the mid tier as a shared service

Remedy Mid Tier as a shared service is a multitenant mid tier cluster.

In an environment with separate tenants for each customer, all the tenant servers share a single mid tier cluster. Users of all these tenants use the same mid tier cluster for interacting with the respective tenants.

By clustering Remedy Mid Tier, you can achieve the following benefits:

Reliability: High availability via seamless failover through session replication. See, High availability with mid tier as a shared service.
Serviceability: Ability to dynamically add or remove mid tiers to the cluster to manage load. See, Serviceability with mid tier as a shared service.

By configuring the Remedy Mid Tier cluster as a multitenant cluster, you can achieve the following benefits:

Scalability: Ability to dynamically onboard or offboard the tenants from a mid tier cluster. See, Scalability with mid tier as a shared service.
Resource optimization: Ability to reduce the hardware and operational costs by using fewer resources; the same mid tiers serves multiple tenants. See, Resource optimization with the mid tier as a shared service.
Optimum resource utilization: Capability to distribute workload across all mid tiers in the cluster, without overutilizing or underutilizing any of the mid tiers. See, Optimum utilization of mid tiers with mid tier as a shared service.

Tip

Required installation — Remedy Mid Tier

To deploy Remedy Mid Tier as a shared service, you must install Remedy Mid Tier on all the nodes in the cluster. You must then configure the mid tier cluster, and then onboard the tenants to the mid tier cluster.

Before you proceed with the installation, review the guidelines for deploying mid tier as a shared service. Then perform the required installations in a correct sequence, as described Deploying-BMC-Remedy-shared-services.

Benefits of the mid tier as a shared service

The scenarios listed in this section demonstrate the benefits of using the mid tier as a shared service. The configuration for the purpose of the sample scenarios is three mid tier clusters, multiple tenants for each mid tier cluster, and a single centralized configuration server for all three clusters. Each mid tier cluster has its own tenant users or system administrators performing actions using the mid tier cluster.

Note

The scenarios in this section depict an environment in which the mid tier, and the ECCS are deployed as shared services. The configurations are hypothetical, and may not represent actual configurations in your environment.

Consider the following components in your environment:

High availability with the mid tier as a shared service

This section describes two scenarios demonstrated in an environment without the mid tier as a shared service, and shows how you can achieve high availability with the mid tier as a shared service.

The following graphic demonstrates the two scenarios:

High availability.png

The following table explains the steps depicted in the graphic for these two scenarios:

Serviceability with the mid tier as a shared service

This section demonstrates a scenario of how you can achieve serviceability of mid tier by deploying mid tier as a shared service. To achieve serviceability, you can add or remove mid tiers from a cluster dynamically.

The following table explains the two scenarios depicted in the graphic:

Scalability with the mid tier as a shared service

This section demonstrates a scenario which describes how you can achieve scalability with mid tier as a shared service by dynamically adding or removing tenants from a mid tier cluster.

The following table explains the two scenarios depicted in the graphic:

Recommendation

For maximum benefit of scalability and performance, install the same version of Remedy ITSM Suite applications on all the tenants in the mid tier cluster.

Resource optimization with the mid tier as a shared service

This section demonstrates a scenario of you can achieve resource optimization with the mid tier as a shared service.

Resource optimization.png

The following table describes these scenarios:

Optimum utilization of mid tiers with the mid tier as a shared service

This section describes a scenario of the resource utilization issue faced in an environment without mid tier as a shared service, and demonstrates how you can achieve optimum resource utilization with mid tier as a shared service.

The following graphic demonstrates this scenario:

Optimum resource utilization.png

Consider the following assumptions for this scenario:

MT 3 and MT 4, each have a threshold of 1000 user requests.
Tenant 4 is configured to serve 500 concurrent users, whereas Tenant 6 is configured to serve 1000 concurrent users.

The following table explains how a mid tier as a shared service provides optimum resource utilization:

Guidelines for deploying mid tier as a shared service

Review the following guidelines before you configure Remedy Mid Tier as a shared service:

Decide the number of clusters in your environment.
If you require N number of mid tiers in a cluster, configure N+1 mid tiers to ensure maximum failover and load balancing capability. For information about mid tier performance, see Performance Benchmarking.
Use either separate mid tiers, or the same mid tiers in your cluster to perform the following functions:
- Administering the ECCS
- Creating a copy of good cache before on-boarding a new Tenant
- Enabling or disabling components and settings during AR System server setup for new Tenant
Decide which mid tiers to include in the cluster based on the following guidelines:
- Each computer hosting a mid tier must have the same hardware capacity. For example, each computer must have four CPUs at 2.0 GHz with 8 GB RAM and a 120-GB hard disk drive.
- Each computer must have only one web server instance and only one mid tier installed within the web server.
- If there are different subdomains or isolated networks, all computers in a cluster must be a part of the same subdomain or isolated network to ensure optimal performance.
Deploy each web server in the cluster on a separate computer, and install one mid tier on each web server. Configure two or more mid tiers as part of one cluster.
Use the symmetric configuration in which all mid tiers use the following:
- Same ECCS
- Same good copy of cache . Ensure that all mid tiers have exact copies of the cache before the mid tier starts serving requests.
  For information on creating a good copy of cache, see Creating a cache from the Remedy AR System online documentation.
Configure the load balancer to send requests from any client to any mid tiers in the cluster, and ensure that the sticky session behavior is set to ON.

For more information see, Configuring a cluster from the Remedy AR System online documentation.