IBM i ストレージ管理機能
IBM iでは、システムに構成されたディスク装置はすべて、論理的なグループにまとめて管理する仕組みになっている。この論理的なグルーピングをASP （Auxiliary Storage Pool：補助記憶域プール）と呼んでいる。
IBM i はASPにデータを配置する際に、基本的にASPを構成するディスク装置に自動的に分散させて、各ディスク装置の容量使用率を均衡化する機能を備える。それにより、ディスク装置からデータやオブジェクトを読み出す際、各ディスク装置から並行してデータを取り出せるので、よりよい読み出しパフォーマンスが期待できる。
またASPの容量使用率が高くなってきた場合は、ASPにディスク装置を追加すればよい。追加後、OSによるデータ・バランシング機能を実行することで、追加されたディスク装置を含め、ASPを構成する全ディスク装置にデータが再配置される。このようなデータ再配置機能は最近、先進的な外部ストレージで実装されるようになったが、IBM i では実に20年以上前から実装している。
ASPは大きく、「システムASP」と「ユーザーASP」に分けられる。またユーザーASPには、「基本ユーザーASP」と「独立ユーザーASP」がある（図表1）。
【図表1 画像をクリックすると拡大します】
システムASPは、OSコードや一時記憶域など、システムが利用するデータやオブジェクトが格納される領域である。IBM i に取り付けているディスク装置をすべてシステムASPに追加し、ユーザーデータやオブジェクトもシステムASPに配置できる。
IBM i はデータやオブジェクトを、ASPを構成する全ディスク装置に対して分散配置することで、高いディスクI/Oパフォーマンスを実現する。ただし、あるディスク装置が故障した場合、全データおよびオブジェクトの一部が消失する。つまり、単一ディスク装置の障害の影響は全データ、全オブジェクトに波及することになる（そのためASPの保護というのがきわめて重要で、ASP単位でミラー保護したりする）。そこで、その影響範囲を限定する目的で生まれたのが、「基本ユーザーASP」である。
基本ユーザーASPは、システムASPを構成するディスク装置とは別のディスク装置で構成するストレージ領域である。基本ユーザーASPのディスク装置に障害が発生しても、システムASPのデータやオブジェクトへの影響が抑えられる。
またデータはASP単位でストライピングされるので、I/O分離の観点からも基本ユーザーASPを用いることが多い。業務データ系のI/Oとログ系のI/Oを分離し、ログ書き出しによる業務データI/Oパフォーマンスへの影響を抑える目的で、DBログであるジャーナル・レシーバーを専用の基本ユーザーASPで構成し、配置することが広く行われている。
もう1つのASPは、「独立ユーザーASP 」（Independent user Auxiliary Storage Pool。以下、IASP）と呼ばれるASPである。基本ユーザーASPはIBM i から見て、常に使用可能な状態でなければならない。それに対してIASPは、IBM i の稼働中に接続したり、切断したりできる。
IBM i の有償ライセンス・プログラムの「PowerHA SystemMirror for i」はこの特徴を活かして、システム間でIASPを複製することにより、ストレージベースの可用性ソリューションを提供している。IBM i のOSベースのIASP複製ソリューションは「地理的ミラーリング」と呼ばれる。外部ストレージが提供するMetro MirrorやGlobal Mirrorなどと連携してIASPを複製する機能も、PowerHA SystemMirror for i では実装されている。
ジャーナル機能
前項で、ユーザーASPに配置することの多いオブジェクトとしてジャーナル・レシーバーを挙げたが、これはDB2 for i におけるDBログなど、IBM i におけるオブジェクト変更の履歴情報や追跡情報を書き出しておくためのオブジェクトである。ジャーナルによる変更の追跡は、図表2のようにDB2 for i のテーブルをはじめとする多種多様なオブジェクトに対して有効化できる。
【図表2 画像をクリックすると拡大します】
DB2 for iにおけるジャーナル機能は図表3のように、テーブルに対してジャーナルと呼ばれるログ記録機能を仕掛けておき、対象の変更内容をジャーナル・レシーバーと呼ばれる入れ物に蓄積する機能を指す。
【図表3 画像をクリックすると拡大します】
ジャーナル・レシーバーに蓄積した情報は図表4のとおり、大きく分けて2つのデータのリカバリに活用できる。
【図表4 画像をクリックすると拡大します】
1つ目はデータの正方向回復（フォワード・リカバリ）で、テーブルをテープから復元した際に、テーブルの保管時点から現時点までのデータの変更内容をテーブルに反映させる処理となる。
2つ目が逆方向回復 （バックアウト・リカバリ）と呼ばれるもので、テーブル内のデータを誤って更新した場合に、希望の時点まで内容を巻き戻す処理となる。
業務アプリケーションでコミットメント制御が必要な場合には、その業務アプリケーションが処理対象とするテーブルに対して、ジャーナルを開始しておくとよい。
DBデータの回復やOSとしてのオブジェクトの保全性に威力を発揮するジャーナルだが、変遷を追跡できるという特徴を活かして、システムの監査証跡にも利用されている。
それが、「監査ジャーナル」と呼ばれる機能だ。監査ジャーナルはIBM i に対するセキュリティ・イベントを記録するための機能で、対象とする監査はアクション監査とオブジェクト監査の2つとなる。
アクション監査とは、ユーザーがシステム上でどのような行為を行ったかの証跡を取得する。一方のオブジェクト監査とは、対象とするオブジェクトへのアクセス記録を取得する。いずれの場合も、全ユーザーを対象にしたり、もしくは特定ユーザーを対象にしたりと、どちらにも対応可能なので、対象を絞った効率的な監査証跡を取得できる（図表5）。
【図表5 画像をクリックすると拡大します】
また、データベース・ジャーナルおよび監査ジャーナルの変更履歴を取得・追跡するという機能を活かして、リモートにジャーナル項目を転送し、リモート側でジャーナル項目データから実データを再生する形でレプリケーションを実現するソリューションも、多くのソフトウェアベンダーから提供されている（図表6）。
【図表6 画像をクリックすると拡大します】
HABP （High Availability Business Partner） ソリューションと総称されることもあるこれらのソリューションは、IBM i の世界では歴史が長い。一方、他プラットフォームのRDBMSでは近年、このようなDBログをベースとしたデータ複製ソリューションが登場している。基礎知識編にある「05 IBM i とデータベース」の項で、DB2 for i の特徴として運用管理の容易性を挙げたが、先進的なHABPソリューションの提供も、他のRDBMSと比較した際の特徴の1つとして挙げられる。【中村 陽一】
