CEE R6 Network Impact Report

1	Introduction
1.1	Purpose
2	General Impact
2.1	Capacity and Performance
2.2	Hardware
2.3	Implementation
2.4	Interface
2.5	Operation
2.6	New Features
2.7	Deprecated Features
2.8	Removed Features
2.9	Other Network Elements
2.10	Other Impacts
3	Summary of Impacts
4	Impact on CEE Features
4.1	OpenStack Mitaka
4.2	Cloud SDN Switch
4.3	SDN Standard
4.4	Small Footprint Deployment
4.5	Single Server Deployment
4.6	Secure TLS Communication
4.7	Centralized Block Storage
4.8	Distributed Block Storage
4.9	Swift on VNX
4.10	SR-IOV
4.11	Bandwidth Management
4.12	Backup and Restore
4.13	Resource Management for Virtual Machines
4.14	CEE Reference Configurations
4.15	Equipment Management
4.16	Centralized Identity Management
4.17	Ericsson Neutron
4.18	Continuous Monitoring High Availability (CM-HA)
4.19	Performance Management
4.20	Fault Management
4.21	Upgrade And Rollback
4.22	Security and Audit Trail Logging
5	Ericsson Atlas
5.1	OpenStack Mitaka
5.2	OVFT
5.3	Application Template Export
5.4	Multi-Region Dashboard and Placement Zones
5.5	On-Demand Application Scaling
5.6	TOSCA support
5.7	Mistral support deployment
5.8	Deployment Wizard
5.9	Enhanced Stack Panels
5.10	Atlas backup
Reference List

1 Introduction

The Network Impact Report (NIR) describes the changes made in the Cloud Execution Environment (CEE) R6 release, compared to CEE 16A IRP releases and the impact on the overall network of the operator, including affected products and functions.

The intention is to cover the delta from CEE 16A latest IRP up to CEE R6 latest release. This document revision covers CEE R6 releases up to CEE R6.3.

1.1 Purpose

The purpose of this document is to provide information for Ericsson system operators at an early stage, and help them plan the introduction of new products and upgrades to their networks.

2 General Impact

This section provides information on how the changes introduced in CEE R6 affect general product behavior and characteristics.

2.1 Capacity and Performance

2.1.1 Capacity and Dimensioning Guidelines

The new features introduced in CEE R6 compared to CEE 16A impact capacity and performance.

ScaleIO uses data mirroring in order to maintain data availability and protect for single-point of failure scenarios. Mirroring of data needs to be considered when calculating the usable capacity versus raw capacity. The usable capacity is much less than the raw capacity somewhere between one third and one half of total raw capacity, depending on the number of ScaleIO servers and how much faults can be tolerated without data loss.
.

2.1.2 Performance

The performance is improved in CEE R6 by introducing a new version of the Open Virtual Switch, OVS 2.5. Data Plane Development Kit version used in CEE R6 that corresponds to OVS 2.5 is DPDK 2.2. In CEE 16A OVS 2.4 and DPDK 2.0 were used.

2.2 Hardware

In CEE R6 the following hardware is supported : HDS 8000, BSP 8100, Dell R630 and HP c7000.

For more details on supported HW refer to the relevant System Dimensioning Guide for corresponding HW - Multi-Server System Dimensioning Guide, CEE R6, BSP System Dimensioning Guide, CEE R6, or HP System Dimensioning Guide, CEE R6, and BOM for Certified HW Configurations, Reference [2].

2.3 Implementation

There are no supported upgrade paths to CEE R6. An initial installation is required.

The following changes are made in CEE R6 release that have impact on implementation:

Atlas installation has changed in CEE R6, it uses localrc for setting variables instead of using arguments and variables as parameters for the atlas installation script. For more details please see Atlas SW Installation
Ansible is replaced by Fuel plugins

2.4 Interface

Changes in the interfaces of CEE R6 are mostly related to the following features:

OpenStack Mitaka support. OpenStack Kilo was used in CEE 16A
ScaleIO introduced
Cloud SDN switch

2.4.1 API Interface

For a summary of major Application Programming Interface (API) impacts, see Table 1.

Table 1 Major API Impacts
Interface	Nodes	Protocol	Impact	CEE Feature
ScaleIO )	ScaleIO Gateway	REST over HTTP(S)		ScaleIO integration
Vi-Vnfm (VIM-VNFM) and Or-Vi (NFVO-VIM)	NFVO/VNFM	REST over HTTP(S)	The behavior of CEE R6 is aligned to the behavior of OpenStack Mitaka?.	OpenStack Mitaka support
Nf-Vi (VIM-SDN)	SDN Controller	REST over HTTP(S)	The interface is updated according to changes introduced in Modular Layer 2 (ML2) mechanism drivers compatible with OpenStack Mitaka .	OpenStack Mitaka support

See subsections of features OpenStack Mitaka Section 4.1, Secure Communication over TLS Section 4.6, Resource Management for Virtual Machines Section 4.13, Ericsson Neutron Section 4.17 for more details on major API impact.

2.4.2 Man–Machine Interface

Changes in the Man–Machine interface are mostly related to OpenStack Command Line Interface (CLI) changes in the OpenStack Mitaka release.

The following changes are made in CEE R6 release that are related to man-machine interface:

ScaleIO feature introduces a new CLI interface called SCLI (ScaleIO Command Line Interface) to interact with the ScaleIO components. See subsections of specific feature for other changes in the CLI.
ScaleIO GUI is not part of CEE GUI in Atlas but is part of Man-Machine interface.

2.4.3 Other interfaces

For information on other interfaces check information on feature that implements corresponding interface. For example, for changes related to SNMP interface check Section 4.20

2.5 Operation

See subsections of specific features in Section 4 for the impact on the CLI and for other changes related to the operation and maintenance of CEE.

2.6 New Features

New features are features that are new in the current release.

The following features/functionality are new in this release:

Openstack Mitaka
Distributed Block Storage
Swift on VNX
SDN Standard
SR-IOV VLAN
Fencing CMHA
Bandwidth Management
Atlas: Mistral support deployment, deployment wizard and enhanced stack panels

2.7 Deprecated Features

Deprecated features are features that, although they still provide their functionality in the current release, their use should be avoided and instead the alternative features should be used.

The following features/functionality are deprecated in this release:

CEE infrastructure backup and restore and fuel backup are replaced by fuel synchronization.
The persistency of hints same_host and different_host
Trunk port v1 API is deprecated in this release. This API is fully supported in this release but will be discontinued in the following CEE releases as it will be replaced by trunkport v4 API. There are no plans for CEE to support both versions of this API in parallel.

Obsolete features are features that are not supported anymore in this current release, because new features have replaced them.

There are no major features in this release that are obsolete, but certain functionality of some features is made obsolete. See subsections for specific features in Section 4.

2.8 Removed Features

Removed features are features that are removed in the current release.

The following features/functionality are removed in this release:

Migration Policies, such as NoMigration and OfflineMigration
Evacuation Policies, such as Evacuation and NoEvacuation

2.9 Other Network Elements

Information on other network elements affected by CEE R6 is provided in Section 3.

2.10 Other Impacts

2.10.1 Changes in IP Addressing

There are changes in the IP addressing for CEE R6 compared with what is needed for CEE 16A .

Two IP addresses from storage network are needed for the ScaleIO.
One IP address needed for HA access of the ScaleIO gateway
A new VLAN (4090) and IP is added for HDS monitoring agent
New vNIC in vFuel VM attached to cee_om_sp on kickstart server with dedicated IP is needed for HDS
.
Note:
Floating IP functionality is not supported in this release.

2.10.2 Changes in VLAN Allocation

A new VLAN (4090) and IP is added for HDS monitoring agent.

Four new VLANs are needed for ScaleIO, two front-end and two back-end, customer needs to assigns the vlan ID.

2.10.3 Glance Image Cache

There are no changes in glance image cache on CEE R6 compared to 16A .

2.10.4 Neutron DHCP Agents

There are no changes in neutron dhcp agents on CEE R6 compared to 16A .

2.10.5 Logging configuration

There are no changes in logging configuration.

2.10.6 RADIUS server

There are no changes related to RADIUS server support.

2.10.7 Service Supervision changes

There are no changes in service supervision in CEE R6 compared to 16A .

2.10.8 Hostname changes

New hostnames are introduced as a result of adding the ScaleIO feature.

In CEE R6 ScaleIO nodes are named: scaleio-0-<x> where <x> is the blade id. There is a minimum of five ScaleIO nodes that are required in CEE.

2.10.9 Deployment changes

In CEE R6 release, Ericsson component deployment is changed from being Ansible based to using Fuel plugins.

3 Summary of Impacts

For features that existed in previous release 'major/minor' refers to impact on this feature in this release. For new features 'major/minor' as description of an impact is provided dependent on how this feature is considered to affect CEE functionality. See Table 2 for a summary of impacts in CEE R6, and see Table 3 for a summary of impacts in Atlas R6.

Table 2 Summary of Impacts in CEE R6
Feature	Impact	Feature Impact	Other Nodes
OpenStack Mitaka	Major	New	NFVO/VNFM
Cloud SDN Switch	Minor	Enhanced
SDN Standard	Major	New
Small Footprint Deployment	None	None
Single Server Deployment	None	None
Ericsson Neutron	Minor	Enhanced	NFVO/VNFM
SR-IOV	Major	Enhanced	NFVO/VNFM
Bandwidth Management	Major	Enhanced
CM-HA	Major	Enhanced	NFVO/VNFM
Resource Management for Virtual Machines	Major	Enhanced	NFVO/VNFM
CEE Reference Configurations	Minor	Enhanced	NFVO/VNFM
Equipment management	Minor	Enhanced	NFVO/VNFM
Centralized Block Storage	Minor	Enhanced
Distributed Block Storage	Major	New
Swift on VNX	Major	New (reintroduced from 15B)	EMC VNX
Backup and Restore	Major	Enhanced
Upgrade and Rollback	Major	Enhanced
Fault Management	Minor	Enhanced	ECM or other SNMP destination for alarms
Performance Management	Minor	Enhanced
Centralized Identity Management	Minor	Enhanced
Secure Communication over TLS	Minor	Enhanced	NFVO/VNFM
Security and Audit Trail Logging	Minor	Enhanced

Table 3 Summary of Impacts in Atlas R6
Feature	Impact	Feature Impact	Other Nodes
OpenStack Mitaka	Major	New	NFVO/VNFM
OVFT	None	None/A	NFVO/VNFM
On-Demand Application Scaling	None	N/A	NFVO/VNFM
Multi-Region Dashboard and Placement Zones	None	N/A
Application Template Export	None	N/A	NFVO/VNFM
TOSCA Support	Minor	Enhanced	NFVO/VNFM
Mistral Support Deployment	Major	New	NFVO/VNFM
Deployment Wizard	Major	New	NFVO/VNFM
Enhanced Stack Panels	Major	New	NFVO/VNFM
Atlas Backup	Major	Enhanced	NFVO/VNFM

4 Impact on CEE Features

This section describes the changes made on the different CEE features in the CEE R6 release.

4.1 OpenStack Mitaka

4.1.1 Description

In CEE R6 Mirantis OpenStack (MOS) 9.0 release is used that includes OpenStack Mitaka. Mirantis OpenStack 7.0 with OpenStack Kilo was used in CEE 16A .

4.1.2 Impact

There is impact on CEE features due to OpenStack Mitaka:

CEE R6 adds support for selecting the thread allocation of the VMs, for more details please see Openstack Compute API in CEE CPI
CEE R6 provides support for the neutron security groups and allowed address pairs APIs , for more details please see Openstack Networking API in CEE CPI.
Note: Depending on the deployment time, setting up the allowed address pairs and security groups might or might not affect the connectivity to the VMs, for more details please see Configuration File Guide

4.1.2.1 Capacity and Performance

There is no information available at this time

4.1.2.2 Hardware

There is no hardware impact of this feature.

4.1.2.3 Implementation

There are no specific steps that are needed for the implementation of this feature.

4.1.2.4 Interface

The impact of this feature on interfaces is described in the following subsections.

4.1.2.4.1 API

The APIs of OpenStack components are backwards compatible within an API version. Additional functionality that is available can be used with same API version.

For more information, refer to OpenStack API Complete Reference and CEE-specific API documents referenced below.

A high-level overview of API versions to be used in CEE is provided below:

Compute API V2 (OpenStack component Nova) — mandatory. Refer to OpenStack Compute API in CEE.
Networking API V2 (OpenStack component Neutron) — mandatory
Networking API in CEE must be checked for changes related to supported functionality and extensions. Refer to OpenStack Networking API in CEE in HP and Dell Multi-Server Deployment, OpenStack Networking API in CEE in Single Server Deployment and OpenStack Networking API in CEE in BSP Deployment
Identity API V2 (OpenStack component Keystone) — mandatory
Refer to OpenStack Identity API in CEE.
Block Storage API V2 (OpenStack component Cinder) — mandatory
Refer to OpenStack Block Storage API in CEE.
Image Service API V2 (OpenStack component Glance) — recommended
Refer to OpenStack Image Service API in CEE.
Telemetry API V2 (OpenStack component Ceilometer) — mandatory
Refer to OpenStack Telemetry API in CEE.

Object Storage API is used only internally in CEE, it is not available for tenants. The Orchestration API is covered as part of Atlas, see Section 5.

4.1.2.4.2 Man–Machine Interface (CLI)

The impact is related to the following:

Changes due to new or changed functionality: changes are described in API documents referenced in Section 4.1.2.4.1.
Migration from OpenStack component specific to OpenStack CLI client .I.

4.1.2.5 Obsolete Features

Details on obsolete features are mostly given in sections for specific features within this document.

4.2 Cloud SDN Switch

4.2.1 Description

In CEE R6 Cloud Software Defined Networking Switch (CSS) is used in the traffic switching domain. It is based on Open vSwitch (OVS) and Intel DPDK - network packets are processed in user space, and high performance and low latency is achieved by use of poll mode drivers. Due to DPDK and the user space packet processing, the network performance is higher compared to a conventional (kernel) OVS datapath. DPDK acceleration for OVS is only used in vSwitch of Compute Host (host OS) and not in vCIC nodes/vFuel.

. DPDK acceleration for OVS is for the tenant network only , for control network the kernel datapath is used.

4.2.2 Impact

Newer version of Cloud Software Defined Networking Switch , CSS is delivered with CEE R6.

CSS2 has been replaced by newer version of CSS on compute hosts. The supported port types for the DPDK datapath are still dpdk and dpdkvhostuser for NIC and virtio interfaces, respectively.

4.2.2.1 Capacity and Performance

No information is available at this moment.

4.2.2.2 Hardware

There is no hardware impact for this feature.

4.2.2.3 Implementation

For implementation information, refer to Configuration File Guide.

4.2.2.4 Interface

There is no interface impact for this feature.

4.2.2.4.1 API

Enhanced vSwitch feature does not have an API interface.

4.2.2.4.2 Man–Machine Interface (CLI)

There is no impact for this feature.

4.2.2.5 Obsolete Features

Port type dpdkvhostcuse should no longer be used as it will be removed in the next release of CSS.

4.3 SDN Standard

4.3.1 Description

With the CEE SDN standard feature it possible for CEE to run on a disaggregated HypeScale DataCenter System 8000 (CSD) and the management component (CCM) and integrates with SDN standalone for L2 and L3 use cases for both intra and inter DC communication. SDN controller is deployed outside CEE on separate server blades.

4.3.2 Impact

No information is available at this point.

4.3.2.1 Capacity and Performance

No information is available at this point.

4.3.2.2 Hardware

No information is available at this point.

4.3.2.3 Implementation

No information is available at this point.

4.3.2.4 Interface

4.3.2.4.1 API

No information is available at this point

4.3.2.4.2 Man–Machine Interface (CLI)

No information is available at this point.

4.3.2.5 Obsolete Features

No information is available at this point.

4.4 Small Footprint Deployment

4.4.1 Description

Small Footprint Deployment is a feature that implements vCIC and vFuel and allows to decrease of the number of servers needed for the CEE infrastructure. In CEE R6, some Compute Hosts can be used for vCIC hosts and vFuel as well as tenant VMs (the exact allocation depends on available capacity).

The redundant deployment should contain at least three servers with three vCIC nodes running on different servers vCIC hosts (Compute Hosts hosting vCIC nodes). It is possible to collocate Atlas and vFuel on some of these servers if there is enough capacity.

4.4.2 Impact

There is no impact on this feature in this release.

4.4.2.1 Capacity and Performance

There is no information available at this time

4.4.2.2 Hardware

Small Footprint deployment is used with all hardware types.

4.4.2.3 Implementation

For implementation information, refer to Configuration File Guide and the installation documentation.

4.4.2.4 Interface

4.4.2.4.1 API

Not applicable.

4.4.2.4.2 Man–Machine Interface (CLI)

Not applicable.

4.4.2.5 Obsolete Features

There are no obsolete features related to this feature .

4.5 Single Server Deployment

4.5.1 Description

Single Server solution runs on a single physical server and includes the following:

One vCIC
Atlas VM, in configuration that requires less CPU, RAM and local disk resources
Tenant VMs

In Single Sever vFuel runs on the Kickstart Server in this case and is not migrated to CEE Region (however some of the Fuel services are migrated to vCIC).

4.5.2 Impact

There is no impact on this feature in this release.

4.5.2.1 Capacity and Performance

There is no impact on capacity and performance for this feature in this release. Single Server has limitations in capacity and performance. Refer to the documentation of a respective VNF to decide if Single Server deployment is supported.

4.5.2.2 Hardware

Only Dell R630 is certified hardware for Single Server deployment. Extreme switches as ToR switches, and Block Storage (Cinder, provided by centralized storage - EMC VNX) cannot be used with this feature.

4.5.2.3 Implementation

For implementation information, refer to Configuration File Guide and the installation documentation.

4.5.2.4 Interface

Handling of NUMA-related aspects is different in Single Server deployments - different flavor keys are used for Single Server to allocate RAM/CPU resources.

4.5.2.4.1 API

Refer toOpenStack Compute API in CEE for information on CPU/memory allocation in Single Server Deployments.

4.5.2.4.2 Man–Machine Interface (CLI)

Changes in CLI interface correspond to changes in API interface described above

4.5.2.5 Obsolete Features

There are no obsolete features related to this feature.

4.6 Secure TLS Communication

4.6.1 Description

The Secure TLS Communication feature changes the configuration of OpenStack endpoints: now HTTPS instead of HTTP is used for communication that OpenStack REST API. TLS 1.2 is the recommended protocol version.

4.6.2 Impact

There are changes in this release for this feature as a result of the Mitaka uplift.

In the CEE R6 release haproxy is configured to add an additional header to the HTTP request (X-Forwarded-Proto https) when the original request was using HTTPS. Services supporting this option will use the setting in the response's URL schema.

4.6.2.1 Capacity and Performance

There is no information available at this time

4.6.2.2 Hardware

There is no hardware impact for this feature.

4.6.2.3 Implementation

HTTPS is secure only if the certificates are compliant with security recommendations. It is necessary to get certificates for each CEE Region being installed. Certificates must be signed by valid Certification Authority — self-signed certificates are not accepted. Two separate certificate files are needed for Atlas and for the vCIC and two certificate files for respective Certification Authorities (CAs). For more details, refer to the following documents:

4.6.2.4 Interface

There are no interface changes for this feature in this release.

4.6.2.4.1 API

There is impact on tools that could be used for connectivity to OpenStack API .

Cipher )

4.6.2.4.2 Man–Machine Interface (CLI)

There is no impact on CLI related to this feature.

4.6.2.5 Obsolete Features

There are no obsolete features related to this feature.

4.7 Centralized Block Storage

4.7.1 Description

Centralized Block Storage allows the implementation of Cinder functionality using a centralized storage system, such as EMC VNX.

4.7.2 Impact

There is no impact on this feature in this release.

4.7.2.1 Capacity and Performance

Capacity is impacted in the following way: the usable capacity is much less than the raw capacity somewhere between one third and one half of total raw capacity, depending on the number of ScaleIO servers and how much faults can be tolerated without data loss.

4.7.2.2 Hardware

Not applicable.

4.7.2.3 Implementation

Not applicable.

4.7.2.4 Interface

Not applicable.

4.7.2.4.1 API

Not applicable.

4.7.2.4.2 Man-Machine Interface (CLI)

ScaleIO GUI interface is added.

4.7.2.5 Obsolete Features

Not applicable.

4.8 Distributed Block Storage

4.8.1 Description

Distributed block storage is a new feature in CEE R6 that allows the implementation of Cinder functionality distributing and scaling the available local disk capacity using the EMC ScaleIO. EMC ScaleIO is a software only solution that utilizes local storage devices and turns them into shared block storage.

4.8.2 Impact

This is a new feature.

4.8.2.1 Capacity and Performance

ScaleIO System raw capacity can range between 300 GB and 16 PB. ScaleIO is using data mirroring in order to maintain data availability that could be cause by a single-point failure, so the usable capacity is half of the system raw capacity.

4.8.2.2 Hardware

The device size can be between 100 GB and 8 TB.

4.8.2.3 Implementation

CEE R6 supports a two layer architecture of ScaleIO. Dedicated blades are needed for the ScaleIO components without counting the already existing compute nodes in CEE. The deployment of ScaleIO is triggered automatically during CEE installation and it is configurable.

4.8.2.4 Interface

Details of interface changes are described in the following subsections.

4.8.2.4.1 API

CEE R6 uses REST API through HTTP(s) to communicate with the ScaleIO gateway.

4.8.2.4.2 Man-Machine Interface (CLI)

CEE R6 uses SCLI to interact with the ScaleIO components.

4.8.2.5 Obsolete Features

Not applicable.

4.9 Swift on VNX

4.9.1 Description

By default Glance is using Swift as storage backing and Swift store is located on the local disks of the CIC hosts. This storage has capacity limitations for Glance images. With this feature, capacity located on the VNX can be used for Swift store.

4.9.2 Impact

This is a new feature, re-introduced from CEE 15B.

4.9.2.1 Capacity and Performance

The capacity for Glance is increased. The performance of Glance on VNX, which implies a connection over the network , is a little bit slower than the performance of having Glance on the local disk, with direct access as it is attached to the host.

4.9.2.2 Hardware

EMC VNX.

4.9.2.3 Implementation

This feature can be automatically activated during installation of CEE if configured in config.yaml.

The feature can be manually activated, post installation, by following OIPs "Swift Store on VNX Activation" and "Swift store on VNX expansion"

4.9.2.4 Interface

Not applicable.

4.9.2.4.1 API

Not applicable.

4.9.2.4.2 Man-Machine Interface (CLI)

Not applicable.

4.9.2.5 Obsolete Features

Not applicable.

4.10 SR-IOV

4.10.1 Description

SR-IOV is a technology that allows the isolation of the PCI Express resources for manageability and performance reasons. SR-IOV allows different VMs to share a single PCI Express hardware interface (as of now, NIC). NIC is seen as Physical Function - it is shared between VMs, but still there is direct access to the network interface to enhance performance.

There are two types of SR-IOV:

SR-IOV flat - the virtual ports managed by Neutron can be configured to not provide VLAN segmentation
SR-IOV vlan - the virtual ports managed by Neutron can be configured to provide VLAN segmentation

4.10.2 Impact

In CEE R6 release support for SR-IOV vlan and SR-IOV flat on Dell and HDS is added. Also automated configuration for permanent SR-IOV support in the host operating system and at host network setup is added in this release.

Automated configuration for permanent SR-IOV support in the host operating system and at host network setup is added in this release.

Neutron APIs can be used to configure L2 connectivity between VMs using SR-IOV.

4.10.2.1 Capacity and Performance

There is no impact on capacity and performance compared to CEE 16A .

4.10.2.2 Hardware

There is no hardware impact.

4.10.2.3 Implementation

For information about the implementation of SR-IOV, refer to Configuration File Guide, r, OpenStack Networking API in CEE in Single Server Deployment, OpenStack Networking API in CEE in BSP Deployment and External Networking Connectivity for CEE Tenants in HP and Dell Multi-Server Deployment.

4.10.2.4 Interface

There is no impact on interfaces in CEE R6 release.

4.10.2.5 Obsolete Features

No information is available.

4.11 Bandwidth Management

4.11.1 Description

The Bandwidth Management feature provides the possibility to schedule VMs with respect to available network resources like bandwidth. Nova will ensure that the total amount of allocated bandwidth on an interface does not exceed the capacity of the interface

4.11.2 Impact

This feature was part of CEE 15B and it has been reintroduced in CEE R6.

4.11.2.1 Capacity and Performance

No impact on capacity and performance

4.11.2.2 Hardware

No impact on hardware.

4.11.2.3 Implementation

No information available at this moment.

4.11.2.4 Interface

No change has been introduced in the interface.

4.11.2.4.1 API

No change has been introduced in the interface.

4.11.2.4.2 Man–Machine Interface (CLI)

No change has been introduced in the interface.

4.11.2.5 Obsolete Features

No obsolete features to list.

4.12 Backup and Restore

4.12.1 Description

Backup and Restore in CEE R6 release consists of Fuel synchronization.

4.12.2 Impact

In CEE R6 release the fuel backup and restore mechanism is replaced by manual fuel synchronization mechanism. The active Fuel VM is synchronized to the cold stand-by Fuel. The user is able to restore vFuel using a manual procedure from a VM image.

4.12.2.1 Capacity and Performance

No information is available at this point.

4.12.2.2 Hardware

Backup and Restore is not applicable for Single Server deployment.

4.12.2.3 Implementation

No configuration changes are necessary to implement this feature.

4.12.2.4 Interface

4.12.2.4.1 API

There is no API interface of Backup and Restore features.

4.12.2.4.2 Man–Machine Interface (CLI)

There is no impact on CLI in this release.

4.12.2.5 Obsolete Features

Fuel backup and restore is not supported anymore being replaced by fuel synchronization.

CEE infrastructure backup is removed in CEE R6 release.

4.13 Resource Management for Virtual Machines

4.13.1 Description

The Resource Management for Virtual Machines feature includes the following:

Handling of NUMA architecture for memory allocation and huge pages memory backing for VMs
Handling of NUMA architecture for CPU allocation and CPU pinning for VMs
Exposure of NUMA/CPU topology to guest OS

4.13.2 Impact

The implementation of features related to the Resource Management for Virtual Machines is changed due to the use of OpenStack Mitaka in CEE R6. The main changes are as follows:

Hypervisor support for NUMA .

4.13.2.1 Capacity and Performance

The performance of virtualized guests is improved. Guests can be optimized to use specific NUMA nodes when provisioning resources. By exposing NUMA topology to the VM and pinning vCPU to specific core it is possible to improve VM performance by ensuring that access to memory will always be local in terms of NUMA topology.

4.13.2.2 Hardware

There is no hardware impact of this feature.

4.13.2.3 Implementation

For information about allocation of RAM and CPU during installation of CEE, refer to Configuration File Guide.

4.13.2.4 Interface

No change has been introduced in the interface

4.13.2.4.1 API

No change has been introduced in the interface. .

4.13.2.4.2 Man–Machine Interface (CLI)

No change has been introduced in the interface .

4.14 CEE Reference Configurations

4.14.1 Description

Cloud Execution Environment provides Certified and Reference Configurations which includes:

End-to-end pre-tested and verified fully redundant configuration
Automated installation and configuration enabling fast and accurate installation of a cloud environment, including Equipment Management
OpenStack drivers (Neutron ML2, Neutron L3 for Extreme ToR switches, Cinder driver (for EMC VNX) and automatic configuration of ToR switch within installation.

CEE is certified on HDS, BSP 8100 (GEP5, GEP7) and HP c7000 and Dell R630 Single Server deployment as Compute HW and has Dell R630 Multi-Server deployment as reference configuration. For HP and Dell certified configuration includes Extreme X460 as control switches, and EMC VNX 5400 as centralized storage.

4.14.2 Impact

In CEE R6 release, support for CEE on HDS is added. HDS reference configuration has the following components:

Dell R630 server system
Pluribus E28 network switches
Juniper EX3300 control network switches.

The templates for all files (config.yaml, configuration, switching scheme and cabling scheme YAML files) are updated and must be used when preparing deployment specific configuration files.

4.14.2.1 Capacity and Performance

Not applicable.

4.14.2.2 Hardware

The requirements of Kickstart Server has changed due to vFuel running on Kickstart Server at the time of CEE installation. Two NICs needs to be used on Kickstart Server for installation of CEE on BSP HW. Refer to Preparation of Kickstart Server for details.

4.14.2.3 Implementation

CEE installation flow is described in CEE Installation document

4.14.2.4 Interface

Information on impact is given in subsections below

4.14.2.4.1 API

There is no API interface related to this feature

4.14.2.4.2 Man–Machine Interface (CLI)

There are changes in commands used within installation related to deployment and migration of vFuel

4.15 Equipment Management

4.15.1 Description

The Equipment Management feature allows the replacement of servers and ToR switches used in CEE.

4.15.2 Impact

Documents on the expansion and replacement or repair have been updated. A new procedure for Swift Store on VNX expansion is available. .

4.15.2.1 Capacity and Performance

Not applicable.

4.15.2.2 Hardware

Not applicable.

4.15.2.3 Implementation

Not applicable.

4.15.2.4 Interface

Not applicable.

4.15.2.4.1 API

There is no API interface of this feature.

4.15.2.4.2 Man–Machine Interface (CLI)

Procedure for Swift Store on VNX expansion is added.

4.15.2.5 Obsolete Features

There are no obsolete features due to this feature.

4.16 Centralized Identity Management

4.16.1 Description

The purpose of Identity and Access Management (CEE IdAM) is to manage identities and credentials for cloud users, and to provide authentication and access control services for user accesses.

4.16.2 Impact

No information available yet.

4.16.2.1 Capacity and Performance

No information is available.

4.16.2.2 Hardware

There is no hardware impact.

4.16.2.3 Implementation

Refer to Security User Guide and Configuration File Guide for information about the implementation of iDAM.

4.16.2.4 Interface

No information is available.

4.16.2.4.1 API

There is no API of this feature.

4.16.2.4.2 Man–Machine Interface (CLI)

There is no impact on CLI in this release.

4.16.2.5 Obsolete Features

No information is available.

4.17 Ericsson Neutron

4.17.1 Description

Ericsson Neutron provides most of the functionality provided by OpenStack Neutron. The following functionality is added in CEE R6 release:

flat networking with Neutron SR-IOV
VLAN-based Neutron SR-IOV by uplift to Mitaka
Neutron DHCP service handled by the CSC SDN controller for SDN deployments, for non SDN deployments DHCP service is provided under the supervision of the neutron-dhcp-agent
CEE provides a performant implementation for the security group and allowed address pair APIs in form of CSS4

4.17.2 Impact

The impact is listed below:

Changes in Ericsson Neutron are related to changes in OpenStack Mitaka, see sections below for more information on documentation
In CEE R6, security group and allowed address pair APIs are supported, their functionality is subject to the firewall driver chosen during deployment time
Trunk port v1 API is deprecated in this release. This API is fully supported in this release but will be discontinued in the following CEE releases as it will be replaced by trunkport v4 API. There are no plans for CEE to support both versions of this API in parallel.

4.17.2.1 Capacity and Performance

For this feature, there is no impact on capacity and performance in this release.

4.17.2.2 Hardware

There is no hardware impact.

4.17.2.3 Implementation

Description of certain Neutron configuration information is covered in Configuration File Guide.

4.17.2.4 Interface

4.17.2.4.1 API

Changes in API are related to the support of API provided by Neutron in OpenStack Mitaka, refer to OpenStack Networking API in CEE in HP and Dell Multi-Server Deployment, OpenStack Networking API in CEE in Single Server Deployment and OpenStack Networking API in CEE in BSP Deployment.

4.17.2.4.2 Man–Machine Interface (CLI)

Changes in CLI correspond to changes in the API specified above.

4.17.2.5 Obsolete Features

There are no obsolete features in this release related to Ericsson neutron.

4.18 Continuous Monitoring High Availability (CM-HA)

4.18.1 Description

CM-HA is a functionality that periodically checks the status of Compute Hosts, vCIC nodes and Fuel.

CM-HA issues alarms related to the failure of vCIC, Compute Host (including VM-related alarms) and Fuel and provides alerts on restart of these components.

If Compute Host is detected to have failed, then CM-HA initiates either of the following, depending on the HA-policy of VM:

Evacuation of the VMs from the affected Compute Host
Restart of the VM on the same Compute Host
No actions are performed in case there is no policy defined

In all 3 cases there are certain alarms triggered by CM-HA.

4.18.2 Impact

The impact related to CM-HA in this release is as follows:

CM-HA fencing is introduced - when a compute node is detected faulty by CM-HA , the failure of the control network will not cause duplication of tenant VMs, when they are evacuated by CM-HA.
CM-HA fencing is configurable and can be turned off, please see Configure File Guideline.

4.18.2.1 Capacity and Performance

There is no impact of this feature on capacity and performance.

4.18.2.2 Hardware

There is no impact of this feature on hardware.

4.18.2.3 Implementation

There are no specific steps related to the implementation of CM-HA feature in general. VMs must have metadata defined to use CM-HA.

4.18.2.4 Interface

4.18.2.4.1 API

The HA Policy can be set in the metadata of the VM, for example:

ha-policy=unmanaged
ha-policy=managed-on-host
ha-policy=ha-offline

The above HA policies replace the following removed evacuation policies: NoEvacuation and Evacuation. Refer to OpenStack Compute API in CEE for details.

4.18.2.4.2 Man–Machine Interface (CLI)

The changes in the CLI correspond to the changes in the API described above.

4.18.2.5 Obsolete Features

Following evacuation policies have been removed: NoEvacuation and Evacuation.

4.19 Performance Management

4.19.1 Description

Performance Management is a feature that includes the collection of performance data related to virtual resources (by Ceilometer), on host environment (by Zabbix), and providing this data through Northbound interfaces including. This functionality provides 3GPP compliant XML report files and access via REST API.

4.19.2 Impact

There is impact on this feature in this release due to openstack uplift to Mitaka.

New counters are added that are related to SDN.

4.19.2.1 Capacity and Performance

There is no impact on Capacity and Performance in this release

4.19.2.2 Hardware

Ceilometer is not implemented in Single Server solution.

4.19.2.3 Implementation

There are no specific implementation steps for this feature.

4.19.2.4 Interface

4.19.2.4.1 API

Refer to OpenStack Telemetry API in CEE, Preconfigured Key Performance Indicators and section titled Telemetry API in OpenStack API Complete Reference.

4.19.2.4.2 Man–Machine Interface (CLI)

There is on impact on this feature in this release.

4.19.2.5 Obsolete Features

There are no obsolete features or functionality related to this feature.

4.20 Fault Management

4.20.1 Description

The Fault Management feature provides alarms and alerts from different software and hardware components used in the CEE Region. Fault Management provides REST API and SNMP as northbound interfaces.

4.20.2 Impact

There is a new feature in CEE R6 related to fault management. It is possible to filter the alarms based on tenant.

4.20.2.1 Capacity and Performance

There is no impact on capacity and performance.

4.20.2.2 Hardware

There is no hardware impact.

4.20.2.3 Implementation

Fault Management Northbound API Interwork Description and Fault Management Configuration Guide User Guide describes implementation of Fault Management.

4.20.2.4 Interface

Impact on interface is described in subsections below.

4.20.2.4.1 API

There is no API interface changes in this release.

4.20.2.4.2 Man–Machine Interface (CLI)

There is functionality to get alarm and alert history using CLI client of Watchmen (watchmen-client alarm-history )

4.20.2.5 Obsolete Features

There are no obsolete features related to this feature.

4.21 Upgrade And Rollback

4.21.1 Description

Upgrade (update) and Rollback features allows to perform SW upgrade/update of CIC nodes, Compute Hosts and Fuel.

Major version upgrade from CEE 16A or earlier product versions is not supported.

4.21.2 Impact

No information is available yet.

4.21.2.1 Capacity and Performance

No information is available yet.

4.21.2.2 Hardware

There is no hardware impact.

4.21.2.3 Implementation

There is no specific configuration to implement this feature.

4.21.2.4 Interface

4.21.2.4.1 API

There is no API of this feature.

4.21.2.4.2 Man–Machine Interface (CLI)

Commands to implement update and rollback are changed, refer to CEE SW Update and Rollback

4.21.2.5 Obsolete Features

There are no obsolete features related to this feature.

4.22 Security and Audit Trail Logging

4.22.1 Description

The audit trail log contains detailed information about system configuration changes. This audit tool enables the service provider to check who carried out specific operations in the system, and when.

The security log records security events on the node. The purpose of this is to record security events, for example, failed logins and attempts to access the node with valid or invalid credentials.

4.22.2 Impact

There is no information available at this time

4.22.2.1 Capacity and Performance

There is no impact on capacity and performance due to this feature.

4.22.2.2 Hardware

There is no hardware impact.

4.22.2.3 Implementation

The configuration of this functionality is included in the template config.yaml and does not need to be changed in almost all cases.

4.22.2.4 Interface

4.22.2.4.1 API

Not applicable.

4.22.2.4.2 Man–Machine Interface (CLI)

Not applicable.

4.22.2.5 Obsolete Features

There are no obsolete features in relation to this feature

5 Ericsson Atlas

5.1 OpenStack Mitaka

5.1.1 Description

Ericsson Atlas includes OpenStack Mitaka release and Openstack heat and horizon services, that are part of Atlas, are uplifted to Mitaka as a consequence.

5.1.2 Impact

There is no impact for this feature in this release.

5.1.2.1 Capacity and Performance

The performance of Heat operations is improved due to improvements in heat-engine in OpenStack Mitaka.

5.1.2.2 Hardware

There is no hardware impact.

5.1.2.3 Implementation

For information of the implementation of Atlas, refer to Atlas SW Installation.

5.1.2.4 Interface

5.1.2.4.1 API

Refer to the OpenStack Heat Interwork Description for details on the Heat template.

5.1.2.4.2 Man–Machine Interface (CLI)

Generic OpenStack CLI client is present in Atlas. In this release OpenStack CLI client is only to be used for functionality provided by Keystone.

The Graphical User Interface (GUI) of Atlas is based on OpenStack dashboard (Horizon). For the Atlas GUI please see following documents: Atlas Dashboard End User Guide and Atlas Dashboard Administrator User Guide

5.1.2.5 Obsolete Features

There are no obsolete features related to this feature

5.2 OVFT

5.2.1 Description

Ericsson Atlas includes Ericsson OVF Translation (OVFT) component that allows use of OVF (OVF 2.1) format for VNF deployment via translation to Heat Orchestration Template (HOT) format.

5.2.2 Impact

In Atlas for CEE R6 the CMHA metadata has been changed , for more details please see Atlas OVF to HOT Mapping and Atlas OVFT API.

5.2.2.1 Capacity and Performance

There is no capacity or performance impact for this feature in this release.

5.2.2.2 Hardware

There is no hardware impact.

5.2.2.3 Implementation

OVFT is included in Ericsson Atlas

5.2.2.4 Interface

5.2.2.4.1 API

For Open Virtualization Format Translator (OVFT) API, refer to Atlas OVF to HOT Mapping and Atlas OVFT API.

5.2.2.4.2 Man–Machine Interface (CLI)

See Atlas CLI End User Guide for CLI interface of OVFT.

5.2.2.5 Obsolete Features

There are no obsolete features related to this feature

5.3 Application Template Export

5.3.1 Description

Application Template Export enables the user to export application templates in OVF or HOT format from Atlas.

5.3.2 Impact

There is no impact on this feature in this release.

5.3.2.1 Capacity and Performance

There is no impact on capacity and performance related to this feature.

5.3.2.2 Hardware

There is no hardware impact.

5.3.2.3 Implementation

There are no specific implementation procedures for this feature.

5.3.2.4 Interface

There is no impact on the interface for this feature.

5.3.2.4.1 API

Orchestration API is supported according to release of OpenStack Mitaka of Heat component, refer to Openstack Orchestration API in CEE and chapter Orchestration API in OpenStack API Complete Reference.

This functionality is supported with OVFT API, refer to Atlas OVFT API.

5.3.2.4.2 Man–Machine Interface (CLI)

There are new commands to support Application Template Export, refer to Atlas CLI End User Guide.

5.3.2.5 Obsolete Features

There are no obsolete features related to this feature.

5.4 Multi-Region Dashboard and Placement Zones

5.4.1 Description

Atlas enables support of multiple CEE Regions — it can manage the configuration and provide a common dashboard for a group of sites or regions.

5.4.2 Impact

In Atlas for CEE R6 there is a change related to filters used in compute environment, server groups filters are used instead of same host/different host filters. .

5.4.2.1 Capacity and Performance

There is no impact on capacity and performance related to this feature.

5.4.2.2 Hardware

There is no hardware impact.

5.4.2.3 Implementation

Refer to Atlas Multi-Region Configuration User Guide for details on how to implement this feature.

5.4.2.4 Interface

There is no impact in interface due to this feature.

5.4.2.4.1 API

Not applicable.

5.4.2.4.2 Man–Machine Interface (CLI)

Not applicable.

5.4.2.5 Obsolete Features

There are no obsolete features in relation to this feature.

5.5 On-Demand Application Scaling

5.5.1 Description

In addition to Heat-based Autoscaling, it is possible to perform scale in and scale out on application demand.

5.5.2 Impact

There is no impact in this release for this feature.

5.5.2.1 Capacity and Performance

There is no impact on capacity and performance due to this feature.

5.5.2.2 Hardware

There is no hardware impact due to this feature.

5.5.2.3 Implementation

There are no specific steps to implement this feature.

5.5.2.4 Interface

5.5.2.4.1 API

Refer to Atlas OVFT API for information on API of this feature.

5.5.2.4.2 Man–Machine Interface (CLI)

Refer to Atlas CLI End User Guide for information on how to use this feature using CLI.

5.5.2.5 Obsolete Features

There are no obsolete features in relation to this feature.

5.6 TOSCA support

5.6.1 Description

Topology and Orchestration Specification for Cloud Applications (TOSCA) provides an interoperable description of services and applications hosted on the cloud and elsewhere, including their components, relationships, dependencies, requirements, and capabilities. The support of TOSCA format complements the support of OVF and HOT formats in Atlas

5.6.2 Impact

This is a new feature.

5.6.2.1 Capacity and Performance

There is no impact on capacity and performance due to this feature.

5.6.2.2 Hardware

There is no hardware impact due to this feature.

5.6.2.3 Implementation

There are no specific steps to implement this feature.

5.6.2.4 Interface

Information on interface impact is provided below.

5.6.2.4.1 API

Refer to Atlas OVFT API for information on API of this feature.

5.6.2.4.2 Man–Machine Interface (CLI)

Refer to Atlas CLI End User Guide for information on how to use this feature using CLI.

5.6.2.5 Obsolete Features

There are no obsolete features in relation to this feature.

5.7 Mistral support deployment

5.7.1 Description

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. One can describe such process as a set of tasks and task relations and upload such description 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 we can run a process according to a specified schedule (i.e. every Sunday at 4.00pm) instead of running it immediately. We call such set of tasks and relations between them a workflow.

In CEE R6 releases we use the vanilla Mistral implementation of Mitaka openstack release. For more information please see Mistral OpenStack Documentation at http://docs.openstack.org/developer/mistral/.

5.7.2 Impact

This is a new feature.

5.7.2.1 Capacity and Performance

There is no impact on capacity and performance due to this feature.

5.7.2.2 Hardware

There is no hardware impact due to this feature.

5.7.2.3 Implementation

There are no specific steps to implement this feature.

5.7.2.4 Interface

Information on interface impact is provided below.

5.7.2.4.1 API

Refer to Atlas OVFT API for information on API of this feature.

5.7.2.4.2 Man–Machine Interface (CLI)

Refer to Openstack Mistral CLI for information on how to use this feature using CLI.

Refer to Atlas Dashboard End User Guide Openstack Mistral CLI for information on how to use this feature using GUI.

5.7.2.5 Obsolete Features

There are no obsolete features in relation to this feature.

5.8 Deployment Wizard

5.8.1 Description

Deploy wizard allows user to update following options for server resources in HOT template stored in Catalog before deploying stack:

user data
metadata
file injection
availability zone
extra_specs for flavor or use of existing flavor

5.8.2 Impact

This is a new feature.

5.8.2.1 Capacity and Performance

There is no impact on capacity and performance due to this feature.

5.8.2.2 Hardware

There is no hardware impact due to this feature.

5.8.2.3 Implementation

There are no specific steps to implement this feature.

5.8.2.4 Interface

Information on interface impact is provided below.

5.8.2.4.1 API

Refer to Atlas OVFT API for information on API of this feature.

5.8.2.4.2 Man–Machine Interface (CLI)

Refer to Atlas CLI End User Guide for information on how to use this feature using CLI.

5.8.2.5 Obsolete Features

There are no obsolete features in relation to this feature.

5.9 Enhanced Stack Panels

5.9.1 Description

The enhanced stack panels feature provides the possibility to display stacks overview, topology, resources and events page for better understanding of resource usage for a stack deployed.