プライマリ・コンテンツに移動
Oracle® Fusion Middleware Oracle WebCenter Contentエンタープライズ・デプロイメント・ガイド
11gリリース1 (11.1.1)
B66703-08
  ドキュメント・ライブラリへ移動
ライブラリ
目次へ移動
目次
索引へ移動
索引

前
 
次
 

2 エンタープライズ・デプロイメントの概要

この章では、Oracle WebCenter Contentエンタープライズ・デプロイメントの概要を示します。

この章には次の項が含まれます:

2.1 エンタープライズ・デプロイメント・ガイドについて

エンタープライズ・デプロイメント・ガイドは、Oracle Fusion Middlewareの実証済Oracle高可用性テクノロジ、セキュリティ・テクノロジおよび推奨事項に基づいたベスト・プラクティスの青写真です。この青写真に示すベスト・プラクティスは、Oracle Database、Oracle Fusion Middleware、Oracle ApplicationsおよびOracle Enterprise Manager Fusion Middleware Controlという技術スタック全体にわたるOracle製品を対象にしています。

Oracle Fusion Middlewareエンタープライズ・デプロイメントの特長は、次のとおりです。

  • 様々な業務のサービス・レベル合意(SLA)を考慮して、高可用性ベスト・プラクティスをできるだけ広範囲に適用できるようにします。

  • データベース・グリッド・サーバーと低コストのストレージを使用したストレージ・グリッドを活用し、回復力に優れ低コストのインフラストラクチャを提供します。

  • 様々な構成を対象として広範囲なパフォーマンス影響調査の結果を利用し、ビジネス・ニーズに応じて実行およびスケールできるように高可用性アーキテクチャが最適に構成されます。

  • 停止状態からのリカバリ時間と自然災害時に許容可能なデータ損失量を制御できます。

  • ハードウェアやオペレーティング・システムに依存しない、Oracleのベスト・プラクティスと推奨アーキテクチャを使用します。

高可用性の実現の詳細は、Oracle Technology NetworkのOracle MAAベスト・プラクティスのページ(http://www.oracle.com/technetwork/database/features/availability/maa-best-practices-155366.html)を参照してください。


注意:

このドキュメントではLinux環境におけるエンタープライズ・デプロイメントを中心に説明していますが、エンタープライズ・デプロイメントは、UNIX環境やWindows環境でも実現できます。

2.2 Oracle WebCenter Contentについて

Oracle WebCenter Contentスイート(以前のOracle Enterprise Content Management SuiteまたはOracle ECM)では、ビジネス環境に合せた適切な情報へのシームレスなアクセスを実現する統合コンテンツ管理を利用できます。この手段として、文章や画像、豊富なメディア・ファイルを管理するとともに、Oracle Application Extension Framework (AXF)を介して、エンタープライズ・アプリケーションとの環境統合を実現するための戦略的なコンテンツ・インフラストラクチャを組織によって実装できます。

Oracle WebCenter Contentの主なメリットは次のとおりです。

  • コストの削減: プリント代、輸送費、保管費、維持費を減らします。

  • 効率化: 唯一の正しい情報源、事業プロセスの合理化、より完全かつ高速な情報へのアクセスを実現します。

  • リスクの軽減: 統一性と監査機能の向上、ビジネス・ポリシーおよびビジネス・ルールの遵守、コンテンツの確実な保護、ブランド管理の強化を実現します。

  • 価値の創造: ビジネスの敏捷性を向上させるほか、クロスセリングとアップセリングの向上やチャネルの確保、顧客関係の向上によって売上を最適化します。

このガイドの参照用エンタープライズ・デプロイメント・トポロジには、Oracle WebCenter Contentの次の機能セットが含まれています。

Oracle WebCenter Content

WebCenter Content(以前のOracle Universal Content ManagementまたはOracle UCM)にはOracle WebCenter Content Serverが含まれています。WebCenter Contentが提供する統一リポジトリを使用すると、構造化されていないコンテンツを格納し、そのコンテンツをビジネス・ユーザーに配信できます。この配信は適切なフォーマットで行われ、またビジネス・ユーザーの業務に親和性の高いアプリケーションのコンテキスト内で行われます。

コンテンツ・サーバーがデフォルトで使用するネイティブの11gユーザー・インタフェース以外にも、WebCenter Contentユーザー・インタフェースを使用してコンテンツ・サーバーを構成できます。WebCenter Contentユーザー・インタフェースの詳細は、第15章「WebCenter Contentユーザー・インタフェースのインストールおよび構成」を参照してください。

Oracle WebCenter Content: Imaging

Imaging(以前のOracle Imaging and Process ManagementまたはOracle I/PM)は、最も包括的で、統合された、コスト・パフォーマンスの高いイメージング・プラットフォームで、エンタープライズ・ビジネス・プロセス内でのドキュメント・イメージをエンドツーエンドで管理できます。高機能なデータ・キャプチャにはOracle WebCenter Forms Recognitionを、LOBの編成やプロセス・コラボレーションにはAXFを、またイメージのキャプチャにはOracle WebCenter Enterprise Captureを活用します。また、イメージの注釈付けとマークアップ、ルーティングと承認の自動化などの機能を提供するほか、エンタープライズ用アプリケーションをサポートするスケーラブルなリポジトリを提供します。組織では、Imagingを使用して、Oracleやサード・パーティのエンタープライズ・アプリケーション内でビジネス・プロセスを迅速に自動化できます。

Oracle WebCenter Content: Inbound Refinery

Inbound Refineryは、ドキュメント、デジタル・イメージ、動画などの電子アセット用のファイル変換を管理する変換サーバーです。変換機能の他に、Inbound Refineryでは、ドキュメントとイメージに対するサムネイル機能、ビデオのストーリーボード作成機能、デジタル・イメージからEXIFデータを抽出して使用する機能、およびAdobe PhotoshopやAdobe Illustratorなどのプログラムから生成された電子ファイルからXMPデータを抽出して使用する機能があります。組織では、Inbound Refineryを使用して、Oracle WebCenter Content Serverに格納されているコンテンツ項目を変換できます。

Oracle WebCenter Enterprise Capture

Captureは、集中型企業環境にも分散型企業環境にも適した拡張性の高いドキュメント・キャプチャを提供します。Oracle WebCenter Content: ImagingおよびOracle WebCenter Contentと完全に統合されているため、きわめて重要なビジネス・コンテンツのキャプチャ、保存、管理、取得が1つのシステムで可能になります。

Oracle WebCenter Enterprise Captureには、インターネットや企業内のイントラネットを利用してリモート・ロケーションで実行可能なスキャン機能やオプションの索引付け機能があります。Captureでイメージをスキャンすると、ローカル・マシンにイメージがコピーされます。そのイメージのバッチを解放するまでは、ローカル・マシンでイメージを表示できます。その後、それらのイメージはサーバーに移動します。バッチのスキャン後、必要に応じた方法でドキュメントを編成します。ドキュメントはCaptureにインポート可能です。スキャナからドキュメントをインポートし、他のソースからアイテムを追加したら、索引を追加します。

2.3 エンタープライズ・デプロイメントの用語

このエンタープライズ・デプロイメント・ガイドで使用される用語は次のとおりです。

  • クラスタ・エージェント: ハードウェア・クラスタのノード・メンバー上で実行されるソフトウェアで、可用性とパフォーマンスの操作を他のノードと協調させます。クラスタウェアによりリソースのグループ化と監視を行い、サービスを移行できます。クラスタ・エージェントではサービスのフェイルオーバーを自動化できます。

  • クラスタウェア: クラスタ・メンバーの処理を1つのシステムとして管理するソフトウェアです。リソースとサービスのセットを定義してから、ハートビートのメカニズムにより複数のクラスタ・メンバー間において監視を行い、これらのリソースとサービスを別のクラスタ・メンバーにできるだけ効率的かつ透過的に移動できます。

  • フェイルバック: システムのフェイルオーバー操作が正常に終了した後は、最初に障害を起こしたメンバーは修復され、スタンバイ・メンバーとしてシステムに再導入されます。必要に応じて、フェイルバック処理を開始して、このメンバーをアクティブにし、別のメンバーを非アクティブにすることができます。このプロセスにより、システムは障害発生前の構成に戻ります。

  • フェイルオーバー: 高可用性システムの一部に予期しない障害(計画外停止)が発生した場合に、コンシューマへのサービス提供を継続する目的で、他の利用可能なシステムを使用してロードを実行します。システムがアクティブ/パッシブ型システムの場合、パッシブ・メンバーはフェイルオーバー操作においてアクティブになります。そしてコンシューマは、障害が発生したメンバーではなく、アクティブになったメンバーにダイレクトされます。フェイルオーバー操作は、手動でも実行できます。また、障害を検出した場合にクラスタのリソースを障害ノードからスタンバイ・ノードに移動するように、ハードウェア・クラスタ・サービスを設定することで、フェイルオーバー操作を自動化することもできます。システムがアクティブ/アクティブ型システムの場合、ロード・バランサのエンティティによりフェイルオーバーが実行されます。このエンティティによって、リクエストがアクティブ・メンバーで処理されます。アクティブ・メンバーに障害が発生すると、ロード・バランサにより障害が検出され、障害メンバーへのリクエストが、正常に動作しているアクティブ・メンバーに自動的にリダイレクトされます。アクティブ/アクティブ型システムとアクティブ/パッシブ型システムの詳細は、『Oracle Fusion Middleware高可用性ガイド』を参照してください。

  • ハードウェア・クラスタ: ハードウェア・クラスタとはコンピュータの集まりであり、ネットワーク・サービス(例: IPアドレス)またはアプリケーション・サービス(例: データベース、Webサーバー)のシングル・ビューをこれらのサービスのクライアントに提供します。ハードウェア・クラスタの各ノードは、それぞれ固有のプロセスを実行するスタンドアロン・サーバーです。これらのプロセスは互いに通信して、単一のシステムであるかのように動作して、アプリケーション、システム・リソースおよびデータを連携してユーザーに提供できます。

    特別なハードウェア(クラスタ・インターコネクト、共有記憶域)とソフトウェア(ヘルス・モニター、リソース・モニター)を使用することで、ハードウェア・クラスタにより高可用性とスケーラビリティが実現されます。クラスタ・インターコネクトは、ハートビート情報がノードの停止を検出する際にハードウェア・クラスタで使用されるプライベート・リンクです。専用のハードウェアとソフトウェアが要求されるため、通常、ハードウェア・クラスタは、Oracle社、HP社、IBM社、Dell社などのハードウェア・ベンダーによって提供されます。1つのハードウェア・クラスタ内で構成可能なノード数は、ベンダーによって異なりますが、Oracle Fusion Middlewareの高可用性では2つのノードのみを必要とします。そのため、このドキュメントでは、2つのノードを持つハードウェア・クラスタを高可用性ソリューションで使用することを想定しています。

  • Middlewareホーム: Middlewareホームは、Oracle WebLogic Serverホーム、および場合によっては1つ以上のOracleホームで構成されています。ミドルウェア・ホームは、ローカル・ファイル・システムに配置できますし、NFSを介してアクセス可能なリモート共有ディスクにも配置できます。

  • ネットワーク・ホスト名: ネットワーク・ホスト名は、/etc/hostsファイルまたはDNS解決のいずれかを使用してIPアドレスに割り当てられる名前です。この名前は、参照先マシンに接続する際にネットワークで参照可能です。ネットワーク・ホスト名と物理ホスト名が同一である場合があります。ただし、各マシンには物理ホスト名は1つのみ付与されますが、ネットワーク・ホスト名は複数付与される場合があります。そのため、マシンのネットワーク・ホスト名はその物理ホスト名であるとはかぎりません。

  • Oracle共通ホーム: Oracle Enterprise Manager Fusion Middleware ControlおよびJava Required Files (JRF)に必要なバイナリおよびライブラリ・ファイルが格納されるOracleホームです。

  • Oracleホーム: Oracleホームには、特定の製品をホストするために必要なファイルがインストールされ格納されています。たとえば、SOAのOracleホームには、Oracle SOA Suiteのバイナリとライブラリ・ファイルが格納されているディレクトリがあります。Oracleホームは、ミドルウェア・ホームのディレクトリ構造の内部にあります。各Oracleホームは、複数のOracleインスタンスやOracle WebLogic Serverドメインと関連付けることができます。

  • Oracleインスタンス: Oracleインスタンスには、アクティブなミドルウェア・システム・コンポーネントが1つ以上あります。コンポーネントの例には、Oracle Web Cache、Oracle HTTP Server、Oracle Internet Directoryなどがあります。インストール時かその後でインスタンスの作成と構成を行うときに、インスタンスにどのコンポーネントを含めるかを決定します。Oracleインスタンスには、更新可能なファイルがあります。それらのファイルの例には、構成ファイル、ログ・ファイル、一時ファイルなどがあります。

  • 物理ホスト名: このガイドでは、物理ホスト名ネットワーク・ホスト名を区別しています。このガイドでは、物理ホスト名を使用して、現在のマシンの内部名を参照します。UNIXシステムでは、hostnameコマンドにより返される名前です。

    Oracle Fusion Middlewareで使用される物理ホスト名は、ローカル・ホストを示します。インストール中に、インストーラでは物理ホスト名が現在のマシンから自動的に取得され、ディスク上のOracle Fusion Middleware構成メタデータに格納されます。

  • 物理IPアドレス: 物理IPアドレスは、ネットワーク上のマシンのIPアドレスです。ほとんどの場合、マシンの物理ホスト名と関連付けられます(物理ホスト名に関する定義を参照)。仮想IPアドレスとは対照的に、物理IPアドレスは、マシンがネットワークに接続されると、必ず同じマシンと関連付けられます。

  • 1次ノード: Oracle Fusion Middlewareインスタンスを常時アクティブな状態で実行しているノードで、バックアップまたは2次ノードを所有するように構成されています。1次ノードに障害が発生すると、Oracle Fusion Middlewareインスタンスでは2次ノードにフェイルオーバーされます。このフェイルオーバーは手動でも実行できますし、管理サーバー用のクラスタウェアを使用して自動的に実行できます。サーバー移行機能に基づいたシナリオでは、WebLogic Whole Server移行機能が自動化フェイルオーバーに使用されています。

  • 2次ノード: Oracle Fusion Middlewareインスタンス用のバックアップ・ノードです。プライマリ・ノードが使用できなくなると、アクティブなインスタンスでフェイルオーバーが実行されます。前述の1次ノードに関する定義を参照してください。

  • 共有記憶域: エンタープライズ・デプロイメント・ドメイン内のすべてのマシンがアクセスできる記憶域のサブシステムです。共有ディスクには特に次のものが配置されています。

    • ミドルウェア・ホームのソフトウェア

    • AdminServerドメイン・ホーム

    • JMS

    • Tlogs(該当する場合)

    WebCenter ContentまたはInbound Refineryの管理対象サーバーを除いて、管理対象サーバー・ホームは共有ディスクにも配置できます。共有記憶域は、Network Attached Storage (NAS)またはStorage Area Network (SAN)にすることができます。また、複数のノードが同時にアクセスして読込みと書込みができる他のストレージ・システムにすることもできます。

  • スイッチバック: スイッチオーバー操作の実行時に、メンテナンスまたはアップグレードのためにシステムのメンバーは非アクティブ化されます。メンテナンスやアップグレードが完了すると、システムでスイッチバック処理を実行して、アップグレードしたメンバーをアクティブ化し、スイッチオーバー前の構成にシステムを戻すことがきます。

  • スイッチオーバー: 通常の操作では、システムのアクティブ・メンバーでメンテナンスやアップグレードが必要になることがあります。スイッチオーバー処理を開始して、メンテナンスやアップグレード(計画停止中に実施)が必要なメンバーが処理していたワークロードを、代替メンバーが引き継ぐことができます。スイッチオーバー操作により、システムのコンシューマに対してサービスが続行できるようになります。

  • 仮想ホスト名: 仮想ホスト名は、ネットワーク・アドレス指定が可能なホスト名で、ロード・バランサやハードウェア・クラスタを使用して1台または複数の物理マシンにマップされます。ロード・バランサでは、仮想サーバー名という用語はこのマニュアルでの仮想ホスト名と同じ意味で使用されます。複数のサーバーのセットを代表する仮想ホスト名をロード・バランサに付与でき、クライアントは仮想ホスト名を使用して、間接的にマシンと通信します。ハードウェア・クラスタの仮想ホスト名は、クラスタの仮想IPアドレスに割り当てられるネットワーク・ホスト名です。仮想IPは、クラスタ内の特定ノードに永続的に付与されないため、仮想ホスト名も特定ノードに永続的に付与されません。


    注意:

    このドキュメントで仮想ホスト名という用語を使用する場合は、常にそれが仮想IPアドレスに関連付けられることを前提とします。単にIPアドレスを必要とする場合または使用する場合には、明示的に記載します。

  • 仮想IPアドレス: クラスタ仮想IPアドレスロード・バランサ仮想IPアドレスとも言います。一般的に、仮想IPアドレスはハードウェア・クラスタやロード・バランサに割り当てることができます。クラスタにおいて単一のシステム・ビューをネットワーク・クライアントに対して実現するために、クラスタのメンバーであるサーバー・グループに対して仮想IPアドレスはエントリ・ポイントのIPアドレスとして機能します。

    ハードウェア・クラスタではクラスタの仮想IPアドレスが使用され、外部の世界に対してクラスタへのエントリ・ポイントを実現します。(クラスタの仮想IPアドレスは、スタンドアロンのコンピュータ上にも構成できます。)ハードウェア・クラスタのソフトウェアにより、クラスタにある2台の物理ノード間においてこのIPアドレスの変更が管理されますが、クライアントはこのIPアドレスに接続します。その際、このIPアドレスが現在アクティブである物理ノードを判別する必要はありません。2台のノードによる標準的構成では、各マシンには固有の物理IPアドレスと物理ホスト名が付与されながら、数個のクラスタIPアドレスを付与することもできます。これらのクラスタIPアドレスは、2台のノードおいて切り替わります。クラスタIPアドレスを現在所有しているノードは、そのアドレスでアクティブになります。

    また、ロード・バランサも一連のサーバーのエントリ・ポイントとして仮想IPアドレスを使用します。これらのサーバーは、同時にアクティブになる傾向があります。この仮想IPアドレスは個々のサーバーには割り当てられませんが、サーバーとクライアントとの間においてプロキシとして動作するロード・バランサに割り当てられます。

  • WebLogic Serverホーム: WebLogic Serverホームには、WebLogic Serverをホストするために必要なインストール済のファイルが格納されています。WebLogic Serverホームのディレクトリは、Oracleホームのディレクトリのピアで、ミドルウェア・ホームのディレクトリ構造の内部にあります。

2.4 Oracle推奨事項のメリット

このガイドで説明するOracle Fusion Middleware構成では、すべての起動でセキュリティが確保され、ハードウェア・リソースが最大化され、様々なアプリケーションを使用したエンタープライズ・コンピューティングのために、信頼性が高く、標準に準拠したシステムを提供するために設計されています。

Oracle Fusion Middleware構成のセキュリティと高可用性のメリットは、次の項で説明するように、ファイアウォール・ゾーンの分離とソフトウェア・コンポーネントのレプリケーションを通じて実現されます。

2.4.1 組込みセキュリティ

エンタープライズ・デプロイメント・アーキテクチャのセキュリティを確保するためには、ソフトウェア・コンポーネントのすべての機能グループを各グループ固有のDMZで分離し、すべてのトラフィックをプロトコルとポートによって制限します。次の特長により、必要なレベルのすべてのセキュリティが確保され、高レベルの標準の準拠が実現します。

  • ポート80で受信した外部通信はすべてポート443にリダイレクトするように、外部のロード・バランサを構成します。

  • 外部クライアントからの通信は、必ずロード・バランシング・ルーター(LBR)を経由します。

  • ロード・バランシング・ルーターからデータ層への直接的な通信は許可されません。

  • コンポーネントは、Oracle Web層、アプリケーション層およびデータ層の異なる保護ゾーンで分離されています。

  • 一度に2つのファイアウォールをまたがる直接的な通信は禁止されています。

  • あるファイアウォール・ゾーンで開始された通信は、次のファイアウォール・ゾーンで必ず終了します。

  • Oracle Internet Directoryはデータ層内で独立しています。

  • Oracle Identity Managementコンポーネントは別のサブネットにあります。

  • 複数の保護ゾーンにおいて複数のコンポーネント間の通信はすべて、ファイアウォールのルールに従いポートとプロトコルによって制限されます。

2.4.2 高可用性

各コンポーネントまたはソフトウェア・コンポーネントの機能グループが別のコンピュータにレプリケートされており、コンポーネント・レベルでの高可用性を実現するように構成されます。このため、エンタープライズ・デプロイメント・アーキテクチャでは高い可用性が実現されます。