test

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

第 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 を使用するための要件」を参照してください。