Akiko Irie
iriea****@hera*****
2013年 8月 31日 (土) 14:34:28 JST
Fork清水さん
いつも丁寧に回答いただきありがとうございます。
ご指定のコマンド実施結果は下部に添付します。
【LCMCでの表示】AP11からLCMCを起動
＞AP11は情報取得できない、ap21はpcmk stoppedの状態。
＞他のresourceも情報が利用できません、の状態。
【# crm_mon 1 の結果】
============
Last updated: Sat Aug 31 14:28:10 2013
Last change: Thu Aug 22 15:25:41 2013 via crm_attribute on ap21
Stack: Heartbeat
Current DC: ap11 (5a94bd5c-8750-4974-995b-7b40dc94bd21) - partition with
quorum
Version: 1.1.6-9971ebba4494012a93c03b40a2c58ec0eb60f50c
7 Nodes configured, unknown expected votes
6 Resources configured.
============
Online: [ ap11 ]
OFFLINE: [ ap21 ap11 ap11 ap11 ap11 ap11 ]
Master/Slave Set: ms_drbd_1 [res_drbd_1]
Masters: [ ap11 ]
Stopped: [ res_drbd_1:1 ]
res_Filesystem_1 (ocf::heartbeat:Filesystem): Started ap11
res_nginx_1 (ocf::heartbeat:nginx): Started ap11
res_tomcat7_1 (lsb:tomcat7): Started ap11
res_ping_1 (ocf::pacemaker:ping): Started ap11
【サービスの起動・再起動について】
resourceの再起動方法ありがとうございます。
確認ですが、tomcatＭａｎａｇｅｒで、個別サービスを再起動するのは、
通常通り実施して問題ないでしょうか？
また、両サーバを落として起動する場合、起動順はAP11、AP21で
しょうか？順番は関係ないですか？
(2013/08/31 10:24), 清水 純 wrote:
【crm_mon -A -1 の結果】
============
Last updated: Sat Aug 31 14:31:57 2013
Last change: Thu Aug 22 15:25:41 2013 via crm_attribute on ap21
Stack: Heartbeat
Current DC: ap11 (5a94bd5c-8750-4974-995b-7b40dc94bd21) - partition with
quorum
Version: 1.1.6-9971ebba4494012a93c03b40a2c58ec0eb60f50c
7 Nodes configured, unknown expected votes
6 Resources configured.
============
Online: [ ap11 ]
OFFLINE: [ ap21 ap11 ap11 ap11 ap11 ap11 ]
Master/Slave Set: ms_drbd_1 [res_drbd_1]
Masters: [ ap11 ]
Stopped: [ res_drbd_1:1 ]
res_Filesystem_1 (ocf::heartbeat:Filesystem): Started ap11
res_nginx_1 (ocf::heartbeat:nginx): Started ap11
res_tomcat7_1 (lsb:tomcat7): Started ap11
res_ping_1 (ocf::pacemaker:ping): Started ap11
Node Attributes:
* Node ap11:
+ master-res_drbd_1:0 : 10000
+ pingd : 0 : Connectivity is lost
以上です。
やはり、Slave側の設定が正しく認識されていないように思います。
AP11にメモリ追加する予定もあるので、一旦両サーバを落として再起動し
てみようと思います。
いりえ
> いりえさん
>
> 同期は取れているようですね。
> ちなみに、service コマンドは使わずに /proc/drbd を cat したほうがよいかと。
>
> で、以下質問ですが、
>> しかし、LCMCで見ると、DRBDは正しく表示されません（汗
>> で、エラーを確認するとAP11へのSSH接続で失敗していますので、これが原因
>> かなぁ。。。と。
>> AP11上でLCMCを実行しているのですが…自分自身にSSHできていない。。。
> DRBDだけでしょうか？
> 他のリソース Tomcat や Nginx 等はステータスがちゃんと見れる状態でしょうか？
>
> また、上記説明では、AP12? へはSSH接続できているのですよね？
> それであれば、Pacemaker の管理下にあるのであればちゃんとステータスが確認
> できるはずです。
> # AP12側から全てのステータスが確認できるはず。
> # 私の環境で片系のSSHでのログインを無効化してみましたが、対象サーバの
> # ステータスがとれないだけで、クラスタリソースの情報は正常に取得できます。
>
> LCMC は Pacemaker に対して実行したコマンドを GUI で表示してくれるだけの
> 管理ソフトですので、対象サーバで以下コマンドを実行してみてください。
>
> # crm_mon 1
>
> 上記コマンドで稼働中のリソースが把握できます。
> ここにリストされなければ Pacemaker の管理下にはいないということになります。
>
> DRBD のリソースで Pacemaker 管理下にあれば、多分こんな感じの出力が上記コマンド
> の結果に含まれるはずです。
> -----
> Master/Slave Set: ms_drbd_1 [res_drbd]
> Masters: [ AP11 ]
> Slaves: [ AP12 ]
> -----
>
> 含まれていなければ Pacemaker 配下にいないということになります。
> 一度、サーバを両ノードともOSごと停止して再起動することをお勧めします。
>
>
> で、もう一つの質問ですが、
>> ところで、冗長化したのちにサーバあるいはサービスを再起動したい場合、
>> 通常なら service xxx restart などとやりますが、この方法はNGということになり
>> ますか？
>> 特にTomcatは不要データがメモリに残りがち（コードが良くない可能性は大ですが）
>> で、1週間に1回再起動していたりします。
>> また、サーバ自身も再起動したりしています。
>> LCMCで管理している場合は、上記の再起動もLCMCでやらないと他のところで
>> 不具合発生するでしょうか？
> 管理配下のリソースに対して service xxx restart は NG です。絶対にやってはいけません。
> 実行すると failcount が上がるかフェイルオーバーすると思います。
> # リソースの監視間隔に依存するのでタイミングが良ければ検知しない可能性もありますが。。。
>
> リソースの再起動をしたい場合、この環境であれば
> # crm resource res_tomcat7_1 restart
> ですね。
> 依存関係としては最後に Tomcat を起動するようにしてあるようなので Tomcat のみ再起動
> できます。
>
> # crm resource res_nginx_1 resart
> を実行すると、tomcat を落として、nginx を再起動して tomcat を起動するという
> 依存関係になっているようです。
>
> サーバ自体の再起動は通常の reboot (もしくは shutdown -r now) で大丈夫ですよ。
>
> 提供可能であれば、一度 # crm_mon -A -1 の結果を見せていただければきちんと
> Pacemaker で管理できているかどうか判断できます。
>
> 確認してみてください。
>
> -- 清水
>
> (2013/08/30 20:59), Akiko Irie wrote:
>> 清水さん
>>
>> こんばんわ。
>> お返事ありがとうございます。
>> コンソールで見たら、当初も投稿しましたが、下記のようにステータス確認でき
>> ます。
>>
>> service drbd status
>> drbd driver loaded OK; device status:
>> version: 8.3.11 (api:88/proto:86-96)
>> srcversion: 2931F0123213F7DB1364EA7
>> m:res cs ro ds p mounted fstype
>> 0:r0 Connected Primary/Secondary UpToDate/UpToDate C /mnt ext4
>>
>> 一応同期とれているようですが。。。
>> しかし、LCMCで見ると、DRBDは正しく表示されません（汗
>> で、エラーを確認するとAP11へのSSH接続で失敗していますので、これが原因
>> かなぁ。。。と。
>> AP11上でLCMCを実行しているのですが…自分自身にSSHできていない。。。
>> failcount の件も教えていただきありがとうございます。
>>
>> ところで、冗長化したのちにサーバあるいはサービスを再起動したい場合、
>> 通常なら service xxx restart などとやりますが、この方法はNGということになり
>> ますか？
>> 特にTomcatは不要データがメモリに残りがち（コードが良くない可能性は大ですが）
>> で、1週間に1回再起動していたりします。
>> また、サーバ自身も再起動したりしています。
>> LCMCで管理している場合は、上記の再起動もLCMCでやらないと他のところで
>> 不具合発生するでしょうか？
>>
>> ろくに見れていないのに質問ばかりですみません(汗
>>
>> いりえ
>>
>> (2013/08/29 11:16), 清水 純 wrote:
>>> いりえさん
>>>
>>> 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
>>>>
>>> _______________________________________________
>>> 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
>
>