You are on page 1of 32

White paper

Reference Architecture for BMC


Service Support Solutions
using BSM 7.6 Components

November 2009

BMC Software, Inc., Confidential


Contacting BMC Software
You can access the BMC Software website at . From this website, you can obtain
information about the company, its products, corporate offices, special events, and career opportunities.
United States and Canada
Address BMC SOFTWARE INC Telephone 713 918 8800 Fax 713 918 8000
2101 CITYWEST BLVD or 800 841 2031
HOUSTON TX 77042-2827 USA
Outside United States and Canada
Telephone (01) 713 918 8800 Fax (01) 713 918 8000

If you have comments or suggestions about this documentation, contact Information Design and Development by
email at .

© Copyright 2009 BMC Software, Inc.


BMC, BMC Software, and the BMC Software logo are the exclusive properties of BMC Software, Inc., are registered with the U.S.
Patent and Trademark Office, and may be registered or pending registration in other countries. All other BMC trademarks, service
marks, and logos may be registered or pending registration in the U.S. or in other countries. All other trademarks or registered
trademarks are the property of their respective owners.
Linux is the registered trademark of Linus Torvalds.
UNIX is the registered trademark of The Open Group in the US and other countries.
Oracle is a registered trademark of Oracle Corporation.
BMC Software considers information included in this documentation to be proprietary and confidential. Your use of this
information is subject to the terms and conditions of the applicable End User License Agreement for the product and the proprietary
and restricted rights notices included in this documentation.
Restricted Rights Legend
U.S. Government Restricted Rights to Computer Software. UNPUBLISHED -- RIGHTS RESERVED UNDER THE COPYRIGHT
LAWS OF THE UNITED STATES. Use, duplication, or disclosure of any data and computer software by the U.S. Government is
subject to restrictions, as applicable, set forth in FAR Section 52.227-14, DFARS 252.227-7013, DFARS 252.227-7014, DFARS
252.227-7015, and DFARS 252.227-7025, as amended from time to time. Contractor/Manufacturer is BMC Software, Inc., 2101
CityWest Blvd., Houston, TX 77042-2827, USA. Any contract notices should be sent to this address.

BMC Software, Inc., Confidential 2


Customer Support
You can obtain technical support by using the Support page on the BMC Software website or by contacting Customer Support by
telephone or email. To expedite your inquiry, please see “Before Contacting BMC Software.”

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.

Support by telephone or email


In the United States and Canada, if you need technical support and do not have access to the Web, call 800 537 1813 or send an
| email message to . (In the Subject line, enter , such
as .) Outside the United States and Canada, contact your local support center for assistance.

Before contacting BMC Software


Have the following information available so that Customer Support can begin working on your issue immediately:
Product information
o Product name
o Product version (release number)
o License number and password (trial or permanent)
Operating system and environment information
o Machine type
o Operating system type, version, and service pack
o System hardware configuration
o Serial numbers
o Related software (database, application, and communication) including type, version, and service pack or
maintenance level
Sequence of events leading to the problem
Commands and options that you used
Messages received (and the time and date that you received them)
o Product error messages
o Messages from the operating system, such as file system full
o Messages from related software

3 BMC Software, Inc., Confidential


License key and password information
If you have a question about your license key or password, contact Customer Support through one of the following methods:
E-mail . (In the Subject line, enter , such as
.)
In the United States and Canada, call 800 537 1813. Outside the United States and Canada, contact your local support
center for assistance.
Submit a new issue at
.

BMC Software, Inc., Confidential 4


Contents
Overview ................................................................................................................... 6
How to use this document ..................................................................................... 6
Updates to this document ...................................................................................... 7
Service Support solution components ....................................................................... 8
The AR System environment .................................................................................... 9
Sizing factors ......................................................................................................... 9
Scalability information ........................................................................................ 11
Hardware requirements ....................................................................................... 13
Deployment logical diagrams .............................................................................. 14
BMC Atrium Discovery and Dependency Mapping ............................................... 18
Sizing factors ....................................................................................................... 18
Scalability information ........................................................................................ 20
Hardware requirements ....................................................................................... 20
Deployment logical diagram ............................................................................... 22
BMC Analytics Environment .................................................................................. 23
Sizing factors ....................................................................................................... 23
Hardware requirements ....................................................................................... 24
Deployment logical diagram ............................................................................... 25
BMC Dashboards Environment .............................................................................. 26
Sizing factors ....................................................................................................... 26
Hardware requirements ....................................................................................... 26
Deployment logical diagrams .............................................................................. 28
BMC Service Support Deployment ......................................................................... 29
Architecture Assumptions ................................................................................... 29
Architecture Notes............................................................................................... 30
Deployment logical diagram ............................................................................... 31

5 BMC Software, Inc., Confidential


White paper
Reference Architecture for BMC Service Support
Solutions using BSM 7.6 Components

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.

This document describes recommended physical reference architectures and platform


sizing requirements for example small, medium, and large deployments of the BMC
Service Support solution. The Service Support solution is based on BMC Remedy
Action Request System (AR System), and includes the BMC Atrium set of core
components and the BMC Service Support applications. The purpose of this document is
to assist BMC customers, BMC Partners, and BMC Consulting Services engineers who
are planning to deploy a Service Support solution, by describing the appropriate
scalability and sizing considerations for each component and for the overall solution.

This document does not include product-level installation, configuration, administration,


or deployment information.

How to use this document


This document contains the following sections pertaining to the main component
environments. You can ignore the sections about products not part of your installation.

“The AR System environment”, page 9 – All AR System and BMC Atrium CMDB
components

BMC Atrium Discovery and Dependency Mapping--the BMC Discovery and


Dependency Mapping product

6
BMC Analytics environment – The BMC Analytics product

BMC Dashboards environment – The BMC Dashboards product


Review the following information to plan the hardware platform sizing for your project:
Sizing factors – The parameters used to describe the load, for example, the number
of concurrent users. Gather this information to determine sizing for your project and
use the recommendations in this guide.

Scalability information – Details about how the components scale between small,
medium, and large implementations. These pointers will help fine tune your
installations.

Hardware requirements – Details about the hardware required to support the


appropriate size installation.

Many computers now use dual-core or multi-core processors, which allows


multithreaded applications such as the AR System server to make better use of
parallel processing. The term “CPU-core” is used in this document to describe the
sizing of computers. This provides an approximation of the amount of parallel
processing available, whether the computer actually has multiple single-core
CPUs, or a single multi-core CPU. Because CPU capabilities can vary by vendor,
BMC recommends that you evaluate this metric based on the vendor’s
documentation about hardware performance.

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.

Sizing diagrams – Schematic diagrams illustrating the recommended reference


architectures for example small, medium, and large installations. These summarize
the hardware requirements and sizing factors described in the other sections.

Updates to this document


The following information has been updated since the publication of Reference
Architecture for Service Support Solutions in March, 2009:

The scalability information for the AR System environment.

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.

7 BMC Software, Inc., Confidential


The RAM requirements for each machine have been updated to account for
additional components, such as the Atrium components, and for operating system
needs.

Service Support solution components


The components of a Service Support solution can vary depending on the business needs
and size of the deployment. The following table summarizes the possible components and
sub-components of the solution. These are all part of the BSM 2.6.6 release.

Note: Some components are not specifically discussed in this document because they are
not relevant for determining system size.

BMC Component Subcomponents Environment location


BMC Atrium BMC Remedy Action Request System: (7.5.00 BMC Remedy AR System environment
patch 3)
AR System server
BMC Remedy Mid Tier
BMC Remedy Approval Server
BMC Remedy Assignment Engine
BMC Atrium Core (7.6) BMC Remedy AR System environment
CMDB
Product Catalog

BMC Discovery and Dependency Mapping


(7.5.01) BMC ADDM environment

BMC Analytics for BSM (2.5.01) BMC Analytics environment

BMC Dashboards for BSM (2.5.01) BMC Dashboard environment

BMC Remedy Service Level Management BMC Remedy AR System environment


(7.5.00 patch 1)
Service Support BMC Remedy Asset Management (7.6) BMC Remedy AR System environment
applications
BMC Remedy Change Management (7.6) BMC Remedy AR System environment

BMC Remedy Service Desk: Incident BMC Remedy AR System environment


Management (7.6)
BMC Remedy Service Desk: Problem BMC Remedy AR System environment
Management (7.6)
BMC Remedy Service Desk (7.6) BMC Remedy AR System environment

BMC Service Request Management (7.6) BMC Remedy AR System environment

BMC Software, Inc., Confidential 8


The AR System environment
This section describes sizing factors, scalability information, and hardware
recommendations for the AR System environment. This includes the AR System server,
server tier components such as Approval Server and the Assignment Engine, BMC
Atrium CMDB components, the BMC Remedy Mid Tier, and the ITSM applications.
Sizing diagrams that summarize these recommendations appear at the end of the section.

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

Deployment size Number of concurrent users

Small 800

Medium 2000

Large 5000

Estimating the number of concurrent users


The number of concurrent users is dependent on the total end user population, and also on
the way the system is used. For example, with the BMC Service Request Management
application, if only a few services are deployed, then the number of concurrent users will
be low, but if a large number of services are deployed, then the system will experience
higher load. This 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 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.

9 BMC Software, Inc., Confidential


Sizing the Database
To determine the size of the database, use ticket sizes. The values in the following table
provide a rough estimate of ticket sizes for the Incident Management, Problem
Management, and Change Management applications. Adjust these estimates according to
the following considerations:

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.

Add 10 GB to the estimate to account for the foundation data.

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

Sizing for reports


Running reports can put a large load on an installation, consuming a significant portion of
the AR System server and databases resources. This can be disruptive to other users of
the system.

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.

If reports execute large or long-running queries in the database, it is best to set up a


separate database instance as well. The report database can be synchronized with the
primary database using database tools, or by setting up the Distributed Service Option
(DSO) between the AR System servers.

BMC Software, Inc., Confidential 10


Scalability information
This section describes scalability points and methods for the AR System environment.

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.

Mid Tier servers


Each Mid Tier can handle up to 200 concurrent users per CPU.

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.

For a VMWare system, consider mapping 1 CPU-core to 1 virtual CPU.

11 BMC Software, Inc., Confidential


On Windows the AR System server runs as a 32-bit process and can support up to
600 concurrent users per AR System server. Beyond this number of users, the process
memory footprint can become too large and make the process unstable.

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.

Integration servers require 10 GB of RAM to account for the additional processes


such as AIE, reconciliation, and the BMC Atrium web services components.

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.

For 64-bit databases, double the RAM requirements described below.

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.

BMC Software, Inc., Confidential 12


BMC Remedy Knowledge Management Servers

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

Small (800) Medium(2000) Large(5000)

CPU-cores: 4 x 2.0 GHZ+ 4 x 2.0 GHZ+ 8 x 2.0 GHZ+

RAM: 2 GB 2 GB 2 GB

DISK: 20 GB 20 GB 20 GB

Number of Servers 2 3 4

AR System servers

Small(800) Medium(2000) Large(5000)

CPU-cores: 4 x 2.0 GHZ+ 8 x 2.0 GHZ+ 8 x 2.0 GHZ+

4 GB(10GB for 4GB (10GB for 4GB (10GB for


RAM: the integration the integration the integration
server) server) server)

DISK: 40 GB 40 GB 40 GB

2+1 3+1 4+1


Number of Servers integration integration integration
server server server

13 BMC Software, Inc., Confidential


Database servers

Small(800) Medium(2000) Large(5000)

CPU: 8 x 2.0 GHZ+ 16 x 2.0 GHZ+ 32 x 2.0 GHZ+

RAM: 8 GB 16 GB 32 GB

DISK:* 40 GB 40 GB 40 GB

Number of Servers 1** 1** 1**


*Database size is for the database server – the data needs to be sized separately.

** BMC recommends using the clustering and high availability features provided by the
database vendor

Deployment logical diagrams


The diagrams in this section summarize the recommended reference configurations for
the BMC Remedy AR System environment, which includes the BMC Remedy and BMC
Atrium core components. Each diagram includes a table of sizing factors for ease of
reference.

BMC Software, Inc., Confidential 14


Figure 1: Small AR System environment

Sizing factor
Number of concurrent users 800

15 BMC Software, Inc., Confidential


Figure 2: Medium AR System environment

Sizing factor
Number of concurrent users 2000

BMC Software, Inc., Confidential 16


Figure 3: Large AR System environment

Load balancer Web clients

o BMC Remedy Mid Tier


o BMC Remedy Knowledge Management

Cores: 8 x 2.0 GHZ+


RAM: 2 GB
Disk: 20 GB
Servers: 4
Mid Tier servers

Load balancer Windows clients

o BMC Remedy AR System server


o BMC Atrium CMDB
o BMC Atrium Product Catalog
o BMC Remedy Approval Server
o BMC Remedy Assignment Engine
o BMC Remedy Email Engine
o BMC Remedy Asset Management
o BMC Remedy Change Management
o BMC Remedy Service Desk
o BMC Service Level Management
o BMC Service Request Management
o BMC Atrium Integration Engine
Cores: 8 x 2.0 GHZ+
RAM: 4 GB / 10GB for
integration server
AR System server group Disk: 40 GB
Servers: 4 + integration

Database server Cores: 32 x 2.0 GHZ+


RAM: 32 GB
Disk:* 40 GB
Servers: 1**
*Database size is for the database server – the data needs to be
sized separately.

Sizing factor
Number of concurrent users 5,000

17 BMC Software, Inc., Confidential


BMC Atrium Discovery and Dependency Mapping
This section describes sizing for BMC ADDM.

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

Desktop or server (not discovering hardware and NA 10


software)

Desktop (discovery of hardware only) Windows 80

Desktop (discovery of software only) Windows 400

Desktop (discovery of software and patches) Windows 500

Enterprise server (discovery of software and Windows 1,000


patches)
Linux® 1,500

UNIX® 2,000

Typical small LAN switch without VLAN (24 NA 250


Network Interface Cards, or NICs)

Typical small LAN switch with VLAN (24 NICs) NA 500

Core LAN switch without VLAN (500 NICs) NA 5,000

Core LAN switch with VLAN (500 NICs) NA 10,000

Typical small edge router (6 NICs) NA 80

Core router NA 5,000

Note: The last row in the preceding table uses the following two assumptions, which
should be adjusted based on the customer’s requirements.

BMC Software, Inc., Confidential 18


 The number of CIs discovered per machine (desktop or server) is 500 (including
hardware and software).

 The number of CI’s discovered per logical server is 50.

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

Number of employees Provided by the customer.

A Number of desktops or laptops Equals the number of employees

B Number of physical servers Equals 5 to 10 percent of A

C Number of switches Equals 5 percent of A

D Number of routers Equals the number of data centers and


remote sites

E Number of active devices Equals 20 percent of the sum of C and D

F Total number of hardware devices Equals sum of A, B, C, D, and E

G Application servers, database servers, Provided by the customer.


and logical components

Total number of CIs (assuming no F * 500 + 50 * G


software or patches are discovered on
any device)

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:

Deployment Size Number of CIs enterprise wide

Small 2,000,000

Medium 7,500,000

Large 15,000,000

19 BMC Software, Inc., Confidential


Scalability information
A single BMC Discovery server is capable of handling 2.6 million CIs. To increase the
capacity of your installation, or to improve the performance of your installation, add
another server.

Sizing the database


The BMC Discovery database requires the following amount of disk space:

Without CMDB synchronization, 2.4 GB per million CIs

With CMDB synchronization, 4.8 GB per million CIs

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.

BMC Discovery servers


You need one server per 2.6 million CI’s. Each server should have the following
minimum configuration.
Per server

CPU: 2 x 2.0 GHZ+

RAM: 4 GB

DISK: 40 GB

BMC Software, Inc., Confidential 20


Therefore, BMC recommends the following sizing configurations for the BMC
Discovery servers:
Medium (7.5 Large (15
Small (2 Million)
Million) Million)

CPU: 2 x 2.0 GHZ+ 4 x 2.0 GHZ+ 4 x 2.0 GHZ+

RAM: 4 GB 4 GB 4 GB

DISK: 40 GB 100 GB 200 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

CPU: 2 x 2.0 GHZ+

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)

CPU: 2 x 2.0 GHZ+ 4 x 2.0 GHZ+ 4 x 2.0 GHZ+

RAM: 4 GB 8 GB 16 GB

DISK: 40 GB 100 GB 200 GB

# of Servers 2 2 4

21 BMC Software, Inc., Confidential


Deployment logical diagram
Figure 4: BMC Atrium Discovery and Dependency Mapping environment

BMC Software, Inc., Confidential 22


BMC Analytics Environment
This section describes sizing for the BMC Analytics environment.

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

Concurrent active 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

Concurrent Active Users


This is an estimate of the number of users who are expected to be concurrently logged on
and actively interacting with the system (clicking on folders, viewing reports, scheduling,
and so on.) Do not include users who are logged on but inactive in this estimate.

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.

23 BMC Software, Inc., Confidential


Database Sizing
BMC Analytics can use the AR System database, but this might affect the performance of
the database server. BMC recommends that you use a separate reporting instance of the
AR System database to support the Analytics environment.

Hardware requirements
This section describes the recommended hardware requirements for the BMC Analytics
environment.

Sizing for the Central Management Server


One CPU for every 500 concurrent active users

One CMS service for every 600 - 700 concurrent active users

4 GB of RAM memory for each CMS service.

Sizing for the Web Intelligence Report Server


One Processor for 25 – 40 concurrent active users

One Web Intelligence Report Server service for each processor.

4 GB of RAM memory per Web Intelligence Report Server service

BMC Software, Inc., Confidential 24


Deployment logical diagram
Figure 5: BMC Analytics environment

25 BMC Software, Inc., Confidential


BMC Dashboards Environment
This section describes sizing for the BMC Dashboards environment.

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

Small < 25 < 2,000 1,000

Medium 25 – 50 2,000 – 5,000 5,000

Large > 50 > 5,000 10,000

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)

CPU*: 2 x 2.0 GHZ+ 4 x 2.0 GHZ+ 4+ x 2.0 GHZ+

RAM: 4 GB 4-8 GB 8+ GB

DISK: 40 GB 100 GB 200 GB

BMC Software, Inc., Confidential 26


*These are Server class CPU’s not just a single core.
Dual-server deployment
Small Medium Large

Dashboard: 1 x 2.0 GHZ+ Dashboard: 2 x 2.0 GHZ+ Dashboard: 2 x 2.0 GHZ+


CPU*:
DIL: 1 x 2.0 GHZ+ DIL: 2 x 2.0 GHZ+ DIL: 2 x 2.0 GHZ+

Dashboard: 2 GB Dashboard: 4 GB Dashboard: 4+ GB


RAM:
DIL: 2 GB DIL: 4 GB DIL: 4+ GB

Dashboard: 20 GB Dashboard: 50 GB Dashboard: 100 GB


DISK:
DIL: 20 GB DIL: 50 GB DIL: 100 GB

*These are Server class CPUs, not just a single core.

27 BMC Software, Inc., Confidential


Deployment logical diagrams—BMC Dashboards
Figure 6: Option I--Single-server Deployment (combine Dashboard server with
DIL server)

Figure 7: Option II--Dual-server Deployment (separate Dashboard server and DIL


server)

Dashboards

Data Integration Layer

AR System Database

BMC Software, Inc., Confidential 28


BMC Service Support Deployment
This section puts together all the products and components we have covered so far, and
presents the architecture for a deployment that includes all these components.

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.

Reporting and Archiving requirements


This architecture assumes that reporting and archiving are done from the same database.
It assumes a mirror database is set up using the available database tools, and this serves
as both the archiving and reporting instance.

High Availability and Disaster Recovery requirements


It is assumed that this installation requires a high availability setup for the BMC Remedy
AR System, whereas the other components can be sized to exact requirements.

For Disaster recovery, it is required that for each component, you set up and maintain a
separate database.

29 BMC Software, Inc., Confidential


Architecture Notes

BMC Remedy Action Request System


AR System is set up with full redundancy for high availability, and has an integration
server that is dedicated to batch processes such as Reconciliation Engine and the Atrium
Integration Engine.

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.

Each discovery database is mirrored to create a DR database. In case of a disaster, the


data will be secure, but the service will be unavailable. If the customer needs the service
to be available during a disaster, a separate installation of the discovery tools with the DR
database will be required.

BMC Software, Inc., Confidential 30


Deployment logical diagram—Service Support
Figure 7: Combined environment

31 BMC Software, Inc., Confidential



114903

BMC Software, Inc., Confidential 32

You might also like