Sun Java Communications Suite 5 配備計画ガイド

Calendar Server LDAP データキャッシュの計画

LDAP データキャッシュオプションを使うと、LDAP データのコミット直後にそのデータが利用可能になります。LDAP の設定によっては、(リモート) マスターサーバーに更新を参照した後、そのマスターサーバーからローカルの LDAP ディレクトリに更新をレプリケートする必要があります。このような種類の設定では、ローカルの LDAP サーバーのコミット済みデータが利用可能になるまでに遅延が生じる可能性があります。

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

この節の内容は、次のとおりです。

LDAP データキャッシュの使用に関する考慮事項

サイトで LDAP データキャッシュを設定すべきかどうかを決定するには、次のガイドラインに従います。

Calendar Server がマスター (またはルート) LDAPディレクトリサーバーに直接アクセスし、コミット済みLDAP データが利用可能になるまでの遅延が発生しない場合、LDAP データキャッシュを設定する必要はありません。
サイト上に「マスター/スレーブ LDAP 構成での LDAP データキャッシュの使用」が配備されており、Calendar Server がマスター LDAP ディレクトリにスレーブ LDAP ディレクトリサーバー経由でアクセスする仕組みになっている場合、コミット済み LDAP データが利用可能になるまでにいくらかの遅延が発生しますが、LDAP データキャッシュを設定すれば、エンドユーザーが最新データにアクセスできるようになります。

マスター/スレーブ LDAP 構成での LDAP データキャッシュの使用

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

Calendar Server がマスター LDAP ディレクトリサーバーに直接アクセスする場合、LDAP データは正確であるはずなので、LDAP データキャッシュを設定する必要はありません。この場合、local.ldap.cache.enable パラメータがデフォルトの「no」に設定されていることを確認してください。
Calendar Server がマスター LDAP ディレクトリサーバーにスレーブディレクトリサーバー経由でアクセスする場合、LDAP データの変更結果は通常、LDAP レフェラル経由でマスターディレクトリサーバーに透過的に書き込まれたあと、そのデータが各スレーブディレクトリサーバーに複製されます。これにより、コミット済み LDAP データが利用可能になるまでに遅延が発生します。たとえば、Calendar Server がある LDAP データの変更をコミットしても、その新しいデータはある一定期間利用可能になりません。なぜなら、マスターディレクトリサーバーが各スレーブディレクトリサーバーを更新するのに一定の時間がかかるからです。後続の Calendar Server クライアント処理では、古い LDAP データが使用され、ユーザーに古いデータが表示されます。

遅延の影響を受ける LDAP 属性

スレーブディレクトリサーバーの更新遅延が短い場合 (ほんの数秒程度である場合)、クライアント側で大きな問題は生じません。しかしながら、その遅延が長い場合 (数分または数時間の場合)、その遅延時間の間、不正確な LDAP データがクライアント上に表示されてしまいます。

次の表は、マスター / スレーブ LDAP サーバー構成で Calendar Server がマスターLDAP ディレクトリサーバーにスレーブ LDAP ディレクトリサーバー経由でアクセスする場合に、遅延の影響を受ける LDAP 属性の一覧です。

表 18–1 遅延の影響を受ける Calendar Server LDAP 属性


操作	影響を受ける LDAP 属性
自動プロビジョニング	`icsCalendar、icsSubscribed、icsCalendarOwned、icsDWPHost`
カレンダグループ	`icsSet`
カレンダ作成	`icsCalendarOwned、icsSubscribed`
カレンダ登録	`icsSubscribed`
ユーザーオプション	`icsExtendedUserPrefs、icsFirstDay、icsTimeZone、icsFreeBusy`
カレンダ検索	`icsCalendarOwned`

エンドユーザーが常に最新の LDAP データにアクセスするようにするには、次の節「マスター / スレーブ遅延問題の解決」で説明する手順に従って LDAP データキャッシュを設定します。

マスター / スレーブ遅延問題の解決

マスター / スレーブ LDAP 構成の問題は、LDAP データキャッシュを使えば解決します。なぜなら、マスターディレクトリサーバーが各スレーブディレクトリサーバーを更新し終わっていなくても、Calendar Server クライアントに最新の LDAP データが提供されるようになるからです。

ユーザーが LDAP データキャッシュを有効にした場合、Calendar Server は、コミット済み LDAP データをキャッシュデータベース (ldapcache.db ファイル) に書き込みます。LDAP キャッシュデータベースはデフォルトで /var/opt/SUNWics5/csdb/ldap_cache ディレクトリに格納されますが、必要であれば、これを別の場所に設定してもかまいません。

クライアントがある単一ユーザーの LDAP データを変更した場合、Calendar Server はその変更データを LDAP キャッシュデータベース (とスレーブディレクトリサーバー) に書き込みます。後続のクライアント処理では、キャッシュデータベースから LDAP データが取得されます。こうしたデータ取得は、単一ユーザーに対する次の処理に適用されます。

ユーザーのログイン時の属性
ユーザーのオプション (カラースキームやタイムゾーンなど)
ユーザーのカレンダグループ
ユーザーのカレンダ登録リスト

したがって、LDAP データキャッシュデータベースで実現可能な機能は、次のとおりです。

単一システム上のプロセス間におけるデータ整合性の維持: このデータベースは、マルチプロセッサシステム上のすべての Calendar Server プロセスから利用可能です。
ユーザーセッションをまたがるデータの持続性: このデータベースは永続的であり、更新を必要としません。LDAP データキャッシュエントリの TTL (Time To Live) やデータベースクリーンアップ間隔を設定できます。

LDAP データキャッシュソリューションの制限

LDAP データキャッシュで実現不可能な機能は、次のとおりです。

複数エントリの一致が予想されるような検索におけるキャッシュ読み取り (特定の会議への出席者を検索する場合など)。このタイプの検索では、LDAP 遅延が発生します。たとえば、LDAP 検索オプションが有効になっており、かつ新しいカレンダが作成されてから遅延期間内にカレンダ検索が実行された場合、その新しいカレンダは検索結果に含まれません。
複数フロントエンドサーバーにまたがるキャッシュの読み書き。各フロントエンドサーバーはそれぞれ独自のキャッシュを持ち、ほかのキャッシュ内のデータにアクセスすることはありません。
常に同じサーバーにログインするとはかぎらないユーザーを処理する機能。各サーバーには専用の LDAP キャッシュがあるため、遅延期間内に、ユーザーがあるキャッシュにログインしている間のアクティビティーについて、別のキャッシュは認識しません。

LDAP データキャッシュの設定

LDAP データキャッシュを設定するには、ics.conf ファイルに適切なパラメータを設定します。詳細については、『Sun Java System Calendar Server 6.3 管理ガイド』を参照してください。

注意 –

Calendar Server またはその稼働元のサーバーが正しくシャットダウンされなかった場合、ldap_cache ディレクトリ内のすべてのファイルを手動で削除してください。そうしないと、次回の再起動時にデータベースが破損し、問題が発生する可能性があります。