How does BSA work?

This topic provides an overview of BMC BladeLogic Server Automation (BSA), its components, and who uses it. The topic includes the following sections:

What can I do with BSA?
What are the different components of BSA?
The BSA Security Model
An example job in BSA
Where to go from here

What can I do with BSA?

BSA 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, BSA offers the following core capabilities:

Capability	BSA 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 BSA?

There are various ways to interact with BSA:

Component	Overview
GUI	The GUI for BSA, 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 BSA. It is a set of utilities that let you perform most of the BSA 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	BSA has two APIs: a web services API and a REST API. The SOAP API has a full range of BSA 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 BSA application server from the command line. This capability provides a way to further automate a BSA implementation, and also allows for integration with other products, such as BMC Cloud Lifecycle Management.

What are the different components of BSA?

An operational BSA 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 BSA.

Component	What is it, and what does it do?
Application Server (appserver)	The appserver is the primary component in the middle tier of BSA's three-tiered architecture. What does the appserver do? The appserver provides secure, scalable software for controlling communication between BSA components—primarily the BSA clients (described above) 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 BSA 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 BSA 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 BSA 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 BSA database? For the most part, the BSA database holds files and file contents. For example, the BSA 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 BSA console requires long entries, that information is also stored in the database. What database vendors does BSA support? BSA 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.

The following diagram shows how the various BSA components fit together.

The BSA Security Model

BSA 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 BSA'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 BSA system components that are communicating. For an explanation of how to implement all possible security capabilities, see Administering-security.

An example job in BSA

The following is a step-by-step walkthrough describing how different BSA 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 BSA, Paul performs the following steps:

Paul logs on to the BSA 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 BSA's capabilities in action:

Walkthrough-Audit-a-single-configuration-item

Walkthrough-Inventory-using-Live-Browse

Walkthrough-Build-a-simple-BLPackage-to-distribute-content