Sun Cluster データサービスの計画と管理 (Solaris OS 版)

オンラインのリソースグループをクラスタノード間で分散する

可用性を最大化するため、あるいは、性能を最適化するため、いくつかのサービスの組み合わせは、特定のオンラインのリソースグループをクラスタノードおよびゾーン間で分散する必要があります。オンラインのリソースグループを分散するということは、リソースグループ間でアフィニティーを作成するということであり、次のような理由で行われます。

初めてリソースグループをオンラインにするときに、要求されている分散を強制的に実行するため
リソースグループのフェイルオーバーまたはスイッチオーバーの後に必要な分散を保持しておくため

この節では、次のような例を使用しながら、リソースグループのアフィニティーを使用して、オンラインのリソースグループをクラスタノードおよびゾーン間で分散する方法について説明します。

あるリソースグループと別のリソースグループを強制的に同じ場所に配置する
あるリソースグループと別のリソースグループをできる限り同じ場所に配置する
リソースグループの集合の負荷をクラスタノード間で均等に分配する
重要なサービスに優先権を指定する
リソースグループのフェイルオーバーまたはスイッチオーバーを委託する
リソースグループ間のアフィニティーを組み合わせて、複雑な動作を指定する

リソースグループのアフィニティー

リソースグループ間のアフィニティーは、複数のリソースグループが同時にオンラインになる可能性があるノードまたはゾーンを制限します。各アフィニティーにおいて、ソースのリソースグループには 1 つまたは複数のターゲットのリソースグループに対するアフィニティーを宣言します。リソースグループ間にアフィニティーを作成するには、ソースの RG_affinities リソースグループプロパティーを次のように設定します。

-p RG_affinities=affinity-list

affinity-list

ソースリソースグループとターゲットリソースグループ (複数可) の間のアフィニティーのコンマ区切りリストを指定します。リストでは 1 つまたは複数のアフィニティーを指定できます。

リストでは各アフィニティーを次のように指定します。

operator target-rg

注 –

operator と target-rg の間にはスペースを入れてはなりません。

operator: 作成しようとしているアフィニティーのタイプを指定します。詳細は、表 2–2を参照してください。
target-rg: 作成しているアフィニティーのターゲットであるリソースグループを指定します。

表 2–2 リソースグループ間のアフィニティーのタイプ


演算子	アフィニティーのタイプ	効果
`+`	弱い肯定的な	ソースは、できる限り、ターゲットがオンラインである (あるいは、起動している) 1 つまたは複数のノードまたはゾーン上でオンラインになります。つまり、ソースとターゲットは異なるノードまたはゾーン上でオンラインになることもあります。
`++`	強い肯定的な	ソースは、ターゲットがオンラインである (あるいは、起動している) 1 つまたは複数のノードまたはゾーン上でのみオンラインになります。つまり、ソースとターゲットは異なるノードまたはゾーン上でオンラインになることはありません。
`-`	弱い否定的な	ソースは、可能であれば、ターゲットがオンラインでない (あるいは、起動していない) 1 つまたは複数のノードまたはゾーン上でオンラインになります。つまり、ソースとターゲットは同じノードまたはゾーン上でオンラインになることもあります。
`--`	強い否定的な	ソースは、ターゲットがオンラインでない 1 つまたは複数のノードまたはゾーン上でのみオンラインになります。つまり、ソースとターゲットは同じノードまたはゾーン上でオンラインになることはありません。
`+++`	フェイルオーバー委託付きの強い肯定的な	強い肯定的なアフィニティーと似ていますが、ソースによるフェイルオーバーはターゲットに委任されます。詳細については、「リソースグループのフェイルオーバーまたはスイッチオーバーを委託する」を参照してください。

弱いアフィニティは、Nodelist 優先順位より優先されます。

そのほかのリソースグループの現在の状態によっては、任意のノードまたはゾーン上で、強いアフィニティーが成立しないことがあります。このような状況では、アフィニティーのソースであるリソースグループはオフラインのままです。その他のリソースグループの状態が変更され、強いアフィニティーが成立できるようになると、アフィニティーのソースであるリソースグループはオンラインに戻ります。

注 –

複数のターゲットリソースグループを持つソースリソースグループに強いアフィニティーを宣言するときは、注意が必要です。宣言されたすべての強いアフィニティーが成立しない場合、ソースリソースグループはオフラインのままになるためです。

あるリソースグループと別のリソースグループを強制的に同じ場所に配置する

あるリソースグループのサービスが別のリソースグループのサービスに強く依存する場合、これらのリソースグループは両方とも同じノードまたはゾーン上で動作する必要があります。たとえば、あるアプリケーションがお互いに依存する複数のサービスのデーモンから構成される場合、すべてのデーモンは同じノードまたはゾーン上で動作する必要があります。

このような状況では、依存するサービスのリソースグループを、強制的に、依存されるサービスのリソースグループと同じ場所に配置するように指定します。あるリソースグループを強制的に別のリソースグループと同じ場所に配置するには、あるリソースグループに別のリソースグループに対する強い肯定的なアフィニティーを宣言します。

# clresourcegroup set|create -p RG_affinities=++target-rg source-rg

source-rg: 強い肯定的なアフィニティーのソースであるリソースグループを指定します。このリソースグループは、別のリソースグループに対する強い肯定的なアフィニティーを宣言するリソースグループです。
-p RG_affinities=++target-rg: 強い肯定的なアフィニティーのターゲットであるリソースグループを指定します。このリソースグループは、強い肯定的なアフィニティーを宣言する対象のリソースグループです。

強い肯定的なアフィニティーを宣言しているソースのリソースグループは、ターゲットのリソースグループに従います。ターゲットのリソースグループが別のノードに再配置された場合、ソースのリソースグループは自動的にターゲットと同じノードに切り替わります。しかし、強い肯定的なアフィニティーを宣言しているソースのリソースグループは、ターゲットのリソースグループが動作していないノードまたはゾーンにはフェイルオーバーできません。

注 –

フェイルオーバーされないのは、リソースモニターが起動したフェイルオーバーだけです。ソースとターゲットの両方のリソースグループが動作しているノードまたはゾーンに障害が発生した場合、これらのリソースグループは、正常に動作している同じノードまたはゾーンにフェイルオーバーします。

たとえば、リソースグループ rg1 にリソースグループ rg2 に対する強い肯定的なアフィニティーが宣言されていると仮定します。rg2 が別のノードまたはゾーンにフェイルオーバーすると、rg1 もそのノードまたはゾーンにフェイルオーバーします。rg1 内のすべてのリソースが操作可能であるとしても、このフェイルオーバーは発生します。しかし、rg1 内のリソースによって、rg2 が動作していないノードまたはゾーンに rg1 をフェイルオーバーしようとした場合、このフェイルオーバーはブロックされます。

強い肯定的なアフィニティーのターゲットをオンラインにしたときに、強い肯定的なアフィニティーのソースがすべてのノード上でオフラインになっている場合があります。このような場合、強い肯定的なアフィニティーのソースは、ターゲットと同じノード上で自動的にオンラインになります。

たとえば、リソースグループ rg1 にリソースグループ rg2 に対する強い肯定的なアフィニティーが宣言されていると仮定します。最初は両方のリソースグループともすべてのノード上でオフラインです。管理者があるノード上で rg2 をオンラインにすると、rg1 は自動的に同じノード上でオンラインになります。

clresourcegroup suspend コマンドを使用すると、強いアフィニティーまたはクラスタ再構成によりリソースグループが自動的にオンラインになるのを防止できます。

強い肯定的なアフィニティーを宣言しているリソースグループをフェイルオーバーする必要がある場合、そのフェイルオーバーは委託する必要があります。詳細については、「リソースグループのフェイルオーバーまたはスイッチオーバーを委託する」を参照してください。

例 2–40 あるリソースグループと別のリソースグループを強制的に同じ場所に配置する

この例では、リソースグループ rg1 を変更して、リソースグループ rg2 に対する強い肯定的なアフィニティーを宣言するためのコマンドを示します。このアフィニティーを宣言すると、rg1 は rg2 が動作しているノードまたはゾーン上だけでオンラインになります。この例では、両方のリソースグループが存在していると仮定します。

# clresourcegroup set -p RG_affinities=++rg2 rg1

あるリソースグループと別のリソースグループをできる限り同じ場所に配置する

あるリソースグループのサービスが別のリソースグループのサービスを使用していることがあります。結果として、これらのサービスは、同じノードまたはゾーン上で動作する場合にもっとも効率よく動作します。たとえば、データベースを使用するアプリケーションは、そのアプリケーションとデータベースが同じノードまたはゾーン上で動作する場合に、もっとも効率よく動作します。しかし、これらのサービスは異なるノードまたはゾーン上で動作してもかまいません。なぜなら、リソースグループのフェイルオーバーの増加よりも効率の低下のほうが被害が小さいためです。

このような状況では、両方のリソースグループを、できる限り、同じ場所に配置するように指定します。あるリソースグループと別のリソースグループをできる限り同じ場所に配置するには、あるリソースグループに別のリソースグループに対する弱い肯定的なアフィニティーを宣言します。

# clresourcegroup set|create -p RG_affinities=+target-rg source-rg

source-rg: 弱い肯定的なアフィニティーのソースであるリソースグループを指定します。このリソースグループは、別のリソースグループに対する弱い肯定的なアフィニティーを宣言するリソースグループです。
-p RG_affinities=+target-rg: 弱い肯定的なアフィニティーのターゲットであるリソースグループを指定します。このリソースグループは、弱い肯定的なアフィニティーを宣言する対象のリソースグループです。

あるリソースグループに別のリソースグループに対する弱い肯定的なアフィニティーを宣言することによって、両方のリソースグループが同じノードまたはゾーンで動作する確率が上がります。弱い肯定的なアフィニティーのソースは、まず、そのアフィニティーのターゲットがすでに動作しているノードまたはゾーン上でオンラインになろうとします。しかし、弱い肯定的なアフィニティーのソースは、そのアフィニティーのターゲットがリソースモニターによってフェイルオーバーされても、フェイルオーバーしません。同様に、弱い肯定的なアフィニティーのソースは、そのアフィニティーのターゲットがスイッチオーバーされても、フェイルオーバーしません。どちらの状況でも、ソースがすでに動作しているノードまたはゾーン上では、ソースはオンラインのままです。

注 –

ソースとターゲットの両方のリソースグループが動作しているノードまたはゾーンに障害が発生した場合、これらのリソースグループは、正常に動作している同じノードまたはゾーン上で再起動されます。

例 2–41 あるリソースグループと別のリソースグループをできる限り同じ場所に配置する

この例では、リソースグループ rg1 を変更して、リソースグループ rg2 に対する弱い肯定的なアフィニティーを宣言するためのコマンドを示します。このアフィニティーを宣言すると、rg1 と rg2 はまず、同じノードまたはゾーン上でオンラインになろうとします。しかし、rg2 内のリソースによって rg2 がフェイルオーバーしても、rg1 はリソースグループが最初にオンラインになったノードまたはゾーン上でオンラインのままです。この例では、両方のリソースグループが存在していると仮定します。

# clresourcegroup set -p RG_affinities=+rg2 rg1

リソースグループの集合の負荷をクラスタノード間で均等に分配する

リソースグループの集合の各リソースグループには、クラスタの同じ負荷をかけることができます。このような状況では、リソースグループをクラスタ間で均等に分散することによって、クラスタの負荷の均衡をとることができます。

リソースグループの集合のリソースグループをクラスタノード間で均等に分散するには、各リソースグループに、リソースグループの集合のほかのリソースグループに対する弱い否定的なアフィニティーを宣言します。

# clresourcegroup set|create -p RG_affinities=neg-affinity-list source-rg

source-rg: 弱い否定的なアフィニティーのソースであるリソースグループを指定します。このリソースグループは、別のリソースグループに対する弱い否定的なアフィニティーを宣言するリソースグループです。
-p RG_affinities=neg-affinity-list: ソースリソースグループと、弱い否定的なアフィニティーのターゲットであるリソースグループの間の、弱い否定的なアフィニティーをコンマで区切って指定します。ターゲットリソースグループは、弱い否定的なアフィニティーを宣言する対象のリソースグループです。

あるリソースグループにその他のリソースグループに対する弱い否定的なアフィニティーを宣言することによって、そのリソースグループが常に、もっとも負荷がかかっていないクラスタノード上でオンラインになることが保証されます。このノード上で動作しているその他のリソースグループは最小数です。したがって、弱い否定的なアフィニティーの最小数が違反されます。

例 2–42 リソースグループの集合の負荷をクラスタノード間で均等に分配する

この例では、リソースグループ rg1、rg2、rg3、および rg4 を変更して、これらのリソースグループを、クラスタで利用可能なノード間で均等に分配するためのコマンドを示します。この例では、リソースグループ rg1、rg2、rg3、および rg4 が存在していると仮定します。

# clresourcegroup set -p RG_affinities=-rg2,-rg3,-rg4 rg1
# clresourcegroup set -p RG_affinities=-rg1,-rg3,-rg4 rg2
# clresourcegroup set -p RG_affinities=-rg1,-rg2,-rg4 rg3
# clresourcegroup set -p RG_affinities=-rg1,-rg2,-rg3 rg4

重要なサービスに優先権を指定する

クラスタは、重要なサービスと重要でないサービス組み合わせて動作するように構成できます。たとえば、重要な顧客サービスをサポートするデータベースは、重要でない研究タスクと同じクラスタで実行できます。

重要でないサービスが重要なサービスに影響を与えないようにするには、重要なサービスに優先権を指定します。重要なサービスに優先権を指定することによって、重要でないサービスが重要なサービスと同じノード上で動作することを防ぐことができます。

すべてのノードが操作可能であるとき、重要なサービスは重要でないサービスとは異なるノード上で動作します。しかし、重要なサービスに障害が発生すると、このサービスは重要でないサービスが動作しているノードにフェイルオーバーします。このような状況では、重要でないサービスは直ちにオフラインになり、重要なサービスはコンピューティングリソースを完全に利用できるようになります。

重要なサービスに優先権を指定するには、重要でない各サービスのリソースグループに、重要なサービスを含むリソースグループに対する強い否定的なアフィニティーを宣言します。

# clresourcegroup set|create -p RG_affinities=--critical-rg noncritical-rg

noncritical-rg: 重要でないサービスを含むリソースグループを指定します。このリソースグループは、別のリソースグループに対する強い否定的なアフィニティーを宣言するリソースグループです。
-p RG_affinities=--critical-rg: 重要なサービスを含むリソースグループを指定します。このリソースグループは、強い否定的なアフィニティーが宣言されるリソースグループです。

強い否定的なアフィニティーのソースのリソースグループは、そのアフィニティーのターゲットのリソースグループから離れます。

強い否定的なアフィニティーのターゲットをオフラインにした場合、強い否定的なアフィニティーのソースは、すべてのノード上でオフラインになる場合があります。このような状況では、強い否定的なアフィニティーのソースは自動的にオンラインになります。通常、ノードリストのノードの順序および宣言されたアフィニティーに基づいて、リソースグループは最も優先されるノード上でオンラインになります。

たとえば、リソースグループ rg1 にリソースグループ rg2 に対する強い否定的なアフィニティーが宣言されていると仮定します。最初はリソースグループ rg1 がすべてのノード上でオフラインになりますが、リソースグループ rg2 は 1 つのノード上でオンラインになります。管理者が rg2 をオフラインにすると、rg1 は自動的にオンラインになります。

clresourcegroup suspend コマンドを使用すると、強いアフィニティーまたはクラスタ再構成により強い否定的なアフィニティーのソースが自動的にオンラインになるのを防止できます。

例 2–43 重要なサービスに優先権を指定する

この例では、重要でないリソースグループ ncrg1 と ncrg2 を変更して、重要なリソースグループ mcdbrg に重要でないリソースグループよりも高い優先権を与えるためのコマンドを示します。この例では、リソースグループ mcdbrg、ncrg1、および ncrg2 が存在していると仮定します。

# clresourcegroup set -p RG_affinities=--mcdbrg ncrg1 ncrg2

リソースグループのフェイルオーバーまたはスイッチオーバーを委託する

強い肯定的なアフィニティーのソースリソースグループは、そのアフィニティーのターゲットが動作していないノードにはフェイルオーバーまたはスイッチオーバーできません。強い肯定的なアフィニティーのソースリソースグループをフェイルオーバーまたはスイッチオーバーする必要がある場合、そのフェイルオーバーはターゲットリソースグループに委託する必要があります。このアフィニティーのターゲットがフェイルオーバーするとき、このアフィニティーのソースはターゲットと一緒に強制的にフェイルオーバーされます。

注 –

++ 演算子で指定した強い肯定的なアフィニティーのソースリソースグループでも、スイッチオーバーする必要がある場合もあります。このような状況では、このアフィニティーのターゲットとソースを同時にスイッチオーバーします。

リソースグループのフェイルオーバーまたはスイッチオーバーを別のリソースグループに委託するには、そのリソースグループに、その他のリソースグループに対するフェイルオーバー委託付きの強い肯定的なアフィニティーを宣言します。

# clresourcegroup set|create source-rg -p RG_affinities=+++target-rg

source-rg

フェイルオーバーまたはスイッチオーバーを委託するリソースグループを指定します。このリソースグループは、別のリソースグループに対するフェイルオーバー委託付きの強い肯定的なアフィニティーを宣言するリソースグループです。

-p RG_affinities=+++target-rg

source-rg がフェイルオーバーまたはスイッチオーバーを委託するリソースグループを指定します。このリソースグループは、フェイルオーバー委託付きの強い肯定的なアフィニティーが宣言されるリソースグループです。

あるリソースグループは、最大 1 つのリソースグループに対するフェイルオーバー委託付きの強い肯定的なアフィニティーを宣言できます。逆に、あるリソースグループは、その他の任意の数のリソースグループによって宣言されたフェイルオーバー委託付きの強い肯定的なアフィニティーのターゲットである可能性があります。

つまり、フェイルオーバー委託付きの強い肯定的なアフィニティーは対照的ではありません。ソースがオフラインの場合でも、ターゲットはオンラインになることができます。しかし、ターゲットがオフラインの場合、ソースはオンラインになることができません。

ターゲットが第三のリソースグループに対するフェイルオーバー委任付きの強い肯定的なアフィニティーを宣言する場合、フェイルオーバーまたはスイッチオーバーはさらに第三のリソースグループに委託されます。第三のリソースグループがフェイルオーバーまたはスイッチオーバーを実行すると、その他のリソースグループも強制的にフェイルオーバーまたはスイッチオーバーされます。

例 2–44 リソースグループのフェイルオーバーまたはスイッチオーバーを委託する

この例では、リソースグループ rg1 を変更して、リソースグループ rg2 に対するフェイルオーバー委託付きの強い肯定的なアフィニティーを宣言するためのコマンドを示します。このアフィニティー関係の結果、rg1 はフェイルオーバーまたはスイッチオーバーを rg2 に委託します。この例では、両方のリソースグループが存在していると仮定します。

# clresourcegroup set -p RG_affinities=+++rg2 rg1

リソースグループ間のアフィニティーの組み合わせ

複数のアフィニティーを組み合わせることによって、より複雑な動作を作成できます。たとえば、関連する複製サーバーにアプリケーションの状態を記録できます。この例におけるノード選択条件は次のとおりです。

複製サーバーは、アプリケーションと異なるノード上で動作している必要があります。
アプリケーションが現在のノードからフェイルオーバーすると、アプリケーションは、複製サーバーが動作しているノードにフェイルオーバーする必要があります。
アプリケーションが複製サーバーが動作しているノードにフェイルオーバーすると、複製サーバーは異なるノードにフェイルオーバーする必要があります。その他のノードが利用できない場合、複製サーバーはオフラインになる必要があります。

これらの条件を満たすには、アプリケーションと複製サーバーのリソースグループを次のように構成します。

アプリケーションを含むリソースグループは、複製サーバーを含むリソースグループに対する弱い肯定的なアフィニティーを宣言します。
複製サーバーを含むリソースグループは、アプリケーションを含むリソースグループに対する強い否定的なアフィニティーを宣言します。

例 2–45 リソースグループ間のアフィニティーの組み合わせ

この例では、次のリソースグループ間のアフィニティーを組み合わせるためのコマンドを示します。

リソースグループ app-rg は、複製サーバーによって状態を追跡するアプリケーションを示します。
リソースグループ rep-rg は、複製サーバーを示します。

この例では、リソースグループはアフィニティーを次のように宣言します。

リソースグループ app-rg は、リソースグループ rep-rg に対する弱い肯定的なアフィニティーを宣言します。
リソースグループ rep-rg は、リソースグループ app-rg に対する強い否定的なアフィニティーを宣言します。

この例では、両方のリソースグループが存在していると仮定します。

# clresourcegroup set -p RG_affinities=+rep-rg app-rg
# clresourcegroup set -p RG_affinities=--app-rg rep-rg