フェイルオーバーの場合

Sun Cluster の場合、リミットデータベース (/var/srm/srmDB) に記述した資源割り当ての方法が、通常のクラスタ環境でも、あるいはスイッチオーバーやフェイルオーバーの場合でも同じになるように、Solaris Resource Manager を構成することができます。詳細は、 割り当ての例を参照してください。

以下の節では、構成例を取り上げています。

• 最初の 2 つの節、2 つのアプリケーションがある 2 ノードクラスタ と 3 つのアプリケーションがある 2 ノードクラスタ は、全ノードのフェイルオーバー例です。

• 資源グループのみのフェイルオーバー は、アプリケーションだけのフェイルオーバー処理を示しています。

クラスタ環境では、アプリケーションは資源グループ (RG) の一部として構成されます。障害が起きると、資源グループとその関連アプリケーションは、ほかのノードにフェイルオーバーします。以下の例では、アプリケーション 1 (App-1) は資源グループ RG-1 で、アプリケーション 2 (App-2) は資源グループ RG-2 で、アプリケーション 3 (App-3) は資源グループ RG-3 でそれぞれ構成されています。

割り当てられる割当数の数は変化しませんが、各アプリケーションに割り当てられる CPU 資源の割合 (%) はノードで動作しているアプリケーションの数および各アクティブアプリケーションに割り当てられている割当数の数にもとづいてフェイルオーバー後変化します。

これらの例は、次の状況を仮定しています。

• 共通する 1 つの親 l ノードの下ですべてのアプリケーションが構成されている

• ノード上で現在稼動しているプロセスは、これらのアプリケーションだけである

• リミットデータベースは、各クラスタノードで同じに構成されている

2 つのアプリケーションがある 2 ノードクラスタ

2 つの物理ホスト (phys-schost-1、phys-schost-2) がそれぞれ特定のアプリケーションのデフォルトマスターとなるように、2 ノードクラスタで 2 つのアプリケーションを設定できます。どちらの物理ホストも、他方の物理ホストのバックアップノードとなります。両ノードの Solaris Resource Manager リミットデータベースファイルに、両方のアプリケーションを指定しなければなりません。クラスタが正常に動作している場合、各アプリケーションは自らのデフォルトマスターで実行され、このマスターですべての割当数が与えられます (Solaris Resource Manager は利用できる全資源を割り当てるからです)。フェイルオーバーやスイッチオーバーが発生した場合、両方のアプリケーションは 1 つのノードで実行されることになり、構成ファイルに指定した割当数で資源が与えられます。たとえば、この例の構成ファイルでは、同じノードで両方のアプリケーションを実行する場合、アプリケーション 1 には 80 の割当数、アプリケーション 2 には 20 の割当数を与えると指定しています。

# limadm set cpu.shares=80 app1
# limadm set cpu.shares=20 app2
... 

次の図では、この構成における正常な処理とフェイルオーバー処理を示します。割り当てられる割当数の数は変化しませんが、各アプリケーションで利用できる CPU 資源の割合 (%) は CPU タイムを要求する各プロセスに割り当てられる割当数の数にもとづいて変化する可能性があります。

3 つのアプリケーションがある 2 ノードクラスタ

3 つのアプリケーションがある 2 ノードクラスタの場合、第 1 の物理ホスト (phys-host1) を 1 つのアプリケーションのデフォルトマスターとし、第 2 の物理ホスト (phys-host2) を残る 2 つのアプリケーションのデフォルトマスターとするように構成できます。次の例のリミットデータベースファイルを各ノードで使用し、フェイルオーバーやスイッチオーバーが発生しても、リミットデータベースファイルは変わらないものとします。

# limadm set cpu.shares=50	 app1
# limadm set cpu.shares=30	 app2
# limadm set cpu.shares=20	 app3
...

クラスタが正常に稼動している場合、アプリケーション 1 はそのデフォルトマスター phys-schost-1 に 50 の割当数が割り当てられます。このノードで CPU 資源を要求しているのはアプリケーション 1 だけであるため、これは CPU 資源の 100% に相当します。アプリケーション 2 と 3 については、これらのデフォルトマスターである phys-schost-2 に 30 の割当数と 20 の割当数がそれぞれ割り当てられます。通常処理の場合、アプリケーション 2 は CPU 資源の 60%、アプリケーション 3 は CPU 資源の 40% を受け取ります。

フェイルオーバーまたはスイッチオーバーが発生してアプリケーション 1 が phys-schost-2 に切り替えられた場合は、3 つのアプリケーションすべての割当数が同じになります。しかし、CPU 資源の割合はリミットデータベースファイルにもとづいて割り当て直されます。

• 50 の割当数が割り当てられたアプリケーション 1 は CPU の 50% を受け取る

• 30 の割当数が割り当てられたアプリケーション 2 は CPU の 30% を受け取る

• 20 の割当数が割り当てられたアプリケーション 3 は CPU の 20% を受け取る

次の図では、この構成における正常な処理とフェイルオーバー処理を示します。

資源グループのみのフェイルオーバー

複数の資源グループが同じデフォルトマスターを持つ構成では、クラスタ内でデフォルトマスターが稼動している間に 1 つの資源グループ (およびその関連アプリケーション) がバックアップノードにフェイルオーバーまたはスイッチオーバーを行う可能性があります。

フェイルオーバーの際、フェイルオーバーを行うアプリケーションにはバックアップノードの構成ファイルに指定されているとおりに資源が割り当てられます。この例では、主ノードとバックアップノードのリミットデータベースファイルの構成は同じです。

たとえば、この構成ファイル例ではアプリケーション 1 に 30 の割当数を、アプリケーション 2 に 60 の割当数を、アプリケーション 3 に 60 の割当数をそれぞれ割り当てるように指定しています。

# limadm set cpu.shares=30 App-1
# limadm set cpu.shares=60 App-2
# limadm set cpu.shares=60 App-3... 

次の図は、この構成の通常処理とフェイルオーバー処理を示したものです。アプリケーション 2 を含む RG-2 は、phys-schost-2 にフェイルオーバーします。割り当てられている割当数の数は変化しませんが、各アプリケーションで利用できる CPU 資源の割合は CPU タイムを要求する各アプリケーションに割り当てられる割当数の数にもとづいて変化する可能性があります。