Effective migration and upgrade of virtual machines in cloud environments

A mechanism is provided in a data processing system for performing a system upgrade. Responsive to receiving selection of one or more virtual machines to upgrade with an upgrade package, the mechanism identifies a plurality of upgrade phases. The mechanism configures the plurality of upgrade phases and generates a pre-upgrade snapshot of each of the one or more virtual machines. The mechanism performs each upgrade phase in the plurality of upgrade phases to form an upgraded virtual machine and performs one or more upgrade validation tests on the upgraded virtual machine. Responsive to the one or more upgrade validation tests succeeding, the mechanism reverts back to the pre-upgrade snapshot.

BACKGROUND

The present application relates generally to an improved data processing apparatus and method and more specifically to mechanisms for effective migration and upgrade of virtual machines in cloud environments.

Cloud computing is the use of computing resources (hardware and software) that are delivered as a service over a network (typically the Internet). Cloud computing entrusts remote services with a user's data, software and computation. Using software as a service, users also rent application software and databases. The cloud providers manage the infrastructure and platforms on which the applications run. End users may access cloud-based applications through a web browser or a light-weight desktop or mobile app while the business software and user data are stored on servers at a remote location.

In the software-as-a-service (SaaS) model, cloud providers install and operate application software in the cloud, and cloud users access the software from cloud clients. The cloud users do not manage the cloud infrastructure and platform on which the application is running. This eliminates the need to install and run the application on the cloud user's own computers, simplifying maintenance and support. What makes a cloud application different from other applications is its elasticity. This can be achieved by cloning tasks onto multiple virtual machines at run-time to meet the changing work demand. Load balancers distribute the work over a set of virtual machines. This process is inconspicuous to the cloud user who sees only a single access point.

SUMMARY

In one illustrative embodiment, a method, in a data processing system, is provided for performing a system upgrade. The method comprises responsive to receiving selection of one or more virtual machines to upgrade with an upgrade package, identifying a plurality of upgrade phases. The method further comprises configuring the plurality of upgrade phases and generating a pre-upgrade snapshot of each of the one or more virtual machines. The method comprises performing each upgrade phase in the plurality of upgrade phases to form an upgraded virtual machine and performing one or more upgrade validation tests on the upgraded virtual machine. The method further comprises responsive to the one or more upgrade validation tests succeeding, reverting back to the pre-upgrade snapshot.

DETAILED DESCRIPTION

The illustrative embodiments provide a mechanism for upgrading virtual machines in cloud environments. The mechanism identifies software prerequisites for upgrade and runtime dependencies. The mechanism supports customers in adding validation tests for their business logic to the base test suite. The mechanism runs the upgrade unattended and alerts a user when an error occurs. The mechanism also validates the migration or upgrade. The mechanism supports complex phased upgrades by validating a current phase before proceeding to the next phase. The mechanism recovers from failures by restoring virtual machine snapshots and confirming the recovered virtual machine is working. The mechanism does this without having to wait for manual administrator intervention, hence minimizing downtime and cost of any failed upgrade. The mechanism may also take a snapshot of the failed upgrade for offline analysis.

Characteristics are as follows:

Service Models are as follows:

Deployment Models are as follows:

Program/utility40, having a set (at least one) of program modules42, may be stored in memory28by way of example, and not limitation, as well as an operating system, one or more application programs, other program modules, and program data. Each of the operating system, one or more application programs, other program modules, and program data or some combination thereof, may include an implementation of a networking environment. Program modules42generally carry out the functions and/or methodologies of embodiments of the invention as described herein. Computer system/server12may also communicate with one or more external devices14such as a keyboard, a pointing device, a display24, etc.; one or more devices that enable a user to interact with computer system/server12; and/or any devices (e.g., network card, modem, etc.) that enable computer system/server12to communicate with one or more other computing devices. Such communication can occur via Input/Output (I/O) interfaces22. Still yet, computer system/server12can communicate with one or more networks such as a local area network (LAN), a general wide area network (WAN), and/or a public network (e.g., the Internet) via network adapter20. As depicted, network adapter20communicates with the other components of computer system/server12via bus18. It should be understood that although not shown, other hardware and/or software components could be used in conjunction with computer system/server12. Examples, include, but are not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archival storage systems, etc.

Product migration/upgrade process is a very crucial aspect for a software system. In the prior art, no specific tool is provided to the customers to support them during the upgrade/migration process and to validate that the upgrade process did not corrupt their data or impact integrated applications. Customers need to access multiple panels in their user interface and start using the system and perform customized sanity checks. This cost of validating an upgrade without tools can discourage users from doing regular upgrades and can lead to longer periods between upgrades and poorer end user satisfaction, as they live with annoying usability problems that are not critical enough to trigger an upgrade.

With the adoption of virtual appliance (pre-built software solutions, comprised of one or more virtual machines that are packaged, updated, maintained, and managed as a unit) and cloud solutions, the upgrade/migration process becomes more complex, because the customer must manage multiple integrated systems.

In accordance with an illustrative embodiment, a system based on an interactive tool and mechanisms to support customers in the upgrade/migration of a solution are provided. The system reduces the cost and risk of upgrades and migrations of virtual appliances and cloud solutions.

Existing upgrade and migration solutions only detect fatal errors and do not validate business logic, and this implies additional work to be manually done after an upgrade. An upgrade or migration can break business logic or integrations as a side effect, and only enterprise/customer specific tests can validate the process was a success. These mechanisms provide a framework for validating the upgrade or migration, reducing time delays scheduling and running manual acceptance testing. As these tests are repeated on all machines, it is far easier to identify specific machines that failed to upgrade, due to a unique problem on that machine, for example.

Existing upgrade and migration solutions may try to rollback failed upgrades, and the mechanisms of the illustrative embodiments make use of virtual machine snapshots to reduce the risk and recover from failed upgrades. In accordance with the illustrative embodiments, the machine can be restored to a working state without human intervention once a validation test fails. The mechanisms of the illustrative embodiments provide components to effectively manage the migration and upgrade process. The mechanisms will work at an enterprise solution level and not only at a stand-alone application or host machine level. In the description of the illustrative embodiments and figures, for simplicity the word “upgrade” may refer to “migration and upgrade.”

FIG. 4is a block diagram illustrating components of a migration and upgrade system in accordance with an illustrative embodiment. Migration/upgrade system400includes user interface401, which may include a graphical and command line interface401. Validation manager410includes upgrade specific test suite411, default sanity test suite412, and rules based alerts413. Default sanity test suite412manages the automated test suite to perform the sanity test before an upgrade takes place. A sanity test determines whether the upgraded application works the same way it did before the upgrade. Default sanity test suite412focuses on runtime dependency changes to verify that a selected component to be upgraded does not affect something else running in the system, prerequisites or software upgrade checks (i.e., Java™ programming language, WebSphere® application server (WAS), DB2® database system, operating system (OS)), and identifying integrated product relationship.

Upgrade specific test suite411manages the automated test suite developed by a customer or software provider to sanity test key features and integrations on initial application install or upgrade. Application programming interface (API)461allows the customer or software provider to import and customize upgrade specific tests.

Rules based alerts413provides notification to a customer or administrator regarding success/failure of an upgrade. Rules based alerts413may communicate through email/simple network management protocol (SNMP) API462to provide notifications, for example. Rules based alerts413may use other techniques for notification, such as short message service (SMS) messaging, for example. Rules based alerts413allows one to configure specific rule based alerts related to upgrade failures to support unattended upgrade. This functionality can be very useful because upgrades and migrations are normally scheduled for periods of off-peak system usage. The administrator may prefer to have the upgrade run unattended and only be alerted if something goes wrong. Rules based alerts413provides alerts if certain upgrades fail and allows the administrator to elect to continue if non-key system components fail to upgrade and must be un-installed manually.

Configuration component420includes preferences421, system upgrade settings422, and upgrade database423. Preferences421allow the customer or administrator to define preferred settings, such as whether the administrator is notified for particular upgrade failures, whether particular upgrades can be rolled back and uninstalled, etc. System upgrade settings422allow the administrator to define the upgrade settings, such as the machines to be upgraded and the phases of the upgrade, for example. Upgrade database (DB)423stores software components for the upgrade.

Snapshot manager430includes pre-upgrade component431and rollback component432. Snapshot manager430communicates with hypervisor neutral API463and handles the virtual machine (VM) snapshots related to system backup. When an upgrade fails, snapshot manager430takes a snapshot of the VM with the failed upgrade for offline analysis. Snapshot manager430may roll back to the pre-upgrade snapshot. Snapshot manager430supports the manager in removing the failed upgrade snapshot if the administrator is satisfied to prevent memory waste.

Manager component440includes pre-upgrade component441, phases component442, and hosts component443. Manager component440manages the specific upgrade/migration process to be started, identifying which components are to be upgraded. Pre-upgrade component441manages the pre-upgrade process to initialize the upgrade. Phases component442manages the phases of the upgrade process. Hosts component443communicates with hosts470to upgrade software components on hosts470.

Upgrade monitor450includes monitor451, monitor multiple phases452, and monitor multiple hosts453. Upgrade monitor450supports the administrator in the upgrade process. Upgrade monitor450monitors the upgrade on multiple hosts based on the configured setting. With an application distributed across multiple host machines470or runtime dependencies existing between applications on separate host machines. In this case, the framework coordinates the upgrade and/or migration based on associations it has discovered or was configured with.

Pre-upgrade component441discovers application dependencies. Pre-upgrade component441discovers runtime dependencies via hosts component443. Based on the application dependencies and runtime dependencies, pre-upgrade component441recommends phases to phases component442.

FIGS. 5A and 5Bpresent a flowchart illustrating operation of mechanism for migration and upgrade in accordance with an illustrative embodiment. The migration and upgrade process provides significant advantages over existing systems, in particular when upgrading cloud virtual machines. The process identifies runtime dependencies and software prerequisites for upgrade, validates the migration and upgrade, sends status alerts to support unattended upgrade, and recovers from failures by restoring virtual machine snapshots and snapshot the failed upgrade virtual machine for offline analysis.

With reference toFIG. 5A, operation begins as the mechanism starts the upgrade (block500). The mechanism selects an upgrade required (block501). The user may select the type of upgrade to perform via a graphical user interface (GUI) or command line interface. The mechanism may read the upgrade/migration packages from a file directory and present the list of upgrade/migration options to the user. The mechanism may provide the user the option to upgrade a single machine, multiple machines, or enterprise wide upgrade.

The mechanism then identifies the machines to upgrade (block502). If the machines to upgrade comprise a single machine, the mechanism connects to the single machine (block503). If the machines to upgrade comprise multiple machines in block502, the mechanism connects to selected machines to be upgraded (block504). If the machines to be upgraded comprise an enterprise wide system in block502, the mechanism connects to all machines or a master image of all machines (block505).

After connecting to the machine(s) in block503, block504, or block505, the mechanism discovers and gathers pre-requisites for the upgrade (block506). The mechanism may discover and gather pre-requisites in the background and save a significant amount of time for the administrators, because the administrators do not need to stop/start the install or manually fetch packages. As an example, the upgrade of the application may also require new versions of Java™ runtime and DB2® database system.

Then, the mechanism discovers products impacted (block507) and discovers upgrade tests (block508). The products may comprise integrated products. The mechanism may present the products to the user to be tested post upgrade. Administrators often want the upgrade to run unattended, report when an error occurs, and revert to the original version. An upgrade validation test may confirm the upgrade was successful and support complex phased upgrades by validating a current phase before proceeding to the next phase. The system can include out-of-the-box upgrade validation automated test suite to test standard components, such as a DB2® database system, Appservers, Web browsers for work following the upgrade. Each upgrade package can optionally provide validation tests, and the administrator can have his own acceptance tests executed by placing them in the validation tests directory. The validation component discovers the upgrade tests and provides a collection of scripts and executables to be run before the upgrade to collect data in the application database and post upgrade to perform consistency checks.

The mechanism may select upgrade tests in block508based on the applications to be upgraded and possibly the application dependencies (both upstream and downstream). The upgrade tests may be specific to the customer environment, that is, the specific operating system or hardware systems. The upgrade tests may be supplied with the application upgrade or developed by the customer or the customer's integrator. Pre-requisites, products impacted, and other dependencies may be machine dependent.

If supported or where multiple applications are to be upgraded, the mechanism identifies and recommends if phased upgrade is needed and displays the recommendation to the user (block509). The mechanism then configures phases, if needed (block510). The mechanism may configure phases on a machine-by-machine basis, on an application-by-application basis, or on a dependency basis. The phases for a given application may include upgrade tests for the application's dependencies, for the application, and for other applications that are dependent upon the given application.

An upgrade may take a number of hours. The administrator may choose to proceed or abort based on risk due to systems impacted or need to gather more validation tests. The mechanism determines whether the user selects to proceed (block511). If the user selects to not proceed, the mechanism cancels the upgrade and operation ends (block512).

Turning toFIG. 5B, if the user selects to proceed in block511, the mechanism creates a restore snapshot for all virtual machines that are to be upgraded (block513). In virtualized cloud environments, the mechanism snapshots the pre-upgrade/pre-migration state so that it can revert to it if needed during the install. The method gathers test data for upgrade verification (block514). If the upgrade fails, the mechanism can revert to the working state and start the application without having to wait for manual administrator intervention. This both supports unattended install and avoids downtime due to the failed upgrade. When upgrading non-virtualized environments, the mechanism can run backup scripts provided by the upgrade package.

The mechanism performs a first phase of the upgrade (block515). The process of performing an upgrade phase is as described below with respect toFIG. 6. The mechanism determines whether the current phase failed upgrade validation (block516). If the phase passes upgrade validation, the mechanism determines whether additional phases are needed (block517). If additional phases are needed, operation returns to block515to perform the next upgrade phase.

If the current phase fails upgrade validation in block516, the mechanism reverts back to the original snapshot (block518). Thereafter, or if no additional phases are needed in block517, the mechanism updates the status of the upgrade on an upgrade monitor or dashboard (block519). The mechanism sends status notification (e.g., SMS, event, email, etc.) to the administrator and interested parties (block520). Where multiple machines are being upgraded, the notification may identify which machines were upgraded successfully and which upgrades are in progress, failed, or queued, for example. Finally, the mechanism completes the upgrade and operation ends (block521).

FIG. 6is a flowchart illustrating an upgrade phase mechanism in accordance with an illustrative embodiment. Operation begins, and the mechanism starts an upgrade phase (block600). The mechanism stops all application processes that must be stopped before the upgrade can be carried out (block601). The mechanism then calls on the upgrade scripts in the upgrade package to perform the upgrade on applications (block602). Following upgrade, the mechanism starts any applications that must be started for validation (block603). The mechanism executes the upgrade validation test suite (block604). The mechanism may display the update status on an upgrade monitor or dashboard (block605). Where multiple machines are being upgraded, the results for each machine may be displayed on the monitor. The automated validation test suite is run on all machines. The upgrade monitor may identify specific machines that failed to upgrade due to problems unique to that machine or configuration.

The mechanism then sends status notification (e.g., SMS, event, email, etc.) to the administrator and interested parties (block606). If configured to, or if failed validation, the mechanism takes a snapshot of the upgraded machine (block607). The mechanism then determines whether the validation tests passed (block608). If the validation tests passed, the mechanism starts the applications on multiple hosts that needed to be stopped while upgrade was in progress (block609). The mechanism manages upgrade data and snapshots created during upgrade to avoid memory exhaustion (block610). For example, the mechanism may schedule upgrade data for deletion and notify the user. Thereafter, the mechanism ends the phase and operation ends (block611).

If the upgrade fails in block608, the mechanism reverts back to the snapshot (block612). The snapshot of the failed upgrade may be diagnosed offline or at off-peak period. The mechanism may also restart applications, returning the machine to a healthy running state. Thereafter, the mechanism ends the phase and operation ends (block611).

Thus, the illustrative embodiments provide mechanisms for effective migration and upgrade of virtual machines in cloud environments. The illustrative embodiments provide enterprise-to-enterprise (E2E) management of the upgrade/migration process in virtual appliances and cloud solutions. The illustrative embodiments provide real time notification of the upgrade/migration process in a phase approach. The illustrative embodiments provide integrated consistency and data validation inside the migration/upgrade process to drive the overall migration/upgrade procedure.