The Application Server is the core of the middle tier in a BMC Server Automation installation. Not only does the Application Server control communication between clients and servers, it also regulates activity between the client and the database, file, and mail servers. The Application Server provides many adjustable parameters that enable you to scale a BMC Server Automation system to virtually any size. The following topics describe some of those parameters:
The Application Server provides several options that you can adjust to accommodate increased activity.
An Application Server should be configured so that even when all of its work item threads are busy, the Application Server still has additional resource capacity.
set appserver maxworkerthreads #
set appserver MaxClientContexts #
set appserver MaxJobs #
set appserver MaxWorkItemThreads #
MaxLightweightWorkItemThreads(see step 6) also can control how many targets can be processed in parallel. If your system uses one Application Server, the maximum number of targets that can be processed is based on the Application Server available work item threads. If your system uses multiple Application Servers, the maximum number of targets that can be processed in parallel is based on the sum of all available work item threads on all Application Servers. When processing Deploy Jobs, work item threads often sit idle while target servers process deployment tasks. To avoid this kind of inefficiency, the Application Server can use a pool of lightweight work item threads to process phases of a Deploy Job that access target servers.
set appserver MaxLightweightWorkItemThreads #
When Application Servers are configured to access the same database, they automatically attempt to cooperate by balancing their job processing workloads. They accomplish this balance by distributing the processing of entire jobs or work items for large individual jobs to other Application Servers.
For Application Servers to cooperate, they must know which Application Servers are in service. Each Application Server periodically updates its time stamp, which functions as its heartbeat. Application Servers that are cooperating monitor each other's heartbeat to determine which Application Servers are in service.
For Application Servers to cooperate, the following prerequisites must be met:
set appserver RemoteServerTimeout #
RemoteServerTimeoutis set to
5, and 10 seconds elapse between heartbeats, the Application Server is considered out of service.
set appserver ServerMonitorInterval #
set appserver SocketConnectTimeout #
set appserver SocketTimeout #
set appserver UseSSLSockets true
trueindicates that connections to this Application Server must be encrypted using SSL.
set appserver RequireClientAuthentication true
trueinstructs the Application Server to require authentication from remote Application Servers. Generally, connections encrypted with SSL also require client authentication.
set appserver RegistryPort #
#is a port number. By default the RegistryPort is set to 9836.
Each Application Server has a log file that contains information about what is being executed on that Application Server. When Application Servers are configured to access the same database, they automatically attempt to cooperate by balancing their job processing workloads, which means that the log information is also distributed.
For example, you might have two physical Application Servers (appserver1 and appserver2), with one job server running on each, and the Distribution Manager is dynamically allocating resources and running jobs on both Application Servers as needed. In this example, the logging information for the job is actually distributed between the log files on both appserver1 and appserver2. Therefore you would need to review the log files on both Application Servers.
By default, the Application Server log file, appserver.log, is located in /opt/bmc/bladeLogic/NSH/br (on UNIX) or installationDirectory\BladeLogic\NSH\br (on Windows). Additional log files are generated for each individual Application Server deployment (deploymentProfileName.log) in the same location.
You can use the
PRIORITY* property to mark a job, or a class of jobs, with a relatively higher priority to ensure they are executed first in case of resource contention. You can assign one of any of the following priorities:
Lowest. By default, all job types have a priority of
Normal. Note that these priority levels are meaningful only in relation to each other.
For a list of the permissions and authorizations required to modify a job priority, see Setting up authorizations for changing job priority and Setting job priority.
If you have implemented a multiple Application Server environment, note the following considerations about job priority:
Critical, but with a low maximum parallelism level. Such a job would appear to relinquish resources to a lower priority job with a high parallelism level, after the initial work item assignment quota for that
Criticalpriority job is reached.
Multiple Application Servers on different hosts can be set up to cooperate on processing jobs. (For information, see Setting up job distribution between multiple Application Servers.) For this cooperation to take place, all Application Servers must have the same bladelogic.keystore file.
To synchronize keystore files of cooperating Application Servers, perform the following steps on each cooperating Application Server:
To change the password needed for the bladelogic.keystore file for all Application Server deployments:
blasadminutility and you can enter set and show commands. All commands that you enter during the session affect all additional Application Servers configured on the same host.
set appserver CertPasswd <password>
You can specify a maximum period of time that can elapse for a job part to be canceled. If cancellation of a job part exceeds this maximum, the job part is classified as stuck and the job part is aborted. This prevents situations where cancellation of a job is not performing as expected and the act of canceling the job can potentially hang the job.
set appserver MaxTimeForCancelToFinish #
The Application Server lets you specify certain limits for connections to the Application Server, such as a prune time for idle connections or the maximum amount of time a client can perform read operations from the Application Server. If the client exceeds these maximums, the connection is closed.
set appserver IdleConnectionPruneTime #
set appserver SocketTimeout #
The Application Server lets you specify time-out behavior for work item threads. By default, if you assign job part time-outs, a work item thread is canceled when it exceeds the time period you have defined in the
JOB_PART_TIMEOUT property. In addition, all other work item threads acting on the same server are also canceled. This prevents situations where multiple work item threads time out serially on the same unresponsive server. If necessary, you can use this procedure to override the default behavior so that only one work item thread times out automatically.
JOB_PART_TIMEOUT property is not applied to jobs that use asynchronous BlExec tasks, as discussed in Defining timeouts for jobs.
set appserver PropagateWorkItemTimeout true|false
truemeans all work item threads acting on the same server are canceled when one work item thread times out. Setting it to
falsemeans only the one work item thread is canceled.
A restart of an Application Server cancels provisioning jobs that have been submitted but are waiting idle (for example, a job waiting for the PXE client to boot). To ensure that these jobs are automatically restarted when the Application Server restarts, use this procedure.
set appserver restartIdleProvisionJobs true
By default, an Update Server Properties Job always ends successfully, even if the RSCD agents on the remote target servers are unreachable, not licensed, or not accessible by the user because the
AGENT_STATUS property for the target servers is updated in any case. You can, however, set the Update Server Properties Job to end in failed status whenever agents do not respond or when the user does not have access to agent.
If a server has the IS_ONLINE property set to
false, the Update Server Properties Job result for that server shows the status to be
set JobFactory UspJobSucceedsWhenAgentDown true|false
true. Setting the value to
falsemeans that the Update Server Properties Job is reported (in the log and in the display of job results) as having ended in failed status if the agent on the remote target is unreachable, not licensed, or not accessible by the user.
For more information, see Creating or modifying Update Server Properties Jobs.
The job log for an Update Server Properties Job can include many INFO-type messages, in addition to error and warning messages. As of product version 8.6.01, you can choose whether to include such informational messages or filter them out
set JobFactory LogOnlyErrorsOrWarningsOnUSPJob true|false
true. A value of
truemeans that Update Server Properties Job logs do not include most INFO-type messages; the logs include error and warning messages, as well as messages about job start and job completion.
For more information, see Creating or modifying Update Server Properties Jobs.
The Application Server lets you specify the maximum number of compliance results that are displayed for any failed condition in a compliance rule. A Compliance Job examines a component and compares its parts to conditions defined in compliance rules for a component template. Parts that do not comply are shown in Compliance Job results. If you are running a Compliance Job that examines many server objects that fail a compliance condition, you might tax your system resources, particularly disk space. If results for a Compliance Job exceed the limits you set in this procedure, the job run is marked with a warning and the job log includes a message saying that job results have been truncated.
set appserver ComplianceResultMaxNumberOfAssets #
The Application Server lets you specify a period of time that a newly created job can remain in a queue while the Application Server is down or too busy to process the job. The period of time is measured from the scheduled occurrence of the job to the time the Application Server starts. Setting a value for this option specifies that if you restart the Application Server and the specified period has:
Elapsed, the scheduled occurrence of a job is not executed
This procedure only defines behavior for new jobs. No matter how you define this value, all existing jobs remain in the job queue for the default amount of time (60 minutes).
set scheduler MaxJobTimeInSchedulerQ #
Use this procedure to set maximums and minimums for database connections. You can set the maximum and minimum number of database connections that jobs use. You can also set the maximum and minimum number of database connections used for general, non-job-related purposes, such as client connections to the database. By providing separate settings for job-related and non-job-related activity, you can help to prevent situations where client connections seem to hang because large jobs are using all available database connections.
The sum of the maximum numbers that you define for
MaxGeneralConnections cannot exceed the connection limit specified by the database server.
To set a maximum and minimum number of job-related database connections, use either of the following commands:
set database MaxJobExecutionConnections #
set database MinJobExecutionConnections #
where #is a number of database connections. Note that the job-related database connection is set to 1 even if you set MaxJobExecutionConnections=0.
Values that you set for job-related database connections are actually divided across two job connection pools, with 75% of the value that you set applied to a primary pool and 25% to a secondary pool that is reserved for nested jobs. This means that you might run out of job-related connections sooner than expected, as discussed in Troubleshooting the Application Server.
set database MaxGeneralConnections #
set database MinGeneralConnections #
This procedure describes how to set up a user name and password for authentication on an HTTP proxy server. Many organizations provide Internet access through a proxy server. If the HTTP proxy server authenticates users, it requires a user name and password, which the Application Server can provide if you perform the following procedure.
The patch management component of BMC Server Automation incorporates the ability to download files from the Internet. Both the Catalog Update and Patch Download Jobs require proxy server settings that are operating-system specific. To eliminate the possibility of overwriting proxy server settings defined for the Application Server, or having to change these settings, these jobs do not use the same proxy server settings as the Application Server. For more information about setting the proxy server settings for patch management, see Configuring global configuration parameters.
set appserver HTTPProxyName <serverName>
<serverName>is the name of the HTTP proxy server.
set appserver HTTPProxyPort #
set appserver HTTPProxyUser <userName>
<userName>is the name of a valid user on the proxy server.
set appserver HTTPProxyPassword <password>
<password>is the password assigned to the proxy user you identified in the previous step.
Use this procedure to specify an IP address to which an Application Server should listen. You can also instruct the Application Server to listen for connections on all of its IP addresses. This procedure is primarily useful when an Application Server has more than one network interface and you want the Application Server to listen for connections on only one.
set appserver SocketsBindAddress <IP_address>|all
<IP_address>is the IP address (IPv4 or IPv6) or host name to which the Application Server should listen. If you do not specify an IP address or host name, the Application Server listens on all of its IP addresses. Similarly, if you enter
allin the command shown above, the Application Server listens on all IP addresses. If you have previously instructed an Application Server to listen for a specific IP address, you must use
allin this command to change those instructions so the Application Server listens on all IP addresses.
To ensure data integrity, BMC Server Automation inspects data packets traveling between Network Shell clients and proxy servers. When this inspection reveals a problem, the packet is not delivered. You can use this procedure to turn off packet inspection.
set appserver EnableProxyInspection true | false
falseturns off proxy inspection and
trueturns it on. By default proxy inspection is turned on.
To ensure proper performance of connections between clients and Application Servers of type NSH_Proxy, you can set a connection session timeout for the NSH proxy. Such session timeouts minimize the number of handshakes that take place during the connection between the client and NSH proxy.
As of patch 1 for version 8.7 (that is, version 8.7.00.001), you can, instead, control this timeout using a configuration file. Create a configuration file, openssl_sessions.cnf in <install-dir>/rscd. In this configuration file, include the following two parameters:
This mechanism generates temporary files that contain encrypted session information. These temporary files accumulate in the RSCD/sessions folder on the agent. Cleanup of these temporary files depends on your version of BMC Server Automation:
To ensure that a connection does not take place when an Application Server and client are at different versions, you can set up a version compatibility check. This check compares the version numbers of the client and the Application Server, at a level of detail you specify. If the version numbers are not the same, the Application Server refuses the connection.
set appserver VersionCompatibilityCheck major|minor|micro|build
major— Sets the check to compare only the major part of the version numbers.
minor— Sets the check to compare the major and minor parts of the version numbers. This setting is the default.
micro— Sets the check to compare the major, minor, and micro parts of the version numbers.
build— Sets the check to compare all four parts of the version numbers.
set appserver VersionCompatibilityCheck micro
set appserver VersionCompatibilityCheck build
The Application Server lets you specify the maximum number of file system objects that are stored in the cache. You can use this setting to improve database performance. For example, if you take a snapshot of a directory structure that contains multiple instances of the same object, the Job does not have to write the same file to the database multiple times, as the file system object is stored in the cache and can be reused.
set appserver FileSystemObjectCacheMaxSize #
The Application Server lets you specify a maximum number of records retrieved from a managed server, per page. These records are used when you are working with groups, smart groups, folders, search groups, database assets, custom objects, and server objects in the Configuration Object Dictionary, for example.
set appserver MaxPageSize #
Restart the Application Server.
In the BMC Server Automation Console, large numbers of objects are presented in groups of 50, by default. You can adjust this display number by selecting Window > Preferences. Expand BMC and Paging Options to change the default. You can then page through these groups to make working with large numbers of objects more manageable. You must select File > Refresh after changing the default to have the change take effect.