Professional Documents
Culture Documents
November 2009
If you have comments or suggestions about this documentation, contact Information Design and Development by
email at .
Support website
You can obtain technical support from BMC Software 24 hours a day, 7 days a week at . From
this website, you can:
Read overviews about support services and programs that BMC Software offers.
Find the most current information about BMC Software products.
Search a database for problems similar to yours and possible solutions.
Order or download product documentation.
Report a problem or ask a question.
Subscribe to receive email notices when new product versions are released.
Find worldwide BMC Software support center locations and contact information, including email addresses, fax numbers,
and telephone numbers.
Overview
This document is an update to Reference Architecture for BMC Service Support
Solutions, originally published in March, 2009. This version includes recommendations
for deployments based on the BSM 7.6 components. For specific version numbers, see
“Service Support solution components” on page 8.
“The AR System environment”, page 9 – All AR System and BMC Atrium CMDB
components
6
BMC Analytics environment – The BMC Analytics product
Scalability information – Details about how the components scale between small,
medium, and large implementations. These pointers will help fine tune your
installations.
Deployment choices are not considered in this document. For example, for a
distributed AR System installation, you will need to size each installation
separately based on the load it will be subjected to.
The AR System installation size is increased to reflect the latest benchmark data
available.
The information about BMC Configuration Discovery has been removed. For
information about BMC Configuration Discovery, refer to the white paper Reference
Architecture for Service Automation Solutions, which is available at
http://www.bmc.com/support.
Note: Some components are not specifically discussed in this document because they are
not relevant for determining system size.
Sizing factors
The AR System server and the Mid-Tier scale horizontally, so more servers can be added
to the load balanced environment for handling more load. The sizing factor for the AR
System environment is the number of concurrent users.
Sizing factor:
Number of concurrent users
Small 800
Medium 2000
Large 5000
In the absence of this data, BMC suggests the following rough guidelines as a starting
point for working with BMC Service Request Management. These numbers are a good
place to start, but they should not be considered as overall recommendations.
For BMC Service Request Management, BMC suggests an estimate of 1 concurrent user
for every 100 potential end users. For example, if a company has 10,000 users who will
be using this application, then we can estimate that the server will experience 100
concurrent users.
For all other BMC Remedy AR System based applications, BMC suggests estimating the
number of concurrent users based on the system being replaced or upgraded.
The size of attachments varies widely. If more accurate numbers are available from
existing application data for the organization, use the organization’s data rather than
these estimated attachment sizes.
Ticket Type Average Size including attachment (kb) Attachment Size (kb)
Incident 41 6
Problem 71 36
Change 72 48
Task 20 3
CI in Asset dataset 28 -
CI in imported dataset* 17 -
*Each CI will exist in the Asset dataset, as well as in each imported dataset
If reports can be run at off-peak hours, then an installation might be able to get by with
using an existing server to run reports. But if reports are run on demand or during peak
hours, or the organization does not have off-peak hours, BMC recommends using a
separate AR System server for running reports.
The AR System and Mid-Tier both scale horizontally, so that adding more servers allows
the system to handle additional load.
You can configure the AR System load balanced environment to direct user interactions
to the load balanced servers, while assigning certain other functions and responsibilities
to specific instances of the AR System server. For example, escalations can be limited to
a single server to ensure that no other server is bogged down with this activity.
Using servers dedicated to specific functions provides an excellent way to scale the
installation. The medium and large configurations described in this document use a
dedicated integration server. This server is not part of the load balanced environment, and
so does not see any end user activity. However, it is part of the AR System server group
and so uses the same database. To relieve the load on other servers in the group, assign
all batch and integration operations such as reconciliation, Atrium Integration Engine
(AIE), 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.
BMC recommends a maximum of 400 concurrent users per servlet engine instance
for most servlet engines.
While a single mid tier can handle the load of a small installation, BMC recommends
using at least two mid tier computers to provide high availability and fail-over
capability.
BMC recommends that you deploy the same number of Mid-Tier machines as the
number of AR Server machines on the load balancer.
AR System servers
Each AR System server can handle from 150 – 200 concurrent users per CPU core.
Note: Niagara T1/T2 chips can handle more along 250-300 concurrent users/CPU-
core.
On non-Windows servers, the AR System server operates as a 64-bit process and can
support up to 1200 concurrent users per AR System server. With more than about
800 concurrent users, the server requires about one second of additional response
time for every 200 additional concurrent users during some operations such as
opening the Incident or Change Management consoles. 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 virtual machines on the same hardware and configure each with up to 60
threads.
For medium and large installations, one AR System server is dedicated for
integration purposes such as running the Reconciliation Engine, AIE, and DSO.
The servers processing user requests require 4 GB of RAM. This accommodates the
AR System server, BMC Atrium and its components, This does not included the web
services components, which are located on the integration servers.
While a single computer can handle the load for a small installation, BMC
recommends using two machines in a server group to provide high availability and
fail-over capability.
Database servers
The size of the database is highly dependent on the way the system is used. The
number and size of attachments can change the database size significantly.
For large installations, use the enterprise capabilities of your database to increase
scalability and availability. Oracle RAC is one such option.
The AR Server does not cache data, and so is highly dependent on a fast, reliable, and
low latency connection to the DB server. Any additional hop / packet screener /
firewall will impact performance.
Sizing the web server machines for this product is highly dependent on the extent to
which this solution is used, and the number of knowledge entries made. A general rule of
thumb is to estimate the number of web server machines for Remedy Knowledge
Management as half those required for the mid tier servers.
Hardware requirements
The tables in this section describe BMC’s recommended hardware platform sizing for
small, medium, and large implementations of the AR System environment.
Please note that the sizings listed below assume one additional server for redundancy
(N+1).
Mid Tier servers
RAM: 2 GB 2 GB 2 GB
DISK: 20 GB 20 GB 20 GB
Number of Servers 2 3 4
AR System servers
DISK: 40 GB 40 GB 40 GB
RAM: 8 GB 16 GB 32 GB
DISK:* 40 GB 40 GB 40 GB
** BMC recommends using the clustering and high availability features provided by the
database vendor
Sizing factor
Number of concurrent users 800
Sizing factor
Number of concurrent users 2000
Sizing factor
Number of concurrent users 5,000
Sizing factors
Sizing for the servers and database is based on the number of discovered CIs. To estimate
the total number of CIs, you must estimate the number of CIs by compiling an estimate of
various types of endpoints, the number of employees in the organization, and the number
of logical servers (such as database and application servers) in the organization.
Sizing factor:
Number of CIs discovered
To estimate the number of CIs discovered per each type of endpoint, such as computers,
routers, and switches, use the guidelines in this table:
Device Platform Number of CIs
UNIX® 2,000
Note: The last row in the preceding table uses the following two assumptions, which
should be adjusted based on the customer’s requirements.
If accurate numbers for routers and other components are not available, use the number
of employees and the number of logical servers in the organization to get a quick estimate
of the total number of CIs:
Devices to be discovered Guideline for estimating devices
The following sizes are based on the number of endpoints from the Configuration
Discovery section. Using the assumption that 250 CIs are discovered per endpoint, the
following table describes sizing for the BMC Discovery environment:
Small 2,000,000
Medium 7,500,000
Large 15,000,000
BMC recommends that each BMC Discovery server should have its own database
instance. All the instances can be hosted on the same physical machine, as long as each
instance has the recommended resources available to it.
Note: The number of CIs per client and server computer varies widely from one
customer to the next. The assumption made in this document for 250 CIs per computer is
not representative of all customers. Use this value as an example.
Hardware requirements
The tables in this section describe BMC’s recommended hardware platform sizing for
small, medium, and large implementations of the BMC Discovery environment.
RAM: 4 GB
DISK: 40 GB
RAM: 4 GB 4 GB 4 GB
# of Servers 2 3 6
Database servers
You need one database instance per BMC Discovery server. Each instance can have the
following minimum resources available to it:
Per instance
RAM: 4 GB
DISK: 40 GB
Note: Multiple instances of the database can be hosted on the same computer.
Accordingly, BMC recommends the following sizing configurations for the BMC
Discovery database servers:
Medium(7.5 Large(15
Small (2 Million)
Million) Million)
RAM: 4 GB 8 GB 16 GB
# of Servers 2 2 4
Sizing factors
The BMC Analytics product is based completely on Business Objects, and so the task of
sizing the installation is really about sizing the Business Objects server and software. The
guidelines in this document have the following limitations:
It is assumed that the installed system is being used for BMC Analytics only.
Sizing is provided for the Central Management Server and the Web Intelligence
Report Server. Depending on your requirements you might need to install additional
components. For sizing information including for other components, refer to the
Business Objects Enterprise XI Sizing Recommendations guide provided by Business
Objects.
Sizing factor:
Number of concurrent active users
To size the BMC Analytics installation, estimate these two numbers:
Potential users
Potential Users
Potential users (Named Users) is the number of users who are able to log on to the
system. This is the easiest number to calculate because it represents the total population
of users who have the ability to access the Enterprise XI environment
According to Business Objects, many customers find that their concurrency ratios
average from 10% to 20% of their total potential user base. For example, with 1000
potential users, use an estimate of 100 to 200 concurrent active users. This number can
vary significantly depending on the nature and breadth of the deployment, but is a
reasonable general guideline for planning purposes.
Hardware requirements
This section describes the recommended hardware requirements for the BMC Analytics
environment.
One CMS service for every 600 - 700 concurrent active users
Sizing factors
Sizing factors:
Number of concurrent users
CI/request ratio (Number of CIs per incident/change/problem/service
requests/SLM ticket)
Assumptions:
Average report file size: 500K
SIM # CI’s
Deployment size # of concurrent users CI/request ratio per service
model
Hardware requirements
This section describes hardware sizing for a single-server deployment and a dual-server
deployment. In a single-server deployment, the Dashboard server and the Data
Integration Layer (DIL) are installed on the same computer. In a dual-server deployment,
they are installed on separate computers.
Single-server deployment
Small (<25) Medium(25-50) Large(>50)
RAM: 4 GB 4-8 GB 8+ GB
Dashboards
AR System Database
Many deployments will be much more complex, considering that customers can have
varying requirements for distributed systems, archiving, disaster recovery, etc. The
architecture presented here makes some simplifying assumptions which are presented in
the next section.
Architecture Assumptions
This architecture is based on the following assumptions:
Centralized Deployment
This is a single site (centralized) installation rather than a distributed installation. It is
capable of serving remote customers as well, but it does not present any steps taken to
improve performance for remote customers.
For Disaster recovery, it is required that for each component, you set up and maintain a
separate database.
For disaster recovery (DR), a separate database instance is used, and data is moved from
the production instance to the DR instance using database tools. This would mean that in
case of a disaster, the data would be secure even if the service is not available. If the
customer requires the service to be fully available in case of a disaster, then the complete
AR System installation would need to be replicated along with the DR database instance.
Analytics
The customer is using BMC Analytics for reporting. This tool generates reports from the
reporting and archiving database instance.
If the customer desires high availability or disaster recovery for this tool, it will require a
redundant setup in production, and a DR instance in the DR setup.
Dashboards
The customer is using Dashboards to track system usage and performance. This tool gets
its data directly from the production database instance.
If the customer desires high availability or disaster recovery for this tool, it will require a
redundant setup in production, and a DR instance in the DR setup.
Discovery tools
Both BMC Configuration Management Discovery and BMC Foundation Discovery /
BMC Topology Discovery tools are in use. Each has its own database server.
The integration server is used to bring the data from the discovery databases into the
CMDB. BMC Atrium Integration Engine is used to bring data from the Configuration
Discovery database into the CMDB and BMC Topology Discovery or BMC Foundation
Discovery pushes the data directly into the CMDB using the API.