Calendar Server のフロントエンドサービスとバックエンドサービスの計画

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

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

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

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

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

• 分散データベースサービス (csdwpd)。同じ Calendar Server システム内の複数のデータベースサーバー間でリンクを張り、分散型のカレンダストアを形成します。

• バックアップサービス (csstored)。自動バックアップ (アーカイブバックアップとホットバックアップの両方) を実行します。最初のバックアップはログファイルを使用したスナップショットであり、2 番目のバックアップは適用済みログファイルを使用したスナップショットです。このサービスは、start-cal コマンド実行時に自動的に起動されます。

スケーラブルな Calendar Server の配備の場合、フロントエンドシステムをバックエンドサーバーとともに配備することがあります。この場合、フロントエンドシステムにはプロセッサごとに cshttpd デーモンのインスタンスが 1 つと、単一の管理サービスが含まれます。バックエンドサーバーには、通知サービス、予定通知サービス、分散データベースサービス、および管理サービスのインスタンスが含まれます。カレンダデータベースは、1 台以上のバックエンドマシンに分散できます。これらのバックエンドマシンは、1 台のフロントエンドマシンに関連付けることができます。

Calendar バックエンドサービスには、通常、Calendar フロントエンドサービスの CPU の半数が必要とされます。Calendar フロントエンドシステムによってサービス品質をサポートするには、CPU 数の 2/3 前後をフロントエンドとして Calendar バックエンドシステムで使用する必要があります。

カレンダサービスをフロントエンドサービスとバックエンドサービスに分割することは、配備の初期の段階で考慮する必要があります。フロントエンドサービスとバックエンドサービスに別々のホスト名を割り当てることによって、カレンダサービスの機能をホストごとに分割するときに、変更が基本的には内部的に行われ、ユーザーが操作方法を変更する必要がないようにします。

通常、フロントエンドサービスのコンポーネントである Calendar Server HTTP プロセスは、CPU 時間を多く使用します。カレンダのピーク使用率を考慮して、予測されるピーク HTTP セッションに対応するため、十分なフロントエンドの処理能力を選択するようにします。通常、冗長性、つまり複数のフロントエンドホストを配備することによって、Calendar Server フロントエンドの使用可能性が向上します。フロントエンドシステムはカレンダの持続的データを保持しないので、Sun Cluster のような HA ソリューションに適したシステムではありません。さらに、そのようなソリューションを使用する際のハードウェアの追加や管理オーバーヘッドにより、HA の Calendar Server フロントエンドへの配備のコストと時間がかかります。Calendar Server による Communications Express の配備には、異なる特性があります。詳細については、Communications Express のマニュアルを参照してください。

本来の 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 ホストの両方を持つ構成では、すべてのホスト上で同じリリースの Calendar Server (パッチやホットフィックスのリリースを含む) が動作している必要があります。