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.

http://www.bmc.com/

mailto:[email protected]

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

http://www.bmc.com/support



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

.




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


Deployment logical diagram ............................................................................... 22

BMC Analytics Environment .................................................................................. 23

Sizing factors ....................................................................................................... 23



BMC Dashboards Environment .............................................................................. 26

Sizing factors ....................................................................................................... 26


Deployment logical diagrams .............................................................................. 28

BMC Service Support Deployment ......................................................................... 29

Architecture Assumptions ................................................................................... 29

Architecture Notes ............................................................................................... 30


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


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.



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 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)


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 Service Desk: Problem

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


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.


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.


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.


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 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)


Number of Servers

2 + 1

integration

server

3 + 1

integration

server

4 + 1

integration

server


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.


Figure 1: Small AR System environment

Sizing factor

Number of concurrent users 800


Figure 2: Medium AR System environment

Sizing factor

Number of concurrent users 2000


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 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.


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


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.


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


Therefore, BMC recommends the following sizing configurations for the BMC

Discovery servers:

Small (2 Million) Medium (7.5

Million)

Large (15

Million)


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

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)


RAM: 4 GB 8 GB 16 GB


# of Servers 2 2 4


Deployment logical diagram

Figure 4: BMC Atrium Discovery and Dependency Mapping environment


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.

https://boc.sdn.sap.com/files/boe_xi_r2_sizing_recommendations.pdf


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.


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


Deployment logical diagram

Figure 5: BMC Analytics environment


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


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



*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.


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


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.


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.


Deployment logical diagram—Service Support

Figure 7: Combined environment


114903

reference architecture for bmc service support solutions using bsm 7.6 components

Documents