| Oracle Fusion Middlewareコンセプト・ガイド 11gリリース1（11.1.1） B55897-02 |
|
 戻る |
 次へ |
この章では、Oracle Fusion Middlewareの管理について説明します。この章の内容は次のとおりです。
エンタープライズ・デプロイメントは、オラクル社の実績のある高可用性テクノロジおよびOracle Fusion Middlewareのリコメンデーションに基づいたベスト・プラクティスの青写真です。高可用性に対するベスト・プラクティスには、テクノロジ・スタック全体にわたるOracle製品すべて（Oracle Database、Oracle Fusion Middleware、Oracle Applications、Oracle Collaboration SuiteおよびOracle Grid Control）が含まれます。
Oracle Fusion Middlewareエンタープライズ・デプロイメントの機能は次のとおりです。
様々なビジネス上のサービス・レベル合意（SLA）を考慮し、高可用性に対するベスト・プラクティスを可能なかぎり広範囲に適用できるようにします。
データベースのグリッド・サーバーおよび低コスト・ストレージに基づくストレージ・グリッドを活用し、レジリエンスの高い低コストのインフラストラクチャを提供します。
様々な構成に対する広範なパフォーマンス影響調査の結果を利用し、最適な高可用性アーキテクチャを構成して、実行およびビジネス・ニーズに合せたスケール変更を可能にします。
障害からのリカバリに要する時間と自然災害時のデータ損失許容量を制御できます。
各Oracleリリースに伴って進化し、ハードウェアおよびオペレーティング・システムからは完全に独立しています。
エンタープライズ・デプロイメントの詳細は、次のガイドを参照してください。
『Oracle Fusion Middleware Oracle WebCenterエンタープライズ・デプロイメント・ガイド』
『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』
『Oracle Fusion Middleware高可用性ガイド』
http://www.oracle.com/technology/deploy/availability/htdocs/maa.htm
Oracle Fusion Middleware環境は、次のいずれかの管理ツールを使用して管理します。
Oracle Enterprise Manager Fusion Middleware Control（Fusion Middleware Control）は、ファームやクラスタの監視および管理に使用できるWebブラウザベースのグラフィカル・ユーザー・インタフェースです。
ファームとは、Fusion Middleware Controlによって管理されるコンポーネントの集まりです。これには、複数のOracle WebLogic Serverドメイン、1つの管理サーバー、1つ以上の管理対象サーバー、複数のクラスタ、およびドメインにインストールおよび構成され、ここで実行されているOracle Fusion Middlewareコンポーネントが含まれます。
Fusion Middleware Controlでは、様々なパフォーマンス・データおよび管理機能を、ファーム、クラスタ、ドメイン、サーバー、コンポーネントおよびアプリケーションの個別のWebベースのホームページに編成します。Fusion Middleware Controlのホームページでは、最も重要な監視データや最も頻繁に使用される管理機能を、すべて各自のWebブラウザから容易に検索することができます。
Fusion Middleware Controlでは、Oracle WebLogic Server管理コンソールに直接アクセスすることができます。Fusion Middleware ControlインタフェースのWebページには、管理コンソールにアクセスできるリンクが含まれています。たとえば｢ドメイン」ホームページで「概要」領域に移動すると、ドメインを構成および管理するための管理コンソールへのリンクがあります。
詳細は、Oracle Fusion Middlewareの管理者ガイドの「Oracle Enterprise Manager Fusion Middleware Controlの使用の概要」を参照してください。
Oracle WebLogic Server管理コンソールは、Oracle WebLogic Serverドメインの管理に使用できるWebブラウザベースのグラフィカル・ユーザー・インタフェースです。これは、管理サーバーへのネットワーク・アクセスが可能なサポートされている任意のWebブラウザからアクセスできます。
管理コンソールを使用すると次のことが可能です。
Oracle WebLogic Serverインスタンスの構成、起動、および停止
Oracle WebLogic Serverクラスタの構成
データベース接続（JDBC）やJMSメッセージングなど、Oracle WebLogic Serverサービスの構成
ユーザー、グループ、ロールの作成および管理を含む、セキュリティ・パラメータの構成
Java EEアプリケーションの構成およびデプロイ
サーバーおよびアプリケーションのパフォーマンス監視
サーバーおよびドメインのログ・ファイルの表示
アプリケーションのデプロイメント・ディスクリプタの表示
選択したランタイム・アプリケーションのデプロイメント・ディスクリプタ要素の編集
詳細は、Oracle Fusion Middlewareの管理者ガイドの「Oracle WebLogic Server管理コンソールの使用の概要」を参照してください。
Oracle WebLogic Scripting Tool（WLST）は、Oracle WebLogic Serverドメインの作成、管理、および監視に使用できる、コマンドラインのスクリプト作成環境です。これは、Javaのスクリプト作成インタプリタであるJythonに基づいています。ローカル変数、条件変数、フロー制御文など、標準のJython機能のサポートに加え、WLSTでは、Oracle WebLogic Serverに固有なスクリプト作成機能（コマンド）一式を提供しています。Jython言語構文に従って、ニーズに合うようWebLogicのスクリプト作成言語を拡張できます。
次のいずれかの方法を使用して、WLSTコマンドを起動できます。
コマンドラインでの対話的な起動
スクリプト・モードでのファイルへの指定
Javaコードへの埋込み
詳細は、『Oracle Fusion Middleware管理者ガイド』の「WebLogic Scripting Tool（WLST）の使用の概要」を参照してください。
WebLogic Scripting Toolの詳細は、『Oracle Fusion Middleware WebLogic Scripting Tool Command Reference』を参照してください。
Oracle Process Manager and Notification Server（OPMN）は、システム・コンポーネントと呼ばれる次のOracle Fusion Middlewareコンポーネントを管理および監視します。
Oracle HTTP Server
Oracle Web Cache
Oracle Internet Directory
Oracle Virtual Directory
Oracle Forms Services
Oracle Reports
Oracle Business Intelligence Discoverer
Oracle Business Intelligence
詳細は、Oracle Fusion Middlewareの管理者ガイドの「Oracle Process Manager and Notification Serverの使用の概要」を参照してください。
Oracle Enterprise Manager Grid Controlは、複数のOracle Fusion MiddlewareファームおよびOracle WebLogic Serverドメインの監視に使用できるWebブラウザベースのグラフィカル・ユーザー・インタフェースです。実際、Grid Controlでは、Oracleパッケージ・ソリューション、Oracle DatabaseおよびOracle VMなどのOracleテクノロジに対して詳細な管理ソリューションを提供しています。また、Grid Controlは、Microsoft MOM、IBM WebSphere、JBoss、EMCストレージ、F5 BIG IP、Check Point Firewall、Remedyなど、24を超える異機種管理プラグインおよびコネクタにより、Oracle以外のテクノロジに対しても幅広くサポートします。
Grid Controlでは、単一インタフェースからのデータ・センター全体の管理以外にも、Oracle Fusion MiddlewareおよびOracle WebLogic Serverのより効率的な管理を支援する重要な機能を提供しています。このようなその他の管理機能には、次のものがあります。
収集した可用性データおよびパフォーマンス・データに基づいて傾向を分析し、レポートします。
事前定義したしきい値を超えたメトリックに対するアラート通知を（電子メール、ページ、SNMPを介して）受け取ります。
一般的な管理操作（起動および停止、WLSTスクリプトなど）を自動化します。
すべてのJavaアクティビティ（インフライト・トランザクションを含む）に対する表示機能や、JavaからデータベースおよびデータベースからJavaへのトランザクションのトレースにより、迅速に問題を解決します。
許可済および未許可の構成変更をリアルタイムで検出、検証、およびレポートします。
開発環境と本番環境間での構成の一貫性を確保します。
Oracle Enterprise Manager Grid Controlの詳細は、OTNより入手可能なOracle Enterprise Manager Grid Controlコンセプト・ガイドを参照してください。
スケーラビリティとは、使用可能なハードウェア・リソースに応じたスループットを提供する、システムの能力のことです。スケーラビリティは、システムのハードウェア・リソースにのみ制限されます。スケーラブルなシステムとは、レスポンス時間とスループットに悪影響を与えずに、リクエストの増加を処理するシステムです。
1つのオペレーティング環境内の計算能力を高めることを、垂直スケーリングと呼びます。水平スケーリングでは、複数のシステムを活用して、1つの共通の問題を並列処理します。
Oracle Fusion Middlewareでは、垂直と水平の両方でスケーリングを行います。水平スケーリングの場合、Oracle Fusion Middlewareでは、ワークロードを共有するためにグループ化されたいくつかの管理対象サーバーで、スループットを増やすことができます。また、Oracle Fusion Middlewareは垂直スケーラビリティが優れているため、同じノードにより多くの管理対象サーバーおよびコンポーネントを追加できます。
高可用性とは、ユーザーがシステムにアクセスできる能力です。高可用性システムのデプロイメントにより、システムが停止している（使用できない）時間が最小化され、稼働している（使用できる）時間が最大化されます。Oracle Fusion Middlewareは、ロード・バランシングや基本的なクラスタリングから、壊滅的なハードウェアおよびソフトウェア障害時に最大のシステム可用性を実現する機能まで、多種多様な高可用性ソリューションの提供を目的として設計されています。
高可用性ソリューションは、ローカル高可用性および障害時リカバリという2つの基本的なカテゴリに分けられます。
高可用性の詳細は、『Oracle Fusion Middleware高可用性ガイド』を参照してください。
高可用性アーキテクチャは、エンタープライズ・デプロイメントの主要な要件の1つです。Oracle Fusion Middlewareには、広範な一連の高可用性機能が用意されており、これによりそのコンポーネントおよびアプリケーションでの計画外の停止時間の発生を防ぎ、計画的な停止時間を最小限に抑えて、ビジネス上の目標を達成することができます。
高可用性とは、サービスが損失することなく、ユーザーがシステムにアクセスできる能力です。高可用性システムのデプロイメントにより、システムが停止している（使用できない）時間が最小化され、稼働している（使用できる）時間が最大化されます。この項では、問題解決の視点から、高可用性の概要について説明します。この項の内容は次のとおりです。
ミッション・クリティカルなコンピュータ・システムでは、1日24時間、週7日、1年間365日使用可能である必要があります。しかし、システムの一部または全体で、計画的または計画外の停止時間が発生する可能性があります。システムの可用性は、デプロイ後の合計時間のうち、サービスを提供している時間のパーセンテージで評価されます。表4-1に例を示します。
表4-1 可用性のパーセンテージと対応する停止時間の値
| 可用性のパーセンテージ | 1年当たりのおおよその停止時間 |
|---|---|
|
95% |
18日 |
|
99% |
4日 |
|
99.9% |
9時間 |
|
99.99% |
1時間 |
|
99.999% |
5分 |
システム停止時間は、計画的なものと計画外のものに分類できます。計画外の停止時間はなんらかの予期しない障害です。計画的な停止時間とは、あらかじめ知らされている、システムが使用不可となるスケジュール済の操作です。一般的に、システム・トラフィックが少ない時間に操作ウィンドウをスケジュールすることにより、計画的な停止時間のエンド・ユーザーへの影響は最小化されます。計画外の停止時間は、ピーク時に発生する場合もあるため、影響が大きくなります。システム・ユーザーにも大きな影響を与えます。
システムの可用性要件を設計する際、この2種類の停止時間（計画的、計画外）は、通常分離して考えられます。システムのニーズは、計画外の停止時間に関しては非常に厳しく、計画的な停止時間に関しては非常に柔軟である可能性があります。これは、就業時間中は最大負荷が大きくなり、夜間および週末には事実上非アクティブのままとなるアプリケーションの場合に、よくあるケースです。対処する障害のタイプによって、異なる高可用性機能を選択することもできます。
高可用性ソリューションは、単一のデータ・センター・デプロイメントで高可用性を提供するローカル高可用性ソリューションと、通常洪水や地域的なネットワークの停止などの災害からアプリケーションを保護するために地理的に分散してデプロイメントされる障害時リカバリ・ソリューションに分類されます。
考えられる障害のタイプの中で、プロセス、ノード、およびメディアの障害と人為的なエラーに対しては、ローカル高可用性ソリューションで保護できます。データ・センター全体に影響を及ぼすローカルな物理的災害に対しては、地理的に分散された障害時リカバリ・ソリューションで保護できます。
高可用性の問題を解決するには、多くのテクノロジおよびベスト・プラクティスが必要です。最も重要なメカニズムは冗長性です。高可用性は、冗長なシステムおよびコンポーネントから生じます。ローカル高可用性ソリューションは、その冗長性レベルにより、アクティブ/アクティブ・ソリューションとアクティブ/パッシブ・ソリューションに分類できます（図4-1を参照）。
アクティブ/アクティブ・ソリューションは、複数のアクティブなシステムのインスタンスをデプロイし、スケーラビリティの向上のほか、高可用性の提供に使用することができます。アクティブ/アクティブのデプロイメントでは、すべてのインスタンスが同時にリクエストを処理します。
アクティブ/パッシブ・ソリューションでは、リクエストを処理するアクティブ・インスタンスと、スタンバイ状態のパッシブ・インスタンスをデプロイします。また、これら2つのインスタンス間には、ハートビート・メカニズムが設定されます。このメカニズムは、オペレーティング・システム・ベンダー固有のクラスタウェアで提供および管理されます。一般に、ベンダー固有のクラスタ・エージェントは、クラスタ・ノード間の自動監視およびフェイルオーバーも可能であり、アクティブ・インスタンスに障害が発生すると、エージェントがアクティブ・インスタンスを完全にシャットダウンしてパッシブ・インスタンスを起動することで、アプリケーション・サービスは無事に処理を再開することができます。この結果、アクティブとパッシブのロールが切り替わります。計画的な停止時間でも計画外の停止時間でも、手動で同じ手順を実行できます。アクティブ/パッシブ・ソリューションは、一般的にコールド・フェイルオーバー・クラスタとも呼ばれます。
Fusion Middlewareアクティブ/パッシブ（CFC）ソリューションは、Oracle Cluster Ready Services（CRS）を使用して管理できます。
包括的な高可用性システムには、アーキテクチャの冗長性に加え、次のローカル高可用性テクノロジも必要です。
構成やソフトウェアに障害が発生したため、予期しないときにプロセスが停止する場合があります。適切なプロセス監視および再起動システムがあると、すべてのシステム・プロセスが常時監視され、障害がある場合はそれらが再起動されます。
システム・プロセスは、指定された時間間隔内での再起動の数を維持することも必要です。短時間に継続的に再起動を行うと、さらに障害が発生する場合もあるため、この点も重要です。したがって、指定された時間間隔内での再起動または再試行の最大数も設計する必要があります。
システムのコンポーネントをまとめてクラスタリングすると、ランタイム処理および管理性に対し、それらのコンポーネントを機能的に1つの実体としてクライアントに認識させることができます。クラスタは、1つのコンピュータ、または同じワークロードを共有する複数のコンピュータ上で実行される一連のプロセスです。クラスタリングと冗長性の間には密接な関係があります。クラスタによって、システムに対する冗長性が提供されます。
クラスタ環境でトランザクション中にフェイルオーバーが発生した場合、クラスタ内で障害の発生していないインスタンスが1つ以上使用可能であれば、セッション・データは保持されます。
ステートフル・アプリケーションでは、これらのリクエストを処理するプロセスに障害が発生した場合に、クライアントの状態がレプリケートされてリクエストのステートフル・フェイルオーバーが行われます。
ロード・バランシング・メカニズムが整備されていると、インスタンスは冗長になります。いずれかのインスタンスに障害が発生した場合、そのインスタンスに対するリクエストを、障害の発生していないインスタンスに送信できます。
同じサーバー・コンポーネントの複数のインスタンスを使用できる場合、これらのコンポーネントに対するクライアント・リクエストは、各インスタンスのワークロードがほぼ同一になるようにロード・バランシングされます。
サービスによっては、特定の時点で実行できるインスタンスが1つのみである場合があります。そのアクティブ・インスタンスが使用できなくなると、サービスは自動的に別のクラスタ・メンバーで開始されます。かわりに、サーバー・プロセス全体をクラスタ内の別のマシンで自動的に開始することもできます。
コンポーネントは別のコンポーネントに依存してサービスを提供します。このようなコンポーネントは、サービスを中断させることなく、依存するコンポーネントの障害からリカバリできる必要があります。
製品のバイナリ・ファイルにパッチを適用するには、多くの場合、停止時間が生じます。回転式で稼働中のクラスタにパッチを適用すると、停止を回避できます。回転式でもパッチをアンインストールすることができます。
構成管理
類似したコンポーネントを1つのグループにクラスタリングすると、多くの場合、共通の構成を共有する必要があります。適切な構成管理によって、コンポーネントは同じ着信リクエストに対して同じ応答を返し、コンポーネントの構成の同期化が可能になり、管理目的の停止時間を短縮する可用性の高い構成管理を実現できます。
ユーザー・エラーによってシステムが誤作動することもあります。状況によっては、コンポーネントまたはシステムの障害を修復できないこともあります。一定の間隔でシステムをバックアップし、障害が発生した場合にバックアップをリストアできるように、バックアップおよびリカバリの機能を用意しておく必要があります。
障害時リカバリ・ソリューションでは通常、2つの同種のサイト（1つはアクティブ・サイト、もう1つはパッシブ・サイト）を設定します。サイトはそれぞれが自己完結型のシステムです。一般的に、アクティブ・サイトを本番サイト、パッシブ・サイトをスタンバイ・サイトと呼びます。通常の運用では、本番サイトがリクエストを処理します。サイトでフェイルオーバーやスイッチオーバーが発生すると、スタンバイ・サイトが本番ロールを引き継ぎ、すべてのリクエストはそのサイトにルーティングされます。フェイルオーバーのためにスタンバイ・サイトを保持するには、スタンバイ・サイトに同種のインストールとアプリケーションを含めるだけでなく、データと構成を本番サイトからスタンバイ・サイトに常時同期化する必要もあります。
オリジナル・サーバーのロード・バランシングは、HTTPリクエストが複数のオリジナル・サーバーに分散され、どのオリジナル・サーバーもオーバーロード状態にならないようにする機能です。
Oracle Web Cacheでは、アプリケーションのWebサーバーのロード・バランシングおよびフェイルオーバー検出をサポートしています。
Oracle Web Cacheにより、キャッシュ・ミスは、サーバー・ファーム内で最も可用性の高い、最高パフォーマンスのWebサーバーに確実に転送されます。容量の経験則により、パフォーマンスが保証され、アプリケーションのWebサーバーの負荷が増加したときにサージ保護が行われます。
ロード・バランシングおよびフェイルオーバーの詳細は、Oracle Fusion Middleware Oracle Web Cache管理者ガイドを参照してください。
Oracle Fusion Middlewareコンポーネントは、起動およびシャットダウンの情報、エラー、警告メッセージ、HTTPリクエストのアクセス情報など、あらゆるタイプのイベントを記録するメッセージを含むログ・ファイルを生成します。この章では、エラーの原因と是正措置に関する情報の検索方法、システム・アクティビティの監視を支援するためのログ・ファイルの表示および管理方法、問題の診断方法について説明します。
詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。
クローニングとは、既存のエンティティの状態を保存しつつ、このエンティティを別のロケーションにコピーするプロセスです。Oracle Fusion Middlewareのクローニングが有用となるいくつかの状況を次に示します。
本番環境、テスト環境、または開発環境のコピーであるMiddlewareホームまたはOracleホームを作成する。クローニングにより、1回のステップですべてのパッチを適用した新しいMiddlewareホームまたはOracleホームを作成できます。これは、個々のOracleホームへのパッチの個別インストール、構成、および適用とは対照的です。
パッチが適用されたホームのゴールド・イメージを用意し、これを多くのホストにデプロイする。
クローニングされたエンティティは、ソース・エンティティと同様に動作します。たとえば、クローニングされたOracleホームは、インストーラを使用して削除またはパッチ適用することができます。これは、別のクローニング操作のソースとして使用することもできます。
クローニングの詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。
Oracle Real Application Clusters（Oracle RAC）とは、複数の相互接続されたコンピュータの処理能力を利用したコンピューティング環境です。クラスタと呼ばれるハードウェアの集まりとともに、Oracle RACは各コンポーネントの処理能力を一体化させ、1つの堅牢なコンピューティング環境にします。クラスタは、ノードとも呼ばれる複数のコンピュータで構成されます。Oracle Real Application Clustersは同時に、Oracle Fusion Middlewareに対して、スケーラビリティおよび可用性の高いデータベースを提供します。
クラスタ内のすべてのOracle RACインスタンスは、同じアクセス権および認可レベルを持ちます。したがって、ノードおよびインスタンスに障害が発生しても、障害が発生していないサーバー・インスタンスでデータベース・サービスが利用可能であるか、利用可能な状態にすることができるため、パフォーマンスに影響を及ぼす場合はありますが、停止することはありません。
Oracle Real Application Clustersの詳細は、『Oracle Fusion Middleware高可用性ガイド』を参照してください。
Oracle Fusion Middleware環境は様々なコンポーネントおよび構成から成り立ちます。一般的なOracle Fusion Middleware環境には、Oracle SOA SuiteなどのJavaコンポーネントのあるOracle WebLogic Serverドメイン、およびOracle Identity ManagementコンポーネントのあるOracle WebLogic Serverドメインが含まれます。1つ以上のOracleインスタンスを含むこともできます。
Oracle Fusion Middleware環境のインストールは相互依存的で、ここには、同期化された状態の構成情報、アプリケーション、およびデータが含まれます。たとえば、構成を変更する際には、インストール内の構成ファイルも更新します。アプリケーションをデプロイする際は、ドメインまたはクラスタ内のすべての管理対象サーバーにデプロイします。
バックアップおよびリカバリを実行する際は、Oracle Fusion Middleware環境全体を考慮することが重要です。一度Oracle Fusion Middleware環境全体をバックアップし、その後、定期的に増分バックアップおよびリカバリ操作を実行します。データの消失が発生した場合は、環境を整合性のある状態にリストアすることができます。
バックアップおよびリカバリの詳細は、Oracle Fusion Middlewareの管理者ガイドの「高度な管理: バックアップとリカバリ」を参照してください。
