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

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コマンドが含まれています。このコマンドを使用して、リソースエージェントの情報を表示し、リソースエージェントを管理します(詳細は4.2.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:drbd:linbit
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用の既成のクラスタ設定です。リソーステンプレート(6.4.2項 「リソーステンプレートの作成」の説明を参照)と混同しないでください。これらはクラスタ用のテンプレートで、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

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

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

root # crm configure graph dot config.svg svg

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

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

オプションや操作を上書きしたい場合は、自分の(プリミティブの)定義を追加します。たとえば、次の新しいプリミティブMy-VM2は監視操作のタイムアウトを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では失敗します)。このような情報をクラスタが利用できるように、制約を定義します。

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

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 vip1 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が定義されていない場合には、リソースは移行しません。

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

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

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

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

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

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

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

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

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

crm(live)configure# node alice utilization memory="4000"
crm(live)configure# node bob utilization memory="4000"
crm(live)configure# node charly utilization memory="4000"
crm(live)configure# primitive xenA ocf:heartbeat:Xen \
    utilization memory="3500" meta priority="10"
crm(live)configure# primitive xenB ocf:heartbeat:Xen \
    utilization memory="2000" meta priority="1"
crm(live)configure# primitive xenC ocf:heartbeat:Xen \
    utilization memory="2000" meta priority="1"
crm(live)configure# primitive xenD ocf:heartbeat:Xen \
    utilization memory="1000" meta priority="5"
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

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

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

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

crm(live)configure# modgroup g-shortcut add p.lsb-exim before p.public-ip

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

crm(live)configure# modgroup g-shortcut remove p.lsb-exim

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

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

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

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

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

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

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

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

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

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

root # crm configure tag-db db1 db2 db3

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

root # crm resource start tag-db

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

root # crm resource stop tag-db

クラスタ設定の変更時、個々のノードに対するソフトウェアパッケージの更新時、または上位製品バージョンへのクラスタのアップグレード時であっても、個々のクラスタコンポーネント上、またはクラスタ全体でテストや保守タスクを実行する必要がある場合があります。

それに関して、High Availability Extensionは、次のレベルでmaintenanceオプションを提供しています。

警告: データ損失の危険

クラスタ制御下でサービスを実行しているときにテストまたは保守タスクを実行する必要がある場合は、次のアウトラインに従ってください。

1. 手順を開始する前に、個々のリソース、ノード、またはクラスタ全体を保守モードに設定します。これにより、順序正しくリソースを起動できないなどの望ましくない影響、クラスタノード間でCIBが同期されないリスク、またはデータ損失を避けることができます。

2. 保守タスクまたはテストを実行します。

3. 完了したら、保守モードを解除して、通常のクラスタ操作を開始します。

保守モード中にリソースおよびクラスタで何が発生するかの詳細については、4.7項 「メンテナンスモード」を参照してください。

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

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

root # crm script describe health

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

root # crm script run health verbose=true

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

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

root # crm script run health \
    step='Collect cluster information' \
    statefile='health.json'

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