MIG: Self-Migration Enabler

	At a Glance
	Catalog	Dynamic
	Category	Dynamic
	User volumes	yes
	Min. memory	192M
	OS	Linux
	Constraints	no
	Questions/Comments	Ask Forum

Functional Overview

MIG enables the containing application to migrate or snapshot itself to another grid. These operations are initiated through a simple web interface (GUI) exposed by MIG and work in conjunction with the helper application MigHelper. The GUI is accessible through the application IP and the configured MIG port.

Using the GUI, a user can request either of the following operations over the containing application:

• Migrate: the application migrates itself to a target grid selected from the GUI. The original source application is stopped and destroyed.

• Snapshot: the application makes a copy of itself in a stopped state on a target grid selected from the GUI. The original source application is re-started.

Grids involved in these operations must first be configured. See preparing the grids.

Boundary

Resources

Terminals

User Volumes

The volume is used to store the private_key and grid_info files required for application migration or snapshot.

Properties

Performance

Additional resources do not affect performance.

Web Interface (GUI)

MIG exposes a web interface which is used to migrate or snapshot the containing application. This GUI is accessed using the application IP on the configured port.

Above is an example of the GUI page used for initiating application migration or snapshot. A user selects an operation (migrate or snapshot), a target application name, and a target grid. On Submit, the browser displays the progress monitor.

Above is an example of the GUI progress monitor during migration. This page contains three monitors:

• The Source Application Monitors tracks:
  • provisioning MigHelper on the target grid
• The MigHelper Application Monitor tracks:
  • stopping the source application
  • migrating the source application to the target grid as the target application
  • starting the target application
• The Target Application Monitor tracks:
  • destroying the source application
  • stopping MigHelper
  • destroying MigHelper

Above is an example of the GUI progress monitor during snapshot. This page contains three monitors:

• The Source Application Monitors tracks:
  • provisioning MigHelper on the target grid
• The MigHelper Application Monitor tracks:
  • stopping the source application
  • migrating the source application to the target grid as the target application
  • re-starting the source application
• The Re-Start Source Application Monitor tracks:
  • stopping MigHelper
  • destroying MigHelper

Preparing For Migration & Snapshot

These steps must be taken before MIG can be used to migrate or snapshot an application. A step-by-step example is provided here.

Preparing The Grids

The MIG appliance must be able to authenticate on any grid to which it will migrate or snapshot. To ensure this, create a public/private key pair in openssh format without a passphrase. Create a user on each grid whose public key corresponds to the generated public key.

Each grid must be able to authenticate on every other grid involved. To ensure this, create users on each grid whose public keys correspond to the public keys of the other grids.

Each grid must have installed:

• The MigHelper reference application template.
• The MIG catalog appliance.
• The MIGCTL catalog appliance (this appliance is necessary for MIG).

Preparing The Application

Connect the MIG appliance to an existing application - see Typical Usage below.

Put the generated private key file, named according to the private_key_file property, on the root of the config volume of the appliance with owner and group nobody and mode 600 .

Create a grid info file which records the information necessary for the application to migrate or snapshot amongst a collection of grids. Put the grid info file, named according to the grid_info_file property, on the root of the config volume with owner and group root and mode 644. This file contains application information for each grid according to the example below:

Note: The file sample.grid.info located in /var/www/html of the MIG appliance can be used as a template.

Error Messages

The following messages may appear in either the appliance log file or the system log of the grid controller when the appliance fails to start:

• httpd did not start
• /var/www/html/.rc.local script is not executable.
• /var/www/html/.rc.local script failed, ret = ret

Typical Usage

LampX4

The diagram below shows how MIG can be connected to the LampX4 reference application. The INSSL gateway properties are set to forward tcp traffic on port 8080 to the aux terminal. Pointing a browser at port 8080 of the application IP or resolvable domain name brings up the web interface for MIG.

Note: the MIG applicance should not be connected directly between an IN gateway and the rest of the application, but rather to the aux terminal of an INSSL gateway.

A step-by-step example for setting up the LampX4 use case on two grids is provided here.

Notes and Links

Notes

• It is good practice to set the username and password properties of MIG to prevent unauthorized users from migrating the application.
• It is necessary to properly set the start order of MIG. MIG must start after the appliance connected to MIG's net terminal in order for MIG to identify the grid on which it is running.

Related Documents

• Implementation Design
• Test Plan
• Release Notes

• Step-by-step Example

• MigHelper

Questions and Comments

To post a question about this appliance, visit our forum.

-- StephenQ - 12 Sep 2007