Understanding the Application Server

Application Server processes

The BMC Server Automation Application Server processes connections from many clients simultaneously. Rather than dedicating a thread to each client connection, the Application Server maintains a pool of threads that can be used for processing client activity. BMC Server Automation calls these worker threads. When a client requests any type of activity, the Application Server selects a worker thread from the pool to execute that task. When the request is complete, the worker thread is returned to the pool. Using this approach, the Application Server can manage many more client connections than it has worker threads. (The number of worker threads in the pool is configurable, as is the number of open client connections. See Managing the Application Server.) 

Typically, the BMC Server Automation Application Server runs as two distinct processes. One process runs the core functionality of the Application Server. The other process is a process spawner, which launches new processes external to the Application Server process. Spawning processes externally to the Application Server can be beneficial for memory management. Process spawning is primarily used for Network Shell Script Jobs and some types of extended objects. If you prefer, you can configure the Application Server so the process spawner does not run as an external process. See Configuring the process spawner.

Work item and job execution threads

A single Application Server processes BMC Server Automation jobs using one job execution thread and a configurable number of work item threads. The job execution thread constantly watches for scheduled jobs. (Note that a job set to run immediately is considered a scheduled job.) When a job comes due, the job execution thread loads the job and allocates work item threads, which perform all work required for that job. After initiating a job in this way, the job execution thread continues to watch for other scheduled jobs. (For a description of how multiple Application Servers can process jobs cooperatively, see Job distribution.)

The number of work item threads required for a job varies by job type. All jobs require one work item thread for pre-execution and another for post-execution. In addition, one work item thread is required to execute each part of the job. For most job types, the number of job parts equals the number of target servers, but there are exceptions to this rule. Deploy Jobs can optionally utilize a special pool of lightweight work item threads used only for processing Deploy Job phases that access target servers.

When allocating work item threads, the Application Server assigns equal preference to all pending jobs. When an Application Server is running multiple jobs, a sufficient number of work item threads might not be available for simultaneously processing all jobs. In this case, when a work item thread becomes available, it is assigned to the first job in the queue of pending jobs. When the next work item thread becomes available, it is assigned to the second job in the queue. The next work item thread goes to the third job in the queue, and so forth, until a work item thread has been assigned to all jobs in the queue. Then the cycle of allocating work item threads begins again, starting with the first job in the queue. With this system, all jobs can begin processing as soon as a work item thread becomes available. However, jobs with fewer job parts might complete sooner than jobs with many job parts.

For more information about specifying the number of available work item threads, see Managing the Application Server.

_{Back to top}

Job distribution to Application Servers

If you have multiple Application Servers installed and they all access the same database, those Application Servers can cooperate by distributing jobs to balance their processing workloads. Using multiple Application Servers increases the job execution capacity of the system and in most cases speeds overall job processing.

Application Servers are configured to cooperate when executing jobs. When multiple Application Servers are configured to execute jobs, scheduled jobs are delegated to the first Application Server that requests a job, provided that the Application Server making the request is not already executing the maximum number of jobs that it can run simultaneously. (That maximum number can be configured.) For example, if a BMC Server Automation installation consists of two Application Servers that are both configured to run the same maximum number of jobs, each Application Server is given the same number of jobs to run (assuming an even number of jobs to execute exists).

The number of work items processed during a job run directly corresponds to the number of target servers for the job. During job execution, Application Servers make an effort to distribute work items to each other to increase the number of concurrently executing work items and shorten overall execution time.

Typically, local work item threads on an Application Server process all work items for a job before those work items can be distributed to other Application Servers. However, if all local work item threads are already processing work items, the Application Server distributes work items to other Application Servers that have idle work item threads. Although work for an individual job can be spread among multiple Application Servers, only one Application Server manages each individual job.

For more information about configuring cooperation between Application Servers, see Managing the Application Server.

_{Back to top}

Pooled database connections

The Application Server maintains two different pools of database connections:

• One pool used for processing jobs running the BMC Server Automation Console
• One pool used for processing all other activity, such as client connections

When a worker thread or a work item thread requires a database connection:

• The thread acquires one from the appropriate pool of database connections.
• When the database activity is complete, the database connection is returned to its pool.
• A thread watches the pool of database connections, ensuring that the number of connections stays within high and low boundaries.
• If the number of database connections reaches the high boundary, the thread attempts to trim the number of database connections back to the low boundary.
  You can configure the high and low boundaries to accommodate user needs. For more information, see Setting the number of database connections.

_{Back to top}

Authentication framework

A BMC Server Automation Application Server employs a unified framework for processing all user authentication requests. That framework is based on three services:

• Authentication Service — An entity dedicated to authenticating users by means of all supported authentication protocols.
• Application Service — An entity that encapsulates the functionality of a BMC Server Automation Application Server.
• Network Shell Proxy Service — An entity that encapsulates the functionality of a Network Shell Proxy Server.

The Authentication Service and the Application Service are always located on the same host. A Network Shell Proxy Service can be located on the same host, or it can be set up on a stand--alone machine even though it is still associated with an Application Server.

When users on a BMC Server Automation client application (except BMC BladeLogic Decision Support for Server Automation) want to authenticate:

• The client contacts the Authentication Service using any supported authentication protocol.
• Based on the authentication protocol, the Authentication Service uses the appropriate mechanism to authenticate that user.
• If authentication succeeds, the Authentication Service issues a session credential to the client application.
• The client application initiates a session by presenting the session credential to an Application Service or Network Shell Proxy Service.

For more information about authentication and other security features, including a description of how BMC BladeLogic Decision Support for Server Automation authenticates users, see Administering security.

_{Back to top}

Application Server Launcher

The Application Server Launcher is a mechanism for configuring and controlling multiple Application Servers on the same host. It is so called because it launches (starts) and controls these additional Application Servers. The Application Server Launcher lets you configure and manage (start, stop, restart, terminate, remove and redeploy) each additional Application Server on the host.

The BMC Server Automation environment supports one Application Server Launcher per host. Installing the Application Server on a host also installs the Application Server Launcher.

The Application Server Launcher must be running on the host in order for you to perform these operations. See Viewing information about Application Servers.

_{Back to top}

Where to go from here