SELF-ORGANISING, SELF-MANAGING HETEROGENEOUS CLOUD

The CloudLightning Service Description Language

CloudLightning Gateway Service – API & Definition LanguageMarian Neagul / marian@ieat.roInstitute e-Austria / www.ieat.roTimișoara / Romania

Overview• A different perspective to the CloudLightning Architecture• The CloudLightning Gateway Service

Main FunctionalitiesAPI Model

• The CloudLightning Service Description Language

The CloudLightning ArchitectureGateway Service Perspective

Gate

way

Ser

vice

Gateway Service UI

Orc

hest

rato

r Eng

ine

Blueprint Decomposition Engine

Apache Brooklyn Serv

ice

Cata

logu

es

The CloudLightning ArchitectureGateway Service Perspective

Gate

way

Ser

vice

Operator

CSP

Acquire/Deploy Blueprint

Register Offers

Catalogues

Brooklyn

Service Decomposition

Console/UI

Que

ryy

Depl

oy

Self

Org

anizi

ng C

loud

Deploy Services

Trigger Self Organization

CloudLightning Gateway ServiceOverall functionality

• Represents the interface between the Operator and the Self Organizing Cloud

The Gateway Service also serves the CSP, allowing him to register new blueprints (definitions of applications) and services

• Abstracts the inner workings of the self organizing system (effectively hiding most of the internal details like vRacks, Cells, etc)• It’s functionality is wrapped around a custom tailored

Service Definition Language ☞

What is an application ?

CloudLightning Gateway ServiceGateway UI (Web Console)• The Web Console is aimed to provide

user interface for Blueprint definitionservice service registration and, most importantly, for triggering the deployment of the

blueprint • The Console builds upon the capabilities of the Brooklyn

componentThis allows us to reuse already existing Apache Brooklyn features

• It aims to hide the intricacies of the self organization systems

CloudLightning Gateway ServiceCatalogues

• We have several kinds:Service Catalogues: holding service definitions provided by the

CSP or, eventually, by the OperatorBlueprint Catalogues: holding blueprint definitions

(compositions of registered services or blueprints)

• The catalogues are consumed by:The decomposition engine, aiming to optimize the service

choice according to various criteriaThe console, for presentation and management purposesThe Apache Brooklyn component for triggering the effective

service orchestration and deployment

CloudLightning Gateway ServiceService Decomposition Engine

• The Service Decomposition Engine is the component of the Gateway Service responsible with the interaction with the self organizing system• It’s main function:

Transforming abstract specifications to concrete implementations according to user requirements; This is achieved by tight integration with the self organizing system;

The Decomposition Engine is the facilitator for achieving some of CloudLightning main aspirations: as for example energy efficiency or performance

CloudLightning Gateway ServiceApache Brooklyn

• We build upon the Apache incubated Brooklyn ProjectWe extend it to support our concept of “meta” servicesWe extend it in order to properly interact with the Service

Decomposition Engine

• Brooklyn's Blueprint language serves as the “backbone” of the CloudLightning Service Definition Language

We add custom constructs for referencing “meta” services and specifying service requirements ☞

CloudLightning Gateway ServiceService Definition Language

• As previously mentioned represents the main construct for specifying application and service requirements• Is build on top of the Apache Brooklyn Blueprint

Extended to support meta servicesExtended to support the specification of requirements at

various levels: service or application level

Structure of the Blueprint / SDLThe API view

Example Blueprint / SDLlocation: cloudlightning-1:ro.ieatname: My Cool Raytracing Solutionrequirements: - ....services:- type: io.cloudlightning.entity.meta.RayTracingComputeService id: RayTracingComputeService brooklyn.config: cloudlightning.soso.min_performance: 100gflops cloudlightning.soso.placement-policy: same-broadcast-domain cloudlightning.config: hints: prefer: ['GPU', "FPGA", "CPU"] # List of preferences requirements: ...- type: io.cloudlightning.entity.meta.raytracing.controller id: raytracingController brooklyn.config: messos_cluster.head_node: $brooklyn:component("RayTracingComputeService")

Implementation Schedule• Specification of the requirements for the Service

Definition Language is expected to be formulated by end of M15 (End of April 2016)• The complete implementation of the Gateway Service is

expected by end of M24 (February 2017)We plan to push relevant patches upstream (Brooklyn)

Questions ?

THANK YOUMarian Neagul