Unsupported content

   

This version of the documentation is no longer supported. However, the documentation is available for your convenience. You will not be able to leave comments.

BMC AR System and BMC Atrium Core CMDB sizing and scalability

The BMC Remedy AR System (AR System) and BMC Remedy Mid Tier products both scale horizontally, so adding more servers allows the system to handle additional load. You can configure AR System in a load-balanced environment to direct user interactions to the load-balanced servers while assigning other functions and responsibilities to specific instances of AR System server. For example, you can limit escalations to a single server to ensure that no other server is hampered by this activity.

Note

As an option, you can integrate BMC Change Management running on a remote ITSM server with BMC Cloud Lifecycle Management. BMC Remedy IT Service Management is not installed by default on the BMC AR System Server – Cloud Portal and Database server.

Dedicating servers to specific functions is an excellent way to scale the installation. The baseline configuration described in this document does not use a dedicated integration server. To relieve the load on other servers in the group, assign all batch and integration operations such as reconciliation, Atrium Integrator(AI) and escalations to this server.

In an AR System server group, the host computers do not all require the same processing power and memory. For example, the integration server can use a computer with higher or lower processing power and memory.

Mid tier servers

Each mid tier can handle up to 200 peak concurrent users per virtual CPU and 400 peak concurrent users per 2 CPU virtual machine (VM).

  • Although a single mid tier can handle the load of a baseline installation, BMC recommends using at least two mid tier computers to provide high availability and failover capability.
  • BMC recommends that you deploy the same number of mid tier computers as the number of BMC Remedy AR System server computers on the load balancer.

BMC Remedy AR System servers

Each AR System server can handle from 150 – 200 peak concurrent users per virtual CPU.

Niagara T1/T2 chips can handle 250 – 300 concurrent users/CPU-core. 

  • For a VMware system, consider mapping 1 CPU-core to 1 virtual CPU.
  • AR System server operates as a 64-bit process and can support up to 1200 concurrent users per server. The memory footprint of the AR System server at 1200 concurrent users is usually stable at about 2 to 3 GB, but can reach 4 to 5 GB.
  • On all platforms, when configuring the AR System server threads, do not exceed about 60 to70 threads for all list, fast, and private queues. At higher thread levels, the throughput stagnates and can even be reduced. Rather than increasing the number of threads in one server beyond this number, BMC recommends that you add multiple servers in VMs on the same resource and configure each with up to 60 threads.
  • Although a single computer can handle the load for a baseline installation, BMC recommends using two VMs in a server group to provide high availability and failover capability.

Sizing the AR System environment

The sizing factor for the AR System environment is the number of concurrent users.

Note

The baseline assumes 100 peak concurrent AR System (BMC Service Request Management) users, but does not assume multiple AR System applications that are not specifically part of the baseline.

This section describes sizing factors, scalability information, and resource recommendations for the AR System environment. This includes AR System server, server-tier components such as Approval Server and the Assignment Engine, BMC Atrium CMDB components, mid tier, and BMC Service Request Management.

Back to top

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 Service Request Management application, if only a few services are deployed, the number of concurrent users will be low; if a large number of services are deployed, the system will experience 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, BMC suggests the following guidelines for creating an initial estimate on the number of concurrent users. Note that these are rules of thumb, and provide estimates rather than accurate numbers.

Type of user

Number concurrent

Service Desk

100% of total population

Self Service

1%-2% of total population

Administrators

100% of total population

BMC Analytics users

10-20% of total population

For example, if the customer has a IT staff of 900 employees, then probably 90 of them can be assumed to be be concurrent at any time. Similarly, if the customer has 100,000 employees who will be using SRM, the concurrent count can vary from 1000 (which is 1%) to 2000 (which is 2%). This high variance will need to be evaluated based on the customers plans to roll out services. If the customer intends to host a lot of services on SRM, then taking the high count is a good idea. If the customer plans to limit the number of services, then a smaller count can be used.

Back to top

AR System resource requirements

This section describes BMC recommended resource platform sizing for the baseline solution deployment architecture of the AR System environment.

Standard sizing templates for AR System environments

Virtual CPUs

Memory

Local storage

Number of servers or VMs

Mid Tier server

2 x 2.0 GHz+

4 GB

40 GB

2

AR System server

2 x 2.0 GHz+

4 GB

40 GB

2

Database server

8 x 2.0 GHz+

16 GB

100 GB

2 (Shared Environment)

Back to top

This version of the documentation is no longer supported. However, the documentation is available for your convenience. You will not be able to leave comments.

Comments