1.7 Calendar Server バージョン 6.3 の LDAP データキャッシュオプション

LDAP データキャッシュオプションを使用すると、LDAP ディレクトリサーバーが、コミットされたデータの利用可能性に遅延が発生するように設定されている場合でも、コミットされるとすぐに LDAP データが利用できるようになります。

たとえば、サイト上にマスター/スレーブ LDAP 構成が配備されており、Calendar Server がマスター LDAP ディレクトリにスレーブ LDAP ディレクトリサーバー経由でアクセスする仕組みになっている場合、コミット済み LDAP データが利用可能になるまでにいくらかの遅延が発生しますが、LDAP データキャッシュを使えば、Calendar Server クライアントが正確な LDAP データにアクセスできるようになります。

ここでは、次の内容について説明します。

• 「1.7.1 Calendar Server バージョン 6.3 での LDAP データキャッシュの使用に関する考慮事項」

• 「1.7.2 Calendar Server バージョン 6.3 のマスター/スレーブ LDAP 構成」

• 「1.7.3 Calendar Server バージョン 6.3 の LDAP データキャッシュ」

• 「1.7.4 Calendar Server バージョン 6.3 の LDAP データキャッシュの制約」

1.7.1 Calendar Server バージョン 6.3 での LDAP データキャッシュの使用に関する考慮事項

次のガイドラインを使用して、サイトで LDAP データキャッシュを設定すべきかどうかを判断してください。

• サイトの Calendar Server がマスター (またはルート) LDAP ディレクトリサーバーに直接アクセスし、コミット済み LDAP データが利用可能になるまでの遅延が発生しない場合、LDAP データキャッシュを設定する必要はありません。local.ldap.cache.enable パラメータが "no" (デフォルト値) に設定されていることを確認してください。

• 「1.7.2 Calendar Server バージョン 6.3 のマスター/スレーブ LDAP 構成」が配備されており、Calendar Server がスレーブ LDAP ディレクトリサーバー経由でマスター LDAP ディレクトリにアクセスしている場合は、コミットされた LDAP データの利用可能性に遅延が発生します。LDAP データキャッシュを設定して、エンドユーザーが最新のデータを入手できるようにしてください。

1.7.2 Calendar Server バージョン 6.3 のマスター/スレーブ LDAP 構成

マスター/スレーブ LDAP 構成には、マスター (ルート) ディレクトリサーバーと、1 つ以上のスレーブ (コンシューマまたはレプリカ) ディレクトリサーバーが含まれます。Calendar Server は、マスター LDAP ディレクトリサーバーに直接アクセスすることも、スレーブディレクトリサーバー経由でアクセスすることもできます。

• Calendar Server がマスター LDAP ディレクトリサーバーに直接アクセスする場合、LDAP データは正確であるはずなので、LDAP データキャッシュを設定する必要はありません。

• Calendar Server がスレーブディレクトリサーバー経由でマスター LDAP ディレクトリサーバーにアクセスしている場合は、LDAP データの変更は通常、LDAP リフェラルを使用して透過的にマスターディレクトリサーバーに書き込まれます。次に、LDAP リフェラルは、データをレプリケーションにより各スレーブディレクトリサーバーに戻します。

  この 2 番目のタイプの構成では、コミットされた LDAP データがスレーブディレクトリサーバーで利用可能になるまでに遅延が発生するため、LDAP データが不正確になるという問題が発生する場合があります。

  たとえば、Calendar Server が LDAP データの変更をコミットしても、マスターディレクトリサーバーが各スレーブディレクトリサーバーの更新を完了するまでの遅延のために、一定の時間は新しいデータが利用できません。以降の Calendar Server クライアント操作で古い LDAP データが使用されると、期限切れの内容が表示されます。

  スレーブディレクトリサーバーを更新する際の遅延が短時間 (ほんの数秒) であれば、クライアントで問題が発生しないこともあります。しかし、遅延がそれ以上 (数分または数時間) になると、遅延の長さに応じてクライアントには不正確な LDAP データが表示されます。

  次の表は、このような遅延によって影響を受ける操作と LDAP 属性を示しています。

  操作	LDAP 属性
  カレンダの自動プロビジョニング	icsCalendar、icsSubscribed、 icsCalendarOwned、icsDWPHost
  カレンダグループ	icsStatus、icsCalendar
  カレンダの作成	icsCalendarOwned、icsSubscribed
  カレンダの登録	icsSubscribed
  ユーザーオプション	icsExtendedUserPrefs、icsFirstDay、 icsTimeZone、icsFreeBusy
  カレンダの検索	icsCalendarOwned

1.7.3 Calendar Server バージョン 6.3 の LDAP データキャッシュ

LDAP データキャッシュは、マスターディレクトリサーバーが各スレーブディレクトリサーバーをまだ更新していない場合でも、Calendar Server クライアントに最新の LDAP データを提供することにより、マスター/スレーブ LDAP 構成の問題を解決します。

LDAP データキャッシュが有効になっていると、Calendar Server は、コミットされた LDAP データをキャッシュデータベース (ldapcache.db ファイル) に書き込みます。LDAP キャッシュデータベースは、デフォルトでは ldap_cache データベースディレクトリに配置されますが、必要に応じて別の場所を設定できます。

クライアントが単一ユーザーの LDAP データを変更すると、Calendar Server は、変更されたデータをスレーブディレクトリサーバーだけでなく、LDAP キャッシュデータベースにも書き込みます。以降のクライアント操作では、LDAP データがキャッシュデータベースから取得されます。

このデータ取得は、単一ユーザーの次の操作に適用されます。

• ログイン時のユーザーの属性

• ユーザーのオプション (配色やタイムゾーンなど)

• ユーザーのカレンダグループ

• ユーザーの登録済みカレンダリスト

これにより、LDAP データキャッシュデータベースでは次のことが可能になります。

• 単一システム上のプロセス間でのデータ整合性。データベースは、マルチプロセッサシステム上のすべての Calendar Server プロセスで利用可能です。

• ユーザーセッション間でのデータ持続性。データベースは永続的であり、更新は必要ありません。

1.7.4 Calendar Server バージョン 6.3 の LDAP データキャッシュの制約

LDAP データキャッシュでは、次のことを行うことはできません。

• エントリのリストが予測される検索のためにキャッシュを読み取ること。たとえば、会議の出席者の検索がこれに当たります。このタイプの検索は、すべての LDAP 遅延の影響を受けます。たとえば、LDAP の検索オプションがアクティブになっており、新しいカレンダを作成したあとの遅延時間内に検索が実行された場合は、カレンダの検索で、新しく作成されたカレンダは表示されません。

• 複数のフロントエンドサーバーにわたるキャッシュの読み取りおよび書き込み。各フロントエンドサーバーは独自のキャッシュを備えており、ほかのキャッシュにあるデータは認識していません。

• 常に同じサーバーにログインするとはかぎらないユーザーを処理する機能。このようなユーザーの場合は、各サーバー上のキャッシュに別の LDAP データが生成されます。