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

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

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

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

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

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

スキーマ (Schema)

Directory Server (Identity Server)

Messaging Server

Message Transfer Agent (MTA)

メッセージストア (Message Store)

MMP (Messaging Multiplexor)

MEM (Messaging Express Multiplexor)

Calendar Server

フロントエンド (Front End)

カレンダーストア (Calendar Store)

Instant Messaging

Instant Messaging プロキシ

Instant Messaging バックエンド

Portal Server

Connector for Microsoft Outlook

Communications Express

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

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

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

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



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

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

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

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

DIT 構造の変更

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

1 ツリー DIT 構造の利点

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

構造が Identity Server に統合される

構造が業界標準と緊密に整合される

構造が 2 ツリー構造よりも大幅に簡素化される

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

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

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

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

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

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

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

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

スキーマの要件

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

ユーザープロビジョニングまたはシングルサイオン (SSO) のいずれかのために、Identity Server 6 2004Q2 (以前の Sun ONE Identity Server 6.1) を使用する場合

はじめて、Communications Services コンポーネントをインストールする場合

Communications Services を Portal Server などのほかの Java Enterprise System 製品と統合する場合



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

たとえば、Messaging Server 5.2 をアップグレードする場合など、Communications Services コンポーネントの既存のバージョンを所有している場合

ユーザーをプロビジョニングする必要はありません (Identity Server SSO が不要な場合)。

ユーザーのプロビジョニングを行うために Delegated Administrator を使用する場合

スキーマの選択の詳細については、次の Web サイトの『Sun Java System Messaging Server 配備計画ガイド』を参照してください。

Directory Server の考慮事項

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

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

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

ディレクトリスキーマとオブジェクトクラスの定義

ディレクトリ情報ツリー (DIT)

グループとメンバーの定義

スタティックおよびダイナミックグループを含むアクセス制御リスト (ACL) の方針

フェイルオーバー、レプリケーション、レフェラルを含む高可用性および高パフォーマンス対応のディレクトリアーキテクチャ

ディレクトリの管理

データ環境を設計する方法に関するこれらの要素や提案の詳細な説明については、次の Web サイトの『Sun Java System Directory Server 配備計画ガイド』を参照してください。

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

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

Tier (層) アーキテクチャの詳細については、次の Web サイトの『Sun Java System Messaging Server 配備計画ガイド』を参照してください。

Directory Server トポロジの考慮事項

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

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

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) が変更をキャッシュするように設定して、この問題を回避することができます。

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 に負荷を配置しなくても済むようになります。

Directory Server と Communications Express の考慮事項

Communications Express クライアントでは、Directory Server の設定の一部を変更する必要があります。Communications Express 設定には、Java Enterprise System 2004Q2 に付属して提供される comms_dssetup.pl スクリプトが必要です。このスクリプトは、Java Enterprise System 2003Q4 の一部として、Sun ONE Calendar Server 6.0 および Sun ONE Messaging Server 6.0 で提供されるものとは異なります。

Messaging Server の考慮事項

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

Message Store

Message Transfer Agent (MTA)

Mail Message Proxy (MMP)

Messaging Express Multiplexor (MEM)

以下の節では、これらの各コンポーネントに対する考慮事項の概要を説明します。これらのコンポーネントのパフォーマンスと可能なハードウェアソリューションの詳細については、次の Web サイトの『Sun Java System Messaging Server 配備計画ガイド』を参照してください。

Message Store の考慮事項

メッセージストアのパフォーマンスは以下のさまざまな要素の影響を受けます。

ディスク I/O

受信メッセージの頻度 (メッセージ配信頻度とも呼ばれる)

メッセージのサイズ

ログインの頻度 (POP/IMAP/HTTP)

トランザクションの頻度 (IMAP/HTTP)

さまざまなプロトコルの同時接続数

ネットワーク I/O

上記の要素は、Message Store に影響を与えるおおよその順番を示しています。Message Store の大部分のパフォーマンス問題は、不十分な I/O 容量から起ります。また、物理ディスクにストアを配置する方法もパフォーマンスに影響します。小規模なスタンドアロンシステムでは、ディスクの単純なストライプを使用して十分な I/O を装備することができます。大規模なシステムでは、ファイルシステムを分離して、ストアのさまざまな部分に I/O を装備します。

Message Transfer Agent (MTA) の考慮事項

MTA パフォーマンスは、以下のような数多くの要素の影響を受けます。

ディスクパフォーマンス

SSL の使用

送受信メッセージ数および接続数

メッセージのサイズ

送信対象宛先およびメッセージの数

MTA への接続および MTA からの接続速度と待ち時間

スパムまたはウィルスのフィルタリングの必要性

SIEVE 言語フィルタリングルールの使用およびほかのメッセージ解析を行う必要性 (変換チャネルの使用など)

MTA ルーターは CPU と I/O の両方を大量に使用します。MTA は、キューディレクトリとログ記録ディレクトリに 2 種類の異なるファイルシステムを使用します。MTA ルーターとして機能する小規模なホスト (4 プロセッサ以下) の場合、これらのディレクトリを別々のファイルシステムに分離する必要はありません。キューディレクトリは、かなり大量の書き込みが同期的に行われます。ログ記録ディレクトリは、一連の小規模かつ同期的な順次書き込みが行われます。

ほとんどの場合、ディスクサブシステムの MTA に冗長性を計画して、スピンドルが故障した場合にメールの恒久的消失を回避します (スピンドルの故障は、最も発生しやすいハードウェア障害)。これは、外部ディスクアレイまたは多くの内部スピンドルを持つシステムが最適であることを意味します。

さらに、MTA の配置に関しては、MTA は必ずファイアウォールに配置する必要があります。

MTA と LMTP の考慮事項

Messaging Server の LMTP サービスは、そのままでは、LMTP サーバーまたはほかの LMTP クライアントで動作するように設計されておりません。配備における LMTP と SMTP サーバーの混在の設定に関する詳細については、次の Web サイトの『Sun Java System Messaging Server リリースノート』を参照してください。

Mail Message Proxy (MMP) の考慮事項

MMP は、ログ記録以外にディスク I/O を使用することはありません。MMP は、完全に CPU およびネットワークにバインドされています。ほかのすべての Messaging Server コンポーネントと異なり、MMP はマルチスプロセス、マルチスレッドではありません。主要な実行コードは、シングルプロセス、マルチスレッドです。したがって、MMP には十分なマルチスプロセスがないため、ほかのコンポーネントと同様にスケーリングされることはありません。

MMP は 4 プロセッサを超えてスケーリングされることはなく、2～4 プロセッサの間で直線的にスケーリングされます。2 プロセッサ、ラックマウントマシンが MMP に適しています。

MMP と同じマシンにほかのコンポーネントソフトウェア (MEM、Calendar Server フロントエンド、Communications Express Web クライアント、LDAP プロキシなど) を配置するように選択した配備の場合は、大規模な 4 プロセッサ SPARC マシンを検討してください。この構成は、管理、パッチ、監視などが必要となるマシンの総数を低減します。

Messaging Express Multiplexor (MEM) の考慮事項

MEM は、Web メールクライアントにミドル層プロキシを提供します。このクライアントにより、ユーザーはメールにアクセスし、ブラウザを使用してメッセージを作成できるようになります。MEM の利点は、どのバックエンドサーバーがメールを格納しているかにかかわらず、エンドユーザーは MEM にのみ接続して電子メールにアクセスできることです。MEM は、ユーザーの LDAP 情報を介して HTTP セッション情報とユーザープロファイルを管理することにより、これを実現します。次の利点は、すべてのスタティックファイルと LDAP 認証の状態が Messaging Server のフロントエンドに配置されることです。この利点は、Message Store バックエンドからレンダリングされる Web ページに関連する追加 CPU 要件の一部を緩和することです。

MEM には、多くの MMP と同じ特性があります。MEM は 4 プロセッサを超えてスケーリングされますが、大部分の環境で、このようにスケーリングする特別な価値はありません。また、将来、Web メールコンポーネントは、Message Store から Web サーバーの Java サーブレットとして XML レンダリングを実行するアクセス層のマシンに負荷が移されることになっています。現在、Java サーブレットは 2 プロセッサを超えて拡大されません。したがって、ハードウェアの選択として SPARC または Intel の MEM 用 2 プロセッサマシンを計画するか、現在の 2 プロセッサ MEM ハードウェアに再度目的を持たせて、次世代ソリューションが発売されたときに小規模なマシンに置き換えることを考慮してください。

同じサーバーのセットに MMP と MEM を配置することができます。このようにする利点は、少数の MMP または MEM が必要になった場合に、冗長性のための追加ハードウェアの数が最小化されることです。同じサーバーのセットに MMP と MEM を配置する唯一の欠点は、あるプロトコルへのサービス拒否攻撃がほかのプロトコルに影響することです。

Calendar Server の考慮事項

Calendar Server は以下の 5 つの主要なサービスで構成されます。

HTTP サービス (cshttpd) は HTTP 要求を待機する。ユーザー要求を受信して、呼び出し元にデータを返す

管理サービス (csadmind) は Calendar Server のインスタンスを必要する。Calendar Server の認証と管理の単一ポイントを提供し、大部分の管理ツールを提供する

通知サービス (csnotify) は、電子メールまたは ENS (予定通知サービス) のいずれかを使用して予定と予定事項の通知を送信する

ENS (予定通知サービス) (enpd) は、予定アラームのブローカとして機能する

分散データベースサービス (csdwpd) は、複数のデータベースサービスを同一の Calendar Server システムにリンクさせ、分散カレンダーストアを形成する

スケーラブルな Calendar Server 配備では、HTTP サービスと管理サービスのインスタンスをカレンダーのフロントエンドシステムとして一緒に配備します (マシンごとに 1 つの cshttpd インスタンスを配備します。各マシンでは、そのマシンの CPU ごとに 1 つの cshttpd プロセスを設定する)。通知サービス、予定通知サービス、分散データベースサービス、管理サービスを、カレンダーのバックエンドシステムとして一緒に配備します。

認証と XML/XSLT 変換は、大きな負荷を生成する 2 つのカレンダーサービスアクティビティです。サービス品質の要件に適合するために、増設 CPU を追加できます。

通常、カレンダーのバックエンドサービスは、カレンダーのフロントエンドサービスの 1/2 のサイズの CPU 数が必要です。カレンダーのフロントエンドシステムによるサービス品質をサポートするためには、カレンダーのバックエンドシステムがフロントエンド CPU の約 2/3 を使用する必要があります。

配備の初期段階で、カレンダーサービスをフロントエンドとバックエンドサービスに分割することを考慮します。

通常はフロントエンドサービスのコンポーネントである Calendar Server の HTTP プロセスが大半の CPU 時間を消費します。これは、カレンダーのピーク利用率を考慮し、予想される HTTP のピークセッションに対応する十分なフロントエンド処理能力を選択する必要があることを示しています。通常、Calendar Server フロントエンドは、冗長性、つまり複数のフロントエンドホストを配備することにより可用性を高めます。フロントエンドシステムはカレンダーの持続的データを保持しないので、Sun Cluster または Veritas のような HA ソリューションに適したシステムではありません。さらに、このようなハードウエアおよび管理諸経費の追加というソリューションは、Calender Server フロントエンド用の HA の配備を、高コストで多くの時間を消費するものにしています。



注	真の HA ソリューションを保証できるカレンダーフロントエンドの唯一の構成は、Messaging Server MTA が配置されている同じホストにカレンダーフロントエンドを配備した場合です。ただし、この構成の場合でも、このようなソリューションの間接費が、わずかな利点に比べて不利にならないかどうか慎重に検討する必要があります。

Calendar Server フロントエンドの最適なハードウェアの選択肢は、シングルまたはデュアルプロセッサの SPARC または Intel サーバーです。マシンごとに 1 つの Calendar Server cshttpd プロセスを配備します。このような配備は、ある程度の初期クライアントの並行処理機能で開始し、既存の構成によるピーク利用率がわかった段階でクライアントのセッション容量の増加を可能にして、費用効率の高いソリューションを提供します。

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



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

Calendar Server のバックエンドサービスはリソース消費のバランスがよくとれており、CPU または I/O (ディスクまたはネットワーク) のいずれにおいてもボトルネックは発生しません。したがって、バックエンド用ハードウェアに適した選択肢は、シングルストライプボリュームの SPARC サーバーとなります。このマシンは、大量のカレンダーのピーク負荷に対してかなりの容量を提供します。

要件に高可用性が含まれる場合は、バックエンドに持続的データが含まれるので、Sun Cluster または Veritas Cluster を使用し Calendar Server のバックエンドを配備するのが賢明です。



注	フロントエンドとバックエンド Calender Server ホストの両方を持つ構成では、すべてのホストが以下を実行する必要があります。同じオペレーティングシステムパッチおよびホットフィックスリリースを含む Calendar Server の同一リリース

Instant Messaging の考慮事項

ほかの Communications Services コンポーネントと同様に、Instant Messaging をフロントエンド (Instant Messaging マルチプレクサ) とバックエンド (サーバーとストア) に分割するアーキテクチャを構成することができます。

Instant Messaging の考慮事項の詳細については、次の Web サイトの『Sun Java System 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 クライアントを利用することができます。

詳細については、次の Web サイトの『Sun Java System Portal Server Deployment Guide』と『Sun Java System Identity Server 配備計画ガイド』を参照してください。

Connector for Microsoft Outlook の考慮事項

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

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 は、Messaging Server のメールと Calendar Server のカレンダー情報の 2 つの別個の情報源からエンドユーザーの Outlook 表示を作成します。

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

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

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

icsCalendar

mail

mailalternateaddress

製品の依存性の完全なリストについては、次の Web サーバーの『Sun Java System Connector for Microsoft Outlook リリースノート』を参照してください。

Sun ONE Calendar Server データの移行

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

Exchange Server データの移行

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

Communications Express の考慮事項

Sun Java System Communications Express は、ブラウザを使用してアクセスできるWeb サーバーベースのアプリケーションです。Communications Express 製品は、Calendar、Address Book、Mail の 3 つのクライアントモジュールで構成されます。Calendar、Address Book、Mail クライアントモジュールは、Web コンテナ上に単独のアプリケーションとして配備され、総称して Communications Express と呼びます。

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

Directory Server

Identity Server (オプション)

Calendar Server

Messaging Server

Communications Express をフロントエンドサーバーとしてインストールします (複数層環境)。Communications Express を実行する同じホストに Messaging Server パッケージの完全なセットをインストールする必要があります。Messaging Server は、Message Store に直接アクセスする Messenger Express インタフェースを提供するか、または Messenger Express を実行するバックエンドに接続する MEM を提供するために使用されます。さらに、フロントエンドマシン上の Communications Express の AddressBook サーバーを設定して、LDAP ディレクトリインフラストラクチャか Communications Express マシン以外の LDAP サーバーのいずれかにデータを格納することができます。詳細については、次の Web サイトの『Sun Java Communications Express 管理ガイド』を参照してください。

Communications Express は、Calendar Server のローカル (通常、同一マシン) の cshttp デーモンと通信します。次に、これらのデーモンは DWP を使用して Calendar Server のバックエンドと通信します。Communications Express は、Messenger Express (Web メール) を使用して Message Store と通信します。

ロードバランサまたはポートディレクタタイプのデバイスを使用する場合は、ユーザーがセッション中に同じフロントエンドサーバーに継続的にルーティングする「スティッキ」(持続的) な接続を使用してください。

セキュリティの考慮事項

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

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

Calendar Server は、数多くのセキュリティレベルを装備して、盗聴、無許可使用、または外部アタックからユーザーを保護します。セキュリティの基本的なレベルは認証の使用です。Calendar Server は、デフォルトで LDAP 認証を使用しますが、代替認証手段が必要な場合は認証プラグインの使用もサポートします。Identity Server との統合により、Calendar Server はシングルサインオン機能の利用が可能になります。

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

セキュリティの詳細については、『Sun Java System Messaging Server 配備計画ガイド』、『Sun Java System Calendar Server 管理ガイド』、『Sun Java System Instant Messaging 配備計画ガイド』を参照してください。



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

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

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

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

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

運用環境におけるインストールの最小化: インターネットまたは信頼されないネットワークにさらされた環境で Sun サーバーをインストールする場合、ホストするアプリケーションのサポートに必要な最小パッケージ数に Solaris のインストールを減らします。サービス、ライブラリ、アプリケーションの最小化を実行することにより、保守が必要なサブシステムの数を減らして、セキュリティを強化することができます。

Solarisa Security Toolkit は、Solaris 運用環境システムの最小化、堅牢化、セキュリティ保護を実行する柔軟性のある拡張可能なメカニズムを提供します。このツールキットの配備の背後にある主な目的は、Solaris システムのセキュリティを確保するプロセスを簡素化し、自動化することです。詳細については、次の Web サイトを参照してください。

http://wwws.sun.com/software/security/jass/

ファイルシステムの変更の追跡と監視: セキュリティの組み込みが必要なシステム内では、ファイル内の変更を追跡し、侵入を検出するためにファイル変更制御および監査ツールが不可欠です。Tripwire for Servers または Solaris Fingerprint Database (SunSolve オンラインで入手可能) などの製品を使用できます。

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

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

認証

メッセージとセッションの暗号化

ウィルスとスパムの防護

通信のアーカイブと監査

エンドユーザーが設定可能なプライバシーオプション

安全な接続の実装

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

公開鍵データセキュリティを実装する場合は、公開鍵インフラストラクチャと鍵の選択をサポートするメールクライアントを選択する必要があります。Communications Services 製品は、追加の設定なしで、このように暗号化されたメッセージの転送と保管に直ちに関わることができます。ただし、Web クライアントにはメッセージを作成し、デコードする機能はありません。

一般的に使用されるデータセキュリティのメカニズムは、さまざまなメッセージングエージェント間のデータ送信に使用する接続で 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 にロードする必要があります。

前へ目次索引次へ
Sun Java System Communications Services 6 2004Q2 企業向け配備計画ガイド