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