Management Mechanisms Early Release - UNICORN...

D3.1 Orchestration & Resource Management Mechanisms – Early Release

1

Orchestration & Resource Management Mechanisms Early Release

Deliverable D3.1

Editors Giannis Ledakis Reviewers Julia Vuong (CAS)

Sotiris Koussouris (SUITE5) Date 10 May 2018 Classification Confidential


2

Contributing Author # Version History

Name Partner Description

Giannis Ledakis UBI 1 Table of Contents (ToC) and partner

contribution assignment.

Giannis Ledakis UBI 2 Drafts for Sections 2, 3 and 4

Armend Duzha Maggioli 3 Resource Manager (section 3 input)

Giannis Ledakis, Panagiotis

Gkouvas, Konstantinos

Theodosiou

UBI 4 Final input for section 4 and draft of section 5

Giannis Ledakis, Anastasios

Zafeiropoulos UBI 5 Final input for sections 4 and 5

Julia Vuong , Sotiris Koussouris CAS,Suite5 6 First Review of the Document on a pre-final

draft

Giannis Ledakis UBI 7 Amendments and final version provided

Julia Vuong , Sotiris Koussouris CAS,Suite5 8 Second Review of the Document

Giannis Ledakis UBI 9 Document ready for submission


3

Contents

CONTENTS 3

1 INTRODUCTION 8

1.1 Document Purpose and Scope 10

1.2 Document Relationship with other Project Work Packages and Deliverables 10

1.3 Document Structure 11

2 STATE OF THE ART AND KEY TECHNOLOGY AXES CHALLENGES 12

2.1 Multi Cloud Orchestration and Virtualized Resource Management 12

2.1.1 Containers orchestration 12

2.1.2 Lifecycle and Controlled States as part of the Orchestration Process 14

2.2 Service Deployment Optimization 14

3 MULTI CLOUD RESOURCE MANAGER 16

3.1 Requirements and User Roles 16

3.1.1 Functional Requirements 16

3.1.2 Non-Functional Requirements 18

3.2 Reference Architecture and Implementation 19

3.3 Interaction with other Unicorn Services and Components 21

4 UNICORN CLOUD ORCHESTRATOR 24





4.2.1 Virtual Machines of Unicorn Cloud Orchestrator 27

4.2.2 Unicorn Orchestrator Controlled States and Controllers 28


5 POLICIES MANAGER AND ENFORCER (POLICY ENGINE) 31






6 OPTIMIZATION ENGINE 40




4




7 CONCLUSIONS 45

8 REFERENCES 46


5

List of Figures

Figure 1: Unicorn Reference Architecture (the components of the mechanisms described in this deliverable

are highlighted) 9

Figure 2: CoreOS Host and Relation to Docker Containers 13

Figure 3: High-Level Overview of Unicorn Orchestration (Resource Manager related parts are highlighted and

shown with arrows) 19

Figure 4: IaaS Providers List in the early release of Resource Manager 20

Figure 5: Registration of new IaaS 21

Figure 6: Configuration of Swagger the Spring boot based application of Resource Manager 22

Figure 7: A sample of Resource Manager Swagger documentation using Swagger and Swagger UI 23

Figure 8: High-Level Abstract Overview of Unicorn Orchestration (Cloud Orchestrator parts are highlighted

and shown with arrow) 26

Figure 9: Representation of a Microservice VM 27

Figure 10: Representation of a deployed component Life-cycle 29

Figure 11: Representation of a deployed application Life-cycle 30

Figure 12: High-Level Overview of Unicorn Orchestration (Mechanisms involved in the Policy Enforcement are

highlighted and shown with arrow) 33

Figure 13: Representation of abstract Policy Engine 33

Figure 14: Representation of the components deployed in the MasterVM 34

Figure 15:Representation of detailed architecture of Policy Engine (Master Node and micro-service node) 35

Figure 16: DroolsService Interface 36

Figure 17: Representation of rule (if CPU Load > 80% ) 36

Figure 18: Prometheus Sample Query 37

Figure 19: Representation of input data (facts) 38

Figure 20: Adding Facts using Prometheus 38

Figure 21: Drools pattern matching execution 39

Figure 22: Optaplanner Constraint Satisfaction Solver 43

Figure 23: Problem Definition 44

List of Tables

No table of figures entries found.


6

Executive Summary

The goal of this deliverable is to provide a comprehensive overview and documentation report for the early

release of the Multi-cloud Orchestrator and the Optimization, Policies and Resources Manager. These

mechanisms are developed as part of Work Package 3 (WP3) and together they provide the main outcome of

this Work Package that is the Unicorn’s Policy-Aware, Multi-Cloud Orchestrator.

This deliverable builds on the Unicorn Deliverable D1.2[1] and for this reason is starts by providing a short update

on the related technologies and the challenges that were identified as part of WP3 effort so far, and the same

time by continuing with the exercise of deriving some more precise requirements for the components

comprising the Unicorn Orchestration and Resource Management Mechanisms.

Each of the four main mechanisms of the Unicorn’s Policy-Aware, Multi-Cloud Orchestrator (Unicorn Cloud

Orchestrator, Multi-Cloud Resource Manager, Policy Manager and Optimization Manager) are described in the

document with focus provided on the reference architecture, the technologies used and the implementation

aspects.

As this document provides a snapshot of the development process and an early release of the components

developed in the scope of WP3, it has to be clarified that components are at different levels of maturity.

Nevertheless, the components are at such maturity levels that they allow for their implementation which will

be in turn result in the first prototype release of the Unicorn Platform.


7

Table of Abbreviations

API Application programming interface

AWS Amazon Web Services

BRMS Business Rules Management System

IaaS Infrastructure as a Service

LXC Linux Containers

MRGQAP Multi-Resource Generalised Quadratic Assignment Problem

OASIS Organization for the Advancement of Structured Information Standards

OS Operating System

QoS Quality of Service

REST Representational State Transfer

SDN Software-Defined Networking

UFP Unsplittable Flow Problem

VDC Virtual Data Center

VDCE Virtual Data Center Embedding

VN Virtual Network

VNE Virtual Network Embedding

XML eXtensible Markup Language


8

1 Introduction The goal of this deliverable is to provide a comprehensive overview and documentation report for the early

release of the Unicorn’s Policy-Aware Multi-Cloud Orchestrator. This orchestrator is the main outcome of Work

Package 3 (WP3) and it is composed of a Multi-Cloud Resource Manager, the Unicorn Cloud Orchestrator, a

Policy Manager and finally an Optimization Manager. These mechanisms correlate with the tasks of the T3.1 -

T3.3 of the WP3. In specific Task 3.1 -Cloud Computing Resource Manager is responsible for the design and

implementation of the resource manager, Task 3.2-Operational Policies Manager is responsible for the design

and implementation of the operational policies manager thus responsible for the definition and enforcement of

policies and Task 3. 3 Multi-cloud Orchestrator and Optimization Manager to design and develop the runtime

application orchestrator for multi-cloud environments and the optimization manager that helps on achieving

optimal configuration of the deployed application.

This deliverable acts as the logical continuation of Unicorn Deliverable D1.2[1] and for this reason is starts by

providing a short update on the related technologies and the challenges that were identified as part of WP3

effort so far, and the same time by continuing with the exercise of deriving some more precise requirements for

the components comprising the Unicorn Orchestration and Resource Management Mechanisms.

Each of the four main mechanisms of the Unicorn’s Policy Aware Multi-Cloud Orchestrator (Unicorn Cloud

Orchestrator, Multi-Cloud Resource Manager, Policy Manager and Optimization Manager) are described in the

document with focus provided on the reference architecture, the technologies used and the implementation

aspects. The Multi-Cloud Resource Manager is responsible for on-boarding new IaaS resources and continuously

reporting their availability. OpenStack, Google Cloud Platform and Amazon Web Service support is provided.

The Orchestrator is responsible for the creation of the deployment artefacts that are needed for each service

defined in the Unicorn compose file and orchestrate the deployment and management of them on IaaS

resources. As it will be explained in the remainder of the deliverable, Unicorn relies on Docker containerization

technologies in order to bundle stateless services and create the appropriate scalable-by-design microservices.

The Policies Manager and Enforcer that hence is also called Policy Engine for simplicity is responsible for the

enforcement of the policies defined by the developer of a Unicorn microservice. The Optimization Manager is

responsible for suggesting the optimal deployment configuration or re-configuration based on predefined

placement constraints.

As this document provides a snapshot of the development process and an early release of the components

developed in the scope of WP3, it has to be clarified that not all components are at the same level of maturity,

but the early implementation of these components will be used for the creation of the first prototype release of

the Unicorn Platform.

The figure below illustrates a high-level overview of the Unicorn Reference Architecture as it was defined in

D1.2[1]. The mechanisms implemented in WP3 are actually covering part of this architecture in the layers of the

Unicorn Platform and the Multi-Cloud Execution Environment.


9

Figure 1: Unicorn Reference Architecture (the components of the mechanisms described in this deliverable are highlighted)

The highlighted components in the previous figure are mapped to the mechanisms of Multi-Cloud Resource

Manager, the Unicorn Cloud Orchestrator, Policy Manager and the Optimization Manager as follows.


10

• Multi-Cloud Resource Manager: Resource Manager, Cloud Offerings Manager, Network Overlay

Manager, Platform Administration Database

• Unicorn Cloud Orchestrator: Application Lifecycle Manager, and the whole part of the application

deployment in the multi-cloud execution environment (VM deployment with appropriate OS,

installation of agents to the VM, installation of Docker engine, deployment of the components of the

containerized microservice application)

• Policies Manager: Deployment Policies Manager and Run-time Policies and SLA Enforcement

• Optimization Manager: Deployment Policies Manager and Application Placement Optimization

It is also important to remind that in D1.2 we defined the term Unicorn microservice as a chainable, horizontally

and vertically scalable-by-design, stateless service, which is adaptive to the underlying resources while

exposing a clear configuration and lifecycle management API. Unicorn microservices can be deployed at a

Multi-Cloud Execution Environment which consists of the following: i) resources (CPU, memory, network,

storage etc.) in the form of VMs bound on the infrastructure of multiple cloud providers and/or availability zones

and regions, ii) an overlay cross-cloud networking fabric, iii) a lightweight operating system, iv) a container

engine and v) a container management and orchestration tool.

1.1 Document Purpose and Scope

The purpose of this deliverable is to provide a comprehensive overview and documentation report of the early

release of the of Unicorn policy-aware orchestrator that allows the deployment and management of

microservice based applications on top of multi-cloud execution environments. In respect to this, D3.1 provided

an overview of the early design and development of the four mechanisms developed in WP3 comprising the

Unicorn policy-aware, multi-cloud orchestrator: (i) the Multi-Cloud resource manager; (ii) the Cloud

Orchestrator; (iii) the Policy Manager; and (iv) the Optimization Manager. D3.1 documents for each component,

the updated requirements that must be satisfied in order to cover fully the Unicorn use cases. It also provides

the components’ functionalities, their reference architecture and finally the other components that need to be

interact in order to offer the needed capabilities.

Finally, the Deliverable concludes and outlines the work to be conducted towards introducing D3.2 that will

assess the accomplishment of the requirements, features and toolsets introduced in this deliverable and will

provide the final documentation of the Unicorn Orchestration and Resource Management mechanisms.

1.2 Document Relationship with other Project Work Packages and Deliverables

For the design and implementation of the mechanisms described in this deliverable, but also for the creation of

this deliverable, the work done in WP1 and was document in deliverables D1.1[2] and D1.2[1] provided the initial

basis. For this reason, this deliverable tries to provide more details and update some of the aspects delivered

in these two documents. In specific, D1.1[2] defines the requirements that define the functionalities of the

components. The exercise to further analyse the user role needs, the use cases and provide refined additional

requirements has been done in this deliverable in order to guide with more precision the design and

implementation of the corresponding mechanisms. D1.2[1] defined the overall architecture that outlines the

interplay of the components and also the defined use cases to be covered. As part of the work done in WP3 it

was important to continue on the foundation of this architecture when developing the mechanisms that create

the Unicorn’s Policy-Aware, Multi-Cloud Orchestrator. Another important deliverable for the work done in scope


11

of WP3 is deliverable D2.1[3] for the model definition that provides the way that an application can defined as

scalable microservice is deployed and orchestrated by Unicorn.

Furthermore, the deliverable is the early version of D3.2 that will assess the accomplishment of the

requirements, features and toolsets introduced in this deliverable and will provide the final documentation of

the Unicorn Orchestration and Resource Management mechanisms.

1.3 Document Structure

The rest of this deliverable is structured as follows:

Section 2 presents the updated view of the D1.2[1] description of the key technology axes that are covered in

order to implement the mechanisms of WP3.

Sections 3-6 provide a comprehensive documentation of the mechanisms of Unicorn’s Policy-Aware, Multi-

Cloud Orchestrator. In each of these sections a high-level description of the mechanism is provided, as well as

refined requirements and details about the mechanism architecture and implementation. Section 3 refers to the

Multi-Cloud Resource Manager, section 4 to the Unicorn Cloud Orchestrator, section 5 to the Policy Manager

and Enforcer (hence Policy Engine), and finally section 6 to thee Optimization Manager (hence Optimization

Engine).

Section 7, concludes this Deliverable and outlines the work to be conducted towards introducing D3.2.


12

2 State of the Art and Key Technology Axes Challenges The aim of the Unicorn project is to empower the European digital SME and Startup eco-system by delivering a

novel and unified framework that simplifies the design, deployment and management of secure and elastic-by-

design cloud applications that follow the micro-service architectural paradigm and can be deployed over multi-

cloud programmable execution environments. In respect to this, deliverable D1.2[1], introduced the key

technology axes where focus is devoted to defining a clear reference guide of the Unicorn Framework

Architecture and its comprising components along with how each component intercommunicates to achieve

the project business objects that will satisfy the demanding target audience it adheres too. Here we are offering

a short description of the research outcomes related to WP3 and this specific deliverable, in order to provide

better understanding of the deliverable and also to update the findings for the specific topics covered in this

deliverable.

2.1 Multi Cloud Orchestration and Virtualized Resource Management

Infrastructure in computing refers to resources which can be virtual or physical and include computing, storage

and networking resources. In the scope of Unicorn, we consider the usage of virtualized resources that are

offered for lease by the infrastructure provider and can be used by the service developers. Moreover, as the

focus of the project is towards the deployment of scalable services towards a multi-cloud environment, we need

to invest on technologies that can enable the easy, fast and secure deployment over virtualized infrastructure.

Under the perspective of the microservice architectural paradigm and within the Unicorn context, modern cloud

applications should incorporate portability and interoperability features. Therefore, for Unicorn it is important

to provide portability and interoperability and enable multi-cloud deployments. As each provider promotes its

own cloud infrastructure, features, standards and formats to access the cloud in a unique and differentiated

way from others, this prevents cloud application developers to compose a heterogeneous context of multiple

cloud platforms and offerings to deploy their cloud applications. In D1.2[1] also the issues regarding Portability,

Interoperability and Management have been covered in terms of the state of the art analysis.

Therefore, multi-cloud deployment and orchestration capabilities are also needed in order to support the vision

of Unicorn for containerized execution environments that addresses both data portability and interoperability

issues, and at the same time multi-cloud deployment and orchestration support. In addition, cloud applications

should be adaptable during runtime and it should be possible to retrieve real-time measurements of resource

consumption. Part of the Unicorn project is to provide the means to realize cloud application monitoring, auto-

scaling and management in multi-cloud execution environments. To achieve this, Unicorn is suggesting a

combination of containerized applications paradigm and usage of virtualized multi-cloud infrastructure.

2.1.1 Containers orchestration

Among the multiple container technologies that have emerged, the one with the biggest market share and the

widest adoption is Docker [4]. In deliverable D1.2 [1], Docker has been extensively described. In short, Docker is

the industry standard container platform built on top of Linux kernel, namespaces, cgroups, chroot, and file

system constructs. Docker provides additional tooling and a platform to manage the lifecycle of containers with

the most notable ones including the Docker Engine, the Docker Swarm and the Docker Compose.

With usage of containers like Docker, all containers on a given host run under the same kernel, with only

application resources isolated per container. This improves security by isolation and making the host OS daemon

managing co-located containers one of the remaining critical points, as it is an attacking surface for exposed


13

vulnerabilities [5]. To improve isolation by providing secure containerization, and still adhere to the Linux kernel

principles, CoreOS Container Linux, depicted in Figure 2, was designed to alleviate and improve many of the

flaws inherent in Docker's container model [5]. In particular, CoreOS is a lightweight Linux operating system

designed for clustered deployments providing automation, security, and scalability. In Unicorn we will follow

the strict rule of having only one container per VM instance, in order to increase security and also to increase

the resilience and the scalability of the application.

Figure 2: CoreOS Host and Relation to Docker Containers

For the deployment and orchestration of containers, frameworks such as Docker Swarm [6], Kubernetes [7] or

even Apache Mesos [8] and OpenStack[9] can be used for the management of clusters based on containers.

Apache Mesos does not support provisioning of containerized resources but Docker Swarm and Kubernetes

allow the definition of initial container deployment and also the management of multiple containers as one

entity, for purposes of availability, scaling, and networking. However, neither of these solutions are taking into

account the resources management, as they are not aware of the available resources at the infrastructure level.

One of the newer findings of the research and design activities performed in WP3, was that it is possible to use

OpenStack along an LXC hypervisor with in order to deploy LXC containers. Although this can be a good option

in terms of ease and performance in development environments, however it lacks the level of isolation that is

provided by the usage of VMs [10], therefore we consider the approach of using lightweight VM images and

Docker containerization to be better suited for usage by SMEs’ services in production. Also, it has to be stated

that some of OpenStack Compute features might be missing when running with LXC as the hypervisor [11] , and

finally that choosing such a solution would limit the interoperability aspects of Unicorn as it would imply the

usage of OpenStack based IaaS offerings.

In Unicorn, one of the goals is to allow the definition of applications using the microservice paradigm, and then

provision of the microservice in a pool of available resources. This provisioning process however is not possible

to be performed using Docker Compose or Kubernetes, as these frameworks are unaware of the available

resource pool. For this reason, Unicorn will develop a dedicated orchestration that is using the best practices of

Kubernetes and also some of the findings and the lessons learnt of the ARCADIA orchestrator [12], in order to

produce the Unicorn Orchestrator that supports the provision, configuration and management of containerized

applications in multiple cloud infrastructure.


14

2.1.2 Lifecycle and Controlled States as part of the Orchestration Process

One of the important aspects of the orchestrator development is to properly define and control the states of

the micro-services that create the Unicorn application. In achieving this goal, we identified two approaches with

major differences.

The first approach is the imperative approach and is what has been followed for the creation of ARCADIA

orchestrator. In a very simplistic view, the imperative programming is a programming paradigm that uses

statements that change a program’s state [13].

The second approach is the declarative approach [13] and is the one that is currently followed by Kubernetes,

and in short using that approach means that we express the logic of a computation state without describing its

control flow. In the Kubernetes approach, everything is a declarative configuration object that represents the

desired state of the system, and it is Kubernetes’s job to ensure that the actual state of the world matches this

desired state.

In other words, in the imperative approach the state of the world is defined by the execution of a series of

instructions rather than a declaration of the desired state of the world. While imperative commands define

actions, declarative configurations define states. To explain this mapping of these two approaches in terms of

containers, the following the statement describes how to create three replicas of a containerized service. With

an imperative approach, the configuration would say: “run replica 1, run replica 2, and run replica 3.” The

corresponding declarative configuration would be “replicas equals three.”

Because it describes the state of the world, declarative configuration does not have to be executed to be

understood. Its impact is concretely declared. Since the effects of declarative configuration can be understood

before they are executed, declarative configuration is far less error-prone. Further, the traditional tools of

software development, such as source control, code review, and unit testing, can be used in declarative

configuration in ways that are impossible for imperative instructions [14]. In the case of Kubernetes, the

combination of declarative state stored in a version control system and Kubernetes’s ability to make reality

match this declarative state makes rollback of a change trivially easy. It is simply restating the previous

declarative state of the system. With imperative systems this is usually impossible, since while the imperative

instructions describe how to get you from point A to point B, they rarely include the reverse instructions that

can get you back.

Although implementing the declarative state management as part of the Unicorn Orchestrator requires more

effort and we consider it an important tool for managing the replication and scaling actions, and for this reason

it will improve the QoS of the platform and will also be more compatible with existing container orchestration

solutions like Kubernetes.

2.2 Service Deployment Optimization

The optimisation problem may be considered as combination of a form of two known theoretical problems, the

Multi-Resource Generalised Quadratic Assignment Problem (MRGQAP) and the Unsplittable Flow Problem

(UFP), both proven to be in the category of NP-Hard problems, meaning that there is no polynomial-time

algorithm that can solve them (a polynomial time algorithm is an algorithm for which its execution time has an

upper bounded that polynomial to the size of its input). Finding optimal solution to the service deployment

problem is computationally intractable. Thus, exact solution is appropriate for small instances of the problem


15

while efficient heuristics are required to be devised to come up with good solutions (near optimal solutions) in

reasonable time.

The multi-cloud deployment of a microservice is a problem that shares similarities with two realistic problems

already addressed in several research works, such as Virtual Network Embedding (VNE) and Virtual Data Center

Embedding (VDCE) problems. In VNE, given a substrate network with capacity constraints on substrate resources

and a virtual network request with capacity constraints on virtual nodes and links, it is required to assign virtual

nodes and links to substrate nodes and links and allocate resources, such that an objective function is maximised

or minimised accordingly. In VDCE, it is required to map VDC components (e.g., virtual machines, virtual switches

and links) onto physical nodes and links. VN embedding models differs from VDC embedding in that they only

consider CPU and network resources, whereas in VDC embedding, other resources such as memory and disk

also need to be considered. VMs co-location, migration, and consolidation are also considered. In the VNE

problem, the substrate network usually comprises tens to hundreds of servers and a virtual network request

usually includes tens of VMs. In contrast, in the VDCA problem, the data centres can comprise thousands of

servers and a VDC request can include hundreds of VMs. These aspects of the VDCA problem impose significant

scalability requirements on the scheduling algorithm. Optimal microservice deployment differentiates in that:

(i) the focus is specific on the application component requirements and not on a general purpose virtual

machine; (ii) a microservice request is most commonly for a limited number of execution environments as in

VNE and in contrast to VDCE, with which, however, shares the flexibility of permitting co-location of execution

environments; (iii) the list of requirements to satisfy in microservice deployment is extended in terms of the

restrictions regarding multiple resources and application scalability concerns. Furthermore, the use of network

functions (e.g., load balancers, firewalls) in the service graph of a microservice distinguishes the problem by

adding more restrictions, which may be relaxed by taking advantage of the emerging programmability of the

infrastructure.


16

3 Multi Cloud Resource Manager In this Section, we present a comprehensive documentation report introducing the reference architecture,

exposed functionality and implementation details referring to the Multi Cloud Resource Manager of Unicorn. As

already mentioned, the Resource Manager is responsible for the on-boarding of new infrastructural resources,

the continuous reporting of their availability and providing the ability to the Multi-Cloud Orchestrator to deploy

and manage the deployed applications.

It should be mentioned that, the Network Overlay Manager that will be delivered in the final version of the

Orchestration and Resource Management Mechanisms (deliverable D3.2) will be an extension of the Resource

Manager as described in this early release.

3.1 Requirements and User Roles

The Users interacting with the Resource Manager include:

• Cloud Application Product Manager that interacts with Resource Manager in order to provide the

appropriate cloud resources credentials.

• Cloud Application Owner that is the person providing the vision for the application as a project,

gathering and prioritizing user requirements and overseeing the business aspects of deployed

applications.

• Unicorn Administrator that is responsible for managing and maintaining the cloud resources that are

available for usage in the Unicorn ecosystem.

• Cloud Provider that provides cloud offerings in the form of programmable infrastructure that will be

consumed by the Resource Manager. The Cloud Provider is also responsible to operate the Cloud

Execution Environments that will host entirely or partially Unicorn-compliant Cloud Applications.

The goal of development of the Resource Manager is to be able to support the relevant use cases and

requirements. Therefore, in order to satisfy the use cases UC.13 (Manage cloud provider credentials), UC.18

(Provide abstract description of programmable cloud execution environment through unified API), UC.20

(Manage programmable infrastructure, service offerings and QoS) and UC.26 (Manage cloud application

owners), documented in D1.2[1], the Resource Manager shall also adhere to the corresponding requirements.

These requirements FR.2, FR.3, FR.15, FR.19, FR.12 were documented in D1.1[2] and for this first early release

of the platform the requirements have been further refined to more details in the following section.

3.1.1 Functional Requirements

ID FR.RM.1

Title Add Credentials for Multiple IaaS offerings

Description Unicorn Resource Manager must provide the means to register to cloud offerings in order to utilize the provided resources for the deployment of services.

Exposed Functionality

Registration forms for at least 3 IaaS providers.


17

ID FR.RM.2

Title Revoke IaaS Credentials for Multiple IaaS offerings

Description Unicorn Resource Manager must provide the means to completely and safely remove the credentials to IaaS offerings. Credentials shall be removed safely means that the removal of credentials should not affect any deployed applications through Unicorn.


Safely revoke credentials action from for at least 3 IaaS providers.

ID FR.RM.3

Title Edit IaaS Credentials for Multiple IaaS offerings

Description Unicorn Resource Manager must provide the means to safely edit the credentials to IaaS offerings. Credentials shall be edited safely means that any change of credentials should be validated in order to ensure that any deployed applications through Unicorn.


Safely edit credentials action from for at least 3 IaaS providers.

ID FR.RM.4

Title Allocate Resources on Multiple IaaS offerings

Description Unicorn Resource Manager must provide the means to allocate the needed resources (virtual infrastructure) on multiple IaaS offerings.


Allow the allocate of VMs and other available resources for at least 3 IaaS offerings.

ID FR.RM.5

Title Manage VM instances on Multiple IaaS offerings

Description Unicorn Resource Manager must provide the means to boot or stope instances on multiple IaaS offerings


Allow the boot and terminate VM instances for at least 3 IaaS offerings.

ID FR.RM.6

Title Release Resources on Multiple IaaS offerings


18

Description Unicorn Resource Manager must provide the means to release the needed resources (virtual infrastructure) on multiple IaaS offerings.


Allow the release VMs for at least 3 IaaS offerings.

ID FR.RM.7

Title Get existing VM instance types for multiple IaaS offerings

Description Unicorn Resource Manager should be able to access the available VM instance types on multiple IaaS offerings


Access VM instance types for at least 3 IaaS offerings

ID FR.RM.8

Title Get existing VM instances of a user for multiple IaaS offerings

Description Unicorn Resource Manager should be able to access the available VM instances on multiple IaaS offerings.


Access VM instances of a user for at least 3 IaaS offerings.

ID FR. RM.9

Title Create VM instances types

Description Unicorn Resource Manager should be able to create VM instance types, where this is possible.

ID FR.RM.10

Title Configuration of the Network Overlay Layer

Description Unicorn Resource Manager should provide the means to enable a Network Overlay Layer that will allow services on different networks to communicate.

3.1.2 Non-Functional Requirements

ID NFR. RM.1

Title Extendibility of Resource Management


19

Description Unicorn Resource Manager should be extendable in order to allow the addition of more IaaS providers to Unicorn without major changes.

3.2 Reference Architecture and Implementation

The Resource Manager is one of the main parts of the Cloud Orchestration Layer, as described in D1.2[1], and is

responsible for providing the appropriate infrastructural resources to the Unicorn Cloud Orchestrator. As

described in D2.1[3] the container bundler component will create the appropriate containers that are

comprising the service graph of the application to be deployed, using an extension of docker compose. Each of

the containers that are create have tο be deployed and managed by the Cloud Orchestrator Layer, using

Resource Manager for the actual provisioning of the appropriate resources (VMs, network, etc) that will be used

in order to deploy the needed Unicorn Agents and Container Images, and the Unicorn Cloud Orchestrator for

the orchestration of the whole process.

Figure 3: High-Level Overview of Unicorn Orchestration (Resource Manager related parts are highlighted and shown with arrows)

The Multi-Cloud Resource Manager provides a common and uniform view of a heterogeneous set of resources,

by implementing a common interface for creation, configuration, management and removal of virtual resources.

Resources under the control of the Resource Manager may include programmable computing, storage and

networking equipment. Also, the Unicorn Overlay Manager is responsible for the creation, management and

configuration of the Overlay Cross-Cloud Network that is network between the components of the defined

service graph that rely on different cloud and is used by the application that will be or has been deployed. The

vision of the project is to create this functionality using Kubernetes and the programmatically management of

Software-Defined Networking (SDN) at least on OpenStack IaaS based clouds.

At technical level, the Resource Manager is a Java Spring Boot application that has modelled the REST APIs of

the IaaS offerings and uses them for invoking the needed IaaS specific method when Unicorn Cloud Orchestrator

requests for specific resource allocation, revocation or management. The Resource Manager in essence helps

the Unicorn Cloud Orchestrator to provide resource aware orchestration capabilities that allows the initial


20

deployment and management of service graph components as containerized microservices in registered

resources.

For the actual deployment process, the decision to follow the “single service to container”[15] and “single

container on single VM” (lightweight VMs based on CoreOS) approach has been followed. This approach

guarantees not only the easy scaling of the applications but also provides isolation at the level of VMs and not

containers.

Although the development so far was mostly in backend level, a first release of the Resource Manager along

with a dedicated UI has been developed and depicted in Figure 4 that illustrates the IaaS listing user interface.

Figure 4: IaaS Providers List in the early release of Resource Manager

As each IaaS provider requires different information during the registration, separate CRUD forms and UI

elements are required. Indicatively, in Figure 5 that AWS registration is depicted, two keys can be provided

(Access Key, Secret Access Key- registration with username and password is also possible but not advisable for

security reasons), while for OpenStack, tenant, username and password credentials shall be provided, along with

the endpoint-URI of the OpenStack installation. As Resource Manager has been developed using extensibility in

mind, the operations that should be supported by an IaaS provider are abstracted and specific the created

adapters implement the abstract interfaces and provide the actual implementation logic.


21

Figure 5: Registration of new IaaS

Using a specific user interface, a service provider can register and de-register resources dynamically. During the

de-registration process, a consistency checking is performed in order to re-assure that there is no deployed

component that is affected by the de-provision.

3.3 Interaction with other Unicorn Services and Components

The Resource Manager interacts with the Cloud Orchestrator of the Platform through its exposed REST API in

order to allow the orchestrator to enable multi-cloud capabilities or any components of the platform that require

interaction. This API is documented using Swagger [16], a tool that automatically creates documentation for

REST interfaces, in order to always provide the proper documentation of the interfaces that are used other

components of Unicorn. In deliverable D3.2 the full set of the Cloud Orchestrator interfaces will be considered

final and documented.

As seen in the Figure 6, Swagger is easily added at the code of the developed service. It supports all major

languages, and in the example below of a Spring based Java application it identifies REST components

automatically.


22

Figure 6: Configuration of Swagger the Spring boot based application of Resource Manager

Swagger then produces the appropriate JSON for the documentation. Based on this JSON, a dedicated UI can

render nicely the whole documentation, while it is also possible to create client libraries for most major

languages.


23

Figure 7: A sample of Resource Manager Swagger documentation using Swagger and Swagger UI

The following snippet is part of the docker-compose file of the Unicorn Resource Manager and depicts the way

that Swagger UI is deployed seamlessly along with the component.

swagger: container_name: "unicorn_swagger" image: swaggerapi/swagger-ui environment: API_URL: "http://localhost:8080/v2/api-docs" ports: - 8070:8080

The exact same configuration is used for the other components of this deliverable and for this reason we are

not repeat it to the corresponding sections of the deliverable.


24

4 Unicorn Cloud Orchestrator In this Section, we present a comprehensive documentation report introducing the reference architecture,

exposed functionality and implementation details referring to the Unicorn Cloud Orchestrator.

Unicorn has the vision to provide a Multi-Cloud Orchestrator that can be used for multi-cloud deployment and

management of micro-services on OpenStack [9], AWS EC2 [17] and Google Cloud [18]. To achieve this, the

Unicorn Cloud Orchestrator is built for the deployment of the micro-service components by using the Multi-

Cloud Resource Manager. In the following, we will analyse these two functionalities separately.


The Users interacting with Cloud Orchestrator include:

• Cloud Application Owner that is the person providing the vision for the application as a project,

gathering and prioritizing user requirements and overseeing the business aspects of deployed

applications.

• Cloud Application Administrator that is responsible for deploying and managing the lifecycle of

developed and Unicorn-compliant cloud applications. This person ensures the application runs reliably

and efficiently while respecting the defined business or other incentives in the form of policies and

constraints.

• Unicorn Developer that creates Unicorn related (software) components for compliant Cloud Providers

and/or DevOps Engineers

To satisfy use cases UC.19 (Develop and use orchestration tools for (multi-)cloud deployments) and UC.5

(Manage the runtime lifecycle of a deployed cloud application), documented in D1.2 [1], while adhering to the

corresponding system requirements FR.16 (Resource and service (de-)reservation over multi-cloud execution

environments) and FR.10 (Manage the runtime lifecycle of a deployed cloud application) documented in D1.1[2],

the following functionalities must be exposed by the Cloud Orchestrator.


ID FR.ORCH.1

Title Communicate with the Resource Manager for multi-cloud deployment

Description Unicorn Cloud Orchestrator should be able use the Multi-Cloud Resource Manager in order to make multi-cloud orchestration of spawned VMs.


Connecting through the API of the Multi-Cloud Resource Manager and execute the appropriate methods for at least 3 IaaS providers.

ID FR.ORCH.2

Title Manage application lifecycle

Description Unicorn Cloud Orchestrator should be able to orchestrate the process of deploying, starting, stopping or deleting a unicorn microservice.


25


Through the usage of UI (provided by Unicorn dashboard) a user shall be able to manage the application lifecycle.

ID FR.ORCH.3

Title Manage microservice component lifecycle

Description Unicorn Cloud Orchestrator should be able to orchestrate the process of deploying, starting, stopping or deleting a stateless service and always be aware of its status.


Through the usage of UI (provided by Unicorn dashboard) a user shall be able to monitor the status of any service of the deployed application.

ID FR.ORCH.4

Title Deploy Applications based on optimization rules input

Description Unicorn Cloud Orchestrator should orchestrate deployment using the rules of the Optimization Manager.


Using appropriate API calls from the Optimization Manager in order to get the optimal deployment configuration.

ID FR.ORCH.5

Title Allow reconfiguration of applications based on runtime policies enforcement input

Description Unicorn Cloud Orchestrator should orchestrate the microservice deployment by taking into account the runtime policies that may suggest for specific stateless services to scale-in or scale-out.


Provide appropriate API call that the Policy Engine can use in order to request a change to the microservice deployment.

ID FR.ORCH.6

Title Orchestrate Deployment of applications using the input of the Container Bundler

Description Unicorn Cloud Orchestrator should be able to provide the proper container to the spawned VM.


ID NFR. ORCH.1


26

Title Scalability

Description Unicorn Cloud Orchestrator should be scalable in order to handle the orchestration of multiple deployed microservices.


Unicorn Cloud Orchestrator reflects the outcomes of task T3.3 and its main responsibility is to support the life-

cycle management of microservice based applications by defining and implementing the signalling protocol

required for deployment, un-deployment, and management of service graphs. To achieve these capabilities in

the scope of Unicorn, the orchestrator shall not only implement the Cloud Orchestrator component, but also to

include dedicated agents on the cloud part.

Figure 8 shows a high-level overview of the orchestration process from the infrastructure to the application layer

along with the key technologies that are used in each layer.

Figure 8: High-Level Abstract Overview of Unicorn Orchestration (Cloud Orchestrator parts are highlighted and shown with arrow)

Starting from the infrastructure layer, Unicorn with the Multi-Cloud Resource Manager provides a transparent

way of accessing infrastructure resources from multiple cloud providers. This an important prerequisite for

allowing Unicorn Cloud Orchestrator to provide support on the orchestration of container-based applications

on infrastructure resources from multiple cloud providers but is not adequate.

As already explained in section 2.1 (and previously in deliverable D1.2) in order to be able to create a scalable

multi-cloud deployment of this scalable service, Unicorn makes use of the Docker Engine [10] in order to allow

the execution of the service components, and uses VMs with a lightweight OS that are spawned on IaaS in order

to create cloud deployment of these services. As part of Unicorn Orchestrator, we used CoreOS as a basis and

integrated two additional agents, one that responsible for the registration of the new spawned VM and service

to the orchestrator, and one agent that is responsible for fetching the containerized image and executing any

commands required to make the service actually run(mainly docker commands), These two agents are required

in order to allow the orchestration process to be achieved, but It has to be stated that an extra agent is integrated


27

to the base CoreOS image in order to allow the monitoring VM related statistics and are utilized for the policy

enforcement.

For this reason, for the actual implementation of the Orchestrator but also for the Policy Enforcement

Mechanism in Unicorn, we had to implement a full stack of services and agents that allow the proper deployment

of the service and the same time collection of the data needed to take decisions for the policies enforcement.

In this regard, we introduce the concept of the Microservice VM which refers to the virtual machines that are

used for the deployment of the Microservice by the orchestrator.

On the following section we examine the architecture using the bottom-up approach.

4.2.1 Virtual Machines of Unicorn Cloud Orchestrator

The Microservice VMs are the workers of the system and are started from the orchestrator component. More

specific, each virtual machine the following components/agents are installed:

• Service Discovery: This agent is used to register the virtual machine as node of the system. Furthermore,

it declares the running services, by address and port. At last, it defines the health checks for each running

service. In our case we use Consul client [19], which it has it is a tool for discovering and configuring

services, and health check capabilities.

• Management Agent: This agent has been developed by the consortium and is a Java-based application

that is responsible to get the appropriate container image and add proper arguments for its execution.

• Monitoring Agent: This agent is used to monitor resources and performance on physical and virtual

machines' aspects. For our implementation we used Netdata [20], which it is fast and efficient

monitoring agent, but due to the pluggable and configurable design the agent is possible to change

without affecting the overall platform and further refinements will be done with collaboration of WP5.

• Container Engine: Finally, we have to highlight that in each VM a container engine (Docker Engine[4] in

specific) is used in order to manage and execute the containerized micro-services. In order to work

properly the application image must be provided and executed with specific arguments that are sent by

the orchestrator, through the Management Agent.

Figure 9: Representation of a Microservice VM


28

For the implementation of the Cloud Orchestrator based on the definition of the microservices VM presented

above, we created a highly available virtual machine (The MasterVM) which that contains all the needed

business logic and the services for the orchestrator. More specific the MasterVM of the Cloud Orchestrator of

the executes the following applications:

• Service Discovery and Registration Tool: This separate service is used in order to register newly spawned

virtual machines as node of the orchestrated system. In this tool, all the running services are declared,

with address and port. In our case we use consul server, which it has it is a tool for discovering and

configuring services deployed in any infrastructure. The consul server has the ability to communicate

with the consul agents (and vice-versa) not only for registration of nodes, but also to perform health-

checks that determine the service availability.

• Cloud Orchestrator: The main part of the Cloud Orchestration is responsible for overviewing the whole

orchestration process, managing the connections and interactions between various components and

sending to the agents any commands needed for execution.

4.2.2 Unicorn Orchestrator Controlled States and Controllers

As also explained in section 2.1.2 of this document, one of the most important aspects of the orchestrator

development is to properly define and control the states of the components that create the overall deployed

application. Although in a single, monolithic application the state can be easily controlled, in a microservice-

based application that each of the deployed components can be replicated and also deployed in multi-cloud

environment, this task far more complex.

In achieving this goal, the two approaches of imperative and declarative approach have been identified and

analysed in section 2. As we consider that using the declarative approach will improve the stability, we had to

define specific controller that are responsible for ensuring that the actual state of the application components

and see if the states match to the desired state. For achieving this, the following controllers need to be

implemented as part of the orchestrator:

• Horizontal Scaling Controller: This controller is responsible for ensuring that the specified scaling

requirements are met at continuous manner. If there are too many containers per service, the Controller

terminates them (scale-in), while if there are too few, it starts more.

• Deployment Controller: This controller is responsible for controller checking and providing to the

orchestrator declarative updates for the deployment. Due to the horizontal scalability offered by

Unicorn, the deployment controller is actually using the Horizontal Scaling Controller in order to define

the number of containers that should be running for each service, even if only one container per

microservice is used.

• Resource Controller: This controller is used to manage the lifecycle of the available nodes (VMs) in a

declarative way. For each spawned VM, the resource controller should know the state of the VM, the

proper functioning of the agents and check if there is a container running in the specific node. It is also

collecting any information regarding the resources of the VM and the IaaS in general (through the

Resource Manager), so that the actual state of the IaaS is always known prior to any scaling or

deployment actions.


29

• Garbage Collection Controller: Garbage Collector is an auxiliary Controller that shall be used to delete

certain objects that once had an owner, but no longer have an owner. This action car refers to VMs

without containers or VMs and containers without a mapped application.

Regarding the actual states of the applications, we utilized the previous experience of ARCADIA and we defined

for any application that is based on the microservice paradigm and is placed to specific IaaS resources though

Unicorn, it shall have the following acceptable states of a deployment process. From a single component point

of view deployment status can BOOTSTRAPPED, ONGOING, DEPLOYED, STARTED. Bootstrapped is a component

that it’s node (VM) has just started, agents are installed and is reporting its status in the Service Discovery.

Ongoing means that is starting the appropriate container or it is blocked until all endpoints it depends are not

available. The Horizontal Scaling and Deployment controllers are monitoring this process and upon resolution

all application dependencies, the component should be in a STARTED mode.

Figure 10: Representation of a deployed component Life-cycle

For the overall deployed application point of view, the same statuses apply but not all components have to be

monitored. Responsible for this is the Deployment Controller. After each deployment ordered by the

orchestrator, a Deployment Controller starts as a separate thread and communicates with the components that

are placed in a specific resource. Upon reception of this message, the components try to identify if there are

specific dependencies that have to be met. If there issues on the specific component or on the components that

it depends on, the components publish in a specific queue a DEPLOYED message accompanied by the identifier


30

of the service graph which is deployed. In case of dependencies that are not met, the state remains to

BOOTSTRAPED until the controller confirms that all components satisfied their dependency.

Figure 11: Representation of a deployed application Life-cycle

Most of the operations that take place inside the Orchestrator are asynchronous. This is deliberate since blocking

calls among the components is strictly prohibited in order to re-assure scalability, although there are some

specific tasks that are heavily dependent on the various operations performed so it have to be executed in a

synchronous manner. In order to extract this near real-time view, the Unicorn Cloud orchestrator relies on the

aforementioned Controllers that are responsible for the assurance of the application status. The controllers will

run in separate threads and will perform constant control loops to ensure that proper data are collected. The

design and implementation of the whole scheduling mechanism of the controllers is a challenging and critical

task that is currently active, as different options for the creation of a scalable scheduling mechanism (creation

of custom threads and a custom cluster service, usage of Apache Mesos scheduling1, usage of Spring Scheduling2)

are evaluated.


The Unicorn Cloud Orchestrator interacts with the Multi-Cloud Resource Manager, the Policies Manager and

Enforcer and the Optimization Engine. Unicorn Orchestrator provides a REST API that can be used by any

components of the platform that require interaction. This API is documented using Swagger, as described in

1 http://mesos.apache.org/#two-level-scheduling 2 https://spring.io/guides/gs/scheduling-tasks/


31

section 3.3, in order to always provide the proper documentation of the interfaces that are used other

components of Unicorn. In deliverable D3.2 the full set of the Cloud Orchestrator interfaces will be considered

final and documented.

5 Policies Manager and Enforcer (Policy Engine) In this Section, we present a comprehensive documentation report introducing the reference architecture,

exposed functionality and implementation details referring to the Policies Manager and Enforcer part of

Unicorn. The combination of these two components can be referred as Policy Engine and allows the automatic

and constant policy enforcement that allows managing the elasticity of the microservice components running

on virtual instances.


The Users interacting with the Policies Manager include:

• Cloud Application Owner that defines to express runtime policies and constraints according to the cloud

application properties.

• Cloud Application Product Manager that also is able to enrich the deployment assembly with runtime

enforcement policies.

• Cloud Application Administrator that is ensures that the application runs reliably and efficiently while

respecting the defined business or other incentives in the form of policies and constraints.

To satisfy Use-Case UC.1 (Define runtime policies and constraints) and UC.9 (Adapt deployed cloud applications

in real time), documented in D1.2 [2], while adhering to system requirements FR.1 (Develop cloud application

based on code annotation design libraries and define runtime policies and constraints) and FR.9 (Autonomic

management of deployed cloud applications and real-time adaptation based on intelligent decision-making

mechanisms), documented in D1.1 [2], the following functionality must be exposed by the Policies Manager.


ID FR.PM.1

Title Provide a UI for the design and management of runtime policies

Description Using the UI of the Unicorn Dashboard runtime policies shall be able possible to be defined or edited.


Policy Engine shall provide the backend mechanisms that allow the design of the policies from the Unicorn Dashboard

ID FR.PM.2

Title Enforcement of runtime policies

Description Based on the policies and the facts, Policy Engine will ask the Unicorn Cloud Orchestrator to enforce a change (scale-in or scale-out).


32


Policy Engine shall utilize API calls provided by the Cloud Orchestrator in order to request a change to the microservice deployment.

ID FR.PM.3

Title Read policies from the Unicorn Compose file of the application

Description Policies defined in the Unicorn Compose file shall be understandable from the Policy Engine


-


ID NFR.PM.1

Title Scalability

Description Policy Engine should be scalable in order to handle policies enforcement with multiple facts, multiple policies and multiple deployed applications


Policies Manager and Enforcer is a component of that is responsible to take decisions based the combination of

specific policies, rules and their combination with data. Although in the initial architecture presented in D1.2 [1]

is part of the Runtime Enforcement Layer, as a component has close relation to the Cloud Orchestration Layer

components, and it can be seen as part of the overall Orchestration mechanism of Unicorn, as depicted in Figure

12 below.


33

Figure 12: High-Level Overview of Unicorn Orchestration (Mechanisms involved in the Policy Enforcement are highlighted and shown with arrow)

Policies Manager refers to the creation, storing and management of the policies, that are based on specific

statements of a Business Rules Management System (BRMS) solution. This BRMS in Unicorn represents the core

engine part of the Policy Enforcer. For the policy engine we use Drools [21], a Java-based BRMS. In Drools

decisions are made using knowledge which is represented as rules. The rules contain business logic based on

simple if-then structure. The ‘if’ statement is actually represented from keyword ‘when’ and is used for declaring

the condition. The, ‘then’ statement defines the action that is performed when condition satisfied. The entirety

of rules is creating what is also known as a production memory. Furthermore, in BRMS as Drools the input data

that represents the facts is also collected and is inserted into what is usually referred as working memory. At

last, the inference engine of Drools is responsible to combine production and working memory to take a

decision. Those decisions are the actions of the if-then statements, in the case that the facts are satisfying the

condition.

Figure 13: Representation of abstract Policy Engine

For this reason, for the actual implementation of the Policy Enforcement Mechanism in Unicorn, we had to

implement a full stack of services and agents that allow the collection of the facts needed to take decisions for

the policies enforcement scenarios of Unicorn. In this regard, for the Policy Enforcement we use the MicroService

VM entity defined in 4.2.1 as a MicroService VM includes the needed Monitoring Agent.

Also, we for the Policy Enforcement needs we extend the MasterVM presented also in 4.2.1, in order to also

include the services and business logic needed for the Policies Management and Enforcement. Therefore, in

addition to the Cloud Orchestrator and the Service Discovery components, it also includes the Monitoring and

Alerting System and the Policy Engine. More specific the master virtual machine executes the following

applications:

• Monitoring and Alerting System: it used to collect real-time performance monitoring metrics for each

virtual machine. Furthermore, it gets addresses for the active nodes from Service Discovery and pulls

performance metrics. If some metrics are lower or higher that a threshold alerting is triggered. In our

case we use Prometheus [22], which it is a system monitoring and alerting toolkit. Prometheus gets from

Consul all Netdata agent addresses to collect performance metrics from each microservice VM.


34

• Policy Engine: As stated already, for the implementation of Policy Engine, Drools engine is used to take

decisions based on combination of rules and data. In our case, the input data is the pulled metrics from

masters' monitoring system (Prometheus).

Figure 14: Representation of the components deployed in the MasterVM

In the following figure the interactions between the nodes that host the application components (through the

dedicated agents) and the highly available MasterVM that hosts the Orchestration and Policy Enforcement.


35

Figure 15:Representation of detailed architecture of Policy Engine (Master Node and micro-service node)

Finally, in order to allow the easier explanation of the way that the Policy Engine3 works and we provide more

details about the implementation aspects of the Policy Engine, including some code snippets along with the

needed explanation.

For the definition of the methods that interact with Drools, DroolsService interface has been with the following

methods:

• initDroolsEngine: Method used to initialize Drool Engine, it gets as parameter the path of rules file.

• insertFactsIntoWorkingMemory: Method used to insert input data into working memory, as facts. It gets

as parameter the object, the object must extend DroolsFact.

• fireRulesAll: Method used to execute inference engine (pattern matcher) for all rules and all facts.

• fireRuleByAgendaGroup: Method used in order to execute inference engine (pattern matcher) for some

specific rules and all facts.

3 https://gitlab.com/unicorn-project/unicorn-policy-engine


36

Figure 16: DroolsService Interface

As already stated before, the rules are based on when-then statements. A simple Unicorn policy is presented

below.

Figure 17: Representation of rule (if CPU Load > 80% )

In order to insert facts, we pull performance metrics from Prometheus, through the usage of Prometheus HTTP

API. The endpoint of Prometheus gets as parameter a query and it returns json-object as depicted in figure

below.


37

Figure 18: Prometheus Sample Query

This method automatic runs every 30 seconds and make a call into the Prometheus HTTP API using a specific

query. It returns json-object, according to this return create a Fact object and then insert it into working memory.


38

Figure 19: Representation of input data (facts)

Figure 20: Adding Facts using Prometheus

Finally, the following class includes methods that execute inference engine (pattern matcher) for all rules and

all facts every one minute.


39

Figure 21: Drools pattern matching execution


The Policies Manager interacts with the Orchestrator and the Optimization Engine Components of the Platform

and provides REST API for integration. This API is documented using Swagger, as described in section 3.3, in

order to always provide the proper documentation of the interfaces that are used other components of Unicorn.

In deliverable D3.2 the full set of the Policies Manager interfaces will be considered final and documented.


40

6 Optimization Engine In this Section, we present more details about the reference architecture, exposed functionality and

implementation details referring to the Optimization Engine of Unicorn. The main objective of the optimization

engine is to support the production of application deployment plans taking into account a set of constraints and

objectives denoted on behalf of service providers.

The constraints may regard -among others- resources guarantees (e.g. minimum amount of memory, storage,

network capacity), specific resources usage (e.g. usage of GPUs), locality (e.g. placement of a software

component at the edge of the network, collocate two or more software components), QoS guarantees (e.g.

dedicated bandwidth for a virtual link).

The objectives may regard business or technical goals that the service provider desires to achieve. The target

may be the overall system capacity or other technical aspects of operation (e.g. balance load among physical

machines, minimize network traffic, maximize utilization of resources, maximize capacity of the system in terms

of hosted request), maximize the overall achieved performance (e.g. satisfy service-level objectives (availability,

response time etc.), minimize number of SLA violations), energy efficiency (e.g. minimize overall energy

consumption, minimize number of active physical machines, minimize carbon footprint), monetary costs (e.g.

minimize fees paid, minimize operations costs, amortize capital expenditures). Multi-objective problem

formulation is realised, taking into account weights per objective, leading to a sum function concerning the main

target to be achieved.


No users are interacting with this component, as it is an internal component used by the policies manager

component. The main use cases and requirements identified for the Policies Manager and Enforcer in section

5.1 also apply to this component as well. In specific, Use-Case UC.1 (Define runtime policies and constraints) and

UC.9 (Adapt deployed cloud applications in real time), and the requirements FR.1(Develop cloud application

based on code annotation design libraries and define runtime policies and constraints) and FR.9 (Autonomic

management of deployed cloud applications and real-time adaptation based on intelligent decision-making

mechanisms), documented in D1.1. The following additional requirements for Optimization Engine have been

created.


ID FR.OPT.1

Title Support the production of application deployment plans based on hard and soft placement constraints

Description Provide constraint satisfaction solver capabilities that suggest the optimized service deployment parameters based the description of the application package, the existing resources, the defined policies and also real-time contextual information.


Optimization Engine provides the optimal deployment description to the Unicorn Cloud Orchestrator


41

ID FR.OPT.2

Title Optimization Manager should be aware of the available resources in multiple IaaS providers that might be used by an application

Description Optimization Manager should get information about existing resources, the defined policies and also real-time contextual information.


Usage of API methods provided by the Multi-Cloud Resource Manager and the Cloud Orchestrator for collecting the required information

ID FR.OPT.3

Title Optimization Manager should be aware of the real-time contextual information(facts) for the deployed components of the application

Description Optimization Manager should get information about real-time contextual information.


Usage of API methods provided by the Policy Engine and the Cloud Orchestrator for collecting the required information


ID NFR. OPT.1

Title Scalability

Description Optimization Engine should be scalable in order to handle a large number optimization requests


Application Placement Optimization was described in the initial architecture as a backend component that acts

as a constraint satisfaction solver and recommendation engine that suggest the optimized service deployment

parameters based the description of the application package, the existing resources, the defined policies and

also real-time contextual information. The optimization for the deployment problem is actually a proactive

adjustment of the running configuration and is using facts, like the available resources in the multi-cloud

execution environments, and the placement constraints per each component defined in the deployment policies

are taken under consideration of the creation of the optimal service graph.

The formulation of the cloud applications deployment problem is realized in a way that captures a series of

practical issues so far ignored in related works [24-28] but which are considered essential for coming up with

realistic deployments, as detailed in the following list:

• Multiple capacitated resources: Several different capacitated resources offered by hosts and links are

considered during an assignment (i.e. CPU, memory, storage I/O, bandwidth). A portion of a capacitated

resource may be offered as a different type of this resource differing in the way it is shared or accessed

(i.e. premium CPU access shared to fewer users than common CPU access).


42

• Oversubscription of resources: Most commonly in virtualization, the benefits of statistical multiplexing

of resources is exploited and actual capacity of a resource is omitted to be more than it actually is,

multiplied by a factor. This also stands for bandwidth sharing of a link (e.g. planning for accepting more

traffic flows than those that could be served if the max traffic rate per flow was considered).

• Virtualization overhead: Required amount of a resource by a software component most commonly

differs when this component runs on a native OS from running in a virtualized OS [29-30]. The overhead

induced by virtualization may further differ from host to host depending on the physical machines

capabilities and virtualization solution adopted.

• Density: In virtualization, most commonly a maximum number of virtual machines may be handled

effectively by a host given its capabilities and capacity of resources. This restriction comes from imposed

virtualization overheads and scheduler related matters [29-30]. Virtualization solutions often suggest or

provide formulas for computing suggested targeted density and oversubscription ratios while it is

considered that no virtual machine can be hosted when one of two, density limit or oversubscribed

capacity of a resource is reached

• Metrics range: Apart from required resources an assignment may require a monitored metric to have a

value within a range. This way, quality requirements may be captured and requested for an assignment.

In example, not only a certain amount of bandwidth may be required but also an acceptable end to end

delay.

• Collocation control: Two software components of the same cloud application may be assigned to

execution environments that are collocated at the same host. This may be efficient in most cases but

may be undesirable when profiling information regarding the microservice indicates that on a workload

increase, these two components may require more resources at the same time; a burst in workload is

followed by a burst in requirement of one or more resources for both components at the same time.

Statistical multiplexing and oversubscription of resources are based on the fact that resource demand

is not simultaneously increased by all running components. Thus, as long it can be controlled, efficient

use of resources is preserved.

Based on the aforementioned aspects, a set of deployment constraints are denoted. Such constraints can be

declared as hard or soft constraints. The hard constraints have to be fulfilled, otherwise there is not going to be

a solution to the problem. The soft constraints are penalized -in case of violation- by a score, which is actually

associated with the achievement of the envisaged objectives. Thus, the solving process first will attempt a zero

hard score (constraints) and then do its best to minimize soft score (objectives).

The overall implementation is based on Optaplanner [23] that is an open source constraint satisfaction solver

(Figure 22). OptaPlanner is a lightweight, embeddable planning engine. It enables Java programmers to solve

optimization problems efficiently. It combines sophisticated optimization heuristics and metaheuristics with

very efficient score calculation. Problem formulation is based on Drools, providing interoperability -if required-

and common technology base with the Policy Engine.


43

Figure 22: Optaplanner Constraint Satisfaction Solver

The definition of a problem in Optaplanner is coded as a set of data objects (POJOs) that may describe the

domain and with appropriate annotations set the planning entities and variables of the problem (Figure 23). The

planning entities are the classes that change during solving (CloudProcess and Path in Figure 23), while the

planning variables are the properties of a planning entity class that change during solving (CloudComputer and

Channel in Figure 23). A planning solution is the class that represents a data set and contains all planning entities

(CloudBalance in Figure 23).

With regards to further implementation details, problem constraints have been coded as a set of drools rules

which when triggered penalize a solution with a score (hard score). Problem objectives have been coded as a

set of drools rules which when triggered penalize a solution with a score (soft score). The solver engine has been

configured to solve the problem which in fact consists of two sub-problems, at the same phase. Solving process

first will attempt a 0 hard score (constraints) and then do its best to minimize soft score (objectives). Input to

the problem is provided as an XML file, while a REST interface to provide input remotely to a solver running as

a service is currently under development.


44

Figure 23: Problem Definition

In this first release of Unicorn components, the vision is for the Optimization Manager to provide the optimal

deployment plan. In the next iteration, this mechanism shall be extended with the ability to do re-configurations

of the deployment plan, based on measurements that derive from the monitoring components and take under

consideration the runtime policies that are provided and enforced by the Policies Manager mechanism.


The Optimization Engine interacts with the Policies Manager in order to access the existing policies and also

receives the resources information by the Multi-Cloud Resource Manager component. This API is documented

using Swagger, as described in section 3.3, in order to always provide the proper documentation of the interfaces

that are used other components of Unicorn. In deliverable D3.2 the full set of the Optimization Engine interfaces

will be considered final and documented.


45

7 Conclusions The current document provides a comprehensive overview and documentation report for the early release of

the Multi-cloud Orchestrator and the Optimization, Policies and Resources Manager. These mechanisms are

developed as part of Work Package 3 (WP3) and together they provide the main outcome of this Work Package

that is Unicorn’s Policy-Aware, Multi-Cloud Orchestrator. These mechanisms correlate with the tasks of the T3.1

-T3.3 of the WP3 and this document provided a snapshot of the development process of the components and

mechanisms developed in the scope of WP3.

This deliverable tries to provide a continuation of Unicorn Deliverable D1.2 [1] and for this reason in section 2 is

provided a short update on the related technologies and the challenges that were identified so far in WP3.

For each of four main mechanisms of WP3 are described in the document with focus provided on the reference

architecture, the technologies used and the implementation aspects.

The Multi-Cloud Resource Manager is responsible for on-boarding new IaaS resources and continuously

reporting their availability. OpenStack, Google Cloud Platform and Amazon Web Service support is provided.

Then the Cloud Orchestrator build on top of the Multi-Cloud Resource Manager in order orchestrate the

deployment and management of deployment artefacts on multiple IaaS resources. The deployment artefacts

are described in detail as they are needed for each service defined in the Unicorn compose file of each

application.

Finally, on top of the Unicorn Cloud Orchestrator, the Policies Engine and the Optimization Manager are built

and are responsible for the enforcement of policies defined by the developer of a Unicorn microservice and

allow the constant scaling and the optimal deployment configuration of the microservice based on predefined

placement constraints and the facts provided by the monitoring mechanism of Unicorn.

This deliverable depicts an early version of the mechanisms and in the upcoming deliverable D3.2 the features

and mechanisms introduced in this deliverable will be finalized. Also, D3.2 will provide the final documentation

of the Unicorn Orchestration and Resource Management mechanisms in terms of implementation, usage and

API description.


46

8 References [1] Unicorn, “Unicorn Deliverable D1.2 UNICORN Reference Architecture.” 2017.

[2] Unicorn, “Unicorn Deliverable D1.1 Stakeholders Requirements Analysis.” 2017.

[3] Unicorn, “Unicorn Deliverable D2.1 UNICORN Libraries, IDE Plugin, Container Packaging and Deployment

Toolset – Early Release.” 2018.

[4] Docker, “https://www.docker.com/.”

[5] Docker vs CoreOS Rkt, “https://www.upguard.com/articles/docker-vs-coreos” .

[6] Docker Swarm, “https://docs.docker.com/engine/swarm/swarm-tutorial/” .

[7] Kubernetes, “http://kubernetes.io/” .

[8] Apache Mesos, “http://mesos.apache.org/” .

[9] OpenStack, “http://openstack.org/” .

[10] OpenStack Documentation, “https://docs.openstack.org/devstack/latest/guides/lxc.html.” .

[11] OpenStack Hypervisor Support Matrix, “https://docs.openstack.org/nova/latest/user/support-

matrix.html.” .

[12] ARCADIA Orchestrator, “http://www.arcadia-framework.eu/release-of-the-first-version-of-the-arcadia-

orchestrator/” .

[13] Declarative Vs Imperative Programming, “https://codeburst.io/declarative-vs-imperative-programming-

a8a7c93d9ad2” .

[14] Kubernetes: Up and Running. Dive into the Future of Infrastructure (Brendan Burns, Kelsey Hightower,

Joe Beda), 2017 .

[15] Pattern: Service instance per container, “http://microservices.io/patterns/deployment/service-per-

container.html” .

[16] Swagger, “https://swagger.io/” .

[17] Amazon ECS, “https://aws.amazon.com/ecs/” .

[18] Google Cloud, “https://cloud.google.com” .

[19] Consul, “https://consul.io/” .

[20] Netdata, “https://github.com/firehol/netdata” .

[21] Drools, “https://www.drools.org/.” .

[22] Prometheus, “https://prometheus.io/” .

[23] Optaplanner, “https://www.optaplanner.org/” .

[24] M. Yagiura, A. Komiya, K. Kojima, K. Nonobe, H. Nagamochi, T. Ibaraki, F. Glover, “A Path Relinking

Approach for the MultiResource Generalized Quadratic Assignment Problem,” 2007 international

conference on Engineering stochastic local search algorithms: designing, implementing and analyzing

effective heuristics (SLS'07), Brussels, Belgium, September 06 - 08, 2007.

[25] Y. Dinitz, N. Garg, M. X. Goemans, “On the Single-Source Unsplittable Flow Problem,” Springer

Combinatorica, January 1999, Volume 19, Issue 1, pp 17–41.

[26] T. D. ter Braak, “Using Guided Local Search for Adaptive Resource Reservation in Large-scale Embedded

Systems,” Design, Automation & Test in Europe Conference & Exhibition (DATE), 2014.

[27] A. Fischer, J. F. Botero, M. Till Beck, H. de Meer, X. Hesselbach, “Virtual Network Embedding: A Survey.

Communications Surveys & Tutorials,” IEEE (Volume: 15, Issue: 4), Feb. 2013.

[28] M. Faten Zhani, Q. Zhang, G. Simon, R. Boutaba, “VDC Planner: Dynamic Migration-Aware Virtual Data

Center Embedding for Clouds,” IFIP/IEEE International Symposium on Integrated Network Management

(IM 2013), May 2013.


47

[29] Z. Li, M. Kihl, Q. Lu and J. A. Andersson, "Performance Overhead Comparison between Hypervisor and

Container Based Virtualization," 2017 IEEE 31st International Conference on Advanced Information

Networking and Applications (AINA), Taipei, 2017, pp. 955-962.

[30] L. Chen, S. Patel, H. Shen and Z. Zhou, "Profiling and Understanding Virtualization Overhead in Cloud,"

2015 44th International Conference on Parallel Processing, Beijing, 2015, pp. 31-40.

Management Mechanisms Early Release - UNICORN...

Documents

Transcript of Management Mechanisms Early Release - UNICORN...