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:
| Component | Names |
|---|---|
| Remedy Mid Tier clusters | Cluster A, Cluster B, Cluster C |
| Remedy Mid Tiers (MT) in different clusters | MT 1, MT 2, MT 3, MT 4, MT 5, and MT 6 |
| Tenants of different clusters | Tenant 1, Tenant 2, and Tenant 3, Tenant 4, Tenant 5, and Tenant 6, Tenant 7, Tenant 8, and Tenant 9 |
| Enterprise Centralized Configuration Server | ECCS |
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.
| Scenario | mid tier crashes while serving a request | New requests are submitted while a mid tier is down |
|---|---|---|
| Issue | In a single mid tier environment, the mid tier crashes while serving a tenant user request, and request is not completed. The users has to log on again and submit the request again. | In a single mid tier environment, if the only mid tier crashes, you cannot send new requests until the mid tier is functional again. |
| Solution | Deploy a mid tier as a shared service | Deploy a mid tier cluster as a shared service |
| Description | A user enters data in a form, and submits the form. However, the serving mid tier crashes before completing the request. The load balancer routes the incomplete request details to a functional mid tier in the cluster, which then completes the request. | If a mid tier from the cluster fails, and then a user submits new requests, the load balancer routes the new requests to a functional mid tier in the cluster. |
| Benefit | When a user logs on to a mid tier in a cluster, session replication occurs in real time. All mid tiers have information about all the sessions that are part of the session replication. If a mid tier crashes, any other mid tier in the cluster can continue with the session seamlessly. A user might not have to log on again and resubmit the request, even if the serving mid tier is down. User requests are completed without interruption. Note: Session replication is possible depending on how you configure your underlying web server. | The functional mid tiers in the cluster serve any new requests until the failed mid tier is functional again. There is no loss of business. |
The following graphic demonstrates the two scenarios:
The following table explains the steps depicted in the graphic for these two scenarios:
| Updating Global settings of mid tiers | Updating tenant specific settings | ||
|---|---|---|---|
| Step | Description | Step | Description |
| S1 | User B4 is a user of Tenant 4. User 4 has already submitted a request, called the Submitted request, to retrieve 1000 records from Tenant 4. | N1 | User B6 is a user of Tenant 6. User B6 sends a request called the New request to update cache settings, while MT 3 from the cluster is not functional. |
| S2 | The load balancer routes the Submitted request to MT 3. | N2 | The load balancer routes the New request to another functional mid tier in the cluster, MT 4. |
| S3 | While processing the Submitted request, MT 3 crashes. The Submitted request is incomplete. A functional mid tier in the cluster, MT 4, picks up the Submitted request. | N3 | MT 4 sends the New request to Tenant 6, who updates the cache settings. MT 4 completes the New request. User B6 is not aware of the failed mid tier in the cluster, and which mid tier actually completed the request. |
| S4 | MT 4 sends the Submitted request to Tenant 4, who returns the resulting 1000 records to User B4. MT 4 completes the Submitted request. When MT 3 fails, User B4 does not have log on again and resubmit the request. User B4 is not aware of which mid tier has completed the Submitted request. | — | — |
| You can achieve high availability of mid tier by deploying the mid tier as a shared service. | |||
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.
| Scenario | A high number of user requests require extra capacity of a mid tier |
|---|---|
| Issue | In a single mid tier environment, a high number of requests from the tenant users create heavy workload on the mid tier. |
| Solution | Deploy the mid tier as a shared service |
| Description | When a high number of user requests require extra capacity of an additional mid tier, you can add a mid tier to the cluster. The newly added mid tier seamlessly starts serving requests and shares the load along with other mid tiers in the cluster. Conversely, with a decrease in number of user requests, if a mid tier is no longer required, you can remove a mid tier from the cluster. The remaining mid tiers can handle the load without affecting system performance. |
| Benefit | With mid tier as shared service, you can achieve serviceability by dynamically adding or removing mid tiers from the cluster, and you can manage load more efficiently. |
The following table explains the two scenarios depicted in the graphic:
| Scenario | Adding a mid tier to the cluster to server high number of requests | Scenario | Removing a mid tier from the cluster |
|---|---|---|---|
| Step | Description | Step | Description |
| 1. | You have three tenants and two mid tiers operating in Cluster B, which serves requests from 2500 users. | 1. | You have three tenants and N number of mid tiers operating in Cluster A, which serves requests from 1000 users. |
| 2. | You find that each mid tier is serving more than 80 percent of its capacity and you expect the load to increase further. | 2. | You find that each mid tier is serving less than 50 percent of its capacity, and you do not expect the load to increase further. |
| 3. | You add an extra mid tier (N+1) to Cluster B and distribute the load equally among all mid tiers. | 3. | You remove one mid tier (N-1) from Cluster A, and distribute the load equally among remaining mid tiers. |
| 4. | You are able to handle more load efficiently, and are able to achieve serviceability. | 4. | You are able to handle less load with fewer resources, and are able to achieve serviceability. |
| You can achieve serviceability by adding or removing mid tiers from the cluster, and you can manage load more efficiently. | |||
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.
| Scenario | You need to add a new tenant to a mid tier cluster, or remove a tenant from the cluster. |
|---|---|
| Issue | In an environment without mid tier as a shared service, you cannot add more than one tenants to a mid tier. |
| Solution | Deploy the mid tier as a shared service. |
| Description | With the mid tier as a shared service, you can dynamically add (onboard) or remove (offboard) tenants from a mid tier cluster.
|
| Benefit | Because you can add or remove tenants from a cluster dynamically, you can achieve scalability. |
The following table explains the two scenarios depicted in the graphic:
| Scenario | Onboarding a new tenant to a cluster | Offboarding a tenant from a cluster | |
|---|---|---|---|
| Step | Description | Step | Description |
| 1. | A new customer is added to your environment, and you need to provision a tenant for the customer. | 1. | Tenant 3 from Cluster A needs to be moved to another cluster in your environment. |
| 2. | You add a new tenant and onboard the tenant to Cluster B | 2. | You offboard Tenant 3 from Cluster A and move it to another cluster. |
| You can achieve scalability by dynamically adding or removing tenants from the the clusters in your environment. | |||
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.
| Scenario | Resource optimization with mid tier as a shared service |
|---|---|
| Issue | In an environment without the a mid tier as a shared service, because you require separate mid tiers for each tenant, more resources are consumed. |
| Solution | Configure a mid tier as a shared service. |
| Description | With a multitenant mid tier cluster, the same mid tiers in a cluster serve multiple tenants at the same time, so that fewer resources are consumed. |
| Benefit | Resource optimization is achieved. |
The following table describes these scenarios:
| More resources are required without the mid tier as a shared service | Fewer resources are required with the mid tier as a shared service |
|---|---|
In this scenario, you require six mid tiers to serve four tenants. |
In this scenario, only two mid tiers are required to serve four tenants. With mid tier as a shared service, fewer resources are required, and you can achieve resource optimization. |
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.
| Scenario | Optimum utilization of mid tiers in the cluster |
|---|---|
| Issue | In an environment without the mid tier as a shared service, a high number of requests from the tenant users creates a heavy workload on the mid tier. The mid tier can fail due to overutilization. Conversely, a lower number of user requests compared with what a mid tier is configured to handle, means underutilization. |
| Solution | Configure a mid tier as a shared service to achieve optimum utilization of all the mid tiers in your environment. |
| Description | The load balancer distributes the requests from users of all the tenants to all mid tiers in the cluster, so that neither mid tier is over or underutilized. Note: The actual workload distribution depends upon the load balancer rules and workload distribution algorithm, which is not in the scope of this documentation. |
| Benefit | The workload is distributed evenly across all mid tiers in the cluster. Optimum utilization of mid tiers is achieved with mid tier as a shared service. |
The following graphic demonstrates this scenario:
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:
| Overutilization or underutilization of resources in an environment without the mid tier as a shared service | Optimum resource utilization with the mid tier as a shared service |
|---|---|
Assume the following scenario:
| The above graphic depicts the following scenario:
You can achieve optimum resource utilization by deploying mid tier as a shared service. |
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.
Related topics
Enterprise Centralized Configuration Server as a shared service
Guidelines for tenants in shared service
Guidelines for deploying a load balancer in a shared services architecture
Comments
Log in or register to comment.