How does BSA work?
This topic provides an overview of BMC Server Automation (BSA), its components, and who uses it. The topic includes the following sections:
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|
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:
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:
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 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.|
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.
The RSCD (Remote System Call Daemon) agent is software that must be installed and running on each remote server that BSA accesses.
NSH is a cross-platform shell with scripting capability that gives seamless access to remote servers from central management workstations.
|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.
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: