Sun Java System Calendar Server 6.3 管理ガイド

5.1 Calendar Server バージョン 6.3 での CLD プラグインの基礎的な情報

この節では、CLD プラグインを実際に有効化および設定する前に理解しておく必要がある、概要および基礎的な情報を提供します。

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

5.1.1 Calendar Server バージョン 6.3 での CLD プラグインの概要

カレンダ検索データベース (CLD) プラグインは単一カレンダインスタンス用の多数のバックエンドサーバーにユーザーカレンダとリソースカレンダを分散することによって、カレンダデータベースの水平方向のスケーラビリティーを提供します。複数のバックエンドサーバーにカレンダデータベースを配布している場合、Calendar Server は CLD プラグインを使用してカレンダが実際に格納されているサーバーを特定します。

Calendar Server は、DWP (データベースワイヤプロトコル) を使用してバックエンドサーバー上のカレンダデータにアクセスします。DWP は csdwpd サービスとして実行される内部プロトコルで、カレンダデータベースのネットワーク機能を提供します。

5.1.2 Calendar Server バージョン 6.3 での CLD プラグインのしくみ

Calendar Server は、バックエンドサーバー上のカレンダデータに次のようにアクセスします。

エンドユーザーが Communications Express を使用してカレンダにアクセスすると、CLD プラグインはカレンダの calid から userid を取り出し、LDAP ディレクトリデータベースまたは CLD データキャッシュ (有効な場合) でカレンダの所有者を検索します。フロントエンドのマシンを設定する方法については、「CLD 用にフロントエンドサーバーを設定するには」を参照してください。
カレンダの所有者が特定されると、プラグインはその icsDWPHost LDAP 属性の値を使用してカレンダが存在するバックエンドサーバーのホスト名を決定します。このホスト名は、DNS (ドメイン名サービス) によって有効な IP アドレスに解決する必要があります。
Calendar Server は、ホスト名を使用して、DWP (データベースワイヤプロトコル) でバックエンドサーバー上のカレンダデータにアクセスします。
Calendar Server は、ユーザーがログインしているサーバーに DWP でカレンダデータを送信するため、そのデータをユーザーインタフェースで表示できます。

ヒント –

サイトで CLD プラグインを使用している場合、同じユーザー用に作成されたすべてのカレンダが、LDAP ユーザーエントリの icsDWPHost LDAP 属性によって指定されているのと同じバックエンドサーバーに格納される必要があります。別のバックエンドサーバーにカレンダを作成しようとすると、Calendar Server はエラーを返します。

5.1.3 Calendar Server バージョン 6.3 での CLD プラグインでサポートされる構成

ここでは、CLD プラグインについての概要を説明します。

CLD プラグインは、次の Calendar Server 構成をサポートしています。

ヒント –

すべての設定において、フロントエンドとバックエンドの各サーバーは、次の条件を満たす必要があります。

同じハードウェアプラットフォーム上にある
同じオペレーティングシステムを稼動している
パッチを含め、同じリリースの Calendar Server を稼動している
DWP ポートに同じポート番号を使用している (service.dwp.port パラメータ)。デフォルトのポート番号は 59779 です。

5.1.3.1 Calendar Server バージョン 6.3 での複数のフロントエンドサーバーと複数のバックエンドサーバー

図 5–1 は、1 つの Calendar Server インスタンスが稼動する 2 つのフロントエンドサーバーと 2 つのバックエンドサーバーを示しています。必要に応じて 3 つ以上のフロントエンドまたはバックエンドサーバーを導入することもできます。

この構成では、サーバーをファイアウォールで保護し、LDAP データベースとカレンダデータベースへのアクセスを制限することができます。カレンダデータベースは 2 つのバックエンドサーバーに分散されます。

フロントエンドサーバーは CPU を多用します。ほとんどの CPU 時間は、エンドユーザーへのカレンダデータの表示に使用されます。バックエンドサーバーはディスクを多用します。ほとんどの CPU 時間は、カレンダデータベースへのアクセスに使用されます。

構成の詳細については、「5.2 CLD および DWP 用の Calendar Server の設定」を参照してください。

図 5–1 複数のフロントエンドサーバーと複数のバックエンドサーバー

これは、フロントエンドサーバーとバックエンドサーバーが複数あるシステムの例を示しています。

5.1.3.2 Calendar Server バージョン 6.3 でフロントエンドサーバーとバックエンドサーバーの両方の機能を持つ複数のマシン

図 5–2 は、フロントエンドサーバーとバックエンドサーバーの両方の機能を持つ 3 つのマシンを示しています。各マシンは、1 台のカレンダデータベースに接続されています。この構成では、カレンダを物理的に分散することができます。カレンダの所有者 (エンドユーザー) は、所有しているカレンダが格納されているマシンにログインします。構成の詳細については、「フロントエンドサーバーとバックエンドサーバーを同じマシンに設定するには」を参照してください。

図 5–2 フロントエンドサーバーとバックエンドサーバーの両方の機能を持つ複数のマシン

この図は、フロントエンドサーバーとバックエンドサーバーの両方の機能を持つマシンの例を示しています。

5.1.4 Calendar Server 6.3 のストレージ要件の簡単なサイジング式

ここでは、メディア使用状況プロファイルに基づいていくつかの簡単な数式を使った簡単なサイジング式について説明します。これによって、必要なバックエンドサーバー数とフロントエンドサーバー数、およびストレージの容量を算出できます。

この節の内容は次のとおりです。

5.1.4.1 Calendar Server 6.3 配備でのメディア使用状況プロファイルの定義

ここでは大まかに、次のような状況を想定します。

すべてのクライアントはWeb クライアントである。

したがって、入力として使用されるのは、次の要素のみです。ユーザー総数と同時並行の割合。
平均的なサイズのカレンダの予定のサイズは 5K である。
各ユーザーが、1 週間につき 10 の予定または仕事を作成する。
CPU 利用率は 80%。
900 MHz のCPU。
各 CPU に 1G バイトの RAM を搭載。
2 年分のカレンダデータがシステムに保存されている。
ストレージには 6 つのホットバックアップコピーがある。

5.1.4.2 フロントエンドCPU の数

数式は次のとおりです。

CPU 数 = 並行ユーザー数 / 4800

5.1.4.3 バックエンドCPU の数

数式は次のとおりです。

CPU 数 = 設定済みの 500,000 ユーザーにつき 4 CPU

5.1.4.4 必要なストレージの容量

数式は次のとおりです。

1 ユーザーあたりのストレージの容量 = 電子メール 100 件 / 週 × 52 週 / 年 × 5K / メール × オンラインでデータを維持する年数 x オンラインのコピー数 (5 バックアップ + 1 作業コピー) = 100*52*5K*2*(5+1) = 1 ユーザーあたり 65M バイトのストレージ。

つまり、2.6M バイト / ユーザー / 年 / オンラインコピー。

注 –

最終的な数字は、オンラインで維持するホットバックアップとアーカイブバックアップの数によって決まります。この例で使用する数は、バックアップコピー 5 つです。