| Oracle Collaboration Suiteデプロイメント リリース2（9.0.4） 部品番号: B15723-01 |
|
 戻る |
 次へ |
この章では、Oracle Collaboration Suiteアーキテクチャの概要、およびアーキテクチャを計画するときに考慮する必要がある設計および問題について説明します。ここでは、次の内容について説明します。
Oracle Collaboration Suiteは、様々なコンポーネントとサーバーを的確に配置および統合することにより、多数の異なる組合せで機能します。構成は、組織のニーズと利用可能な既存のアーキテクチャによって異なります。
選択するアーキテクチャによって、パフォーマンスと安定性は確実に影響を受けます。高可用性を必要とし、それを目的としてOracle Collaboration Suiteに移行した組織もあります。アーキテクチャ全体に高可用性を必要としない組織では、そのために費用を節約できます。たとえば、高可用性をEmailにのみ実装し、CalendarやFilesなどのコンポーネントには実装しない場合、時間と費用を大幅に節約できます。
Oracle Collaboration Suiteの3つの層をすべて単一のノードに配置できます。ただし、このような配置アーキテクチャでは、組織の可用性、セキュリティおよびスケーラビリティの要件にすべて適合することが困難な場合があります。複数のノードに層を分散することによって、これらの要件に適合しやすくなります。
特定のノードでのリソースの利用を最適化するには、異なるタイプのワークロードがそのノードで混在しないようにする必要があります。通常、比較的大規模なシステムのアーキテクチャの場合は、これらの層が異なるノードに分散されます。
Oracle Collaboration Suiteの3つの層は、異なるタイプのワークロードを処理します。中間層は、ディスクのI/O操作がほとんどないCPU集中型およびメモリ集中型の層です。Infrastructure層およびInformation Storage層は、ディスクI/O集中型の層です。Information Storage層のディスクI/Oは、ほぼ同数の読取り操作と書込み操作で構成されます。Infrastructure層のディスクI/Oは、読取り操作のほうが書込み操作よりも多くなります。
Oracle Collaboration Suiteでは、リソースを増やす必要性が、中間層と、InfrastructureおよびInformation Storageでは異なります。これが、分散アーキテクチャが必要であるもう1つの理由です。分散アーキテクチャを使用すると、Information Storage層と中間層を別々にスケール・アップできます。次の図に、異なるノード上にあるInformation Storage層と中間層を示します。
パブリック・ネットワークからOracle Collaboration Suiteコンポーネントにアクセスできるようにする場合、このタイプのアクセスを保護する対策をとる必要があります。層を分散し、非武装地帯（DMZ）の後ろにシステムを配置することによって、システムのセキュリティを強化できます。標準的なセキュリティを実施することによって、たとえば、ネットワーク・トラフィックがインターネットからデータベースへ直接渡されることが防止されます。かわりに、このようなトラフィックは、DMZおよびアプリケーション・サーバー層を介してルーティングされます。
DMZには、パブリック・ネットワークとプライベート・ネットワークの間でトラフィックをセキュアに中継するために必要なハードウェアとソフトウェアを配置する必要があります。DoS攻撃やウィルスなど、既知のセキュリティ脅威に対しても予防策をとる必要があります。
配置内のユーザー数に適した容量を用意するには、まず最初に必要なサーバー数を評価する必要があります。ユーザー数以外に、使用頻度や同時実行性も考慮する必要があります。
メモリーとサーバーの必要性については、ドキュメント『Oracle Collaboration Suite サイジングおよびパフォーマンス・チューニング』を参照してください。ネットワーク・アーキテクチャの将来的な拡張の計画については、このマニュアルの「Oracle Collaboration Suiteのスケーラビリティ計画」の項を参照してください。
容量の計画時に考慮する必要があるもう1つの設計は、層の分離です。各層は独自の方法でリソースを使用するため、別々のサーバーにインストールすると有益です。この設計を使用すると、層をきめ細かく調整および拡大できます。
最後に、適切なハードウェア・プラットフォームを使用していることを確認します。組織の要件と既存の環境に応じて、様々なオペレーティング・システム（Solaris、Linux、Windowsなど）およびアーキテクチャ（2つ上のCPU、32ビットまたは64ビット）から選択できます。
中間層システムはシェアード・ナッシング・アーキテクチャを持つため、単一CPUまたはデュアルCPUなどの小規模で安価なハードウェアに適しています。データベース・サーバー・システムは、通常、メモリー要件の大きい大規模なマルチCPUノードに適しています。
適切に配置された中間層システムは、互いにバックアップとして機能します。このような重複中間層は、配置に柔軟性をもたらします。たとえば、1日の間に電子メールからOracle Filesアクセスまで負荷が大きく変動したときに、すべての中間層システムに負荷を分散できます。
第2章「Oracle Collaboration Suiteのネットワーク計画」で説明したように、Oracle Collaboration Suiteへのアクセスは、ネットワーク設定とセキュリティ計画によって決定されます。計画において、内部からであっても外部からであっても、あるいはその両方からであっても、コンポーネントへのアクセスが必要な場所を判断する必要があります。
ユーザーの場所に応じて、複数の中間層サーバーを実行できます。一般に、1台はDMZ内、1台は内部ネットワークで、どちらもシングル・サインオンへのアクセスが必要です。ただし、1組の中間層が配置される場合のほうが多く、NATとDNSを使用して分離とアクセスが提供されます。通常、これはサーバー数の制限または高可用性設定のためです。
どのような配置においても、拡張の計画は重要です。ユーザー・ベースのサイズまたはニーズに合わせて、配置の拡張を準備する必要があります。単一の層または非高可用性環境にインストールする場合でも、仮想ホスト名の使用をお薦めします。これにより、サーバーの名前を変更しなくても、後で複数のサーバーに渡り、サービスを抽象化できます。
拡張とメモリーの増強が可能なハードウェアを使用します。詳細は、「Oracle Collaboration Suiteの容量計画」を参照してください。
高可用性という用語は、コンポーネントまたはアプリケーションに障害が発生した場合でもネットワークが稼働し続ける機能を意味します。この機能は、電子メールなどの中心的な通信ツールや、Web Conferencingなどのリアルタイム通信ツールにとって特に重要です。
複数のノードに中間層を分散しても、高可用性は確保されません。電子メールやボイス・メールなどのサービスへの継続的なアクセスを実現するには、システムのすべての層が利用可能である必要があります。サービスへの継続的なアクセスを実現するには、システムのコンポーネントをレプリケートし、フェイルオーバー・メカニズムを実装して、障害が発生したコンポーネントから稼働中のコンポーネントへユーザーをリダイレクトする必要があります。
次の図では、Oracle Collaboration Suiteの3つの層は分散およびレプリケートされています。
Oracle Collaboration Suiteのすべての層を複製およびレプリケートすると、可用性は最大になります。中間層での障害を処理するために、ロード・バランシングが使用されます。Information Storage層の障害を処理するために、Oracle9i Real Application Clustersが使用されます。Infrastructure層のフェイルオーバー処置として、コールド・スタンバイ・サーバーが使用されます。
削除されたデータまたは破損したデータを最新の適正な状態へ復元する機能について計画する必要があります。これは、バックアップ設計の一部です。
ネットワークの冗長性には、ネットワーク障害が発生した場合にも稼働を継続するために導入した設計が含まれます。設計は、組織内での基本的なバックアップの実行から、高水準のサイト・ミラー化の保守まで様々です。Oracle Collaboration Suiteでは、後者はまだ不可能であるため、完全なバックアップ設計を実装することが最も良い方法です。
冗長性を最も必要とするコンポーネントを判断するには、ネットワーク全体で障害が発生した状況を想定し、どのサービスまたはコンポーネントを最初に復元するかを考えます。それらのコンポーネントには、重複層などのバックアップ設計を使用して、効率的なフェイルオーバー計画を導入します。すべてのコンポーネントが重要な場合には、高水準の冗長性が必要となります。
この項では、Oracle Collaboration Suiteを配置する既存または予定しているアーキテクチャについて、検討する必要がある次の詳細な問題について説明します。
ユーザー数およびユーザー・プロファイルに対して必要なサーバーの数
ドキュメント『Oracle Collaboration Suite サイジングおよびパフォーマンス・チューニング』を参照して、配置に必要なサーバー数を決定します。
組織が購入できるハードウェアの金額
理想的には、堅牢で可用性の高いOracle Collaboration Suiteインストールを構築するために必要な数のサーバーを購入します。ただし、予算が限られているために購入する数を減らして、ネットワーク・サービスとプロトコルを工夫して使用し、Oracle Collaboration Suiteをセキュアで効率的に実行する必要がある場合があります。
組織が管理できるサーバーの数
ITスタッフの規模によって大きく異なります。
Oracle Collaboration Suiteでは、AIX、Solaris、HP-UNIX、Linux、Tru64およびWindowsがサポートされています。選択するプラットフォームによって、使用できるハードウェアが異なります。64ビット・サーバーはデータベースに使用され、32ビット・サーバーは中間層に使用される傾向があります。詳細は、「Oracle Collaboration Suiteの容量計画」を参照してください。
配置は、次の3段階で計画できます。
開発: ホスト名、サーバー、コンポーネント、サービスおよびアクセスを、小規模で詳細に計画します。
ステージング: テスト・グループが使用できるように初期配置を拡張します。これにより、設計の短所を明らかにし、容量とパフォーマンスをテストします。
本番: 組織全体で使用するための公式の配置。
開発環境から本番環境への移行を容易にするには、「Oracle Collaboration Suiteのスケーラビリティ計画」で説明したように、最初から仮想ホスト名を使用することをお薦めします。この設計によって、サービスとコンポーネントの統合を大幅に変更しなくても、重複中間層の配置へと拡大できます。
組織は高可用性を必要とするか
一般に、高可用性の実装によって、必要なハードウェアは2倍になります。コールド・フェイルオーバー設計を実装する必要があり、Oracle9i Real Application Clustersの使用を考慮する必要があります。
高可用性の配置におけるストレージ設計は、標準的な配置の場合とは大きく異なります。共有ストレージが必要であり、外部SCSIストレージまたはストレージ・エリア・ネットワーク（SAN）を考慮する必要があります。SANは、様々な種類のデータ・ストレージ・デバイスを、関連付けられたデータ・サーバーにインターコネクトする高速専用ネットワークです。
高可用性環境は、より複雑なため、非高可用性環境よりもインストールと構成に非常に多くの計画と労力が必要になります。高可用性の管理もより複雑であり、十分な時間を割り当てる必要があります。
ほとんどの組織に推奨されるバックアップ設計には、定期的にスケジュールされたデータ・バックアップ、ファイル・システム・バックアップおよびテープ・バックアップについて定型的な方針が含まれます。また、組織に、規定されたリカバリ時間やデータ・リカバリの単位がある場合もあります。Oracle Collaboration Suiteインストールでは、Email、CalendarおよびFilesについて、バックアップされるデータ量を考慮します。
組織にアーカイブの必要性はあるか
Oracle Emailでは、古いメッセージまたはほとんどアクセスされない第3の表領域のメッセージを第3層に格納できます。これによって、ディスク上に経済的に格納できます。Oracle Collaboration Suiteのその他のアーカイブ設計は、現在開発中です。
この項（およびこの章の残りの部分）では、Oracle Collaboration Suiteで使用される様々なアーキテクチャ・タイプについて説明し、図を示します。これらの図は、独自の配置を計画するときに参照できます。実践的な配置事例については、第4章「Oracle Collaboration Suiteの配置例」も参照してください。
ここでは、次の内容について説明します。
Oracle Collaboration Suiteでは、Oracle EmailやOracle Filesなどの特定のアプリケーションを処理する専用中間層ノードを配置できます。または、これらのアプリケーションを実行する中間層ノードを重複させることもできます。この形式の重複には、次のような利点があります。
中間層管理の単純化: これは、各重複ノードを管理する要件およびプロセスが同じためです。
中間層リソースの効率的な使用: これは、様々なアプリケーションへの要求が1日のうちの時間によって変わるためです。たとえば、電子メール使用のピークが1日の開始時で、ファイル使用のピークがそれ以外のすべての時間である場合は、すべての中間層ノードがサービス要件のこの変化に対応できます。
次の図に、専用層オプションと重複層オプションの違いを示します。
専用中間層ノードを使用すると、営業日の開始時には、Oracle Filesノードは十分に使用されておらず、Oracle Emailノードは最大負荷に対処する必要があります。
ただし、システムの進化につれて、コンポーネントを段階的に導入する場合があります。たとえば、Oracle Emailを最初に実装し、次にOracle Files、その次にOracle Calendarサーバーを実装します。このような場合、前の実装段階への影響を減らすために、ハードウェアを特定の中間層コンポーネント専用にするほうが適切な場合があります。
この項では、Oracle Collaboration Suiteの3つの層それぞれのサービスとコンポーネントについて説明します。ここでは、次の内容について説明します。
中間層で提供されるサービスは、次のとおりです。
電子メール・プロトコル
Simple Mail Transfer Protocol（SMTP）
Post Office Protocolバージョン3（POP3）
Internet Message Access Protocolバージョン4（IMAP4）
ファイル・プロトコル
ファイル転送プロトコル（FTP）
サーバー・メッセージ・ブロック（SMB）
ネットワーク・ファイル・システム（NFS）
AppleTalkファイリング・プロトコル（AFP）
Web-based Distributed Authoring and Versioning（WebDAV）
Webプロトコル
Hypertext Transfer Protocol（HTTP）
HTTP-Secure（HTTPS）
電子メール・サービス（Webmail/HTTPを含む）
ファイル・サービス（Oracle Files/HTTPを含む）
カレンダ・サービス
Webcal/HTTP
SyncML/HTTP
Oracle Calendarサーバー
ワイヤレス・サービス（Wireless/HTTPを含む）
ポータル・サービス（Oracle9i Application Server Portal/HTTPを含む）
Oracle UltraSearchサービス（Oracle UltraSearch/HTTPを含む）
Web Cache
Infrastructure層は、次のコンポーネントで構成されています。
ディレクトリ・サービス
Lightweight Directory Access Protocol（LDAP）
Oracle Delegated Administration Service/HTTP
Oracle9i Application Server Single Sign-Onサーバー（シングル・サインオンとHTTPサービスを提供）
インフラストラクチャ・データベース（Oracle Internet Directory、Oracle9iAS Single Sign-OnおよびOracle9i Application Server Portalデータを含む）
図3-4に、専用中間層の実装を示します。
この図の詳細は、次のトピックで説明します。
専用層オプションでは、、中間層、Infrastructure層およびInformation Storage層は、個別の専用ノードにインストールされます。中間層では、専用ノードはOracle Email、Oracle FilesおよびOracle Calendarサーバー・サービスへのリクエストを処理します。データベース層では、専用ノードはOracle Email、Oracle Filesおよびインフラストラクチャ・データベースへのアクセス・リクエストを処理します。
Information Storageは、クラスタ化された2つ以上のノードのそれぞれにインストールされます。Oracle Filesインスタンス、Oracle Emailインスタンスおよび共有ディスク上に配置されたOracle9i Real Application Clustersを使用するように構成されたデータベースで構成されます。
比較的大規模な配置では、Oracle FilesデータベースとOracle Emailデータベースに対して、Oracle9i Real Application Clustersの個別のインスタンスを使用できます。この機能は、2つのデータベースのいずれかに障害が発生した場合、データベースを分離するのに役立ちます。Infrastructureは、別のノードにインストールされます。インフラストラクチャ・データベースは共有ディスク上に配置され、このノードの専用インスタンスからアクセスされます。中間層は複数のノードにインストールされますが、各ノードのロールに応じて固有のプロセスのみが開始されます。
可用性を確保するために専用ノードをレプリケートする場合、ハードウェア・ロード・バランシングを実装して、たとえば、電子メール・リクエストを複数の電子メール・ノードに、ファイル・アクセス・リクエストを複数のファイル・ノードに分散する必要があります。Oracle Calendarサーバー・ノードは例外であり、負荷を複数のカレンダにあらかじめ分割する必要があります。
専用層オプションの利点の1つは、すべてのワークロード・タイプが分離されており、システムで果たす役割に応じてノードを構成および調整できる点です。これにより、各ノードのパフォーマンスが向上します。ただし、この配置アーキテクチャ・オプションに基づくソリューションでは、正確なサイジング方法論を使用し、各Oracle Collaboration Suiteコンポーネントの使用方法の特徴を詳細に理解する必要があります。
専用層オプションの実装におけるインストールのタイプは、ストレージ、インフラストラクチャ、中間層およびコンピュータ・テレフォニ・サーバーの4つのみです。ただし、ノードは特定の役割の実行専用のため、異なる構成とプロセスの組合せを中間層に6つも設定する必要があります。また、データベース層では2つの設定手順があります。特定の役割専用のノードには、別の役割専用のノードとは異なる設定タスクと管理タスクがあります。
理論上、パッチは影響するノードにのみ適用する必要があります。たとえば、Oracle Files中間層のパッチをOracle Email中間層ノードに適用する必要はありません。この特長は、システムの保守に関する全般的な作業を軽減するのに役立ちます。
スケーラビリティの点では、専用層オプションによって、システムの様々な要素を個々にスケール・アップして、ワークロードの変化に適応する柔軟性が提供されます。たとえば、ある期間にファイル使用が増加した場合、システムの他の部分にはほとんど影響を与えずに、Oracle Filesサービスを処理するためのノードを追加できます。このことは、データベース層で増加した負荷が処理可能であるかぎり有効です。
SSLがシステムに実装されている場合は、HTTPSリクエストを処理するノードを追加できます。これらの追加ノードは、暗号化ワークロードの増加を管理するために必要です。また、システムを拡大する場合にノード以外の要素を追加することもできます。
インフラストラクチャの可用性を向上させるには、重複ノードを使用して、それぞれのノードでOracle Internet Directoryのインスタンスを実行します。Oracle Internet Directoryのこれらのインスタンスは、Oracle Internet Directoryレプリケーションを使用することによって同期化されます。標準的な操作では、Oracle Internet Directoryワークロードをこれらのサーバー間で静的に区分できます。
Oracle Calendarサーバーの場合、共有ディスク上のカレンダにアクセスできるフェイルオーバー・ノードを用意する必要があります。その他の中間層専用サーバーとDMZ内のサーバーの場合は、レプリケートが可能であり、ロード・バランシングを使用できます。データベース層については、Oracle9i Real Application Clustersを実行するクラスタ化されたデータベース・サーバーをOracle FilesデータベースとOracle Emailデータベースに対して使用できます。
ソリューションをアウトソーシングするか、またはソリューションがCollaboration Suite認証構成を使用する場合は、重複層オプションを使用する必要があります。
|
注意: Collaboration Suite認証構成とは、洗練された構成であるOracle Collaboration Suiteインストールです。この構成は、アウトソーシングされたOracle Collaboration Suiteサービスの管理アクティビティとメンテナンス・アクティビティを標準化するために、Oracle Outsourcingによって使用されます。標準的なファイル・レイアウトで配置されたOracle Collaboration Suiteの構成をとり、管理スクリプトとプロシージャによってサポートされます。 |
図3-5に、重複層の実装を示します。
この図の詳細は、次のトピックで説明します。
重複層オプションを実装すると、システムを単純化し、小規模システムで必要となるノード数を削減して、柔軟にコンポーネントを分散できます。この配置アーキテクチャには、最大で4つのノード・タイプがあります。中間層、Information Storage、InfrastructureおよびOracle Calendarサーバー、およびコンピュータ・テレフォニです。
中間層ノードは、Oracle Email、Oracle Files、Oracle CalendarサーバーおよびOracle UltraSearchなど、すべてのコンポーネントへのリクエストを処理します。これらのノードは、Webクライアントやワイヤレス・クライアントからのリクエストも処理できます。これらすべてのノードのインストール、設定およびプロセス・プロファイルは同じである必要があります。
Information Storageは、クラスタ化された2つ以上のノードのそれぞれにインストールされます。Oracle Filesインスタンス、Oracle Emailインスタンスおよび共有ディスク上に配置されたOracle9i Real Application Clustersを使用するように構成されたデータベースで構成されます。大規模な配置では、Oracle9i Real Application Clustersを、Oracle FilesデータベースとOracle Emailデータベースそれぞれに使用できます。これは、障害が発生した場合にこれらのデータベースを分離するのに役立ちます。
Infrastructureは、別のノードにインストールされます。そのデータベース（Oracle9i Real Application Clustersとの使用は保証されていません）は、共有ディスク上に配置され、ノードの専用インスタンスからアクセスされます。
Oracle Calendarサーバー・プロセスはInfrastructureと同じノードにインストールされるか、または専用ノードにインストールされ、Oracle Calendarサーバー・ファイル・システムは共有ディスクに配置されます。Oracle Calendarサーバー・プロキシは各中間層ノードに配置され、組み合せられたInfrastructureおよびOracle Calendarサーバー・ノードに、Oracle Calendarサーバーへのリクエストを渡します。このオプションのバリエーションとして、組み合せられたInfrastructureノードまたは専用のInfrastructureノードのかわりに、中間層ノードでOracle Internet Directoryプロセスを実行できます。この場合、インストールはCollaboration Suite認証構成の拡張構成: 複数Oracle Collaboration Suite Middle-Tierオプションに準拠することになります。このオプションにより、アプリケーション層とデータベース層が適切に分離されます。
重複層オプションでは、ワークロード・タイプをある程度分離できます。この分離は、専用層オプションほど広範なものではありません。重複層オプションを使用すると、Information Storageノードと中間層ノードのパフォーマンスを最適化できます。
この配置アーキテクチャ・オプションの利点の1つは、営業日のうちにコンポーネント間でワークロードが変化するときに、中間層全体ですべてのタイプのリクエストに応答可能であることです。このことは、前述の専用層のシナリオとは対照的です。前述のシナリオでは、Oracle Emailノードは十分に使用されず、Oracle Filesノードは最大負荷に対処する必要がありました。
重複層オプションでは、システムを大規模に拡大した場合でも、インストール、構成およびプロセスの組合せのタイプは4つのみです。すべての中間層ノードがすべてのタイプのリクエストを処理するということは、適切なツールまたは共有インストール・イメージを使用して、これらのノード（大規模なシステムでは何重にも重複する場合がある）の管理を自動化できるということです。ブレード・サーバーと共有インストール・イメージを使用すると、適切なディスクをマウントして中間層プロセスを開始することによって、新しい中間層処理機能を簡単に追加できます。中間層のパッチは、すべての中間層ノードに適用する必要があります。ただし、共有イメージを使用する場合、パッチの適用は1回のみです。
スケーラビリティの点では、この配置アーキテクチャ・オプションによって、徐々にスケール・アップする場合の柔軟性が提供されます。ただし、特定のコンポーネントをスケール・アップすることはできません。すべての中間層ノードがすべてのタイプのリクエストを処理するため、追加された新しいリソースにすべてのコンポーネントがアクセスします。特定のワークロードが大きくなると、すべての中間層ノードでこのワークロードの処理に使用される割合が増加します。
重複層オプションでは、可用性を向上させる代替案は専用層オプションの場合と同じです。インフラストラクチャの可用性を向上させるには、Oracle Internet Directoryレプリケーションを使用して、Oracle Internet Directoryのインスタンスが同期化された重複ノードを実現します。
Oracle Internet Directoryサービスのワークロードを、通常の処理のために、これらのノード間で静的に区分できます。Oracle Calendarサーバーの場合、共有ディスク上のOracle Calendarサーバーにアクセスできるフェイルオーバー・ノードを用意する必要があります。その他の中間層専用サーバーとDMZ内のサーバーの場合は、レプリケートとロード・バランシングを使用できます。データベース層については、Oracle9i Real Application Clustersを実行するクラスタ化されたデータベース・サーバーをOracle FilesデータベースとOracle Emailデータベースに使用できます。
それぞれの配置アーキテクチャ・オプションに、利点があります。重複層オプションでは、ある程度のワークロードの分離が可能であり、比較的小規模で開始して、特定のサービスのワークロードが増加するにつれてリソース使用を最大化できます。また、この配置アーキテクチャ・オプションは管理が比較的安価であり、Collaboration Suite認証構成との整合性もあります。
専用層オプションには、特定の用途に対してサーバーを調整し、コンポーネントごとにスケール・アップするという非常に大きな柔軟性があります。ただし、このアーキテクチャは管理に費用がかかります。このアーキテクチャは、コンポーネントを段階的に実装するシステムやリソース要求の見積りが可能な大規模なシステムに適しています。
この項では、Oracle Collaboration Suiteの配置について説明します。セキュリティ、可用性、スケーラビリティおよびフォルト・カブリングを最適化しながらイントラネットおよびインターネットへのアクセスを可能にするアーキテクチャ全体に、すべてのクライアントとすべてのサービスが配置されます。この配置は、重複中間層の配置です。図3-6に、完全にフォルト・トレラントなネットワーク、および完全な高可用性と複数のネットワーク・ゾーンを配置する多種多様なコンポーネントを示します。
|
注意: 図3-6は、用途の例です。大規模な組織のニーズに適した配置の例を示します。小規模な組織の場合は、より単純なアーキテクチャと少ないハードウェア要件でOracle Collaboration Suiteを配置できます。セキュリティ、パフォーマンスおよび可用性に対して様々なレベルの要件を持つ小規模、中規模および大規模な組織のニーズに適した典型的なOracle Collaboration Suiteの配置例については、第4章「Oracle Collaboration Suiteの配置例」を参照してください。 |
この配置については、次のトピックで説明します。
この項では、ネットワーク・インフラストラクチャの次の要素について説明します。
Oracle Collaboration Suiteネットワーク・アーキテクチャのセキュリティは、3つのゾーン設定を使用します。この設定は、イントラネット、DMZおよび外部ネットワーク（インターネットなど）で構成されます。
ネットワークは、各Oracle Collaboration Suiteコンポーネントへの二重ネットワーク・パスによって、冗長になるように構成されます。スイッチの回数を減らすには、仮想LANを使用します。Oracle Collaboration Suiteネットワーク・インフラストラクチャ全体は、100MB/秒以上である必要があります。Network Attached Storageを使用する場合、図でデータベース・サーバーの次にある最も左側のネットワーク・セグメントは、冗長性を持たせて1000MB/秒である必要があります。冗長性を確保するには、サーバー・ホストごとに複数のネットワーク・アダプタ・カード（2枚または4枚）を使用する必要があります。
ファイアウォールは、イントラネットとDMZ、DMZとインターネットの境界を定めます。これらのファイアウォールは、一方に障害が発生しても他方はサービスを提供し続けるように、ハートビート・メカニズムを使用して相互に監視し合うように構成されます。
セキュリティのために、DMZファイアウォールは、Webまたはワイヤレス・メディアによるHTTPSアクセスとSMTPサービスのみを許可するように構成されます。また、WebセミナーやWeb会議を可能にするOracle Web Conferencingによって要求されるポートへの接続を許可するように構成されます。
イントラネット・ファイアウォールは、DMZからイントラネットへ渡されるHTTPおよびSMTPサービスのみを許可するように構成されます。また、Oracle Web ConferencingによるWebセミナーまたはWeb会議をインターネット上で実施する必要がある場合は、Oracle NetworkおよびLDAPアクセスが、ファイアウォールによって排他的にDMZ内のWeb Conferencingアプリケーション・サーバーに提供される必要があります。
ロード・バランサは、Oracle Collaboration Suiteの配置アーキテクチャにおいて重要な役割を果たします。電子メール・リレーやインターネットへのWebアクセスなどのサービスのフロント・エンドとして、DMZ内にハートビートとフェイルオーバーのペアで構成されます。また、イントラネット内のOracle Collaboration Suiteサービスの複合体のフロント・エンドも形成します。ロード・バランサは、使用可能なリソースへ負荷を動的に分散させるために、アプリケーション・サービスを提供するアクティブ・サーバーのプールへリクエストをルーティングします。あるノードに障害が発生した場合、コンテンツ・スイッチは、残存するサーバーへサービス・リクエストをルーティングします。ロード・バランサのいずれのペアについても、スティッキー・セッション属性をすべてのサービスに対して設定する必要があります。
DMZ内のロード・バランサ・ペアは、仮想ホストを使用して構成されます。これらの仮想ホストは、Web CacheサーバーとWeb Conferencingアプリケーション・サーバーを介してHTTPSサービスに、SMTPリレー・サーバー・プールを介してSMTPサービスにマッピングされます。
また、一部のロード・バランサに共通する特長は、SSLアクセラレーションを提供する機能です。この機能が使用可能な場合は、この機能を使用してDMZサーバーから暗号化作業をオフロードし、リソースの要件を軽減する必要があります。
イントラネット内のロード・バランサ・ペアは、区分された2つのサーバー・プールにマッピングされた仮想ホストとサービスを使用して構成されます。
この項では、Oracle Collaboration Suiteによってサポートされる次のエンド・ユーザー・デバイスについて説明します。
ネイティブ・クライアントという用語は、Microsoft Outlookなどのクライアント側アプリケーションを実行するPC、Netscape Messenger、Oracle Corporate Time、PDAなどのクライアント・デバイスを意味します。
ネイティブ・クライアントは、アプリケーション・プロトコル（POPやIMAPなど）または独自のプロトコルを使用して通信する必要があるため、通常は、イントラネット内でのみ、あるいはイントラネット外で仮想プライベート・ネットワーク（VPN）またはイントラネット・ダイアルアップ・アクセスを介して使用されます。
Oracle Collaboration Suiteアプリケーションは、PC、PDAおよび携帯電話上のWebクライアントに対して、マークアップベースのアプリケーションとして提供されます。セキュリティのために、すべてのWebクライアントは、SSLを使用して公開されたサービスにのみアクセスする必要があります。
外部WAPゲートウェイによって、携帯電話および特定のタイプのPDAからOracle Collaboration Suiteサービスにアクセスできます。これらのゲートウェイは、モバイル・サービス・プロバイダのサイトに配置される場合もあります。アクセス・タイプは、次のいずれかです。
プル型サービス。PCブラウザ・アプリケーションなど。
プッシュ型サービス。WAPプッシュ操作など。
|
注意: WAPプッシュ操作では、バンド外メッセージをモバイル機器に送信し、アラートやアプリケーションにログインする機会をユーザーに提示できます。 |
Oracle Wireless & Voiceアプリケーションは、主にモバイル・データ・アクセスのためにWAPゲートウェイと通信します。
ボイスメールおよびFAX用に構成すると、FAX機器からOracle Voicemail & Faxサーバーにページを送信できます。これらのページはFAXとしてユーザーの受信ボックスに配信されます。ワイヤレス・サービスおよびボイス・サービス用に構成すると、音声サーバーでFAX機器への電子メールまたはファイルの送信などのアウトバウンド操作を実行できます。
ボイスメールおよびFAX用に構成すると、電話（携帯または固定）を使用してボイスメールを送受信できます。ワイヤレス・サービスおよびボイス・サービス用に構成すると、音声認識と音声合成の両方を使用して多数のOracle Collaboration Suiteサービスにアクセスできます。また、Oracle Wireless & Voiceコンポーネントを使用してアウトバウンド・コールを行い、ユーザーにアラートを配信できます。
DMZ層は、インターネット上でサービスを提供するために公開されます。SMTP、Web HTTPおよびWeb Conferencingのトラフィックを許可するようにDMZファイアウォールを構成する必要があります。
この項では、DMZ層の次の要素について説明します。
DMZファイアウォールは、インターネット上に公開されたサービスにのみDMZへのアクセスを許可します。このファイアウォールは、SMTP、Web over HTTPおよびWeb Conferencingのトラフィックを許可するように構成する必要があります。ファイアウォールに障害が発生した場合にフェイルオーバーが機能するように、2つの別々のファイアウォールがそのファイアウォール間で実行されるハートビート・メカニズムとともに使用されます。
図3-6は、1つはファイアウォールに接続され、もう1つはDMZ内のOracle Collaboration Suiteコンポーネントに接続された2つのLBRを示しています。ファイアウォールと同様に、LBRに障害が発生した場合にフェイルオーバーが機能するように、LBRはLBR間のハートビートを監視するように構成されます。DMZのLBRは、DMZ内のサービスレベル・フェイルオーバーも提供します。LBRは、DMZホストへのスティッキー・セッション用に構成する必要があります。
SMTPゲートウェイは、Oracle Collaboration Suiteシステムとの間で電子メールをリレーします。SMTPゲートウェイは、標準的なsendmailを実行するホストです。このホストは、Oracle Collaboration Suiteがサービスを提供するユーザーとドメインへ、およびイントラネット上に配置されたSMTPメール転送エージェントへ、アドレス指定された電子メールをリレーするように構成されます。また、インターネット上の許可されたホストから電子メールをリレーするように構成することもできます。既知の許可されたホストからのみメールをリレーするようにSMTPリレーを構成しない場合、インフラストラクチャはスパマーに悪用される危険性があります。認証を要求し、SSLによる安全なSMTP接続を行うように、SMTPリレーを構成することもできます。
DMZ内には2つ以上のSMTPリレーがあり、DMZのLBRは両方のSMTPメール・リレー間でロード・バランシングを行います。一方のSMTPリレーに障害が発生した場合は、残存するSMTPリレーがサービスの提供を継続します。電子メールの量が非常に多い場合は、SMTPリレー・サーバーをDMZ層に追加導入して容量を追加できます。
SMTPゲートウェイは、受信する電子メールをスパム対策コンポーネントへリレーします。このコンポーネントは、スパムとして識別されなかった電子メールをイントラネット上のユーザーおよびドメインへの配信のためにSMTPゲートウェイへ戻します。スパム対策サーバーをDMZにSMTPゲートウェイとともに（または同じサーバー上に）配置すると、スパムを早期にブロックできます。また、電子メールをDMZ内のSMTPゲートウェイへリレーする前に、インターネット上のサービス・エンティティで受信する電子メールのスパムをフィルタリングするスパム対策ソリューションもあります。この場合、スパムがDMZに到達することはありません。必要に応じて、冗長性のために、またはスループットが向上するようにスパム対策サーバーを構成できます。
DMZ内では、WebサービスはWeb Cacheインスタンスを介してルーティングされます。これらのWeb Cacheインスタンスは、イントラネット上のアプリケーション・コンテンツを生成するWebサーバーのリバース・プロキシおよびキャッシング・サーバーの役割を果たします。DMZ内には、2つ以上のWeb Cacheインスタンスがあります。これらのWeb Cacheインスタンスには、ロード・バランシング機能とフェイルオーバー機能があります。
Oracle Web Conferencingが構成されている場合は、コンポーネントのサブセット（特に、Web Conferencingアプリケーション・サーバー）をDMZ内に配置する必要があります。これにより、インターネット上の参加者はWeb会議およびWebセミナーに参加できます。
Web over HTTP（会議およびセミナーの検索、参加、または開始）とWeb Conferencing固有のプロトコルの2つのポートが、DMZファイアウォールの通過を許可されている必要があります。Web Conferencingには独自の内部フェイルオーバー・メカニズムがあるため、Web Conferencing固有のプロトコルは、DMZのLBRを介してルーティングされる必要はありません。
また、Web Conferencingアプリケーション・サーバーはOracle Internet DirectoryとOracle Network Servicesを必要とするため、Web Conferencingアプリケーション・サーバーからのみこれらのプロトコルにアクセスできるように、イントラネット・ファイアウォールを構成する必要があります。可用性とキャパシティを実現する、2つ以上のWeb Conferencingアプリケーション・サーバーがあります。
イントラネット層は、中心的なOracle Collaboration Suiteコンポーネントをホストします。また、イントラネットは安全で、信頼されたネットワークであり、Oracle Collaboration Suiteのほとんどのユーザーはイントラネットの範囲内にいると想定されます。イントラネットの境界は、イントラネットとDMZの間にあるイントラネット・ファイアウォールによって定められます。イントラネットの範囲内のユーザーは、イントラネット上に存在するか、VPNサーバーによってトンネリングされるか、またはモデム・バンクを介して接続されます。
この項では、DMZ層の次の要素について説明します。
イントラネットのLBRは、ハートビート監視とのフェイルオーバー・ペアとして構成されます。また、アプリケーション・サーバーの1つのプールにHTTPリクエストを分散し、中心的なOracle Collaboration Suiteインフラストラクチャ・コンポーネントを含む別のプールにLDAPプロトコル・リクエストを分散するためにも構成されます。LBRによってルーティングされるOracle Collaboration Suiteサービスに対して、スティッキー・セッション属性を設定する必要があります。
LDAPディレクトリ・プロトコルにサービスを提供するようにOracle Internet Directoryを構成するには、より詳細な設定が必要です。プレビューとして、アクティブ-アクティブ構成の2つ以上のサーバーでOracleサービスが提供されます。
アクセスする固有のLDAP Oracle Internet Directoryサーバーに従って、Oracle Collaboration Suiteサービスを区分することをお薦めします。このためには、イントラネットのLBRのLDAPサービス用に3つの仮想ホストを構成する必要があります。1番目の仮想ホストは、1番目のLDAPサーバーにマッピングし、2番目のLDAPサーバーにフェイルオーバーするホスト/LDAPポートとして構成する必要があります。2番目の仮想ホストは、2番目のLDAPサーバーにマッピングし、1番目のLDAPサーバーにフェイルオーバーするホスト/LDAPポートとして構成する必要があります。これら2つの仮想ホストは、ロード・バランシングを実装するようには構成されません。3番目の仮想ホストは、両方のLDAPサーバーにマッピングし、2つのサーバー間のロード・バランシングを行うように構成する必要があります。
Oracle Internet DirectoryはOracle Collaboration Suiteインフラストラクチャの中核であり、他のすべてのOracle Collaboration Suiteコンポーネントで使用されます。アクセスは、LDAPプロトコルによって行われます。その役割は重要であるため、高可用性を構成する必要があります。このためには、最初にアクティブ-アクティブ構成のサーバーの組合せでIP/ストレージ・フェイルオーバーを設定し、次に、レプリケーションを設定します。サーバーの各組合せは独自のインフラストラクチャ・データベース・レプリカを操作し、Oracle Advanced Replicationを使用して他の組合せへ双方向でレプリケートします。
ネイティブ・クライアントに、LDAPサーバー・ホスト名とポートを割り当てる必要があります。前述のLBR構成を使用すると、ネイティブ・クライアントに、両方のLBRサーバー間のロード・バランシングを行うように構成されたLBRの仮想ホストのホスト名とポートを割り当てることができます。
各レプリカは、Oracle9i Real Application Clustersを使用するように構成できます。これは、図3-6では示されていません。
エンタープライズ・ディレクトリ情報は、Oracle Collaboration Suiteのディレクトリ・インフラストラクチャ以外のソースによって提供されます。この場合、Directory Integration Platform（DIP）を使用して、Oracle Collaboration Suiteの主なディレクトリ要素を双方向で移入および更新できます。
Oracle Calendarサーバーは、カレンダ情報の独自のデータ・ストアを保持します。可用性を維持するために、中核のOracle Calendarサーバー・コンポーネントは、物理サーバーのIP/ファイル・システムのアクティブ/スタンバイ・フェイルオーバーの組合せで実行されるように構成されます。Webベースのカレンダ・アプリケーションやSyncMLサービスなどのHTTPベースのカレンダ・サービスは、異なるホストで実行されます。Outlook ConnectorやCorporate Timeなどのネイティブ・クライアントは、本来のOracle Calendarサーバーに直接接続します。
Oracle Voicemail & Faxサーバーをイントラネット上で構成し、PBXに接続する必要があります。通常、PBXへの接続は、T1/E1または電話回線の形式です。ボイスメールおよびFAXを受信するには、ビジーまたは応答のないコールを受信者情報とともにOracle Voicemail & Faxサーバーへ送信するように、PBXを構成する必要があります。高可用性を実現するために、Oracle Voicemail & Faxサーバーはペアになっています。各サーバーは、一方に障害が発生した場合に残存するサーバーへコールが再ルーティングされるように、PBXで構成されます。電話ベースのボイスメールを取得するために、ダイアルイン番号を提供するようにPBXを構成する必要があります。
ボイス・サーバーは、イントラネット上に配置する必要があります。これらのサーバーは、別個のハントグループ内のPBXに（通常、T1/E1または電話回線によって）接続する必要があります。電子メール、カレンダ、ファイルおよびディレクトリ・サービスへの電話による音声認識および音声合成インタフェースを実現するには、ボイスメール・アクセス番号とは異なるダイアルイン・アクセス番号を提供するようにPBXを構成する必要があります。PBXは、ボイス・サーバーが電話配信アラートのアウトバウンド・コールを行うことを許可する必要があります。
Oracle Web Conferencingボイスおよび変換サーバーは、ボイスのデジタル化とプレゼンテーション・ドキュメントの変換サービスを行います。これらのサーバーは、フェイルオーバー・ペアでイントラネット上に配置されます。DMZ内のWeb Conferencingアプリケーション・サーバーは、イントラネット上のすべてのボイスおよび変換サーバーと通信できるように構成する必要があります。前述のとおり、Web Conferencingアプリケーション・サーバーは、イントラネット・ファイアウォールによって渡されたポートを使用して、DMZからボイスおよび変換サーバーへ通信します。
Oracle UltraSearchクローラ・サーバーを構成する場合は、フェイルオーバー（IP/ファイル・システム）ペアとして配置する必要があります。これらのサーバーは、Oracle UltraSearchのデータベースへのアクティブ/スタンバイ・アクセスを共有する必要があります。クローラは、指定されたサイトにアクセスして、イントラネット（場合によってはインターネット）検索索引を作成します。
イントラネット配置の中心となるのは2つ以上のサーバーのプールであり、それぞれのサーバーがすべてのOracle Collaboration Suiteアプリケーション・プロトコルを実行します。イントラネットのLBRは、プロトコルに従ってこのプール内のサーバーにリクエストを分散します。提供されるサービスは、次のとおりです。
SMTP（イントラネット上で送受信される電子メール用）
POP3およびIMAP（ネイティブ電子メール・クライアント用）
WebDAV、FTP、SMB、AFPおよびNFSファイル・アクセス・プロトコル
WebおよびモバイルXMLユーザー・インタフェース（Oracle9iAS Portal、Webmail、Web Calendar、SyncML、Oracle Files Webアプリケーション、Oracle Wireless & VoiceおよびOracle UltraSearch用）
Oracle9iAS Single Sign-OnサービスおよびセルフサービスOracle Delegated Administration Service
プール内に2つ以上のホストを構成することによって、すべてのアプリケーション・プロトコルに高可用性を確保できます。スケーラビリティとスループットの拡張のために、このプールにサーバーを追加し、LBRの構成を更新できます。また、この構成では、すべてのアプリケーション・サービスにおいて、このプール内のリソースが最大限活用されます。
推奨される方法に従って、プール内の各サーバー上のディレクトリ・サービスにアクセスするアプリケーション・サービスを構成する必要があります。SMTP MTA、Oracle Files、Oracle9iAS Portal、Oracle Wireless & Voice、WebmailおよびOracle Web Conferencingは、1台のLDAPサーバーのみにリクエストをルーティングするLBR上の仮想ホストの1つにアクセスするように構成する必要があります。IMAP、POP、Oracle Delegated Administration Service、Oracle9iAS Single Sign-On、Oracle CalendarサーバーおよびOracle Voicemail & Faxは、2番目のLDAPサーバーにマッピングするLBR上の他の仮想ホストにアクセスするように構成する必要があります。この形式の分割には、次のような利点があります。
ディレクトリ更新がグループ化されます。パスワードの更新など、ユーザーに影響を与える可能性のあるディレクトリ更新がグループ化されます。このため、ディレクトリ・レプリカの伝播が完了していなくても、更新は有効になります。
ディレクトリ・サービスへのリクエストが均等分散されます。通常、SMTP MTA、Oracle9iAS Single Sign-On、IMAP、POPおよびOracle Calendarは、ディレクトリ・サービスに大きな負荷をかけます。Oracle Files、Oracle9iAS Portal、Oracle Wireless & Voice、WebmailおよびOracle Web Conferencingのユーザー・インタフェースはディレクトリ・サービスに大きな負荷をかけません。分割によって、ディレクトリ・サービスのトラフィックは、競合するアプリケーション・サービス間で均等に調整されます。
（ディレクトリ、そのレプリカ、Oracle CalendarサーバーおよびOracle UltraSearchクローラのデータ・ストアについてすでに説明したので）誤記のように思われるかもしれませんが、Oracle Collaboration Suiteのあらゆる配置において、データベース記憶域の大部分はOracle EmailとOracle Filesによって占められます。
図3-6に示した配置アーキテクチャでは、Oracle EmailデータベースとOracle Filesデータベースの両方が大きなワークロードを処理すると想定して、異なるデータベースを使用するガイドラインに従う必要があります。また、どちらのデータベースも、マルチサーバーOracle9i Real Application Clustersアクセス用に構成されます。この特長によって、データベース層の可用性とスケーラビリティが拡張されます。
Oracle Files Storeは、一方のサーバーがユーザー・ファイルが格納されているデータベースへ、他方のサーバーが電子メールが格納されているデータベースへアクティブ-アクティブ・アクセスするために、2台以上のサーバーで実装されます。これらのサーバーは、Oracle9i Real Application Clusters用に構成されます。また、ストレージへの接続がNASかSANかに関係なく、Oracle Files Storeの物理ディスク・ストレージへの冗長パスがあります。前述のように、NASストレージを使用する場合、このセグメントのネットワーク帯域幅は1000 MB/秒である必要があります。また、Oracle Files Storeは、高速バックアップを可能にするためにバックアップ・サーバーに直接接続されますが、データベース・サーバーによる直接処理は、通常、必要ありません。
