test

Sun Java System Communications Services 6 2005Q4 配備計画ガイド

パート III Calendar Server の配備

この部には、次の章があります。

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

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

この章には、次の節があります。

Calendar Server の概要

Sun Java System Calendar Server (旧称 SunTM ONE Calendar Server) は、高性能な、インターネット標準ベースのカレンダサーバーで、中規模および大規模な企業から、さらに非常に大規模な電気通信およびインターネットのサービスプロバイダまで各ユーザーの必要に対応したスケーラビリティーを考慮し設計されています。ネイティブな Web ブラウザインタフェースまたはコネクタを使用して、Microsoft Outlook などの他のカレンダクライアントに接続することで Calendar Server は、家庭または職場のコンシューマにグループスケジュール機能および個人用のカレンダ機能を提供すると同時に、インターネットを介して他のユーザーとのカレンダ情報の共有を可能にします。ユーザーインタフェース (UI) をカスタマイズして、電子商取引用の Web リンク、バナー広告、ロゴ、またはカレンダサーバーユーザーのブランドなどを含めることができます。

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

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

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

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

Calendar Server の概念の詳細については、『Sun Java System Calendar Server 6 2005Q4 Administration Guide』を参照してください。

Calendar Server 配備の設計

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

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

Calendar Server やその他の Java Enterprise System コンポーネントの配備プロセスの詳細については、『Sun Java Enterprise System 2005Q4 Deployment Planning Guide』を参照してください。

Calendar Server の配備目的

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

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

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

Calendar Server 配備チーム

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

Calendar Server のエンドユーザー

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

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

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

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

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

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

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

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

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

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

この章には、次の節があります。

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

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

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

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

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

Calendar Server サービスの詳細については、『Sun Java System Calendar Server 6 2005Q4 Administration Guide』を参照してください。

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

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

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

Sun Java System Access Manager (リリース 2003Q4 (6.1) 以降) には次の機能があります。

これらのトピックの詳細については、『Sun Java System Calendar Server 6 2005Q4 Administration Guide』を参照してください。

Access Manager は、Calendar Server が稼働しているサーバーで実行することも、リモートサーバーで実行することもできます。

エンドユーザーは、2 つの Web ユーザーインタフェース (UI) の 1 つ、つまり Sun Java System Calendar Express または Sun Java System Communications Express のいずれかを使用して、クライアントマシンから Calendar Server に接続します。これらのインタフェースの使い方については、各インタフェースのオンラインヘルプを参照してください。

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

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

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

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

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

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

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

Calendar Server サービスの詳細については、『Sun Java System Calendar Server 6 2005Q4 Administration Guide』を参照してください。

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

Access Manager (リリース 6.1 (リリース 6 2003Q4) 以降) を使用して、シングルサインオン (SSO) の実装、Sun Java Enterprise System LDAP スキーマ 2 の使用、ホスト (仮想) ドメイン、ユーザー、グループ、組織、リソース、ロールのプロビジョニングと管理を行うことができます。

エンドユーザーは、2 つの Web ユーザーインタフェース (UI) の 1 つ、つまり Sun Java System Calendar Express または Sun Java System Communications Express のいずれかを使用して、クライアントマシンから Calendar Server に接続します。これらのインタフェースの使い方については、各インタフェースのオンラインヘルプを参照してください。

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

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

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

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

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

Calendar Server サービスの詳細については、『Sun Java System Calendar Server 6 2005Q4 Administration Guide』を参照してください。

注 –

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

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

Access Manager (リリース 6.1 (リリース 6 2003Q4) 以降) を使用して、シングルサインオン (SSO) の実装、Sun Java Enterprise System LDAP スキーマ 2 の使用、またはホスト (仮想) ドメイン、ユーザー、グループ、組織、リソース、ロールのプロビジョニングと管理を行うことができます。

エンドユーザーは、2 つの Web ユーザーインタフェース (UI) の 1 つ、つまり Sun Java System Calendar Express または Sun Java System Communications Express のいずれかを使用して、クライアントマシンから Calendar Server に接続します。これらのインタフェースの使い方については、各インタフェースのオンラインヘルプを参照してください。

第 18 章 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 の管理範囲外のものです。ディレクトリサーバーのパスワードポリシーについては、『Sun Java System Directory Server 5 2005Q1 Deployment Plannning Guide』を参照してください。

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

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 2005Q4 Administration Guide』を参照してください。

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

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

この章には、次の節があります。

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

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

スケーラブルな 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 ホストの両方を持つ構成では、すべてのホスト上で次のソフトウェアが動作している必要があります。

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

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

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

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

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

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

マスター / スレーブ LDAP 構成

マスター / スレーブ LDAP 構成には、1 つのマスター (ルート) ディレクトリサーバーと、1 つ以上のスレーブ (コンシューマまたはレプリカ) ディレクトリサーバーが含まれます。Calendar Server からマスター 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 データキャッシュデータベースで実現可能な機能は、次のとおりです。

LDAP データキャッシュの制限

LDAP データキャッシュで実現不可能な機能は、次のとおりです。

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

LDAP データキャッシュを設定するには、 ics.conf ファイル内の対応するパラメータを設定します。詳細については、『Sun Java System Calendar Server 6 2005Q4 Administration Guide』を参照してください。

注意 – 注意 –

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

第 20 章 Calendar Server のインストール前の考慮事項について

この章では、Calendar Server のインストール前に考慮が必要な事項について説明します。

この章には、次の節があります。

Calendar Server のインストール考慮事項

Calendar Server のインストールと設定は、以前の Calendar Server リリース (2003Q4 以前のバージョン) に比べ大幅に変更されました。Calendar Server 用のスタンドアロンのインストーラはなくなりました。

まだ Calendar Server をインストールしていない場合は、Sun Java Enterprise System インストーラを使用して、2005Q4 バージョンを取得する必要があります。このインストーラを使用すると、他の Sun Java System コンポーネント製品およびパッケージもインストールできます。Java Enterprise System インストーラについては、『Sun Java Enterprise System 2005Q4 Installation Guide for UNIX』を参照してください。

Calendar Server 6 2003Q4 から Calendar Server 6 2005Q4 にアップグレードする場合のアップグレードプロセスについては、『Sun Java Enterprise System 2005Q4 アップグレードガイド』の「Java Enterprise System 2003Q4 からのアップグレード」で説明されています。

Calendar Server の旧バージョン (バージョン 5.x まで) からの移行については、『Sun Java System Calendar Server 6 2005Q4 Administration Guide』の第 4 章「Database Migration Utilities」を参照してください。

5.x 以降のバージョンからの移行については、Sun サポート担当者に連絡してください。

設定が必要な Calendar Server コンポーネント

Calendar Server ソフトウェアをインストールする際、Java Enterprise System インストーラは Calendar Server パッケージをすべてインストールします。 ついで、Calendar Server 設定プログラムを使い、適切な Calendar Server コンポーネントを Calendar ホストに設定します。

次の表では、それぞれのタイプの Calendar ホストで、設定が必要なコンポーネントを示しています。

表 20–1 設定が必要な Calendar Server コンポーネント

構成対象の Calendar ホストのタイプ 

設定プログラムで選択されるコンポーネント 

フロントエンド 

HTTP サービスおよび管理サービス 

バックエンド 

通知サービス、予定通知サービス、分散データベースサービス、および管理サービス 

分散データベースサービス (csdwpd) は、バックエンドサーバー、つまりカレンダデータベースのあるサーバーにのみ必要とされ、ユーザーアクセスサービス (cshttpd) を提供しません。これは、カレンダデータベースのないフロントエンドサーバーには必要とされません。csdwpd サービスを使用することで、同じ Calendar Server 設定内のフロントエンドとバックエンドのサーバーをリンクし、分散型のカレンダストアを形成することができます。

Calendar Server の管理者の計画

Calendar Server の管理者には、次の管理者が含まれます。

Calendar Server 管理者 (calmaster)

Calendar Server 管理者とは、ユーザー名とそれに関連付けられたパスワードの組み合わせのうち、Calendar Server の管理権限を付与されているユーザーのことです。たとえば、Calendar Server 管理者は Calendar Server サービスの起動と停止、ユーザーの追加と削除、カレンダの作成と削除などを実行できます。このユーザーは Calendar Server の管理権限を持ちますが、ディレクトリサーバーの管理権限を持つとは限りません。

Calendar Server 管理者のデフォルトのユーザー ID は calmaster ですが、Calendar Server の設定時に別のユーザーを指定することもできます。インストール後に別のユーザーを指定する場合は、ics.conf ファイルの service.admin.calmaster.userid パラメータの設定を変更します。

Calendar Server 管理者として指定するユーザー ID は、ディレクトリサーバー内の有効なユーザーアカウントである必要があります。Calendar Server の設定時に Calendar Server 管理者のユーザーアカウントがディレクトリサーバーに存在していない場合には、設定プログラムがアカウントを自動的に作成します。

ics.conf ファイルの Calendar Server 管理者用設定パラメータの完全なリストについては、『Sun Java System Calendar Server 6 2005Q4 Administration Guide』を参照してください。

Calendar Server ユーザーおよびグループ

Solaris システムでは、これらの特別なアカウントは Calendar Server の実行に使用されるユーザー ID とグループ ID を示しています。特別なアカウントが存在しないときは、設定プログラムによって自動的に作成されるデフォルト値 icsuser および icsgroup を使用してください。ただし、Calendar Server 設定プログラムの実行時に icsuser および icsgroup 以外の値を指定することもできます。これらの値は、それぞれ ics.conf ファイルの local.serveruid パラメータおよび local.servergid パラメータに格納されます。

スーパーユーザー (root)

Solaris ソフトウェアが稼働するマシン上では、Calendar Server をインストールするには superuser (root) としてログインするか、あるいは superuser になる必要があります。コマンド行ユーティリティを使用して superuser として実行し、Calendar Server を管理することもできます。ただし、一部のタスクについては、Calendar Server ファイルへのアクセスの問題を回避するために、superuser としてではなく icsuser および icsgroup (または選択した値) として実行することをお勧めします。

Calendar Server のホストしているドメインの計画

Calendar Server はホストしている (または仮想) ドメインをサポートしています。ホストしているドメインのインストールでは、各ドメインが Calendar Server の同じインスタンスを共有するため、1 つのサーバーに複数のドメインが存在できます。各ドメインはネームスペースを定義し、1 つのネームスペースではすべてのユーザー、グループ、リソースが一意です。各ドメインには、変更可能な属性とユーザー設定もあります。

ホストしているドメインのインストールおよび設定には、スキーマ 2 だけを使用してください。

ホストしているドメインをサーバーにインストールおよび設定するには、次の高レベルの手順を実行します。

  1. Directory Server をインストールおよび設定します。

  2. Web Server または Application Server をインストールおよび設定します。

  3. Access Manager をインストールおよび設定します。

    Access Manager とともに Delegated Administrator がインストールされます。

  4. Calendar Server をインストールします。

  5. comm_dssetup.pl スクリプトを実行します。

    このスクリプトの実行手順については、『Sun Java System Calendar Server 6 2005Q4 Administration Guide』の第 2 章「Directory Preparation Script (comm_dssetup.pl)」を参照してください。

  6. Communications Services Delegated Administrator を設定します。

    Communications Services Delegated Administrator ユーティリティの設定手順と使用手順については、『Sun Java System Communications Services 6 2005Q4 Delegated Administrator 管理ガイド』を参照してください。

  7. デフォルトドメインおよびサイト管理者 (calmaster ) を作成します。

    デフォルトドメインは commadmin の設定時に作成されます。ただし、ドメインエントリを変更して、Calendar または Mail サービスを追加する必要があります。また、サイトカレンダ管理者 (calmaster) を設定する必要があります。これらの 2 つのタスクの実行方法の手順については、『Sun Java System Calendar Server 6 2005Q4 Administration Guide』のパート II「Postinstallation Configuration」を参照してください。

  8. Calendar Server を設定します。

    csconfiguratior.sh プログラムの実行手順については、『Sun Java System Calendar Server 6 2005Q4 Administration Guide』の第 3 章「Calendar Server Configuration Program (csconfigurator.sh)」を参照してください。

  9. Calendar Server のホストしているドメインの設定パラメータを設定します。

    設定パラメータおよびその値のリストについては、『Sun Java System Calendar Server 6 2005Q4 Administration Guide』の「Hosted Domain Configuration」を参照してください。

  10. commadmin ユーティリティを使用して、ホストしているドメインをサイトに作成します。

  11. commadmin ユーティリティを使用して、ホストしているドメインにユーザーおよびリソースを配置します。

  12. Calendar Server サービスを起動します。

    手順については、『Sun Java System Calendar Server 6 2005Q4 Administration Guide』の「Starting and Stopping Calendar Server」を参照してください。

    注 –

    常時 Communications Services Delegated Administrator インタフェースを使用して、スキーマ 2 のプロビジョニングを行なってください。

    スキーマ 1 のプロビジョニングツールはホストしているドメインをサポートしていません。

Calendar Server のインストール後の設定

Calendar Server ソフトウェアをインストールしたら、その設定をする必要があります。この手順は、従来インストールプロセスの一部として行われましたが、現在インストーラから分離されています。

Calendar Server をインストールしたあと、次のように Calendar Server を設定する必要があります。

  1. Directory Server 設定スクリプト (comm_dssetup.pl) を実行し、Sun Java System Directory Server を設定します。

  2. Calendar Server 設定プログラム (csconfigurator.sh) を実行してサイト固有の要件を設定し、新しい ics.conf 設定ファイルを作成します。ics.conf ファイルのパラメータの説明については、『Sun Java System Calendar Server 6 2005Q4 Administration Guide』の「Configuration Parameters (ics.conf) File」を参照してください。

    comm_dssetup.pl スクリプトは /opt/SUNWcomds/sbin ディレクトリに、csconfigurator.sh ユーティリティは /opt/SUNWics5/cal/sbin ディレクトリに格納されています。

    Java Enterprise System インストーラおよび Calendar Server 設定ユーティリティ (csconfigurator.sh ) が実行しない、構成の設定や変更がいくつかあります。次の項目は手動で変更する必要があります。

    • DWP および CLD の設定: ics.conf ファイルを編集して、CLD キャッシュオプションを有効にしてください。このキャッシュがカレンダユーザーの DWP ホストサーバー情報を格納することで、LDAP ディレクトリサーバーに対する呼び出しを減らすことができます。

    • デフォルトのタイムゾーン:デフォルトのタイムゾーンがアメリカのニューヨークでない場合、 ics.conf ファイルを編集して変更してください。さらに、/opt/SUNWics5/cal/bin/html/default_user_prefs.xml ファイルも変更して、ics.conf ファイルと同期するようにする必要があります。

    • クライアント側のレンダリング: Calendar Server では、XSLT 処理をエンドユーザーのブラウザにダウンロードすることで、クライアント側のレンダリングを実行します。このため、Calendar Server が実行する必要のある処理は減少します。Calendar Server は、ブラウザが XSLT 処理のレンダリングに対応している場合にだけ XSLT 処理をダウンロードします。現在のリリースでは、この機能は Internet Explorer 6.0 以降だけに適用されます。ics.conf ファイルを編集して、クライアント側のレンダリングへのこのようなパフォーマンスの改善を行なってください。

    • tmpfs の設定:tmpfs の設定を編集してパフォーマンスを向上させてください。

    これらの変更の詳細については、『Sun Java System Calendar Server 6 2005Q4 Administration Guide』を参照してください。