Tnc2011 Isod Bof Cloud Iaas Architecture v01

Defining Generic Architecture
for
Cloud Infrastructure as a Service (IaaS)
Provisioning Model
Yuri Demchenko
SNE Group, University of Amsterdam

ISOD BoF at TNC2011
16 May 2011, Prague
ISOD BoF @ TNC2011 Cloud IaaS Architetcure Framework 1
Outline
Background projects
SNE Cloud research directions
Generic Cloud IaaS architecture
InterCloud (OS/Middleware)
Security Infrastructure for Cloud (dynamically provisioned)
Proposed architectural framework
Infrastructure Services Modelling Framework (ISMF)
Composable Services Architecture (CSA)
Service Delivery Framework (SDF)
Defining Security Infrastructure for Clouds
Security aspects in Cloud computing
Dynamic Access Control Infrastructure (DACI)
Future work
Architecture components development
Architectures/models matching NIST, OASIS, DMTF, etc.
System and Network Engineering (SNE) Group at
the University 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 and
AAA/Security
Recent and current projects participation DatGrid, NextGrid, EGEE,
Phosphorus, GEYSERS, GEANT3, NOVI
Research on Clouds as an emerging common method to provision and access
complex infrastructure services combining network and IT resources
Defining architectural framework for Cloud IaaS
Extending it for Cloud Security infrastructure and defining basic security and trust
models
Use case for Infrastructure Services Provisioning
Project based collaborating
user groups located in remote
campuses on data intensive
projects requiring high performance
computing and rich visualisation
Campus
infrastructure
including
visualisation tools
Control &
Monitoring
Sc. Instrument
(Manufactrg)
Grid
Storage T1
Grid CE
Data Filtering
Grid
Storage T0
Grid VO-A
Visuali-
sation
User
Group A
User
CE
Campus A
Visuali-
sation
User
CE
User
Group B
Campus B
CE CE CE
SE SE
CSE CSE CSE CSE
CloudSE
T1
CE
Processed Data
Experimental
Data
Specialist
Data
Processing
Project based
Cloud Infrastructure
Data Filtering
Ctrl&Mngnt
Plane
Grid based core e-Science
Infrastructure including
data intensive scientific
instrument
Cloud
infrastructure
provisioned on
demand
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 for
the infrastructure resources virtualisation and management, including description,
discovery, modeling, composition and monitoring
Composable Services Architecture (CSA) that intends to provide a conceptual
and methodological framework for developing dynamically configurable virtualised
infrastructure services and Cloud middleware
Service Delivery Framework (SDF) that provides a basis for defining the whole
composable services life cycle management and supporting infrastructure
services
(Additionally) Service Control and Management Plane/Framework may be
defined as a combination of management functionality in all 3 components
(Additionally) Security services/infrastructure have a dual role:
Virtual Security Infrastructure - provisioned as a part of virtualised infrastructure
Support secure operation of the whole provisioning framework
ISOD BoF @ TNC2011 Cloud IaaS Architetcure Framework Slide_5
IaaS Abstract Model
User/
Applic
B
User/
Applic
A
VIR3
VIR4
VIR5
VIR6
VIR2
VIR1
VI Operator
Layer
PIP1 PIP2 PIP4 PIP3
Virtual Infrastructure (VI) (operated by VIO1)
VIProvider2
ND-PIP1
ND-VIP1
ND-PIP2 ND-PIP3-PIP4
ND-VIP2
ND-VIO1
UserND-A UserND-B
PI Provider
Layer

(PR Layer)
VI Provider
Layer

(VR/LR Layer)
VIProvider1
VI/VR Adaptation Layer
Pi/PR Adaptation Layer
Pi/PR Layer
C
o
m
p
o
s
i
t
i
o
n

L
o
g
i
c
a
l

R
s
r
AAI/Policy
Security
SLC
Metadada
Application/Service Layer
C
t
r
l

&

M
n
g
n
t

(
O
r
c
h
e
s
t
r
a
t
n
)

Logical Abstraction Layer
Security
Context
Resource
Config
VI Comp & Mngnt Layer (VICM)
VR1 VR3 VR4 VR5
VR6 VR2
VIO1
SLA/
SLM
Legend
ND* - Network Domain
VIR* - VI Resource (deployed)
VR Virtual Resource
LR Logical Resource
PR Physical Resource
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 by
GEYSERS project
Basic functionality is implemented as GEMBus/CSA
ISMF Virtual Resource Lifecycle
{LR0} -> LR2
Planning
Composition
Reservation
LR2 -> VR
VI Deployment
P
h
y
s
i
c
a
l

R
e
s
o
u
r
c
e

L
o
g
i
c
a
l

R
e
s
o
u
r
c
e

V
i
r
t
u
a
l

R
e
s
o
u
r
c
e

Network Segment
Network Segment
LR0
Re-usable
(Published)
PRs
Topology Pool
Network Segment
PR-LR1
Config&
Instantiation
Registered PRs
Composed LRs
Deployed VRs .
V
i
r
t
u
a
l

I
n
f
r
a
s
t
r
u
c
t
u
r
e

PIP1
PIP2
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 and
interconnecting them with the available network infrastructure
Network infrastructure can be composed of a few network segments (from the
network topology pool) run by different network providers.
Composed LRs are deployed as VRI/VI to VIP/VIO and as virtualised/instantiated PR-
LR to PIP
Resource/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 INRIA

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 Multidomain Bus)
Composable Services Layered Model
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-configured
virtualised services according to
OSIMM model for SOA
Application Layer
Virtualisation Layer
Messaging Layer
Network&Transport Layer
Composition & Orchestration Layer
Composable Services Architecture Version 0.13
Applications and User Terminals
Composition
Layer/Serv

(Reservation
SLA
Negotiatn)
Logical Abstraction Layer for
Component Services and Resources
Control &
Management
Plane

(Operation,
Orchestration)
Composable Services Middleware
(GEMBus)
Network Infrastructure
Compute
Resources
Storage
Resources
Component Services & Resources
Proxy (adaptors/containers) - Component Services and Resources
Proxy (adaptors/containers) Composed/Virtualised Services and Resources
MD SLC

Registry

Logging

Security

User
Client
Composable Services
lifecycle/provisioning
stages
(1) Request
(2) Composition/
Reservation
(3) Deployment
(4) Operation
(5) Decommissioning
Control/
Mngnt Links
Data Links
Composable Services Lifecycle/Provisioning
Workflow
Main stages/phases
(1) Service Request (including SLA
negotiation)
(2) Composition/Reservation (aka
design)
(3) Deployment, including
Reqistration/Synchronisation
(4) Operation (including
Monitoring)
(5) Decommissioning
Additional stages
Re-Composition should address
incremental infrastructure
changes
Recovery/Migration can use SL-
MD to initiate resources re-
synchronisation but may require
re-composition
The whole workflow is
supported by the Service
Lifecycle Metadata Service (SL
MD)

Service Request/
SLA Negotiation
Composition/
Reservation
Deployment
Operation
(Monitoring)
Decommissioning
Registr&Synchro
Recovery/
Migration
Re-Compo
sition
Service
Lifecycle
Metadata
Service
(SL MD)
Provisiong
Session
Managnt
Composable Services Architecture Version 0.13
Lifecycle stages workflow
Composable Services
lifecycle/provisioning
stages
(1) Request
(2) Composition/
Reservation
(3) Deployment
(4) Operation
(5) Decommissioning

MD SLC Service
Lifecycle Metadata

GEMBus GEANT
Multidomain Bus

GESB Geysers ESB
Control/
Mngnt Links
Data Links
Applications and User Terminals
Composition
Layer /Serv

(Reservation
SLA
Negotiatn)
Logical Abstraction Layer for
Component Services and Resources
Control &
Management
Plane

(Operation,
Orchestration)
Composable Services
Middleware
(GEMBus/GESB)
Network Infrastructure
Compute
Resources
Storage
Resources
Component Services & Resources
Proxy (adaptors/containers) - Component Services and Resources
Proxy (adaptors/containers) Composed/Virtualised Services and Resources
MD SLC

Registry

Logging

Security

User
Clien
t
1
1
2
2
2
2
2
3
3
3
3
3
3 4
2
4
4
4
4
4
Serv
Serv
Serv
CSA functional elements interaction
(1) Request
User Client -> Control and Management
(2) Composition/ Reservation
Control&Mngnt -> Registry -> Composition/Reservation Serv -> (Logical
Abstract -> Resr Adapters) -> LC Metadata Serv
(3) Deployment
Control&Mngnt -> Composition/Reservation Serv -> (Logical Abstract -> Resr
Adapters) -> 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)
GEMBus Infrastructure for Composable Service
GEMBus provides common dynamically configurable messaging infrastructure for
Composable services communication
GEMBus Infrastructure Services
GEMBus Component Services
Service 2
(CSrvID,
SesID)
GEMBus
Registry
Composition &
Orchestration
Logging Service
Service 1
(CSrvID,
SesID)
Service 3
(CSrvID,
SesID)
Service 4
(CSrvID,
SesID)

GEMBus
GEMBus Messaging
Infrastructure (GMI)
Routing
Configur
ation
Interceptors
(AspOrient)
Security Service
Message Handling
Example Service Composition Service NX
CSrvID, SesID bind component services into the on-demand provisioned
Composed service NX
Role and place for
Composition and
Orchestration

* Composable
services or GEMBus
infrastructure service
UserClient

(CSrvID,SesID)
Service 4
(CSrvID,SesID)
Service 3
(CSrvID,SesID)
Service 1
(CSrvID,SesID)
Service 2
(CSrvID,SesID)
UserClient

(CSrvID,SesID)
Frontend
CompSrvNX
(CSrvID,SesID)
Service 4
(CSrvID,SesID)
Service 3
(CSrvID,SesID)
Service 1
(CSrvID,SesID)
Service 2
(CSrvID,SesID)
Composed Service NX
(CSrvID,SesID)
Composed Service NX
(CSrvID,SesID)
User
Interface
Defining Security Infrastructure for Clouds
Security aspects in Cloud computing
DACI implementation in GEYSERS for infrastructure services
(network + IT) provisioning on demand

General security services/aspects
Access Control (including AuthN, AuthZ, Identity
Management)
Trust Management (including key management)
Policy Based Management (PBM)
Data protection (Confidentiality, Integrity, Access Control)
Communication Security
Privacy (complex of measures and policy based access
control)
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 of
providers
Integration with the providers business workflow

Current Cloud Security Practice
SLA based security model
SLA between provider and user defines the provider responsibility and
guarantee
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
Emerging Cloud Security Models
Former (legacy): Provider - User/Customer
New Cloud oriented security provisioning models
Provider - Customer - User
Enterprise as a Customer, and employees as Users
Provider Operator (Broker) - Customer User
Application area IT/telco company serves as an Operator for
application services infrastructure created for customer company
Security issues/problems in new security
provisioning models
Integration of the customer and provider security services
Identity Management and Single Sign On (SSO)
Identity provisioning for dynamically created Cloud based
infrastructure or applications
Security Infrastructure for IaaS
Dynamic Security Association (DSA)
User/
Applic B
(TA0.B)
User/
Applic A
(TA0.A)
VIR3
VIR4
VIR5
VIR6
VIR2
VIR1
VI Operator
Layer
TA1.x
PIP1(TA3.1)
Virtual Infrastructure (VI) (operated by VIO1)
TD-PIP1
TD-VIP1
TD-PIP2 FedTD-PIP3-PIP4
TD-VIP2
TD/DSA VIO1
User B
Trust Domain
PI Provider
(PR)
Layer

TA3.x
VI Provider
(VR/LR)
Layer

TA2.x
VI/VR Adaptation Layer
Pi/PR Adaptation Layer
Pi/PR Layer
C
o
m
p
o
s
i
t
i
o
n

L
o
g
i
c
a
l

R
s
r

AAI/Policy
Security
SLC
Metadada
Application/Service Layer
C
t
r
l

&

M
n
g
n
t

(
O
r
c
h
e
s
t
r
a
t
n
)

Security
Context
Resource
Config
VI Comp & Mngnt Layer (VICM)
VR1 VR3 VR4 VR5
VR6 VR2
VIO1 (TA1, DSA)
SLA/
SLM
PIP1(TA3.2) PIP1(TA3.3) PIP1(TA3.4)
User B
Trust
Domain
DSA
Legend
- DSA Security Context/
Configuration
TD* - Trust Domains
DSA Dynamic Security Assoc.
VIR* - VI Resource (deployed)
VR/LR/PR Virtual/Logical/
Physical Resource
VIProvider1 (TA2.1) VIProvider2 (TA2.2)
Trust links/relations
VIR/VR/LR/PR relations
Security Context management during provisioning
VIO VIP VIP DACI/AAI
VI reservation request
(including VIO TA1)
AuthZ request (VI-GRI)
PIP(s)
Mapping from the returned
PR-LRI to VR-GRI for VIP
Reserve complex
resource at PIP(s) in
daisy-chain mode or
concurrent mode
VR reservation request
(including VIP TA2)
Reservation confirmation
with PR-LRI of committed PR
VI reservation response with a
VI-GRI and set of VR-GRI(s)
Generate a VI-GRI
PIP AAI
AuthZ request (PR-LRI)
User/Applicatn
VI/VR Request (TA0)
SLA Negotiation
SDF Stages
VRs . PRs
DACI
Deployment stage VI/VR Configuration, DACI configuration and Security context distribution
Operation stage VI/VR Management, Monitoring, DACI operation and security context management
Dec``ommissioning stage VI/VR teardown, resources release, security context recycling
SLA Negotiation
Planning,
Reservation
Deployment,
Activation
Operation
Decommissioning
Generate GRI
Return GRI
Lifecycle stages
(1) Request (GRI, UserID, VIO-ID,
(SLA))
(2) Reservation (Reservation session,
SecContext)
(3) Deployment (DSA creation,
configuration)
(4) Operation (Access Session,
SecContext)
(5) Decommissioning (DSA, Creds/key
recycle, Sessions termination)

VIO VIP VIP DACI/AAI
VI reservation request
(including VIO TA1)
PIP(s)
Mapping from the returned
PR-LRI to VR-LRI for VIP
Reserve
complex
resource at
PIP(s) in
daisy-chain
mode or
concurrent
mode
VR reservation request (including VIP TA2)
Reservation confirmation with
PR-LRI of committed PR
VI reservation response with a
VI-GRI and set of VR-LRI(s)
Generate a VI-GRI
PIP AAI
AuthZ request (PR-LRI)
User/Applicant
VI/VR Request (TA0)
SLA Negotiation
SLA Negotiation
Planning,
Reservation
Generate
GRI
Return GRI
VI deployment/activation
request
DACS instantiate
(VI-GRI)
Deploy VRs at the PIP (PR-LRIs)
Deploy VRs at
PIP(s) in daisy-
chain mode or
concurrent mode VR deployment response
VI deployment notification
VI deployment notification
Deployment,
Activation stage
VI/VR Configuration,
DACI configuration
and Security context
distribution
VR DACS
PR
Access VR(PR-LRI)
Access PR
Access VR(VR-LRI)
Authz request (VR-LRI)
Authz response
Operation
Decomission VI (VI-GRI)
Decommision VRs at the PIP (PR-LRIs)
For each PIP
providing VRs of
the VI
Decomission DACS (VI-GRI)
Decomission VI notification
Decomission VI notification
Decommissioning
VI/VR teardown,
resources release,
security context
recycling
VI/VR Management,
Monitoring, DACI
operation and
security context
management
Decomission VR notification
DACI at (2) Reservation stage
Operated with AAI of VIO, VIP, PIP
Collect and distribute components Trust Anchors
DACI at (3) Deployment stage
DACI created: configured, bootstrapped, initiated
DACI at (4) Operation stage
AuthN/AuthZ services of VI operated by DACI
PIP AAI either
DACI at (5) Decommissioning stage
Sessions termination, global sign-out/logout
Key recycle, session credentials invalidation, cache purge
AAI in GEYSERS
Basic CSSI services
Data encryption
Digital signature
Authentication
Authorization
Policy management
Security session and context
management

Called from services (or part of
core interfaces)
SLI (SML-LICL)
CCI (NCP-LICL)
NLI (NCP-LICL)
LPI (LICL-PHY)
NIPS-UNI
SML
NCP
LICL
VITM
NIPS Server
CCI
NIPS-UNI
SLI
NLI
PHY
LPI
G
E
Y
S
E
R
S

S
e
c
u
r
i
t
y

(
A
A
I
)

CSSI
PEP: Policy Enforcement Point
PDP: Policy Decision Point
PAP: Policy Administration Point
DACS: Dynamic Access Control Service
AAI Reference Model (GEYSERS)
AuthN
Service
PDP
PAP
AuthN DB
Token Validation
Service (TVS)
SecCtx Handler
AAI Gateway
PEP
Dyn AC
Service
Mngnt

Common Security Services Interface (CSSI)
Config,
Attr
Trust/Key
Mngnt
Implementation suggestions (GEYSERS DACI)
Extend GAAA-Toolkit library to support dynamic Security/AAI
infrastructure creation and integration with provisioned VI
Provides GAAA Authorisation API (GAAAPI) functions with extended
AuthZ and session management functionality
Support for SDF workflow and Security Services Lifecycle Mngnt
Needs general infrastructure services such as Metadata SLM
Define and implement Common Security Service Interface (CSSI)
Supports both internal applications calls and Web service integration via
Spring security
Implements GSS-API and extends it with GAAAPI functionality
Use standard Messaging, Transport and Network security
mechanisms provided by implementation platform
Implementation platform specific ESB/WS/SOA (Fuse, Apache
ServiceMix, etc.)
Future Research
Architectures/models matching
First, which are on the standard track
NIST, OASIS, DMTF, IETF
Next, proposed by industry and consortia
IBM, Cisco, Juniper, Extreme Networks
Basic terms and concepts definition/re-visiting
Dynamic vs On-Demand
Infrastructure services vs (Computer) Services
ISMF definition
Planned Activities
Further development of the proposed architectural
components 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
Next meeting OGF32 Salt Lake City, USA (16-18 July 2011), OGF33
Lyon, France (19-23 September 2011)
CloudCom2011 Conference November 29 December 2,
2011, Athens
Focus on Cloud Architecture research
EU wide cooperation and possible new EU projects
Additional Information
Security Services Lifecycle Management (SSLM)
model

Security Services Lifecycle Management Model
Specific SSLM stages and mechanisms to ensure consistency of the security context
management
Security Service Request that initiates creation of the dynamic security association and
may 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 the
local 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 or
restoration.
Service
Request
(GRI)
Planning
Design
Reservation
Deployment
Operation
Monitoring
Decom-
missioning
Operation
Monitoring
Decommis
Key Recycle
Resrv
Session
Binding
SecServ
Request
Deploy
Rtm Bind
Bootstr
Reqistr
Synchron
B) Service Lifecycle
A) Security Service Lifecycle
Relation between SSLM/SLM stages and supporting general and
security mechanisms
SLM
stages
Request Design/Reservatio
n Development
Deployment Operation Decomissio
ning
Process/
Activity
SLA Nego
tiation
Service/ Resource
Composition
Reservation
Composition
Configuration
Orchestration/
Session
Management
Logoff
Accounting
Mechanisms/Methods (M mandatory; O - optional)
SLA
M M
Workflow
(O) M
Metadata
M M M M
Dynamic
Security
Associatn
(O) M M
AuthZ
Session
Context
M (O) M
Logging
(O) (O) M M

Tnc2011 Isod Bof Cloud Iaas Architecture v01

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Tnc2011 Isod Bof Cloud Iaas Architecture v01

Hochgeladen von

Copyright:

Verfügbare Formate

Defining Generic Architecture

Das könnte Ihnen auch gefallen