How does TrueSight Server Automation work?

This topic provides an overview of TrueSight Server Automation, its components, and who uses it. The topic includes the following sections:

What can I do with the product?
How do I use the product?
What are the different components of the product?
The TrueSight Server Automation Security Model
An example job in TrueSight Server Automation
Where to go from here

What can I do with the product?

This product is a server automation tool. As an organization's server estate increases, administrators often find themselves struggling to:

Push out new configurations to servers
Deploy new servers in a consistent fashion
Track changes to server configurations

To help you deal with these challenging issues, the product offers the following core capabilities:

Capability	enables you to
Provisioning	Perform bare-metal provisioning, VM provisioning, and full service stack provisioning, including additional configuration items to customize the deployment.
Configuration management	Deploy and track changes to server configuration across the entire estate.
Patching	Push vendor updates to server OSs in a stable and consistent fashion.
Compliance	Analyze an organization's overall level of compliance with internal, regulatory, and security standards.

How do I use the product?

There are various ways to interact with TrueSight Server Automation:

Component	Overview
GUI	The GUI for TrueSight Server Automation, also known as the console, is the main interaction point for provisioning servers and automating their management. The console can connect to one or more Application Servers (also known as appservers). With the console, users can create jobs that can: Automate provisioning across many different environments Keep compliance under control Roll out software patches Automatically enforce a desired configuration state across your environment
Portal	The BladeLogic Portal is a web-based user interface targeted at end users who do not need the ability to create content for jobs. Portal users are typically operators who execute common server configuration management activities, such as patching, compliance, and software deployment.
BLCLI	BLCLI is the command-line interface for TrueSight Server Automation. It is a set of utilities that let you perform most of the tasks from a command line.
Network Shell	Network Shell (NSH) is a network scripting language that enables cross-platform access through a command line interface. From a central workstation, you can manage servers directly with NSH, or you can first authenticate a connection via the appserver.
API	TrueSight Server Automation has two APIs: a web services API and a REST API. The SOAP API has a full range of TrueSight Server Automation capabilities, but uses a complicated interface. The REST API is more user-friendly, but has limited functionality. Both APIs offer a way to make calls to the application server from the command line. This capability provides a way to further automate a TrueSight Server Automation implementation, and also allows for integration with other products. For information about the two APIs, see Working-with-Web-Services.

What are the different components of the product?

An operational TrueSight Server Automation system has a three-tier architecture that consists of client, server, and middle tiers. The following table gives an overview of each of the architectural pieces that comprise TrueSight Server Automation.

Component	What is it, and what does it do?
Application Server (appserver)	The appserver is the primary component in the middle tier of TrueSight Server Automation's three-tiered architecture. What does the appserver do? The appserver provides secure, scalable software for controlling communication between TrueSight Server Automationcomponents—primarily the TrueSight Server Automation clients and RSCD agents on managed servers. Many of the appserver's actions are based on user-defined jobs that perform a variety of tasks. The appserver also provides the instructions needed to provision servers. Where does the appserver run? Typically, the appserver runs on a dedicated machine in a central location. While only one appserver is necessary, larger installations typically configure multiple appservers. One or more may be dedicated for running jobs to improve performance and provide failover capabilities. Another may function as the interface to the console and other client applications. A third type of application server can authenticate and manage traffic between Network Shell users and RSCD agents. When a user performs any actions on a managed server, the appserver relays those instructions to the appropriate agents. If necessary, the appserver also communicates with other middle tier components—the database, file server, and PXE server (used for provisioning). What components does the appserver control? The appserver communicates with RSCD agents and initiates all communication to perform ad hoc and scheduled tasks. Not only does the appserver manage communication between clients and remote servers, it also controls interaction with the database, file server, and PXE server.
RSCD agent	The RSCD (Remote System Call Daemon) agent is software that must be installed and running on each remote server that TrueSight Server Automation accesses. How does the RSCD agent work? The RSCD agent can perform a variety of actions. Using native operating system commands, the agent can perform simpler actions, such as moving, modifying, comparing, or deleting files. The agent can also execute jobs that require it to perform a more complex series of activities. The agent never initiates activity. It only acts when directed to, either by means of jobs running on the appserver or users directly performing actions on the server via Network Shell (NSH) or the BLCLI. How is the RSCD agent different from NSH? NSH is a scripting language that allows users to perform cross-platform actions on servers via a command line interface. When an RSCD agent performs actions on a managed server, it is often executing NSH commands. However, the agent is capable of performing additional activities when the appserver or BLCLI runs jobs.
Repeaters/Proxies	Why would I use a repeater? The repeater is a file cache for deployment payloads. During deployments, files are pushed to the repeater and then from the repeater to targets. Using repeaters can limit bandwidth requirements when deploying large payloads to multiple remote systems and reduce the load on the file server on a local network. Why would I use a proxy? SOCKS is an Internet protocol that facilitates the routing of network packets between client-server applications via a proxy server. SOCKS performs at Layer 5 of the OSI model - the Session Layer (an intermediate layer between the presentation layer and the transport layer). If you want to manage remote servers on a different network from your TrueSight Server Automation system or outside your network's firewall, you can set up your appserver to communicate with those servers through SOCKS proxy servers.
NSH	NSH is a cross-platform shell with scripting capability that gives seamless access to remote servers from central management workstations. What does NSH do? NSH is a network scripting language that enables cross-platform access through a command line interface. How would I use it? You would use NSH for for ad hoc administration of one or more servers. How does NSH interact with the appserver? You can create and schedule jobs that that run NSH scripts. Optionally, you can define a special type of appserver called an NSH Proxy Server that authenticates and manages NSH traffic.
Database	What lives in the TrueSight Server Automation database? For the most part, the database holds files and file contents. For example, the database can store snapshot data about managed servers. Snapshot data is incremental. Every subsequent run of a snapshot stores only the delta information compared to the previous snapshot. In addition to files and their contents, if the console requires long entries, that information is also stored in the database. What database vendors does TrueSight Server Automation support? TrueSight Server Automation supports both Oracle and SQL Server databases.
File server	The file server stores files used for deployment and other large quantities of data unsuited for storage in the database. The appserver controls communication with the file server.

To see how the various TrueSight Server Automation components fit together, see TrueSight-Server-Automation-architecture.

The TrueSight Server Automation Security Model

The product provides multiple levels of system security, ranging from unrestricted communication between management consoles and remote servers to security models that incorporate the strongest available security mechanisms.

Before you go anywhere on the console, you must authenticate with the appserver. This is done through an Authentication Profile. After that, every time a user logs on to a appserver, they specify an Authenticaiton Profile, which stores basic information about how a user connects to an appserver, such as the authentication mechanism. Users can be authenticated using different security protocols, including LDAP, RSA SecurID, and TrueSight Server Automation's internal authentication model. Once logged in, a user's rights are determined by a system of role-based access control (RBAC) and ACLs. Privileges can be managed at the appserver level, as well as at the RSCD level using configuration files.

The capabilities you implement depend on your own security requirements and the system components that are communicating. For an explanation of how to implement all possible security capabilities, see Administering-security.

An example job in TrueSight Server Automation

The following is a step-by-step walkthrough describing how different components interact with each other in a sample job.

Paul is a systems administrator for a gaming company who wants to deploy an updated configuration file to 50 servers. To deploy the file using TrueSight Server Automation, Paul performs the following steps:

Paul logs on to the console and uploads the configuration file to a repository that the appserver manages called the Depot. Paul stores the file as part of a package called a BLPackage, which includes metadata about the file (such as the file's permissions, and so on).
Paul uses the console to create a Deploy Job to deploy the file to select servers in the environment. He schedules the Deploy Job to run that night at 2 AM. The appserver creates the scheduled job in the database associated with that package.
At 2 AM, the appserver sees that there is a pending job to be executed; the appserver reads the metadata about the job, and connects over the network to the RSCD agent running on each of the 50 target servers.
The appserver pushes the configuration file to be deployed, along with the necessary metadata, to the RSCD agent.
The agent executes the commands, puts the file in the correct location, and reports the results and status back to the appserver.
The appserver sends any appropriate notifications for the job to the console, and stores the aggregated results for each node in the database.
The next morning, Paul launches the console and views the results of the job. Seeing that the configuration was successfully deployed to all 50 servers, Paul takes the rest of the day off and goes fishing.

Where to go from here

Take a look at some of the sample walkthroughs to see examples of some common product capabilities in action: