This documentation supports the 9.1 version of BMC Remedy ITSM Deployment.

To view the latest version, select the version from the Product version menu.

BMC Remedy Mid Tier as a shared service

This topic provides the following information:

Concept of the mid tier as a shared service

BMC 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 BMC Remedy Mid Tier, you can achieve the following benefits:

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

Tip

Required installation — BMC Remedy Mid Tier

To deploy BMC Remedy Mid Tier as a shared service, you must install  BMC 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:

ComponentNames
BMC Remedy Mid Tier clustersCluster A, Cluster B, Cluster C
BMC Remedy Mid Tiers (MT) in different clustersMT 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 ServerECCS

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.

Scenariomid tier crashes while serving a requestNew requests are submitted while a mid tier is down
IssueIn 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.
SolutionDeploy a mid tier as a shared serviceDeploy 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 tiersUpdating tenant specific settings
StepDescriptionStepDescription
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.

S2The load balancer routes the Submitted request to MT 3.N2The 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.

Back to top

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.

ScenarioA high number of user requests require extra capacity of a mid tier
IssueIn a single mid tier environment, a high number of requests from the tenant users create heavy workload on the mid tier.
SolutionDeploy 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:

ScenarioAdding a mid tier to the cluster to server high number of requestsScenarioRemoving a mid tier from the cluster
StepDescriptionStepDescription
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.

Back to top

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.

ScenarioYou need to add a new tenant to a mid tier cluster, or remove a tenant from the cluster.
IssueIn an environment without mid tier as a shared service, you cannot add more than one tenants to a mid tier.
SolutionDeploy 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.

  • Onboarding a new tenant — You can onboard a tenant to a cluster in the following situations:
    • If a new customer subscribes to the environment.
    • A tenant is moved from one cluster to another.
  • Offboarding a tenant — You can offboard a tenant from a cluster in the following situations:
    • A customer is unsubscribed from the environment.
    • A tenant must be moved from one cluster to another.
BenefitBecause 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:

ScenarioOnboarding a new tenant to a clusterOffboarding a tenant from a cluster
StepDescriptionStepDescription
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 BMC Remedy ITSM Suite applications on all the tenants in the mid tier cluster.

Back to top

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

IssueIn an environment without the a mid tier as a shared service, because you require separate mid tiers for each tenant, more resources are consumed.
SolutionConfigure a mid tier as a shared service.
DescriptionWith 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.
BenefitResource optimization is achieved.


The following table describes these scenarios:

More resources are required without the mid tier as a shared serviceFewer resources are required with the mid tier as a shared service
  • MT 1 is associated only with Tenant 1, and MT 2 is associated only with Tenant 2.
    MT 1 and MT 2 do not form a cluster.
  • Cluster A contains mid tiers MT 3 and MT 4, but is not multitenant.
    Cluster A is associated only with Tenant 3.
  • Cluster C contains mid tiers MT 5 and MT 6, but is not multitenant.
    Cluster C is associated only with Tenant 4.

In this scenario, you require six mid tiers to serve four tenants.

  • Cluster B is a multitenant mid tier cluster, which contains MT 3, and MT4.
    Cluster B serves Tenant 1, Tenant 2, Tenant 3, and Tenant 4.

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

IssueIn 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.
SolutionConfigure 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.

BenefitThe 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:
  • MT 3 is associated only with Tenant 4, and handles 500 requests.
  • Because MT 3 has a threshold of 1000 requests, MT 3 is not utilized completely.
  • MT 4 is associated only with Tenant 6, and handles 1000 requests.
  • Because MT 4 has a threshold of 1000 requests, MT 4 is completely utilized.
The above graphic depicts the following scenario:
  • MT 3 and MT 4 are clustered in Cluster B.
  • Cluster B is multitenant, and has the following tenants onboarded:
    • Tenant 4 with 500 users.
    • Tenant 6 with 1000 users.
  • MT 3 and MT 4, have to serve in all 1500 requests from users of Tenant 4 and Tenant 6.
  • Because the load balancer distributes the requests across all mid tiers in the cluster, MT 3 and MT 4 each handles an average of 750 requests. Neither mid tier in the cluster is overutilized or underutilized.

You can achieve optimum resource utilization by deploying mid tier as a shared service.

Back to top

Guidelines for deploying mid tier as a shared service

Review the following guidelines before you configure BMC 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 BMC 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 BMC Remedy AR System online documentation.

Back to top

Related topics

Enterprise Centralized Configuration Server as a shared service

Tenants in shared service

Load balancer in shared service

Was this page helpful? Yes No Submitting... Thank you

Comments