わずかな予算で災害時復旧に備える
市場に出回っている多くの製品は、System iの運用者が連続可用性と迅速なロール・スワップを確実に行なえるようにすることを目的としています。ハードウェアに大きく依存した製品もあります。また論理オブジェクト・レプリケーション用のソフトウェアを採用している製品もあります。そのほとんどが自分のお金を出してハードウェアやソフトウェアの機能をマシンに追加することを要求しています。
そのような製品をインストールして追加のサポートを構成するのは賢明なことであり、迅速なロール・スワップやさまざまなオブジェクト・タイプのレプリケーションをサポートする必要があるのならなおさらです。しかし本稿では少し違ったアプローチで探ってみます。たとえば上記のような製品を購入するための予算がない場合や、最も重要なデータベース・ファイルに対する最近の更新をレプリケートするだけにしたいという場合や、通常はごく簡単なデータベース操作だけを実施していたい場合、ターゲット・システム上でリフレッシュを連続再生することはせず定期的にリフレッシュするだけにしたい、というような場合はどうすればよいのでしょうか。以上のことを、既にi5/OSに同梱されているものを組み合わせて使用し、夜間保存だけに頼らずもっとタイムリーに回復できるようなテクニックはあるのでしょうか。実は「ある」のです。
その方法とは従来の意味で言う高可用性（HA: High Availability）のアプローチではありません。実際、この方法はせいぜい中程度の可用性と呼べる程度のものなので、これが適切とはいえない厳しく複雑な環境ももちろんあります。しかし、この方法は無料で利用できるのです。
この方法について私が最初に興味を持ったのは、数年前にあるコンサルタントが私のところへ来て、Apply Journal Changes (APYJRNCHG)というCLコマンドでリモート･ジャーナルを入力として使用できるかと尋ねてきたときです。私のそのときの回答は「できるわけがないじゃないか!」でした。しかし、その後もそのコンサルタントと電子メールでやり取りを続けるうちに、オペレーティング・システムの目を欺いてリモート・ジャーナル・レシーバーがローカル・ジャーナル・レシーバーに変換されたと思い込ませることができるかもしれないと気づきました。このコンサルタントは、実運用中のマシン上のデータベースの変更をターゲット・マシンに毎秒ごとに送信し、ターゲット・マシンを定期的（1時間ごとくらい）に起動して、その変更を重要なデータベース・ファイルのレプリカに対して再生することが従来のリモート・ジャーナル・サポートを使ってできる、というような設定を想像していたようです。この戦術は、最近発生したデータベースへの変更のほとんど大部分を、遠隔地にあるマシンに輸送して定期的に再生できるということを保証しています。可用性を最大限にするとか即時ロール・スワップをしようというのではなく、重要なデータベース・ファイルを夜間バッチで保存するという単純な方法よりは良い考えで、しかもタイムリーであるというものです。
概略背景
通常、実運用中のマシン上のデータベース・ファイルはローカル・ジャーナルによって保護されています。このローカル・ジャーナルはリモートにレプリケートすることができるので、リモート・ジャーナルを生成することができます（図1）。通常リモート・ジャーナルとそれに対応するジャーナル・レシーバーは、元々のデータベース・ファイルをハウジングしているマシンとは別のターゲット・マシン上に存在しています。ターゲット・マシンはソース・マシンからはかなり離れたところに存在しているので、火災や洪水、竜巻、地震、台風などといった災害からのマシンの生存、保護が可能です。ソース・マシン上のローカル・ジャーナルに流れてくるものは、すべてすぐにターゲット・マシン上のリモート・ジャーナルにも流れていきます。どれくらい早いかというと、コンマ何秒の間です。したがって、リモート・ジャーナル・レシーバーは、実運用されているファイルに影響を与える最近のデータベースへの変更に関して、信頼性の高いタイムリーな情報源となります。
この種の構成では、リモート・ジャーナルはローカル・ジャーナルの双子の相棒となります。ただしこの双子には一点だけ重要な差異があります。リモート・ジャーナルは自分自身に対して供給してくるデータベース・ファイルがないという点です。少なくともターゲット・マシン上には存在しません。その結果、このリモート・ジャーナルに対してAPYJRNCHG操作を発行しようとしても拒否されます。この点がまさに前述のコンサルタントが解決しようとしていた問題なのです。
リダイレクション: OSの目を欺く
私は研究所のi5/OSの仲間に集まってもらって議論しましたが、話し合えば合うほど、ジャーナル・レシーバー（それがローカルにあろうとリモートにあろうと）がテープや保存ファイルなどといった保存メディアに一旦書き出されてしまうと、その出所を思い起こそうとしないという事実が明らかになってきました。保存されたジャーナル・レシーバーは回復時にのみ適切なジャーナルに連結しようとし、そのターゲット・ジャーナルがローカルにあるのかリモートにあるのかを問題にしません。これこそが今回の問題を解決するための秘訣です。
ジャーナルとジャーナル・レシーバーは通常自分が何と関連付けられているかについて気にしていて、名前を変更されたり場所を移動されたりすることに対して制限ルールを設けているのですが、そのような制限ルールはいずれもジャーナル・レシーバーとそれに対応するジャーナルとの間の名前の関連付けに基づいています。したがって、リモート・レシーバーが生成された元となっているソース・ジャーナルと同じ名前のジャーナルを（そのジャーナルがどのライブラリ中に存在するかも含めて）ターゲット側に置く方法が見つかれば、問題は解決されたことになります。このターゲット・ジャーナルの置換を実現し、それによってオペレーティング・システムの目を欺くためには、ターゲット側のライブラリ構造を注意深く設定する必要があります。
ローカル・ジャーナルをハウジングしている実運用中のマシン上にあるソース・ライブラリ、リモート・ジャーナルをハウジングしているターゲット・マシン上にあるリダイレクトされたライブラリ、ローカル・ジャーナルをハウジングしているターゲット・マシン上の重複ソース・ライブラリの3つのライブラリを図2に示します。
リモート・ジャーナル・レシーバーは、その名前とリモート・ジャーナルが元々複製を作る際の元になったライブラリ（つまり、実運用中のマシン上にあるソース・ライブラリ）と対応する関連ライブラリを探したり連結したりすることに対して強い類似性があるため、この保存されたジャーナル・レシーバーはターゲット側での回復時に名前の検索を実行します。ジャーナル・レシーバーは、ソース側と全く同じライブラリ名の中にハウジングされている、自分と全く同じ名前のジャーナルを検索します。こうした巧妙な名前付け戦略により、保存されたリモート・ジャーナル・レシーバーの回復時にオペレーティング・システムを騙して、あたかもローカル・ジャーナル・レシーバーであるかのように扱うことができます。
我々の戦略は、リダイレクト・ライブラリを置くことでリモート・ジャーナル・レシーバーを定期的に保存ファイルに保存して、すぐにその保存イメージを回復し、ローカル・ジャーナル・レシーバーを生成するというものです。（リダイレクトされたライブラリ中に存在する）リモート・ジャーナル・レシーバーのコピーを保存するCLコマンドの例を図3Aに示します。図3Bには、それに対応する保存されたリモート・レシーバーを回復して重複ソース・ライブラリを指し示すためのCLコマンドを示します。この例では、RDIRLIBがリモート・ジャーナル・レシーバーをハウジングしているリダイレクトされたライブラリで、SRCLIBはターゲット・マシン上でローカル・ジャーナルをハウジングしているライブラリです。
さあ、あなたの番です
今までのリモート・レシーバーをローカル・レシーバーとみなすことで、ターゲット側でAPYJRNCHGコマンドまたはAPYJRNCHGXコマンドを発行してリモート・ジャーナル・レシーバーのコンテンツをレプリカ・ファイルに適用することができます。これでいいのか、というくらい簡単です。
もう少し全体像を見ることで各ステップを見てみましょう。定期的な論理リフレッシュのための全体的な戦略には以下のアクションが必要で、それぞれ図4中のラベル番号に対応しています。
- 実運用中のシステム上で最も重要なデータベース・ファイルを識別し、それら1つ1つに対してローカル・ジャーナル機能が有効になっていることを確かめます（STRJRNPF）。
- ターゲット・システムにその重要なデータベース・ファイルの最初のコピーを準備します。これにはソース側でそれらのファイルを保存し、ターゲット側で回復します。こうすることで、重要な内部母斑であるJID（ジャーナル識別子）がレプリカ・ファイルに対して割り当てられます。対応するJIDは重要です。JIDはAPYJRNCHGXコマンドを使用することでリモート・ジャーナル・レシーバーを読み込む際に適切なオブジェクトを探すことができます。
- ターゲット・マシンに対するリモート・ジャーナル接続を設定します。このステップにおいてはライブラリ・リダイレクションを採用して、リモート・ジャーナルがオリジナルのソース・ライブラリと異なるライブラリに存在するようにしてください。
- レプリカされたファイル用にターゲット側でのローカル・ジャーナル機能を有効にし、ローカル・ジャーナルが自分自身をソース側の対応するローカル・ジャーナルと同じライブラリに存在するように見えるようにします。これが、回復時にリモート・レシーバーを「採用する」ローカル・ジャーナルとなります。
- 上記のリモート・ジャーナル・レシーバーを定期的にしかも堅実に保存ファイルに保存できる戦略を決めます。この戦略を実行するプログラム例については
www-03.ibm.com/servers/eserver/iseries/db2/journalperfutilities.htmlを参照ください。 - 保存ファイルから上記のジャーナル・レシーバーのイメージを回復し、回復されたジャーナル・レシーバーが、ソース側の元々のソース・ライブラリと同じ名前のターゲット側のライブラリ中にあるローカル・ジャーナルに追加されるように指示します。
- 適切なジャーナル「apply」コマンドを発行します。環境によってはAPYJRNCHGで簡単にできる場合もありますが、成功の確率を高めるにはAPYJRNCHGXを使用するようステップアップしてみてはいかがでしょうか。APYJRNCHGXは簡単なputやupdateを個々の行で再生するだけでなく、新たに作成されたファイルやメンバーについてもすべて再生します。
- 新しいジャーナル・レシーバーがデタッチされるたびに上記5、6、7のステップを繰り返します。
モーニング・コール
上記のステップ5、6、7を毎回手動で実行しても構いませんが、そうした単純作業にはすぐに飽きてしまうでしょう。このプロセスを簡素化するには、ジャーナル・レシーバーのサイズやコンテンツがそれ以上増大しないことがほぼ確実になった状態のときだけ、上記のようなAPYJRNCHGX操作をするというような戦略を実施するのが一般的です。そのような状態はジャーナル・レシーバーがデタッチされたときに発生します。つまり、新しいレシーバーを生成してアタッチするCHGJRN操作をするとこのような状態になります。したがって、定期的な「apply」操作をいつ実行すれば良いかを知るためのトリガ・メカニズム（モーニング・コールのようなもの）は、リモート・ジャーナルに関連付けられているメッセージ・キューを監視してジャーナルのデタッチ・メッセージを見ていれば自動化できます。
このような監視をするために使用するサンプル・ソフトウェアは前述のウェブサイトに掲載されています。このサンプル・プログラムはHAAPPLYというもので、ターゲット・マシン上で実行します。
同様に、上記のようなCHGJRN操作（トリガ・メカニズム）がソース・マシン上で定期的に実行されるようにしておくことが必須です。これには、ジャーナル容量の閾値を設定してCHGJRN操作がレシーバーのサイズに応じて定期的に発行されるようにしておくことができます。または、（前述のウェブサイトに掲載されている）CHGNSLEEPプログラムを使用して、このような操作が経過時間に応じて発行されるようにしておくこともできます。このプログラムはソース側で起動し、ソース・マシン側でCHGJRN操作が発行されるたびにターゲット・システム上に存在するリモート・ジャーナル用の対応するCHGJRN操作を起動します。
空中偵察
ここで本稿を読むのを止めても十分なソリューションが得られるかもしれませんが、リモート・ジャーナル接続を監視しておくことが有益な場合もあります。もし寝ぼけた遠隔オペレータが通信回線を切断してしまったら、プロバイダは運転を止めるか機能不全に陥って接続がタイムアウトしてしまうので、すぐに対策を取れるようにしておきたいでしょう。私がこれに対応するリモート・ジャーナルの接続状態を監視する空中偵察プログラムを同僚に書くように頼んだのは、こうした理由によるものです。ソース側のローカル・ジャーナルには対応するメッセージ・キューが割り当てられており、このキューはリモート・ジャーナルが停止するときに通知を受けます。空中偵察プログラムはHRTMONITOR （心拍数モニタを意味するHeartbeat Monitorからつけた名前だと思います）といい、前述の他のプログラムと同じウェブサイトに掲載されています。あまり見栄えの良いプログラムではありませんし、ユーザー・フレンドリーなものにするには修正の必要があると思うでしょうが、ポイントはおわかりいただけると思います。
リモート・ジャーナル接続が切断されたようなときはどうなるのでしょうか。ソース側のアプリケーションは稼働を続け、ソース側のローカル・ジャーナル・レシーバーは次々に発生するデータベースへの変更に関する差分情報を収集し続けます。接続線の問題が解消すればリモート・ジャーナル接続の再起動は簡単です。上記サンプルの心拍数計プログラムは、このような場合オプションで知らせてくれます。
ところでどこまでついてこられるのか
上記のアプローチは非常にシンプルで原始的なアプローチです。速度という面では最適なものではありません。ターゲット側に並列処理は組み込まれていません。レプリカ・データベースの行を更新する前に主記憶装置に読み込むという先読み処理もしていません。これらはいずれもターゲット側が遅れないようにするためによく使用される本格的なHA製品のテクニックです。しかも当然のことですが、確実に迅速なロール・スワップで連続再生を行なう必要がある場合も同様の操作が必要です。ですから「データベースの新しい変更が次々に大量に発生したときに、この定期的な節約版再生テクニックが本当についていけるのか」という疑問が出て当然です。
その疑問に答えるのに、ホテルのフロントデスクの簡単なチェックイン環境をソース側に設定し、疑似会議を処理するように準備しました。私たちが試したサンプル環境では、1人のゲストがチェックインするのに7個のSQL文を必要とし、毎分500人以上のゲストを処理しました。かなり負荷を高めに（おそらく慎重すぎると思えるくらい高めですが、ターゲット側にわざと負荷をかけたかったのです）138秒間隔でジャーナル・レシーバーを変更しました。つまり、数分ごとに約8,700個以上のジャーナル・エントリーがターゲット側に適用されることになります。
使用したソース側のマシンは12ウェイ・モデル840で、OSはV5R4でした。ターゲット側のマシンは4ウェイ・モデル520です。結果はというと、図5に示した通り、ソース側で毎分4,754件のジャーナル・エントリーを生成し、それと同じエントリーをターゲット側で毎分16,004件の速度で再生しました。この速度ではターゲット側は何の問題もなくソース側についてこられました。もっと負荷の高い環境では、元になっているSQLテーブルを別個のジャーナルにさらに分割することで、ターゲット側の並列処理度を高めることができます。
比較のために別のデータでも実行して138秒間隔よりも負荷を重くしたり少なくしたりしてジャーナル・レシーバーを起動、変更してみました。図に示した通り5秒～10秒間隔で定期的にリフレッシュするのはかなり高負荷で、APYJRNCHGX操作はついてくるのが大変でした。リフレッシュ操作の時間間隔は5分から10分とするのが妥当でしょう。なぜかというと、データベースの各行毎に適度な起動オーバーヘッドがあるというだけで再生するように調整されているHA製品とは異なり、組み込まれているAPYJRNCHGXコマンドは滑走路までノロノロと進むボーイング747機のようなもので、上空に上がるまでにしばらく時間がかかるのです。ただし巡航高度に達した後は、大量の乗客を長距離に渡って輸送するには効率的な手段となります。APYJRNCHGXの場合もこれと同じなのです。このプログラムは一度に1行を処理するためのものではなく、それなりの量を処理するためのものなのです。勢いがつけば各行のイメージをSLIC対SLICで更新します。図5に示したターゲット側とソース側の棒グラフを比較してみれば、この方法がかなり効率的であることがおわかりいただけるでしょう。
しかし、最初に勢いをつけて巡航速度になるまでにかなりのオーバーヘッドがあるので、APYJRNCHGXは1行毎を一度に1行ずつ連続して適用するアプローチには向いていません。そうしたアプローチは市場に出回っている正式なHA製品にお任せします。ここでご紹介したのは、リモート・ジャーナルからの簡単な定期的適用を（1つずつではなく塊で）行なうためのもので、それ以上のものではありません。
ソース側の蓄積速度がもっと速くなったときでも処理速度は変わらないとまでは言い切れませんし、ソース側で何百何千という対話ジョブがデータベースを高速で更新しているような場合は、1つの適用ジョブが一貫してターゲット側でもついてこられると期待するのは現実的ではありません。そのような大量のトラフィックがある場合は、本格的なHA製品を購入する必要があります。ここでご紹介した定期的にリフレッシュをするというアプローチは、もっと小規模でそれほどの処理速度を求められない、重要なファイルがごく一部に限られたものであるような場合に向いているのです。
結局どういうことか
今回述べてきたことを、ここで振り返ってみましょう。
- 重要なファイルに対する最新の変更を、遠隔地にあるターゲット・マシンに対して、その変更が発生後コンマ何秒かの間にルーティングする方法
- ジャーナル・レシーバーのデタッチ操作を定期的に起動し、その結果、適用操作を一定間隔で起動するための規則
上記の結果から得られる恩恵は、最も重要なデータベース・ファイルのコピーを定期的にリフレッシュするテクニックです。
このようなサポートで武装することで、最新のデータベースへの変更が、元の実運用中のシステムから離れた場所にあるマシン上で安全で確実な状態にあるということがわかりますので、夜間も安心して眠ることができます。これだけでも本当に災害が起こったとしても十分な準備を整えるのに役立つでしょう。この特別なソフトウェアのために支払う代金は、1円も必要ありません。すべてi5/OSの中に組み込まれているからです。
このプログラムは最高の可用性をもたらすのでしょうか。もちろんそうではありませんし、そう言うつもりもありません。ロール・スワップに必要な時間は一瞬ではありません。このアプローチは、簡単なデータベース・ファイル以外のオブジェクト・タイプはレプリケートしませんし、入れ子トランザクションなどといったしゃれたことができるわけでもありません。しかし実際にサイトに壊滅的なダメージを与えるような災害が起こったときに、最も重要なデータベース・ファイルに対して行なわれた最新の変更が、健全なまま生きているということがわかっているのは良いことです。
これが本稿を書こうと思った本当の動機であり、中程度の可用性しか与えないアプローチに甘んじるよう提案するものではなく、ただこのアプローチを設定してテストするのがいかに簡単なものであるかを説明したかっただけなのです。実際に設定してテストしてみると、財務担当部門の人にリモート・オブジェクトのレプリケーションを説明して、その恩恵を証明することができるでしょう。そして次のステップとして本格的なHAソフトウェア製品を購入するよう、その財務担当者を説得することができるかもしれません。
さあ準備はできました。リモート・ジャーナルから定期的にリフレッシュすることで、わずかな予算で可用性を中程度に保つことができるのです。そのようなレプリケーションがこんなに簡単に、しかもこんなに安価で実現できると誰が知っていたでしょうか。
