U.S. patent application number 14/097068 was filed with the patent office on 2015-06-04 for method and system of geographic migration of workloads between private and public clouds.
This patent application is currently assigned to International Business Machines Corporation. The applicant listed for this patent is International Business Machines Corporation. Invention is credited to Orcun Atakan, Benjamin Hicks Briggs, Louis Thomas Fuka, Ori Pomerantz.
Application Number | 20150156131 14/097068 |
Document ID | / |
Family ID | 53266259 |
Filed Date | 2015-06-04 |
United States Patent
Application |
20150156131 |
Kind Code |
A1 |
Pomerantz; Ori ; et
al. |
June 4, 2015 |
METHOD AND SYSTEM OF GEOGRAPHIC MIGRATION OF WORKLOADS BETWEEN
PRIVATE AND PUBLIC CLOUDS
Abstract
A database contains available cloud environments to which a
virtual image workload may be deployed. The database includes
ratings for each available cloud option, such as cost, distance,
reliability, which workloads that environment may handle. A table
of attributes and weights is used to create a rating of the
requested deployment. This rating determines where the image is
deployed. The invention discloses techniques for gathering
additional information from the user about the virtual image
workload to be deployed. A mapping algorithm applies the attributes
and weights to the gathered information to create a rating for the
deployment. An algorithm is then used to determine to which
available cloud environment the workload will be deployed.
Inventors: |
Pomerantz; Ori;
(Pflugerville, TX) ; Briggs; Benjamin Hicks;
(Austin, TX) ; Fuka; Louis Thomas; (Austin,
TX) ; Atakan; Orcun; (Cedar Park, TX) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
International Business Machines Corporation |
Armonk |
NY |
US |
|
|
Assignee: |
International Business Machines
Corporation
Armonk
NY
|
Family ID: |
53266259 |
Appl. No.: |
14/097068 |
Filed: |
December 4, 2013 |
Current U.S.
Class: |
709/226 |
Current CPC
Class: |
H04L 67/10 20130101;
H04L 47/70 20130101; H04L 67/1021 20130101 |
International
Class: |
H04L 12/911 20060101
H04L012/911; H04L 29/08 20060101 H04L029/08 |
Claims
1. A method for geographic migration of workloads for processing
between available cloud environments comprising: identifying a
workload for processing; identifying one or more cloud environments
in a cloud network that are available for process workloads;
assessing activity of the identified cloud environments in the
cloud network that are available for processing workloads;
identifying a machine in a cloud environment for processing a
workload; and processing the identified workload at the identified
machine in the cloud environment.
2. The method as described in claim 1 further comprising after said
identifying a machine in a cloud environment for processing a
workload, determining a geographic location of the identified
machine for processing the workload and migrating the identified
workload for processing to the geographic location of the
identified machine.
3. The method as described in claim 1 further comprising creating a
database of available cloud environments to which a virtual image
workload may be deployed, the available clouds in the database
being rated according to a set of parameters that can include cost,
distance, reliability, which workloads that environment may
handle.
4. The method as described in claim 3 wherein said assessing
activity of the identified cloud environments in the cloud network
that are available for processing workloads further comprises:
calculating latency performances of machines at a cloud environment
of the workload for processing; and calculating latency
performances between one or more cloud environments in the cloud
network.
5. The method as described in claim 4 wherein said identifying a
machine in a cloud environment for processing a workload further
comprises: combining calculated latency performance information and
the information of the identified workload for processing; and
generating an assessment of the performance of processing the
workload at various available cloud environments.
6. The method as described in claim 5 further comprising
determining whether to migrate the workload identified for
processing to a cloud environment at a different geographic
location or to process the identified workload at its current cloud
environment location.
7. The method as described in claim 4 wherein said identifying a
machine in a cloud environment for processing a workload further
comprises: creating a table of attributes; creating a rating of the
workload to be processed; and determining a processing location for
the identified workload based on the created rating for the
workload.
8. The method as described in claim 1 wherein said identifying a
workload for processing further comprises gathering additional
information from the user about the virtual image workload to be
deployed.
9. The method as described in claim 7 wherein said determining a
processing location for the identified workload based on the
created rating for the workload further comprises creating a
mapping algorithm which applies the attributes and weights to the
input from information gathered from an identified workload to
create a rating for placement of the identified workload for
processing.
10. The method as described in claim 9 further comprising creating
an algorithm to determine to which available cloud environment the
workload will be deployed.
Description
FIELD OF THE INVENTION
[0001] This invention relates to a method and system for more
efficient processing of computer system workloads and in particular
to a method and system for migrating computing system workloads
between private and public clouds in order to facilitate more
efficient use of computing resources and more efficient processing
of computing workloads.
BACKGROUND OF THE INVENTION
[0002] A computer storage or memory comprises components used to
retain digital data. The computer memory is a core component of
computer systems. Computer systems generally incorporate a storage
hierarchy. The traditional divisions of computer storage are
primary, secondary, tertiary and off-line storage. Primary storage
(or main memory) is often referred to as the memory. The primary
memory is the only memory type that is directly accessible to the
central processing unit (CPU). The CPU continuously reads
instructions stored there and executes them as required. Any data
actively operated on is also stored there in uniform manner.
Secondary storage (also known as external memory or auxiliary
storage), differs from primary storage in that it is not directly
accessible by the CPU. The computer usually uses its input/output
channels to access secondary storage and transfers the desired data
using intermediate area in primary storage. Tertiary storage or
tertiary memory provides a third level of storage. Tertiary storage
involves a robotic device which mounts, inserts and dismounts
removable mass storage media into a storage device according to the
system's demands. This data is often copied to secondary storage
before use. It is primarily used for archiving rarely accessed
information since it is much slower than secondary storage.
Tertiary storage is primarily useful for extraordinarily large data
stores, accessed without human operators. Off-line storage is a
computer data storage on a medium or a device that is not under the
control of a processing unit. The medium is recorded, usually in a
secondary or tertiary storage device, and then physically removed
or disconnected. It must be inserted or connected by a human
operator before a computer can access it again. Unlike tertiary
storage, it cannot be accessed without human interaction. Off-line
storage is used to transfer information, since the detached medium
can be easily physically transported.
[0003] As technology has progressed, another form of computer
storage is increasing in popularity and usage. This form of storage
is referred to as "cloud storage". Cloud storage is based on cloud
computing. Cloud computing describes a variety of computing
concepts that involve a large number of computers connected through
a real-time communication networks such as the Internet. In
science, cloud computing is a synonym for distributed computing
over a network, and means the ability to run a program or
application on many connected computers at the same time.
Cloud Computing Architecture
[0004] A cloud computing system is generally divided into two
sections: the front end and the back end. These sections connect to
each other through a communication network such as the Internet.
The user or client communicates with the system through the front
end section. The back end section is the "cloud" section of the
system.
[0005] The front end includes the client's machine and the
application required to access the cloud computing system. Not all
cloud computing systems have the same user interface. Services like
Web-based e-mail programs leverage existing Web browsers like
Internet Explorer or Firefox. Other systems have unique
applications that provide network access to clients. On the back
end of the system are the various computers, servers and data
storage systems that create the "cloud" of computing services. In
theory, a cloud computing system could include practically any
computer program you can imagine, from data processing to video
games. Usually, each application will have its own dedicated
server.
[0006] In a cloud computing system, there's a significant workload
shift. Local computers no longer have to do all the processing when
it comes to running applications. The network of computers that
make up the cloud handles them instead. Hardware and software
demands on the user's side decrease. The first requirement is that
the user's computer must execute the cloud computing system's
interface software. This interface software can be a basic Web
browser. The cloud network covers the rest of the operations. A
second requirement is to be connected to the network with the
cloud.
[0007] As cloud computing has become a strategic initiative for
large enterprises, the new method of delivering and consuming IT
services has forced its users to rethink activities such as job
scheduling. One aspect of job scheduling in cloud technology is
workload automation. Workload as use herein is an abstraction of a
process or set of processes that can be componentized, individually
operated upon and produce a determinate result, with the
abstraction being above the network hardware and operating system
layers. A job scheduler is a tool that allows management and
scheduling of jobs or workloads using a calendar system.
[0008] Workload automation is the evolution of job scheduling with
advanced workload management capabilities for the dynamic data
center. The aspects of scheduling workloads include automatically
resolving complex dependencies on various platforms and application
tiers and then triggering workloads based on both IT and business
events.
[0009] A primary function of a good workload automation solution is
to provide visibility into enterprise-wide workloads, regardless of
where the workload or the workload automation solution is
physically located. However, workloads are not operated along
platform lines of separation. They have cross-platform dependences
for computing needs and for application dependences. For instance,
the workload automation solution could be on a mainframe but the
workloads could be running on distributed platforms, or vice-versa.
Most vendors have separate solutions for each platform, making it
difficult for IT operations to understand workload dependencies
across platforms or virtual servers.
[0010] For a dynamic workload automation solution, it becomes even
more complex when workloads are run in the cloud, another virtual
resource. This makes it important for the workload automation
solution to be able to offer full flexibility in its ability to
operate agents across platforms, virtual resource and the cloud and
visibility into all of these workloads from a single place. To cite
an example, CA Workload Automation solution's CA Workload Command
Center displays visibility into workloads in mainframe, distributed
and Amazon EC2 cloud--all in a single pane. This gives workload
administrators visibility into enterprise-wide workload
infrastructure.
[0011] The second aspect of cross-platform workload management,
beyond visibility as discussed above is control. Workload
administrators need the ability to apply job definitions that
abstract out the platform differences sufficiently in order to
avoid recreating multiple job definitions for each platform. This
saves time, not only for adding new job definitions, but also on
maintenance and service and helps IT operations be more responsive
to business needs.
[0012] Users access cloud computing using networked client devices,
such as desktop computers, laptops, tablets and smart phones. Cloud
configurations can take the form of public clouds, private clouds
or hybrid clouds. Private cloud is cloud infrastructure operated
solely for a single organization, whether managed internally or by
a third-party and hosted internally or externally.
[0013] A cloud is a "public cloud" when the services are rendered
over a network that is open for public use. There is little
difference between the architecture of a public and a private
cloud. However, security considerations can be substantially
different for services (applications, storage, and other resources)
that are made available by a service provider. Generally, public
cloud service providers like Amazon AWS, Microsoft and Google own
and operate the infrastructure and offer access only via Internet
(direct connectivity is not offered).
[0014] A hybrid cloud consists of private cloud and public cloud
components. In a hybrid cloud, there has to be a determination of
which component (public or private) will run a virtualized
workload? For example, when assigning a virtualized server, one may
want to assign it to the least expensive option, whether that be
public or private. In the alternative, they may want to assign the
virtual server to the private cloud until there are no more
resources available, then assign virtual servers to the public
cloud. In addition, a newly requested virtual server may have a
higher priority for the private cloud and "bump" existing virtual
servers to the public cloud
http://www.globalstf.org/docs/proceedings/ccv/135.pdf discusses A
Decision Support System for Moving Workloads to Public Clouds. This
is different from our idea because it talks more about a decision
to migrate existing bare metal applications to a virtual
environment.
[0015] A central server administers the system, monitoring traffic
and client demands to ensure everything runs smoothly. Most of the
time, servers don't run at full capacity. That means there's unused
processing power going to waste. There is a need for a method and
system for migrating workloads between public clouds and between
public and private clouds. Further, there is a need to consider
provisioning virtual machines on demand to meet new requirements
and accounts for the possibility of choosing dynamically from
several different cloud environments to take advantage of the best
fit.
SUMMARY OF THE INVENTION
[0016] The invention discloses a database of available cloud
environments to which a virtual image workload may be deployed. The
database includes information for each available cloud option, such
as cost, distance, reliability, which workloads that environment
may handle. A table of attributes and weights can be provided and
used to create a rating of the requested deployment. This rating
determines where the image is deployed. The invention discloses
techniques for gathering additional information from the user about
the virtual image workload to be deployed. A mapping algorithm can
apply the attributes and weights to the gathered information to
create a rating for the deployment. An algorithm is then used to
determine to which available cloud environment the workload will be
deployed. The present invention also implements a system that
determines which available cloud environments have security
measures such that the cloud environment is suitable to process a
workload that requires determined security measures for processing.
This invention can determine whether to migrate a workload to
another cloud environment or process the workload at a current
workload location.
DESCRIPTION OF THE DRAWINGS
[0017] FIG. 1 is a configuration of a network cloud environments
through which workloads can be migrated geographically and
processed.
[0018] FIG. 2 is an illustration of the internal configuration of a
cloud environment for processing a workload.
[0019] FIG. 3 is an illustration of a network of cloud environments
and cloud users in various geographic locations for determining
network latency from clients in various cloud locations.
[0020] FIG. 4 is a flow diagram of the steps in a general
implementation of the method of the present invention for
determining cloud environment availability.
[0021] FIG. 5 is a flow diagram of the steps in a general
implementation of the method of the present invention for
determining cloud environment availability and cloud security for
processing an identified workload.
[0022] FIG. 6 is a flow diagram of the steps in determining which
cloud environment to migrate a workload.
DETAILED DESCRIPTION OF THE INVENTION
[0023] The present invention is a method and system for
geographically migrating and processing workloads in a system of
network cloud environments. This invention provides the ability to
migrate a workload from one cloud environment to another cloud
environment for more efficient processing and more efficient use of
cloud environment resources.
[0024] FIG. 1 illustrates a general configuration for a cloud
network. This network comprises four different cloud environments
A, B, C and D. These cloud environments are positioned in different
geographic locations. Communication links 102, 104, 106, 108 and
110 provide the ability for communications between cloud
environments. The cloud environments have users 112 and 114 that
use these clouds to store information in the cloud database and to
also use these clouds for processing purposes. The cloud users can
store information in cloud databases in the respective or local
clouds or store information in databases in any cloud in the
network. Similarly, users can process applications and workloads in
the resident cloud for their geographic location or process the
applications and workloads at any cloud in the network.
[0025] Even though cloud environments are used for both data
storage and application and workload processing, the present
invention has a particular focus on determining cloud availability
for processing workloads. An objective is to improve the efficiency
of workload processing in a cloud network environment. FIG. 2
illustrates the internal configuration of a cloud environment for
processing a workload. An internal configuration for a cloud
environment comprises a web server 202, an application server 204
and a cloud database 206. Users 208, 210 and 212 can communicate
with the cloud environment through the web server 202 through
communication links 214.
[0026] In processing applications/workloads using cloud technology,
for example, customers in East Asia use applications in different
hours than customers in Europe, and both groups of customers use
applications in different hours than those in the Americas.
Furthermore, in practice, to facilitate efficient workload
processing, multiple clouds are put in multiple locations. In
addition, the front-end server and possibly other servers that are
primarily for processing are moved rather than the cloud storage
database, to the appropriate locations based on the user's
location.
[0027] Referring to a cloud workload, the workload typically
includes multiple virtual machines, doing different jobs. For
example, in this FIG. 2 as mentioned, the cloud has three virtual
machines ("VMs"): the web server 202, the application server 204,
and the database 206. Very often during workload processing, the
bandwidth requirements for the connection between the front end (in
this case, the web server 202) and the users/clients are higher
than those for the internal connections (in this case, web server
202 to application server 204 and application server 204 to
database 206). In such cases, it would be better to place the web
server closer to the majority of users.
[0028] As mentioned, the method of the present invention provides a
means to access the activity in a cloud network and determine the
optimal location in the cloud network for processing of a workload.
This determination of the optimal location in the cloud network
comprises three phases: 1) Application Instrumentation; 2) Network
Test, and 3) Virtual Machine (VM) Migration.
Application Instrumentation
[0029] Application instrumentation analyzes the movement of packets
between a user 212, the web server 202, the application server 204
and the database 206. In the application instrumentation phase,
which only needs to be done when the application or the average
workload changes, the method of the present invention checks the
number of packets used for the different connections. This process
assesses the amount of traffic on the network. As shown in FIG. 2,
the method would look for three values:
[0030] Nuw: The number of packets going between the web server and
the users.
[0031] Nwa: The number of packets going between the web server and
the application server.
[0032] Nad: The number of packets going between the application
server and the database.
The invention also checks the size of the servers, including their
disks:
[0033] Sa: The web server; Sb: The application server; Sc: The
database server
Network Test
[0034] The network test is the second phase in determining of the
optimal location in the cloud. Referring to FIG. 3, shown is an
illustration of a network of cloud environments and cloud users in
various geographic locations for determining network latency from
clients in various cloud locations.
This network test phase determines the latency in the network. The
latency is basically the time required for a packet to move from an
initial network component to a second network component and then
back to the original network component. Every hour or so, use a
service that has clients in multiple places, such as geoedge.com,
to get the latency from client locations to various clouds. For
discussing latency, the parameters are identified as follows:
[0035] LDT--Direct latency Toronto
[0036] LDS--Direct latency Shanghai
[0037] LDU--Direct latency United States [0038] Nc--Number of uses
in China [0039] Ne--Number of uses in Europe [0040] Nu--Number of
uses in United States
[0041] Lcs--latency between China and Shanghai
[0042] Lct--latency between China and Toronto
[0043] Lut--latency between United States and Toronto
[0044] Lus--latency between United States and Shanghai
[0045] Let--latency between Europe and Toronto
[0046] Les--latency between Europe and Shanghai
[0047] Lst--latency between Shanghai and Toronto
Referring to FIG. 3, using these values, it is possible to
approximate the total latency. If China currently has Nc users,
Europe Ne users and the United States Nu users, then the direct
latency would be LDs=Nc*Lcs+Ne*Les+Nu*Lus if the front end server
were in Shanghai, and LDt=Nc*Lct+Ne*Let+Nu*Lut. If the database VM
has to stay in Toronto (it has a huge disk so it would be too big
to move), there are three possible configurations:
[0048] 1. Everything is in Toronto. In that case,
L1=LDt=Nc*Lct+Ne*Let+Nu*Lut.
[0049] 2. Only the web server is in Shanghai. In that case,
L2=LDs+Lst*(Nc+Ne+Nu)*(Nwa/Nuw).
[0050] 3. Web server and application server in Shanghai. In that
case,
L3=LDs+Lst*(Nc+Ne+Nu)*(Nad/Nuw).
Virtual Machine (VM) Migration
[0051] In this phase, there is a determination of whether to move
or migrate data or a workload to a location other than the original
location. To make this decision, there has to be determination of
how much latency justifies moving an amount of data between Toronto
and Shanghai. This factor will be referred to as factor q.
Calculate the minimum of {L1, L2, L3}. If that minimum is different
from the current state by more than qSa (if switching between 1 and
2), qSb (if switching between 2 and 3), or q(Sa+Sb) (if switching
between 1 and 3), switch the virtual machine from one cloud to the
other.
[0052] The method for determining the availability of a cloud
environment for purposes of workload migration is illustrated in
FIG. 4. In this method an initial step 402 is to identify a
workload for possible migration to an available cloud environment
for processing. This identification of a workload for processing at
an available cloud environment can involve the use of various
established parameters such as size of the workload and current
location of the workload. The next step 404 is to identify cloud
environments in a cloud network that are available to perform
workload processing activities. This step 404 can involve
establishment of a database of clouds and a rating system that
characterizes the availability of each cloud environment. Step 406
identifies a general processing source for the specific workload
for which processing is desired. This step identifies the current
processing source for the workload. For example, if the client with
the workload to be processed is in the United States, this step 406
identifies the processing source in the United States (generally,
the first option) for processing the workload. Step 408 begins the
assessment of the servers in an identified cloud network. In
addition to the initial processing source identified in step 406,
step 408 identifies other servers in the cloud network that could
be potential servers for processing the workload.
[0053] As previously discussed, in assessing servers in a cloud
network to determine cloud availability for processing workloads,
it is desirable to perform latency calculations of the servers in
the cloud network. Step 410 calculates latency performance for
servers in cloud environments in the cloud network with the
initiating cloud. A cloud environment can have multiple servers
that are capable of workload processing. In this step 410, the
latency (time required to send a packet and have that packet
returned) between servers in a particular cloud are calculated.
Step 412 determines the latency between the clouds in different
networks. Referring back to FIG. 3, step 410 can determine the
latency of the Toronto cloud and a U.S. client. Step 412 can
determine the latency between the Toronto cloud and the Shanghai
cloud or the latency between a U.S. client and the Shanghai cloud.
Step 414 gathers and combines the latency information calculated in
steps 410 and 412. This step also combines the latency information
with previously known and identified information about the
particular workload identified for processing. Step 416 then
determines whether to process the workload at the present computing
machine and location identified in step 406 or to migrate the
workload to a different cloud location.
[0054] As mentioned, workloads can be migrated between cloud
environments to facilitate more efficient use of processing
resources. When there is a high volume of processing in one cloud
location, workloads from that high volume cloud can be migrated to
clouds that have much lower volumes at that same time. FIG. 4
describes the process of identifying available cloud for processing
workloads. This availability is based mainly on capacity to
accommodate the processing of additional workloads. However,
workload migrate can involve other factors such as machine
security. In hybrid cloud systems, there can be public clouds and
private clouds. Private clouds are typically more secure and not as
accessible. In addition, some workloads also have security
requirements and there may be a desire to have these workloads
processed on machines that have more stringent security
mechanisms.
[0055] FIG. 5 describes an implementation of the method of the
present invention for determining cloud environment availability
and cloud security for processing an identified workload. In FIG.
5, the steps 502, 504, 506, 508, 510 and 512 are the same as steps
402, 404, 406, 408, 410 and 412 of FIG. 4 respectively. Step 514
gathers and combines the latency information calculated in steps
510 and 512. This step also combines the latency information with
previously known and identified information about the particular
workload identified for processing. At this point, step 516
identifies and determines security requirements for an identified
workload. Step 518 determines whether a workload could be processed
on a public cloud. Typically, the private cloud would have
sufficient security to satisfy processing requirements for any
workload. Step 520 determines whether to execute the specific
workload at the present computing machine location or to move or
migrate the workload to a different cloud location for
processing.
[0056] FIG. 6 provides more details about the process of
identifying which specific cloud to migrate a workload for
processing. As part of identifying an appropriate cloud environment
for processing a workload step 602 establishes a database of
available cloud environments to which a workload may be deployed.
The database could be comprised based on a capacity requirement
such as clouds that have fifty percent (50%) available capacity at
any one time can be included in the database.
[0057] A rating system can be created, and each master image from
which a virtualized workload is cloned is rated according to this
system. The rating mechanism has a series of attributes, each with
its own weight. The various master images are rated on these
attributes. Additionally, the requestor of the virtualized workload
can enter information to influence the rating of the system. Step
604 rates each available cloud in the database. The database rating
system includes ratings for each available cloud option can be
based on parameters such as cost, distance, reliability, which
workloads that environment may handle. The rating system can
generate a table of attributes and weights. This table is used to
create a rating of the requested deployment. This rating will
determine where the image is deployed. Step 606 gathers specific
information about the workload for which processing is desired.
This information about the workload can include the size of the
workload. Step 608 creates a rating for the workload to be
processed. This step incorporates information from steps 604 and
606 to create the rating. A mapping algorithm can be used to create
this rating. The mapping algorithm applies attributes and weights
to the input about the workload to create a rating for the workload
deployment. As previously mentioned, another parameter could be
security of the processing for the work. Based on the rating
created in step 608 for a workload, step 610 determines which
available cloud from the cloud database to deploy the workload for
processing. In this step 610, an algorithm to determining to which
available cloud environment the workload will be deployed.
[0058] It is important to note that while the present invention has
been described in the context of a fully functioning data
processing system, those skilled in the art will appreciate that
the processes of the present invention are capable of being
distributed in the form of instructions in a computer readable
storage medium and a variety of other forms, regardless of the
particular type of medium used to carry out the distribution.
Examples of computer readable storage media include media such as
EPROM, ROM, tape, paper, floppy disc, hard disk drive, RAM, and
CD-ROMs.
* * * * *
References