Migration overview

This section is a simplified, start to finish glimpse of the migration user experience.

The Db2® Mirror GUI is the primary user interface for IBM® i Migrate While Active. The Db2 Mirror GUI can run on the source node or on a third node.

To access the Db2 Mirror GUI interface, use the following URL:

http://hostname:2001/Db2Mirror

After authenticating, the Add Pair dialog will appear, as depicted in Figure 2. Here you have the option to either add a Db2 Mirror pair or add an IBM i Migrate While Active pair. Pairs can be added at any time by selecting the Add New Pair from the Add menu in the left navigation bar.

To begin a migration, select IBM i Migrate While Active from the Add New Pair dialog.

To begin a new migration, select Configure a new pair as shown in Figure 3.

Figure 3. Add Pair options for IBM i Migrate While Active

After clicking Next, the migration wizard starts.

You begin the migration wizard by providing details about the two IBM i nodes that are part of the migration process. These nodes are referred to as the source and copy nodes. After all details about the nodes are gathered, the migration process starts. You are guided through this process in a step-by-step manner. Some steps cannot be performed in the GUI because they must be performed from the console while in restricted state.

The entire step-by-step flow is detailed on the System migration stage, Data synchronization stage, and Cutover stage pages.

System migration stage

The migration wizard requires that you input many details about the source and copy nodes. These details include network configuration, cluster configuration, and time server settings. The wizard also provides you with choices in how to achieve the migration. These choices include options for the type of devices or the level of compression that you want to use.

Installing the IBM i operating system onto the copy node is one of the steps in the migration process. This important step can be accomplished in different ways. Figure 4 shows how the wizard begins the migration journey by asking you to specify a system install device choice.

Figure 4. Migration wizard - System install device options

The next choice presented to you in the wizard is to specify the Network File System (NFS) server approach to be used during the migration. Figure 5 shows the NFS server options that Migrate While Active supports.

Figure 5. Migration wizard - NFS server options

Within the System Install Options tab, a critical piece of insight about the source node is shown: the amount of storage available. Migrations that use automatically created virtual optical devices rely upon available disk storage on the source node to create install media. To avoid encountering a critical storage shortage on the source node, the GUI helps the migration user understand the storage impact the migration will have on the source node.

The second element of the System Install Options tab involves a decision about which compression type to use when creating install media.

Figure 6. Migration wizard - System install options

Tip: The *MEDIUM option is the recommended compression type because it typically provides adequate compression and reasonable performance. For systems on Power10 or later, the *ZLIB option can provide compression using hardware acceleration. Because the system save occurs while the source node is in restricted state, consider your source node outage goals in addition to the storage requirement.

Next, the migration wizard asks you to specify details about the devices to use for saving user data during the system migration. Figure 7 shows the device options supported by Migrate While Active.

Figure 7. Migration wizard - System migration user data

Figure 8 shows another important migration decision: the amount of user data to save.

Figure 8. Migration wizard - User data save options

The simplest choice is to select an entire system save. Choosing this option means that during the system save, all integrated file system directories and objects within directories in SYSBAS are saved. Also, all libraries and objects within libraries in SYSBAS are saved during the system save.

The alternative is to choose a partial system save. When this option is selected, Migrate While Active avoids saving most Db2 Mirror replication-eligible objects during the system save. Instead, these objects are automatically migrated later during the data synchronization stage.

When determining how much data to save, consider the following:

Migrations that use automatically created virtual tape devices require sufficient disk storage on the source node.
An entire system save requires more disk storage than a partial system save.
Because the system save occurs while the source node is in restricted state, consider your source node outage goals. Saving the entire system takes longer than a partial system save.

Note: To use the partial system save option requires coordination with IBM. Send an email to iessspt@us.ibm.com, requesting the use of this option. The email will be answered by a member of IBM's Technology Expert Labs (formerly Lab Services).

After you enter your node details and choices into the migration wizard, a validation step is performed to help ensure that all requirements are met before the migration process can begin. If the validation fails, correct any problems and rerun the validation until it is successful.

After the validation step completes successfully, the system migration process starts. You will be guided though each step.

The source node must be in restricted state during the system save. After the save of the source node is complete, active production work can run on the source node while the save data is transferred and used to install and restore the copy node. Migrate While Active will be tracking any changes to objects on the source node.

After all system migration steps are completed, Migrate While Active begins continuous data synchronization.

Data synchronization stage

While the copy node is being installed and restored during the system migration stage, any changes to objects on the source node are tracked by Migrate While Active. This includes objects within libraries and within the integrated file system. All tracking is limited to objects within SYSBAS.

After the copy node is restored and communicating with the source node, the process of data synchronization begins. Data synchronization is an asynchronous, interval-based process where changed objects on the source node are synchronized to the copy node.

The migration home page, as shown in Figure 10, provides many ways to see the progress and access more details about the overall migration process. Hovering over either node icon provides extra details about the node. Either right clicking the node icon or accessing the left side navigation area (not pictured) provides actions for learning more about the configuration, security, and progress of the migration process.

To help you understand the ongoing data synchronization process, an interactive Migration Guide is provided within the GUI. Click the center circle icon shown in Figure 10 to view the migration progress details in the Migration Guide.

As shown in Figure 11, the GUI shows that data synchronization is ongoing and orchestrated by the Migration Manager. At any point in time, synchronization of changed objects may or may not be active.

Figure 11 shows that synchronization of mirrored objects and integrated file system objects is active. Changed objects are being saved and restored from the source node to the copy node.

Figure 11. Data synchronization progress in the Migration Guide

The View Data link displays a high-level overview of data synchronization. From this view, you can filter and drill down into the details showing each object that is tracked and waiting to be synchronized.

Figure 12 shows an example of object tracking and data synchronization over the past six hours. The blue bars reflect observation of tracking of changes to objects on the source node. The green bars reflect completed migration of changed objects to the copy node.

Cutover stage

At some point, the Migrate While Active user will decide to shift from the data synchronization stage to the cutover stage. The cutover stage encompasses a final synchronization of any remaining objects that need data synchronization, a review of any objects that were ineligible or failed to migrate to the copy node, and finally a role swap from the source node to the copy node. After the cutover stage has completed, the Migrate While Active environment will no longer exist, and the source and copy nodes will be independent IBM i instances.

Choosing the right time to begin the final data synchronization is essential to minimize the outage on the source node. Closely review the unprocessed and failed entries returned by the LIBRARY_MIGRATION_LIST view and IFS_MIGRATION_LIST view. These entries can be accessed from the View Data link found in the Migration Guide.

Another best practice before entering the cutover stage is to use the estimation tool that shows the user the estimated time required for the final synchronization. The time estimator reviews the number and sizes of the remaining entries on the tracking lists, conducts a trial performance evaluation of communication speed, and produces a time estimate to help identify an ideal cutover time.

The cutover estimate is accessed from the View Data link found in the Migration Guide. The estimation tool can be executed multiples times as long as the MIRROR_DATABASE network redundancy group (NRG) is active. Click the Rebuild button shown in Figure 13 to refresh the estimate.

Figure 13. Data synchronization cutover estimate

The estimation tool measures the speed of communication between the source and copy nodes by calling the MIGRATION_NETWORK_BANDWIDTH table function. This table function will package, send, and measure multiple groups of transmissions to calculate the network bandwidth speed. The result is displayed as the Current Calculated Transfer Speed shown in the Figure 13.

The cutover estimate within the Db2 Mirror GUI displays the estimation details including the number of synchronization operations, the total size of the objects, and the estimated total transfer time required to perform the synchronization. See ESTIMATE_FINAL_SYNCHRONIZATION_TIME table function for a full description of the values that are returned.

To enter the cutover stage, press the Finalize button on the continuous data synchronization status screen in the Migration Guide, as shown in Figure 14.

Figure 15 shows the final data synchronization step at the point where the Migrate While Active user needs to enter restricted state on the source node. The final data synchronization step requires this outage on the source node to allow it to:

Complete the data synchronization of objects without the possibility of conflicting locks from user activity on the source node.
Complete the data synchronization of objects without the addition of new changes to objects on the source node.

To start final synchronization, the source node must be taken into restricted state. This means the GUI cannot be used because all subsystems need to be ended. Therefore, the WRKMIGSTS command needs to be used from the source node.

Figure 16 shows the WRKMIGSTS command with option 20 selected to start final synchronization.

Figure 16. Start final data synchronization

Once the final data synchronization has completed, reconnect to the GUI on the source node. Use the View Data link shown in Figure 17 to review the data synchronization details.

To complete the migration, press Launch, as shown in Figure 17.

At any point before the role swap, the user can cancel out of the cutover stage and return to the data synchronization stage.

After the migration has completed, the Migrate While Active user has one last decision to make: whether to direct Migrate While Active to remove all configuration and tracking detail. If you want to be able to refer to the Migrate While Active configuration, tracking, and migration details at a future time, do not select Exit Migration on step 6.