マスター / スレーブ 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 データキャッシュを設定します。
- © 2010, Oracle Corporation and/or its affiliates