Application Servers

A BMC Server Automation deployment consists of one or more Application Server (appserver) processes. The number and configuration of Application Servers in a deployment depends on such factors as the number of targets to be managed and the expected job load for the system.

Within limits, it is possible to run multiple Application Servers on a single physical server while still maintaining acceptable performance. For more information, see Adding Application Server instances.

An Application Server's deployment and type determine the work it performs:

• Application Server deployment — Defines the services that the Application Server provides (for example, process spawner or PXE server). You can configure an Application Server to specify its deployment.
• Application Server type — Defines the work that an Application Server can perform. You can specify an Application Server's type in its profile.
   By default, an Application Server is a general purpose server of type All. Other types (Job, Configuration, and NSH_Proxy) must be explicitly set at deployment time.

For more information, see About-Application-Server-deployments-and-profiles.

Depending on its configuration and type, an Application Server can fulfill any of several distinct profiles or combinations of profiles:

• Configuration servers
   A configuration (UI) server is an Application Server of type Configuration or type All (which includes Configuration). BMC Server Automation clients (rich client UI, BLCLI command line client, bmi.exe) connect to configuration servers to allow interaction with the BMC Server Automation system. A configuration server provides middle-tier functionality, answering requests from BMC Server Automation client applications both for data and for operations on that data.

• Job servers
   A job server is an Application Server of type Job or type All (which includes Job). Job servers are responsible for the execution of BMC Server Automation jobs. In many environments, job servers are limited by internal resource contention but do not impose excessive workload on the hardware. To make more complete use of the available hardware resources, you can configure multiple job servers on the same physical computer. Alternatively, in a virtualized environment, you can run multiple job server guest virtual machines (VMs) on the same physical server.

• NSH proxy servers
   Network Shell (NSH) proxy servers perform a specialized role in BMC Server Automation installations, as described in Proxy-servers.

• Process spawners
   A BMC Server Automation process spawner offers improved performance for NSH Script Jobs under certain circumstances. See Resource-usage-of-NSH-Script-Jobs.

• PXE servers
   A BMC Server Automation PXE server, technically a specially configured Application Server, performs a specialized role in support of provisioning jobs. PXE servers are discussed in Infrastructure-for-provisioning.

• Authentication Servers
   The Authentication Server verifies the identity of a BMC Server Automation user, after which the user is allowed to interact with the BMC Server Automation client. The Configuration Server profile includes Authentication Server functionality, so it is not normally necessary to establish a separate Authentication Server in a BMC Server Automation environment. Authentication Servers do not normally experience a high workload. Usually, you do not need to configure more than one Authentication Server for a single BMC Server Automation environment.

• Windows Patch Helper Servers
   For installations in which patch management for Microsoft Windows hosts is a use case, the BSA Catalog Update Job requires an additional Windows Helper Server. This Helper Server must run one of the Windows family of operating systems. During the execution of Catalog Update Jobs, the CPU utilization on the Helper Server might spike for a few minutes while processing metadata downloaded from Shavlik.