ラリー・ヤングレン著

i5/OSの奥深くに存在するテクノロジーに皆さん気づき始めたようです。実際、このテクノロジーに関してIBMのロチェスター研究所に寄せられている問い合わせの数から判断すると、ここ数年このテクノロジーに爆発的な関心が寄せられていたことになります。そのテクノロジーとは、ほとんど知られてはいませんが、リモート・ジャーナルという機能です。

リモート・ジャーナルは数年前に初めて導入されましたが、広く知られることなくしばらくはあまり日の目を見ませんでした。しかし最近になって注目を集めるようになり、今や1台のiSeriesマシンから別のiSeriesマシンへ、最新のデータを効率よく転送するための最良の手段として採用されるようになってきています。

私自身がリモート・ジャーナルと関わるようになったのは、OS/400のV4R2がまだ設計段階だった数年前でした。IBMのジャーナル開発チームに加わって、リモート・ジャーナルの設計を完成させ、市場に投入する陣頭指揮をとるように言われたのです。その時の先任者たちは、リモート・ジャーナルのサポートを単なる機能強化された効率的な転送メカニズムで、その上に高可用性対応の既存のビジネス・パートナーが改良された自社の製品を構築できるものとしか見ていませんでした。

また彼らは、このテクノロジーは高可用性市場への参入を容易にするものだというのが新規ベンダーの考えであることに気づいておらず、リモートヴォルト環境を確立するための魅力的な手段となり得るという先見の目を持っている人もほとんどいませんでした。しばらくの間は、既存製品の配管改良工事をしているのだ、くらいにしか考えていませんでした。

◆配管改良工事と転送の高速化

このテクノロジーを簡単に説明できたことはありませんでした。

私が今どんな仕事をしているのかと数年前に年配の親族に聞かれたときに、彼女が簡単に理解できるような説明や概念をいろいろ考えました。そこで私は配管工事の話をし、今設計しているのは改良されたパイプ中を通って情報が1台のマシンから別のマシンへ流れるようにするものであると説明しました。

リモート・ジャーナル・サポートは、たしかに配管改良工事ではあるのですが、目的のある配管工事であり、以前にも増してその目的は、データベース・ファイル、バイト・ストリーム・ファイル、データ・キュー、データ・エリアのインスタンスに影響を与えるような最新の変更を、1つのマシンから別のマシンへリアルタイムに転送するサポートをすることとなっています。しかもこれでもまだリモート・ジャーナルについて半分しかご紹介していないのです。

iSeriesのジャーナル開発チームが主に高可用性の転送機能強化を目的としてリモート・ジャーナルを考え出したのは事実です。この機能強化により2つのデータベース・ファイルのインスタンスをほぼ同時に保持したい場合に、常用マシンからバックアップ・マシンへ行レベルのインクリメンタルな変更をすばやく転送することができます。しかし、創造性豊かなユーザーは、この設計の本来の目的を見越していました。このテクノロジーを使用して、主マシンの負荷を低減させてCPUサイクルをできるだけ空けておこうする人が増えています。このテクニックを使ってデータ・ウェアハウスを定期的に効率よくリフレッシュする人もいれば、このサポートをフルに活用してリモートでリアルタイムのデータヴォルトを構築する人もいます。
では、このようなことをすべて可能にするような、基礎となる「配管改良工事」とは何なのしょうか。

機能が強化されたジャーナル機能の動作は、ジャーナル・エントリを常用マシンのローカルのディスク・ドライブに書き込むだけにとどまらず、同じジャーナル・イメージの重複コピーをリアルタイムで通信回線を通してリモート・マシンのメモリにルーティングします。リモート・ジャーナル接続を確立するためには、主に3つの単純な手順を踏みます。
まず、ターゲット・マシンを決めます。

ADDRDBDRE RDB（TGRTMACH）
　 RMTLOCNAME（'9.5.192.1' *IP）

次に、ソース・マシンに対してターゲット・マシンを紹介し、必要とするジャーナルを識別します。

ADDRMTJRN RDB（TGRTMACH）
　 SRCJRN（TESTRJ/J1）

最後に、2台のマシンに「握手」をさせるとデータが流れ始めます。

CHGRMTJRN RDB（TGRTMACH）
　 SRCJRN（TESTRJ/J1）
　 JRNSTE（*ACTIVE）

上記のコマンドとリモート・ジャーナルの全体的なアプローチの詳細については、www.redbooks.ibm.comにある、IBMレッドブック、AS/400 Remote Journal Function for High Availability and Data Replication （SG24-5189）に記載されています。

◆任意の他の名前でのログ記録

現代のデータベース製品はそのほとんどが基礎となるロギング・メカニズムを組み込んでいて、新しい行のデータベース･イメージができるたびにログに記録して監査証跡を残すようになっています。i5/OS以外のデータベースではこの機能をログ記録サポートと呼んでいます。i5/OSではこの機能をジャーナリングと呼び、この機能を離れたところから実行するときにリモート・ジャーナリングと呼びます。

ログ記録がデータベース・テーブルだけを対象としていて、データベース製品にしっかりとパッケージされている他のオペレーティング・システムとは異なり、i5/OSのジャーナリング・サポートはi5/OS自身の主要な部分となっています。つまり、DB2だけに制限されているのではないということです。これによりi5/OSのユーザーは、特にリモート・ジャーナリングについて強みを得ることができると言えます。

i5/OS環境では、重要なデータが複製の対象とするためにデータベース内に単独で存在している必要はありません。データベース・テーブル（またはバイト・ストリーム・ファイル、データ・エリア、データ・キュー）の集合はこれらのオブジェクトに対する変更を（その変更がどこから来たかに関係なく）ローカルのジャーナル・レシーバに記録することができるのです。ジャーナル・レシーバは通信回線を経由してそのコンテンツをリモートのロケーションにリアルタイムで流し、そこではジャーナル・イメージが複製（リモート）ジャーナルとして再び組み立てられ、ジャーナル・レシーバとマッチングします。

たとえば、預金口座から30ドルを引き出したとしましょう。ローカル・ジャーナルがそのトランザクションを検知して、離れたところにいる双子 （リモート・ジャーナル・レシーバ）とその情報を共有します。リモート・レシーバのコンテンツを監視している誰もが30ドルの引出しに気づき、ターゲット・マシン上の預金口座テーブルの複製に対して、同じ照合トランザクションを実行するように選択することができます。

◆どれくらい離れていても良いか

ターゲット・システムはソース・システムからどれくらい離れていても良いのでしょうか。この問いに対する答えがまさにこのアプローチの長所です。この機能のベースとなっているリモート・ジャーナル・テクノロジーは距離を問題としません。リモートのトラフィックのピーク量を処理するのに十分な高速通信パイプがあれば、距離は障害となりません。したがって、ターゲット・システムが隣の部屋にあるという場合ばかりではなく、遠く離れた都市にあるというリモート・ジャーナルのユーザーにめぐり合うのは珍しいことではありません。高可用性を求めているすべてのアプローチでこうしたことが可能である訳ではないようです。

◆マイクロコードの奥深くで

i5/OSでのこうした一連の機能のサポートは、マシンの奥深くにマイクロコード（SLIC）レベルで実装されていて、メモリからメモリへのマシン間の転送は既存の通信サポートを使用して行われます。ジャーナル・エントリの主メモリ・レジデント・バッファがそれぞれ完了して、常用マシンのローカル・ディスク上に書き出される準備が整うと、ベースとなっている非同期リモート・ジャーナル・サポートによりターゲット・マシンの主メモリへの並行転送がスケジュールされます。

このジャーナル・エントリ・イメージの複製をマシンの奥深くで統合することで、i5/OSは高い効率を達成することができるのです。リモート・ジャーナル・サポートをご利用になったお客様からよく寄せられる声がまさにこの点なのです。リモート・ジャーナルのユーザーの多くは、イメージがターゲット・マシンに到達するのが今までのテクノロジーに比べてずっとタイムリーであると述べています。

しかも、この効率的な配管工事の恩恵を受けるのはデータベース・ファイルやSQLテーブルだけではありません。最新の変更を常用マシン上のローカル・ジャーナルに委ねているあらゆるオブジェクトは、そのベースとなっているリモート・ジャーナル・サポートを活用して、その変更がターゲット側に転送されるのを確認することができます。ジャーナル・イメージがターゲット側に到達し、リモート・ジャーナル・レシーバ内に格納されたら、選択したソフトウェアをうまく活用し、差分を取り込んで再生するだけです。

高可用性のビジネス・パートナーのパッケージを利用してこの再生ステップを行っている店舗もあり、独自の取り込み・再生サポートを作成したり、定期的にApply Journal Change （APYJRNCHG）コマンドや、APYJRNCHGxコマンドを発行したりする店舗もあります。実際、複製対象のデータベースでのオペレーションが非常に複雑な場合に、再生オペレーションをできるだけ煩わしくないものにするための、QDBRPLAY APIがi5/OSに最近導入されました。QDBRPLAYでは、i5/OS独自の取り込み・再生サポートと商用の高可用性パッケージの両方をAPYJRNCHGx 用に構築された同じサポートへ結び付けることができます。

このような変更を2台のマシン間で同期モード（常用マシン上のアプリケーション・ジョブがターゲット・マシンの主メモリに到達したという確認を待つモード）でも非同期モード（ジャーナル・イメージの転送を常用マシン上で実行されているスレーブSLICタスクに任せるモード）でも送信することができます。しかし、ほとんどのお客様は非同期モードの方を選び、そのほとんどの方がジャーナル・イメージは通常ターゲット側に一瞬で到達すると報告しています。

◆トラフィックが自由に流れるように保つ

リモート・ジャーナルのトラフィックが、一定のペースで到着するということはあまりありません。バッチ・ジョブが大量に発生するといった要因により、ジャーナル・アクティビティが急激に増え、そのベースとなっているテクノロジーに負荷を与えることもありえます。一日の運用の中でも負荷の山と谷があるのが普通です。

こうした理由によりV5R3で導入されたリモート・ジャーナルの機能強化の1つとして、自動オーバードライブ・モード（非同期スーパー・バンドリングとも呼ばれる）があります。この機能は、ジャーナル・エントリ・イメージがソース側に溜まり始めた場合の繁忙時 （数秒間転送されないまま残っている状態）に作動します。この機能は、溜まったままにしておいた場合に生じる個々のジャーナル・エントリの塊を、1つの「スーパーバンドル」にまとめます。その結果、通常は適度のオーバーヘッドでタイミングの良い転送を実行できます。

◆統制のとれたタスク・チーム

イメージをLAN上に送り出すソース側のSLICスレーブ･タスクに加えて、ターゲット側にも2つの同様のSLICタスクがあります。その1つは、イメージを引き出して主メモリ上に少しの間保存します。もう1つは、主メモリ上にある最近到着したイメージを発見し、ディスクに急いで格納します。これら2つのタスクを組み合わせると、良く訓練されたフットボール・チームのように、ジャーナルの塊がプレーヤーから別のプレーヤーに渡されていき、ターゲット・マシン上のディスクに確実に格納されます。

適切な性能分析パッケージがインストールされていれば、Work with System Activity （WRKSYSACT）コマンドを発行して、このようなSLICタスクが生成するアクティビティのピークを測ることで、SLICタスクがマシンに課するオーバーヘッド量を推測することができます。一般的には、あまり大量のCPUを消費しないはずです。

リモート・ジャーナル転送サポートは、最新のデータベースの行イメージを、ベースとなるハードウェアが許す限りできるだけすばやくソース・マシンからターゲット・マシンへ複製することに焦点を置いており、しかもメモリからメモリへの転送であることもあって、「ディスクへの書き込みはどうなっていますか」という質問を良く受けます。

リモート・ジャーナルのプロセスでは、ターゲット側のリスナー・ジョブ（ビジネス・パートナーの高可用性アプリケーションであることが多い）は、最新のジャーナル・エントリが確実にディスクに書き出されて無事であるとわかるまでは、リモート・ジャーナルに到着したことは知らされません。無事とわかって初めてジャーナル・エントリのリモート・インスタンスが明らかになるのです。だからといって、ソース・マシンもソース・マシン上のアプリケーションも、このステップが完了するのを待っていなければならないわけではありません。

この転送メカニズムが高速なのは、大部分がこうした理由によるものです。リモート側で強制されるタスクがリモートの受信タスクと分離されているのも、高速化に寄与しています。1つのタスクが両方のミッションを背負い込んでいるわけではないので、ターゲット・マシン上のディスク書き込みステップが転送ステップを止めておく必要が無いのです。

◆ターゲット側の状態を保持する

タイムリーな再生と高性能を真剣に考える場合には、他の同様に重要な高可用性ジャーナル・オプションであるスタンバイ・モード（オプション42としてi5/OSの一部として利用可能です）と合わせてリモート・ジャーナル・オプションを採用する店舗が増えています。

ターゲット・マシンのミッションは、ロール・スワップが発生するまでスタンバイし、発生したときにユーザーがアプリケーションをソース側からターゲット側に切り替えて運用を継続させようとするので、ターゲット・マシン側に格納されている対応する複製ファイルは、通知があったら即座に運用ロールを引き継げるように準備が整っていなければなりません。この複製ファイルはその瞬間完全に保護された状態である必要があり、それは、ジャーナルされる必要があるということを意味します。しかしロール・スワップが発生するまで、複製ファイルの完全ジャーナリングのオーバーヘッドは時に過剰となります。

これを解決するには、ターゲット側でスタンバイ・モードを使用します。スタンバイはオプションのジャーナルの状態で、複製されたファイルの下のローカルなジャーナルのためにターゲット・マシン上で使用できる（そして使用すべき）ものです。

こうした配置では、常用マシン上でローカル・ジャーナル・レシーバ（図1のA）を採用するのが一般的でしょう。そしてi5/OSはローカル・イメージをターゲット・マシン上のリモート・ジャーナル・レシーバ（B）に送信します。リモート・ジャーナル・イメージがターゲット側に到達したら、選択されたソフトウェア・パッケージ（C）がそれをデータベース・ファイル（D）の複製に対して再生します。この複製ファイルにはローカル・ジャーナル（E）が付随していて、これを一時的にスタンバイ・モードにします。

ターゲット側のローカル・ジャーナルはスタンバイ・モードで使用するように指定されているので、ターゲット側の速度の低下を招くようなディスク・トラフィックはより少なくなっています。スタンバイ・モード中のジャーナルのディスク・トラフィックが大量になることは稀です。これにより得られる利点は、ターゲット側のジャーナルが完全にアクティブになっているのではなく、単にスタンバイしているだけであれば、高可用性ソフトウェアを使用することでターゲット側の複製されたファイルを今まで以上に早く更新できることです。

ターゲット側の複製データベース・ファイルの下にあるローカル・ジャーナルを構成して、そのローカル・ジャーナルをスタンバイ・モードでアイドルにすることで、両側を最高の状態にすることができます。すなわち、ターゲット側に大きなオーバーヘッドを生じさせること無くソース側からターゲット側へすばやくフェイルオーバーして、ターゲット側が代わりに主ロールを引き継ぐことができます。スタンバイ・モードを有効にするには、CHGJRN JRNSTATE（*STANDBY）というCLコマンドを発行するだけです。スタンバイ・モードのままにしておくのも同様に簡単で、CHGJRN JRNSTATE（*ACTIVE）コマンドを発行します。

◆回線が途切れたら

リモート・ジャーナルの説明をするとまず聞かれるのが「通信線回線がダウンしたら／した時どうなるのか」という質問です。答えは明解で、ローカル・ジャーナルが引き継ぎ、更新された行イメージを蓄積し続け、通信回線が再確立されてリモート・ジャーナル接続が再び有効になった時点で、ターゲット側に対してその蓄積されたイメージを転送します。つまり、通信回線が切断されても常用マシン上のアプリケーションは停止することはありません。これは皆さんが望んでいることでしょう。

図2に、切断された通信回線経路とそれに対応した、通信回線の再確立を待っている更新のジャーナルが段階的に蓄積されていく様子を示します。

同期リモート・ジャーナル送信モードを選択した場合、そのベースとなる通信層が、回線が本当に切断されていると判断するまでにリトライを何度か試みるのは事実です。また同期リモート・ジャーナルでは、アプリケーション・プログラムの下でこのリトライが行われ、したがってしばらくの間アプリケーション・プログラムが一時停止するというのも事実です。このようなリトライの時間が非常識なほど長いもので無ければ、上記の事実は良い兆しといえるのです。

このようなリトライによりアプリケーションが中断しないようにするために、IBMはV5R3でリモート・ジャーナル・サポートを強化し、リトライ時間を適度なものにしてあります。V5R3以前の製品をご使用の場合、（たとえばCHGTCPAコマンドなどで）リトライの試行を控えめにしたほうが良いでしょう。

ソース・マシンとターゲット・マシン間の通信パイプが、ターゲット側のパイプでゴミとして破棄されるようなものを運ばないようにする選択ができるのです。次回は、パイプ中を流れるデータをできるだけ効率的にパッケージ化するための最善策についてご紹介します。

ラリー・ヤングレン氏は、IBMロチェスター研究所に勤務し、i5/OSのマイクロコードの設計とiSeriesジャーナル開発チームのリーダーを務めています。