Sizing and deployment considerations
To plan the sizing and deployment, you must consider the size of BMC HR Case Management environment that includes BMC Remedy Action Request System Server, BMC Remedy Mid Tier, and the databases.
This following sections in this topic gives guidance about estimating the number of concurrent users, graphic representation of small-scale and large-scale deployment, things to consider during virtualization, and so on:
Related topic
Use cases and value paths
Before you can determine sizing, you must understand the business and organizational requirements and use cases for each solution—number of users, transaction types and quantity, and customizations (for HR services and knowledge bases) that impact sizing. The following examples describe use cases, and factors that can impact sizing:
- Heavy case volume from issues management
- HR knowledge base management and Full Text Search (FTS)
- Large numbers of HR service catalog items (solutions)
- Integrations
Sizing your environment
The BMC Remedy Action Request System (BMC Remedy AR System) and BMC Remedy Mid Tier (Mid Tier) servers scale better horizontally than vertically. Although adding resources such as CPUs and memory to a server might be tempting, testing has shown a point of diminishing returns on performance in doing so. Scaling horizontally by adding more servers to a server group results in better and more consistent performance than scaling vertically.
You can configure BMC HR Case Management in a load-balanced environment to direct user interactions to the load-balanced BMC Remedy AR System mid tier and BMC Remedy AR System servers while assigning dedicated non-user functions and responsibilities to specific instances of the BMC Remedy AR System Server. For example, escalations, integrations, reconciliations, and notifications can be separated from "user" servers to ensure that these services do not impact user activity. This is a reliable way to provide consistent high-performance services as well as scale the installation safely.
Similar to dedicated BMC AR System Servers for nonuser-related functions, additional dedicated servers at the web tier should be considered if web services are implemented for BMC HR Case Management.
In a BMC Remedy AR System server group, the host computers do not all require the same processing power and memory. For example, the back-end servers can use servers with more or less processing power and memory.
Sizing in virtualization
Current sizing is based on CPU cores from physical hardware, not virtualization. Be aware that with hypervisor-based x86/x64 systems such as VMware ESX Server using multicore, multithreaded processors, hyperthreading can increase the number of virtual CPUs displayed and made available to the ESX Server. Assuming that a vCPU has the same processing power as a CPU core could negatively impact capacity planning.
Ensure that the following virtualization features are configured properly.
- Priorities related to resource pools (Do the BMC applications deployed in a virtual environment have the proper priority?)
- Distributed Resource Scheduling (DRS)
- VMware vMotion
- Affinity
If necessary, consult your virtualization expert for more details.
BMC Remedy Mid Tier servers and web infrastructure
Use at least two BMC Remedy Mid Tier servers to provide high availability and failover capability. Deploy the same number of mid tier servers as the number of "user loaded" BMC Remedy AR System servers. This assumes the AR System servers and mid tier servers are sized appropriately.
BMC Remedy AR System Server
BMC Remedy AR System Server operates as a 64-bit multithreaded processor, and can support up to 3,000 concurrent users per server. In BSM performance and scalability tests, the memory footprint of the 3,000 concurrent users of the BMC Remedy AR System Server and the mid tier server is stable at about 2 to 3 GB. In practice, however, the memory footprint can grow to 10 GB or more. The memory sizes, listed in the sizing baselines*, are the correct starting points.
BMC previously advised that 60 or 70 threads be considered the upper limit for all threads in total. The BSM performance white paper shows that significantly higher thread settings can be preferable. The correct way to tune threads is to use API Thread % Idle Time = 0s values from an API log analysis to find out what needs to be increased or can be decreased. If you can restart the server with thread logging on, you can observe when new threads are started up.
Estimating the number of concurrent users
The number of concurrent users depends on the total end-user population, and on the way the system is used. For example, with the BMC HR Case Management application, if only a few HR services (external solutions) are deployed, the number of concurrent users is low. If a large number of HR services are deployed, the system experiences a higher load.
The number of concurrent users is best established by looking at the load on the existing system that is being replaced or upgraded. In the absence of this data, use the following guidelines to create an initial estimate on the number of concurrent users. These guidelines give estimates rather than accurate numbers.
Type of user | Number of concurrent users |
|---|---|
HR agent | 10 percent of HR staff |
Self-service employee | 1 – 2 percent of total population |
HR administrator | 1 percent of HR staff |
For example, if you have an HR staff of 90 employees, all of whom use the BMC HR Case Management, you can assume that about 9 of them are concurrent at any time. Similarly, if you have 100,000 employees who are using BMC MyIT to request HR services (External Solutions), the concurrent count can vary from 1,000 (1 percent) to 2,000 (2 percent). You must evaluate this high variance based on your plans to roll out HR services. If you intend to host many HR services on the BMC HR Case Management, use the high count. If you plan to limit the number of HR services, use a smaller count.
Scalability for the HR knowledge base
BMC HR Case Management 4.7 uses the FTS service provided by BMC Remedy AR System for indexing. This requires the indexer to run on one of servers of the BMC Remedy AR System in a server group. Since this indexer consumes CPU, run it on a back end AR System Server (which is typically not serving online user traffic). The index should be local and not on a shared storage (NAS/SAN).
In addition to the indexer, each of the AR System servers in the server group has a service that reads information from the common index. This can also consume CPU cycles, thereby reducing the performance of the AR System server where the indexer resides. In general, the larger the size of the index is, the greater the effect on scalability.
Databases considerations
You might choose to host product installations on a single physical server, or on separate servers, or tiers. The decision is based on multiple factors, including but to limited to hardware and licensing costs, performance, administration and maintenance efforts, and security requirements.
Small-scale deployment model
The following diagram illustrates a generic, small-scale deployment suitable for up to 50 concurrent users.
Large-scale deployment model
The following diagram illustrates a generic, large-scale deployment suitable for up to 150 concurrent users.
Integration methods and data flows
The following diagram illustrates the integration methods, and data flow specific to BMC HR Case Management for a large-scale deployment.
Where to go from here