Browse Prior Art Database

High Availability migration of workloads instances between different cloud service providers

IP.com Disclosure Number: IPCOM000240669D
Publication Date: 2015-Feb-17
Document File: 7 page(s) / 169K

Publishing Venue

The IP.com Prior Art Database

Abstract

This article describes the solution for high availability migration of the running instances of workloads between two Cloud Service Providers within the same hypervisor.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 01 of 7

High Availability migration of workloads instances between different cloud service providers

A workload is by definition (http://www.merriam-webster.com/dictionary/workload) the amount of work performed or capable of being performed (as by a mechanical device) usually within a specific period. When in scope of a Cloud Computing, a workload can be thought as an abstraction of the actual work that one instance or a set of them are meant to perform.

A Cloud service provider lets to create an instances of workloads, which are being started on connected hypervisor. In situation, when a new Cloud Service Provider is connected with the same hipervisor, all existing elements are visible, but they are unstructured and looks rather as free electrons.

Cloud service provider lets to create an instances of workloads, which are being started on connected hypervisor. In situation, when a new Cloud Service Provider is connected

with the same hipervisor, all existing elements are visible, but they are unstructured and looks rather as free electrons.

High availability corresponds to system or component which is continuously accessible and operational. Users wants their system to be ready for the whole time of specified period.

1


Page 02 of 7

When migrating whole instances of workloads, the main issue is how to recreate these

workloads on new cloud service provider, so after migration systems are still visible as a set of connected elements, not a singletons. This can be obtained with ussage of graph based solution. While this operation, maintaining high availability may be crucial. The assurance of accessibility can be problematic due to specification of cloud service providers, between which the migration is being performed. The main idea here is to recreate exact copies of workload instances on the new Cloud Service Provider, and after that, behind the scene, switch new systems with old systems, without stopping them.

After this, new Cloud Service Provider will be able to control instance as a whole. Moreover it will be communicating with the old systems, which means migration was successful and high availability was maintained.

Migration of running instances of workload should be performed in three steps:
1. Make the workload pattern available for the new Cloud Service Provider - Cloud Service Provider B is able to deploy the same template as one we want to migrate.
2. Deploy a new instance of workload via new Cloud Service Provider.

3. Replace parts of new workload instance with elements from a corresponding

workload instance that is desired to be migrated, without stopping old instance.

The most crucial step is the third one. It can be done with usage of graph based solution.

A graph is generated based on deployed insta...