Calendar Server の考慮事項

Calendar Server は次の 5 つの主要サービスから構成されています。

• HTTP サービス (cshttpd)。HTTP 要求を待機します。HTTP サービスはユーザー要求を受け取り、データを呼び出し元に返します。

• 管理サービス (csadmind)。Calendar Server のそれぞれのインスタンスに必要とされます。管理サービスは Calendar Server の認証および管理を 1 ヵ所で行い、また、ほとんどの管理ツールを提供します。

• 通知サービス (csnotify)。電子メールまたは予定通知サービスのいずれかを使用して、予定および作業の通知を送信します。

• 予定通知サービス (enpd)。予定およびアラーム通知のブローカとして機能します。

• 分散データベースサービス (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 または Veritas のような HA ソリューションに適したシステムではありません。さらに、そのようなソリューションを使用する際のハードウェアの追加や管理オーバーヘッドにより、HA の Calendar Server フロントエンドへの配備のコストと時間がかかります。

本来の HA ソリューションを保証する Calendar フロントエンドの唯一の構成は、Messaging Server MTA ルーターを含む同じホストに Calendar フロントエンドを配備している場合です。ただし、この構成でも、そのようなソリューションのオーバーヘッドについては、利点がわずかなことからして、注意深く比較検討する必要があります。

Calendar Server フロントエンドのハードウェアの適切な選択は、シングルプロセッササーバーまたはデュアルプロセッササーバーです。プロセッサごとに Calendar Server cshttpd プロセスのインスタンスを 1 つ配備します。そのような配備によってコスト効率の良いソリューションが提供され、一定レベルの初期のクライアント並行性機能から開始し、ピーク使用率レベルがわかるにつれ、既存の構成にクライアントセッション機能を追加していくことができます。

複数のフロントエンドを配備する場合、フロントエンドサービス全体に負荷を分散するにはスティッキー接続や持続的接続を備えるロードバランサが必要です。

Communications Express は 2 つのプロセッサを超えては拡大されません。以前に Calendar Server で説明した同じハードウェアの選択肢が、Communications Express の配備にも適用されます。

Calendar Server バックエンド サービスは、リソースの消費で十分にバランスが取れているので、CPU あるいはディスクまたはネットワークなどの I/O のいずれにおいても、ボトルネックが形成されるという証拠はありません。このため、バックエンドのハードウェアな適切な選択は、1 つのストライプボリュームを備える SPARC サーバーになります。そのようなマシンはピーク時の大量のカレンダ負荷に対してかなりの容量を提供します。

要件の中に高可用性がある場合、バックエンドには持続的データが含まれているので、Calendar Server バックエンドを Sun Cluster で配備するのが妥当です。

フロントエンドおよびバックエンドの Calendar Server ホストの両方を持つ構成では、すべてのホスト上で次のソフトウェアが動作している必要があります。

• 同じオペレーティングシステム

• 同じリリースの Calendar Server (パッチやホットフィックスのリリースを含む)