可用性を最大化するため、あるいは、性能を最適化するため、いくつかのサービスの組み合わせは、特定のオンラインのリソースグループをクラスタノード間で分散する必要があります。オンラインのリソースグループを分散するということは、リソースグループ間でアフィニティを作成するということであり、次のような理由で行われます。
初めてリソースグループをオンラインにするときに必要な分散を強制的に実行するため
リソースグループのフェイルオーバーまたはスイッチオーバーの後に必要な分散を保持しておくため
この節では、次のような例を使用しながら、リソースグループのアフィニティを使用して、オンラインのリソースグループをクラスタノード間で分散する方法について説明します。
あるリソースグループと別のリソースグループを強制的に同じ場所に配置する
あるリソースグループと別のリソースグループをできる限り同じ場所に配置する
リソースグループの集合の負荷をクラスタノード間で均等に分配する
重要なサービスに優先権を指定する
リソースグループのフェイルオーバーまたはスイッチオーバーを委託する
リソースグループ間のアフィニティを組み合わせて、複雑な動作を指定する
リソースグループ間のアフィニティは、複数のリソースグループが同時にオンラインになる可能性があるノードを制限します。各アフィニティにおいて、ソースのリソースグループには 1 つまたは複数のターゲットのリソースグループに対するアフィニティを宣言します。リソースグループ間にアフィニティを作成するには、ソースの RG_affinities リソースグループプロパティを次のように設定します。
-y RG_affinities=operator target-rg-list |
operator と target-rg-list の間にスペースを入れてはなりません。
作成しようとしているアフィニティのタイプを指定します。詳細は、表 2–2を参照してください。
作成しようとしているアフィニティのターゲットであるリソースグループをコンマで区切って指定します。このリストには、1 つまたは複数のリソースグループを指定できます。
オペレータ |
アフィニティのタイプ |
効果 |
---|---|---|
+ |
ソースは、できる限り、ターゲットがオンラインである (あるいは、起動している) 1 つまたは複数のノード上でオンラインになります。つまり、ソースとターゲットは異なるノード上でオンラインになることもあります。 |
|
++ |
ソースは、ターゲットがオンラインである (あるいは、起動している) 1 つまたは複数のノード上でのみオンラインになります。つまり、ソースとターゲットは異なるノード上でオンラインになることはありません。 |
|
- |
ソースは、可能であれば、ターゲットがオンラインでない (あるいは、起動していない) 1 つまたは複数のノード上でオンラインになります。つまり、ソースとターゲットは同じノード上でオンラインになることもあります。 |
|
-- |
ソースは、ターゲットがオンラインでない 1 つまたは複数のノード上でのみオンラインになります。つまり、ソースとターゲットは同じノード上でオンラインになることはありません。 |
|
+++ |
強い肯定的なアフィニティと似ていますが、ソースによるフェイルオーバーはターゲットに委託されます。詳細は、「リソースグループのフェイルオーバーまたはスイッチオーバーを委託する」を参照してください。 |
弱いアフィニティは、Nodelist 優先順位より優先されます。
その他のリソースグループの現在の状態によっては、任意のノード上で、強いアフィニティが成立しないことがあります。このような状況では、アフィニティのソースであるリソースグループはオフラインのままです。その他のリソースグループの状態が変更され、強いアフィニティが成立できるようになると、アフィニティのソースであるリソースグループはオンラインに戻ります。
1 つのソースリソースグループに複数のターゲットリソースグループに対する強いアフィニティを宣言するときには注意してください。宣言されたすべての強いアフィニティが成立しない場合、ソースリソースグループはオフラインのままになるためです。
あるリソースグループのサービスが別のリソースグループのサービスに強く依存する場合、これらのリソースグループは両方とも同じノード上で動作する必要があります。たとえば、あるアプリケーションがお互いに依存する複数のサービスのデーモンから構成される場合、すべてのデーモンは同じノード上で動作する必要があります。
このような状況では、依存するサービスのリソースグループを、強制的に、依存されるサービスのリソースグループと同じ場所に配置するように指定します。あるリソースグループを強制的に別のリソースグループと同じ場所に配置するには、あるリソースグループに別のリソースグループに対する強い肯定的なアフィニティを宣言します。
# scrgadm -c|-a -g source-rg -y RG_affinities=++target-rg |
強い肯定的なアフィニティのソースであるリソースグループを指定します。このリソースグループは、別のリソースグループに対する強い肯定的なアフィニティを宣言するリソースグループです。
強い肯定的なアフィニティのターゲットであるリソースグループを指定します。このリソースグループは、強い肯定的なアフィニティが宣言されるリソースグループです。
強い肯定的なアフィニティを宣言しているソースのリソースグループは、ターゲットのリソースグループに従います。しかし、強い肯定的なアフィニティを宣言しているソースのリソースグループは、ターゲットのリソースグループが動作していないノードにはフェイルオーバーできません。
フェイルオーバーされないのは、リソースモニターが起動したフェイルオーバーだけです。ソースとターゲットの両方のリソースグループが動作しているノードに障害が発生した場合、これらのリソースグループは、正常に動作している同じノード上で再起動されます。
たとえば、リソースグループ rg1 にリソースグループ rg2 に対する強い肯定的なアフィニティが宣言されていると仮定します。 rg2 が別のノードにフェイルオーバーするとrg1 もそのノードにフェイルオーバーします。この場合、rg1 内のすべてのリソースが操作可能であるとしても、rg1 はそのノードにフェイルオーバーします。しかし、rg1 内のリソースによって、rg2 が動作していないノードに rg1 がフェイルオーバーしようとした場合、このフェイルオーバーはブロックされます。
強い肯定的なアフィニティを宣言しているリソースグループをフェイルオーバーする必要がある場合、そのフェイルオーバーは委託する必要があります。詳細は、「リソースグループのフェイルオーバーまたはスイッチオーバーを委託する」を参照してください。
この例では、リソースグループ rg1 を変更して、リソースグループ rg2 に対する強い肯定的なアフィニティを宣言するためのコマンドを示します。このアフィニティを宣言すると、rg1 は rg2 が動作しているノード上だけでオンラインになります。この例では、両方のリソースグループが存在していると仮定します。
# scrgadm -c -g rg1 -y RG_affinities=++rg2 |
あるリソースグループのサービスが別のリソースグループのサービスを使用していることがあります。結果として、これらのサービスは、同じノード上で動作する場合にもっとも効率よく動作します。たとえば、データベースを使用するアプリケーションは、そのアプリケーションとデータベースが同じノード上で動作する場合に、もっとも効率よく動作します。しかし、これらのサービスは異なるノード上で動作してもかまいません。なぜなら、リソースグループのフェイルオーバーの増加よりも効率の低下のほうが被害が小さいためです。
このような状況では、両方のリソースグループを、できる限り、同じ場所に配置するように指定します。あるリソースグループと別のリソースグループをできる限り同じ場所に配置するには、あるリソースグループに別のリソースグループに対する弱い肯定的なアフィニティを宣言します。
# scrgadm -c|-a -g source-rg -y RG_affinities=+target-rg |
弱い肯定的なアフィニティのソースであるリソースグループを指定します。このリソースグループは、別のリソースグループに対する弱い肯定的なアフィニティを宣言するリソースグループです。
弱い肯定的なアフィニティのターゲットであるリソースグループを指定します。このリソースグループは、弱い肯定的なアフィニティを宣言するリソースグループです。
あるリソースグループに別のリソースグループに対する弱い肯定的なアフィニティを宣言することによって、両方のリソースグループが同じノードで動作する確率が上がります。弱い肯定的なアフィニティのソースは、まず、そのアフィニティのターゲットがすでに動作しているノード上でオンラインになろうとします。しかし、弱い肯定的なアフィニティのソースは、そのアフィニティのターゲットがリソースモニターによってフェイルオーバーされても、フェイルオーバーしません。同様に、弱い肯定的なアフィニティのソースは、そのアフィニティのターゲットがスイッチオーバーされても、フェイルオーバーしません。どちらの状況でも、ソースがすでに動作しているノード上では、ソースはオンラインのままです。
ソースとターゲットの両方のリソースグループが動作しているノードに障害が発生した場合、これらのリソースグループは、正常に動作している同じノード上で再起動されます。
この例では、リソースグループ rg1 を変更して、リソースグループ rg2 に対する弱い肯定的なアフィニティを宣言するためのコマンドを示します。このアフィニティを宣言すると、rg1 と rg2 はまず、同じノード上でオンラインになろうとします。しかし、rg2 内のリソースによって rg2 がフェイルオーバーしても、rg1 は最初にオンラインになったノード上でオンラインのままです。この例では、両方のリソースグループが存在していると仮定します。
# scrgadm -c -g rg1 -y RG_affinities=+rg2 |
リソースグループの集合の各リソースグループには、クラスタの同じ負荷をかけることができます。このような状況では、リソースグループをクラスタ間で均等に分散することによって、クラスタの負荷の均衡をとることができます。
リソースグループの集合のリソースグループをクラスタノード間で均等に分散するには、各リソースグループに、リソースグループの集合のほかのリソースグループに対する弱い否定的なアフィニティを宣言します。
# scrgadm -c|-a -g source-rg -y RG_affinities=-target-rg-list |
弱い否定的なアフィニティのソースであるリソースグループを指定します。このリソースグループは、その他のリソースグループに対する弱い否定的なアフィニティを宣言するリソースグループです。
弱い指定的なアフィニティのターゲットであるリソースグループをコンマで区切って指定します。これらのリソースグループは、弱い否定的なアフィニティが宣言されるリソースグループです。
あるリソースグループにその他のリソースグループに対する弱い否定的なアフィニティを宣言することによって、そのリソースグループが常に、もっとも負荷がかかっていないクラスタノード上でオンラインになることが保証されます。 このノード上で動作しているその他のリソースグループは最小数です。したがって、弱い否定的なアフィニティの最小数が違反されます。
この例では、リソースグループ rg1、rg2、rg3、および rg4 を変更して、これらのリソースグループを利用可能なクラスタノード間で均等に分散するためのコマンドを示します。この例では、リソースグループ rg1、rg2、rg3、および rg4 が存在していると仮定します。
# scrgadm -c -g rg1 RG_affinities=-rg2,-rg3,-rg4 # scrgadm -c -g rg2 RG_affinities=-rg1,-rg3,-rg4 # scrgadm -c -g rg3 RG_affinities=-rg1,-rg2,-rg4 # scrgadm -c -g rg4 RG_affinities=-rg1,-rg2,-rg3 |
クラスタは、重要なサービスと重要でないサービス組み合わせて動作するように構成できます。たとえば、重要な顧客サービスをサポートするデータベースは、重要でない研究タスクと同じクラスタで実行できます。
重要でないサービスが重要なサービスに影響を与えないようにするには、重要なサービスに優先権を指定します。重要なサービスに優先権を指定することによって、重要でないサービスが重要なサービスと同じノード上で動作することを防ぐことができます。
すべてのノードが操作可能であるとき、重要なサービスは重要でないサービスとは異なるノード上で動作します。しかし、重要なサービスに障害が発生すると、このサービスは重要でないサービスが動作しているノードにフェイルオーバーします。このような状況では、重要でないサービスは直ちにオフラインになり、重要なサービスはコンピューティングリソースを完全に利用できるようになります。
重要なサービスに優先権を指定するには、重要でない各サービスのリソースグループに、重要なサービスを含むリソースグループに対する強い否定的なアフィニティを宣言します。
# scrgadm -c|-a -g noncritical-rg -y RG_affinities=--critical-rg |
重要でないサービスを含むリソースグループを指定します。このリソースグループは、別のリソースグループに対する強い否定的なアフィニティを宣言するリソースグループです。
重要なサービスを含むリソースグループを指定します。このリソースグループは、強い否定的なアフィニティが宣言されるリソースグループです。
強い否定的なアフィニティのソースのリソースグループは、そのアフィニティのターゲットのリソースグループから離れます。
この例では、重要でないリソースグループ ncrg1 と ncrg2 を変更して、重要なリソースグループ mcdbrg に重要でないリソースグループよりも高い優先権を与えるためのコマンドを示します。この例では、リソースグループ mcdbrg、ncrg1、および ncrg2 が存在していると仮定します。
# scrgadm -c -g ncrg1 RG_affinities=--mcdbrg # scrgadm -c -g ncrg2 RG_affinities=--mcdbrg |
強い肯定的なアフィニティのソースリソースグループは、そのアフィニティのターゲットが動作していないノードにはフェイルオーバーまたはスイッチオーバーできません。強い肯定的なアフィニティのソースリソースグループをフェイルオーバーまたはスイッチオーバーする必要がある場合、そのフェイルオーバーはターゲットリソースグループに委託する必要があります。このアフィニティのターゲットがフェイルオーバーするとき、このアフィニティのソースはターゲットと一緒に強制的にフェイルオーバーされます。
++ オペレータで指定した強い肯定的なアフィニティのソースリソースグループでも、スイッチオーバーする必要がある場合もあります。このような状況では、このアフィニティのターゲットとソースを同時にスイッチオーバーします。
リソースグループのフェイルオーバーまたはスイッチオーバーを別のリソースグループに委託するには、そのリソースグループに、その他のリソースグループに対するフェイルオーバー委託付きの強い肯定的なアフィニティを宣言します。
# scrgadm -c|-a -g source-rg -y RG_affinities=+++target-rg |
フェイルオーバーまたはスイッチオーバーを委託するリソースグループを指定します。このリソースグループは、別のリソースグループに対するフェイルオーバー委託付きの強い肯定的なアフィニティを宣言するリソースグループです。
source-rg がフェイルオーバーまたはスイッチオーバーを委託するリソースグループを指定します。このリソースグループは、フェイルオーバー委託付きの強い肯定的なアフィニティが宣言されるリソースグループです。
あるリソースグループは、最大 1 つのリソースグループに対するフェイルオーバー委託付きの強い肯定的なアフィニティを宣言できます。逆に、あるリソースグループは、その他の任意の数のリソースグループによって宣言されたフェイルオーバー委託付きの強い肯定的なアフィニティのターゲットである可能性があります。
つまり、フェイルオーバー委託付きの強い肯定的なアフィニティは対照的ではありません。ソースがオフラインの場合でも、ターゲットはオンラインになることができます。しかし、ターゲットがオフラインの場合、ソースはオンラインになることができません。
ターゲットが第三のリソースグループに対するフェイルオーバー委託付きの強い肯定的なアフィニティを宣言する場合、フェイルオーバーまたはスイッチオーバーはさらに第三のリソースグループに委託されます。第三のリソースグループがフェイルオーバーまたはスイッチオーバーを実行すると、その他のリソースグループも強制的にフェイルオーバーまたはスイッチオーバーされます。
この例では、リソースグループ rg1 を変更して、リソースグループ rg2 に対するフェイルオーバー委託付きの強い肯定的なアフィニティを宣言するためのコマンドを示します。このアフィニティを宣言すると、 rg1 はフェイルオーバーまたはスイッチオーバーを rg2 に委託します。この例では、両方のリソースグループが存在していると仮定します。
# scrgadm -c -g rg1 -y RG_affinities=+++rg2 |
複数のアフィニティを組み合わせることによって、より複雑な動作を作成できます。たとえば、関連する複製サーバーにアプリケーションの状態を記録できます。この例におけるノード選択条件は次のとおりです。
複製サーバーは、アプリケーションと異なるノード上で動作している必要があります。
アプリケーションが現在のノードからフェイルオーバーすると、アプリケーションは、複製サーバーが動作しているノードにフェイルオーバーする必要があります。
アプリケーションが複製サーバーが動作しているノードにフェイルオーバーすると、複製サーバーは異なるノードにフェイルオーバーする必要があります。その他のノードが利用できない場合、複製サーバーはオフラインになる必要があります。
これらの条件を満たすには、アプリケーションと複製サーバーのリソースグループを次のように構成します。
アプリケーションを含むリソースグループは、複製サーバーを含むリソースグループに対する弱い肯定的なアフィニティを宣言します。
複製サーバーを含むリソースグループは、アプリケーションを含むリソースグループに対する強い否定的なアフィニティを宣言します。
この例では、次のリソースグループ間のアフィニティを組み合わせるためのコマンドを示します。
リソースグループ app-rg は、複製サーバーによって状態を追跡するアプリケーションを示します。
リソースグループ rep-rg は、複製サーバーを示します。
この例では、リソースグループはアフィニティを次のように宣言します。
リソースグループ app-rg は、リソースグループ rep-rg に対する弱い肯定的なアフィニティを宣言します。
リソースグループ rep-rg は、リソースグループ app-rg に対する強い否定的なアフィニティを宣言します。
この例では、両方のリソースグループが存在していると仮定します。
# scrgadm -c -g app-rg RG_affinities=+rep-rg # scrgadm -c -g rep-rg RG_affinities=--app-rg |