Unicenter Desktop and Server Management: Solution Planning Guide

Unicenter Desktop and Server
Management
Solution Planning Guide

R11.x
This documentation (the “Documentation”) and related computer software program (the “Software”) (hereinafter
collectively referred to as the “Product”) is for the end user’s informational purposes only and is subject to change
or withdrawal by CA at any time.
This Product may not be copied, transferred, reproduced, disclosed, modified or duplicated, in whole or in part,
without the prior written consent of CA. This Product is confidential and proprietary information of CA and protected
by the copyright laws of the United States and international treaties.
Notwithstanding the foregoing, licensed users may print a reasonable number of copies of the Documentation for
their own internal use, and may make one copy of the Software as reasonably required for back-up and disaster
recovery purposes, provided that all CA copyright notices and legends are affixed to each reproduced copy. Only
authorized employees, consultants, or agents of the user who are bound by the provisions of the license for the
Software are permitted to have access to such copies.
The right to print copies of the Documentation and to make a copy of the Software is limited to the period during
which the license for the Product remains in full force and effect. Should the license terminate for any reason, it
shall be the user’s responsibility to certify in writing to CA that all copies and partial copies of the Product have
been returned to CA or destroyed.
EXCEPT AS OTHERWISE STATED IN THE APPLICABLE LICENSE AGREEMENT, TO THE EXTENT PERMITTED BY
APPLICABLE LAW, CA PROVIDES THIS PRODUCT “AS IS” WITHOUT WARRANTY OF ANY KIND, INCLUDING
WITHOUT LIMITATION, ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE
OR NONINFRINGEMENT. IN NO EVENT WILL CA BE LIABLE TO THE END USER OR ANY THIRD PARTY FOR ANY
LOSS OR DAMAGE, DIRECT OR INDIRECT, FROM THE USE OF THIS PRODUCT, INCLUDING WITHOUT LIMITATION,
LOST PROFITS, BUSINESS INTERRUPTION, GOODWILL, OR LOST DATA, EVEN IF CA IS EXPRESSLY ADVISED OF
SUCH LOSS OR DAMAGE.
The use of this Product and any product referenced in the Documentation is governed by the end user’s applicable
license agreement.
The manufacturer of this Product is CA.
This Product is provided with “Restricted Rights.” Use, duplication or disclosure by the United States Government
is subject to the restrictions set forth in FAR Sections 12.212, 52.227-14, and 52.227-19(c)(1) - (2) and DFARS
Section 252.227-7013(c)(1)(ii), as applicable, or their successors.
All trademarks, trade names, service marks, and logos referenced herein belong to their respective companies.
Copyright © 2006 CA. All rights reserved.

Contents
Introduction ................................................................................1
Local or Remote MDB ................................................................3

Ingres or Microsoft SQL Server ................................................................................................ 3
Network Latency .................................................................................................................... 3
Clustering ............................................................................................................................. 4
Dedicated Database Server(s).................................................................................................. 4
Multiple Applications/Shared Database ...................................................................................... 4
Conclusion ............................................................................................................................ 5
Domain Manager Planning .......................................................7

Data Isolation........................................................................................................................ 7
Security Administration........................................................................................................... 7
Geographic Isolation............................................................................................................... 8
Conclusion ............................................................................................................................ 9
Domain Manager Capacity Estimation..................................11

Inventory Data Collection and Processing ................................................................................ 12
Collection Tasks and Scalability Servers ............................................................................. 13
Service Level Compliance ................................................................................................ 14
Software Deployment Container Build ..................................................................................... 14
Software Package Distribution to Scalability Servers.................................................................. 17
Conclusion .......................................................................................................................... 18
iii
Scalability Server Planning...................................................... 21
Example Environment ...........................................................................................................21
Mapping Scalability Servers to the Environment ........................................................................21
Hardware Cost ................................................................................................................22
Maintenance Cost ............................................................................................................22
Administrative Cost .........................................................................................................23
Non-Compliance Cost.......................................................................................................23
Scalability Server Capacity Estimation .................................. 25

LAN Environment..................................................................................................................25
Time Restrictions ..................................................................................................................25
Typical Package....................................................................................................................26
Service Level Compliance.......................................................................................................27
Adjustments for Resource Contention and Overhead.............................................................27
Maximum Simultaneous Activations ...................................................................................28
Number of Scalability Servers Required ..............................................................................28
Service Level Required.....................................................................................................29
Number of Target Agents .................................................................................................29
Conclusion................................................................................ 31
iv
Introduction
Successful implementation of your Unicenter solution requires careful planning,
driven by business stakeholder requirements and expected service levels.
Designing the appropriate architecture for that solution, therefore, should begin
with the business and administrative requirements, and then evolve through a
series of refinements based upon the design’s ability to comply with expected
service levels. To help with this process, this document provides planning and
capacity guidelines for the following Unicenter Desktop and Server Management
(DSM) components:
Domain Manager
Scalability Server
These guidelines are based on the results of extensive product performance and
scalability testing.
First, however, let us take a look at how the decision on where to locate the
Management Database (MDB) – either locally or remotely – plays a significant role
in all remaining component decisions.
1
Local or Remote MDB
One of the first decisions to make in architecting a Unicenter r11 solution is
whether the MDB should be installed locally (on the same host as the application)
or remotely (on another host accessible via the network). Technical arguments
can be made for both designs but, based on performance testing and reduced
cost, implementing the CA application and MDB on the same host is considered
the best practice - unless a compelling business or technical justification exist for
remote placement.
To determine if deviation from the best practice is justified requires understanding

client requirements (both technical and political). With these in mind, you can
than apply the following set of simple guidelines and principles to drive the
decision-making process.
Note: Many of the guidelines and principles provided in this document are
interrelated - applying any of them out of context may lead to a false conclusion.
Therefore, it is important that you review this document in its entirety.
Ingres or Microsoft SQL Server
Based on performance, Microsoft SQL Server (2000 or 2005) is the recommended

DBMS except in the following cases:
Non-Windows solution is insisted upon (discussion of the

advantages/disadvantages of such a solution falls outside the scope of this
document).
Small-to-medium client where the additional cost of Microsoft SQL Server is a

critical factor.
In general, the guidelines that should be used to determine whether a local or

remote MDB is optimum are not specific to a DBMS type. However, it may be a
crucial piece of information when, after considering all non-dependent factors, the
outcome is not definitive.
Network Latency
Network latency introduced when the DBMS server is remote from the application
server would negatively impact overall performance. Implementing an application
server and remote database server also adds cost to the solution in the form of
additional hardware and OS licenses. In the course of reviewing the other
guidelines and principles, factors that outweigh the negative impact of network
latency may surface. However, if there is no compelling justification (political or
technical) for implementing the MDB on a server remote from the application
server, the recommendation is to install the MDB local on the application server.
3
Local or Remote MDB
Clustering
Currently, not all CA applications are “cluster aware”. If policy dictates that
databases be hosted on clustered systems to provide fault tolerance and if the CA
application is “cluster aware” barring any other compelling justification (political
or technical) for implementing the MDB on a remote server, the recommendation
is to install both the MDB and the application on the same cluster. However, if
the CA application is not “cluster aware” and the client insists on installing the
MDB on a cluster, then the recommendation is to install the application on a
separate standalone server with a remote MDB on the cluster - provided the
application supports such a configuration. Otherwise, the application and the
MDB should be installed on the same non-clustered server.
Dedicated Database Server(s)
Policy may dictate that all databases be hosted on dedicated servers for
administrative and security reasons and that no applications may be installed on
these servers. While installing the MDB remote from CA applications may not be
optimum because of the network latency introduced, nevertheless the reduction in
administrative cost and security exposure may more than offset the performance
impact. Compliance with such policy would be considered a compelling
justification for implementing the CA application(s) with a remote MDB.
Multiple Applications/Shared Database
Additional considerations are required when multiple CA applications will be

sharing the same MDB – either now or in future – particularly at the Enterprise
(top) tier of the architecture. For example, UAPM and DSM integration currently
requires that the applications share the same MDB.
Installing multiple applications on separate hosts reduces potential administrative

conflicts (access control, maintenance schedules, etc.). For example, if the MDB
requires a reboot, any other application installed on that server will be brought
down. On the other hand, separating the applications from the MDB (and each
other) provides the ability to perform administrative tasks independently.
In general, when multiple applications will share the MDB in a medium to large
implementation, the recommendation is to host the MDB on a separate server,
remote from the application server(s).
4
Unicenter DSM Solution Planning Guide
Conclusion
When designing an architecture for a single CA application it is clear that co-

locating the application and MDB on the same server (or cluster) would provide
the best performance\least cost best practice. Alternatively, installing the MDB
remotely should only be considered after a careful review of all factors to
determine if there are other compelling justifications that outweigh the
performance and cost benefits. Bear in mind that, while the term “remote”
implies separate hosts, it should be understood that the hosts should be
electronically close with reliable network connectivity.
In the end, the decision must be driven by the overall impact to the business.
5
Domain Manager Planning
Determining the optimum number of Domain Managers to deploy for a solution
begins with reviewing business requirements, security policies, administrative
structure and geographic disbursement of assets and administrative resources.
Following are guidelines to assist in developing a draft solution based on
cost/benefit of various alternatives. This draft will then be refined in other phases
of the planning process to ensure compliance with additional business
requirements - such as service level agreements.
Data Isolation
Although reducing the number of Domain Managers can reduce hardware and
administrative costs, business and/or government policy may dictate that data
gathered from assets associated with one or more business units or locations may
not be co-mingled with data gathered from other areas of the Enterprise.
Compliance with the dictate would require a separate MDB and, therefore, a
separate Domain Manager must be implemented to service the assets involved.
Policy will also determine whether or not a subset of the data may be replicated to
an Enterprise Manager.
Security Administration
In many cases management is not completely centralized for all assets in the
Enterprise. Administration may be delegated to or required by individual business
units. The solution, therefore, must provide a level of autonomy and security that
supports limiting management of assets and access to related data only to the
responsible group. Unicenter DSM provides the ability to limit access to subsets
of assets and functions within the scope of a Domain Managers via object level
security. In this situation, then, it would appear that reducing the number of
Domain Managers to reduce hardware costs and using object level security to
control access to the assets would be the correct choice.
Consider, however, that such an implementation requires a super-administrator

or group to manage the security policies. As a result the effort and, therefore,
the cost to design, implement and maintain the policies would vary depending
upon complexity of the rules, volatility of the policies and the ability to automate
application of the policies as assets are added, modified, transferred or retired.
Conversely, implementing a Domain Manager based on management scope

provides complete autonomy. Potentially complex object level security models
are not required and the role of the super-administrator is drastically reduced or
eliminated.
7
Domain Manager Planning
Given that costs and benefits will vary, every effort must be made to understand
current business processes and requirements. Once understood, consider the
feasibility and complexity of the associated security models. Estimate the effort
of implementing and maintaining the models (if feasible) and the cost related to
the effort (immediate and ongoing). Compare these costs to the cost of
additional hardware, software and maintenance to implement additional Domain
Managers to arrive at a decision.
Geographic Isolation
Assets would be considered geographically isolated when they are located at

remote sites connected by slow network links to each other and/or a central
location. As noted in the section Local or Remote MDB, installing the Domain
Manager on the same system or electronically close to the system hosting the
MDB is considered best practice – as is locating the MDB close to the primary data
consumers. It follows then that the Domain Manager should be placed at a
location(s) where the data will be consumed and not at remote locations
generating the data.
For example, consider an environment in which assets are concentrated at two

remote locations each with a 256 kbps connection to a central “headquarters”.
Scenario 1: In general the consumers of the asset data reside at

“headquarters”. Users at the remote location have limited or no need to
access the information generated. In following the guideline to place the MDB
near the primary consumers, consider implementing the Domain Manager(s)
at the “headquarters” location where it will gather data from the Scalability
Servers located near the agents at the remote sites.
Scenario 2: In this scenario, the primary consumers of the asset data are
located at the same remote locations as the assets within their scope of
responsibility. In this case, consider implementing a Domain Manager at each
location and an Enterprise Manager at headquarters (if needed).
It should be apparent that the solution suggested in “Scenario 2” may result in a

higher initial cost in terms of hardware and software licenses. As with all the
principles and guidelines presented, the final decision must take into account
many factors. Basing the design of the solution on a single principle in isolation is
never recommended.
8
Conclusion
The guidelines and principles provided should make it possible to develop an

initial logical solution or architecture based on an understanding of business
requirements, processes, policies and network topology. In many cases the
decisions will be determined based on cost/benefit comparison of alternatives.
The process of arriving at a final solution continues with validating and adjusting
to ensure that the initial solution can perform in compliance with service level
requirements.
9
Domain Manager Capacity Estimation
When used in the context of planning a solution the term “capacity” should be
understood to mean not simply “maximum load that can be applied” but “the
ability to deliver the results required in compliance with a specified service level
under a given load.” Significant improvements in performance for Unicenter DSM
r11 Domain Manager components make it possible, in general, to reduce the
number of instances deployed when compared to previous versions. Where, in
previous release, the best practice recommendation for medium sized
environments (5,000 to 30,000 assets) may have been to use multiple instances
reporting to an Enterprise Manager, it may now, in fact, be possible to deploy a
single Domain Manager. Reducing the number of Domain Managers can reduce
both hardware and administrative costs driving down the total cost of ownership.
Although many tasks are managed and performed by the Domain Manager, the
operations that have the most significant impact are:
Inventory Data Collection and Processing
Software Deployment Container Building
Software Package Distribution to Scalability Servers
Obviously, the first item on the list, inventory data collection and processing, will
have a larger impact on environments in which DSM’s Asset Management features
are the primary driver for implementation. Service levels would generally be
expressed in terms of an acceptable latency period between the time a change is
made to an asset and the time the Domain database is updated.
The second and third items on the list, however, would have a higher impact for
environments in which automated software distribution is viewed as more vital.
In some cases, the time to complete one or both operations may not be
applicable. For example, software deployment containers can be defined and
populated in advance then activated at a later time, so that software deployment
occurs during a more restrictive “window of opportunity”. Likewise, software
packages can be distributed and staged at Scalability Servers. However, scaling
the solution based on the ability to reduce lead time by building software
deployment containers and staging software packages in advance risks the
inability to deploy software in a timely manner in a “worst case” scenario. Users
must weigh the potential reduction in the cost of ownership versus the cost of
non-compliance, estimate the likelihood of a “worst case” scenario and accept the
risk.
After devising a preliminary architectural model based on the administrative,

logistical and political requirements discussed in the previous chapter, the next
step is to verify that it is still possible to satisfy service level commitments with
the number of planned Domains. Adjustments should be made when necessary.
11
IMPORTANT: An understanding of the business requirements, service level

constraints and network topology is required before proceeding. Models are
provided to illustrate the impact of common factors on expected performance and
not to predict actual metrics. Results of calculations performed are estimates
and are intended as guidelines. Actual performance may vary in a live,
production environment.
Inventory Data Collection and Processing
Although the performance of many processes executed by Unicenter DSM Domain

Manager is impacted by load, few have measurable impact on service level
compliance. One significant exception is inventory data collection and processing
which is carried out by one or more Engine instances.
Service levels are typically based on the ability to process a standard set of
inventory data for a specified number of agents in a specified time period.
Performance is impacted by the number of collection tasks scheduled to run
concurrently as well as the number of agents managed. For example, the chart
below illustrates the relationship between the number of concurrent collection
tasks and the time in seconds to process the inventory data from a single agent:
secs./agent
10.00
8.00
6.00
secs./agent
4.00
2.00
0.00
1 2 3 4 5 6 7 8 9 10
Concurrent Collection Tasks
12
Testing was performed on a mid-range system (Dual processor, 8 GB RAM) with

both Unicenter DSM and Microsoft SQL Server hosting the locally installed MDB.
It should be noted that, based on observations, the primary limiting factor was
DBMS locking and release. No evidence was detected, during testing, that the
processes involved where constrained by system resources. Standard inventory
load of 46 kb per agent (typical for full hardware and software inventory scan
without file manager data as recommended for r11) was generated for 1000
agents per Scalability Server. Subsequent inventory scans may produce
substantially less data and, thereby, reduce the average processing time per
agent. However, for the purposes of capacity planning, validation must be based
on a “worst case scenario”.
As the chart indicates, increasing the number of concurrent tasks can, at first,
drastically reduce the average time to process inventory per agent. For example,
when only one collection tasks is enabled, it takes approximately 8.5 seconds to
process the data. When two collection tasks run concurrently, database
contention increases the time to insert the data for each individual agent from 8.5
seconds to approximately 9.7 seconds. But because the data for two agents is
processed simultaneously the average time to process the data per agent is only
4.86 seconds. The average processing time continues to improve less
dramatically until six concurrent tasks are executing. At that point, competition
for database resources increases and performance begins to gradually
deteriorate.
The performance (seconds per agent) curve can be modeled as follows:
((.3 x (No. of Tasks)2) + (.36 x (No. of Tasks) + 7.8 )/(No. of Tasks)
Using this formula, it is possible to determine what adjustments need to be made

to the number of Domain Managers proposed by the draft solution to meet service
level expectations.
Collection Tasks and Scalability Servers
Before simply increasing the number of concurrent collection tasks in order to

achieve required performance levels, you should consider the impact on the
overall cost and complexity of the resulting solution:
A unique collection task is created for each Scalability Server reporting to a

Domain Manager.
Each collection task can be assigned to one and only one Engine instance.
Concurrent execution of multiple collection tasks requires multiple Engine

instances (since an Engine instance can execute one and only one task
concurrently) and multiple Scalability Servers (since every collection task
processes data from one and only one Scalability Server).
Increasing the number of concurrent collection tasks to improve performance,

therefore, requires increasing the minimum number of Scalability Servers
implemented.
13
Since only one instance may be installed on a given host, increasing the
number of Scalability Servers increases the minimum number of host systems
required and, therefore, the cost in terms of hardware, software and
administration.
Although more detailed planning guidelines for Scalability Servers are provided
later in this guide, keep in mind that the number of concurrent collection tasks
may never exceed the number of Scalability Servers implemented.
Service Level Compliance
Given that, based on the preliminary solution, it is possible to determine the

number of agents each Domain Manager is expected to manage it should also be
possible to gauge if service level requirements for asset data collection can be
met. For example, if the draft solution calls for a single Domain to manage
18,000 agents, the customer expectation may be to have the data collected from
all agents updated within a 24 hour period.
With one concurrent collection task, substitute the known values in the model:
((.3 x 12) + (.36 x 1) + 7.8)/1 = 8.46 seconds/agent
Multiplied by 18,000 agents, the total collection time would be over 42 hours.
Increase the number of concurrent collection tasks to 3 then re-evaluate:
((.3 x 32) + (.36 x 3) + 7.8)/3 = 3.8
Multiplied by 18,000 agents, the total collection time would be approximately 18

hours. It follows, then, that if the number of concurrent collections can be
increased to 3, the service level requirement could be met.
Software Deployment Container Build
Building software deployment containers manually, through the UI, or

automatically, through policy evaluation, requires that the candidate asset’s
installation history be checked for previous installations of the selected software
as well as for the installation of any software that package may depend upon.
The amount of time required to complete this task can be estimated based:
Total number of assets managed by the Domain Manager
Number of candidate assets targeted to receive the software
Average number of installation history records per asset
Performance test results indicate a relationship between the product of these

three factors and the time required to build a software deployment container.
14
Build Deployment Container (25,000 Agents with 100 Installation

Records Each)
1200
1000
Seco n d s 800
Actual
600
Projected
400
200
0
1000 5000 10000 15000 20000 25000
Agents Targeted
Testing was performed on a mid-range system (Dual processor, 8 GB RAM) with

both Unicenter DSM and Microsoft SQL Server hosting the MDB installed locally.
In the case above, an order to deploy a single software packages was distributed
to a varying number of candidates, at varying total asset populations with
increasing numbers of installation history records. As the chart illustrates, the
actual time needed to build the deployment container increases exponentially in
relation to the product of total number of assets, candidates and average
installation history records. The equation below closely models the behavior:
Y = (9.00741E-20 * X2) + (1.25452E-08 * X) + 2.074
Where:
X = Total Assets * Candidate Assets * Avg. Installation History Records
Y = Number of seconds to build the software deployment container
Based upon a comparison of the actual values recorded during the test and
calculated values, the values projected by the model should be within a tolerance
of plus or minus 10 percent.
15
The model equation is useful to verify the possibility of meeting expected service
levels given the proposed number of agents per Domain Manager, the typical
number of candidates targeted for software deployment and the average number
of installation records per asset. For example, assume, based on previous
research, that a Domain Manager is typically expected to control 15,000 assets,
(due to asset configuration, change management policy or other restrictions).
Deployments are expected to target approximately one third of the assets. Over
time, it is expected that an average of 30 software packages will be deployed to
each asset. Service level compliance dictates that lead time for the start of
deployment of an existing package can not exceed one hour. Using the model
equation:
Total Assets Managed = 15,000
Number of Candidates Targeted = 5,000
Average Number of Installation History Records/Asset = 30
X = 15,000 * 5,000 * 30 or 150M
Y = (9.00741E-20 * 150M2) + (1.25452E-08 * 150M) + 2.074 or 31

seconds
In other words, in a Domain managing 15,000 assets, each with an average of 30

installation history records, it should take, approximately, 30 seconds to build a
container and begin deployment of a software package to 5,000 candidates.
Obviously, the projection assumes no other such deployments had been initiated
with container builds in progress or pending.
Consider the impact on expected service levels in the next example. Here, the
Domain Manager will control 25,000 assets and deployments may target all assets
as opposed to just a subset of assets. Also, it is expected over time that an
average of 100 software packages will be deployed to each asset.
Total Assets Managed = 25,000
Number of Candidates Targeted = 25,000
Average Number of Installation History Records/Asset = 100
X = 25,000 * 25,000 * 100 or 62500M
Y = (9.00741E-20 * 62500M2) + (1.25452E-08 * 62500M) + 2.074 or

1138 seconds
The resulting projected impact on lead time required to begin a deployment in this
scenario may be significant (from 31 seconds in the previous example to
approximately 19 minutes).
16
Software Package Distribution to Scalability Servers
Distribution of software packages from the Domain to subordinate Scalability

Servers depends heavily on available network bandwidth. The Data Transport
Service (DTS) is used, by default, for package transfers. Total transfer time can
be reduced by implementing DTS configurations that employ compression and
multicasting. However, even in environments where it is possible to implement
such advanced configurations, risk factors (for example, temporary server or
network outages) can force retries, therefore delaying distribution to one or more
targets will impact total transfer time. Choosing to scale the architecture based
on the expected impact of advanced DTS configuration is recommended only
when the cost of non-compliance is relatively low and performance is not
available. In most cases, it is recommended that “worst case” scenario be
assumed (all transfers will be point to point with little or no compression).
Given the above, the time to transfer a given size software package from a
Domain Manager to a Scalability Server is primarily determined by the LAN speed
and bandwidth availability factor for the slowest link between them. Transfer
time can be estimated using the following simple model:
Data transfer time = <Package Size in mb>/(<LAN Speed in bps>/8 bits

* <Bandwidth Availability Factor as a percentage>
For example, assume the software package to be 600 MB, the LAN speed of the
slowest link to be 100 mbps and bandwidth availability estimated to be 20%
(considered to be an optimistic value by most experts). Substitute the values in
the model and calculate the results:
Data transfer time = 600mb/(100 mbps/8 bits) * .20) = 240 seconds
In this example, it is expected that the package can be transferred from the
Domain Manager to a Scalability Server in approximately 4 minutes. By default, a
maximum of 50 simultaneous transfers are allowed. It follows that the package
can reach up to 50 Scalability Servers in that time.
Limiting the number of Domain Managers essentially limits the number of source
points for software package transfer to Scalability Servers. Consider the following
conditions:
Software Package was not available to be staged at Scalability Servers in

advance (for example, a hyper-fix)
Highly distributed network topology with typically slow links
17
Given these conditions, transfer time from the Domain Manager(s) to the
Scalability Servers would have a significant impact on the ability to meet expected
service levels. To illustrate, assume a 50MB software package must be delivered
to agents at 100 remote sites connected to a central site via 1 mbps links. To
estimate the transfer time:
Data transfer time = 50 mb/ (((.256 * 1.024) mbps/8 bits) * .20) = 7629
seconds
The estimated transfer time is 2 hours 7 minutes. By default, a maximum of 50

transfers can run simultaneously and since the package must reach 100 locations,
a minimum lead time of approximately 4 hours 15 minutes must be added to the
time to deploy and install the software to the target agents.
The example is based on the default and most commonly used settings. It is
possible to reduce the transfer time with some advanced Data Transport Service
(DTS) configuration to optimize packet sizes, implement throttling and
multicasting and actual performance would be dependent upon many variables
specific to the environment. For the purposes of illustration, though, assume the
only configuration change is to implement multicast. Theoretically, the package
could be transmitted to all 100 locations simultaneously - essentially cutting the
total transfer time in half (2 hours 7 minutes).
The benefits of tuning DTS to optimize performance should be obvious and, of

course, is recommended. However, be aware of the risk that environment
specific factors may preclude use of some features in some cases and, such
circumstances may not be readily apparent until the actual implementation is
underway. If the cost of non-compliance is high, it is usually recommended that
the solution be scaled to tolerate “worst cast” scenario based on default
configuration. Reliance on the advanced configuration of DTS to comply with
expected service levels requires acknowledgement of potential risk by the user.
Should the risk be unacceptable, it should be clear the number of source points
(Domain Managers) must be increased when it is necessary to reduce lead time.
Conclusion
The number of agents per Domain Manager impacts the ability to meet service
levels requirements for asset inventory data collection. The relationship between
the time required to collect the data is dependent upon the number of concurrent
collection tasks scheduled. The impact on collection time by increasing the
number of concurrent collection tasks is an improvement in performance to a
point of diminishing returns. Increasing the number of concurrent collection tasks
also impacts the minimum number of Scalability Servers required and may
ultimately impact the overall cost of the solution.
18
Time required to build a software deployment container depends on the total

number of agents managed by the Domain Manager, the average number of
installation history records per asset and the number of candidates targeted for
deployment of a package. Building software deployment containers and staging
software packages at Scalability Servers in advance reduces lead time but risks
the inability to deploy software in a timely manner in a “worst case” scenario.
The potential reduction in the cost of ownership versus the cost of non-
compliance in relation to the likelihood of a “worst case” scenario should be
considered before accepting the risk factor.
The models provided should be used to verify the ability of the infrastructure to
comply with business requirements and expected service levels, but the
architecture must be adjusted if expected demand on the Domain Manager(s)
would exceed estimated capacity to complete operations within expected service
levels.
19
Scalability Server Planning
Determining the appropriate number of Scalability Servers can be a challenge.
Unfortunately no simple formula exists. Addressing this challenge requires a
thorough understanding of the environment, any constraints that may apply and,
most importantly, the expected service levels and/or deliverables expected. With
that information available, it is possible to work through the problem by applying
various principles, guidelines and available tools.
Example Environment
The “DGE” virtual environment referenced in the following examples is a large

organization with a number of offices, varying in size, scattered around the world.
All branches connect to DGE headquarters. DGE will deploy a total of 25,000
agents, using the following basic topology:
Location Type Number of LAN Speed Wan Speed

Agents
Headquarters (1) 5,000 1 gbps N/A
Regional Distribution 2,500 each 100 mbps 10 mbps

Centers (4)
Sales Offices (90) 100 each 100 mbps 1 mbps
Service Centers (40) 25 each 10 mbps 256 kbps
These topology details will be used in examples in the following sections:
Mapping Scalability Servers to the Environment
Variations to this sample architecture may also be provided to demonstrate how

the impact of change to certain elements.
Mapping Scalability Servers to the Environment
It is impossible to propose a solution without having a least a basic knowledge of

the network topology to be serviced. Basic principles still apply: Scalability
Servers near the agents with Engines electronically close to the database.
Applying these principles to a large percentage of client environments may, in
fact, yield a solution that must simply be validated.
21
For DGE, the first working solution would be as follows:
Location Type Number of Agents Number of Scalability

Servers
Headquarters 5,000 1
Regional Distribution 2,500 each 4

Centers (4)
Sales Offices (90) 100 each 90
Service Centers (40) 25 each 40
It should be obvious from the example that the most significant factor impacting
the number of Scalability Servers needed is not the number of agents (25,000)
but the number of locations (135).
Much discussion surrounds the minimum number of agents at location to justify a

Scalability Server. Unfortunately the only correct answer is “…it depends”. In
order to decide, several factors must be considered and compared for each
scenario.
Hardware Cost
Cost of additional hardware is a primary factor to consider when recommending a

Scalability Server be implemented at each location. However, new, dedicated
hardware may not be required in all cases. An existing server with surplus
capacity adequate to support a Scalability Server may be used.
Maintenance Cost
A maintenance cost may be associated with implementing a Scalability Server at

remote locations. An incremental cost may apply even if new hardware is not
required. In some cases, the additional maintenance cost could be significant.
Depending on circumstances, implementing a Scalability Server at the remote site

can reduce maintenance costs. Scalability Servers are also “boot servers” and
can maintain a local software library. Building a new workstation or server or re-
building a host that has failed or been turned over at the remote site can be
controlled centrally. Dispatching a technician to perform the task may no longer
be required. Because software is staged locally in the library, meantime to repair
is reduced if installation/re-installation is required.
22
Administrative Cost
Data Transport Service (DTS) may be a viable alternative to implementing a

Scalability Server at remote sites. When Common Component Services (CCS) is
integrated with DSM r11, DTS routing can be defined to transfer packages to a
designated node at the remote site and then re-distributed to other targets within
the site. Such routings must be defined for each location. The target DTS “hop-
node” (node target to receive and redistribute the package) and the node in the
associated DTS container (container object to which all target nodes are linked)
must be defined and maintained. Manual administration or development of a
custom solution to semi-automate the process will both have an associated cost.
Non-Compliance Cost
In the end, any net additional hardware, maintenance and administrative costs
must be weighed against the cost of non-compliance with business requirements.
For example, assume the cost to implement a Scalability Server is estimated to be
$4,000. Assume also that the estimated cost to the business is estimated to be
$200/hr if a workstation at a remote site is not functioning. Based on historical
data, the average outage can last approximately four hours (some incidents can
be resolved quickly, some require the machine be rebuilt and that requires a
technician be dispatched). On the other hand, the workstation can be re-imaged
from a Scalability Server in an hour. Based on these statistics:
Incidents Outage Cost Remediation Cost Total Cost w/o

w/o Scalability w/o Scalability Scalability Server
Server Server
1 800 400 1200
2 1600 800 2400
3 2400 1200 3600
4 3200 1600 4800
5 4000 2000 6000
6 4800 2400 7200
7 5600 2800 8400
8 6400 3200 9600
9 7200 3600 10800
10 8000 4000 12000
23
Incidents Outage Cost Remediation Cost Total Cost w/

w/ Scalability w/ Scalability Scalability Server
Server Server
1 200 4000 4200
2 400 4000 4400
3 600 4000 4600
4 800 4000 4800
5 1000 4000 5000
6 1200 4000 5200
7 1400 4000 5400
8 1600 4000 5600
9 1800 4000 5800
10 2000 4000 6000
The example is meant to illustrate that, while the other costs might increase if a
Scalability Server is implemented at the remote site, the cost of non-compliance
(i.e., cost associated with unavailable workstations) can be reduced to offset the
increase. Note also that most of the cost to implement a Scalability Server is a
“one-time” fixed cost while non-compliance costs are recurring.
24
Scalability Server Capacity Estimation
The question, “How many agents can an r11 Scalability Server support?” has been
posed many times. No limit has been reached in testing to date and, even if an
actual breakpoint had been established, the answer to the question would still
only be useful if the sole requirement was a solution with the fewest number of
servers. However, the objective is to deliver an architecture that addresses the
business requirements and satisfies service level constraints. Therefore, the real
question that must be answered is “How many Scalability Servers are needed to
implement the solution?” Answering this question requires identifying certain
facts and understanding their relationships in order to perform calculations that
ultimately result in an estimate.
The principle service level requirement for software distribution is typically stated
as “the amount of time allowed for a package to be delivered to all targets.” The
following discussion on how this requirement impacts the number of Scalability
Servers needed, continues with the DGE client scenario which was introduced in
the previous chapter. For the purposes of this chapter, the DGE client has a
requirement to deliver to all targets in one day.
IMPORTANT: An understanding of the business requirements, service level

constraints and network topology is required before proceeding. Models are
provided to illustrate the impact of common factors on expected performance and
not to predict actual metrics. Results of calculations performed are estimates
and intended as guidelines. Actual performance may vary in a live, production
environment.
LAN Environment
Network speed affects both transfer time and installation time. In most
environments, 100% of the bandwidth will not be available for Unicenter DSM use
as other applications will be competing for the same resources. Therefore, you
will need to have a reasonable estimate of the percentage of bandwidth that will
be available for package transfer and installation. For example, an estimate of
20% would be considered optimistic.
Time Restrictions
Restrictions governing the hours during which software may be installed may also
apply. This “window of opportunity” can be defined by a start time and end time.
The difference between the start time and end time is used to determine the
actual numbers of hours per day available for installation.
25
For example, if software may only be delivered after backups are completed
(12:00 am) and must be completed before the beginning of the business day
(07:00 am) the “window of opportunity” is seven hours.
Typical Package
Installation time can vary widely depending on the efficiency and complexity of
the set up process. Two packages that may be relatively close in size can have
significantly different installation times. Package size also affects the amount of
time required to transfer source files from the server to the agents. The size will
vary depending on the application. For example, the package size of a
commercial application, like Microsoft Office, can be many times the size of a
package for a security fix. An initiative to track package sizes for applications
acquired and installed for development of software signatures has been untaken.
As data becomes available, statistics for use in capacity estimations will be made
available.
Estimated number of seconds to deliver a package is calculated based on package

size, installation time and network speed adjusted for anticipated bandwidth
availability.
Example:
Package Size: 600 mb
Package Installation Time: 10 minutes
Network Speed: 100 mbps
Bandwidth Availability Factor: 20 %
Calculations:
Data transfer time: 600mb/(100 mbps/8 bits * .20) = 240 seconds
…where 600 mb is the package size, .20 is the estimated percentage of

bandwidth available, 100 mbps is the network speed in megabits and 8 is
the number of bits in a byte.
Delivery time: 240 + 600 = 840 seconds
…where 600 is the estimated number of seconds for installation procedure to

execute if run locally and 240 is the amount of time calculated to transfer the
actual source files called for by the installation.
26
Once the number of packages deliverable per unit time is estimated and time
restrictions are known it is possible to calculate the expected value for one of four
metrics provided values for the other three are known:
Maximum Simultaneous Activations
Number of Scalability Servers
Service Level
Number of Target Agents
For example, to determine the number of Scalability Servers required you will
need to know the values for maximum simultaneous activations, service level and
number of target agents. Principles, procedures and models are provided since
optimization will typically involve several “what if” cases.
Adjustments for Resource Contention and Overhead
As might be expected, as the number of agents per Scalability Server increases

resource contention and overhead also increases. Observations in test
environments showed that the impact followed a non-linear curve.
Resource Contention
200.00
150.00
Seconds
100.00 Series1
50.00
0.00
00
00
00
00
00
00
00
00
00
0
10
20
30
40
50
60
70
80
90
Agents
The following formula was derived to estimate the “overhead’ based on the
number of agents:
(0.0075 * [Number of Agents]2) + (1.15 * [Number of Agents])
27
In reality, it was not possible to retest on every possible hardware platform.

Results did not vary greatly between equipment that met the minimum
recommended resource requirements for Scalability Servers. It is not expected
that upgrading resources (i.e., additional RAM, more or faster processors) would
reduce the estimated overhead significantly.
Maximum Simultaneous Activations
By default, Unicenter DSM is configured to limit the number of agents connected

to a server executing installation procedures to 25. Understand that increasing
the value may not result in the completion of more installations in a fixed time
period. In fact, because the competition for limited resources increases, the
individual installations may slow down to a point where fewer will complete. The
value should be altered only after careful testing and study.
For example, suppose the following is known:
Time to transfer and install a package is estimated to be 840 seconds.
Number of targets agents is 150.
Number of Scalability Servers planned for a site is 1.
Service Level required is 1 day between the hours of midnight and 7:00 am
(essentially 7 hours or 25,200 seconds (7 * 60 * 60)).
Because it is a small site, an existing server has been proposed to host the DSM
Scalability Server. The concern is that 25 simultaneous deliveries may impact the
network and server performance. The question asked is “what is the minimum
number of simultaneous activations required to satisfy the service requirement?”
The calculation would be:
(840 * 150) / 1 * (7 * 60 * 60) = 5 simultaneous activations
Based on the estimates and calculations, the service commitment could still be
met if maximum simultaneous activations value is set to five (although a slightly
higher value may be recommended). Adjustments for resource contention and
overhead still must be applied.
Number of Scalability Servers Required
Typically, it is necessary to estimate the number of Scalability Servers needed to

provide the service level required when a large number of agents will be located
on the same LAN.
For example, suppose the following is known:
Maximum Simultaneous Activations will be 25 (default).
28
(840 * 2500) / 25 * (7 * 60 * 60) = 3.33 servers
Based on the initial estimates and calculations, at least four Scalability Servers
will be needed to service the location. Adjustments for resource contention and
overhead still must be applied.
Service Level Required
In some cases, it may be necessary to answer questions similar to “How long will
it take to delivery to all agents from a specified number of Scalability Servers?”
In other words, what level of service could be expected?
What if the following is known?
Number of Scalability servers proposed is 2.
(840 * 2500) / (25 * 2 * (60 * 60)) = 11.66 hours
In other words, based on the estimates and calculations, it would be expected

that the package would reach all 2500 agents in approximately six hours (if an
equal number of agents are serviced from each). Adjustments for resource
contention and overhead still must be applied.
Number of Target Agents
The most common “what if” question asked is “how many agents can a package
be delivered to from a Scalability Server?” given the following:
Number of Scalability servers proposed is 1.
29
(25 * 1 * (7 * 60 * 60)) / 840 = 750 target agents
Based on estimates and calculations, it may be possible to reach 750 targets in

seven hours. Adjustments for resource contention and overhead still must be
applied.
30
Conclusion
Planning a Unicenter DSM solution begins with gathering and understanding
business stakeholder requirements and expected service levels. The design
evolves through a process that begins with drafting a rough architecture that
aligns with expectations and is then refined as needed by verifying the ability
to comply with service levels using models based on information generated by
CA conducted performance testing. The result is an architecture designed to
meet or exceed the user expectations.
31

Unicenter Desktop and Server Management: Solution Planning Guide

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Unicenter Desktop and Server Management: Solution Planning Guide

Transféré par

Droits d'auteur :

Formats disponibles

Unicenter Desktop and Server

Solution Planning Guide

The manufacturer of this Product is CA.

Copyright © 2006 CA. All rights reserved.

Local or Remote MDB ................................................................3

Domain Manager Planning .......................................................7

Domain Manager Capacity Estimation..................................11

Scalability Server Capacity Estimation .................................. 25

To determine if deviation from the best practice is justified requires understanding

Ingres or Microsoft SQL Server

Based on performance, Microsoft SQL Server (2000 or 2005) is the recommended

 Non-Windows solution is insisted upon (discussion of the

 Small-to-medium client where the additional cost of Microsoft SQL Server is a

In general, the guidelines that should be used to determine whether a local or

Dedicated Database Server(s)

Multiple Applications/Shared Database

Additional considerations are required when multiple CA applications will be

Installing multiple applications on separate hosts reduces potential administrative

When designing an architecture for a single CA application it is clear that co-

Consider, however, that such an implementation requires a super-administrator

Conversely, implementing a Domain Manager based on management scope

Assets would be considered geographically isolated when they are located at

For example, consider an environment in which assets are concentrated at two

 Scenario 1: In general the consumers of the asset data reside at

It should be apparent that the solution suggested in “Scenario 2” may result in a

The guidelines and principles provided should make it possible to develop an

 Inventory Data Collection and Processing

 Software Deployment Container Building

 Software Package Distribution to Scalability Servers

After devising a preliminary architectural model based on the administrative,

IMPORTANT: An understanding of the business requirements, service level

Inventory Data Collection and Processing

Although the performance of many processes executed by Unicenter DSM Domain

Testing was performed on a mid-range system (Dual processor, 8 GB RAM) with

The performance (seconds per agent) curve can be modeled as follows:

((.3 x (No. of Tasks)2) + (.36 x (No. of Tasks) + 7.8 )/(No. of Tasks)

Using this formula, it is possible to determine what adjustments need to be made

Collection Tasks and Scalability Servers

Before simply increasing the number of concurrent collection tasks in order to

 A unique collection task is created for each Scalability Server reporting to a

 Concurrent execution of multiple collection tasks requires multiple Engine

 Increasing the number of concurrent collection tasks to improve performance,

Service Level Compliance

Given that, based on the preliminary solution, it is possible to determine the

((.3 x 12) + (.36 x 1) + 7.8)/1 = 8.46 seconds/agent

((.3 x 32) + (.36 x 3) + 7.8)/3 = 3.8

Multiplied by 18,000 agents, the total collection time would be approximately 18

Software Deployment Container Build

Building software deployment containers manually, through the UI, or

 Total number of assets managed by the Domain Manager

 Number of candidate assets targeted to receive the software

 Average number of installation history records per asset

Performance test results indicate a relationship between the product of these

Build Deployment Container (25,000 Agents with 100 Installation

Testing was performed on a mid-range system (Dual processor, 8 GB RAM) with

Y = (9.00741E-20 * X2) + (1.25452E-08 * X) + 2.074

X = Total Assets * Candidate Assets * Avg. Installation History Records

Y = Number of seconds to build the software deployment container

Service Level Compliance

Total Assets Managed = 15,000

Number of Candidates Targeted = 5,000

Average Number of Installation History Records/Asset = 30

Non-Windows solution is insisted upon (discussion of the

Small-to-medium client where the additional cost of Microsoft SQL Server is a

Scenario 1: In general the consumers of the asset data reside at

Inventory Data Collection and Processing

Software Deployment Container Building

Software Package Distribution to Scalability Servers

A unique collection task is created for each Scalability Server reporting to a

Concurrent execution of multiple collection tasks requires multiple Engine

Increasing the number of concurrent collection tasks to improve performance,

Total number of assets managed by the Domain Manager

Number of candidate assets targeted to receive the software

Average number of installation history records per asset

Software Package was not available to be staged at Scalability Servers in

Highly distributed network topology with typically slow links