Defining Generic Architecture
forCloud Infrastructure as a Service (IaaS)
Provisioning Model
Yuri Demchenko, Cees de Laat
SNE Group, University of Amsterdam
ISGC2011 Conference
22-25 March 2011, Taipei

ISGC2011, 22-25 March 2011

Cloud IaaS Architetcure Framework

1Outline• System and Network Engineering (SNE) Group at
the University of Amsterdam• Basic use case from e-Science• Proposed architectural framework•Infrastructure Services Modeling Framework (ISMF)•

Composable Services Architecture (CSA)•Service Delivery Framework (SDF)• Security aspects in Cloud computing•

Security Services Lifecycle Management (SSLM) model

ISGC2011, 22-25 March 2011

Cloud IaaS Architetcure Framework2System and Network Engineering (SNE) Group atUniversity of Amsterdam••

SNE group is primarily a research group but also supports SNE master education
Main research areas– High speed optical networks• Recent testbed achieved sub-40Gbps at Amsterdam-CERN link

– Information modeling for network and infrastructure services description– Security and generic AAA Authorisation framework (GAAA-AuthZ)•••••

Evolving from client/security model to dynamically provisioned services

Long term research cooperation with SURFnet and GigaPort programs in NL
Re-building own testbed for optical network technologies, Cloud experiments andAAA/Security
Recent and current projects participation – DatGrid, NextGrid, EGEE,Phosphorus, GEYSERS, GEANT3, NOVIInterest to Cloud technologies as an emerging common method to accesscomplex infrastructure services – network and IT resources– Defining architectural framework for Cloud IaaS
– Extending it for infrastructure security services and related security and trust models

ISGC2011, 22-25 March 2011

Cloud IaaS Architetcure Framework

3Use case for Infrastructure Services Provisioning

Cloudinfrastructure
provisioned ondemand

Project based
Cloud Infrastructure

Processed DataSESECE

CECE
Campus A
Visualisation

Project based Collaboratinguser groups located in remote
campuses on data intensive
projects requiring high performancecomputing and rich visualisation

Ctrl&Mngnt
Plane

Specialist
Data
Processing

Campus B
Visualisation

Data Filtering

CECE

CE
CloudSE
CSE
CSE
CSE
CSE
T1

UserGroup A

UserGroup B

Experimental
Data

Campusinfrastructure
includingvisualisation tools

UserUser
Grid CE
Data Filtering

Control &Monitoring

GridStorage T1

Grid VO-A
Sc. Instrument(Manufactrg)

ISGC2011, 22-25 March 2011

GridStorage T0

Grid based core eScience
Infrastructure including
data intensive scientificinstrument

Cloud IaaS Architetcure Framework4

Proposed Architectural Framework for Cloud IaaS
The proposed framework should support on-demand infrastructure services
provisioning and operation•

Infrastructure Services Modeling Framework (ISMF) that provides a basis forthe infrastructure resources virtualisation and management, including description,discovery, modeling, composition and monitoring•

Composable Services Architecture (CSA) that intends to provide a conceptualand methodological framework for developing dynamically configurable virtualisedinfrastructure services•Service Delivery Framework (SDF) that provides a basis for defining the whole
composable services life cycle management and supporting infrastructureservices•(Optionally) Service Control and Management Plane/Framework may be
defined as combination of management functionality in all 3 components•

Security services/infrastructure have a dual role:– Virtual Security Infrastructure - provisioned as a part of virtualised infrastructure– Support normal/secure operation of the whole provisioning framework

ISGC2011, 22-25 March 2011

Cloud IaaS Architetcure Framework

Slide_5

IaaS Abstract ModelVirtual Infrastructure (VI) (operated by VIO1)
VIR2
Application/Service Layer

User/ApplicA

VIR5
VIR4

VIR1

VIR6
VIR3

User/ApplicB

VI Comp & Mngnt Layer (VICM)

Ctrl &Mngnt(Orchestratn)

Composition
Logical Rsr

AAI/Policy
Security

SLC
Metadada

VI Operator
Layer

VIO1

VI/VR Adaptation Layer

VR1

VR2

VR3

VR4

VR5

VR6

VI Provider
Layer(VR/LR Layer)

VIProvider1

Logical Abstraction Layer

VIProvider2
PI Provider
Layer

Pi/PR Adaptation Layer
ResourceConfig

SLA/SLM

Security
Context(PR Layer)
PIP1

PIP2

ND-PIP1

ND-PIP2

PIP3

PIP4

Pi/PR Layer

LegendUserND-A
ND* - Network Domain
VIR* - VI Resource (deployed)
VR – Virtual Resource
LR – Logical Resource
PR – Physical Resource

ISGC2011, 22-25 March 2011

ND-PIP3-PIP4

UserND-B

ND-VIP2

ND-VIP1
ND-VIO1Cloud IaaS Architetcure Framework

6Virtual Infrastructure Composition and Management(VICM) Layer Operation•Main actors involved into provisioning process– Physical Infrastructure Provider (PIP)– Virtual Infrastructure Provider (VIP)– Virtual Infrastructure Operator (VIO)•

Virtual Infrastructure Composition and Management (VICM) layer includes– VICM middleware - defined as CSA– Logical Abstraction Layer and the VI/VR Adaptation Layer facing correspondingly lower
PIP and upper Application layer.

•The infrastructure provisioning process includes the following main SDF stages
–––––

•

(1) virtual infrastructure creation request(2) infrastructure planning and advance reservation;(3) infrastructure deployment including services synchronization and initiation;(4) operation stage(5) infrastructure decommissioning

VICM redefines Logical Infrastructure Composition Layer (LICL) proposed byGEYSERS project–

Basic functionality is implemented as GEMBus/CSA

ISGC2011, 22-25 March 2011

Cloud IaaS Architetcure Framework

7ISMF – Virtual Resource Lifecycle
Network Segment
Network Segment

VRs{LR0} -> LR2
Planning
Composition
Reservation

Composed

LRs

Registered.

PRs

Physical Resource

PR-LR1
Config&InstantiationLR0
Re-usable(Published)
PRs
PIP1

ISGC2011, 22-25 March 2011

Virtual Infrastructure

Deployed

Logical Resource

LR2 -> VR
VI Deployment

Virtual Resource

Network Segment

Topology Pool

PIP2

Cloud IaaS Architetcure Framework

8

ISMF - Relation between PR-LR-VR-VI••

Virtual Resource lifecycle – defines relations between different resource presentations
along the provisioning process
Physical Resource information is published by PIP to the Registry service serving
VICM and VIP–••••

Logical Resource representing PR includes also properties that define possible (topological)
operations on the PR, such as e.g. partitioning or aggregation.

Published LR information presented in the commonly adopted form (using common
data or semantic model) is then used by VICM/VIP composition service to create
requested infrastructure as combination of (instantiated) Virtual Resources andinterconnecting them with the available network infrastructure
Network infrastructure can be composed of a few network segments (from thenetwork topology pool) run by different network providers.
Composed LRs are deployed as VRI/VI to VIP/VIO and as virtualised/instantiated PRLR to PIPResource/service description format considered–––

NDL/NML (Network Description Language / Network Markup Language at OGF)USDL (Unified Services Description Language) at W3C
VXDL infrastructure service request format by INRIAISGC2011, 22-25 March 2011

Cloud IaaS Architetcure Framework

9Composable Services Architecture (CSA)• Defined as middleware for on-demand provisioned
Composable Services• Proposed in the GEANT3 JRA3 Composable
Services project• Implemented as GEMBus (GEANT MultidomainBus)

ISGC2011, 22-25 March 2011

Cloud IaaS Architetcure Framework

10Composable Services Layered Model

Application Layer

Virtualisation Layer
Composition & Orchestration Layer
Logical Abstraction Layer

Messaging Layer
Network&Transport Layer

ISGC2011, 22-25 March 2011

– Application Layer hosts application
related protocols– GEMBus Messaging Infrastructure(GMI) includes• Messaging Layer• Virtualisation(Composition&Orchestration) Layer– Network&Transport Layer should
allow using/binding to standards
communication and security protocol– Composable services are defined as“dynamically re-configuredvirtualised services” according to
OSIMM model

Cloud IaaS Architetcure Framework

Slide_11

Composable Services Architecture – Version 0.13
Composable Services
lifecycle/provisioning
stagesApplications and User Terminals
User
ClientProxy (adaptors/containers) – Composed/Virtualised Services and Resources

Control &Management
Plane(Operation,Orchestration)

Composition
Layer/Serv

Composable Services
Middleware(GEMBus)MD SLC

RegistryLogging(1) Request(2) Composition/Reservation(3) Deployment(4) Operation(5) Decommissioning(ReservationSLANegotiatn)

Security

Logical Abstraction Layer for
Component Services and Resources

Proxy (adaptors/containers) - Component Services and Resources

StorageResources

ComputeResources

Network Infrastructure
Component Services & Resources

ISGC2011, 22-25 March 2011

Cloud IaaS Architetcure Framework

Control/
Mngnt Links

Data Links

Slide_12

Composable Services Lifecycle/Provisioning
Workflow•

Main stages/phases–

Service Request/
SLA Negotiation–Composition/
Reservation
Re-Composition

ServiceLifecycle
MetadataService(SL MD)

Deployment–––•Additional stages–Registr&Synchro
Recovery/Migration

Operation(Monitoring)–Provisiong
SessionManagnt•

Decommissioning

Service Request (including SLAnegotiation)
Composition/Reservation (akadesign)
Deployment, including
Reqistration/Synchronisation
Operation (including Monitoring)
Decommissioning
Re-Composition should addressincremental infrastructurechanges
Recovery/Migration can use SLMD to initiate resources resynchronisation but may require
re-composition

The whole workflow is
supported by the Service
Lifecycle Metadata Service (SLMD)•ISGC2011, 22-25 March 2011

Cloud IaaS Architetcure Framework

Slide_13

Composable Services Architecture – Version 0.13Lifecycle stages workflow
4Serv

UserClient

4 3

4Applications and User Terminals

Serv

Serv

Proxy (adaptors/containers) – Composed/Virtualised Services and Resources132

1Control &ManagementPlane

4(Operation,Orchestration)(1) Request(2) Composition/Reservation(3) Deployment(4) Operation(5) Decommissioning

2
3
Composition Layer/Serv

Composable Services
Middleware(GEMBus/GESB)2MD SLC

Registry

Logging

Security

Composable
Services
lifecycle/provisioni
ng stages(Reservation SLANegotiatn)

MD SLC – Service
Lifecycle Metadata

3 2

GEMBus – GEANT
Multidomain Bus
Logical Abstraction Layer for
Component Services and Resources

3 244

GESB – Geysers ESB

3 2

Proxy (adaptors/containers) - Component Services and Resources

StorageResources

ComputeResources

Network Infrastructure
Component Services & Resources

Control/Mngnt Links

Data Links
ISGC2011, 22-25 March 2011

Cloud IaaS Architetcure Framework

Slide_14

CSA functional elements interaction•(1) Request– User Client -> Control and Management•(2) Composition/ Reservation– Control&Mngnt -> Registry -> Composition/Reservation Serv -> (LogicalAbstract -> Resr Adapters) -> LC Metadata Serv•(3) Deployment– Control&Mngnt -> Composition/Reservation Serv -> (Logical Abstract -> ResrAdapters) -> LC Metadata Serv -> User Client• (4) Operation– User Client -> Control&Mngnt (Orchestration) -> Rsr Adapters ->Virtualised/Composed Applications•(5) Decommissioning– Control&Mngnt -> LC Metadata Serv -> (Logical Abstract -> Resr Adapters)

ISGC2011, 22-25 March 2011

Cloud IaaS Architetcure Framework

Slide_15

GEMBus Infrastructure for Composable Service
GEMBus Component Services
Service 1(CSrvID,SesID)

Service 2

Service 3

Service 4(CSrvID,SesID)(CSrvID,SesID)(CSrvID,SesID)

Message Handling
Routing

Configuration

Interceptors(AspOrient)

GEMBus

GEMBus Messaging
Infrastructure (GMI)GEMBusRegistry

Composition &Orchestration

Security ServiceLogging Service

GEMBus Infrastructure Services

GEMBus provides common dynamically configurable messaging infrastructure for
Composable services communication
ISGC2011, 22-25 March 2011

Cloud IaaS Architetcure Framework

Slide_16

Example Service Composition – Service NX
Service 4(CSrvID,SesID)

UserClient

Composed Service NX(CSrvID,SesID)

Service 3

Service 1

Service 2(CSrvID,SesID)(CSrvID,SesID)(CSrvID,SesID)

Service 4

Composed Service NX(CSrvID,SesID)(CSrvID,SesID)(CSrvID,SesID)

Role and place for
Composition andOrchestration* Composable
services or GEMBus
infrastructure service

UserInterface•

UserClientFrontend
CompSrvNX(CSrvID,SesID)(CSrvID,SesID)

Service 3

Service 1

Service 2(CSrvID,SesID)(CSrvID,SesID)(CSrvID,SesID)

CSrvID, SesID – bind component services into the on-demand provisioned
Composed service NX

ISGC2011, 22-25 March 2011

Cloud IaaS Architetcure Framework

Slide_17

Cloud Security – Problem area and issues• Virtualised services• On-demand/dynamic provisioning• Multi-tenant/multi-user• Multi-domain• Uncontrolled execution and data storage environment– Data protection• Trusted Computing Platform Architecture (TCPA)• Promising homomorphic/elastic encryption• Integration with legacy security services/infrastructure ofthe providers• Integration with the providers business workflow
ISGC2011, 22-25 March 2011

Cloud IaaS Architetcure Framework

18

Current Cloud Security Model• SLA based security model– SLA between provider and user defines the provider responsibility andguarantee– Providers undergo certification– Standard business model• Using VPN and SSH keys generated for user infrastructure/VMs– Works for single Cloud provider•••••Has inherited key management problems
Not easy integration with legacy physical resources
Not scalable
Simple access control, however can be installed by user
Trade-off between simplicity and manageability

ISGC2011, 22-25 March 2011

Cloud IaaS Architetcure Framework

19Security Infrastructure for IaaS
Virtual Infrastructure (VI) (operated by VIO1)
VIR2
Application/Service Layer

VIR5
VIR4

VIR1
User/Applic A(TA0.A)

VIR6
VIR3

VI Comp & Mngnt Layer (VICM)

VIO1 (TA1, DSA)

AAI/Policy
Security

Composition
Logical Rsr

Ctrl & Mngnt(Orchestratn)

VI/VR Adaptation Layer

SLCMetadada

VR1

VI Operator
Layer
TA1.x

DSA
VR2

VR3

VR4

VR5

Logical Abstraction Layer

VIProvider1 (TA2.1)

VIProvider2 (TA2.2)

SLA/
SLM

Security
Context

PIP1(TA3.1)

Pi/PR Layer

Legend- DSA Security Context/
Configuration
TD* - Trust Domains
DSA – Dynamic Security Assoc.
VIR* - VI Resource (deployed)
VR/LR/PR – Virtual/Logical/
Physical Resource

User B
TrustDomain

PIP1(TA3.2)

PIP1(TA3.3)

TD-PIP2

TD-PIP1

PIP1(TA3.4)

FedTD-PIP3-PIP4

VI Provider(VR/LR)
Layer
TA2.x

TA3.x

User B
Trust Domain

TD-VIP2

TD-VIP1
TD/DSA VIO1

Trust links/relations

ISGC2011, 22-25 March 2011

VR6

PI Provider
(PR)
Layer

Pi/PR Adaptation Layer
Resource
ConfigUser/
Applic B(TA0.B)

VIR/VR/LR/PR relations

Cloud IaaS Architetcure Framework

20Security Services Lifecycle Management ModelA) Security Service Lifecycle
SecServ
Request

Resrv
SessionBinding

DeployRtm Bind
Bootstr

Reqistr
Synchron

Operation
Monitoring

Decommis
Key Recycle

Operation
MonitoringDecommissioningB) Service Lifecycle
ServiceRequest(GRI)

Planning
DesignReservation

Deployment

Specific SSLM stages and mechanisms to ensure consistency of the security contextmanagement• Security Service Request that initiates creation of the dynamic security association andmay use SLA security context.
• Reservation Session Binding with GRI (also a part of general SDF/SLM) that provides
support for complex reservation process including required access control and policy
enforcement.
• Registration&Synchronisation stage (as part Deployment stage) that allows binding thelocal resource or hosting platform run-time process ID to the GRI as a provisioning session
ID. Specifically targets possible scenarios with the provisioned services migration orrestoration.
ISGC2011, 22-25 March 2011

Cloud IaaS Architetcure Framework

Slide_21

Relation between SSLM/SLM stages and supporting general andsecurity mechanisms
SLM
stagesRequestDesign/Reservation Development

Deployment

Operation

Decomissioning

Process/Activity

SLA
tiationService/Resource
Composition
Reservation

Composition
Configuration

Orchestration/Session
Management

LogoffAccounting

Nego

Mechanisms/Methods
SLAV

Workflow

Metadata

V(V)VVV

Dynamic
Security
Associatn(V)

VV

AuthZ
SessionContext

V(V)

VLogging

(V)

(V)

V

ISGC2011, 22-25 March 2011

VV

Cloud IaaS Architetcure Framework

VSlide_22

Future developments• Further development of the proposed architecturalcomponents in GEANT3 and GEYSERS projects– Demo at SuperComputing 2011 Conference and exhibition• Dynamically provisioned security infrastructure– Dynamic security association• Contribution to OGF ISOD-RG activity• EU wide cooperation and possible EU project

ISGC2011, 22-25 March 2011

Cloud IaaS Architetcure Framework

23

Acknowledgement•This work is supported by the FP7 EU funded project
GEANT3 (FP7-ICT-238875), and the FP7 EU funded
Integrated project The Generalised Architecture forDynamic Infrastructure Services (GEYSERS, FP7ICT-248657).

ISGC2011, 22-25 March 2011

Cloud IaaS Architetcure Framework

Slide_24

Additional Information• GEYSERS project reference architecture

ISGC2011, 22-25 March 2011

Cloud IaaS Architetcure Framework

Slide_25

GEYSERS Reference Architecture
SC(Service Consumer)

VIO(Virtual InfrastructureOperator)

VIP(Virtual Infrastructure
Provider)PIP(Physical InfrastructureProvider)

Cloud IaaS Architetcure
ISGC2011, 22-25 March 2011Framework

26

GEYSERS Layered Architecture
Control and Management Planes
are defined•

Important for consistent design

Management Interfaces

Control Interfaces

Cloud IaaS Architetcure
ISGC2011, 22-25 March 2011Framework

27

General security services/aspects
 Access Control (including AuthN, AuthZ, IdentityManagement) Trust Management (including key management) Policy Based Management (PBM) Data protection (Confidentiality, Integrity, Access Control)– Communication Security– Privacy (complex of measures and policy based accesscontrol)

ISGC2011, 22-25 March 2011

Cloud IaaS Architetcure Framework

Slide_28

Security Services Lifecycle Management (SSLM) Model•

Security Service request and generation of the GRI that will serve as a provisioning
session identifier and will bind all other stages and related security context.

•Reservation session binding that provides support for complex reservation processincluding required access control and policy enforcement.

•

Deployment stage begins after all component resources have been reserved and includes
distribution of the security context and binding the reserved resources or services to GRI as
a common provisioning session ID.

•Registration&Synchronisation stage (optional) specifically targets possible scenarios withthe provisioned services migration or failover/interruption. In a simple case, the Registration
stage binds the local resource or hosting platform run-time process ID to the GRI as aprovisioning session ID.

•Operation stage - security services provide access control to the provisioned services andmaintain the service access or usage session.

•Decommissioning stage ensures that all sessions are terminated, data are cleaned up andsession security context is recycled.

ServiceRequest(GRI)
ISGC2011, 22-25 March 2011

ReservSession
Binding

Deployment &RsrBindRegistr
Synchro(Opt)

Cloud IaaS Architetcure Framework

Operatn
Access

Decommision

Slide_29

SNE @ UvA take on Cloud technology• Defining architectural framework for Cloud Infrastructure as aService (IaaS) provisioning model– Consistent security architecture can only be built if the main
system/services/infrastructure are well defined• Defining architecture for dynamically configured security
services/infrastructure• OGF On-Demand Infrastructure Service (ISOD) provisioning
BoF/RG– Including definition of IaaS and required security models

ISGC2011, 22-25 March 2011

Cloud IaaS Architetcure Framework

30