LDAP データキャッシュオプションを使うと、LDAP データのコミット直後にそのデータが利用可能になります。LDAP ディレクトリサーバーの設定によっては、(リモート) マスターサーバーに更新を参照した後、そのマスターサーバーからローカルの LDAP ディレクトリに更新をレプリケートする必要があります。このような種類の設定では、ローカルの LDAP サーバーのコミット済みデータが利用可能になるまでに遅延が生じる可能性があります。
たとえば、サイト上にマスター / スレーブ LDAP 構成が配備されており、Calendar Server がマスター LDAP ディレクトリにスレーブ LDAP ディレクトリサーバー経由でアクセスする仕組みになっている場合、コミット済み LDAP データが利用可能になるまでにいくらかの遅延が発生しますが、LDAP データキャッシュを使えば、Calendar Server クライアントが正確な LDAP データにアクセスできるようになります。
この節では次の内容について説明します。
サイトで LDAP データキャッシュを設定すべきかどうかを決定するには、次のガイドラインに従います。
サイトの Calendar Server がマスター (またはルート) LDAP ディレクトリサーバーに直接アクセスし、コミット済み LDAP データが利用可能になるまでの遅延が発生しない場合、LDAP データキャッシュを設定する必要はありません。 local.ldap.cache.enable パラメータがデフォルトの「no」に設定されていることを確認してください。
サイト上に「マスター / スレーブ LDAP 構成」が配備されており、Calendar Server がマスター LDAP ディレクトリにスレーブ LDAP ディレクトリサーバー経由でアクセスする仕組みになっている場合、コミット済み LDAP データが利用可能になるまでにいくらかの遅延が発生しますが、LDAP データキャッシュを設定すれば、エンドユーザーが最新データにアクセスできるようになります。
マスター / スレーブ LDAP 構成には、1 つのマスター (ルート) ディレクトリサーバーと、1 つ以上のスレーブ (コンシューマまたはレプリカ) ディレクトリサーバーが含まれます。Calendar Server からマスター LDAP ディレクトリサーバーへのアクセスは、直接行うことも、スレーブディレクトリサーバー経由で行うことも可能です。
Calendar Server がマスター LDAP ディレクトリサーバーに直接アクセスする場合、LDAP データは正確であるはずなので、LDAP データキャッシュを設定する必要はありません。
Calendar Server がマスター LDAP ディレクトリサーバーにスレーブディレクトリサーバー経由でアクセスする場合、LDAP データの変更結果は通常、LDAP レフェラル経由でマスターディレクトリサーバーに透過的に書き込まれたあと、そのデータが各スレーブディレクトリサーバーに複製されます。
上記の 2 番目のタイプの構成では、コミット済み LDAP データがスレーブディレクトリサーバー上で利用可能になるまでにいくらかの遅延が発生するため、LDAP データが不正確になるという問題が発生する可能性があります。
たとえば、Calendar Server がある LDAP データの変更をコミットしても、その新しいデータはある一定期間利用可能になりません。なぜなら、マスターディレクトリサーバーが各スレーブディレクトリサーバーを更新するのに一定の時間がかかるからです。後続の Calendar Server クライアント処理では、古い LDAP データが使用され、ユーザーに古いデータが表示されます。
スレーブディレクトリサーバーの更新遅延が短い場合 (ほんの数秒程度である場合)、クライアント側で大きな問題は生じません。しかしながら、その遅延が長い場合 (数分または数時間の場合)、その遅延時間の間、不正確な LDAP データがクライアント上に表示されてしまいます。
次の表は、マスター / スレーブ LDAP サーバー構成で Calendar Server がマスターLDAP ディレクトリサーバーにスレーブ LDAP ディレクトリサーバー経由でアクセスする場合に、遅延の影響を受ける LDAP 属性の一覧です。
表 19–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 データキャッシュを設定するには、 ics.conf ファイル内の対応するパラメータを設定します。詳細については、『Sun Java System Calendar Server 6 2005Q4 Administration Guide』を参照してください。
Calendar Server またはその稼働元のサーバーが正しくシャットダウンされなかった場合、ldap_cache ディレクトリ内のすべてのファイルを手動で削除してください。そうしないと、次回の再起動時にデータベースが破損し、問題が発生する可能性があります。