Sun Java Communications Suite 5 配備計画ガイド

パート III Calendar Server の配備

次の章で構成されています。

第 15 章 Calendar Server ソフトウェアの紹介

この章では、Sun Java System Calendar Server の概要、Calendar Server の配備が役立つビジネス上の理由、および配備プロセスについて説明します。

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

Calendar Server の概要

Sun Java System Calendar Server は、高性能な、インターネット標準ベースのカレンダサーバーで、中規模および大規模な企業から、さらに最大級の電気通信およびインターネットのサービスプロバイダに至るまで、顧客のニーズに応じたスケーラビリティーを考慮して設計されています。Web ブラウザインタフェースまたはコネクタを使用して、Microsoft Outlook などのほかのカレンダクライアントに接続することで Calendar Server は、家庭または職場のコンシューマにグループスケジュール機能および個人用のカレンダ機能を提供すると同時に、インターネットを介してほかのユーザーとのカレンダ情報の共有を可能にします。

Calendar Server は、オープンで相互運用可能かつ高性能な、業界最高レベルの時間管理およびリソース管理ソリューションです。そのスケーラビリティー、パフォーマンス、信頼性によって、ほかのソリューションに比べて低い総所有コストで、必要な機能を得ることができます。iCalendar 標準のネイティブサポートによって、ユーザーは簡単にインターネットで共有できる形式で予定をスケジュールすることができます。Calendar Server は次のような標準規格とプロトコルを採用しています。

Internet Calendaring (iCalendar)
iCalendar Transport-Independent Interoperability Protocol (iTIP)
iCalendar Message-based Interoperability Protocol (iMIP)
XML (eXtensible Markup Language)
LDAP（Lightweight Directory Access Protocol）
HyperText Transport Protocol (HTTP)

Calendar Server のアーキテクチャーは、垂直方向 (システムごとの CPU の数を増大させる) と水平方向 (ネットワークにサーバーを追加する) の両方向で、柔軟性に富み、拡張可能で、スケーラブルです。その結果、Calendar Server は、さまざまなニーズに対応した設定が可能なサーバーから構成されるシステムと見なすことができます。スタンドアロンのカレンダサーバーとして単独で使用することもでき、さまざまなサービスをサーバー間で重複または分割させる、多くのインスタンスで設定することもできます。

Calendar Server は、プラグインを利用して外部のサービスを取得します。さらに、Calendar Server は、LDAP ベースおよび ID ベースの配備もサポートしており、Sun Java System AccessManager、Sun Java System Portal Server、および Sun Java System Instant Messaging と統合して追加の機能を提供します。

Calendar Server は次の利点を提供します。

グループスケジュール機能、空き時間 - 予定ありの検索、および企業のディレクトリの検索
会議室、プロジェクタ、およびほかのリソースのリソーススケジュール機能
XML または iCalendar 形式で配信される標準ベースの予定およびカレンダデータフィードのサポート。これによって通信機能が強化され、商取引リンクやバナー広告から新しい収入の可能性が提供される
ほかのディレクトリサービス用の API を含む、ネイティブ LDAP のサポート
Connector to Microsoft Outlook のサポート
ホストしているドメインのサポート。コマンド行ツールや GUI ツールによるこれらのドメインの管理も含む
システム管理、オンラインのバックアップと復元、およびデータベース全体のバックアップと復元の簡略化
仕事、家族、友人などの複数のカレンダのサポート
公開および非公開のカレンダのサポートのほか、公開、非公開、および機密の個々の予定のサポート
選択した受信者にアポイント、出席依頼、およびアラームの電子メール通知が自動的に送信され、Sun Java System Instant Messaging との統合でポップアップアラームが自動的に提供される
各カレンダで複数の所有者がサポートされ、プロジェクトチームやコミュニティーグループでコミュニケーションが簡単になり生産性が向上する
一次所有者の代わりに行使する他者にカレンダの所有権を委託する機能
カレンダの日次、週次、月次、および年次の各ビューのサポート
スケーラブルで、ネットワーク化された、サーバー間、クライアントサーバーアーキテクチャーによって、何十万ものユーザーをサポート
Secure Sockets Layer (SSL) 暗号化、LDAP 認証、認証プラグイン、および Access Manager でアイデンティティー対応のシングルサインオン (SSO) をサポート
統合された個人用アドレス帳と電子メールの機能
カレンダの階層化表示のサポート。これによってユーザーは 2 つ以上のカレンダを 1 つの表示に統合でき、コミュニケーションや生産性を向上することができる
予定や作業での添付ファイルのサポート
LDAP グループのサポート。スタティックグループ、入れ子のグループ、ダイナミックグループを含む

Calendar Server の概念の詳細については、『Sun Java System Calendar Server 6.3 管理ガイド』を参照してください。

Calendar Server 配備の設計

配備プロセスは、次の基本フェーズから構成されており、ソリューションライフサイクルと呼ばれます。

ビジネス要件の分析
技術要件の分析
論理アーキテクチャーの設計
配備アーキテクチャーの設計
配備の実行
配備の運用

配備フェーズは固定的なものではなく、配備プロセスは反復して行われます。

Calendar Server の配備目的

Calendar Server の配備計画を開始する前に、次のことを確認してください。

組織が Calendar Server を配備するのはなぜでしょうか

次のようにいくつかの理由が考えられます。

コストの削減:ユーザーごとの総所有コストが市販されているほかのカレンダ製品を使用するより低くなります。
生産性の向上:カレンダユーザーは、自分の予定や作業を管理できるほか、組織内のほかの職員との会議や約束を予定することができます。また、ユーザーはカレンダグループと、会議室や機器などのリソースを管理できます。さらに、カレンダをモバイルデバイスや Microsoft Outlook と同期させることもできます。
スケーラビリティーおよび可用性の向上:Calendar Server は垂直と水平の両方向で拡大縮小します。組織が拡大すると、サーバーをアップグレードしたり、さらにサーバーを追加したりすることによって簡単に設定をアップグレードできます。
高可用性 (HA) 設定:Sun Cluster ソフトウェアとの統合によって、Calendar Server で高可用性サービスが行えるように設定できます。ソフトウェアやハードウェアの障害が発生すると、Calendar Server は二次サーバーへフェイルオーバーします。

Calendar Server 配備チーム

通常、Calendar Server の配備には、それぞれが異なる役割と責任を受け持つ何人かの人員が必要です。小規模な組織では、1 人でいくつかの役割を兼任することがあります。考慮すべき役割の中には次のものがあります。

プログラムマネージャーは、Calendar Server 配備全体を監督し、その成功や失敗に責任を持ちます。
Calendar Server 管理者は、Calendar Server を管理するための毎日の管理業務を行い、さらに Calendar Server のインストールやアップグレードの責任者となる場合もあります。
パフォーマンスエンジニアは、試験的配備および本稼働における配備の Calendar Server のパフォーマンスをテストおよび監視し、配備条件を満たしているかを確認します。
開発エンジニアリングでは、Calendar Server のアプリケーションやプラグインを記述し、必要に応じて、Calendar Server のユーザーインタフェース (UI) をカスタマイズします。
マニュアルスペシャリストは、管理者やエンドユーザー向けにカスタマイズされたあらゆるマニュアルを執筆します。
教育およびトレーニングでは、実務講習と教材を開発します。
サポートスペシャリストは、試験的配備および本稼働における配備の両方をサポートします。

Calendar Server のエンドユーザー

エンドユーザーは、Communications Express Web クライアント、または Sun Java System Connector for Microsoft Outlook を使用することによって Calendar Server に接続できます。

サイトのエンドユーザーについて、次のことを確認します。

サイトには、全部で何人の Calendar Server のエンドユーザーがいますか。
エンドユーザーはどのようにして Calendar Server に接続しますか。Communications Express を使用しますか。Microsoft Outlook を使用しますか。それとも両方のクライアントを組み合わせますか。
地理的な場所はいくつ含まれていますか。エンドユーザーはすべて同じまたは違うタイムゾーンにいますか。
エンドユーザーは、毎日、同じ時間に Calendar Server にログインしますか。
配備では、ピーク使用時のアクティブなエンドユーザーは何人いますか。
エンドユーザーベースはどのくらいの速さで拡張しますか。
Calendar Server エンドユーザーに特有のパフォーマンス要件は何ですか。
シングルサインオン (SSO) 要件は何ですか。
ユーザーの中に、以前のバージョンの Calendar Server から移行しているユーザーがいますか。
エンドユーザーは Communications Sync Software の使用を計画していますか。
サイトにプロキシサーバーの使用を計画していますか。
サイトに負荷分散機能の使用を計画していますか。

必要とされる Calendar Server エンドユーザーのパフォーマンス

エンドユーザーに特有のパフォーマンス要件は何でしょうか。次に例を示します。

どのくらいのエンドユーザーの応答時間が許容されますか。
ピークロード時に予想されるパフォーマンスの低下を許容できますか。

配備で使用することを計画しているのはどのような構成ですか。Calendar Server の構成シナリオには、次のものが含まれます。

1 つの Calendar Server インスタンス
単一のフロントエンドサーバーと単一のバックエンドデータベースサーバー
LDAP CLD プラグインを用いる複数のバックエンドデータベースサーバーを持つ複数のフロントエンドサーバー
LDAP CLD プラグインによる複数のフロントエンド/バックエンドサーバー
高可用性 (HA) 構成

複数のフロントエンドサーバーの設定を計画している場合、どのようにエンドユーザーの分散を計画するでしょうか。

複数のバックエンドデータベースサーバーの設定を計画している場合、どのようにデータベースの分散を計画するでしょうか。たとえば、サーバーを地理的に分散するなどの方法があります。

どのような拡張計画があるでしょうか。フロントエンドとバックエンドの両方についてはどうでしょうか。

第 16 章 Calendar Server アーキテクチャーの開発

この章では、3 つの基本的な Calendar Server 配備アーキテクチャーについて説明しています。それらは使用しているサイトに特有の要件に応じて変更することができます。

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

単一サーバー Calendar Server アーキテクチャー

図 16–1 に、単一サーバーアーキテクチャーを示します。この配備では、すべての Calendar Server サービス (プロセス) が、1 つのサーバーの 1 つの CPU (プロセッサ) または複数の CPU で稼働します。Directory Server と Access Manager のプロセスは、同じサーバー上でも異なるサーバー上でも実行できます。

図 16–1 単一サーバー Calendar Server アーキテクチャー

この図は、最小の単一サーバー Calendar Server 配備を示したものです。

単一サーバー上の Calendar Server インスタンスには、次のサービスが含まれます。

管理サービス (csadmind プロセス)。Calendar Server の起動と停止、カレンダユーザーまたはリソースの作成と削除、カレンダの取得と格納を行うコマンドなど、管理機能をサポートします。
HTTP サービス(cshttpd プロセス)。WCAP 要求を処理します。
予定通知サービス (enpd)。予定およびアラーム通知のブローカとして機能します。
バックアップサービス (csstored)。自動バックアップ (アーカイブバックアップとホットバックアップの両方) を実行します。

Calendar Server サービスの詳細については、『Sun Java System Calendar Server 6.3 管理ガイド』を参照してください。

最小構成ではデータベースは同じサーバーに配置されるため、カレンダデータベースが別のサーバーに配置されている環境でネットワーク機能を提供する DWP (データベースワイヤプロトコル) サービス (csdwpd プロセス) は必要ありません。

Calendar Server は、ユーザーの認証とユーザー設定の格納に使用するディレクトリサーバーを必要とします。通常は、Sun Java System Directory Server などの LDAP ディレクトリサーバーを使用します。ただし、Calendar Server API (CSAPI) を使用して、LDAP 以外のディレクトリサーバーを使用するためのプラグインを記述することもできます。この API については、『Sun Java System Calendar Server 6.3 WCAP Developer’s Guide』を参照してください。

ディレクトリサーバーは、Calendar Server が稼働しているサーバーに配置することも、リモートサーバーに配置することもできます。

スキーマ 2 配備のユーザー、グループ、リソース、ドメイン、および役割の管理用に Calendar Server が使用するツールは、Delegated Administrator です。Delegated Administrator は、個別にインストールして設定する必要があります。Delegated Administrator には、グラフィカルユーザーインタフェースとコマンド行ユーティリティー (commadmin ) の両方が用意されています。Delegated Administrator ユーティリティーの詳細については、『Sun Java System Delegated Administrator 6.4 管理ガイド』を参照してください。

スキーマ 1 配備では、Calendar Server には独自にバンドルされた、管理ユーティリティーのセットがあります。

Access Manager の使用、または Communications Suite 製品間の信頼できるサークルテクノロジによって、Communications Suite 製品に SSO を実装することができます。ユーザーは Access Manager にログインすると、すべてのサーバーで SSO が適切に設定されている限り、そのほかのサーバーにもアクセスできます。信頼できるサークルテクノロジでは、ユーザーは Messaging Server にログインすると、もう一度ログインしなくても、Calendar Server と Instant Messaging にもアクセスできます。SSO の信頼できるサークル実装の詳細については、『Sun Java System Calendar Server 6.3 管理ガイド』を参照してください。

2 層 Calendar Server アーキテクチャー

Calendar Server は、複数のフロントエンドサーバーとバックエンドサーバーに設定を分配することにより、スケーラビリティーを実現します。各サーバーでは、Calendar Server サービスを複数の CPU に分散させることもできます。

次の図に示す 2 層アーキテクチャーはネットワークフロントエンド / データベースバックエンド構成とも呼ばれ、ユーザーはフロントエンドサーバーにログインし、DWP (データベースワイヤプロトコル) サービス (csdwpd プロセス) を使用してバックエンドサーバーに接続します。カレンダデータベースは、バックエンドサーバーだけに接続されています。この図には示されていませんが、フロントエンドホストは、LDAP ディレクトリにアクセスする必要があります。

図 16–2 2 層 Calendar Server アーキテクチャー

この図は、高いスケーラビリティーを備えた Calendar Server 配備を示したものです。

フロントエンドサーバーとバックエンドサーバーの両方で実行される Calendar Server プロセスは次のとおりです。

ユーザーはロードバランサによってフロントエンドサーバーに誘導され、そこでログインします。それぞれのフロントエンドサーバーは次のサービスを必要とします。
- 管理サービス (csadmind プロセス)
- HTTP サービス (cshttpd プロセス)
- GSE データベース (csstored)
各バックエンドサーバーにはカレンダデータベースが接続されるため、各バックエンドサーバーは次のサービスを必要とします。
- 管理サービス (csadmind プロセス)
- バックアップサービス (csstored)
- 予定通知サービス (enpd および csnotifyd プロセス)
- カレンダデータベース用にフロントエンドサーバーにネットワーク機能を提供する DWP (データベースワイヤプロトコル) サービス (csdwpd プロセス)

この構成では、ユーザーはバックエンドサーバーにログインしないため、HTTP サービス (cshttpd プロセス) は必要ありません。

Calendar Server サービスの詳細については、『Sun Java System Calendar Server 6.3 管理ガイド』を参照してください。

スケーラブルな Calendar Server の構成には、ユーザーの認証とユーザー設定の格納に使用するディレクトリサーバーが必要です。

複数サーバーの 2 層 Calendar Server アーキテクチャー

複数のフロントエンドサーバーやバックエンドサーバーを使用した 2 層 Calendar Server アーキテクチャー (図 16–3) では、ユーザーは特定のサーバーにログインし、各サーバーはカレンダデータベースに接続されています。この構成では、カレンダを物理的に配布することができます。各サーバーにはカレンダが配置され、その所有者が Calendar Server にログインします。

図 16–3 複数サーバーの 2 層 Calendar Server アーキテクチャー

この図は、複数のフロントエンド / バックエンドサーバー用の Calendar Server 構成を示したものです。

このアーキテクチャーでは、どのサーバーもフロントエンドとしても、バックエンドとしても機能し、すべての Calendar Server サービス、つまり、管理サービス (csadmind プロセス)、HTTP サービス (cshttpd プロセス)、予定通知サービス (enpd プロセスおよび csnotifyd プロセス)、DWP (データベースワイヤプロトコル) サービス (csdwpd プロセス)、バックアップサービス (csstored) を必要とします。

Calendar Server サービスの詳細については、『Sun Java System Calendar Server 6.3 管理ガイド』を参照してください。

注 –

このアーキテクチャーでは、フロントエンドサービスをバックエンドサービスとは別のマシンに配置することも可能で、LDAP Calendar Lookup Database (CLD) を使用してフロントエンドがどのバックエンドからデータを取得する必要があるかを判別できます。詳細については、『Sun Java System Calendar Server 6.3 管理ガイド』を参照してください。

複数のフロントエンド / バックエンドサーバーの配備には、ユーザーの認証とユーザー設定の格納に使用するディレクトリサーバーが必要です。

第 17 章 Calendar Server セキュリティーの計画

この章では、Calendar Server 配備のさまざまなコンポーネントに対する計画を立案し、それらのコンポーネントを保護する方法について説明します。

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

Calendar Server セキュリティーの概要

セキュリティーは、今日のビジネスにおける日々の業務の中で重要な役割を果たしています。セキュリティーの侵害は、企業秘密を危険にさらす可能性だけでなく、停止時間、データの破損、および運用コストの増大を招く可能性もあります。Calendar Server は、ユーザーを盗聴、不許可の使用、または外部からの攻撃から保護するためにいくつかのセキュリティーレベルを提供します。基本レベルのセキュリティーは認証によるものです。Calendar Server は、デフォルトの設定で LDAP 認証を使用していますが、代替の認証方法が必要とされる場合、認証プラグインの使用もサポートしています。さらに、Access Manager と統合する場合、Calendar Server はそのシングルサインオン機能を利用することができます。

セキュリティーにはユーザーが本人であることを確かめる以上のことが関係しています。セキュリティーにはデータの機密保護を確実にすることも含まれます。このため、Calendar Server はログインまたはログインとデータに対して、SSL 暗号化技術の使用をサポートしています。つまり、Web クライアントからサーバーへ、ログインのみが暗号化される場合と、ログインを含むセッション全体が暗号化される場合があります。

Secure Remote Access との統合によっても SSL 暗号化が可能になりますが、その場合、プロキシゲートウェイを介することになります。さらに、ポータルゲートウェイとの統合により提供される URL 書き換え機能により、外部のエンティティーからさらに Calendar Server を隔離することが可能になります。Calendar Server は、ゲートウェイを介さない Calendar Server と直接接続ができないようにする、ポータルゲートウェイとともに配備することができます。この場合、すべての URL が書き換えられるため、Calendar Server の本当の URL の特定が困難になります。ユーザーが認証される場合でも、それによって、そのユーザーにほかのカレンダユーザーのデータへのアクセス権があるわけではありません。

カレンダドメインの中には、認証されたユーザーがほかの認証されたユーザーのカレンダデータへの不正にアクセスするのを防ぐ、ほかのセキュリティー層があります。セキュリティーの方策の 1 つに、Calendar Server アクセス制御のエントリによる方法があります。アクセス制御によって、カレンダユーザーは、自分のカレンダを閲覧可能な人、予定を自分のカレンダにスケジュール設定可能な人、自分のカレンダを変更可能な人、自分のカレンダから予定を削除可能な人を指定することができます。さらにアクセス制御によって、ユーザーは、自分の代わりに出席依頼に応答することのできる人、予定のスケジュール設定または変更ができる人、予定を削除できる人を選択することができます。最後に、アクセス制御を使用すると、ユーザーのドメインの範囲を調整できるので、あるドメインのユーザーが別のドメインのユーザーによる予定のスケジュール設定を防止したり、または可能にしたりすることができます。

ただし、アクセス制御に加えて、Calendar Server は、カレンダフロントエンドとデータベースバックエンドを分割する配備に対して、データベースプロトコルレベルにおける追加レベルのセキュリティーを提供します。このセキュリティーレベルは、DWP (データベースワイヤプロトコル) 認証と呼ばれ、ユーザーの名前とパスワードのペアを利用して DWP 接続を認証します。DWP 接続が認証されるためには、ユーザー名とパスワードのペアが、フロントエンドとデータベースバックエンドの両方で同じである必要があります。

セキュリティー戦略の監視

サーバーの監視は、セキュリティー戦略で重要な位置を占めます。システムに対する攻撃を識別するには、メッセージキューのサイズ、CPU の使用率、ディスクの空き容量、ネットワークの使用率を監視します。メッセージキューサイズの異常な増大やサーバー応答時間の異常な減少から、攻撃のいくつかは識別できます。また、通常とは異なるシステムの負荷パターンや接続についても調査します。ログを毎日チェックして、異常な活動がないか調べます。

カレンダユーザー認証の計画

ユーザー認証によって、ユーザーはカレンダクライアントを介してログインし、自分のカレンダ情報を取得できます。ユーザー認証の方法には次のものがあります。

プレーンテキストと暗号化されたパスワードによるログイン

ユーザー ID とパスワードは、LDAP ディレクトリに保存されます。「最小の長さ」のようなパスワードのセキュリティー基準は、ディレクトリのポリシー要件で決定されます。パスワードのセキュリティー基準は Calendar Server の管理範囲外のものです。ディレクトリサーバーのパスワードポリシーについては、Directory Server のマニュアルを参照してください。

http://docs.sun.com/app/docs/coll/1660.1

プレーンテキストパスワードと暗号化パスワードの両方のログインが使用可能です。

Secure Sockets Layer (SSL) による証明書ベースの認証

Calendar Server は SSL プロトコルを使用して、暗号化通信やクライアントとサーバーの証明書ベースの認証を行います。この節では、証明書ベースの SSL 認証について説明します。

SSL は公開鍵暗号法の概念に基づいています。TLS (Transport Layer Security) は SSL のスーパーセットとして機能しますが、名前が混同されて使われています。

SSL をサポートしているサーバーには、証明書、公開鍵、非公開鍵、証明書、鍵、およびセキュリティーデータベースが高レベルで必要となります。これにより、メッセージの認証、機密、完全性が確保されます。

SSL で認証するため、カレンダクライアントはサーバーと SSL セッションを確立し、ユーザーの証明書をサーバーに送信します。その後、サーバーが、提出された証明書の信頼性を評価します。証明書の信頼性が確認されると、そのユーザーは認証済みであるとみなされます。

認証に SSL を使用する場合は、Calendar Server のサーバー証明書を取得する必要があります。この証明書は、使用するサーバーの識別情報をクライアントやほかのサーバーに提供します。サーバーには複数のサーバー証明書を用意しておき、証明書自身を識別することができます。サーバーには、信頼できる認証局 (CA) の証明書を必要な数だけインストールして、クライアントの認証に使用できます。

SSL の詳細については、『Sun Java System Calendar Server 6.3 管理ガイド』を参照してください。

第 18 章 Calendar Server サービスの計画

この章では、Calendar Server サービスの計画について説明します。

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

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 (パッチやホットフィックスのリリースを含む) が動作している必要があります。

Calendar Server LDAP データキャッシュの計画

LDAP データキャッシュオプションを使うと、LDAP データのコミット直後にそのデータが利用可能になります。LDAP の設定によっては、(リモート) マスターサーバーに更新を参照した後、そのマスターサーバーからローカルの LDAP ディレクトリに更新をレプリケートする必要があります。このような種類の設定では、ローカルの LDAP サーバーのコミット済みデータが利用可能になるまでに遅延が生じる可能性があります。

LDAP データキャッシュを使えば、Calendar Server クライアントが正確な LDAP データにアクセスできるようになりますが、コミット済み LDAP データが利用可能になるまでに遅延が発生する可能性があります。たとえば、サイト上にマスター/スレーブ LDAP 構成が配備されており、Calendar Server がマスター LDAP ディレクトリにスレーブ LDAP ディレクトリサーバー経由でアクセスする仕組みになっている場合、遅延が発生します。

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

LDAP データキャッシュの使用に関する考慮事項

サイトで LDAP データキャッシュを設定すべきかどうかを決定するには、次のガイドラインに従います。

Calendar Server がマスター (またはルート) LDAPディレクトリサーバーに直接アクセスし、コミット済みLDAP データが利用可能になるまでの遅延が発生しない場合、LDAP データキャッシュを設定する必要はありません。
サイト上に「マスター/スレーブ LDAP 構成での LDAP データキャッシュの使用」が配備されており、Calendar Server がマスター LDAP ディレクトリにスレーブ LDAP ディレクトリサーバー経由でアクセスする仕組みになっている場合、コミット済み LDAP データが利用可能になるまでにいくらかの遅延が発生しますが、LDAP データキャッシュを設定すれば、エンドユーザーが最新データにアクセスできるようになります。

マスター/スレーブ LDAP 構成での LDAP データキャッシュの使用

マスター / スレーブ LDAP 構成には、1 つのマスター (ルート) ディレクトリサーバーと、1 つ以上のスレーブ (コンシューマまたはレプリカ) ディレクトリサーバーが含まれます。Calendar Server からマスター LDAP ディレクトリサーバーへのアクセスは、直接行うことも、スレーブディレクトリサーバー経由で行うことも可能です。

Calendar Server がマスター LDAP ディレクトリサーバーに直接アクセスする場合、LDAP データは正確であるはずなので、LDAP データキャッシュを設定する必要はありません。この場合、local.ldap.cache.enable パラメータがデフォルトの「no」に設定されていることを確認してください。
Calendar Server がマスター LDAP ディレクトリサーバーにスレーブディレクトリサーバー経由でアクセスする場合、LDAP データの変更結果は通常、LDAP レフェラル経由でマスターディレクトリサーバーに透過的に書き込まれたあと、そのデータが各スレーブディレクトリサーバーに複製されます。これにより、コミット済み LDAP データが利用可能になるまでに遅延が発生します。たとえば、Calendar Server がある LDAP データの変更をコミットしても、その新しいデータはある一定期間利用可能になりません。なぜなら、マスターディレクトリサーバーが各スレーブディレクトリサーバーを更新するのに一定の時間がかかるからです。後続の Calendar Server クライアント処理では、古い LDAP データが使用され、ユーザーに古いデータが表示されます。

遅延の影響を受ける LDAP 属性

スレーブディレクトリサーバーの更新遅延が短い場合 (ほんの数秒程度である場合)、クライアント側で大きな問題は生じません。しかしながら、その遅延が長い場合 (数分または数時間の場合)、その遅延時間の間、不正確な LDAP データがクライアント上に表示されてしまいます。

次の表は、マスター / スレーブ LDAP サーバー構成で Calendar Server がマスターLDAP ディレクトリサーバーにスレーブ LDAP ディレクトリサーバー経由でアクセスする場合に、遅延の影響を受ける LDAP 属性の一覧です。

表 18–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 キャッシュがあるため、遅延期間内に、ユーザーがあるキャッシュにログインしている間のアクティビティーについて、別のキャッシュは認識しません。

LDAP データキャッシュの設定

LDAP データキャッシュを設定するには、ics.conf ファイルに適切なパラメータを設定します。詳細については、『Sun Java System Calendar Server 6.3 管理ガイド』を参照してください。

注意 –

Calendar Server またはその稼働元のサーバーが正しくシャットダウンされなかった場合、ldap_cache ディレクトリ内のすべてのファイルを手動で削除してください。そうしないと、次回の再起動時にデータベースが破損し、問題が発生する可能性があります。

Calendar Server ドメインの計画

新しく Calendar Server をインストールする場合は、先にデフォルトのドメインを作成してから Calendar Server 設定スクリプトを実行する必要があります。デフォルトのドメインを作成するには、Delegated Administrator を使用してください。つまり、Delegated Administrator は、Calender Server の設定前に、インストールされて設定されている必要があります。