HPSA Basics: 10 Reasons to Use HPSA HP Server Automation to Manage Servers

HPSA stands for HP Server Automation.

HPSA is used to bring entire server infrastructure (both physical and virtual) under one management to gain full visibility to all your servers and operations.

It can handle multiple server management activities including provisioning on bare metal, software management, patch management, audit remediation, security management,etc.

This article explains major features within SA that can be used to automate your datacenter management.

1. SA Core Architecture

HPSA architecture well suites for managing an infrastructure environment from few servers to 1000s of servers. It mainly has Core and Agent as part of its architecture.

Core:

The SA Core is the server side of the Server-Agent Architecture.

The core provides the functionality that automates servers and application management. A core server is a physical server that runs one or more the SA components, each with a unique purpose.

A core can run on a single server, or the core components can be distributed across multiple physical server to increase performance.

Each core points to oracle database which saves information about managed server configurations within SA. Some of the other core components can have multiple instances, which can be installed on different servers to achieve horizontal scalability.

Agent:

In a non-automated data center environment, thousands of servers are manually managed using all kinds of tools. Managing these servers using SA requires installing an SA core in to environment and also deploying SA agents on the servers in the environment that you want managed by SA.

In an SA managed environment, all servers either have an SA build agent or SA agent that communicates with the SA core.

The SA build Agent can also be installed on a bare metal server that contains no operating system, the Build agent runs in memory and communicates with the SA core basically waiting for provisioning instructions. The SA agent is software running in an existing operating system on the server and is used to communicate to the SA core. Communications between the core and agents allows the core to manage the entire life cycle of a server.

HPSA was earlier called as Opsware Server Automation.

2. Multiple SA Interfaces and Tools

HPSA suite has several interfaces and tools that are required for pretty much cover all the needs of an Infrastructure management. The following are some of the very useful tools that are part of HPSA

• SAS Web Client: The Web Based interface to SA through which users can manage servers, prepare OS installation Profiles, track configuration changes, and manage users and groups, and their permissions, and so on.
• SA Client: A powerful java client for SA. It is windows desktop application with the cross-platform flexibility of java. This is the most widely tool used by the system Administrators for provisioning, software management, policies, etc..
• SA Command Line Interface (OCLI): A command line interface used primarily for file management in the software repository.
• DCML Exchange Tool (DET): A Data Center Markup Language (DCML) tool used for packaging and
• transferring content from one SA core to another.
• ISM Development Kit(DK): A development kit that consists of command-line tools and libraries for creating, building, and uploading ISMs. An ISM is set of files and directories that include application bits, installation scripts and control scripts.
• SA Web services API (WS API): SA web services shows a web service interface to facilitate the integration of business and operations support systems with the SA platform. SA WS API allows other IT systems, such as existing monitoring, trouble ticking, billing, and virtualization technology, to exchange information with the SA platform.

For Demonstration purposes, I have used HP server automation Virtual appliance in this article. This is 30-day free trial version you can download it from HP website.

3. Inside the SA Client

The Devices tab in the navigation pane shows the devices in your managed environment. At the toplevel, there are folder for device groups, servers and storage devices.

Device groups: A device group acts as container for a collection of servers. It enables you to perform the same action such as installing patches and remediating servers on all of the servers simultaneously, instead of performing the action on individual servers, one at a time.

There are two types of device groups, private groups and public groups. Public groups are visible to all users, and can be access by any SA user. The private device groups are only visible to the group creator.

Servers: Servers are organized into the following four different categories:

• Un Provisioned server
• Managed server
• Unmanaged server
• Virtual server

Library: The Library tab in the Navigation pane allows you to see the contents on SA Core’s software repository. The library provides a way to display the software resources, such as application configurations, software policies, patches, patch policies, packages and so on managed by SA. Folders are also located in the library. In the library, you can view the software resources either by their type or by their location in the folder hierarchy.

Job and Sessions: A job is nothing but any major process run by the SA client such as communication test between SA core and managed server, a software installation, an OS installation, audit results remediation, an application configuration push, a server compliance audit, and so on. When launching a job in SA client, you specify when job runs to either run at immediately or specified time in future.

4. SA Users

The SA users can be classified as follows:

Operation Staff: System administrators and security administrators also the persons who is responsible for all aspects of managing and provisioning the servers in an operational environment. They perform actions such as provisioning servers, installing patches and applications.

SA Administrators: Advanced System Administrators responsible for administering the SA core.

Policy Setters: IT/application architect, Datacenter manager, responsible for architecting what SA does in the managed environment. For example, they determine which OS can be used.

5. Manage Software with Policies

SA allows you to model software using software policies.

You can specify in a software policy the packages and patches to be installed, and the configurations to be applied to the managed servers.

SA also provides a framework to ensure compliance against defined policies. With this feature, you can find out where, specifically, the server is out of compliance and remediate the server.

The policies usually contains the packages, patches, Application configuration, Files, Scripts, Unix users and groups(for changing ownership after package is installed).

6. Patch Management in SA

The Patch management in SA feature allows you to install patches directly to managed servers or device groups.

In a software/patch policy , patch administrators can provide pre-install and post-install scripts, install and uninstall flags, and instructions on when to reboot and how to handle error codes from the pre-install and post-install scripts.

SA uses a central repository (called the software repository) to store patches and organize them in their formats.

SA also maintains a central database that has detailed informed about every server under management, the patches and software installed on the servers, and the patches and software available for installation. You can use this information to determine the severity of your exposure to a newly discovered threat, and to help you access the benefits of rolling out patch as compared with costs in downtime and testing requirements.

7. Audit and Remediation in SA

The Audit and Remediation feature in SA allows you to create the rules that define server configuration compliance for the servers in your organization.

Rules can be created ad-hoc when running a server audit, created based on an existing server configuration (through a snapshot), or you can define a template(Audit Policy) of rules that can be used within your audits on a regular basis.

SA also allows you to run and schedule audits against servers to test compliance and if necessary, remediate server configurations not in compliance.

8. Script Management Execution in SA

A user created is executed manually on individual server, one server after another.

Now, there is feature in SA that automates the script execution process and the scripts are executed on all the servers that you want without having login to each server.

It also allows you to organize the scripts in folders and define security permissions around them.

From SA client, you can upload a script, set it up to run simultaneously across multiple UNIX or windows servers, and monitor it as it executes on each server. After a script is executed, you can view the results for every server and then export the scripts.

9. SA Agent Overview

Each server that SA manages has an intelligent agent running on that server. The SA agent is responsible for a change on a server.

Whenever SA needs to make changes to servers, it does so by sending requests to the SA Agent.

An SA agent is idle unless SA is trying to perform some change on the server. In addition, each SA agent periodically contacts the model repository and registers itself, which allows the model repository to keep track of the machine status, and know when particular servers are disconnected from and reconnected to the network. An SA agent runs with Administrator privileges (root on UNIX servers and Local system).

There are three types of SA agents as follows:

1. Full Agent – Responsible for managing a server.
2. Build Agent – An agent responsible for OS provisioning.
3. OGFS agent – Agent responsible for OS provisioning with build plans.

Manual Agent installation: To install the SA agent on any unmanaged server, you need to download the package first. Download the agent installer from SA client. The installers are available under Library(By Type) > Packages. You can search for the opsware-agent package to find all available agent installers by OS. If necessary upload the installer to the unmanaged server (must be logged in as root). You can then install the agent from the shell or a script.

Automatic Agent installation: this is useful to deploy the agent to multiple servers efficiently and easily.

The following is a screenshot from SA web client:

10. Device Group Overview

Device groups provide a useful way to gather physical or virtual servers into logical collections.

Grouping servers enables you to perform the same action on all of the servers simultaneously, instead of performing the action on individual servers, one at a time.

Operations that can be performed on a server can be performed on a device group.

A Device group acts as a container for a collection of servers. When any operations, such as installing software or patch and configuring application configurations, are performed on a device group, they are actually performed on servers within the group and not on the group itself.

The following are some of the characteristics of the device groups:

• A device group can be included in many or no device groups.
• Device groups can contain servers and other device groups.
• When you run an operation on a group that contains nested groups. The operation also applies to all servers in the nested groups below the current group (except for application configuration).
• Groups do not inherit custom attributes from their parents.