VISION Cloud: Highlighting challenges on Federation. Interoperability for data storage cloud. OGF 35 June 17-19, 2012 Delft, Netherlands

Transcription

1 OGF 35 June 17-19, 2012 Delft, Netherlands : Highlighting challenges on Federation & Interoperability for data storage cloud Massimo Villari University of Messina, Italy

2 OUTLINE Data lock-in Issue aims Standards: NIST SNIA Federation Concepts: For SNIA For Solutions: Working In Progress (WIP) Conclusions and Hints for Future Works 2

3 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] 3

4 : Federation and Interoperability Change storage providers without data lock-in Provider A Provider B User s View of his/her Storage

5 NIST Cloud Computing New Reference Architecture 5

6 NIST Cloud Computing New Reference Architecture 6

7 Cloud Federation Three types of Clouds Open (free contribution) Commercial (by charge) Hybrid (open/commercial) The clouds can interoperate Hybrid Cloud Commercial Cloud Open Cloud 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 7

8 SNIA: Cloud Data Management Interface (CDMI ) SNIA goals: 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 To Enable compatibility Cloud to Cloud Use (Federation

9 Federation Terminology for SNIA Federation Peering Proxying Federation Initiator Federation Target Initiator Target 9

10 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 (Concept of ID Preserving) 10

11 different approaches for Federation Motivations: 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 Providers has to be guaranteed. 11

12 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. There is no nesting or hierarchy of containers 12

13 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 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. 13

14 Account Model Tenants and users: A user is: the entity that actually uses (consumes) 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. 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. 14

15 Containers are replicated on of a collection of clusters in geographically distributed data centers Tenants logical view Cluster/ Data Center

16 End-users manage containers and objects by setting system attributes Retain until 1-Jan Keep in EU Tenant j s logical view Extra Resilience Versioning

17 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 can federate with other s, which also support object stores with advanced metadata capabilities or alternatively a may federate with other storage clouds that provide more basic capabilities. 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. 17

18 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. 18

19 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. 19

20 Resource Federation NON simple management NO ADMIN/SUPERUSER NO BACKUP_OPERATOR Different Approach of SNIA Directives 20

21 On-Boarding Federation: toward 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. The old provider can be a 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 continuous access to their storage during the course of the migration process. 21

22 Identity Federation between tenant and 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. 22

23 Identity Federation Manager SAML Based: specific for Services On-Boarding from NON- Provider: OAUTH? OpenID?

24 Conclusions Federation for SNIA VISION has a more complex approach respect to the SNIA Peering VISION adopts the concept of SNIA Proxying Common Terminology Federation Initiator Federation Target 24

25 Hints for New Research Works (WIP)

26 Thank You Visit our Website: Massimo Villari University of Messina, Italy