ヘルプには複数の方法でアクセスできます。

helpサブコマンド(--helpオプションと混同しないこと)のほとんどすべての出力によって、テキストビューアが開きます。このテキストビューアは上下にスクロール可能で、ヘルプテキストが読みやすくなっています。テキストビューアを閉じるには、Qキーを押します。

ヒント: バッシュおよび対話型シェルでタブ補完機能を使用

crmshは、対話型シェルに対してだけではなく、バッシュでの直接的で完全なタブ補完機能をサポートしています。たとえば、「crm help config<Tab>」と入力してを押すと、対話型シェルと同様に単語が補完されます。

crmコマンドそのものは、次のように使用できます。

すでに説明した方法に加えて、crmshは、同期コマンド実行もサポートしています。これを有効にするには、-wオプションを使用します。crmを-wなしで起動した場合でも、後ほどユーザ初期設定のwaitをyesに設定すれば(options wait yes)、有効にすることができます。このオプションが有効化される場合、crmは遷移が終了するまで待機します。処理が開始すると毎回、進行状況を示すための点が印刷されます。同期コマンドの実行はresource startなどのコマンドにのみ適用できます。

注記: 管理サブコマンドと設定サブコマンド間の相違

crmツールには管理機能(サブコマンドresourcesおよびnode)があり、設定に使用できます(cib、configure)。

以降のサブセクションでは、crmツールの重要な側面について、その概要を示します。

リソースエージェントはクラスタ設定で常に操作する必要があるため、crmツールには、raコマンドが含まれています。このコマンドを使用して、リソースエージェントの情報を表示し、リソースエージェントを管理します(詳細は6.3.2項 「サポートされるリソースエージェントクラス」も参照)。

root # crm ra
crm(live)ra# 

コマンドclassesは、すべてのクラスとプロバイダを一覧表示します。

crm(live)ra# classes
 lsb
 ocf / heartbeat linbit lvm2 ocfs2 pacemaker
 service
 stonith
 systemd

クラス(およびプロバイダ)に使用できるすべてのリソースエージェントの概要を取得するには、listコマンドを使用します。

crm(live)ra# list ocf
AoEtarget           AudibleAlarm        CTDB                ClusterMon
Delay               Dummy               EvmsSCC             Evmsd
Filesystem          HealthCPU           HealthSMART         ICP
IPaddr              IPaddr2             IPsrcaddr           IPv6addr
LVM                 LinuxSCSI           MailTo              ManageRAID
ManageVE            Pure-FTPd           Raid1               Route
SAPDatabase         SAPInstance         SendArp             ServeRAID
...

リソースエージェントの概要は、infoで表示できます。

crm(live)ra# info ocf:linbit:drbd
This resource agent manages a DRBD* resource
as a master/slave resource. DRBD is a shared-nothing replicated storage
device. (ocf:linbit:drbd)

Master/Slave OCF Resource Agent for DRBD

Parameters (* denotes required, [] the default):

drbd_resource* (string): drbd resource name
    The name of the drbd resource from the drbd.conf file.

drbdconf (string, [/etc/drbd.conf]): Path to drbd.conf
    Full path to the drbd.conf file.

Operations' defaults (advisory minimum):

    start         timeout=240
    promote       timeout=90 
    demote        timeout=90 
    notify        timeout=90 
    stop          timeout=100
    monitor_Slave_0 interval=20 timeout=20 start-delay=1m
    monitor_Master_0 interval=10 timeout=20 start-delay=1m

ビューアは、「Q」を押すと終了できます。

ヒント: crmの直接使用

前の例では、crmコマンドの内部シェルを使用しました。ただし、必ずしも、それを使用する必要はありません。該当するサブコマンドをcrmに追加すれば、同じ結果が得られます。たとえば、すべてのOCFリソースエージェントを一覧するには、シェルに「crm ra list ocf」を入力すれば済みます。

crmshシェルスクリプトは、crmshサブコマンドをファイル内に列挙する便利な方法を提供します。これにより、特定の行をコメントしたり、これらのコメントを後で再生したりするのが簡単になります。crmshシェルスクリプトには「crmshサブコマンドのみ」を含めることができることに注意してください。他のコマンドは許可されていません。

crmshシェルスクリプトを使用するには、その前に特定のコマンドを使用してファイルを作成してください。たとえば、次のファイルにはクラスタのステータスが出力され、すべてのノードのリストが提供されます。

# A small example file with some crm subcommands
status
node list

ハッシュ記号(#)で始まる行はコメントなので、無視されます。行が長すぎる場合は、行末にバックスラッシュ(\)を挿入します。可読性を向上させるため、特定のサブコマンドに属する行をインデントすることをお勧めします。

このスクリプトを使用するには、次の方法のいずれかを使用します。

root # crm -f example.cli
root # crm < example.cli

すべてのクラスタノードから情報を収集して変更をすべて展開することは、鍵となるクラスタ管理タスクです。複数のノードで同じ手順を手動で実行するのはミスを起こしがちであるため、代わりにcrmshクラスタスクリプトを使用できます。

これらを「crmshシェルスクリプト」と混同しないでください(8.1.4項 「crmshのシェルスクリプトの使用」で説明)。

crmshシェルスクリプトとは対照的に、クラスタスクリプトでは次のような追加のタスクを実行します。

crmshクラスタスクリプトは、他のクラスタ管理ツールを置き換えるものではなく、クラスタ全体に対して統合化された方法でこれらのタスクを実行できるようにします。詳細については、http://crmsh.github.io/scripts/を参照してください。

root # crm script list

root # crm script show mailto
mailto (Basic)
MailTo

 This is a resource agent for MailTo. It sends email to a sysadmin
whenever  a takeover occurs.

1. Notifies recipients by email in the event of resource takeover

  id (required)  (unique)
      Identifier for the cluster resource
  email (required)
      Email address
  subject
      Subject

root # crm script verify mailto id=sysadmin email=tux@example.org
1. Ensure mail package is installed

        mailx

2. Configure cluster resources

        primitive sysadmin ocf:heartbeat:MailTo
                email="tux@example.org"
                op start timeout="10"
                op stop timeout="10"
                op monitor interval="10" timeout="10"

        clone c-sysadmin sysadmin

root # crm script run mailto id=sysadmin email=tux@example.org
INFO: MailTo
INFO: Nodes: alice, bob
OK: Ensure mail package is installed
OK: Configure cluster resources

root # crm status
[...]
 Clone Set: c-sysadmin [sysadmin]
     Started: [ alice bob ]

注記: 非推奨に関する注意

設定テンプレートの使用は非推奨で、今後削除される予定です。設定テンプレートはクラスタスクリプトに置き換えられます。8.1.5項 「crmshのクラスタスクリプトの使用」を参照してください。

設定テンプレートは、crmsh用の既成のクラスタ設定です。リソーステンプレート(8.4.3項 「リソーステンプレートの作成」の説明を参照)と混同しないでください。これらはクラスタ用のテンプレートで、crmシェル用ではありません。

設定テンプレートは、最小限の操作で、特定ユーザのニーズに合わせて調整できます。テンプレートで設定を作成する際には、警告メッセージでヒントが与えられます。これは、後から編集することができ、さらにカスタマイズできます。

次の手順は、簡単ですが機能的なApache設定を作成する方法を示しています。

詳細がわかっていれば、コマンドをさらに簡素化できます。次のコマンドをシェルで使用して、上記の手順を要約できます。

root # crm configure template \
   new g-intranet apache params \
   configfile="/etc/apache2/httpd.conf" ip="192.168.1.101"

内部crmシェルに入っている場合は、次のコマンドを使用します。

crm(live)configure template# new intranet apache params \
   configfile="/etc/apache2/httpd.conf" ip="192.168.1.101"

ただし、このコマンドは、設定テンプレートから設定を作成するだけです。設定をCIBに適用したり、コミットすることはありません。

シャドーイング設定は、異なる設定シナリオのテストに使用されます。複数のシャドウ設定を作成した場合は、1つ1つテストして変更を加えた影響を確認できます。

通常の処理は次のようになります。

設定の変更をクラスタにロードする前に、変更内容をptestでレビューすることを推奨します。ptestコマンドを指定すると、変更のコミットによって生じるアクションのダイアグラムを表示できます。ダイアグラムを表示するには、graphvizパッケージが必要です。次の例は監視操作を追加するスクリプトです。

root # crm configure
crm(live)configure# show fence-bob 
primitive fence-bob stonith:apcsmart \
        params hostlist="bob"
crm(live)configure# monitor fence-bob 120m:60s
crm(live)configure# show changed
primitive fence-bob stonith:apcsmart \
        params hostlist="bob" \
        op monitor interval="120m" timeout="60s"
crm(live)configure# ptest
crm(live)configure# commit

クラスタダイアグラムを出力するには、コマンドcrm configure graphを使用します。これにより現在の設定が現在のウィンドウに表示されるので、X11が必要になります。

SVG (Scalable Vector Graphics)を使用する場合は、次のコマンドを使用します。

root # crm configure graph dot config.svg svg

設定の一部またはすべてをローカルファイルまたはネットワークURLからロードできます。次の3つの異なる方法を定義できます。

ファイルmycluster-config.txtから新しい設定をロードするには、次の構文を使用します。

root # crm configure load push mycluster-config.txt

クラスタで使用できるRA(リソースエージェント)には3種類あります(背景情報については6.3.2項 「サポートされるリソースエージェントクラス」を参照)。新しいリソースをクラスタに追加するには、次の手順に従います。

類似した設定で複数のリソースを作成する場合、リソーステンプレートを使用すれば作業が簡単になります。基本的なバックグラウンド情報については、6.5.3項 「リソーステンプレートと制約」を参照してください。これらを、「通常の」テンプレート(8.1.6項 「設定テンプレートの使用」で説明したもの)と混同しないでください。次の構文を知るには、rsc_templateコマンドを使用してください。

root # crm configure rsc_template
usage: rsc_template <name> [<class>:[<provider>:]]<type>
        [params <param>=<value> [<param>=<value>...]]
        [meta <attribute>=<value> [<attribute>=<value>...]]
        [utilization <attribute>=<value> [<attribute>=<value>...]]
        [operations id_spec
            [op op_type [<attribute>=<value>...] ...]]

たとえば、次のコマンドは、ocf:heartbeat:Xenリソースと、デフォルト値および操作に由来するBigVMの名前を持つ新しいリソーステンプレートを作成します。

crm(live)configure# rsc_template BigVM ocf:heartbeat:Xen \
   params allow_mem_management="true" \
   op monitor timeout=60s interval=15s \
   op stop timeout=10m \
   op start timeout=10m

新しいリソーステンプレートを定義したら、それをプリミティブとして使用すること、または順序、コロケーション、またはrsc_ticketの制約で参照することができます。リソーステンプレートを参照するには、@記号を使用します。

crm(live)configure# primitive MyVM1 @BigVM \
   params xmfile="/etc/xen/shared-vm/MyVM1" name="MyVM1"

新しいプリミティブMy-VM1は、BigVMリソーステンプレートからすべてを継承します。たとえば、上の2つに等しいものは次のようになります。

crm(live)configure# primitive MyVM1 ocf:heartbeat:Xen \
   params xmfile="/etc/xen/shared-vm/MyVM1" name="MyVM1" \
   params allow_mem_management="true" \
   op monitor timeout=60s interval=15s \
   op stop timeout=10m \
   op start timeout=10m

オプションや操作を上書きしたい場合は、自分の(プリミティブの)定義を追加します。たとえば、次の新しいプリミティブMyVM2は監視操作のタイムアウトを2倍にしますが、その他はそのままに残します。

crm(live)configure# primitive MyVM2 @BigVM \
   params xmfile="/etc/xen/shared-vm/MyVM2" name="MyVM2" \
   op monitor timeout=120s interval=30s

リソーステンプレートは、そのテンプレートから派生するすべてのプリミティブを表すものとして、制約で参照することができます。これにより、クラスタ設定をいっそう簡潔かつクリアに行うことができます。リソーステンプレートは、場所の制約を除くすべての制約から参照することができます。コロケーション制約には、複数のテンプレート参照を含めることはできません。

crmからは、STONITHデバイスは単なる1つのリソースと認識されます。STONITHリソースを作成するには、次の手順に従います。

すべてのリソースを設定することは、ジョブのほんの一部分です。クラスタが必要なすべてのリソースを認識しても、正しく処理できるとは限りません。たとえば、DRBDのスレーブノードにファイルシステムをマウントしないようにしてください(実際、DRBDでは失敗します)。このような情報をクラスタが利用できるように、制約を定義します。

制約の詳細については、6.5項 「リソースの制約」を参照してください。

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

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

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

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

crm(live)configure# colocation nfs_on_filesystem inf: nfs_group filesystem_resource

root # crm configure assist weak-bond RES1 RES2

crm(live)configure# order nfs_after_filesystem mandatory: filesystem_resource nfs_group

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

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

通常、rsc1はaliceで実行されます。そこで失敗すると、migration-thresholdがチェックされ、失敗回数と比較されます。失敗回数がmigration-threshold以上の場合、次の候補のノードにマイグレートします。

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

概要については、6.5.4項 「フェールオーバーノード」を参照してください。

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

概要については、6.5.5項 「フェールバックノード」を参照してください。

一部のリソースは、メモリの最小量など、特定の容量要件を持っています。要件が満たされていない場合、リソースは全く開始しないか、またはパフォーマンスを下げた状態で実行されます。

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

パラメータと設定の詳細な背景情報については、6.5.6項 「負荷インパクトに基づくリソースの配置」を参照してください。

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

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

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

crm(live)configure# node alice utilization memory="4000"
crm(live)configure# node bob utilization memory="4000"
crm(live)configure# node charlie utilization memory="4000"
crm(live)configure# primitive xenA ocf:heartbeat:Xen \
    utilization hv_memory="3500" meta priority="10" \
    params xmfile="/etc/xen/shared-vm/vm1"
crm(live)configure# primitive xenB ocf:heartbeat:Xen \
    utilization hv_memory="2000" meta priority="1" \
    params xmfile="/etc/xen/shared-vm/vm2"
crm(live)configure# primitive xenC ocf:heartbeat:Xen \
    utilization hv_memory="2000" meta priority="1" \
    params xmfile="/etc/xen/shared-vm/vm3"
crm(live)configure# primitive xenD ocf:heartbeat: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は、そのどちらか1つしか割り当てられません。xenBとxenCの優先度は同等なので、結果はまだ未定義です。これを解決するためにも、どちらかに高い優先度を設定する必要があります。

リソースを監視するには、2つの方法(opキーワードで監視処理を定義するか、monitorコマンドを使用するか)があります。次の例では、Apacheリソースを設定し、opキーワードの使用で 60秒ごとに監視します。

crm(live)configure# primitive apache apache \
  params ... \
  op monitor interval=60s timeout=30s

同じことを次のようにしても実行できます。

crm(live)configure# primitive apache apache \
   params ...
crm(live)configure# monitor apache 60s:30s

概要については、6.4項 「リソース監視」を参照してください。

クラスタの一般的な要素の1つは、一緒の場所で見つける必要のあるリソースのセットです。連続的に開始し、逆の順序で停止します。この設定を簡単にするため、グループのコンセプトをサポートしています。次の例では、2つのプリミティブ(IPアドレスと電子メールリソース)を作成します。

グループメンバーの順序を変更するには、configureサブコマンドからmodgroupコマンドを使用します。プリミティブのEmailをPublic-IPの前に移動するには、次のコマンドを使用します(このコマンドは機能のデモのみを目的としています)。

crm(live)configure# modgroup g-mailsvc add Email before Public-IP

グループ(Emailなど)からリソースを削除する場合には、このコマンドを使用します。

crm(live)configure# modgroup g-mailsvc remove Email

概要については、6.3.5.1項 「グループ」を参照してください。

クローンは当初、IPアドレスのN個のインスタンスを開始し、負荷分散のためにクラスタ上に分散させる便利な方法と考えられていました。それらは、DLMとの統合、サブシステムおよびOCFS2のフェンシングなど、他の目的にも有効であることがわかってきました。どのようなリソースでも、リソースエージェントがサポートしていれば、クローン化できます。

クローンリソースの詳細については、6.3.5.2項 「クローン」を参照してください。

クラスタを管理する際には、コマンドcrm configure showで、クラスタ設定、グローバルオプション、プリミティブなどの現在のCIBオブジェクトを一覧表示します。

root # crm configure show
node 178326192: alice
node 178326448: bob
primitive admin_addr IPaddr2 \
        params ip=192.168.2.1 \
        op monitor interval=10 timeout=20
primitive stonith-sbd stonith:external/sbd \
        params pcmk_delay_max=30
property cib-bootstrap-options: \
        have-watchdog=true \
        dc-version=1.1.15-17.1-e174ec8 \
        cluster-infrastructure=corosync \
        cluster-name=hacluster \
        stonith-enabled=true \
        placement-strategy=balanced \
        standby-mode=true
rsc_defaults rsc-options: \
        resource-stickiness=1 \
        migration-threshold=3
op_defaults op-options: \
        timeout=600 \
        record-pending=true

多数のリソースがある場合、showの出力が冗長になります。出力を制限するには、リソースの名前を使用します。たとえば、プリミティブadmin_addrのみのプロパティを一覧表示するには、リソース名をshowに付加します。

root # crm configure show admin_addr
primitive admin_addr IPaddr2 \
        params ip=192.168.2.1 \
        op monitor interval=10 timeout=20

ただし、特定のリソースの出力をさらに制限したい場合があります。これは、「フィルタ」を使用して実現できます。フィルタは特定のコンポーネントに出力を制限します。たとえば、ノードのみを一覧表示するには、type:nodeを使用します。

root # crm configure show type:node
node 178326192: alice
node 178326448: bob

プリミティブにも興味がある場合には、orオペレータを使用します。

root # crm configure show type:node or type:primitive
node 178326192: alice
node 178326448: bob
primitive admin_addr IPaddr2 \
        params ip=192.168.2.1 \
        op monitor interval=10 timeout=20
primitive stonith-sbd stonith:external/sbd \
        params pcmk_delay_max=30

さらに、特定の文字列で開始するオブジェクトを検索するには次の表記を使用します。

root # crm configure show type:primitive and and 'admin*'
primitive admin_addr IPaddr2 \
        params ip=192.168.2.1 \
        op monitor interval=10 timeout=20

使用可能なすべてのタイプを一覧表示するには、crm configure show type:と入力し、<Tab>キーを押します。Bash補完により、すべてのタイプのリストが表示されます。

新しいクラスタリソースを開始するには、そのIDが必要です。次の手順に従います。

リソースは、失敗した場合は自動的に再起動しますが、失敗のたびにリソースの失敗回数が増加します。migration-thresholdがそのリソースに設定されている場合は、失敗の数が移行しきい値に達すると、そのリソースはノードで実行できなくなります。

次の手順に従って、クラスタリソースを削除します。

リソースは、ハードウェアまたはソフトウェアに障害が発生した場合、クラスタ内の他のノードに自動的にフェールオーバー(つまり移行)するよう設定されていますが、Hawk2またはコマンドラインを使用して、手動でリソースを別のノードに移動することもできます。

この作業を行うには、migrateコマンドを使用します。たとえば、リソースipaddress1をbobというクラスタノードに移行するには、次のコマンドを使用します。

root # crm resource
crm(live)resource# migrate ipaddress1 bob

タグは、コロケーションの作成や関係の順序付けを行わずに、複数のリソースをただちに参照する方法です。これは、概念的に関連するリソースをグループ化するのに役立つ場合があります。たとえば、データベースに関連するいくつかのリソースがある場合、databasesというタグを作成し、データベースに関連するすべてのリソースをこのタグに追加します。

root # crm configure tag databases: db1 db2 db3

これにより、1つのコマンドですべてを起動できます。

root # crm resource start databases

同様に、すべてを停止することもできます。

root # crm resource stop databases

クラスタまたはノードの「ヘルス」ステータスは、「スクリプト」というもので表示できます。スクリプトは、ヘルスだけに限らず各タスクを実行できます。ただし、このサブセクションでは、ヘルスステータスを取得する方法に焦点を当てます。

healthコマンドに関するすべての詳細を取得するには、describeを使用します。

root # crm script describe health

このコマンドは、すべてのパラメータの説明とリスト、およびそのデフォルト値を示します。スクリプトを実行するには、runを使用します。

root # crm script run health

スイートから1つのステップのみを実行したい場合は、describeコマンドのStepsカテゴリで、使用可能なすべてのステップを一覧表示できます。

たとえば、次のコマンドは、healthコマンドの最初のステップを実行します。さらなる調査のために、出力がhealth.jsonに保存されます。

root # crm script run health
    statefile='health.json'

上記のコマンドは、crm cluster healthでも実行できます。

スクリプトに関する追加情報を表示するには、http://crmsh.github.io/scripts/を参照してください。