Migrate While Activeの謎のベールがはがされる
先月、IBMは、Migrate While Activeのサブスクリプションの販売を開始しました。これは、顧客のオンプレミス インストレーションから、IBM Cloudで稼働するPower Virtual ServerへのIBM i ワークロードのマイグレーションを迅速化および簡略化するように設計された新たなオファリングです。また、IBMは、先月、オンラインのGuided Tourウェビナーも開催し、この新オファリングに関する質問に対する、待ち望まれていた回答をいくつか提供しています。
IBMは、 10月下旬、IBM i 7.4および7.5向けの最新のテクノロジー リフレッシュを公開した2週間後に、Migrate While Activeを発表しました。顧客がデータをPowerVSへ移行しながら、IBM i ワークロードを稼働し続けられるように設計されたこの新たなオファリングに関して、IBMはあまり初期情報を提供していませんでした。
Migrate While Active（12月13日より一般利用可能）に関しては、IBMがIBM i 7.4で発表した継続的可用性製品、Db2 Mirrorをベースとしているなど、いくつか知らされていた情報もありました。また、Migrate While Activeは、Db2 Mirrorのレプリケーション メカニズムを利用するものの、Db2 MirrorクラスターでのIBM i システム間の超高速接続を提供する高価なRoCEアダプターを必要としないこと、および、Db2 Mirrorの10キロメートル制限とは対照的に、距離制限なく標準的なTCP/IP接続を使用できることなどについてもすでに知らされていました。
しかし、IBMがこの製品を開発した理由や、Db2 Mirrorのフル ライセンスが必要かどうか、どのようなIBM i オブジェクトをサポートしないのか、ユーザーはPowerVS顧客である必要があるのかなど、多くの質問が回答されずに残されていました。IBMは、先月、Migrate While Activeに関するGuided Tourで、これらを初めとする多くの質問に回答しています。このGuided Tour（ こちらでアクセスできます）は、Db2 Mirror開発チームを率いるロチェスターのソフトウェア エンジニア、Kris Whitney氏がホスト役を務めています。
IBMがMigrate While Activeを開発したのは、IBM i 顧客が本番IBM i システムをIBM CloudおよびPowerVSに移行する際に直面する課題に対処するためだとWhitney氏はGuided Tourで述べています。IBM顧客およびクラウドの見込み客を悩ましてきた1つの問題は、データをどのようにしてクラウドに移動するのかということでした。
「群を抜いて1番尋ねられる質問は、「テープをIBMに送ることはできますか」という質問です」とWhitney氏はGuided Tourで述べています。「現時点で、配送業者を介してテープを送るサービスは提供していません。また、テープを介してIBM Cloudへシステムをリストアする方法もありません。」
2番目に多い質問は、1つ目の質問の変化形です。すなわち、IBM FlashSystemをIBM Cloudに接続して、グローバル コピー（Global Copy）またはグローバル ミラー（Global Mirror）を使用してPowerVSにデータを移動することができるかというものです。この質問に対する答えも「ノー」だとWhitney氏は述べています。
「現在のところ、そうすることはできません」と彼は述べます。「確かに、IBM CloudにFlashSystemはあります。しかし、問題は、それらがマルチテナントのFlashSystemであることです。2つのFlash System間でのレプリケーションはマルチテナントではありません。それらを接続してストレージを複製することはできないため、セーブ-リストア タイプの方式を使用することになります。」
クラウドへ移行するほとんどのIBM i 顧客は、オンプレミス環境を複製するのではなく、新たなIBM i 環境をゼロから作成（またはスクラッチ インストールを実行）したいと考えていることはIBMも承知しているとWhitney氏は述べています。一般的なスクラッチ インストールでは、IBM i 顧客は、新たな環境へ切り替える前に、かなりの時間を掛けて、データをセーブおよびリストア（およびそれをテスト）することになります。
このタイプのスクラッチ インストールの課題は、長い時間が掛かる場合があり、それに伴う多くのダウンタイムが生じることがあることです。データのリストアおよびテストに掛かる数日間あるいは数週間の間にも、本番IBM i システムは稼働し続け、最終的には新たなクラウド環境にセーブされ、リストアされる必要がある、多くの変更が生み出されます。
「そうしたセーブ-リストアのプロセスを繰り返し行うこともできますが、プロセスに要する時間を短くすることにはなりません」とWhitney氏は述べています。「そのため、そのことが1つの課題でした。もうひとつの課題はメディアでした。スクラッチ インストールを行うDモードの方法はありません。ネットワーク インストール タイプの方式を使用する必要があります。」
IBM Cloudの顧客は、通常、2種類の仮想メディアを使用して、PowerVSへデータを移行し、ネットワーク インストールを実行（IBM Cloudで稼働するNFSサーバーを介して）してきたとWhitney氏は述べています。仮想光ディスクは、スクラッチ インストールをブートし、実行するのに便利だと彼は述べています。一方、仮想テープは、IBMの Aspera 、または FalconStor 社や DSI社のVTLアプライアンスの圧縮および重複排除機能のおかげで、より拡張性が高く、より効率的に帯域幅を使用します。
そこが問題なのです。クラウドへデータを移動する方法には、実に様々な方法があります。それぞれにメリットとデメリットがありますが、それらすべてを組み合わせるとなると、混沌と化してしまいます。
「クラウドへデータを移動する方法には、おそらく、20～50種類の様々なやり方があります」とWhitney氏は述べています。「私たちが抱えている問題は、選択肢が多過ぎるために、それに従えばよく、繰り返し行うことができる、ただ1つのやり方というものがないことです。」
したがって、それこそがMigrate While Activeの第1の目標ということになります。すなわち、可能な限り、効率的で、高性能で、簡単なやり方で、可能な限り、少ないダウンタイムでPowerVSへ移行する、ただ1つの方法を提供することです。
Migrate While Activeは、PowerVSマイグレーションに伴うダウンタイムを、数日間または数週間から、わずか数分間または数時間に短縮することができるとIBMは述べます。これにより、IBM i 顧客は、IBMのクラウドへ移行しながら本番システムを稼働し続けることが可能となるということです。
とは言うものの、Migrate While Activeでもダウンタイムは発生します。実際のところ、ダウンタイムが発生する場面は2回あります。すなわち、1回目はマイグレーションの初期でのダウンタイムで、これはチェックポイントを作成するためです。2回目はマイグレーションの最後でのダウンタイムで、ソースおよびターゲット ノードの同期のためです。
そして、Migrate While Activeは、マイグレーションのためのただ1つのツールおよび方法を提供するために開発されたものですが、IBMは、顧客がそのプロセスで他の方法やツールも使用できるように柔軟性を持たせています。たとえば、ユーザーは、VTLを頼りに初期のデータ レプリケーションを実行し、アップデートにDb2 Mirrorを頼りにすることもできます。また、リモートでマウントされた光ディスク サーバーを使用して、ネットワーク インストールを実行することもできます。
「私たちは本番ダウンタイムを短縮することを目指しています。また、このプロセスをガイドに従って自動的に進められるようにすることも目指しています」とWhitney氏は述べています。「ただし、100%自動化されたプロセスにはなりません。自動化が非常に難しいこともあるからです。そのため、自動化できる部分は自動化を進めますが、自動化できない部分については、ガイドに従って操作を行うことになります。」
2 TB～3 TB以下のIBM i データ資産は、利用可能なネットワーク帯域幅によっては、Migrate While Activeのネイティブのレプリケーション方式を使用すれば問題ないかもしれません。しかし、10 TBを超える場合は、VTLが圧縮および重複排除でもたらす効率性は本当に助けになるとWhitney氏は述べています。
Migrate While Activeで、初期セーブに既存の月次バックアップ（フル システム セーブ）を使用できないのかと思う顧客もいるかもしれません。「答えは「ノー」です。なぜなら、システム セーブの取得時点のチェックポイントが必要だからであり、それが、クラウドに同期することになる変更のトラッキングの開始時点になるからです」とWhitney氏は述べています。
Migrate While Activeは、データを複製するのにIBMジャーナリングを使用しないとWhitney氏は指摘しています。代わりに、「トラッキング リスト」をベースにしているDb2 Mirrorの非同期データ レプリケーション方式を利用します。これにより、必要なストレージの量は最少になります。
「これらのトラッキング リストは、ジャーナリングを使用する場合と比較してあまり多くのストレージを使用しません」とWhitney氏は述べています。「すべての変更を順番にトラッキングする必要があるジャーナルベースのシステムと比較して言えば、非常に効率的です。」
このアプローチについて注意が必要な1つの点は、レプリケーション セッションが終了するまでは、データは不完全だということです。そのため、Migrate While Activeは、ディザスター リカバリー（DR）という点では役に立ちません。「これは、DRソリューションでありません。マイグレーション ソリューションです」と彼は述べます。「移行中に、すべてを同調させようとしてはいないのです。」
IBMは、Migrate While Activeの顧客がマイグレーション プロセスを管理するのを支援するためのGUIを開発しています。このGUI（ソースまたはターゲット ノードのどちらでも稼働可能）は、ユーザーが、マイグレーション プロセスを開始し、プロセスの監視を行えるようにします。このGUIは重要です。なぜなら、Migrate While Activeはほとんど自動化されていますが、特にシステムが制限状態にあるときには、手動で行う必要がある一定の手順があるからです。
また、IBMは、Migrate While Active用のグリーンスクリーン インターフェースも提供しています。さらに、Migrate While Activeの一部としてDb2 for iデータベースで作成された新たなSQLサービスがいくつかあるため、顧客はいつでもそれらのサービスを直接呼び出すことができ、さらには、プログラミングによって、またはAnsibleのようなフレームワークを通じてそれらを自動化することもできます。
Migrate While ActiveはDb2 Mirror製品ですが、Db2 Mirror製品のフル ライセンスは必要ありません。IBMは、この新たなDb2 Mirror製品（すなわちMigrate While Active）のために、Db2 Mirrorライセンスの構成を修正しています。顧客は、Db2 Mirrorベース製品（5770-DBM 5050）を無償でライセンスし、「オプション1 - Continuous Availability（継続的可用性）（5101）」または「オプション2 - Migrate While Active（5102）」のいずれかを選択できるようになっています。
IBMは、コア当たりベースでライセンスする、Migrate While Activeのサブスクリプション オファリングを何種類か提供しています。たとえば、顧客は、90日間のサブスクリプションをコア当たり700ドルで購入したり、1年間のサブスクリプションをコア当たり2,000ドルで購入したりすることができます。また、28日間の試用期間も提供されています。さらに、IBM i 顧客は、2,000ドル分の取得済みクラウド クレジットを利用して、Migrate While Activeを使用してみることもできます。
Migrate While Activeは、IBMが、既存製品（Db2 Mirror）に対して、他のことを行えるように変更を加えることで製品化したものです。IBMのプロダクト マネージャーのWhitney氏が明らかにしたように、IBMが顧客の利用状況を把握し、それに応じて調整が施されると、Migrate While Activeに対しても変更が加えられることになるでしょう。
Migrate While Activeに関するGuided Tourの動画には、 こちらのリンクでアクセスすることができます。また、この製品に関する詳細情報については、 IBM Supportサイトで参照することもできます。
