Sun Cluster 3.0 環境における Solaris Resource Manager の構成

有効なトポロジ

Solaris Resource Manager は、サポートされている任意の Sun Cluster 3.0 Update トポロジにインストールできます。有効なトポロジについては、『Sun Cluster 3.0 12/01 の概念』を参照してください。

要件の決定

Sun Cluster 環境で Solaris Resource Manager を構成する前に、スイッチオーバーやフェイルオーバーにおいて、資源の制御と追跡管理をどのように実行するかを決定しなければなりません。すべてのクラスタノードを同じように構成すると、使用制限が主ノードとバックアップノードで同等に適用されます。

全ノードの構成ファイルにおいて、アプリケーションの構成パラメータをすべて同じにする必要はありませんが、最低でもマスターになる可能性があるノードでは、構成ファイルにアプリケーションのすべてを指定しなければなりません。たとえば、アプリケーション 1 は phys-host1 で実行しますが、phys-host2 や phys-host3 にスイッチオーバーやフェイルオーバーされる可能性がある場合、アプリケーション 1 は、この 3 つの全ノード (phys-host1、phys-host2、および phys-host3) の構成ファイルに指定しなければなりません。

Solaris Resource Manager は、使用量や総使用量のパラメータを構成するという点では非常に柔軟性があり、Sun Cluster により受ける制約もほとんどありません。構成上の選択は、サイトの条件によって決まります。システムを構成する前に、次の節で説明する一般的なガイドラインを参考にしてください。

メモリー制限値パラメータの設定

Sun Cluster で Solaris Resource Manager を使用する場合は、アプリケーションの不要なフェイルオーバーやピンポン現象を予防するため、メモリー制限値を適切に設定しなければなりません。通常は、次のガイドラインに従ってください。

• メモリー制限値をあまり低く設定しないでください。アプリケーションがメモリー制限値に達した場合、フェイルオーバーとなります。仮想メモリー制限値に達すると、予期せぬ結果となるため、とくにデータベースアプリケーションの場合に重要です。

• 主ノードとバックアップノードでは、同じメモリー制限値に設定しないでください。同じ制限値を設定すると、アプリケーションがメモリー制限値に達して同じメモリー制限値が指定されたバックアップノードにフェイルオーバーする時にピンポン現象が発生します。バックアップノードでは、少しでも高くメモリー制限値を設定してください 。どれくらい高く設定すべきかは、サイトの状況 (アプリケーション、資源、方針など) 次第です。メモリー制限値を異なる値に設定することによって、ピンポン現象を予防して、システム管理者はパラメータの調整を行うのに必要な時間を確保できます。

• 負荷均衡など、設定の細かくない問題解決に、Solaris Resource Manager のメモリー制限値を使用してください。たとえば、欠陥のあるアプリケーションが過剰な資源を使用するのを予防します。

総使用量パラメータの使用

CPU 割当数、ログイン数、接続時間など、システム資源の総使用量を追跡するのに、Solaris Resource Manager のいろいろなパラメータを使用できます。ただし、特に指定しない限り、スイッチオーバーやフェイルオーバーが発生した場合、スイッチオーバーまたはフェイルオーバーされた全アプリケーションの総使用量データ (CPU 使用量、ログイン数、接続時間) は、新しいマスターノードで 0 から記録が再開されます。総使用量のデータは、ノード間で動的に移動されることはありません。Solaris Resource Manager の総使用量レポート機能の正確性を維持するために、総使用量の情報をクラスタノードから収集するスクリプトを作成できます。総使用量のデータを収集する際、どのマスターでアプリケーションが実行されるか分からないため、このスクリプトでは、アプリケーションの全マスターでの総使用量のデータを収集しなければなりません。詳細については、第 9 章「使用量データ」を参照してください。

フェイルオーバーの場合

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 タイムを要求する各アプリケーションに割り当てられる割当数の数にもとづいて変化する可能性があります。