self-organisation as a cloud resource management strategy

Dissemination Level: Publichttp://cloudlightning.eu/

@_cloudlightning

SELF-ORGANIZATION, A STRATEGY

FOR CLOUD RESOURCE

MANAGEMENT

Prof J. P. Morrison

Dr Huanhuan Xiong

University College Cork, Ireland

http://cloudlightning.eu/




@_cloudlightning

OverviewCloud resource management

The Cloud isn’t what it used

to be

Self-Organization and Self-

Management Perspective

Final Remarks





@_cloudlightning

Traditional

Resource

Management

Scope

• Resource

management here is

confined to identifying

and selecting

resources to host the

next task

• Many proprietary

Schemes (Google,

Amazon, Azure) not

disclosed

• Work informed by

strategies adopted in

open-source projects

such as OpenStack

Resource Management

Resource Allocation

identifying and selecting resource to host next task

Referred to, in literature, as Resource Scheduling

Other aspects of Resource

Life-Cycle Management not

considered here





@_cloudlightning

Resource

Scheduling

With

OpenStack

Nova

Schedular

• OpenStack uses the

Nova Scheduler to

locate resource to

host the next task

• Many different

strategies have been

proposed and

implemented.

Chance Scheduler

Choose host randomly

Simple Scheduler

Choose host based on number

of running cores.

Filter Scheduler

Filter and calculate weighted

cost.





@_cloudlightning

OpenStack Nova Filter Scheduler





@_cloudlightning

More than 20 filters are currently available. These can be combined to meet complex

requirements. They are categorized as follows:

Resource-based filters

Decisions made according to available resources: memory, disk, CPU cores.

CoreFilter, DiskFilter and RamFilter.

Image-based filters:

Decisions made according to image properties. Select hosts from CPU architecture, hypervisor,

and VM mode.

Host-based filters:

Decisions made according to grouping criteria: location, availability zone, or designated use.

Net-based filters:

Decisions made according to host IP or subnet.

Custom filters:

Users defined custom filter.

OpenStack Filtering Options





@_cloudlightning

The LeastCost Algorithm schedules instance creation on available

hosts in the order of the weight assigned to each host.

The input is a set of objective-functions, called the 'cost-functions'. These

cost functions usually consider four parameters: CPU, RAM, disk storage

and network bandwidth.

Each host calculates a combined weight for each cost-function:

∑(weight of cost function * score returned by this function for the host)

The host with the least cost is selected for provisioning.

OpenStack Weighting





@_cloudlightning

Weighting

Each time the scheduler

selects a host, it records

the consumed resources,

subsequent selections are

adjusted accordingly.

This is important because

weight is computed for

each requested instance.

All weights are normalized

before being summed and

the host with the least

weight is given the highest

priority.





@_cloudlightning

Summary

Characteristics

of the OS

Filter

Scheduling

Strategy

Sophisticated Strategies

Scheduling time increases

with filter complexity

Scheduling time increases

with host population size

Filtering options determined

by application

Weights are preconfigured

into the scheduler, thus

statically determining its

behaviour





@_cloudlightning

The Cloud isn’t

what it

used to be

It’s becoming a victim of its

own success.

Complexity and costs are

rising

Low server utilization

Overprovisioning

High energy costs

More diverse and complex applications

Heterogeneous resources

Control theory tells us that centralized management is ineffective at scale





@_cloudlightning

Perceived

Objectives Customer Level Objectives Make cloud computing more accessible Make cloud computing more efficient Move towards “ease of everything”

Provider level objectives Re-establish control over their IaaS offerings

Facilitate better power managementEnable fast resource provisioning for quicker

service initiation

Enable seamless exploitation of heterogeneous hardwareExploit faster and cheaper service delivery

offered by hardware acceleratorsEmploy different heterogeneous hardware

types for different services or for different invocations of the same service





@_cloudlightning

Self-Organization and Self-Management

Perspective





@_cloudlightning

Resources In a heterogeneous cloud, there will be many different types of compute

resources.

These resources may be available individually or they may be bundled into

subsystems.

Individual resources and subsystems may have pre-installed software stacks

They may be physically located on interconnects with different characteristics

A CL-Resource is a generic term used to refer to any of the above

CL-Resources can thus be bare metal; virtual machines, containers, networked

commodity or specialized hardware, servers with accelerators such as GPUs,

MICs and FPGAs; pre-built HPC environments

In response to a service request, the CL system identifies specific CL-

Resources to be used for the delivery of that service.

Workflows of services may be implemented on a mixture of CL-Resources

– one resource type per service





@_cloudlightning

Towards a

Dynamic

Filtering

Mechanism

• Facilitate scalability

with increasing host

population size and

filtering complexity

Hierarchically Structure the host space

to reflect host properties

Hardware type, co-location on low-latency networks, proximity to storage servers, etc.

Decentralize Resource Management

decisions





@_cloudlightning

Hierarchical Structure of the CloudLightning Architecture

Cell Manager

pRouter pRouter

pSwitch pSwitch pSwitch

VRM VRM VRM VRM VRMVRM VRM

Heterogeneous Resource Fabric (Hardware)-L0

L1

L2

L3

L4

Resource

Requests

Resource





@_cloudlightning

CloudLightning

Layers

• pSwitches can

transfer management

of vRMs

• vRMs can transfer

management of

physical resources

• pRouters typically

distinguish between

different hardware

types and, in that

instance, cannot

transfer management

of underlying

pSwitches

Entities in the same layer, self-

manage.

Under certain constraints, they

are able to transfer management

of lower-level components, and

thus self-organize.

Re-organizing strategies are

designed to maximize the

functional requirements of the

applications and the non-

functional requirements of the

system.





@_cloudlightning

vRack Manager Types and Groups

vRack Managers are typed to

reflect differences in the CL-Resources under their control

constrain how vRack Manager Groups are formed and self-organized

leverage resource specific optimization opportunities resulting from grouping

vRack Managers together





@_cloudlightning

Towards a

Dynamic

Filtering

Mechanism

• Allow weights to

change dynamically

to reflect evolving

conditions and

concerns

• Facilitate scalability

with increasing host

population size and

filtering complexity

Hierarchically Structure the host space to

reflect host properties

Hardware type, co-location on low-latency networks, proximity to storage servers, etc.

Decentralize Resource Management decisions

Dynamically calculate a fitness view

(Perception) per locale and propagate

upwards

Dynamically calculate a driving force (Impetus)

per locale and propagate downwards.

Define a Suitability Index per locale by

combining local Perception and Impetus

Maximize the Suitability Index everywhere





@_cloudlightning

Heterogeneous Resource Fabric (Hardware)-

VRM Level: routing by resource info and SI

pSwitch Level: routing by resource info and SI

pRouter Level: routing by resource info and SI

Cell Manager

Resource

Aggregation

What’s available?

What’s most suitable?

Resource Request

Resource Allocation (locally decided)

Perception

Impetus

Impetus

Impetus

Perception

Perception

Perception

based on

Weighted

Assessment

Functions

Resource

Aggregation

Resource

Aggregation

Functional

Requirements

Non-Functional

Requirements

Resource Request

Resource Request

Resource Request





@_cloudlightning

• Impetus is a vehicle for Directed Evolution

• SI embodies non-functional requirements

– Energy efficiency, management overhead, performance, etc.

• Routing maximizes both the functional

requirements of the application and the non-

functional requirements of the system

• Routing allows for resource selection without

reservation

– a common feature of decentralised selection algorithms

• Routing does not guarantee required resource

directly, but likely after reorganisation.





@_cloudlightning

Booting the Cloud: Dynamically growing the resource fabric of the

CloudLightning Architecture

R

pRouter

pSwitch

vRM

R

R R R R

vRM

… …

pRouter

pSwitch

vRM

R

…

R

pSwitch

pRouter

Cell Manager





@_cloudlightning

Plug and Play





@_cloudlightning

In Conclusion

We contend that

Self-

Organization

facilitates

Separation of the concerns of the IaaS

consumer and the CSP

Creation of a service oriented architecture for

the emerging heterogeneous cloud

Control over energy consumption by improved

IaaS management

Improved service delivery

Leveraging of heterogeneity

Bringing of HPC to the cloud

Resource management in hyper-scale cloud

deployments





@_cloudlightning

CloudLightning Approach

• CloudLightning proposes a novel architecture for

provisioning heterogeneous cloud resources to deliver

services, specified by the user, using a bespoke

service description language.

01

Complexity

CloudLightning uses self-

organisation and self-

management to manage

complexity effectively.

02

Heterogeneous

Resources

CloudLightning was

specifically for

heterogeneous hardware

03

IaaS

Access

04

Energy Efficiency

05

Resource

Utilisation

CloudLightning

uses dynamic

workload and

resource

management to

increase the

efficiency of

resource utilisation.

06

Service

Deployment

The CloudLightning

deployment

mechanism

simplifies the

operational

overhead for non-

technical users

Achieved through

heterogeneous resources,

reducing overprovisioning,

maximising VM/server density

and turning off idle servers

Clear service interface through

separation of concerns between

consumer and

provider.





@_cloudlightning

THANK YOU

John Morrison

[email protected]




self-organisation as a cloud resource management strategy

Technology