Comments
Transcript
Oracle Application Server 10gエンタープライズ・デプロイメントのための
Oracle® Application Server 10g エンタープライズ・デプロイメントのための アドバンスト・トポロジ 10g（9.0.4） 部品番号 : B12319-01 2004 年 6 月 Oracle Application Server 10g エンタープライズ・デプロイメントのためのアドバンスト・トポロジ , 10g（9.0.4） 部品番号 : B12319-01 原本名 : Oracle Application Server 10g Advanced Topologies for Enterprise Deployments, 10g (9.0.4) 原本部品番号 : B12115-01 原本著者 : Orlando Cordero Copyright © 2003 Oracle Corporation. All rights reserved. 制限付権利の説明 このプログラム（ソフトウェアおよびドキュメントを含む）には、オラクル社およびその関連会社に所 有権のある情報が含まれています。このプログラムの使用または開示は、オラクル社およびその関連会 社との契約に記された制約条件に従うものとします。著作権、特許権およびその他の知的財産権と工業 所有権に関する法律により保護されています。 独立して作成された他のソフトウェアとの互換性を得るために必要な場合、もしくは法律によって規定 される場合を除き、このプログラムのリバース・エンジニアリング、逆アセンブル、逆コンパイル等は 禁止されています。 このドキュメントの情報は、予告なしに変更される場合があります。オラクル社およびその関連会社は、 このドキュメントに誤りが無いことの保証は致し兼ねます。これらのプログラムのライセンス契約で許 諾されている場合を除き、プログラムを形式、手段（電子的または機械的）、目的に関係なく、複製また は転用することはできません。 このプログラムが米国政府機関、もしくは米国政府機関に代わってこのプログラムをライセンスまたは 使用する者に提供される場合は、次の注意が適用されます。 U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation, and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the Programs, including documentation and technical data, shall be subject to the licensing restrictions set forth in the applicable Oracle license agreement, and, to the extent applicable, the additional rights set forth in FAR 52.227-19, Commercial Computer Software--Restricted Rights (June 1987). Oracle Corporation, 500 Oracle Parkway, Redwood City, CA 94065. このプログラムは、核、航空産業、大量輸送、医療あるいはその他の危険が伴うアプリケーションへの 用途を目的としておりません。このプログラムをかかる目的で使用する際、上述のアプリケーションを 安全に使用するために、適切な安全装置、バックアップ、冗長性（redundancy）、その他の対策を講じ ることは使用者の責任となります。万一かかるプログラムの使用に起因して損害が発生いたしましても、 オラクル社およびその関連会社は一切責任を負いかねます。 Oracle は Oracle Corporation およびその関連会社の登録商標です。その他の名称は、Oracle Corporation または各社が所有する商標または登録商標です。 目次 はじめに ............................................................................................................................................................................ v 対象読者 ..................................................................................................................................................................... vi このマニュアルの構成 ............................................................................................................................................. vi 関連ドキュメント .................................................................................................................................................... vii 表記規則 .................................................................................................................................................................... vii 1 エンタープライズ・トポロジの概要 1.5 1.5.1 エンタープライズ・トポロジについて、およびそれが推奨される理由 ....................................... 推奨トポロジ ........................................................................................................................................... エンタープライズ・データ・センター・トポロジ : J2EE アプリケーション .............................. エンタープライズ・データ・センター・トポロジ : Portal、Wireless および Business Intelligence アプリケーション ............................................................................................. 部門別トポロジ ..................................................................................................................................... インストールの順序 ..................................................................................................................... 1.6 1.6.1 開発ライフ・サイクル・トポロジ ..................................................................................................... 1-13 テスト環境からステージング環境へのアプリケーションの移行 ......................................... 1-13 1.6.2 ステージング環境から本番環境へのアプリケーションの移行 ............................................. 1-13 1.1 1.2 1.3 1.4 1-2 1-3 1-3 1-8 1-10 1-12 2 エンタープライズ・トポロジのインストールと構成における考慮事項 2.1 2.1.1 J2EE アプリケーション・トポロジ ..................................................................................................... 2-2 ハードウェア要件 ........................................................................................................................... 2-3 2.1.2 インストールの順序 ....................................................................................................................... 2-4 2.2 2.3 エンタープライズ・トポロジ : Portal、BI、Wireless、Forms Services および Reports Services のインストールと構成 ............................................................................................. 2-5 部門別トポロジ : 部門アプリケーションをホスティングする部門 ................................................ 2-7 i 2.4 2.5 2.5.1 2.5.1.1 2.5.1.2 2.5.2 3 エンタープライズ・トポロジ : 開発ライフ・サイクル・トポロジのインストールと構成 ........ 2-8 エンタープライズ・トポロジのインストール後のタスク ............................................................... 2-9 Infrastructure .................................................................................................................................. 2-9 OracleAS Portal と Oracle Internet Directory .................................................................... 2-9 OracleAS Portal と OracleAS Web Cache ........................................................................... 2-9 OracleAS Portal と Oracle Application Server Wireless ........................................................ 2-10 2.6 2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.6.6 2.6.7 2.6.8 J2EE アプリケーション・トポロジのインストール後のタスク ................................................... Oracle Application Server Web Cache ...................................................................................... Oracle HTTP Server ..................................................................................................................... Oracle Application Server Forms Services ............................................................................... Oracle Application Server Reports Services ............................................................................. Oracle Application Server Discoverer ....................................................................................... Oracle Application Server Single Sign-On ............................................................................... OracleAS Portal ............................................................................................................................ Oracle Enterprise Manager ......................................................................................................... 2.7 次に参照するドキュメント ................................................................................................................. 2-14 2-11 2-11 2-13 2-13 2-13 2-13 2-13 2-13 2-14 エンタープライズ・デプロイメント・トポロジでの Single Sign-On の構成 3.1 3.2 3.3 3.3.1 3.3.2 高可用性について ................................................................................................................................... セキュリティについて ........................................................................................................................... 複数のシングル・サインオン中間層における 1 つの Oracle Internet Directory の使用 ............ 使用例 ............................................................................................................................................... 3-2 3-2 3-2 3-3 構成手順 ........................................................................................................................................... 3-5 4 ネットワーク 4.1 4.1.1 Oracle Application Server ネットワークの概要 ................................................................................ 4-2 Distributed Configuration Management（DCM）.................................................................... 4-2 4.1.2 Oracle Process Manager and Notification（OPMN）............................................................... 4-3 4.1.3 4.1.4 LDAP と Oracle Internet Directory ............................................................................................. 4-4 Enterprise Manager Server Control ............................................................................................. 4-4 4.2 4.2.1 ファイアウォールの考慮事項 : 適切なポートのオープン ................................................................ 4-5 異なる層にありファイアウォールで分断された mod_oc4j と OC4J ..................................... 4-6 4.2.2 mod_oc4j 用の適切なポートのオープン ..................................................................................... 4-6 4.2.3 4.3 4.4 ii iASPT の構成 ................................................................................................................................... 4-6 ロード・バランシングの考慮事項 ....................................................................................................... 4-7 ロード・バランシング・ルーターを使用する複数の中間層の構成 ............................................... 4-7 4.5 5 エンタープライズ・デプロイメント・トポロジの管理 5.1 5.1.1 管理における全般的な考慮事項 ........................................................................................................... 5-2 ログ・ファイルの循環 ................................................................................................................... 5-2 5.1.2 OC4J の定期的な再起動 ................................................................................................................ 5-3 5.1.3 サーバーおよびアプリケーションの起動と停止 ....................................................................... 5-3 5.1.4 アップグレード、パッチおよび構成変更のロールアウト ....................................................... 5-3 5.1.5 バックアップとリカバリ ............................................................................................................... 5-3 5.1.6 NFS の利用 ...................................................................................................................................... 5-4 5.1.7 ポート管理 ....................................................................................................................................... 5-4 5.1.8 静的 IP アドレスと動的 IP アドレスの使用 ............................................................................... 5-4 5.1.9 異なる Infrastructure の分離と結合 ............................................................................................ 5-5 5.1.10 ログ・ファイルのマイニング ....................................................................................................... 5-5 5.2.1 エンタープライズ・データ・センター・トポロジ : 同一データ・センターを共有する 複数の部門 ............................................................................................................................................... 5-5 管理上の考慮事項のチェックリスト ........................................................................................... 5-5 5.2.2 Oracle Enterprise Manager Application Server Control のチェックリスト ......................... 5-6 5.2.3 バックアップとリカバリに関する考慮事項 ............................................................................... 5-6 5.2.4 アプリケーションのデプロイとパフォーマンスに関する考慮事項 ....................................... 5-6 5.3 5.3.1 部門別トポロジ : 部門アプリケーションをホスティングする部門 ................................................ 5-7 管理上の考慮事項 ........................................................................................................................... 5-7 5.3.2 バックアップとリカバリに関する考慮事項 ............................................................................... 5-8 5.3.3 アプリケーションのデプロイとパフォーマンスに関する考慮事項 ....................................... 5-8 5.2 5.4 6 リバース・プロキシ・サーバーの構成 ............................................................................................. 4-10 開発ライフ・サイクル・トポロジ ...................................................................................................... 5-8 パフォーマンスとチューニングに関する考慮事項 6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 オリジナル・サーバー（OS）のネットワーク・パラメータ ......................................................... Oracle HTTP Server（OHS）................................................................................................................. SSL ............................................................................................................................................................ Oracle Internet Directory（OID）......................................................................................................... JVM パラメータ ...................................................................................................................................... JSP ............................................................................................................................................................. Web Cache ............................................................................................................................................... ロギング・レベル ................................................................................................................................... 6-2 6-2 6-2 6-2 6-2 6-3 6-3 6-3 iii 6.9 6.10 索引 iv データベース接続 ................................................................................................................................... 6-3 Portal ........................................................................................................................................................ 6-3 はじめに 『Oracle Application Server 10g エンタープライズ・デプロイメントのためのアドバンスト・ トポロジ』では、インストール要件、インストーラの新機能、インストールに影響する Oracle Application Server の概要、他の製品との互換性、およびエンタープライズ・トポロ ジにおける管理情報について説明します。 v 対象読者 このガイドは、基本的なシステム管理作業に精通したユーザーを対象にしています。この作 業には、ユーザーとグループの作成、ユーザーのグループへの追加、Oracle Application Server のインストール先であるコンピュータへのオペレーティング・システムのパッチの適 用などがあります。インストール時には、シェル・スクリプトをルートとして実行する必要 があります。 このマニュアルの構成 このマニュアルには、次の章と付録が含まれています。 第 1 章「エンタープライズ・トポロジの概要」 この章には、いくつかの Oracle Application Server エンタープライズ・デプロイメント・ト ポロジに関する概要があります。 第 2 章「エンタープライズ・トポロジのインストールと構成における考慮事項」 この章では、インストール前の要件、また各トポロジにおけるインストール中、インストー ル後および構成の情報について説明します。 第 3 章「エンタープライズ・デプロイメント・トポロジでの Single Sign-On の構成」 この章では、様々な中間層の構成やトポロジにおける Oracle Application Server Single Sign-On の構成方法について説明します。 第 4 章「ネットワーク」 この章では、ポート番号の割当て、ロード・バランサ、ファイアウォールなどのネットワー ク考慮事項について説明します。 第 5 章「エンタープライズ・デプロイメント・トポロジの管理」 この章では、エンタープライズ・デプロイメント・トポロジを管理するためのツールと手法 について説明します。 第 6 章「パフォーマンスとチューニングに関する考慮事項」 この章では、パフォーマンスとチューニングに関する最も一般的な問題を示し、追加情報の 参照先についても説明します。 vi 関連ドキュメント 詳細は、次の Oracle ドキュメントを参照してください。 ■ 『Oracle Application Server 10g 管理者ガイド』 ■ 『Oracle Application Server 10g 概要』 表記規則 本文では、次の表記規則を使用します。 規則 意味 固定幅フォント 固定幅フォントの文字は、ファイル名、コマンドまたは構成ファイ ルの内容を示します。 固定幅フォントの イタリック 固定幅フォントのイタリックは、特定の値を指定する必要があるプ レースホルダを示します。 [] 大カッコは、複数の選択項目を囲みます。項目のうちの 1 つを入力 するか、入力しないでください。 ... 水平の省略記号は、直接関係しない情報が省略されていることを示 します。 vii viii 1 エンタープライズ・トポロジの概要 この章には、次の項があります。 ■ エンタープライズ・トポロジについて、およびそれが推奨される理由 ■ 推奨トポロジ ■ エンタープライズ・データ・センター・トポロジ : J2EE アプリケーション ■ 部門別トポロジ ■ 開発ライフ・サイクル・トポロジ エンタープライズ・トポロジの概要 1-1 エンタープライズ・トポロジについて、およびそれが推奨される理由 1.1 エンタープライズ・トポロジについて、およびそれが推奨 される理由 エンタープライズ・トポロジとは、データ・センターなどの大規模な環境で一般的に使用さ れる、Oracle Application Server の高度なインストールおよび構成方法を意味します。 エンタープライズ・デプロイメント・トポロジでは、アプリケーション・サーバーの配置に 対して、次の 4 つの主要な目標があります。 ■ 特定のトポロジ内のソフトウェアおよびハードウェア構成におけるサービスの質の確 保。 ■ ■ ■ エンタープライズ・システムが効率的に管理され、作業負荷が分散されます。 デプロイメント・トポロジで、ハードウェア、ネットワーク・ツールなどのリソー スを追加または削除するときに、アプリケーションが効率的に実行されます。 トポロジ内で、システム管理タスクなどの計画 / 計画外アクティビティが、停止時 間ゼロで実行されます。 ■ セキュアなアプリケーション・サーバー・プラットフォームの提供。 ■ セキュリティおよび識別情報管理。 ■ ユーザーのプロビジョニングおよび管理を一元的に実行できるようにします。 ■ 管理権限を一貫性のある方法で委譲することを可能にします。 ■ ■ エンタープライズ・トポロジ内の他のセキュリティおよび識別情報管理システムと の統合を実現します。 ソフトウェアのプロビジョニングおよび管理。 ■ アプリケーションの分散およびアクセス可能性を簡略化および自動化します。 ■ システムの自己管理を可能にします。 ■ 複数のシステムを 1 つの論理ユニットとして監視および管理します。 ■ エンタープライズの集中管理ツールとして、Oracle Enterprise Manager を導入しま す。 Oracle Application Server の概要は、『Oracle Application Server 10g 概要』を参照してくだ さい。 各トポロジの要件およびインストール情報は、Oracle Application Server 10g のインスト レーション・ガイドの第 11 章を参照してください。 1-2 Oracle Application Server 10g エンタープライズ・デプロイメントのためのアドバンスト・トポロジ エンタープライズ・データ・センター・トポロジ : J2EE アプリケーション 1.2 推奨トポロジ 次の各項では、エンタープライズ・トポロジのいくつかの構成方法について説明します。 ■ エンタープライズ・データ・センター・トポロジ : J2EE アプリケーション ■ 部門別トポロジ ■ 開発ライフ・サイクル・トポロジ 1.3 エンタープライズ・データ・センター・トポロジ : J2EE ア プリケーション このデプロイメント・トポロジは、J2EE アプリケーションのサポートに対して最適化されて います。ここには、J2EE アプリケーションをセキュアな可用性の高い環境で実行するために 必要なコンポーネントがあります。 Portal and Wireless または Business Intelligence and Forms 中間層タイプのコンポーネント を使用するアプリケーションがある場合は、第 1.4 項「エンタープライズ・データ・セン ター・トポロジ : Portal、Wireless および Business Intelligence アプリケーション」を参照し てください。 対象ユーザー このトポロジは、組織の内外にユーザーを持つエンタープライズを想定しています。外部 ユーザーからのリクエストは、ファイアウォールを経由します。 説明 このトポロジ（図 1-1）では、Oracle Application Server の各コンポーネントが複数のコン ピュータと層に分散されます。各層にあるコンピュータへのアクセスは、ファイアウォール により保護されています。Web サーバーはインターネットからの攻撃に対して最もリスクの 高いコンポーネントのため、エンタープライズ内の他のコンピュータに直接アクセスできな いようにするのが一般的です。Web サーバーからのリクエストはファイアウォールを経由さ せます。 この分散トポロジでは、他層のコンピュータに影響を与えることなく、各層のコンピュータ を増やしてパフォーマンスと可用性を向上させることが可能です。たとえば、OracleAS Web Cache および Oracle HTTP Server を実行するコンピュータでボトルネックが検出され た場合は、これらのコンポーネントを実行するコンピュータを追加できます。 エンタープライズ・トポロジの概要 1-3 エンタープライズ・データ・センター・トポロジ : J2EE アプリケーション 図 1-1 エンタープライズ・データ・センター・トポロジ : J2EE アプリケーション 1-4 Oracle Application Server 10g エンタープライズ・デプロイメントのためのアドバンスト・トポロジ エンタープライズ・データ・センター・トポロジ : J2EE アプリケーション シングル・サインオン中間層（Web シングル・サインオン中間層（ サーバー層 DMZ） ） この層は、最も外側のファイアウォールに接しています。ロード・バランサは外部ユーザー からリクエストを受け取ると、この層の 2 組のコンピュータに転送します。この各組は、 バックアップ用およびパフォーマンスの向上を図るためにあり、少なくとも 2 台のコン ピュータで構成する必要があります。また各組には、必要に応じて、さらにコンピュータを 追加できます。 内部ユーザーも、この層で実行されている Web サーバーにアクセスします。 この層のコンピュータでは、次のコンポーネントが実行されます。 ■ 一方の組では、OracleAS Web Cache および Oracle HTTP Server が実行されます。 すべての Web サーバーが、この層で実行されます。Oracle HTTP Server および OracleAS Web Cache により、静的オブジェクトおよび J2EE アプリケーションに対する リクエストが処理されます。これらのコンポーネントは、リクエストを J2EE ビジネス・ ロジック DMZ 層のコンピュータに転送します。パフォーマンスと可用性を向上させる ために、Oracle HTTP Server の mod_oc4j モジュールがロード・バランシングとフェ イルオーバーを実行します。 ■ もう一方の組では、Oracle Application Server Single Sign-On および Oracle Delegated Administration Services が実行されます。 Oracle Application Server Single Sign-On は内外のユーザーを認証します。Oracle Delegated Administration Services は、ユーザーが Oracle Internet Directory にある各自 のプロファイルを編集できるようにします。 mod_plsql: Web サーバーからカスタマ・データベースに格納されている mod_plsql アプリ ケーションを起動する必要がある場合は、J2EE ファイアウォールは不要です（図 1-1 と図 1-2 を比較）。J2EE ファイアウォールの主な目的は、Web サーバーからイントラネットへの SQL*Net アクセスをブロックすることです。mod_plsql を使用する場合は、SQL*Net が使 用されるため、メッセージがブロックされないようにする必要があります。 エンタープライズ・トポロジの概要 1-5 エンタープライズ・データ・センター・トポロジ : J2EE アプリケーション 図 1-2 エンタープライズ・データ・センター・トポロジ : mod_plsql へのアクセスが必要な J2EE アプリケーション 1-6 Oracle Application Server 10g エンタープライズ・デプロイメントのためのアドバンスト・トポロジ エンタープライズ・データ・センター・トポロジ : J2EE アプリケーション Infrastructure DMZ この層では、Web サーバー層 DMZ で実行される Oracle Application Server Single Sign-On および Oracle Delegated Administration Services を除く、OracleAS Infrastructure 10g のす べてのコンポーネントが実行されます。 OracleAS Infrastructure 10g は別のファイアウォールの背後にインストールし、Web サー バーがエンタープライズ内の他のコンピュータに直接アクセスできないようにします。 Oracle Application Server Metadata Repository および Oracle Internet Directory には、 Oracle Application Server インスタンスにより使用される重要なデータが格納されます。 OracleAS Metadata Repository には、セキュリティ・メタデータ、管理メタデータおよび製 品メタデータが格納されます。J2EE and Web Cache インスタンスや Oracle Application Server Single Sign-On などのインフラストラクチャ・コンポーネントにより、このリポジト リが使用されます。 Oracle Internet Directory には、内外ユーザーのデータが格納されます。Oracle Application Server Single Sign-On は、Oracle Internet Directory のデータを基にユーザーを認証します。 OracleAS Metadata Repository および Oracle Internet Directory は、Real Application Clusters または Oracle Application Server Cold Failover Cluster 環境にインストールできま す。 J2EE ビジネス・ロジック DMZ この層では、J2EE and Web Cache インスタンスにアプリケーションをデプロイして実行し ます。アプリケーションは、カスタマ・データベースのビジネス・データにアクセスできま す。 J2EE and Web Cache インスタンスとコンピュータの数は、実行するアプリケーションの数 とユーザーの数に応じて決めます。OracleAS Clusters を使用してクラスタ化できるように、 少なくとも 2 つのインスタンスを用意することをお薦めします。インスタンスをクラスタ化 することで、可用性とスケーラビリティが強化され、パフォーマンスも向上します。 J2EE ファイアウォールがあるため、Web サーバー層 DMZ にある Web サーバーは、この層 のコンピュータに直接アクセスできません。 イントラネット この層には、エンタープライズ・プロセスを実行するコンピュータが含まれ、ビジネス・ データを格納するデータベースもあります。データベースは、Real Application Clusters ま たは Oracle Application Server Cold Failover Cluster などの高可用環境に配置できます。 J2EE ビジネス・ロジック層で実行されるアプリケーションは、この層のデータベースにアク セスできます。Web サーバー層 DMZ の Web サーバーで障害が発生した場合、イントラ ネット・ファイアウォールにより企業イントラネットへの Web サーバーのアクセスは完全 にブロックされます。 エンタープライズ・トポロジの概要 1-7 エンタープライズ・データ・センター・トポロジ : Portal、Wireless および Business Intelligence アプリケーション 1.4 エンタープライズ・データ・センター・トポロジ : Portal、 、 Wireless および Business Intelligence アプリケーション このデプロイメント・トポロジでは、J2EE アプリケーションに加えて、Portal and Wireless および Business Intelligence and Forms 中間層のコンポーネントを使用するアプリケーショ ンがサポートされます。これらのコンポーネントが不要な場合は、J2EE and Web Cache 中 間層のコンポーネントのみを使用するトポロジが説明されている第 1.3 項「エンタープライ ズ・データ・センター・トポロジ : J2EE アプリケーション」を参照してください。 対象ユーザー このトポロジは、組織の内外にユーザーを持つエンタープライズを想定しています。外部 ユーザーからのリクエストは、ファイアウォールを経由します。 説明 このトポロジ（図 1-3）では、Oracle Application Server の各コンポーネントが複数のコン ピュータと層に分散されます。各層にあるコンピュータへのアクセスは、ファイアウォール により保護されています。この分散トポロジでは、他層のコンピュータに影響を与えること なく、各層のコンピュータを増やしてパフォーマンスと可用性を向上させることが可能で す。たとえば、アプリケーションを実行するコンピュータでボトルネックが検出された場合 は、Web サーバー層 DMZ にコンピュータを追加して、そこで Business Intelligence and Forms 中間層を実行できます。 1-8 Oracle Application Server 10g エンタープライズ・デプロイメントのためのアドバンスト・トポロジ エンタープライズ・データ・センター・トポロジ : Portal、Wireless および Business Intelligence アプリケーション 図 1-3 エンタープライズ・データ・センター・トポロジ : Portal、 、Wireless および および Business Intelligence アプリケーション エンタープライズ・トポロジの概要 1-9 部門別トポロジ 1.5 部門別トポロジ 部門別構成トポロジの考慮事項と要件は、エンタープライズ・データ・センター構成と重複 しており、そのサブセットとなります。 対象ユーザー このトポロジは、第 1.3 項「エンタープライズ・データ・センター・トポロジ : J2EE アプリ ケーション」で説明したトポロジの小規模バージョンです。このトポロジは、2 つのメタ データ・リポジトリを持つ OracleAS Infrastructure 10g と複数の中間層で構成されます。こ のトポロジは、組織内の個々の部門での使用に適しています。このトポロジにアクセスする のは、組織の内部ユーザーです。したがって、このトポロジでは、外部ユーザーを対象とす るセキュリティ要件は念頭に置きません。 説明 このトポロジ（図 1-4）は、OracleAS Infrastructure と、少なくとも 1 つの Portal and Wireless 中間層を含む複数の中間層で構成されます。このトポロジでは、次の 2 つのメタ データ・リポジトリが使用されます。 ■ ■ 1 つは製品メタデータ用です（コンピュータ 2 にインストールされる）。このメタデー タ・リポジトリは、Portal and Wireless 中間層により使用されます。 もう 1 つは識別情報管理サービス用です（コンピュータ 1 にインストールされる）。この メタデータ・リポジトリは、識別情報管理サービスを必要とするすべての中間層により 使用されます。 トポロジの拡張 Oracle Application Server Middle-Tier は、必要に応じて、追加したコンピュータにインス トールできます。これらの中間層は、前述のメタデータ・リポジトリのいずれかに関連付け る必要があります。詳細は、『Oracle Application Server 10g 管理者ガイド』を参照してくだ さい。 1-10 Oracle Application Server 10g エンタープライズ・デプロイメントのためのアドバンスト・トポロジ 部門別トポロジ 図 1-4 部門別トポロジ 高可用性機能の追加 インフラストラクチャは、Real Application Clusters または Oracle Application Server Cold Failover Cluster 環境にインストールできます。具体的な手順は、Oracle Application Server 10g のインストレーション・ガイドの第 9 章「高可用性環境でのインストール」を参照して ください。 このトポロジでは、次のことを前提としています。 ■ OracleAS Infrastructure 10g のインストール時に、Oracle Internet Directory を新規作成 している。 エンタープライズ・トポロジの概要 1-11 部門別トポロジ 1.5.1 インストールの順序 アイテムを次の順序でインストールします。各コンピュータは、図 1-4 に示されています。 1. コンピュータ 1: OracleAS Infrastructure 10g を、識別情報管理サービスおよび OracleAS Metadata Repository とともにインストールします。具体的な手順は、Oracle Application Server 10g のインストレーション・ガイドの OracleAS Infrastructure 10g の インストールに関する項を参照してください。これにより、OracleAS Metadata Repository を含むデータベースが作成されます。また、Oracle Internet Directory が作 成されます。 2. コンピュータ 2: 2 番目の OracleAS Metadata Repository をインストールします。具体的 な手順は、Oracle Application Server 10g のインストレーション・ガイドの新規データ ベースでの OracleAS Metadata Repository のインストールに関する項を参照してくださ い。インストーラにより OracleAS Metadata Repository の登録を求められたときは、手 順 1 で作成した Oracle Internet Directory への接続情報を入力します。Portal and Wireless 中間層は、この第 2 のメタデータ・リポジトリを使用して製品メタデータを参 照します。具体的な手順は、Oracle Application Server 10g のインストレーション・ガ イドの複数のメタデータ・リポジトリが使用できるかどうかに関する項を参照してくだ さい。 3. コンピュータ 3: Portal and Wireless 中間層をインストールします。具体的な手順は、 Oracle Application Server 10g のインストレーション・ガイドの Portal and Wireless ま たは Business Intelligence and Forms のインストールに関する項を参照してください。 インストーラにより Oracle Internet Directory の情報が求められたときは、手順 1 で作 成した Oracle Internet Directory への接続情報を入力します。この Oracle Internet Directory には、手順 1 および 2 でインストールした OracleAS Metadata Repository が 登録されています。インストーラにより OracleAS Metadata Repository の情報が求めら れたときは、手順 2 でインストールした OracleAS Metadata Repository を選択します。 4. コンピュータ 4: J2EE and Web Cache 中間層をインストールします。具体的な手順は、 Oracle Application Server 10g のインストレーション・ガイドの OracleAS Cluster およ び Identity Management が使用可能な J2EE and Web Cache のインストールに関する項 を参照してください。インストーラにより Oracle Internet Directory の情報が求められ たときは、手順 1 で作成した Oracle Internet Directory への接続情報を入力します。イ ンストーラにより OracleAS Metadata Repository の情報が求められたときは、手順 1 で インストールした OracleAS Metadata Repository を選択します。 1-12 Oracle Application Server 10g エンタープライズ・デプロイメントのためのアドバンスト・トポロジ 開発ライフ・サイクル・トポロジ 1.6 開発ライフ・サイクル・トポロジ このトポロジは他のトポロジを組み合せたもので、テスト環境からステージング環境、さら には本番環境までのアプリケーションの移行をサポートします。 テスト環境 : アプリケーション開発者は、専用の環境でアプリケーションをテストします。 テスト環境の例については、Oracle Application Server 10g のインストレーション・ガイド の次の項を参照してください。 ■ Java 開発者トポロジに関する項 ■ Portal and Wireless 開発者トポロジに関する項 ■ Forms、Reports および Discoverer 開発者トポロジに関する項 ステージング環境 : 品質保証担当者は、本番環境にデプロイする前に、すべてのアプリケー ションをテストします。この環境では、第 1.5 項「部門別トポロジ」で説明したトポロジを 使用できます。ステージング環境のこのトポロジでは、1 つの部門のみでなく、すべての部 門からアプリケーションが実行されます。 本番環境 : アプリケーションは、企業内外のユーザーが使用できる状態にあります。第 1.3 項「エンタープライズ・データ・センター・トポロジ : J2EE アプリケーション」を参照して ください。 1.6.1 テスト環境からステージング環境へのアプリケーションの移行 アプリケーションをテスト環境からステージング環境に移行するには、ステージング環境内 の中間層にアプリケーションをデプロイします。アプリケーションは、ステージング環境の Identity Management および Oracle Application Server Metadata Repository を使用します。 アプリケーションがデータベース内のカスタム・データを使用している場合は、そのデータ をテスト環境のデータベースからステージング環境のデータベースに移動する必要がありま す。 1.6.2 ステージング環境から本番環境へのアプリケーションの移行 アプリケーションをステージング環境から本番環境に移行するには、本番環境にアプリケー ションをデプロイし、アプリケーションの固有データをステージング環境から本番環境に移 動します。 もう 1 つの方法として、再結合機能を使用することもできます。この機能により、中間層を そのインフラストラクチャから切り離し、別のインフラストラクチャに関連付けることがで きます。この機能を使用すると、中間層をそのアプリケーションとともに、ステージング環 境から本番環境に移行できます。 ただし、この方法でも、ステージング・データベースに格納されたアプリケーションの固有 データは本番環境のデータベースに移動する必要があります。 エンタープライズ・トポロジの概要 1-13 開発ライフ・サイクル・トポロジ 中間層の再結合は、本番環境にコンピュータやアプリケーション・サーバー・リソースを追 加する必要がある場合に便利です。この機能では、すでに中間層がインストールされアプリ ケーションがデプロイされているコンピュータを、1 度の手順で追加できます。 中間層の再結合の詳細は、『Oracle Application Server 10g 管理者ガイド』を参照してくださ い。 1-14 Oracle Application Server 10g エンタープライズ・デプロイメントのためのアドバンスト・トポロジ 2 エンタープライズ・トポロジのインストールと エンタープライズ・トポロジのインストールと 構成における考慮事項 次の各項では、それぞれのトポロジのインストールと構成における考慮事項について説明し ます。 ■ ■ J2EE アプリケーション・トポロジ エンタープライズ・トポロジ : Portal、BI、Wireless、Forms Services および Reports Services のインストールと構成 ■ 部門別トポロジ : 部門アプリケーションをホスティングする部門 ■ エンタープライズ・トポロジ : 開発ライフ・サイクル・トポロジのインストールと構成 ■ エンタープライズ・トポロジのインストール後のタスク ■ J2EE アプリケーション・トポロジのインストール後のタスク ■ 次に参照するドキュメント エンタープライズ・トポロジのインストールと構成における考慮事項 2-1 J2EE アプリケーション・トポロジ 2.1 J2EE アプリケーション・トポロジ 表 2-1 に、データ・センターなどのエンタープライズ環境に J2EE アプリケーション・トポ ロジをインストールおよび構成する際の考慮事項を要約します。 表 2-1 J2EE アプリケーション開発者トポロジにおけるインストールの考慮事項 考慮事項 デプロイの例 インストール ハードウェア・クラスタ、NFS マシンへの複数ホストのインス トール。 複数の中間層インスタンス。 Portal アプリケーション専用の製品メタデータ・サービス。 一部のアプリケーション用の共有製品メタデータ・サービス。 エンタープライズ全体にわたる共有セキュリティ・サービス。 一元化された管理サービス。 テスト、ステージング、本番サイクルのサポート。 ハード・ディスクや CPU の交換時、または RAM のアップグレー ド時において Oracle Application Server が正常に動作すること。 管理 一元化された管理サービス。 既存の一元化された管理サービスへの Oracle Application Server のプラグイン。 ロールベースの管理（9.0.4 の初期機能で Oracle Application Server の主要機能）。 複数の管理者。 バックアップとリカバリ : 分散環境全体の完全なコールド・バッ クアップ。 セキュリティ グローバル OID/SSO、または同じ論理 OID（1 つ以上の OID イ ンスタンスで構成）を共有する論理 SSO（1 つ以上の SSO インス タンスで構成） 。 外部ファイアウォールの背後にある内部ユーザー用の SSO と OID の両方。 内外両方のユーザーが使用するアプリケーションをホスティング する場合は（MOC など）、両ユーザーがセキュリティ・サービス の一部を共有できることを、セキュリティの考慮事項で確認する 必要がある。 部門別のサードパーティ・ディレクトリ（iPlanet、Active Directory、eDirectory など）との統合。 ユーザーのプロビジョニングとプロビジョニング解除。 2-2 Oracle Application Server 10g エンタープライズ・デプロイメントのためのアドバンスト・トポロジ J2EE アプリケーション・トポロジ 表 2-1 J2EE アプリケーション開発者トポロジにおけるインストールの考慮事項（続き） 考慮事項 デプロイの例 アプリケーションのデプロ イとパフォーマンス Web Cache のある、または Web Cache のない Oracle Application Server Clusters への J2EE アプリケーションのデプロイ。 Portal アプリケーションでの Web Cache の使用（単一ノード環境 の場合でも）。 Forms アプリケーションでの、SSO のない OLTP システムに対す る処理の実行。 BI アプリケーションでの、より厳重なセキュリティに保護された データ・ウェアハウスに対する処理の実行。 すべてのアプリケーションを Portal and Wireless デバイスからア クセス可能にする。 セルフ・サービス・アプリケーション（IP および Workflow を使 用）。 高可用性（HA） Infrastructure HA: 各 Infrastructure サービスに対する様々なタイ プの HA ソリューション。 オプション : 中間層アプリケーションに対する OPMN ベースのク ラスタ管理。 サードパーティ製品 ファイアウォール、ロード・バランサ、ハードウェア・クラスタ、 ハードウェア・アクセラレータ。 2.1.1 ハードウェア要件 エンタープライズ・デプロイメント・トポロジのインストールと構成、およびその各種コン ポーネントの実行に必要なハードウェア要件の概要は、表 2-2 を参照してください。 エンタープライズ・トポロジのインストールと構成における考慮事項 2-3 J2EE アプリケーション・トポロジ 2.1.2 インストールの順序 アイテムを次の順序でインストールします。 1. Infrastructure DMZ: OracleAS Infrastructure 10g を、識別情報管理サービスおよび Oracle Application Server Metadata Repository とともにインストールします。インス トール手順の詳細は、Oracle Application Server 10g のインストレーション・ガイドの OracleAS Infrastructure のインストールに関する項を参照してください。 注意 : 「構成オプションの選択」画面では、Oracle Application Server Single Sign-On または Oracle Delegated Administration Services を選択し ないでください。これらのコンポーネントは、次の手順でインストールし ます。 2. Web サーバー層 DMZ: Oracle Application Server Single Sign-On と Oracle Delegated Administration Services をインストールします。 Oracle Application Server 10g のインストレーション・ガイドの Identity Management コンポーネントのみのインストール（Oracle Internet Directory を除く）に関する項を参 照してください。次の点に注意してください。 ■ ■ 3. 「構成オプションの選択」画面では、Oracle Delegated Administration Services と Oracle Application Server Single Sign-On のみを選択します。 インストーラにより Oracle Internet Directory の情報が求められたときは、手順 1 で インストールした Oracle Internet Directory への接続情報を入力します。 Web サーバー層 DMZ: Business Intelligence and Forms（または Portal and Wireless）中 間層をインストールします。これにより、Oracle HTTP Server と OracleAS Web Cache もインストールされます。 詳細は、Oracle Application Server 10g のインストレーション・ガイドの第 6 章「Portal and Wireless または Business Intelligence and Forms のインストール」を参照してくだ さい。 2-4 Oracle Application Server 10g エンタープライズ・デプロイメントのためのアドバンスト・トポロジ エンタープライズ・トポロジ : Portal、BI、Wireless、Forms Services および Reports Services のインストールと構成 2.2 エンタープライズ・トポロジ : Portal、 、BI、 、Wireless、 、Forms Services および Reports Services のインストールと構成 次の表に、Portal、BI、Wireless、Forms および Reports をインストールおよび構成する際の ユーザーの考慮事項を要約します。 表 2-2 Portal、 、BI、 、Wireless、 、Forms および Reports のインストールおよび構成時の考慮事項 考慮事項 ユーザーの考慮事項 概要 Web サーバー層 : 複数マシンへの OHS のスタンドアロン・インス トール。 Application Server 層 : 1 つの大型マシンによる複数の中間層のホ スティング、または複数マシンによる複数アプリケーションのホ スティング。 Infrastructure: 専用または共有の製品メタデータ・サービス。共有 のセキュリティ・サービス、一元化された管理。 特別なインストール要件 : クラスタ・マシンのインストール。 クローニング、再関連付け : NFS マシンでのハードウェア・クラ スタ・サポートのインストール。 他の Oracle 製品との共存 : Oracle Application Server と Oracle Application Server Infrastructure が 2 つの異なる Oracle ホームに あり、IP プラットフォーム構築時の環境が別の Oracle ホームにあ るインストール。 ユーザー操作性のすぐれたインストールの基準 : 容易なインストールとクローニング。 インストール直後にパッチが不要。 簡単にクローニングできるインストール。 柔軟性の高い分散 Infrastructure サービス。 エンタープライズ・トポロジのインストールと構成における考慮事項 2-5 エンタープライズ・トポロジ : Portal、BI、Wireless、Forms Services および Reports Services のインストールと構成 表 2-2 Portal、 、BI、 、Wireless、 、Forms および Reports のインストールおよび構成時の考慮事項（続き） のインストールおよび構成時の考慮事項（続き） 考慮事項 ユーザーの考慮事項 ハードウェアの詳細 Web サーバー層 /Application Server 層 : 単一の大型ホストによる中間層、または小型マシンのファームに よる中間層。 単一の大型ホスト・マシンの詳細 : OS: Solaris（E280 以降） 、HP または IBM AIX。 CPU: 2 ～ 4（400Mhz 以上）。 RAM: 8GB。 ハード・ディスク : 80GB。 小型マシンの詳細（ローエンドの場合は 2 ～ 3、ハイエンドの場 合は 6 ～ 8）: OS: Linux、Solaris、HP または IBM AIX。 CPU: 1 ～ 2（Solaris の場合は 400Mhz 以上、Linux の場合は 600Mhz 以上）。 RAM: 1 ノードにつき 512MB ～ 1GB。 ハード・ディスク : 10 ～ 20GB。 Infrastructure: OS: Solaris、HP または IBM AIX。 CPU: 1 ～ 2CPU。 RAM: 512MB ～ 1GB。 ハード・ディスク : 10 ～ 20GB。 分散インストール・トポロジ Web サーバー層 : OHS は DMZ-1 にインストール、アプリケー ション・サーバーとは異なる DMZ にする。 Application Server 層 : Application Server は DMZ-2 にインス トール。 製品メタデータ・サービス : ほとんどのケースでは、DMZ-2 にイ ンストール。製品メタデータ・サービスのみを実行する専用ホス トが、専用の中間層インスタンスまたは小規模な一連の中間層イ ンスタンスにより使用される。 セキュリティ・サービス : ファイアウォールの背後にある。セ キュリティ・サービスのみを実行する専用のホスト。すべての中 間層インスタンスにより共有される。 管理サービス : ファイアウォール内での管理の一元化。 ユーザー・プロファイル システム管理者（高度な知識を持つユーザー）。 2-6 Oracle Application Server 10g エンタープライズ・デプロイメントのためのアドバンスト・トポロジ 部門別トポロジ : 部門アプリケーションをホスティングする部門 2.3 部門別トポロジ : 部門アプリケーションをホスティングする 部門 表 2-3 に、部門別トポロジをインストールおよび管理する際の考慮事項を要約します。 表 2-3 部門別トポロジにおける考慮事項 考慮事項 ユーザーの考慮事項 インストールと管理 クラスタ・マシン、NFS マシンへの複数ホストのインストール。 複数の中間層インスタンスの使用。 Java または J2EE アプリケーションのみをデプロイする場合、 Infrastructure は不要。 Portal アプリケーション専用の製品メタデータ・サービス。 一部のアプリケーション用の共有製品メタデータ・サービス。 エンタープライズ・レベル・ユーザーのサブセットを保護する共 有セキュリティ・サービス。 管理サービス : 管理対象のインスタンスの数はエンタープライズ・ データ・センターよりも少なくする。管理に関する他の考慮事項 はすべて同じ。 ハード・ディスクや CPU の交換時、または RAM やネットワー ク・インタフェースのアップグレード時において Oracle Application Server が正常に動作すること。 セキュリティ Infrastructure ソフトウェアと OID/SSO データの両方を含む単一 のインストール。 エンタープライズ OID に対するユーザー・サブセットの格納。 アプリケーションのデプロ イとパフォーマンス エンタープライズ構成サービスに対するオーバーヘッドをなくす。 複数の OC4J インスタンスに対するロード・バランサとしての OHS の使用。 Web Cache のある、または Web Cache のない Oracle Application Server Clusters への J2EE アプリケーションのデプロイ。 Portal アプリケーションでの Web Cache の使用。 高可用性（HA） 部門別デプロイメントの HA 要件は、アプリケーションの性質に 依存する。 HA が必要な場合は、ローカルな Data Guard または Cold Failover Cluster の使用が推奨される。必要ない場合は、完全な コールド・バックアップとリカバリ手順を使用する。 サードパーティ製品 アプリケーションへの負荷によっては、ロード・バランサが必要 になる場合がある。 エンタープライズ・トポロジのインストールと構成における考慮事項 2-7 エンタープライズ・トポロジ : 開発ライフ・サイクル・トポロジのインストールと構成 2.4 エンタープライズ・トポロジ : 開発ライフ・サイクル・トポ ロジのインストールと構成 表 2-4 に、開発ライフ・サイクル・トポロジをインストールおよび管理する際の考慮事項を 要約します。 表 2-4 開発ライフ・サイクル・エンタープライズ・トポロジにおける考慮事項 考慮事項 ユーザーの考慮事項 インストール テスト環境 : 中間層と Infrastructure の単一ホストへのインストー ル（すべてのサービスは単一のデータベースを使用）。 ステージング環境 : 1 つの大型マシンによる複数の中間層のホス ティング、または製品メタデータ・サービス（専用、共有のいず れか）を持つ複数マシンによる複数の中間層のホスティング。た だし、セキュリティ・サービスは必ず共有する。 本番環境 : エンタープライズ全体のセキュリティ・サービスを使 用する点以外は、ステージング環境とほぼ同じ。 ハード・ディスクや CPU の交換時、または RAM のアップグレー ド時において Oracle Application Server が正常に動作すること。 管理 テスト - スタンドアロンまたはコマンドライン・ツール。 開発 - スタンドアロンまたは一元管理。 本番 - 一元管理。 セキュリティ セキュリティ要件は流動的。 セキュリティ・サービスの再関連付けは必須。 アプリケーションのデプロ イとパフォーマンス 停止 / 起動およびデプロイにかかる時間の短縮が優先される。 チューニング可能なパラメータを頻繁に再構成する場合、それを 迅速に行えること。複数のバージョンをインストールおよび実行 できること。これは、ロード・バランシングやアプリケーション の組合せを 1 つのマシン上でテストすることが可能な環境である。 高可用性（HA） テスト環境 : 該当しない。アプリケーションとアプリケーション 固有の構成ファイルはバックアップされる。 ステージング環境 : Cold Failover Cluster またはローカルな DG。 完全なコールド・バックアップ。 本番環境 : 障害時リカバリ目的の RAC、Cold Failover Cluster お よびリモート DG。完全なコールド・バックアップ。 サードパーティ製品 アプリケーションの負荷によっては、DMZ、ファイアウォール、 ロード・バランサまたはルーターが必要になる場合がある。 2-8 Oracle Application Server 10g エンタープライズ・デプロイメントのためのアドバンスト・トポロジ エンタープライズ・トポロジのインストール後のタスク 2.5 エンタープライズ・トポロジのインストール後のタスク この項では、エンタープライズ・デプロイメント・トポロジの次の各領域でインストール後 に実行する必要があるタスクについて説明します。 ■ Infrastructure ■ OracleAS Portal と Oracle Application Server Wireless ■ Oracle Application Server Single Sign-On 2.5.1 Infrastructure OracleAS Portal では、Infrastructure レベルの Oracle Internet Directory と OracleAS Web Cache に対して、インストール後の手順を実行する必要があります。 2.5.1.1 OracleAS Portal と Oracle Internet Directory OracleAS Portal 中間層をインストールするたびに、Oracle Internet Directory（OID）にある Portal ユーザーが削除および再作成されます。これは、Portal へのランタイム・アクセスに、 最後にインストールした中間層の Oracle Application Server インスタンス・パスワードを使 用する必要があることを意味します。 すべての中間層インストールが実行された後に、ユーザーは OID にある各自の Portal ユー ザー・パスワードを変更できます。それ以降は、OracleAS Metadata Repository を変更する 必要がいっさいありません。 2.5.1.2 OracleAS Portal と OracleAS Web Cache 複数の中間層環境での Oracle Application Server Web Cache のセットアップの詳細な手順 は、『Oracle Application Server Portal 構成ガイド』に説明されています。 エンタープライズ・トポロジのインストールと構成における考慮事項 2-9 エンタープライズ・トポロジのインストール後のタスク 2.5.2 OracleAS Portal と Oracle Application Server Wireless 中間層のインストール時に Oracle Application Server Wireless を OracleAS Portal とともに 構成した場合は、Portal が Oracle Application Server Wireless サービスに登録されます。複 数の中間層をインストールした場合は、最後に構成された Oracle Application Server Wireless サービスの URL が OracleAS Portal インスタンスに格納されます。この URL は、 選択した Oracle Application Server Wireless サービスの URL に変更できます。Oracle Application Server Wireless サービス用に選択した Oracle Application Server Middle-Tier で、次のスクリプトを実行します。 UNIX: ORACLE_HOME/wireless/sample/portalRegistrar.sh Windows: ORACLE_HOME/wireless/sample/portalRegistrar.bat Portal プロバイダの UI フレームワーク 複数の Portal 中間層をインストールすると、プロバイダの作成に使用される既存のデフォル ト JPDK インスタンスの URL が上書きされます。この URL を、選択した JPDK インスタン スの URL に変更する手順は次のとおりです。 1. ブラウザを使用して Portal にログインします。 2. 「ビルダー」リンクをクリックします。 3. 「管理者」タブをクリックします。 4. 「サービス」ポートレットで「グローバル設定」をクリックします。 5. 「構成」タブをクリックします。 6. インストールした Portal 中間層のデフォルト JPDK インスタンスの URL を入力します。 関連項目 : 『Oracle Application Server Portal 構成ガイド』 2-10 Oracle Application Server 10g エンタープライズ・デプロイメントのためのアドバンスト・トポロジ J2EE アプリケーション・トポロジのインストール後のタスク 2.6 J2EE アプリケーション・トポロジのインストール後 アプリケーション・トポロジのインストール後のタスク ル後のタスク この項では、エンタープライズ・デプロイメント・トポロジの Web 層を構成する次の J2EE アプリケーションのインストール後のタスクについて説明します。 ■ Oracle Application Server Web Cache ■ Oracle HTTP Server ■ Oracle Application Server Forms Services ■ Oracle Application Server Reports Services ■ Oracle Application Server Discoverer ■ Oracle Application Server Single Sign-On ■ OracleAS Portal ■ Oracle Enterprise Manager 2.6.1 Oracle Application Server Web Cache 次に、OracleAS Web Cache のインストールおよび構成後のチェックリストを示します。 1. Ping URL の構成 ウォッチドッグが Web Cache の稼動状況をチェックする場合は、構成可能な URL を キャッシュ可能にすることをお薦めします。キャッシュできない URL を構成したとき は、Web Cache によりオリジナル・サーバーへの接続が試みられます。オリジナル・ サーバーが応答しないままウォッチドッグがタイムアウトする場合、ウォッチドッグに より Web Cache が再起動されます。 2. 接続制限の最適化 Application Server（オリジナル・サーバー）の接続制限とインバウンド接続の制限は、 最適な数値に設定する必要があります。この数値は、キャッシュ・ミスしたリクエスト を OracleAS Web Cache がキャッシュするときの、オリジナル・サーバーへのクライア ント・リクエストの通信量によって決まります。 3. 物理メモリー キャッシュ内のオブジェクトとのディスク・スワッピングを減らすために、キャッシュ 用に十分なメモリーをインストールする必要があります。オラクル社は、256MB 以上を 推奨します。 4. 謝罪ページのセットアップ（ネットワーク・エラー、サービスの混雑および ESI フラグ メント） ネットワーク・エラー、オリジナル・サーバーの混雑および ESI フラグメントに対する デフォルトの謝罪ページが、アプリケーションの形式（ルックアンドフィール）に合わ ない場合があります。 エンタープライズ・トポロジのインストールと構成における考慮事項 2-11 J2EE アプリケーション・トポロジのインストール後のタスク 5. SSL 証明書のセットアップ クライアント側の SSL 証明書をセットアップする手順は次のとおりです。 a. b. Oracle Wallet Manager で新しい Wallet を作成します。 OracleAS Web Cache Manager の管理インタフェースの「Listen Ports」ページ （「Ports」→「Listen Ports」）で新しい Wallet を指定します。 オリジナル・サーバー（OS）の SSL 証明書をセットアップする手順は次のとおりです。 a. Oracle Wallet Manager で新しい Wallet を作成します。 b. 「Origin Servers, Sites, and Load Balancing」ページで新しい Wallet を指定します （「Origin Servers, Sites, and Load Balancing」→「Origin Server Wallet」）。 6. サイト定義のセットアップ（仮想ホスティング） Web Cache では、サイト定義を使用することで、異なるサイトに対して異なるキャッ シュ・ルールを適用できます。また、サイトからサーバーへのマッピングにより、異な るサイトへのリクエストを特定のオリジナル・サーバーにルーティングできます。 Web Cache のサイト定義は、外部から認識できるホスト名と一致する必要があります。 Web Cache のデフォルトでは、Web Cache をインストールしたホストのデフォルト名と ポート番号が取得されます。 別名定義では、複数のホスト名を 1 つのサイトにマッピングすることができます。たと えば、サイト www.company.com:80 に company.com:80 という別名があるとします。 サイト www.company.com:80 に対して別名 company.com:80 を指定することで、Web Cache では、company.com:80 または www.company.com:80 のどちらからでも同一コン テンツをキャッシュできます。サイトおよび別名定義は、エラー・ページの構成にも影 響します。 7. ロギング Web Cache が標準モードで実行されているときは、冗長なイベント・ロギングを必ず無 効にします。冗長なロギングはデバッグ目的のためにあり、システム・リソースを大量 に消費します。 詳細は、『Oracle Application Server Web Cache 管理者ガイド』の第 10 章「Oracle Application Server Web Cache の管理」を参照してください。 8. 失効リクエスト 事前失効リクエストでは、失効インデックス・オプションが使用されます。 詳細は、『Oracle Application Server Web Cache 管理者ガイド』の第 10 章「Oracle Application Server Web Cache の管理」を参照してください。 2-12 Oracle Application Server 10g エンタープライズ・デプロイメントのためのアドバンスト・トポロジ J2EE アプリケーション・トポロジのインストール後のタスク 2.6.2 Oracle HTTP Server 再構成されたコンポーネントおよびサービスに応じて、Oracle HTTP Server への変更が必要 になる場合があることに注意してください。構成の説明は、各コンポーネント・ガイドの該 当する項を参照してください。 2.6.3 Oracle Application Server Forms Services インストール後に実行が必要な Oracle Application Server Forms Services の構成タスクはあ りません。Oracle Application Server Forms Services の動作の詳細は、『Oracle Application Server Forms Services 利用ガイド』の第 8 章を参照してください。また、Oracle Application Server Forms Services のリリース・ノートで、最新の問題点と回避策を確認し てください。 2.6.4 Oracle Application Server Reports Services インストール後に実行が必要な Oracle Application Server Reports Services の構成タスクは ありません。また、Oracle Application Server Reports Services のリリース・ノートで、最新 の問題点と回避策を確認してください。 2.6.5 Oracle Application Server Discoverer Discoverer 構成および通信プロトコル・ページで、その値をデフォルトからトンネリングに 変更して、ロード・バランサおよびファイアウォールが機能するようにします。 2.6.6 Oracle Application Server Single Sign-On 複数の Single Sign-on Server を使用している場合は、Oracle HTTP Server をさらに構成する 必要が生じる場合もあります。詳細は、第 3.3 項「複数のシングル・サインオン中間層にお ける 1 つの Oracle Internet Directory の使用」を参照してください。 2.6.7 OracleAS Portal Oracle Portal に対するインストール後のタスクには、次のものがあります。 ■ 第 4.3 項「ロード・バランシングの考慮事項」 ■ 第 4.4 項「ロード・バランシング・ルーターを使用する複数の中間層の構成」 ■ 第 4.5 項「リバース・プロキシ・サーバーの構成」 エンタープライズ・トポロジのインストールと構成における考慮事項 2-13 次に参照するドキュメント 2.6.8 Oracle Enterprise Manager EM はファイアウォールのセットアップ内でのみアクセス可能であることを確認します。 Application Server Control が正しく動作するためには、ポート 1814 がファイアウォール背 後の各層に対してオープンされている必要があります。 エンタープライズ・デプロイメント・トポロジの管理に Application Server Control を使用 する方法の詳細は、第 5 章「エンタープライズ・デプロイメント・トポロジの管理」を参照 してください。 2.7 次に参照するドキュメント Oracle Application Server をインストールした後は、『Oracle Application Server 10g 管理者 ガイド』を参照してください。このガイドには、「Oracle Application Server のインストール 後の作業の概要」という大変役に立つ章があります。 この章に記載されているコンポーネントを使用する場合は、そのコンポーネントを使用する 前に、インストール後のコンポーネントに固有の手順を実行する必要があります。表 2-5 「コンポーネント構成ガイド」に、その手順が説明されているコンポーネント・ガイドの一 覧を示します。 表 2-5 コンポーネント構成ガイド コンポーネント インストール後の手順を説明するガイド OracleAS Portal 『Oracle Application Server Portal 構成ガイド』 Oracle Application Server Forms Services 『Oracle Application Server Forms Services 利用ガイド』 Oracle Application Server Single Sign-On 『Oracle Application Server Single Sign-On 管理者ガイド』 Oracle Application Server Forms Services のリリース・ ノート Oracle Application Server Discoverer 『Oracle Application Server Discoverer 構成ガイド』 Oracle Application Server Reports Services 『Oracle Application Server Reports Services レポート Web 公開ガイド』 OracleAS Web Cache 『Oracle Application Server Web Cache 管理者ガイド』 Oracle HTTP Server 『Oracle HTTP Server 管理者ガイド』 2-14 Oracle Application Server 10g エンタープライズ・デプロイメントのためのアドバンスト・トポロジ 3 エンタープライズ・デプロイメント・トポロジ での Single Sign-On の構成 次の各項では、エンタープライズ・デプロイメント・トポロジでの OracleAS Single Sign-On に関する簡単な説明と追加情報を提供します。 ■ 高可用性について ■ セキュリティについて ■ 複数のシングル・サインオン中間層における 1 つの Oracle Internet Directory の使用 エンタープライズ・デプロイメント・トポロジでの Single Sign-On の構成 3-1 高可用性について 3.1 高可用性について システムまたはシステム内のコンポーネントの可用性は、それが正常に動作する時間の割合 によって定義されます。システムは、その要件とパフォーマンス仕様を満たすときに正常に 動作します。 高可用性が Oracle Internet Directory や OracleAS Single Sign-On などの Oracle Application Server のセキュリティ機能にどのような影響を与えるかについて、基本的な概要を理解して おく必要があります。 詳細は、『Oracle Application Server 10g 高可用性ガイド』を参照してください。 3.2 セキュリティについて Oracle Application Server には、そのすべてのコンポーネントに加えて、アプリケーショ ン・サーバーにデプロイされたサードパーティ・アプリケーションとカスタム・アプリケー ションをサポートする総合的なセキュリティ・フレームワークが用意されています。このフ レームワークでは、認証は OracleAS Single Sign-On、認可と一元化されたユーザー・プロビ ジョニングは Oracle Internet Directory、Web サーバー・コンポーネントは Oracle HTTP Server、Java2 Enterprise Edition（J2EE）アプリケーションのセキュリティは Oracle Application Server Java Authentication and Authorization Service（JAAS）プロバイダでそ れぞれ実行されます。 Oracle Application Server のセキュリティの詳細は、『Oracle Application Server 10g セキュ リティ・ガイド』を参照してください。最新の情報については、OTN-J（Oracle Technology Network Japan）（http://otn.oracle.co.jp/）を参照してください。 さらに、各コンポーネントのセキュリティに関して、各コンポーネントのドキュメントを参 照してください。 3.3 複数のシングル・サインオン中間層における 1 つの Oracle Internet Directory の使用 最も単純な高可用性の例は、中間層のシングル・サインオン・インスタンス自体内でのフェ イルオーバーです。中間層の追加はスケーラビリティを向上させ、結果として Single Sign-On Server の可用性が高くなります。 この構成では、1 つの HTTP ロード・バランサが 2 つ以上の Oracle HTTP Server の前に配置 されます。バックエンドには、1 つのディレクトリ・サーバーと 1 つの識別情報管理インフ ラストラクチャ・データベースがあります。ロード・バランサの目的は、シングル・サイン オンのパートナ・アプリケーションに対して 1 つのアドレスを公開しながら、アプリケー ション・リクエストを実際に処理するシングル・サインオン中間層ではファームを実現する ことです。HTTP ロード・バランサは、Oracle HTTP Server のどのインスタンスで障害が発 生したかを検出でき、そのインスタンスへのリクエストを他のインスタンスにフェイルオー バーできます。 3-2 Oracle Application Server 10g エンタープライズ・デプロイメントのためのアドバンスト・トポロジ 複数のシングル・サインオン中間層における 1 つの Oracle Internet Directory の使用 3.3.1 使用例 ここで紹介する使用例では、次の仮定的な構成を前提としています。 ■ ■ ■ ディレクトリ・サーバーと識別情報管理インフラストラクチャ・データベースは、 oid.mydomain.com にあります。 2 つのシングル・サインオン中間層があります。1 つはホスト sso1.mydomain.com にイ ンストールされ、IP アドレスは 138.1.34.172 です。もう 1 つは sso2.mydomain.com に インストールされ、IP アドレスは 138.1.34.173 です。これらのサーバーは両方とも非 SSL ポート 7777 をリスニングします。また、どちらも oid.mydomain.com にあるディ レクトリと識別情報管理インフラストラクチャ・データベースを使用するように構成さ れています。 パートナ・アプリケーションに対して公開される Single Sign-On Server のアドレスは sso.mydomain.com で、IP アドレスは 138.1.34.234 です。HTTP ロード・バランサは、 sso.mydomain.com のポート 80 をリスニングするように構成されています。HTTP ロー ド・バランサは、ユーザー・リクエストを sso1.mydomain.com と sso2.mydomain.com との間で負荷分散します。 注意 : ■ ■ この使用例では、ロード・バランサは非 SSL ポート番号であるポート 80 をリスニングします。SSL を使用してブラウザとやり取りするよう にロード・バランサを構成する場合は、異なるポート番号を使用する 必要があります。デフォルトの SSL ポート番号は 443 です。 この使用例とこの直後の使用例では、2 つのシングル・サインオン中 間層が使用されます。実際には、任意の数の中間層をサポートできま す。 図 3-1 に、1 つの Oracle Internet Directory インスタンスを使用するように構成された 2 つの シングル・サインオン中間層を示します。 エンタープライズ・デプロイメント・トポロジでの Single Sign-On の構成 3-3 複数のシングル・サインオン中間層における 1 つの Oracle Internet Directory の使用 図 3-1 2 つのシングル・サインオン中間層と 1 つの Oracle Internet Directory 3-4 Oracle Application Server 10g エンタープライズ・デプロイメントのためのアドバンスト・トポロジ 複数のシングル・サインオン中間層における 1 つの Oracle Internet Directory の使用 3.3.2 構成手順 図 3-1 に示したシングル・サインオン・システムのセットアップには、次のタスクが含まれ ます。 ■ 識別情報管理インフラストラクチャ・データベース、ディレクトリ・サーバーおよび Single Sign-on Server のインストール ■ シングル・サインオン中間層の Oracle HTTP Server の構成 ■ HTTP ロード・バランサの構成 ■ 識別情報管理インフラストラクチャ・データベースの構成 ■ シングル・サインオン中間層での mod_osso の再登録 識別情報管理インフラストラクチャ・データベース、ディレクトリ・サーバーおよび Single Sign-on Server のインストール 1. パートナ・アプリケーションに対して公開する Single Sign-on Server の名前を選択しま す。これはロード・バランサのアドレスにもなります。ここで紹介する使用例では、ア ドレスは sso.mydomain.com です。 2. oid.mydomain.com に Oracle Application Server Infrastructure をインストールします。 ここでは、オプション「Identity Management and OracleAS Metadata Repository」を 選択します。このインストール・タイプのコンポーネント一覧が表示されたら、Oracle Internet Directory のみを選択します。 3. 中間層の sso1.mydomain.com と sso2.mydomain.com に Oracle Application Server Infrastructure をインストールし、オプション「Identity Management and OracleAS Metadata Repository」を再度選択します。 4. このインストール・タイプのコンポーネント一覧が表示されたら、Oracle Application Server Single Sign-On のみを選択します。Oracle Universal Installer によりこれらのシ ングル・サインオン・インスタンスに関連付けられているディレクトリ・サーバー名を 求められたら、oid.mydomain.com を入力します。 注意 : Oracle Application Server インストーラでは、デフォルトで、特定 の範囲内のポート番号が割り当てられます。コンポーネントに別のポート 番号を割り当てる場合は、Oracle Application Server 10g のインストレー ション・ガイドの静的ポート番号に関する項を参照してください。 エンタープライズ・デプロイメント・トポロジでの Single Sign-On の構成 3-5 複数のシングル・サインオン中間層における 1 つの Oracle Internet Directory の使用 シングル・サインオン中間層の Oracle HTTP Server の構成 ユーザーと Oracle HTTP Server の間にロード・バランサが配置される場合は、Single Sign-on Server の有効な URL が変わります。この変更を反映するように、両方のシングル・ サインオン中間層の Oracle HTTP 構成ファイル httpd.conf を変更する必要があります。 このファイルは $ORACLE_HOME/Apache/Apache/conf にあります。 1. sso1.mydomain.com と sso2mydomain.com の httpd.conf ファイルに、次の行を追加 します。 KeepAlive off ServerName sso.mydomain.com Port 80 この手順により、シングル・サインオン中間層の Oracle HTTP Server が外部に公開さ れている名前（この例では sso.mydomain.com）でリスニングするように構成されま す。 2. HTTP ロード・バランサでの SSL の使用を構成する場合は、sso1.mydomain.com と sso2.mydomain.com の両方で mod_certheaders を構成します。このモジュールは、 Oracle HTTP Server で、HTTP 経由の受信リクエストを SSL リクエストとして処理する ことを可能にします。構成手順は次のとおりです。 a. 両方の中間層の httpd.conf ファイルに、次の行を入力します。 LoadModule certheaders_module libexec/mod_certheaders.so b. Oracle Application Server Web Cache をロード・バランサとして使用する場合は、 次の行を入力します。 AddCertHeader HTTPS ハードウェア・ロード・バランサを使用する場合は、次の行を入力します。 SimulateHttps on c. 2 つの中間層間でシステム・クロックを同期化します。 d. 次のコマンドを実行して、Distributed Cluster Management（DCM）スキーマをこ の変更で更新します。 $ORACLE_HOME/dcm/bin/dcmctl updateConfig -v -d 3-6 Oracle Application Server 10g エンタープライズ・デプロイメントのためのアドバンスト・トポロジ 複数のシングル・サインオン中間層における 1 つの Oracle Internet Directory の使用 HTTP ロード・バランサの構成 HTTP ロード・バランサには、BigIP、Alteon、Local Director などのハードウェアまたは Oracle Application Server Web Cache などのソフトウェアを使用できます。 ■ ハードウェア・ロード・バランサ ハードウェア・ロード・バランサを使用する場合は、アドレスが 138.1.34.172 と 138.1.34.173 の実在する 2 つのサーバーに対してプールを 1 つ構成します。アドレス 138.1.34.234 の仮想サーバーを 1 つ構成します。この仮想サーバーは、ロード・バラン サの外部インタフェースになります。手順は、ロード・バランサの各ベンダーが提供す るドキュメントを参照してください。 ■ ソフトウェア・ロード・バランサ Oracle Application Server Web Cache を使用して接続リクエストをロード・バランシン グする場合は、次を参照してください。 『Oracle Application Server Web Cache 管理者ガイド』の Single Sign-On Server へのリ クエストのルーティングおよび Oracle Identity Management インフラストラクチャの活 用に関する項を参照してください。 注意 : 最高のパフォーマンスを得るには、ハードウェア・ロード・バラ ンサを使用してください。 識別情報管理インフラストラクチャ・データベースの構成 シングル・サインオン中間層の一方で、スクリプト ssocfg を実行します。このスクリプト では、Single Sign-on Server が、その外部公開アドレスへの認証リクエストを受け付けるよ うに構成されます。この例では、スクリプトを次のように実行します。 ■ UNIX: $ORACLE_HOME/sso/bin/ssocfg.sh http sso.mydomain.com 80 ■ Windows NT/2000: %ORACLE_HOME%¥sso¥bin¥ssocfg.bat http sso.mydomain.com 80 コマンド例では、引数として、ロード・バランサのリスナー・プロトコル、ホスト名および ポート番号が指定されていることに注意してください。ロード・バランサのアドレスは、 Single Sign-on Server の外部公開名であることを思い起こしてください。SSL を使用するよ うにロード・バランサを構成する場合は、非 SSL ポートの 80 を SSL ポートの 443 に置き換 え、http を https に置き換えます。 エンタープライズ・デプロイメント・トポロジでの Single Sign-On の構成 3-7 複数のシングル・サインオン中間層における 1 つの Oracle Internet Directory の使用 ssocfg の実行後に、シングル・サインオン中間層を再起動します。 $ORACLE_HOME/opmn/bin/opmnctl restartproc process-type=OC4J_SECURITY 最後に、アプリケーションをテストします。 http://sso.mydomain.com/pls/orasso シングル・サインオン中間層での mod_osso の再登録 両方の中間層マシンで、mod_osso をパートナ・アプリケーション sso.mydomain.com とし て再登録します。 sso1.mydomain.com で mod_osso を再登録する手順は次のとおりです。 1. コンピュータ sso1.mydomain.com で、シングル・サインオン管理者として、シングル・ サインオン管理ページにログインします。その際には、必ず http://sso.mydomain.com/pls/orasso にログインしてください。 2. 「パートナ・アプリケーションの管理」ページを使用して、パートナ・アプリケーショ ン sso1.mydomain.com に対する既存のエントリを削除します。 3. ORACLE_HOME 環境変数を、sso1.mydomain.com の Oracle ホームを指すように設定し ます。PATH 変数に $ORACLE_HOME/jdk/bin を含めます。 4. 登録スクリプトを実行します。URL については、各自のインストールに適切な値に置き 換えてください。スクリプトにより、sso.mydomain.com という名前のパートナ・アプ リケーションが作成されます。 $ORACLE_HOME/jdk/bin/java -jar $ORACLE_HOME/sso/lib/ossoreg.jar -oracle_home_path orcl_home_path -site_name site_name -config_mod_osso TRUE -mod_osso_url mod_osso_url -u userid [-virtualhost virtual_host_name] [-update_mode CREATE | DELETE | MODIFY] [-config_file config_file_path] [-admin_id adminid] [-admin_info admin_info] コマンド・パラメータの説明は、『Oracle Application Server Single Sign-On 管理者ガイ ド』の第 4 章「mod_sso の登録」を参照してください。 3-8 Oracle Application Server 10g エンタープライズ・デプロイメントのためのアドバンスト・トポロジ 複数のシングル・サインオン中間層における 1 つの Oracle Internet Directory の使用 sso2.mydomain.com で mod_osso を再登録する手順は次のとおりです。 1. コンピュータ sso2.mydomain.com で、シングル・サインオン管理者として、シングル・ サインオン管理ページにログインします。その際には、必ず http://sso.mydomain.com/pls/orasso にログインしてください。 2. 「パートナ・アプリケーションの管理」ページを使用して、パートナ・アプリケーショ ン sso2.mydomain.com に対する既存のエントリを削除します。 3. 次の手順に従って、クリアテキストの osso.conf ファイルを作成します。 a. sso.mydomain.com の「パートナ・アプリケーションの編集」をクリックします。 b. 「パートナ・アプリケーションの編集」ページで、パラメータ sso_server_ version、cipher_key、site_id、site_token、login_url、logout_url および cancel_url の値を書き留めます。sso1.mydomain.com でアプリケーショ ンを登録したときに使用したのと同じ値を使用します。これは、両中間層間で同じ サイト ID、サイト・トークンおよび暗号鍵を使用するためです。これにより、両 サーバーがお互いのクローンとして動作することになります。 c. テキスト・エディタを使用して、osso.conf ファイルを作成します。 sso_server_version=v1.2 cipher_key=encryption_key site_id=id site_token=token login_url=http://sso.mydomain.com/pls/orasso/orasso.wwsso_app_admin.ls_login logout_url=http://sso.mydomain.com/pls/orasso/orasso.wwsso_app_admin.ls_ logout cancel_url=http://sso.mydomain.com:80/ 4. ルートとして sso2.mydomain.com にログインし、手順 3 で作成した osso.conf ファ イルにナビゲートします。その後、ファイルを不明瞭化します。 $ORACLE_HOME/Apache/Apache/bin/iasobf osso.conf $ORACLE_HOME/Apache/Apache/ conf/osso/osso.conf 5. Oracle HTTP Server を再起動します。 $ORACLE_HOME/opmn/bin/opmctl restartproc type=ohs エンタープライズ・デプロイメント・トポロジでの Single Sign-On の構成 3-9 複数のシングル・サインオン中間層における 1 つの Oracle Internet Directory の使用 6. oidadmin ツールを使用して、Delegated Administration Service（DAS）のベース URL を変更します。 a. ツールを起動します。 $ORACLE_HOME/bin/oidadmin b. Oracle Directory Manager に、cn=orcladmin としてログインします。 c. 属性 orcldasurlbase を含むエントリにナビゲートします。 cn=OperationalURLs,cn=DAS,cn=Products,cn=OracleContext d. この属性を次の値に変更します。 http://sso.mydomain.com/ ホスト名の後には必ずスラッシュを付けてください。ポータルで「useradmin」 をクリックすると、useradmin の URL がこの値に変更されます。 7. パートナ・アプリケーション oiddas をテストします。 http://sso.mydomain.com/oiddas 3-10 Oracle Application Server 10g エンタープライズ・デプロイメントのためのアドバンスト・トポロジ 4 ネットワーク 次の各項では、Oracle Application Server トポロジにおけるネットワーク関連の考慮事項に ついて説明します。 ■ Oracle Application Server ネットワークの概要 ■ ファイアウォールの考慮事項 : 適切なポートのオープン ■ ロード・バランシングの考慮事項 ■ リバース・プロキシ・サーバーの構成 ネットワーク 4-1 Oracle Application Server ネットワークの概要 4.1 Oracle Application Server ネットワークの概要 Oracle Application Server には、エンタープライズ・デプロイメント・トポロジの様々な構 成要素の接続および管理に使用できる機能として、次のものがあります。 ■ Distributed Configuration Management（DCM） ■ Oracle Process Manager and Notification（OPMN） ■ LDAP と Oracle Internet Directory ■ Enterprise Manager Server Control 4.1.1 Distributed Configuration Management（ （DCM） ） DCM は、エンタープライズ・デプロイメント・トポロジ全体にわたる複数の Oracle Application Server インスタンスの構成管理に使用できる管理フレームワークです。DCM は、クライアント、デーモンおよびメタデータ・リポジトリからなります。 DCM 機能では、次のことが可能になります。 ■ ■ ■ Oracle Application Server インスタンスのクラスタおよびファームの管理。Oracle Application Server Containers for J2EE インスタンス、Oracle HTTP Server インスタン ス、Oracle Process Manager and Notification、Java Authentication and Authorization Service などの個々のコンポーネントの構成管理。 Oracle Application Server Containers for J2EE アプリケーションのクラスタ全体へのデ プロイ（特に、開発ライフ・サイクル・トポロジに当てはまる）。 アーカイブ、保存とリストア、インポートとエクスポートなどの各機能での構成バー ジョンの管理。一部の機能は、定期的なシステム・メンテナンスの一環として自動化で きます。 dcmctl は、Distributed Configuration Management のコマンドライン・ユーティリティで す。このユーティリティは、構成管理とアプリケーションのデプロイに使用できます。 dcmctl の使用方法とその全コマンドの説明は、『Distributed Configuration Management リ ファレンス・ガイド』の第 2 章「dcmctl のコマンド」にあります。 構成とトポロジに関するすべてのデータは、Distributed Configuration Management メタ データ・リポジトリに格納されます。このリポジトリは Oracle Application Server Metadata Repository に含めることができます。 DCM の操作の詳細は、 『Distributed Configuration Management リファレンス・ガイド』を 参照してください。 4-2 Oracle Application Server 10g エンタープライズ・デプロイメントのためのアドバンスト・トポロジ Oracle Application Server ネットワークの概要 4.1.2 Oracle Process Manager and Notification（ （OPMN） ） OPMN は Oracle Application Server のすべてのインストール・タイプでインストールおよ び構成されており、Oracle Application Server の実行において中心的な役割を果たします。 OPMN の機能には、次のものがあります。 ■ ■ ■ ■ ■ 単一または複数の Oracle Application Server コンポーネントおよびインスタンスに対す るプロセス制御と監視に使用するコマンドライン・インタフェースの提供。 Oracle Application Server の各コンポーネントに対する統合された管理手段の提供。 Oracle Application Server のサブコンポーネントおよびサブ・サブコンポーネントの管 理。 異なる Oracle Application Server コンポーネント・インスタンスで発生したすべてのイ ベントの、それを利用可能なすべての Oracle Application Server コンポーネントへの送 信。 ユーザーが Oracle Application Server コンポーネントを決まった順序で起動および停止 できるようにすることによる、コンポーネント間での相互依存関係の問題の解決。 ■ イベント・スクリプトによる、エンタープライズ機能のカスタマイズ。 ■ ホストと Oracle Application Server プロセスの統計情報およびタスクの収集。 ■ ■ ■ Oracle Application Server プロセスが予期せず終了した際、または応答不能や到達不能 になった際の、そのプロセスの自動再起動。ping および通知操作により検出される。 Oracle Application Server プロセスの停止の自動検出。 OPMN が起動され使用可能になる前に、他の Oracle Application Server コンポーネント を起動および実行する必要はない。 OPMN サーバーは、ホストを起動した後、できるだけ早く起動してください。OPMN 管理 コンポーネントを起動 / 停止する際には、OPMN が実行されている必要があります。 OPMN の管理対象である Oracle Application Server コンポーネントは、手動で起動または 停止しないでください。Oracle Application Server コンポーネントの起動および停止に、以 前のバージョンの Oracle Application Server のコマンドライン・スクリプトまたはユーティ リティを使用しないでください。コンピュータをリブートまたはオフにするときは、OPMN を必ず最後に停止する必要があります。 Oracle Application Server コンポーネントの起動および停止には、Application Server Control または opmnctl コマンドライン・ユーティリティを使用してください。 OPMN の詳細は、『Oracle Process Manager and Notification Server 管理者ガイド』を参照 してください。 ネットワーク 4-3 Oracle Application Server ネットワークの概要 4.1.3 LDAP と Oracle Internet Directory LDAP は拡張可能な標準ディレクトリ・アクセス・プロトコルです。LDAP は、LDAP クラ イアントとサーバー間の通信で使用する共通言語です。 Oracle Internet Directory は、分散するユーザーおよびネットワーク・リソースに関する情報 の高速検索と一元管理を可能にする汎用目的のディレクトリ・サービスです。Oracle Internet Directory は、Lightweight Directory Access Protocol（LDAP）バージョン 3 と Oracle9i の高いパフォーマンス、スケーラビリティ、耐久性、可用性を組み合せたもので す。 LDAP と Oracle Internet Directory の操作の詳細は、『Oracle Internet Directory 管理者ガイ ド』を参照してください。アプリケーション開発者は、『Oracle Internet Directory アプリ ケーション開発者ガイド』の内容に精通している必要があります。 4.1.4 Enterprise Manager Server Control Oracle Enterprise Manager Application Server Control を使用することで、Web サイトの管 理者は Oracle Application Server インスタンスを構成し、そのパフォーマンスとスケーラビ リティを監視および最適化できます。また、問題状況に対する事前対応が可能になります。 管理者は、Application Server Control の Oracle Application Server インスタンス・ホーム ページから、Oracle Application Server インスタンスを停止および再起動できます。また、 収集されたパフォーマンス統計に基づいて構成設定を変更することで、パフォーマンスやス ケーラビリティを改善したり、任意の問題に対応できます。Application Server Control で は、各コンポーネントのパフォーマンス・メトリックが表形式とチャート形式の両方で表示 されるので、問題を一目で特定できます。Oracle Application Server をドリルダウンすると、 各 Oracle Application Server インスタンスのステータス、過去の起動時間の統計、および現 行のパフォーマンスと可用性情報を参照できます。 メトリックはコンポーネントのタイプにより異なりますが、代表的なメトリックとして次の ものがあります。 4-4 ■ 起動 / 停止ステータス ■ メモリー使用量 ■ エラー率 ■ 起動時間 ■ 接続数 Oracle Application Server 10g エンタープライズ・デプロイメントのためのアドバンスト・トポロジ ファイアウォールの考慮事項 : 適切なポートのオープン 4.2 ファイアウォールの考慮事項 : 適切なポートのオープン エンタープライズ・トポロジなどの Oracle Application Server の分散インストールでは、 ファイアウォールのポートを構成して、Oracle Application Server サービスが正常に動作で きるようにする必要があります。特に、次のことを許可する必要があります。 ■ ■ ■ ■ ■ ■ ユーザー（クライアント）が Web サーバーに接続するための HTTP と HTTPS のオープ ン アプリケーション・サーバー（中間層インストール）と Infrastructure 間の通信 （SQL*Net、ORCL-LDAP、ORCL-LDAP-SSL、ONS、OPMN などを使用） アプリケーション・サーバーとデータベース間の通信（SQL*Net および必要に応じて LDAP プロトコルを使用） アプリケーション・サーバーでの ONS アウトバウンドの使用 Enterprise Manager（Infrastructure および中間層インストールで使用）ではポート 1814、他の任意のツールやサービスでは LDAP ポートなどを設定 mod_oc4j と OC4J 間の通信に使用する AJP のオープン 注意 : デフォルト・ポートはオペレーティング・システム間 （Solaris、Windows および Linux）で異なる場合があります。ポート の検出と管理には、Application Server Control を使用してください。 デフォルト・ポートが変更されている場合は、ポート情報の追跡に Oracle Enterprise Manager Application Server Control を使用することをお薦めします。デフォルト・ポート に関する情報は、『Oracle Application Server 10g 管理者ガイド』のデフォルト・ポートの項 を参照してください。 Firewall Stateful Inspection（FSI）は DMZ、中間層および Infrastructure 間では使用されま せん。FSI は外部インターネット・インタフェースで使用することをお薦めします。 ファイアウォールの構成および管理に関する情報は、管理者に問い合せるか、ファイア ウォール実装のドキュメントを参照してください。 ネットワーク 4-5 ファイアウォールの考慮事項 : 適切なポートのオープン 4.2.1 異なる層にありファイアウォールで分断された mod_oc4j と OC4J この場合、mod_oc4j は Oracle HTTP Server 内にあり、（1）処理が必要なリクエストを識別 し、（2）そのリクエストをルーティングする OC4J プロセスを決定してから、（3）そのプロ セスと通信します。現行の mod_oc4j は一部の関連パラメータ（たとえば、SSL 情報や特定 の環境変数など）を抽出し、それらを AJP13 プロトコルを使用して OC4J に転送します。 mod_oc4j は OC4J からのレスポンスを分析し、Single Sign-On リダイレクトが必要な場合な どに適切なアクションを実行します。 デフォルトでは、ファーム内のすべての Oracle Application Server インスタンス上の OPMN プロセスが、各インスタンス内の OC4J の起動 / 停止ステータスを相互に通知しま す。次に、すべての OPMN がクラスタ内の任意のマシンの OC4J ステータスの変更をロー カルな mod_oc4j に通知します。これにより、mod_oc4j は管理者の介在がなくても、その ルーティング表を最新状態に維持できます。 4.2.2 mod_oc4j 用の適切なポートのオープン セキュリティ上の対策として、mod_oc4j は特定の層（通常は DMZ 層）に配置し、別の層 （通常は別の DMZ 層）に配置された OC4J プロセスと通信させることができます。mod_ oc4j は他の OC4J インスタンスとの通信に AJP を使用するため、AJP と OPMN 用に適切な ポートをオープンすることは重要です。 OC4J アーキテクチャの詳細は、『Oracle9i Application Server: mod_oc4j 技術概要』 （http://otndnld.oracle.co.jp/products/9ias/pdf/mod_oc4j_wp.pdf）を参照してください。 4.2.3 iASPT の構成 Application Server 10g Port Tunneling（iASPT）機能を使用すると、複数の OC4J プロセス との通信に必要なポートの数が 1 つになります。iASPT プロセスは、Oracle HTTP Server （OHS）と Java Virtual Machine（JVM）間の接続用の通信コンセントレータとして機能しま す。OHS はサーブレット・エンジンに直接接続せずに、そのかわりに iASPT に接続します。 その後、iASPT はその通信をサーブレット・エンジンに転送します。各 iASPT は、リクエ ストを複数のサーブレット・エンジンにルーティングします。こうした接続の集約化を行う ことにより、内部のファイアウォール DMZ の各 iASPT プロセスにそれぞれ 1 つのポートを オープンすればよくなり、OC4J コンテナごとに 1 つのポートをオープンする必要がなくな ります。 4-6 Oracle Application Server 10g エンタープライズ・デプロイメントのためのアドバンスト・トポロジ ロード・バランシング・ルーターを使用する複数の中間層の構成 iASPT の構成の一環として、mod_oc4j がある場所と OC4J コンテナがある場所を iASPT に 知らせる必要があります。Wallet ファイルとそのパスワードなど、mod_oc4j に追加する ディレクティブがいくつかあります。ターゲットの OC4J インスタンスがあるサーバーでは、 opmn.xml を構成し、iASPT ステータスを有効にすると同時に、使用するポートまたはポー ト範囲を指定する必要があります。最後に、iaspt.conf を変更し、Wallet の正しい場所と ポート情報を指定します。 iASPT の構成方法の詳細は、『Oracle HTTP Server 管理者ガイド』の第 10 章を参照してくだ さい。 4.3 ロード・バランシングの考慮事項 アプリケーション・サーバーのプール（リソース・プールと呼ばれる）と Single Sign-On Server のプールがある構成では、ロード・バランサ（ソフトウェアまたはハードウェア）に 仮想 IP アドレスを追加し、その仮想 IP アドレスにプールを追加する必要があります。アプ リケーション・サーバー・プールには、永続性を指定する必要があります。これには多くの 場合、ロード・バランサのソフトウェアまたはハードウェアの構成ページでアクティブな HTTP Cookie を設定することが関係しています。管理者に問い合せるか、ロード・バランサ のドキュメントを参照してください。 SSL では、暗号化が動作する仕組みにより、Cookie の使用が問題になります。多くの場合、 SSL セッション ID を使用して、ロード・バランサでの永続性を指定する必要があります。 『Oracle Application Server Portal 構成ガイド』の第 5 章に、ロード・バランシングに関する 追加情報があります。その情報の一部を、次の項で説明します。 4.4 ロード・バランシング・ルーターを使用する複数の中間層 の構成 この項では、ロード・バランシング・ルーター（LBR）がフロントエンドに配置された複数 の中間層をセットアップして、同一の OracleAS Metadata Repository にアクセスする方法に ついて説明します。 ロード・バランシング・ルーター（LBR）の目的は、クライアント層に対して 1 つのアドレ スを公開することと、実際にサービスを提供するサーバー・ファームのフロントエンドとな ることです。それらのサーバーは、LBR によるリクエストの振分けに基づいて処理を行いま す。LBR の実体は、Web リクエストを多数のフィジカル・サーバーに振り分ける機能を持つ 非常に高速なネットワーク・デバイスです。 ここでは、図 4-1 に示すような複数の中間層の構成をセットアップすることを想定します。 この例では、OracleAS Web Cache が Portal and Wireless 中間層と同じマシンにあることを 想定していますが、理論的には異なるマシンにあってもかまいません。 ネットワーク 4-7 ロード・バランシング・ルーターを使用する複数の中間層の構成 図 4-1 ロード・バランサを使用する複数の中間層の構成 表 4-1 図についての追加情報 マシン 詳細 ロード・バランシング・ルーター マシン名 : lbr.abc.com IP アドレス : L1.L1.L1.L1 リスニング・ポート : 80 失効化ポート : 4001 （内部からのみアクセス可 能） Oracle Application Server（Portal and Wireless 中間層）1 マシン名 : m1.abc.com IP アドレス : M1.M1.M1.M1 Oracle HTTP Server リスニング・ポート : 7778 OracleAS Web Cache リスニング・ポート : 7777 OracleAS Web Cache 失効化ポート : 4001 4-8 Oracle Application Server 10g エンタープライズ・デプロイメントのためのアドバンスト・トポロジ ロード・バランシング・ルーターを使用する複数の中間層の構成 表 4-1 図についての追加情報（続き） マシン 詳細 Oracle Application Server（Portal and Wireless 中間層）2 マシン名 : m2.abc.com IP アドレス : M2.M2.M2.M2 Oracle HTTP Server リスニング・ポート : 7778 OracleAS Web Cache リスニング・ポート : 7777 OracleAS Web Cache 失効化ポート : 4001 OracleAS Portal を LBR 用に構成する方法を理解するには、Portal の内部アーキテクチャを よく理解することが重要です。 ■ ■ ■ ■ Portal の Parallel Page Engine（PPE）は、ページのメタデータ情報を要求するために、 Oracle Application Server Web Cache に対するループバック接続を実行します。デフォ ルト構成では、OracleAS Web Cache と OracleAS Portal 中間層は同じマシン上にあり、 ループバックはローカルです。LBR を Oracle Application Server のフロントエンドにす る場合は、PPE から OracleAS Web Cache へのループバック・リクエストはすべて、 LBR 経由で行われることになります。OracleAS Portal 中間層と OracleAS Web Cache が 同じマシン上、場合によっては同じサブネット上にあるとします。この場合、追加構成 なしでは、ソケット接続によるコール時に、ループバック・リクエストが原因でネット ワークのハンドシェイクに問題が発生します。 ループバックが正常に行われるには、LBR にネットワーク・アドレス変換（NAT）のバ ウンス・バック・ルールをセットアップする必要があります。これは、ファイアウォー ル内部からのリクエストに対して、LBR をプロキシとして構成することを意味します。 これにより、レスポンスがネットワーク上のソース・アドレスに返されてから、クライ アントに返送されるようになります。 OracleAS Portal は、OracleAS Web Cache を使用して、数多くのコンテンツをキャッ シュします。OracleAS Web Cache にキャッシュされたコンテンツが変更された場合は、 OracleAS Portal は、データベースからの Web Cache の失効リクエストを OracleAS Web Cache に送信します。OracleAS Portal が失効メッセージを送信できるのは、1 つの Web Cache ノードのみです。OracleAS Web Cache クラスタでは、Portal がクラスタの 全メンバー内にあるコンテンツの失効化の処理を、1 つの OracleAS Web Cache メン バーに依頼します。 LBR を Oracle Application Server のフロントエンドにする場合は、LBR がデータベース からの失効リクエストを受け付け、クラスタ・メンバー間の負荷を調整するよう構成す る必要があります。 ネットワーク 4-9 リバース・プロキシ・サーバーの構成 注意 : Infrastructure は LBR の背後にあることに注目してください。 Infrastructure は 1 つのホストにインストールすることも、複数のホスト に分散させることもできます。Infrastructure を適切に構成する方法につ いては、『Oracle Application Server Single Sign-On 管理者ガイド』の 「拡張構成」を参照してください。 PPE が LBR にループバックするよう、ループバック接続用にサーバーを構成するには、次 の手順を実行する必要があります。 1 つの Portal and Wireless 中間層のインストール ■ 手順 1: 1 つの Portal and Wireless 中間層（M1）をインストールします。 ■ 手順 2: LBR 経由でアクセスされるように M1 の OracleAS Portal を構成します。 ■ 手順 3: OracleAS Portal が起動され実行中であることを確認します。 ■ 手順 4: 既存の Portal を実行するように新しい中間層（M2）を構成します。 これらの手順の詳細は、『Oracle Application Server Portal 構成ガイド』の第 5 章を参照 してください。 関連項目 : 使用するプラットフォームについての情報は、Oracle Application Server 10g のインストレーション・ガイドを参照してくださ い。 4.5 リバース・プロキシ・サーバーの構成 リバース・プロキシ・サーバーは、外部からアクセス可能なホストから内部ホストを分離す る目的で、ファイアウォール・アーキテクチャの一部として使用されるホスト・プロセスで す。これは、外部からのリクエストが内部サービスにアクセスするために必ず通過しなけれ ばならないプロキシを配置することにより実現されます。通常、プロキシ・サーバーは二重 のホームを持つホストになります。つまり、2 つのネットワーク・インタフェース・カード を持つホストになります。1 つのインタフェースは外部ネットワークに接続され、もう 1 つ のインタフェースは内部ネットワークまたはファイアウォールの非武装地帯（DMZ）に接 続されます。 4-10 Oracle Application Server 10g エンタープライズ・デプロイメントのためのアドバンスト・トポロジ リバース・プロキシ・サーバーの構成 図 4-2 に、ブラウザがプロキシ・サーバーにより公開されるホスト名を経由してサーバーに アクセスするアーキテクチャを示します。リクエストは、プロキシ・サーバーにより、ファ イアウォール内の実際のホストに転送されます。 この例では、OracleAS Single Sign-On Server がリバース・プロキシ・サーバーと連携して 動作するように正しく構成されていることを前提とします。 関連項目 : 『Oracle Application Server Single Sign-On 管理者ガイド』 の第 9 章「プロキシ・サーバーを使用する Oracle Application Server Single Sign-On の配置」を参照してください。 図 4-2 リバース・プロキシ・サーバーによるインターネット構成 ネットワーク 4-11 リバース・プロキシ・サーバーの構成 この例では、次のことを前提にしています。 ■ ■ ■ 公開アドレスは www.abc.com です。 ファイアウォールの内部では、Oracle Application Server Middle-Tier のサーバー名は internal.company.com です。この Application Server 中間層マシンのホストには、 OracleAS Web Cache と Oracle HTTP Server の両方がインストールされています。 外部では、サーバーのアドレスにデフォルト・ポートの 80 が使用されますが、内部で は、internal.company.com はポート 7777 をリスニングします。 図 4-1 に示すアーキテクチャで OracleAS Portal を構成する方法については、『Oracle Application Server Portal 構成ガイド』の第 5 章を参照してください。 プロキシ・サーバーをセットアップする方法の追加情報については、Portal Center （http://portalcenter.oracle.com）のペーパー『A Primer on Proxy Servers』を参照してくだ さい。任意の Portal Center ページで、右上隅にある検索アイコンをクリックしてください。 4-12 Oracle Application Server 10g エンタープライズ・デプロイメントのためのアドバンスト・トポロジ 5 エンタープライズ・デプロイメント・トポロジ の管理 この章では、エンタープライズ・デプロイメントの管理について次の情報を提供します。 ■ ■ 管理における全般的な考慮事項 エンタープライズ・データ・センター・トポロジ : 同一データ・センターを共有する複 数の部門 ■ 部門別トポロジ : 部門アプリケーションをホスティングする部門 ■ 開発ライフ・サイクル・トポロジ エンタープライズ・デプロイメント・トポロジの管理 5-1 管理における全般的な考慮事項 5.1 管理における全般的な考慮事項 管理対象であるトポロジのタイプに関係なく、次のような全般的な考慮事項があります。 ■ ログ・ファイルの循環 ■ OC4J の定期的な再起動 ■ サーバーおよびアプリケーションの起動と停止 ■ アップグレード、パッチおよび構成変更のロールアウト ■ バックアップとリカバリ ■ NFS の利用 ■ ポート管理 ■ 静的 IP アドレスと動的 IP アドレスの使用 ■ ログ・ファイルのマイニング ■ 異なる Infrastructure の分離と結合 5.1.1 ログ・ファイルの循環 サービスとコンポーネントの多くでは、定期的なメンテナンスが必要な独自のログ・ファイ ルが生成されます。このメンテナンスの要件は、エンタープライズ・トポロジの大きさと規 模により異なります。 パフォーマンスに悪影響を与えないように、Oracle Application Server のログ・ファイルに は最大 2GB の制限があります。この 2GB の制限より前に、管理者はログ・ファイルをアー カイブしてリセットする必要があります。このタスクは日次に、または週に何度か実行する 必要があります。 ログ・ファイルの管理方法の 1 つに、ウォータフォール・アプローチがあります。これは、 負荷の低い非ピーク時に、サーバーまたはコンポーネントを 1 度に 1 つずつメンテナンスす る方法です。このアプローチでは、1 つのサーバーがオフライン化されたり正常に停止され なかったときでも、データ・センター全体では高可用性を維持できます。サーバーまたはコ ンポーネントが再起動されたら、次のサーバーを停止して、1 時間後にログ・ファイルをメ ンテナンスするといったことも可能です。 また、確実に実行するために、このタスクを chron ジョブで自動化できます。詳細は、 『Oracle Application Server 10g 管理者ガイド』を参照してください。 5-2 Oracle Application Server 10g エンタープライズ・デプロイメントのためのアドバンスト・トポロジ 管理における全般的な考慮事項 5.1.2 OC4J の定期的な再起動 オラクル社は、OC4J のパフォーマンスを向上させるために、OC4J の定期的な再起動をお薦 めします。ある場合、アプリケーションや OC4J 自体にある Virtual Machine（VM）のメモ リー・リークが原因で、アプリケーション・サーバーのパフォーマンスが劣化することがあ ります。自動再起動が実行されない場合は、どれくらいの頻度で OC4J を再起動する必要が あるかを毎日の監視に基づいて決めます。ビジネス上のニーズも、OC4J を再起動する頻度 に影響を与えます。 5.1.3 サーバーおよびアプリケーションの起動と停止 どのサーバーおよびアプリケーションが起動または停止されるかは、対象のサーバー、ユー ザーの要件、およびユーザーが使用するアプリケーションによって決まります。サーバーお よびアプリケーションの起動と停止は、シェル・スクリプトおよび chron ジョブにより、必 要に応じて自動化できます。 サーバーの自動起動と停止を実装するときは、サーバーとともに起動する必要があるアプリ ケーションを考慮に入れる必要があります。また、サーバーが再起動されるまで停止するこ とや、サーバーまたはアプリケーションが正常な起動に失敗する可能性があることも踏まえ て、高可用性に対する影響を考慮する必要があります。 停止と再起動の手順は、それぞれの層ごとに計画することもできます。たとえば、パッチを ロールアウトする場合は、データベースはそのままにして、アプリケーション・サーバーの みを再起動すればよいこともあります。 5.1.4 アップグレード、パッチおよび構成変更のロールアウト アップグレードおよびパッチ適用目的で構成変更をロールアウトするときは、httpd.conf の 仮想ホストごとに 1 回実行します。httpd.conf の構成方法については、『Oracle HTTP Server 管理者ガイド』を参照してください。 5.1.5 バックアップとリカバリ エンタープライズ・トポロジの障害時におけるバックアップとリカバリ計画の一環として、 Oracle Application Server のアーカイブ機能を使用できます。日次の計画は、次のとおりで す。 1. コード・ツリー全体を対象とするオペレーティング・システムの完全な TAR ファイル の作成 2. すべてのインストール・タイプのファイル・リポジトリ（データベース）のバックアッ プ エンタープライズ・デプロイメント・トポロジの管理 5-3 管理における全般的な考慮事項 新しいサーバーがオンライン化され、リサーチと開発用のデータが必要となる開発環境で も、アーカイブを使用できます。 実際のバックアップとリカバリ計画では、ビジネス上のニーズとセキュリティ上の問題も考 慮に入れる必要があります。 5.1.6 NFS の利用 データ・センターでの NFS の使用には、次のような利点があります。 ■ ■ ■ NFS パーティション上での静的コンテンツの保持および必要時のサーバーまたはアプリ ケーションへのマウント 静的コンテンツの迅速なデプロイ エンタープライズ・トポロジ全体にわたるデータの迅速な再同期化（ときには、数時間 かかった処理が数分に短縮される） 5.1.7 ポート管理 大規模なエンタープライズ・トポロジでは、特別なポート構成が実装されている場合、ポー トとポート競合の追跡が非常に困難になる可能性があります。また、次に割当て可能なポー トの特定も困難になります。 必要に応じて、多数のポートを 1 つの IP アドレスに関連付けることができます。 Oracle Enterprise Manager を使用して情報を表示し、エンタープライズ・トポロジでのポー トの使用を管理します。 5.1.8 静的 IP アドレスと動的 IP アドレスの使用 静的 IP アドレスと動的 IP アドレスの選択と使用は、次のような要因により決まります。 ■ ■ ■ エンタープライズ・トポロジの仮想 IP 構造 ハードウェアまたはソフトウェア・ロード・バランサによる IP アドレッシングの制御方 法 ファイアウォールの構成と実装 5-4 Oracle Application Server 10g エンタープライズ・デプロイメントのためのアドバンスト・トポロジ エンタープライズ・データ・センター・トポロジ : 同一データ・センターを共有する複数の部門 5.1.9 異なる Infrastructure の分離と結合 Oracle Application Server の新機能の 1 つに、中間層と SSO/OID インスタンス （Infrastructure）を再関連付けする機能があります。 たとえば、ある中間層インスタンスを開発用途に限定した SSO/OID インスタンスに関連付 けることで、ロールアウトする前に、開発、テストまたはアップグレードを実行できます。 その後、中間層を本来の SSO/OID インスタンスに再関連付けします。Infrastructure の結合 または分離の詳細は、『Oracle Application Server 10g 管理者ガイド』を参照してください。 この後の各項で、管理対象となるトポロジのタイプごとに情報を提供します。 5.1.10 ログ・ファイルのマイニング エンタープライズ・トポロジでのログ・ファイルのマイニングには、次のような利点があり ます。 ■ 本番環境にデプロイする前のデバッグ作業での開発チームの支援 ■ ハッカーによる攻撃などのセキュリティ情報の提供 ■ エラーの各レベルでの情報の提供 ■ 自動化されたプロセスに関する情報の提供 5.2 エンタープライズ・データ・センター・トポロジ : 同一デー タ・センターを共有する複数の部門 次の各項では、エンタープライズ・デプロイメント・トポロジにおける管理上の考慮事項に ついて説明します。 ■ 管理上の考慮事項のチェックリスト ■ Oracle Enterprise Manager Application Server Control のチェックリスト ■ バックアップとリカバリに関する考慮事項 ■ アプリケーションのデプロイとパフォーマンスに関する考慮事項 5.2.1 管理上の考慮事項のチェックリスト ■ ■ Oracle Enterprise Manager の監視機能とアラート機能を使用して、システム内の潜在的 なパフォーマンス問題が確実に通知されるようにします。デフォルトのアラートしきい 値を使用するか、監視とアラートに必要なカスタムのしきい値を構成します。しきい値 のベースラインの決定には、Oracle Enterprise Manager で収集された履歴データを使用 します。 デプロイするアプリケーション用に、可用性とレスポンスを監視する Web アプリケー ションを作成します。 エンタープライズ・デプロイメント・トポロジの管理 5-5 エンタープライズ・データ・センター・トポロジ : 同一データ・センターを共有する複数の部門 5.2.2 Oracle Enterprise Manager Application Server Control のチェックリスト アプリケーション・サーバーの管理には、Oracle Enterprise Manager Application Server Control を使用します。これは、アプリケーション・サーバーとともに自動的にインストー ルされます。このコンソールには、Application Server Control の「管理」リンクからアクセ スします。 Oracle Enterprise Manager Application Server Control は、次の目的で使用します。 ■ コンポーネントの必要に応じた起動と停止 ■ 未使用のコンポーネントの有効化 / 無効化によるシステム・リソースの消費の防止 ■ アプリケーション・サーバーにある任意コンポーネントの構成パラメータの設定または 変更 ■ アプリケーションのデプロイと構成 ■ アプリケーションのセキュリティ管理 ■ アプリケーションとコンポーネントのパフォーマンスおよびリソース消費のリアルタイ ムな監視 ■ ポートの表示と設定 ■ ログ・ファイルの閲覧と検索 ■ Infrastructure のスキーマ管理 ■ 使用可能なコマンドライン・ユーティリティによるスクリプト作成と自動化 5.2.3 バックアップとリカバリに関する考慮事項 ■ 分散環境全体の完全なコールド・バックアップ 5.2.4 アプリケーションのデプロイとパフォーマンスに関する考慮事項 チェックリストで、次の項目を確認します。 ■ ■ ■ ■ J2EE アプリケーションが Web Cache のある、または Web Cache のない Oracle Application Server Clusters にデプロイされている Portal アプリケーションが Web Cache を使用している（単一ノード環境の場合でも） Forms アプリケーションが Single Sign-On のない OLTP システムに対して処理を実行し ている Business Intelligence（BI）アプリケーションが、より厳重なセキュリティに保護された データ・ウェアハウスに対して処理を実行している ■ すべてのアプリケーションが Portal and Wireless デバイスからアクセス可能である ■ セルフ・サービス・アプリケーションが IP および Workflow を使用している 5-6 Oracle Application Server 10g エンタープライズ・デプロイメントのためのアドバンスト・トポロジ 部門別トポロジ : 部門アプリケーションをホスティングする部門 5.3 部門別トポロジ : 部門アプリケーションをホスティングする 部門 次の各項では、部門別トポロジにおける管理上の考慮事項について説明します。 ■ 管理上の考慮事項 ■ バックアップとリカバリに関する考慮事項 ■ アプリケーションのデプロイとパフォーマンスに関する考慮事項 5.3.1 管理上の考慮事項 ■ ■ ■ Enterprise Manager の監視機能とアラート機能を使用して、システム内の潜在的なパ フォーマンス問題が確実に通知されるようにします。用意されているアラートしきい値 を使用するか、監視とアラートに必要なカスタムのしきい値を構成します。しきい値の ベースラインの決定には、Enterprise Manager で収集された履歴データを使用します。 デプロイするアプリケーション用に、可用性とレスポンスを監視する Web アプリケー ションを作成します。 アプリケーション・サーバーの管理には、Oracle Enterprise Manager Application Server Control を使用します。Oracle Enterprise Manager Application Server Control は、アプリケーション・サーバーとともに自動的にインストールされます。 Oracle Enterprise Manager Application Server Control で、次のタスクを実行します。 ■ コンポーネントの必要に応じた起動と停止 ■ 未使用のコンポーネントの有効化 / 無効化によるシステム・リソースの消費の防止 ■ アプリケーション・サーバーにある任意コンポーネントの構成パラメータの設定ま たは変更 ■ アプリケーションのデプロイと構成 ■ アプリケーションのセキュリティ管理 ■ アプリケーションとコンポーネントのパフォーマンスおよびリソース消費のリアル タイムな監視 ■ ポートの表示と設定 ■ ログ・ファイルの閲覧と検索 ■ Infrastructure のスキーマ管理 ■ 使用可能なコマンドライン・ユーティリティによるスクリプト作成と自動化 エンタープライズ・デプロイメント・トポロジの管理 5-7 開発ライフ・サイクル・トポロジ 5.3.2 バックアップとリカバリに関する考慮事項 ■ 分散環境全体の完全なコールド・バックアップ 5.3.3 アプリケーションのデプロイとパフォーマンスに関する考慮事項 ■ ■ ■ ■ 複数の OC4J インスタンスに対するロード・バランサとしての OHS の使用 Web Cache のある、または Web Cache のない Oracle Application Server Clusters への J2EE アプリケーションのデプロイ Portal アプリケーションでの Web Cache の使用 Oracle Enterprise Manager Application Server Control を使用したアプリケーションのパ フォーマンスと可用性の監視 5.4 開発ライフ・サイクル・トポロジ テスト環境 : アプリケーション・サーバー・インストールでは、Oracle Enterprise Manager Application Server Control を使用します。スタンドアロン・コンポーネントでは、コマンド ライン・ツールを使用します。 ステージング環境 : アプリケーション・サーバー・インストールでは、Oracle Enterprise Manager Application Server Control を使用します。スタンドアロン・コンポーネントでは、 コマンドライン・ツールを使用します。 本番環境 : アプリケーション・サーバー・インストールでは、Oracle Enterprise Manager Application Server Control を使用します。スタンドアロン・コンポーネントでは、コマンド ライン・ツールを使用します。 5-8 Oracle Application Server 10g エンタープライズ・デプロイメントのためのアドバンスト・トポロジ 6 パフォーマンスとチューニングに 関する考慮事項 エンタープライズ・デプロイメント・トポロジのパフォーマンスを最適化するためには、そ の動作とリソース使用状況の監視方法を理解することが最も重要です。Oracle Application Server には、そのための各種のツールが用意されています。インストールの監視方法の詳細 は、『Oracle Application Server 10g パフォーマンス・ガイド』を参照してください。また、 ハードウェア・ベンダーのほとんどは、ハードウェア・リソースの使用状況を監視するツー ルを提供しています。 この章では、デプロイメント・トポロジのパフォーマンスのチューニングに役立つ、次のリ ファレンス情報を提供します。 ■ オリジナル・サーバー（OS）のネットワーク・パラメータ ■ Oracle HTTP Server（OHS） ■ SSL ■ Oracle Internet Directory（OID） ■ JVM パラメータ ■ JSP ■ Web Cache ■ ロギング・レベル ■ データベース接続 ■ Portal パフォーマンスとチューニングに関する考慮事項 6-1 オリジナル・サーバー（OS）のネットワーク・パラメータ 6.1 オリジナル・サーバー（OS）のネットワーク・パラメータ オリジナル・サーバー（ ）のネットワーク・パラメータ OS のネットワーク・パラメータの設定でパフォーマンスが最適化されており、十分なネッ トワーク・キャパシティがあることを確認します。詳細は、『Oracle Application Server 10g パフォーマンス・ガイド』を参照してください。 6.2 Oracle HTTP Server（ （OHS） ） Application Server 構成での並行性を制御するために、OHS の MaxClients パラメータをど のように使用するかを理解する必要があります。また、OHS との永続接続（キープ・アラ イブ）をいつ使用すべきか、永続接続をどれくらいの時間維持すべきかを理解する必要があ ります。永続接続では、それぞれ Apache の子プロセスが使用されます（UNIX の場合）。詳 細は、『Oracle Application Server 10g パフォーマンス・ガイド』を参照してください。 6.3 SSL SSL を使用するとパフォーマンスのオーバーヘッドが高くなるので、SSL は適切に使用しま す。SSL セッションの最初のリクエストは、後続のリクエストよりも時間がかかります。ま た、SSL のセッション時間を構成する方法も理解する必要があります。詳細は、『Oracle Application Server 10g パフォーマンス・ガイド』と『Oracle Application Server Certificate Authority 管理者ガイド』を参照してください。 6.4 Oracle Internet Directory（ （OID） ） OID を使用するときは、LDAP キャッシュを使用します。また、jazn-xml でもセキュリティ が十分に確保される場合は、jazn-xml を使用することでパフォーマンスが向上します。詳細 は、次のガイドを参照してください。 ■ 『Oracle Application Server 10g パフォーマンス・ガイド』 ■ 『Oracle Internet Directory 管理者ガイド』 ■ 『Oracle Application Server 10g セキュリティ・ガイド』 6.5 JVM パラメータ 使用する Java アプリケーションとプラットフォームに対して適切な Java Virtual Machine （JVM）パラメータを設定します。可能なかぎり、認定された最新の JVM を使用します。た とえば、オラクル社でのテストにおいて、JDK 1.4.1 は JDK 1.3.1 よりも高速であることが証 明されています。詳細は、『Oracle Application Server 10g パフォーマンス・ガイド』を参照 してください。 6-2 Oracle Application Server 10g エンタープライズ・デプロイメントのためのアドバンスト・トポロジ Portal 6.6 JSP タイムスタンプ・チェックとセッション生成が不要な場合は、それらを無効にすることで、 JSP のパフォーマンスを向上させることができます。 6.7 Web Cache Web Cache を使用することで、アプリケーションのパフォーマンスを大幅に向上させること ができます。各アプリケーションでのキャッシュの妥当性を検討します。Web Cache 用に十 分なメモリーとネットワーク帯域幅を確保し、できるだけ高速な CPU を使用します。Web Cache の使用によりスループットが向上すると、今度はネットワークの帯域幅が主要なボト ルネックになる可能性があります。 詳細は、『Oracle Application Server Web Cache 管理者ガイド』を参照してください。 6.8 ロギング・レベル デフォルトでは、Oracle Application Server コンポーネントのロギング・レベルが本番シス テムに適したレベルに設定されています。より詳細なロギングを有効にすることで追加情報 を取得できますが、システムへのパフォーマンス・オーバーヘッドが大きくなります。デ バッグ・ログ・レベルの使用は、トラブルシューティング目的に限定します。 6.9 データベース接続 一部の Oracle Application Server コンポーネントにはデータベース接続機能があり、維持さ れているデータベース接続の数やデータベース・セッションの時間をチューニングできま す。データベース接続のチューニング方法、および JDBC と PL/SQL メトリックの操作方法 の詳細は、『Oracle Application Server 10g パフォーマンス・ガイド』を参照してください。 6.10 Portal 使用度の高いポータルでは、Portal の Parallel Page Engine の並行性を向上させることがで きます。ただし、並行性が向上しても、それを処理するための十分なリソースがシステムに ない場合は、システム全体のパフォーマンスに悪影響を与えることになります。 パフォーマンスとチューニングに関する考慮事項 6-3 Portal 6-4 Oracle Application Server 10g エンタープライズ・デプロイメントのためのアドバンスト・トポロジ 索引 A Application Server Control 管理タスク , 5-7 管理チェックリスト , 5-6 パフォーマンス・メトリック , 4-4 D Distributed Configuration Management dcmctl コマンドライン・ユーティリティ , 4-2 Distributed Configuration Management（DCM） 概要 , 4-2 F Firewall Stateful Inspection, 4-5 I iASPT mod_oc4J, 4-7 OC4J, 4-7 Wallet 情報の指定 , 4-7 構成 , 4-6 Infrastructure 結合または分離 , 5-5 Infrastructure DMZ インストール , 1-7 説明 , 1-7 J J2EE アプリケーション・トポロジ インストールの順序 , 2-4 ハードウェア要件 , 2-3 J2EE アプリケーション・トポロジのインストール後の タスク , 2-11 Discoverer, 2-13 Enterprise Manager, 2-14 Forms Services, 2-13 Oracle HTTP Server, 2-13 Ping URL, 2-11 Portal, 2-13 Reports Services, 2-13 Single Sign-On, 2-13 SSL 証明書 , 2-12 失効リクエスト , 2-12 謝罪ページ , 2-11 接続制限の最適化 , 2-11 チェックリスト , 2-11 物理メモリー要件 , 2-11 ロギング , 2-12 J2EE ビジネス・ロジック DMZ, 1-7 JPDK インスタンスの URL 選択の変更 , 2-10 JSP パフォーマンスの向上 , 6-3 JVM 適切なパラメータの設定 , 6-2 L LDAP システム・パフォーマンス , 6-2 J2EE and Web Cache インスタンス 数の決定 , 1-7 索引 -1 パフォーマンスの向上 , M mod_plsql アプリケーション・アクセス , 1-5 N NFS データ・センターでの使用 , 5-4 O OC4J 定期的な再起動 , 5-3 OID 複数のシングル・サインオン中間層 , 3-2 opmn.xml iASPT, 4-7 Oracle Application Server ネットワーク 概要 , 4-2 Oracle Enterprise Manager Application Server Control 概要 , 4-4 Oracle HTTP Server MaxClients パラメータの使用 , 6-2 Oracle Internet Directory LDAP, 4-4 Oracle Process Manager and Notification（OPMN） 機能 , 4-3 OracleAS Portal LBR 用の構成 , 4-9 P Portal の Parallel Page Engine 向上した並行性の処理 , 6-3 Portal プロバイダの UI フレームワーク デフォルト JPDK インスタンスの URL, 2-10 S SSL Cookie と暗号化について , 4-7 セッション時間の構成 , 6-2 W Web Cache 索引 -2 6-3 あ アプリケーションのデプロイ 考慮事項 , 5-6, 5-8 インストールと構成 J2EE アプリケーション・トポロジ , 2-2 Portal、BI、Wireless、Forms Services および Reports Services, 2-5 開発ライフ・サイクル・サポート・トポロジ , 2-8 部門別トポロジ , 2-7 インデックス・オプション , 2-12 イントラネット 層の説明 , 1-7 エンタープライズ・データ・センター・トポロジ J2EE アプリケーション , 1-3 Portal、Wireless および Business Intelligence アプ リケーション , 1-8 Portal、Wireless および Business Intelligence アプ リケーション、説明 , 1-8 Portal、Wireless および Business Intelligence アプ リケーション、対象ユーザー , 1-8 エンタープライズ・データ・センター・トポロジ、 J2EE アプリケーション 説明 , 1-3 対象ユーザー , 1-3 エンタープライズ・デプロイメント・トポロジ 管理上の考慮事項 , 5-2 エンタープライズ・トポロジ インストール後のタスク , 2-9 Infrastructure, 2-9 エンタープライズ・トポロジ、推奨理由 , 1-2 エンタープライズ・トポロジのインストール後のタス ク OracleAS Portal と Oracle Application Server Wireless, 2-10 OracleAS Portal と Oracle Internet Directory, 2-9 OracleAS Portal と OracleAS Web Cache, 2-9 オリジナル・サーバー（OS）の SSL 証明書 構成 , 2-12 か 開発ライフ・サイクル・サポート・トポロジ 考慮事項 , 5-8 説明 , 1-13 開発ライフ・サイクル・トポロジ ステージング環境から本番環境へのアプリケーショ ンの移行 , 1-13 仮想 IP アドレス ロード・バランサへの追加 , 4-7 仮想ホスト サイト定義のセットアップ , 2-12 管理上の考慮事項 同一データ・センターを共有する複数の部門 , 5-5 起動と停止 アプリケーション , 5-3 サーバー , 5-3 機能 , 3-2 高可用性 概要 , 3-2 高可用性機能 追加 , 1-11 構成変更 分散化 , 5-3 コンポーネント構成ガイド、一覧表 , 2-14 さ サービスの質、確保 , 1-2 サイト定義 仮想ホストの構成 , 2-12 障害時リカバリ アーカイブ , 5-3 シングル・サインオン中間層 , 1-5 シングル・サインオン中間層（Web サーバー層 DMZ） 概要 , 1-4 事前失効リクエスト , 2-12 推奨トポロジ , 1-3 静的 IP 選択 , 5-4 セキュリティ , 3-2 た データベース接続 接続の監視 , 6-3 動的 IP アドレス 選択 , 5-4 な ネットワーク・パラメータ オリジナル・サーバーでのチューニング , 6-2 は ファイアウォール AJP 用のポートのオープン , 4-5 Enterprise Manager 用のポートのオープン , 4-5 HTTP および HTTPS 用のポートのオープン , 4-5 アプリケーション・サーバーと Infrastructure 用の ポートのオープン , 4-5 アプリケーション・サーバーとアウトバウンド ONS 用のポートのオープン , 4-5 アプリケーション・サーバーとデータベース用の ポートのオープン , 4-5 ポートのオープン , 4-5 複数のシングル・サインオン中間層 HTTP ロード・バランサの構成 , 3-7 mod_osso の再登録 , 3-8 Oracle HTTP Server の構成 , 3-6 構成 , 3-5 識別情報管理インフラストラクチャ・データベース の構成 , 3-7 使用例 , 3-3 部門別トポロジ , 1-10 インストールの順序 , 1-12 拡張 , 1-10 管理上の考慮事項 , 5-7 説明 , 1-10 対象ユーザー , 1-10 プロキシ・サーバー , 4-10 別名定義 サイト定義 , 2-12 複数のホスト名 , 2-12 ポート 管理 , 5-4 ポート・トンネリング 概要 , 4-6 ら リバース・プロキシ・サーバー 構成 , 4-10 ルーター ロード・バランシングの構成 , ループバック NAT での構成 , 4-9 構成手順 , 4-10 4-7 索引 -3 ロード・バランシング・ルーター 複数の中間層の構成 , 4-7 ロギング・レベル 最適化 , 6-3 ログ・ファイル ウォータフォール・アプローチでの管理 , 最大制限 , 5-2 循環 , 5-2 マイニング , 5-5 索引 -4 5-2