2.1 FLAIMデータベース

eDirectoryはデータベースとしてFLAIMを使用しています。FLAIM (Flexible Adaptable Information Manager)は、従来型の情報、揮発性情報および複雑な情報に対して使用されます。FLAIMは拡張性に優れたデータベースエンジンで、マルチリーダ/シングルライタ並列実行モデルをサポートしています。リーダはライタをブロックせず、ライタもリーダをブロックしません。

物理的に、FLAIMはデータをブロックに体系化します。一部のブロックは、一般的にメモリ内に保持されます。これらがブロックキャッシュです。エントリキャッシュ(レコードキャッシュと呼ばれることもあります)は、データベースからの論理エントリをキャッシュします。エントリは、ブロックキャッシュ内のアイテムで構成されています。FLAIMは両方のキャッシュに対してハッシュテーブルを保持します。ハッシュバケツのサイズは、アイテムの数に応じて定期的に調整されます。

デフォルトで、eDirectoryは4KBのブロックサイズを使用します。DIB全体をキャッシュするためのブロックキャッシュサイズはDIBサイズに等しく、エントリキャッシュに必要なサイズはDIBサイズの約2倍から4倍です。

エントリを読み出す際に、FLAIMはまずエントリキャッシュ内のエントリを確認します。エントリが存在する場合、ブロックキャッシュからの読出しは必要ありません。ディスクからブロックを取得する際に、FLAIMはまずキャッシュ内のブロックを確認します。ブロックが存在する場合、ディスク読み込み操作は必要ありません。

エントリが追加されたかまたは変更された場合、そのエントリに対応するブロックはディスクに直接コミットされないので、ディスクとメモリは同期されていない可能性があります。ただし、エントリに対する更新はロールフォワードログ(RFL)に記録されます。RFLは、システム障害後にトランザクションを回復するために使用されます。

Least Recentrly Used (LRU)は、キャッシュ内のアイテムを置換するために使用される置換アルゴリズムです。

2.1.1 チェックポイント

チェックポイントは、オンディスクバージョンのデータベースとインメモリ(キャッシュされた)データベースの整合性を保ちます。FLAIMは、データベースへの最小限の更新アクティビティ中にチェックポイントを実行することができます。これは毎秒実行され、ダーティブロック(ダーティキャッシュ)をディスクに書き込みます。キャッシュ内で変更されたものの、まだディスクに書き込まれていないブロックを「ダーティブロック」と呼びます。FLAIMはデータベースのロックを取得し、チェックポイントが完了するか他のスレッドがデータベースの更新を待機するまで、可能な限り最大量の仕事をします。オンディスクデータベースが同期状態からかけ離れてしまわないため、ある条件下では、データベースの更新を待機しているスレッドがある場合でもチェックポイントが強制的に実行されます:

  • チェックポイントスレッドが既定の時間(デフォルトで3分)以内にチェックポイントを完了できない場合、強制的に実行され、ダーティキャッシュは排除されます。

  • ダーティキャッシュのサイズがmaxdirtycache(設定されている場合)よりも大きい場合、チェックポイントはダーティキャッシュのサイズをmindirtycache(設定されている場合)または0まで強制的に減らします。

2.1.2 インデックス

インデックスは、インデックス内で特定のキーを探すというタスクのスピードを大幅に向上できるように配置されたキーの集合です。インデックスキーは、エントリから一つ以上のフィールド(属性)の内容を抽出することで構築されます。インデックスはブロックキャッシュ内に保持されます。インデック付き属性が変更された場合、インデックスブロック内での変更が必要です。

eDirectoryは、システム属性(フィールド)に対してデフォルトのインデックス集合を定義しています。parentIDおよびancestorIDなどのシステム属性は、1レベル検索およびサブツリー検索に使用されます。これらのインデックスは、中断や削除ができません。ディレクトリは内部でこれらを使用します。デフォルトインデックスは、CNSurnameGiven Nameなどの属性に対して定義されています。インデックスには、実在インデックス、値インデックスおよび部分文字列インデックスの種類があります。これらのインデックスは中断できます。削除すると、自動的に再作成されます。

iManagerまたはndsindex Lightweight Directory Access Protocol (LDAP)ユーティリティを使用してインデックスを作成できます。インデックスはサーバに固有のものです。

DSTrace (ndstrace)内でStorage Manager(StrMan)タグを有効にすることで、検索クエリに選んだインデックスを確認できます。

次に示すのは、"cn=admin"、CNを使用したサブツリー検索に対するDSTraceログの例です。

3019918240 StrMan: Iter #b239c18 query ((Flags&1)==1) && ((CN$217A$.Flags&8=="admin") && (AncestorID==32821))
3019918240 StrMan: Iter #b239c18 index = CN$IX$220

次に示すのは、"Description=This is for testing"AncestorIDを使用したサブツリー検索に対するDSTraceログの例です。

2902035360 StrMan: Iter #83075b0 query ((Flags&1)==1) && ((Description$225A$.Flags&8=="This is for testing") && (AncestorID==32821))
2902035360 StrMan: Iter #83075b0 index = AncestorID_IX

2.1.3 ロールフォワードログ

FLAIMは、各更新トランザクションに対する操作をロールフォワードログ(RFL)ファイルに記録します。RFLは、システム障害からトランザクションを回復する時や、バックアップから復元する時に使用されます。RFLファイルはチェックポイントが完了するたびに切り詰められます。ただしhot continuous backupを使用して(rflkeepfiles)がオンになっている場合を除きます。

2.1.4 FLAIMの属性コンテナリゼーション

エントリキャッシュの使用率を最適化し、属性検索操作のパフォーマンスを向上させるため、FLAIMは、値のサイズが大きい属性または値の個数が多い属性を、属性コンテナと呼ばれる別の場所に格納します。属性コンテナに移動できるのは、以下の条件に該当する属性です。

  • 値の数が25個を超える

  • 値のサイズが2048バイトを超える

eDirectoryでは、属性の移動を柔軟にスケジューリングできます。まず、移動する準備ができている属性を表示し、自分の都合に合わせて移動をスケジュールします。

属性コンテナに移動する準備ができている属性の数を表示するには、ndscheckコマンドを実行します。属性の詳細を表示するには、擬似サーバオブジェクトのiMonitor dsReadyContainerAttr属性を使用します。

属性コンテナリゼーションを開始するには、擬似サーバオブジェクトのndsrepairの単一オブジェクト修復オプションを使用します。属性をコンテナに格納するには、ndsrepairコマンドを実行します。その際次のように、新しいアドバンススイッチ-amと、その後に属性名を指定します。

ndsrepair –J <Pseudo server object ID> –Ad –AM/–am <attribute name>

属性の自動コンテナリゼーションを有効にするには、_ndsdb.iniファイルにenablemovetoattrcontainer=1を追加し、eDirectoryを再起動します。

属性コンテナに属性を移動すると、eDirectoryによって、その属性の名前でシステムインデックスが作成されます。コンテナに格納した属性を、元のコンテナに戻すことはできません。