IBM i の新しい移行方法 IBM i Migrate While Active を調べてみました。

## はじめに
2024年10月にIBMよりIBM i Migrate While Activeという新しい機能が発表されました。現行IBM i 環境を稼働させた状態で新しいIBM i 環境にデータをコピー、OS環境の移行に伴うシステム停止時間を最小化できるような機能です。
今後ぜひ試してみたい機能で、検証を前にドキュメント・ベースで少し調べてみました。

## IBM i Migrate While Activeとは
IBM i Migrate While Activeはその名の通り、移行元となるIBM i 環境を動かした状態で新しいIBM i 環境にデータを移行できるようにする機能で、IBMの以下のサイトに情報が掲載されています。

[IBM Support DocNo.7172591: IBM i Migrate While Active](https://www.ibm.com/support/pages/ibm-i-migrate-while-active "IBM Support DocNo.7172591: IBM i Migrate While Active")
[IBM Docs IBM i 7.5: IBM i Migrate While Active](https://www.ibm.com/docs/en/i/7.5?topic=availability-i-migrate-while-active "IBM Docs IBM i 7.5: IBM i Migrate While Active")

Active-ActiveのHAソリューションであるIBM Db2 Mirror for i の機能要素を活用した移行用のソリューションです。ちょうどMIMIXやQuickEDD、Hybrid SYNCなどのHABPソリューションをシステム移行に活用するのと同じようなポジショニングになるのかなと思えました。

IBM Db2 Mirror for i では、ノード (IBM i ) 間をRDMA (Remote Direct Memory Access) 対応のハードウェア・アダプターで接続して、Db2 for i のデータやノード間でのレプリケーションがサポートされているオブジェクト、セキュリティー設定などが同期されます。ただ、各ノードのIBM i 自体は異なるリリース、PTFレベルで構いません。

(IBM Docsに記載の図です)
![migartdb2m.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1305251/86ce7cdc-8daf-206f-ed05-c59760c00662.jpeg "IBM Db2 Mirror for i のイメージ図")

一方IBM Migrate While ActiveではソースとなるIBM i とコピーのIBM i の間はTCP/IPで通信し、また方向は常にソースからコピーへの一方通行です。
ソースとコピーのIBM i はOSリリース、PTFレベルが一致した状態でのレプリケーションになる点がDb2 Mirror for iの同期と異なる点になります。

(こちらもIBM Docsに記載の図です)
![migarttcpip.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1305251/9b8a6dbe-3957-8eac-1edf-120d095f2e53.jpeg "IBM Migrate While Activeのイメージ図")

ソースとコピーがTCP/IPで繋がっていれば良いので、異なるロケーションやオンプレ環境からクラウド環境へのリフト・アップに使えるということですね。

## IBM i Migrate While Activeでの移行ステージ
IBM i Migrate While Activeでのシステム移行は大きく3つのステージからなります。これらの作業を専用のインターフェース (GUI, CLコマンド) を使って進めていけるというものです。
1. システム移行 (System Migration)
1. データ同期 (Data Synchronization)
1. 切り替え (Cutover)

(IBM Docsより)
![migartflow.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1305251/165397bc-d47d-dc4e-1dc7-b36033b104f3.jpeg "移行ステージの概要")


### 1. システム移行ステージ
最初はシステム移行ステージで、同期先となるコピー・ノードの作成を行うステージです。まず、同期元となるソース・ノードのシステム・バックアップを取得します。システム・バックアップは*SYSBAS内の全データを対象としたフル・バックアップでも構いません。バックアップはOSリストアに必要な部分は仮想光ディスク装置のイメージ・カタログに取得されて、その他の部分は仮想テープ装置のイメージ・カタログとして取得する形です。
取得したイメージ・カタログをネットワーク・インストール・サーバー (下図ではCloud Optical RepositoryとしてのIBM i NFS Server) として別に構成したIBM i 環境に配置し、そこからコピー・ノードにOS環境を復元する流れとなります。この形式はBRMSとICCを使ったICOSへのPowerVSでのIBM i のフル・バックアップ取得とフル・リストアと同じですね。

(こちらもIBM Docsより)
![migartmigratelocal.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1305251/4a87f9d6-634f-4e72-aef2-9cf95cee65f9.jpeg "システム移行ステージ")

### 2. データ同期ステージ
システム移行ステージが完了すると、次はデータ同期ステージとしてソース・ノードのIBM i (同期元) からコピー・ノードのIBM i (同期先) へのデータ同期を行います。IBM i Migrate While Activeの名称の通り、システム移行ステージ完了後はソース・ノードは業務アプリケーションを稼働させて本番利用できる状態になり、その状態下でのデータ同期となります。このデータ同期は「非同期」の通信で行われます。

なお、データ同期は一時停止/再開ができるようです。
一時停止中にコピー・ノード側でアプリの稼働確認とかできるのか、検証できればぜひ試してみたいですね。

:::note info
サポートされるオブジェクトについて
IBM i Migrate While Activeでは基本的に*SYSBASにある保管可能なオブジェクト全てが同期でき、ライブラリー内のオブジェクト、IFS上のオブジェクトいずれも対象になっています。

サポートされるオブジェクト・タイプの詳細や考慮点はこちらにまとまっています。Db2 Mirrorの機能で同期がとれるもの、保管復元で同期をとるものなど種別があるようですが、思い付くようなオブジェクトはほぼほぼカバーされているのかなと思えました。
[IBM Docs IBM i 7.5: Object types and migration](https://www.ibm.com/docs/en/i/7.5?topic=concepts-object-types-migration "Object types and migration")

上記リンク先を読みますと、データベース・ジャーナルと監査ジャーナルのジャーナル・レシーバーはシステム移行ステージでコピー・ノードに持っていけます。ただしデータ同期中のレシーバーへの変更 (エントリーの追加とか) は、トラッキング/同期はされないようで、レシーバーについては最終移行時に必要であれば個別にコピー・ノードに持っていく必要があるようです。なるほど。。。
:::

### 3. 切り替えステージ
最後のステージが切り替えステージです。最終移行できる状態になったことを確認して、データ同期ステージを終了し、ソース・ノードからコピー・ノードへの最終同期を行います。この最終同期ではソース・ノードは制限状態になります。最終同期が完了した段階で、切り替えできるとなったら最終切り替え処理を実行して一連が完了となります。

## 終わりに
IBM i Migrate While Activeについて調べてみて、まずは一連の動きのイメージを掴むことができました。
2024年12月時点では、**ソース・ノードとコピー・ノードのOSリリースおよびPTFレベルは一致する必要がある** ということで、現新マシンの移行時のOSリリース・アップなどには未対応のようです。実際のシステム移行ではマシンの入れ替えとともにOSのリリースも更新するのが良く行われているかなと思いますので、そのようなケースにも使えるようになるといいなと思います。

まだ実機で触れられていないので情報のみとなりましたが、今後使える機会があればぜひ検証して、その結果もまとめていきたいと思います。