わかりやすくするために、この項のすべての例でSmart Viewを使用しています。
Provider Servicesを使用すると、同じデータベースでアプリケーションを実行しているEssbaseサーバーをグループ化して、それらを1つのリソースとして使用できます。
注意: | Essbaseサーバーをクラスタに追加または削除する場合は、サーバーを再起動してグループへの変更を反映させます。グループ内のコンポーネントは、サーバーを再起動せずに使用可能/使用不可を切り替えることができます。 |
Essbaseデータベースをクラスタリングすると、ロード・バランシングとフェイルオーバーをサポートできるようになります。Provider Servicesは並列クラスタリングを提供します。これは、ユーザーの要求に応答する、一連のアクティブな重複データベースです。ユーザーからは、どのデータベースにアクセスしているかは見えません。ユーザーは単一のデータ・ソースに接続して、そのソースからデータを取得します。Provider Servicesを使用すると、可用性および優先ルールに基づいた、クラスタ内のデータベース間での接続のルーティングが容易になります。
図2、Provider ServicesでのEssbaseデータベースのクラスタリングでは、Smart ViewユーザーはProvider Servicesを介してEssbaseに接続します。
各ユーザー接続は、Essbaseのセッション中にサーバーに割り当てられます。Provider Servicesはセッション・レベルでロード・バランシングを行います。たとえば、図2、Provider ServicesでのEssbaseデータベースのクラスタリングでは、ユーザー1の接続はデータ・ソースAにマップされます。ユーザー2の接続はデータ・ソースBにマップされます。ユーザー3の接続はデータ・ソースCにマップされます。つまりユーザー1からのすべての要求は、接続中はデータ・ソースAで処理されます。
データ・ソースAで障害が発生した場合:
ユーザー1はデータ・ソースAでタイムアウトします。
ユーザー1は次に使用可能なデータ・ソースに再ルーティングされます。この場合は、図3、1つのデータ・ソースがオフラインになったデータベース・クラスタのデータ・ソースCです。
図3、1つのデータ・ソースがオフラインになったデータベース・クラスタに、データ・ソースAがオフラインになった場合に行われる処理を示します。
図3、1つのデータ・ソースがオフラインになったデータベース・クラスタでは、クエリー1の状態は中間層に保持されて再ルーティングされます。Provider Servicesにも、サーバー間のロード・バランシング機能があります。
図4、単一サーバー上のEssbaseデータベース・クラスタに、単一サーバーに配置されたクラスタ・データベースを示します。
図4、単一サーバー上のEssbaseデータベース・クラスタでは、2つのサーバーにEssbaseデータベースが含まれています。サーバー1には4つのプロセッサがあり、RAMは8GBです。サーバー2には8つのプロセッサがあり、RAMは16GBです。サーバー2のリソースのほうが多いため、サーバー2にデータ・ソースBとCが置かれます。このため、サーバー2は両方の接続を処理できます。
フェイルオーバーのサポートも、単一サーバー上のデータベース・クラスタに適用されます。図5、単一サーバー上のデータベース・クラスタのフェイルオーバーで、サーバー2がオフラインになります。ユーザー2とユーザー3は、次に使用可能なサーバーであるサーバー1に再ルーティングされます。
