Oracle Business Intelligence Enterprise Editionデプロイメント・ガイド > Oracle Business Intelligenceのクラスタ化、ロード・バランシングおよびフェイルオーバー >

Oracle BIコンポーネントのフェイルオーバー・メカニズム

この項では、クラスタ内のBIコンポーネントのフェイルオーバー・プロセスについて説明します。

• BI Presentation Servicesの障害
• BI Serverの障害
• マスターBI Serverの障害
• BI Schedulerの障害
• Cluster Controllerの障害

BI Presentation Servicesの障害

• Webクライアント

  初回のユーザー・セッション・リクエストは、いずれのBI Presentation Servicesにも送ることができますが、各ユーザーはその後、特定のBI Presentation Servicesインスタンスにバインドされます。プレゼンテーション・サーバーに障害が発生するとセッションが切断され、エラーがブラウザにリレーして戻されます。サーバーに障害が発生したときに進行中で、ディスクに保存されていなかった作業は失われます。ユーザーは、再度ログインして、使用可能なBI Presentation Servicesへの新しい接続を確立する必要があります。ユーザーのログインがSingle Sign-Onシステム（Oracle Single Sign-on（SSO）など）を介して行われている場合、この再ログインは自動的に行われます。新しいBI Presentation Servicesセッションは、新しいBI Serverセッションを作成します。

  注意:  BI Presentation Servicesインスタンスが失敗すると、システムがインスタンスの失敗を認識し、ユーザーが新しいBI Presentation Servicesインスタンスに移行されるまで、少し時間がかかります。この間にセッション状態の障害が発生する場合があります。

• iBot

  エラーがBI Schedulerにリレーされ、BI Schedulerでは障害を記録してジョブを再試行します。この再試行により、使用可能なBI Presentation Servicesへの新しい接続が確立されます。

BI Serverの障害

BI Serverに障害が発生すると、ODBCエラーがクライアントに返されます。

• BI Presentation Services

  Oracle BIの各Webユーザーは、1つのBI Serverでリクエストを処理します。このBI Serverが使用できなくなると、エンド・ユーザーの画面にエラーが表示されますが、ブラウザのリフレッシュ機能を使用すると、使用可能なBI Serverとの新しいセッションが確立されます。

• Administration Tool

  接続しているBI Serverが使用できなくなると、Administration ToolはODBCエラーをリレーして接続を切断します。管理者は再接続する必要があります。

• iBot

  BI Serverに障害が発生すると、エラーがSchedulerにリレーされ、Schedulerでは障害を記録してジョブを再試行します。これにより、使用可能なBI Serverへの新しい接続が確立されます。

• サード・パーティーのクライアント

  サード・パーティーのクライアントは、ODBCを使用してBI Serverに接続します。BI Serverに障害が発生すると、エラーがリレーされ、ODBC標準に従ってセッションがいったん切断されてから再開されます。

マスターBI Serverの障害

マスターBI Serverが使用できなくなると、メタデータのオンライン変更が実行できません。これは管理上の処理で、ランタイムの可用性には影響しません。マスターBI Serverが永続的に使用できない場合は、他のServerの1つを新しいマスターに指定する必要があります。これには、すべてのサーバーの再構成が必須となります。

BI Schedulerの障害

BI Schedulerは、Cluster Controllerによって監視および管理されています。BI Schedulerが使用できない場合は、次にアクティブにするBI SchedulerをCluster Controllerが決定します。以前のプライマリSchedulerが再び使用可能になっても、プライマリ・ロールは元に戻りません。

アクティブなBI Schedulerが失敗しても、Schedulerプロトコルはステートレスであり、シームレスにフェイルオーバーするため、開いているクライアント接続がエラーを受信することはありません。

• iBot

  iBot実行は、Schedulerテーブルの状態を維持します。Schedulerの次のインスタンスがアクティブになると、このインスタンスが、実行中であったすべてのジョブ・インスタンスの状態を読み取り、それらのインスタンスを実行します。iBotは、プライマリ・インスタンスに障害が発生する前に配信していなかった受信者にのみ配信します。

• Java、コマンドラインまたはスクリプト・ジョブ

  ジョブは、新しいジョブ・インスタンスで最初から再実行されます。

  注意:  ジョブ・インスタンスは、Job Managerから手動で再実行できます。iBotの場合は、正しく配信されなかったユーザーにのみ配信します。たとえば、iBotの実行途中でメール・サーバーが停止した場合、インスタンスの再実行によって、メール・サーバーの故障により電子メールを受信しなかった受信者にのみ配信が行われます。

Cluster Controllerの障害

Cluster Controllerは、BI ServerまたはBI Schedulerの障害の検出、および失敗したサーバーのクライアントのためのフェイルオーバーをサポートしています。

Cluster Controllerはアクティブ/パッシブ・モデルで動作します。すべてのクライアントは、まずPrimary Cluster Controllerへの接続を試行します。Primary Cluster Controllerが使用できない場合、クライアントはSecondary Cluster Controllerに接続します。Secondary Cluster Controllerは、負荷と可用性に基づいて、BI ServerおよびアクティブなBI Schedulerインスタンスにリクエストを送ります。Primaryがその後使用可能になると、すべてのリクエストは再びPrimaryに送られます。

Secondary Cluster Controllerは、Primaryと同様に、各BI Serverのセッション件数を監視しますが、Primary Cluster Controllerが停止中でないかぎり、アクティブなSchedulerに指示しません。

Primary Cluster ControllerとSecondary Cluster Controllerは、相互のライフ・サイクルを監視します。これにより、Cluster Controllerインスタンス間で通信が停止中の場合はスプリット・ブレイン障害の影響を受けやすくなりますが、それぞれのインスタンスは実行されていて、他のクライアントと通信できます。このような場合、BI Serverは影響を受けませんが、Schedulerには同時に2つのアクティブなインスタンスが発生することがあります。まれに、このことが原因となって、ジョブが二重に実行される場合があります。通信回線が回復すると、Primary Cluster Controllerはクラスタに対して、1つのSchedulerのみをアクティブにするように指示します。Clusterコンポーネントは同一のLocal Area Network（LAN）に存在する必要があり、クラスタ化されたデプロイではMulti-NICがサポートされないことにより、スプリット・ブレイン障害が発生する可能性は最小限に抑えられます。

両方のCluster Controllerが使用できない場合は、ログインしようとする新しいユーザーに対して、BI Presentation Servicesがエラーを返します。既存のセッションは影響を受けません。