この部には、次の章があります。
この章では、Sun Java System 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 は次のような標準規格とプロトコルを採用しています。
Internet Calendaring (iCalendar)
iCalendar Transport-Independent Interoperability Protocol (iTIP)
iCalendar Message-based Interoperability Protocol (iMIP)
Extensible Markup Language (XML)
Lightweight Directory Access Protocol (LDAP)
HyperText Transport Protocol (HTTP)
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) と統合して追加の機能を提供します。
Web ベースのグループスケジュール機能、空き時間 - 予定ありの検索、および企業のディレクトリの検索
XML ベースのカスタマイズ機能 (配色、ログイン、ユーザーインタフェース、ロゴ、ブランド設定など)
XML または iCalendar 形式で配信される標準ベースの予定およびカレンダデータフィードのサポート。これによって通信機能が強化され、商取引リンクやバナー広告から新しい収入の可能性が提供される
他のディレクトリサービス用の API を含む、ネイティブ LDAP のサポート
Microsoft Outlook などの追加カレンダクライアントへのコネクタ。これによって、クライアントは Calendar Server 上でスケジュール機能を実行することができる
ホストしているドメインのサポート
システム管理、オンラインのバックアップと復元、およびデータベース全体のバックアップと復元の簡略化
仕事、家族、友人などの複数のカレンダのサポート
公開および非公開のカレンダのサポートのほか、公開、非公開、および機密の個々の予定のサポート
カレンダの階層化表示のサポート。これによってユーザーは 2 つ以上のカレンダを 1 つの表示に統合でき、コミュニケーションや生産性を向上することができる
選択した受信者にアポイント、出席依頼、およびアラームの電子メール通知が自動的に送信され、Sun Java System Instant Messaging との統合でポップアップアラームが自動的に提供される
各カレンダで複数の所有者がサポートされ、プロジェクトチームやコミュニティーグループでコミュニケーションが簡単になり生産性が向上する
一次所有者の代わりに行使する他者にカレンダの所有権を委託する機能
日ごと、週ごと、月ごと、年ごと、および比較の各ビュー
スケーラブルで、ネットワーク化された、サーバー間、クライアントサーバーアーキテクチャーによって、何十万ものユーザーをサポート
Secure Sockets Layer (SSL) 暗号化、LDAP 認証、認証プラグイン、および Access Manager でアイデンティティ対応のシングルサインオン (SSO) をサポート
Calendar Server の概念の詳細については、『Sun Java System Calendar Server 6 2005Q4 Administration Guide』を参照してください。
配備プロセスは、次の基本フェーズから構成されており、ソリューションライフサイクルと呼ばれます。
ビジネス要件の分析
技術要件の分析
論理アーキテクチャーの設計
配備アーキテクチャーの設計
配備の実行
配備の運用
配備フェーズは固定的なものではなく、配備プロセスは反復して行われます。
Calendar Server やその他の Java Enterprise System コンポーネントの配備プロセスの詳細については、『Sun Java Enterprise System 2005Q4 Deployment Planning Guide』を参照してください。
Calendar Server の配備計画を開始する前に、次のことを確認してください。
組織が Calendar Server を配備するのはなぜでしょうか
次のようにいくつかの理由が考えられます。
コストの削減:ユーザーごとの総所有コストが市販されている他のカレンダ製品を使用するより低くなります。
生産性の向上:カレンダユーザーは、自分の予定や作業を管理できるほか、組織内の他の職員との会議や約束を予定することができます。また、ユーザーはカレンダグループと、会議室や機器などのリソースを管理できます。さらに、カレンダを PDA などのモバイルデバイスや Microsoft Outlook と同期させることもできます。
スケーラビリティーおよび可用性の向上:Calendar Server は垂直と水平の両方向で拡大縮小します。組織が拡大すると、サーバーをアップグレードしたり、さらにサーバーを追加したりすることによって簡単に設定をアップグレードできます。
セキュリティーの向上:Solaris システムに Calendar Server を配備すると、その組織は、Windows 環境でよく見られる多くのウィルスや他のセキュリティー上の危険を回避できます。
高可用性 (HA) 設定:Sun Cluster ソフトウェアとの統合によって、Calendar Server で高可用性サービスが行えるように設定できます。ソフトウェアやハードウェアの障害が発生すると、Calendar Server は二次サーバーへフェイルオーバーします。
通常、Calendar Server の配備には、それぞれが異なる役割と責任を受け持つ何人かの人員が必要です。小規模な組織では、1 人でいくつかの役割を兼任することがあります。考慮すべき役割の中には次のものがあります。
プログラムマネージャは、Calendar Server 配備全体を監督し、その成功や失敗に責任を持ちます。
Calendar Server 管理者は、Calendar Server を管理するための毎日の管理業務を行い、さらに Calendar Server のインストールやアップグレードの責任者となる場合もあります。
パフォーマンスエンジニアは、試験的配備および本稼働における配備の Calendar Server のパフォーマンスをテストおよび監視し、配備条件を満たしているかを確認します。
開発エンジニアリングでは、Calendar Server のアプリケーションやプラグインを記述し、必要に応じて、Calendar Server のユーザーインタフェース (UI) をカスタマイズします。
マニュアルスペシャリストは、管理者やエンドユーザー向けにカスタマイズされたあらゆるマニュアルを執筆します。
教育およびトレーニングでは、実務講習と教材を開発します。
サポートスペシャリストは、試験的配備および本稼働における配備の両方をサポートします。
エンドユーザーは、Calendar Express Web クライアント、Communications Express Web クライアント、または Sun Java System Connector for Microsoft Outlook を使用することによって Calendar Server に接続できます。
サイトのエンドユーザーについて、次のことを確認します。
サイトには、全部で何人の Calendar Server のエンドユーザーがいますか。
エンドユーザーはどのようにして Calendar Server に接続しますか。Calendar Express を使用しますか。Communications Express を使用しますか。Microsoft Outlook を使用しますか。それともそれらのクライアントを組み合わせますか。
地理的な場所はいくつ含まれていますか。エンドユーザーはすべて同じまたは違うタイムゾーンにいますか。
エンドユーザーは、毎日、同じ時間に Calendar Server にログインしますか。
配備では、ピーク使用時のアクティブなエンドユーザーは何人いますか。
エンドユーザーベースはどのくらいの速さで拡張しますか。
Calendar Server エンドユーザーに特有のパフォーマンス要件は何ですか。
シングルサインオン (SSO) 要件は何ですか。
ユーザーの中に、NetscapeTM Calendar 4.x から移行しているユーザーがいますか。
エンドユーザー向けに Calendar Server UI のカスタマイズを計画していますか。
サイトにプロキシサーバーの使用を計画していますか。
エンドユーザーに特有のパフォーマンス要件は何でしょうか。例:
どのくらいのエンドユーザーの応答時間が許容されますか。
ピークロード時に予想されるパフォーマンスの低下を許容できますか。
配備で使用することを計画しているのはどのような構成ですか。Calendar Server の構成シナリオには、次のものが含まれます。
1 つの Calendar Server インスタンス
単一のフロントエンドサーバーと単一のバックエンドデータベースサーバー
LDAP CLD プラグインによる複数のフロントエンド/バックエンドサーバー
高可用性 (HA) 構成
複数のフロントエンドサーバーの設定を計画している場合、どのようにエンドユーザーの分散を計画するでしょうか。
複数のバックエンドデータベースサーバーの設定を計画している場合、どのようにデータベースの分散を計画するでしょうか。たとえば、サーバーを地理的に分散するなどの方法があります。
どのような拡張計画があるでしょうか。フロントエンドとバックエンドの両方についてはどうでしょうか。
この章では、3 つの基本的な Calendar Server 配備アーキテクチャーについて説明しています。それらは使用しているサイトに特有の要件に応じて変更することができます。
この章には、次の節があります。
図 17–1 に、単一サーバーアーキテクチャーを示します。この配備では、すべての Calendar Server サービス (プロセス) が、1 つのサーバーの 1 つの CPU (プロセッサ) または複数の CPU で稼働します。Directory Server と Access Manager のプロセスは、同じサーバー上でも異なるサーバー上でも実行できます。
単一サーバー上の Calendar Server インスタンスには、次のサービスが含まれます。
管理サービス (csadmind プロセス)。Calendar Server の起動と停止、カレンダユーザーまたはリソースの作成と削除、カレンダの取得と格納を行うコマンドなど、管理機能をサポートします。
HTTP サービス (cshttpd プロセス)。着信した SHTML および WCAP 要求を処理します。
予定通知サービス (enpd)。予定およびアラーム通知のブローカとして機能します。
バックアップサービス (csstored)。自動バックアップ (アーカイブバックアップとホットバックアップの両方) を実行します。
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) 以降) には次の機能があります。
Communications Services Delegated Administrator ユーティリティ:Calendar Server を含む Sun Java System コミュニケーションサーバーの、ホスト ( 仮想) ドメイン、ユーザー、グループ、組織、リソース、ロールをプロビジョニングおよび管理するときは、この CLI ユーティリティ (commadmin) を使用します。
Communications Services Delegated Administrator ユーティリティの詳細については、『Sun Java System Communications Services 6 2005Q4 Delegated Administrator 管理ガイド』を参照してください。
シングルサインオン (SSO):Access Manager の使用または信頼できるサークルテクノロジによって、Calendar Server や Messaging Server を含む Sun Java Enterprise System サーバーに SSO を実装することができます。Access Manager は、Java Enterprise System サーバーの SSO ゲートウェイとして機能します。ユーザーは Access Manager にログインすると、すべてのサーバーで SSO が適切に設定されている限り、その他のサーバーにもアクセスできます。
Sun Java System LDAP スキーマ 2: このバージョンのスキーマを利用するには、Access Manager (リリース 2003Q4 以降) が必要です。
これらのトピックの詳細については、『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 に接続します。これらのインタフェースの使い方については、各インタフェースのオンラインヘルプを参照してください。
Calendar Server は、複数のフロントエンドサーバーとバックエンドサーバーに設定を分配することにより、スケーラビリティーを実現します。各サーバーでは、Calendar Server サービスを複数の CPU に分散させることもできます。
次の図に示す 2 層アーキテクチャーはネットワークフロントエンド / データベースバックエンド構成とも呼ばれ、ユーザーはフロントエンドサーバーにログインし、DWP (データベースワイヤプロトコル) サービス (csdwpd プロセス) を使用してバックエンドサーバーに接続します。カレンダデータベースは、バックエンドサーバーだけに接続されています。
フロントエンドサーバーとバックエンドサーバーの両方で実行される Calendar Server プロセスは次のとおりです。
ユーザーはロードバランサによってフロントエンドサーバーに誘導され、そこでログインします。それぞれのフロントエンドサーバーは次のサービスを必要とします。
管理サービス (csadmind プロセス)
HTTP サービス (cshttpd プロセス)
各バックエンドサーバーにはカレンダデータベースが接続されるため、各バックエンドサーバーは次のサービスを必要とします。
この構成では、ユーザーはバックエンドサーバーにログインしないため、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 アーキテクチャー (図 17–3) では、ユーザーは特定のサーバーにログインし、各サーバーはカレンダデータベースに接続されています。この構成では、カレンダを物理的に配布することができます。各サーバーにはカレンダが配置され、その所有者が 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 に接続します。これらのインタフェースの使い方については、各インタフェースのオンラインヘルプを参照してください。
この章では、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』を参照してください。
プレーンテキストパスワードと暗号化パスワードの両方のログインが使用可能です。
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』を参照してください。
この章では、Calendar Server サービスの計画について説明します。
この章には、次の節があります。
Calendar Server は次の主な 6 つのサービスから構成されています。
HTTP サービス (cshttpd)。HTTP 要求を待機します。HTTP サービスはユーザー要求を受け取り、データを呼び出し元に返します。
管理サービス (csadmind)。Calendar Server のそれぞれのインスタンスに必要とされます。管理サービスは Calendar Server の認証および管理を 1 ヵ所で行い、また、ほとんどの管理ツールを提供します。
通知サービス (csnotify)。電子メールまたは予定通知サービスのいずれかを使用して、予定および作業の通知を送信します。
分散データベースサービス (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 のような 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 ホストの両方を持つ構成では、すべてのホスト上で次のソフトウェアが動作している必要があります。
同じオペレーティングシステム環境とバージョン (つまり、Solaris SPARC、Solaris x86、Linux Red Hat などをそれぞれ実行するシステムの混在は不可)。
同じリリースの Calendar Server (パッチやホットフィックスのリリースを含む)。
LDAP データキャッシュオプションを使うと、LDAP データのコミット直後にそのデータが利用可能になります。LDAP ディレクトリサーバーの設定によっては、(リモート) マスターサーバーに更新を参照した後、そのマスターサーバーからローカルの LDAP ディレクトリに更新をレプリケートする必要があります。このような種類の設定では、ローカルの LDAP サーバーのコミット済みデータが利用可能になるまでに遅延が生じる可能性があります。
たとえば、サイト上にマスター / スレーブ LDAP 構成が配備されており、Calendar Server がマスター LDAP ディレクトリにスレーブ LDAP ディレクトリサーバー経由でアクセスする仕組みになっている場合、コミット済み LDAP データが利用可能になるまでにいくらかの遅延が発生しますが、LDAP データキャッシュを使えば、Calendar Server クライアントが正確な LDAP データにアクセスできるようになります。
この節では次の内容について説明します。
サイトで LDAP データキャッシュを設定すべきかどうかを決定するには、次のガイドラインに従います。
サイトの Calendar Server がマスター (またはルート) LDAP ディレクトリサーバーに直接アクセスし、コミット済み LDAP データが利用可能になるまでの遅延が発生しない場合、LDAP データキャッシュを設定する必要はありません。 local.ldap.cache.enable パラメータがデフォルトの「no」に設定されていることを確認してください。
サイト上に「マスター / スレーブ LDAP 構成」が配備されており、Calendar Server がマスター LDAP ディレクトリにスレーブ LDAP ディレクトリサーバー経由でアクセスする仕組みになっている場合、コミット済み LDAP データが利用可能になるまでにいくらかの遅延が発生しますが、LDAP データキャッシュを設定すれば、エンドユーザーが最新データにアクセスできるようになります。
マスター / スレーブ LDAP 構成には、1 つのマスター (ルート) ディレクトリサーバーと、1 つ以上のスレーブ (コンシューマまたはレプリカ) ディレクトリサーバーが含まれます。Calendar Server からマスター LDAP ディレクトリサーバーへのアクセスは、直接行うことも、スレーブディレクトリサーバー経由で行うことも可能です。
Calendar Server がマスター LDAP ディレクトリサーバーに直接アクセスする場合、LDAP データは正確であるはずなので、LDAP データキャッシュを設定する必要はありません。
Calendar Server がマスター LDAP ディレクトリサーバーにスレーブディレクトリサーバー経由でアクセスする場合、LDAP データの変更結果は通常、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 データキャッシュデータベースで実現可能な機能は、次のとおりです。
単一システム上のプロセス間におけるデータ整合性の維持: このデータベースは、マルチプロセッサシステム上のすべての Calendar Server プロセスから利用可能です。
ユーザーセッションをまたがるデータの持続性: このデータベースは永続的であり、更新を必要としません。LDAP データキャッシュエントリの TTL (Time To Live) やデータベースクリーンアップ間隔を設定できます。
LDAP データキャッシュで実現不可能な機能は、次のとおりです。
複数エントリの一致が予想されるような検索におけるキャッシュ読み取り (特定の会議への出席者を検索する場合など)。このタイプの検索では、LDAP 遅延が発生します。たとえば、LDAP 検索オプションが有効になっており、かつ新しいカレンダが作成されてから遅延期間内にカレンダ検索が実行された場合、その新しいカレンダは検索結果に含まれません。
複数フロントエンドサーバーにまたがるキャッシュの読み書き。各フロントエンドサーバーはそれぞれ独自のキャッシュを持ち、ほかのキャッシュ内のデータにアクセスすることはありません。
常に同じサーバーにログインするとはかぎらないユーザーを処理する機能。そのようなユーザーに対しては、各サーバーのキャッシュ内にそれぞれ異なる LDAP データが生成されます。
LDAP データキャッシュを設定するには、 ics.conf ファイル内の対応するパラメータを設定します。詳細については、『Sun Java System Calendar Server 6 2005Q4 Administration Guide』を参照してください。
Calendar Server またはその稼働元のサーバーが正しくシャットダウンされなかった場合、ldap_cache ディレクトリ内のすべてのファイルを手動で削除してください。そうしないと、次回の再起動時にデータベースが破損し、問題が発生する可能性があります。
この章では、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 ソフトウェアをインストールする際、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 の管理権限を付与されているユーザーのことです。たとえば、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』を参照してください。
Solaris システムでは、これらの特別なアカウントは Calendar Server の実行に使用されるユーザー ID とグループ ID を示しています。特別なアカウントが存在しないときは、設定プログラムによって自動的に作成されるデフォルト値 icsuser および icsgroup を使用してください。ただし、Calendar Server 設定プログラムの実行時に icsuser および icsgroup 以外の値を指定することもできます。これらの値は、それぞれ ics.conf ファイルの local.serveruid パラメータおよび local.servergid パラメータに格納されます。
Solaris ソフトウェアが稼働するマシン上では、Calendar Server をインストールするには superuser (root) としてログインするか、あるいは superuser になる必要があります。コマンド行ユーティリティを使用して superuser として実行し、Calendar Server を管理することもできます。ただし、一部のタスクについては、Calendar Server ファイルへのアクセスの問題を回避するために、superuser としてではなく icsuser および icsgroup (または選択した値) として実行することをお勧めします。
Calendar Server はホストしている (または仮想) ドメインをサポートしています。ホストしているドメインのインストールでは、各ドメインが Calendar Server の同じインスタンスを共有するため、1 つのサーバーに複数のドメインが存在できます。各ドメインはネームスペースを定義し、1 つのネームスペースではすべてのユーザー、グループ、リソースが一意です。各ドメインには、変更可能な属性とユーザー設定もあります。
ホストしているドメインのインストールおよび設定には、スキーマ 2 だけを使用してください。
ホストしているドメインをサーバーにインストールおよび設定するには、次の高レベルの手順を実行します。
Directory Server をインストールおよび設定します。
Web Server または Application Server をインストールおよび設定します。
Access Manager をインストールおよび設定します。
Calendar Server をインストールします。
このスクリプトの実行手順については、『Sun Java System Calendar Server 6 2005Q4 Administration Guide』の第 2 章「Directory Preparation Script (comm_dssetup.pl)」を参照してください。
Communications Services Delegated Administrator を設定します。
Communications Services Delegated Administrator ユーティリティの設定手順と使用手順については、『Sun Java System Communications Services 6 2005Q4 Delegated Administrator 管理ガイド』を参照してください。
デフォルトドメインおよびサイト管理者 (calmaster ) を作成します。
デフォルトドメインは commadmin の設定時に作成されます。ただし、ドメインエントリを変更して、Calendar または Mail サービスを追加する必要があります。また、サイトカレンダ管理者 (calmaster) を設定する必要があります。これらの 2 つのタスクの実行方法の手順については、『Sun Java System Calendar Server 6 2005Q4 Administration Guide』のパート II「Postinstallation Configuration」を参照してください。
Calendar Server を設定します。
csconfiguratior.sh プログラムの実行手順については、『Sun Java System Calendar Server 6 2005Q4 Administration Guide』の第 3 章「Calendar Server Configuration Program (csconfigurator.sh)」を参照してください。
Calendar Server のホストしているドメインの設定パラメータを設定します。
設定パラメータおよびその値のリストについては、『Sun Java System Calendar Server 6 2005Q4 Administration Guide』の「Hosted Domain Configuration」を参照してください。
commadmin ユーティリティを使用して、ホストしているドメインをサイトに作成します。
commadmin ユーティリティを使用して、ホストしているドメインにユーザーおよびリソースを配置します。
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 を設定する必要があります。
Directory Server 設定スクリプト (comm_dssetup.pl) を実行し、Sun Java System Directory Server を設定します。
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』を参照してください。