CloudPatterns.org

Problem

There are numerous administrative and maintenance tasks that need to be performed on physical servers, virtual servers and other IT resources. By default, many of these tasks are performed manually by humans.

Various frequently recurring circumstances at times necessitate the execution of these tasks to be immediate and on-demand. However, performing certain types of administrative tasks manually is impractical and inefficient due to the potential for human error, and the synchronization that is required to simultaneously carry out the same task across different platforms.

Solution

An automation system that supports multiple connectivity options is created to run commands and scripts on diverse platforms. Different scripts need to be integrated together to run in a common workflow that uses extra extensions. This engine may also generate reports on each separate step of the workflow.

Figure 1 - The cloud resource administrator defines the workflow logic (1) and expresses it in a series of scripts that is incorporated into an intelligent automation engine repository (2). The cloud resource administrator then selects the workflow, the systems it will run on, and its execution schedule (3). The intelligent automation engine runs the workflow and reports the results (4).

Application

An automation system referred to as an intelligent automation engine is implemented as a workflow management application that is capable of executing various scripts. The workflow logic is expressed in scripts via sequenced steps that are in a predetermined order with conditional logic. Conditions pertaining to environmental factors can be defined so that additional scripts and logic can be automatically triggered when environmental parameters change.

The intelligent automation engine includes a repository that is used to store artifacts, such as workflow scripts, log files, and connectivity configurations, as well as a user interface that allows for the creation and editing of scripting templates. The engine may further support connections to other system monitors to integrate monitoring data with script execution.

Intelligent automation engines support a range of common connection methods, such as SSH, RDP, and RCMD, in addition to various authentication methods. Other templates are supplied so that different connection methods can be more easily used.

Figure 2 - An overview of how the components can be assembled as a result of the application of this pattern.

1. The cloud resource administrator defines the workflow logic.
2. Script execution schedule times can be added while the workflow logic is being created or at a later point.
3. Existing scripts can be reused and added to the current workflow.
4. Access to the scripts is protected to ensure that they can only be run by authorized clients.
5. The scripts are ready for use.
6. The intelligent automation engine saves the scripts in its repository.
7. Security credentials for accessing and executing each script can be added.
8. The scripts can be used by the automated service provisioning programs.
9. The scripts are published via the self-service portal and the usage and administration portal for access and usage by cloud consumers.

The following figure depicts sample workflow logic that can be programmed in a script.

Figure 3 - This scenario depicts a physical server that needs patching, which is a routine task and a prime candidate for automation. The physical server is part of a cluster, so the script needs to ensure that the physical server is properly taken offline and monitoring is disabled before initiating the patching process.

There are circumstances in the patching workflow shown in Figure 3 that will test the ability of the intelligent automation engine to make logical decisions. For example, the script will be needed to be programmed with responses to the following scenarios:

• the patch is installed successfully or unsuccessfully
• a reboot is required (if the reboot is successful, the engine must have a way to detect this / if the reboot is unsuccessful, the engine must log the error)
• after the patch is completed, the physical server's status needs to be changed to "online" and brought back into the cluster

Scripted workflows can at times require an extended period of time to complete, which makes handling error conditions more difficult. Additional challenges that arise when applying this pattern pertain to integrating scripts across different platforms and systems.

NIST Reference Architecture Mapping

This pattern relates to the highlighted parts of the NIST reference architecture, as follows: