test

Sun Cluster の概念 (Solaris OS 版)

フェイルオーバーシナリオ

管理パラメータを適切に構成すれば、プロジェクト構成 (/etc/project) 内の割り当ては、通常のクラスタ操作でも、スイッチオーバーやフェイルオーバーの状況でも正常に機能します。

以下の各項ではシナリオ例を説明します。

Sun Cluster 環境では、アプリケーションはリソースの一部として構成します。そして、リソースをリソースグループ (RG) の一部として構成します。障害が発生すると、リソースグループは、対応付けられたアプリケーションとともに、別のノードまたはゾーンにフェイルオーバーされます。以下の例では、リソースは明示的に示されていません。各リソースには、1 つのアプリケーションが構成されているものとします。

注 –

フェイルオーバーは、ノードまたはゾーンがノードリストで指定され、RGM で設定された順序で行なわれます。

以下の例は次のように構成されています。

フェイルオーバーが起こると、各アプリケーションに割り当てられる CPU 時間の割合が変化します。ただし、割り当てられているシェアの数はそのままです。この割合は、そのノードまたはゾーンで動作しているアプリケーションの数と、アクティブな各アプリケーションに割り当てられているシェアの数によって異なります。

これらのシナリオでは、次のように構成が行われているものとします。

2 つのアプリケーションを供う 2 ノードクラスタ

2 ノードクラスタに 2 つのアプリケーションを構成することによって、それぞれの物理ホスト (phys-schost-1、 phys-schost-2) を 1 つのアプリケーションのデフォルトマスターにすることができます。一方の物理ホストは、他方の物理ホストの二次ノードになります。アプリケーション 1 とアプリケーション 2 に関連付けられているすべてのプロジェクトは、両ノードのプロジェクトデータベースファイルに存在している必要があります。クラスタが正常に動作している間、各アプリケーションはそれぞれのデフォルトマスターで動作し、管理機能によってすべての CPU 時間を割り当てられます。

フェイルオーバーかスイッチオーバーが起ると、これらのアプリケーションは同じノードで動作し、構成ファイルの設定に従ってシェアを割り当てられます。たとえば、/etc/project ファイルに次のエントリが指定されていると、アプリケーション 1 に 4 シェアが、アプリケーション 2 に 1 シェアがそれぞれ割り当てられます。

Prj_1:100:project for App-1:root::project.cpu-shares=(privileged,4,none)
Prj_2:101:project for App-2:root::project.cpu-shares=(privileged,1,none)

次の図は、この構成の正常時の動作とフェイルオーバー時の動作を表しています。割り当てられているシェアの数は変わりません。ただし、各アプリケーションが利用できる CPU 時間の割合は変わる場合があります。この割合は、CPU 時間を要求する各プロセスに割り当てられているシェア数によって異なります。

図 : この図については、前の本文中で説明しています。

3 つのアプリケーションを供う 2 ノードクラスタ

3 つのアプリケーションが動作する 2 ノードクラスタでは、1 つの物理ホスト (phys-schost-1) を 1 つのアプリケーションのデフォルトマスターとして構成できます。そして、もう 1 つの物理ホスト (phys-schost-2) をほかの 2 つのアプリケーションのデフォルトマスターとして構成できます。各ノードには、次のサンプルプロジェクトデータベースファイルがあるものとします。フェイルオーバーやスイッチオーバーが起っても、プロジェクトデータベースファイルが変更されることはありません。

Prj_1:103:project for App-1:root::project.cpu-shares=(privileged,5,none)
Prj_2:104:project for App_2:root::project.cpu-shares=(privileged,3,none)
Prj_3:105:project for App_3:root::project.cpu-shares=(privileged,2,none)

クラスタが正常に動作している間、アプリケーション 1 には、そのデフォルトマスター phys-schost-1 で 5 シェアが割り当てられます。このノードで CPU 時間を要求するアプリケーションはこのアプリケーションだけであるため、この数は 100 パーセントの CPU 時間と同じことです。アプリケーション 2 と 3 には、それぞれのデフォルトマスターである phys-schost-2 で 3 シェアと 2 シェアが割り当てられます。したがって、正常な動作では、アプリケーション 2 に CPU 時間の 60 パーセントが、アプリケーション 3 に CPU 時間の 40 パーセントがそれぞれ割り当てられます。

フェイルオーバーかスイッチオーバーが発生し、アプリケーション 1 が phys-schost-2 に切り替えられても、3 つのアプリケーションの各シェアは変わりません。ただし、割り当てられる CPU リソースの割合はプロジェクトデータベースファイルに従って変更されます。

次の図は、この構成の正常な動作とフェイルオーバー動作を示しています。

図 : この図については、前の本文中で説明しています。

リソースグループだけのフェイルオーバー

複数のリソースグループが同じデフォルトマスターに属している構成では、1 つのリソースグループ (および、それに関連付けられたアプリケーション) が 二次ノードまたはゾーンにフェイルオーバーされたり、スイッチオーバーされることがあります。その間、クラスタのデフォルトマスターは動作を続けます。

注 –

フェイルオーバーの際、フェイルオーバーされるアプリケーションには、二次ノードまたはゾーン上の構成ファイルの指定に従ってリソースが割り当てられます。この例の場合、主ノードと二次ノードのプロジェクトデータベースファイルの構成は同じです。

次のサンプル構成ファイルでは、アプリケーション 1 に 1 シェア、アプリケーション 2 に 2 シェア、アプリケーション 3 に 2 シェアがそれぞれ割り当てられています。

Prj_1:106:project for App_1:root::project.cpu-shares=(privileged,1,none)
Prj_2:107:project for App_2:root::project.cpu-shares=(privileged,2,none)
Prj_3:108:project for App_3:root::project.cpu-shares=(privileged,2,none)

次の図は、この構成の正常時の動作とフェイルオーバー時の動作を表しています。ここでは、アプリケーション 2 が動作する RG-2 が phys-schost-2 にフェイルオーバーされます。割り当てられているシェアの数は変わりません。ただし、各アプリケーションが利用できる CPU 時間の割合は、CPU 時間を要求する各アプリケーションに割り当てられているシェア数によって異なります。

図 : この図については、前の本文中で説明しています。