Develop > Server Automation Platform > Overview of the Server Automation Platform

Overview of the Server Automation Platform

Using the Server Automation Platform, you can perform the following tasks:

  • Build new automation applications and extend SA to improve IT productivity and comply with your IT policies.
  • Exchange information with other IT systems, such as existing monitoring, trouble ticketing, billing, and virtualization technology.
  • Use the SA Model Repository to store and organize critical IT information about operations, environment, and assets.
  • Automate the management of a wide range of applications and operating systems.
  • Incorporate existing Unix and Windows scripts with SA, enabling the scripts to run in a secure, audited environment.

This topic provides an overview on the components and benefits of the Server Automation Platform:

Components

The following figure displays the major elements of the Server Automation Platform.

Server Automation Platform components

As the above figure shows, the platform comprises the following five key elements. Each of these elements is discussed in more detail in subsequent sections.

Automation applications

As in the figure above, the Automation Applications are at the top of the stack. These are the applications users write on top of the platform.

Automation applications can either be SA-Hosted Applications, which run in the SA Runtime Environment, or as standalone applications that run in a completely independent context. Standalone applications access the platform remotely through Web Services calls.

Simple applications can be written as simple Unix shell scripts in minutes. More complex applications—such as integration with an existing source control or ticketing system—can take a little longer and might involve Python or Microsoft .NET or Java coding. In either case, the platform is designed as a language-independent system easily adopted by a wide variety of developers.

SA runtime environment

Next down the platform stack is the SA Runtime Environment, which provides a set of powerful, out-of-the box runtime services and a corresponding language-independent programming model. SA-Hosted Applications run in the SA Runtime Environment.

The core of the runtime environment consists of two components that organize and provide access to all managed devices in a familiar Linux/Unix shell file-and-directory paradigm:

  • Global Shell:

    The Global Shell is a command-line interface to the Global File System (OGFS). The command-line interface is exposed through a Linux shell such as bash that runs in a terminal window. The OGFS unifies the SA data model and the contents of managed servers—including files—into a single, virtual file system.

  • Global File System:

    The OGFS represents objects in the platform data model (such as facilities, customers, and device groups) and information available on platform managed devices (such as the configuration setting on a managed network device or the file system of a managed server) as a hierarchical structure of file directories and text files. For example, in the OGFS, the /opsw/Customer directory contains details about customer objects and the /opsw/Server directory has information about managed servers. The /opsw/Server directory also contains subdirectories that reflect the contents (such as file systems and registries) of the managed servers.

    This file-and-directory paradigm allows administrators familiar with shell scripting to easily write scripts which perform the same task across different servers by iterating through the directories that represent servers. Behind the scenes, the Global File System securely delivers and executes any logic in the script to each managed server.

    The contents of devices can be accessed through the Global File System, a virtual file system that represents all devices managed by SA and Network Automation (NA). Given the necessary security authorizations, both end users and automation applications can navigate through the OGFS to the file systems of remote servers. On Windows servers, administrators can also access the registry, II metabase, and COM+ objects.

SA Command Line Interface

The SA Command Line Interface (CLI) provides system administrators and platform automation applications a way to invoke automation tasks such as provisioning software, patching devices, or running audits from the command line. A rich syntax allows users to represent rich object types as input or receive them as output from CLI invocations.

The CLI itself is actually programmatically generated on top of the platform API, discussed in the next section. The advantage of this is that as soon as developers add a new API to the platform API, a corresponding CLI method is automatically available for it. In other words, there is no lag time between the availability of new features in the product and the availability of the corresponding CLI methods in the platform.

SA Platform API

The SA Platform API is the Win32 API of SA: It defines a set of application programming interfaces to get and set values as well as perform actions. The SA user interfaces, including the SA Client and the SA Command Line Interfaces (CLI), are all built on top of the SA Platform API. The API includes libraries for Java RMI clients and WSDLs for SOAP-based Web Services clients. With Web Services support, programmers can create clients in popular languages such as Perl, C#, and Python.

SA Platform resources

SA Platform Resources sit beneath the SA Runtime Environment and give developers access to a rich set of objects and actions which they can re-use and manipulate in their own applications.

  • Inventory Model

    The Inventory Model provides all the information gathered by the SA about each managed devices such as make, manufacturer, CPU, operating system, installed software, and so on. Inventory information is made available through the SA API and also appears as files (in the attr subdirectories) in the Global File System. The Inventory Model includes objects such as Servers and Network Devices.

    Administrators can extend the data associated with inventory objects. For example, if users want to store a picture of the device or a lease expiration date or the ID of a UPS the device is plugged into, the platform makes it easy to add those attributes to each device record. Users can then add, delete, and work with those attributes just as they would the attributes that come out of the box.

  • Security Model

    The Security Model allows developers to leverage the built-in SA authentication and authorization security systems.

    All clients of the platform—management applications, scripts, as well as the end-user interfaces provided by SA are controlled by the same security framework.

    The security administrator — not the developer — creates user roles and grants permissions. Developers can re-use all of these user roles and permissions in the context of their own applications. For example, network administrators can write a shell script and share it with other network administrators with the confidence that those network administrators can only run that script on network devices they are authorized to manage and no others.

    The authorization mechanism controls access at several levels: the types of tasks users can perform, the servers and network devices accessed by the tasks, and the SA objects (such as software policies).

  • Environment Model

    The Environment Model defines the overall business context in which devices live. In general, devices belong to one or more customers, are located in a particular facility, and belong to one or more groups. The platform makes each of these objects — Customers Facilities, Device Groups, and others — available to application developers.

    As with inventory objects, environment objects can easily be extended. This makes it easy, for example, to define attributes such as the SNMP trap receiver used in a particular data center or printers only available in a particular facility, or Apache configurations used by only a particular business unit.

  • Policy Model

    The Policy Model gives developers access to all the best practices defined in SA. Policies describe the desired state on a server or network device. For example, a patch policy describes the patches that should be on a server, a software policy describes what software should be on a server, and so on.

    Subject matter experts define these policies which can be used by any authorized system administrator to audit devices to discover whether what’s actually on a device differs from what should be on the device. Programmers have access to this complete library of policies to use in their own applications.

    Software policies are organized into folders which can define security boundaries. In other words, applications will be able to access only those software policies they are permitted to access based on their user permissions.

  • Package Repository

    The Package Repository gives developers access to all the software and patches stored in SA. These include operating system builds, operating system patches, middleware, agents, and any other pieces of software that users have uploaded into SA.

  • Event Repository

    The Event Repository houses the digitally signed audit trails that the SA generates when actions are performed, either through the user interface or programmatically with the platform. As with other platform objects, these events are available programmatically.

  • Automation Actions

    Automation Actions allow developers to programmatically launch any of the actions that SA can perform on managed devices, ranging from running an audit to provisioning software to applying the latest OS patch.

    The platform provides access to the same features available to end-users in the SA Client. These features include tasks such as installing patches, provisioning operating systems, and installing and removing software policies. In fact, the SA Client calls the same APIs that are exposed programmatically through the SA Runtime Environment.

  • Remote Access

    Remote Access gives developers programmatic access to the managed device’s file system (in the case of servers) and execution environment (in the case of all devices). Developers can easily write applications which check for the existence of a file or particular software package, run operating system commands to check disk usage, or run system scripts to perform routine maintenance tasks.

SA Management Network

The Management Network is a powerful combination of technologies which enable developers to securely access any device under management. The Management Network delivers several key services:

  • Connectivity: Allows the platform (and thus automation applications) to reach any managed device.
  • Security: Includes SSL/TLS-based encryption, authentication, and message integrity.
  • Address space virtualization: Enables the platform to locate servers across multiple overlapping IP address spaces. Most complex enterprise networks have multiple private IP address spaces.
  • Availability: Allows system architectures to define redundant paths to any given managed device so that devices can still be reached despite failures in any given network path.
  • Caching: Enables servers to download software and patches from a nearby server rather than a distant server, saving both time and network connectivity charges.
  • Bandwidth throttling: Lets system architectures determine how much bandwidth SA and any SA applications can consume as it traverses the network to a particular device.
  • Least cost routing: Allows system designers to set up rules governing which paths to use to reach a particular device to minimize network connectivity costs.

SA Managed Devices

At the bottom of the platform stack are the actual devices under management. The platform manages over 65 server OS versions and over 35 different network device vendors with thousands of device models/versions supported out of the box.

The list of supported devices is constantly being updated. Platform developers and script writers benefit directly from this device list since their automation applications can consistently reach an ever growing list of managed devices in the same, familiar platform programming environment.

Benefits of the SA Platform

The SA Platform has the following key benefits.

Powerful security

The platform delivers the following comprehensive security mechanisms so developers don’t have to worry about providing them in their own applications.

  • Secure communication channels: End-to-end communication from the automation applications out to the managed devices is encrypted and authenticated.
  • Role-based access control: The platform respects the role-based access controls built into the SA so developers can easily share their applications with the con.dence that they will run just on those devices that an administrator has been granted access to.
  • Digitally signed audit trail: After an automation application runs, the platform generates a digitally signed audit trail capturing who ran the application, the time of the application execution, and the devices on which the application ran.
  • Comprehensive reach The platform provides comprehensive reach across all devices so system administrators and developers don’t have to worry about how to get to a device:
  • Market-leading platform coverage: Supported devices include over 65 server OS versions and more than 1,000 network devices.
  • In any physical location: The devices can be located anywhere in the world whether in a major data center or a retail store or a satellite of.ce.
  • In any IP address space: The devices can belong to any IP address space, as the platform supports multiple overlapping IP address spaces.
  • In DMZs: Devices can be located in DMZs or other difficult-to-access network spaces without requiring the developer or system administrator to worry about the details of reaching the device (for example, through a bastion host).

Rich services

The platform exposes practically all the relevant data and actions in the underlying automation system:

  • Rich data out-of-the-box: Developers have easy access to a rich set of data generated in part by the platform itself (such as device inventory data and facility information) and in part by users interacting with the platform (such as device groups customers, best practices policies, and uploaded software, patches, and scripts). Developers can easily write applications to read and write this data.
  • Extensible data store: Developers can easily extend the native platform objects to include their own data. Device inventory models can be extended to include attributes the platform does not natively discover. Customer and facility objects can be extended to include attributes that should guide the provisioning or auditing of devices related to that customer.
  • Automation tasks: The platform exposes nearly all the capabilities of the underlying automation systems to developers: patching, provisioning, auditing, and others. This enables developers writing complex work flows that span multiple systems to simply call these actions from the context of an automation application.

Easily accessible to a broad spectrum of programmers

The platform is explicitly designed to appeal to a broad range of developers ranging from Unix shell and Visual Basic script writers to Perl and Python programmers to enterprise .NET or Java programmers. The platform’s Runtime Services layer makes most platform objects available in a file-and-directory paradigm and most platform services available from a command-line interface (the SA CLI). This allows system administrators used to writing shell scripts to instantly use the platform without having to learn a new programming language and tool. They can get started with their favorite text editor, a familiar Unix shell, and then quickly develop scripts.

For more complicated applications and integration with existing systems, system programmers can use whatever programming tools and languages that have Web Services bindings.

Send Help Center feedback