MIG - Self-Migration Enabler - Implementation

Base Class

MIG is an assembly containing two appliances.

• Development.PS8 from the proto catalog is used unmodified.
• MIGCTL is branched from the WEB5 base class.

Class Volumes

The volume configuration for MIG is determined by the base class images from which it is created.

See Development.PS8 - Scalable Port Switch? for relevant data on the port switch.

Volumes for release 1.0 of MIGCTL include:

• boot volume, 100MB size, mounted as "/", writeable, instantiable.
• usr volume, 200MB size, mounted as "/usr", read-only, common.
• content volume 1 MB size, mounted as "/mnt/content", read-only, common
• config volume, mounted as "/mnt/config", writeable, placeholder

The boot and usr volumes are unmodified from the WEB5 appliance except for /etc/fstab which additionally mounts the config volume. All software specific to MIGCTL is installed on the content volume and requires apache, PHP, ssh and bash in order to function.

Packages

• Main: 3tapp-mig-1.0.0-1.noarch.rpm. This contains the scripts and web interface which perform the basic operations of MIG.

Contents of the release directory:

Exported appliance images:

• MIG-1.0.0exp.tar.bz2
• MIGCTL-1.0.0exp.tar.bz2

Exported MigHelper? application:

• MigHelper-1.0.0exp.tar.bz2

"Generator" RPMs: install these in the order listed on the content volume of MIGCTL to re-create the appliance:

• 3tapp-mig-1.0.0-1.noarch.rpm

Source RPMs:

• None. All sources are PHP or Javascript and are available in the "Generator" RPM.

Tests (see the test plan CatDynMigTp and the release notes CatDynMigRelNotes):

• mig-tst-app.tar.bz2 - test application

Re-creating the Appliance

To recreate the MIG and MIGCTL appliances:

• Drag a blank class definition assembly onto the canvas. Set its interfaces, volumes and properties according to the MIG Data Sheet
• Edit the interior of the assembly and connect a Development.PS8 and WEB5 appliance according to diagram at the top of this page.
• Set the Development.PS8 properties as follows:
  • out1_protocol = tcp
  • out1_in_port = port_no (redirected to assembly)
  • out1_out_port = 80
• Branch the WEB5 appliance and name the new class MIGCTL. Name the instance in the assembly ctl
• Edit the MIGCTL class:
  • Delete the content volume. Add a new content volume on /dev/hda3 Common, read-only, shared with a size of 1M and filesystem ext2.
  • Add a new volume config on /dev/hda4 Placeholder, mandatory
  • Add properties: username, password, mode, private_key_file, grid_info_file.
  • Constrain the mode property to allowed values migrate|snapshot|both
  • Set max resources equal to min resources.
• Edit the MIGCTL instance settings:
  • Re-direct the volume config to the assembly volume config.
  • Re-direct the new properties to the assembly properties.
• Edit /etc/fstab on MIGCTL to mount the config volume with defaults.
• Install the rpm 3tapp-mig-1.0.0-1.noarch.rpm on MIGCTL (temporarily change the content volume to writeable).

Theory of Operation

MIG enables the containing application to migrate or snapshot itself to another grid. This operation is initiated through a web interface and works in conjunction with the reference application MigHelper.

In brief:

• MIG on the source app provisions an instance of MigHelper on the target grid.
• MigHelper stops the source app and migrates it to target app on the target grid.
• MigHelper either starts the target app on the target grid (migrate) or starts the source app on the source grid (snapshot).
• MIG, on start, destroys MigHelper on the target grid and, during migration, destroys the source app on the source grid.

In detail, MIG performs three basic operations:

• A start-up script on MIGCTL:
  • Determines current_grid - the grid MIG is running on from among those in the grid.info file
  • Checks for a lock file which indicates the MIG is starting up after a migration or snapshot. The lock file indicates: source_grid, source_app_name, target_grid, target_app_name and action (snap or migrate)
  • If source_grid == current_grid and action == snap, then destroy MigHelper_target_app_name on target_grid.
  • If source_grid == current_grid and action == migrate, then this app is the re-started source_app from a failed migration, in which case destroy MigHelper_target_app_name on target_grid.
  • If target_grid == current_grid and action == migrate, then destroy MigHelper_target_app_name on target_grid, and destroy source_app_name on source_grid.
  • If target_grid == current_grid and action == snap, then this is a manually started snapshot, in which case do nothing.

• A migration script on MIGCTL:
  • Validates username and password from the web interface against property values
  • Creates the lock file
  • Generates the _env property value string for the MigHelper
  • If necessary destroys MigHelper_target_app_name on target_grid (from an aborted migration)
  • Provisions MigHelper_target_app_name on target_grid

• A web interface on MIGCTL:
  • Validates username and password against property values
  • If lock file exists, offers the choice of viewing the monitor or over-riding the lock file
  • Lists possible target grids from grid.info.
  • Allows user selection of target_grid, target_app_name and action.
  • Checks for existence of target_app_name on target_grid.
  • Execs the migration script
  • Meters progress on the source_app, MigHelper, and target_app

Configuration

Configuration is performed by the start-up script which uses properties in /etc/applogic.sh and determines the current_grid.

Log Files

Logs specific to a given migration are created in the /3tera directory of the config volume and are viewed by the web monitor during migration. These files are overwritten for each migration.

-- StephenQ - 11 Sep 2007