Revision as of 16:42, 8 July 2014

Inter Cloud Resource Federation (Alliance)

arvind "dot" tiwari "at" HP "dot" com

Cloud based services are growing business trend in the IT industry, where service providers establishes cloud and offers computing resources (Infrastructure, Platform and Software) to consumers. Consumers often require computing resources across multiple regions, to address their application needs. Single cloud provider may not be able to address such requests due to lack of presence or capacity in multiple regions. This blueprint proposes a solution to address this concern by introducing a concept of Inter Cloud Resource Federation (a.k.a. Inter Cloud Federation). Using this technical approach multiple cloud entities can work in alliance to form a bigger cloud entity with massive resource capacities.

Problem

This blueprint is trying to address following problems

Multi Region Capability

Enterprises are adopting cloud based service to address their growing computing workload and they often want resources across multiple regions. These regions sometimes span across multiple geographical boundaries.

Single provider may not be able to address such requests as setting up huge cloud across multiple regions is a costly and risky investment. Providers often want to lease resources from other provider cross regions to fulfill customer computing workload.

Virtual Private Cloud or Cloud Leasing

Vendors want to be in cloud business to lease resources to other service providers or customers who want have VPC (or Reseller). Unlike other service providers these vendors want to target bigger consumers.

Cloud service provider has idle computing resources which are not making revenue. Service provider wants to lease these resources to another provider who is in need of these resources.

Cloud Bursting

In private cloud deployments enterprises want to bursts into a public/separate cloud when the demand for computing capacity spikes.

Joint Venture Cloud

Setting up Cloud with massive resource capacity is time consuming and very costly venture, not everyone would like to invest in such a big venture. Business partners like to invest in a joint venture to make a bigger cloud entity with massive resources capacity.

Merger and Acquisitions

Merger of business entities are common, integration/utilization of cloud enabled computing resources of two business enterprises are troublesome due to lack of technology. An enterprise expects seamless integration of two cloud entities after merger with anticipation of effective and prompt resource utilization.

Expensive Architecture

Building multi region architecture to join multiple data centers using dedicated/leased lines is costly and creates tight coupling. This solution is also not an scalable solution for incremental growth.

Solution

OpenStack provides an open source cloud computing platform which is getting huge industry adoption for building up private/public/hybrid cloud. OpenStack based cloud deployments provide Infrastructure and Platform services capabilities to cloud providers. OpenStack inherited cloud entities are ideal candidates to work in alliances to form Inter Cloud Federation, as their API and Resource models are identical.

To address these problems, a new service will be added to the OpenStack services stack which will provide “Inter Cloud Federation” (a.k.a. Alliance) services to participating cloud entities. This service will be responsible for interconnecting multiple cloud instances and provide an abstraction layer to hide interoperability and integration complexities from the provider and end users.

Cloud providers have to enable this service on their cloud deployments and configure the required artifacts for partner or host cloud entities.

The picture below depicts the resource consumption flow from Host cloud to Partner clouds.

The picture ‘a’ (below), shows integration of multiple data centers with dedicated leased line for data replication. This architecture tightly couples the data centers and it is not a cost effective.

Picture ‘b’ portrays the interlinked cloudified data centers through Alliance service. In this model data exchange between the participating clouds will be happening on secured Internet channel but not on the dedicated lines.

Design Considerations

Following are the high level design consideration and functional components of Inter Cloud Federation Services (a.k.a. Alliance).

Host Cloud (HC)

A cloud entity which consumes resources from different cloud providers. This cloud entity plays a role of “resource consumer” in cloud federation business.

Partner Cloud (PC)

Cloud instance(s) which offers its services to a Host Cloud entity. These cloud entities plays a role of “resource provider” in cloud federation business.

Cloud Pairing

The pairing process is the initial step taken by two cloud providers to work in alliance. This step is required to establish trust between two cloud instances and configure required artifacts. These artifacts include cryptographic keys, cloud identifiers, region/zone information, service availability and Inter cloud federation service endpoints. Alliance service endpoints are required for service discovery and inter cloud token validations.

The pairing process can be done manually by two cloud providers (or it can be automated). Host cloud provider has to configure artifacts for partner cloud entities and partner has to configure artifacts for host cloud(s). Cloud pairing can be bidirectional, in this case one cloud instance will be playing as host cloud in one and partner cloud on other side.

Inter Cloud Ticket (ICT)

This ticket is used for the purpose of inter cloud communication (e.g. Resource discovery, user token validation across clouds). This is PKI ticket and contains data structure to hold context information required for communication. This ticket will be encrypted using partner’s (destination) public key and signed by host’s (source) private key.

Inter Cloud Token Validation

This service is used by two participating cloud entities to validate user token which involve signature validation and ticket decryption to get the actual X-Auth-Token. This service runs at ICFS service.

Region Discovery

This is one of the services provided by ICFS to list available regions (or availability zone). Clients use this service to know what are the available regions or zones offered by a provider. Generally these are static information stored in ICFS system.

Service Discovery

This service is used to discover available services in a particular region or zone offered by a partner cloud. This will provide dynamic list of available services from particular partner region.

Resource Provisioning

This service is responsible for provisioning remote resources. The resource provisioning will be done on local Keystone project of hosting cloud. It also maintains provisioning information in local database. The provisioning info will be used for the purpose of token generation and validation.

Resource Access Across Clouds

Resource access process start by getting an “X-Auth-Token” scoped (1) to local Keystone project of "host" cloud. Keystone service at HC will talk to local Alliance to get information about remote resources associated with project (2).

As part of token response (3) client gets a service catalog containing endpoints to the remote (federated) resources. Client uses the remote resource endpoint to access the resource (4), it provides (X-Host-Cloud-Id) host cloud identifier in request header and the X-Auth-Token{hc} got from host cloud.

Auth middle-ware protecting the resource at partner cloud intercepts the request and makes a call (5) to Keystone for token validation. Keystone delegates (6) such the token validation request to Alliance service which is not issued by it (foreign token) and have X-Host-Cloud-Id header associated.

Alliance uses the cloud identifier (X-Host-Cloud-Id) from the header to lookup the paired host cloud and it's peer Alliance endpoint. Using the X-Auth-Token{hc}, it forms an Inter Cloud Federation Ticket and uses paired Alliance endpoint to validate user token (7).

Alliance at HC will coordinate with local Keystone to validate the token (8).

After successful inter cloud token validation (9), Alliance service provide (10) the validate response to Keystone service running at PC. Keystone will caches the token in locale system and respond to middle-ware(11). Keystone will use the cached token for future token validations.

X-Auth-Token processing

Clients won't like to deal with multiple X-Auth-Tokens to access their resources across clouds (regions).

Following are the options to solve this issue.

PKI tokens

PKI tokens can be used by clients to access resources across clouds. There won't be inter cloud token validation required to validate the PKI tokens. PKI token are proven to be heavy, Federated Token can be a better solution.

Federated Tokens

Instead of generating new X-Auth-Token{pc} by partner cloud, partner cloud may choose to use the same X-Auth-Token{hc} issued by host cloud.

After successful inter cloud token validation (as explained above) Alliance will cache the token locally and utilize the same X-Auth-Token for future communication. This option can be set as part of cloud pairing depending of level of trust between two cloud providers.

Note: Inter cloud token validation is one time process or can be done multiple times over the period of communication by clients.

Federated Tokens by Eager Propagation

To support federated tokens partner cloud has to do inter cloud token validation and cache the validate token response to make the future token validation more efficient. Another approach to solve the performance of inter cloud token validation is to propagate the tokens to partner cloud in push mode. Host cloud will propagate token to the relevant partner using notification route.

SSO Across Cloud

In this mode, clients chooses to use PC's identity (Keystone) endpoint to make auth token request. Client provide credentials, project_id and cloud_id to the PC's identity service. Keystone will coordinate with Alliance service to get the token from remote cloud.

SSOut Across Cloud (or Inter Cloud Token Revocation)

Token revocation in an important aspect to maintain the security and system integrity. In case of resource federation use case, tokens revocation become more important as an stale token can cause bigger harm specially to the resource provider clouds.

Inter cloud token revocation will allow token revocation across cloud, e.g. Host cloud can initiate the token revocation for a token issued by itself or partner clouds can request/initiate the token revocation of a federated token.

Alliance service is will be the interface between clouds to make the token revocation happen.

Notification

Is part of Inter Cloud Federation Service and used to notify certain events (e.g. Meter, resource de-provisioning etc...) to and from participating clouds.

Issue and Concerns

Homogeneous vs Heterogeneous Cloud Partners

TBD

Impact

Following are the high level impact on existing OpenStack service

• Keystone token management subsystem will be impacted to support endpoints for partner services.
• Keystone service REST API will make an extra call to Alliance service to get list of available remote services.
• Horizon will be enhanced to integrate with Inter Alliance Service.
• Other OS Services - TBD