Reference Architecture for BMC Service Support Solutions Using BSM 7.6 Components
-
Upload
matevzzorman -
Category
Documents
-
view
1.079 -
download
2
Transcript of Reference Architecture for BMC Service Support Solutions Using BSM 7.6 Components
BMC Software, Inc., Confidential
White paper
Reference Architecture for BMC
Service Support Solutions
using BSM 7.6 Components
November 2009
BMC Software, Inc., Confidential 2
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
2101 CITYWEST BLVD
HOUSTON TX 77042-2827 USA
Telephone 713 918 8800
or 800 841 2031
Fax 713 918 8000
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.
3 BMC Software, Inc., Confidential
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
BMC Software, Inc., Confidential 4
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
.
5 BMC Software, Inc., Confidential
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
6
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
7 BMC Software, Inc., Confidential
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.
BMC Software, Inc., Confidential 8
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
patch 3)
AR System server
BMC Remedy Mid Tier
BMC Remedy Approval Server
BMC Remedy Assignment Engine
BMC Remedy AR System environment
BMC Atrium Core (7.6)
CMDB
Product Catalog
BMC Remedy AR System environment
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
(7.5.00 patch 1)
BMC Remedy AR System environment
Service Support
applications
BMC Remedy Asset Management (7.6) BMC Remedy AR System environment
BMC Remedy Change Management (7.6) BMC Remedy AR System environment
BMC Remedy Service Desk: Incident
Management (7.6)
BMC Remedy AR System environment
BMC Remedy Service Desk: Problem
Management (7.6)
BMC Remedy AR System environment
BMC Remedy Service Desk (7.6) BMC Remedy AR System environment
BMC Service Request Management (7.6) BMC Remedy AR System environment
9 BMC Software, Inc., Confidential
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.
BMC Software, Inc., Confidential 10
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.
11 BMC Software, Inc., Confidential
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.
BMC Software, Inc., Confidential 12
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.
13 BMC Software, Inc., Confidential
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+
RAM:
4 GB(10GB for
the integration
server)
4GB (10GB for
the integration
server)
4GB (10GB for
the integration
server)
DISK: 40 GB 40 GB 40 GB
Number of Servers
2 + 1
integration
server
3 + 1
integration
server
4 + 1
integration
server
BMC Software, Inc., Confidential 14
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.
15 BMC Software, Inc., Confidential
Figure 1: Small AR System environment
Sizing factor
Number of concurrent users 800
BMC Software, Inc., Confidential 16
Figure 2: Medium AR System environment
Sizing factor
Number of concurrent users 2000
17 BMC Software, Inc., Confidential
Figure 3: Large AR System environment
o BMC Remedy Mid Tier
o BMC Remedy Knowledge Management
Load balancer
Mid Tier servers
AR System server group
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: 2 GB
Disk: 20 GB
Servers: 4
Cores: 8 x 2.0 GHZ+
RAM: 4 GB / 10GB for
integration server
Disk: 40 GB
Servers: 4 + integration
Load balancer
Web clients
Windows clients
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
BMC Software, Inc., Confidential 18
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
software)
NA 10
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
patches)
Windows 1,000
Linux® 1,500
UNIX® 2,000
Typical small LAN switch without VLAN (24
Network Interface Cards, or NICs)
NA 250
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.
19 BMC Software, Inc., Confidential
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,
and logical components
Provided by the customer.
Total number of CIs (assuming no
software or patches are discovered on
any device)
F * 500 + 50 * G
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
BMC Software, Inc., Confidential 20
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
21 BMC Software, Inc., Confidential
Therefore, BMC recommends the following sizing configurations for the BMC
Discovery servers:
Small (2 Million) Medium (7.5
Million)
Large (15
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:
Small (2 Million) Medium(7.5
Million)
Large(15
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
BMC Software, Inc., Confidential 22
Deployment logical diagram
Figure 4: BMC Atrium Discovery and Dependency Mapping environment
23 BMC Software, Inc., Confidential
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.
BMC Software, Inc., Confidential 24
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
25 BMC Software, Inc., Confidential
Deployment logical diagram
Figure 5: BMC Analytics environment
BMC Software, Inc., Confidential 26
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
Deployment size # of concurrent users CI/request ratio
SIM # CI’s
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
27 BMC Software, Inc., Confidential
*These are Server class CPU’s not just a single core.
Dual-server deployment
Small Medium Large
CPU*: Dashboard: 1 x 2.0 GHZ+
DIL: 1 x 2.0 GHZ+
Dashboard: 2 x 2.0 GHZ+
DIL: 2 x 2.0 GHZ+
Dashboard: 2 x 2.0 GHZ+
DIL: 2 x 2.0 GHZ+
RAM: Dashboard: 2 GB
DIL: 2 GB
Dashboard: 4 GB
DIL: 4 GB
Dashboard: 4+ GB
DIL: 4+ GB
DISK: Dashboard: 20 GB
DIL: 20 GB
Dashboard: 50 GB
DIL: 50 GB
Dashboard: 100 GB
DIL: 100 GB
*These are Server class CPUs, not just a single core.
BMC Software, Inc., Confidential 28
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)
AR System Database
Data Integration Layer
Dashboards
29 BMC Software, Inc., Confidential
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.
BMC Software, Inc., Confidential 30
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.
31 BMC Software, Inc., Confidential
Deployment logical diagram—Service Support
Figure 7: Combined environment
BMC Software, Inc., Confidential 32
114903