清水 純
jun.s****@centr*****
2013年 8月 29日 (木) 11:16:43 JST
Forkいりえさん
service drbd start 等を実施しても今現在問題なければそのままで大丈夫だと
思いますが、LCMC を使用しているとのことなので、サービス画面からちゃんと
DRBD リソースが起動しているのが確認できれば大丈夫です。
# ここで確認できればちゃんと pacemaker の管理配下にあるということですので。
stop/restart 等を実行すると、止めたタイミングで pacemaker がそれを検出して
failcount がカウントされます。
設定にもよりますがこれにより意図しない再起動やフェイルオーバーが発生する可能性
がありますが、実行時点で発生するものなので、現在ちゃんと動いているのであれば
それほど気にする必要ありません。
ちなみに、crm_mon -f コマンドで failcount がカウントされていればその詳細が分かります。
LCMC の画面でも確認できると思いますので念のため確認しておいた方がよいでしょう。
カウンタのリセットは LCMC から実施したほうが楽です。
対象のリソースを右クリック→フェイルカウントの削除(cleanup) を選択すればOKです。
コマンドなら、crm resource cleanup <リソース名> {<ノード名>} です。
参考まで。
-- 清水
(2013/08/28 22:17), Akiko Irie wrote:
> 清水さん
>
> 以下アドバイスありがとうございます。
> 手順通りに試してみます。
>
>> drbd を pacemaker の管理配下で運用しているときに service drbd start/stop/restart 等は
> 実施してはいけません。
>
> 先日同期がNGだった（と思われた）ときにスタートした気がします（汗）
> この場合どうすれば良いのでしょう？？？
>
>> 根本的な部分ですが、drbd のサービス(chkconfig)はちゃんと off になって
> いますよね？
>
> 上記はoffにした記憶がありますが、確認します。
>
> 他ごとが片付かず、気になりつつ手が出せない（下手に出してさらに悪くなると
> 怖い）状態です。
> でも必ずトライしてまたご報告します。
>
> 本当に、ありがとうございます。
>
> いりえ
>
>
> (2013/08/28 14:09), 清水 純 wrote:
>> いりえさん
>>
>> crm configure edit で編集した場合、即時反映されますよ。
>>
>> 即時反映させたくない場合は、
>> # crm configure
>> crm(live)configure# edit ← この時点では編集のみ
>> crm(live)configure# verify ← 上記設定に問題ないか確認
>> crm(live)configure# commit ← 設定の反映
>>
>> の手順を踏んだ方がよいかと。
>>
>> ちなみに、drbd の設定ではなく pacemaker の設定になります。
>> drbd を pacemaker の管理配下で運用しているときに service drbd start/stop/restart 等は
>> 実施してはいけません。
>>
>> 根本的な部分ですが、drbd のサービス(chkconfig)はちゃんと off になっていますよね？
>>
>> -- しみず
>>
>> (2013/08/28 13:50), Akiko Irie wrote:
>>> 清水さん
>>>
>>> こんにちわ。
>>> 丁寧に回答いただきありがとうございます。
>>>
>>> ご指摘通り本番稼働中です。
>>> 稼働前に切替え等のテストはいろいろしていたのですが。。。未熟者で。。
>>>
>>> 教えていただいた設定にしてみます。
>>> 設定変更後はｄｒｂｄの再起動（service drbd restart?reload?）をすれば
>>> 反映されるのでしょうか。
>>> 今まではLCMCのみできたので、基本的な事ばかりの質問で申し訳ない
>>> です。
>>> 再設定の時は、下記後半でご提示いただいている件も含め勉強して
>>> いきたいと思います。
>>>
>>> ありがとうございました。
>>>
>>> いりえ
>>>
>>> (2013/08/28 13:35), 清水 純 wrote:
>>>> いりえさん
>>>>
>>>> こんにちは。清水です。
>>>>
>>>> colocation の設定前に入れればOKなはずですよ。
>>>>
>>>> この方法の場合、LCMC ではちゃんと設定情報が確認できないみたいですね。
>>>> 最新の 1.5.9 で試してみましたがマスター/スレーブリソースの設定情報
>>>> で、"ホストの場所"という部分の設定が変わりますが、設定後、LCMC上で
>>>> この部分はいじらないようにしてください。
>>>> LCMCに上書きされると設定内容が変わってしまうので注意が必要です。
>>>>
>>>> # 設定を元に戻したいという場合は、追記した location 設定を削除するか
>>>> # LCMCから"ホストの場所"で設定した値を<<選択なし>>に変更すれば
>>>> # 追加した location 設定を削除することが出来ます。
>>>>
>>>>
>>>> すでに本番稼働されているのですかね？
>>>> まだ試験段階であれば、現在の colocation/order 設定をすべて削除して
>>>> 以下のように変更することを個人的にはお勧めします。
>>>> # まぁ、この辺は好みの問題もあると思うので参考程度に捉えてもらって
>>>> # よいです。
>>>>
>>>> -----
>>>> group rg_apserver_1 res_Filesystem_1 res_nginx_1 res_tomcat7_1
>>>> clone cl_ping_1 res_ping_1
>>>> meta clone-max="2"
>>>> location master_location_appserver rg_appserver_1 \
>>>> rule $id="master_location_appserver-rule" -inf: not_defined pingd or pingd lt 100
>>>> colocation col_drbd-appserver inf: rg_appserver:Started ms_drbd_1:Master
>>>> order ord_drbd-appserver inf: ms_drbd_1:promote rg_appserver:start
>>>> -----
>>>>
>>>> 以下、簡易説明。
>>>> ・group でまとめる。
>>>> group でまとめてしまえば一つ一つのリソースの依存関係をすべて記載する
>>>> 必要がありません。
>>>> # リソースが多い場合、なぜか意図した動きをしてくれなかったことがあった
>>>> # ので、まとめられる部分は group にまとめてしまうようにしています。
>>>>
>>>> ・ping によるネットワーク疎通確認は両ノードで実行するようにする。
>>>> clone という概念があります。
>>>> 上記設定をすることで、待機系サーバでもネットワークの疎通確認を行ってくれる
>>>> ので、待機系でネットワークの疎通に問題がある場合に事前に検知できます。
>>>> → 上記 location 設定と組み合わせることでちゃんとネットワークの疎通が確認
>>>> 出来ているノードで起動してくれます。
>>>>
>>>> ・最後に、マスター/スレーブリソースはグループに(たぶん…)入れられないので
>>>> 上記の場合 ms_drbd_1 と rg_appserver_1 の依存関係だけ colocation/order で
>>>> 指定する。
>>>>
>>>> 以上。参考まで。
>>>>
>>>> (2013/08/28 11:27), Akiko Toriumi wrote:
>>>>> 渡辺さん
>>>>>
>>>>> こんにちわ。
>>>>>
>>>>> 少し空き時間が取れたので、取り急ぎアドバイスいただいた「案1」
>>>>> の設定をしようと思ったのですが、どこに記述すればよいかわかり
>>>>> ませんでした。
>>>>> 設定内容をお知らせいたしますので、教えていただけますでしょうか。
>>>>>
>>>>> どうぞよろしくお願いします。
>>>>>
>>>>> いりえ
>>>>>
>>>>>
>>>>> −−−−−−−−−−−−−−−−−−−−−−−−−−
>>>>> node $id="0d1a6aa2-c51d-4f4b-890c-cd8221f96d1f" ap11
>>>>> node $id="5a94bd5c-8750-4974-995b-7b40dc94bd21" ap11
>>>>> node $id="9e3545d3-4051-406b-b533-0f864c2ef626" ap11 \
>>>>> attributes standby="off"
>>>>> node $id="b86cb0eb-1881-4f25-8e53-8977f59397f6" ap11
>>>>> node $id="d2b87b5b-14cf-4dcd-98d4-4c15d4b7cb3e" ap11
>>>>> node $id="d6719107-eb74-4d2e-9277-e9802e418b71" ap21 \
>>>>> attributes standby="off"
>>>>> node $id="d7d6d8d9-aff3-343b-4773-c047f3a7ef2b" ap11
>>>>> primitive res_Filesystem_1 ocf:heartbeat:Filesystem \
>>>>> params device="/dev/drbd/by-res/r0" directory="/mnt/" fstype="ext4" \
>>>>> operations $id="res_Filesystem_1-operations" \
>>>>> op start interval="0" timeout="60" \
>>>>> op stop interval="0" timeout="60" \
>>>>> op monitor interval="20" timeout="40" start-delay="0" \
>>>>> op notify interval="0" timeout="60" \
>>>>> meta target-role="started"
>>>>> primitive res_drbd_1 ocf:linbit:drbd \
>>>>> params drbd_resource="r0" \
>>>>> operations $id="res_drbd_1-operations" \
>>>>> op start interval="0" timeout="240" \
>>>>> op promote interval="0" timeout="90" \
>>>>> op demote interval="0" timeout="90" \
>>>>> op stop interval="0" timeout="100" \
>>>>> op monitor interval="10" timeout="20" start-delay="0" \
>>>>> op notify interval="0" timeout="90" \
>>>>> meta target-role="started"
>>>>> primitive res_nginx_1 ocf:heartbeat:nginx \
>>>>> operations $id="res_nginx_1-operations" \
>>>>> op start interval="0" timeout="40" \
>>>>> op stop interval="0" timeout="60" \
>>>>> op monitor interval="0" timeout="60" start-delay="0" \
>>>>> op reload interval="0" timeout="40" \
>>>>> meta target-role="started"
>>>>> primitive res_ping_1 ocf:pacemaker:ping \
>>>>> params host_list="192.168.0.1" \
>>>>> operations $id="res_ping_1-operations" \
>>>>> op start interval="0" timeout="60" \
>>>>> op stop interval="0" timeout="20" \
>>>>> op monitor interval="10" timeout="60" start-delay="0" \
>>>>> op reload interval="0" timeout="100" \
>>>>> meta target-role="started"
>>>>> primitive res_tomcat7_1 lsb:tomcat7 \
>>>>> operations $id="res_tomcat7_1-operations" \
>>>>> op start interval="0" timeout="15" \
>>>>> op stop interval="0" timeout="15" \
>>>>> op monitor interval="15" timeout="15" start-delay="15" \
>>>>> meta target-role="started"
>>>>> ms ms_drbd_1 res_drbd_1 \
>>>>> meta clone-max="2" notify="true" interleave="true"
>>>>> colocation col_res_nginx_1_res_Filesystem_1 inf: res_nginx_1
>>>>> res_Filesystem_1
>>>>> colocation col_res_ping_1_ms_drbd_1 inf: res_ping_1 ms_drbd_1:Master
>>>>> colocation col_res_ping_1_res_Filesystem_1 inf: res_Filesystem_1 res_ping_1
>>>>> colocation col_res_tomcat7_1_res_nginx_1 inf: res_tomcat7_1 res_nginx_1
>>>>> order ord_ms_drbd_1_res_ping_1 inf: ms_drbd_1:promote res_ping_1:start
>>>>> order ord_res_Filesystem_1_res_nginx_1 inf: res_Filesystem_1 res_nginx_1
>>>>> order ord_res_nginx_1_res_tomcat7_1 inf: res_nginx_1 res_tomcat7_1
>>>>> order ord_res_ping_1_res_Filesystem_1 inf: res_ping_1 res_Filesystem_1
>>>>> property $id="cib-bootstrap-options" \
>>>>> stonith-enabled="false" \
>>>>> dc-version="1.1.6-9971ebba4494012a93c03b40a2c58ec0eb60f50c" \
>>>>> no-quorum-policy="ignore" \
>>>>> cluster-infrastructure="Heartbeat" \
>>>>> last-lrm-refresh="1373752168"
>>>>> rsc_defaults $id="rsc-options" \
>>>>> resource-stickiness="200"
>>>>>
>>>>> −−−−−−−−−−−−−−−−−−−−−−−−−−
>>>>>
>>>>> (2013/08/23 1:03), Tatsuya Watanabe wrote:
>>>>>> 渡辺と申します。こんばんは。
>>>>>>
>>>>>> 二日たっているので状況が変わっているかもしれませんがコメントします。
>>>>>>
>>>>>>> 当面稼働系を正として強制稼働させたいのですが可能でしょうか？
>>>>>> 「稼動系を正として強制稼動」というのは具体的にどのような動作を
>>>>>> イメージされているのでしょうか。
>>>>>>
>>>>>> 実際どのような動作を希望されているのかと、どのような設定を
>>>>>> されているのかが分からないため、以下は推測になりますが、
>>>>>> 参考にして頂ければと思います。
>>>>>>
>>>>>> ・案1
>>>>>>
>>>>>> 稼動系をnode1、待機系をnode2として、node2ではDRBDを
>>>>>> Primaryに昇格させたくない（ただしDRBDのレプリケーションは維持したい）
>>>>>> ということでしたら、Pacemakerのnode2のlocation設定に
>>>>>> -infを設定するというのが一案と思います。
>>>>>>
>>>>>> 稼働中のノードでPacemakerの設定を修正するには
>>>>>> crm configure editを使用します(以下、私の環境での一例です)
>>>>>>
>>>>>> # crm configure edit
>>>>>>
>>>>>> location rsc_location-1 <DRBDのマスタスレーブリソース名> \
>>>>>> rule $id="rsc_location-1-rule" $role="master" 200: #uname eq node1 \
>>>>>> rule $id="rsc_location-1-rule-0" $role="master" -inf: #uname eq node2 \
>>>>>>
>>>>>> この例ではnode1の故障時にも、node2のDRBDはPrimaryに昇格しないため、
>>>>>> 実質片系状態です。node1の故障時にはnode2を昇格させたい＋node1の故障が
>>>>>> 復旧したら自動的にnode1にフェイルバックさせたいということでしたら、
>>>>>> 以下のような設定になります。
>>>>>>
>>>>>> ・案2
>>>>>>
>>>>>> rsc_defaults $id="rsc-options" \
>>>>>> resource-stickiness="0" \
>>>>>>
>>>>>> location rsc_location-1 <DRBDのマスタスレーブリソース名> \
>>>>>> rule $id="rsc_location-1-rule" $role="master" 200: #uname eq node1 \
>>>>>> rule $id="rsc_location-1-rule-0" $role="master" 100: #uname eq node2 \
>>>>>>
>>>>>> resource-stickinessを0、スコア値をnode1>node2にしているので、
>>>>>> node1が優先的に昇格します。
>>>>>>
>>>>>> 他の設定によっても変わってきますので、実際の設定にあわせて修正が必要になります。
>>>>>> 以下のような情報を頂ければもう少し適切なコメントができるかもしれません。
>>>>>>
>>>>>> # crm_mon -fA -1
>>>>>> # crm configure show
>>>>>> # cat /etc/drbd.conf
>>>>>>
>>>>>>> 稼働系⇒待機系の同期はされていれば問題なか
>>>>>>> ったと思うのですが、そちらはNGだっただと
>>>>>>> 思います。。。
>>>>>> ご認識の通り、同期されていない状態でフェイルオーバすれば、
>>>>>> プロトコルCであっても当然データは欠損します。同期がNG
>>>>>> だったのは間違いないのでしょうか。
>>>>>>
>>>>>>> これは、正しくdrbdで冗長化されているという認識で良いのでしょうか？
>>>>>> 接続状態（Connected）、両ノードの役割(Primary/Secondary)、
>>>>>> データの状態(UpToDate)とも良好な状態に見えます。
>>>>>>
>>>>>>> ちなみに、LCMCの画面で見ると、・・・
>>>>>> 申し訳有りませんが、LCMCは使ったことがありませんので、
>>>>>> こちらについてはコメントできなそうです。
>>>>>>
>>>>>> 稼動系が不安定なのであれば、まずはそれを何とかするのが先決ですね。
>>>>>>
>>>>>> 以上、よろしくお願いします。
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Linux-ha-japan mailing list
>>>>>> Linux****@lists*****
>>>>>> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
>>>>> _______________________________________________
>>>>> Linux-ha-japan mailing list
>>>>> Linux****@lists*****
>>>>> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
>>>>>
>>> _______________________________________________
>>> Linux-ha-japan mailing list
>>> Linux****@lists*****
>>> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
>>>
>> _______________________________________________
>> Linux-ha-japan mailing list
>> Linux****@lists*****
>> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
>>
>>
>
> _______________________________________________
> Linux-ha-japan mailing list
> Linux****@lists*****
> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
>