目次にジャンプページナビゲーションにジャンプ: 前のページ[アクセスキーp]/次のページ[アクセスキーn]
documentation.suse.com / SUSE Linux Enterprise High Availability Extensionのドキュメント / 管理ガイド / 設定および管理 / リソース制約の設定
適用項目 SUSE Linux Enterprise High Availability Extension 15 SP5

7 リソース制約の設定

 

すべてのリソースを設定する以外にも、多くの作業が必要です。クラスタが必要なすべてのリソースを認識しても、正しく処理できるとは限りません。リソースの制約を指定して、リソースを実行可能なクラスタノード、リソースのロード順序、特定のリソースが依存している他のリソースを指定することができます。

7.1 制約のタイプ

 

使用可能な制約には3種類あります。

リソースの場所

場所の制約はリソースを実行できるノード、できないノード、または実行に適したノードを定義するものです。

リソースのコロケーション

コロケーション制約は、ノード上で一緒に実行可能な、または一緒に実行することが禁止されているリソースをクラスタに伝えます。

リソースの順序

アクションの順序を定義する、順序の制約です。

重要
重要: 制約および特定のタイプのリソースに関する制限

  • リソースグループの「メンバー」に対してコロケーション制約を作成しないでください。代わりに、リソースグループ全体を指すリソース制約を作成してください。その他のタイプの制約はすべて、リソースグループのメンバーに対して使用しても問題ありません。

  • クローンリソースまたはプロモータブルクローンリソースが適用されているリソースで制約を使用しないでください。制約はクローンまたはプロモータブルクローンリソースに適用する必要があり、その子リソースに適用することはできません。

7.2 スコアと無限大

 

制約を定義する際は、スコアも扱う必要があります。あらゆる種類のスコアはクラスタの動作方法と密接に関連しています。スコアの操作によって、リソースのマイグレーションから、速度が低下したクラスタで停止するリソースの決定まで、あらゆる作業を実行できます。スコアはリソースごとに計算され、リソースに対して負のスコアが付けられているノードは、そのリソースを実行できません。リソースのスコアを計算した後、クラスタはスコアが最も高いノードを選択します。

INFINITYは現在1,000,000と定義されています。この値の増減は、次の3つの基本ルールに従います。

  • 任意の値+ INFINITY = INFINITY

  • 任意の値- INFINITY = -INFINITY

  • INFINITY - INFINITY = -INFINITY

リソース制約を定義する際は、各制約のスコアを指定します。スコアはこのリソース制約に割り当てる値を示します。スコアの高い制約は、それよりもスコアが低い制約より先に適用されます。1つのリソースに対して場所の制約を複数作成し、それぞれに異なるスコアを指定することで、リソースがフェールオーバーするノードの順序を指定できます。

7.3 リソーステンプレートと制約

 

リソーステンプレートを定義したら(6.8項 「リソーステンプレートの作成」を参照)、次のタイプの制約で参照できます。

  • 順序の制約

  • コロケーション制約

  • rsc_ticket制約(Geoクラスタの場合)

ただし、コロケーション制約には、テンプレートへの参照を複数含めることはできません。リソースセットには、テンプレートへの参照を含めることはできません。

制約内で参照されたリソーステンプレートは、そのテンプレートから派生するすべてのプリミティブを表します。これは、そのリソーステンプレートを参照しているすべてのプリミティブリソースに、この制約が適用されることを意味します。制約内でリソーステンプレートを参照すれば、リソースセットの代替となり、クラスタ設定をかなりの程度単純化することができます。リソースセットの詳細については、7.7項 「リソースセットを使用して制約を定義する」を参照してください。

7.4 場所制約の追加

 

場所制約は、リソースを実行できるノード、実行に適したノード、または実行できないノードを決定します。たとえば、場所制約により、特定のデータベースに関連するすべてのリソースを同じノードに配置します。この種類の制約は、各リソースに複数追加できます。すべてのlocation制約は、所定のリソースに関して評価されます。

Hawk2またはcrmshのいずれかを使用して場所制約を追加できます。

7.4.1 Hawk2を使用した場所制約の追加

 
手順 7.1: 場所制約の追加
 

  1. Hawk2にログインします。 

    https://HAWKSERVER:7630/

  2. 左のナビゲーションバーから、環境設定 ›  Add Constraint (制約の追加) ›  Location (場所)の順に選択します。

  3. 固有の制約IDを入力します。

  4. Resources (リソース)のリストから、制約を定義するリソースを1つまたは複数選択します。

  5. スコアにスコアを入力します。スコアはこのリソース制約に割り当てる値を示します。正の値は、次のステップで指定するノードでリソースを実行できることを示します。負の値は、リソースをそのノードで実行すべきではないことを示します。スコアの高い制約は、それよりもスコアが低い制約より先に適用されます。

    使用頻度の高い次の値は、ドロップダウンボックスからも設定できます。

    • ノードで強制的にリソースを実行するには、矢印アイコンをクリックしてAlwaysを選択します。これにより、スコアはINFINITYに設定されます。

    • ノードでリソースを実行しない場合、矢印アイコンをクリックしてNever (実行しない)を選択します。これによりスコアは-INFINITYに設定され、リソースはそのノードで実行してはならないことになります。

    • スコアを0に設定するには、矢印アイコンをクリックしてAdvisory (推奨値)を選択します。これにより制約が無効になります。これは、リソース検出を設定してもリソースを制約したくない場合に便利です。

  6. ノードを選択します。

  7. 作成をクリックして、設定を完了します。画面上部に、アクションが成功したかどうかを示すメッセージが表示されます。

Hawk2 - 場所制約
図 7.1: Hawk2 - 場所制約
 

7.4.2 crmshを使用した場所制約の追加

 

locationコマンドは、リソースを実行できるノード、できないノード、または実行に適したノードを定義するものです。

fs1というIDを持つリソースをaliceという名前のノード上で実行するプリファレンスを100にする簡単な例を次に示します。 

crm(live)configure# location loc-fs1 fs1 100: alice

もう1つの例は、pingによる場所の設定です。 

crm(live)configure# primitive ping ping \
    params name=ping dampen=5s multiplier=100 host_list="r1 r2"
crm(live)configure# clone cl-ping ping meta interleave=true
crm(live)configure# location loc-node_pref internal_www \
    rule 50: #uname eq alice \
    rule ping: defined ping

パラメータhost_listは、pingおよびカウントするホストのスペースで区切られたリストです。場所の制約のもう1つの使用例は、「リソースセット」としてのプリミティブのグループ化です。これは、たとえば、いくつかのリソースがネットワーク接続のping属性によって異なるときに役立つ場合があります。以前は、-inf/pingルールを設定で何度も重複して指定する必要があったため、設定内容が不必要に複雑でした。

次の例では、仮想IPアドレスloc-aliceおよびvip1を参照して、リソースセットvip2を作成します。 

crm(live)configure# primitive vip1 IPaddr2 params ip=192.168.1.5
crm(live)configure# primitive vip2 IPaddr2 params ip=192.168.1.6
crm(live)configure# location loc-alice { vip1 vip2 } inf: alice

ある場合には、locationコマンドでリソースパターンを使用すると、より効率的で便利です。リソースパターンは、2つのスラッシュ間の正規表現です。たとえば、前に示した仮想IPアドレスは、次とすべて一致させることができます。 

crm(live)configure# location loc-alice /vip.*/ inf: alice

7.5 コロケーション制約の追加

 

コロケーション制約は、ノード上で一緒に実行可能な、または一緒に実行することが禁止されているリソースをクラスタに伝えます。コロケーション制約はリソース間の依存関係を定義するため、コロケーション制約を作成するには、少なくとも2つのリソースが必要です。

Hawk2またはcrmshのいずれかを使用してコロケーション制約を追加できます。

7.5.1 Hawk2を使用したコロケーション制約の追加

 
手順 7.2: コロケーション制約の追加
 

  1. Hawk2にログインします。 

    https://HAWKSERVER:7630/

  2. 左のナビゲーションバーから、環境設定 ›  Add Constraint (制約の追加) › コロケーションの順に選択します。

  3. 固有の制約IDを入力します。

  4. スコアにスコアを入力します。スコアは複数のリソースの場所の関係を決定します。正の値は、リソースを同じノードで実行しなければならないことを示します。負の値は、リソースを同じノードで実行するべきではないことを示します。スコアと他の要因との組み合わせによって、ノードの配置先が決定します。

    使用頻度の高い次の値は、ドロップダウンボックスからも設定できます。

    • 同じノードで強制的にリソースを実行するには、矢印アイコンをクリックしてAlwaysを選択します。これにより、スコアはINFINITYに設定されます。

    • リソースを同じノードで実行しない場合、矢印アイコンをクリックしてNever (実行しない)を選択します。これによりスコアは-INFINITYに設定され、リソースは同じノードで実行してはならないことになります。

  5. 制約のリソースを定義するには、次の手順に従います。

    1. リソースカテゴリのドロップダウンボックスから、リソース(またはテンプレート)を選択します。

      リソースが追加され、下に新しい空のドロップダウンボックスが表示されます。

    2. この手順を繰り返してリソースを追加します。

      最上位のリソースは次のリソースなど順に依存するため、クラスタはまず最後のリソースを置く場所を決め、次にその決定に基づいて依存するものを配置していきます。制約が満たされないと、クラスタは依存するリソースが実行しないようにすることがあります。

    3. コロケーション制約内のリソースの順序を入れ替えるには、リソースの横にある上矢印アイコンをクリックして、その上のエントリと入れ替えます。

  6. 必要に応じて、各リソースの他のパラメータ(Started、Stopped、Promote、Demoteなど)を指定します。リソースの横にある空のドロップダウンボックスをクリックして、目的のエントリを選択します。

  7. 作成をクリックして、設定を完了します。画面上部に、アクションが成功したかどうかを示すメッセージが表示されます。

Hawk2 - コロケーション制約
図 7.2: Hawk2 - コロケーション制約
 

7.5.2 crmshを使用したコロケーション制約の追加

 

colocationコマンドは、同じホストまたは別のホストで実行するべきリソースを定義するために使用します。

常に同じノードで実行する必要があるリソース、または同じノードで実行してはならないリソースを定義する場合には、それぞれ+infまたは-infのスコアを設定することだけが可能です。無限大以外のスコアの使用も可能です。その場合、コロケーションはadvisoryと呼ばれ、衝突が発生したときに他のリソースが停止しないようにするため、クラスタがそれらの制約に従わないこともあります。

たとえば、リソースresource1とresource2を常に同じホスト上で実行するには、次の制約を使用します。 

crm(live)configure# colocation coloc-2resource inf: resource1 resource2

プライマリ/セカンダリ設定では、現在のノートがプライマリかどうかと、リソースをローカルに実行しているかどうかを把握することが必要です。

7.6 順序制約の追加

 

順序の制約を使用して、開始、停止、プライマリへの昇格など、別のリソースが特殊な条件を満たす直前または直後に、サービスを開始または停止できます。たとえば、デバイスがシステムで利用できるようになるまで、ファイルシステムはマウントできません。順序制約はリソース間の依存関係を定義するため、順序制約を作成するには、少なくとも2つのリソースを作成する必要があります。

Hawk2またはcrmshのいずれかを使用して順序制約を追加できます。

7.6.1 Hawk2を使用した順序制約の追加

 
手順 7.3: 順序制約の追加
 

  1. Hawk2にログインします。 

    https://HAWKSERVER:7630/

  2. 左のナビゲーションバーから、環境設定 ›  Add Constraint (制約の追加) › 順序の順に選択します。

  3. 固有の制約IDを入力します。

  4. スコアにスコアを入力します。スコアがゼロより大きい場合、順序制約は必須になりますが、そうでない場合はオプションです。

    使用頻度の高い次の値は、ドロップダウンボックスからも設定できます。

    • 順序制約を必須にする場合、矢印アイコンをクリックしてMandatory (必須)を選択します。

    • 順序制約を提案のみにする場合、矢印アイコンをクリックしてOptional (オプション)を選択します。

    • Serialize (順番に処理): リソースに対して2つの停止/開始アクションが同時に実行されないようにするには、矢印アイコンをクリックしてSerialize (順番に処理)を選択します。これにより、1つのリソースの開始が完了しないと他のリソースを開始できなくなります。通常は、起動時にホストに高い負荷をかけるリソースに使用します。

  5. 順序の制約の場合、オプションシンメトリックは常に有効にしていてください。これは、リソースを停止するときには逆順で行うという指定です。

  6. 制約のリソースを定義するには、次の手順に従います。

    1. リソースカテゴリのドロップダウンボックスから、リソース(またはテンプレート)を選択します。

      リソースが追加され、下に新しい空のドロップダウンボックスが表示されます。

    2. この手順を繰り返してリソースを追加します。

      一番上のリソースが最初に開始され、次に2番目に開始されます。通常、リソースは逆の順序で停止されます。

    3. 順序制約内のリソースの順序を入れ替えるには、リソースの横にある上矢印アイコンをクリックして、その上のエントリと入れ替えます。

  7. 必要に応じて、各リソースの他のパラメータ(Started、Stopped、Promote、Demoteなど)を指定します。リソースの横にある空のドロップダウンボックスをクリックして、目的のエントリを選択します。

  8. 変更を確認して、設定を完了します。画面上部に、アクションが成功したかどうかを示すメッセージが表示されます。

Hawk2 - 順序制約
図 7.3: Hawk2 - 順序制約
 

7.6.2 crmshを使用した順序制約の追加

 

orderコマンドは、アクションのシーケンスを定義します。

たとえば、常にresource1をresource2の前に開始するには、次の制約を使用します。 

crm(live)configure# order res1_before_res2 Mandatory: resource1 resource2

7.7 リソースセットを使用して制約を定義する

 

場所、コロケーション、または順序の制約を定義するための別のフォーマットとして、resource setsを使用することができます。リソースセットでは、プリミティブが1つのセットでグループ化されます。以前は、これはリソースグループを定義するか(デザインを正確に表現できない場合もあった)、個々の制約として各関係を定義することでこの操作が可能でした。個々の制約として定義した場合、多数のリソースとの組み合わせが増えるにつれて、制約が飛躍的に増加しました。リソースセットを介した設定で、冗長性が常に低減されるわけではありませんが、定義内容の把握と管理がより容易になります。

Hawk2またはcrmshのいずれかを使用してリソースセットを設定できます。

7.7.1 Hawk2でリソースセットを使用して制約を定義する

 
手順 7.4: 制約のためにリソースセットを使用する
 

  1. 場所制約内でリソースセットを使用するには:

    1. 手順7.1「場所制約の追加」の説明に従って操作を進めます。ただし、ステップ 4は除きます。1つのリソースを選択する代わりに、CtrlまたはShiftを押しながらマウスをクリックして、複数のリソースを選択します。これにより、場所制約内でリソースセットが作成されます。

    2. 場所制約からリソースを削除するには、Ctrlを押しながらリソースを再度クリックして、選択解除します。

  2. コロケーションまたは順序の制約内でリソースセットを使用するには:

    1. 手順7.2「コロケーション制約の追加」または手順7.3「順序制約の追加」の説明に従います。ただし、制約に対してリソースを定義する手順(ステップ 5.aまたはステップ 6.a)は除きます。

    2. 複数のリソースを追加します。

    3. リソースセットを作成するため、リソースの横にあるチェーンアイコンをクリックして、そのリソースを上のリソースにリンクします。リソースセットは、セットに属しているリソースの周囲のフレームによって示されます。

    4. リソースセット内の複数のリソースを結合したり、複数のリソースセットを作成したりできます。

      Hawk2 - コロケーション制約の2つのリソースセット
      図 7.4: Hawk2 - コロケーション制約の2つのリソースセット
       

    5. 上のリソースからリソースをリンク解除するには、そのリソースの横にあるハサミアイコンをクリックします。

  3. 変更を確認して、制約の設定を完了します。

7.7.2 crmshでリソースセットを使用して制約を定義する

 
例 7.1: 場所制約のリソースセット
 

たとえば、crmshでリソースセット(loc-alice)の次の設定を使用して、2つの仮想IP (vip1とvip2)を同じノードaliceに配置できます。 

crm(live)configure# primitive vip1 IPaddr2 params ip=192.168.1.5
crm(live)configure# primitive vip2 IPaddr2 params ip=192.168.1.6
crm(live)configure# location loc-alice { vip1 vip2 } inf: alice

リソースセットを使用してコロケーション制約の設定を置き換える場合は、次の2つの例を検討します。

例 7.2: コロケートされたリソースのチェーン
 
<constraints>
    <rsc_colocation id="coloc-1" rsc="B" with-rsc="A" score="INFINITY"/>
    <rsc_colocation id="coloc-2" rsc="C" with-rsc="B" score="INFINITY"/>
    <rsc_colocation id="coloc-3" rsc="D" with-rsc="C" score="INFINITY"/>
</constraints>

リソースセットで表される同一の設定: 

<constraints>
   <rsc_colocation id="coloc-1" score="INFINITY" >
    <resource_set id="colocated-set-example" sequential="true">
     <resource_ref id="A"/>
     <resource_ref id="B"/>
     <resource_ref id="C"/>
     <resource_ref id="D"/>
    </resource_set>
   </rsc_colocation>
</constraints>

リソースセットを使用して順序の制約の設定を置き換える場合は、次の2つの例を検討します。

例 7.3: 順序付けされたリソースのチェーン
 
<constraints>
    <rsc_order id="order-1" first="A" then="B" />
    <rsc_order id="order-2" first="B" then="C" />
    <rsc_order id="order-3" first="C" then="D" />
</constraints>

順序付けされたリソースを持つリソースセットを使用して、同様な目的を達成できます。

例 7.4: リソースセットとして表される順序付けされたリソースのチェーン
 
<constraints>
    <rsc_order id="order-1">
    <resource_set id="ordered-set-example" sequential="true">
    <resource_ref id="A"/>
    <resource_ref id="B"/>
    <resource_ref id="C"/>
    <resource_ref id="D"/>
    </resource_set>
    </rsc_order>
</constraints>

これらのセットは、順序付けされている(sequential=true)場合もあれば、順序付けされていない場合(sequential=false)場合もあります。また、require-all属性を使用して、ANDおよびORロジック間を切り替えることができます。

7.7.3 依存性なしのリソースセットのコロケーション

 

同じノード上にリソースのグループを配置する方が役立つ場合がありますが(コロケーション制約を定義)、リソース間に困難な依存関係を持つことはありません。たとえば、同じノード上に2つのリソースを配置したいが、それらの一方で障害が発生した場合に他方をクラスタで再起動したくない場合があります。

これは、weak-bondコマンドを使用して、crmシェルで実行できます。 

# crm configure assist weak-bond resource1 resource2

weak-bondコマンドの実装により、指定されたリソースを持つダミーリソースとコロケーション制約が自動的に作成されます。

7.8 リソースフェールオーバーノードの指定

 

リソースに障害が発生すると、自動的に再起動されます。現在のノードで再起動できない場合、または現在のノードでN回失敗した場合は、別のノードへのフェールオーバーが試行されます。リソースが失敗するたびに、その失敗回数が増加します。新しいノードへのマイグレートを行う基準(migration-threshold)となるリソースの失敗をいくつか定義できます。クラスタ内に3つ以上ノードがある場合、特定のリソースのフェールオーバー先のノードはHigh Availabilityソフトウェアが選択します。

ただし、リソースに1つ以上の場所の制約とmigration-thresholdを設定することで、そのリソースのフェールオーバー先にするノードを指定できます。

Hawk2またはcrmshのいずれかを使用してリソースフェールオーバーノードを指定できます。

例 7.5: マイグレーションしきい値 - プロセスフロー
 

たとえば、リソース「rsc1」に場所の制約を設定し、このリソースを「alice」で優先的に実行するように指定したと仮定します。そのノードで実行できなかった場合は、「migration-threshold」を確認して失敗回数と比較します。失敗回数 >= マイグレーションしきい値の場合は、リソースは次の優先実行先として指定されているノードにマイグレートされます。

デフォルトでは、いったんしきい値に達すると、そのノードでは、リソースの失敗回数がリセットされるまで、失敗したリソースを実行できなくなります。これは、手動でクラスタ管理者が行うか、リソースにfailure-timeoutオプションを設定することで実行できます。

たとえば、migration-threshold=2とfailure-timeout=60sを設定すると、リソースは、2回の失敗の後に新しいノードに移行します。そして、1分後に復帰できます(固着性と制約のスコアによる)。

移行しきい値の概念には2つの例外があり、これらの例外は、リソースの開始失敗か、停止失敗のどちらかで発生します。

  • 起動の失敗では、失敗回数がINFINITYに設定されるので、常に、即時に移行が行われます。

  • 停止時の失敗ではフェンシングが発生します(stonith-enabledがデフォルトであるtrueに設定されている場合)。

    STONITHリソースが定義されていない場合は(またはstonith-enabledがfalseに設定されている場合)、リソースの移行は行われません。

7.8.1 Hawk2を使用したリソースフェールオーバーノードの指定

 
手順 7.5: フェールオーバーノードの指定
 

  1. Hawk2にログインします。 

    https://HAWKSERVER:7630/

  2. 手順7.1「場所制約の追加」に記されている手順に従って、そのリソースの場所の制約を設定します。

  3. migration-threshold、手順 8.1: リソースまたはグループの変更に説明されている手順に従ってリソースにステップ 5メタ属性を追加し、migration-thresholdの値を入力します。INFINITYではない正の値を指定する必要があります。

  4. リソースの失敗回数を自動的に失効させる場合は、failure-timeout、手順 6.2: Hawk2を使用したプリミティブリソースの追加に説明されている手順に従ってステップ 5メタ属性をそのリソースに追加し、の値failure-timeoutを入力します。

    Image

  5. リソースの初期設定として、追加のフェールオーバーノードを指定する場合は、追加の場所の制約を作成します。

リソースの失敗回数は、自動的に期限切れにする代わりに、いつでも、手動でクリーンアップすることもできます。詳細については、8.5.1項 「Hawk2を使用したクラスタリソースのクリーンアップ」を参照してください。

7.8.2 crmshを使用したリソースフェールオーバーノードの指定

 

リソースフェールオーバーを判定するには、メタ属性migration-thresholdを使用します。すべてのノードで失敗回数がmigration-thresholdを超えると、リソースは停止したままになります。例: 

crm(live)configure# location rsc1-alice rsc1 100: alice

通常、rsc1はaliceで実行されます。そのノードで実行できなかった場合は、「migration-threshold」を確認して失敗回数と比較します。failcount >= migration-thresholdの場合、リソースは次の優先実行先として指定されているノードにマイグレートされます。

開始が失敗すると、start-failure-is-fatalオプションによっては、失敗回数がinfに設定されます。stopの失敗により、フェンシングが発生します。STONITHが定義されていない場合には、リソースは移行しません。

7.9 リソースフェールバックノードの指定(リソースの固着性)

 

ノードがオンライン状態に戻り、クラスタ内にある場合は、リソースが元のノードにフェールバックすることがあります。リソースを実行していたノードにリソースをフェールバックさせたくない場合や、リソースのフェールバック先として別のノードを指定する場合は、リソースの固着性の値を変更します。リソースの固着性は、リソースの作成時でも、その後でも指定できます。

リソース固着性値の指定時には、次の予想される結果について考慮してください。

0の値:

これがデフォルトの設定です。リソースはシステム内で最適な場所に配置されます。現在よりも「状態のよい」、または負荷の少ないノードが使用可能になると、移動することを意味しています。このオプションは自動フェールバックとほとんど同じですが、以前アクティブだったノード以外でもリソースをフェールバックできるという点が異なります。

0より大きい値:

リソースは現在の場所に留まることを望んでいますが、状態がよいノードが使用可能になると移動される可能性があります。値が大きくなるほど、リソースが現在の場所に留まることを強く望んでいることを示します。

0より小さい値:

リソースは現在の場所から別な場所に移動することを望んでいます。絶対値が大きくなるほど、リソースが移動を強く望んでいることを示します。

INFINITYの値:

ノードがリソースの実行権利がなくなったために強制終了される場合(ノードのシャットダウン、ノードのスタンバイ、migration-thresholdに到達、または設定変更)以外は、リソースは常に現在の場所に留まります。このオプションは自動フェールバックを無効にする場合とほとんど同じです。

-INFINITYの値:

リソースは現在の場所から常に移動されます。

7.9.1 Hawk2を使用したリソースフェールバックノードの指定

 
手順 7.6: リソースの固着性の指定
 

  1. Hawk2にログインします。 

    https://HAWKSERVER:7630/

  2. resource-stickiness、手順 8.1: リソースまたはグループの変更に従って、ステップ 5メタ属性をリソースに追加します。

  3. resource-stickinessの-INFINITYとINFINITY間の値を指定します。

    Image

7.10 負荷インパクトに基づくリソースの配置

 

すべてのリソースが同等ではありません。Xenゲストなどの一部のリソースでは、そのホストであるノードがリソースの容量要件を満たす必要があります。リソースの組み合わされたニーズが提供された容量より大きくなるようにリソースが配置されると、リソースのパフォーマンスが低下します(あるいは失敗することさえあります)。

これを考慮に入れて、High Availability Extensionでは、次のパラメータを指定できます。

  1. 一定のノードが提供する容量

  2. 一定のリソースが要求する容量

  3. リソースの配置に関する全体的なストラテジ

Hawk2またはcrmshのいずれかを使用してこれらを設定できます。

ノードは、リソースの要件を満たすだけの空き容量があれば、そのリソースに対して資格があるとみなされます。リソースの要件とノードが提供する容量を手動で設定するには、使用属性を使用します。使用属性に任意の名前を付け、設定に必要なだけ名前/値のペアを定義します。ただし、属性値は、整数にする必要があります。

使用属性を持つ複数のリソースがグループ化されていたり、これらにコロケーション制約がある場合、High Availability Extensionではそのことを考慮に入れます。可能な場合、これらのリソースは、「すべての」容量要件を満たすことができるノードに配置されます。

注記
注記: グループの使用属性

リソースグループに対して使用属性を直接設定することはできません。ただし、グループの設定を簡素化するために、グループ内のすべてのリソースに必要な合計容量を含む使用属性を追加することができます。

High Availability Extensionには、ノードの容量とリソースの要件を自動的に検出し、設定する手段も用意されています。

NodeUtilizationリソースエージェントは、ノードの容量をチェックします(CPUとRAMについて)。自動検出を設定するには、クラス、プロバイダ、タイプがocf:pacemaker:NodeUtilizationのクローンリソースを作成します。このクローンのインスタンスが各ノードに1つずつ実行している必要があります。インスタンスが開始すると、CIBでそのノードの設定にutilizationセクションが追加されます。詳細については、crm ra info NodeUtilizationを参照してください。

リソースの最小要件の自動検出(RAMとCPU)に配慮し、Xenリソースエージェントが改良されました。Xenリソースは、開始時点でRAMとCPUの消費状況を反映します。リソース設定には、使用属性が自動的に追加されます。

注記
注記: Xenとlibvirtに異なるリソースエージェントを適用

ocf:heartbeat:Xenリソースエージェントは、libvirtに使用するべきではありません。libvirtではマシン記述ファイルの変更が想定されているためです。

libvirtには、ocf:heartbeat:VirtualDomainリソースエージェントを使用します。

最小要件を検出することに加え、VirtualDomainリソースエージェントを通して現在の利用状況を監視することができ、仮想マシンでのCPUとRAMの使用状況を検出します。この機能を使用するには、クラス、プロバイダ、およびタイプがocf:heartbeat:VirtualDomainのリソースを設定します。次のインスタンス属性を使用できます:

  • autoset_utilization_cpu

  • autoset_utilization_hv_memory (Xen用)またはautoset_utilization_host_memory (KVM用)

これらの属性のデフォルトはtrueです。これにより、監視サイクルのたびにCIBで使用値が更新されます。詳細については、crm ra info VirtualDomainを参照してください。

注記
注記: hv_memory および host_memory

NodeUtilizationおよびVirtualDomainリソースエージェントでは、hv_memoryおよびhost_memoryはデフォルトで両方ともtrueです。ただし、Xenはhv_memoryのみを必要とし、KVMはhost_memoryのみを必要とします。混乱を避けるために、不要な属性を無効にすることをお勧めします。例:

例 7.6: hv_memoryを無効にしてKVM用のリソースエージェントを作成する
 
# crm configure primitive p_nu NodeUtilization \
      params utilization_hv_memory=false \
      op monitor timeout=20s interval=60
# crm configure primitive p_vm VirtualDomain \
      params autoset_utilization_hv_memory=false \
      op monitor timeout=30s interval=10s
例 7.7: host_memoryを無効にしてXen用のリソースエージェントを作成する
 
# crm configure primitive p_nu NodeUtilization \
      params utilization_host_memory=false \
      op monitor timeout=20s interval=60
# crm configure primitive p_vm VirtualDomain \
      params autoset_utilization_host_memory=false \
      op monitor timeout=30s interval=10s

容量と要件を手動と自動のどちらで設定する場合でも、placement-strategyプロパティ(グローバルクラスタオプション内)で、配置ストラテジを指定する必要があります。次の値を使用できます。

default (デフォルト値)

使用値は考慮しません。リソースは、場所のスコアに従って割り当てられます。スコアが同じであれば、リソースはノード間で均等に分散されます。

utilization

リソースの要件を満たすだけの空き容量がノードにあるかどうか決定する際に、利用率を確認します。ただし、負荷分散は、まだ、ノードに割り当てられたリソースの数に基づいて行われます。

minimal

リソースの要件を満たすだけの空き容量がノードにあるかどうか決定する際に、利用率を確認します。できるだけ少ない数のノードにリソースを集中しようとします(残りのノードの電力節約のため)。

balanced

リソースの要件を満たすだけの空き容量がノードにあるかどうか決定する際に、利用率を確認します。リソースを均等に分散して、リソースのパフォーマンスを最適化しようとします。

注記
注記: リソース優先度の設定

使用できる配置ストラテジは、最善策であり、まだ、複雑なヒューリスティックソルバで、常に最適な割り当て結果を得るには至っていません。リソースの優先度を正しく設定して、最重要なリソースが最初にスケジュールされるようにしてください。

7.10.1 Hawk2を使用した負荷インパクトに基づくリソースの配置

 

使用属性は、リソースの要件と、ノードが提供する容量の両方を設定するために使用されます。リソースが要求する容量を設定するには、その前にノードの容量を設定する必要があります。

手順 7.7: ノードが提供する容量の設定
 

  1. Hawk2にログインします。 

    https://HAWKSERVER:7630/

  2. 左のナビゲーションバーから、監視機能 › 状態の順に選択します。

  3. ノードタブで、容量を設定するノードを選択します。

  4. 操作列で、下矢印アイコンをクリックして編集を選択します。

    ノードの編集画面が開きます。

  5. 使用率の下で、使用属性の名前を空のドロップダウンボックスに入力します。

    名前は任意です(RAM_in_GBなど)。

  6. 属性を追加するには、追加アイコンをクリックします。

  7. 属性の隣の空のテキストボックスに、属性値を入力します。値は整数にする必要があります。

    Image

  8. 必要なだけ使用属性を追加し、これらの属性すべての値を追加します。

  9. 変更内容を確認します。画面上部に、アクションが成功したかどうかを示すメッセージが表示されます。

手順 7.8: リソースが要求する容量の設定
 

プリミティブリソースを作成するときや、既存のプリミティブリソースを編集するときに、特定のリソースがノードに要求する容量を設定します。

リソースに使用属性を追加する前に、手順 7.7で説明するように、クラスタノードの使用属性を設定しておく必要があります。

  1. Hawk2にログインします。 

    https://HAWKSERVER:7630/

  2. 既存のリソースに使用属性を追加する場合、8.2.1項 「Hawk2を使用したリソースとグループの編集」に示すように、Manage (管理) › 状態の順に移動して、［リソース設定］ダイアログを開きます。

    新しいリソースを作成する場合、6.4.1項 「Hawk2を使用したプリミティブリソースの作成」に示すように、設定 › Add Resource (リソースの追加)の順に移動して進みます。

  3. ［リソース設定］ダイアログで、使用率カテゴリに移動します。

  4. 空のドロップダウンボックスから、手順 7.7でノードに対して設定した使用属性のいずれかを選択します。

  5. 属性の隣の空のテキストボックスに、属性値を入力します。値は整数にする必要があります。

  6. 必要なだけ使用属性を追加し、これらの属性すべての値を追加します。

  7. 変更内容を確認します。画面上部に、アクションが成功したかどうかを示すメッセージが表示されます。

ノードが提供する容量とリソースが要求する容量を設定してから、配置ストラテジをグローバルクラスタオプションに設定します。そうしないと、容量設定は有効になりません。負荷のスケジュールに使用できるストラテジがいくつかあります。たとえば、負荷をできるだけ少ない数のノードに集中したり、使用可能なすべてのノードに均等に分散できます。

手順 7.9: 配置ストラテジの設定
 

  1. Hawk2にログインします。 

    https://HAWKSERVER:7630/

  2. 左のナビゲーションバーから、環境設定 › クラスタ設定を選択し、各画面を開きます。グローバルクラスタオプション、およびリソースと操作のデフォルトが表示されます。

  3. 画面上部にある空のドロップダウンボックスから、placement-strategyを選択します。

    デフォルトでは、その値はデフォルトに設定され、使用属性と値が考慮されていないことを意味します。

  4. 要件に応じて、配置ストラテジを適切な値に設定します。

  5. 変更内容を確認します。

7.10.2 crmshを使用した負荷インパクトに基づくリソースの配置

 

リソースの要件とノードが提供する容量を設定するには、使用属性を使用します。使用属性に任意の名前を付け、設定に必要なだけ名前/値のペアを定義します。いくつかのエージェントは、たとえばVirtualDomainなどの使用を更新します。

次の例では、クラスタのノードとリソースの基本設定がすでに完了していることを想定しています。さらに、特定のノードが提供する容量と特定のリソースが必要とする容量を設定します。

手順 7.10: crmで使用属性を追加または変更する
 

  1. rootとしてログインし、crm対話型シェルを開始します。 

    # crm configure

  2. ノードが提供する容量を指定するには、次のコマンドを使用し、プレースホルダNODE_1をノードの名前に置き換えます。 

    crm(live)configure# node NODE_1 utilization hv_memory=16384 cpu=8

    これらの値によって、NODE_1は16 GBのメモリと8つのCPUコアをリソースに提供すると想定されます。

  3. リソースが要求する容量を指定するには、次のコマンドを使用します。 

    crm(live)configure# primitive xen1 Xen ... \
      utilization hv_memory=4096 cpu=4

    これによって、リソースはNODE_1からの4,096のメモリ単位と4つのCPU単位を使用します。

  4. propertyコマンドを使用して、配置ストラテジを設定します。 

    crm(live)configure# property ...

    次の値を使用できます。

    default (デフォルト値)

    使用値は考慮しません。リソースは、場所のスコアに従って割り当てられます。スコアが同じであれば、リソースはノード間で均等に分散されます。

    utilization

    リソースの要件を満たすだけの空き容量がノードにあるかどうか決定する際に、利用率を確認します。ただし、負荷分散は、まだ、ノードに割り当てられたリソースの数に基づいて行われます。

    minimal

    リソースの要件を満たすだけの空き容量がノードにあるかどうか決定する際に、利用率を確認します。できるだけ少ない数のノードにリソースを集中しようとします(残りのノードの電力節約のため)。

    balanced

    リソースの要件を満たすだけの空き容量がノードにあるかどうか決定する際に、利用率を確認します。リソースを均等に分散して、リソースのパフォーマンスを最適化しようとします。

    注記
    注記: リソース優先度の設定

    使用できる配置ストラテジは、最善策であり、まだ、複雑なヒューリスティックソルバで、常に最適な割り当て結果を得るには至っていません。リソースの優先度を正しく設定して、最重要なリソースが最初にスケジュールされるようにしてください。

  5. 変更をコミットしてから、crmshを終了します。 

    crm(live)configure# commit

次の例は、同等のノードから成る3ノードクラスタと4つの仮想マシンを示しています。 

crm(live)configure# node alice utilization hv_memory="4000"
crm(live)configure# node bob utilization hv_memory="4000"
crm(live)configure# node charlie utilization hv_memory="4000"
crm(live)configure# primitive xenA Xen \
    utilization hv_memory="3500" meta priority="10" \
    params xmfile="/etc/xen/shared-vm/vm1"
crm(live)configure# primitive xenB Xen \
    utilization hv_memory="2000" meta priority="1" \
    params xmfile="/etc/xen/shared-vm/vm2"
crm(live)configure# primitive xenC Xen \
    utilization hv_memory="2000" meta priority="1" \
    params xmfile="/etc/xen/shared-vm/vm3"
crm(live)configure# primitive xenD Xen \
    utilization hv_memory="1000" meta priority="5" \
    params xmfile="/etc/xen/shared-vm/vm4"
crm(live)configure# property placement-strategy="minimal"

3ノードはすべてアクティブであり、まずxenAがノードに配置され、次にxenDが配置されます。xenBとxenCは、一緒に割り当てられるか、またはどちらか1つがxenDとともに割り当てられます。

1つのノードに障害が発生した場合、残りのノード上で利用できるメモリ合計が少なすぎて、これらのリソースすべてはホストできません。xenAは確実に割り当てられ、xenDも同様です。ただし、xenBまたはxenCのいずれかしか配置できず、その優先度は同じであるため、結果はまだ定義されていません。これを解決するためにも、どちらかに高い優先度を設定する必要があります。

7.11 詳細の参照先

 

制約の設定の詳細や、順序付けおよびコロケーションの基本的な概念についての詳しいバックグラウンド情報はhttp://www.clusterlabs.org/pacemaker/doc/にある次のドキュメントを参照してください:

  • 『Pacemaker Explained』、「Resource Constraints」の章

  • Colocation Explained

  • Ordering Explained