This documentation supports the 9.0 version of Remedy Action Request System.

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

Guidelines for BMC Remedy deployment architect

To ensure seamless failover and fast response time in the BMC Remedy environment, the deployment architect performs the following actions:

  • Lays down the deployment strategy and provides instructions to the BMC Remedy administrator to implement the deployment strategy. See the following figure for a sample deployment strategy.

    Note

    This diagram is only representative and does not indicate the actual number of tenants or mid tiers in any cluster.

  • Decides how many clusters to create to support the existing Remedy customers based on the benchmarking done for the RoD environment
  • Decides 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, four CPUs at 2.0 GHz with  8 GB RAM and a 120-GB hard disk drive.
    • Each computer must have only one Tomcat instance and only one mid tier installed within Tomcat.
    • 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.
  • Decides which tenants must be added to the same mid tier in a cluster based on the following guidelines:
    • The total number of concurrent users across all tenants added to a given mid tier cluster must be less than or equal to 2,500.
    • For a symmetric configuration with three backups, a single mid tier instance does not scale beyond 800 concurrent users. Remember these numbers while adding a tenant to a given mid tier.
    • To take full advantage of cache objects comparison and sharing, all tenants in a single mid tier must have the same number of languages. For example, if all tenants in a mid tier have views only in English in all BMC Remedy IT Service Management and BMC Service Request Management forms, maximum sharing of cache objects across the tenants is achieved.
    • Combine all the tenants that have the same version. For example, add all tenants that have BMC Remedy AR System 7604 SP2 to a single mid tier cluster.
    • Combine all tenants that have minimum customizations.
  • Decides the rules for the load balancer that are in line with the deployment strategy. For example, sticky session should always be used, but routing the requests to the appropriate clusters or mid tier must be based on which tenant is supported by which mid tier. Such rules must be defined when a decision on the final cluster and tenant deployment is made.
  • Defines the necessary rule changes for the n+1 scenario (that is, while temporarily adding a mid tier to or removing one from a cluster)
  • Identifies which mid tiers to add to a cluster
  • Assigns a unique cluster ID for each mid tier added to a cluster
  • Designates an AR System server as the Centralized Configuration Server (CCS)
  • Decides whether a dedicated cluster is required for a large Tier-1 tenant. Typically, tenants should not be used across clusters. A large tenant (Tier-1) can use a dedicated cluster for service.

Related topics

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

Comments

  1. John Lester

    The image does not appear on this page. It says "Unknown Attachment"

    Sep 22, 2015 02:06
    1. Vaijayanti Nerkar

      Thanks John for pointing this out. This image is visible internally but not externally to customers. There does not seem to be any restrictions for the image. We will work with our infrastructure team to get this sorted.

      Regards,

      Vaijayanti 

      Sep 22, 2015 10:48