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.
- 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
Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*