Inter Cloud Resource Federation

=Intercloud Resource Federation (Alliance)=

Arvind Tiwari
Cloud based services are a growing business trend in the IT industry, where service providers establish cloud and offer 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 InterCloud Resource Federation (a.k.a. Alliance). 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 providers 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 lease resources to other service providers or customers who want have VPC (Virtual Private Cloud). Unlike other service providers these vendors want to target large consumers.

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

Cloud Bursting
In private in-house cloud deployments, enterprises want to bursts into a public/separate cloud when the demand for computing capacity spikes.

Joint Venture Cloud
Setting up a 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 joint ventures to make a bigger cloud entity with massive resource capacities.

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 a 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 InterCloud 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 “InterCloud 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 cloud.



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 cost effective.

Picture ‘b’ portrays the interlinked cloudified data centers through Alliance service. In this model, data exchanges between the participating clouds will be happening on secured (PtoP VPN) Internet channel not on dedicated lines.



=Design Considerations= Following are the high level design consideration and functional components of InterCloud Federation Services (a.k.a. Alliance).

Host Cloud (HC)
A cloud entity 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) offer 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 InterCloud 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.

InterCloud Ticket (ICT)
This ticket is used for the purpose of inter-cloud communication (e.g. Resource discovery, user token validation across clouds). This is a 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.

InterCloud 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 is a part of Alliance 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.



Remote Resource Provisioning
Resource provisioning is required to allocate limited resource efficiently on the (partner cloud) resource provider cloud. Provisioning is also needed to provide sense of ownership to the end user, for cloud provider (partner/host) provisioning is required to address metering aspect.

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



In the above picture user maintains his identity at one place (host cloud) and owns resources from remote cloud(s) on a local project. This is another benefit of resource federation, where user can use a single project in host cloud to scope all the remote resources across the cloud(s).

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 InterCloud 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 InterCloud 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 InterCloud Federation Service and used to notify certain events (e.g. Meter, resource de-provisioning etc...) to and from participating clouds.

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

=Note=
 * This page is in "work in progress" mode.
 * Please excuse any typographical error.