| Oracle Application Serverエンタープライズ・デプロイメント・ガイド 10gリリース3（10.1.3.2.0） E05046-01 |
|
 戻る |
 次へ |
Oracle WebCenter Suiteのエンタープライズ・デプロイメントとは、リファレンス構成の1つであり、Oracle WebCenter Framework（ポートレット、コンテンツ統合およびセキュリティ用のランタイム開発フレームワーク）とOracle WebCenter Services（Oracle Content DBを含む）を使用して大規模でミッションクリティカルなビジネス・ソフトウェア・アプリケーションをサポートするよう設計されています。ハードウェアおよびソフトウェアをエンタープライズ・デプロイメント構成で使用すると、次の環境が提供されます。
サービスの品質が高い
システム・ワークロードの管理とロード・バランシングが、効率的に行われます。
リソースが追加または削除されても、アプリケーションは引き続き動作します。
システム・メンテナンスや予期しない障害による停止が最小限になります。
すべての着信ネットワーク・トラフィックは単一のセキュアなポート上のロード・バランシング・ルーターで受信され、ファイアウォール内の内部IPアドレスに転送されます。ファイアウォール内では、DMZの中に機能コンポーネントがグループ化されます。
セキュリティ・システムが統合化されます。
管理アクセスが隔離されます。
ソフトウェアのプロビジョニングと管理が効率的
アプリケーションを簡単に配布できます。
システムが、セントラル・コンソールから単一の論理ユニットとして管理および監視されます。
障害検出および再起動のメカニズムによって、可用性が確保されます。
このマニュアルで示すOracle Application Server構成は、あらゆるトランザクションに高度なセキュリティを保証し、ハードウェア・リソースの効率的な利用を可能にするほか、様々なアプリケーションを使用したエンタープライズ・コンピューティングに信頼性の高い、標準に準拠したシステムを提供できるように設計されています。Oracle Application Server構成のセキュリティおよび高可用性は、ファイアウォール・ゾーンでの隔離とソフトウェア・コンポーネントのレプリケーションにより実現されます。
エンタープライズ・デプロイメント・アーキテクチャにより、セキュリティが保証されます。これは、すべてのソフトウェア・コンポーネントが機能別にグループ化されてDMZ内で隔離され、すべてのトラフィックがプロトコルとポートによって規制されるためです。このアーキテクチャは、次に示す特徴により、必要なあらゆるレベルのセキュリティおよび高いレベルの標準準拠が保証されます。
外部クライアントからの通信は、必ずロード・バランシング・ルーターを経由します。
ロード・バランシング・ルーターからデータ層DMZへの直接の通信は行えません。
コンポーネントはWeb層、アプリケーション層およびデータ層のDMZ間で分離されます。
あるファイアウォール・ゾーンで開始された通信は、次のファイアウォール・ゾーンで必ず終了します。
Identity ManagementコンポーネントはDMZ内に配置されます。
DMZ間にわたるコンポーネント間の通信はすべて、ファイアウォールのルールに従い、ポートとプロトコルによって制限されます。
Oracle WebCenter Suiteによるエンタープライズ・デプロイメントにより、WebCenter Frameworkコンポーネントのデプロイメントを、可用性が高くスケーラブルでセキュアな方法で実現可能です。
このマニュアルでは、次の各セキュリティ・オプションによってOracle WebCenter Suiteのエンタープライズ・デプロイメントを構成する手順について説明します。
JSSOとOracle Internet Directoryを実装するmyWebCenter（図1-1を参照）
Oracle COREid Access and Identityを実装するmyWebCenter（図1-2を参照）
OracleAS Single Sign-Onを実装するmyWebCenter（図1-3を参照）
表1-1に、セキュリティ構成およびその構成で使用するIDストアとポリシー・ストアを示します。
ポリシー・ストアとは、OracleAS JAAS Providerの認可権限のリポジトリのことです。Oracle Internet DirectoryとXML（ORACLE_HOME/j2ee/home/system-jazn-data.xmlファイル）は、ポリシー・ストア・リポジトリとしてサポートされています。
ユーザー・アカウントとロールは、エンタープライズIDストア（通常はLDAPサーバー）に常に組み込まれており、ポリシー・ストアでレプリケートされません。ポリシー・ストアには、エンタープライズIDストアのグループとロールへの参照権限と付与権限のみがあります。同じリポジトリ（Oracle Internet DirectoryまたはXMLファイルベース）は、IDストアとポリシー・ストアの両方として使用できます。
表1-1 サポートされるセキュリティ構成
| デプロイメント構成 | ポリシー・ストア | IDストア |
|---|---|---|
|
Java SSOを実装するmyWebCenter脚注1 |
OracleAS JAAS ProviderおよびOracle Internet Directory |
OracleAS JAAS ProviderおよびOracle Internet Directory |
|
OracleAS Single Sign-Onを実装するmyWebCenter1 |
OracleAS JAAS ProviderおよびOracle Internet Directory |
OracleAS JAAS ProviderおよびOracle Internet Directory |
|
Oracle COREid Access and Identityを実装するmyWebCenter1脚注2 |
OracleAS JAAS ProviderおよびXML |
OracleAS JAAS ProviderおよびOracle Internet Directory脚注3 |
脚注1 Oracle Content DBおよびWebCenter Suiteでは、jazn.xmlまたはOracle Internet Directoryを使用する必要があります。WebCenter Suiteがサポートしている認証メカニズム（JAZN-XML、Java SSOまたはOracleAS Single Sign-On）は、アダプタによってもサポートされています。Oracle Content DBサーバーには異なるサポート・モデルが存在します（たとえば、Java SSOはサポートされていません）。
脚注2 Oracle COREid Access and Identity環境で権限を追加する方法の詳細は、『Oracle Containers for J2EEセキュリティ・ガイド』の第11章を参照してください。
脚注3 Oracle COREid Access and Identityをポリシー・ストアのOracleAS JAAS ProviderおよびXML、IDストアのOracle Internet Directoryとともに使用する場合は、すべてのユーザー・アカウントとロールがIDストア（Oracle Internet Directory）にあり、かつポリシー権限がポリシー・ストア（system-jazn-data.xmlファイル）にあることを確認してください。このファイルにおける権限は、IDストア（Oracle Internet Directory）のユーザーを参照する必要があります。詳細は、第4章の「Oracle COREid Access and Identity用Oracle WebCenter Servicesのユーザー・ロールの構成」を参照してください。
myWebCenterシステムのサーバーは次の各層にグループ化されます。
Web層: WEBHOST1とWEBHOST2。Oracle HTTP Serverがインストールされています。
アプリケーション層: APPHOST1とAPPHOST2。Oracle Containers for J2EEがインストールされており、複数のOC4Jインスタンスにアプリケーションがデプロイされています。
Oracle COREid Access and Identityを使用するmyWebCenterでは、この層に管理者用のWebGate、WebPass、Oracle COREid Access and IdentityのIDサーバ、Access Server、Access ManagerおよびADMINHOSTも含まれます。
OracleAS Single Sign-Onを使用するmyWebCenterでは、この層にOracleAS Single Sign-OnとOracle Delegated Administration Servicesを実装するIDMHOST1とIDMHOST2が含まれます。
データ層: OIDHOST1とOIDHOST2。10gリリース3（10.1.4.0.1）のOracle Internet Directoryと、2ノードのReal Application ClustersデータベースであるINFRADBHOST1およびINFRADBHOST2がインストールされています。
図1-1 JSSOとOracle Internet Directoryを実装するmyWebCenter.comのエンタープライズ・デプロイメント・アーキテクチャ
図1-2 Oracle COREid Access and Identityを実装するmyWebCenter.comのエンタープライズ・デプロイメント・アーキテクチャ
図1-3 OracleAS Single Sign-Onを実装するmyWebCenter.comのエンタープライズ・デプロイメント・アーキテクチャ
表1-2は、各ユーザー認証方法を使用したmyWebCenterの構成プロセスをまとめたものです。選択した構成で、最初の列に示されている手順を順番に実行してください。
表1-2 エンタープライズ・デプロイメントの構成手順
| 実行する手順 | JSSO and Oracle Internet Directoryを実装するmyWebCenterの構成 | Oracle Access Managerを実装するmyWebCenterの構成 | OracleAS Single Sign-Onを実装するmyWebCenterの構成 |
|---|---|---|---|
|
|
○ |
○ |
○ |
|
第3章の「Web層とアプリケーション層のインストールと構成」 |
○ |
○ |
○ |
|
第3章の「OC4J_AppsとOC4J_WebCenterのインスタンスのセッション状態レプリケーションの構成」 |
○ |
○ |
○ |
|
第3章の「RACデータベース用APPHOST1とAPPHOST2の構成」 |
○ |
○ |
○ |
|
|
○ |
○ |
○ |
|
|
○ |
× |
○ |
|
第4章「Oracle COREid Access and Identityのインストールと構成」 |
× |
○ |
× |
|
第5章「OracleAS Single Sign-OnとOracle Delegated Administration Serviceのインストールと構成」 |
× |
× |
○ |
表1-3および表1-4は、WindowsおよびLinuxオペレーティング・システムのエンタープライズ・デプロイメントに最低限必要なハードウェア要件をそれぞれ示しています。メモリーの数値はOracle Application Serverのインストールおよび実行に必要なメモリーを示しています。ただし、大部分の本番サイトでは、最低でも1GBの物理メモリーを構成してください。
詳細な要件またはこれ以外のプラットフォームに関する要件は、ご使用のプラットフォームのOracle Application Serverのインストレーション・ガイドを参照してください。
表1-3 myWebCenterのハードウェア要件（Windows）
| サーバー | プロセッサ | ディスク | メモリー | TMPディレクトリ | スワップ |
|---|---|---|---|---|---|
|
WEBHOST |
300MHz以上のIntel Pentiumプロセッサを推奨 |
400MB |
512MB |
インストーラの実行には55MB（インストール・タイプによっては256MB）が必要 |
512MB |
|
APPHOST |
300MHz以上のIntel Pentiumプロセッサを推奨 |
2GB |
1GB |
400 |
1GB |
|
OIDHOSTおよびINFRADBHOST |
300MHz以上のIntel Pentiumプロセッサを推奨 |
2.5GB |
1GB |
インストーラの実行には55MB（インストール・タイプによっては256MB）が必要 |
1GB |
|
ADMINHOST |
300MHz以上のIntel Pentiumプロセッサを推奨 |
400MB |
512MB |
なし |
512MB |
表1-4 myWebCenterのハードウェア要件（Linux）
| サーバー | プロセッサ | ディスク | メモリー | TMPディレクトリ | スワップ |
|---|---|---|---|---|---|
|
WEBHOST |
Pentium（32ビット）、450MHz以上 |
520MB |
512MB |
400MB |
1.5GB |
|
APPHOST |
Pentium（32ビット）、450MHz以上 |
2GB |
1GB |
400 |
1.5GB |
|
OIDHOSTおよびINFRADBHOST |
Pentium（32ビット）、450MHz以上 |
2.5GB |
1GB |
400MB |
1.5GB |
|
ADMINHOST |
Pentium（32ビット）、450MHz以上 |
520MB |
512MB |
400MB |
1.5GB |
本番の要件は、アプリケーションやユーザー数によって異なります。このマニュアルで説明するエンタープライズ・デプロイメント構成はすべて、層ごとに2台ずつサーバーを使用することで、フェイルオーバー機能を実現します。しかしこれは、アプリケーションやユーザー数に対して予想される十分なコンピューティング・リソースではありません。パフォーマンスが低下するほどシステムのワークロードが増大した場合は、必要に応じて3台目のサーバーを構成に追加できます。これには、各層（WEBHOST2、APPHOST2、INFRADBHOST2）に2台目のサーバーをインストールおよび構成したときの手順を繰り返します。
この項で説明する別の形態では、より少ないサーバー、異なるソフトウェア、または他の構成を使用してデプロイメントの目標を達成することができます。
マルチマスター・レプリケーションは、システム内で少なくとも1台のディレクトリ・サーバーが利用可能な場合に、Oracle Internet Directoryへの読取りおよび書込みアクセスを保証する、Oracle Internet Directoryのソフトウェア・ソリューションです。Oracleディレクトリ・サーバーが障害から復旧すると、正常に稼動しているディレクトリ・サーバーから自動的にレプリケーションが再開され、ディレクトリ・レプリケーション・グループ内のディレクトリ・サーバー間で同期が行われます。また、一方のディレクトリ・サーバー・インスタンスに行われた変更は、他方のディレクトリ・サーバー・インスタンスにも反映されます。
Oracle Internet Directoryでマルチマスター・レプリケーションを実装するには、『Oracle Internet Directory管理者ガイド』の「Oracle Internet Directoryレプリケーションの管理」、「マルチマスター・レプリケーションのインストールと構成」に記載されている手順に従ってください。
OracleAS Cold Failover Cluster（Identity Management）ソリューションは、2台のコンピュータで構成されるハードウェア・クラスタです。常時Infrastructureインストールをアクティブに実行しているコンピュータを1次（ホット）ノードと呼びます。このノードに障害が発生した場合は、ハードウェア・クラスタ内で、Infrastructureの運用が自動的に2次（コールド）ノードに引き継がれます。
ハードウェア・クラスタ・ノードはそれぞれスタンドアロン・サーバーであり、個別にプロセスを実行しますが、共有記憶域サブシステムにアクセスします。クラスタ内のノードはどちらも、同じ記憶域（通常は、ディスク）にアクセスできますが、常に記憶域に対するアクティブなアクセス権が付与されているのは1次ノードのみです。1次ノードに障害が発生した場合は、そのハードウェア・クラスタのソフトウェアが、記憶域へのアクセス権を2次ノードに付与します。
|
注意: OracleAS Cold Failover Cluster（Identity Management）ソリューションの詳細は、『Oracle Application Server高可用性ガイド』を参照してください。 |
OracleAS Cold Failover Cluster（Identity Management）ソリューションは、次の点で標準の構成とは異なります。
Oracle Internet Directoryサーバーとデータベースは同じコンピュータに配置されますが、標準の構成では、最初のOracle Internet Directoryインスタンスとデータベース・インスタンスがOIDHOST1とINFRADBHOST1に配置され、2番目のOracle Internet Directoryインスタンスとデータベース・インスタンスがOIDHOST2とINFRADBHOST2に配置されます。したがって、OracleAS Cold Failover Cluster（Identity Management）ソリューションの方がRAC構成よりもサーバーが2台少なくて済みます。
ノードに障害が発生した場合は、ワークロードがコールド・ノードに引き継がれる間、クライアントに対するサービスが一時中断します。
OracleAS Cold Failover Cluster（Identity Management）ソリューションを導入する手順は次のとおりです。
ハードウェア・クラスタを配置し、構成します。
OracleAS Cold Failover Cluster（Identity Management）ソリューションを使用するクラスタ・コンピュータにOracle Application Serverインスタンスをインストールし、構成します。詳細は、Oracle Application Serverのインストレーション・ガイドの「OracleAS Cold Failover Cluster（Identity Management）構成のインストール」を参照してください。
OracleAS Cold Failover Cluster（Identity Management）ソリューションを管理します。詳細は、『Oracle Application Server高可用性ガイド』のOracle Application Server Cold Failover Cluster（Identity Management）の管理に関する項を参照してください。
プロキシによって、Oracle HTTP Serverがクライアント・リクエストを処理する方法が変わります。
フォワード・プロキシは、クライアントと、コンテンツを含むオリジナル・サーバーを中継するサーバーです。フォワード・プロキシは、通常、ファイアウォールで規制される内部クライアントに対してインターネット・アクセスを提供します。オリジナル・サーバーからコンテンツを取得するには、クライアントはプロキシにリクエストを送信し、オリジナル・サーバーをターゲットとして指名します。プロキシはオリジナル・サーバーのコンテンツをリクエストして、それをクライアントに返送します。クライアントは、フォワード・プロキシを使用して他のサイトにアクセスするように構成されている必要があります。
リバース・プロキシは、クライアントの外側に位置し、コンテンツ・サーバーとなるサーバーです。リバース・プロキシは、ファイアウォール外部からのリクエストをファイアウォール内のサーバーに中継し、取得したコンテンツをクライアントに返します。ファイアウォールのルールによってプロキシ・サーバーへのアクセスのみが許可されるため、コンテンツ・サーバーは保護されます。プロキシ・サーバーは、ファイアウォール内のサーバーに関する情報が外部クライアントに渡らないよう、コンテンツ・サーバーによって生成されるすべてのメッセージのヘッダーにリストされるURLを変更します。リバース・プロキシについて、クライアントでの設定は必要ありません（クライアントは、リバース・プロキシのネームスペースのコンテンツに対してリクエストを行うため）。リバース・プロキシはリクエストの送信先を判定し、そのコンテンツをオリジナル・サーバーのものであるかのように返します。
