test

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

パート I 配備計画の概要

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

第 1 章 Communications Services 配備の紹介

この章では、Sun JavaTM System Communications Services 6 2005Q4 の概要、Communications Services の配備に関する業務上の根拠、および配備プロセスそのものについて説明します。

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

Communications Services の概要

Sun Java System Communications Services 6 2005Q4 は、安全で、費用効率の高い通信とコラボレーションを提供します。Communications Services は、他の通信およびコラボレーションソリューションに代わる、安全で、スケーラブルな、総所有コスト (TCO) を削減するソリューションを提供し、顧客が懸念するコスト、機能、および従来の通信インフラストラクチャーのセキュリティーなどの問題解決に取り組みます。

Communications Services は、企業と ISP 双方の通信およびコラボレーションのニーズに対応するために必要な電子メール、カレンダ、およびインスタントメッセージングソリューションを提供します。Communications Services の製品とサービスは、一般的なビジネス要件に対する強力な対応策を提供します。あらゆる組織にとって、通信は不可欠です。そして多くの場合、大規模な範囲の多様で地理的に分散しているユーザーコミュニティーに対して通信サービスを提供する必要があります。従来の通信ソリューションはコストがかかり、今日のスケーラビリティーとセキュリティー要件に対応するのに十分ではありません。Communications Services によって、組織は総所有コストの予算内でソリューションを配備することが可能になります。

また、Communications Services は、多様な顧客が必要とする独自のサービスとフル装備のコラボレーション機能を提供します。最後に、Communications Services の配備は、企業のファイアウォールの外側に通信を拡張する際や、複数のデバイスを使用するモバイルユーザーに対して必要とされるようになった高いセキュリティーを提供します。

Communications Services のコアソリューションは、次のコンポーネント製品から構成されています。

Communications Services ソリューションは次の追加機能によって拡張されます。

全体として、Communications Services は、何千ものユーザーを抱える企業向け配備および数十万ものユーザーを抱える ISP 配備ための、標準ベースの統合された通信およびコラボレーション製品群を提供します。Communications Services は、あらゆる組織の多様な通信ニーズに対応する堅固で柔軟なプラットフォームを提供します。Communications Services は、遠隔地オフイス、分散ワークグループ、グローバルな企業拠点を接続するための最適なソリューションです。

Messaging Server について

Sun Java System Messaging Server 6 は、高性能かつ高い安全性を備えたメッセージングプラットフォームです。数千人から数百万人規模のユーザーのスケーリングに対応する Messaging Server は、電子メールサーバーを統合し、通信インフラストラクチャーの総所有コストを削減しようとする企業に適しています。Messaging Server は、ユーザー認証、セッションの暗号化、スパムとウィルスの防止に役立つ適切なコンテンツのフィルタリングを通し通信の統合を実現する幅広いセキュリティー機能を提供します。

Messaging Server によって、組織は社員、パートナー、および顧客からなるコミュニティー全体に対して安全で信頼性の高いメッセージングサービスを提供できます。

Messaging Server は現在、次の 2 つのクライアント向けユーザーインタフェース (UI) をサポートしています。

今後、Messenger Express ユーザーインタフェースに新機能が追加されることはありません。Messaging Server は非推奨となり、代わって Communications Express が推奨のユーザーインタフェースとなりました。Sun Microsystems, Inc. は後日、Messenger Express の生産中止スケジュールを発表する予定です。

Messaging Server の概念やその他の配備に関する詳細については、パート II「Messaging Server の配備」を参照してください。

Calendar Server について

Sun Java System Calendar Server 6 は、ユーザーによるアポイントメント、予定、作業、リソースの管理、調整を可能にして、円滑なチームコラボレーションを可能にします。Calendar Server は、直観的な Web ベースのインタフェースによって、エンドユーザーが任意の時間、任意の場所で任意の Web ブラウザから、非公開、公開、またはグループカレンダにアクセスできるようにします。配備は、Messaging Server および Instant Messaging とともに Calendar Server を使用して、包括的な通信およびコラボレーション環境をユーザーに提供します。

Calendar Server は現在、次の 2 つのクライアント向けユーザーインタフェース (UI) をサポートしています。

Calendar Server は非推奨となり、代わって新しい Communications Express が推奨のユーザーインタフェースとなりました。今後、Calendar Server ユーザーインタフェースに新機能が追加されることはありません。Sun Microsystems, Inc. は後日、Calendar Server の生産中止スケジュールを発表する予定です。

Calendar Server の概念やその他の配備に関する詳細については、パート III「Calendar Server の配備」を参照してください。

Instant Messaging について

Sun Java System Instant Messaging 7 は、安全で、リアルタイムの通信とコラボレーションを可能にします。Instant Messaging は、参加の確認をチャット、会議、アラート、ニュース、ポーリング、ファイル転送などのインスタントメッセージング機能と組み合わせて、機能の豊富なコラボレーション環境を形成します。これらの機能は、1 対 1 だけでなくグループによる共同作業にも対応し、短期間の通信のほか、会議室やニュースチャネルなどの持続的な場を利用することができます。Instant Messaging を Calendar Server、Messaging Server と組み合わせて使用すれば、包括的な通信およびコラボレーション環境をユーザーに対して提供できます。

Instant Messaging は、複数の認証メカニズムとセキュリティー保護された SSL 接続によって通信の統合を可能にします。Sun JavaTM System Portal Server 6 と Sun JavaTM System Access Manager 6 との統合により、セキュリティー機能、サービスベースのプロビジョニングアクセスポリシー、ユーザー管理、セキュリティー保護されたリモートアクセスが強化されます。さらに、Instant Messaging は XMPP (Extensible Messaging and Presence Protocol) をサポートします。XMPP を使用すると、ユーザーは、公衆ネットワークからの接続を集約するサードパーティー製の一部のクライアントが使用できるようになります。1 つのクライアント内に、AIM、Yahoo、MSN、Sun、およびその他の XMPP ベースのサーバーからの接続を収容できます。

Instant Messaging の概念や配備に関する詳細については、パート IV「Instant Messaging の配備」を参照してください。

Communications Express について

Sun Java System Communications Express 6 は、通信およびコラボレーション用の Web ベースの統合クライアントです。Communications Express は Messaging Server と Calendar Server の共通ソフトウェアであり、カレンダ情報、メール、およびアドレス帳に対する Web インタフェースをエンドユーザーに対して提供します。

Communications Express の概念や配備に関する詳細については、パート V「Communications Express の配備」を参照してください。

Synchronization について

Sun ONE Synchronization 1.1 は、Windows パーソナルコンピュータ上で実行されるソフトウェア製品で、Calendar Server の予定および作業と、モバイルデバイスや Microsoft Outlook などの PIM (Personal Information Manager) との同期を可能にします。

詳細については、次の Web サイトにある Sun ONE Synchronization のマニュアルを参照してください。

http://docs.sun.com/db/coll/S1_Sync_11

Connector for Microsoft Outlook について

Sun Java System Connector for Microsoft Outlook 7 は、Outlook を Messaging Server と Calendar Server のデスクトップクライアントとして使用できるようにします。

Connector for Microsoft Outlook は、エンドユーザーのデスクトップにインストールする Outlook のプラグインです。Connector for Microsoft Outlook は、Messaging Server にフォルダの階層と電子メールメッセージを照会します。次に、Connector for Microsoft Outlook は、この情報を Outlook で表示できる MAPI (Messaging API) プロパティーに変換します。同様に、Connector for Microsoft Outlook は、Calendar Server に予定と作業を照会し、それらを MAPI プロパティーに変換します。このモデルによって、Connector for Microsoft Outlook は、Messaging Server のメールと Calendar Server のカレンダ情報の 2 つの別個の情報源からエンドユーザーの Outlook 表示を作成します。

同様に、Connector for Microsoft Outlook では、WABP (Web Address Book Protocol) を使用して Address Book Server に連絡先を照会し、それらを MAPI プロパティーに変換します。このモデルによって、Connector for Microsoft Outlook は、Messaging Server のメール、Calendar Server のカレンダ情報、Address Book Server の連絡先という、3 つの別個の情報源からエンドユーザーの Outlook 表示を作成します。

詳細については、次の Web サイトにある Connector for Microsoft Outlook のマニュアルを参照してください。

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

Communications Services コンポーネント製品の依存性

Communications Services は、インフラストラクチャーサービスを提供するほかの Sun Java System コンポーネント製品との依存関係があります。これらのコンポーネント製品には、Sun JavaTM System Directory Server と、オプションで Sun Java System Access Manager が含まれます。さらに、Communication Services は、HTML コンテンツを提供し、HTML 接続を提供する Web サーバーに依存します。この機能を実行するために、Sun JavaTM System Web Server (従来の SunTM ONE Web Server) または Sun JavaTM System Application Server を使用できます。

また、Communications Services は DNS 機能にも依存します。Communications Services 製品をインストールするには、DNS サーバーが機能している必要があります。

製品の依存関係の詳細については、第 3 章「製品の要件と考慮事項について」を参照してください。

Communications Services のビジネスニーズへの対応方法について

組織は、強力な機能を備えると同時に、コストを削減し管理を簡素化するためのサービスの配備が必要です。サービスのアーキテクチャーには、ユーザーが日常業務の遂行に不可欠な情報に、複数の方法でのアクセスを可能にするためのセキュリティーとスケーラビリティーの要件を追加する必要があります。Communications Services では、企業の総所有コストの予算内でスケーラブルなメッセージング、カレンダ、インスタントメッセージングを提供することによりこれらのニーズに対応します。

Communications Services により、配備と保守が容易で、完全な機能を持つアーキテクチャーの開発が可能になります。最も重要なことは、Communications Services アーキテクチャーによって各サービス要素にセキュリティーが組み込まれることです。これらの要素には、ネットワークインフラストラクチャー、動作環境、および Communications Service コンポーネント製品そのものが含まれます。

Messaging Server のビジネスニーズへの対応方法について

Messaging Server は、優れた信頼性と生産性の向上を促進するとともに、管理と運用コストを低減します。Messaging Server は、確定したトランザクションを使用するため、メッセージはディスクに格納されるまで受信済みとして認識されません。この信頼性機能は、メールメッセージの損失や破損を防止します。さらに、Message Store は、卓越したパフォーマンスとデータ統合を実現するために、追記型データストアと 2 段階インデックスを採用するカスタム設計のデータベースを中心に構築されます。

Calendar Server のビジネスニーズへの対応方法について

Calendar Server は、オープンで相互運用可能かつ高性能な、業界最高レベルの時間管理およびリソース管理ソリューションです。Calendar Server によって、ほかのソリューションに比べて低い総所有コストで、必要な機能を得ることができます。Calendar Server のアーキテクチャーは、柔軟で拡張可能なので、垂直方向 (システムごとの CPU の数を増大させる) と水平方向 (ネットワークにサーバーを追加する) の両方向で拡張性があります。

Instant Messaging のビジネスニーズへの対応方法について

Instant Messaging ソフトウェアは、プロジェクトのライフサイクルを短縮し、新しいサービスを手ごろな価格で配備できるように Java Enterprise System と緊密に統合されています。さらに、Instant Messaging は、Portal Server、Access Manager、Messaging Server、および Calendar Server と連携して動作します。この統合によって、ユーザーは、安全かつスケーラブルなフル装備の通信およびコラボレーションサービスのプラットフォームを、単一のベンダーから入手できます。Instant Messaging に含まれる定評ある Java API は、複数のプラットフォームのサポート、プラットフォームの拡張性、リアルタイム通信およびコラボレーション機能のカスタマイズとともに、統合を容易にするオープンな標準を提供します。これらの機能は、既存のアプリケーションに組み込まれたり、あるいは新しいアプリケーションの基盤となります。また、XMPP による相互運用性は、パートナー企業や顧客との間でリアルタイム通信を実現したいと考えている企業に大きなメリットをもたらします。というのも、それらのパートナー企業や顧客の多くは、それぞれ独自のインスタントメッセージングシステムを構築しているからです。

Communications Express のビジネスニーズへの対応方法について

Communications Express は通信およびコラボレーション用の Web ベースの統合クライアントであり、インターネットサービスプロバイダ、企業、および OEM のニーズを満たします。Communications Express はカレンダ、メール、およびアドレス帳に対する統合ユーザーインタフェースを備えており、あるクライアントモジュールから別のクライアントモジュールへとアクセス先を変更しても、ユーザー資格の再認証を行う必要がありません。メールとカレンダ間の通信は、Access Manager または Messaging Server のシングルサインオンメカニズムを使って確立されます。カレンダアプリケーションとメールアプリケーションは、同一のアドレス帳を共有します。Communications Express の「オプション」タブで指定されたユーザー設定を、すべてのモジュールが共有します。

Communications Services の利点の概要

従来、Communications Services コンポーネントは、大規模な、通信事業者クラスの配備に使用されてきました。大規模配備で要求されるのと同じ信頼性を企業で利用することができます。

次の表に、Communications Services の利点をまとめます。

表 1–1 Communications Services が組織に対して提供する利点

主な機能 

利点 

高いパフォーマンスおよびスケーラビリティー 

効率的な通信が可能になり、企業と ISP の両方のサービス品質が向上します。 

豊富なセキュリティー機能 

通信とデータの整合性および従業員、顧客、パートナーのプライバシーを保護し、業界の規則を遵守します。 

仮想ドメインのホスティングと委任管理

Messaging Server、Calendar Server、および Instant Messaging は、1 つのサーバーで複数の企業のメッセージをホストし、あるいは企業 IT が組織内の複数の部門をホストできるようにして、必要なサーバー数を削減し、TCO を低減します。 

スケーラブル、堅牢、さらに拡張可能なコンポーネント 

一体化した通信サービスの配備が可能になり、電話サービスとともに、電子メール通知、ファックス、ポケットベルなどの技術も提供可能になります。 

予定管理、作業とリソースの管理のための拡張可能なコラボレーションプラットフォーム 

Calendar Server で時間とリソースの管理が改善され、ユーザーの生産性が向上します。 

会議や予定のグループスケジュール機能 

Calendar Server で組織全体のチームコラボレーションや通信が改善します。 

ハイパーリンクで予定または作業の情報を共有 

Calendar Server では作業または予定に関連した情報の交換によってコラボレーションを促進します。 

複数クライアントのサポート 

Ximian Evolution や Microsoft Outlook などの複数のリッチクライアントに対して、統合された Web ベースのクライアントとサポートを提供します。

オープン、モジュール方式、および標準ベースのアーキテクチャー 

顧客は、カスタマイズされ、パーソナライズされたソリューションを配備できます。 

Communications Services 配備の高可用性の向上

クラスタソフトウェアを使用すると、Messaging Server、Calendar Server、および Instant Messaging で高可用性が実現できるように設定できます。Messaging Server は、SunTM Cluster および Veritas Cluster Server の両方のソフトウェアをサポートしています。Calendar Server および Instant Messaging は、Sun Cluster ソフトウェアをサポートしています。クラスタソフトウェアの使用時に、プライマリシステムが保守目的でオフラインとなっている場合、あるいは障害によりダウンしている場合に、Messaging Server、Calendar Server、または Instant Messaging のセカンダリホストがユーザーにサービスを提供します。

Sun Cluster を使用しなくても、Messaging Server には、サーバープロセスとサービスの可用性の状態を継続的にチェックする組み込み監視機能が装備されています。Messaging Server は、必要に応じてプロセスとサービスを自動的に再起動することができます。レポートと分析を選択した場合、Messaging Server は障害と回復操作のログを記録します。

さらに、冗長コンポーネントを使用することにより、高度に可用性のある構成で Communications Services 製品を配備することができます。この種の配備により、サービスの稼働時間を高レベルにすることができます。このように可用性の高い配備を行うには、サービスアーキテクチャーの各コンポーネントで冗長性が必要になります。このようなコンポーネントには、二重のデータストアサーバー、二重のネットワークインタフェースカード、および二重のシステム記憶装置が含まれます。

注 –

このガイドでは、Communications Services の高可用性配備における Sun Cluster の利用に関する詳細は取り扱っていません。このトピックに関する詳細については、Sun Cluster、Messaging Server、Calendar Server、および Instant Messaging のマニュアルを参照してください。

Communications Services での Portal Server の使用

Portal Server を含む Communication Services 製品のインストールでポータルページのメッセージングおよびカレンダポートレットにアクセスできます。これらのポートレットは、メッセージング情報、カレンダスケジュール、アドレス帳情報の要約を提供します。Portal Server の統合には、Portal Server、Calendar Express、Messaging Express、Communications Express クライアント間のシングルサインオン機能が含まれます。

注 –

Sun JavaTM System スキーマ 1 とスキーマ 2 の両方の環境で、Communications Express を実行できます。スキーマ 2 を使用している場合は、Access Manager 認証を使用して Communications Express にシングルサインオンすることができます。

また、Portal Server は Instant Messaging のメッセージアーカイブをサポートします。さらに、ユーザーは、Portal Server デスクトップを使用して、Messenger Express、Calendar Express、Instant Messenger クライアントを利用することができます。

Portal Server の次の 2 つのコンポーネントは、Communications Services の基本配備に対する追加機能を提供します。

注 –

このガイドでは、ポータル環境における Communications Services のポータル配備については取り扱っていません。詳細については Portal Server のマニュアルを参照してください。

配備プロセスについて

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

配備フェーズは固定的なものではなく、配備プロセスは反復して行われます。ただし次の各節では、配備フェーズをそれぞれ個別に説明しています。

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

ビジネス要件の分析

ビジネス分析フェーズでは、配備プロジェクトのビジネス目標を定義し、その目標を達成するために満たす必要のあるビジネス要件を記述します。ビジネス要件を記述する際には、ビジネス目標の達成に影響する可能性のある、あらゆるビジネス制約を考慮してください。ビジネス分析フェーズの成果物であるビジネス要件文書は、後続の技術要件フェーズで使用されます。ライフサイクル全体を通じて、このビジネス分析フェーズで実施した分析結果に基づいて、配備計画と最終的な配備済みシステムの成功度合いを測定します。

技術要件の分析

技術要件フェーズでは、ビジネス分析フェーズで定義されたビジネス要件とビジネス制約の内容を確認し、それらを配備アーキテクチャー設計時に使用可能な技術仕様書に変換します。技術仕様書には、パフォーマンス、可用性、セキュリティーといったサービス品質に関する基準を記述します。

技術要件フェーズで準備する情報は、次のとおりです。

成果物である使用分析文書、ユースケース文書、およびシステム要件文書が、ソリューションライフサイクルの論理設計フェーズに提供されます。また、技術要件分析フェーズではサービスレベル要件も特定します。これらの要件が、配備済みシステムの障害を解決し、システム要件を満たすべく顧客サービスを提供する上での条件となります。サービスレベル要件は、プロジェクト承認時に締結されるサービスレベル契約の基礎となります。

論理アーキテクチャーの設計

論理設計フェーズでは、配備に必要なサービスを特定します。サービスの特定が完了したら、それらのサービスを提供する論理的に区別されたコンポーネントを、論理アーキテクチャー内にマッピングします。論理アーキテクチャーには、コンポーネント間の依存関係も記載します。論理アーキテクチャーと技術要件フェーズで作成された技術要件仕様書によって、「配備シナリオ」が特徴づけられます。

論理アーキテクチャーには、配備シナリオ実施時に必要となる実際のハードウェアは規定されていません。しかしながら、論理アーキテクチャーは、コンポーネント間の相互関係の視覚化に役立ち、ユースケースと特定された使用パターンをさらに分析するための土台を提供し、配備設計フェーズの開始点となります。

API を使用してサービスを拡張する際や、たとえば企業のブランド設定を導入してルックアンドフィールをカスタマイズする際には、追加の作業が必要なこともあります。

ソリューションによっては、配備やカスタマイズにかなりのコストがかかり、新しいビジネスおよびプレゼンテーションサービスの開発が必要になる場合もあります。他のソリューションの場合、Portal Server デスクトップなどの既存のグラフィカルユーザーインタフェースをカスタマイズすることによって必要な機能の実現が可能な場合もあります。

製品 API の使用や製品機能のカスタマイズについては、適切なコンポーネント製品のマニュアルを参照してください。

配備アーキテクチャーの設計

設計フェーズでは、論理アーキテクチャー内に指定された論理コンポーネントを、配備アーキテクチャー内の物理コンポーネントにマッピングします。また、配備実施時に役立つ設計文書も作成します。配備設計がうまくいくと、次の成果物が得られます。

配備の実行

実行フェーズでは、配備設計時に作成された設計文書に基づいて配備アーキテクチャーを構築し、配備を実施します。このフェーズでは、個々の配備プロジェクトの特性に応じて次の手順の一部または全部を実行します。

配備の本稼働後も引き続き、配備の監視、テスト、および調整を行い、ビジネス目標が確実に達成されるようにする必要があります。

第 2 章 Communications Services の要件の分析

Communications Services 配備の計画においては、まず組織のビジネスと技術的な要件を分析する必要があります。この章は、Communications Services 設計を決定するために使用する要件を収集し、評価するのに役立ちます。

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

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

配備目標の確認

Communications Services ハードウェアまたはソフトウェアを購入または配備する前に、配備目標を明確にする必要があります。組織内のさまざまなソースから、配備の要件があがってきます。多くの場合、要件はあいまいな言葉で表現されますが、それを特定の目標に向けた明確な定義に変える必要があります。

要件分析の結果は、明確で簡潔な言葉で定義し、配備による成果を評価できる目標としてまとめる必要があります。プロジェクト関係者からの同意を得た明確な目標がなければ、先に進んでも成功するのは困難です。

配備を計画する前に検討の必要がある要件には、次のものがあります。

ビジネス要件の定義

ビジネスの目標は、配備の決定に大きく影響します。具体的には、ユーザーの行動、サイトの配布、配備に影響を与える潜在的な政治的要因について理解しておく必要があります。これらの業務上の要件を理解していない場合は容易に想定を誤り、配備設計の精度に影響を与えることになりかねません。

運用の要件

直接的な目標を持った一連の機能上の要件として、運用要件を明確にします。通常、次の項目が該当します。

たとえば、「適切なエンドユーザー応答時間」という要件を評価可能な用語で言い換えて、関係者全員が何が「適切」で応答時間がどのように評価されるかを理解できるようにします。

カルチャーとポリティクス

配備を考える場合、企業のカルチャーとポリティクスを考慮する必要があります。需要というものは、結局はビジネス要件そのものから生み出されてくるものです。例:

技術要件の定義

技術の要件 (または機能の要件) は、組織のシステムニーズの詳細です。

既存の利用率パターンのサポート

既存の利用率パターンを、配備実現のための明確で評価可能な目標として定義します。そのような目標を定義する際に参考となる質問を、次に示します。

サービスにアクセスするユーザーについて調査します。ユーザーはいつ既存のサービスを使うのかといった要素が、配備の要件、ひいては配備の目標を定める重要なポイントとなります。組織の今までの事例からこれらのパターンを得ることができない場合は、他の組織の事例を研究し、推測します。

利用率のきわめて高い部署では、専用のサーバーが必要になる場合もあります。一般に、ユーザーが実際のサーバーから遠く離れており、回線速度も遅い場合、応答時間が長くなります。応答時間が適切であるかどうかを検討する必要があります。

サイトの分散

次の質問を検討して、サイトの分散が配備目標に与える影響を理解します。

ネットワーク

ネットワーク要件の理解に役立つ質問を、次に示します。

注 –

これらの質問に「はい」と答えた場合は、2 層アーキテクチャーをお勧めします。

既存のインフラストラクチャー

より信頼性の高い高可用性帯域幅が利用できる場合は、集中化サーバーを採用できます。

サポート要員

24時間、週に 7 日 (24 x 7) 体制のサポートは、特定のサイトでのみ提供されます。少数のサーバーによる簡単なアーキテクチャーの場合は、サポートが容易です。

財務要件の定義

財務上の制約は、配備の構築方法に影響を与えます。財務上の要件は全体的な視点から明確に定義される場合が多く、配備の限界や目標が明確になります。

ハードウェア、ソフトウェア、および保守のための明確なコスト以外に、次のような他のコストがプロジェクト全体に影響を与えます。

プロジェクトの要件に関連する数多くの要素を注意深く分析することで、プロジェクトに関連する財務上の問題を回避することができます。

サービスレベル契約 (SLA) の定義

サービスレベル契約には、稼働時間、応答時間、メッセージ配信時間、および障害回復のような領域に関連する配備を盛り込む必要があります。サービスレベル契約自体には、システムの概要、サポート組織の役割と責任、応答時間、サービスレベルの評価方法、要求の変更などの項目が網羅されています。

サービスレベル契約の範囲を決定する際には、システムの可用性に対する組織の予測が重要なポイントとなります。システムの可用性は、システム稼働時間に対するパーセンテージで表されます。システムの可用性を表す公式は次のとおりです。 

可用性 = 稼働時間 / (稼働時間 + 停止時間) * 100

たとえば、サービスレベル契約で稼働時間が 99.99 パーセントと規定されている場合、1 か月に許されるシステムが使用できない時間は、約 4 分間となります。

さらに、システムの停止時間とは、システムが使用できない時間の合計を意味します。この合計には、システム障害やネットワークの停止などの予期しない停止時間だけでなく、計画された停止時間、予防的保守、ソフトウェアのアップグレードやパッチを当てる時間なども含まれます。システムが 7x24 (週 7 日、24 時間) 稼働を前提としている場合、アーキテクチャーに冗長性を持たせて計画された停止や予期しない停止に備え、高可用性を確保する必要があります。

プロジェクト目標の決定

まず、調査と分析を行なって、プロジェクトの必要要件を明確にする必要があります。次に、明確で評価可能な目標を決定します。プロジェクトに直接関与しない人員でも理解可能な形で目標を設定し、プロジェクトの評価方法も明確にしておきます。

プロジェクト目標は、すべての利害関係者によって承認される必要があります。プロジェクト目標は、プロジェクトの成功を見きわめるために、実装後の検査で計測される必要があります。

拡大のための計画

現在要求されている許容量を決定するだけでなく、計画できる時間枠内で将来必要とされる能力も算出しておく必要があります。拡張のスケジュールは、通常 12 か月から 18 か月です。拡張の例外と利用率特性の変化を考慮して、拡張を検討する必要があります。

ユーザー数とメッセージの数の増加に対応して、容量計画のガイドラインを策定する必要があります。さまざまなサーバーのメッセージトラフィックの増大、全体のユーザー数の増加、メールボックスサイズの拡大、カレンダのアポイントメントの増加などを計画に含める必要があります。収容ユーザー数の増加に伴い、その間の利用率特性も変化します。配備目標 (そして配備設計) は、将来に向けても実現可能なように、状況に応じて対応できるものでなければなりません。

アーキテクチャーが将来の拡張を容易に吸収できるよう設計しておくのが理想的です。たとえば、Communications Services 自体に論理名を使用します。詳細については、「論理サービス名の使用」を参照してください。稼働段階に入ったら、配備状態を監視して、配備ニーズがいつどのように増加しているかを認識することも重要です。

総所有コスト (TCO) の理解

総所有コスト (TCO) もまた、許容量の計画に影響を与える要素です。これには、Communications Services の配備で選択するハードウェアが含まれます。次の表で、数を多くした小規模なハードウェアシステム、または少数の大規模ハードウェアシステムのどちらを配備するかに関しての検討項目をまとめています。

表 2–1 総所有コスト (TCO) の検討

ハードウェアの選択 

利点 

欠点 

数を多くした小規模なハードウェアシステム 

  • 小規模なハードウェアシステムは一般にコストが低くなります。

  • 数を多くした小規模なハードウェアシステムは多くの拠点に配備が可能で、分散型ビジネス環境をサポートします。

  • 数を多くした小規模なハードウェアシステムでは、サーバーが保守のため停止している場合でも、トラフィックを別のサーバーにルーティングすることでシステム保守やアップグレード、移行のための停止時間を短縮することが可能です。

  • ハードウェアシステムは小規模であればあるほど能力が限定され、必要な数が増えます。維持、管理、および保守のコストはハードウェアシステムの数が増えるにつれて増大します。

  • 数を多くした小規模なハードウェアシステムでは管理台数が多いため、管理の手間が増大します。

少数の大規模ハードウェアシステム 

  • 少数の大規模ハードウェアシステムでは、サーバーごとの固定管理コストが少なくなります。管理コストが、内部または ISP からに関係なく、毎月定期的に請求される場合、管理するハードウェアシステムが少数なのでコストが低くなります。

  • ハードウェアシステムの数が少ないということは、保守が必要なシステムの数が少ないため、保守、アップグレード、移行の作業が容易になります。

  • 大規模なハードウェアシステムでは、通常、導入時のコストが大きくなります。

  • 少数のハードウェアシステムでは、保守、アップグレード、移行のための停止時間も長くなります。

第 3 章 製品の要件と考慮事項について

この章では、配備設計に影響を与える要件と考慮事項について説明します。Communications Services アーキテクチャーを的確に決定するためには、これらの要件と考慮事項を理解する必要があります。

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

さまざまなコンポーネントの計画

Communications Services の配備アーキテクチャーを設計する場合、配備に使用するさまざまなコンポーネントの要件を考慮する必要があります。たとえば、Communications Services をほかの Java システム製品に統合するための技術要件がある場合は、対応するスキーマを選択する必要があります。同様に、たとえば、Communication Service が Directory Server にアクセスし、負荷を配置する方法などの製品間の依存性によって配備を選択する必要があります。

各製品の個々のコンポーネントを理解することにより、要件に最適なアーキテクチャーの種類を計画することができます。配備に応じて、次のコンポーネントの基本を理解し、計画する必要があります。

サービスコンポーネントとサービス層の理解

複数のコンポーネント製品またはサービスを利用する Communications Services の配備を計画する場合、各コンポーネント製品 (またはサービス) 自体の構成を理解する必要があります。

図 3–1 は、別個のホストに配備できるコンポーネントに各サービスを分割する方法と、各コンポーネントが占める特定の層を示しています。単一のホストにすべてのコンポーネントを配備したり、同一のホストに特定のサービスのコンポーネントを配備したりすることもできますが、Tier (層) アーキテクチャーに移行することを検討してください。Tier (層) アーキテクチャーには、単一層の場合でも 2 層の場合でも多くの利点があります。詳細については、「単一層アーキテクチャーの利点」および 「2 層アーキテクチャーの利点」を参照してください。

図 3–1 Communications Services のコンポーネント

この図は、さまざまな Communications Services のクライアント、アクセス、およびデータコンポーネントを示します。

この図では、クライアントコンポーネントは Outlook Connector プラグイン、Evolution などの thick クライアント、ブラウザ、および標準電子メールアプリケーションで構成されます。これらのコンポーネントは、エンドユーザーのクライアントコンピュータに配置されます。アクセス層のコンポーネントは、Messaging Server (MMP、MTA、MEM) 、Calendar Server、Communications Express (MEM と連結する必要がある)、Instant Messaging (Instant Messaging Proxy)、Portal Server (SRA および Core)、認証用の Access Manager、およびアドレス帳の検索を提供するコーポレートディレクトリのフロントエンドサービスで構成されます。データ層のコンポーネントは、Directory Server (本来はフロントエンドおよびバックエンドのコンポーネントから構成できる)、Messaging Server (メッセージストア)、Calendar Server (カレンダストア)、および Instant Messaging のバックエンドサービスで構成されます。SAN (Storage Area Network) の「雲形模様」は物理データストレージを表します。

注 –

この図で示されるコーポレートディレクトリは、コンポーネント製品そのものではありません。これは、クライアントがアドレス帳形式の検索を行うために、企業が通常アクセス層に配備するコーポレートディレクトリの「コピー」を表しています。

次の節では、これらのさまざまなコンポーネントを詳細に説明します。

LDAP ディレクトリ情報ツリーの要件

ディレクトリ情報ツリー (DIT) は、ドメイン、サブドメイン、ユーザー、およびグループを表すノードを使用して、ディレクトリエントリをツリー構造またはスキーマ に編成するための方法です。Sun Java Enterprise System では、1 ツリー構造を実装することにより、ディレクトリを構造化する方法の基本的な変更が行われています。

DIT 構造の変更

Messaging Server と Calendar Server は 1 ツリー構造を導入しており、この構造にはドメインコンポーネント (DC) ツリーがありません。すべてのドメイン情報が組織ツリーのドメインノードに保持されます。新しい 1 DIT 構造では、エイリアスはまったく異なる方法で処理されます。

図 3–2 の下半分では、1 ツリー LDAP 構造を示しています。

図 3–2 2 ツリー LDAP 構造と 1 ツリー構造との比較

この図では、Messaging Server 6.0 で導入された 1 ツリー LDAP 構造と以前の 2 ツリー構造とを比較します。

1 ツリー DIT 構造の利点

1 ツリー構造のスキーマ 2 ネイティブモードを使用する主な利点は次のとおりです。

次の図に示されているとおり、2 ツリー構造では一部のノードが組織ツリーのノードを直接指定しています (inetDomainBaseDN 属性を使用)。そのほかのノードは、組織ツリーノードを直接指定する代わりに、aliasedObjectName 属性を使用して別の DC ツリーノードを指定するエイリアスノードです。

図 3–3 aliasedDomainName と inetDomainBaseDN を持つ 2 ツリーエイリアス

この図は、aliasedObjectName が設定された 2 ツリー LDAP を示します。

この図では、DC ツリーの sesta.com は、aliasedObjectName を使用して DC ツリーの siroe.com を指定し、siroe.com は、inetDomainBaseDN を使用して組織ツリーの同様の名前が付けられたノードを指定します。

さらに、図 3–4 に示されるように、DC ツリーには、inetDomainBaseDN を使用して組織ツリー内の同じノードを直接指す 1 つまたは複数のノードが存在する可能性があります。この場合、「実際」のドメイン名 (メールが実際に配置され、メールがルーティングされるドメイン) を指定するために、DC ツリーノードのいずれかに「連結遮断」属性 inetCanonicalDomainName が必要になります。

図 3–4 inetCanonicalDomainName 属性を持つ 2 ツリーエイリアス

この図では、inetCanonicalDomainName を使用して同じ組織ツリーノードを指している 2 つの DC ツリーノードがある 2 ツリー LDAP を示しています。

それに対して、下図に示すように 1 ツリー構造は組織ツリーのみで構成されます。

図 3–5 associatedDomain を持つ 1 ツリーエイリアス

この図は、Sun ONE スキーマ, v.2 でエイリアスの処理を行う簡単な方法を示しています。

1 ツリー構造では、以前 DC ツリーにあったすべてのドメイン属性が組織ツリーのドメインノードに含まれます。各ドメインノードは、sunManagedOrganization オブジェクトクラスと、DNS ドメイン名を含む sunPreferredDomain 属性によって識別されます。また、ドメインノードは、このドメインを識別するエイリアス名をリスト表示する 1 つまたは複数の associatedDomain 属性を持つことができます。2 ツリー構造とは反対に、エイリアス名の重複ノードはありません。

1 ツリー DIT 構造は、組織固有のアクセス制御のためのデータを区分する方法として役立ちます。つまり、各組織は、ユーザーおよびグループエントリが配置される独立したサブツリーを DIT に持つことができます。このデータへのアクセスは、そのサブツリーの一部にあるユーザーに制限されます。これにより、ローカライズされたアプリケーションを安全に実行することができます。

さらに、Calendar Server または Messaging Server の新しい配備では、1 ツリー構造の方が、既存の単一の DIT LDAP アプリケーションに、より適切にマッピングされます。

スキーマの要件

どの Communications Services 製品をインストールする場合でも、使用するスキーマについて事前に理解しておく必要があります。スキーマとは、ディレクトリのエントリとして格納できる情報の種類を説明する一連の定義です。Communications Services では、Sun JavaTM System LDAP スキーマ 1 と Sun JavaTM System LDAP スキーマ 2 の 2 つのスキーマが選択肢としてあり、サポートされています。次の基準に従って、スキーマを選択します。

次の場合にスキーマ 2 を使用します。

注 –

SSO を提供するために Access Manager 6 を使用する必要はありません。スキーマ 2 を選択しても、Access Manager 6 に依存しない信頼できるサークルタイプの SSO を使用することができます。

次の場合にスキーマ 1 を使用します。

スキーマ選択の詳細については、第 8 章「スキーマとプロビジョニングのオプションについて」を参照してください。

Directory Server の考慮事項

Sun Java System Directory Server は、イントラネット、ネットワーク、およびエクストラネット情報用に、柔軟性のある複数層データストレージを提供します。Directory Server は既存のシステムを統合し、社員、顧客、供給業者、およびパートナー情報を統合する中央リポジトリとして機能します。Directory Server を拡張して、ユーザープロファイルおよび設定とともに、エクストラネットユーザーの認証を管理することができます。

Portal Server、Access Manager、Messaging Server、Calendar Server、Instant Messaging のスキーマなど、すべてのカスタム LDAP スキーマは単一のディレクトリにインストールされます。

ビジネスの目的と予想される使用パターンに応じて、データ環境を設計する数多くの方法と、考慮すべき数多くの要素があります。ディレクトリ設計は次の領域に対処する必要があります。

データ環境を設計する方法に関するこれらの要素や提案の詳細な説明については、『Sun Java System Directory Server 5 2005Q1 Administration Guide』を参照してください。

Directory Server と Tier (層) アーキテクチャーの考慮事項

単一層アーキテクチャーから複数層アーキテクチャーへの移行では、まず Directory Server を専用のマシンに「分割」する必要があります。負荷が一定の量を超えると、同じホストの Directory Server と Messaging Server は特有のパフォーマンスの影響を受けます。これは、Messaging Server が Directory Server で動作するように設計されることによります。Directory Server を専用のマシンに分離することが、配備のパフォーマンスを向上させる最初の手順です。

層アーキテクチャーの詳細については、第 5 章「Communications Services 論理アーキテクチャーの開発」を参照してください。

注 –

Directory Server は、ディレクトリユーザー管理とソフトウェアアプリケーション設定とを明確に区別してインストールすることが可能です。このアーキテクチャーには 2 つのディレクトリが存在します。1 つはディレクトリホスト上のユーザーおよびグループ用ディレクトリ、もう 1 つは別のホスト上の設定ディレクトリです。ソフトウェアアプリケーション設定の部分を削除する必要がある場合、こうした区別をしておいたほうが、Directory Server から情報を削除する作業が容易になります。

Directory Server のトポロジの考慮事項

単一マシンにインストールした Directory Server のインスタンスに配備を構築することは可能ですが、その他の Communications Services コンポーネントもコアサービスとして機能するディレクトリサーバーに依存します。したがって、通常の配備をするのではなく、冗長性のある可用性の高い構成の Directory Server の配備を計画する必要があります。

Directory Server の可用性を高めるための最初の手順は、マスターディレクトリサーバーのペアを確立することです。次に、マルチマスターレプリケーションを使用して、LDAP の書き込みスループットと可用性を向上させます。Sun Cluster を高可用性配備で使用する場合、2 つの LDAP マスターがクラスタ化されます。詳細については、「Directory Server と高可用性」を参照してください。

Directory Server の容量計画

Directory Server の容量計画には確立された規則はありませんが、パフォーマンス測定基準に適合するかどうかを確認するためにディレクトリサーバーを注意深く監視することは非常に重要です。システムがこれらの測定基準に適合しない場合は、増設ディレクトリコンシューマを追加します。通常、次の点を監視します。

目標応答時間 (10 ミリ秒) に対する上記測定値を評価します。IOWAIT は 10 ミリ秒を超えてはなりません。また、この層での CPU 利用率の合計が 70% を超えてはなりません。

Directory Server と Calendar Server の相互作用に関する考慮事項

Calendar Server は、Directory Server に格納されるユーザーエントリに対して複数の書き込みを行います。これらの大量の書き込みは、ユーザーが最初に Calendar Server にログインするときとユーザーが特定のアクションを実行するときに発生します。これらのアクションには、カレンダの作成、カレンダへの登録、設定の変更などがあります。これらのアクションを考慮しないと、Directory Master Server に大きな負荷を与える可能性があります。

ディレクトリのレプリケーションを使用する場合、LDAP Master Server は LDAP 複製サーバーにエントリを複製します。Calendar ユーザーがこれらのアクションのいずれかを実行する場合、Calendar Server は Master Directory Server への変更の書き込みだけを行うことができます。これはレプリカが読み取り専用のためです。

2 番目の相互作用に関する考慮事項は、これらの複製されたディレクトリ構造の中にあります。ユーザーが設定を変更する場合、Master Directory Server から Calendar Server が使用する Directory Replica に正しく複製されるまで、これらの変更は正常に表示されません。この応答遅延を防止するために、Calendar Express (cshttpd) がローカルに変更をキャッシュするように設定して、この問題を回避することができます。詳細については、「Calendar Server LDAP データキャッシュの計画」を参照してください。

Directory Server と個人アドレス帳に関する考慮事項

Messenger Express クライアントは、個人アドレス帳 (PAB) の概念をサポートします。これにより、ユーザーは Directory Server に個人用連絡先 (たとえば、業務用連絡先、友人、家族など) を格納することができます。ユーザーの PAB に新しい個人用連絡先が追加されるごとに、Directory Server に書き込みが行われます。これらのアクションを考慮しないと、ディレクトリレプリケーションの方針とは関係なく LDAP Master Server に大きな負荷を与える可能性があります。

User and Group Directory Server 上のパフォーマンスの問題を解決する 1 つの方法は、PAB 情報を別の Directory Server に配置することです。これにより、PAB の相互作用が LDAP Master Server に負荷を配置しなくても済むようになります。

注 –

現在の Communications Express クライアントと、非推奨の Messenger Express Web メールインタフェースの両方を実行している場合、これら 2 つのクライアントが使用するアドレス帳は情報を共有しません。2 つのクライアントインタフェースがエンドユーザーによって切り替えられる場合、2 つのアドレス帳には異なるエントリが含まれます。

Messaging Server の考慮事項

Communications Services の開発では、次の Messaging Server コンポーネントのパフォーマンスを評価する必要があります。

これらのコンポーネントのパフォーマンスと可能なハードウェアソリューションの詳細については、「Messaging Server アーキテクチャーのパフォーマンスの考慮事項」を参照してください。

Calendar Server の考慮事項

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

スケーラブルな 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 または Veritas のような HA ソリューションに適したシステムではありません。さらに、そのようなソリューションを使用する際のハードウェアの追加や管理オーバーヘッドにより、HA の Calendar Server フロントエンドへの配備のコストと時間がかかります。

注 –

本来の HA ソリューションを保証する Calendar フロントエンドの唯一の構成は、Messaging Server MTA ルーターを含む同じホストに Calendar フロントエンドを配備している場合です。ただし、この構成でも、そのようなソリューションのオーバーヘッドについては、利点がわずかなことからして、注意深く比較検討する必要があります。

Calendar Server フロントエンドのハードウェアの適切な選択は、シングルプロセッササーバーまたはデュアルプロセッササーバーです。プロセッサごとに Calendar Server cshttpd プロセスのインスタンスを 1 つ配備します。そのような配備によってコスト効率の良いソリューションが提供され、一定レベルの初期のクライアント並行性機能から開始し、ピーク使用率レベルがわかるにつれ、既存の構成にクライアントセッション機能を追加していくことができます。

複数のフロントエンドを配備する場合、フロントエンドサービス全体に負荷を分散するにはスティッキー接続や持続的接続を備えるロードバランサが必要です。

注 –

Communications Express は 2 つのプロセッサを超えては拡大されません。以前に Calendar Server で説明した同じハードウェアの選択肢が、Communications Express の配備にも適用されます。

Calendar Server バックエンド サービスは、リソースの消費で十分にバランスが取れているので、CPU あるいはディスクまたはネットワークなどの I/O のいずれにおいても、ボトルネックが形成されるという証拠はありません。このため、バックエンドのハードウェアな適切な選択は、1 つのストライプボリュームを備える SPARC サーバーになります。そのようなマシンはピーク時の大量のカレンダ負荷に対してかなりの容量を提供します。

要件の中に高可用性がある場合、バックエンドには持続的データが含まれているので、Calendar Server バックエンドを Sun Cluster で配備するのが妥当です。

注 –

フロントエンドおよびバックエンドの Calendar Server ホストの両方を持つ構成では、すべてのホスト上で次のソフトウェアが動作している必要があります。

Instant Messaging の考慮事項

ほかの Communications Services コンポーネントと同様に、Instant Messaging をフロントエンド (Instant Messaging マルチプレクサ) とバックエンド (サーバーとストア) に分割するアーキテクチャーを構成することができます。詳細については、「Instant Messaging アーキテクチャー戦略の構築」を参照してください。

Portal Server の考慮事項

Portal Server を持つ Communications Services 製品をインストールして、メッセージング、カレンダ、インスタントメッセージングアプリケーションにアクセスする「傘型」フロントエンドを提供します。Portal Server の統合には、Portal Server 、Calendar Express Web クライアント、Messaging Express Web クライアント、Communications Express クライアント間のシングルサインオン機能が含まれます。さらに、ユーザーは、Portal Server デスクトップを使用して、Messaging Express、Calendar Express、および Instant Messaging クライアントを利用することができます。

詳細については、『Sun Java System Portal Server 6 2005Q4 Deployment Planning Guide』および『Sun Java System Access Manager 7 2005Q4 Deployment Planning Guide』を参照してください。

Connector for Microsoft Outlook の考慮事項

この節では、Connector for Microsoft Outlook の配備の際に発生するいくつかの配備問題について説明します。詳細については、次の Web サイトの Connector for Microsoft Outlook のマニュアルを参照してください。

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

Sun Java System Connector for Microsoft Outlook は、Outlook を Sun Java Enterprise System のデスクトップクライアントとして使用できるようにします。Connector for Microsoft Outlook は Outlook のプラグインで、エンドユーザーのデスクトップにインストールする必要があります。Connector for Microsoft Outlook は、Messaging Server にフォルダの階層と電子メールメッセージを照会します。次に、この情報を Outlook が表示できる MAPI (Messaging API) プロパティに変換します。同様に、WCAP プロトコルを使用して Calendar Server に予定と作業を照会し、MAPI プロパティに変換します。このモデルによって、Connector for Microsoft Outlook は 2 つの別個の情報源からエンドユーザーの Outlook 表示を作成します。情報源の 1 つは Messaging Server のメールで、もう 1 つは Calendar Server のカレンダ情報です。

ユーザーが Outlook を使用して項目を作成および変更する場合、Connector for Microsoft Outlook は新しいメッセージをメッセージ形式に応じて適切なサーバーに渡します。送信電子メールは SMTP メールサーバーに送信されて配信され、変更された電子メールメッセージはユーザーの IMAP フォルダに返送されて格納されます。新しいカレンダの予定および作業は標準的な形式に変換されて、Calendar Server データベースに格納されます。

Connector for Microsoft Outlook コンポーネント製品の依存性

Connector for Microsoft Outlook を使用するには、同一の配備に Messaging Server と Calendar Server が必要です。サポートされるバージョンに関する詳細については、これらの製品のリリースノートを参照してください。

Connector for Microsoft Outlook を正常に機能させるには、全体のパフォーマンスを向上させるために、次の Sun Java System Directory Server の LDAP 属性に少なくとも実在と等価のインデックスを付ける必要があります。

製品の依存性の完全なリストについては、『Sun Java System Communications Services 2005Q4 リリースノート』の第 6 章「Microsoft Outlook 版 Sun Java System Connector 7 2005Q4 リリースノート」を参照してください。

Sun ONE Calendar Server データの移行

Sun ONE Calendar Server 6.0 以前の Calendar Server のバージョンを使用している場合は、Sun Client Services を利用して、データを新しい形式に変換し、移行する必要があります。この Calendar Server データの移行は Outlook を使用するために必要です。また、ストレージの基本的な変更と繰り返される予定の管理のために必要になります。新たな Sun Java System Calendar Server の顧客は、移行サービスは必要ありません。

Exchange Server データの移行

Connector for Microsoft Outlook は、Exchange Server の Microsoft Exchange Server メッセージを変換しません。Sun Client Services を利用してデータを変換する必要があります。

Communications Express の考慮事項

Sun Java System Communications Express は、通信およびコラボレーション用の Web ベースの統合クライアントです。Communications Express は Messaging Server と Calendar Server の共通ソフトウェアであり、カレンダ情報、メール、およびアドレス帳に対する Web インタフェースをエンドユーザーに対して提供します。

Communications Express は、カレンダ、アドレス帳、およびメールの 3 つのクライアントモジュールで構成されます。カレンダとアドレス帳のクライアントモジュールは、Web コンテナ上の単一アプリケーションとして配備されます。Messenger Express は、Messaging Server の HTTP サービスを使用する、スタンドアロンの Web ベースのメールアプリケーションです。Messenger Express は、Communications Express と同じシステム上に配備する必要があります。

Communications Express は次の Sun Java System コンポーネント製品に依存します。

S/MIME の考慮事項

Communications Express Mail では、S/MIME (Secure/Multipurpose Internet Mail Extension) のセキュリティ機能が利用可能です。S/MIME を使用するように設定された Communications Express Mail ユーザーは、ほかの Communications Express Mail ユーザーや Microsoft Outlook メールシステムのユーザーと、署名または暗号化されたメッセージを交換できます。

詳細については、「Communications Express メールで S/MIME を使用するための要件」を参照してください。

第 4 章 ネットワークインフラストラクチャーに対するニーズの決定

ネットワークインフラストラクチャーはシステムの根本的な基盤です。ネットワークインフラストラクチャーが形成する各サービスによってネットワークの動作構造が作り出されます。Communications Services の配備で、プロジェクトの目標を基準にネットワークインフラストラクチャーを決定することで、拡大縮小や拡張が可能なアーキテクチャーを確保できます。

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

既存ネットワークの理解

既存のネットワークインフラストラクチャーを理解して、それが配備の目標をどの程度満たすものであるかを判断する必要があります。既存のインフラストラクチャーを調査することで、既存のネットワークコンポーネントをアップグレードしたり、新規のコンポーネントを購入したりする必要があるかどうかがわかります。次の領域を調査して、既存のネットワークの完全な全体像を構築する必要があります。

  1. ケーブルの長さ、グレードなどの物理的な通信リンク

  2. アナログ、ISDN、VPN、T3 のような通信リンクと、サイト間で利用可能な帯域幅と待ち時間

  3. 次のサーバーの基本情報

    • ホスト名

    • IP アドレス

    • ドメインメンバー用のドメインネームシステム (DNS) サーバー

  4. 次に挙げるデバイスのネットワーク上の場所

    • ハブ

    • スイッチ

    • モデム

    • ルーターとブリッジ

    • プロキシサーバー

  5. モバイルユーザーを含むそれぞれのサイトのユーザー数

この調査結果一覧を完成させた後で、プロジェクトの目標に照らしてその情報を再検討し、配備を成功させるにはどのような変更が必要であるかを判断します。

ネットワークインフラストラクチャーの理解

次の代表的なネットワークインフラストラクチャーコンポーネントは、配備の成否に直接影響します。

ルーターとスイッチ

ルーターはインフラストラクチャーのネットワークを接続して、システム間の通信を可能にします。配備後のルーターの能力には余力を持たせて、プロジェクトの拡大とそれに伴う処理の増加に備える必要があります。

スイッチは、血管のようにネットワーク内のシステムを接続します。

フル稼働状態のルーターやスイッチはボトルネックとなる可能性があり、クライアントが別のネットワーク上にあるサーバーにメッセージを送信するのにかなり長い時間がかかる結果となります。そのような場合には、先見性の欠如や、ルーターやスイッチをアップグレードする資金の欠乏から、そのコスト以上に個人の生産性が低下してしまうこともあります。

ファイアウォール

ファイアウォールは、ルーターとアプリケーションサーバーの間に位置し、アクセス制御を行います。ファイアウォールは本来、信頼されていないネットワーク (インターネット) から信頼済み (内部) ネットワークを保護するものです。現在ではより一般的に、外部ネットワークやインターネットなどの信頼されていないネットワークから、信頼済みまたは隔離された自己のネットワーク上のアプリケーションサーバーを保護する目的で使われています。

ルーターの設定を行うことで、ファイアウォールを通過するデータのスクリーニングを行い、ファイアウォール全体の機能が強化されます。ルーターの設定により、NFS や NIS のような好ましくないサービスをブロックし、パケットレベルのフィルタリングを使用して信頼されていないホストやネットワークからの通信をブロックできます。

さらに、インターネットまたは信頼されていないネットワークに開放されている環境に Sun サーバーをインストールするときに、アプリケーションをホストするのに必要な最小限の数まで、Solaris ソフトウェアのインストールパッケージを減らすことができます。サービス、ライブラリ、およびアプリケーションの数を最小化することにより、保守が必要なサブシステムの数が減少し、セキュリティーの向上につながります。SolarisTM Security Toolkit は、Solaris システムを最小化し、強化し、セキュリティー保護されたシステムにするための、柔軟性と拡張性に富んだメカニズムを提供します。

サイトのセキュリティーポリシーで、このような問題に対する対策を考慮する必要があります。

ロードバランサ

ロードバランサを使用して、Web サーバーまたはアプリケーションサーバー全体の負荷を分散するか、実行するタスクの種類に基づいて要求を分散します。さまざまな専用アプリケーションを異なるアプリケーションサーバーで使用しているような場合は、ユーザーが要求するアプリケーションの種類に応じてロードバランサを使用します。

データセンターが複数ある場合は、ロードバランサの地理的な分散も考慮する必要があります。地理的な負荷分散により、要求やサイトの能力、ユーザーとの距離に基づいて負荷の分散が行われます。1 つのセンターがダウンした場合は、地理的なロードバランサによりフェイルオーバー機能が提供されます。

Web ファーム上のロードバランサでは、サーバーの前とルータの後ろにロードバランサを配置して、トラフィックを適切なサーバーにルーティングします。ソフトウェア負荷分散ソリューションは、Web サーバーにインストールします。ソフトウェアによるソリューションでは、サーバーの 1 つが通常はトラフィックスケジューラとして機能します。

負荷分散ソリューションでは、受信したパケットのヘッダと内容を読み取ることができます。これにより、ユーザーや要求の種類を含むパケット内の情報の種類別に負荷分散を行うことができます。パケットヘッダを読み取る負荷分散ソリューションにより、権限のあるユーザーを識別し、特定のタスクを処理するサーバーに要求を送ることができます。

サービスを提供しているすべてのサーバーとの間で、ロードバランサが動的な通信をどの程度行なっているかを調査する必要があります。スケジューラはそれぞれのサーバーに ping を実行するか「ライブ」なエージェントをサーバー上で作成してロードデータを確認していますか。ロードバランサが TCP パケットをどのように解析しているかも調査する必要があります。そして、ロードバランサがパケットを処理するスピードにも注目します。ロードバランサの中には、他のロードバランサより効率性の高いものもあります。ロードバランサの効率性は、通常スループットで測定されます。

ストレージエリアネットワーク (SAN)

配備を成功に導くためには、ストレージシステムのデータ要件を理解することが必要です。SAN のシステムでは、ストレージをそれが使用されているサーバーから独立した形で配備することが多くなってきています。SAN のシステムを配備することで、ストレージデバイスを再配置することなくマシンを交換することができるため、機能しなくなったサーバーの回復に要する時間を短縮することができます。

次の質問を参考にして、SAN の導入により配備するストレージの要件が適切に達成されているかどうかを評価します。

DNS (Domain Name System、ドメインネームシステム)

DNS クエリの使用頻度が高いサーバーにはローカルキャッシング DNS サーバーを用意して、ルックアップによる待ち時間を短縮し、ネットワークトラフィックを減らします。

要件を決定する際には、メールストア、メールリレーイン、メールリレーアウトなどの機能別にホスト名を割り当てるようにします。すべてのホスト名が現在 1 台のマシン上でホストされている場合でも、このポリシーを考慮する必要があります。サービスをそのように構成しておくと、そのサービスを別のハードウェアに移すときに、変更に伴う影響をかなり小さくすることができます。

ネットワークインフラストラクチャーレイアウトの計画

インフラストラクチャーのトポロジを考えるときに、次の視点から検討を行う必要があります。

非武装地帯 (DMZ)

今日、ほとんどの企業ネットワークで DMZ が取り入れられています。DMZ により、企業ネットワークがインターネットから分離されます。DMZ は厳重に保護された領域で、Web サーバーのようなインターネットサービスと機能を提供するサーバーが配置されます。これらのマシンは、直面する攻撃に耐えられるように強化されています。そのような攻撃によりセキュリティーが破られた場合のエクスポージャーを制限するために、通常これらのサーバーには内部ネットワークに関する情報が含まれていません。たとえば、ネームサーバー機能には、インターネットに接続されたサーバーとルーターしか含まれていません。

さらに進んだ DMZ では、ファイアウォールのセキュリティーと機能がより強固になったことから、DMZ がファイアウォールの後ろのセグメントに移動されています。しかし、DMZ は依然として内部ネットワークからは分離されています。Web サーバー、FTP サーバー、メールサーバー、および外部 DNS をホストするすべてのマシンは、必ず DMZ セグメントに配置する必要があります。

単純なネットワーク設計では、インターネットサービス、VPN アクセス、およびリモートアクセスのための個別の DMZ セグメントだけを定義します。ただし、VPN アクセスとリモートアクセスのトラフィックにはセキュリティー上の問題が存在します。したがって、これらのタイプのトラフィックについては、それ以外のネットワークから分離された適切な接続が必要となります。

DMZ セグメントを提供するファイアウォールは、対応するサービスポートと DMZ 内でそのサービスを提供しているホストに宛てられたインバウンドパケットだけを許可するものでなければなりません。また、DNS やメールのようなサービスを提供するマシンは、そのサービスのためにインターネットにアクセスする必要がありますが、これらのマシンに対するインターネットへのアウトバウンドトラフィックを制限します。要求された接続のタイプにより、DMZ をインバウンド専用とアウトバウンド専用に分けることも 1 つの方法です。しかし、サービス拒否攻撃により DNS や電子メールサービスが妨害される可能性を考えると、インバウンドとアウトバウンド専用のサーバーに分けてこれらのサービスを提供することには検討の余地があります。電子メールベースのトロイの馬やワームにより、アウトバウンドメールサーバーが制御不能に陥り、オーバーランが発生した場合でも、インバウンドメールは受け取ることができます。DNS サーバーと同じアプローチを適用します。

イントラネット

DMZ は、インターネットへのサービスを提供するホストのためのネットワークセグメントを提供します。この設計により、内部ホストは外部からの攻撃にさらされるホストとは別のセグメントに置かれるため、保護されます。内部的には、内部ユーザーに限定された同様のサービス (Web、ファイルサーバー、内部 DNS など) を提供しています。インターネットサービスをセグメント化するのと同様に、内部サービスもセグメント化します。このような方法によるサービスの分離により、ルーターのフィルタリングでより緊密な制御を行うことができます。

インターネットに向けたサービスを DMZ で分離してセキュリティーを確保したように、私設内部サービスも独自の内部 DMZ 内に配置するべきです。また、ネットワークのサービスとサイズによっては複数の DMZ が有用なように、複数のイントラネットも同様に有用です。

セグメントを提供するファイアウォールの規則は、DMZ のファイアウォールに使用されるものと同様に構成する必要があります。インバウンドトラフィックは、内部メールサーバーに渡されるインバウンドメールのような DMZ からの情報をリレーするマシンと、内部ネットワーク内にあるマシンだけから送られてくるものでなければなりません。

内部ネットワーク

残りのセグメントが内部ネットワークセグメントを構成します。これらのセグメントには、ユーザーのマシンや部署で使用するワークステーションが含まれます。これらのマシンは、イントラネット内のホストからの情報を要求します。開発、ラボ、およびテストネットワークセグメントもこれに含まれます。各内部ネットワークセグメント間のファイアウォールを使用してトラフィックのフィルタリングを行い、部門間のセキュリティーをさらに強化します。これらのセグメント上で使用される内部ネットワークトラフィックとサービスのタイプを識別して、内部ファイアウォールが有効であるかどうかを判断します。

内部ネットワーク上のマシンは、インターネット上のマシンと直接通信してはいけません。これらのマシンでは、DMZ 内のマシンとの直接通信を避けた方が賢明です。これらのマシンが要求するサービスがイントラネット上のホストにあれば理想的です。一方で、イントラネット上のホストは DMZ 内のホストと通信を行なって、電子メールのアウトバウンドや DNS などのサービスを完了することができます。このような間接的な通信であれば問題はありません。

プロキシ

DMZ 内には、インターネット上のマシンと直接通信を行うマシンだけを配置する必要があります。ユーザーがインターネットへのアクセスを要求した場合は、以前のトポロジに基づいた問題が発生します。このような場合は、プロキシが有効です。内部ネットワークセグメントに、またはさらに望ましいのはイントラネットセグメントにプロキシを配置します。インターネットにアクセスする必要のあるマシンは、要求をプロキシに渡し、プロキシがそのマシンに代わって要求を実行します。インターネットへのこのリレーにより、マシンが直面する可能性のある危険を防ぐことができます。

プロキシはインターネット上のマシンと直接通信を行うため、DMZ 内に配置する必要があります。ただしこれは、内部のマシンが直接 DMZ 内のマシンと通信を行うのを防ぐという意図と矛盾します。この通信を間接的なものにするために、二重のプロキシシステムを使用します。イントラネット内の二次プロキシは、内部マシンの接続要求を DMZ 内のプロキシに渡し、そこでインターネットへの直接接続が行われます。

ファイアウォールの設定

通常のパケットフィルタリング機能のほかに、ほとんどのファイアウォールには IP スプーフィングを防ぐ機能もあります。可能な限り IP スプーフィング保護機能を使用してください。

たとえば、インターネットから内部ネットワークへのエントリポイントが 1 つだけで、インターネットからのパケットに内部マシンの発信元アドレスがある場合、それはおそらくスプーフされたものです。ネットワークのトポロジに基づいて、内部マシンの発信元アドレスを持つパケットは、インターネットからではなく内部ネットワークから発信されたものでなければなりません。IP スプーフィングを防ぐことでこのような可能性はほとんどなくなり、IP アドレスベースの認証をすり抜けることも困難になるため、他のファイアウォールの規則を減らすことができます。内部ファイアウォールにも同様の IP スプーフィング対策を行います。

モバイルユーザー

リモートユーザーまたはモバイルユーザーに対しては、どのようにアクセス手段を提供するかを検討する必要があります。そのようなユーザーがアクセスできない手段があるでしょうか。どのようなタイプのセキュリティーポリシーを必要としていますか。SSL による認証が必要ですか。また、モバイルユーザーの数にほとんど変化がないか、今後増加するのかについても検討します。

第 5 章 Communications Services 論理アーキテクチャーの開発

この章では、Communications Services 論理アーキテクチャーを開発する方法について説明します。論理アーキテクチャーとは、Communications Services コンポーネントとそれらをサポートするために必要なインフラストラクチャーサービスの論理構築ブロックを記述した設計のことです。

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

Communications Services 配備の論理アーキテクチャーの概要

Communications Services を単一層または 2 層論理アーキテクチャーのいずれかに配備することができます。論理アーキテクチャーの特定は、必要なマシンのタイプと台数を左右するため、非常に重要です。

通常、一般企業への配備では単一層アーキテクチャーが使用され、インターネットサービスプロバイダ (ISP) や電気通信会社への配備では 2 層アーキテクチャーが使用されます。ただし、一般的な場合と同じように例外が存在します。小規模な ISP が単一のマシンに配備することがあり、大規模な中央集中型の企業が、多くの場合 ISP が配備するのと同じ理由で 2 層アーキテクチャーに配備することもあります。遠隔地で働く社員のアクセスを容易にする企業が増えるほど、企業の配備も ISP と同様のものになっていきます。

この節では、次の Communications Services 論理アーキテクチャーについて説明します。

Communications Services を単一層アーキテクチャーと複数層アーキテクチャーのどちらで配備するかにかかわらず、両方のモデルの長所と短所を理解する必要があります。

単一ホスト用の単一層論理アーキテクチャー

その名前が示すように、単一ホスト用の単一層論理アーキテクチャーは、すべてのサービスを単一のマシンに配置します。通常、このアーキテクチャーは次のような企業に最適です。

次の図は、単一ホスト用の単一層論理アーキテクチャーを示します。

図 5–1 単一ホスト用の単一層アーキテクチャー

この図は、単一ホスト用の単一層論理アーキテクチャーを示します。

Outlook、Messenger Express などのエンドユーザークライアントプログラムがユーザー層を形成します。層 1 は、メッセージング、カレンダ、インスタントメッセージング、ディレクトリなどすべてのサービスを実行する単一のマシンです。Communications Express を配備する場合、Web サーバー (またはアプリケーションサーバー) も、この単一マシン上で実行されます。単一層配備の特徴は、エンドユーザーがプロキシやほかのエージェントを介さずに直接ストアと通信することです。

単一ホスト用の単一層論理アーキテクチャーでは、十分な CPU、メモリー、およびストレージを備えるマシンが必要になります。このタイプの配備に対する組織のニーズに最も適合したマシンを決定するには、Sun の販売代理店と共同で作業を行う必要があります。

単一ホスト用の単一層論理アーキテクチャーを実装する場合、サービスに論理名を割り当てることによって複数層アーキテクチャーに拡張できるように配備を構成することができます。この構成は、DNS マッピングを利用して、ユーザーが同一のフロントエンドプロセス (マシン) を使用するように指示します。将来、サービスを Tier (層) 方式に分割するなど、拡大に対応するための変更が必要になった場合、ユーザーはクライアントアプリケーションを再設定する必要がありません。詳細については、「論理サービス名の使用」を参照してください。

複数ホスト用の単一層論理アーキテクチャー

複数ホスト用の単一層論理アーキテクチャーは複数のサーバーから構成され、各サーバーがコンポーネント製品に特定のサービスを実行します。たとえば、Messaging Server ホストはすべての Messaging Server サービスを実行するようにインストールおよび設定され、Calendar Server ホストはすべての Calendar Server サービスを実行するようにインストールおよび設定されます。ほかのホストも同様になります。このアーキテクチャーは高可用性を確保するために設定される場合もあります。

単一層論理アーキテクチャーの特徴は、エンドユーザーがプロキシやほかのエージェントを介さずに直接データストアと通信することです。たとえば、Messaging Server では、ユーザーは MMP または MTA を経由せずにルーティングされます。単一層論理アーキテクチャーは、サーバー間のメールのルーティングまたは企業ネットワークへの出入りにスタンドアロン MTA ルーターを使用する場合がありますが、エンドユーザーはユーザーのメッセージストアの MTA にメールを送信します。MMP はメッセージストアへのイントラネット接続には関与しません。

同じ考え方が Calendar Server と Instant Messaging の両方に当てはまります。単一層論理アーキテクチャーでは、フロントエンドプロセスは別個のマシンには配置されません。

図 5–2 は、複数ホスト用の単一層論理アーキテクチャーを表しています。

図 5–2 複数ホスト用の単一層アーキテクチャー

この図は、複数ホスト用の単一層アーキテクチャーを示します。

この図では、Outlook、Messenger Express などのエンドユーザークライアントプログラムがユーザー層を形成します。層 1 は 4 種類のサーバーのセットです。1 番目のサーバーは Calendar Server プロセスを実行し、2 番目は Messaging Server プロセスを実行し、3 番目は Instant Messaging プロセスを実行し、4 番目は Directory Server プロセスを実行します。Communications Express を配備する場合は、Messaging Server のホストに Web メール用の Web サーバー (Web Server または Application Server) も含まれます。

単一層分散論理アーキテクチャー

単一層分散論理アーキテクチャーは、単一層アーキテクチャーの変形で、2 つの層に Directory Server が配備されています。この形式の配備は、地理的に分散した小規模な部門または組織を持つ企業に適しています。各部門またはオフイスは、独自のサービス (メール、カレンダ、インスタントメッセージング) とローカルディレクトリインスタンス (コンシューマ) を持ちます。すべてのローカルディレクトリインスタンスがキャッシュされますが、集中化された企業マスターリポジトリとは同期します。この配備は、低帯域幅の接続を使用するオフイスでは一般的なシナリオです。ディレクトリは 2 層形式で設計され、データをローカルに保持するために低帯域幅を経由して複製されます。

図 5–3 は、単一層分散論理アーキテクチャーを表しています。

図 5–3 単一層分散アーキテクチャー

この図は、単一層分散論理アーキテクチャーを示します。

この図では、Outlook、Messenger Express などのエンドユーザークライアントプログラムがユーザー層を形成します。層 0 は、層 1 を通じて負荷を分散するロードバランサを構成します。層 1 は、Communications Services プロセスの複数サーバーのセットです。複数のサーバーが Calendar Server サービスを実行し、複数のサーバーが Messaging Server サービスを実行し、複数のサーバーが Instant Messaging サービスを実行します。Directory Server は、ローカルの複製されたディレクトリのコピーを実行する層 1 のコンシューマサーバーとディレクトリのマスターコピーを持つ層 2 のもう 1 つのサーバーに分割されます。この配備形式では、クライアントの照会はマスターコピーではなく、ローカルのディレクトリコピーに送信されることに注意してください。ローカル Directory Server だけが、マスター Directory Server と通信します。

注 –

インターネット接続を使用する単一層アーキテクチャーを配備する場合は、別のアクセス層を使用します。たとえば、SSL を使用せずにイントラネット内部からデータストアにアクセスするように指示します。ただし、インターネットからデータストアにアクセスする場合は、SSL を介するアクセス層を経由するように指示します。これにより、インターネットから分離されたアクセス層に、データストアの SSL 負荷の大部分がオフロードされます。

この形式の配備の欠点は、企業のイントラネット上のサーバーを利用したり、インターネットからサーバーにアクセスしたりするユーザーが常時 SSL を使用するようにクライアントアプリケーションを設定する必要があることです。これは、SSL の有効、無効を切り替える手間が非常にかかるためです。このため、かなりの割合の SSL トラフィックがストアに直接接続されることになります。イントラネット内部のアクセス層を利用することによって、この問題を解消し、接続の方向を制限することによって、不正なアクセスからイントラネットを保護することができます。

2 層論理アーキテクチャー

2 層論理アーキテクチャーでは、データストアはフロントエンドプロセスを経由して通信します。つまり、Messaging Server の場合、MMP、MEM、および MTA がデータストアプロセスとは別のマシンに配置されることを意味します。2 層アーキテクチャーを使えば、メールストアは重要な共通タスクの負荷が軽減され、メールの受信と配信に集中することができます。Calendar Server の場合、HTTP サービスと管理サービスがストアプロセスと別のマシンに配置されることを意味します。Instant Messaging の場合、プロキシサービスがバックエンドプロセスと別のマシンに配置されることを意味します。

いくつかのレベルで、ほかのサーバーとの共存が可能です。たとえば、同一のマシンにカレンダストアとメッセージストアを配置することができます。同様に、MMP マシンにカレンダのフロントエンドを配置することができます。

2 層論理アーキテクチャーでは、Directory Server は通常、負荷分散された一連のコンシューマディレクトリに対するマルチマスターとレプリケーションを持つため、それ自体が複雑な配備となります。

図 5–4 は、2 層論理アーキテクチャーを表しています。

図 5–4 2 層アーキテクチャー

この図は、2 層論理アーキテクチャーを示します。

上図では、Outlook、Messenger Express などのエンドユーザークライアントプログラムがユーザー層を形成します。ロードバランサが層 0 を形成します。Calendar Server、Messaging Server、Instant Messaging、Web プロキシ/MEM のフロントエンドが層 1 を形成します。最後に、Directory Server、Calendar Server、Messaging Server、Instant Messaging のバックエンドが層 2 を形成します。Communications Express を配備する場合は、Web サーバーも層 2 に配置できます。

2 層アーキテクチャーでは、層 1 と層 2 の要素を独立したインスタンスとして配備できるため、設計全体の柔軟性が高まります。さらに、個々のインスタンスに別々の機能を割り当てることにより、システムのセキュリティーを強化することができます。

通常の配備では、メッセージングとカレンダフロントエンドをネットワークの非武装地帯 (DMZ) に配置し、ファイアウォールを経由してメインのメッセージングとカレンダサービスに接続します。この構成により、層 1 の要素を個々にスケーリングすることができるため、システムの水平方向のスケーリングが可能になります。これらの要素に、バックエンドサーバーの容量を超えるようなスケーリングはしないでください。

フロントエンドの要素がバックエンドサーバーの容量に到達した場合、バックエンドの層 2 の要素を拡大して、より多くのユーザーをサポートすることができます。通常、フロントエンドはトラフィックの関数としてスケーリングします。バックエンドはユーザー数の関数としてスケーリングされます。

注 –

単一層アーキテクチャーおよび 2 層アーキテクチャーにおけるコンポーネントのサイズ決定に関する特別な手順については、クライアントサービス担当者に連絡してください。

エッジ論理アーキテクチャー

エッジ論理アーキテクチャーは 2 層論理アーキテクチャーへのリモートアクセスに対するセキュリティーを向上させます。エッジ配備は、名前およびパスワード認証 (SMTPAuth ) のみを使用することにより、遠隔地のモバイル通信を利用する社員に公衆インターネットを経由するアクセスを許可します。メッセージは、公衆インターネットを介して企業ネットワークと通信されるので、SSL を使用して暗号化されます。仮想私設ネットワークは一切関与しません。通信の内部転送は、最大のパフォーマンスを発揮するために「平文」で行われます。アクセスは、配備の「エッジ」に含まれ、データストアを無許可の侵入から保護します。

エッジを配備するビジネス上の理由は次のとおりです。

図 5–5 は、エッジ論理アーキテクチャーを表しています。

図 5–5 エッジアーキテクチャー

この図は、エッジ論理アーキテクチャーを示します。

この図では、データストアは「エッジ」および「内部」フロントエンドサーバーにのみ接続されるセキュリティー保護された私設ネットワークの層 2 に配置されています。リモートクライアントは SSL を使用してフロントエンドサーバーに接続します。内部アクセスは本質的に安全であるとみなされるので、内部クライアントは SSL を使用して接続する必要はありません。

エッジアーキテクチャー設計の推奨事項

単一層アーキテクチャーの利点

単一層アーキテクチャーを使用する利点は、追加ハードウェアの購入と維持が不要になることによるコストの低減です。

単一層アーキテクチャーがその企業に最適かどうかを決定するには、次の質問に対する回答が役立ちます。

これらの質問に対する回答が「はい」である場合、その企業は単一層アーキテクチャーを使用することを示しています。

2 層アーキテクチャーの利点

Communications Services 製品内のすべてのサービスはネットワーク機能に依存します。2 層アーキテクチャーは、公衆 (ユーザー側) ネットワークと私設 (データセンター側) ネットワークの 2 つの独立したネットワークを持つネットワーク設計を提供します。

ネットワークを 2 層に分離することにより、次の利点が提供されます。

水平方向のスケーラビリティー戦略

スケーラビリティーは、コンピュータ資源を最高の費用効率で利用し、ピーク時の作業負荷を処理し、ビジネスの拡大に対応してすばやくインフラストラクチャーを拡張する必要がある組織に不可欠です。次の点に注意してください。

2 層アーキテクチャーに配備する場合、Communications Services 製品は水平方向に非常に効果的なスケーリングが可能です。各機能要素は、特定の層に増設マシンを追加することにより、増大する負荷をサポートすることができます。

フロントエンドサービスとバックエンドサービスのスケーリング

実際には、フロントエンドサービスとバックエンドサービスのスケーリングは若干異なります。

層 1 の要素の場合、フロントエンドへのトラフィックが現在の容量を超えて増加したときにスケーリングプロセスを開始します。比較的低コストのマシンを追加し、これらのマシン全体の負荷分散を追加します。この結果、ロードバランサにシステムの全体負荷、サービスの分散、およびスケーラビリティー要求の指示をすることにより、層 1 の各サービス機能に優先付けをすることができます。

層 2 の要素の場合、バックエンドサービスがユーザー容量またはデータ容量を超過したときにスケーリングプロセスを開始します。一般的な基準としては、層 1 のサービスの負荷容量のちょうど 2 倍以下に対応できるように層 2 のサービスを設計します。

たとえば、5,000 ユーザー用に設計したアーキテクチャーの場合、層 1 のフロントエンドサービスは 5,000 ユーザーをサポートするように設計されています。バックエンドサービスは、この 2 倍の 10,000 ユーザーに対応できるように設計します。システム容量が 5,000 ユーザーを超えている場合は、フロントエンドサービスを水平方向に拡大することができます。全体容量が 5,000 ユーザーに到達している場合は、バックエンドサービスを対応できるように拡大することができます。このような設計により、ユーザーに関してでも、スループットに関してでも、柔軟に拡大できるようになります。

その他の配備の課題

この節では、いくつかの共通の Communications Services 配備の最良の方法とその他の配備に関する考慮事項について説明します。

Messaging Server に対する LMTP (Local Message Transfer Protocol) の実装

最良の方法は、メッセージ配信のために SMTP の代わりに LMTP を実装することです。LMTP アーキテクチャーがバックエンドメッセージストアへの配信に関して効率性が高い理由は次のとおりです。

LMTP を実装するには 2 層アーキテクチャーが必要です。LMTP の設定手順については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』の「LMTP 配信の設定」を参照してください。

Realtime Blackhole List (RBL) の実装

Mail Abuse Protection System の Realtime Blackhole List (MAPS RBL) は、送信元の IP アドレスで識別される、一方的に送られてくる大量電子メール (UBE: Unsolicited bulk email) の既知の送信元の動的な更新リストです。Messaging Server SMTP サーバーは RBL の使用をサポートし、UBE またはスパムとして RBL が識別する送信元からの受信メールを拒否することができます。

すべての配備において RBL の実装を考慮する必要があります。通常、MTA の前に配備された高品質の RBL は、最低でも 10%、場合によってはそれ以上 MTA に対するトラフィックを軽減します。

RBL と BrightMail などのアンチスパムまたはアンチウィルスサーバーは連携して動作することができます。たとえば、アンチスパムサーバーが特定の IP アドレスからの 100 通の電子メールから 95〜99 通のメールを排除した場合、その IP アドレスを RBL に追加することができます。また、BrightMail 分析の実行時に、BrightMail の誤検知によって RBL を調整することができます。この結果、UBE の特定の変動を処理する上で、RBL を一層有効に活用できるようになります。

MTA ディスパッチャーの ENABLE_RBL オプションの設定に関する詳細については、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』を参照してください。

論理サービス名の使用

Communications Services サーバーの論理名を使用する配備を設計します。将来の拡張や拡大を容易にするために、単一システムの配備においても論理名を使用する必要があります。論理名の使用は、DNS の格納以外に追加の配備設定費用は不要です。

これらの論理名を次の 2 つのカテゴリに分けて考えることができます。1 つは電子メールクライアントプログラムの設定などエンドユーザーに影響を与え、もう 1 つはインバウンド SMTP サーバーなどバックエンドの管理に影響を与えるものです。

次表でこれらの論理名について説明します。

表 5–1 ユーザー側の論理名

例 

説明 

mail.siroe.com

エンドユーザーが電子メールを収集するサーバーの名前 

imap.siroe.com

エンドユーザーが電子メールを収集する IMAP サーバーの名前

pop.siroe.com

エンドユーザーが電子メールを収集する POP サーバーの名前

smtp.siroe.com

送信メールサーバーとしてユーザーが指定する SMTP サーバーの名前 

webcal.siroe.com または ce.siroe.com

Communications Express (以前の Calendar Express) サーバーの名前 

表 5–2 保守レベルの論理名

例 

説明 

relay-in.siroe.com

インバウンド SMTP サーバーのバンクに相当します。 

relay-out.siroe.com

アウトバウンド SMTP サーバーのバンクに相当します。 

mmp.siroe.com

MMP サーバーのバンクに相当します。 

mem.siroe.com

MEM サーバーのバンクに相当します。 

storeAA.siroe.com

バックエンドメッセージストア。たとえば、storeAA.siroe.com〜storeZZ.siroe.com のように、使用するトポロジで動作するネーミング方式を選択します。

calstoreAA.siroe.com

バックエンドカレンダストア。たとえば、calstoreAA.siroe.com〜calstoreZZ.siroe.com のように、使用するトポロジで動作するネーミング方式を選択します。

表 5–3 ユーザーレベルの保守レベル論理名へのマッピング

保守レベル 

ユーザーレベル 

relay-in.siroe.com

なし 

relay-out.siroe.com

smtp.siroe.com

mmp.siroe.com

mmp.siroe.com、pop.siroe.com、imap.siroe.com のうちの 1 つまたは複数の名前

mem.siroe.com

webmail.siroe.com

storeAA.siroe.com〜storeZZ.siroe.com

なし。エンドユーザーには隠されている 

calstore_aa.siroe.com〜calstore_az.siroe.com

なし。エンドユーザーには隠されている 

第 6 章 サービスの可用性の設計

論理アーキテクチャーを決定したら、次はサイトに適したサービスの可用性レベルを特定します。サービスの可用性レベルは、選択したハードウェア、ソフトウェアインフラストラクチャー、使用する保守方法が関係しています。この章では、いくつかの選択肢とそのメリットおよびコストについて説明します。

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

高可用性ソリューションの概要

Communications Services の高可用性ソリューションは、製品ごとに異なります。

たとえば、Messaging Server は、2 つの異なる高可用性ソリューションである Sun Cluster と Veritas Cluster Server (VCS) をサポートします。Messaging Server は、これら各ソリューションに対するエージェントを提供します。

Messaging Server と Calendar Server は、異なるクラスタトポロジをサポートしています。詳細については、対応するクラスタ製品のマニュアルを参照してください。

Application Server を Web コンテナとして使用する場合は、その高可用性、負荷分散、およびクラスタ管理機能を利用できます。

Instant Messaging は Sun Cluster エージェントも提供しますが、VCS はサポートしません。冗長性のある Instant Messaging マルチプレクサの配備によって、さらに可用性の高い配備を実現できます。そのような配備では、あるマルチプレクサで障害が発生しても、それとは別の利用可能なマルチプレクサ経由で、Instant Messaging クライアントはバックエンドサーバーと通信できます。

また、Directory Server などのインフラストラクチャーコンポーネントの可用性を高くすることで、Communications Services 配備の可用性をさらに高めることができます。

この章の次の節では、各コンポーネントで使用できるオプションについて説明します。

システムの自動再設定 (ASR)

単に高可用性 (HA) ソリューションを評価するだけでなく、ASR を可能にするハードウェアの配備についても検討する必要があります。

ASR は停止時間に関連するハードウェア障害を最小限にするためのプロセスです。サーバーに ASR 機能がある場合は、ハードウェアの個別のコンポーネントに障害が発生しても、停止時間を最小限にとどめることが可能になります。ASR により、サーバーの自動再起動と、障害の発生したコンポーネントが交換されるまでそれを停止しておくことが可能になります。欠点は、障害の発生したコンポーネントがサービスから排除される結果、システムのパフォーマンスが低下することです。たとえば、CPU に障害が発生すると、マシンは残りの CPU を使用して再起動されます。システムの I/O ボードまたはチップに障害が発生した場合は、システムの I/O ボードが減少するか、代わりの I/O パスが使用されます。

さまざまな Sun SPARC システムが、さまざまなレベルの ASR をサポートしています。ASR をまったくサポートしていないシステムもあれば、非常に高レベルの ASR をサポートしているシステムもあります。当然ながら、高い ASR 機能を持つサーバーはその分コストも高くつきます。ソフトウェアに高可用性がない場合、コストには制約がないものとすれば、データ格納用にはハードウェアに高い冗長性と ASR 機能を持たせたマシンを選択します。

Directory Server と高可用性

Communications Services の見地からみると、ディレクトリサービスを計画する際の最も重要な要素は可用性です。インフラストラクチャーサービスとして、ディレクトリは認証、アクセス、電子メールのルーティングなどの高レベルのアプリケーションに対して、可能なかぎり継続的なサービスを提供する必要があります。

高可用性を提供する Directory Server の重要な機能は「レプリケーション」です。レプリケーションは、ある Directory Server から別の Directory Server にディレクトリデータを自動的にコピーするメカニズムです。レプリケーションによって、可用性の高いディレクトリサービスを提供し、データを地理的に分散することが可能になります。実際的には、レプリケーションは次の利点を提供します。

下表は、可用性のあるディレクトリを設計する方法を示します。

表 6–1 高可用性 Directory Server の設計

手法 

説明 

シングルマスターレプリケーション 

サプライヤとして機能するサーバーが 1 つまたは複数のコンシューマサーバーにマスターのレプリカを直接コピーします。この構成では、すべてのディレクトリの変更がサプライヤに格納されたマスターのレプリカに対して行われ、コンシューマには読み取り専用のデータのコピーが含まれます。 

双方向、マルチマスターレプリケーション 

同一データの共有を担当する 2 つのサプライヤ間のマルチマスター環境で、2 つのレプリケーションアグリーメントを作成します。サプライヤ A とサプライヤ B がそれぞれ同一データのマスターのレプリカを保持し、このマルチマスター構成のレプリケーションフローを制御する 2 つのレプリケーションアグリーメントが存在します。 

4 方向、マルチマスター 

通常、2 つの独立したデータセンターに Directory Server マスターのペアを提供します。この構成は、レプリケーションに 4 方向、マルチマスターレプリケーション (MMR) を使用します。4 方向マスターフェイルオーバー構成により、この完全に接続されたトポロジがデータの完全性を保証する高可用性ソリューションを提供しています。レプリケーショントポロジのハブとともに使用する場合、負荷分散を容易にし、各データセンターの 4 つのコンシューマが、読み取り (検索) 操作のためにこのトポロジのスケーリングを可能にします。 

Directory Server 用の Sun Cluster エージェント

Sun Cluster ソフトウェアの使用により、ディレクトリの設定に最高水準の可用性が提供されます。アクティブ Directory Server ノードの障害が発生した場合、Sun Cluster はバックアップノードにサービスの透過的なフェイルオーバーを提供します。ただし、クラスタのインストール、設定、保守などの管理 (およびハードウェア) コストは、通常 Directory Server のレプリケーション手法よりも高くなります。 

詳細については、『Sun Java System Directory Server 5 2005Q1 Deployment Plannning Guide』を参照してください。

Application Server と高可用性

Communications Express は Web コンテナ (Web Server または Application Server) 内に配備されるため、Web コンテナの高可用性化を検討してください。

たとえば、Application Server Enterprise Edition はコアアプリケーションサーバープラットフォームの機能強化版であり、高可用性化機能、負荷分散機能、およびクラスタ管理機能を備えています。Enterprise Edition では、Platform Edition の管理機能が拡張されており、複数インスタンス、複数マシンの配備にも対応できるようになっています。

Application Server のクラスタリングサポートには、設定の容易なクローンアプリケーションサーバーインスタンスグループが含まれます。このグループを使えば、クライアント要求の負荷分散を実現できます。このエディションでは、外部ロードバランサと負荷分散機能を備えた Web 層ベースプロキシの両方が、サポートされています。Application Server EE は、HADB (高可用性データベース) を使って HTTP セッションとステートフルセッション Bean に対するフェイルオーバーを実現します。

詳細については、次の Application Server Enterprise Edition 8.1 2005Q2 のマニュアルを参照してください。

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

Messaging Server、Calendar Server と高可用性

クラスタソフトウェアを使用すると、Messaging Server および Calendar Server で高可用性が実現できるように設定できます。Messaging Server は、Sun Cluster および Veritas Cluster Server の両方のソフトウェアをサポートしています。Calendar Server は、Sun Cluster ソフトウェアをサポートしています。

フロントエンドとバックエンドコンポーネントが別々のマシンに分散された、Tier (層) Communications Services アーキテクチャーでは、バックエンドが持続的データを保持する「ストア」となるため、クラスタテクノロジを使用してバックエンドコンポーネントを高可用性化する場合があります。クラスタテクノロジは、持続的データを保持していないため、通常は Messaging Server または Calendar Server のフロントエンドでは保障されていません。通常、Messaging Server の MTA、MMP、MEM と Calendar Server のフロントエンドの可用性を高めるには、システムを冗長化します。つまり、複数のフロントエンドホストを配備します。また、RAID テクノロジによって MTA のディスクサブシステムを保護することで MTA を高可用性化することも可能です。

Sun Cluster トポロジの詳細については、『Sun Cluster Concepts Guide for Solaris OS』の第 2 章「Key Concepts for Hardware Service Providers」を参照してください。

Messaging Server の高可用性の設定について詳しくは、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』の第 3 章「高可用性の構成」を参照してください。

Calendar Server の高可用性の設定について詳しくは、『Sun Java System Calendar Server 6 2005Q4 Administration Guide』の第 7 章「Configuring for High Availability (Failover Service)」

Instant Messaging と高可用性

Instant Messaging は Sun Cluster エージェントを提供しますが、Veritas Cluster Service をサポートしていません。Instant Messaging マルチプレクサの配備を冗長化したり、Instant Messaging ウォッチドッグプロセスを活用したりすることで、より可用性の高い環境を実現できます。

Instant Messaging の高可用性の概要

Sun Cluster エージェントを使用して高可用性 (HA) を実現するために Instant Messaging を設定すると、ソフトウェアとハードウェアの障害の監視および復旧機能が提供されます。高可用性機能はスケーラブルサービスではなくフェイルオーバーデータサービスとして実装され、現時点では Solaris 上でのみサポートされています。

注 –

同じ SMTP サーバーを使用することで、1 つの HA 環境内に複数の Instant Messaging ノードを配置することができます。

Sun Cluster エージェントを使用して Instant Messaging の HA 環境を実装する前に、次のどの HA 配備がもっともニーズに適しているかを決定します。

複数の Instant Messaging マルチプレクサの使用

複数のマルチプレクサを含む Instant Messaging 配備では、あるマルチプレクサで障害が発生しても、それとは別の利用可能なマルチプレクサ経由で、Instant Messaging クライアントはバックエンドサーバーと通信できます。現時点では、複数のマルチプレクサが単一の Instant Messaging サーバーインスタンスと通信するようにしか設定できません。複数のマルチプレクサが複数の Instant Messaging インスタンスと通信するように設定することはできません。

Instant Messaging ウォッチドッグプロセスの使用

Instant Messaging にはウォッチドッグプロセスが含まれています。このプロセスは Sun Cluster エージェントを監視し、サーバーのロックアップやクラッシュなど、何らかの理由により利用不可能になったサービスを再開します。ウォッチドッグプロセスを設定した場合、ある Instant Messaging コンポーネントの機能が停止すると、ウォッチドッグプロセスが、そのコンポーネントをシャットダウンしてから再起動します。

有効化テクニックとテクノロジの使用

前節で説明した高可用性ソリューションのほかに、有効化テクニックとテクノロジを使用して可用性とパフォーマンスの両方を向上させます。これらのテクニックとテクノロジには、ロードバランサ、Sun Java System Directory Proxy Server 、レプリカロールプロモーションなどがあります。

ロードバランサの使用

ロードバランサを使用して、エンドツーエンドのシステム全体に高可用性を提供することにより、アーキテクチャーの各層の機能の可用性を保証することができます。ロードバランサは、専用のハードウェア機器または完全なソフトウェアソリューションです。

負荷分散は、単一のアプリケーションインスタンス、サーバー、またはネットワークが単一の障害ポイントになることを回避すると同時にサービスのパフォーマンスを向上させる最善の方法です。負荷分散の主な目的の 1 つは、サービスの水平方向の能力を拡大することです。たとえば、ディレクトリサービスの場合、ロードバランサは、ディレクトリサービスが処理可能な同時 LDAP 接続の総数および 1 秒あたり LDAP 操作の総数を増加させます。

Directory Proxy Server の使用

Sun Java System Directory Proxy Server (以前の SunTM ONE Directory Proxy Server) は多くのプロキシ形式の機能を提供します。これらの機能の 1 つに LDAP 負荷分散があります。Directory Proxy Server は専用ロードバランサと同じ機能を実行できませんが、フェイルオーバー、レフェラルのフォロー、セキュリティ、マッピング機能のために、この機能の使用を検討します。

詳細については、次の Web サイトの Directory Proxy Server のマニュアルを参照してください。

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

レプリカロールプロモーションの使用

Directory Server には、ディレクトリインスタンスのレプリカロールを昇格させたり、降格させる方法があります。この機能により、レプリカハブをマルチマスターサプライヤに昇格させる、またはその逆を行うことができます。コンシューマをレプリカハブのロールに昇格させる、またはその逆を行うこともできます。ただし、コンシューマを直接マルチマスターサプライヤとして昇格させること、またはその逆を行うことはできません。この場合には、コンシューマはまずレプリカハブとなり、次にハブからマルチマスターのレプリカとなることができます。逆の場合も同じように実行できます。

レプリカロールプロモーションは分散配備に役立ちます。地理的に分散した 6 箇所のサイトがある場合について考えてみます。マルチマスターサプライヤを各サイトに配置したいと思いますが、最大 4 つのサイトに、サイトごとに 1 つ配置するだけに制限されています。ほかの 2 つの各サイトに少なくとも 1 つのハブを配置する場合は、ほかのマルチマスターサプライヤの 1 つがオフラインになっているか、または何らかの理由で運用されていない場合に、それらを昇格させることができます。

詳細については、『Sun Java System Directory Server 5 2005Q1 Administration Guide』を参照してください。

高可用性製品の参照情報

高可用性モデルの詳細については、次の製品マニュアルを参照してください。

Sun Cluster

Veritas Cluster Server

リモートサイトフェイルオーバーの理解

リモートサイトフェイルオーバーは、プライマリサイトに致命的な障害が発生した場合に、そのプライマリサイトに WAN で接続されているサイトでサービスを開始する機能です。リモートサイトフェイルオーバーにはいくつかの形式があり、それぞれにコストが異なります。

リモートサイトフェイルオーバーでは、すべてのケースでサーバーとストレージを追加して、リモートサイトにインストールおよび設定された、サービスのユーザー負荷のすべてまたは一部を処理する能力を持つようにする必要があります。すべてまたは一部というのは、顧客によっては優先するユーザーとそうでないユーザーがいることを意味します。ISP でも企業でも、そのような状況が起こります。ISP には、この機能のために割増料金を支払うユーザーがいます。企業では、全従業員に電子メールの機能を提供している部門内で、ユーザーによってはそのサポートが高くついている場合があるかもしれません。たとえば、カスタマサポートに直接関わるユーザーのメールに対してリモートサイトフェイルオーバーを選択した場合でも、製造ラインで勤務する従業員には、リモートサイトフェイルオーバーを用意しないというケースが考えられます。リモートハードウェアは、このようにリモートサイトフェイルオーバーメールサーバーにアクセスを許可されたユーザーの負荷を処理できます。

ユーザーベースの使用率だけを制限すると、必要な冗長サーバーとストレージハードウェアの数を減らすことができますが、フェイルバックの設定と管理も複雑になります。そのようなポリシーはまた、長期的には予期しない別の影響をユーザーに与えます。たとえば、ドメインメールルーターが 48 時間にわたって利用不能になった場合、インターネット上の他の MTA ルーターがそのドメイン宛てのメールを保持します。ある時点でサーバーがオンラインに戻った際に、メールが配送されます。さらに、すべてのユーザーをフェイルオーバーリモートサイトに設定していない場合は、MTA が起動して設定されていないユーザーに対して永続的なエラー (バウンス) が返されます。最後に、すべてのユーザーを受け入れるようにメールを設定している場合は、すべてのユーザーをフェイルバックするか、フェイルオーバーがアクティブな間使用できないアカウント宛てのメールを保持し、フェイルバックが起こったらそれを本来の配信の流れに戻すように MTA ルーターを設定する必要があります。

考えられるリモートサイトフェイルオーバーのソリューションには、次のようなものがあります。

ハードウェアやソフトウェアをはじめ、管理コスト、電力費、光熱費、ネットワークコストまで、これらのソリューションでは、さまざまなコストが発生します。これらのコストはすべてそのまま計算に入れて、数字をはじき出します。そうしなければ、いくつかのコストを算出するのが困難になります。そのようなコストには、めったに実施しない一連の手順を実施するときのミスによるコスト、停止時間による直接のコスト、データ損失によるコストなどがあります。このような種類のコストを正確に算定するのは不可能です。顧客によっては、停止時間とデータの損失は代償が高くつくか、まったく受け入れられません。別の顧客にとっては、それは単なる不愉快にすぎないかもしれません。

リモートサイトフェイルオーバーを行う場合には、リモートディレクトリが少なくとも最新のもので、メッセージデータの復元が可能な状態にあることも必要です。リモートサイトにリストアメソッドを使用する場合は、ディレクトリが完全に復元されてからメッセージを復元する必要があります。また、ユーザーをシステムから削除した場合、ディレクトリ内でそのユーザーに無効のタグがつけられるだけなのはやむをえません。ユーザーのデータがあるメッセージバックアップテープが使用されるかぎり、それらのユーザーをディレクトリから削除してはなりません。

リモートサイトフェイルオーバーについての質問

次の質問を参考にして、リモートサイトフェイルオーバーの計画を立ててください。

注 –

ローカル HA 用の Sun Cluster とリモートサイトフェイルオーバー用の Veritas ソフトウェアを併用しないでください。Sun Cluster は現時点ではリモートサイトフェイルオーバーをサポートしていません。

また、プライマリサイトからバックアップサイトへの自動フェイルオーバーをソフトウェアに許可しないでください。その場合、セカンダリサイトからプライマリサイトの障害が誤って検出される可能性がかなり高くなります。このようなケースでは、ソフトウェアにプライマリサイトを監視させ、障害を検出したときに警告を出させるように設定します。次に、バックアップサイトへの自動フェイルオーバープロセスを開始する前に、障害が実際に発生していることを確認します。

第 7 章 セキュリティーの設計

この章では、セキュリティーの手法の概要、一般的なセキュリティー脅威、およびセキュリティーニーズ分析の手順の概要について説明します。

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

製品のセキュリティーの詳細については、第 13 章「Messaging Server セキュリティーの計画」と第 18 章「Calendar Server セキュリティーの計画」を参照してください。

Communications Services セキュリティーの概要

Communications Services 配備のセキュリティーは、「多重防御」手法を採用することによって管理します。ネットワーク、ハードウェアのプラットフォーム、オペレーティングシステム、アプリケーション自体を個々に安全にすることによって、アーキテクチャーの各層のセキュリティーを確保します。セキュリティーには、不必要なネットワークポートやアクセスメカニズムを閉鎖することによって各層を堅牢化する方法があります。また、インストールするソフトウェアパッケージの数を最小にして、システムが必要とするパッケージのみ利用できるようにします。最後に、ネットワーク内の意図しないアクセスから、層をセキュリティー保護するために層を隔離します。

Messaging Server のプロキシサーバーをインストールして、データセキュリティーを補強することができます。背後にある Messaging Server のファイアウォールに配置されたプロキシサーバーは、Messaging Server 上の情報に対する攻撃を防御します。

Calendar Server は、ユーザーを盗聴、不許可の使用、または外部からの攻撃から保護するためにいくつかのセキュリティーレベルを提供します。基本レベルのセキュリティーは認証によるものです。Calendar Server は、デフォルトの設定で LDAP 認証を使用していますが、代替の認証方法が必要とされる場合、認証プラグインの使用もサポートしています。Access Manager と統合すれば、Calendar Server はそのシングルサインオン機能を利用することができます。

Instant Messaging は、複数の認証メカニズムとセキュリティー保護された SSL 接続によって通信の統合を可能にします。Portal Server と Access Manager との統合によって、追加セキュリティー機能、サービスベースのプロビジョニングアクセスポリシー、ユーザー管理、セキュリティー保護されたリモートアクセスが可能になります。

注 –

完全かつセキュリティー保護された環境を確保するために、配備にはセキュリティー保護するホストの内部クロックを同期させる時間サーバーが必要です。

セキュリティー戦略の作成

セキュリティー戦略の作成は、配備計画のなかで最も重要なステップの 1 つです。セキュリティー戦略は、組織のセキュリティーに対するニーズを満たし、ユーザーに不便を強いることなくセキュリティーが確保されたメッセージ環境を提供するものでなければなりません。

さらに、セキュリティー戦略は単純なものにして、管理を容易に行えるようにしておく必要があります。複雑なセキュリティー戦略を用いると、ユーザーがメールにアクセスできなかったり、ユーザーや権限のない侵入者によってアクセスされては困る情報が変更されたり、収集されたりする問題が生じます。

RFC 2196『Site Security Handbook』に記載されたセキュリティー戦略を構築するための 5 つのステップを、次に示します。

  1. 何を保護するのかをはっきりさせます。

    たとえば、保護対象のリストにはハードウェア、ソフトウェア、データ、従業員、文書、ネットワークインフラストラクチャー、または組織の評判などが含まれます。

  2. 何から保護するのかを判断します。

    例: 権限のないユーザー、スパマー、またはサービス拒否攻撃

  3. システムに対する脅威の可能性を推測します。

    大規模なサービスプロバイダの場合、セキュリティーが脅威に晒される可能性は小規模な組織よりもはるかに高いといえます。さらに、組織の性格がセキュリティーに対する脅威を誘発することも考えられます。

  4. 費用対効果の高い方法で資産を守る対策を導入します。

    たとえば、SSL 接続を設定する際のオーバーヘッドによって、メッセージング配備のパフォーマンスに対する負荷が発生する可能性があります。セキュリティー戦略を設計するうえで、セキュリティーニーズとサーバーの能力のバランスを取る必要があります。

  5. 戦略を常時見直し、弱点が発見されるたびに戦略を練り直して、よりすぐれたものに改善します。

    定期的な監査を行い、セキュリティーポリシーの全体的な有効性を検証します。監査は、ログファイルと SNMP エージェントが記録した情報を調査することで行います。SNMP の詳細については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』を参照してください。

セキュリティー戦略では、次の項目についても計画する必要があります。

物理的なセキュリティー

インフラストラクチャーの重要な部分への物理的なアクセスを制限します。たとえば、ルーター、サーバー、配線クローゼット、サーバールーム、データセンターを、窃盗、改竄、その他の悪用から保護するために、物理的な制限を設けます。権限を持たない人物にサーバールームへの侵入を許し、ルーターの配線を抜かれることがあるようでは、ネットワークとサーバーのセキュリティーも無意味なものとなります。

サーバーセキュリティー

重要なオペレーティングシステムアカウントとデータへのアクセスを制限することも、セキュリティー戦略の一部となります。この保護は、オペレーティングシステムで利用できる認証とアクセス制御のメカニズムにより行われます。

さらに、最新のオペレーティング環境のセキュリティーパッチをインストールし、数ヶ月ごとに、またベンダーからのセキュリティー警告に対応して、パッチを更新する必要があります。

オペレーティングシステムのセキュリティー

運用環境におけるセキュリティー違反の潜在的リスクを軽減するために、「システムの堅牢化」と呼ばれる次の方法を実行します。

ネットワークセキュリティー

水平方向のスケーラビリティーとサービスのセキュリティーの両方をサポートするには、ファイアウォールの背後にアーキテクチャーのアクセス層を配置する配備構成をお勧めします。2 層アーキテクチャーでは、2 つのファイアウォールを使用して DMZ を作成します。これは、2 番目のファイアウォールの背後にある内部ネットワークのメインサービス要素を保護しながら、情報配信要素、カレンダおよびメッセージングフロントエンドへのアクセスを可能にします。また、このような構成は、アクセス層とデータ層の要素を個別に拡大縮小して、トラフィックおよびストレージ要素に対応することができます。

ネットワークへのアクセスを制限することは、セキュリティー戦略の重要なポイントとなります。通常は、ファイアウォールを使用してネットワークへの全般的なアクセスを制限します。ただし、電子メールはサイト外から使用できるようにしておく必要があります。SMTP がそのサービスの 1 つに該当します。

ネットワークのセキュリティーを確保するには、次の条件が必要となります。

メッセージングセキュリティー

Messaging Server には、次のセキュリティー機能があります。

詳細については、第 13 章「Messaging Server セキュリティーの計画」を参照してください。

アプリケーションのセキュリティー

Communications Services 製品ポートフォリオは、業務用通信のセキュリティーと統合を実現する機能を提供します。Communications Services は、次のような幅広い「組み込み」セキュリティー機能を提供します。

セキュリティー保護された接続の実装

Communications Services は、SSL/TLS、S/MIME 、SAML などのセキュリティー標準をサポートします。SSL/TLS を使えば、クライアントとサーバー間のすべての通信を暗号化されたセッション内で行えます。Portal Server と統合すれば、追加の認証メカニズムがデフォルトで利用可能になるほか、アプリケーション全体にわたってシングルサインオン機能を利用できるようになります。

注 –

Web サーバー内の Communications Express アプリケーションと Calendar Server の cshttpd デーモン間では、SSL はサポートされていません。

公開鍵データセキュリティーを実装する場合は、公開鍵インフラストラクチャーと鍵の選択をサポートするメールクライアントを選択する必要があります。Communications Services 製品は、追加の設定なしで、このように暗号化されたメッセージの転送と保管に直ちに関わることができます。Communications Express Mail クライアント上では、S/MIME (Secure/Multipurpose Internet Mail Extension) を利用できます。S/MIME を使用するように設定された Communications Express Mail ユーザーは、Communications Express Mail、Microsoft Outlook Express、および Mozilla メールシステムを使用するほかのユーザーと、署名または暗号化されたメッセージを交換できます。

注 –

以前のバージョンの Messaging Server に含まれる Web メールクライアントは、暗号化されたメッセージを生成したり復号化したりできません。

一般的に使用されるデータセキュリティーのメカニズムは、さまざまなメッセージングエージェント間のデータ送信に使用する接続で SSL 暗号化を使用して、配線間 (つまり、クライアントからサーバーまで) のデータだけを保護します。このソリューションは、公開鍵暗号化ほど完全ではありませんが、実装がはるかに容易で、数多くの製品とサービスプロバイダによってサポートされています。

クライアントからサーバーまで SSL を使用することにより、どんな問題が解決するでしょうか。組織は、所有するコーポレートネットワークを制御し、そのネットワーク上で送信されるデータは社員以外の者からは安全であるとみなされています。コーポレートネットワークの外部から企業のインフラストラクチャーを使用して送信されるメールは、暗号化接続を介して企業のネットワークにデータを送信します。同様に、コーポレートネットワークの外部の企業ユーザーが受信するすべてのメールは、暗号化接続を介して送信されます。したがって、内部ネットワークの安全に関する企業の仮定が正しく、社員が自分自身とほかの社員間の転送用に認定されたサーバーだけを使用する場合には、社員間のメールは外部攻撃から安全に保護されています。

このソリューションではどんな問題が解決されないか。まず最初に、この方法では、組織の内部ネットワークにアクセスした受信者以外のユーザーが偶然にもデータを参照してしまうことを防げません。次に、社員と外部パートナー、顧客、または供給業者間で送信されるデータの保護が行われません。データは、完全にセキュリティー保護されていない状態で公衆インターネット間を移動します。

ただし、この問題は、企業と顧客の両方のネットワークの MTA ルーター間の SSL 暗号化設定によって修正することができます。この種類のソリューションは、使用する各私設接続の設定が必要になります。このためには、メールを介して送受信する顧客またはパートナーのデータにセキュリティーのための重要な層を追加します。Communications Services の MTA と SSL を使用することにより、企業は送信手段として公衆インターネットを使用してコストの節約ができますが、MTA は パートナーの SSL を使用しなければなりません。このソリューションは、パートナーとの間のほかのトラフィックを考慮しておりません。ただし、通常、メールはトラフィックの大きな部分を占めており、企業は転送されるデータに基づいて料金を支払うことができるので、公衆インターネットの使用はコストが少なくて済みます。

2 つの異なる認証局 (CA) を使用するセキュリティー保護された接続の実装

サーバーとクライアント間、たとえば、Messaging Server から配備したほかのサーバー間に SSL 接続を実装することができます (Web Server、Calendar Server、Directory Server も同様)。必要に応じて、サーバー用とクライアント用に 2 つの認証局 (CA) を使用することができます。

このシナリオでは、ある CA を使用してサーバー証明書を発行し、別の CA を使用してクライアント証明書を発行します。クライアントにサーバーの証明書が本物であることを承認させたい場合は、サーバーの CA 証明書をクライアントの証明書 DB にロードする必要があります。サーバーにクライアントの証明書が本物であることを承認させたい場合は、クライアントの CA 証明書をサーバーの証明書 DB にロードする必要があります。

セキュリティーに関する誤解

この節では、配備のセキュリティーニーズに対して逆効果になる、典型的な誤解について説明します。

その他のセキュリティーリソース

セキュリティー保護された Communications Services 配備の設計について、詳しくは Computer Emergency Response Team (CERT) Coordination Center のサイトを参照してください。

http://www.cert.org

第 8 章 スキーマとプロビジョニングのオプションについて

この章では、Communications Services のスキーマおよびプロビジョニングのオプションについて説明しています。Communications Services のプロビジョニングは複雑なので、製品をインストールする前にオプションについて理解しておく必要があります。

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

スキーマの選択について

この節では、Communications Services で使用可能なサポートされているスキーマオプションと、どちらを使用するかを決定する方法について説明しています。

Messaging Server スキーマの選択について

Messaging Server では、2 つのスキーマオプションが使用可能で、サポートされています。Sun Java System LDAP スキーマバージョン 1 と Sun Java System LDAP スキーマバージョン 2 の 2 つです。

注 –

Sun Java System LDAP スキーマバージョン 1 からSun Java System LDAP スキーマバージョン 2 への移行方法については、『Sun Java System Communications Services 6 2005Q4 Schema Migration Guide』の「commdirmig command」を参照してください。

スキーマ 1 のインストールとプロビジョニングのサポートは非推奨になり、今後のリリースからは削除される予定です。ただし、独自のプロビジョニングツールを持つ顧客は、LDAP スキーマ 1 を引き続き使用できます。

Messaging Server で使用するスキーマの選択

プロビジョニングのニーズにより、Messaging Server のインストールにふさわしいスキーマを選択します。

LDAP スキーマ 1 と Messaging Server

LDAP スキーマ 1 は、組織ツリーと DC ツリーの両方で構成されるプロビジョニングスキーマです。当時は単に「スキーマ」と呼ばれた、このスキーマのセットは、以前の Messaging Server 5.x バージョンでサポートされていました。

スキーマ 1 では、Messaging Server がユーザーエントリまたはグループエントリを検索するときは、DC ツリーのユーザーまたはグループのドメインノードを見て、inetDomainBaseDN 属性の値を抽出します。この属性には、実際のユーザーまたはグループエントリの組織サブツリーへの DN 参照があります。

以前のバージョンの Messaging Server がインストールされているサイトでのみ、スキーマ 1 を使用します。

注 –

将来 Messaging Server にその他の Sun Java System 製品を統合してインストールする場合は、スキーマ 2 への移行が必須となります。

LDAP スキーマ 1 と Messaging Server でサポートされているプロビジョニングツール

スキーマ 1 は、SunTM ONE Delegated Administrator for Messaging (旧称 iPlanet Delegated Administrator) と LDAP プロビジョニングツールをサポートしています。詳細については、「プロビジョニングツールについて」を参照してください。

LDAP スキーマ 2 (ネイティブモード) と Messaging Server

LDAP スキーマ 2 は一連のプロビジョニング定義で、Directory Server LDAP を使用してエントリとして格納できる情報のタイプを定義しています。

ネイティブモードでは、検索テンプレートを使用して LDAP Directory サーバーを検索します。ドメイン検索テンプレートによりドメインが検索されると、次にユーザーまたはグループ検索テンプレートにより、特定のユーザーまたはグループが検索されます。

Communications Services をはじめてインストールし、2 ツリープロビジョニングモデルに依存するその他のアプリケーションをマシンにインストールしていない場合は、ネイティブモードの使用をお勧めします。Java Enterprise System 製品群にその他の製品をインストールする場合も、このモードを使用するとよいでしょう。

スキーマ 1 を使用する既存の Communications Services 5.x があり、Communications Services をほかの Java Enterprise Server 製品と統合する場合は、Communications Services 6 にアップグレードしたあとでディレクトリをスキーマ 2 に移行させることをお勧めします。LDAP スキーマバージョン 1 から LDAP スキーマバージョン 2 への移行方法の詳細については、『Sun Java System Communications Services 6 2005Q4 Schema Migration Guide』を参照してください。

注 –

Java Enterprise System 製品群のすべての Sun Java System 製品で、スキーマ 2 ネイティブモードをプロビジョニングモデルとして使用するようお勧めします。

LDAP スキーマ 2 と Messaging Server でサポートされているプロビジョニングツール

スキーマ 2 は、Sun Java System Communications Services Delegated Administrator をサポートしています。詳細については、「プロビジョニングツールについて」を参照してください。

LDAP スキーマ 2 互換モードと Messaging Server

スキーマ 2 互換モードは、スキーマ 1 とスキーマ 2 ネイティブモードとの中間のモードです。スキーマ 2 互換モードは両方のスキーマをサポートしており、すでに保有している既存の 2 つのツリー設計を維持できます。また、スキーマ 2 互換モードは、Messaging Server をインストールする前に Access Manager をインストールしていることが前提となっています。

スキーマ 1 を必要とする既存のアプリケーションがあるが、Access Manager やシングルサインオン機能などのように、スキーマ 2 を要求する機能も必要な場合に、スキーマ 2 互換モードを使用します。

注 –

スキーマ 2 互換モードは、スキーマ 2 ネイティブモードへの移行の便宜を提供するためのものです。最終的なスキーマ選択では、スキーマ 2 互換モードを使用しないでください。スキーマ 1 からスキーマ 2 互換モードへ移行してから最終的にスキーマ 2 ネイティブモードへと移行するプロセスは、スキーマ 1 からスキーマ 2 ネイティブモードへの単純な移行よりも複雑です。詳細については、『Sun Java System Communications Services 6 2005Q4 Schema Migration Guide』を参照してください。

Calendar Server スキーマの選択について

Calendar Server では、2 つのスキーマオプションが使用可能で、サポートされています。Sun Java System LDAP スキーマバージョン 1 と Sun Java System LDAP スキーマバージョン 2 の 2 つです。

注 –

Sun Java System LDAP スキーマバージョン 1 からSun Java System LDAP スキーマバージョン 2 への移行方法については、『Sun Java System Communications Services 6 2005Q4 Schema Migration Guide』を参照してください。

スキーマ 1 のインストールとプロビジョニングのサポートは非推奨になり、今後のリリースからは削除される予定です。ただし、独自のプロビジョニングツールを持つ顧客は、LDAP スキーマ 1 を引き続き使用できます。

Calendar Server で使用するスキーマの選択

プロビジョニングのニーズに基づき、Calendar Server のインストールにふさわしいスキーマを選択します。

LDAP スキーマ 1 と Calendar Server

LDAP スキーマ 1 は、組織ツリーと DC ツリーの両方で構成されるプロビジョニングスキーマです。当時は単に「スキーマ」と呼ばれた、このスキーマのセットは、以前の Calendar Server 5.x バージョンでサポートされていました。

Calendar Server はユーザーやグループのエントリを検索する場合、DC ツリーのユーザーまたはグループのドメインノードを調べ、inetDomainBaseDN 属性の値を抽出します。この属性には、実際のユーザーまたはグループエントリの組織サブツリーへの DN 参照があります。

Calendar Server の旧バージョンをインストール済みのサイトだけが、スキーマ 1 を使用する必要があります。

注 –

将来、ほかの Sun Java System 製品とともに Calendar Server をインストールすることを計画している場合、スキーマ 2 への移行は必須です。

LDAP スキーマ 1 と Calendar Server でサポートされているプロビジョニングツール

スキーマ 1 は LDAP プロビジョニングツールをサポートしています。詳細については、「プロビジョニングツールについて」を参照してください。

LDAP スキーマ 2 (ネイティブモード) と Calendar Server

スキーマ 2 は一連のプロビジョニング定義で、Directory Server LDAP を使用してエントリとして格納できる情報のタイプを定義しています。

ネイティブモードでは、検索テンプレートを使用して LDAP Directory サーバーを検索します。ドメイン検索テンプレートによりドメインが検索されると、次にユーザーまたはグループ検索テンプレートにより、特定のユーザーまたはグループが検索されます。

Communications Services をはじめてインストールし、2 ツリープロビジョニングモデルに依存するその他のアプリケーションをマシンにインストールしていない場合は、ネイティブモードの使用をお勧めします。Java Enterprise System 製品群にその他の製品をインストールする場合も、このモードを使用するとよいでしょう。

スキーマ 1 を使用する既存の Communications Services 5.x があり、Communications Services をほかの Java Enterprise Server 製品と統合したい場合は、Communications Services 6 に移行したあとで、ディレクトリをスキーマ 2 に移行させることをお勧めします。LDAP スキーマバージョン 1 から LDAP スキーマバージョン 2 への移行方法の詳細については、『Sun Java System Communications Services 6 2005Q4 Schema Migration Guide』を参照してください。

注 –

Java Enterprise System 製品群のすべての Sun Java System 製品で、スキーマ 2 ネイティブモードをプロビジョニングモデルとして使用するようお勧めします。

LDAP スキーマ 2 と Calendar Server でサポートされているプロビジョニングツール

スキーマ 2 は、Sun Java System Communications Services Delegated Administrator をサポートしています。詳細については、「プロビジョニングツールについて」を参照してください。

LDAP スキーマ 2 互換モードと Calendar Server

スキーマ 2 互換モードは、スキーマ 1 とスキーマ 2 ネイティブモードとの中間のモードです。スキーマ 2 互換モードは両方のスキーマをサポートしており、すでに保有している既存の 2 つのツリー設計を維持できます。また、スキーマ 2 互換モードは、Messaging Server をインストールする前に Access Manager をインストールしていることが前提となっています。

スキーマ 1 を必要とする既存のアプリケーションがあるが、Access Manager やシングルサインオン機能などのように、スキーマ 2 を要求する機能も必要な場合に、スキーマ 2 互換モードを使用します。

注 –

スキーマ 2 互換モードは、スキーマ 2 ネイティブモードへの移行の便宜を提供するためのものです。最終的なスキーマ選択では、スキーマ 2 互換モードを使用しないでください。スキーマ 1 からスキーマ 2 互換モードへ移行してから最終的にスキーマ 2 ネイティブモードへと移行するプロセスは、スキーマ 1 からスキーマ 2 ネイティブモードへの単純な移行よりも複雑です。詳細については、『Sun Java System Communications Services 6 2005Q4 Schema Migration Guide』を参照してください。

プロビジョニングツールについて

この節では、サポートされているプロビジョニングツールについて説明します。これらのツールを使って、LDAP ディレクトリ内のユーザー、グループ、およびドメインのエントリ情報の問い合わせ、変更、追加、または削除を行うことができます。

Messaging Server プロビジョニングツールの理解

サポートされている Messaging Server プロビジョニングツールを使って、LDAP ディレクトリ内のユーザー、グループ、およびドメインのエントリ情報の問い合わせ、変更、追加、または削除を行うことができます。この節では、これらの Messaging Server プロビジョニングツールを検証します。

「Messaging Server で使用するスキーマの選択」にある質問の他に、表 8–1 を使用して、スキーマとプロビジョニングツールオプションを評価します。

注 –

Messaging Server のインストールと設定を行う前に、Messaging Server エントリのプロビジョニングのためのスキーマモデルとツールを決定する必要があります。

次の節で、サポートされているプロビジョニングツールに関する高度な情報について説明します。

Sun ONE Delegated Administrator for Messaging

Sun ONE Delegated Administrator for Messaging (旧称 iPlanet Delegated Administrator) には、ユーザーおよびグループのプロビジョニングを行うためのコマンド行ユーザーインタフェースとグラフィカルユーザーインタフェースがあります。Delegated Administrator は、プロビジョニング定義の Messaging Server 5.x バージョンである Sun LDAP スキーマ 1 を使用します。

Messaging Server 用 LDAP プロビジョニングツール

スキーマ 1 のユーザーとグループに関しては、LDAP Directory ツール (スキーマ 2 はサポートされていない) を使用してプロビジョニングを行います。Delegated Administrator のグラフィカルおよびコマンド行インタフェースとは異なり、ユーザーインタフェースを使用せずに、LDAP を通じて LDIF レコードの追加、削除、変更を行うことで、ダイレクトにユーザーとグループのプロビジョニングを行います。

Delegated Administrator と Messaging Server

Access Manager は スキーマ 2 を使用します。Java Enterprise System 製品群に含まれる Sun Java System コンポーネント製品がスキーマ 2 を使用するため、Communications Services 6 Delegated Administrator を使用します。Java Enterprise System 製品を複数使用する場合や Calendar Server の新規インストールを実行する場合には、特にそのようにする必要があります。

インストールの詳細については、『Sun Java System Communications Services 6 2005Q4 Delegated Administrator 管理ガイド』を参照してください。

Messaging Server プロビジョニングツールオプションの比較

表 8–1 に、サポートされているさまざまなスキーマ、プロビジョニングツール、プロビジョニングの制限、および詳細情報についての推奨マニュアルを示します。

表 8–1 Messaging Server のプロビジョニングメカニズム

サポートされているプロビジョニングツール 

プロビジョニングツールの機能 

プロビジョニングツールの制限 

詳細情報 

Sun ONE Delegated Administrator for Messaging グラフィカルユーザーインタフェース 

使用スキーマ: スキーマ 1 

ユーザー、グループ、ドメイン、およびメーリングリストの管理者のためのグラフィカルユーザーインタフェースを提供します。エンドユーザーは不在メッセージと Sieve フィルタを管理できます。 

  • Messaging Server 6 にアップグレードしている既存の Messaging Server 5.x の顧客だけが使用可能です。

  • Sun ONE Web Server 6.0 (Messaging Server 5.2 バンドルとしてのみ入手可能) でのみ使用可能です。Sun ONE Web Server 6.1 では使用できません。

  • Sun スキーマ 2 およびほかの Java Enterprise System 製品との互換性がありません。

  • Sun Java System Messenger Express 経由でメールフィルタを使用できません。Delegated Administrator 経由でフィルタを使用する必要があります。

  • Messaging Server 5.2 製品でのみ使用可能なオートリレーチャネルを使用する必要があります。

Sun ONE Delegated Administrator for Messaging 1.3 のマニュアルを参照してください。 

Sun ONE Delegated Administrator インタフェースのインストールと管理方法を説明しています。 

Sun ONE Delegated Administrator for Messaging コマンド行インタフェース 

使用スキーマ: スキーマ 1 

ユーザー、グループ、ドメイン、およびメーリングリストの管理者のためのコマンド行インタフェースを提供します。 

  • Sun スキーマ 2 およびほかの Java Enterprise System 製品との互換性がありません。

Sun ONE Delegated Administrator for Messaging 1.3 のマニュアルを参照してください。 

Sun ONE Delegated Administrator コマンド行ユーティリティーの構文と使用方法を解説しています。

LDAP プロビジョニングツール

使用スキーマ: スキーマ 1 

LDAP エントリを直接変更するツールまたはカスタムプロビジョニングツールを作成するツールを提供します。 

  • Sun スキーマ 2 およびほかの Java Enterprise System 製品との互換性がありません。

『iPlanet Messaging Server 5.2 Provisioning Guide』および『iPlanet Messaging and Collaboration Schema Reference』を参照してください。

Sun LDAP スキーマ 1 プロビジョニングモデルについて説明しています。 

さらに、LDAP プロビジョニングツールと特定の属性およびオブジェクトクラスの使用法についても説明しています。 

Sun Java System Console 

使用スキーマ: スキーマ 1 

Sun Java System Console にプロビジョニング機能が含まれていますが、Messaging ユーザーとグループのプロビジョニングには推奨しません。代わりに、割り当て、ログファイル、その他の関連するメッセージストア項目などのサーバー設定の管理に Sun Java System Console を使用してください。 

  • Sun スキーマ 2 およびほかの Java Enterprise System 製品との互換性がありません。

  • Console ではユーザーとグループを適切に追加したり変更したりできないため、プロビジョニングツールとしては推奨しません。

『Sun Java System Messaging Server 6 2005Q4 管理ガイド』および対応する Sun Java System Console オンラインヘルプを参照してください。

Delegated Administrator

使用スキーマ: スキーマ 2 

ユーザー、グループ、ドメイン、およびメーリングリストの管理者のためのグラフィカルインタフェースとコマンド行インタフェースを提供します。 

ほかの Java Enterprise System 製品と互換性があります。 

  • Sun スキーマ 1 との下位互換性がありません。

  • Sun Java System Access Manager では GUI プロビジョニングツールを使用できません。

  • Sun Java System Access Manager をインストールしてこのインタフェースを有効にする必要があります。

『Sun Java System Communications Services 6 2005Q4 Delegated Administrator 管理ガイド』を参照してください。

コマンド行ユーティリティーの構文と使用法を解説しています。 

Calendar Server プロビジョニングツールについて

サポートされている Calendar Server プロビジョニングツールを使って、LDAP ディレクトリ内のユーザー、グループ、およびドメインのエントリ情報の問い合わせ、変更、追加、または削除を行うことができます。この節では、これらの Calendar Server プロビジョニングツールについて説明します。

「Calendar Server で使用するスキーマの選択」にある質問のほかに、表 8–2 を使用して、スキーマとプロビジョニングツールオプションを評価します。

注 –

Calendar Server のインストールおよび設定に先立って、Calendar Server エントリをプロビジョニングするためのスキーマおよびツールを決定する必要があります。

次の節で、サポートされているプロビジョニングツールに関する高度な情報について説明します。

Calendar Server 用 LDAP プロビジョニングツール

スキーマ 1 のユーザーとグループに関しては、LDAP Directory ツール (スキーマ 2 はサポートされていない) を使用してプロビジョニングを行います。ユーザーインタフェースを使用せずに LDAP を通じて LDIF レコードの追加、削除、変更を行うことで、ユーザーとグループのプロビジョニングを直接行えます。

Delegated Administrator と Calendar Server

Access Manager はスキーマ 2 を使用します。Java Enterprise System 製品群に含まれる Sun Java System コンポーネント製品がスキーマ 2 を使用するため、Communications Services 6 Delegated Administrator ユーティリティーを使用します。Java Enterprise System 製品を複数使用する場合や Calendar Server の新規インストールを実行する場合には、特にそのようにする必要があります。

インストール方法については、『Sun Java System Communications Services 6 2005Q4 Delegated Administrator 管理ガイド』を参照してください。

Calendar Server プロビジョニングツールオプションの比較

次の表に、サポートされているさまざまなスキーマ、プロビジョニングツール、プロビジョニングの制限、および詳細情報についての推奨マニュアルを示します。

表 8–2 Calendar Server のプロビジョニングメカニズム

サポートされているプロビジョニングツール 

プロビジョニングツールの機能 

プロビジョニングツールの制限 

詳細情報 

LDAP プロビジョニングツール

使用スキーマ: スキーマ 1 

LDAP エントリを直接変更するツールまたはカスタムプロビジョニングツールを作成するツールを提供します。 

Sun スキーマ 2 およびほかの Java Enterprise System 製品との互換性がありません。 

『iPlanet Messaging Server 5.2 Provisioning Guide』および『iPlanet Messaging and Collaboration Schema Reference』を参照してください。

Sun LDAP スキーマ 1 プロビジョニングモデルについて説明しています。 

さらに、LDAP プロビジョニングツールと特定の属性およびオブジェクトクラスの使用法についても説明しています。 

Delegated Administrator

使用スキーマ: スキーマ 2 

ユーザー、グループ、ドメイン、およびリソースを管理する管理者のためのグラフィカルインタフェースとコマンド行インタフェースを提供します。 

ほかの Java Enterprise System 製品と互換性があります。 

  • Sun スキーマ 1 との下位互換性がありません。

  • Sun Java System Access Manager をインストールしてこのインタフェースを有効にする必要があります。

『Sun Java System Communications Services 6 2005Q4 Delegated Administrator 管理ガイド』を参照してください。

コマンド行ユーティリティーの構文と使用法を解説しています。