Inter Cloud Resource Management

Pre-requisite:- Cloud Computing

A theoretical model for cloud computing services is referred to as the “inter-cloud” or “cloud of clouds.” combining numerous various separate clouds into a single fluid mass for on-demand operations Simply put, the inter-cloud would ensure that a cloud could utilize resources outside of its range using current agreements with other cloud service providers. There are limits to the physical resources and the geographic reach of any one cloud.

Need of Inter-Cloud

Due to their Physical Resource limits, Clouds have certain Drawbacks:

• When a cloud’s computational and storage capacity is completely depleted, it is unable to serve its customers. 
• The Inter-Cloud addresses these circumstances when one cloud would access the computing, storage, or any other resource of the infrastructures of other clouds.

Benefits of the Inter-Cloud Environment include:

• Avoiding vendor lock-in to the cloud client
• Having access to a variety of geographical locations, as well as enhanced application resiliency.
• Better service level agreements (SLAs) to the cloud client
• Expand-on-demand is an advantage for the cloud provider.

Inter-Cloud Resource Management

A cloud’s infrastructure’s processing and storage capacity could be exhausted. combining numerous various separate clouds into a single fluid mass for on-demand operations. Simply put, the intercloud would ensure that a cloud could utilize resources outside of its range combining numerous various separate clouds into a single fluid mass for on-demand operations. Such requests for service allocations received by its clients would still be met by it.

Types of Inter-Cloud Resource Management

1. Federation Clouds: A federation cloud is a kind of inter-cloud where several cloud service providers willingly link their cloud infrastructures together to exchange resources. Cloud service providers in the federation trade resources in an open manner. With the aid of this inter-cloud technology, private cloud portfolios, as well as government clouds (those utilized and owned by non-profits or the government), can cooperate.
2. Multi-Cloud: A client or service makes use of numerous independent clouds in a multi-cloud. A multi-cloud ecosystem lacks voluntarily shared infrastructure across cloud service providers. It is the client’s or their agents’ obligation to manage resource supply and scheduling. This strategy is utilized to use assets from both public and private cloud portfolios. These multi-cloud kinds include services and libraries.

Topologies used  In InterCloud Architecture

1. Peer-to-Peer Inter-Cloud Federation: Clouds work together directly, but they may also utilize distributed entities as directories or brokers. Clouds communicate and engage in direct negotiation without the use of intermediaries. The peer-to-peer federation intercloud projects are RESERVOIR (Resources and Services Virtualization without Barriers Project).

2. Centralized Inter-Cloud Federation: In the cloud, resource sharing is carried out or facilitated by a central body. The central entity serves as a registry for the available cloud resources. The inter-cloud initiatives Dynamic Cloud Collaboration (DCC), and Federated Cloud Management leverage centralized inter-cloud federation.

3. Multi-Cloud Service: Clients use a service to access various clouds. The cloud client hosts a service either inside or externally.  The services include elements for brokers. The inter-cloud initiatives OPTIMUS, contrail, MOSAIC, STRATOS, and commercial cloud management solutions leverage multi-cloud services.

4. Multi-Cloud Libraries: Clients use a uniform cloud API as a library to create their own brokers. Inter clouds that employ libraries make it easier to use clouds consistently. Java library J-clouds, Python library Apache Lib-Clouds, and Ruby library Apache Delta-Cloud are a few examples of multiple multi-cloud libraries.

Difficulties with Inter-Cloud Research

The needs of cloud users frequently call for various resources, and the needs are often variable and unpredictable. This element creates challenging issues with resource provisioning and application service delivery. The difficulties in federating cloud infrastructures include the following: 

• Prediction of Application Service Behaviour: It is essential that the system be able to predict customer wants and service Behaviour. It cannot make rational decisions to dynamically scale up and down until it has the ability to predict. It is necessary to construct prediction and forecasting models. Building models that accurately learn and fit statistical functions suited to various behaviors is a difficult task. Correlating a service’s various behaviors can be more difficult.
• Flexible Service-Resource Mapping: Due to high operational expenses and energy demands, it is crucial to enhance efficiency, cost-effectiveness, and usage. A difficult process of matching services to cloud resources results from the system’s need to calculate the appropriate software and hardware combinations. The QoS targets must be met simultaneously with the highest possible system utilization and efficiency throughout the mapping of services.
• Techniques for Optimization Driven by Economic Models: An approach to decision-making that is driven by the market and looks for the best possible combinations of services and deployment strategies is known as combinatorial optimization. It is necessary to create optimization models that address both resource- and user-centered QoS objectives.
• Integration and Interoperability: SMEs may not be able to migrate to the cloud since they have a substantial number of on-site IT assets, such as business applications. Due to security and privacy concerns, sensitive data in an organization may not be moved to the cloud. In order for on-site assets and cloud services to work together, integration and interoperability are required. It is necessary to find solutions for the problems of identity management, data management, and business process orchestration.
• Monitoring System Components at Scale: In spite of the distributed nature of the system’s components, centralized procedures are used for system management and monitoring. The management of multiple service queues and a high volume of service requests raises issues with scalability, performance, and reliability, making centralized approaches ineffective. Instead, decentralized messaging and indexing models-based architectures are required, which can be used for service monitoring and management services.