Revision as of 02:27, 2 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 needs and they often want resources across multiple regions. These regions are sometime spans across multiple geographical boundaries. A 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 wants to lease resources from other provider cross regions to fulfill customer needs.

Cloud Bursting

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

Idle Resources

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

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.

Cloud Leasing

Vendors want to be in cloud business just to lease resources to service providers, unlike other service providers these vendors don’t want to deal with small consumers.

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.

Tightly Coupled Data Centers

Building multi region architecture to join multiple data centers under single cloud entity is costly and creates tight coupling.

Solution

OpenStack provides open source cloud computing platform which is getting huge industry adoption for building up private/public/hybrid cloud. OpenStack based cloud deployments provides 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 same.

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. ICFS endpoints are required for service discovery, inter cloud token issuer 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 two way, 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 ticket 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 Issuer

This is one of the services of ICFS which validates a token issued by host cloud and issues local tokens. This component interacts with local Keystone service to request local tokens.

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 to local Keystone project of host cloud. As part of token response client gets a service catalog containing endpoints to the remote (federated) resources and endpoint of partner’s inter cloud token issuer service. Client first use the PC’s inter cloud token issuer service endpoint to get local token at partner cloud, it also provide host cloud identifier in request header and the X-Auth-Token{hc} got from host cloud.

Partner cloud uses the cloud (host) identifier from the header to lookup the paired host cloud and its ICFS endpoint. Using the X-Auth-Token{hc}, partner cloud forms a Inter Cloud Federation Ticket and uses ICFS endpoint to validate user token. After successful validation PC issues a token (X-Auth-Token{pc}) to the client. Client uses the X-Auth-Token{pc} for resource access.

Federated Token (optional)

Instead of generating new X-Auth-Token{pc}, partner cloud may choose to use the same X-Auth-Token{hc} issued by host cloud after successful inter cloud token validation. This option can be set as part of cloud pairing depending of level of trust between two cloud providers. Two support federated tokens partner cloud has to cache the validate token response to make the future token validation more efficient.

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.

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 ICFS service to get list of available remote services.
• Horizon will be enhanced to integrate with Inter Cloud Federation Service.
• Other OS Services - TBD