この章では、Calendar Server サービスの計画について説明します。
この章には、次の節があります。
Calendar Server は次の主な 6 つのサービスから構成されています。
HTTP サービス (cshttpd)。HTTP 要求を待機します。HTTP サービスはユーザー要求を受け取り、データを呼び出し元に返します。
管理サービス (csadmind)。Calendar Server のそれぞれのインスタンスに必要とされます。管理サービスは Calendar Server の認証および管理を 1 ヵ所で行い、また、ほとんどの管理ツールを提供します。
通知サービス (csnotify)。電子メールまたは予定通知サービスのいずれかを使用して、予定および作業の通知を送信します。
分散データベースサービス (csdwpd)。同じ Calendar Server システム内の複数のデータベースサーバー間でリンクを張り、分散型のカレンダストアを形成します。
バックアップサービス (csstored)。自動バックアップ (アーカイブバックアップとホットバックアップの両方) を実行します。最初のバックアップはログファイルを使用したスナップショットであり、2 番目のバックアップは適用済みログファイルを使用したスナップショットです。このサービスは、start-cal コマンド実行時に自動的に起動されます。ただし、インストール時には有効化されないため、このサービスが機能するように設定する必要があります。バックアップサービスを設定しなかった場合、このサービスが設定されていない旨の通知メッセージが、24 時間ごとに管理者に送信されます。
スケーラブルな Calendar Server の配備の場合、フロントエンドシステムをバックエンドサーバーとともに配備することがあります。この場合、フロントエンドシステムにはプロセッサごとに cshttpd デーモンのインスタンスが 1 つと、単一の管理サービスが含まれます。バックエンドサーバーには、通知サービス、予定通知サービス、分散データベースサービス、および管理サービスのインスタンスが含まれます。
認証および XML と XSLT の変換の 2 つは、多大な負荷を生じさせるのカレンダサービスのアクティビティです。サービス品質の要件を満たすために CPU を追加することができます。スケーラブルな環境の場合、このような負荷の高いアクティビティはフロントエンドシステムで実行され、サービス品質の要件に対応するために、個々のフロントエンドシステムに CPU を追加、またはフロントエンドシステムを追加できるようになっています。
上記は、Communications Express Calendar クライアントを使ってカレンダにアクセスする場合には当てはまりません。Communications Express は WCAP プロトコルを使用して Calendar Server データにアクセスするため、Calendar Server インフラストラクチャーは XML/XSLT 変換を行いません。Communications Express の配備の詳細については、パート V「Communications Express の配備」を参照してください。
Calendar バックエンドサービスには、通常、Calendar フロントエンドサービスの CPU の半数が必要とされます。Calendar フロントエンドシステムによってサービス品質をサポートするには、フロントエンドの CPU の 2/3 前後を Calendar バックエンドシステムで使用する必要があります。
カレンダサービスをフロントエンドサービスとバックエンドサービスに分割することは、配備の初期の段階で考慮する必要があります。フロントエンドサービスとバックエンドサービスに別々のホスト名を割り当てることによって、カレンダサービスの機能をホストごとに分割するときに、変更が基本的には内部的に行われ、ユーザーが操作方法を変更する必要がないようにします。
通常、フロントエンドサービスのコンポーネントである Calendar Server HTTP プロセスは、CPU 時間を多く使用します。カレンダのピーク使用率を考慮して、予測されるピーク HTTP セッションに対応するため、十分なフロントエンドの処理能力を選択するようにします。通常、冗長性、つまり複数のフロントエンドホストを配備することによって、Calendar Server フロントエンドの使用可能性が向上します。フロントエンドシステムはカレンダの持続的データを保持しないので、Sun Cluster のような HA ソリューションに適したシステムではありません。さらに、そのようなソリューションを使用する際のハードウェアの追加や管理オーバーヘッドにより、HA の Calendar Server フロントエンドへの配備のコストと時間がかかります。
本来の HA ソリューションを保証する Calendar フロントエンドの唯一の構成は、Messaging Server MTA を含む同じホストに Calendar フロントエンドを配備している場合です。ただし、この構成でも、そのようなソリューションのオーバーヘッドについては、利点がわずかなことからして、注意深く比較検討する必要があります。
Calendar Server フロントエンドのハードウェアの適切な選択は、シングルプロセッササーバーまたはデュアルプロセッササーバーです。プロセッサごとに Calendar Server cshttpd デーモンのインスタンスを 1 つ配備します。そのような配備によってコスト効率の良いソリューションが提供され、一定レベルの初期のクライアント並行性機能から開始し、ピーク使用率レベルがわかるにつれ、既存の構成にクライアントセッション機能を追加していくことができます。
複数のフロントエンドを配備する場合、フロントエンドサービス全体にロードを分散するにはスティッキ接続や持続的接続を備えるロードバランサが必要です。
Calendar Server バックエンド サービスは、リソースの消費で十分にバランスが取れているので、CPU あるいはディスクまたはネットワークなどの I/O のいずれにおいても、ボトルネックが形成されるという証拠はありません。このため、バックエンドのハードウェアな適切な選択は、1 つのストライプボリュームを備える SPARC サーバーになります。そのようなマシンはピーク時の大量のカレンダロードに対してかなりの容量を提供します。
要件の中に高可用性がある場合、バックエンドには持続的データが含まれているので、Calendar Server バックエンドを Sun Cluster で配備するのが妥当です。
フロントエンドおよびバックエンドの Calendar Server ホストの両方を持つ構成では、すべてのホスト上で次のソフトウェアが動作している必要があります。
同じオペレーティングシステム環境とバージョン (つまり、Solaris SPARC、Solaris x86、Linux Red Hat などをそれぞれ実行するシステムの混在は不可)。
同じリリースの Calendar Server (パッチやホットフィックスのリリースを含む)。
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 ディレクトリ内のすべてのファイルを手動で削除してください。そうしないと、次回の再起動時にデータベースが破損し、問題が発生する可能性があります。