BestPractice8.1 | Provisioning | Server (Computing)

BMC BladeLogic Server Automation Best Practices for Deployment and Configuration

BMC BladeLogic Server Automation Best Practices for for Deployment and Configuration

REVISION HISTORY
Date March, 2011 Product version 8.1.00 Revisions Initial version.

Page 2

................................ 26 Appendix: TCP/UDP Port Usage.............................................................................................................. 16 Large-Scale installations ...................................................................................................................................................................................................................................................................................................................................................................... 22 Recommendations for Configuration servers .................................. 6 NSH Script Jobs .................................... 20 About Java memory ........ 13 BMC BladeLogic Server Automation components ......................................... 7 Provision Jobs .................................................................................................................................................. 2 Understanding job behavior ......................................................................................................................................................................................................................... 27 Page 3 .............................................................. 11 Administrative jobs......................................................................................... 24 Recommendations for NSH Proxy servers ................................................................................................................................................................................................................................................................ 21 Recommendations for job servers ............................................................................................................................................................................................... 9 Virtualization Jobs............................................................................................ 7 Deploy Jobs ............................................. 4 Compliance ............................................................................................................................................................. 4 Job execution framework ........... 19 Configuration guidance ..................................................................................................................................................................................................................................................... 20 About thread pools.............................................................................................................................................................................. 9 Patching Jobs ................................................................................................................................................................... 21 About database connections ................................................................................................................................................................................................................................... 17 Geographically-distributed installations ..................................................................................................................................................................................................BMC BladeLogic Server Automation Best Practices for for Deployment and Configuration TABLE OF CONTENTS Revision history ................................................................................... 5 Component Discovery Jobs ............................................................................................................................... 13 Simple installations .................................................................................................................................................................. 12 Deployment guidance ..............................................................................................

otherwise. which maintains yet another thread pool. This can present a potential resource issue. Lightweight work items Some work items are designated as lightweight work items because their execution consumes significantly fewer server resources than does the execution of normal work items. While it waits for a response from the remote target. If the lightweight work item thread pool is not empty (that is. When a work item must perform a remote operation. as the work item thread is not available to service other work items with more active processing needs. each job server also maintains a separate thread pool for lightweight work items. This resource utilization concern is addressed by the introduction of asynchronous tasks. Currently.0. A work item thread assigned to such a work item blocks while it waits. threads from this pool manage lightweight work items. Like jobs. Each job server maintains a pool of threads. The main work of a job is the creation and management of individual work items and their results. Some work items. Work items are separately-schedulable units of work that are undertaken as part of the execution of a job. Asynchronous tasks are a relatively new feature of the job execution framework. This section describes the overall operation of the framework.000 target hosts can create and schedule execution of possibly several thousand work items. A work item may or may not be executed by the same job server that is responsible for executing the job that created it. a work item thread is assigned exclusively to that work item. Asynchronous BlExec tasks are managed by the BlExec service. Asynchronous BlExec tasks While a work item is executing. has a non-zero size). Work items scheduled for execution are maintained in a work item queue in the job server. and some are not. however. having been introduced in BMC BladeLogic Server Automation version 8. work items whose implementation is not asynchronous task aware still perform remote operations directly and cause their work item threads to wait for the operation to complete. an asynchronous BlExec task does not consume any thread resources. corresponding to different steps or stages of the job. A work item is almost always bound to one target host. In addition to the work item thread pool. all work items (lightweight and nonlightweight) are managed by the normal work item thread pool. work items are executed by job servers. and network resource requirements. Page 4 . Thus. is maintained by each job server for the execution of work items. spend much of their time waiting for results from operations being carried out remotely. known as work item threads. Then the work item itself terminates. Jobs. but the tasks occupy a thread from the pool only when they have active processing to perform. a job may generate multiple work items for each target. A work item must be explicitly written to make use of asynchronous tasks. the work item can instead create and queue an asynchronous BlExec task to perform the operation. JOB EXECUTION FRAMEWORK All BMC BladeLogic Server Automation jobs execute in the job execution framework. targets. called the job thread pool. some BMC BladeLogic Server Automation jobs are asynchronous task aware. and work items The execution of a BMC BladeLogic Server Automation job begins with the job being placed in a work queue of jobs waiting to execute. storage. the lightweight work item thread pool.BMC BladeLogic Server Automation Best Practices for for Deployment and Configuration UNDERSTANDING JOB BEHAVIOR This section provides a brief overview of the runtime behavior of the various job types. with emphasis on computation. It is in the execution of work items that the job carries out its responsibilities. on a target host. dedicated to executing jobs in the job queue. for example. or to a component on a target. Further. instead of performing that remote operation and waiting for a response. a job that is scheduled to execute against 1. A pool of threads.

6 and earlier After the snapshot job executes.bnp from that job run is still available on the job server. then the old . After the comparison between the two .0 Version 8.snp file.bnp file is used directly. Files are the most common type of asset used in Snapshot and Audit Jobs. Audit. Version 8. repeated snapshots of an asset that changes very little or not at all result in relatively little information being stored in the database.1.snp file. To perform a full snapshot of a file.bnp file as it would have existed following the last scan of this particular target.bnp (baseline snapshot) representing the previous scan.snp file is completed on the Application Server. The lone exception to this rule is that when a file’s content is included in a snapshot. If the . it is copied from the file server to the local Application Server and then used for comparison. One . the file is deleted). the entire contents of that file must be transferred to the Application Server. instead of the actual contents. processing steps follow this flow: Only in version 7.6 and earlier Version 7. (In BMC BladeLogic Server Automation version 8. Application Server CPU High Network Traffic High Database Load Moderate Agent Low Page 5 .bnp of the current snapshot of the asset and the . In BMC BladeLogic Server Automation 8. and rules-based Compliance Jobs. As it is received by the Application Server.6 and earlier Version 8. if one exists.snp file. For example. however. Therefore. This comparison is performed between the new .snp file is constructed for each component part. Snapshot Jobs Snapshot jobs collect information about assets from a target and convey that information to the Application Server. When construction of the .6 and earlier Version 8. the . capturing just the MD5 digest (checksum) of a file. The job server uses the data in the database to reconstruct a . COMPLIANCE This section describes Snapshot. results in the calculation of the 128-bit MD5 digest value on the target and transmission of only that 128-bit value to the Application Server for storage in the . Otherwise. it is then scanned and compared to the most recent prior snapshot from that target.snp (snapshot) suffix.0. the next processing step takes place.snp file is renamed to . Version 7.BMC BladeLogic Server Automation Best Practices for for Deployment and Configuration Version 7. no additional data is recorded in the database. In BMC BladeLogic Server Automation 8.1 The BlExec service and asynchronous BlExec tasks are not available earlier than BMC BladeLogic Server Automation 8.bnp file from the last scan of this particular target is available on the file server (see below).bnp file from the prior snapshot). The . The table shows a summary of resource usage for Snapshot Jobs. Version7.0 and later. the file’s content is received as a separate file and not included in the . in the case of an unchanged file. The exact means by which the . Deploy jobs and Virtual Guest Jobs also take advantage of asynchronous BlExec tasks.bnp file also remains on the job server. information about each asset is stored in a local (on the Application Server) file with a . and a .0. only the differences between the two versions are stored in the BMC BladeLogic Server Automation database.bnp and copied to the file server. NSH Script jobs and patch analysis jobs take advantage of asynchronous BlExec tasks. the . On the other hand.6 and earlier If the last scan of this particular target ran on the same job server and the old .0. the next processing step takes place.bnp files (that is. Otherwise.bnp file is obtained depends on the BMC BladeLogic Server Automation version.0.

For example. for each component part. then each rule failure selects a BLPackage to be included in a combined remediation BLPackage for that host. For Audit Jobs. in that it involves constructing and comparing two snapshot files on the Application Server (with a . operate by: collecting asset information on the target transferring that data back to the Application Server applying the user-specified rules to the returned data to assess the target’s compliance Unlike Audit and Snapshot jobs. After each audit target is processed. In the case of a noncompliant result. each target of the audit job is processed by first constructing a target . The result (compliant.snp files are recorded in the database.snp file and then comparing the master and target .BMC BladeLogic Server Automation Best Practices for for Deployment and Configuration Audit Jobs Audit Job behavior is largely similar to that of Snapshot Jobs. Compliance Jobs do not use temporary snapshot files (. Each suitable target is then contacted and sufficient assets collected to perform a test of the signature condition for the target.snp or . The Compliance Job does not complete until the BLPackage Deploy Job has completed. or noncompliant with exception) of applying each condition is recorded in the database. The table shows a summary of resource usage for Compliance Jobs that perform autoremediation. For a snapshot-based audit.bnp) on the Application Server. master .snp files are copied to the file server. Application server CPU High Network Traffic Moderate – High Database Load Moderate Agent Moderate Network Traffic High Database Load Moderate Agent Low COMPONENT DISCOVERY JOBS Component Discovery Jobs first use component applicability rules to select appropriate targets from the requested list of targets. The table shows a summary of resource usage by Component Discovery Jobs. and shared among any Application Servers that run work items for the Audit Job. each work item operates by looping through the component parts of its assigned component. (Any other hosts with the same combination of failing rules will use the same remediation package. Differences between the two . a snapshot of the master target is performed and the results captured in . a single request is issued to collect the required information for each of the assets to be tested.snp files.snp file is generated from data in the database.snp files are marked for deletion on the file server. The master . regardless of how many earlier audits may have detected the same difference. noncompliant. For live audits. master .snp files for that target are discarded. it decides whether or not it needs to retrieve data from the target. Application Server CPU High Compliance Jobs Compliance jobs. Page 6 . the specific value under test is also recorded in the database. if necessary. a non-complying condition on file size causes the actual file size to be recorded in the database. the master . Compliance autoremediation If a target is noncompliant and if the Compliance Job has the Allow Auto-remediation option specified.snp files have been constructed. the target .snp files are always constructed as part of the job.snp file is persisted in the database. For each difference detected. the relevant conditions are applied to determine compliance. also called rule-based compliance jobs. but not the contents of the file. As each requested asset arrives on the Application Server.) The Compliance Job then runs a BLPackage Deploy Job against the noncompliant targets.snp suffix this time). When a Compliance Job runs.snp files. After the master . The table shows a summary of resource usage for Audit Jobs. Upon completion of the Audit Job. and recording only the differences. If it does need to retrieve assets for the current component part. the asset from the target .

Even for scripts executed on the Application Server however. see Asynchronous BlExec tasks on page 4.1.0.nsh script to copy (push) the requested file. passing the host list as a parameter (Type 4) From a performance perspective. This script runs on the Application Server. the script running on the Application Server copies the file to one or more remote repeaters. rather than on the Application Server. Page 7 .1.1 and later Prior to BMC BladeLogic Server Automation version 8. there is no direct data transfer between the source and the target. Choosing this option causes the job to be executed using asynchronous BlExec tasks.0. Issues with deadlock and hangs are resolved in release 8. Type 3 jobs differ from the other types in that they execute the script on the target. any nexec commands are executed on the target. The table shows a summary of resource usage by the Process Spawner.0 and later As of BMC BladeLogic Server Automation version 8. BMC recommends its use. For an indirect File Deploy Job. Version 8. That separate process can be created and managed either by the Application Server or by a separately-running application known as the Process Spawner. Use of the Process Spawner offers significant performance benefits for NSH Script jobs. Use of the Process Spawner can significantly reduce the overhead of creating and tearing down the process used to execute the NSH script. Version 7. A File Deploy Job operates by first constructing and then executing an . Process Spawner NSH Script Jobs invoke the actual NSH scripts in a separate process. the script running on the Application Server copies the file from its source to each target.6 and earlier Version 8. users have the option of selecting asynchronous execution for Type 3 NSH Script Jobs.BMC BladeLogic Server Automation Best Practices for for Deployment and Configuration Application Server CPU Low – Moderate Network Traffic Low – Moderate Database Load Moderate Agent Low NSH SCRIPT JOBS Scripts executed by NSH Script Jobs are categorized by the four radio buttons presented in the job’s Add Script dialog: Execute the script separately against each host (Type 1) Execute the script once. passing the host list as a parameter to the script (Type 2) Copy and execute the script against each host separately (Type 3) Execute the script using the PERL interpreter. BMC does not recommend using the Process Spawner in these versions. use of the Process Spawner can result in deadlocks or hangs under high workloads. a script then runs on each repeater to push the file to the final target. Version 8. For a direct File Deploy Job. Application server CPU Varies Network Traffic Varies Database Load Low Agent Varies DEPLOY JOBS This section describes file and package deploy jobs. The Application Server acts as an intermediary. with the Application Server again acting as an intermediary. File Deploy Jobs A File Deploy Job arranges to deploy a file from any NSH-accessible location to one or more remote targets.

Similarly. for example. no staging is required. if any. See Lightweight work items. Any necessary files are copied to the target in preparation for deployment. Commit Execute Post commands. these commands are executed on the remote target. If the package uses the agent mounts source option. page 4. See Asynchronous BlExec tasks. Notes Asynchronous BlExec task High file server load Lightweight Work Item Lightweight Work Item. Undo If the deployment is unsuccessful. Run installation commands on the target. including. several phase work items have been enhanced to use asynchronous BLExec tasks for execution. possibly by way of repeater servers. allowing for increased throughput even without populating the thread pool for lightweight work items. if any. on the target. as most of the work for this phase is carried out on the target hosts Page 8 .1 and later As of BMC BladeLogic Server Automation version 8. its effects are reverted on the target. presents almost no load to the BMC BladeLogic Server Automation infrastructure. Application Server CPU Moderate Network Traffic High Database Load Moderate Agent Moderate The server from which the files are deployed can experience heavy load during a File Deploy Job. as most of the work for this phase is carried out on the target hosts. on page 4. The Commit phase. in contrast.BMC BladeLogic Server Automation Best Practices for for Deployment and Configuration When pre-commands or post-commands are specified as part of a File Deploy Job. Execute Pre commands. Phases of the BLPackage Deploy Job BLPackage Deploy Jobs comprise a sequence of work items run in the following phases: Phase Simulate Staging Work Item Description This is a dry run or preflight phase to verify that conditions exist which should lead to a successful execution. registry keys and configurations within files. Asynchronous BlExec task Lightweight Work Item Asynchronous BlExec task The Staging phase has the potential to generate significant workloads on the file server (or other server providing the package source files). work items for the BLPackage Deploy Job’s Commit phase are implemented as Lightweight Work Items.1. not just files. With the exception of work items for predeploy and postdeploy commands. any Repeaters involved can experience heavy load during a File Deploy Job. The table shows a summary of resource usage by BLPackage Deploy Jobs. The table shows a summary of resource usage by File Deploy Jobs. The Commit phase. Application Server CPU Low Network Traffic High Database Load Low Agent Low The Staging phase has the potential to generate significant workloads on the file server (or other server providing the package source files. These server objects are packaged together for unattended deployment on multiple remote hosts. on the target. Version 8. in contrast. presents almost no load to the BMC BladeLogic Server Automation infrastructure. BLPackage Deploy Jobs A BLPackage is an aggregation of many types of server objects.

Page 9 . As the target device reboots. The data store server may experience moderate to high load during provisioning. while installation files are served off an NFS server (data store). for initial booting instructions TFTP server.BMC BladeLogic Server Automation Best Practices for for Deployment and Configuration PROVISION JOBS A Provision Job establishes the necessary network resources required for a target machine to be provisioned upon reboot. and a payload. it requires network access to servers from which it can retrieve instructions and downloadable artifacts. for operating system installation files Generally speaking. software patches released by a patch vendor (that is. Solaris provisioning The Oracle JumpStart technology used for provisioning Solaris machines relies on three separate JumpStart functions: JumpStart Boot Server JumpStart Install Server JumpStart Configuration Server These functions may be provided independently. from which it retrieves the system package Data store. HP-UX provisioning The HP-UX Ignite technology uses a single Ignite master to control the provisioning target and to provide the operating system installation files. in most cases. depending on the type of target device. a Windows or Linux target contacts the following: DHCP server. The table shows a summary of resource usage by Provision Jobs. as the target device is rebooting. Microsoft. describing the patch and its applicability. containing the actual bits of the patch. from which it downloads a pre-boot kernel image. Provisioning details Windows and Linux provisioning Provisioning support for Windows and Linux devices is based on the Pre-Execution Environment (PXE) standard. AIX provisioning The IBM AIX Network Installation Manager (NIM) technology uses a NIM master to control the provisioning target. to identify a PXE server PXE server. Application Server. The device’s boot process varies. Of the three functions. but in all cases. When booting under the control of a provisioning job. it requests progressive instructions from BMC BladeLogic servers and downloads boot images and operating system installation files from servers on the network. The boot server must be on the same network as the provisioning target. Application Server CPU Very Low Network Traffic Low Database Load Low Agent Low Provisioning servers (whatever the type) must be available to the target host being provisioned. then the job monitors the progress of the provisioning activity as it occurs on the target. the install server (the data store) bears the greatest load. Red Hat. but the network link between the target device and the data store server may experience substantial bandwidth usage. none of these activities impose significant computational demands on the supporting servers. PATCHING JOBS In BladeLogic. or combined into one or two actual JumpStart servers. Adobe) are conceptualized as comprising metadata.

As of BMC BladeLogic Server Automation version 8. Online patch catalogs are updated by downloading additional content from vendor and/or metadata-provider websites. Patches are organized into patch catalogs.1 and later Prior to BMC BladeLogic Server Automation version 8. the patch remediation job runs an algorithm that creates a set of BLPackages and BLPackage Deploy Jobs. patch analysis for Solaris was performed primarily on the Application Server. patch analysis for all target types now uses an asynchronous agent call. Further. Application server CPU Low* Network Traffic Low Database Load Low Agent Moderate – High* *See version-specific notes. Catalog Update Jobs You can create Catalog Update Jobs for each type of patch repository. For Windows and Solaris. patch analysis processing takes place on the affected target. Red Hat requires a payload download. rather than on the target. Application Server CPU High Patch Analysis Jobs On all supported platforms as of BMC BladeLogic Server Automation version 8. which is an NSH-accessible directory somewhere in the BladeLogic environment. For example. The table shows a summary of resource usage by Catalog Update Jobs. then you must identify a Windows Helper Server Location when you create the repository. That is. which typically mounts removable storage media onto which patch information is already loaded. The Application Server running a catalog update job for an online repository requires web access to these sites (that is. Version 7. Network Traffic High Database Load Moderate Agent Low The table shows a summary of resource usage by Catalog Update Jobs. for Solaris patch analysis. If different Page 10 . and the Application Server is running on a Linux host. without downloading the payload. the target agent then performs the necessary calculation to determine which patches to install on the target. Version 8. Patch Remediation Jobs A patch remediation job does the following: Runs a patch download job to download patch payloads of missing patches that have not yet been downloaded. Based on the patch analysis results. the Application Server must be configured to allow traffic to pass through any firewalls and web proxy servers). A common strategy for populating an offline repository is to transfer patch content on removable media with the help of a BMC-provided download utility. the catalog for Windows patches is separate from the catalog for Red Hat patches. Offline patch catalogs are updated by transferring content from a local server. If a repository is to include Windows patches. patch analysis for Solaris now occurs on the target. This can present a moderate to high work load on the Application Server. If multiple servers have the same set of missing patches. the patch remediation job creates a single Deploy Job with BLPackages that target the servers.0. An offline or air-gapped environment is one in which the repository does not have direct access to the internet and therefore patches cannot be directly downloaded from the vendor site to an offline repository. the relevant metadata (typically less than 5 MB) is transferred from the repository to the target agent.0. above. you can run analysis with just the metadata.6 and earlier Version 8.BMC BladeLogic Server Automation Best Practices for for Deployment and Configuration Patches are stored in a repository in the computing environment. allowing greater concurrency on the Application Server. So you can create a Windows patch catalog with all Windows 2008 patches and only download payloads of the patches that are found missing. The Windows Helper Server Location is a user-defined temporary directory on a Microsoft Windows server which is used to decrypt files downloaded from the vendor site.0. according to filters defined in BladeLogic.0. where it is decoded.

The BLPackage Deploy Jobs are wrapped into a Batch Job. applies the template to a stateless blade (so that the blade becomes a server with an identity). The UCS Provisioning Job takes a predefined template. The chassis also includes a hardware entity (the Fabric Interconnect) that manages all the computing. Internally. The table shows a summary of resource usage by Virtual Infrastructure Discovery Jobs. network. The table shows a summary of resource usage by UCS Provisioning Jobs. a Virtual Infrastructure Discovery Job scans the network to identify ESX servers or other virtual hosting environments and then interrogates them to identify guests hosted by that computer. the patch remediation job creates a Deploy Job for each unique set of missing patches. so the behavior and resource demands of a Virtual Guest Job correspond to those of the Deploy Job. a Virtual Guest Job communicates with the VCenter through a custom object (CO) that must be installed on the Virtual Center host. networking configuration. or is scheduled to execute at a later time. from a known VCenter or other virtual infrastructure. Application server CPU Low Network Traffic High Database Load Low Agent Low See BLPackage Deploy Job. The BladeLogic UCS custom object (CO) communicates with this hardware entity. and then provisions the server. Virtual Infrastructure Discovery Job Also called a sprawl job.BMC BladeLogic Server Automation Best Practices for for Deployment and Configuration servers have different patches missing. Virtual Guest Jobs require minimal Application Server resources. which may experience heavy workload during the Staging phase of deployment. and storage configurations (WWNN and WWPN). The Batch Job then executes immediately (if specified). A UCS template is a configuration that contains settings to configure a blade to become a server. above. Patch resources are stored in the patch repository. for more information about the resource demands of the deploy operations. with or without an operating system. Virtual Guest Jobs operate as BLPackage Deploy Jobs. VIRTUALIZATION JOBS Virtual Guest Job A Virtual Guest Job constructs a virtual guest. This template contains server identity information (MAC address). Network Traffic Moderate Database Load Low – Moderate Agent Low Page 11 . Configuration decisions for the new virtual guest are captured in a Virtual Guest Package. For some steps in its operation. Application Server CPU Very Low Network Traffic Low Database Load Low Agent Low Virtual Guest Jobs make demands on the Virtual Center host to accomplish construction of the virtual guest. The table shows a summary of resource usage by Patch Remediation Jobs. Application Server CPU Low – Moderate UCS Provisioning Jobs A Cisco Unified Computing System (UCS) chassis comprises a number of hardware blades which act as a pool of computing resources. and storage connectivity resources. The table shows a summary of resource usage by Virtual Guest Jobs.

Application Server CPU Low ACL Push Jobs At its core. The table shows a summary of resource usage by Update Server Properties Jobs. etc. The table shows a summary of resource usage by ACL Push Jobs. IP address. Application Server CPU Low Network Traffic Low Database Load Low Agent Low Network Traffic Low Database Load Low Agent Low Distribute Configuration Objects Jobs The table shows a summary of resource usage by Distribute Configuration Objects Jobs. and then overwrites the user file (the file in the target’s rsc directory whose name is ‘user’) with those entries.BMC BladeLogic Server Automation Best Practices for for Deployment and Configuration Application Server CPU Very Low Network Traffic Low Database Load Low Agent Low UCS Provisioning Jobs make demands on the UCS Fabric Interconnect to accomplish the actual construction of the virtual guest. ADMINISTRATIVE JOBS Update Server Properties Job The Update Server Properties Job invokes miscellaneous remote commands to obtain server name. Application Server CPU Low Network Traffic Low – Moderate Database Load Low Agent Low – Moderate Decommission Configuration Object Jobs The table shows a summary of resource usage by Decommission Configuration Object Jobs. operating system type and version. Application Server CPU Low Network Traffic Low Database Load Low Agent Low Page 12 . an ACL Push Job computes a set of entries for the user file on each target.

but.BMC BladeLogic Server Automation Best Practices for for Deployment and Configuration DEPLOYMENT GUIDANCE A BMC BladeLogic Server Automation deployment typically involves a large number of individual software elements arrayed across a number of physical servers deployed around the environment. For more information. This section discusses performance and other considerations for the deployment of the various BMC BladeLogic Server Automation software elements. including the number of targets to be managed and the expected job load for the system. Additionally. NSH Proxy Servers NSH Proxy Servers perform a specialized role in BladeLogic installations. or combinations of profiles. depending on its configuration. The number and configuration of Application Servers in a deployment depends on many factors. Accordingly. In many environments. Within limits.exe) connect to configuration servers to allow interaction with the BladeLogic system. do not impose excessive workload on the hardware. Application Servers are tightly coupled to the database and impose significant demands on the server that hosts the database. there is anecdotal evidence that high packet loss rates on the Application-Server-to-database link may cause issues for (expose defects in) the Oracle JDBC driver. BMC recommends the use of a dedicated physical machine or cluster to host the database server for BladeLogic. Job servers Application Servers configured as job servers are responsible for the execution of BMC BladeLogic Server Automation jobs. BMC BLADELOGIC SERVER AUTOMATION COMPONENTS This section describes the components that may constitute a BMC BladeLogic Server Automation installation. job servers are limited by internal resource contention. as described in NSH proxies. BLCLI command line client. surprisingly. it may be advisable to configure multiple job servers on the same physical machine in order to make more complete use of the available hardware resources. An Application Server can fulfill any of several distinct profiles. page 16. Page 13 . High latency on the link between the Application Servers and the database server can cause unacceptable performance for BladeLogic. A configuration server provides middle-tier functionality. A configuration (UI) server is an Application Server of type CONFIGURATION of type ALL (which includes CONFIGURATION). in a virtualized environment. it is acceptable to run multiple Application Servers on a single physical server while still maintaining acceptable performance. Alternatively. answering requests from BMC BladeLogic Server Automation client applications both for data and for operations on that data. Application Servers A BMC BladeLogic Server Automation deployment comprises one or more Application Server (appserver) processes. Database server At the center of every BMC BladeLogic Server Automation installation is the BMC BladeLogic database server. bmi. The database server or cluster should be on the same LAN as the BMC BladeLogic Server Automation Application Server. see Adding Application Server instances. you can run multiple job server guest VMs on the same physical server. Configuration servers BMC BladeLogic Server Automation clients (rich client UI. on page 17.

page 24. Repeaters For environments in which deploy job performance over the WAN is a concern. Both the performance of the file server and the network connection between job servers and the file server have a critical impact on Deploy Jobs. See Process Spawner considerations. In this configuration. Authentication servers do not normally experience a high work load. It is not normally necessary to configure more than one authentication server for a single BladeLogic environment. BMC recommends the use of advanced repeaters whenever repeaters are deployed across a WAN. File server Every BMC BladeLogic Server Automation environment includes a server designated as the file server. at least one Application Server in a BMC BladeLogic Server Automation environment must be configured as an authentication server. for the console and Application Server to be separated by a longer network link. BMC recommends running the console on a Citrix Presentation Server. the authentication server verifies the identity of a BMC BladeLogic Server Automation user. Properly configured. BMC BladeLogic Server Automation consoles Communication between the BMC BladeLogic Server Automation console and Application Servers requires significant bandwidth. after which the user is allowed to interact with the BladeLogic client. Authentication servers Although not a separate Application Server profile. PXE servers are discussed in Servers for provisioning. but not recommended. Any server running an RSCD agent can be designated as the file server for the installation. localhost should be designated as the file server. PXE servers A BMC BladeLogic Server Automation PXE server. As its name implies. BMC recommends the use of one or more repeaters at each data center. performs a specialized role in support of provisioning jobs. BMC BladeLogic Server Automation performance can be enhanced by employing an NFS-based network-attached storage (NAS) device and mounting the storage on each physical computer hosting an Application Server. It is possible. This allows users who are offsite from the presentation server to run remote instances of the UI without experiencing excessive latency. Using NFS as a file server Because NFS sharing provides higher performance than NSH data transfer. page 14. Servers for provisioning BMC BladeLogic Server Automation provisioning works with different provisioning technologies. so that each Application Server treats the shared mount point as local storage. Advanced Repeaters An Advanced Repeater server is simply a repeater that uses BMC BladeLogic Advanced Repeater technology to enable file servers and repeater servers to store and share data more efficiently. technically a specially configured Application Server. For environments in which a population of geographically-dispersed users must all have access to the BMC BladeLogic Server Automation console. but performance under that configuration may be unacceptable. A typical practice is to configure one of the configuration Application Servers also to act as an authentication server. a repeater serves as a staging location at each site for packages as they are deployed. BMC recommends deploying consoles to servers on the same LAN as the Application Servers to which they connect.BMC BladeLogic Server Automation Best Practices for for Deployment and Configuration Process Spawners A BladeLogic Process Spawner offers improved performance for NSH Script jobs under certain circumstances. Page 14 . depending on the type of server being provisioned.

Each target device needs to have access to a local PXE server. Traffic to the Application Server is relatively light. JumpStart servers should be located on the same LAN as the Solaris servers being provisioned. A provisioning target also needs access to the BladeLogic Application Server and a data store. Although PXE servers do communicate with the database. which must communicate with the database over longer network legs. To use a JumpStart server with provisioning jobs. The PXE server and the TFTP server must reside on the same physical server. It is therefore acceptable to install geographically-removed PXE servers. usually on the same LAN. you must install an RSCD agent on the JumpStart server. and a JumpStart install server.BMC BladeLogic Server Automation Best Practices for for Deployment and Configuration Windows and Linux provisioning PXE servers support Windows and Linux provisioning jobs by providing boot-time services to target devices. Solaris provisioning The Oracle Solaris JumpStart technology identifies a JumpStart boot server. However. but may be remote from the BMC BladeLogic Server Automation Application Server. AIX provisioning The IBM AIX NIM technology requires a NIM Master server on the same LAN as the AIX servers being provisioned. you must install an RSCD agent on the NIM Master server. so it is not necessary for the Application Server to be geographically proximate to the provisioning target. a JumpStart config server. all of which may be (and commonly are) hosted on the same physical device. To use a NIM Master with provisioning jobs. the data volume of that communication is relatively low. Page 15 . it is preferable that the data store be local to the provisioning target. if the provisioning target will be retrieving files from a data store.

A SOCKS proxy normally requires minimal computing power but can be expected to have network bandwidth demands commensurate with its role as a communication concentrator for the remotely-managed targets. NSH proxy servers played an important role in negotiating fire walls in large scale deployments. you must install an RSCD agent on the Ignite Master server. Accordingly. and Geographically-distributed installations. for example) or otherwise not directly accessible from the Application Servers. You can set up a very small-scale installation using just two physical management servers to host BMC BladeLogic Server Automation. In this situation. but this practice is no longer recommended. One computer is dedicated to hosting the database. Proxies NSH proxies Historically.x and later. establish a SOCKS Proxy Server in each remote data center and configure any intervening firewalls to allow the Application Servers to contact the SOCKS proxy over port 1080. NSH proxies are used mainly as a security enhancement measure. for additional considerations. Page 16 . BMC recommends using SOCKS Proxy Servers. BMC recommends a dedicated database server or cluster to support a BMC BladeLogic Server Automation installation.BMC BladeLogic Server Automation Best Practices for for Deployment and Configuration HP-UX provisioning The HP-UX Ignite technology requires an Ignite Master server on the same LAN as the HP-UX servers being provisioned. To use an Ignite Master with provisioning jobs. See also Large-Scale installations on page 17. Configure the Application Server to establish communications with the remote targets by using the SOCKS proxy. usually over port 4750. page 19. SOCKS proxies To access targets that are behind a firewall (because they are in a remote data center. rather than contacting the remote hosts directly. while the other hosts all the essential BladeLogic components: Application Server offering: Job server Configuration (UI) server Authentication server File server Management console UI (BMC BladeLogic Server Automation console) This simple installation highlights the fact that BMC BladeLogic Server Automation makes significant use of the associated database. In BMC BladeLogic Server Automation versions 7. SIMPLE INSTALLATIONS This section describes basic considerations applicable to all BMC BladeLogic Server Automation installations.

remember to allow memory for the operating system and for other processes running on the computer. Adding Application Server instances To meet the demands of a larger data center. you can add BMC BladeLogic Server Automation components to provide greater management capacity. adding WITs means configuring another Application Server. This section describes the use of additional infrastructure to provide greater capacity for a BMC BladeLogic Server Automation installation. Fortunately. doing so is likely to lead to unacceptable performance in most cases. but the number of WITs per job server is normally limited by the amount of memory available in a single Application Server. Page 17 . However. including the Application Server launcher. In most cases. Most commonly it is necessary to add job servers to provide support for a larger number of managed servers. then. A rule of thumb is to install Application Servers on physical servers based on the assumption that each Application Server requires: Two CPU cores Physical memory sufficient for the Application Server process (4 GB for a 32-bit Application Server and 8-10 GB for a 64-bit Application Server). Under these guidelines. including the database server. it is likely that additional Application Servers will need to be deployed. In some cases. it is possible to host all the components on one machine. It is frequently the case that a physical server has CPU and other resources sufficient to host several times the total number of WITs that can be run in a single Application Server. a typical eight-core server computer with sufficient memory can support three to four Application Servers.BMC BladeLogic Server Automation Best Practices for for Deployment and Configuration For demonstration or other specialized purpose. See Configuration guidance on page 20 for more detailed suggestions on memory and WIT settings for job servers. The number of WITs is a configurable option of each job server. LARGE-SCALE INSTALLATIONS Most customer environments are too large to be managed by the simple 2-server infrastructure described in the previous section. Increasing job throughput To execute more jobs against more targets in a given period of time. In figuring required RAM for the physical server. it is usually necessary to increase the number of work item threads (WITs) available to execute jobs. it may also be necessary to deploy additional Configuration (UI) servers to support a larger user population.

pdf. Scaling the file server The BMC BladeLogic Server Automation design requires a designated File Server to host the files in the BladeLogic Depot. for best performance. In both cases.BMC BladeLogic Server Automation Best Practices for for Deployment and Configuration Support for more users For environments supporting a large user population. You can control the minimum and maximum number of database connections maintained by an Application Server through user-configurable settings for the various database connection pools. Load balancing In large deployments involving multiple instances of some or all BMC BladeLogic Server Automation components. but as a starting point. a configuration offering several benefits in terms of performance and scalability.bmc. a share exported by the filer is mounted at the same mount point on each computer hosting an Application Server. The File Server is simply a server running the RSCD agent. The File Server is then defined to be localhost. BMC recommends deploying Application Servers in separate virtual machines. If you plan to establish an extremely large BMC BladeLogic Server Automation implementation. In combination.bmc. In addition. avoid allocating more vCPUs than the physical host has physical CPU cores. and BMC BladeLogic 8. the actual physical resources available on the database server impose a practical limit on the number of database connections that that particular database server can maintain. it may be necessary to provide load balancing services to ensure that the extra resources being applied are being utilized appropriately. A NAS filer using NFS or SMB can act as a kind of virtual file server. allowing for redundancy and higher performance. Then work with the local DBA and database vendor to ensure that the database server is capable of supporting that load. or spread the Application Servers across separate virtual machines. the choice naturally arises whether it is better to deploy multiple Application Servers in a single virtual machine. in the absence of additional information. See BMC BladeLogic Application Server Running on VMware ESX: Performance and Scalability Best Practices. http://documents. this configuration allows the use of clustered NAS servers.pdf . these guidelines call for one Configuration server for every 250 users. Limits to growth Neither Oracle nor SQL Server has a theoretical limit on the number of database connections that a database server can support. The workload required to support a user varies widely. http://documents. the Application Server performs best when the virtual machine hosting it is configured to have one dedicated virtual CPU (vCPU). Job servers effectively perform their own load balancing. you should use the information in the Configuration Guidance section to estimate the total number of database connections required for the implementation. However.com/supportu/documents/29/84/142984/142984. This. This configuration offers potentially improved performance because the NFS protocol used by the filer exhibits better performance over the network than does the NSH protocol. scheduling jobs and work items according to availability. Page 18 . the Application Servers themselves are likely running on the same physical host computer. making the share appear to be local storage for each Application Server. you may need to increase the number of Configuration (UI) Servers in the installation. limits the total number of Application Servers a particular BMC BladeLogic Server Automation implementation can support. BMC typically recommends: Install one Configuration server for every 50 concurrent logged-in users. in turn. In this configuration. No additional load balancing considerations are applicable for job servers. In addition.com/supportu/documents/60/54/106054/106054. Considerations for virtualized environments When BladeLogic Application Servers are hosted in virtual (guest) machines in a virtualized environment. Expect as many as 20% of total users to be logged in at any one time. Further. of course.0 Application Server Running on Red Hat Xen: Performance and Scalability Best Practices. In virtualized environments. and the file storage path is that on which the shared storage is mounted.

The BMC BladeLogic Advanced Repeater is an enhancement to the repeater architecture that provides scalable transport of data over wide-area networks. in addition to remote managed servers. The BIG-IP product by F5 is a common choice for this purpose. In these cases it is necessary to consider not just the scale of the BMC BladeLogic Server Automation installation but also its geographic distribution. it is usually not practical to deploy a management console (BMC BladeLogic Server Automation console) at a remote site. (This staging pushes to the repeater and then pushes from the repeater to the target. that may be important for large-scale installations. Advanced repeaters also offer additional features. for example DHCP. Depending on the provisioning technology used. Citrix Presentation Server If. Page 19 . Load balancing for authentication servers (for example. Appropriate use of repeaters in remote data centers can significantly reduce the amount of network traffic that must be carried over long (slow and/or expensive) data lines. Repeaters You can configure repeaters as staging areas for deployment files. For more homogeneous load balancing. with at least one repeater configured in each remote data center. you can achieve a crude but effective load balancing simply by assigning different users to use different configuration servers. GEOGRAPHICALLY-DISTRIBUTED INSTALLATIONS For a variety of reasons. due to the bandwidth and latency requirements for the console-to-configuration server link. each remote data center must provide support for one or more provisioning-related services. Deploy Jobs with targets in remote data centers should normally be configured to use indirect push staging. the installation also requires access to BMC BladeLogic Server Automation for remote users.) Provisioning servers As a rule. it is unusual for the largest customer environments to be entirely contained within a single data center. BMC recommends the use of a Citrix Presentation Server. The firewall can be configured to route connections on port 1080 (the SOCKS proxy port) to the SOCKS Proxy Server. SOCKS proxies For a remote data center accessible only through a firewall.BMC BladeLogic Server Automation Best Practices for for Deployment and Configuration Two strategies for load balancing are commonly applied for configuration (UI) servers: For cases where the user population and behaviors support it. PXE and TFTP servers. For performance reasons. for purposes of failover) must similarly be provided by an external load balancer. which then brokers a connection to the actual target server agent (on port 4750. the RSCD agent port). BMC recommends the use of advanced repeaters for geographically-distributed deployments. This section describes additional infrastructure recommended for managing servers in remote data centers. you must add an external load balancer to the installation and use it to distribute the load across configuration servers. such as bandwidth throttling and secure communications. support for provisioning targets in remote data centers must be provided from provisioning servers located in the remote data center. BMC recommends the use of a SOCKS proxy in the remote data center.

this process space limit imposes a ceiling on the number of threads that can be accommodated within a single Application Server. The native heap (also sometimes called the C heap) contains thread stacks. a 64-bit Java process also requires a larger Java heap. The java heap contains Java objects and accounts for most of the memory required by a running Application Server. not guarantees or absolute limits. Recommended Java heap settings This section describes recommended Java heap sizes for Application Servers running under different operating systems. In this case. Both heaps. and native heap A Java process comprises two distinct memory areas: the Java heap and the native heap. 32-bit processes A process running under any 32-bit operating system is limited to 4 GB of virtual address space. file handles. For example. as well as timing effects between concurrently-operating threads. If the maximum Java heap size is set too low.elis. For an example. This section provides an overview of some considerations that apply to correctly sizing Java memory for BladeLogic. the recommendations that follow are merely that: recommendations. 32-bit Windows divides the entire address space in half. from which the operating system must reserve a significant portion for itself. Apart from some general discussion. The Java heap is managed by the Java garbage collector. An Application Server can. must fit within the footprint of a single process. typically 50% or more larger than the 32-bit Java process. be configured to provide the combined services of the single-purpose Application Server (an Application Server of type ALL). see http://users. usually by adding recommended values for the same parameter for different Application Server types. allowing an application process only 2 GB total private process space. it is possible to run out of native heap memory. To complicate matters further. and so is sometimes called GC heap.ugent. Refer to the BMC BLADE L OGIC SERVER AUTOMATION ADMINISTRATION GUIDE for details on using the blasadmin tool to control the configuration parameters. you must modify the parameter recommendations.pdf. of course. If the maximum Java heap size is set too high.BMC BladeLogic Server Automation Best Practices for for Deployment and Configuration CONFIGURATION GUIDANCE This section offers guidance on appropriate settings for the configuration parameters for a BMC BladeLogic Server Automation Application Server. For large Java applications like Application Servers. Therefore. peak memory use for either the Java heap or the native heap depends on the precise work load being considered. Process space. ABOUT JAVA MEMORY Effective operation of a large Java system like the BladeLogic Application Server depends critically on the availability of sufficient heap memory. Compared to a 32-bit Java process performing equivalent work. and other objects not managed by the Java garbage collector.be/~leeckhou/papers/SPE06. Page 20 . this section organizes BMC configuration recommendations according to type for single-purpose Application Servers. especially out-of-memory errors. These are recommendations only and must be adjusted in light of observed conditions. it is possible to run out of Java heap memory. Increasing the maximum size of the Java heap necessarily decreases the maximum possible size of the native heap that can fit within a certain process size. Java heap. 64-bit processes A process running under a 64-bit operating system has access to a much larger virtual address space. together with the Java executable code itself.

the negative contention effects grow more rapidly than do the positive serendipity effects. Selecting appropriate sizes for each of the various thread pools is one of the most important configuration choices for an Application Server.BMC BladeLogic Server Automation Best Practices for for Deployment and Configuration For 32-bit processes. as the number of threads increases. there is a greater likelihood of one thread having to wait for another thread’s exclusive access to conclude. Contention: Because some operations on some data structures require exclusive access. but doesn’t double it. especially memory. Doubling the number of threads in a pool improves performance. while still consuming as much memory and other resources as any other thread. if there is sufficient physical memory to support this setting. any given item request from any thread is more likely to be fulfilled from the cache. especially caches. Threads within the same process share certain data structures. sometimes sharply so. Each additional thread provides a smaller and smaller net benefit. BMC recommends that the Java heap size be increased as indicated in the table. BMC recommends operating system-specific Java heap size values according to the table below. Due to memory constraints. This effect degrades per-thread performance as the number of threads increases. which are not shared between threads in different processes. Java threads may also consume operating system resources such as thread handles. a thread consumes even more memory. available process size limits the number of threads available in an Application Server. with each pool devoted to a different purpose. Each thread consumes resources. each dedicated to a specific purpose. Regardless of additional performance considerations. See operating system-specific recommendations for this value summarized in the table below. even when idle. Max Java Heap Recommendations Operating System Windows Linux Solaris 32-bit 1024 MB 1536 MB 2048 MB 64-bit 6144 MB 6144 MB Not applicable ABOUT THREAD POOLS An Application Server maintains several thread pools. This phenomenon has a mildly positive effect on overall performance as the number of threads increases. ABOUT DATABASE CONNECTIONS Connections between an Application Server and the database are managed in three connection pools. Page 21 . has two consequences: Serendipity: Because there are more threads contributing to the process-wide caches. Increasing the number of threads within a single process. that is. As the number of threads in a process grows. blasadmin Setting Module AppServer Setting MaxHeapSize Description and Recommendation Specifies the maximum heap size for this Application Server. Each connection pool allows the configuration of a minimum and maximum number of connections. because another thread is more likely to have already placed the element in the cache. although BMC recommends leaving the minimum value at zero for all connection pools. job servers using 32-bit processes should be configured to use no more than 50 work item threads. increasing the number of threads is subject to diminishing returns. especially threads within a particular thread pool. For 64-bit processes. While executing.

BMC recommends a setting of 50 work item threads. BMC suggests a value of 200 threads for lightweight work items. BMC recommends 50 work item threads for each of these Application Servers. You must also ensure that the database server has sufficient capacity to service all the connections from all the connection pools for all the Application Servers in the environment. for parallelism. In light of these considerations. blasadmin Setting Module AppServer Setting MaxWorkItemThreads Description and Recommended Value Number of threads that can be used to execute job parts. otherwise 0.6 and earlier. so a job targeted at thousands of servers can be expected to result in thousands of work items being queued for processing. Recommendations for the work item thread pool The work item thread pool is the thread pool whose configuration has the greatest effect on overall job performance. Version 7.1. BMC recommends working with the DBA and database vendor to ensure that you have this capacity. BMC recommends a value up to 200 if Deploy Jobs are a primary use. configuring a database pool with a maximum size that is too low can degrade performance. BMC recommends establishing additional Application Servers instead of increasing the number of work item threads. for parallelism. Further. BMC recommends 50 work item threads for both 32-bit and 64-bit Application Servers. Configuring a larger number of work item threads risks an OutOfMemoryError under the process size limitations of 32-bit processes. blasadmin Setting Module AppServer Setting MaxLightweightWorkItem Threads Description and Recommended Value Number of threads that can be used to execute lightweight job parts. Version 8.BMC BladeLogic Server Automation Best Practices for for Deployment and Configuration Configuring a database pool’s maximum size to be too high wastes resources. The default value of 0 threads for lightweight work items uses ordinary work item threads for the execution of all work items. However. it is usually desirable to allocate a generous number of work item threads for a job server. Recommendations for the lightweight work item thread pool Lightweight work item threads are of benefit primarily for Deploy Jobs. For installations in which Deploy Jobs represent a significant fraction of the workload. as a thread requesting a database connection from an empty connection pool blocks until a connection becomes available.0. For 64-bit Application Servers. Page 22 . the work items themselves tend not to be CPU intensive. For 32-bit Application Servers. RECOMMENDATIONS FOR JOB SERVERS This section provides general recommendations for configuring Application Servers established as job servers. Most jobs generate one or more work items per target host.1 Up through BMC BladeLogic Server Automation 8. larger available process spaces make it possible to use a larger number of work item threads. lightweight or not. selecting the best size for this thread pool involves trade-offs. and the best size will be different for different environments. The number of work item threads to configure is primarily determined by the effects of contention between work item threads. particularly for very large installations. and for large installations. Version 8. may risk exceeding the total capacity of the database server. Conversely.

JobFactory GlobalDefaultJobParallelism Global default value for Job Parallelism made available to user. it is the default value that appears in the UI for a job’s maximum parallelism option. Page 23 . such as creating the work items themselves. BMC recommends leaving async execution enabled. Deploy Jobs. for example. The maximum number of jobs the Application Server allows to run simultaneously. BMC recommends using the default value of 500 in most cases. This parameter has no direct effect on the operation of the Application Server. While most of the work involved in executing a job is delegated to work items. Maximum size for the job execution pool. BlExec NumWorkerThreads Number of worker threads used by the BlExec service. some of the work. blasadmin Setting Module AppServer Setting EnableAsyncExecution Description and Recommended Value Enables/disables the async execution framework for jobs that allow it. You can set the value to true or false. This parameter governs a small pool of threads used to communicate with BMC Atrium Orchestrator. Other parameters For completeness. Rather. The job execution pool is distinct from the work item thread pool. for parallelism. the default setting is true. a lower value reduces the demand for file descriptors. when that option is selected. BMC recommends using the default value of 20. and will be carried out by the job execution pool. AppServer MaxJobs Maximum number of jobs the Application Server can execute simultaneously. regardless of the availability of resources to execute the jobs. remains the responsibility of the job itself. BlExec MaxSocketConnections Maximum simultaneous sockets open by the BlExec service. AppServer MaxJobThreads Maximum number of threads that can be used to execute a job. A higher value allows more simultaneous connections. blasadmin Setting Module AppServer Setting MaxApprovalThreads Description Number of Approval Threads. These configuration parameters do not normally require adjustment from their default values. It is not normally necessary to change the BlExec service’s configuration settings.BMC BladeLogic Server Automation Best Practices for for Deployment and Configuration Recommendations for the BlExec service and thread pool An Application Server’s BlExec service maintains a pool of threads for the execution of asynchronous tasks involving communication with remote targets. the default values produce good results in most cases. this section describes some additional configuration parameters related to thread pool sizes for job servers.

For NSH script jobs. Version 8. For best performance of NSH script jobs in these versions of BladeLogic.BMC BladeLogic Server Automation Best Practices for for Deployment and Configuration Recommendations for database connections For best job server performance. RECOMMENDATIONS FOR CONFIGURATION SERVERS Estimating client connections Parameter value settings for configuration (UI) servers should be based on the number of client connections you anticipate being made to the configuration server.6 and earlier. BMC recommends using the Process Spawner for all job servers for BMC BladeLogic Server Automation version 8. For version 8. The number of client connections opened by a UI client varies over time and depends on the operations that the user is engaged in at any given moment.0.1 and beyond. so too does the cost of spawning a new process directly from the Application Server. As the configured size of the Application Server grows. rather than spawning them directly. The BLCLI client uses exactly one client connection for its execution. blasadmin Setting Module ProcessSpawner Setting SpawnExternally Description and Recommendation Processes should be spawned outside the Application Server or not. As an initial estimate. a job server can be configured to use a Process Spawner to spawn subprocesses. For BMC BladeLogic Server Automation version 8. blasadmin Setting Module Database Setting MaxJobExecutionConnections Description and Recommended Value Maximum connections in the pool for job execution thread group. The Process Spawner is simply a process with a small memory footprint that can spawn new processes without the penalty of the Application Server’s large memory footprint. BMC recommends a value that is twice the number of work item threads (MaxWorkItemThreads).1 and later. BMC recommends setting the maximum size for the general database connection pool to twice the number of work item threads. BMC recommends a value of 2 * MaxWorkItemThreads. Database MaxGeneralConnections Maximum connections in the pool for general thread group. and is usually much more short-lived than an interactive user’s GUI session. Page 24 . BMC recommends a planning figure of 2. BMC recommends allowing the job execution connection pool to grow up to twice the number of work item threads (MaxWorkItemThreads in AppServer module). especially for environments that depend heavily on NSH script jobs. This value is the total of the number of client connections from UI clients (RCP) and from BLCLI clients. Version 7. the benefit of using the Process Spawner increases.0 and earlier. the default value should be adequate. logging of output from NSH script jobs is handled with connections from the general database connection pool.5 client connections for each concurrent GUI user.0 Up through BMC BladeLogic Server Automation 8. Process Spawner considerations As memory size increases. while other jobs use the job execution database connection pool.

it is not necessary to change these parameters from their default values. for best configuration (UI) server performance. then the total load for client connections can be divided across the number of configuration servers that will be established. as described in the previous section. and setting MaxClientContexts to this value. BMC recommends using the default value of 200. BMC recommends using the default value of 10. The following table describes the parameters that most strongly affect the performance of the client connection service. BMC recommends a value that is twice the number of client connection threads. or approximately 5% of the value of MaxClientContexts. Recommendations for database connections Similarly. In the absence of sufficient information from which to form an estimate for peak client connection demand. the peak demand estimate for client connections for the configuration server is: 2.BMC BladeLogic Server Automation Best Practices for for Deployment and Configuration Thus. BMC recommends estimating peak client connection demand.5 * (number of simultaneous GUI users) + (number of simultaneous BLCLI commands) If multiple configuration servers with a load balancer will be established. blasadmin Setting Module AppServer Setting MaxClientContexts Description and Recommended Value Number of maximum client connections to the Application Server. Recommendations for the client connection service and thread pool The client connection service is responsible for managing connections from client processes in Application Servers acting as configuration (UI) servers. AppServer MaxWorkerThreads Number of client connection worker threads. BMC recommends allowing the pool of database connections for client service threads to grow up to twice the number of client connection service threads (MaxWorkerThreads in AppServer module). Page 25 . In most cases. blasadmin Setting Module Database Setting MaxClientConnections Description and Recommended Value Maximum connections in the pool for client connections. The client connection service maintains a pool of threads for servicing client requests.

For an Application Server configured to act exclusively as an NSH proxy server. Page 26 . configure the NSH Proxy server for the anticipated number of concurrent NSH connections it will be expected to handle. blasadmin Setting Module AppServer Setting MaxNshProxyContexts Description and Recommended Value Maximum number of NSH proxy connections to the Application Server. AppServer MaxNshProxyThreads Number of NSH proxy threads. For an Application Server configured to act as both a configuration server and an NSH proxy server. to account for idle NSH connections. Database MaxClientConnections Maximum connections in the pool for client connections. this value should be the same as MaxNshProxyThreads. this value should be the sum of MaxWorkerThreads and MaxNshProxyThreads. Set this value to the maximum number of concurrent NSH connections the proxy will be expected to handle. In the absence of usage estimates specific to the installation.BMC BladeLogic Server Automation Best Practices for for Deployment and Configuration RECOMMENDATIONS FOR NSH PROXY SERVERS BMC recommends the use of NSH Proxy servers as a best practice for security. BMC suggests an initial estimate of 20% of MaxNshProxyContexts. This value can be significantly less than MaxNshProxyContexts. For best performance.

used for Linux PXE Servers SNMP SNMPTRAP BDSSA server PXE Server SOCKS proxy SQL Server DB SQL Server DB SQL Server DB Oracle DB Oracle DB Oracle DB PXE Server RSCD Agent PXE discovery when co-located with DHCP Primary communication channel from Application Server to each managed host SMB. used for Windows PXE Servers SOCKS Proxy protocol 5282 HTTP (TCP) Adv. File Server Page 27 . By default. Extended DHCP response to an initial extended DHCP request 68 69 80 80 161 162 443 445 1080 1433 1433 1433 1521 1521 1521 4011 4750 DHCP (UDP) TFTP (TCP/UDP) HTTP (TCP) HTTP (TCP) SNMP (UDP) SNMP (UDP) HTTPS (TCP) SMB (TCP) TCP MS-SQL (TCP) MS-SQL (TCP) MS-SQL (TCP) TNS (TCP) TNS (TCP) TNS (TCP) DHCP (UDP) RSCD (TCP) DHCP PXE client HTTP client PXE client Application Server Application Server HTTPS client PXE client SOCKS client Application Server BDSSA server PXE Server Application Server BDSSA server PXE Server PXE client Application Server Advanced Repeater PXE client TFTP Server BDSSA server PXE Server HTTP. PXE Server binds to 67 UDP.BMC BladeLogic Server Automation Best Practices for for Deployment and Configuration APPENDIX: TCP/UDP PORT USAGE The following table summarizes the use of TCP/UDP ports across all the elements of a BladeLogic installation: Port 25 25 67 Protocol SMTP (TCP) SMTP (TCP) DHCP (UDP) From Application Server BDSSA server PXE client To Mail Server SMTP server DHCP service Notes SMTP For emailing scheduled reports and notifications PXE boot broadcasts a DHCP request that includes PXE info.

Service Auth. A second Application Server on the same host will typically have a base port of 9900. Server Application Server Launcher Launcher Launcher Application Server RMI Registry SSL Provisioning (user guide p.if the File Server and Adv. Application Server Application Server Auth. Arbitrary port assignments can be made in all cases. File Server are not co-located usually local traffic only usually local traffic only usually local traffic only usually local traffic only Cognos report BladeLogic SSO JMX listener -. Repeater BDSSA server BDSSA Auth. with 9850-9899 being the default for a single Application Server. Service Application Server NSH Proxy JMX listener for Application Server Authentication Service TCP Application Server RMI communication ports * Application Server ports are normally configured from a base port. with 9800 being the default base port. ** The MinPort-MaxPort range is configurable. 853. Repeater Cognos client BDSSA server BLASAdmin console Application Server Console Provisioning Client Application Server Adv. Repeater BMCCM Tuner Adv. and so on. Page 28 . File Server Notes Marimba publishing -. steps 7 and 9) 9838 (base+38*) 9840 (base+40*) 9840 (base+40*) 9841 (base+41*) 9842 (base+42*) 9850-9899 (MinPortMaxPort**) TCP TCP TCP TCP TCP Jconsole Application Server RCP (Client UI) RCP (Client UI) NSH.usually local traffic only 7717 7717 7717 8080 9300 9640 9700 9701 9702 9831 9836 (base+36*) TCP TCP TCP HTTP (TCP) TCP TCP JMX (TCP) TCP TCP TCP TCP Transmitter Administrator Proxy Administrator Certificate Manager Adv. File Server Adv.BMC BladeLogic Server Automation Best Practices for for Deployment and Configuration Port 7717 Protocol TCP From File Server To Adv.

and logos may be registered or pending registration in the U. Recognized as the leader in Business Service Management. 2010.S. are registered with the U. BMC Software. © 2011 BMC Software. faster and stronger. virtual and cloud environments.96 billion. Inc. IT runs on BMC Software. AIX and IBM are trademarks or registered trademarks of International Business Machines Corporation in the United States. Oracle and Java are registered trademarks of Oracle and/or its affiliates. service marks. or both. mainframe. Linux is the registered trademark of Linus Torvalds. All other trademarks or registered trademarks are the property of their respective owners. reduce risk and drive business profit. Inc. and other countries. other countries.bmc. Patent and Trademark Office. Other names may be trademarks of their respective owners. All rights reserved.BMC BladeLogic Server Automation Best Practices for for Deployment and Configuration Business runs on IT. and the BMC Software logo are the exclusive properties of BMC Software.com for more information. Visit www. UNIX is the registered trademark of The Open Group in the U.S. or in other countries. BMC.  *195833* Page 29 . and may be registered or pending registration in other countries. All other BMC trademarks. Business thrives when IT runs smarter. That’s why the most demanding IT organizations in the world rely on BMC Software across distributed. BMC revenue was approximately $1. BMC offers a comprehensive approach and unified platform that helps IT organizations cut cost. For the four fiscal quarters ended September 30.S..

Sign up to vote on this title
UsefulNot useful

Master Your Semester with Scribd & The New York Times

Special offer for students: Only $4.99/month.

Master Your Semester with a Special Offer from Scribd & The New York Times

Cancel anytime.