VISION Cloud:
Highlighting challenges on Federation
&
Interoperability for data storage cloud
Massimo Villari
University of Messina, Italy
OGF 35
June 17-19, 2012 Delft, Netherlands
2 VISION Cloud
OUTLINE
Data lock-in Issue
VISION Cloud aims
Standards:
–
NIST
–
SNIA
Federation Concepts:
–
For SNIA
–
For VISION Cloud
VISION Cloud Solutions: Working In Progress (WIP)
The challenge: Avoid data lock-in
[Above the Clouds: A Berkley View of Cloud Computing] [L. Willcocks, W. Venters, E. Whitley - Accenture]
[Randy Bias – VP Technology Strategy of GoGrid, ServePath] [CeBIT 2011]
[M. Malek - Google]
Change storage providers without data lock-in
User’s View of his/her Storage
Provider A Provider B
VISION Cloud: Federation and Interoperability
5 VISION Cloud
6 VISION Cloud
7 VISION Cloud
Cloud Federation
Hybrid Cloud
Commercial
Cloud
Open Cloud
Three types of Clouds
Open (free contribution)
Commercial (by charge)
Hybrid (open/commercial)
The clouds can interoperate
A federation is composed of two or more Clouds that
interoperate according to specific rules
A Cloud federation has different access points for users
interaction
SNIA: Cloud Data Management Interface (CDMI™)
SNIA
goals:
To Enable
Cloud to
Cloud
Use
(Federation
)
To Provide a
Standard Interface
for Clients to
communicate with
Storage Clouds
To Provide a
Standard
Approach for
Adding Vendor
Specific
Functionality
without breaking
clients
compatibility
9 VISION Cloud
Federation Terminology for SNIA
Federation
Peering
Proxying
Federation Initiator
Federation Target
Target
Initiator
10 VISION Cloud
Federation for SNIA: 4 Use Cases
Unidirectional Proxy Federation (Use Cases 1 and 2):
–
CDMI Domains Cloud Federation
–
Non-CDMI Cloud Federation (it has a CDMI proxy)
(Concepts of ID Preserving and NON-ID Preserving)
Unidirectional Peering Federation (Use Case 3):
–
Initiator Cloud CDMI Read/Write
–
Target Coud CDMI Read Only
(Concept of ID Preserving)
Bidirectional Peering Federation (Use Case 4):
–
Initiator Cloud CDMI Read/Write
–
Target Coud CDMI Read/Write
11 VISION Cloud
VISION Cloud different approaches for Federation
Motivations
:
VISION Cloud has to develop a complete Architectural
Stack. To this, its interface is CDMI compliant but it is
looking at
moreover
.
It strongly relies on the Tenant concept. Business between
Tenants and VISION Cloud Providers has to be
guaranteed.
12 VISION Cloud
Data Model
DATA OBJECT
:
An object consists of data and metadata. Objects are contained by containers, which can also have metadata associated with them.
A storlet is a computation that executes safely and securely on objects in a container. Data objects are contained in containers. Each data object resides within the context of a single container.
CONTAINERS
serve the following purposes: Data management. Containers serve as an aggregation point for grouping related data objects together.
Policies can be set on a container basis and are applied to all of the objects in the container, for example, whether the container supports the versioning of its objects.
Isolation. Containers divide the namespace at the highest level, and provide isolation between the objects in a container from the objects in other containers.
Internal management. Containers are the unit of placement, which reduces the frequency of making global placement decisions. This also reduces the size of location information that
has to be retained globally, and helps in routing client requests efficiently to the right cluster in the cloud.
13 VISION Cloud
Account Model
Tenants and users:
A tenant is an organization that subscribes for and receives storage cloud services. A tenant may represent a commercial firm, a governmental organization, or any other organization,
including any group of one or more individual persons. Tenants have the following characteristics:
– A tenant is the unit that subscribes to storage cloud services. It signs a service level agreement, and it is billed for the service it receives according to agreed pricing and usage.
– A tenant requires a certain level of isolation from other tenants in terms of security and resource allocation. The level of isolation that the tenant receives from VISION Cloud is defined as part of the tenant’s SLA.
– A tenant defines a set of users that belong to it. (More on users of the next slide.)
– Each tenant has its own set of users and its own namespace for its containers.
– A tenant may also define additional tenants that belong to it – this could be recursive, although in practice we do not expect more than two levels. Such a child tenant could represent a department within an organization, or it could be an independent
organization to which the parent tenant provides storage cloud services. It is referred to a child tenant as a sub-tenant.
– A parent tenant is billed for the storage services consumed by its child tenant.
Otherwise, a child tenant is independent of its parent tenant and is a tenant in its own right with its own characteristics: its own SLAs, isolation from other tenants, its own set of users and its own namespace for its containers.
14 VISION Cloud
Account Model
Tenants and users: A user is:
the entity that actually uses (consumes) VISION Cloud’s storage services. The term ’user’ may refer to a person or to an application/program. A user belongs to one and only one
tenant. We note that a person might own a user account in more than one tenant, but this is opaque to VISION Cloud. A tenant administrator creates users and manages them.
A user has an identifier (unique within its tenant) and may have credentials allowing it to authenticate itself to VISION Cloud.
Containers are replicated on of a collection of
clusters in geographically distributed data centers
Cluster/
Data
Center
Tenants’ logical view
End-users manage containers and objects by
setting system attributes
Extra
Resilience
Versioning
Tenant j’s logical viewKeep
in EU
Retain
until
1-Jan-2015
17 VISION Cloud
Federation Model
In VISION the Federation is defined to be the process by which two systems
establish a trusted connection to exchange content via a predefined protocol. In
such a federation relationship, there is a system that initiates operations, the that
is the
Federation Initiator
, and a system that executes operations, the
Federation Target
.
A VISION Cloud can federate with other VISION Clouds, which also support
object stores with advanced metadata capabilities or alternatively a VISION Cloud
may federate with other storage clouds that provide more basic capabilities.
VISION Cloud supports two storage cloud federation models:
1.
Resource Federation and
2.
On-boarding Federation.
It also supports identity federation to allow a tenant to have its users
authenticated by it rather than by VISION Cloud.
18 VISION Cloud
Resource Federation
In Resource Federation, a
tenant
works with a cloud (its role will be
the
Initiator cloud
in the federation):
The Initiator cloud can decide to purchase storage services from
one or more Target clouds.
The federation between the Initiator and Target clouds is
transparent to the tenant.
The tenant’s users always direct their requests to the Initiator and
are unaware of the federation. (SNIA: Unidirectional Proxying)
To achieve better performance, the Initiator cloud may in response
to a user request that refers to an object on the Target cloud,
redirect the client to perform the request on the Target cloud
directly.
19 VISION Cloud
Resource Federation motivations
There can be various reasons for resource federation:
the Target cloud may have data centers/clusters closer to the
tenant; the Initiator cloud might be running low on resources;
the Target cloud might provide a storage service (e.g., long-term
archiving) that the Initiator cloud does not support, etc.
the Initiator cloud is a private cloud and that the Target clouds are
community or public clouds;
an Initiator cloud might access a Target cloud, the Initiator creates a
tenant for itself on the Target, in advance. All accesses from Initiator
to Target Cloud will be done via this tenant . This allows the Target
cloud to perform accounting and billing for the Initiator cloud.
20 VISION Cloud
Resource Federation NON simple management
NO ADMIN/SUPERUSER
NO BACKUP_OPERATOR
21 VISION Cloud
On-Boarding Federation: toward VISION Cloud
On-boarding Federation assists a customer who wishes to migrate his existing
storage data from one cloud to another. In on-boarding a tenant that is a customer of
one provider decides to move to a new provider.
The new provider is the Initiator of the federation and the old provider is the Target of
the federation.
The tenant starts working with the new provider, the new provider provides a unified
view of the tenant’s storage across the old provider and the new provider, and
meanwhile the new provider moves the tenant’s storage from the old provider to the
new provider (all the while providing a single view).
The new provider is always a VISION Cloud.
The old provider can be a VISION Cloud or
some other cloud type, e.g., S3,
Google Drive
.
During on-boarding the amount of storage to migrate could be very large and the
migration time could be very long. It is important to provide a tenant’s users
22 VISION Cloud
Identity Federation between tenant and VISION Cloud
A tenant will often want to use its own IDP (Identity Provider) to hold
the credentials for it users and authenticate them, rather than having
them registered and authenticated with the IDP of the VISION cloud.
This is facilitated by an Identity Federation between the IDP of the
tenant and the IDP of VISION Cloud.
Identity Federation Manager
SAML Based: specific for VISION Cloud
Services
On-Boarding from NON-VISION Cloud
Provider: OAUTH? OpenID?
24 VISION Cloud
