test

Sun Java System Communications Services 6 2005Q4 配備計画ガイド

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

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

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

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

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

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

マスター / スレーブ LDAP 構成

マスター / スレーブ LDAP 構成には、1 つのマスター (ルート) ディレクトリサーバーと、1 つ以上のスレーブ (コンシューマまたはレプリカ) ディレクトリサーバーが含まれます。Calendar Server からマスター 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 データキャッシュデータベースで実現可能な機能は、次のとおりです。

LDAP データキャッシュの制限

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

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

LDAP データキャッシュを設定するには、 ics.conf ファイル内の対応するパラメータを設定します。詳細については、『Sun Java System Calendar Server 6 2005Q4 Administration Guide』を参照してください。

注意 – 注意 –

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