| Oracle® Fusion Middleware Oracle Portal管理者ガイド 11gリリース1（11.1.1） B61385-01 |
|
 戻る |
 次へ |
この章では、Oracle Portalの計画、インストール、構成および管理に含まれるタスク・フローの詳細について説明します。この章を読むと、ポータルを効果的に構築するのに必要なハードウェアおよびソフトウェアをどのように計画すればよいかを理解することができます。
この章の内容:
ポータルの構成を計画するには、システムで実現する目標を明確にすることが重要です。次の各項では、これらの重要な決定事項としてそれぞれ何が含まれるのかを確認します。
Oracle Fusion Middlewareには、様々なトポロジ・オプションが用意されています。Oracle Fusion Middlewareの推奨トポロジには、小規模で一般的な開発の実装から、大規模な企業全体の実装までが含まれています。
|
関連項目
|
Webポータルをサポートするサーバー、データベースおよびリソースは、特にピーク間隔では様々なユーザー通信量を処理する必要があります。
Webポータルと同様に、ポータルを配置するのに必要なサーバーおよびデータベースの容量は、主に、予想されるユーザー・リクエストの数によって決まります。1つのページをユーザーに表示するには、ユーザーがページの表示を許可されているかどうかの検証、ページに表示されるイメージのロード、ページの書式情報が含まれているスタイル・シートのコールなど、様々な処理が別個に必要になる場合があります。
必要な容量の上限および下限は、ユーザーがどのようにポータルを使用するかによって決まります。ポータルの主要機能が統合の場合は、一般的に負荷の大半が中間層にかかります。一方、大幅にカスタマイズしたコンテンツ・ドリブンのポータルの場合は、リポジトリやインフラストラクチャに負荷がシフトします。少なくとも、ユーザーが受け入れることができるレスポンス時間と、業務時間中の平均負荷を満たすだけのサーバー容量が必要です。可能であれば、ユーザー業務のピーク間隔中に予想されるページ・リクエストの量を満たすようにします。CPU、メモリー、I/O容量、ネットワーク帯域幅などのハードウェア・リソースは、レスポンス時間を短縮するための重要な要素です。Oracle Portalは、多数のトランザクションを処理できるサーバー、またはサーバー・グループにインストールする必要があります。このようにしない場合は、レスポンス時間が長くなることがあります。
サーバーおよびデータベースの容量を追加すると、Webポータルのパフォーマンスは確実に向上しますが、資金を自由に投入できる場合を除き、十分なパフォーマンスと新しいハードウェアおよびソフトウェアを使用できるようにするためのコストとのバランスを保つ必要があります。
|
関連項目 『Oracle Fusion Middleware Administrator's Guide』 |
レスポンス時間は、ユーザー・リクエストが発行されてから、そのリクエストに対するレスポンスが完了するまでの経過時間です。Webポータルは、最小のソフトウェアおよびハードウェア・オーバーヘッドを使用して、できるだけ早く応答する必要があります。パフォーマンスについては、次の点について考慮する必要があります。
負荷を分散させる
Webポータル上に大量の通信量が予想される場合は、独自の中間層インスタンスを持つ複数のサーバーに負荷を分散することができます。過剰な通信量によって1つのサーバーがオーバーロードした場合は、別のサーバーがオーバーフローを処理できます。詳細は、第2.1.8.1項「ロード・バランス」を参照してください。
障害が発生しないようにする
Oracle Portal構成を分散すると、Webポータルでより多くのソフトウェア・リソースおよびハードウェア・リソースを利用できるため、単一サーバー構成よりも可用性が向上します。追加のサーバーおよびソフトウェアを使用して、フェイルオーバーを用意することにより、システムの安定性を確保することができます。詳細は、第2.1.8.2項「フェイルオーバーと冗長性」を参照してください。
キャッシュ・クラスタを実装する
中規模から大規模の配置の可用性およびスケーラビリティを向上させるには、キャッシュ・クラスタを構成することができます。キャッシュ・クラスタは、障害検出とフェイルオーバーを提供することにより、Webサイトの可用性を高めます。詳細は、第1.3項「Oracle Portalのキャッシュについて」を参照してください。
|
関連項目 『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』 |
ページ、ポートレット・インスタンスおよびテンプレートに合せて最適なキャッシュ・オプションを選択する
キャッシュは、Oracle Portalのパフォーマンスを最大化するための主要な方法です。分散アーキテクチャを使用するとシステムの可用性と速度は向上しますが、キャッシュ法のほうがはるかに重要です。パフォーマンスとスケーラビリティを高めるために、Oracle Portalではいくつかのキャッシュ・オプションが用意されています。詳細は、『Oracle Fusion Middleware Oracle Portalユーザーズ・ガイド』にあるページのパフォーマンスの向上に関する章を参照してください。
冗長性により、同じ構成の複製コンピュータを用意することでシステムを拡張し、リクエストを十分に処理できる容量を用意し、障害およびエラーが発生した場合はバックアップを使用できます。
さらに、ページ、ポートレット・インスタンスおよびテンプレートに合せた最適なキャッシュ・オプションを選択することでスケーラビリティが向上します。Oracle Portalには、そのためのキャッシュ・オプションがいくつか用意されています。詳細は、『Oracle Fusion Middleware Oracle Portalユーザーズ・ガイド』にあるページのパフォーマンスの向上に関する章を参照してください。
詳細は、第2.1.8.3項「スケーラビリティ」および第1.3項「Oracle Portalのキャッシュについて」を参照してください。
クラスタリングを行うと、単一のOracle Fusion Middlewareインスタンスを使用した場合よりもシステムの可用性を高めることができます。1つのOracle Fusion Middleware上の単一のインスタンスで稼働しているアプリケーションは、そのサーバーが稼働しているオペレーティング・システムとホストに依存しています。このような場合には、ホストが停止するとアプリケーションも使用できなくなるため、ホストはシングル・ポイント障害を引き起こします。
|
関連項目 『Oracle Fusion Middleware高可用性ガイド』 |
重要なデータは、すべてのユーザーが使用するコンテンツに影響を与えずに、セキュリティで保護する必要があります。
Oracle Portalでは、このような柔軟な方法でWebコンテンツへのアクセスを管理できるように、Oracle Fusion Middlewareの他のコンポーネントとOracle Database 11gを活用して、ポータルを強力に保護します。Oracle Portalでは、そのセキュリティ・モデルを実装するために、次のすべてのコンポーネントと対話します。
Oracle Application Server Single Sign-On
mod_osso（J2EE Webアプリケーションのシングル・サインオンを容易にするOracle HTTP Serverのリスナー・モジュール）
Oracle Web Cache
Oracle Internet Directory
Oracle Delegated Administration Services
Oracle Directory Integration Platform
詳細は、第7章「Oracle Portalの保護」を参照してください。
この項では、Oracle PortalおよびOracle Fusion Middlewareの関連するすべてのコンポーネントを最適に使用するために、ハードウェアとソフトウェアのインストールをどのように構成するかについて説明します。ここでは、多数のユーザーにサービスを行う大規模なサイトの配置だけでなく、小規模な開発環境を設定するために、ハードウェアをどのように構成するかを説明します。
最も単純な構成では、Oracle Fusion Middlewareのすべてのコンポーネントを、図2-1に示すように1台のコンピュータにインストールします。実際には、1つのデータベースをコンピュータに常駐させ、Oracle Portal、Oracle Internet DirectoryおよびOracleAS Single Sign-Onに個別のスキーマを格納することも可能です。
この構成は、開発者がOracle Portalの宣言インタフェースを使用してページ、ポートレットおよびアプリケーションを構築する、小さな開発環境に適しています。また、完成したWebポータルの小規模な配置を簡単にサポートできます。より多くのコンテンツをより多くのユーザーに配信する大規模なサイトを配置する場合は、図2-1に示すような単一のサーバーまたは単純な構成では不十分です。
単一のコンピュータ構成がニーズに合ない場合は、Oracle Portalアーキテクチャの様々な要素を他のコンピュータに移動することを考慮する必要があります。Webポータルを構成する場合、使用するサイトのサイズに応じて複数のサーバーが必要になり、各サーバーがより特化した処理を実行します。ハードウェアを追加するとパフォーマンスが向上し、ソフトウェア・インスタンスを追加すると、冗長性が確保されます。
大規模なWebポータル・サイトを構成する場合の配置オプションには、次の作業が必要です。
配置したWebポータルの要件が実現されるまで、これらの作業を実行します。たとえば、サイトで通常の作業負荷のみを処理する場合は、最初に中間層をデータベースから切り離してから、Oracle Identity Managementを別のサーバーに移動することを考えます。前述の構成作業をすべて実行する必要はありません。ただし、サイトが拡大するにつれ、前述した順序で基になる構成を拡張する必要があります。
|
注意: Webポータルをオンラインにする前に、小規模なテスト・システムで設定およびテストを行うことをお薦めします。これにより、最終的に使用するユーザーに影響を与えずに、実際の使用パターンに基づいて、役に立つ構成情報および調整情報を集めることができます。 |
大規模なシステムを構成する際に最初に考慮すべきことは、図2-2に示すように、中間層を別にインストールすることです。
|
関連項目 『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』 |
図2-2 インフラストラクチャ層からのOracle Fusion Middleware中間層の切離し
これにより、Oracle Metadata Repositoryと中間層は、I/O、メモリー、ディスク容量などのハードウェア・リソースの競合から解放されます。また、これらのコンポーネントを別個のコンピュータにインストールすると、パフォーマンスをより柔軟に調整できます。これは、Oracle Metadata Repositoryに多数のコンテンツを格納するようなサイトでは重要です。オペレーティング・システムなどに関する調整パラメータは、HTTP Serverなどの中間層コンポーネントの調整パラメータとは別個になります。一方のパフォーマンス・パラメータを設定しても、もう一方のパフォーマンスが調整されない場合があります。
OracleAS Single Sign-Onは、Oracle Portalおよび他のアプリケーションのOracle Internet Directoryを使用してユーザー証明書を認証します。したがって、ユーザーは、1つのユーザー名とパスワードを使用してWebポータルに1回ログインするだけで、複数のアカウントとアプリケーションにアクセスできるようになります。
配置されたOracle Portalサイトにログインすると、そのユーザーは、その他のOracleAS Single Sign-Onのセキュアなすべてのアプリケーションにアクセスできます。
図2-3に示すように、Oracle Identity Managementは、Oracle Metadata Repositoryとは別のコンピュータに配置されています。1つのOracle Identity Managementインスタンスを、複数のOracle製品（Oracle Portalの中間層の複数のインスタンスなど）で使用するように構成できます。
図2-3 個別のコンピュータにインストールされたOracle Identity Management
図2-3に示すシステムは、分散構成の例です。構成には、複数の中間層インスタンスをサポートすることが可能な、集中型のOracle Identity Managementサーバーが含まれます。Oracle Identity Managementを独自のサーバーに移動すると、そのパフォーマンスをデータベースと中間層から切り離して調整できます。
さらに、Oracle Identity Managementを中間層インストールから切り離すことにより、分散システム全体の安定性が高まります。中間層がインストールされているコンピュータに障害が発生しても、OracleAS Single Sign-On、およびログインの検証をSingle Sign-Onに依存するその他の中間層インスタンスは、影響を受けません。また、複数のセキュリティ・ポリシーを使用して、構成内の様々なコンピュータを管理できます。
|
関連項目 『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』 |
大規模なWebポータルを使用する場合は、冗長中間層インスタンス（同じ構成設定を持つインスタンス）を追加します。追加された中間層インスタンスは、図2-4のようになります。各中間層インスタンスを独自のコンピュータにインストールすると、ハードウェア障害を切り離すことができます。
中間層はポータル・ページに対するユーザー・リクエストをプロバイダに転送し、返されたコンテンツを使用してページを作成します。中間層インスタンスをOracle Portal構成に追加すると、より多くのユーザー・リクエストを処理できるようになり、ポータル全体のパフォーマンスが向上します。データベースとネットワーク・リソースがより効率的に使用されます。
Oracle Web Cacheサーバーを中間層から切り離して、データのキャッシュ率の向上、リクエスト時間の短縮、中間層における負荷の軽減を実現することもできます。
Oracle Web CacheはCPUよりもメモリーを消費するため、切り離すと、システムの調整が容易になりパフォーマンスが向上します。また、コンポーネントを切り離すと、キャッシュされたデータとエンド・ユーザーの距離が縮まり、特定のユーザー・コミュニティのネットワーク・エッジでキャッシュされるコンテンツを制限することで効果的にセキュリティが向上します。たとえば、一般的な内部または外部のシナリオでは、特定のキャッシュされたコンテンツを有するコミュニティを対象にOracle Web Cacheの切離しを行うことができます。
Oracle Fusion Middleware 11gでは、Cold Failover Cluster、Data Guard、Real Application Clusters（RAC）など、すべてのOracle高可用性（HA）ソリューションをOracleAS Infrastructureで使用できます。
|
関連項目 『Oracle Fusion Middleware高可用性ガイド』 |
Oracle Portal構成を分散すると、Webポータルでより多くのソフトウェア・リソースおよびハードウェア・リソースを利用できるため、単一のコンピュータ構成よりもパフォーマンスが向上します。ただし、この他にも利点があります。追加のサーバーおよびソフトウェアを使用して、フェイルオーバーを用意することにより、システムの安定性を確保することができます。また、複数のサーバー間でロード・バランスを使用すれば、1日の間に発生するWebポータルの作業量の変動に対応することができます。さらに、より多くのユーザーをサポートするために、サーバーを分散構成に追加すれば、スケーラビリティを高めることができます。
Webポータル上に大量の通信量が予想される場合は、独自の中間層インスタンスを持つ複数のサーバーに負荷を分散することができます。過剰な通信量によって1つのサーバーがオーバーロードした場合は、別のサーバーがオーバーフローを処理できます。
Oracle Fusion Middlewareは、着信リクエストを処理するサーバー・インスタンスのプーリングを利用して、独自のロード・バランス機能を提供します。1つのインスタンスが応答しない場合、リクエストは別のインスタンスに転送されます。これにより、配置されたサイトのユーザーは、コンテンツとアプリケーションを常に利用できるようになります。
非常に大規模なサイトの場合は、ロード・バランスのハードウェアまたはソフトウェアを追加して、着信リクエストを中間層サーバーに分散できます。図2-5は、この目的で使用するロード・バランス・ルーター（LBR）を示しています。LBRは、ネットワーク・リクエストを多数のサーバーに配布する高速ネットワーク・デバイスです。これは最も一般的なロード・バランスの方法です。ロード・バランス・ルーターは、各リクエストを特定の中間層サーバーに送信するかわりに、ポータル・ユーザーに公開アドレスを1つだけ提供します。
LBRを追加して、着信リクエストを中間層サーバーへ分散させる方法の詳細は、第6.3項「ロード・バランス・ルーターを使用する複数の中間層の構成」を参照してください。
たとえば、通信量の多い個人用サイトMy.Oracle.com（MOC）で、LBRを使用してリクエストを振り分けるとします。負荷を分散するソフトウェア・ロジックは、個々の中間層サーバーに個別にインストールされるのではなく、LBR自体に含まれています。このため、LBRを使用すると、お使いの構成の管理コストが低下します。MOCはイントラネットおよびエクストラネットのWebサイトです。MOCは、オラクル社のオンライン・サービスおよび外部プロバイダのビジネス情報に対するカスタマイズ可能な単一エントリ・ポイントを、オラクル社の従業員に提供します。
LBRを追加すれば、負荷の変動にも対応できます。ユーザーはサイトにアクセスし、アプリケーションを使用して、特定のピーク間隔（ほとんどのユーザーがログインして業務を開始する9 a.m.〜10 a.m.など）に非常に高い頻度でコンテンツをリクエストすることがあります。このような大量の通信量が発生する時間に、LBRは、ページ・リクエストを様々な中間層インスタンスに分散して、迅速なレスポンスを確保することができます。
ピーク負荷が定期的に発生する場合は、ピーク負荷要件に対応するための構成を検討します。ピーク負荷の頻度が低い場合は、ハードウェアの投資を追加しないで、ピーク間隔にレスポンス時間の遅延が発生する状態で使用することもできます。
LBR自体を構成してフェイルオーバーをサポートすることもできます。図2-6に示すMy.Oracle.comの構成では、主ルーターに障害が発生した場合に利用できる、2番目のLBRを追加できます。
フェイルオーバーは、サーバーやデータベースなど、システムの一部に障害が発生したときにバックアップに切り替える能力です。たとえば、Oracle Database 11gに障害が発生した場合は、バックアップに保存された状態情報を使用して、データベースが再起動されます。
冗長性は、同じ構成の複製コンピュータを用意する手法です。冗長コンピュータは、リクエストを十分に処理できる容量を用意し、障害およびエラーが発生した場合はバックアップを使用します。冗長性は、構成内のコンピュータの数を増やすことにより実装されます。1台のサーバーがアクティブになっているときは、他のサーバーがそのサーバーの動作を監視して、障害が発生した場合に引き継ぎます。
図2-6に示すように、My Oracle.comは、他のサーバーで障害の原因となる問題が発生した場合に、引き継ぐことができる追加の中間層サーバーを使用して、フェイルオーバーを提供します。
冗長中間層インスタンスを設定するには、同じサイト名およびサーバー・ポート・エントリ（サイト名がmy.oracle.com、ポートが5000など）で、元のインスタンスと各冗長インスタンスを構成します。つまり、物理的なサイト名とポートが同じである必要はありませんが、冗長層の仮想ホスト参照は同じでなくてはなりません。
冗長性のかわりに、構成全体の余剰容量を使用してフェイルオーバーを提供することもできます。たとえば、75%の容量で稼働中の4台の中間層サーバーがあるとします。1台のサーバーで障害が発生した場合、他の3台が4分の1の作業負荷を引き継ぐことができます（25%×3 = 75%、障害が発生したサーバーの容量に相当）。
スケーラビリティは、ユーザーの数とコンテンツの量が増えたときに、Webポータルがより多くのリクエストを処理する能力です。ポータルがより多くの通信量を処理するときに、パフォーマンスの変化をユーザーに意識させないようにする必要があります。パフォーマンスの変化は、レスポンス間隔とエラーの頻度によって判断されます。スケーラビリティを目標とする場合は、他の構成に悪影響を与えることなく、必要に応じてデータベース容量とサーバーを追加できる柔軟な構成が必要です。
この項では、Oracle Portalの計画、インストール、構成および管理に含まれるタスク・フローの詳細について説明します。
Oracle Portalを適切に配置するためには、次の手順が必要です。
Oracle Portalのアップグレード（必要な場合）
インストール後の構成の実行（基本的な構成および管理）
次の各項では、各手順の概要を説明し、様々な参照先（この構成ガイド、Oracle Fusion Middleware 11gドキュメント・ライブラリのその他のマニュアル、テクニカル・ホワイト・ペーパーおよびOTN（http://www.oracle.com/technology/）など）の詳細情報について説明します。
Oracle Portalを初めて使用する場合は、第1章「Oracle Portalのアーキテクチャについて」を読むと、Oracle PortalがOracle Fusion Middlewareのアーキテクチャにどのように適合するかを理解することができます。
Oracle Portal構成の計画の詳細は、Portal Center（http://www.oracle.com/technology/products/ias/portal/index.html）を参照してください。
Oracle Portalの以前のリリースからのアップグレードに関する最新情報は、OTN（http://www.oracle.com/technology/products/ias/portal/upgrade.html）を参照してください。アップグレードのページで、次を参照できます。
アップグレード・スクリプトのダウンロード手順
アップグレードに関するオンライン・マニュアル
インストールをスムーズに行うためには、すべての前提条件を満たしており、インストール前の手順がすべて実行されていることを確認する必要があります。『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』には、Oracle Fusion Middlewareの一般的な要件が記載されていますが、第3章「インストール前およびインストール後の作業」には、ポータル特有の手順が説明されています。
『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』では、Oracle Portalを実行するのに必要なOracle Fusion Middleware中間層およびInfrastructureをインストールする手順を説明しています。詳細は、第3章「インストール前およびインストール後の作業」を参照してください。
第5章「基本的な構成および管理」では、Oracle Portalの管理者が実行できる、構成後のすべての作業について説明しています。
詳細は、Portal Center（http://www.oracle.com/technology/products/ias/portal/index.html）を参照してください。
第III部「拡張構成」は、Oracle Fusion Middlewareの管理者を対象としています。第6章「拡張構成」では、仮想ホスト、ロード・バランス・ルーター、プロキシ・サーバー、Oracle Web CacheおよびOracleAS Single Sign-Onの構成など、Oracle Portalの拡張構成と統合構成を実行する方法を説明しています。第III部の他の章では、検索、インポートとエクスポートなどの機能の詳細について説明しています。
第7章「Oracle Portalの保護」では、Oracle Portalでセキュリティ機能を構成するための詳細情報を説明しています。
Oracle Portalは、Oracle Enterprise Manager 11g Fusion Middleware Controlから監視できます。詳細は、第8章「Oracle Portalの監視と管理」を参照してください。
また、ポータルのパフォーマンスを監視する目的で、パフォーマンス・レポートを生成できます。第10.5項「パフォーマンス・レポートの生成」を参照してください。このパフォーマンスに関する情報は、この後のOracle Portalのパフォーマンスのチューニングで役立ちます。第10章「Oracle Portalのパフォーマンスの調整」を参照してください。
付録G「Oracle Portalのトラブルシューティング」では、様々な問題を解決および診断する方法について説明しています。
