第17章 複数のノードでアクティブなクラスターリソース (クローンリソース) の作成

クラスターリソースが複数のノードでアクティブになるように、リソースのクローンを作成できます。たとえば、ノードの分散のために、クローンとなるリソースを使用して、クラスター全体に分散させる IP リソースのインスタンスを複数構成できます。リソースエージェントが対応していれば、任意のリソースのクローンを作成できます。クローンは、1 つのリソースまたは 1 つのリソースグループで構成されます。

注記

同時に複数のノードでアクティブにできるリソースのみがクローンに適しています。たとえば、共有メモリーデバイスから ext4 などの非クラスター化ファイルシステムをマウントする Filesystem リソースのクローンは作成しないでください。ext4 パーティションはクラスターを認識しないため、同時に複数のノードから繰り返し行われる読み取りや書き込みの操作には適していません。

17.1. クローンリソースの作成および削除

リソースの作成と、そのリソースのクローン作成を同時に行う場合は、次のコマンドを使用します。

RHEL 8.4 以降:

pcs resource create resource_id [standard:[provider:]]type [resource options] [meta resource meta options] clone [clone_id] [clone options]

RHEL 8.3 以前:

pcs resource create resource_id [standard:[provider:]]type [resource options] [meta resource meta options] clone [clone options]

デフォルトでは、クローンの名前は resource_id-clone となります。RHEL 8.4 の時点では、clone _id オプションの値を指定して、クローン にカスタムな名前を設定できます。

1 つのコマンドで、リソースグループの作成と、リソースグループのクローン作成の両方を行うことはできません。

作成済みリソースまたはリソースグループのクローンを作成する場合は、次のコマンドを実行します。

RHEL 8.4 以降:

pcs resource clone resource_id | group_id [clone_id] [clone options]...

RHEL 8.3 以前:

pcs resource clone resource_id | group_id [clone options]...

デフォルトでは、クローンの名前は resource_id-clone または group_name-clone になります。RHEL 8.4 の時点では、clone _id オプションの値を指定して、クローン にカスタムな名前を設定できます。

注記

リソース設定の変更が必要なのは、1 つのノードのみです。

注記

制約を設定する場合は、グループ名またはクローン名を必ず使用します。

リソースのクローンを作成すると、デフォルトでは、クローンは -clone が名前に追加されているリソースの名前になります。次のコマンドは、タイプが apache のリソース webfarm と、そのクローンとなるリソース webfarm-clone を作成します。

# pcs resource create webfarm apache clone
注記

あるリソースまたはリソースグループのクローンを、別のクローンの後にくるように作成する場合は、多くの場合 interleave=true オプションを設定する必要があります。これにより、依存されているクローンが同じノードで停止または開始した時に、依存しているクローンのコピーを停止または開始できるようになります。このオプションを設定しない場合は、次のようになります。クローンリソース B がクローンリソース A に依存していると、ノードがクラスターから離れてから戻ってきてから、そのノードでリソース A が起動すると、リソース B の全コピーが、全ノードで再起動します。これは、依存しているクローンリソースに interleave オプションが設定されていない場合は、そのリソースの全インスタンスが、そのリソースが依存しているリソースの実行インスタンスに依存するためです。

リソースまたはリソースグループのクローンを削除する場合は、次のコマンドを使用します。リソースやリソースグループ自体は削除されません。

pcs resource unclone resource_id | clone_id | group_name

表17.1「リソースのクローンオプション」 には、クローンのリソースに指定できるオプションを示します。

表17.1 リソースのクローンオプション

フィールド説明

priority, target-role, is-managed

表10.3「リソースのメタオプション」 に従って、クローンされたリソースから継承されるオプション。

clone-max

起動するリソースのコピーの数。デフォルトは、クラスター内のノード数です。

clone-node-max

1 つのノードで起動できるリソースのコピー数。デフォルト値は 1 です。

notify

クローンのコピーを停止したり起動する時に、前もって、およびアクションが成功した時に、他のコピーに通知します。使用できる値は false および true です。デフォルト値は false です。

globally-unique

クローンの各コピーで異なる機能を実行させるかどうか。使用できる値は false および true です。

このオプションの値を false にすると、リソースが実行しているすべてのノードで同じ動作を行うため、1 台のマシンごとに実行できるクローンのコピーは 1 つです。

このオプションの値を true にすると、任意のマシンで実行中のクローンのコピーが、別のインスタンスが別のノードまたは同じノードで実行されているかに関係なく、そのインスタンスと同等ではありません。clone-node-max の値が「1」より大きい場合にはデフォルト値が true になり、小さい場合は false がデフォルト値になります。

ordered

コピーを、(並列ではなく) 連続して開始する必要があります。使用できる値は false および true です。デフォルト値は false です。

interleave

(クローン間の) 順序制約の動作を変更して、(2 番目のクローンの全インスタンスが終了するまで待機する代わりに) 2 番目のクローンと同じノードにあるコピーが起動または停止するとすぐに、最初のクローンのコピーが起動または停止できるようにします。使用できる値は false および true です。デフォルト値は false です。

clone-min

このフィールドに値を指定した場合は、interleave オプションが true に設定されていても、元のクローンの後に順序付けされたクローンは、元のクローンに指定された数だけインスタンスが実行するまで、起動できません。

安定した割り当てパターンを実現するために、クローンは、デフォルトでわずかに固定 (sticky) されています。これは、クローンが実行しているノードにとどまることをわずかに優先することを示します。resource-stickiness の値を指定しないと、クローンが使用する値は 1 となります。値を小さくすることで他のリソースのスコア計算への阻害を最小限に抑えながら、Pacemaker によるクラスター内の不要なコピーの移動を阻止することができます。resource-stickiness リソース のメタオプションを設定する方法は、「リソースのメタオプションの設定」を参照してください。

17.2. クローンリソース制約の表示

ほとんどの場合、アクティブなクラスターノードに対するクローンのコピーは 1 つです。ただし、リソースクローンの clone-max には、そのクラスター内のノード合計より小さい数を設定できます。この場合は、リソースの場所の制約を使用して、クラスターが優先的にコピーを割り当てるノードを指定できます。これらの制約は、クローンの ID を使用する必要があることを除いて、通常のリソースの制約と同じように記述されます。

次のコマンドは、クラスターがリソースのクローン webfarm-clonenode1 に優先的に割り当てる場所の制約を作成します。

# pcs constraint location webfarm-clone prefers node1

順序制約の動作はクローンでは若干異なります。以下の例では、interleave クローンオプションをデフォルトの false のままにしているため、起動する必要がある webfarm-clone のすべてのインスタンスが起動するまで、webfarm-stats のインスタンスは起動しません。webfarm-clone のコピーを 1 つも起動できない場合にのみ、webfarm-stats がアクティブになりません。さらに、webfarm-stats が停止するまで待機してから、webfarm-clone が停止します。

# pcs constraint order start webfarm-clone then webfarm-stats

通常のリソース (またはリソースグループ) とクローンのコロケーションは、リソースを、クローンのアクティブコピーを持つ任意のマシンで実行できることを意味します。クラスターは、クローンが実行している場所と、リソース自体の場所の優先度に基づいてコピーを選択します。

クローン間のコロケーションも可能です。この場合、クローンに対して許可できる場所は、そのクローンが実行中のノード (または実行するノード) に限定されます。割り当ては通常通り行われます。

以下のコマンドは、コロケーション制約を作成し、webfarm-stats リソースが webfarm-clone のアクティブなコピーと同じノードで実行するようにします。

# pcs constraint colocation add webfarm-stats with webfarm-clone

17.3. 昇格可能なクローンリソースの作成

昇格可能なクローンリソースは、promotable メタ属性が true に設定されているクローンリソースです。昇格可能なクローンリソースにより、インスタンスの操作モードは、Master および Slave のいずれかにできます。モードの名前には特別な意味はありませんが、インスタンスの起動時に、Slave 状態で起動する必要があるという制限があります。

17.3.1. 昇格可能なリソースの作成

次のコマンドを実行すると、リソースを昇格可能なクローンとして作成できます。

RHEL 8.4 以降:

pcs resource create resource_id [standard:[provider:]]type [resource options] promotable [clone_id] [clone options]

RHEL 8.3 以前:

pcs resource create resource_id [standard:[provider:]]type [resource options] promotable [clone options]

デフォルトでは、昇格可能なクローンの名前は resource_id-clone となります。RHEL 8.4 の時点では、clone _id オプションの値を指定して、クローン にカスタムな名前を設定できます。

また、次のコマンドを使用して、作成済みのリソースまたはリソースグループから、昇格可能なリソースを作成することもできます。

RHEL 8.4 以降:

pcs resource promotable resource_id [clone_id] [clone options]

RHEL 8.3 以前:

pcs resource promotable resource_id [clone options]

デフォルトでは、昇格可能なクローンの名前は resource_id-clone または group_name-clone になります。RHEL 8.4 の時点では、clone _id オプションの値を指定して、クローン にカスタムな名前を設定できます。

表17.2「昇格可能なクローンに利用できる追加のクローンオプション」 には、昇格可能なリソースに指定できる追加クローンオプションを示します。

表17.2 昇格可能なクローンに利用できる追加のクローンオプション

フィールド説明

promoted-max

昇格できるリソースのコピー数。デフォルト値は 1 です。

promoted-node-max

1 つのノードで昇格できるリソースのコピー数。デフォルト値は 1 です。

17.3.2. 昇格可能なリソース制約の表示

ほとんどの場合、昇格可能なリソースには、アクティブなクラスターノードごとに 1 つのコピーがあります。そうではない場合は、リソースの場所制約を使用して、クラスターが優先的にコピーを割り当てるノードを指定できます。これらの制約は、通常のリソースと同様に記述されます。

リソースのロールをマスターにするかスレーブにするかを指定するコロケーション制約を作成できます。次のコマンドは、リソースのコロケーション制約を作成します。

pcs constraint colocation add [master|slave] source_resource with [master|slave] target_resource [score] [options]

コロケーションの制約を設定する方法は、「クラスターリソースのコロケーション」を参照してください。

昇格可能なリソースが含まれる順序制約を設定する場合に、リソースに指定できるアクションに、リソースのスレーブロールからマスターへのロールの昇格を指定する promote があります。また、demote を指定すると、マスターからスレーブにリソースを降格できます。

順序制約を設定するコマンドは次のようになります。

pcs constraint order [action] resource_id then [action] resource_id [options]

リソースの順序制約の詳細は、「クラスターリソースの実行順序の決定」を参照してください。

17.4. 障害時の昇格リソースの降格 (RHEL 8.3 以降)

昇格可能なリソースを設定できます。そのため、そのリソースの 昇格 または 監視 アクションが失敗した場合、またはリソースのクォーラムが失われると、リソースは降格されますが、完全に停止されることはありません。これにより、リソースを完全に停止したときに、手動で介入する必要がなくなります。

  • promote アクションの失敗時にプロモート可能なリソースを降格するように設定するには、以下の例のように on-fail 操作のメタオプションを demote に設定します。

    # pcs resource op add my-rsc promote on-fail="demote"
  • monitor アクションの失敗時にプロモート可能なリソースを降格するように設定するには、interval をゼロ以外の値に設定します。on-fail 操作のメタオプションを demote に設定します。 以下の例に示すように、ロールMaster に設定します。

    # pcs resource op add my-rsc monitor interval="10s" on-fail="demote" role="Master"
  • クラスターパーティションでクォーラムが失われると、昇格されたリソースが降格されますが、実行され続け、他のすべてのリソースが停止されるようにクラスターを設定するには、no-quorum-policy クラスタープロパティーを demote に設定します。

操作に denmote メタ属性を指定しても、リソースの昇格は影響を受けません。影響を受けるノードのプロモーションスコアが引き続き最高となっている場合は、再度昇格するように選択されます。


このページには機械翻訳が使用されている場合があります (詳細はこちら)。