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を使用した場所制約の追加 #
Hawk2にログインします。
https://HAWKSERVER:7630/
左のナビゲーションバーから、
› › の順に選択します。固有の
を入力します。使用頻度の高い次の値は、ドロップダウンボックスからも設定できます。
ノードで強制的にリソースを実行するには、矢印アイコンをクリックして
Always
を選択します。これにより、スコアはINFINITY
に設定されます。ノードでリソースを実行しない場合、矢印アイコンをクリックして
Never
を選択します。これによりスコアは-INFINITY
に設定され、リソースはそのノードで実行してはならないことになります。スコアを
0
に設定するには、矢印アイコンをクリックしてAdvisory
を選択します。これにより制約が無効になります。これは、リソース検出を設定してもリソースを制約したくない場合に便利です。
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
ルールを設定で何度も重複して指定する必要があったため、設定内容が不必要に複雑でした。
次の例では、リソースセットloc-alice
が作成され、仮想IPアドレス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を使用したコロケーション制約の追加 #
Hawk2にログインします。
https://HAWKSERVER:7630/
左のナビゲーションバーから、
› › の順に選択します。固有の
を入力します。使用頻度の高い次の値は、ドロップダウンボックスからも設定できます。
同じノードで強制的にリソースを実行するには、矢印アイコンをクリックして
Always
を選択します。これにより、スコアはINFINITY
に設定されます。同じノードでリソースを実行しない場合、矢印アイコンをクリックして
Never
を選択します。これによりスコアは-INFINITY
に設定され、リソースは同じノードで実行してはならないことになります。
制約のリソースを定義するには、次の手順に従います。
リソースが追加され、下に新しい空のドロップダウンボックスが表示されます。
この手順を繰り返してリソースを追加します。
最上位のリソースは次のリソースなどに依存するため、クラスタはまず最後のリソースを置く場所を決め、次にその決定に基づいて依存するものを配置していきます。制約が満たされないと、クラスタは依存するリソースが実行しないようにすることがあります。
コロケーション制約内のリソースの順序を入れ替えるには、リソースの横にある上矢印アイコンをクリックして、その上のエントリと入れ替えます。
必要に応じて、各リソースに追加のパラメータ(
Started
、Stopped
、Promote
、Demote
など)を指定します。リソースの横にある空のドロップダウンボックスをクリックし、必要なエントリを選択します。
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を使用した順序制約の追加 #
Hawk2にログインします。
https://HAWKSERVER:7630/
左のナビゲーションバーから、
› › の順に選択します。固有の
を入力します。使用頻度の高い次の値は、ドロップダウンボックスからも設定できます。
順序制約を必須にするには、矢印アイコンをクリックして
Mandatory
を選択します。順序制約を推奨のみにするには、矢印アイコンをクリックして
Optional
を選択します。Serialize
: リソースに対して2つの停止/開始アクションが同時に実行されないようにするには、矢印アイコンをクリックしてSerialize
を選択します。これにより、1つのリソースの開始が完了しないと他のリソースを開始できなくなります。通常は、起動時にホストに高い負荷をかけるリソースに使用します。
順序の制約の場合、オプション
は常に有効にしていてください。これは、リソースを停止するときには逆順で行うという指定です。制約のリソースを定義するには、次の手順に従います。
リソースが追加され、下に新しい空のドロップダウンボックスが表示されます。
この手順を繰り返してリソースを追加します。
一番上のリソースが最初に開始され、次に2番目に開始されます。通常、リソースは逆の順序で停止されます。
順序制約内のリソースの順序を入れ替えるには、リソースの横にある上矢印アイコンをクリックして、その上のエントリと入れ替えます。
必要に応じて、各リソースに追加のパラメータ(
Started
、Stopped
、Promote
、Demote
など)を指定します。リソースの横にある空のドロップダウンボックスをクリックし、必要なエントリを選択します。変更を確認して、設定を完了します。画面上部に、アクションが成功したかどうかを示すメッセージが表示されます。
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でリソースセットを使用して制約を定義する #
場所制約内でリソースセットを使用するには:
ステップ 4を除いて、手順7.1「場所制約の追加」で説明されている手順に従って進行します。1つのリソースを選択する代わりに、CtrlまたはShiftを押しながらマウスをクリックすることによって、複数のリソースを選択します。これにより、場所制約内でリソースセットが作成されます。
場所制約からリソースを削除するには、Ctrlを押しながらリソースを再度クリックして、選択解除します。
コロケーションまたは順序の制約内でリソースセットを使用するには:
手順7.2「コロケーション制約の追加」または手順7.3「順序制約の追加」の説明に従います。ただし、制約に対してリソースを定義する手順(ステップ 5.aまたはステップ 6.a)は除きます。
複数のリソースを追加します。
リソースセットを作成するため、リソースの横にあるチェーンアイコンをクリックして、そのリソースを上のリソースにリンクします。リソースセットは、セットに属しているリソースの周囲のフレームによって示されます。
リソースセット内の複数のリソースを結合したり、複数のリソースセットを作成したりできます。
図 7.4: Hawk2 - コロケーション制約の2つのリソースセット #上のリソースからリソースをリンク解除するには、そのリソースの横にあるハサミアイコンをクリックします。
変更を確認して、制約の設定を完了します。
7.7.2 crmshでリソースセットを使用して制約を定義する #
たとえば、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つの例を検討します。
<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つの例を検討します。
<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>
順序付けされたリソースを持つリソースセットを使用して、同様な目的を達成できます。
<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のいずれかを使用してリソースフェールオーバーノードを指定できます。
たとえば、リソース「rsc1
」に場所の制約を設定し、このリソースを「alice
」で優先的に実行するように指定したと仮定します。そこで失敗すると、migration-threshold
がチェックされ、失敗回数と比較されます。failcount
>= 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を使用したリソースフェールオーバーノードの指定 #
Hawk2にログインします。
https://HAWKSERVER:7630/
手順7.1「場所制約の追加」に記されている手順に従って、そのリソースの場所の制約を設定します。
手順 8.1: リソースまたはグループの変更、ステップ 5に説明されている手順に従ってリソースに
migration-threshold
メタ属性を追加し、migration-thresholdの値を入力します。INFINITYではない正の値を指定する必要があります。リソースの失敗回数を自動的に失効させるにはは、手順 6.2: Hawk2を使用したプリミティブリソースの追加、ステップ 5で説明されているようにに、
failure-timeout
メタ属性をそのリソースに追加し、failure-timeout
の を入力します。図 7.5: Hawk2: リソースフェールオーバーのメタ属性 #リソースの初期設定として、追加のフェールオーバーノードを指定する場合は、追加の場所の制約を作成します。
リソースの失敗回数は、自動的に期限切れにする代わりに、いつでも、手動でクリーンアップすることもできます。詳細については、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
の値:リソースはシステム内で最適な場所に配置されます。現在よりも「状態のよい」、または負荷の少ないノードが使用可能になると、移動することを意味しています。このオプションは自動フェールバックとほとんど同じですが、以前アクティブだったノード以外のノードにリソースを移動できるという点が異なります。これはPacemakerのデフォルトです。
0
より大きい値:リソースは現在の場所に留まることを望んでいますが、状態がよいノードが使用可能になると移動される可能性があります。値が大きくなるほど、リソースが現在の場所に留まることを強く望んでいることを示します。
0
より小さい値:リソースは現在の場所から別な場所に移動することを望んでいます。絶対値が大きくなるほど、リソースが移動を強く望んでいることを示します。
INFINITY
の値:ノードがリソースの実行権利がなくなったために強制終了される場合(ノードのシャットダウン、ノードのスタンバイ、
migration-threshold
に到達、または設定変更)以外は、リソースは常に現在の場所に留まります。このオプションは自動フェールバックを無効にする場合とほとんど同じです。-INFINITY
の値:リソースは現在の場所から常に移動されます。
7.9.1 Hawk2を使用したリソースフェールバックノードの指定 #
Hawk2にログインします。
https://HAWKSERVER:7630/
resource-stickiness
、手順 8.1: リソースまたはグループの変更に従って、ステップ 5メタ属性をリソースに追加します。resource-stickiness
を-INFINITY
とINFINITY
の間の値に指定します。図 7.6: Hawk2: リソースフェールバックのメタ属性 #
7.10 負荷インパクトに基づくリソースの配置 #
すべてのリソースが同等ではありません。Xenゲストなどの一部のリソースでは、そのホストであるノードがリソースの容量要件を満たす必要があります。リソースの組み合わされたニーズが提供された容量より大きくなるようにリソースが配置されると、リソースのパフォーマンスが低下します(あるいは失敗することさえあります)。
これを考慮に入れて、SUSE Linux Enterprise High Availabilityでは、次のパラメータを指定できます。
一定のノードが提供する容量
一定のリソースが要求する容量
リソースの配置に関する全体的なストラテジ
Hawk2またはcrmshのいずれかを使用してこれらを設定できます。
ノードは、リソースの要件を満たすだけの空き容量があれば、そのリソースに対して資格があるとみなされます。リソースの要件とノードが提供する容量を手動で設定するには、使用属性を使用します。使用属性に任意の名前を付け、設定に必要なだけ名前/値のペアを定義します。ただし、属性値は、整数にする必要があります。
使用属性を持つ複数のリソースがグループ化されていたり、これらにコロケーション制約がある場合、SUSE Linux Enterprise High Availabilityではそのことを考慮に入れます。可能な場合、これらのリソースは、「すべての」容量要件を満たすことができるノードに配置されます。
リソースグループに対して使用属性を直接設定することはできません。ただし、グループの設定を簡素化するために、グループ内のすべてのリソースに必要な合計容量を含む使用属性を追加することができます。
SUSE Linux Enterprise High Availabilityには、ノードの容量とリソースの要件を自動的に検出し、設定する手段も用意されています。
NodeUtilization
リソースエージェントは、ノードの容量をチェックします(CPUとRAMについて)。自動検出を設定するには、クラス、プロバイダ、タイプがocf:pacemaker:NodeUtilization
のクローンリソースを作成します。このクローンのインスタンスが各ノードに1つずつ実行している必要があります。インスタンスが開始すると、CIBでそのノードの設定にutilizationセクションが追加されます。詳細については、crm ra info NodeUtilization
を参照してください。
リソースの最小要件の自動検出(RAMとCPU)に配慮し、Xen
リソースエージェントが改良されました。Xen
リソースは、開始時点でRAMとCPUの消費状況を反映します。リソース設定には、使用属性が自動的に追加されます。
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
のみが必要です。混乱を避けるために、不要な属性を無効にすることをお勧めします。例:
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
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を使用した負荷インパクトに基づくリソースの配置 #
使用属性は、リソースの要件と、ノードが提供する容量の両方を設定するために使用されます。リソースが要求する容量を設定するには、その前にノードの容量を設定する必要があります。
Hawk2にログインします。
https://HAWKSERVER:7630/
左のナビゲーションバーから、
› の順に選択します。名前は任意です(
RAM_in_GB
など)。属性を追加するには、
アイコンをクリックします。属性の隣の空のテキストボックスに、属性値を入力します。値は整数にする必要があります。
図 7.7: Hawk2: ノード使用属性の編集 #必要なだけ使用属性を追加し、これらの属性すべての値を追加します。
変更内容を確認します。画面上部に、アクションが成功したかどうかを示すメッセージが表示されます。
プリミティブリソースを作成するときや、既存のプリミティブリソースを編集するときに、特定のリソースがノードに要求する容量を設定します。
リソースに使用属性を追加する前に、手順 7.7で説明するように、クラスタノードの使用属性を設定しておく必要があります。
Hawk2にログインします。
https://HAWKSERVER:7630/
既存のリソースに使用属性を追加するには、8.2.1項 「Hawk2を使用したリソースおよびグループの編集」に示すように、 › の順に移動して、[リソース設定]ダイアログを開きます。
新しいリソースを作成する場合、6.4.1項 「Hawk2を使用したプリミティブリソースの作成」に示すように、 › の順に移動して進みます。
[リソース設定]ダイアログで、
カテゴリに移動します。空のドロップダウンボックスから、手順 7.7でノードに対して設定した使用属性のいずれかを選択します。
属性の隣の空のテキストボックスに、属性値を入力します。値は整数にする必要があります。
必要なだけ使用属性を追加し、これらの属性すべての値を追加します。
変更内容を確認します。画面上部に、アクションが成功したかどうかを示すメッセージが表示されます。
ノードが提供する容量とリソースが要求する容量を設定してから、配置ストラテジをグローバルクラスタオプションに設定します。そうしないと、容量設定は有効になりません。負荷のスケジュールに使用できるストラテジがいくつかあります。たとえば、負荷をできるだけ少ない数のノードに集中したり、使用可能なすべてのノードに均等に分散できます。
Hawk2にログインします。
https://HAWKSERVER:7630/
左のナビゲーションバーから、
› を選択し、各画面を開きます。グローバルクラスタオプション、およびリソースと操作のデフォルトが表示されます。画面上部にある空のドロップダウンボックスから、
placement-strategy
を選択します。デフォルトでは、その値は
に設定され、使用属性と値が考慮されていないことを意味します。要件に応じて、
を適切な値に設定します。変更内容を確認します。
7.10.2 crmshを使用した負荷インパクトに基づくリソースの配置 #
リソースの要件とノードが提供する容量を設定するには、使用属性を使用します。使用属性に任意の名前を付け、設定に必要なだけ名前/値のペアを定義します。いくつかのエージェントは、たとえばVirtualDomain
などの使用を更新します。
次の例では、クラスタのノードとリソースの基本設定がすでに完了していることを想定しています。さらに、特定のノードが提供する容量と特定のリソースが必要とする容量を設定します。
crm
で使用属性を追加または変更する #root
としてログインし、crm
対話型シェルを開始します。#
crm configure
ノードが提供する容量を指定するには、次のコマンドを使用し、プレースホルダNODE_1をノードの名前に置き換えます。
crm(live)configure#
node NODE_1 utilization hv_memory=16384 cpu=8
これらの値によって、NODE_1は16 GBのメモリと8つのCPUコアをリソースに提供すると想定されます。
リソースが要求する容量を指定するには、次のコマンドを使用します。
crm(live)configure#
primitive xen1 Xen ... \ utilization hv_memory=4096 cpu=4
これによって、リソースはNODE_1からの4096のメモリ単位と4つのCPUユニットを使用します。
property
コマンドを使用して、配置ストラテジを設定します。crm(live)configure#
property
...次の値を使用できます。
default
(デフォルト値)使用値は考慮しません。リソースは、場所のスコアに従って割り当てられます。スコアが同じであれば、リソースはノード間で均等に分散されます。
utilization
リソースの要件を満たすだけの空き容量がノードにあるかどうか決定する際に、利用率を確認します。ただし、負荷分散は、まだ、ノードに割り当てられたリソースの数に基づいて行われます。
minimal
リソースの要件を満たすだけの空き容量がノードにあるかどうか決定する際に、利用率を確認します。できるだけ少ない数のノードにリソースを集中しようとします(残りのノードの電力節約のため)。
balanced
リソースの要件を満たすだけの空き容量がノードにあるかどうか決定する際に、利用率を確認します。リソースを均等に分散して、リソースのパフォーマンスを最適化しようとします。
注記: リソース優先度の設定使用できる配置ストラテジは、最善策であり、まだ、複雑なヒューリスティックソルバで、常に最適な割り当て結果を得るには至っていません。リソースの優先度を正しく設定して、最重要なリソースが最初にスケジュールされるようにしてください。
変更をコミットしてから、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 詳細の参照先 #
制約の設定の詳細や、順序付けおよびコロケーションの基本的な概念についての詳しいバックグラウンド情報はhttps://www.clusterlabs.org/pacemaker/doc/にある次のドキュメントを参照してください。
『Pacemaker Explained』、「Resource Constraints」の章
Colocation Explained
Ordering Explained