U.S. patent application number 13/874015 was filed with the patent office on 2013-10-31 for server image migrations into public and private cloud infrastructures.
This patent application is currently assigned to Racemi, Inc.. The applicant listed for this patent is RACEMI, INC.. Invention is credited to Gregory Allen Jednaszewski, Scott Alan Leerssen, Steven Keith McClure, Charles Thomas Watt.
Application Number | 20130290542 13/874015 |
Document ID | / |
Family ID | 49478314 |
Filed Date | 2013-10-31 |
United States Patent
Application |
20130290542 |
Kind Code |
A1 |
Watt; Charles Thomas ; et
al. |
October 31, 2013 |
Server Image Migrations Into Public and Private Cloud
Infrastructures
Abstract
Systems and methods for migrating a server image between any
physical, virtual, and cloud servers. The system includes a deploy
agent that is run on the target server, a migration manager to
control operations, an image library for optional long-term storage
of the image, and mailbox-based communications mechanism to support
management operations spanning multiple data centers and firewalls.
While deploying an image to the target server, the deploy agent
automatically adjusts the image to account for changes in server
hardware, storage layout, and network infrastructure to ensure that
any applications within the image continue to function
properly.
Inventors: |
Watt; Charles Thomas;
(Atlanta, GA) ; Leerssen; Scott Alan; (Atlanta,
GA) ; McClure; Steven Keith; (Mableton, GA) ;
Jednaszewski; Gregory Allen; (Mableton, GA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
RACEMI, INC. |
Atlanta |
GA |
US |
|
|
Assignee: |
Racemi, Inc.
Atlanta
GA
|
Family ID: |
49478314 |
Appl. No.: |
13/874015 |
Filed: |
April 30, 2013 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
61640475 |
Apr 30, 2012 |
|
|
|
Current U.S.
Class: |
709/226 |
Current CPC
Class: |
H04L 29/08153 20130101;
H04L 67/1004 20130101; H04L 51/22 20130101 |
Class at
Publication: |
709/226 |
International
Class: |
H04L 29/08 20060101
H04L029/08 |
Claims
1. A method of migrating a computer server image from a source
server to a cloud-based target server, the cloud-based target
server being connected for electronic communications via a data
communication network with a migration server and an image server
associated with the migration server, the image server containing a
captured copy of the source server image, the captured copy of the
source server image including configuration information from the
image and the original source server from whence it came,
comprising the steps of: providing a deploy agent code for
execution on the cloud-based target server, the deploy agent code
executing configuration operations to install the captured source
server image to the cloud-based target server; upon executing the
deploy agent code on the cloud-based target server, the deploy
agent code gathering server configuration information from the
cloud-based target server including any operational parameters
associated with the cloud environment; the deploy agent code
communicating to the migration server that the deploy agent is
running on the cloud-based target server and available to perform
an image migration; the deploy agent code communicating the
gathered server configuration information to the migration server;
the deploy agent code receiving from the migration server migration
instructions including the location of the image on the image
server and the required configuration of the target server; the
deploy agent code reading the captured image of the source server
from the image server and installing it on the cloud-based target
server; and the deploy agent code executing configuration
operations to modify the image that it has deployed to the
cloud-based target server to comport with target server
configuration information.
2. The method of claim 1, wherein the deploy agent code executing
configuration operations to modify the image that it has deployed
to the cloud-based target server in accordance with: (a) the source
server configuration information and image configuration
information as stored with the captured image; (b) the available
configuration of the cloud-based target server; (c) any operational
parameters associated with the cloud environment in which the
cloud-based target server is running; and (d) any configuration
requirements that were specified to the migration server by an end
user when requesting the image migration.
3. The method of claim 1, wherein the operational parameters
associated with the cloud environment comprise operational
requirements or restrictions.
4. The method of claim 1, wherein the cloud-based target server is
provided by a private cloud or a public cloud.
5. The method of claim 1, wherein the source server is selected
from the group comprising a physical server, a virtual server, a
cloud server.
6. The method of claim 1, wherein the deploy agent is installed on
top of a pre-existing cloud server that has been created by the
cloud server control system.
7. The method of claim 1, wherein the deploy agent code is provided
as a ramdisk image that is executed by the cloud-based target
server after rebooting.
8. The method of claim 1, wherein the deploy agent is instantiated
directly on the target cloud server by the cloud server control
system using a compact disc read-only memory (CD-ROM) or DVD image
in ISO 9660 format.
9. The method of claim 1, wherein the deploy agent is instantiated
directly on the cloud-based target server by the cloud server
control system using a template image maintained by cloud server
control system.
10. The method of claim 1, wherein the deploy agent reads the
captured image directly from an agent running on the source
server.
11. The method of claim 1, wherein the operating system (OS) of the
source server image is selected from the group comprising: LINUX,
Windows, Mac OSX, FreeBSD, Solaris.
12. The method of claim 1, wherein the operational parameters
associated with the cloud environment require the deploy agent to
modify the migrated image that it has deployed to the cloud-based
target server in order to install any special device drivers
necessary to run the image on the cloud-based target server.
13. The method of claim 12, wherein the deploy agent collects the
necessary device drivers from the operating system of the
cloud-based target server as originally created by the cloud server
control system.
14. The method of claim 12, wherein the migration server maintains
a library of the necessary device drivers for installation on the
cloud-based target server.
15. The method of claim 1, wherein the deploy agent modifies the
file system layout of the original source server image to fit upon
the storage devices that are provided by the cloud-based target
server, such modifications including one or more of: (a)
Consolidating logical units (LUNs) or partitions of storage onto
the available storage volumes, (b) Consolidating multiple file
systems onto a single LUN or partition, (c) Resizing the space
allocated to a file system to fit onto the available LUN or
partition, or (d) Changing the type of file system.
16. The method of claim 15, wherein the calculations on how to
modify the file system layout of the original source server image
are made by a migration manager computer program executing on the
migration server and sent to the deploy agent running on the
cloud-based target server as a set of instructions.
17. The method of claim 1, wherein the deploy agent modifies the
network configuration of the original source server image so that
the migrated cloud-based target server will be configured properly
to access network communications within the target cloud
environment.
18. The method of claim 17, wherein the deploy agent collects the
necessary network configuration information required for operation
within the target cloud environment from the operating system of
the cloud-based target server as originally created by the cloud
server control system.
19. The method of claim 18, wherein the calculations on how to
modify the network configuration of the original source server
image such that the deployed cloud-based target server will work
within the target cloud environment are made by a migration manager
computer program executing on the migration server and sent to the
deploy agent running on the target cloud server as a set of
instructions.
20. The method of claim 1, wherein the deploy agent modifies the
migrated image that it has deployed to the cloud-based target
server in order to install any additional software, such as
management or monitoring agents, that are required by the cloud
vendor in order for a server to operate within the cloud
infrastructure.
21. The method of claim 1, wherein all communications between the
migration server and the cloud-based target server are implemented
through the exchange of messages using a mailbox communications
server, the mailbox communications server being configured to
receive incoming file service requests to create, read, write, or
list files, the file service requests being implemented using
network communications protocols such that all requests originate
with the migration server, source server, or target server and pass
through any firewalls protecting them to reach the mailbox
server.
22. The method of claim 21, wherein the protocol used to implement
the file service requests of the mailbox server is selected from
the group comprising: Amazon S3 protocol, Web Distributed Authoring
and Versioning (WebDAV), File Transfer Protocol (FTP), SSH File
Transfer Protocol (SFTP).
23. A method of migrating a computer server image from a source
server to a cloud-based target server, the source server and
cloud-based target server being connected for electronic
communications via a data communication network with a migration
server and with an image server associated with the migration
server, the migration server being connected for electronic
communications with a cloud server control system that controls one
or more cloud-based target servers, comprising the steps of: the
migration server receiving an image migration request command
including any configuration requirements for the target server; the
migration server gathering configuration information for the source
server and the source server image from a capture agent associated
with the source server; the migration server issuing a command to
the capture agent instructing it to capture the image of the source
server, the source server having an operating system (OS) of a
particular type; the capture agent storing the captured image of
the source server on the image server; the migration server
providing an instruction to the cloud server control system to
instantiate a cloud-based target server having an operating system
(OS) of the same particular type as said source server OS, the OS
of the instantiated cloud-based target server including a boot
loader code portion; the migration server loading a deploy agent
code onto the cloud-based target server, the deploy agent code
comprising code for executing configuration operations to install
the captured image of the source server to the cloud-based target
server; the migration server further modifying the boot loader code
portion of the instantiated cloud-based target server such that the
target server will execute the deploy agent code upon reboot of the
target server; the migration server providing an instruction to the
cloud server control system to effect a reboot of the instantiated
cloud-based target server; upon reboot of the cloud-based target
server, executing the deploy agent code; the deploy agent code
gathering server configuration information from the cloud-based
target server including any operational parameters associated with
the cloud environment; the deploy agent code communicating to the
migration server a notification that the deploy agent is running on
the cloud-based target server and available to perform an image
migration; the deploy agent code communicating the gathered server
configuration information to the migration server; upon receiving
the notification that the deploy agent on the cloud-based target
server is available, and upon receiving the target server's
configuration information, the migration server mapping the
configuration of the captured image to match the configuration of
the available cloud-based target server; the migration server
sending migration instructions to the deploy agent including the
location of the image on the image server and the required
configuration of the target server, upon receiving migration
instructions from the migration server, the deploy agent code
reading the captured image of the source server from the image
server and installing it on the cloud-based target server; and the
deploy agent code executing configuration operations to modify the
image that it has deployed to the cloud-based target server.
24. The method of claim 23, wherein the deploy agent code executing
configuration operations to modify the image it has deployed to the
cloud-based target server are effected in accordance with: (a) the
server configuration information and image configuration
information gathered from the source server, (b) the available
configuration of the cloud-based target server; (c) any operational
parameters associated with the cloud environment in which the
cloud-based target server is running; and (d) any configuration
requirements that were specified by an end user when requesting the
image migration.
25. The method of claim 23, wherein the capture agent runs directly
on the source server.
26. The method of claim 23, wherein the capture agent runs on a
computer system other than the source server, but has access to the
storage containing the source server image.
27. The method of claim 23, wherein the cloud-based target server
is provided by a private cloud or a public cloud.
28. The method of claim 23, wherein the source server is one of the
group comprising: a physical server, a virtual server, a cloud
server.
29. The method of claim 23, wherein the migration server receives
commands from a user interface for receiving commands from a human
end user or from an application programming interface (API) for
receiving commands from an external automated systems.
30. The method of claim 23, wherein the instructions to the cloud
server control system from the migration server are provided to an
API of the cloud server control system.
31. The method of claim 23, wherein the migration server examines
the information gathered from the capture agent to determine the
configuration of the source server including the number of CPUs,
amount of memory, and the number and size of storage devices, and
then specifies appropriate configuration parameters to the cloud
server control system in order to create a target cloud server of
similar capacity.
32. The method of claim 23, wherein the operational parameters
associated with the cloud environment comprise operational
requirements or operational restrictions.
33. The method of claim 23, wherein the migration server installs
the deploy agent on a pre-existing cloud server rather than
creating a new one using the cloud server control system.
34. The method of claim 23, wherein the step of modifying the boot
loader code portion of the instantiated cloud-based target server
to execute the deploy agent code comprises the steps of: providing
a boot loader code modification program together with the deploy
agent code, the boot loader code modification program operative to
change the boot loader code of the particular OS type of the
instantiated cloud-based target server; and executing the boot
loader code modification program prior to reboot of the
instantiated cloud-based target server.
35. The method of claim 23, wherein the deploy agent code is
provided as a ramdisk image that is executed by the cloud-based
target server after rebooting.
36. The method of claim 23, wherein the cloud-based target server
is rebooted using an operating system command run on the target
server rather than through a command issued to the cloud server
control system.
37. The method of claim 23, wherein the deploy agent is
instantiated directly on the target cloud server by the cloud
server control system using a compact disc read-only memory
(CD-ROM) or DVD image in ISO 9660 format.
38. The method of claim 23, wherein the deploy agent is
instantiated directly on the cloud-based target server by the cloud
server control system using a template image maintained by cloud
server control system.
39. The method of claim 23, wherein the step of capturing the image
of the source server is effected under control of a migration
manager computer program executing on the migration server.
40. The method of claim 23, wherein the step of deploying the
captured image to the target cloud server is effected under control
of a migration manager computer program executing on the migration
server.
41. The method of claim 23, wherein a migration manager computer
program executing on the migration server effects control of both
the capture and deploy steps of the migration process such that the
source server image is transferred directly from the capture agent
on the source server to the deploy agent on the cloud-based target
server rather than stored in an image server.
42. The method of claim 23, wherein the operating system (OS) of
particular type is selected from the group comprising: LINUX,
Windows, Mac OSX, FreeBSD, Solaris.
43. The method of claim 23, wherein the operational requirements
associated with the cloud environment require the deploy agent to
modify the migrated image that it has deployed to the cloud-based
target server in order to install any special device drivers
necessary to run the image on the cloud-based target server.
44. The method of claim 43, wherein the deploy agent collects the
necessary device drivers from the operating system of the
cloud-based target server as originally created by the cloud server
control system.
45. The method of claim 43, wherein the migration server maintains
a library of the necessary device drivers for installation on the
cloud-based target server.
46. The method of claim 23, wherein the deploy agent modifies the
file system layout of the original source server image to fit upon
the storage devices that are provided by the cloud-based target
server, such modifications including one or more of: (a)
Consolidating logical units (LUNs) or partitions of storage onto
the available storage volumes, (b) Consolidating multiple file
systems onto a single LUN or partition, (c) Resizing the space
allocated to a file system to fit onto the available LUN or
partition, or (d) Changing the type of file system.
47. The method of claim 46, wherein the calculations on how to
modify the file system layout of the original source server image
are made by a migration manager computer program executing on the
migration server and sent to the deploy agent running on the
cloud-based target server as a set of instructions.
48. The method of claim 23, wherein the deploy agent modifies the
network configuration of the original source server image so that
the migrated cloud-based target server will be configured properly
to access network communications within the target cloud
environment.
49. The method of claim 48, wherein the deploy agent collects the
necessary network configuration information required for operation
within the target cloud environment from the operating system of
the cloud-based target server as originally created by the cloud
server control system.
50. The method of claim 48, wherein the calculations on how to
modify the network configuration of the original source server
image such that the deployed cloud-based target server will work
within the target cloud environment are made by a migration manager
computer program executing on the migration server and sent to the
deploy agent running on the target cloud server as a set of
instructions.
51. The method of claim 23, wherein the deploy agent modifies the
migrated image that it has deployed to the cloud-based target
server in order to install any additional software, such as
management or monitoring agents, that are required by the cloud
vendor in order for a server to operate within the cloud
infrastructure.
52. The method of claim 23, wherein all communications between the
migration server, the source server and cloud-based target server
are implemented through the exchange of messages using a mailbox
communications server, the mailbox communications server being
configured to receive incoming file service requests to create,
read, write, or list files, the file service requests being
implemented using network communications protocols such that all
requests originate with the migration server, source server, or
target server and pass through any firewalls protecting them to
reach the mailbox server.
53. The method of claim 52, wherein the protocol used to implement
the file service requests of the mailbox server selected from the
group comprising: Amazon S3 protocol, Web Distributed Authoring and
Versioning (WebDAV), File Transfer Protocol (FTP), SSH File
Transfer Protocol (SFTP).
54. A system for migrating a computer server image from a source
server to a cloud-based target server, the source server and
cloud-based target server being connected for electronic
communications via a data communication network, the cloud-based
target server being controlled by a cloud server control system
that controls one or more cloud-based target servers, comprising: a
migration server coupled for electronic communications with the
source server and the cloud-based target server, the migration
server connected for electronic communications with the cloud
server control system; and computer program code on the migration
server comprising computer executable instructions that, when
executed on the migration server, carry out the steps of: gathering
configuration information for the source server and a source server
image from a capture agent associated with the source server;
providing an instruction to the cloud server control system to
instantiate a cloud-based target server having an operating system
(OS) of the same particular type as said source server OS; loading
a deploy agent code onto the instantiated cloud-based target
server, the deploy agent code comprising code for executing
configuration operations to install the captured image of the
source server to the cloud-based target server; and sending
migration instructions to the deploy agent including the location
of the captured image of the source server and the required
configuration of the target server, the deploy agent code
thereafter executing on the instantiated cloud-based target server
to read the captured image of the source server, install it on the
cloud-based target server, and execute configuration operations to
modify the image that it has deployed to the cloud-based target
server.
55. The system of claim 54, wherein the OS of the instantiated
cloud-based target server including a boot loader code portion, and
wherein the computer program code further carries out the steps of:
modifying the boot loader code portion of the instantiated
cloud-based target server such that the target server will execute
the deploy agent code upon reboot of the target server; and
providing an instruction to the cloud server control system to
effect a reboot of the instantiated cloud-based target server such
that the deploy agent code executes on the cloud-based target
server to read the captured image of the source server, install it
on the cloud-based target server, and execute the configuration
operations.
56. The system of claim 54, further comprising an image server
associated with the migration server for storing a captured image
of the source server, and wherein the deploy agent executes on the
instantiated cloud-based target server to read the captured image
of the source server from the image server.
57. The system of claim 54, wherein the deploy agent executes on
the instantiated cloud-based target server to read the captured
image of the source server directly from the source server.
58. The system of claim 54, further comprising the step of: sending
migration instructions to the capture agent associated with the
source server including information identifying parameters for the
captured image, the deploy agent thereafter capturing the image of
the source server and deploying the captured image to a source
image destination.
59. The system of claim 58, wherein the source image destination is
selected from the group comprising: an image server associated with
the migration server, the cloud-based target server, a
network-addressable storage device.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application claims benefit under 35 U.S.C. .sctn.119(e)
of U.S. Provisional Patent Application No. 61/640,475, filed Apr.
30, 2012, and entitled "Server Image Migration into Public and
Private Cloud Infrastructures," which is incorporated herein by
reference as if set forth herein in its entirety.
[0002] This application is also related to co-pending application
U.S. Nonprovisional patent application Ser. No. ______, filed Apr.
30, 2013.
TECHNICAL FIELD
[0003] The present disclosure relates to physical, virtual, and
cloud servers and the methods and apparatuses for migrating an
image between them.
BACKGROUND
[0004] A server is a computer system that provides some type of
service to one or more client computer systems. Clients typically
access the service using a network connection: local clients over a
local area network (LAN), remote clients over a wide area network
(WAN).
[0005] A server image is a logical embodiment of a server that
contains all of the data needed to boot and operate one or more
services on a computer. A server image typically includes (but is
not limited to) a kernel and operating system(s), device drivers
(that are normally associated with hardware-related components),
application software and data, and configuration settings
associated with the network and storage environments.
[0006] A server can run an image by having the image installed into
its permanent memory or onto a storage device accessible to the
server. Alternately it can dynamically access the image via a
network connection.
[0007] Because a server image includes device drivers and several
other hardware-related components that are specific to the computer
hardware on which it runs, and because the image includes
configuration settings for the network and storage environments
surrounding the computer on which it runs, an image will not
function properly when moved from one computer environment to
another without being significantly reconfigured. The "migration"
process moves an image from one computer to another, reconfiguring
it as appropriate for the new computer hardware and
environment.
[0008] The embodiment of a single server running an image to
provide one or more services is often called a "workload". On the
basis of current technology, typically there are three ways to run
a workload, e.g., when the single server is functioning as: 1) a
physical server, 2) a virtual server, and 3) a cloud computer. A
physical server is a dedicated physical computer running a single
workload such that the operating system has exclusive, direct
access to the computer's hardware. A virtual server is a workload
running concurrently on a virtualization host such that the
virtualization host intercedes between the computer hardware and
the operating system within the workload to manage access to the
physical resources of the underlying computer. Common
virtualization hosts would include computers running a VMware.TM.
or Xen.TM. hypervisor. A cloud computer is a workload running on a
pool of physical and/or virtual resources that can be dynamically
allocated on demand to a varying number of workloads. Clouds can be
"private" such that the physical resources are owned by the same
entity that owns the workloads, or "public" such that the physical
resources are owned by a third party and made available for use by
the workload owner, typically for a fee.
[0009] Physical, virtual, and cloud servers provide different
tradeoffs between total cost of ownership (TCO) and performance.
Physical servers generally provide the best performance but
generally have the highest TCO. Virtual servers reduce TCO by
running multiple workloads on a single physical computer, but
generally provide lower performance because they cannot provide a
single workload with access to all the resources of that computer.
The use of cloud servers can greatly reduce the capital cost
component of TCO when dynamically scaling a service to match its
current load. This is particularly effective when using public
clouds where the capital costs are born by a third party.
[0010] The optimal placement of a workload, whether on a physical,
virtual or cloud server, might change over time for many reasons
such as the life cycle (development, test, production, etc.) of the
service, the number of clients currently accessing the service, or
the availability of more efficient physical resources. The TCO of a
workload would be greatly reduced if there were a way to rapidly
migrate it from one server to another, freely moving between
physical, virtual, and cloud servers so that it can always be
placed on the most cost-effective resource that meets its current
needs.
[0011] Conventionally, the process of migrating a workload from one
server environment to another is largely a manual process that is
time consuming, error prone, and very expensive. The automated
migration tools that exist today are limited in capability. Tools
provided by the virtualization vendors such as VMWARE.TM. and
CITRIX.TM. typically providing migration into their specific
hypervisor environment. More general purpose tools such as
Symantec's Ghost.TM. and Platespin's Migration.TM. Manager.TM.
usually do not support cloud servers and cannot work outside a
corporate LAN environment.
[0012] Therefore, there is a long-felt but unresolved need for a
system and/or method that provides the ability to freely migrate a
workload between any types of environments, e.g., between physical,
virtual, and cloud environments.
BRIEF SUMMARY
[0013] The present disclosure meets the needs identified above by
providing systems and methods for the migration of server images
between physical, virtual, and cloud servers.
[0014] In an embodiment, the present disclosure describes a capture
agent that runs on the source server to survey the environment in
which the image runs and capture the image, a deploy agent that
runs on a target server (regardless of whether the target server is
a physical, virtual, or cloud, server) in order to survey the
target server environment and deploy the source image into that
environment, a migration manager to coordinate the migration
process and map the requirements of the source image onto the
resources available in the target environment, an image library in
which to optionally store the image for later use, and a
mailbox-based communications mechanism to support server management
operations that span multiple data center environments and
corporate firewalls.
[0015] These and other aspects, features, and benefits of the
present disclosure will become apparent from the following detailed
written description of the preferred embodiments and aspects taken
in conjunction with the following drawings, although variations and
modifications thereto may be effected without departing from the
spirit and scope of the novel concepts of the disclosure.
BRIEF DESCRIPTION OF THE DRAWINGS
[0016] The accompanying drawings illustrate one or more embodiments
and/or aspects of the disclosure and, together with the written
description, serve to explain the principles of the disclosure.
Wherever possible, the same reference numbers are used throughout
the drawings to refer to the same or like elements of an
embodiment, and wherein:
[0017] FIG. 1 is an exemplary embodiment of a system for migrating
server images between physical, virtual, and cloud servers.
[0018] FIG. 1a is a flow chart showing the high level computer
implemented steps in an exemplary image migration process.
[0019] FIG. 2 is a flowchart showing computer-implemented steps in
an exemplary image capture process, according to one embodiment of
the present disclosure.
[0020] FIG. 3 is a flowchart showing computer-implemented steps in
an exemplary image deploy process, according to one embodiment of
the present disclosure.
[0021] FIG. 4a is an example of mapping an image from a source to a
target environment.
[0022] FIG. 4b is a flowchart showing computer-implemented steps in
an exeemplary image mapping process, according to one embodiment of
the present disclosure.
[0023] FIG. 5 is a flowchart showing computer-implemented steps in
an exemplary image configuration process, according to one
embodiment of the present disclosure.
[0024] FIG. 6 is a block diagram showing an exemplary method of
communicating through firewalls using mailboxes.
DETAILED DESCRIPTION
[0025] For the purpose of promoting an understanding of the
principles of the present disclosure, reference will now be made to
the embodiments illustrated in the drawings and specific language
will be used to describe the same. It will, nevertheless, be
understood that no limitation of the scope of the disclosure is
thereby intended; any alterations and further modifications of the
described or illustrated embodiments, and any further applications
of the principles of the disclosure as illustrated therein are
contemplated as would normally occur to one skilled in the art to
which the disclosure relates.
[0026] I. The Migration Process
[0027] Referring to FIG. 1, an exemplary embodiment of a system 100
that provides migration of server images between physical, virtual,
and cloud servers. As shown, a source server 101 comprises an
attached source image 102 and a capture agent 105. In one
embodiment the source server is a physical server and the image is
written on the server's disk drive that is directly attached to the
server. In another embodiment the source server is a virtual server
and the image is written to a virtual storage device managed by the
virtualization host. In yet another embodiment the source server is
a cloud server and the image is written to a storage volume managed
by the cloud infrastructure. Those of ordinary skill in the art
will appreciate that there are many ways to store a server image
and make it accessible to the server such that the server can
successfully boot and run the image. Any system, method or
technique that is known in the art may be used for storing,
booting, and running the image on the source server, whether a
physical, virtual, or cloud server.
[0028] The capture agent 105 runs on a computer system that has
access to the source image 102. In one embodiment the capture agent
runs on the source server while the server is actively running the
source image. This is called "live" image capture. In another
embodiment the capture agent runs on the source server while the
server is not actively running the source image. This is called
"offline" capture. Any system, method or technique known in the art
may be used for running the agent on the source server such that
the source image is not active but still accessible to the server.
Some examples include booting the agent from a CD-ROM or ISO image,
or booting the agent from the network using PXE. In yet another
embodiment, the capture agent runs on a computer other than the
source server that has access to the source image. An example that
involves capturing an image from a virtual server would be a
virtualization host on which the virtual server is running. An
example that involves capturing an image from a physical server
whose image is stored on a SAN volume would be some other computer
that has access to the SAN volume.
[0029] The target server 120 is shown with its system storage 121
on which will be stored the migrated server image. Any form of
storage that can hold a bootable server image can be used by an
embodiment of the invention(s) described herein. Examples when the
target server is a physical server would include (but are not
limited to) directly attached disk drives, removable storage
devices such as a flash USB drive, or network accessible storage
such as a fibre-channel or iSCSI SAN volume. When the target server
is a virtual server, its system storage will typically be a virtual
disk drive managed by the virtualization host or a dedicated SAN
LUN. When the target server is a cloud server, its system storage
will be provided by the cloud infrastructure.
[0030] The deploy agent 125 runs on a computer system that has
access to the target server's system storage. It is responsible for
gathering information about the target server and its system
storage, and for deploying the migrated image to the target
storage. In one embodiment the deploy agent runs on the target
server and writes the image directly to the target server's system
storage. In another embodiment the deploy agent runs on some other
computer system that has access to the target server's system
storage. An example when migrating to a virtual server would be the
virtualization host that is managing the virtual disk drive for the
target server. An example when migrating to a physical server
booting from a SAN volume would be some other computer that has
access to the SAN volume.
[0031] The exemplary embodiment of the system 100 provides two
methods for migrating a server image, a "direct" approach and a
"capture/deploy" approach. The "direct" migration streams the
source image directly from the capture agent 105 to the deploy
agent 125. This approach has the benefit of copying the image just
one time over the network. Typically, such an approach has two
disadvantages. Firstly, if a system image needs to be migrated a
second time, then the entire migration operation has to be
repeated. Secondly, the source image cannot be migrated if the
source image no longer exists, is not currently accessible, or has
become corrupted.
[0032] The "capture/deploy" approach works in two steps. First, the
capture agent 105 captures the source image to an image library 150
where it is stored for later use. At some later time, the deploy
agent 125 reads the image from the library and deploys it to the
target server's system storage. By retaining a copy of the captured
image, this approach can use a single capture to deploy multiple
copies of the source image. Additionally, according to this
approach, the deploy agent 125 can deploy the image after the
source server and image no longer exist or have become corrupted,
which can be useful for applications such as disaster recovery.
FIG. 1a shows the high level flow for the two-step process.
[0033] As shown in FIG. 1, the migration manager 160 is responsible
for controlling the migration process using a task sequencer 161,
which coordinates and sequences the tasks required for server image
migration across the capture agent 105, deploy agent 125, image
library 150, and other components that participate in the process.
The migration manager includes a user interface (UI) 162 that is
used by a system administrator to interact with the migration
manager, wherein the system administrator (the user) is an
individual who is responsible for the server migration process. In
other words, UI 162 provides a mechanism by which the user
initiates capture, deploy, or direct migration processes. Also, UI
162 allows the user to specify configuration settings for the
migration system 1A01, e.g., users can specify parameters specific
to a particular process. According to aspects of the present
disclosure, the UI 162 may be a command line interface (CLI),
graphical user interface (GUI), or an application programming
interface (API) by which the migration manager can be controlled by
some other computer program. As shown in 1A02, an image migration
process can also be initiated by an external automated system in
response to an external event, such as the failure of a server, an
application requiring additional capacity, or less expensive
resources becoming available.
[0034] Now turning to FIG. 2, an exemplary image capture process is
shown with the help of a flowchart. According to one aspect,
several steps of the flowchart involved in an image capture process
are performed by a capture agent 105, or by various components
(e.g., Hardware Scanner 106, Application Scanner 108, and others)
included within capture agent 105 (e.g., see FIG. 1). Such steps
are annotated (within the flowchart) using the notation "CA", short
for capture agent 105. According to another aspect, the image
capture process typically begins with the installation step 201 of
the capture agent. As previously described, the capture agent 105
can run on the source server in either a live or an off-line mode.
Alternately, the capture agent can also run on some other computer
that has access to the storage device holding the source server
image. The description that follows herein generally applies to the
live mode of running the agent on the source server. It will occur
to one skilled in the art that any method can be used to run the
capture agent on the live source server. For example, a method
could involve manual installation using a CD-ROM, or automated
installation using a patch management system. The installation of
the capture agent is shown in 1A04.
[0035] Once installed, the capture agent surveys the environment
1A05 in which the image runs and saves relevant data so that such
data can be subsequently used by the migration manager in an image
mapping process. In one exemplary embodiment of the disclosed
system, surveying tasks (e.g., in steps 202-205) are optional. As
will be understood, a large number of surveying tasks, along with a
greater detail of such tasks will improve the system's ability to
accurately map the image's operating environment to the target
server environment. Generally, the order in which these tasks are
performed does not matter. Survey task step 202 in this exemplary
embodiment involves taking an inventory of the source server
hardware for identifying all physical or virtual hardware available
to the source server. For example, hardware scanner component 106
(included in capture agent 105 as shown in FIG. 1) performs the
survey task 202. Although not shown in FIG. 2, information relating
to the inventory of the source server hardware is stored as part of
the image metadata 152, wherein the image metadata 152 itself is
further stored as part of the captured image 151, e.g., as shown in
FIG. 1. The image metadata does not need to be stored physically
with the image file system data, and also no limitations are
imposed on the format in which the image metadata is stored. For
example, the image metadata can be stored in a database, an XML
file, or any other format commonly known in the art.
[0036] Next, in step 203, the capture agent 105 surveys the
operating systems configuration settings of the source, e.g., by
using an operating system scanner component 107. Although not shown
in FIG. 2, such operating systems configuration settings are stored
as part of the image metadata 152. Examples of operating systems
configuration settings include (but are not limited to)
configuration settings of all network interfaces including
addresses, netmasks, gateways, routes, name servers, etc;
configuration settings of the storage devices including disks, RAID
groups, partitions, volume groups, logical volumes, file systems,
attached SAN devices, remote file shares, etc; configuration
settings of the user authentication system including any external
services required for user authentication such as directory
services, domain services, etc.
[0037] After the capture agent 105 surveys the operating systems
configuration settings of the source, the capture agent 105 then
surveys (at step 204) various services and applications installed
within the source image. In one exemplary aspect, step 204 is
performed by the application scanner component 108, included within
capture agent 105 (see FIG. 1). It will be generally understood
that in step 204, the application scanner component 108 gathers the
configuration settings for each service or application, installed
within the source image. Further, (not shown in FIG. 2), the
capture agent 105 stores (along with the image metadata 152) the
gathered configuration settings and associated application data. In
one exemplary scenario, associated application data includes
naming, addressing, or routing information for any network or
storage resources used by the application. It will be understood
that in scenarios wherein the original source environment of the
image cannot be exactly duplicated at the target server as part of
a migration process, some of these configuration settings may have
to be modified in order for the application or service to function
properly post migration.
[0038] The final survey task (step 205) is to survey the
infrastructure surrounding the source server, including but not
limited to any LANs or virtual LANs (VLANs) and any external
storage devices to which the source server is connected. Typically
this information cannot be determined from within the context of
the source server itself and thus is gathered by accessing the
management interfaces of the infrastructure systems. Thus, this
task is usually performed by the migration manager 160 (also
referred to herein as "MM") running on a computer that is trusted
to access the infrastructure systems. It will occur to one skilled
in the art that many data center environments already have tools
installed to map these infrastructure connections, for example,
there are many common management tools using the simple network
management protocol (SNMP). As shown in 205, the migration manager
160 can access a source ("External") infrastructure scanner 140
where available. If the source server is a virtual server, the
virtualization host that is running the virtual server will
typically provide the network and storage infrastructure.
Accordingly, survey information related to the network and storage
infrastructure can be obtained directly from the virtualization
management system. If the source server is a cloud server, the
cloud infrastructure will typically provide APIs by which this
information can be retrieved.
[0039] After the survey of the source server environment, the
capture agent begins the actual capture 1A06 of the source image
file systems using its image capture component 109. Usually, there
are two common approaches to capturing image file system data:
file-based and block-based capture. File-based capture reads the
file data out of the underlying file system, saving the data for
each file separately in a manner that is independent of the
original file system format and disk layout. This makes it easy to
resize the file system, change the file system type, or change the
storage configuration and layout when deploying the image onto a
target server. Block-based capture reads and captures the file
system layout as well as all file system data directly from the
underlying storage by capturing all data blocks associated with the
underlying storage. When used with compression, this is usually
faster than file-based capture. It also allows for very efficient
incremental updates on a block-by-block basis. It has the
disadvantage of requiring the target deployment to use exactly the
same size disk and file system type for image deployment. Although
an embodiment of the present disclosure can use either technique,
or any other image capture technique known in the art, the
embodiment described in this disclosure uses file-based
capture.
[0040] As the image capture operation will occur over a length of
time that varies with the size of the image, if the source server
is running and its applications are online, it is possible that the
image data might change during the capture operation, resulting in
an inconsistent and possibly invalid captured image. Thus when
capturing an image from a running server, the image capture
component 109 takes (at step 206) a snapshot of the volumes holding
the image, if the capability is supported by the underlying storage
subsystem. This helps ensure that the entire captured image is
consistent for a single point in time.
[0041] For each of the file systems to be captured, the capture
agent then streams (at step 210) the file system data to the target
destination, which is either the image library 150 or the deploy
agent on the target server 125. The file system data is processed
one file at a time. At step 211, the file metadata is read and
added to the stream. This typically includes file system attributes
such as the ownership, access permissions, last creation or access
time, etc. The file data is then read at step 212 and added to the
stream. Any method or format known in the art can be used to encode
or save the file data and metadata to the stream. This would
include but is not limited to the tape archive format (tar), copy
in-out (cpio) and other file archiving and backup formats.
Typically all file systems that are mounted and in-use by the
server will be captured. The user can optionally override this
default and specify mounted file systems that are not to be
captured or unmounted file systems that are to be captured. The
user can also optionally specify the capture of raw disks, volumes,
or partitions. As these have no recognizable file system format,
they are captured using block-mode capture.
[0042] Still referring to FIG. 2, the data stream can be optionally
compressed at step 213. Over slow network environments, compression
can greatly speed the capture operation. However, over very fast
network environments it can actually slow down the capture
operation if the capture agent cannot compress the data quickly
enough to keep up with the network line speed. Compression can also
be a disadvantage when performing a live capture as compressing the
data will consume CPU cycles on the source server, perhaps
impacting the performance of the applications. Any method or
algorithm for data compression known in the art can be used to
compress the data stream.
[0043] The archived file system data in the data stream can be
optionally encrypted 214 to ensure its confidentiality if stored in
an image library. Any encryption algorithm known in the art for
encrypting a data stream can be used. As the data stream will need
to be decrypted, key management and distribution is essential to
ensuring the confidentiality of the file system data. Any method of
key management known in the art can be used including, but not
limited to, shared secret keys or public-key based distribution
schemes. Like compression, encryption can adversely affect the
performance of any applications running on the source server as it
will consume CPU cycles.
[0044] For efficient network transfer, the data stream is typically
buffered (step 215) and transferred at step 216 in blocks of a size
efficient for the network technology in use. Any network technology
for streaming data can be used to transfer the captured image to
the destination. This would include but is not limited to the
hypertext transfer protocol (HTTP), the secure socket layer
protocol (SSL), the file transfer protocol (FTP), or a raw
transmission control protocol (TCP) connection. After the image
transfer has been completed, any volume snapshots that were used in
the capture process are typically released at step 220.
[0045] When the captured image is not used for a direct migration,
it is stored in an image library 150. Each captured image 151
contains the image metadata 152 gathered by the capture agent's
survey steps 202-205 as well as the archived file system data 153.
Each archived file 154 contains the file's data 155 and metadata
156. Any archive format known to the art can be used to represent
and store the archived file system data. The discussions in
connection with FIG. 2 are for purposes of example and explanation.
According to aspects of the present disclosure, many modifications
can be made to the above-mentioned steps, as will occur to one
skilled in the art.
[0046] Now turning to FIG. 3, an image deploy process is shown. In
one exemplary embodiment, and as shown in FIG. 3, various steps of
the image deploy process are performed by different components of
the disclosed system, e.g., migration manager (MM) 160, a deploy
agent (DA), and others. Starting at step 301, a user (e.g., system
administrator) specifies a source image and a target server 302.
Further, the user also specifies deployment options (e.g., storage
or file system layout, network configuration, etc.) specific to a
particular deploy process. Accordingly, these are collected by the
migration manager at step 303. As will be understood, the image
source can be any server with an installed capture agent or any
previously captured image. The target server can be a pre-existing
physical, virtual or cloud server. Alternatively the user may
identify a pool or group of servers from which to select an
available target. In yet another alternative aspect, the user may
specify the desired characteristics for the target server, such as
type of CPU, number of CPUs, amount of memory, disk storage, etc,
and allow the migration manager to select a suitable target from
the pool of available servers. When deploying to a virtual server,
the user may specify a target set of virtual resources in which to
create a new virtual server, such as a specific virtualization
host, a resource pool, data center, etc. When deploying to a cloud
infrastructure, the user may specify the cloud vendor, the data
center or region, set of resources such as an availability zone,
and the type or size of server to be created.
[0047] The user can either start the deployment immediately or
schedule it to occur at some later time or in response to a
specific event, such as the failure of the original source
server.
[0048] The migration manager's task sequencer 161 begins the actual
deployment or migration operation by first configuring (at step
304) the target hardware by using the hardware configuration module
166 to communicate with the target infrastructure using the
appropriate vendor's application programming interface (API), e.g.,
cloud vendor API 180 or virtualization vendor API 181. This is
shown by 1A07. Specifically, the hardware configuration module 166
issues commands to create the server if it does not already exist,
specify the system BIOS settings, the number of CPUs, the amount of
RAM, the number and type of network interfaces, the number and type
of storage interfaces, and the number, size, and type of storage
devices.
[0049] In many scenarios, it may not be possible to configure the
hardware for physical servers, as very few physical servers allow
for dynamic configuration of their resources. To configure the
hardware of a virtual server the migration manager will typically
access the management system for the server's virtualization host
in order to create a new virtual server matching the required
configuration. To configure a cloud server the migration manager
will typically access the cloud infrastructure's APIs in order to
create a new virtual server matching the required configuration. In
many scenarios, cloud providers limit the configuration options to
a pre-defined set of approved hardware configurations. In such
scenarios, it may be necessary to choose the predefined
configuration that most closely matches the desired
configuration.
[0050] In one aspect, configuring (at step 305) the infrastructure
surrounding the target server is optional and usually involves
specifying the connections between the target server and its
surrounding environment. This includes but is not limited to:
configuring the switch ports to which a network interface is
connected, specifying the VLAN settings on the switch ports,
specifying firewall rules to allow network access to the server,
adding the server to a load balancing pool, and specifying the
connection between a storage adapter and an external storage
volume. To configure the target infrastructure, the migration
manager will typically access an external infrastructure
configuration component 182 using that component's APIs. For
physical servers this might be an existing data center management
system that controls the network and storage infrastructures within
the data center. For a virtual server the migration manager will
typically access the management system for the virtualization host,
which controls the virtual infrastructure surrounding the virtual
server. For a cloud server the migration manager will typically
access the cloud infrastructure's APIs in order to specify the
server's network and storage environment.
[0051] Once the target hardware and infrastructure have been
configured, the task sequencer 161 installs (at step 306) a deploy
agent to build out the new target image 1A08. In order for the
deploy agent 125 to configure the storage for the target server and
build out new file systems in which to load the image, the agent is
to be run in a manner such that its own software is not run
directly from the target storage. Otherwise it would cease to
function when it reconfigured the target storage. In one embodiment
of the present disclosure, the deploy agent 125 is run directly on
the target server in a manner that does not require the agent
software to be run from the target storage. In another embodiment
of the present disclosure, the deploy agent 125 is installed on
some other computer that has access to the storage system that will
be used for the deployed image. The description of the deploy
process provided below herein is based on the assumption that the
deploy agent 125 is run directly on the target server in a manner
that does not require the agent software to be run from the target
storage. However, it will be understood that alternate embodiments
wherein the deploy agent 125 is installed on some other computer,
will include similar steps in a deploy process.
[0052] There are several methods known in the art for running a
program such as the deploy agent on a computer without relying on
the underlying storage. Any such method may be used. For example,
in one embodiment of the present disclosure, the target server may
be booted using a network boot protocol such as the pre-boot
execution environment (PXE). In another embodiment of the present
disclosure, the target server may be booted using an international
organization for standardization (ISO) image of a compact disk
read-only memory (CD-ROM).
[0053] Many cloud environments do not allow external management
systems to access the local LAN environment of the cloud
infrastructure, thus the migration manager will not have access to
any PXE requests coming from the cloud servers. Also, many cloud
infrastructures do not expose a mechanism for booting a server
directly from an ISO image. In such environments one way to run the
deploy agent on the target server is as follows: 1) have the cloud
infrastructure create and boot a server of a type matching the
image to be migrated--for example, when migrating a Windows 2008
image, create a Windows 2008 cloud server; 2) Package the deploy
agent as a ramdisk image; 3) After the cloud server becomes
available, copy the ramdisk image to the cloud server's file
system; 4) Modify the server's boot loader configuration to run the
deploy agent ramdisk rather than the cloud server image; and 5)
Reboot the server 1A09. When the cloud server reboots it will then
run the deploy agent image directly from the installed ramdisk,
leaving the cloud server's disk drives free and available for
provisioning. Some cloud infrastructures boot servers running the
LINUX operating system directly without using a boot loader
program. The deploy agent can be run on such systems in a manner
similar to the method described above. But instead of modifying the
boot loader configuration, the LINUX initialization program,
/etc/init, can be replaced with a version modified to install the
ramdisk image and run the deploy agent
[0054] Some cloud environments provide a facility for taking a
snapshot of a running cloud server and using the resulting snapshot
as a template for creating new cloud servers. When such a facility
exists, the time to create a cloud server with an installed deploy
agent can be greatly decreased by installing the ramdisk and
configuring the boot loader as described in the previous paragraph,
and then taking a snapshot of the server rather than rebooting it.
Creating a cloud server from the new template will then run the
deploy agent from the ramdisk. This eliminates the time required in
the original approach to copy the ramdisk over the network and
reboot the cloud server.
[0055] Some cloud infrastructures provide linux servers on a Xen
virtualization host using Xen's direct boot mode. This means that
the virtualization host ignores the operating system kernel within
the image and directly boots some other kernel specified by and
maintained by the cloud infrastructure. This will only work if the
image contains a set of drivers matching the kernel chosen by the
cloud infrastructure. This would always be the case when creating a
server from one of the cloud's own templates. But it is unlikely to
be the case when migrating an image that originated outside the
cloud into the cloud environment, with the result that the migrated
server fails to boot. This problem can be fixed by installing the
correct drivers--i.e., those matching the kernel used by the cloud
infrastructure--during the image deploy process. The drivers can be
easily packaged and installed during the software injection phase
of the image configuration process 532. But this would require that
a driver package be prepared for all of the kernels supported by
the cloud infrastructure. Thus, when running on a cloud server
target, the first step performed by the deploy agent is to mount
the original system image created by the cloud provider and copy
all device drivers into the agent's ramdisk 1A10. They can then be
later installed into the deployed image in the driver configuration
phase 533 of the image configuration process FIG. 5. This ensures
that the drivers matching the kernel used to boot the cloud server
are always copied into the migrated image.
[0056] Within many cloud infrastructures security and routing
restrictions require the cloud server to use a very specific
network configuration in order to communicate with the cloud
infrastructure and external systems such as the migration manager.
Thus, at step 309, the deploy agent when running on a cloud server
target copies the original network configuration of the cloud
server into the configuration of the deploy agent 1A10. This
ensures that the deploy agent can communicate with the migration
manager. Later this same network configuration will be read from
the target server during the OS survey step 311 and then included
in the image mapping process 312. This ensures that the required
network configuration is transferred to the deployed target after
migration.
[0057] After the initial steps specific to cloud deployment, the
deploy agent surveys the target environment 1A10. First it uses its
hardware scanner component 126 to survey the target server's
hardware 310. The results of this survey are sent back to the
migration manager as server metadata. The specific format of the
metadata and the method for communicating it back to the migration
manager do not matter. The example embodiment uses the same method
used by the capture agent for capturing the image metadata.
[0058] For cloud deploys, the survey of the hardware configuration
is followed by a survey of the operating system settings 311 by the
operating system scanner 127. As will be generally understood, the
operating system being surveyed is that of the deploy agent itself,
which is generally not relevant to the migration of the image. But
it is useful when migrating into public cloud environments and will
be discussed in detail later herein.
[0059] After the target survey is complete, the operating
environment and configuration of the source image is to be mapped
onto the target environment 1A11, which consists of the hardware of
the target server and the surrounding network and storage
infrastructures 312. This mapping process is performed by the
migration manager's mapping function 163 and is shown in more
detail in FIG. 4b.
[0060] Server migration can be used to achieve many important uses
within a production data center including but not limited to:
hardware refresh, server virtualization, data center consolidation,
rapid server recovery, disaster recovery, application scaling, lab
management, and software lifecycle management. Each of these use
cases has different requirements for how the configuration of the
source image gets mapped into the target environment. An example of
this image mapping process is shown in FIG. 4a. In the example
shown, an image is moved from a source server 410 that has two
network interfaces 411 and 412 and a set of storage devices 413
consisting of three disk drives to a target server 415 that has
just one network interface 416 and a single disk drive 417. This is
a typical example of server virtualization in which an existing
physical server is removed and replaced with a new virtual server.
In order to replace the original server without requiring changes
to the applications running within the image or changes to other
systems that might rely on the original server, the target server
has to retain the source server's full configuration. Thus, both of
the network configurations on the source server are moved onto the
single network interface of the target server. The two file systems
on the source server, which are spread over three disk drives, are
to be moved onto the single disk drive of the target server. This
is shown in the mapping equation 420, which is repeated here:
S.sub.src=NI.sub.1(V.sub.a+N.sub.a+A.sub.a)+NI.sub.2(V.sub.b+N.sub.b+A.s-
ub.b)+FS.sub.1(D.sub.1+D.sub.2)+FS.sub.2(D.sub.3)
.fwdarw.S.sub.tgt=NI.sub.1((V.sub.a+N.sub.a+A.sub.a),(V.sub.b+N.sub.b+A.-
sub.b))+D.sub.1(FS.sub.1+FS.sub.2)
[0061] Where on the left side of the mapping (.fwdarw.): S.sub.src
is the source server; NI.sub.1 is the source server's first network
interface that is configured with VLAN A (V.sub.A), network A
(N.sub.A), and address A (A.sub.A); NI.sub.2 is the source server's
second network interface that is configured with VLAN B (V.sub.B),
network B (N.sub.B), and address B (A.sub.B); FS.sub.1 is the
source server's first file system, which is laid out on disks
D.sub.1 and D.sub.2; FS.sub.2 is the source server's second file
system, which is laid out on disk D.sub.3.
[0062] On the right side of the mapping (.fwdarw.): S.sub.tgt is
the target server; NI.sub.1 is the target server's first and only
network interface that is configured with two separate
configurations 1) VLAN A (V.sub.A), network A (N.sub.A), and
address A (A.sub.A), and 2) VLAN B (V.sub.B), network B (N.sub.B),
and address B (A.sub.B); D.sub.1 is the source server's first and
only disk which contains two file systems FS.sub.1 and
FS.sub.2.
[0063] In one exemplary scenario, if instead of replacing the
original server we are replicating it for testing within a quality
assurance (QA) lab, it will be necessary to change the VLAN
assignments on the network configurations so the test copy of the
server does not interfere with the still running production copy,
e.g., on the target server V.sub.a.fwdarw.V.sub.x and
V.sub.b.fwdarw.V.sub.y.
[0064] Many public clouds provide the user with cloud servers that
have two network interfaces, one with a fixed configuration that is
used by the provider to communicate with the server, and a second
flexible interface that can be configured as necessary to support
the workload on the cloud server. Thus when moving the source
server from the mapping equation above to a public cloud, the
target server configuration may look more like:
S.sub.tgt=NI.sub.1(V.sub.p+N.sub.p+A.sub.p)+NI.sub.2((V.sub.x+N.sub.a+A.-
sub.a),(V.sub.y+N.sub.b+A.sub.b))+D.sub.1(FS.sub.1+FS.sub.2)
[0065] Where the "P" configuration on the first network interface
is the fixed configuration required by the cloud provider.
[0066] In order to handle a wide variety of use cases in a manner
that is easy for the end user, the mapping function 163 generally
provides the following features 1) its supports templates of
migration mappings such as moving an image from a physical server
to a virtual server; 2) it provides rule-based mappings to permit
full automation; 3) it accepts user input that guides or overrides
some or all of the automated mapping process. The combination of
these features allows the migration manager to select an
appropriate template based upon the context of the operation or
simple cueing by the end user, and to then complete the mapping
operation based upon the selected template and the automated rules
engine.
[0067] In the example embodiment of FIG. 1, a deployment profile
164 is used to provide the end user's guidance or requirements for
the mapping process. The deployment profile consists of a data
structure or set of commands that define the mapping requirements.
The specific format of the deployment profile does not matter and
can be any form of data structure or commands known in the art such
as an XML document, a database table, or a shell script. The
migration manager's UI 162 allows the user to create, store, and
edit deployment profiles, and to apply them to a migration or
deploy operation. The deployment profile may provide any of the
following: guidelines for the mapping rules; actual specifications
for the configuration of network interfaces, gateways, routes, name
servers, storage devices, logical volumes, file systems; a set of
additional software modules to install; a set of device drivers to
install; any other configuration settings or functions necessary to
the mapping process. Profiles that have been previously saved can
be reused as templates for later operations.
[0068] FIG. 4b shows the image mapping process in more detail. The
mapping process consists of but is not limited to: mapping the
hardware configuration 450, mapping the infrastructure
configuration 451, mapping the operating system configuration 452,
and mapping the application configuration 453. These steps can be
performed in any order or can be performed together. The need for
coordination between the mapping steps can be seen in the example
of FIG. 4a. As the target server has fewer network interfaces than
the source, the full configurations from the two hardware devices
of the source are mapped to the one device on the target as part of
the hardware mapping. One of the original VLAN configurations can
be handled by the switching infrastructure surrounding the target
server using untagged VLANs (infrastructure mapping), but as there
can only be one untagged VLAN configured on a single switch port,
the second VLAN configuration is handled using a tagged VLAN
configured within the operating system.
[0069] Application configuration mapping 453 involves changing any
configuration settings for an application that depend on specific
hardware, infrastructure, or operating system configuration items
that have been changed as a result of the mapping process. For
example, if an application is configured to connect to a peer on a
specific network address and that address has been changed as part
of the mapping process, the application's configuration will need
to be updated with the new network address. As the location,
format, and interpretation of application configuration data is
application specific, application mapping is generally limited to
the primary applications of interest.
[0070] Once the mapping process is complete, the migration manager
sends a deployment command 313 to the deploy agent 1A11. This
command includes all of the information necessary to deploy the
image to the target server. It includes but is not limited to: BIOS
settings, hardware device settings such as a MAC address for a
network interface device, RAID configuration, disk partitioning,
volume configuration, volume group configuration, file system
configuration, file system mount points, network address
configuration, routes, gateways, name servers, operating system
configuration, and application configuration. The format of the
command does not matter and can be any format commonly known to the
art such as remote procedure call (RPC), eXtensible Markup Language
(XML), etc. As the deploy command conveys data for many subsequent
steps, it can also be broken into multiple parts which are sent
separately to the deploy agent.
[0071] After receiving the deploy command, the deploy agent begins
the deployment process 1A12 by configuring (at step 314) the target
server's storage devices. This involves but is not limited to:
configuring adapter addresses such as the WWN of a fibre channel
adapter or the iSCSI initiator name of an iSCSI adapter,
configuring RAID groups and settings, partitioning disks, and
creating volume groups and logical volumes.
[0072] After the target storage devices have been configured, the
deploy agent builds (at step 315) out any file systems specified by
the deploy command. It then mounts the file systems so that they
can be populated with the archived file system data stored in the
source image.
[0073] The deploy agent then opens the source image by connecting
either to the capture agent, when performing a direct migration, or
image library, when performing a separate deploy operation, and
populates the file systems from the image stream 316. This process
is the reverse of the image capture streaming process 210. Data is
received from the source and buffered. If the data is encrypted, it
is then decrypted. If the data is compressed it is then
decompressed. Each file in the archived file system data is then
written to the corresponding newly created target file system and
any metadata is applied to the recovered file.
[0074] Some of the important advantages provided by a system
constructed according to described herein compared to block-based
approaches to server imaging are the ability to resize the image
file systems, deploy image file systems to storage devices quite
different from those on the source server, and to even change file
system types. These advantages are a result of the process
described above wherein the deploy agent configures the target
storage devices and builds out new file systems using configuration
parameters that might be different from the original source system
due to the mapping process and optional user specifications.
Because the blocks captured by a block-based imaging system include
the file system layout from the source server, they only produce a
useful image when written back to a storage volume of the same
block size and overall size.
[0075] After all file systems have been recovered, the original
source image has been transferred to the target storage, but is not
yet configured to run in the target environment. The deploy agent
then runs the image configuration process 317, 1A13, which is shown
in more detail in FIG. 5. In the first step of the image
configuration process, which is specific to cloud targets, the
deploy agent copies at step 530 device drivers saved from the
original target image built by the cloud infrastructure into the
deployed image. This ensures that if the cloud infrastructure
forces the use of a specific OS kernel, the matching drivers are
available for configuration.
[0076] The image configuration then continues with the deploy agent
optionally injecting at step 532 any added software to the image.
This allows the deploy process to add things that might be
necessary for a server to function in the target environment. Some
examples would include but are not limited to: 1) adding a
management agent that is needed for the server to function within a
cloud infrastructure; 2) adding drivers and other software needed
for the server to function properly on a virtualization host such
as a VMware ESX server; 3) adding patches, security fixes, and
other upgrades to the image that might have become available since
the image was captured; 4) adding drivers that are necessary for
the image to work with the target server's hardware; 5) adding
custom configuration scripts to automate the migration of
application software.
[0077] The image configuration process then continues with the
insertion and configuration (at step 533) of any new drivers that
are required for the image to function properly when run on the
hardware of the target server. The deploy agent first looks for the
required drivers within the target image where they might have been
supplied by the operating system itself, by any injected software,
or any saved cloud drivers. If the required drivers are not found
within the image itself the deploy agent pulls them directly from
the migration manager's driver library 165. The method by which the
drivers are pulled from the driver library does not matter and can
be any method of file retrieval known in the art such as HTTP or
NFS. The deploy agent determines which drivers to pull based upon
the hardware survey 310 that it previously conducted during the
target survey process. On industry standard server hardware using
the Peripheral Component Interconnect (PCI) bus, the PCI bus
identifiers are unique to a given hardware device and can be used
to identify the device and its associated driver. The method used
to map hardware devices (or PCI IDs) on the target server to
drivers in the library does not matter and can be any method of
mapping known in the art such as a database or an XML file.
[0078] The details on how the driver library is built and
maintained do not generally depend on the working of a system
constructed according to aspects described herein but includes (at
a minimum) the ability to add drivers by pulling them directly from
a running server and adding them directly from media devices such
as floppy disks and CD-ROMs.
[0079] After the drivers have been installed and configured, the
deploy agent continues the image configuration process by
configuring the operating system within the image at step 534 to
account for any changes made by the mapping process, the software
injection, and the driver changes. This typically includes the
configuration of the network interfaces, gateways, routes, name
servers, authentication servers, etc.
[0080] Next, at step 535, the deploy agent then makes any
application-specific configuration changes that are necessary to
account for changes that have been to the hardware, drivers, and
operating system. This would include the running of any scripts
injected for this purpose during the software injection phase
(e.g., at step 532).
[0081] The deploy agent then configures the target image to boot on
the target server at step 536. The procedure for this is specific
to the type of server platform and the operating system within the
image, but typically involves configuring the boot loader and
writing changes to the master boot record (MBR).
[0082] The image migration process is now complete. The migration
manager removes any controls that it might have used previously to
boot the server with a deploy agent, such as a CD ISO image
attached to the server, and reboots the target server (e.g., at
step 318 in FIG. 3). When it boots, it will load and run the newly
deployed target image.
[0083] III. A Mailbox-Based Communications System for Management
Communications Spanning Multiple Data Centers and Firewalls.
[0084] A significant issue facing any application that must
communicate with servers across data center boundaries is how to
communicate securely and reliably through corporate firewalls. This
is particularly the case when migrating a server between data
centers or from a private data center into a public cloud. FIG. 6
shows a server migration in which the capture agent 105, deploy
agent 125, and migration manager 160 all reside in separate data
center environments, 760, 740, and 720 respectively. The data
centers are connected via an insecure public network, such as the
Internet. Each data center is isolated from the public network
using a firewall 775, 755, and 735 respectively. It is a common
security policy for a corporate firewall to block all network
connections that originate external to the data center and target a
server within the data center. Thus any attempt by the migration
manager to initiate communication with the capture agent will be
blocked by the firewall 775. Likewise, any attempt by the capture
agent to initiate communication with the migration manager will be
blocked by firewall 735.
[0085] Aspects of the present disclosure describe a method to
address this issue by using file-based management mailboxes, as
shown exemplarily in FIG. 6. A mailbox server 701 provides a
separate, protected mailbox for each managed server (i.e., source
or target server). The mailbox server can reside in any data
center, provided that it is supplied with adequate security, and
provided that the firewall protecting the data center will allow
incoming network connections to the mailbox server. In one
embodiment, the mailbox server can be co-resident with the
migration manager. In another embodiment, the mailbox server can
reside in the same data center as the source or target servers. In
yet another embodiment the mailbox server can be implemented using
a public storage service such as Amazon's S3 storage.
[0086] The file-based management mailboxes provide several
advantages over direct communications between the management system
and the managed servers. All network connections originate with the
servers within the protected data centers and pass out through the
firewalls. This enables the management communications to pass
through corporate firewalls without making changes to their
existing security policies. Because the managed servers are not
directly connected to any management server and instead communicate
only with the mailbox server, the management system can be run in a
stateless manner. This makes it very easy to implement fault
tolerance and scalability within the management system. If a
management server fails, it can be replaced without losing any data
from or communications with the managed servers. Additionally, it
will also be appreciated that as the management load grows, the
management system can easily scale by adding additional management
servers. At any time, any management server can handle interactions
with any managed server.
[0087] FIG. 6 shows the contents of a single mailbox 705 that is
owned by the capture agent 105. The access permissions to the
mailbox directory are as follows: a trusted management system (such
as the migration manager 160 in this example) can list the
available mailboxes and can create and delete any mailbox; all
other entities are not allowed to list the available mailboxes, but
they are allowed to create a mailbox for themselves. In one aspect,
the access permissions to an individual mailbox are set up as
follows: 1) the owner of the mailbox has full read/write access to
all contents of its mailbox; 2) trusted management systems have
full read/write access to all contents of the mailbox; 3) all other
entities cannot see the existence of the mailbox or the existence
of any of its contents, but if given a universal resource
identifier (URI) to a file within the mailbox, they have read-only
access to that file.
[0088] In one exemplary embodiment, a system constructed according
to aspects of the present disclosure (as described herein) supports
two mailbox server implementations. The first mailbox server
implementation uses Amazon's S3 storage service, which is accessed
using the S3 protocol protected by the secure socket layer (SSL)
protocol. The second mailbox server implementation uses the Web
Distributed Authoring and Versioning (WebDAV) protocol protected by
SSL. Those of ordinary skill in the art will appreciate that that
any network service and protocols that provide secure access to
files on a server can be used to construct alternate embodiments of
the disclosed system.
[0089] When a management agent (such as the capture agent 105 in
this example) starts for the first time, it creates a universally
unique identifier (UUID) for itself and saves this UUID for future
use, in case it has to restart in the future. Then, the management
agent contacts the mailbox server 701, creating a mailbox 705 for
itself using the UUID. The agent is able to contact the mailbox
server because the connection goes out through its firewall.
Outgoing connections are typically permitted by most corporate
security policies. The connection reaches the mailbox server
because the firewall in the data center hosting the mailbox server
has been specifically configured to allow incoming connections to
the mailbox server.
[0090] To ensure security of the mailbox mechanism, the managed
server creates its UUID in a manner so as to ensure that the UUID
cannot be guessed by anyone trying to gain access to its mailbox.
In one example, the managed server uses a wide variety of
information known only to itself, such as installation date to the
millisecond, processor UUID, MAC address of network interfaces,
serial number or UUID of disk drives, etc., so as to achieve 128
bits (or more) of randomness. Further, this information is then
hashed using a cryptographic hashing algorithm such as MD5 or SHA-2
to create a UUID of at least sixteen hex digits.
[0091] After creating its mailbox, the agent gathers status
information about itself, writing this information to a status file
706 in its mailbox. If the agent is a capture agent in an exemplary
embodiment, the status information would include the source survey
data 202, 203, and 204. However, if the agent is a deploy agent in
another exemplary embodiment, the status information would include
the target survey data 310 and 311.
[0092] After updating its status information, the agent writes a
heartbeat file 707 to its mailbox. The heartbeat file contains a
current timestamp and a value specifying the time interval between
heartbeat updates.
[0093] After writing the heartbeat file, the agent updates the file
within the interval that it specified in the file. In one aspect,
failure to update the file within this interval will be considered
a system failure by the management system and the agent will be
considered offline. While updating the heartbeat file, the agent
also checks for the existence of a command file 708, which if
found, will contain one or more commands from a trusted management
system. If the command file is present, it is read and then
deleted. The contents of the file will contain one or more commands
that are to be performed by the agent. Any response by the agent to
the management system is written to a request/response file
709.
[0094] Any time the status of an agent changes, the agent updates
its status file within its mailbox. For example, if the agent has
to request a service from the management system or asynchronously
send it some information such as an asynchronous alert, this is
written to a request/response file 709. More than one request or
response can be included in a single file, however, the agent does
not modify the request/response file in any way once it has been
written. The management system will typically delete the file after
it has been processed as acknowledgement. As file locking on some
network file systems can be very unreliable, if the agent needs to
send additional requests or responses to the management system, the
agent adds an additional request/response file using a sequence
number (or some other method, as will occur to one of ordinary
skill in the art) for indicating the sequence of the command
files.
[0095] The management system (migration manager 160 in this
example) detects new servers to manage by reading the list of
mailboxes from the mailbox server and identifying any new
mailboxes. The management system reads the status of a server by
reading the status file 706 from the server's mailbox. The
management system also detects the health of a server by reading
the heartbeat file 707 from the server's mailbox and comparing the
time stamp and interval to the current time. In one exemplary
aspect, the health of a server is detected in the following manner.
If the (current time-time stamp)>N.times.interval, where N is
typically 2<=N<=5, the server can be considered offline. The
factor N is used to prevent false failures due to short-term
loading on the managed server or short-term network issues.
[0096] If the management system needs to send a command to the
managed server, such as a capture command in this example, it
writes the command to a command file 708 within the server's
mailbox. According to aspects of the present disclosure, one or
more commands can be written to a single file. Generally speaking,
once a file has been written, it is not modified. If the management
system needs to add additional commands, additional command files
are added using a sequence number (or some other method, as will
occur to one of ordinary skill in the art) for indicating the
sequence of the command files.
[0097] If the management system issues a command to a managed
server for which a response is expected, the management system
periodically checks the server's mailbox for a request/response 709
file. If the agent running on the managed server is performing an
operation that can generate asynchronous service requests or
information, then the management system periodically checks the
server's mailbox for a request/response file.
[0098] Accordingly, it will be understood that various embodiments
of the present system described herein are generally implemented as
a special purpose or general-purpose computer including various
computer hardware as discussed in greater detail below. Embodiments
within the scope of the present disclosure also include
computer-readable media for carrying or having computer-executable
instructions or data structures stored thereon. Such
computer-readable media can be any available media which can be
accessed by a general purpose or special purpose computer, or
downloadable through communication networks. By way of example, and
not limitation, such computer-readable media can comprise physical
storage media such as RAM, ROM, flash memory, EEPROM, CD-ROM, DVD,
or other optical disk storage, magnetic disk storage or other
magnetic storage devices, any type of removable non-volatile
memories such as secure digital (SD), flash memory, memory stick
etc., or any other medium which can be used to carry or store
computer program code in the form of computer-executable
instructions or data structures and which can be accessed by a
general purpose or special purpose computer, or a mobile
device.
[0099] When information is transferred or provided over a network
or another communications connection (either hardwired, wireless,
or a combination of hardwired or wireless) to a computer, the
computer properly views the connection as a computer-readable
medium. Thus, any such a connection is properly termed and
considered a computer-readable medium. Combinations of the above
should also be included within the scope of computer-readable
media. Computer-executable instructions comprise, for example,
instructions and data which cause a general purpose computer,
special purpose computer, or special purpose processing device such
as a mobile device processor to perform one specific function or a
group of functions.
[0100] Those skilled in the art will understand the features and
aspects of a suitable computing environment in which aspects of the
present disclosure may be implemented. Although not required,
aspects of the present system are described in the general context
of computer-executable instructions, such as program modules or
engines, as described earlier, being executed by computers in
networked environments. Such program modules are often reflected
and illustrated by flow charts, sequence diagrams, exemplary screen
displays, and other techniques used by those skilled in the art to
communicate how to make and use such computer program modules.
Generally, program modules include routines, programs, objects,
components, data structures, etc. that perform particular tasks or
implement particular abstract data types, within the computer.
Computer-executable instructions, associated data structures, and
program modules represent examples of the program code for
executing steps of the methods disclosed herein. The particular
sequence of such executable instructions or associated data
structures represent examples of corresponding acts for
implementing the functions described in such steps.
[0101] Those skilled in the art will also appreciate that the
present system may be practiced in network computing environments
with many types of computer system configurations, including
personal computers, hand-held devices, multi-processor systems,
microprocessor-based or programmable consumer electronics,
networked PCs, minicomputers, mainframe computers, and the like.
Also, the present system is practiced in distributed computing
environments where tasks are performed by local and remote
processing devices that are linked (either by hardwired links,
wireless links, or by a combination of hardwired or wireless links)
through a communications network. In a distributed computing
environment, program modules may be located in both local and
remote memory storage devices.
[0102] An exemplary system for implementing the invention(s), which
is not illustrated, includes a general purpose computing device in
the form of a conventional computer, including a processing unit, a
system memory, and a system bus that couples various system
components including the system memory to the processing unit. The
computer will typically include one or more magnetic hard disk
drives (also called "data stores" or "data storage" or other names)
for reading from and writing to. The drives and their associated
computer-readable media provide nonvolatile storage of
computer-executable instructions, data structures, program modules,
and other data for the computer. Although the exemplary environment
described herein employs a magnetic hard disk, a removable magnetic
disk, removable optical disks, other types of computer readable
media for storing data can be used, including magnetic cassettes,
flash memory cards, digital video disks (DVDs), Bernoulli
cartridges, RAMs, ROMs, and the like.
[0103] Computer program code that implements most of the
functionality described herein typically comprises one or more
program modules may be stored on the hard disk or other storage
medium. This program code, as is known to those skilled in the art,
usually includes an operating system, one or more application
programs, other program modules, and program data. A user may enter
commands and information into the computer through keyboard,
pointing device, a script containing computer program code written
in a scripting language or other input devices (not shown), such as
a microphone, etc. These and other input devices are often
connected to the processing unit through known electrical, optical,
or wireless connections.
[0104] Remote computers may be another personal computer, a server,
a router, a network PC, a peer device or other common network node,
and typically include many or all of the elements described above
relative to the main computer system in which aspects of the
present system are embodied. The logical connections between
computers include a local area network (LAN), a wide area network
(WAN), and wireless LANs (WLAN) that are presented here by way of
example and not limitation. Such networking environments are
commonplace in office-wide or enterprise-wide computer networks,
intranets and the Internet.
[0105] When used in a LAN or WLAN networking environment, the main
computer system implementing aspects of the disclosed system is
connected to the local network through a network interface or
adapter. When used in a WAN or WLAN networking environment, the
computer may include a modem, a wireless link, or other means for
establishing communications over the wide area network, such as the
Internet. In a networked environment, program modules depicted
relative to the computer, or portions thereof, may be stored in a
remote memory storage device. It will be appreciated that the
network connections described or shown are exemplary and other
means of establishing communications over wide area networks or the
Internet may be used.
[0106] In view of the foregoing detailed description of preferred
embodiments of the present invention(s), it readily will be
understood by those persons skilled in the art that the present
invention(s) is/are susceptible to broad utility and application.
While various aspects have been described in the context of a
preferred embodiment, additional aspects, features, and
methodologies of the present invention(s) will be readily
discernable from the description herein, by those of ordinary skill
in the art. Many embodiments and adaptations of the present
invention(s) other than those herein described, as well as many
variations, modifications, and equivalent arrangements and
methodologies, will be apparent from or reasonably suggested by the
present invention(s) and the foregoing description thereof, without
departing from the substance or scope of the present invention(s).
Furthermore, any sequence(s) and/or temporal order of steps of
various processes described and claimed herein are those considered
to be the best mode contemplated for carrying out the present
invention(s). It should also be understood that, although steps of
various processes may be shown and described as being in a
preferred sequence or temporal order, the steps of any such
processes are not limited to being carried out in any particular
sequence or order, absent a specific indication of such to achieve
a particular intended result. In most cases, the steps of such
processes may be carried out in a variety of different sequences
and orders, while still falling within the scope of the present
invention(s). In addition, some steps may be carried out
simultaneously.
* * * * *