IBM i 7.1：ますます充実する高可用性サービス向けの遠隔ジャーナル
リリース 7.1 の新機能で HA サービス向け遠隔ジャーナルがさらに簡単で効果的に
最新リリースの IBM i, 7.1 には細かいが数多くの機能拡張が含まれており、それらは主に遠隔ジャーナル・サポートの利用を決めた高可用性 (HA) サービスの顧客を対象にしています。こうした新機能を利用することで、特に HA 環境でのジャーナル体験が向上します。
選択せよ
Start Journal Library (STRJRNLIB) サポートはリリース 6.1 で導入されました。このサポートでは、ライブラリーに属性が付与されます。この属性によって、このライブラリーで表示される新しいファイル、データ域、データ・キューのジャーナルが自動的に保護されます。これは、新規作成されたファイルを見落とさないようにする場合に、便利で魅力的な機能です。リリース 7.1 では、このサポートは機能拡張されており、この継承ルールに基づいてどのオブジェクトを組み込むか、またどのオブジェクトを除外するかなど、より選択的な操作が可能になります。6.1 サポートを気に入ったユーザーなら、この分野での 7.1 機能拡張に満足することでしょう。
例えば、作業ファイルと実動ファイル両方を同じライブラリーに保存するとしましょう。リリース 6.1 の方式は、オール・オア・ナッシングです。6.1 では、すべてのファイル (作業ファイルと実動ファイル両方) についてジャーナル保護を開始するようライブラリーに伝えるか、この新機能を使用せず、ファイルが存在しなくてもオペレーティング・システムに自動的にジャーナル保護を開始させるかのいずれかでした。リリース 7.1 では機能にさらに多様性が加わりました。作業ファイル (名前が WRK で始まるファイル) を省略できるのです。以下に新しい 7.1 サポートの例を挙げます。
STRJRNLIB LIB(MYLIBD) JRN(MYLIBA/JRN)
INHRULES((*ALL *ALLOPR *INCLUDE
*OBJDFT *OBJDFT *OBJDFT *ALL)
(*FILE *ALLOPR *OMIT *OBJDFT
*OBJDFT *OBJDFT WRK*))
このライブラリーの継承ルールを作っているのは INHRULES キーワードです。*FILE オブジェクトの *OMIT 指定では、名前が WRK という文字で始まるファイルはライブラリーの継承ルールの考慮から外すことを示しています。STRJRNLIB コマンドをプロンプトで指示して、その他の設定を表示します。
この機能拡張で結果的にわかったことは、その動作をカスタマイズできることで STRJRNLIB 継承サポートがリリース 6.1 のときよりもさらに魅力的で、多用途になったことです。
オペレーティング・システムに細かいことに執着させる
ときには、不穏な動きを眼にすることもあります。特にこれは、TCP/IP 通信回線でソース・マシンとターゲット・マシン間を遠隔ジャーナル接続している場合に発生します。わずかな隙をついて控えめでささいな問題が発生した場合でも、遠隔ジャーナル接続がダウンすることがあります。リリース 7.1 以前は、そうしたささいな問題が発生した場合、ジャーナル・エントリーはそれ以上宛先側に流れなくなりました。
遠隔ジャーナル接続が終了したと、あなた (あるいは HA ソフトウェア・パッケージ) が認識し、Change Remote Journal (CHGRMTJRN) コマンドを発行してその接続を再度アクティブにするまで、ジャーナル・エントリーは未送信のまま送信元に貯まっていました。高可用性を目標としているあなたとしては、あまり魅力的な状態とは言えませんね。リリース 7.1 では、オペレーティング・システムにそうした状態を監視させ、(必要なら複数回) 遠隔ジャーナル接続を再度アクティブにするようトライさせることで、そうしたイライラを解消してくれます。これは良いことだと思います。これで苦境から脱出することができるでしょう。
新しい自動リスタート・サポートは CHGRMTJRN コマンドで指定します。以下にその例を挙げます。
CHGRMTJRN RDB(CHICAGO)
SRCJRN(LCLLIB/JOURNAL1)
TGTJRN(RMTLIB/JOURNAL1) JRNSTATE(*ACTIVE)
DELIVERY(*ASYNC) RESTART(10 60)
遠隔ジャーナル接続を再確立する権限が与えられたことをオペレーティング・システムに通知するのは、最後の RESTART キーワードです。実際、この例では、60 秒間隔で最大 10 回までリスタートを試行するよう OS に指示しています。なかなか優れものでしょう?
遠隔ジャーナルのトラフィック・パターンから目を離さないで
遠隔ジャーナル送信を使用した HA アプローチでは、宛先側でジャーナル・イメージをタイムリーに受信し、処理する必要があります。しかしリリース 6.1 では、宛先側には何の取り組みもありませんでした。むしろリリース 6.1 では、送信元にモニターを導入して、新しいジャーナル・イメージがタイムリーに送信されるよう監視できるようになっています。そうしたサポートで身を固めていれば、こうした質問にも答えられるでしょう「送信元は、まともに新しいジャーナル・エントリーを次から次へと回線に投入しているのか？」。しかし、リリース 6.1 で監視できることは、全体像の半分に過ぎません。結果的に送信元が重労働を負っている場合、遅い通信回線や酷使された宛先側では、最新のデータベース変更が宛先側の複製ファイルでタイムリーに表示されるのを確認できない場合があります。その結果、リリース 6.1 サポートは、出だしはよかったものの、送信元の情報だけしか明らかにできませんでした。そのため、ほとんどのショップは、宛先側はどうなっているのかと頭をかきむしって困惑するだけでした。さらに何かが必要だったのです。
リリース 7.1 は、それに応えるような新しい宛先側表示機能を提供しています。「では、自分はどれだけ"遅れている"のか？」正直なところ、そうした表示機能はせいぜい推定レベルであり、一致するジャーナル画面では意図的に画面中心に「推定」という言葉を表示させ、その事実を強調しています。しかし基礎となるソフトウェアは、いわゆる推定でもかなり良いことを保証すべく懸命に動作しています。かなり良いので、100 分の 1 秒程度の遅れさえ報告しているほどですから。
宛先側が送信遅延 (例: ジャーナル・エントリーが作成され、送信元のローカル・ジャーナル・レシーバーに蓄積された時間とエントリーが表示され、宛先側の HA ソフトウェアでの収穫を待っている間の時間差) について認識している事をのぞいてみると、宛先側で はWork with Journal Attributes (WRKJRNA) コマンドを発行できます。結果生じる 7.1 ディスプレイには図 1 のような内容が表示されます。
WRKJRNA ディスプレイは、宛先側から見た送信遅延の現状を表示しているだけでなく、役に立ちそうな履歴情報 (最悪の遅延が目撃された場合にそれを明らかにするような情報) も表示している点に注目してください。そうした情報を手元に置いておくことで、使用している通信回線のサイズが適切で、同じ速度を実現しているかどうか判断する材料になるでしょう。
台所の流しに投げ入れないで
私が子供のころ、家族で一緒によく休暇を過ごした叔母さんがいました。叔母さんの車はいったん旅行の荷物を詰め込むと大変狭苦しくなり、いつもあっけに取られていたものです。一方、私の家族の車の後部座席はゆったりスペースがあり、私と兄弟はのんびり長距離旅行を楽しんだのです。この違いは、私の家族は、本当に必要と確信できるものだけを持っていく、最小主義というアプローチを採ったためです。一方、いとこの方の両親は、「まさかのために」目に見えるものをすべて詰め込んでいたのでした。
リリース 7.1 以前の遠隔ジャーナル・トランスポート・メカニズムは、叔母さんとその詰め込みすぎの性向によく似ていたと言えるでしょう。表示されるジャーナル・エントリーは、送信元で表示されると、問答無用で宛先側に送信されました。リリース 7.1 では、そうした動作から脱することができます。リリース 7.1 からは、送信元でジャーナル保護する権利が与えられている特定の種類のジャーナル・エントリー、または特定のオブジェクトからのジャーナリングされた変更がHA プロバイダーで必要ないとわかったら、そうした無用のエントリーを送信して、CPU サイクルや TCP/IP 帯域幅を無駄使いすることはありません。むしろ、オペレーティング・システムにそうしたジャーナル・エントリーを省略するようアドバイスできます。それらのエントリーはそれでも送信元で表示されますが、回線に飛び乗って宛先側に旅立つことはありません。
特に SQL ユーザーの場合、そうしたエントリーの主なカテゴリーの 1 つは、いわゆるジャーナル「前」イメージになる傾向があります。これらは SQL トランザクションが仮の変更をロールバックできるようにするジャーナル・エントリーです。それらは SQL トランザクションが進行中の場合に送信元で役に立ちますが、ほとんどの HA 製品ではそれらのエントリーは不要で、正直、絶対宛先側に送信しないでほしいと見なされています。リリース 7.1 時点では、送信する必要はありません。
この新しい 7.1 サポートをフル活用するため、以下のようなコマンドを発行できます。
CHGRMTJRN RDB(NEWYORK)
SRCJRN(LCLLIB/JOURNAL1)
TGTJRN(RMTLIB/JOURNAL1) JRNSTATE(*ACTIVE)
DELIVERY(*ASYNC) FTRIMAGES(*BEFORE)
最後のキーワードである FTRIMAGES を見てください。これは Filter Images パラメーターです。このパラメーターは、送信元の基礎となる遠隔ジャーナル・トランスポート・メカニズムにいわゆる、「前」イメージをフィルターに掛けるよう指示しています。つまり、これらのイメージは回線に載せるべきではなく、宛先側に表示されません。
特に「前」イメージの密度が高い場合、そうした選択が TCP/IP 通信回線が過剰バイトで目詰まりを起こさないようにするのに役立ちそうです。通信パケットがより効率的に充てんされるだけでなく、宛先側の収穫ソフトウェアと HA 再生ソフトウェアでふるいに分ける無駄なパケットが少なくて済みます。まさに、お互いメリットがあるウィン・ウィンの関係です。
実際この新しいサポートは、遠隔ジャーナルの効率を改善しようとしている人たちに非常に魅力的に写ります。IBM ではそれを使用するためにジャーナル・パフォーマンス・アクセラレーター (別名は OS の「Option 42 HA Journal Performance」機能) を必要としているほどです。これは、Change Journal (CHGJRN) コマンドの Journal Caching (JRNCACHE) キーワードをフル活用するため、多くの遠隔ジャーナル・ユーザーがすでにインストールしているジャーナル・アクセラレーター機能と同じです。したがって、このジャーナル・アクセラレーター・オプションは、効率性の向上のため、より効率的なジャーナル・バンドルを送信元に構築するだけでなく、選び抜かれたパケットを宛先側に送信するのに役立ちます。大量のジャーナル・アクティビティーを予想しているほとんどの堅実なジャーナル・ユーザーは、このオプションのインストールを真剣に考えてみる必要があります。
「通信回線に十分目配りをする簡単な方法は何も再送しないこと」により、遠隔ジャーナル接続は障害があったり、手入れされていない通信回線より速度が落ちます。使用している TCP/IP 接続に問題があり、ソース・マシンからターゲット・マシンへクリーンなパケットを無事送信できない場合、おそらく、宛先側が一生懸命受信しようと努力しているように見える事実以外の症状はほとんどないでしょう。
リリース 7.1 以前は、IBM はよく、遠隔ジャーナル・ユーザーは定期的に Network Statistics (NETSTAT) コマンドを発行して、遠隔ジャーナルを処理している通信回線を確認するよう提案していました。そこで高いレベルで再送信されたパケット (いわゆる、再送) が見つかった場合、IBM は回線をクリーンアップするよう提案していました。これは優れたアドバイスでしたが、ジャーナル・ユーザーとしては、遠隔ジャーナル・トラフィックの状態を監視するために非ジャーナル・コマンドに関わらなければならなかったことを意味しました。
リリース 7.1 により、そうした監視がはるかに簡単になりました。また、多少はより自然になりました。ジャーナル表示画面で、関連する遠隔ジャーナル通信回線情報が 1 つになったのです。
図 2 でおわかりのように、この遠隔ジャーナルで見られる再送信は WRKJRNA 画面の 2 次パネルで直接監視できます。1 次 WRKJRN 画面から何度かページを下に見て行き、この 2 次情報を確認する必要があります。
遠隔ジャーナル・ファンに微笑むリリース 7.1
まあ、そんなところです。新しい 7.1 ジャーナル機能をいくつかのぞいてみれば、真面目な遠隔ジャーナル・ユーザーの人生も多少はスムーズになるはずです。なんだか、外に飛び出して、リリース 7.1 のコピーを手にしたい気分にかられませんか？
