| 1 | Introduction |
2 | Overview |
| 2.1 | Atlas Deployments |
3 | Orchestration |
4 | Workflow |
5 | Atlas Document Overview |
Reference List | |
1 Introduction
This document provides an overview of the management system for the Cloud Execution Environment (CEE).
For detailed information about using the Atlas dashboard, refer to the Atlas Dashboard Administrator User Guide and the Atlas Dashboard End User Guide.
This document covers the following topics:
- Atlas and CEE overview
- Atlas orchestration
- Atlas documentation overview
2 Overview
Atlas provides a management interface for CEE through a REST API, which separates it from the CIC hosts. Atlas users can manage CEE through both GUI and CLI. An architectural overview of CEE is shown in Figure 1fig-CEEArchitecture_eps.
- Note:
- Atlas manages both CEE and OpenStack CLI clients (the latter include the "general" OpenStack CLI and the individual OpenStack component CLIs for Neutron, Nova or Glance). OpenStack CLIs are also available through the vCICs, however, for the most efficient use, run them on Atlas.
Figure 0 CEE Architectural Overview
Figure 1 CEE Architectural Overview
Atlas is a single Virtual Machine (VM) monitored by CEE. Internally, Atlas supervises and restarts services as necessary, as shown in figAtlasProcess-eps Figure 2, but the Atlas VM itself is monitored and restarted by CEE. See figAtlasOverw-eps Figure 3 for an overview of Atlas and Figure 4 for structure and components.
2.1 Atlas Deployments
Atlas as a VM can execute in the following OpenStack region types:
- OpenStack regions with local storage only
- OpenStack regions with central storage
2.1.1 Region with Local Storage Only
Without access to replicated block storage, no resilience against disk or compute node replacement is available, and there is a risk of runtime and configuration data loss. However, backups of runtime and configuration data can be manually transferred into a replicated Swift object store. To restore Atlas from a backup stored in Swift, the image must be manually transferred from Swift to Atlas.
2.1.2 Region with Central Storage
Data stored in Atlas is either needed for the operation of Atlas itself, for example, configuration and log files, or by deployed applications, for example, the Heat database. To safeguard its availability, this data is stored on replicated Cinder volumes.
2.1.3 Network Usage and Connectivity
From the CICs point of view Atlas is considered a standard VM, and not an infrastructure VM. Therefore, it has no connectivity to the internal control network. The two logical networks of Atlas are realized on the traffic network, and the CEE control network is not utilized. See fig-AtlasNetwCon_eps Figure 7.
2.1.4 Fault Management
Atlas provides fault management in the form of an active alarm list, in which the user gets an overview of all the active alarms in the system, as well as the alarm and alert history. The alarm lists can be sorted on specific parameters, such as creation date and event type. It can also be filtered based on the severity level of the alarms. Upon clicking an alarm in the list, the user is presented with a detailed view of the alarm containing additional information.
The Operational Instruction (OPI) about a specific alarm is presented in HTML format by default, but is also available to download in PDF format.
In the alarm and alert history panel, the user can specify a date and view the alarms and alerts that were raised on that particular date. The alarm and alert history is available for the last seven days.
3 Orchestration
Atlas is a set of management tools, that provides a web-based user interface to CEE services, and application life cycle management. Atlas is based on the existing open source OpenStack components, Horizon and Heat.
Atlas manages the standard OpenStack services, such as Nova and Neutron. CEE services can be exposed and managed in the Atlas GUI and CLI if the expected service interface is provided, and if it can be integrated into the GUI.
In order to support the OVF standard, Atlas implements a custom service, OVF Translator (OVFT).
OVFT is an Ericsson service that:
- Provides OVF package handling in OpenStack.
- Stores HOT and Topology and Orchestration Specification for Cloud Applications (TOSCA) templates in the Atlas database.
The service prepares an OVF-based application for deployment using Heat. The predeployment process involves the following steps for OVF packages: upload, validation, extraction, image handling, and translation of an OVF descriptor to a corresponding HOT template.
Once an OVF package has been processed, it is stored in the Atlas database and appears in the application catalog in Horizon. OVFT provides a REST API, a CLI, and a Horizon GUI extension.
Heat is the main OpenStack service that implements an orchestration engine to deploy composite cloud applications based on templates. A Heat template describes the infrastructure resources for an application in a text file. Infrastructure resources that can be described include: servers, networks, volumes, ports, and so on. Heat understands two types of templates: the AWS CloudFormation template and the Heat Orchestration Template (HOT).
Atlas can orchestrate the installation of applications defined in OVF or HOT format. The orchestration includes all the necessities to fully install an application, VM setup, dimensioning and affinity rules, networking, and storage. Applications that are defined through a template are saved in a simple Atlas catalog allowing the application to be instantiated and installed as many times as needed. Instance-dependent application data can be supplied at the time of deployment by the use of a config-drive attached to the application VMs, containing the supplied instance data that is readable by the application.
Application orchestration in Atlas is ensured by two services, Heat and OVFT, as seen in figAtlasOrchestrationArchitecture-eps Figure 8.
The Atlas dashboard can be used to provision OpenStack users. Provisioning takes place through the OpenStack Keystone API by the Atlas GUI and the Atlas CLI.
- Note:
- Atlas includes Mistral, so application life cycle management is enriched with workflows and OpenStack specific actions. For further information, see the OpenStack End User Guide.
4 Workflow
Mistral is a workflow service. Most business processes consist of multiple distinct interconnected steps that need to be executed in a particular order in a distributed environment. Such a process can be described as a workflow that consists of a set of tasks and task relations. The workflow can be uploaded to Mistral so that it takes care of state management, correct execution order, parallelism, synchronization and high availability. Mistral also provides flexible task scheduling so that the operator can run a process according to a specified schedule, for example, every Sunday at 16:00, instead of running it immediately.
5 Atlas Document Overview
For a brief description of the available Atlas documents, see Table 1.
|
Document |
Description |
|---|---|
|
This document | |
|
Describes management tasks available to administrators | |
|
Describes management tasks available to end users | |
|
Describes the orchestration API | |
|
OpenStack Networking API in CEE in Dell Multi-Server Deployment |
Describes the networking API in CEE in Dell multi-server deployment |
|
Describes the networking API in CEE in single server deployment | |
|
Describes the atlas and swift commands used | |
|
Atlas Troubleshooting Guideline, Reference [1] |
Describes how users can collect information for troubleshooting Atlas |
|
Describes how to back up the configuration of Atlas for CEE | |
|
Describes how to restore the configuration of Atlas for CEE | |
|
Describes procedures for installing Atlas | |
|
Describes procedures for upgrading and updating the SW in an existing CEE Atlas server |
Reference List
| [1] Atlas Troubleshooting Guideline, 6/1553-CRA 119 1873/5 Uen |

Contents















