3 / 612345...Last »

Pacemaker で扱えるリソースの種類 (Primitive, Clone, Master/Slave, Group)

By t-matsuo, on 10月 15th, 2014%

Pacemakerでは現在、Primitive, Clone, Master/Slave という大きく分けて3つの種類のリソース、および、PrimitiveをまとめたGroupというリソースを定義することができます。これらのリソースの違いについて簡単に説明します。

これらの概念は、Pacemaker-1.0系およびPacemaker-1.1系で共通です。

Primitive

まず、一番よく使われるのがこの Primitive リソースです。これは全てのリソース定義の基礎になります。

これは、通常のAct-Standby構成で用いるリソースで、どこか一カ所のノードで動くことができます。よって、クラスタ全体のある1ノードだけで動いていればよいリソースに使用し、リソースが故障すれば、他のノードにフェールオーバーさせることができます。データベースやメールサーバのようなものをHAクラスタリングする場合は通常このリソースを定義することになります。

 

Clone

Cloneリソース は、Primitive リソースを複数のノードで動作させたい場合に使用します。そのため定義方法は、まずPrimitive を定義し、それをClone化するという流れになります。

あるアプリケーションを複数のノードで動かしたい場合、Primitiveだけで実現しようとすると、動かしたいノード数分だけ定義する必要がありますが、Cloneの場合は1つのCloneリソースを定義するだけで動かすことができます。

代表的な使用例として、ネットワークの疎通監視に使用するpingd リソースエージェント(以下RA) があります。ネットワーク越しにサービスを提供するAct-Standby 構成において、ActのPrimitiveリソースが故障し、Standby ノードにフェールオーバーしても、Standby ノードのネットワークが切れていては意味がありません。こういった事態を避けるために、pingd RA を全てのノードで動作させ、サービスを提供していないノードでもネットワークを監視し、ネットワークが故障してしまった場合は、そのノードにサービスがフェールオーバーしないようにするのが通常の使い方です。

なお、RAの実装としては、Primitive, Clone に違いはないため、動作が保証されているかは別として、Primitive で定義できる RAはClone化できます。

 

Master/Slave

Master/Slave リソースは、Clone リソースをさらに発展させたもので、Cloneリソースで親子の関係があるリソースに使用します。定義方法は、まずPrimitive を定義し、それをMaster/Slave化するという流れになります。

代表的な使用例としては、データのレプリケーションに使用するDRBD用のRA があります。DRBDでは、PrimaryとSecondaryと呼ばれる状態があり、Primaryではデータの読み書き、SecondaryではPrimaryからレプリケーション用のデータを受信し、ディスクに書き込みます。そのため、DRBDは複数のノードで動いている必要があり、さらにPrimaryとSecondaryの状態を区別する必要が出てきます。これをPacemakerのMaster/Slave を使って実現しています。

また、PostgreSQL用のRA(pgsql)でストリーミングレプリケーションを制御する際にもMaster/Slaveリソースを使用します。ストリ－ミングレプリケーションでは片方のPostgreSQLをMaster(読み書き可能)、もう片方をSlave(書き込み不可)とし、Masterに書き込まれたデータをSlaveに転送し続けることで、両系のデータを常に同じになるよう保っています。PostgreSQLのストリーミングレプリケーションとPacemaker(pgsql RA)を連携・制御する構成をPG-REXと呼称しています。詳細はPG-REXコミュニティ(日本語)で。

なお、Master/Slave では、Primitive, Clone 用のRAに実装されている、start, stop というリソースの起動・停止操作に追加して、promote, demote という親に昇格、子どもに降格させる操作がRAに実装されている必要があるため、Primitive や Clone 用のRAをそのままMaster/Slave 化することはできません。

 

Group

Group リソースは、複数のPrimitiveリソースを１つのグループとしてまとめたリソースです。
同じグループとなったPrimitiveリソースは必ず同じノードで、定義された順番に起動／停止します。

Pacemaker内部の動作としては「colocation(同居)制約」と「order(順序)制約」の両制約をかけたのと同等です。
制約について詳しくは、こちらを参照ください。

group

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Continue reading Pacemaker で扱えるリソースの種類 (Primitive, Clone, Master/Slave, Group)

Comments are closed   読み物    

動かして理解するPacemaker ～CRM設定編～ その３

By higashik, on 1月 14th, 2014%

変更履歴

  • 2013.9.19 初版制定
  • 2016.3.24 Pacemaker-1.1に対応

■はじめに

Linux-HA Japanをご覧の皆さんこんにちは。Linux-HA Japanの中の人、ひがしと申しますm(_ _)m

「動かして理解するPacemaker ～CRM設定編～ その３」ということで、前々回、前回の続きです。

今回で、例の設定ファイルが制御している以下7項目をすべて読み解くことになります。3回に渡ったCRM設定編は今回で最後となります。

  • 1. STONITHは無効です。(その１で読み解き済み)
  • 2. 1回のリソース故障でF/Oします。自動フェイルバックはしません。(その１で読み解き済み)
  • 3. resource1, resource2という名前のリソースをgrpという名前のgroup(グループ)にします。(その２で読み解き済み)
  • 4. resource3という名前のリソースをclnResourceという名前のclone(クローン)リソースとし、両マシンで起動します。(その２で読み解き済み)
  • 5. resource1,2,3のリソースは、必ずresource3(clnResource)→resource1→resource2の順で起動します。(一部その２で読み解き済み)
  • 6. grpはどちらか片方のマシンで起動します。両マシンが稼働可能な状態の場合、pm01を優先します。
  • 7. resource3(clnResource)が起動していないノードではresource1およびresource2(grp)は起動しません。

※前回、前々回の記事でリソース名をCRM設定とは異なる「dummy1」などと記載していましたが、「resource1」の誤りでした。すみません。

 

今回注目するのは以下の部分です。

### Resource Location ###
location rsc_location-1 grp \
    rule 200: #uname eq pm01 \
    rule 100: #uname eq pm02

### Resource Colocation ###
colocation rsc_colocation-1 INFINITY: grp clnResource

### Resource Order ###
order rsc_order-1 0: clnResource grp symmetrical=false

この箇所ではlocation, colocation, orderの３つのコマンドを使用しています。

この３つはいずれもリソースに対し「制約」を設定するためのコマンドです。

「制約」を使用すると、リソースが起動する際の以下３つの条件を設定することができ、それぞれがコマンドに対応しています。

  • location　→場所：どのノードで起動するか？
  • colocation→同居：どのリソースと一緒に起動するか？
  • order　　 →順序：どのリソースの前/後に起動するか？

早速、この３コマンドの説明を、と言いたいところですが、その前に制約を理解するのに重要な概念があります。
それは「スコア値」です。

詳細は後ほど説明しますが、制約の３コマンドはいずれもあるルールに対しスコア値を設定するものです。
なので、まずはスコア値の説明からしたいと思います。

■スコア値の大きいノードでリソースは起動する

スコア値は、リソースをどのノードで起動するかの優先度を示す値です。
ノードを起動したり、リソースを追加したり、故障が発生したり、とクラスタの状態に変化があった場合にPacemakerが自動的に(再)計算します。

Pacemakerは算出したスコア値を比較し、最も大きな値のノードでリソースを起動します。
算出したスコア値が負の値場合、そのノードでそのリソースを起動することはできません。

スコア値は以下の範囲のいずれかになります。

-INFINITY < 負の値 < 0 < 正の値 < INFINITY

「-INFINITY(マイナス無限大)」と「INFINITY(無限大)」は特殊な値で、前者は「禁止」、後者は「強制」を示します。
それぞれ他の値との演算結果は以下のように定義されています。

  • 他の値 + INFINITY = INFINITY
  • 他の値 – INFINITY = -INFINITY
  • INFINITY – INFINITY = -INFINITY

1,2番目の演算結果はなんとなくわかりますが、3番目の演算結果はちょっと不思議な気がします。
数学的に言えば∞-∞は不定です。が、クラスタのリソースが起動するかどうかが不定となっては不便です。
-INIFNITYは典型的には故障が発生したノードに付与されます。もしINIFINITY – INFINITYが不定だと、後述の制約コマンドでINFINITYを付与したノードで故障が発生した場合、リソースが起動するかどうかが不定になってしまいます。
これを避け、故障したノードでは起動しない、と判断するため-INFINITYを優先しているのです。

スコア値は基本的にはPacemakerがクラスタの状況に応じ自動的に算出しますが、後述の「制約」により特定に場合のスコア値をユーザが決める(Pacemakerに与える)ことができます。
「制約」を上手に活用しスコア値を操作することで、リソースの起動をユーザの意のままに操ることができるのです。

■locationで起動するノードを制約

locationは起動するノードを制約するコマンドです。
そのノードの状態を評価し、それにマッチした場合のスコア値を定義することで設定します。

locationの概要と代表的な書式は以下のようになります。

概要 論理演算式を満たした場合のスコア値を指定することで、リソースが起動するノードを制約します。
論理演算式では主に「ノード名」と「属性値」を評価できます。
rule～の行を複数記述することで１リソースに複数の評価式およびスコアを設定することができます。
書式 location <制約のID> <リソースID> \
  rule <スコア値>: <ノード状態の評価式> [and|or <ノード状態の評価式>…] [\]
  [rule …]
設定項目 制約のID この制約を一意に識別するためのIDを付与します。英数字から成るクラスタ内で一意の任意の文字列を指定します。
リソースID 制約の対象となるリソースをリソースIDで指定します。rule～の行を複数記述することで１リソースに複数のスコア値を設定することができます。
スコア値 右側の論理演算式が真の場合のスコア値を指定します。
ノード状態の評価式 ノード状態の評価式は主に「ノード名の評価」および「属性値の評価」「属性値の有無」の３パターンをよく使用します※。
記法はそれぞれ以下のような形です。

#uname <演算子> <値>
ノード名と<値>を、<演算子>で比較・評価します。
「#uname」という記述はそのノードのノード名に展開され評価されます。
<値>には任意の英数字を比較対象として指定することができます。
<属性値名> <演算子> <値>
<属性値名>で指定した属性値と<値>を、<演算子>で比較・評価します。
<値>には任意の英数字を比較対象として指定することができます。
defined|not_defined <属性値名>
<属性値名>で指定した属性値が定義されているかどうかを評価します。
definedは当該属性値が定義されているときに真、not_definedは定義されていないときに真となります。

※日付も評価することができますが、ここでは説明を省略します。知りたい方はCRM-CLI公式マニュアル(日本語版)参照をしてください。

<演算子>には以下を使用することができます。

  • lt : 左辺が右辺より小さい場合に真となる
  • gt : 左辺が右辺より大きい場合に真となる
  • lte: 左辺が右辺より小さいか等しい場合に真となる
  • gte: 左辺が右辺より大きいか等しい場合に真となる
  • eq : 左辺と右辺が等しい場合に真となる
  • ne : 左辺と右辺が等しくない場合に真となる

なお、andおよびorを使用し、複数の論理演算式の結果を統合することができます。

評価式の中で登場する属性値とは、Pacemakerが保持している値で、ノード毎にリソースの状態や、クラスタの状態を表します。
状況に応じて値が変化することで、そのノードの状態を知ることができます。
典型的にはリソースエージェントがリソースの状態をリアルタイムに示すために使用します。
例えばネットワーク疎通を確認するリソース(ocf:pacemaker:pingd)は、ネットワークが疎通している場合、指定した属性値に値を加算し、疎通していないと値を減算します。属性値は監視の度にリアルタイムに変化するため、この属性値を見ることで、今現在ネットワークが疎通しているのかを確認できるようになっています。

なお、crm_monコマンドに-Aオプションをつけると、属性値を表示させることができます。





以下の部分は、グループgrpに対し、ノードpm01での起動にはスコア200を、ノードpm02での起動にはスコア100を指定しています。
つまり、grpの起動ノードとしてpm01を優先するよう制約しています。

location rsc_location-1 grp \
    rule 200: #uname eq pm01 \
    rule 100: #uname eq pm02

これで、以下の項目が読み解けました。

  • 6. grpはどちらか片方のマシンで起動します。両マシンが稼働可能な状態の場合、pm01を優先します。

■colocationで同居するリソースを制約

colocationは指定した(複数の)リソースが同一ノードで起動することに対しスコア値を設定します。

colocationの概要と代表的な書式は以下のようになります。

概要 あるリソースと、別のリソースが同一ノードに存在することに対しスコア値を設定します。
書式 colocation <制約のID> <スコア値>: <リソースID>[:<ロール>] <リソースID>[:<ロール>] [<リソースID>[:<ロール>]] …
設定項目 制約のID この制約を一意に識別するためのIDを付与します。英数字から成るクラスタ内で一意の任意の文字列を指定します。
スコア値 右側に記述したリソースを同居させることに対するスコア値を指定します。
典型的にはINFINITYを指定し同居を強制、または-INFINITYを指定し別ノードでの起動を強制します。
リソースID 制約の対象となるリソースをリソースIDで指定します。
左側のリソース起動時に右側のリソースが同一ノードに存在することに対しスコア値を設定します。
リソースIDを記述する順序で意味合いが若干変わることに注意してください。
なお、「:<ロール>」とロールを記述することもできます。ロールはmsコマンドでリソースを定義した場合に必要となる概念です。MasterやSlave等のリソース状態を指します。msコマンドについては今回の記事では対象としていないため詳細説明は省略します。

以下の部分は、グループgrpの起動時に、clnResourceが同じノードで起動する(している)ことを強制しています。

colocation rsc_colocation-1 INFINITY: grp clnResource

これで、以下の項目が読み解けました。

  • 7. resource3(clnResource)が起動していないノードではresource1およびresource2(grp)は起動しません。


■orderで順序を制約

orderは指定した(複数の)リソースのアクションを行う順序に対しスコア値を設定します。

orderの概要と代表的な書式は以下のようになります。

概要 指定した(複数の)リソースのアクションを行う順序に対しスコア値を設定します。
アクションには、起動、停止、昇格等が含まれます。
書式 order <制約のID> <スコア値>: <リソースID>[:<アクション>] <リソースID>[:<アクション>] …
[symmetrical=true|false]
設定項目 制約のID この制約を一意に識別するためのIDを付与します。英数字から成るクラスタ内で一意の任意の文字列を指定します。
スコア値 この制約に対するスコア値を指定します。
0より大きい値を指定すると、左側のリソースが状態変化した場合、右側のリソースにも影響(停止や起動を実行)します(Mandatory Ordering)。
0を指定すると、左側のリソースのアクション実行時以外の状態変化が右側のリソースに影響しません。(Advisory Ordering)
ちょっと難しい言い回しになりましたが、0とINFINITYを設定した場合、以下のようなイメージになると理解すればよいでしょう。

  • 0 :なるべく、左→右の順に<アクション>する
  • INFINITY:絶対に、左→右の順に<アクション>しなければならない
リソースID 制約の対象となるリソースをリソースIDで指定します。
左側のリソース起動時に右側のリソースが同一ノードに存在することに対しスコア値を設定します。
リソースIDを記述する順序で意味合いが若干変わることに注意してください。
アクション アクションは対象となるリソースを起動(start)、停止(stop)、昇格(promote)、降格(demote)のうち、どれを実行する場合の制約かを指定します。
指定しない場合デフォルトはstartです。
※昇格(promote)および降格(demote)はmsコマンドでリソースを定義した場合に必要となる概念です。msコマンドについては今回の記事では対象としていないため詳細説明は省略します。
symmetrical symmetricalはこの制約の逆順の制約を自動的に設定するかどうかをtrue(=する)またはfalse(=しない)で指定します。
例えば、「起動をA→Bの順で行う」という制約に対し、「停止はB→Aの順で行う」という逆の制約を自動的に設定できます。
指定しない場合デフォルトはtrueです。

以下の部分は、clnResource→grpの順に起動することを示しています。
スコア値は0のため、起動後のclnResourceの状態変化はgrpに影響しません。
symmetricalをfalseにしているため停止順は不定です。

### Resource Order ###
order rsc_order-1 0: clnResource grp symmetrical=false

これで以下の項目が読み解けました。

  • 5. resource1,2,3のリソースは、必ずresource3(clnResource)→resource1→resource2の順で起動します。




お気づきの方もいるかもしれませんが、前回ご紹介したgroupコマンドも、同居と順序を指定するものでした。
例えば、「group grp1 resource1 resource2」は「resource1と2は必ず同居し」、「resource1→resource2の順序で起動」を定義します。

groupは、colocationとorderを組み合わせて再現することができます。



次頁で、今回わかったことを応用した実験をしてみましょう。

Comments are closed   読み物

動かして理解するPacemaker ～CRM設定編～ その２

By higashik, on 10月 15th, 2013%

変更履歴

  • 2013.9.19 初版制定
  • 2016.3.23 Pacemaker-1.1に対応

■はじめに

Linux-HA Japanをご覧の皆さんこんにちは。Linux-HA Japanの中の人、ひがしと申しますm(_ _)m

「動かして理解するPacemaker ～CRM設定編～ その２」ということで、前回の「その１」の続きです。

早速、前回記事に引き続き、CRM設定ファイルを解読していきましょう。

 

前回は、例の設定ファイルが制御している以下7項目のうち、上から2項目のからくりを読み解きました。

  • 1. STONITHは無効です。(その１で読み解き済み)
  • 2. 1回のリソース故障でF/Oします。自動フェイルバックはしません。(その１で読み解き済み)
  • 3. resource1, resource2という名前のリソースをgrpという名前のgroup(グループ)にします。
  • 4. resource3という名前のリソースをclnResourceという名前のclone(クローン)リソースとし、両マシンで起動します。
  • 5. resource1,2,3のリソースは、必ずresource3(clnResource)→resource1→resource2の順で起動します。
  • 6. grpはどちらか片方のマシンで起動します。両マシンが稼働可能な状態の場合、pm01を優先します。
  • 7. resource3(clnResource)が起動していないノードではresource1およびresource2(grp)は起動しません。

※2013.1.22 リソース名をCRM設定とは異なる「dummyN」などと記載していましたが、「resourceN」の誤りでした。修正しました。すみません。

今回は、3,4番目および5番目の一部(下線部)を読み解きます。

 

今回注目するのは以下の部分です。

### Group Configuration ###
group grp \
    resource1 \
    resource2

### Clone Configuration ###
clone clnResource \
    resource3

### Primitive Configuration ###
primitive resource1 ocf:heartbeat:Dummy \
    op start interval="0s" timeout="300s" on-fail="restart" \
    op monitor interval="10s" timeout="60s" on-fail="restart" \
    op stop interval="0s" timeout="300s" on-fail="block"

primitive resource2 ocf:heartbeat:Dummy \
    op start interval="0s" timeout="300s" on-fail="restart" \
    op monitor interval="10s" timeout="60s" on-fail="restart" \
    op stop interval="0s" timeout="300s" on-fail="block"

primitive resource3 ocf:heartbeat:Dummy \
    op start interval="0s" timeout="300s" on-fail="restart" \
    op monitor interval="10s" timeout="60s" on-fail="restart" \
    op stop interval="0s" timeout="300s" on-fail="block"

この箇所ではgroup, clone, primitiveの3コマンドを使用し、どんなリソースを使用するかを定義しています。

■primitiveでリソースを定義

primitiveコマンドはクラスタ内で使用したい個々のリソースの定義を行います。

primitiveコマンドの概要と書式を以下に示します。

概要 リソースIDおよびリソースエージェント(RA)を指定し、クラスタ内で使用するリソースを定義します。
リソースの起動、監視、停止それぞれの制御時のタイムアウトおよびそれぞれの制御が失敗したときの挙動も指定します。
書式 primitive リソースID RA名
    [meta リソースの動作設定…]
    [params RAに渡すパラメータ…]
    [op start|stop|monitor オペレーション時の設定…]
設定項目 リソースID リソースの名前を任意の英数字で定義します。クラスタ内で一意でなければなりません。
CRMファイルの他の箇所でこのリソースを示す場合やcrm_monコマンドでの表示等にも使用します。
RA名 使用するRAの種類とファイル名を「:」で区切った記法で指定します。よく使用するパターンは以下です。

ocf:heartbeat:RAファイル名
/usr/lib/ocf/resource.d/heartbeat/RAファイル名※　に配置されたスクリプトをRAとして使用します。
ocf:pacemaker:RAファイル名
/usr/lib/ocf/resource.d/pacemaker/RAファイル名※　に配置されたスクリプトをRAとして使用します。
lsb:initスクリプト名
/etc/init.d/initスクリプト名　に配置されたスクリプトをRAとして使用します。
Linuxに付属のinitスクリプトをRAとして使用することができます。
ただし、initスクリプトがLSBと呼ばれる仕様に準拠している必要があります。
stonith:プラグインファイル名(パス)
STONITH機能を使用する場合、STONITHの方法に応じた専用のプラグインを指定します。
/usr/lib64/stonith/プラグイン名※　に配置されたプログラムを使用します。

ocf:～は「:」で区切られた3つの記述の1,2番目でRAの種別を、3番目がRAのファイル名を示します。
lsb:～およびstonith:～は、「:」で区切られた1番目でRAの種別を、2番目がスクリプト/プログラムのファイル名です。
※Pacemakerをインストールすると、このディレクトリに様々なRA、プラグインが配置されます。

リソースの動作設定 リソースの故障時等の動作を個別に設定します。
前回ご紹介したrsc_defaultsコマンドで指定できるresource-stickinessやmigration-thresholdパラメータを使用できます。
RAに渡すパラメータ RAがリソースの制御のためにパラメータを必要とする場合、「パラメータ名=”値”」の形式でここで指定します。
例えばファイルシステムをマウント・監視するリソース(ocf:heartbeat:Filesystem)の場合、ファイルシステムタイプ、マウントポイント、対象デバイスといったような情報をパラメータで与えます。
Dummy RAのように、動作にパラメータを必要としないRAの場合、記述は必要ありません。

crmコマンドに”ra info RA名”と引数を付与すると、当該RAのパラメータを含む、簡単なマニュアルが表示されます。この表示も参考にしてください。

 # crm ra info ocf:heartbeat:Filesystem
 RAの簡易説明...
オペレーション時の設定 リソースの起動(start)、停止(stop)、監視(monitor)の各オペレーション時のタイムアウト等を「設定=”値”」の形式で設定します。よく使用するのは以下の設定です。

interval
オペレーションの間隔を秒で指定します。開始、停止のように繰り返さないオペレーションの場合、0を指定します。
timeout
オペレーションが完了するのを待つ最大時間を秒で指定します。この時間を過ぎてもオペレーションが成功しない場合、失敗とみなします。
on-fail
オペレーションが失敗した場合の動作を指定します。
よく使用するのは以下の動作です。

  • block ：それ以降のあらゆるクラスタ動作をそのままの状態で中止します。
  • restart：このリソースの再起動（停止→起動）を試みます。他のノードへ再配置される場合があります。再起動に失敗した場合、再起動を繰り返し試みます。
  • fence ：STONITH機能を使用して、対象ノードの強制停止を試みます。当該リソースは他のノードへ再配置されます。STONITH機能が無効の場合、指定することはできません。
  • ignore ：オペレーションの失敗を無視し、このリソースに対する動作以外のクラスタ動作を継続します。
  • stop ：このリソースの停止を試みます。他のノードへの再配置はされません。停止に失敗した場合、停止を繰り返し試みます。


以下の部分は、リソースIDがresource1で、/usr/lib/ocf/resource.d/heartbeat/Dummy をRAとするリソースを定義していることになります。
開始・停止のタイムアウトは300秒、監視のタイムアウトは60秒です。
開始および監視に失敗したときはリソース再起動、停止に失敗したときはクラスタのそれ以後の動作を中止します。

primitive resource1 ocf:heartbeat:Dummy \
    op start interval="0s" timeout="300s" on-fail="restart" \
    op monitor interval="10s" timeout="60s" on-fail="restart" \
    op stop interval="0s" timeout="300s" on-fail="block"

resource2, 3 についても同様です。

■groupでリソースをひとまとめに

groupは、primitiveで定義した個々のリソースをグループ化します。
グループ化したリソースに対しては、以下の制御が行われます。

  • 常に同一サーバで起動する。
  • groupコマンドに指定した順にリソースを起動する。またその逆順に停止する。

グループ化は、あるサービスを提供するのに、複数のリソースを同時に使用しなければならない場合に使用します。
例えば、データベースをクラスタ化する場合、データベースそのものの他に、共有ディスクや、アクティブ側のデータベースへアクセスするためのIPアドレスなどを同時に起動しなければなりません。
しかも、共有ディスクはデータベースより先に起動(マウント)しなければなりません(さもないとデータファイルがなくデータベースを起動できないでしょう)。

groupコマンドの書式は以下です。

書式 group グループID リソースID…
設定項目 グループID グループの名前を任意の英数字で定義します。クラスタ内で一意でなければなりません。
リソースID グループ化する対象リソースをprimitiveコマンドで定義したリソースIDで指定します。


以下部分は、リソースID resource1およびresource2をグループ化しています。グループIDはgrpです。

### Group Configuration ###
group grp \
    resource1 \
    resource2

これにより、resource1とresource2は常に同じノードで起動し、resource1 → resource2 の順で起動し、その逆順で停止します。

■cloneで複数ノードへリソース複製

cloneは、primitiveで定義した個々のリソースをクローン化します。
クローン化したリソースは、通常のリソースと異なり、複数のノード上で同時に起動します。リソースが複製（クローン）され、複数ノードへ配置されるイメージです。

例えば、ノードのネットワーク疎通を確認するリソース(Pacemaker-1.0系の場合「ocf:pacemaker:pingd」、1.1系の場合「ocf:pacemaker:ping」)を使用する場合、アクティブ側ノードはもちろん、スタンバイ側ノードでもいつでもサービスが提供できるよう、常にアクティブ側と同じようにネットワーク疎通を確認しておく必要があります。
このようなときのためにcloneは用意されています。

cloneコマンドの書式は以下です。

書式 clone クローンリソースID リソースID…
    [meta クローンリソース動作設定…]
設定項目 クローンリソースID クローンリソースの名前を任意の英数字で定義します。クラスタ内で一意でなければなりません。
リソースID クローン化する対象リソースをprimitiveコマンドで定義したリソースIDで指定します。
クローンリソース動作設定 クローンリソースの動作に関する設定を「設定名=”値”」という書式で記述します。
以下のような設定が可能です。

  • clone-max :クラスタ全体で、いくつリソースを起動するかを指定します。デフォルトはクラスタに含まれるノード数です(つまり全ノードで当該リソースが起動します)。
  • clone-node-max:1ノードで当該リソースがいくつ起動するかを指定します。デフォルトは1です。


以下の部分は、リソースID resource3をクローン化しています。クローンリソースIDはclnResourceです。
clone-max, clone-node-maxは指定していないため、全ノード(pm01,pm02)で1つずつresource3リソースが起動します。

### Clone Configuration ###
clone clnResource \
    resource3

 

さぁ、以上で、3,4番目および5番目の一部の制御が理解できました。

  • 3. dummy1, dummy2という名前のリソースをgrpという名前のgroup(グループ)にします。
    • →primitiveでdummy1, dummy2を定義し、groupでグループ化しています。
  • 4. dummy3という名前のリソースをclnDummyという名前のclone(クローン)リソースとし、両マシンで起動します。
    • →cloneコマンドでクローンリソースを定義しています。clone-maxを指定していないので両(全)ノードで起動します(デフォルト)。
  • 5. dummy1,2,3のリソースは、必ずdummy3(clnDummy)→dummy1→dummy2の順で起動します。
    • →dummy1→dummy2の順はこれらがgroupのためです。(dummy3の起動順のからくりは次回説明します。)

次ページでこれらの動作を実験で確認します。


コラム LSBって？
LSBはLinux Standard Baseと呼ばれる、Linuxの内部構造の仕様です。
PacemakerがinitスクリプトをRAとする場合、このLSBに準拠していることを前提に制御をおこないます。
具体的には以下を前提としています。


  • 「start」「stop」「status」の３つのメソッドが定義されていること。
    • 

  • 「start」メソッドはサービス(リソース)の状態に応じ以下の動作および返り値を返すこと。
    • 

    • サービスが停止している場合：サービスを起動し0を返す。
      • 

    • サービスが(すでに)起動している場合：0を返す。
    

  • 「stop」メソッドはサービス(リソース)の状態に応じ以下の動作および返り値を返すこと。
    • 

    • サービスが(すでに)停止している場合：0を返す。
      • 

    • サービスが起動している場合：サービスを停止し、0を返す。
    

  • 「status」メソッドはサービス(リソース)の状態に応じ以下の動作および返り値を返すこと。
    • 

    • サービスが停止している場合：3を返す。
      • 

    • サービスが起動している場合：0を返す。
    

  • それぞれ失敗した場合は、0および3以外のエラーコードを返すこと。


独自のRAを作成する場合も、この仕様に準拠する必要があります。詳細は公式マニュアルを参照してください。
Comments are closed   読み物

動かして理解するPacemaker ～CRM設定編～ その１

By higashik, on 9月 19th, 2013%

変更履歴

  • 2013.9.19 初版制定
  • 2016.3.23 Pacemaker-1.1に対応

■はじめに

Linux-HA Japanをご覧の皆さんこんにちは。Linux-HA Japanの中の人、ひがしと申しますm(_ _)m

みなさん、Pacemaker触っていますか？

OSCなどのブースや講演で中の人がPacmakerをデモしているのを見かけると思いますが、ああいう構成って一から自分で作ろうとするとまぁ大変ですよね。

個人的に最初につまづくのが”CRM設定ファイル“だと思います。

例えば、2011年福岡で開催されたOSCで講演したデモ環境のCRM設定ファイル（これに含まれるdemo4.crmファイル）を見てみてください。

長い・・しかも設定ファイルなのに￥記号たくさんww

やばい・・ゲシュタルト崩壊して￥がVサインに見えてきた(注1)。。だからみんなPacemakerのことピースメーカーって呼んじゃうんだな(注2)・・そのせいで呼び名が変更されるって記事もあったし・・・

注1:＼に見えてる人はごめんなさい

注2：本当はペースメーカーです

でもしかし！このCRM設定ファイルの攻略なしにPacemakerでHA環境は作れないのです。

というわけで本記事ではこのCRM設定ファイルを読める/書けるようになることを目標に、全３回の連載形式でいろいろ書いていこうと思います。

動かして理解するPacemaker ～CRM設定編～　連載一覧（全３回）

■CRM設定ファイルとは

CRM設定ファイルは、Pacemakerに、「どのようなリソース（※1）をどこで稼働させるか？」「いつフェイルオーバ(※2)するのか？」というようなことを教えるための設定ファイルです。

賢明な読者の中には、「その設定ってコマンドラインからやるんじゃなかったっけ？」とお思いの方もいるかもしれません。

その通り！

過去に掲載された記事の中でも、crmコマンドというPacemaker付属のコマンドラインで行っています。

CRM設定ファイルはこのcrmコマンドに流し込むコマンドを列挙したものです。

小規模な設定であればコマンドを直接打ってもいいですが、大規模になるとファイルに書いておいた方が保存、配布などが楽になります。Windowsでいうバッチファイル、Linuxでいうシェルスクリプトみたいなものですね。

これで、一つ謎が解けました。そうですCRM設定ファイルに「\」が多かったのはその箇所が本来1行で書くコマンドラインだからです。

ちなみにcrmコマンドは、設定のみならず、クラスタの状態確認、操作等、様々な機能を持っています。まさにクラスタのシェルですね。

さぁ以上を踏まえて、早速、CRM設定ファイルを読んでいきましょう。

※1 リソースって何だっけ、という人は、この記事の「リソース制御機能」を参照してください。
※2 以後フェイルオーバを「F/O」と略記します。

■CRM設定ファイルの構成

前述の2011年福岡で開催されたOSCで講演したデモ環境のCRM設定ファイルをもう一度見てみてください。

心の眼でよーく見ると、行の始めは以下の８種類のコマンドのどれかであることがわかります。

ちなみに行頭が「#」はコメントアウト、「\」は行が続くことを表します。

  • property
  • rsc_defaults
  • group
  • clone
  • primitive
  • location
  • colocation
  • order

次回以降で紹介しますが、Master-Slave構成を使う場合、

  • ms

というコマンドも使用します。

上記９コマンドあれば、たいがいのHA構成は定義できちゃいます。

Pacemaker-1.1系の場合、上記に加え fencing_topology というコマンドも使用します。詳細はOSCデモ機の設定を公開しますをご覧ください。

早速、９コマンドの解説を、、と言いたいところですが、ここで１つCRM設定ファイルの例を示します。

### Cluster Option ###
property no-quorum-policy="ignore" \
    stonith-enabled="false" \
    crmd-transition-delay="2s"

### Resource Defaults ###
rsc_defaults resource-stickiness="INFINITY" \
    migration-threshold="1"

### Group Configuration ###
group grp \
    resource1 \
    resource2

### Clone Configuration ###
clone clnResource \
    resource3

### Primitive Configuration ###
primitive resource1 ocf:heartbeat:Dummy \
    op start interval="0s" timeout="300s" on-fail="restart" \
    op monitor interval="10s" timeout="60s" on-fail="restart" \
    op stop interval="0s" timeout="300s" on-fail="block"

primitive resource2 ocf:heartbeat:Dummy \
    op start interval="0s" timeout="300s" on-fail="restart" \
    op monitor interval="10s" timeout="60s" on-fail="restart" \
    op stop interval="0s" timeout="300s" on-fail="block"

primitive resource3 ocf:heartbeat:Dummy \
    op start interval="0s" timeout="300s" on-fail="restart" \
    op monitor interval="10s" timeout="60s" on-fail="restart" \
    op stop interval="0s" timeout="300s" on-fail="block"

### Resource Location ###
location rsc_location-1 grp \
    rule 200: #uname eq pm01 \
    rule 100: #uname eq pm02

### Resource Colocation ###
colocation rsc_colocation-1 INFINITY: grp clnResource

### Resource Order ###
order rsc_order-1 0: clnResource grp symmetrical=false

この例は比較的単純ですが、msを除く８のコマンドを全て含んでおり、Active-Standby構成の基本がつまっています。しかもDummyという特殊なリソースのみを使用しているため、Pacemaker以外、Apacheや共有ディスク等のリソースは不要です。

なお、Pacemaker-1.1系の場合、「crmd-transition-delay=”2s”」の設定は不要です。Pacemaker-1.1系で試す方は当該行を削除してください。

以降、しばらくはこのCRM設定ファイルを題材に解説をしていきます。

次のページで早速このCRM設定でPacemakerを動かしてみましょう。

Comments are closed   読み物

Nightlyビルド公開します

By t-matsuo, on 7月 26th, 2013%

Pacemaker本家コミュニティにて、開発最新版のPacemaker 1.1.10 がリリースされました。本バージョンに大きな問題がなければ、Pacemakerはメジャーバージョンアップするとの予告が出ており、1.1.10 は重要なバージョンと言えそうです。

これを記念して、Linux-HA Japanでは、いち早く最新のパッケージを使ってみたいという方のために、RHEL6(x86_64)および互換OS向けのNightlyビルドを公開したいと思います。

http://linux-ha.sourceforge.jp/nightly/

ビルド対象のパッケージは、Pacemaker 1.0系(安定版)、1.1系(開発版)、および周辺コンポーネントです。

Nightlyビルドには、Pacemaker 1.0系と1.1系両方のコンポーネントが混在しているため、どのコンポーネントを組み合わせればよいかわからない人は以下を組み合わせてみてください。

Pacemaker 1.0系 (安定版)

cluster-glue . . . → Read More: Nightlyビルド公開します

Comments are closed   ニュース, 読み物   , , ,  

Fedora 19 上でPostgreSQL ストリーミングレプリケーションのクラスタリング

By t-matsuo, on 7月 8th, 2013%

先日リリースされたFedora 19には、Linux-HA Japanで開発したPostgreSQLのストリーミングレプリケーションのクラスタリング機能がついに同梱されました。

Pacemaker のバージョンも開発版で比較的新しい 1.1.9 が同梱されているので、これを使ってPostgreSQLストリーミングレプリケーションのクラスタリングに挑戦してみたいと思います。

環境

今回、Fedoraのインストール手順方法は割愛しますが、以下の環境を用意してください。
※ 超スモール構成のため、商用での利用は推奨しません。信頼性を確保するには、Pacemaker用やレプリケーション用の専用LANを準備し、STONITHの導入を検討してください。

fe19-sr

  • ホスト名は、52-fe19 と 53-fe19 とします。 (単に私の手元の環境で使っているホスト名で、深い意味はありません。。。)
  • 皆大好きなSELinuxやファイアウォールは無効にしておきます。
  • 設定が複雑になるので、ネットワーク監視やディスク監視は行いません。
  • 超スモール環境のためネットワークは2本で挑戦します。なお、よく悪者扱いされるNetworkManagerは停止し、IPは手動で設定してください。また、/etc/hostsにホスト名を定義するとトラブル可能性があるので定義しないでください。
    • 1本目用途 : PostgreSQLへのアクセス用+Pacemaker通信用
      • 52-fe19のIP 192.168.0.152
      • 53-fe19のIP 192.168.0.153
      • PostgreSQLアクセス用の仮想IP(vip-master) 192.168.0.252
    • 2本目用途 : レプリケーション用 + Pacemaker通信用
      • 52-fe19のIP 192.168.1.152
      • 53-fe19のIP 192.168.1 .153
      • レプリケーション用仮想IP(vip-rep) 192.168.1.252

インストール

両ノードに、yumを使って必要なパッケージを一気にインストールし、PostgreSQLのアーカイブディレクトリを作成しておきます。(両ノードで実行)

# yum install postgresql-server pacemaker corosync pcs
読み込んだプラグイン:langpacks, refresh-packagekit
(省略)
完了しました!
# su - postgres
$ mkdir /var/lib/pgsql/pg_archive

PostgreSQLの設定

PostgreSQLのデータベースクラスタを作成します。(52-fe19上で実行)

$ cd /var/lib/pgsql/data
$ initdb
データベースシステム内のファイルの所有者は"postgres"ユーザでした。
このユーザがサーバプロセスを所有しなければなりません。
(省略)
成功しました。以下を使用してデータベースサーバを起動することができます。

    postmaster -D /var/lib/pgsql/data
または
    pg_ctl -D /var/lib/pgsql/data -l logfile start

postgresql.conf ファイルに以下を設定します。その他の設定はデフォルトのままで構いません。なお、synchronous_standby_names パラメータが設定されている場合は、必ずコメントアウトして無効にしておいてください。(52-fe19上で設定)

listen_addresses = '*'
wal_level = hot_standby
synchronous_commit = on
archive_mode = on
archive_command = 'cp %p /var/lib/pgsql/pg_archive/%f'
max_wal_senders=5
wal_keep_segments = 32
hot_standby = on
restart_after_crash = off
replication_timeout = 5000
wal_receiver_status_interval = 2
max_standby_streaming_delay = -1
max_standby_archive_delay = -1
synchronous_commit = on
restart_after_crash = off
hot_standby_feedback = on

pg_hba.conf ファイルを設定します。(セキュリティは全く考慮していません) (52-fe19上で設定)

host    all             all     127.0.0.1/32        trust
host    all             all     192.168.0.0/16      trust
host    replication     all     192.168.0.0/16      trust

PostgreSQLを起動します。(52-fe19上で実行)

$ pg_ctl -D . start
サーバは起動中です。

53-fe19 にデータをコピーします。(53-fe19上で実行)

# su - postgres
$ pg_basebackup -h 192.168.0.152 -U postgres -D /var/lib/pgsql/data -X stream -P

手動でレプリケーション接続できるか試します。53-fe19に/var/lib/pgsql/data/recovery.confを作成します。

standby_mode = 'on'
primary_conninfo = 'host=192.168.1.152 port=5432 user=postgres'
restore_command = 'cp /var/lib/pgsql/pg_archive/%f %p'
recovery_target_timeline = 'latest'

53-fe19のPostgreSQLを起動します。(53-fe19上で実行)

$ pg_ctl -D /var/lib/pgsql/data/ start

52-fe19上で以下のSQLを使ってレプリケーションの状態を確認します。

$ psql -c "select client_addr,sync_state from pg_stat_replication;"
  client_addr  | sync_state 
---------------+------------
 192.168.1.153 | async
(1 行)

無事レプリケーション接続できました。では、一旦両ノードのPostgreSQLを停止します。(両ノードで実行)

$ pg_ctl -D /var/lib/pgsql/data stop
$ exit

Corosyncの設定

corosyncの設定ファイル/etc/corosync/corosync.confを用意します。(両ノードで作成)

quorum {
           provider: corosync_votequorum
           expected_votes: 2
}
aisexec {
    user: root
    group: root
}
service {
    name: pacemaker
    ver: 0
    use_mgmtd: yes 
}
totem {
    version: 2
    secauth: off 
    threads: 0
    rrp_mode: active
    clear_node_high_bit: yes 
    token: 4000
    consensus: 10000
    rrp_problem_count_timeout: 3000
    interface {
        ringnumber: 0
        bindnetaddr: 192.168.0.0
        mcastaddr: 226.94.1.1
        mcastport: 5405
    }   
    interface {
        ringnumber: 1
        bindnetaddr: 192.168.1.0
        mcastaddr: 226.94.1.1
        mcastport: 5405
    }   
}
logging {
    fileline: on
    to_syslog: yes 
    syslog_facility: local1
    syslog_priority: info
    debug: off 
    timestamp: on
}

Corosyncを起動します。(両ノードで実行)

# systemctl start corosync.service

/var/log/messages に以下のようなメッセージが出ればcorosyncの起動成功です。

[MAIN  ] main.c:275 Completed service synchronization, ready to provide service.

ちなみに私の環境では、52-fe19でこのログが出続けていますが、原因はよくわかりません。。。とりあえず動いているようなのでこのまま先に進みます。(おぃ! )

Incrementing problem counter for seqid 2087 iface 192.168.0.152 to [1 of 10]

次はPacemkaerの起動・設定に入っていきます。

Comments are closed   読み物   , ,  

crmコマンドを用いたPacemaker のリソース設定方法

By t-matsuo, on 10月 20th, 2012%

Pacemaker で制御するリソースを設定するには、crm コマンドを使用します。以下にcrmコマンドの基本的な使い方を記述します。前提として、CentOS 5上にPacemakerのインストールが完了し、Pacemakerが起動しているとします。クラスタ制御部は、Corosync、Heartbeat どちらでも構いません。

まず、crm コマンドを起動します。(以下太字が実際に入力する部分です)

[root@pm01 ~]# crm
crm(live)#

リソースの設定モードに入ります。

crm(live)# configure
crm(live)configure#

現在の設定をshowコマンドで確認します。何も設定をしていないので、表示されるのはノード名（サーバ名)と、バージョン、使用しているクラスタ制御部名(以下の例ではHeartbeat3を使用)だけです。

crm(live)configure# show
node $id=”0c140f90-7de3-438f-b1b5-3b9722bbde21″ . . . → Read More: crmコマンドを用いたPacemaker のリソース設定方法

Comments are closed   読み物

Pacemaker-1.0 インストール方法 CentOS 5編

By higashik, on 10月 20th, 2012%

CentOS5.5 x86_64 にPacemakerをインストールする方法は、主に以下の4つがあります。

ここでは、下記の1, 2 の方法について記述します。

yum を使ってネットワークインストール

Pacemaker本家(clusterlabs) の yumのリポジトリを使用

インターネット接続必須
最新の安定バージョンをいち早く使ってみたい人向け (?)

Linux-HA Japan 提供のローカルリポジトリ . . . → Read More: Pacemaker-1.0 インストール方法 CentOS 5編

Comments are closed   読み物

Matahari Project の現状について

By ikedaj, on 10月 15th, 2012%

しばらくさぼっていましたが9月分のリリース情報をまとめて投稿します！

2012年9月3日にMatahari Projectから悲しいお知らせが（ＴДＴ）

As will be evident to those of you who have . . . → Read More: Matahari Project の現状について

Comments are closed   読み物    

JPUG 第24回しくみ+アプリケーション勉強会 セミナー資料公開

By t-matsuo, on 9月 29th, 2012%

2012/9/29 開催の第24回PostgreSQLのしくみ分科会、アプリケーション分科会への参加ありがとうございました。
当日の発表資料、”HAクラスタでPostgreSQLを高可用化(後編) 〜レプリケーション編〜”を公開します。

PostgreSQLを高可用化(後編) 〜レプリケーション編〜(PDF)

発表内容転記 : 『オープンソースのHAクラスタソフトPacemakerに、PostgreSQLのストリーミングレプリケーション構成をクラスタリングする機能がマージされました。この新機能の概要、および動作について解説いたします。』

前編の資料はこちらです。

 

English version . . . → Read More: JPUG 第24回しくみ+アプリケーション勉強会 セミナー資料公開

Comments are closed   イベント情報, 読み物   ,  
3 / 612345...Last »