# crm resource stop www_app
CRM(Cluster Resource Manager, 別名 Pacemaker)はクラスタマネージャです。CRMはCIB(Cluster Information Base)に保存された情報をもとにクラスタを管理します。CIBはXML形式で記述されています。CIBは構文が複雑なので、CIBの情報を変更する手順はかなり煩雑です。
現在、CIBを編集するために下記のツールが提供されています。
GUI
コマンドラインツール(`crm_resource`など)
cibadminコマンド
GUIは特に人気のあるツールで、現在も改良が続けられています。(訳者注：2012年1月時点において三種類のGUIが提供されています。Python GUI, LCMC, Hawk)初めてクラスタを管理する場合はまずGUIを試してみるとよいでしょう。
Pacemakerには`crm_resource`コマンドをはじめとするコマンドラインツールが付属しており、これらを利用してCIBを編集することもできます。しかし、コマンドラインツールはオプションの種類が多く操作も複雑であるため、習熟に時間がかかるという欠点があります。また、コマンドラインツール間でプションが統一されていないものもあり、ユーザが混乱する原因になっています。(訳者注：Pacemaker 1.0.10以降では、オプションの統一が進んでいます。)
コマンドラインツールの一つである`cibadmin`コマンドは優れた管理ツールです。ユーザはCIB全体ではなく、CIBの一部のみを取り出して編集することができます。しかし、`cibadmin`コマンドは操作が難しいため、かなり経験を積んだユーザにしか使いこなせないかもしれません。何度も操作を試してみて慣れていくしかありませんが、コマンドの出力するエラーメッセージがわかりづらいため、難易度は高いといえます。
CRM-CLIは、CIBの編集およびクラスタの管理を行うためのツールです。CRM-CLIは内部で`cibadmin`コマンドのようなコマンドラインツールを呼び出しており、コマンドラインツールを通してXMLの編集が実行されます。それぞれのコマンドラインツールから実行された結果は互換性を保持しています。
CRM-CLIは、対話式の操作だけではなくバッチ入力方式にも対応しています。標準入力から一連のコマンドを連続して実行することも可能であり、操作をスクリプト化することもできます。クラスタの設定や管理に慣れていないユーザのために、テンプレートも用意されています。
CRM-CLIを操作することによって、CIBそのものを生成することもできます。CRM-CLIのコマンドを記述したスクリプトはXML形式ではありませんが、CIBに反映することが可能です。
最近追加された新しい機能として、シャドウCIBがあります。ユーザは複数のシャドウCIBを作成し、そのうちの一つをクラスタへ反映することができます。 XML形式の設定を直接編集し、ファイルまたはネットワーク経由でクラスタへ反映することも可能です。
ユーザの習熟度に応じて使用可能な機能を限定することもできます。
CRM-CLIのコマンドは、基本的には、改行を含めずに実行してください。コマンドに複数のオプションを追加して文字列が長くなってしまった場合は、継続文字(\)を使用して改行することもできます。
CRM-CLIはクラスタ内のノードで実行してください。
このツールも最も重要な部分はユーザインターフェースです。この章では形式ばったチュートリアルではなく感覚的に理解できるような例をいくつか紹介します。では、いくつかの例を紹介しましょう。
コマンドラインモード
# crm resource stop www_app
対話式モード
# crm crm(live)# resource crm(live) resource# unmanage tetris_1 crm(live) resource# up crm(live)# node standby node4
バッチ入力モード
# crm<<EOF
configure
erase
#
# resources
#
primitive disk0 iscsi \
params portal=192.168.2.108:3260 target=iqn.2008-07.com.suse:disk0
primitive fs0 Filesystem \
params device=/dev/disk/by-label/disk0 directory=/disk0 fstype=ext3
primitive internal_ip IPaddr params ip=192.168.1.101
primitive apache apache \
params configfile=/disk0/etc/apache2/site0.conf
primitive apcfence stonith:apcsmart \
params ttydev=/dev/ttyS0 hostlist="node1 node2" \
op start timeout=60s
primitive pingd pingd \
params name=pingd dampen=5s multiplier=100 host_list="r1 r2"
#
# monitor apache and the UPS
#
monitor apache 60s:30s
monitor apcfence 120m:60s
#
# cluster layout
#
group internal_www \
disk0 fs0 internal_ip apache
clone fence apcfence \
meta globally-unique=false clone-max=2 clone-node-max=1
clone conn pingd \
meta globally-unique=false clone-max=2 clone-node-max=1
location node_pref internal_www \
rule 50: #uname eq node1 \
rule pingd: defined pingd
#
# cluster properties
#
property stonith-enabled=true
commit
EOF
CRM-CLIを使ったことがなくても、上記の例は直感的に理解することができるのではないでしょうか。CRM-CLIによって、クラスタを効率的に管理し、容易に設定を変更することができます。
コマンドプロンプトに表示される`(live)`という文字列は、操作対象のCIBが実行中のクラスタ(ライブCIB)であることを表しています。ライブCIBではなくシャドウCIBに対して操作を実行することもできます。シャドウCIBとはライブCIBのコピーと考えてよいでしょう。シャドウCIBに対する操作はライブCIBには反映されません。
CIBはXMLの階層構造を保持しており、CRM-CLIは、XMLの階層ごとに特定のコマンドを使用します。
シャドウCIBは新しく追加された機能です。シャドウCIBはライブCIBと同様の操作が可能ですが、シャドウCIBに対する設定変更はクラスタには反映されません。管理者は複数のシャドウCIBを作成し、そのうちの一つだけをクラスタに反映することができます。シャドウCIBの操作中は、コマンドプロンプトには現在操作を実行中のシャドウCIBの名前が表示されます。シャドウCIBでは、`configure`レベルのコマンドのみ使用可能です。
`configure commit`コマンドを実行してはじめて、シャドウCIBの変更がクラスタ(ライブCIB)に反映されます。クラスタを設定する際、最初はライブCIBを直接編集することが多いかもしれませんが、慣れてきたらまずシャドウCIBで設定を変更し、設定内容が間違っていないことを確認してからクラスタに反映するとよいでしょう。`configure`レベルでの操作例
crm(live)configure# cib new test-2
INFO: test-2 shadow CIB created
crm(test-2)configure# commit
CRM-CLIには、クラスタを設定するための基本的なテンプレートがいくつが用意されています。ユーザはテンプレートを利用することによって、複雑な操作を行わずにクラスタを設定することができます。Pacemakerをはじめて使用する場合は、まずテンプレートを利用してクラスタを設定してみましょう。
Apacheのテンプレートを利用した設定例
# crm configure
crm(live)configure# template
crm(live)configure template# list templates
apache filesystem virtual-ip
crm(live)configure template# new web <TAB><TAB>
apache filesystem virtual-ip
crm(live)configure template# new web apache
INFO: pulling in template apache
INFO: pulling in template virtual-ip
crm(live)configure template# list
web2-d web2 vip2 web3 vip web
最初に`configure`レベルに移動して`template`コマンドを実行してください。`list templates`コマンドを実行すると、利用可能なテンプレートの一覧が表示されます。`new`コマンドを実行して、Apacheの設定を作成します。タブキーによる入力補完も使用することができます。Apacheを実行するためには仮想IPも必要となります。テンプレートを使用してApacheの設定を作成すると自動的に仮想IPの設定も作成されます。ここで`list`コマンドを実行すると、先ほど作成した「web」という名前の設定(Apache, 仮想IP)が表示されます。上記の例ではweb以外の設定も表示されていますが、これらは別の機会に作成した設定です。
`show`コマンドを実行すると、設定内容が表示されます。ユーザがそれぞれの環境にあわせて設定を変更する必要のあるパラメータは、エラーメッセージが表示されます。エラーメッセージの表示されたパラメータには、ユーザが値を入力する必要があります。
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
crm(live)configure template# edit
edit`コマンドを実行するとテキストエディタが起動します。エディタを使用して先ほどの設定(設定名 web)を手動で編集しましょう。ファイルの先頭に、変更が必要な項目が表示されます。よく作りこまれたテンプレートの場合、ユーザはいくつかのパラメータ値を入力するだけでクラスタの設定を行うことができます。先ほどの設定(設定名 web)の場合、変更する必要のあるパラメータの接頭辞に `%% が追加されています。
$ grep -n ^%% ~/.crmconf/web
23:%% ip
31:%% netmask
35:%% lvs_support
61:%% id
65:%% configfile
71:%% options
76:%% envfiles
上記のパラメータはユーザの環境にあわせて変更する必要があります。各行の最後尾にパラメータ値を追記してください。編集しおわった設定を再度検索すると、下記の様な表示が得られるでしょう。netmask, lvs_support, opsions, envfiles は必須パラメータではないので、空欄でもかまいません。
$ grep -n ^%% ~/.crmconf/web
23:%% ip 192.168.1.101
31:%% netmask
35:%% lvs_support
61:%% id websvc
65:%% configfile /etc/apache2/httpd.conf
71:%% options
76:%% envfiles
パラメータの設定方法は非常に単純です。パラメータの名前と値をスペースで区切って定義してください。
%% <name> <value>
`edit`コマンドで設定を編集した後、`show`コマンドで設定内容を確認してください。
crm(live)configure template# show
primitive virtual-ip ocf:heartbeat:IPaddr \
params ip="192.168.1.101"
primitive apache ocf:heartbeat:apache \
params configfile="/etc/apache2/httpd.conf"
monitor apache 120s:60s
group websvc \
apache virtual-ip
上記の手順で、Apacheと仮想IPを設定したgroupリソースを作成することができました。groupリソースの名前は`websvc`です。
`configure`レベルで`show`コマンドを実行して表示された設定内容がテンプレートとして提供されていた内容に加えて、ユーザ環境に依存するパラメータ値が正しく追加されていることを確認してください。上記の手順は基本的な設定手順となりますので、よく理解しておいてください。
では、いよいよ、設定した内容を適用させます。適用した内容は`template`レベルよりも一つ上の階層である`configure`レベルで確認することができます。
crm(live)configure template# apply
crm(live)configure template# cd ..
crm(live)configure# show
node xen-b
node xen-c
primitive apache ocf:heartbeat:apache \
params configfile="/etc/apache2/httpd.conf" \
op monitor interval="120s" timeout="60s"
primitive virtual-ip ocf:heartbeat:IPaddr \
params ip="192.168.1.101"
group websvc apache virtual-ip
ここで中止しなくてはならないのは、`apply`コマンドを実行した時点では、まだクラスタに設定が反映されていないということです。これはライブCIBを直接編集する場合だけではなくシャドウCIBを操作する場合も同じです。設定内容をクラスタに反映するためには`commit`コマンドを実行する必要があります。
次に、リソースが配置制約を設定します。配置制約は、クラスタの初期起動時に、どのノードでリソースが起動するかを定義することができます。
crm(live)configure# location websvc-pref websvc 100: xen-b
If you are not happy with some resource names which are provided by default, you can rename them now:
crm(live)configure# rename virtual-ip intranet-ip
crm(live)configure# show
node xen-b
node xen-c
primitive apache ocf:heartbeat:apache \
params configfile="/etc/apache2/httpd.conf" \
op monitor interval="120s" timeout="60s"
primitive intranet-ip ocf:heartbeat:IPaddr \
params ip="192.168.1.101"
group websvc apache intranet-ip
location websvc-pref websvc 100: xen-b
これまでの手順をおさらいしてみましょう。クラスタの設定を行うためには次の手順が必要です。
new: 新しいテンプレートを作成します。
edit: ユーザの環境に合わせてパラメータ値を設定します。
show: 設定内容を確認します。
apply: `configure`レベルで、設定内容を適用します(まだクラスらには反映されていません)。
CRM-CLIはタブキーによる入力補完が可能です。入力補完は静的にも動的にも実行可能です。後者はクラスらの状態やリソースエージェントの情報を取得するために必要となります。入力補完はコマンドのヘルプ表示やリソースに必要なパラメータを表示するためにも使用することができます。実行例
crm(live)# resource <TAB><TAB>
bye exit manage param show unmanage
cd failcount meta quit start unmigrate
cleanup help migrate refresh status unmove
end list move reprobe stop up
crm(live)# configure
crm(live)configure# primitive fence-1 <TAB><TAB>
heartbeat: lsb: ocf: stonith:
crm(live)configure# primitive fence-1 stonith:ipmilan params <TAB><TAB>
auth= hostname= ipaddr= login= password= port= priv=
crm(live)configure# primitive fence-1 stonith:ipmilan params auth=<TAB><TAB>
auth* (string)
The authorization type of the IPMI session ("none", "straight", "md2", or "md5")
crm(live)configure# primitive fence-1 stonith:ipmilan params auth=
リソースの定義については、リソースエージェントのmeta-dataに基づいて構文チェックが実行されます。例えば、次のようなチェックが実行されます。
必要なパラメータが設定されているか
定義されたパラメータが存在しているか
リソースの各オペレーション(start/stop/monitor/promote/demote)にタイムアウト値は設定されているか
パラメータ値のチェックは一般的なものなので、特に説明する必要はないでしょう。構文チェックでエラーとなった項目は、設定時にもエラーが出力されます。
オペレーションのタイムアウト値は、meta-dataに記述された推奨値よりも大きな値を設定したほうがよいでしょう。パラメータ値が小さいために発生する不具合はよくある設定ミスの一つですが、タイムアウト値が小さすぎる場合でもクラスは正常に起動するため、不具合発生時の原因解析が困難になる場合はあります。オペレーションに設定されたタイムアウト値が小さいと、クラスタはリソースの起動時に警告(warning)を出力します。警告が出力された場合はタイムアウト値を再検討してください。meta-dataで推奨されている場合はあくまで最小のタイムアウト値です。特定の環境によってはさらに大きな値が必要となる場合もありますので注意してください。
構文チェックが実行される頻度はcheck-frequencyと check-modeで定義されています。
`check-frequency`が`always`に設定されており、かつ`check-mode`が`strict`に設定されている場合、エラーは決して許容されないため、エラーを含む設定内容はクラスタに反映されません。
CRM-CLIによるクラスタの設定手順は非常にシンプルです。クラスタを管理するコマンドを実行する際、いくつかのオプションが必要となる場合もありますが、オプションはそれほど複雑ではありません。`configure`レベルで使用するコマンドに関しては複雑なオプションもいくつか存在しますが、その他のコマンドは総じて直感的に操作することができるでしょう。
コマンドの構文例: <> 文字列を表します。 [] 省略可能であることを意味します。 (...) 繰り返しを意味します。 | 多数の項目からある一項目を選択します。 (strings, :, =) その他の構文要素です。
statusコマンドはクラスタの状態を表示します。`crm_mon`コマンドで表示される内容とほぼ同じものです。引数を追加すると、詳細情報の表示や異なるフォーマットでの表示も可能です。詳細は`crm_mon`コマンドのmanを参照してください。
使用方法:
status [<option> ...]
option :: bynode | inactive | ops | timing | failcounts
cibコマンドはシャドウCIBの管理を行います。cibコマンドはCRM-CLIのトップレベルとconfigureレベルでのみ実行可能です。
実行時にcib_shadow コマンドを呼び出しているため、環境変数`CIB_shadow`が必要となります。CRM-CLIを実行中、プロンプトにはシャドウCIBもしくはライブCIBの名前が表示されます。
newコマンドは新しいシャドウCIBを作成します。newコマンドを実行するとライブCIBがシャドウCIBにコピーされます。シャドウCIBのstatusセクションを編集する場合は、`withstatus`を指定してください。詳細はcibstatus sectionを参照してください。ライブCIBを既存のシャドウCIBに強制的に上書きする場合は、`force`オプションを追加してください。
シャドウCIBをライブCIBからではなく、全く空の状態亜kら作成する場合は、`empty`を指定してください。シャドウCIBはライブCIBが存在していない状態、つまりクラスタが起動していない状態でも作成することができます。
使用方法:
new <cib> [withstatus] [force] [empty]
deleteコマンドはシャドウCIBを削除します。
使用方法:
delete <cib>
resetコマンドはシャドウCIBにライブCIBを上書きします。
使用方法:
reset <cib>
Apply a shadow CIB to the cluster.
使用方法:
commit <cib>
複数のシャドウCIBが存在する場合、編集対象のシャドウCIBをuseコマンドで選択することができます。シャドウCIBのstatusセクションを編集する場合は、`withstatus`を指定してください。詳細はcibstatus sectionを参照してください。シャドウCIBが複数存在している場合、useコマンドを使用して編集中に別のシャドウCIBを選択することもできますし、ライブCIBを選択することもできます。
使用方法:
use [<cib>] [withstatus]
diffコマンドは現在実行されているクラスタの設定とシャドウCIBの差分を表示します。
使用方法:
diff
listコマンドはシャドウCIBの一覧を表示します。
使用方法:
list
importコマンドはファイルに保存されたCIBの情報をシャドウCIBに取り込みます。CIBの情報はPE(Policy Engine)からファイルに出力されています。importコマンドは、まずプログラムが実行されたローカルファイルを参照した後、/var/lib/pengineを検索します。ファイルのフルパスを指定することも可能です。CIBの情報が保存されたファイルが見つかると、シャドウCIBにファイルの内容がコピーされます。このシャドウCIBは`configure`レベルと`cibstatus`レベルで編集可能となります。
importコマンドの引数としてシャドウCIBの名前が省略された場合は、取り込まれたファイル名がシャドウCIBの名前となります。
PEファイルは複数出力されていることが多いので、ファイル名をしている際は注意してください。
使用方法:
import {<file>|<number>} [<shadow>]
Examples:
import pe-warn-2222
import 2289 issue2
cibstatusコマンドはCIBのstatsuセクションを編集、管理します。詳細はCIB status management sectionを参照してください。
raコマンドはリソースエージェントに関連する情報を表示します。raコマンドはCRM-CLIのトップレベルとconfigureレベルでのみ実行可能です。
classコマンドはリソースエージェントのclassおよびproviderを表示します。
使用方法:
classes
listコマンドは利用可能なリソースエージェントを表示します。classパラメータに`ocf`を指定した場合、利用可能なOCF RAを表示します。
使用方法:
list <class> [<provider>]
使用例:
list ocf pacemaker
metaコマンドはリソースエージェントのmeta-dataを表示します。meta-dataにはリソースエージェントの使用方法などが記述されています。
使用方法:
meta [<class>:[<provider>:]]<type>
meta <type> <class> [<provider>] (obsolete)
使用例:
meta apache
meta ocf:pacemaker:Dummy
meta stonith:ipmilan
providerコマンドはリソースエージェントのproviderを表示します。デフォルトのclassは`ocf`です。
使用方法:
providers <type> [<class>]
使用例:
providers apache
resourceコマンドを使用してリソースを管理することができます。
resourceコマンドによる操作は、`crm_resource`コマンドなどでも代替可能です。
statusコマンドはリソースの状態を表示します。引数が省略された場合、すべてのリソースの状態が表示されます。
使用方法:
status [<rsc>]
startコマンドはリソースを起動します。startコマンドを実行すると`target-role`属性が設定されます。複数のmeta属性が存在する場合は、すべての属性が設定されます。リソースがgroupリソース、またはcloneリソースの場合、子リソースから`target-role`属性が削除されます。
使用方法:
start <rsc>
stopコマンドはリソースを停止します。stopコマンドを実行すると`target-role`属性が設定されます。複数のmeta属性が存在する場合は、すべての属性が設定されます。リソースがgroupリソース、またはcloneリソースの場合、子リソースから`target-role`属性が削除されます。
使用方法:
stop <rsc>
restartコマンドはリソースを再起動します。このコマンドは、startコマンドをstopコマンドを連続して実行します。リソースが完全に停止するまでコマンドは待機状態となります。すべてのリソースが停止した後に起動処理が実行されます。このコマンドが複数の操作を実行するため、実行中にメッセージが出力されることがあります。
使用方法:
restart <rsc>
使用例:
# crm resource restart g_webserver
INFO: ordering g_webserver to stop
waiting for stop to finish .... done
INFO: ordering g_webserver to start
#
promoteコマンドはリソースをスレーブ状態からマスター状態へプロモート(昇格)します。
使用方法:
promote <rsc>
demoteコマンドはリソースをマスター状態からスレーブ状態へデモート(降格)します。
使用方法:
demote <rsc>
manageコマンドはリソースを管理対象とみなします。manageコマンドを実行すると`target-role`属性が設定されます。複数のmeta属性が存在する場合は、すべての属性が設定されます。リソースがgroupリソース、またはcloneリソースの場合、子リソースから`target-role`属性が削除されます。
使用方法:
manage <rsc>
unmanageコマンドはリソースを管理対象外とします。unmanageコマンドを実行すると`target-role`属性が設定されます。複数のmeta属性が存在する場合は、すべての属性が設定されます。リソースがgroupリソース、またはcloneリソースの場合、子リソースから`target-role`属性が削除されます。
使用方法:
unmanage <rsc>
migrate(move)コマンドはリソースを他のノードへ移動させます。移動先のノードは引数に指定する必要がありますが、この引数が省略された場合は、リソースが現在起動しているノードに対する制約が変更されます。つまり、リソースが現行ノードで起動不可となる制約が追加されるため、リソースは他ノードへ移動することになります。制約にはlifetimeオプションを追加することも可能です。lifetimeが失効すると、現行ノードに追加された制約は無効となります。
使用方法:
migrate <rsc> [<node>] [<lifetime>] [force]
unmigrateコマンドはmigrateコマンドで作成された制約を削除します。
使用方法:
unmigrate <rsc>
paramコマンドはリソースのパラメータを表示、編集、削除します。
使用方法:
param <rsc> set <param> <value>
param <rsc> delete <param>
param <rsc> show <param>
使用例:
param ip_0 show ip
metaコマンドはリソースのmeta属性を表示、編集、削除します。現在、全てのリソースのmeta属性は、metaコマンド以外、例えば resource stop などでも操作可能となっています。
使用方法:
meta <rsc> set <attr> <value>
meta <rsc> delete <attr>
meta <rsc> show <attr>
使用例:
meta ip_0 set target-role stopped
failcountコマンドはリソースのフェイルカウントを表示、編集、削除します。
使用方法:
failcount <rsc> set <node> <value>
failcount <rsc> delete <node>
failcount <rsc> show <node>
使用例:
failcount fs_0 delete node2
cleanupコマンドはリソースの故障履歴(フェイルカウントを含む)を削除します。このコマンドはリソースの故障が発生した後に、リソースの故障履歴を削除するために使用します。ノードを指定する引数を省略した場合、すべてのノードで故障履歴の削除が実行されます。多数のノードで構成されるクラスタの場合、コマンドの実行に時間がかかる可能性がありますので注意してください。
使用方法:
cleanup <rsc> [<node>]
refreshコマンドはCIBに含まれるLRMの状態を更新します。
使用方法:
refresh [<node>]
reprobeコマンドはCRMを経由せずに起動したリソースのprobe処理を実行します。
使用方法:
reprobe [<node>]
nodeコマンドはノードの管理を行います。
statusコマンドはノードの状態を表示します。引数が省略された場合、すべてのノードの状態が表示されます。
使用方法:
status [<node>]
showコマンドはノードの設定内容を表示します。引数が省略された場合、すべてのノードの状態が表示されます。
使用方法:
show [<node>]
standbyコマンドはノードをスタンバイ化します。ノードを指定する引数が省略された場合、コマンドを実行したノードがスタンバイ化されます。lifetimeオプションにrebootを指定した場合、スタンバイ状態のノードが再起動した後、ノードはオンライン状態でクラスタに参加します。lifetimeオプションにforeverを指定した場合、スタンバイ状態のノードが再起動した後、ノードはスタンバイ状態でクラスタに参加します。
使用方法:
standby [<node>] [<lifetime>]
lifetime :: reboot | forever
onlineコマンドはノードをオンライン化します。ノードを指定する引数が省略された場合、コマンドを実行したノードがオンライン化されます。
使用方法:
online [<node>]
fenceコマンドはノードをフェンス(停止)します。STONITHリソースが利用可能な場合にのみ実行されます。STONITHリソースが設定されていない場合は、フェンス処理も実行されません・
使用方法:
fence <node>
clearnodestateコマンドは特定ノードの状態を削除します。このコマンドを実行すると、ノードの故障履歴などが削除され、オフライン状態となります。ノードがフェンスされた状態を手動で再現することができます。
注意！clearnodestateコマンドを実行してもリソースは起動したままとなる場合があります。このとき共有ディスクの二重マウントなどを引き起こす可能性もあるので注意してください。
使用方法:
clearstate <node>
deleteコマンドはノードの設定を削除します。このコマンドを実行すると、CIBからノードの情報が削除されます。メンバシップレイヤとしてHeartbeatを使用している場合は、内部的にhb_delnodeコマンドが実行されます。
使用方法:
delete <node>
attributeコマンドはノードの属性を編集します。ノードに必要なメモリサイズなどを属性値として設定することができます。
使用方法:
attribute <node> set <attr> <value>
attribute <node> delete <attr>
attribute <node> show <attr>
使用例:
attribute node_1 set memory_size 4096
status-attrコマンドはCIBに含まれるノードの属性(クラスタの実行中に変更される属性)を編集します。例えば、`pingd`リソースの属性などを編集することができます。
使用方法:
status-attr <node> set <attr> <value>
status-attr <node> delete <attr>
status-attr <node> show <attr>
使用例:
status-attr node_1 show pingd
optionsコマンドを使用して、CRM-CLIの各種オプションを設定することができます。
skill-levelコマンドを使用して、各ユーザが実行可能な操作を制限することができます。ユーザの権限は、operator, administrator, expertの3種類から選択します。operatorはresourceおよびnodeコマンドを使用することができますが、リソースの編集や削除は実行できません。administratorは、operatorの権限に加えて、configureコマンドによるクラスタの設定、およびシャドウCIBの管理を実行することができます。expertはすべての操作を実行することができます。
使用方法:
skill-level <level>
level :: operator | administrator | expert
CRM-CLIはcrm_verify, crm_resource, cibadmin などのコマンドラインツールを呼び出しているため、rootユーザやCRMのオーナ(通常はhaclusterユーザ)の権限が必要となる場合があります。rootユーザでCRM-CLIを実行している場合は、ユーザの権限について意識する必要はありません。rootユーザ以外のユーザでCRM-CLIを操作する場合は、userコマンドを使用して適切なユーザに切り替えてください。
使用方法:
user system-user
使用例:
user hacluster
editorコマンドはエディタを起動します。好みのエディタプログラムを指定することもできます。特定のエディタが設定されていない場合は、環境変数EDITORもしくは標準UNIXエディタ(vi, emacsm nano)がデフォルトで設定されます。
使用方法:
editor program
使用例:
editor vim
pagerコマンドはページャを起動します。 好みのページャプログラムを指定することもできます。特定のページャが設定されていない場合は、環境変数EDITORもしくは標準UNIXエディタ(less, more, pg)がデフォルトで設定されます。
CRM-CLIのデフォルトの設定では、CIBの要素を自動的にソートして表示します。CIBの要素を作成された順序に従って表示したい場合、sort-elementsをnoに設定してください。
使用方法:
sort-elements {yes|no}
使用例:
sort-elements no
CRM-CLIのデフォルトの設定では、コマンドの実行結果を待たずにプロンプトを復帰します。waitをyesに設定すると、コマンドの実行結果を待ってからプロンプトを復帰させます。対話式モードの場合、待機時間中はプロンプトにドットが表示されます。
使用方法:
wait {yes|no}
使用例:
wait yes
CRM-CLIにはコンソールの色設定も実装されています。文字を色分けして表示する機能と、キーワードを大文字で表示する機能が利用可能です。設定可能なパラメータは、plain, color, uppercase です。colorとuppercaseは組み合わせて使用することもできます。ここでは、colorとuppercaseを設定してみましょう。
outputoにcolorを設定します。カンマ区切り形式で複数のcolorを指定することもできます。下記の情報を出力した際に文字が色分けされます。
keywords
object ids
attribute names
attribute values
scores
resource references
CRM-CLIの出力を色分けするためには、python-cursesがインストールされている必要があります。ターミナルで利用可能な色を設定してください。デフォルトの表示を使用する場合は、normalを指定します。
デフォルト値はyellow, normal, cyan, red, green, magentaです。ターミナルの背景を黒っぽい色にしておくと見やすいでしょう。色設定を保存する方法は、別の章を参考にしてください。
使用例:
colorscheme yellow,normal,blue,red,green,magenta
CIBの情報が変更された場合、どのタイミングでXMLの構文チェックを実行するかを設定することができます。設定値は、always, on-verify, neverのいずれかです。 check-frequencyのデフォルト値はalwayです。クラスタの管理に慣れた上級者の場合はon-verifyを設定してもよいでしょう。この場合、verifyコマンドが実行されたタイミングで構文がチェックされます。
構文チェックを実行するためにはリソースエージェントが指定のディレクトリに配置されている必要があります。もし、リソースエージェントがインストールされていない環境でCRM-CLIを実行する場合は、check-frequencyをneverに設定してください。
詳細はConfiguration semantic checksを参照してください。
CIBの情報が変更された場合、check-modeの設定に応じて構文チェックの結果が出力されます。設定値は、strict, relaxのいずれかです。 構文チェックで誤りが発見された場合、デフォルトでは「エラー」レベルでメッセージが出力されますが、relaxedモードでは「警告」レベルで出力されます。デフォルト値はstrictです。
詳細はConfiguration semantic checksを参照してください。
showコマンドはCRM-CLIの設定内容を表示します。
saveコマンドはCRM-CLIの設定内容を保存します。保存先は`$HOME/.crm.rc`です。CRM-CLIの実行時に、rcファイルが自動的に読み込まれます。
configureレベルではCIBのオブジェクトに対して設定の変更を行います。
設定内容は「ノードの設定」「リソースの設定」「制約の設定」「属性の設定」の4種類に分類されます。configureレベルのコマンドは、異なるCIBオブジェクトでも共通に使用できるものがあります。
例えば、nodeコマンドは、ノードの設定変更だけではなく、ノードの属性に関する設定変更を実行することができます。
リソースの設定に使用するコマンドは次の通りです。
primitive
monitor
group
clone
ms/master (master-slave)
制約の設定に使用するコマンドは次の通りです。
location (配置制約)
colocation (同居制約)
order (順序制約)
クラスタ全体の挙動を設定するためのクラスタプロパティやリソースのメタ属性、オペレーションのデフォルト値などをも編集することができます。クラスタプロパティ、リソースのメタ属性、オペレーションのデフォルト値は属性値として処理されます。属性の設定に使用するコマンドは次の通りです。
property
rsc_defaults
op_defaults
変更された設定は、configureレベルから別のレベルに移動したとき、または、commitコマンドが実行されたときにCIBに反映されます。
nodeコマンドでノードを定義することができます。ノードの情報はCRMによって自動的に生成されます。ノードの属性値を編集する場合を除いて、このコマンドでなにか操作を実行する必要はあまりありません。ノードの属性値もこのコマンドで編集可能です。
使用方法:
node <uname>[:<type>]
[attributes <param>=<value> [<param>=<value>...]]
type :: normal | member | ping
使用例:
node node1
node big_node attributes memory=64
primitiveリソースを定義します。primitiveリソースは、groupリソースやcloneリソース、master/slaveリソースから参照されます。他のリソースから参照されていないprimitiveリソースは単純な一つのリソースとして起動します。
primitiveリソースには三種類に分類することができます。Anonymousリソースはオペレーションが定義されていないリソースです。オペレーションの設定を他のリソースから参照しない場合に使用します。一般的なリソースには、いくつかのオペレーションが定義されます。オペレーションの定義を他のリソースから参照可能な状態とするためには、operationsキーワードを追加し、$id-refパラメータにユニークなIDを設定してください。他のリソースは$id-refの値を参照します。
オペレーションの属性は、instance attributesとして保持されます。オペレーションの属性値として典型的な例は`OCF_CHECK_LEVEL`です。
使用方法:
primitive <rsc> [<class>:[<provider>:]]<type>
[params attr_list]
[meta attr_list]
[operations id_spec]
[op op_type [<attribute>=<value>...] ...]
attr_list :: [$id=<id>] <attr>=<val> [<attr>=<val>...] | $id-ref=<id>
id_spec :: $id=<id> | $id-ref=<id>
op_type :: start | stop | monitor
使用例:
primitive apcfence stonith:apcsmart \
params ttydev=/dev/ttyS0 hostlist="node1 node2" \
op start timeout=60s \
op monitor interval=30m timeout=60s
primitive www8 apache \
params configfile=/etc/apache/www8.conf \
operations $id-ref=apache_ops
primitive db0 mysql \
params config=/etc/mysql/db0.conf \
op monitor interval=60s \
op monitor interval=300s OCF_CHECK_LEVEL=10
monitorは最も一般的なオペレーションです。リソースの設定に、monitorオペレーションのみを追加することもできます。primitiveリソースは単純なリソースですが、様々な設定を追加していくと複雑になってしまう場合があります。monitorコマンドは、あくまで単純にmonitorオペレーションを追加することを目的としています。もし、monitorオペレーションに特殊な属性を設定したい場合はprimitiveコマンドを使用してopパラメータを編集してください。
使用方法:
monitor <rsc>[:<role>] <interval>[:<timeout>]
使用例:
monitor apcfence 60m:60s
上記の例では、primitiveリソースにmonitorオペレーションのinterval(60分)とtimeout(60秒)を設定しています。intervalはmonitorオペレーションが実行される「間隔」、timeoutはmonitorオペレーションが失敗した場合に故障を検知する「タイムアウト(待ち時間)」です。
groupリソースを定義します。
使用方法:
group <name> <rsc> [<rsc>...]
[meta attr_list]
[params attr_list]
attr_list :: [$id=<id>] <attr>=<val> [<attr>=<val>...] | $id-ref=<id>
使用例:
group internal_www disk0 fs0 internal_ip apache \
meta target_role=stopped
clonrリソースを定義します。一つのprimitiveリソース、または一つのgroupリソースで構成されます。
使用方法:
clone <name> <rsc>
[meta attr_list]
[params attr_list]
attr_list :: [$id=<id>] <attr>=<val> [<attr>=<val>...] | $id-ref=<id>
使用例:
clone cl_fence apc_1 \
meta clone-node-max=1 globally-unique=false
master/slaveリソースを定義します。一つのprimitiveリソース、または一つのgroupリソースで構成されます。
使用方法:
ms <name> <rsc>
[meta attr_list]
[params attr_list]
attr_list :: [$id=<id>] <attr>=<val> [<attr>=<val>...] | $id-ref=<id>
使用例:
ms disk1 drbd1 \
meta notify=true globally-unique=false
locationはリソースの配置制約を定義します。配置制約は、1つ以上のruleから構成されており、ruleに適合したリソースに対して特定のスコアが割り当てられます。
使用方法:
location <id> <rsc> {node_pref|rules}
node_pref :: <score>: <node>
rules ::
rule [id_spec] [$role=<role>] <score>: <expression>
[rule [id_spec] [$role=<role>] <score>: <expression> ...]
id_spec :: $id=<id> | $id-ref=<id>
score :: <number> | <attribute> | [-]inf
expression :: <simple_exp> [bool_op <simple_exp> ...]
bool_op :: or | and
simple_exp :: <attribute> [type:]<binary_op> <value>
| <unary_op> <attribute>
| date <date_expr>
type :: string | version | number
binary_op :: lt | gt | lte | gte | eq | ne
unary_op :: defined | not_defined
date_expr :: lt <end>
| gt <start>
| in_range start=<start> end=<end>
| in_range start=<start> <duration>
| date_spec <date_spec>
duration|date_spec ::
hours=<value>
| monthdays=<value>
| weekdays=<value>
| yearsdays=<value>
| months=<value>
| weeks=<value>
| years=<value>
| weekyears=<value>
| moon=<value>
Examples:
location conn_1 internal_www 100: node1
location conn_1 internal_www \
rule 50: #uname eq node1 \
rule pingd: defined pingd
location conn_2 dummy_float \
rule -inf: not_defined pingd or pingd number:lte 0
clocationはリソースの同居制約を定義します。二つ以上のリソースに対して、リソース間の制約を定義することができます。同居制約には依存関係の優先度を設定することができます。括弧で囲まれたリソース間の依存関係が優先されます。次の例では、リソースB, Cの依存関係がAとの依存関係よりも優先されます。
使用方法:
colocation <id> <score>: <rsc>[:<role>] <rsc>[:<role>] ...
使用例:
colocation dummy_and_apache -inf: apache dummy
colocation c1 inf: A ( B C )
orderはリソースの順序制約を定義します。二つ以上のリソースに対して、リソース間の制約を定義することができます。順序居制約には依存関係の優先度を設定することができます。括弧で囲まれたリソース間の依存関係が優先されます。次の例では、リソースB, Cの依存関係がAとの依存関係よりも優先されます。
使用方法:
order <id> score-type: <rsc>[:<action>] <rsc>[:<action>] ...
[symmetrical=<bool>]
score-type :: advisory | mandatory | <score>
使用例:
order c_apache_1 mandatory: apache:start ip_1
order o1 inf: A ( B C )
propertyコマンドはクラスタの全体的な設定を行います。CIBのcrm_configセクションに値が保持されます。
使用方法:
property [$id=<set_id>] <option>=<value> [<option>=<value> ...]
使用例:
property stonith-enabled=true
rsc_defaultsコマンドはリソースに設定するmeta属性のデフォルト値を定義します。
使用方法:
rsc_defaults [$id=<set_id>] <option>=<value> [<option>=<value> ...]
使用例:
rsc_defaults failure-timeout=3m
op_defaultsコマンドはオペレーションに設定するmeta属性のデフォルト値を定義します。
使用方法:
op_defaults [$id=<set_id>] <option>=<value> [<option>=<value> ...]
使用例:
op_defaults record-pending=true
`show`コマンドは設定された値を表示します。エディタを使用して設定値を編集することもできます。変更された値のみを表示することも可能です。CRM-CLI形式ではなくXML形式で表示することもできます。
使用方法:
show [xml] [<id> ...]
show [xml] changed
`edit`コマンドを実行するとエディタが起動します。`show`コマンドを同様に、すべての設定値を一括で編集することもできますし、特定の値のみ編集することもできます。
XML形式で編集することも可能ですがリソースや制約に設定されたIDを変更しないように注意してください。
使用方法:
edit [xml] [<id> ...]
edit [xml] changed
`delete`コマンドはオブジェクトを削除します。他のオブジェクトに対して依存関係のある設定内容(例：groupリソースの場合はprimitiveリソースに依存関係があります)が削除された場合、依存関係にあるオブジェクトも一緒に削除されます。また、削除するオブジェクトに依存関係のある制約も全て削除されます。
使用方法:
delete <id> [<id>...]
`rename`コマンドはオブジェクトの名前を変更します。リソースの名前を変更したい場合は、このコマンドを使用してください。renameコマンドを使用すると依存関係にある制約も一括して変更されます。edirコマンドでリソースの名前を変更した場合は、制約の設定が変更されないため、設定内容に矛盾が生じる可能性があります。
リソースの名前を変更したい場合は、リソースが停止した状態でrenameコマンドを実行してください。
使用方法:
rename <old_id> <new_id>
`refresh`コマンドはCIBを更新します。変更がcommitコマンドを使用してクラスタに反映されていない場合は、反映前の変更内容はすべて失われます。
使用方法:
refresh
`erase`コマンドはCIBの「すべての」設定を削除します。ただしノード情報の削除対象外です。CIBからノード情報を削除したい場合は、nodesコマンドの使用方法を参照してください。
実行中のクラスタからノードの情報を削除すると、予想外の動作が発生する可能性があるので十分に注意してください。
使用方法:
erase [nodes]
`ptest`コマンドを実行してPE(Policy Engine)の遷移グラフを表示します。
CIBには、ユーザが編集した情報だけではなく、実行中のクラスタ状態が保持されています。ユーザ編集した情報を、実行中のクラスタに反映した場合、クラスタの状態がどのように遷移するかをptestコマンドで確認することができます。
クラスタの情報を保持しているstatusセクションは cibstatus レベルのコマンドで操作することができます。`ptest`コマンドは実際のクラスタ状態を変化させずに、擬似的な遷移グラフを作成します。
`ptest`コマンドの実行結果を図で表示するためには、graphvizをインストールする必要があります。X11環境で`ptest`コマンドを実行すると、dorryが実行され遷移グラフが表示されます。
-vオプションでデバッグレベルを変更することもできます。リソースに割り当てられたスコアを表示することもできます。
使用方法:
ptest [nograph] [v...] [scores]
Examples:
ptest scores
ptest vvvvv
cibstatusコマンドはCIBのstatsuセクションを編集、管理します。詳細はCIB status management sectionを参照してください。
templateコマンドは特定のテンプレートをエディタへ取り込みます。ユーザはテンプレートを利用して設定を行うことができます。詳細はtemplate sectionを参照してください。
使用方法:
template [xml] url
使用例:
template two-apaches.txt
commitコマンドは変更内容をCIBに反映します。configureレベルで実行したコマンドはCIBに即座に反映されるわけではありません。変更内容がCIBに反映されるタイミングは、`commit`コマンドを実行したとき、またはconfigureレベルを抜けたときのいずれかです。複数のユーザが同時に編集を行っている場合は、設定内容の反映が拒否されることもあります。このような場合あh、`force`オプションを追加して強制的に変更を反映することもできます。
使用方法:
commit [force]
verifyコマンドを使用して変更内容を検証することができます。
使用方法:
verify
`CIB not supported`というエラーが出力された場合は、CIBのバージョンが古い可能性があります。updateコマンドを実行してCIBのバージョンを更新してください。updateコマンドは、内部的にcibadminコマンドを呼び出します。
# cibadmin --upgrade --force
エラーが出力されない場合でも、CIBのバージョンが古いということがわかっているのであれば、forceオプションを使用して強制的にバージョンアップしてください。
使用方法:
upgrade [force]
saveコマンドは設定内容をファイルに保存します。XML形式で保存することも可能です。
使用方法:
save [xml] <file>
使用例:
save myfirstcib.txt
loadコマンドはローカルまたはネットワーク上のファイルを読み込みます。`replace`オプションを使用した場合、現在の設定を削除して新しい設定を読み込みます。`update`オプションを使用した場合、現在の設定は上書きされます。ファイルの形式はCLIまたはXMLです。
使用方法:
load [xml] <method> URL
method :: replace | update
使用例:
load xml update myfirstcib.xml
load xml replace http://storage.big.com/cibs/bigcib.xml
CRM-CLIはXMLを編集しないことを前提としていますが、CIBの内容が複雑になると、まれにXMLを直接編集しなければならない場合があります。このような場合はxmlコマンドを使用してください。xmlコマンドを使用して、XMLの各要素を直接編集することができます。手動編集によってXMLの構文が冗長になってしまった場合などは、CRM-CLIが自動的に通常の形式へ変換します。ただし、xmlコマンドを使用することはほとんどないはずです。
使用方法:
xml <xml>
事前に準備されたテンプレートを使用してクラスタの設定を行うことができます。テンプレートは典型的なクラスタの雛形です。ユーザはテンプレートの一部のパラメータを変更するだけで容易にクラスタを設定することができます。
このコマンドはtemplateレベルだけではなく、configurationレベルのさらに下の階層(configuration/template)でも実行可能です。
newコマンドは新しいテンプレートを作成します。テンプレートは同時に複数作成することもできます。configurationレベルとtemplateレベルの設定内容は別々に保存されます。それぞれのレベルで同じ名前のテンプレートを作成することもできます。
必要なパラメータがすでにわかっている場合は、テンプレートを作成する段階で値を入力することができます。
パラメータのIDはデフォルトで設定名が使用されます。
使用方法:
new <config> <template> [<template> ...] [params name=value ...]"
Examples:
new vip virtual-ip
new bigfs ocfs2 params device=/dev/sdx8 directory=/bigfs
loadコマンドは既存のテンプレートを読み込みます。edit, show, apply の各コマンドは読み込まれたテンプレートを参照します。
使用方法:
load <config>
editコマンドでエディタを起動し、テンプレートを編集することができます。
使用方法:
edit [<config>]
deleteコマンドでテンプレートを削除することができます。読み込まれた設定は強制的に削除されます。
使用方法:
delete <config> [force]
listコマンドは利用可能なテンプレートを表示します。
使用方法:
list [templates]
applyコマンドはテンプレートの内容をライブCIBに適用します。デフォルトでは、updateオプションが使用されるためCIBは上書きされます。replaceオプションを指定した場合は、CIBは一度削除されたあと新しい設定が適用されます。
使用方法:
apply [<method>] [<config>]
method :: replace | update
showコマンドはテンプレートの内容を表示します。
使用方法:
show [<config>]
CIBのcibstatusセクションは、実行中のノードやリソースの情報を保持しています。このセクションが保持する情報が変更されるのは、リソースのオペレーションが実行されたとき、ノードの状態が変更されたときに限られています。cibstatusセクションはCRMによって変更されますが、CRMはcibstatusセクションを編集するためのユーザインターフェースを提供していません。このため、cibstatusセクションは基本的に読み込み専用領域となります。cibstatusセクションはディスク上のファイルには保存されません。cibstatusセクションの状態は、`cibadmin -Q`コマンドで表示することができます。
cibstatusセクションが変更されるとPolicy Engineの挙動にどのような影響を与えるのかは興味深い点です。cibstatsuレベルで提供されているコマンドは、CIBのstatusセクションに保持された様々な値を表示します。状態遷移の詳細については、ptestを参照してください。
loadコマンドはファイルやシャドウCIB、ライブCIBからstatusセクションを読み込みます。デフォルトではライブCIBからstatusセクションを読み込みます。ユーザがファイルやシャドウCIBからstatusセクションを読み込でいる状態では、クラスタの状態遷移がCIBに反映されない場合があります。ユーザの参照している領域をクラスタが上書きしてしまう可能性があるからです。クラスタの状態遷移をCIBに反映するためには、`locad live`コマンドを実行してください。
シャドウCIBも、statusセクションを保持していますが、この情報はシャドウCIBが作成されたときのものです。よってライブCIBとは異なるstatus情報を保持している可能性があります。よって、ptestコマンドはデフォルトでライブCIBのstatusセクションを参照します。
使用方法:
load {<file>|shadow:<cib>|live}
使用例:
load bug-12299.xml
load shadow:test1
saveコマンドはstatusセクションの内容をファイルもしくはシャドウCIBへ保存します。
CIBのフォーマットで記述されたファイルが既に存在する場合は、statusセクションの変更内容のみが置換されます、。CIBのフォーマットで記述されたファイルが存在しない場合h、statusセクションだけではなくすべての設定が保存さます。
引数が省略された場合は、statusセクションの変更はオリジナルのCIBに保存されます。オリジナルのCIBとは実行中のクラスタが参照するライブCIBのことです。
使用方法:
save [<file>|shadow:<cib>]
使用例:
save bug-12299.xml
originコマンドは実行中のクラスタで使用している設定を表示します。最新の設定が表示さえます。
使用方法:
origin
showコマンドはクラスタの状態をXML形式で表示します。出力された内容を理解するためニアh、XMLやCIBの知識が必要となります。changeオプションを使用すると、いくぶんかは読みやすい出力になるかもしれません。
使用方法:
show [changed]
nodeコマンドはノードの状態を変更します。ノードをクラスタから除外したり、新しいノードをクラスタへ参加させたりするだけではなく、クラスタに参加しているノードの状態をuncleanへ変更することもできます。
node_state, crmdの属性をonlineへ変更します。また、expexted, joinの属性をmemberへ変更します。ノードはクラスタへ参加します。
node_state, crmdの属性をofflineへ変更します。また、expextedの属性を削除します。ノードはクラスタから除外されます。
node_state, crmdの属性をuncleanへ変更します。また、expextedの属性をmemberへ変更します。ノードはクラスタ内でオフライン状態となります。
使用方法:
node <node> {online|offline|unclean}
使用例:
node xen-b unclean
opコマンドを使用してリソースのオペレーションに設定された名前などを編集することができます。オペレーションが実行されると、通常はリソースエージェントから規定の返り値が戻されます。オペレーションの状態(op_status)を変更することも可能です。オペレーションの状態をdone以外に設定する場合は、リソースエージェントからの返り値は無視されます。
使用方法:
op <operation> <resource> <exit_code> [<op_status>] [<node>]
operation :: probe | monitor[:<n>] | start | stop |
promote | demote | notify | migrate_to | migrate_from
exit_code :: <rc> | success | generic | args |
unimplemented | perm | installed | configured | not_running |
master | failed_master
op_status :: pending | done | cancelled | timeout | notsupported | error
n :: the monitor interval in seconds; if omitted, the first
recurring operation is referenced
rc :: numeric exit code in range 0..9
使用例:
op start d1 xen-b generic
op start d1 xen-b 1
op monitor d1 xen-b not_running
op stop d1 xen-b 0 timeout
endコマンドは現在のレベルを終了して、一つ上のレベルへ移動します。このコマンドはどのレベルでも利用可能です。
使用方法:
end
helpコマンドは、現在のレベルで実行可能なコマンドや、コマンドのオプションについての情報を表示します。このコマンドはどのレベルでも利用可能です。
使用方法:
help [<topic>]
CRM-CLIを終了します。