Revision as of 15:26, 1 July 2014

Inter Cloud Resource Federation (Alliance)

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

Abstract

Cloud based services are growing business trend in the IT industry, where a service provider 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. A 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 fulfil customer needs.

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.

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 model are fully compatible.

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.

A cloud service provider has to enable this service on their cloud deployments and configure the required artifacts for partner or host cloud entities.

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

Pairing process is the initial step taken by two cloud providers to work in federated fashion. This step is required to establish trust between two cloud instances and configure required artifacts. These artifacts include cryptographic keys, cloud entity identifiers, region/zone information, service availability and Inter cloud federation service endpoints. ICFS 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 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 represent 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. 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.

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.

Notification

Is part of Inter Cloud Federation Service and used to notify certain events 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.
• OS Services - TBD