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

8 クラスタリソースの設定と管理(コマンドライン)

クラスタリソースを設定および管理するには、コマンドラインユーティリティであるcrmシェル(crmsh)またはWebベースのユーザインタフェースであるHawk2のいずれかを使用します。

この章では、crmコマンドラインツールを紹介し、このツールの概要、テンプレートの使用方法、そして、主にクラスタリソースの設定と管理(基本的なリソースと高度なリソース(グループとクローン)の作成、制約の設定、フェールオーバーノードとフェールバックノードの指定、リソース監視の設定、リソースの開始、クリーンアップ、または削除、および手動によるリソースの移行について説明します。

注記
注記: ユーザの権限

クラスタを管理するには十分な権限が必要です。crmコマンドおよびそのサブコマンドは、rootユーザとして、またはCRM所有者ユーザとして実行される必要があります(通常はhaclusterユーザ)。

ただし、userオプションを使用することで、crmとそのサブコマンドを一般(権限のない)ユーザとして実行し、必要な場合はいつでもsudoを使用してIDを変更できます。たとえば、次のcrmコマンドは、権限のあるユーザIDとしてhaclusterを使用します。

root # crm options user hacluster

/etc/sudoersを設定しておいて、sudoがパスワードを要求しないようにしておく必要があることに注意してください。

8.1 crmsh - 概要

crmコマンドには、リソース、CIB、ノード、リソースエージェントなどを管理するサブコマンドがあります。このコマンドには、例を組み込んだ詳細なヘルプシステムが用意されています。すべての例は、付録Bで説明される命名規則に従います。

イベントは/var/log/crmsh/crmsh.logにログを記録します。

ヒント
ヒント: 対話型crmプロンプト

crmを引数なしで(または1つのサブレベルのみを引数として)使用することにより、crmシェルは対話モードになります。このモードは、次のプロンプトで示されます。

crm(live/HOSTNAME)

読みやすくするために、このマニュアルでは対話型crmのプロンプトでホスト名を省略します。次の例のように、aliceなどの特定のノードで対話型シェルを実行する必要がある場合にのみホスト名を含めます。

crm(live/alice)

8.1.1 ヘルプの表示

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

  • crmとそのコマンドラインオプションの使用方法を出力するには:

    root # crm --help
  • 使用可能なすべてのコマンドの一覧を表示するには:

    root # crm help
  • コマンドの参照情報だけでなく、他のヘルプセクションにアクセスするには:

    root # crm help topics
  • configureサブコマンドの詳細なヘルプテキストを表示するには:

    root # crm configure help
  • configuregroupサブコマンドの構文、使用方法、例を印刷するには:

    root # crm configure help group

    これも同様です:

    root # crm help configure group

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

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

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

8.1.2 crmshのサブコマンドの実行

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

  • 直接: すべてのサブコマンドをcrmに続け、<Enter>を押すと、ただちにその出力が表示されます。たとえば、crm help raを入力すると、raサブコマンド(リソースエージェント)に関する情報を取得できます。

    サブコマンドは、その短縮形が固有である限り短縮できます。たとえば、statusstと短縮しても、crmshにはユーザが意図したサブコマンドとして認識されます。

    パラメータを短縮する機能もあります。通常、パラメータはparamsキーワードを使用して追加します。paramsセクションが最初のセクションでほかにセクションがない場合、このセクションを省略できます。たとえば、次のような行があるとします。

    root # crm primitive ipaddr IPaddr2 params ip=192.168.0.55

    これは次の行と同等です。

    root # crm primitive ipaddr IPaddr2 ip=192.168.0.55
  • crmシェルスクリプトとして使用: Crmシェルスクリプトにはcrmのサブコマンドが含まれます。詳細については、8.1.4項 「crmshのシェルスクリプトの使用」を参照してください。

  • crmshクラスタスクリプトとして使用:これらは、メタデータ、RPMパッケージへの参照、設定ファイル、およびcrmshサブコマンドを1つのわかりやすい名前でバンドルしてまとめたものです。crm scriptコマンドを使用して管理します。

    これらをcrmshシェルスクリプトと混同しないでください。両方に共通する目的はいくつかありますが、crmシェルスクリプトにはサブコマンドのみが含まれるのに対し、クラスタスクリプトにはコマンドの単純なエミュレーション以上の処理が組み込まれています。詳細については、8.1.5項 「crmshのクラスタスクリプトの使用」を参照してください。

  • 内部シェルとして対話式に使用:crm」とタイプして、内部シェルに入ります。プロンプトがcrm(live)に変化します。helpを使用すると、利用可能なサブコマンドの概要を取得できます。内部シェルにはさまざまなサブコマンドレベルがあり、1つのサブコマンドをタイプしてEnterを押すことで、そのサブコマンドのレベルに入ることができます。

    たとえば、「resource」とタイプすると、リソース管理レベルに入ります。プロンプトはcrm(live)resource#に変わります。内部シェルを終了するには、コマンドquitを使用します。1レベル戻る場合は、backupend、またはcdを使用します。

    crm、そしてオプションを付けずにサブコマンドを入力してEnterを押すと、そのレベルに直接入ることができます。

    内部シェルは、サブコマンドとリソースのタブによる完了もサポートします。コマンドの冒頭をタイプして<Tab>を押すと、crmがそのオブジェクトを完了します。

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

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

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

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

8.1.3 OCFリソースエージェントに関する情報の表示

リソースエージェントはクラスタ設定で常に操作する必要があるため、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」を入力すれば済みます。

8.1.4 crmshのシェルスクリプトの使用

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

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

例 8.1: 単純なcrmshシェルスクリプト
# A small example file with some crm subcommands
status
node list

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

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

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

8.1.5 crmshのクラスタスクリプトの使用

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

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

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

  • 特定のタスクに必要なソフトウェアをインストールする。

  • 設定ファイルを作成または変更する。

  • 情報を収集し、クラスタの潜在的な問題をレポートする。

  • 変更をすべてのノードに展開する。

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

8.1.5.1 使用方法

利用可能なすべてのクラスタのリストを取得するには、次のコマンドを実行します。

root # crm script list

スクリプトのコンポーネントを表示するには、showコマンドと、クラスタスクリプトの名前を使用します。次に例を示します。

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

showの出力には、タイトル、短い説明、および手順が含まれます。各手順は一連のステップに分かれており、これらのステップを指定された順序で実行します。

各ステップには、必須パラメータとオプションパラメータのリスト、および短い説明とそのデフォルト値が含まれます。

各クラスタスクリプトは、一連の共通パラメータを認識します。これらのパラメータは任意のスクリプトに渡すことができます。

表 8.1: 共通パラメータ
パラメータ引数説明
アクションINDEX設定した場合、1つのアクションのみを実行します(verifyによって返されたインデックス)。
dry_runBOOL設定した場合、実行のシミュレートのみを行います(デフォルト: no)。
ノードLISTスクリプト実行対象のノードのリスト。
portNUMBER接続先のポート。
statefileFILEシングルステップ実行の場合に、指定したファイルに状態を保存します。
sudoBOOL設定した場合、sudoパスワードを入力するようcrmによってプロンプトが表示され、必要に応じてsudoが使用されます(デフォルト: no)。
timeoutNUMBER秒単位での実行タイムアウト(デフォルト: 600)。
userUSER指定したユーザとしてスクリプトを実行します。

8.1.5.2 クラスタスクリプトの検証と実行

問題を避けるため、クラスタスクリプトを実行する前に、実行するアクションを確認してパラメータを検証します。クラスタスクリプトは一連のアクションを実行でき、さまざまな理由で失敗する可能性があります。そのため、実行前にパラメータを検証すると、問題の回避に役立ちます。

たとえば、mailtoリソースエージェントでは、固有の識別子と電子メールアドレスが必要です。これらのパラメータを検証するには、以下を実行します。

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

        mailx

2. Configure cluster resources

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

        clone c-sysadmin sysadmin

verifyは各ステップを出力し、指定したパラメータでプレースホルダを置き換えます。問題が見つかった場合、verifyによってレポートされます。問題がなければ、verifyコマンドをrunに置き換えます。

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

crm statusを使用して、リソースがクラスタに統合されているかどうかを確認します。

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

8.1.6 設定テンプレートの使用

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

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

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

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

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

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

    root # crm configure
  2. 設定テンプレートから新しい設定を作成します。

    1. templateサブコマンドに切り替えます。

      crm(live)configure# template
    2. 使用可能な設定テンプレートを一覧します。

      crm(live)configure template# list templates
      gfs2-base   filesystem  virtual-ip  apache   clvm     ocfs2    gfs2
    3. 必要な設定テンプレートを決めます。Apache設定が必要なので、apacheテンプレートを選択し、g-intranetと名付けます。

      crm(live)configure template# new g-intranet apache
      INFO: pulling in template apache
      INFO: pulling in template virtual-ip
  3. パラメータを定義します。

    1. 作成した設定を一覧表示します。

      crm(live)configure template# list
      g-intranet
    2. 入力を必要とする最小限の変更項目を表示します。

      crm(live)configure template# show
      ERROR: 23: required parameter ip not set
      ERROR: 61: required parameter id not set
      ERROR: 65: required parameter configfile not set
    3. 好みのテキストエディタを起動し、ステップ 3.bでエラーとして表示されたすべての行に入力します。

      crm(live)configure template# edit
  4. 設定を表示し、設定が有効かどうか確認します(太字のテキストは、ステップ 3.cで入力した設定によって異なります)。

    crm(live)configure template# show
    primitive virtual-ip ocf:heartbeat:IPaddr \
        params ip="192.168.1.101"
    primitive apache apache \
        params configfile="/etc/apache2/httpd.conf"
        monitor apache 120s:60s
    group g-intranet \
        apache virtual-ip
  5. 設定を適用します。

    crm(live)configure template# apply
    crm(live)configure# cd ..
    crm(live)configure# show
  6. 変更内容をCIBに送信します。

    crm(live)configure# commit

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

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に適用したり、コミットすることはありません。

8.1.7 シャドーイング設定のテスト

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

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

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

    root # crm configure
  2. 新しいシャドウ設定を作成します。

    crm(live)configure# cib new myNewConfig
    INFO: myNewConfig shadow CIB created

    シャドウCIBの名前を省略する場合は、一時名の@tmp@が作成されます。

  3. 現在のライブ設定をシャドウ設定にコピーするには、次のコマンドを使用します。コピーしない場合は、このステップをスキップします。

    crm(myNewConfig)# cib reset myNewConfig

    このコマンドを使用すると、既存のリソースを後から編集する場合に、簡単に編集できます。

  4. 通常どおり変更を行います。シャドウ設定の作成後は、すべての変更がシャドウ設定に適用されます。すべての変更を保存するには、次のコマンドを使用します。

    crm(myNewConfig)# commit
  5. ライブクラスタ設定が再び必要な場合は、次のコマンドでライブ設定に戻ります。

    crm(myNewConfig)configure# cib use live
    crm(live)# 

8.1.8 設定の変更のデバッグ

設定の変更をクラスタにロードする前に、変更内容を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

8.1.9 クラスタダイアグラム

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

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

root # crm configure graph dot config.svg svg

8.2 Corosync設定の管理

Corosyncは、ほとんどのHAクラスタの下層にあるメッセージング層です。corosyncサブコマンドは、Corosync設定を編集および管理するためのコマンドを提供します。

たとえば、クラスタのステータスを一覧表示するには、statusを使用します。

root # crm corosync status
Printing ring status.
Local node ID 175704363
RING ID 0
        id      = 10.121.9.43
        status  = ring 0 active with no faults
Quorum information
------------------
Date:             Thu May  8 16:41:56 2014
Quorum provider:  corosync_votequorum
Nodes:            2
Node ID:          175704363
Ring ID:          4032
Quorate:          Yes

Votequorum information
----------------------
Expected votes:   2
Highest expected: 2
Total votes:      2
Quorum:           2
Flags:            Quorate

Membership information
----------------------
    Nodeid      Votes Name
 175704363          1 alice.example.com (local)
 175704619          1 bob.example.com

diffコマンドは非常に便利です。すべてのノード上のCorosync設定を比較し(別途記載のない場合)、それらの差異を出力します。

root # crm corosync diff
--- bob
+++ alice
@@ -46,2 +46,2 @@
-       expected_votes: 2
-       two_node: 1
+       expected_votes: 1
+       two_node: 0

詳細については、「http://crmsh.nongnu.org/crm.8.html#cmdhelp_corosync」を参照してください。

8.3 クラスタリソースの設定

クラスタの管理者は、クラスタ内のサーバ上の各リソースや、サーバ上で実行する各アプリケーションに対してクラスタリソースを作成する必要があります。クラスタリソースには、Webサイト、電子メールサーバ、データベース、ファイルシステム、仮想マシン、およびユーザが常時使用できるようにする他のサーバベースのアプリケーションまたはサービスなどが含まれます。

作成できるリソースタイプの概要については、6.3.3項 「リソースのタイプ」を参照してください。

8.3.1 ファイルからのクラスタリソースのロード

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

置き換え

このオプションは、現在の設定を新たなソース設定に置き換えます。

update

このオプションは、ソース設定のインポートを試みます。現在の設定に新たな項目を追加したり、既存の項目を更新したりします。

push

このオプションは、ソースからのコンテンツを現在の設定にインポートします(updateと同じ)。ただし、新しい設定で使用できないオブジェクトを削除します。

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

root # crm configure load push mycluster-config.txt

8.3.2 クラスタリソースの作成

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

  1. rootとしてログインし、crmツールを開始します。

    root # crm configure
  2. プリミティブIPアドレスを設定ます。

    crm(live)configure# primitive myIP IPaddr \
         params ip=127.0.0.99 op monitor interval=60s

    前のコマンドはプリミティブに名前myIPを設定します。クラス(ここではocf)、プロバイダ(heartbeat)、およびタイプ(IPaddr)を選択する必要があります。さらに、このプリミティブでは、IPアドレスなどのパラメータが必要です。自分の設定に合わせてアドレスを変更してください。

  3. 行った変更を表示して確認します。

    crm(live)configure# show
  4. 変更をコミットして反映させます。

    crm(live)configure# commit

8.3.3 リソーステンプレートの作成

類似した設定で複数のリソースを作成する場合、リソーステンプレートを使用すれば作業が簡単になります。基本的なバックグラウンド情報については、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 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

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

8.3.4 STONITHリソースの作成

crmからは、STONITHデバイスはリソースです。STONITHリソースを作成するには、次の手順に従います。

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

    root # crm configure
  2. 次のコマンドで、すべてのSTONITHタイプのリストを取得します。

    crm(live)# ra list stonith
    apcmaster                  apcmastersnmp              apcsmart
    baytech                    bladehpi                   cyclades
    drac3                      external/drac5             external/dracmc-telnet
    external/hetzner           external/hmchttp           external/ibmrsa
    external/ibmrsa-telnet     external/ipmi              external/ippower9258
    external/kdumpcheck        external/libvirt           external/nut
    external/rackpdu           external/riloe             external/sbd
    external/vcenter           external/vmware            external/xen0
    external/xen0-ha           fence_legacy               ibmhmc
    ipmilan                    meatware                   nw_rpc100s
    rcd_serial                 rps10                      suicide
    wti_mpc                    wti_nps
  3. 上記のリストからSTONITHタイプを選択し、利用できるオプションのリストを表示します。次のコマンドを実行します。

    crm(live)# ra info stonith:external/ipmi
    IPMI STONITH external device (stonith:external/ipmi)
    
    ipmitool based power management. Apparently, the power off
    method of ipmitool is intercepted by ACPI which then makes
    a regular shutdown. If case of a split brain on a two-node
    it may happen that no node survives. For two-node clusters
    use only the reset method.
    
    Parameters (* denotes required, [] the default):
    
    hostname (string): Hostname
        The name of the host to be managed by this STONITH device.
    ...
  4. stonithクラス、ステップ 3で選択したタイプ、および必要に応じて該当するパラメータを使用して、STONITHリソースを作成します。たとえば、次のコマンドを使用します。

    crm(live)# configure
    crm(live)configure# primitive my-stonith stonith:external/ipmi \
        params hostname="alice" \
        ipaddr="192.168.1.221" \
        userid="admin" passwd="secret" \
        op monitor interval=60m timeout=120s

8.3.5 リソース制約の設定

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

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

8.3.5.1 場所の制約

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

この種類の制約は、各リソースに複数追加できます。すべての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アドレスvip1およびvip2を参照して、リソースセットloc-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

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

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

8.3.5.2 コロケーション制約

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

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

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

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

マスタスレーブ構成では、現在のノートがマスタかどうかと、リソースをローカルに実行しているかどうかを把握することが必要です。

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

同じノード上にリソースのグループを配置できると便利な場合がありますが(コロケーション制約を定義)、リソース間で困難な依存性を持つことはありません。

同じノード上にリソースを配置するが、これらの一方に障害が発生した場合のアクションがない場合は、weak-bondコマンドを使用します。

root # crm configure assist weak-bond RES1 RES2

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

8.3.5.4 順序の制約

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

リソースのアクションや操作の順序を指定することが必要な場合があります。たとえば、デバイスがシステムで利用できるようになるまで、ファイルシステムはマウントできません。順序の制約を使用して、開始、停止、マスタへの昇格など、別のリソースが特殊な条件を満たす直前または直後に、サービスを開始または停止できます。

順序の制約を設定するには、次のようなコマンドをcrmシェルで使用します。

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

8.3.5.5 サンプル設定のための制約

このセクションで使用される例は、制約を追加しないと機能しません。すべてのリソースは、必ず、マスタであるDRBDリソースと同じマシンで実行される必要があります。DRBDリソースは、他のリソースが開始する前にマスタにする必要があります。マスタでないときに、drbdデバイスをマウントしようとすると失敗します。次の制約を満たす必要があります。

  • ファイルシステムは、常に、DRDBリソースのマスタと同じノード上に存在する必要があります。

    crm(live)configure# colocation filesystem_on_master inf: \
        filesystem_resource drbd_resource:Master
  • NFSサーバとIPアドレスは、ファイルシステムと同じノードに存在する必要があります。

    crm(live)configure# colocation nfs_with_fs inf: \
       nfs_group filesystem_resource
  • NFSサーバとIPアドレスは、ファイルシステムがマウントされた後に開始されます。

    crm(live)configure# order nfs_second Mandatory: \
       filesystem_resource:start nfs_group
  • ファイルシステムは、drbdリソースがこのノードのマスタに昇格した後にマウントされる必要があります。

    crm(live)configure# order drbd_first Mandatory: \
        drbd_resource:promote filesystem_resource:start

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

リソースフェールオーバーを判定するには、メタ属性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項 「フェールオーバーノード」を参照してください。

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

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

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

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

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

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

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

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

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

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

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

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

手順 8.1: crmで使用属性を追加または変更する
  1. rootとしてログインし、crm対話型シェルを開始します。

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

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

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

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

    crm(live)configure# primitive xen1 Xen ... \
         utilization 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 memory="4000"
crm(live)configure# node bob utilization memory="4000"
crm(live)configure# node charlie utilization 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のいずれかしか配置できず、その優先度は同じであるため、結果はまだ定義されていません。これを解決するためにも、どちらかに高い優先度を設定する必要があります。

8.3.9 リソース監視の設定

リソースを監視するには、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項 「リソース監視」を参照してください。

8.3.10 クラスタリソースグループの設定

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

  1. crmコマンドをシステム管理者として実行します。プロンプトがcrm(live)に変化します。

  2. プリミティブを設定します。

    crm(live)# configure
    crm(live)configure# primitive Public-IP ocf:heartbeat:IPaddr \
       params ip=1.2.3.4 id= Public-IP
    crm(live)configure# primitive Email systemd:postfix \
       params id=Email
  3. 該当するIDを使用して、正しい順序で、プリミティブをグループ化します。

    crm(live)configure# group g-mailsvc Public-IP Email

グループメンバーの順序を変更するには、configureサブコマンドからmodgroupコマンドを使用します。プリミティブのEmailPublic-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項 「グループ」を参照してください。

8.3.11 クローンリソースの設定

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

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

8.3.11.1 匿名クローンリソースの作成

匿名クローンリソースを作成するには、まずプリミティブリソースを作成して、それをcloneコマンドで指定することです。次の操作を実行してください:

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

    root # crm configure
  2. 次のように、プリミティブを設定します。

    crm(live)configure# primitive Apache apache
  3. プリミティブをクローンします。

    crm(live)configure# clone cl-apache Apache

8.3.11.2 プロモータブルクローンリソースの作成

プロモータブルクローンリソース(以前はマルチステートリソースと呼ばれていました)は、クローンが得意とするところです。このタイプにより、インスタンスを2つの動作モード、プライマリまたはセカンダリのいずれかに設定できます。

プロモータブルクローンリソースを作成するには、まずプリミティブリソースを作成してから、プロモータブルクローンリソースを作成します。プロモータブルクローンリソースは少なくとも、昇格および降格操作をサポートしている必要があります。

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

    root # crm configure
  2. プリミティブを作成します。必要に応じて間隔を変更します。

    crm(live)configure# primitive my-rsc ocf:myCorp:myAppl \
        op monitor interval=60 \
        op monitor interval=61 role="Promoted
  3. プロモータブルクローンリソースを作成します。

    crm(live)configure# clone clone-rsc my-rsc

8.4 クラスタリソースの管理

crmツールでは、クラスタリソースの設定が可能なだけでなく、既存リソースを管理することもできます。移行のサブセクションで概要を示します。

8.4.1 クラスタリソースの表示

クラスタを管理する際には、コマンド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補完により、すべてのタイプのリストが表示されます。

8.4.2 新しいクラスタリソースの開始

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

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

    root # crm
  2. リソースレベルに切り替えます。

    crm(live)# resource
  3. startでリソースを開始し、<Tab>キーを押してすべての既知のリソースを表示します。

    crm(live)resource# start ID

8.4.3 クラスタリソースの停止

1つ以上の既存のクラスタリソースを停止するには、各IDが必要です。以下に手順を示します。

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

    root # crm
  2. リソースレベルに切り替えます。

    crm(live)# resource
  3. stopでリソースを停止し、<Tab>キーを押してすべての既知のリソースを表示します。

    crm(live)resource# stop ID

    複数のリソースを一度に停止できます。

    crm(live)resource# stop ID1 ID2 ...

8.4.4 リソースのクリーンアップ

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

  1. シェルを開いて、rootユーザとしてログインします。

  2. すべてのリソースのリストを取得します。

    root # crm resource list
      ...
    Resource Group: dlm-clvm:1
             dlm:1  (ocf:pacemaker:controld) Started
             clvm:1 (ocf:heartbeat:lvmlockd) Started
  3. リソースdlmをクリーンアップするには、たとえば、以下の手順を実行します:。

    root # crm resource cleanup dlm

8.4.5 クラスタリソースの削除

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

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

    root # crm configure
  2. 次のコマンドを実行して、リソースのリストを取得します。

    crm(live)# resource status

    たとえば、出力はこのようになります(ここで、myIPはリソースの該当するID)。

    myIP    (ocf:IPaddr:heartbeat) ...
  3. 該当するIDを持つリソースを削除します(これは、commitも含意します)。

    crm(live)# configure delete YOUR_ID
  4. 変更をコミットします。

    crm(live)# configure commit

8.4.6 クラスタリソースの移行

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

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

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

8.4.7 リソースのグループ化/タグ付け

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

root # crm configure tag databases: db1 db2 db3

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

root # crm resource start databases

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

root # crm resource stop databases

8.4.8 ヘルスステータスの取得

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

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/を参照してください。

8.5 cib.xmlから独立したパスワードの設定

クラスタ設定にパスワードなどの機密の情報が含まれている場合、それらをローカルファイルに保存する必要があります。こうしておけば、これらのパラメータがログに記録されたり、サポートレポートに漏洩することはありません。

secretを使用する前に、リソースの概要を確認するため、showコマンドを実行しておくとよいでしょう。

root # crm configure show
primitive mydb mysql \
   params replication_user=admin ...

上記のmydbリソースに対してパスワードを設定するには、次のコマンドを使用します。

root # crm resource secret mydb set passwd linux
INFO: syncing /var/lib/heartbeat/lrm/secrets/mydb/passwd to [your node list]

次のように、保存されたパスワードが返されます。

root # crm resource secret mydb show passwd
linux

パラメータは、ノード間で同期する必要があることに注意してください。crm resource secretコマンドを使用すれば、この処理が実行されます。秘密のパラメータを管理する場合には、このコマンドを使用することを強く推奨します。

8.6 履歴情報の取得

クラスタの履歴の調査は複雑な作業です。この作業を簡素化するために、crmshにはhistoryコマンドとそのサブコマンドが含まれています。これは、SSHが正しく設定されていることが前提となります。

それぞれのクラスタは、状態を移動し、リソースを移行し、または重要なプロセスを開始します。これらすべてのアクションは、historyのサブコマンドによって取得できます。

デフォルトでは、すべてのhistoryコマンドは過去1時間のイベントを確認します。このタイムフレームを変更するには、limitサブコマンドを使用します。構文は次のとおりです。

root # crm history
crm(live)history# limit FROM_TIME [TO_TIME]

有効な例として、次のようなものが挙げられます。

limit4:00pm , limit16:00

どちらのコマンドも同じ意味で、今日の午後4時を表しています。

limit2012/01/12 6pm

2012年1月12日の午後6時。

limit"Sun 5 20:46"

今年の今月の5日日曜日の午後8時46分。

その他の例とタイムフレームの作成方法については、http://labix.org/python-dateutilを参照してください。

infoサブコマンドでは、crm reportによって使用されているすべてのパラメータが表示されます。

crm(live)history# info
Source: live
Period: 2012-01-12 14:10:56 - end
Nodes: alice
Groups:
Resources:

crm reportを特定のパラメータに制限するには、サブコマンドhelpで使用可能なオプションを表示します。

詳細レベルに絞り込んでいくには、サブコマンドdetailとレベル数を使用します。

crm(live)history# detail 1

数値が大きいほど、レポートが詳細になっていきます。デフォルト値は0 (ゼロ)です。

ここまでのパラメータを設定したら、logを使用してログメッセージを表示します。

最後の遷移を表示するには、次のコマンドを使用します。

crm(live)history# transition -1
INFO: fetching new logs, please wait ...

このコマンドはログを取得し、dotty (graphvizパッケージから)を実行して、遷移グラフを表示します。シェルはログファイルを開きます。ログ内は、カーソルキーでブラウズできます。

遷移グラフを表示する必要がない場合には、nographオプションを使用します。

crm(live)history# transition -1 nograph

8.7 詳細の参照先