Components of a TrueSight Server Automation installation

This topic describes the components that can constitute a TrueSight Server Automation installation. The topic includes the following sections:

• Basic components of a TrueSight Server Automation installation
• Database server 
• Application Servers
• Storage locations 
• TrueSight Server Automation Consoles 
• Infrastructure for provisioning 
• Proxy servers 
• Where to go from here

Basic components of a TrueSight Server Automation installation

The following diagram shows the basic components of a TrueSight Server Automation installation.

The following sections provide an overview of the components.

Database server 

At the center of every TrueSight Server Automation installation is the TrueSight Server Automation database server. Application Servers are tightly coupled to the database and impose significant demands on the server that hosts the database. BMC recommends the use of a dedicated physical machine or cluster to host the database server for TrueSight Server Automation.

The database server or cluster should be on the same LAN as the TrueSight Server Automation Application Server. High latency (longer than 10 milliseconds) on the link between the Application Servers and the database server can cause unacceptable performance for TrueSight Server Automation. Additionally, high packet loss rates on the Application-Server-to-database link can cause issues for (or expose defects in) the Oracle JDBC driver.

Application Servers

A TrueSight 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, number of concurrent client users, and the expected job load for the system.

The following sections present basic concepts for Application Servers and discusses the considerations for combining multiple Application Servers.

Application Server types and deployments

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

• Application Server type — Defines the work that an Application Server can perform. You can specify an Application Server's type in its profile during creation.  There are four types of Application Servers — JOB, CONFIGURATION, NSH_PROXY, and ALL (a combination of the other three).  For a default installation, an ALL instance is created the first time that the Application Server service is started.  
• Application Server deployment — This is an instance of an Application Server of a specific type.  There can be multiple instances (deployments) on a single system. The deployment can be of a single type or of multiple types; for example: CONFIGURATION+NSH_PROXY or JOB+NSH_PROXY.

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

Combining Application Server 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 services). TrueSight Server Automation clients (rich client UI, BLCLI command line client, webservices) connect to configuration servers to authenticate and allow interaction with the TrueSight Server Automation system.

• Job servers
  A job server is an Application Server of type JOB or type ALL (which includes JOB services). JOB servers are responsible for the execution of TrueSight Server Automation jobs. It does not run services to handle NSH connections or user authentication.

• NSH proxy servers
  Network Shell (NSH) proxy servers proxy NSH client connections through the application infrastructure to the managed servers. This enables administrators to allow only the Application Server infrastructure to connect to the RSCD agent on managed servers instead of allowing user workstations to connect directly.

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

• PXE servers
  A TrueSight 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.

Considerations for combining Application Server profiles and deployments

The larger your environment, the more Application Server instances (or deployments) you will need. To optimize the use of resources, you can combine multiple Application Server profiles in one instance, or even have multiple Application Server instances running on one host computer.

To help you decide on the best combination of Application Servers in your environment, note the following guidelines:

• Application Servers of type CONFIGURATION and type JOB are typically heavy users of JVM resources, while Application Servers of type NSH_PROXY have lower demands for JVM resources.
• Therefore, you should not combine type CONFIGURATION with type JOB in one Application Server instance. By keeping these two Application Server profiles separate, you ensure that the JVM is dedicated to just one purpose.
• As separate Application Server instances (a separate Configuration server and separate Job server), you can consider having both on the same physical server, provided that this machine has enough memory and CPU.
• For the same reason, although ALL (the combination of all types) is the default type for a new instance of an Application Server, BMC does not recommend using ALL in a production environment.
• If you need an NSH proxy (an Application Server of type NSH_PROXY), it is recommended that you combine it with another Application Server type, either CONFIGURATION or JOB. The overhead for such a combination is not high, and you avoid having to manage a separate JVM. You also avoid having to configure your Job server or Configuration server to use a separate NSH proxy, and do not need to keep track of which NSH proxy is used by which server.
  
  • JOB+NSH_PROXY is recommended if your environment needs Job servers to use NSH proxies. For example, for certain SOCKS use cases or when using Automation Principals. This combination separates job traffic from user traffic. If you do not need an NSH proxy, the Application Server can be of type JOB alone.
  • CONFIGURATION+NSH_PROXY is needed only if users in your environment communicate through an NSH proxy.
• For additional considerations for running multiple Application Server instances on a single physical server, while still maintaining acceptable performance, see Considerations for adding Application Server instances.

Storage locations 

The TrueSight Server Automation environment can include the following storage locations:

• File servers
  Every TrueSight Server Automation environment includes a server designated as the file server. You can designate any server running an RSCD agent as the file server for the installation. Both the file server performance and the network connection between job servers and the file server have a critical impact on Deploy Jobs.
•  NFS as a file server
  NFS sharing provides higher performance than NSH data transfer. If Application Servers are all hosted on Linux or Oracle Solaris systems, then TrueSight Server Automation performance can be enhanced by using an NFS-based network-attached storage (NAS) device and mounting the storage on each system that hosts an Application Server. In this configuration, localhost should be designated as the file server, so that each Application Server treats the shared mount point as local storage.
•  Repeaters
  For environments in which Deploy Job performance over the WAN is a concern, BMC recommends the use of one or more repeaters at each data center. When configured correctly, a repeater serves as a staging location at each site for packages as they are deployed.
• Patch repository
  To use patch functionality, you must designate a patch repository. A patch repository is an NSH-accessible directory in the TrueSight Server Automation environment that is used to store patch metadata and payload information for patch jobs.
•  Provisioning data store
  For PXE-based provisioning (that is, provisioning of Windows and Linux servers), a provisioning data store server must be available. The provisioning data store holds OS images for the servers being provisioned.

TrueSight Server Automation Consoles 

Communication between the TrueSight Server Automation Consoles and Application Servers is sensitive to latency — the faster the connection between these components, the faster the overall performance. BMC recommends deploying consoles to servers on the same LAN as the Application Servers to which they connect. It is possible, but not recommended, for the console and Application Server to be separated by a longer network link; however, performance under that configuration might be unacceptable.

For environments in which a population of geographically-dispersed users must all have access to the console, BMC recommends running the console on Citrix XenApp or Microsoft Terminal Server. This allows users who are offsite from the presentation server to run remote instances of the UI without experiencing excessive latency.

Infrastructure for provisioning 

TrueSight Server Automation provisioning works with different provisioning technologies, depending on the type of server being provisioned.

Windows and Linux provisioning

PXE servers support Microsoft Windows and Linux provisioning jobs by providing boot-time services to target devices. Each target device must have access to a local PXE server, usually on the same LAN. The following diagram shows the elements of Windows and Linux provisioning.

Although PXE servers communicate with the database, the data volume of that communication is relatively low. It is acceptable to install geographically-removed PXE servers, which must communicate with the database over longer network legs.

The PXE server and the TFTP server must reside on the same physical server (or, in a virtualized environment, in the same virtual machine).

A provisioning target also needs access to the TrueSight Server Automation Application Server and a data store. Traffic to the Application Server is relatively light, so it is not necessary for the Application Server to be geographically proximate to the provisioning target. However, if the provisioning target will be retrieving files from a data store, it is preferable that the data store be local to the provisioning target.

Solaris provisioning

The Oracle Solaris JumpStart technology identifies a JumpStart boot server, a JumpStart Configuration Server, and a JumpStart install server, all of which can be (and commonly are) hosted on the same physical device. Unless using WAN boot configurations, JumpStart servers should be located on the same LAN as the Solaris servers being provisioned, but can be remote from the TrueSight Server Automation Application Server. To use a JumpStart server with provisioning jobs, you must install an RSCD agent on the JumpStart server.

AIX provisioning

The IBM AIX NIM technology requires a NIM Master server that is accessible by IP from the AIX servers being provisioned. To use a NIM Master with provisioning jobs, you must install an RSCD agent on the NIM Master server.

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, you must install an RSCD agent on the Ignite Master server.

Proxy servers 

Where to go from here

Simple-installations