Sizing and CApacity Planning

8/3/2019 Sizing and CApacity Planning

1/32

White Paper

October 2006

Sizing and Capacity

Planning for BMCRemedy IT Service

Management 7.0and BMC Atrium CMDB 2.0


2/32

BMC Software, Inc.www.bmc.com

Copyright 19912006 BMC Software, Inc. All rights reserved.

BMC, the BMC logo, all other BMC product or service names, BMC Software, the BMC Software logos, andall other BMC Software product or service names, are registered trademarks or trademarks of BMC

Software, Inc. All other trademarks belong to their respective companies.

BMC Software, Inc., considers information included in this documentation to be proprietary andconfidential. Your use of this information is subject to the terms and conditions of the applicable end userlicense agreement or nondisclosure agreement for the product and the proprietary and restricted rightsnotices included in this documentation.

Restricted Rights Legend

U.S. Government Restricted Rights to Computer Software. UNPUBLISHED -- RIGHTS RESERVED UNDER THECOPYRIGHT LAWS OF THE UNITED STATES. Use, duplication, or disclosure of any data and computer software by theU.S. Government is subject to restrictions, as applicable, set forth in FAR Section 52.227-14, DFARS 252.227-7013, DFARS252.227-7014, DFARS 252.227-7015, and DFARS 252.227-7025, as amended from time to time. Contractor/Manufacturer isBMC Software, Inc., 2101 CityWest Blvd., Houston, TX 77042-2827, USA. Any contract notices should be sent to this address.

Contacting Us

If you need technical support for this product, contact Customer Support by email [email protected]. If you have comments or suggestions about this documentation, contactInformation Development by email at [email protected].

This edition applies to version 2.0 of the licensed program.
http://www.bmc.com/mailto:[email protected]:[email protected]:[email protected]:[email protected]://www.bmc.com/


3/32

Sizing and Capacity Planning for BMC Remedy IT Service Management 7.0 and BMC Atrium CMDB 2.0 ! 3

White Paper

Sizing and Capacity Planning for BMCRemedy IT Service Management 7.0 andBMC Atrium CMDB 2.0

This white paper provides direction to anyone considering animplementation of ITSM. In particular, it helps identify potential

configurations for use in such an implementation, and it providesinformation about the likely performance and resource usage of the productsin such a configuration. It also suggests additional technologies that might beuseful for extending the configuration to support large global IT enterprises,with characteristics like high availability, scalability and failover.


4/32

4"Sizing and Capacity Planning for BMC Remedy IT Service Management 7.0 and BMC Atrium CMDB 2.0

White Paper

Overview

An accurate analysis of the performance and sizing of the hardware systems

that support ITSM and CMDB is critical to a successful implementation.This white paper shares some of the knowledge gained from the performancetesting done at BMC during the development and release of these importantproducts.

The findings in this paper can be used as a starting point to help you todetermine the appropriate performance and sizing considerations for ITSMand CMDB in your specific environment. This paper provides a starting

point for answering the following questions:! What are typical configurations that one might choose for implementing

the ITSM suite of products?

! What is the capacity of such a configuration in terms of user counts andresponse times?

! How can one extend such configurations to support even larger

environments?! How have these products been tested for performance, and what were

some of the results of those benchmarking efforts?

Overall, this white paper attempts to draw a clear correlation between thedecisions you will need to make to provide business service management,and their ramifications from an application performance perspective.

Standard configurations and their estimated performance

This white paper focuses on a few representative configurations. BMC refersto these as small, medium, and large configurations, though even the largeconfiguration is a relatively modest investment. The configuration guidelinesthat follow are only a starting place for any implementation. Any completesizing effort deserves the attention of a qualified staff to consider all aspectsof the configuration, including networking and I/O requirements, and peakand average workload characteristics. Larger systems, in particular, mightrequire full projects to determine accurate sizing and capacity planning. Thegoal of this white paper is only to provide a starting place for such largerefforts.


5/32

! 5

Sizing and Capacity Planning for BMC Remedy IT Service Management 7.0

Small configuration

The small configuration that follows uses Intel-based systems, primarilyrunning Windows. The building block for the small configuration is basedon the Dell PowerEdge 1850 Server containing two single-core, 64-bit IntelXeon processors at up to 3.8GHz. The exact ratio of mid-tier boxes to BMCRemedy Action Request System (AR System) server boxes for allconfigurations varies based on the observed user load, but as a starting place,the configuration provides one 2-CPU box to support web-based users, andcould likely handle 100 to 300 online users of moderate load. Thisconfiguration has only one AR System server box, which will be used for both

Reconciliation Engine (RE) batch operations, and online processing. Giventhat RE batch processes are generally high-load operations, BMC assumessuch operations should be done in a maintenance batch window, or BMCexpects the response time of online users to be impacted by this intensivebatch operation.

The discovery source is shown only to indicate where an integration wouldbe used, but is not identified as a specific component in the configuration.

These sizing estimates are based on frequent testing at BMC labs, as well asearly feedback from customers. BMC expects any size configuration shoulduse external storage for the database server, because a configuration thatbottlenecks on I/O bandwidth will suffer poor response time.

Figure 1: Small configuration

2 CPU/4 G

Intel/WindowsMidtier/Webtier

2 CPU/4 GIntel/WindowsAR Server/ITSM/CMDB

2 CPU/4 GIntel/WindowsOr Intel/LinuxDatabase TierOracle or SqlServer

External Storage


6/32


White Paper

Medium configuration

When you go from a small to a medium configuration the number of CPUson all boxes is doubled. The building block for the medium configuration isbased on the Dell PowerEdge 6850 server containing four 64-bit Intel Xeonprocessors. You can take advantage of horizontal scaling on the AR Systemserver tier by implementing server groups to provide two AR System serverboxes. As a practical consideration, this requires installing the same softwarestack, with ITSM applications, CMDB, and the AR System server on eachAR System box. But operationally, you could route all online users to theprimary ITSM box during RE execution. This allows you to run high-load RE

batch jobs on the secondary ITSM box at any time of the day, withoutimpacting the response times of your online users. Therefore, largerincremental updates can be run on a daily basis with such a configuration,and the size of the daily batch window is made largely irrelevant.

Reporting is another common use of such an additional AR System serverbox. This configuration also provides some measure of high availability, as afailure of either AR System box can be handled by routing both ITSM users

and RE jobs to the remaining node. The use of a load balancer is to distributeusers across the two mid-tier boxes, and to distribute user connections acrossthe two AR System server nodes when reconciliation is not running. Whenrunning reconciliation, the second load balancer can be eliminated orreconfigured such that on-line users are not directed to the reconciliationnode. If two AR System boxes are highly utilized, then a bottleneck coulddevelop on the dataserver, which should then be increased in size to handle

such load.


7/32

! 7


Figure 2: Medium configuration

Load Balancer

4 CPU/8 G EachIntel/WindowsMidtier/Webtier

4 CPU/8 GIntel/WindowsAR Server/ITSM/CMDBPrimary ITSM

4 CPU/8 GIntel/Windows

Or Intel/LinuxDatabase Tier

Oracle or SqlServer

Load Balancer

DiscoverySource(Not Included)

External Storage

4 CPU/8 GIntel/WindowsAR Server/ITSM/CMDBPrimary RESecondary ITSM(Optional)


8/32


White Paper

Large configuration

The large configuration uses a similar cluster of two AR System server nodesto allow concurrent online and batch processing. This configuration uses aSun T2000, which has a single socket processor chip, containing eightprocessor cores, each of which has four hardware threads per core. Thenumber of mid-tier systems can be altered to support the expected web-based user load, and the number of mid-tiers displayed here is only anexample.

Figure 3: Large configuration

Load Balancer

8 Core Sun T2000Sparc/SolarisMidtier/Webtier

8 Core Sun T2000Sparc/SolarisAR Server/ITSM/CMDBPrimary ITSM

8 Core Sun T2000Sparc/SolarisDatabase TierOracle

External Storage

8 Core Sun T2000Sparc/SolarisAR Server/ITSM/CMDBPrimary RESecondary ITSM

(Optional)

Load Balancer

DiscoverySource(Not Included)


9/32

! 9


Load testing process

Load testing of online users was done with two toolsets: SilkPerformer fromSegue, and Scapa Test from Scapa Technologies Limited. Both companieshave collaborated with BMC to provide specific functionality to allow moreeffective driving of the BMC Remedy based product set. Silk Performerallows users to simulate web-based users using AR System server mid-tier.The mid-tier is driven through a higher level of abstraction than http, calledthe back-channel APIs of the mid-tier. Using this technology allowed BMC tocreate load testing scripts that are more concise than those that replay pureHTTP.

The Scapa Test and Performance Platform also has specific functionalityrelated to AR System, and allows the capture and replay of AR System APIs.This serves to simulate users accessing AR System based applications throughthe User Tool. This also allows load testing without needing to model themid-tier of a configuration, which then can be evaluated in separate loadtests.

Neither of these tools model the client-side of the application. Therefore,variables, such as the time taken by a given client machine to render a screen,are not part of the response time calculations presented in the majority of thispaper. However, this is a common best practice in benchmarking, as it allowsless critical variables, such as the browser side cache size, to be eliminatedfrom the more important data such as webserver based response times. Theobserved additional latency of waiting for a client-side browser to render ascreen is considered in a later section.

Benchmarks

This section provides some examples of benchmarking results from thetesting that resulted in the sizing recommendations provided later. This isnot an exhaustive list of work that was completed, but instead provides someexamples of response time and resource utilization curves for some of the

configurations described. In this sense, the data provides useful backgroundfor those interested in capacity planning for this product set. For the sake ofconvenience, most of these example benchmark results use the smallconfiguration.


10/32


White Paper

AR System Server

AR System Server is the underlying platform for the ITSM 7.0 release, andtherefore is relevant to discuss briefly before discussing the ITSM

applications themselves. Overall, the current release of AR System serveradded substantial new functionality, and now provides for better integrationwith the ITIL-compliant ITSM applications suite. While there were no largechanges in terms of the performance characteristics of the product, there wassubstantial work done to make sure it performed as well or better thanAR System server version 6.3. Additionally, work was done to carefully trackany memory leaks in the product, to avoid any such issues appearing in the

field.The following graph shows how under high load of roughly 70 percent CPUutilization for the AR System server box, AR APIs appear to perform roughly15 percent faster in 7.0 than they did in the 6.3 release of the product. Thistest represents a high load of Help Desk version 6.0 type users, as is runthrough an internal load driving scripting language. The list of APIsconsidered here is not an exhaustive list, but the APIs that are generally used

by applications the most. The following graph is designed for use in relativecomparisons between the two AR System server versions, and not to providedirection in expected response time for any particular configuration.


11/32

! 11


Figure 1-1: Figure 4: AR System server 6.3 versus AR System server 7.0 performance

Another useful technique used to test the AR System server version 7.0 wasto consider its performance in the case of backwards compatibility with theITSM version 6.0 suite. In the following graph, response time during a mixedworkload of both Help Desk 6.0 and Change Management 6.0 seems to haveimproved when the server was upgraded to version 7.0.

0

500

1000

1500

2000

2500

3000

CreateEn

try(ce)

GetEn

try(ge)

SetE

ntry

(se)

GetLis

tEntrywithFi

elds(gle

wf

GetListEn

try(gle

GetSche

ma(gs)

GetList

Activ

eLink

s(glal

GetList

Char(glc

GetList

Grou

p(glg)

GetS

erverInfo

(gsi

GetCha

r(gc)

millisecond

6.3 AR Server Average 7.0 AR Server Average


12/32


White Paper

Figure 1-2: Figure 5: AR System server 6.3 versus AR System server 7.0 performance

Incident Management

BMC Remedy Incident Management is a market-leading and ITIL-compliant application that services both self-service and back-office users. Itis typically the product in the ITSM suite with the highest online user count,and hence is a critical application to evaluate.

Workload:

! Users using the Requester Console creating tickets (30 percent of users)

! Users using the Requester Console modifying tickets (20 percent of users)

! Support users creating tickets (20 percent of users)

! Support users searching for ticket sets (30 percent of users)


13/32

! 13


The load of such a workload is dependent on the rate of business transactionsas much as the user count. For both Incident and Change Managementworkloads BMC used active users that each complete a business transactionevery one, to one and a half minutes. For the case of Incident Management,half the users execute create ticket operations (either on the Requester or theSupport console), so the ticket creation throughput for a 300-user load isapproximately 120 per minute, or two per second. While this is higher thanthe average customer use, BMC believes this active load allows observation ofsystem activity under high stress, avoiding under sizing a system. Thedatabase was pre-populated through Silk Performer scripts before use, andcontains over two million database records and roughly 10,000 existing

incident tickets.

The following graphs demonstrate the scaling of CPU usage, averagememory usage per process, and average response times per user. This testingwas done with the Silk Performer load testing product, and thereforerepresents response time measured at the webserver of the BMC Remedymid-tier, as discussed earlier.BMC observed that overall that response time isreasonable for such a configuration, as even up to 400 users it does not growquickly, and the highest measured response times are still well under twoseconds. Similarly, CPU utilization and memory consumption appearconsistent and reasonable up to 400 users. However, that given, the variablesin comparing a benchmarking result to a production user load, in the latersizing sections it is conservative and suggest user counts lower than BMC hasrun in benchmarking scenarios.


14/32


White Paper

Figure 6: Incident Management 7.0 Average total system CPU usage

0

10

20

30

40

50

60

70

0 50 100 150 200 250 300 350 400 450

Number of Users

%

MT

ARDB

i i d i l i f d i


15/32

! 15


Figure 7: Incident Management 7.0 Average response time

0

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6

1.8

200 300 400

Number of Users

Second

RC Create Incident

RC Save WorkInfo

Support Create IncidentSupport Incident Search 50

Whit P


16/32


White Paper

Figure 8: Incident Management 7.0 - Average memory usage

Change Management

BMC Remedy Change Management delivers comprehensive policy, processmanagement, and planning capabilities that help you increase the speed and

consistency in which you implement changes. Change Management isanother application in the ITSM suite with enhanced functionality for thecurrent version. This version provides closed-loop configurationmanagement integrations, as well as new task management procedures. BMCexpects that the depth of functionality in Change Management will result ina higher load per user than in Incident Management, but typicallyimplementations have many fewer online Change Management users than

they have Incident Management users.Workload:

! Create Change Ticket from Requester Console (33.33 percent)

! Add Workinfo to Change Ticket from Requester Console (33.33 percent)

! Search and Retrieve 50 Change Tickets from Change ManagementConsole and View Audit Log (33.33 percent)

0

100

200

300

400

500

600

700

800

0 100 200 300 400

Number of Users

M

BMT

AR

DB

Sizing and Capacity Planning for BMC Remedy IT Service Management 7 0


17/32

! 17


Users in this workload complete a business transaction approximately everyminute, and the database is pre-populated with over 100,000 change tickets.

For the previously described small configuration using Change

Management, the following table covers average response time, average CPUusage, and memory consumption per database and AR System server. Theseresults were generated using the Scapa Test load driver product. Therefore,they represent response time of the Windows User Tool more than the mid-tier.

The following graphs demonstrate the average CPU use, average memory useper process and average response times for different user requests. Overall,

the CPU utilization for a given user count is substantially higher than thatobserved for Incident. However, even as CPU utilization on the AR Systemserver box grows to 85 percent, the response time of all measured operationsstill is less than two seconds. Again, BMC differentiates these benchmarkresults from the more conservative sizing suggestions provided later in thispaper.

Figure 9: Change Management 7.0 Average total system CPU usage

0

10

20

30

40

50

60

70

80

90

100

0 50 100 150 200 250

Number of Users

CPUutilization(%)

AR Box CPU

DB Box CPU

White Paper


18/32


White Paper

Figure 10: Change Management 7.0 Average response time

0

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6

1.8

2

0 50 100 150 200 250

Number of Users

ResposeTim

esinseconds

Open RC

Create Ticket

Save WorkInfoOpen CM Console

Search 50 Tickets



19/32

! 19

g p y g y g

Figure 11: Change Management 7.0 Average memory usage per process

Memory usage for ITSM 7.0 CM Benchmark

0

100

200

300

400

500

600

700

800

0 50 100 150 200 250

Number of Users

MemoryinM

B

ARS

Oracle

White Paper


20/32


Configuration Management Database (CMDB)

The CMDB plays a central role in the Business Service Management (BSM)solution. A detailed explanation of best practices for creating and deploying

a CMDB is available in the white paper titled The Performance and Use of theBMC Atrium CMDB version 2.0. Here, BMC instead summarizes observedthroughput of some critical operations related to CMDB use for theconfigurations discussed.

For the CMDB to use data from any discovery source, three batch operationsneed to take place: data transport, identify, and merge. Data transport occurswhen data is transported from the discovery datastore to a CMDB staging

dataset. Identify is when any IT component discovered by multiple discoverysources is found, so that all the data associated with that component can bemerged into one location at a later stage. And merge is the reconciliation, inwhich data is moved from one or more staging datasets into the productiondataset of the BMC Atrium CMDB. BMC considers test cases of loading anumber of computer systems, where each computer system has 20configuration items (CIs), and these CIs are roughly half components and

half relationships. This data is brought into the CMDB to identify it and thenmerge it. The later two steps utilize the Reconciliation Engine (RE) of theCMDB.

Figure 12: CMDB Merge Operation

0

10

20

30

40

50

60

70

80

90

100

Small Medium Large

Configuration

CI'sperSecond



21/32

! 21

The graph in Figure 12 shows the scaling observed for the Merge activity ofthe Reconciliation Engine for the three standard configurations, with the testcase mentioned. It is apparent that the throughput scales consistently acrossthe smaller Intel-based servers and up to the larger system. The estimatedperformance for all three operations is shown in the following sizingguidelines section.

Observed User Response Times versus Benchmark Times

Throughout this white paper, BMC refers to benchmarking response times,which, for consistency, do not include the more variable client-sidecomponents of response times that a typical user observes. To quantify this

variable component, BMC performed manual stop-watch timings on amodest-sized client machine, while at the same time running the Incidentworkload on the small configuration. This allowed BMC to compare theobserved user response times with the benchmark response times measuredby the Silk Performer tool.

In general, the client-side overhead of response time is roughly between 1and 1.5 seconds. For opening forms, BMC observed that the client-side work

was larger, and therefore the benchmark response time was a smallerpercentage of the observed client-side time. However, for other activitieswhere the client has cached the required data (such as refreshing therequester table), the benchmark response time was a larger percentage of theobserved client-side time. Overall, client-side response time was observed tobe consistently less than 4 seconds, and in most cases less than 3 seconds.

Clearly, there is a subjective element to manual response time testing, but inthis effort, multiple manual timings were taken for each timed event in anattempt to minimize that subjective element.The results of this testingcompare two typical client configurations:

! Client one with 1 Intel CPU running at 2.4 Ghz and 1 Gigabyte of memory

! Client two with 1 Intel CPU running at 3.0 Ghz and 2 Gigabyte of memory

In reviewing the results of these tests, you should also consider the size of theclient machine and the software running on it. For example, virus protectionsoftware can substantially effect such client-side performance.

White Paper


22/32


Figure 13: Requester console actions average response time in a browser for 300 users

Sizing guidelines

From the previous benchmarking results, BMC can compute estimated usercounts for each configuration, which allows for successful implementationwith reasonable and consistent performance. These recommendations,however, do not reflect the exact user count and throughput rates observedin the benchmark tests. Instead, they represent more conservative estimatesbased on achieving consistent performance for a range of specific activities.More specifically, BMC expects the following user counts to result in client-side response times of between 2 and 4 seconds for most operations.

This corresponds to the observed benchmark response times of between 1and 2 seconds, in addition to the client browser rendering time and networktime associated with an actual user viewing the UI of the application. BMCalso expects that these user counts allow all tiers of the configuration tooperate in the mid-range of CPU utilization (between 20 percent and 70percent), and that their memory requirements are well under the memoryprovided on each box. A variety of tests were performed to gatherinformation for such estimates, but not all configurations were tested with allworkloads.

0

0.5

1

1.5

2

2.5

3

Create Incident Refresh

Requester table

View Incident

ticket

Add Work Info to

Incident

Logout Login to

Requester

Console

Second

Avg SilkPerf LAN (s)

Avg Browser3.0 Ghz/2GB RAMSunnyvale LAN(s)

Avg Browser2.4 Ghz/1GB RAMSunnyvale LAN (s)



23/32

Sizing guidelines! 23

The recommended user counts for both Incident Management and ChangeManagement are provided in the table that follows. These are generalestimates. More detailed estimates would require a detailed knowledge of acustomer's specific workload and database characteristics. However, one

characteristic that is common between both Change Management andIncident Management, is that there are two separate user consoles. Therequester console is designed for self-service users, while the support consoleis designed for professional users.

In general, for both Change Management and Incident Management, therequester console is substantially higher in CPU demands than the supportconsole. This is related to the implementation of a variant of the ServiceRequest Management System (SRMS) that was included in this release. Amore complete form of SRMS is currently under development, and it isexpected that the two consoles will have more similar profiles once thatproduct is in place. For now, assume that a workload with the below usercount and all requester console users will be higher in the range of acceptableCPU utilization (for example, 50 percent to 60 percent), whereas a workloadthat consists of strictly support users will be lower in that range (for example,

30 percent to 40 percent).

Table 1: Sizing by user count

Configuration Incident Management Change Management

Small 300 175

Medium 550 325

Large 800 500

White Paper


24/32


The user counts suggested in Table 1, represent the use of one AR Systemserver node of the size corresponding to each configuration. If AR Systemserver groups are used, the second node might be used as a dedicatedreporting or Reconciliation node, or could be used for additional ITSM users

if needed. User counts taking into account both AR System server nodes foron-line activity are not presented, but would be roughly double the abovenumbers.

The expected throughput for CMDB activities is provided in Table 2.Generally, such batch activities do utilize AR System server and databaseCPU extensively, depending on the thread counts. The thread count settingsdetermine the amount of parallel activity that can take place on theAR System server system, and therefore lower settings (such as the defaultsetting) will decrease the throughput of the system to a level much lower thanobserved in the following table.

In general, over-configuring threads has little impact, while under-configuring threads might limit thoughput. In this way, BMC uses a numberapproximately three times the CPU count for the number of list threads

(both minimum and maximum), and six times the CPU count for thenumber of fast threads (both minimum and maximum). So a mediumconfiguration will have 12 and 24 threads for List and Fast thread counts,respectively. Such high thread counts will enable batch operations, such asRE, to complete quickly, but will also handle on-line activity effectively.Private threads might also be allocated and used by RE jobs, thoughconfiguring that is documented in other locations.

When the thread count is set as suggested above, the likely RE throughputrates should match the three configurations presented in Table 2. Somevariation can be expected, based on the specific data characteristics, and thedetails in the reconciliation precedence rules. These values however, shouldbe useful guidelines for planning CMDB batch activity.

Table 2: CMDB - CIs per second

Configuration CMDB Create

Instance API

Identify Merge

Small 60 40 20

Medium 100 80 40

Large 130 110 80


25/32

White Paper


26/32


BMC Performance Assurance

The sizing recommendations and benchmark testing were limited to allowquick communication of these results. BMC also provides tools that allow

you to generalize such benchmarking results to a wider range ofconfigurations and use cases. BMC Performance Assurance (BPA) has datacapture capabilities for the results of benchmark testing, and it also has amodeling component. The modeling component allows you to extrapolatefrom one test scenario that was run, to others that were not run. This allowsyou to model hardware platforms that were not included in this white paper,or to consider other variables, such as larger user counts, different memory,

or CPU characteristics.To demonstrate the utility of this tool in this context, BMC performed asimple modeling test. BMC ran 100 users of the Incident Managementworkload, discussed previously, and collected the data using BMCPerformance Assurance. Then, that data was used to model the expectedresponse time if the user count was increased to 200 users. BMC then ran thetest with 200 users to validate the modeling of the tool. The following graph

shows how the modeled response time (labeled BPA) align with themeasured response times, though the modeling was based on a baseline froma 100-user run. It appears that the BPA tool allows for accuratedetermination of response times for test cases that have not been run, andtherefore can simplify characterization of a wide range of systemrequirements by reducing the requirement to actually run such benchmarktests.

Figure 14: Modeled BPA Response Time versus Measured Silk Response Time



27/32

Enterprise configuration considerations! 27

Other applications

While the Service Level Management (SLM) application is a usefulapplication, it has yet to be characterized to the degree that BMC can provide

sizing guidance in this document. Asset Management is not dramaticallydifferent from the 6.0 version of the product, and BMC expects performancecharacteristics to be approximately the same as observed in other documentson the 6.0 version. To assist customers as much as possible, BMC will providethe limited set of information available at this time, and expect to documentboth these two applications and other aspects of the Business ServiceManagement (BSM) product set in future white papers.

Enterprise configuration considerations

This section considers other characteristics of this product set that supportenterprise level implementations. BMC assumes such implementations willbe inherently global in nature, often requiring 24-hour access 7 days a week,and will likely require high availability and scalability to increase capacity

further.

User AR System server groups

AR System server groups comprise the technology that allows multipleservers to concurrently run AR System applications, while sharing the samedatabase tier. Server groups provide a cluster of AR System servers that are

indistinguishable, from the user's perspective, from one larger server. Thisprovides two benefits to the IT organization: it allows use of a set of smallerservers that are at a lower price point for a given amount of resources, and itallows high availability, as the failure of one server can take place withoutimpacting the business service provided by the larger AR System servergroup.

White Paper


28/32


Within the context of this paper, BMC considers AR System server groups asa mechanism for running two separate workloads: the high-load batchoperations related to CMDB reconciliation tasks, and the on-line useractivities related to use of the ITSM Suite. This is the configuration suggested

(as optional) for both the medium and large standard configurationsoutlined in this white paper. Using such a configuration allows the high-loadreconciliation tasks to be run outside of a batch window, but withoutimpacting the response time of the on-line users who are runningconcurrently. In such a configuration, the IT managers might choosearbitrary times to update their CMDB, thereby avoiding having stale data.Though the two workloads are initially assumed to be run on separate nodes

of the AR System server group (with the reconciliation node not beingattached to a load balancer), both nodes are still functionally equivalent. Soin the event of a failure of one of the nodes, the other node could functionallyexecute both workloads, though the capacity would be diminished.

BMC tested this configuration to make sure that it functioned as expected,and to assess what extra load would appear when running two workloadssimultaneously. A benchmark was run on one small configuration for 200

incident users with the previously discussed workload, and anotherbenchmark was run on the same configuration for CMDB ReconciliationActivities, specifically Identify and Merge. BMC then set up an AR Systemserver group with two AR System server nodes, and ran the two workloadsconcurrently on this setup. BMC observed that the CPU utilization of thedatabase in the AR System server group configuration was essentially thesame as the sum of the CPU utilizations for the separate configurations.

Therefore, it is critical in such a scenario to size the database server largeenough that the database CPU does not become a bottleneck. CPUutilization of the AR System server boxes generally does not varysubstantially from that observed in the two separate configurations. Theresponse time observed for the Incident users in the combined scenariodepends directly on the CPU utilization of the database, so it might increasesubstantially if the CPU utilization of the database server gets above 60

percent or 70 percent. Otherwise, there was little adverse impact of usingAR System server groups to combine such disjointed workloads.



29/32

Enterprise configuration considerations! 29

Distributed Server Option

The Distributed Server Option (DSO) is an AR System server feature thatallows replication of data from one AR System configuration to another

separate configuration. DSO can be used as a disaster recovery mechanismwhere a separate, perhaps smaller configuration is stored in a separate, andsafer location as a warm back. Alternatively, it can be used to globallydistribute an ITSM environment, and has features that allow ticketownership to follow the sun, so that the global instance, which is theirworkday, can access all open tickets from other global instances, as well ascreate their own new tickets.

The DSO for the ITSM 7.0 product set (including AR System server 7.0) isgreatly improved over previous versions. In particular, there has been asubstantial reduction in the data that is transported across instances, so thatno redundant or unnecessary data is transported.

BMC recently ran testing on DSO to characterize the overhead in responsetime and CPU utilization that would be observed in a typical implementationrunning the Incident Management workload discussed in this white paper. Aload of 200 Incident Management users were run for more than one hour,while DSO was run in unidirectional mode to push data to a separate,secondary configuration. The extra overall CPU utilization on a primaryAR System server due to DSO was 10 percent and the secondary server 3percent. The network traffic in packet and byte rate increased approximately50 percent when DSO was enabled, and BMC observed roughly 12,000 DSOpush operations per hour. The slight increase in response time was expected,

as CPU utilization increased. There was no significant change in memoryusage. Overall, DSO for ITSM 7.0 seems to be a low overhead solution fordata replication, and is a viable alternative for creating global environments.

Note: This testing was done with server configurations that are co-located.Where servers are separated by a wide distance, then DSO push frequencymay be reduced.

White Paper


30/32


Virtualizer

Virtualizer is a relatively new BMC product that allows dynamic reallocationof system resources within a configuration. Virtualizer has the capability to

monitor resource consumption across all three tiers of a traditional three-tierconfiguration, and rules can be constructed to take actions based on theobserved resource consumption. For example, in an environment such as themedium or large configurations discussed previously, you could dynamicallymove a server from the AR System server group tier (which has a light CPUload) to the mid-tier of the configuration (which has a high CPU load),because CPU utilization on the mid-tier is too high.

Alternatively, Virtualizer might also reallocate resources on a scheduledbasis. An example of this use case would be in an environment where moston-line users are no longer active in the evening, so servers allocated to themid-tier could be reallocated to the AR System server group tier everyevening to assist with batch and reporting requirements. The database canalso represent such a grid-enabled tier with technologies, such as Oracle 10gReal Application Clusters (RAC).

Virtualizer suggests a future state for sizing and capacity planning, whereconfiguration design might be more high-level, but also associated with adynamic resource allocation scheme. With this technology, a simple solutionto an optimal configuration might be to purchase 5, 10, or 15 small servers,and arrange them in any convenient three tier configuration as a startingplace. Then, as resource demands become apparent, the optimal allocation ofthose servers to tiers of the architecture will naturally take place. In this way,

the general goal of configuration planning becomes much simpler, and betteruse of existing resources can be ensured as an automated process.

Summary and conclusions

In this white paper, BMC has provided background and direction onconfiguration planning for new and growing ITSM applicationimplementations. BMC hopes that readers will now understand and be ableto predict some of the performance characteristics of the products, and alsoto make more knowledgeable choices about hardware configurations tosupport the products. BMC will continue to expand this base of knowledgeto include other applications and different use cases within this sameapplication set. Other white papers will also be delivered that provide furtherdetail on some of the enterprise configuration technologies discussed briefly

in this white paper.


31/32


32/32

*65722**65722**65722**65722*

*65722*

Documents

Sizing and CApacity Planning