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

有効なトポロジ

Sun Cluster の有効なトポロジで、2 ノードまたはそれ以上のクラスタに、Solaris Resource Manager をインストールできます。有効なトポロジには次のようなものがありますが、これらに限定される訳ではありません。

• 対称 - 2 つのノードを同一に構成します。通常の状況では、両者がデータサービスを提供します。

• 非対称 - 2 ノードの構成ですが、一方のノードが他方のノードのホットスタンバイとして機能します。

• N+1 (星形） - 2 つ以上のノードで構成します。1 つのノードが他方のスタンバイとして機能します。

• N to N (スケーラブル) - すべてのサーバーが共有ディスクセットに直接接続されます。データサーバーは、他のどのサーバーにでもフェイルオーバーできます。

これらのトポロジは、docs.sun.com にある『Sun Cluster 2.2 ソフトウェアのインストール』の第 1 章で詳細に説明しています。

要件の決定

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 の総使用量レポート機能の正確性を維持するために、総使用量の情報をクラスタノードから収集するスクリプトを作成できます。総使用量のデータを収集する際、どのマスターでアプリケーションが実行されるか分からないため、このスクリプトでは、アプリケーションの全マスターでの総使用量のデータを収集しなければなりません。詳細については、第 8 章「使用量データ」を参照してください。

フェイルオーバーの場合

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

次の例を考えてください。

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

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
... 

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

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-host1 で利用できる割当数がすべて与えられます。アプリケーション 2 と 3 には、デフォルトマスター phys-host2 でそれぞれ 60 と 40 の割当数が与えられますが、これは利用できる全資源の中で適切な割合が各アプリケーションに適用されているからです。フェイルオーバーまたはスイッチオーバーが発生して、アプリケーション 1 が phys-host2 にスイッチオーバーした場合、3 つのアプリケーションの割当数はリミットデータベースファイルに従って再割り当てされ、アプリケーション 1 は 50、アプリケーション 2 は 30、アプリケーション 3 は 20 の割当数となります。

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

論理ホストだけのフェイルオーバー

複数の論理ホストが同一のデフォルトマスターを持っている構成の場合、デフォルトマスターを停止させずにクラスタ内で動作させたまま、論理ホスト (および関連アプリケーション) だけをバックアップノードにフェイルオーバーまたはスイッチオーバーさせることができます。このような場合、スイッチオーバーやフェイルオーバーが発生したアプリケーションには、バックアップノードの構成ファイルに指定したとおりに資源が割り当てられます。この処理は、2 ノードクラスタで説明した処理と同じです。

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