Mailing List Archive

nakaさん

こんにちは、山内です。

詳細はログを見てみないとわかりませんが、
Pacemaker1.0系のpingリソースで利用しているattrd_updater（attrdプロセスへの属性更新）の仕様上、
故障検知よりも、故障カウントのアップが遅れることが原因だと思われます。

propertyに「crmd-transition-delay」パラメータがありますので、これを5sなどと設定してみてください。
これにより、全体的に故障発生時のフェイルオーバーが5s程度遅れてしまいますが、故障カウントの制御は
うまくいくはずです。

CentOS6.2とOS環境が古いですが、可能であれば、Pacemaker1.1系の利用をご検討されることをお勧めします。

以上です。



----- Original Message -----
> From: Keisuke Nakamura <k.xnakamu@gmail.com>
> To: linux-ha-japan@lists.osdn.me
> Cc:
> Date: 2016/11/25, Fri 14:03
> Subject: [Linux-ha-jp] pingリソースのfail-countについて
>
> 関係者各位
>
> お世話になっております。nakaと申します。
>
> 環境：
> CentOS 6.2(x86_64)
> pacemaker-1.0.12-1.el6.x86_64
> heartbeat-3.0.5-1.1.el6.x86_64
>
> (質問)
> pingリソースのfail-countについて質問です。
> pingリソースを利用しデフォルトゲートウェイへの疎通監視
> を設定している2ノードクラスタ構成を組んでおります。
> 先日弊社環境のネットワーク障害の影響で数分間、両ノードとも
> デフォゲへの疎通が不安定な状態となり、上記のpingリソースでの
> 異常を契機にクラスタグループリソースのF/Oが繰り返し行われました。
> その後ネットワークが復旧後は、繰り返し行われていたF/Oも止まり、
> サービスも正常に起動している状態となりました。
>
> 障害直後crm_monで状態をみても、fail-countが加算されてなく
> failed actionも表示されなかったのですが、pingリソースで
> F/Oの上限回数の設定はできるものでしょうか？（例えば3回F/O
> 繰り返したら停止するとか）
> fail-countについての情報を探し出せず、当メールにてご相談
> させて頂きました。お手隙の時にご教授頂けますと幸いです。
>
> (現状設定値の一部↓)
> primitive res_ping ocf:pacemaker:ping \
>         params name="eth0_ping_set" host_list="10.1.0.1"
> multiplier="200" dampen="1" debug="true"
> attempts="10" \
>         op monitor interval="10s" timeout="60" \
>         op start interval="0" timeout="60"
> …中略…
> property $id="cib-bootstrap-options" \
>         dc-version="1.0.12-066152e" \
>         cluster-infrastructure="Heartbeat" \
>         stonith-enabled="false" \
>         no-quorum-policy="ignore" \
>         default-action-timeout="120s" \
>         last-lrm-refresh="1463626573"
> rsc_defaults $id="rsc-options" \
>         resource-stickiness="INFINITY"
>
> 以上、宜しくお願い致します。
> _______________________________________________
> Linux-ha-japan mailing list
> Linux-ha-japan@lists.osdn.me
> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>

_______________________________________________
Linux-ha-japan mailing list
Linux-ha-japan@lists.osdn.me
http://lists.osdn.me/mailman/listinfo/linux-ha-japan

nakaさん

お世話になっております。
池田です。

Pacemaker 1.0.12の場合、ping RAはこちらを使用されているかと思います。
https://github.com/ClusterLabs/pacemaker-1.0/blob/Pacemaker-1.0.12/extra/resources/ping

監視処理実行時に、ping RAがなにをやっているかというと
https://github.com/ClusterLabs/pacemaker-1.0/blob/Pacemaker-1.0.12/extra/resources/ping#L170

pidfileの存在を判定しています。
- pidfileが存在していれば、ping_update関数を実行
- pidfileが存在していなければ、監視失敗 → フェイルカウントを更新

pidfileは起動処理実行時に作成しています。
https://github.com/ClusterLabs/pacemaker-1.0/blob/Pacemaker-1.0.12/extra/resources/ping#L157

さらに、ping_update関数がなにをやっているかというと
https://github.com/ClusterLabs/pacemaker-1.0/blob/Pacemaker-1.0.12/extra/resources/ping#L261

ping_check関数の実行結果をattrd_updaterコマンドに渡しています。

pingコマンドを実行して、ネットワークの疎通確認をしてるのがping_check関数ですね。
paramで指定したhost_listやmultiplierも絡んでくるところですが
nakaさんの設定では、10.1.0.1に対してpingコマンドを10回実行して
成功したら、200がattrd_updaterコマンドに渡されます。
失敗したら、0がattrd_updaterコマンドに渡されます。
attrd_updaterコマンドが失敗した場合は、フェイルカウントが更新されます。

attrd_updaterコマンドがなにをやっているかというと
Pacemakerが管理しているクラスタ情報の「属性値」とよばれるものを更新しています。
「フェイルカウント」と「属性値」は別のものです。
だんだんややこしくなってきましたが
ping RAが監視処理実行時にフェイルカウントを更新する条件は
- pidfileが存在していない
- attrd_updaterコマンドが失敗した
です。
pingコマンドの失敗を契機にフェイルカウントは更新されません。

pingコマンドが失敗した、つまり、ネットワークに異常が発生したという条件で
なにが行われているかというと、attrd_updaterコマンドによる属性値の更新です。
属性値は、crm_monコマンドに「-A」オプションを追加すると表示されます。
nakaさんの設定では、「eth0_ping_set 200」が見えてくるのではないでしょうか。

crm_mon -A コマンドを実行した状態で
pingコマンドが成功した場合、属性値は200と表示されます。
pingコマンドが失敗した場合、属性値は0と表示されます。

また、ping RAを使用する場合、location制約も設定します。
http://linux-ha.osdn.jp/wp/archives/3868#location

設定例) 1.1系の設定例ですが、locationは1.0系も同じです。
http://linux-ha.osdn.jp/wp/archives/4377#pingLAN

location <location ID> <リソース名> \
rule -INFINITY: not_defined eth0_ping_set or eth0_ping_set lt 200 \

上記のlocation設定では
(1) 「eth0_ping_set」という属性値が設定されていない(not_defined)
または
(2) 「eth0_ping_set」という属性値が200より小さい(lt 200)
いう条件において、「リソース」は起動できません。
ややこしい。。。
ざっくりいうと、「eth0_ping_set」という属性値が200だった場合に、リソースは起動できるってことですね。

で、ネットワークが故障すると、この属性値が0になるので
(2)の条件にあてはまり、リソースはフェイルオーバします。
ネットワークが復旧すると、属性値が200に戻り、リソースがフェイルバック可能な状態となります。
ネットワークが連続的に故障すると、リソースのフェイルオーバ/フェイルバックが連続して発生するのはこのためです。

nakaさんの環境では
ノード1のpingが失敗 → リソースはノード1にフェイルオーバ
ノード1のpingが復旧 → リソースはノード2に居残る(resource-stickiness="INFINITY")
ノード2のpingが失敗 → リソースはノード2にフェイルバック
を繰り返したのではないでしょうか。

ping RAは、このような仕様なので

> pingリソースでF/Oの上限回数の設定はできるものでしょうか？
> （例えば3回F/O繰り返したら停止するとか）

残念ながら、ネットワーク故障でこの動作を実現することはできないと思います。
なお、厳密にいうと、他のリソースでも「F/O繰り返したら停止」という設定は微妙なところで
migration-thresholdに設定された「故障上限値」まで同一ノードで「再起動」する、という動作になるので
ファイルオーバの上限回数を設定することはできないはずです。

フェイルオーバの上限回数とはまたちょっと違いますが
フェイルカウントが上限まで達したノードではリソースが起動できない動作を実現するために
ネットワーク故障を契機にフェイルカウントを更新する、という設定案としては
例えば、anything RAを使ってみる、などもありますが
https://github.com/ClusterLabs/resource-agents/blob/v3.9.7/heartbeat/anything

nakaさんの環境はバージョンをみた感じ、積極的に新規リソースを追加してまで
ネットワーク故障に対応したい！というのもなかなか難しそうですし
現実的な解としては、デフォルトゲートウェイのヒトに
あんまり壊れないでね、とお願いする感じなのかな、という気もしますが。。。
デフォルトゲートウェイがどのネットワーク機器にくっついているのかにもよりますが
L3とかだと、それ自体も冗長化されていて数秒単位で切り替わってくれるはずなので
瞬断を繰り返しても、ping RAのリトライ処理で再検出できます。

以前、ファイアウォール機器をping対象にしたことがありますが
ネットワーク担当の人によく話を聞くと「このファイアウォールは切り替えに
10分くらいかかります」と言われ、慌てて同じセグメント内でL3を探したことはあります。
# 気づいたきっかけはそのファイアウォールがたまーにICMPを
# ドロップするという謎動作をしていたからですが。

あと、あまりにもよく壊れる(というか疎通がぶっちぎれる)経路をping先にしてしまった環境では
潔くネットワーク監視は諦めて(仮想環境だったていうのもありますが)、
127.0.0.1をping先に変更したという話も聞きました。


以上よろしくお願いいたします。

池田淳子


差出人: Keisuke Nakamura
送信日時: 2016年11月25日 14:03
宛先: linux-ha-japan@lists.osdn.me
件名: [Linux-ha-jp] pingリソースのfail-countについて

関係者各位

お世話になっております。nakaと申します。

環境：
CentOS 6.2(x86_64)
pacemaker-1.0.12-1.el6.x86_64
heartbeat-3.0.5-1.1.el6.x86_64

(質問)
pingリソースのfail-countについて質問です。
pingリソースを利用しデフォルトゲートウェイへの疎通監視
を設定している2ノードクラスタ構成を組んでおります。
先日弊社環境のネットワーク障害の影響で数分間、両ノードとも
デフォゲへの疎通が不安定な状態となり、上記のpingリソースでの
異常を契機にクラスタグループリソースのF/Oが繰り返し行われました。
その後ネットワークが復旧後は、繰り返し行われていたF/Oも止まり、
サービスも正常に起動している状態となりました。

障害直後crm_monで状態をみても、fail-countが加算されてなく
failed actionも表示されなかったのですが、pingリソースで
F/Oの上限回数の設定はできるものでしょうか？（例えば3回F/O
繰り返したら停止するとか）
fail-countについての情報を探し出せず、当メールにてご相談
させて頂きました。お手隙の時にご教授頂けますと幸いです。

(現状設定値の一部↓)
primitive res_ping ocf:pacemaker:ping \
params name="eth0_ping_set" host_list="10.1.0.1"
multiplier="200" dampen="1" debug="true" attempts="10" \
op monitor interval="10s" timeout="60" \
op start interval="0" timeout="60"
…中略…
property $id="cib-bootstrap-options" \
dc-version="1.0.12-066152e" \
cluster-infrastructure="Heartbeat" \
stonith-enabled="false" \
no-quorum-policy="ignore" \
default-action-timeout="120s" \
last-lrm-refresh="1463626573"
rsc_defaults $id="rsc-options" \
resource-stickiness="INFINITY"

以上、宜しくお願い致します。
_______________________________________________
Linux-ha-japan mailing list
Linux-ha-japan@lists.osdn.me
http://lists.osdn.me/mailman/listinfo/linux-ha-japan

あれ、山内さんのメールを読み損なっていましたが
ping RAはフェイルカウントを維持できるんでしたっけ。
pingd RAはpingdデーモンの故障回数を維持してた気がしてましたが、勘違いしてました。
失礼しました。

池田淳子

2016/11/29 6:51 <renayama19661014@ybb.ne.jp>:

> nakaさん
>
> こんにちは、山内です。
>
> 詳細はログを見てみないとわかりませんが、
> Pacemaker1.0系のpingリソースで利用しているattrd_updater（attrdプロセスへの属性更新）の仕様上、
> 故障検知よりも、故障カウントのアップが遅れることが原因だと思われます。
>
> propertyに「crmd-transition-delay」パラメータがありますので、これを5sなどと設定してみてください。
> これにより、全体的に故障発生時のフェイルオーバーが5s程度遅れてしまいますが、故障カウントの制御は
> うまくいくはずです。
>
> CentOS6.2とOS環境が古いですが、可能であれば、Pacemaker1.1系の利用をご検討されることをお勧めします。
>
> 以上です。
>
>
>
> ----- Original Message -----
> > From: Keisuke Nakamura <k.xnakamu@gmail.com>
> > To: linux-ha-japan@lists.osdn.me
> > Cc:
> > Date: 2016/11/25, Fri 14:03
> > Subject: [Linux-ha-jp] pingリソースのfail-countについて
> >
> > 関係者各位
> >
> > お世話になっております。nakaと申します。
> >
> > 環境：
> > CentOS 6.2(x86_64)
> > pacemaker-1.0.12-1.el6.x86_64
> > heartbeat-3.0.5-1.1.el6.x86_64
> >
> > (質問)
> > pingリソースのfail-countについて質問です。
> > pingリソースを利用しデフォルトゲートウェイへの疎通監視
> > を設定している2ノードクラスタ構成を組んでおります。
> > 先日弊社環境のネットワーク障害の影響で数分間、両ノードとも
> > デフォゲへの疎通が不安定な状態となり、上記のpingリソースでの
> > 異常を契機にクラスタグループリソースのF/Oが繰り返し行われました。
> > その後ネットワークが復旧後は、繰り返し行われていたF/Oも止まり、
> > サービスも正常に起動している状態となりました。
> >
> > 障害直後crm_monで状態をみても、fail-countが加算されてなく
> > failed actionも表示されなかったのですが、pingリソースで
> > F/Oの上限回数の設定はできるものでしょうか？（例えば3回F/O
> > 繰り返したら停止するとか）
> > fail-countについての情報を探し出せず、当メールにてご相談
> > させて頂きました。お手隙の時にご教授頂けますと幸いです。
> >
> > (現状設定値の一部↓)
> > primitive res_ping ocf:pacemaker:ping \
> > params name="eth0_ping_set" host_list="10.1.0.1"
> > multiplier="200" dampen="1" debug="true"
> > attempts="10" \
> > op monitor interval="10s" timeout="60" \
> > op start interval="0" timeout="60"
> > …中略…
> > property $id="cib-bootstrap-options" \
> > dc-version="1.0.12-066152e" \
> > cluster-infrastructure="Heartbeat" \
> > stonith-enabled="false" \
> > no-quorum-policy="ignore" \
> > default-action-timeout="120s" \
> > last-lrm-refresh="1463626573"
> > rsc_defaults $id="rsc-options" \
> > resource-stickiness="INFINITY"
> >
> > 以上、宜しくお願い致します。
> > _______________________________________________
> > Linux-ha-japan mailing list
> > Linux-ha-japan@lists.osdn.me
> > http://lists.osdn.me/mailman/listinfo/linux-ha-japan
> >
>
> _______________________________________________
> Linux-ha-japan mailing list
> Linux-ha-japan@lists.osdn.me
> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>

$B;3FbMM!"CSEDMM(B

$B$*@$OC$K$J$C$F$*$j$^$9!"(Bnaka$B$H?=$7$^$9!#(B
$B$4@bL@M-Fq$&$4$6$$$^$9!*$H$F$b=u$+$j$^$9!#(B
$BD:$$$?>pJs$r$b$H$K!"(Bping$B%j%=!<%9$,$I$s$J=hM}$r$7$F$k$+$r(B
$BM}2r$9$k$H$3$m$+$i3NG'$7$F$$$-$^$9!#!J(Bheartbeat$B$N%m%0$K$h$/(B
attrd_updater$B$N%a%C%;!<%8$OL\$K$7$F$?$N$G$9$,!"?($l$:$K(B
$B$3$3$^$GMh$F$7$^$$$^$7$?!K(B
ping$B!!(BRA$B$O(Bfailcount$B$r0];}$G$-$k$+!);d$NJ}$G$b3NG'$7$F$_$^$9!#(B

$B<h$j5^$.8fNi$^$G!#(B


2016$BG/(B11$B7n(B29$BF|(B 9:57 Junko IKEDA <tsukishima.ha@gmail.com>:
> $B$"$l!";3Fb$5$s$N%a!<%k$rFI$_B;$J$C$F$$$^$7$?$,(B
> ping RA$B$O%U%'%$%k%+%&%s%H$r0];}$G$-$k$s$G$7$?$C$1!#(B
> pingd RA$B$O(Bpingd$B%G!<%b%s$N8N>c2s?t$r0];}$7$F$?5$$,$7$F$^$7$?$,!"4*0c$$$7$F$^$7$?!#(B
> $B<:Ni$7$^$7$?!#(B
>
> $BCSED=_;R(B
>
>
> 2016/11/29 6:51 <renayama19661014@ybb.ne.jp>:
>
>> naka$B$5$s(B
>>
>> $B$3$s$K$A$O!";3Fb$G$9!#(B
>>
>> $B>\:Y$O%m%0$r8+$F$_$J$$$H$o$+$j$^$;$s$,!"(B
>> Pacemaker1.0$B7O$N(Bping$B%j%=!<%9$GMxMQ$7$F$$$k(Battrd_updater$B!J(Battrd$B%W%m%;%9$X$NB0@-99?7!K$N;EMM>e!"(B
>> $B8N>c8!CN$h$j$b!"8N>c%+%&%s%H$N%"%C%W$,CY$l$k$3$H$,860x$@$H;W$o$l$^$9!#(B
>>
>> property$B$K!V(Bcrmd-transition-delay$B!W%Q%i%a!<%?$,$"$j$^$9$N$G!"$3$l$r(B5s$B$J$I$H@_Dj$7$F$_$F$/$@$5$$!#(B
>> $B$3$l$K$h$j!"A4BNE*$K8N>cH/@8;~$N%U%'%$%k%*!<%P!<$,(B5s$BDxEYCY$l$F$7$^$$$^$9$,!"8N>c%+%&%s%H$N@)8f$O(B
>> $B$&$^$/$$$/$O$:$G$9!#(B
>>
>> CentOS6.2$B$H(BOS$B4D6-$,8E$$$G$9$,!"2DG=$G$"$l$P!"(BPacemaker1.1$B7O$NMxMQ$r$48!F$$5$l$k$3$H$r$*4+$a$7$^$9!#(B
>>
>> $B0J>e$G$9!#(B
>>
>>
>>
>> ----- Original Message -----
>> > From: Keisuke Nakamura <k.xnakamu@gmail.com>
>> > To: linux-ha-japan@lists.osdn.me
>> > Cc:
>> > Date: 2016/11/25, Fri 14:03
>> > Subject: [Linux-ha-jp] ping$B%j%=!<%9$N(Bfail-count$B$K$D$$$F(B
>> >
>> > $B4X78<T3F0L(B
>> >
>> > $B$*@$OC$K$J$C$F$*$j$^$9!#(Bnaka$B$H?=$7$^$9!#(B
>> >
>> > $B4D6-!'(B
>> > CentOS 6.2(x86_64)
>> > pacemaker-1.0.12-1.el6.x86_64
>> > heartbeat-3.0.5-1.1.el6.x86_64
>> >
>> > ($B<ALd(B)
>> > ping$B%j%=!<%9$N(Bfail-count$B$K$D$$$F<ALd$G$9!#(B
>> > ping$B%j%=!<%9$rMxMQ$7%G%U%)%k%H%2!<%H%&%'%$$X$NABDL4F;k(B
>> > $B$r@_Dj$7$F$$$k(B2$B%N!<%I%/%i%9%?9=@.$rAH$s$G$*$j$^$9!#(B
>> > $B@hF|J@<R4D6-$N%M%C%H%o!<%/>c32$N1F6A$G?tJ,4V!"N>%N!<%I$H$b(B
>> > $B%G%U%)%2$X$NABDL$,IT0BDj$J>uBV$H$J$j!">e5-$N(Bping$B%j%=!<%9$G$N(B
>> > $B0[>o$r7@5!$K%/%i%9%?%0%k!<%W%j%=!<%9$N(BF/O$B$,7+$jJV$79T$o$l$^$7$?!#(B
>> > $B$=$N8e%M%C%H%o!<%/$,I|5l8e$O!"7+$jJV$79T$o$l$F$$$?(BF/O$B$b;_$^$j!"(B
>> > $B%5!<%S%9$b@5>o$K5/F0$7$F$$$k>uBV$H$J$j$^$7$?!#(B
>> >
>> > $B>c32D>8e(Bcrm_mon$B$G>uBV$r$_$F$b!"(Bfail-count$B$,2C;;$5$l$F$J$/(B
>> > failed action$B$bI=<($5$l$J$+$C$?$N$G$9$,!"(Bping$B%j%=!<%9$G(B
>> > F/O$B$N>e8B2s?t$N@_Dj$O$G$-$k$b$N$G$7$g$&$+!)!JNc$($P(B3$B2s(BF/O
>> > $B7+$jJV$7$?$iDd;_$9$k$H$+!K(B
>> > fail-count$B$K$D$$$F$N>pJs$rC5$7=P$;$:!"Ev%a!<%k$K$F$4AjCL(B
>> > $B$5$;$FD:$-$^$7$?!#$*<j7d$N;~$K$465<xD:$1$^$9$H9,$$$G$9!#(B
>> >
>> > ($B8=>u@_DjCM$N0lIt"-(B)
>> > primitive res_ping ocf:pacemaker:ping \
>> > params name="eth0_ping_set" host_list="10.1.0.1"
>> > multiplier="200" dampen="1" debug="true"
>> > attempts="10" \
>> > op monitor interval="10s" timeout="60" \
>> > op start interval="0" timeout="60"
>> > $B!DCfN,!D(B
>> > property $id="cib-bootstrap-options" \
>> > dc-version="1.0.12-066152e" \
>> > cluster-infrastructure="Heartbeat" \
>> > stonith-enabled="false" \
>> > no-quorum-policy="ignore" \
>> > default-action-timeout="120s" \
>> > last-lrm-refresh="1463626573"
>> > rsc_defaults $id="rsc-options" \
>> > resource-stickiness="INFINITY"
>> >
>> > $B0J>e!"59$7$/$*4j$$CW$7$^$9!#(B
>> > _______________________________________________
>> > Linux-ha-japan mailing list
>> > Linux-ha-japan@lists.osdn.me
>> > http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>> >
>>
>> _______________________________________________
>> Linux-ha-japan mailing list
>> Linux-ha-japan@lists.osdn.me
>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>
>
> _______________________________________________
> Linux-ha-japan mailing list
> Linux-ha-japan@lists.osdn.me
> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>



--
Nakamura
_______________________________________________
Linux-ha-japan mailing list
Linux-ha-japan@lists.osdn.me
http://lists.osdn.me/mailman/listinfo/linux-ha-japan

nakaさん
池田さん

こんばんは、山内です。

すいません、全くの私の勘違いです。

fail-countは、ping RAが故障(monitor)を起こした場合にアップするものであって、
pingの疎通が切れた場合には、関係しません。

よって、nakaさんのケースでは、fail-countはアップせずに、フェイルオーバーが発生します。
＃"eth0_ping_set" をlocationで記載していると思いますが、その制約条件でフェイルオーバーが発生します。

この動作は、Pacemaker1.1系でも同じです。

提案したcrmd-transition-delayはまた、別物です。

以上です。


----- Original Message -----
> From: Keisuke Nakamura <k.xnakamu@gmail.com>
> To: linux-ha-japan@lists.osdn.me
> Cc:
> Date: 2016/11/29, Tue 18:22
> Subject: Re: [Linux-ha-jp] pingリソースのfail-countについて
>
> 山内様、池田様
>
> お世話になっております、nakaと申します。
> ご説明有難うございます！とても助かります。
> 頂いた情報をもとに、pingリソースがどんな処理をしてるかを
> 理解するところから確認していきます。（heartbeatのログによく
> attrd_updaterのメッセージは目にしてたのですが、触れずに
> ここまで来てしまいました）
> ping　RAはfailcountを維持できるか？私の方でも確認してみます。
>
> 取り急ぎ御礼まで。
>
>
> 2016年11月29日 9:57 Junko IKEDA <tsukishima.ha@gmail.com>:
>> あれ、山内さんのメールを読み損なっていましたが
>> ping RAはフェイルカウントを維持できるんでしたっけ。
>> pingd RAはpingdデーモンの故障回数を維持してた気がしてましたが、勘違いしてました。
>> 失礼しました。
>>
>> 池田淳子
>>
>>
>> 2016/11/29 6:51 <renayama19661014@ybb.ne.jp>:
>>
>>> nakaさん
>>>
>>> こんにちは、山内です。
>>>
>>> 詳細はログを見てみないとわかりませんが、
>>> Pacemaker1.0系のpingリソースで利用しているattrd_updater（attrdプロセスへの属性更新）の仕様上、
>>> 故障検知よりも、故障カウントのアップが遅れることが原因だと思われます。
>>>
>>> propertyに「crmd-transition-delay」パラメータがありますので、これを5sなどと設定してみてください。
>>> これにより、全体的に故障発生時のフェイルオーバーが5s程度遅れてしまいますが、故障カウントの制御は
>>> うまくいくはずです。
>>>
>>> CentOS6.2とOS環境が古いですが、可能であれば、Pacemaker1.1系の利用をご検討されることをお勧めします。
>>>
>>> 以上です。
>>>
>>>
>>>
>>> ----- Original Message -----
>>> > From: Keisuke Nakamura <k.xnakamu@gmail.com>
>>> > To: linux-ha-japan@lists.osdn.me
>>> > Cc:
>>> > Date: 2016/11/25, Fri 14:03
>>> > Subject: [Linux-ha-jp] pingリソースのfail-countについて
>>> >
>>> > 関係者各位
>>> >
>>> > お世話になっております。nakaと申します。
>>> >
>>> > 環境：
>>> > CentOS 6.2(x86_64)
>>> > pacemaker-1.0.12-1.el6.x86_64
>>> > heartbeat-3.0.5-1.1.el6.x86_64
>>> >
>>> > (質問)
>>> > pingリソースのfail-countについて質問です。
>>> > pingリソースを利用しデフォルトゲートウェイへの疎通監視
>>> > を設定している2ノードクラスタ構成を組んでおります。
>>> > 先日弊社環境のネットワーク障害の影響で数分間、両ノードとも
>>> > デフォゲへの疎通が不安定な状態となり、上記のpingリソースでの
>>> > 異常を契機にクラスタグループリソースのF/Oが繰り返し行われました。
>>> > その後ネットワークが復旧後は、繰り返し行われていたF/Oも止まり、
>>> > サービスも正常に起動している状態となりました。
>>> >
>>> > 障害直後crm_monで状態をみても、fail-countが加算されてなく
>>> > failed actionも表示されなかったのですが、pingリソースで
>>> > F/Oの上限回数の設定はできるものでしょうか？（例えば3回F/O
>>> > 繰り返したら停止するとか）
>>> > fail-countについての情報を探し出せず、当メールにてご相談
>>> > させて頂きました。お手隙の時にご教授頂けますと幸いです。
>>> >
>>> > (現状設定値の一部↓)
>>> > primitive res_ping ocf:pacemaker:ping \
>>> >        params name="eth0_ping_set"
> host_list="10.1.0.1"
>>> > multiplier="200" dampen="1"
> debug="true"
>>> > attempts="10" \
>>> >        op monitor interval="10s" timeout="60"
> \
>>> >        op start interval="0" timeout="60"
>>> > …中略…
>>> > property $id="cib-bootstrap-options" \
>>> >        dc-version="1.0.12-066152e" \
>>> >        cluster-infrastructure="Heartbeat" \
>>> >        stonith-enabled="false" \
>>> >        no-quorum-policy="ignore" \
>>> >        default-action-timeout="120s" \
>>> >        last-lrm-refresh="1463626573"
>>> > rsc_defaults $id="rsc-options" \
>>> >        resource-stickiness="INFINITY"
>>> >
>>> > 以上、宜しくお願い致します。
>>> > _______________________________________________
>>> > Linux-ha-japan mailing list
>>> > Linux-ha-japan@lists.osdn.me
>>> > http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>>> >
>>>
>>> _______________________________________________
>>> Linux-ha-japan mailing list
>>> Linux-ha-japan@lists.osdn.me
>>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>>
>>
>> _______________________________________________
>> Linux-ha-japan mailing list
>> Linux-ha-japan@lists.osdn.me
>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>>
>
>
>
> --
> Nakamura
> _______________________________________________
> Linux-ha-japan mailing list
> Linux-ha-japan@lists.osdn.me
> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>

_______________________________________________
Linux-ha-japan mailing list
Linux-ha-japan@lists.osdn.me
http://lists.osdn.me/mailman/listinfo/linux-ha-japan

nakaさん
池田さん

こんばんは、山内です。

最初のnakaさんのご質問の回答という意味では、池田さんが回答した。

>残念ながら、ネットワーク故障でこの動作を実現することはできないと思います。
>なお、厳密にいうと、他のリソースでも「F/O繰り返したら停止」という設定は微妙なところで
>migration-thresholdに設定された「故障上限値」まで同一ノードで「再起動」する、という動作になるので
>ファイルオーバの上限回数を設定することはできないはずです。

上記の回答が正しいです。

勘違いで混乱させてしまったかも知れません、申し訳ありませんでした。

以上です。



----- Original Message -----
> From: "renayama19661014@ybb.ne.jp" <renayama19661014@ybb.ne.jp>
> To: "linux-ha-japan@lists.osdn.me" <linux-ha-japan@lists.osdn.me>
> Cc:
> Date: 2016/11/29, Tue 18:42
> Subject: Re: [Linux-ha-jp] pingリソースのfail-countについて
>
> nakaさん
> 池田さん
>
> こんばんは、山内です。
>
> すいません、全くの私の勘違いです。
>
> fail-countは、ping RAが故障(monitor)を起こした場合にアップするものであって、
> pingの疎通が切れた場合には、関係しません。
>
> よって、nakaさんのケースでは、fail-countはアップせずに、フェイルオーバーが発生します。
> ＃"eth0_ping_set" をlocationで記載していると思いますが、その制約条件でフェイルオーバーが発生します。
>
> この動作は、Pacemaker1.1系でも同じです。
>
> 提案したcrmd-transition-delayはまた、別物です。
>
> 以上です。
>
>
> ----- Original Message -----
>> From: Keisuke Nakamura <k.xnakamu@gmail.com>
>> To: linux-ha-japan@lists.osdn.me
>> Cc:
>> Date: 2016/11/29, Tue 18:22
>> Subject: Re: [Linux-ha-jp] pingリソースのfail-countについて
>>
>> 山内様、池田様
>>
>> お世話になっております、nakaと申します。
>> ご説明有難うございます！とても助かります。
>> 頂いた情報をもとに、pingリソースがどんな処理をしてるかを
>> 理解するところから確認していきます。（heartbeatのログによく
>> attrd_updaterのメッセージは目にしてたのですが、触れずに
>> ここまで来てしまいました）
>> ping　RAはfailcountを維持できるか？私の方でも確認してみます。
>>
>> 取り急ぎ御礼まで。
>>
>>
>> 2016年11月29日 9:57 Junko IKEDA <tsukishima.ha@gmail.com>:
>>>   あれ、山内さんのメールを読み損なっていましたが
>>>   ping RAはフェイルカウントを維持できるんでしたっけ。
>>>   pingd RAはpingdデーモンの故障回数を維持してた気がしてましたが、勘違いしてました。
>>>   失礼しました。
>>>
>>>   池田淳子
>>>
>>>
>>>   2016/11/29 6:51 <renayama19661014@ybb.ne.jp>:
>>>
>>>>   nakaさん
>>>>
>>>>   こんにちは、山内です。
>>>>
>>>>   詳細はログを見てみないとわかりませんが、
>>>>   Pacemaker1.0系のpingリソースで利用しているattrd_updater（attrdプロセスへの属性更新）の仕様上、
>>>>   故障検知よりも、故障カウントのアップが遅れることが原因だと思われます。
>>>>
>>>>   propertyに「crmd-transition-delay」パラメータがありますので、これを5sなどと設定してみてください。
>>>>   これにより、全体的に故障発生時のフェイルオーバーが5s程度遅れてしまいますが、故障カウントの制御は
>>>>   うまくいくはずです。
>>>>
>>>>   CentOS6.2とOS環境が古いですが、可能であれば、Pacemaker1.1系の利用をご検討されることをお勧めします。
>>>>
>>>>   以上です。
>>>>
>>>>
>>>>
>>>>   ----- Original Message -----
>>>>   > From: Keisuke Nakamura <k.xnakamu@gmail.com>
>>>>   > To: linux-ha-japan@lists.osdn.me
>>>>   > Cc:
>>>>   > Date: 2016/11/25, Fri 14:03
>>>>   > Subject: [Linux-ha-jp] pingリソースのfail-countについて
>>>>   >
>>>>   > 関係者各位
>>>>   >
>>>>   > お世話になっております。nakaと申します。
>>>>   >
>>>>   > 環境：
>>>>   > CentOS 6.2(x86_64)
>>>>   > pacemaker-1.0.12-1.el6.x86_64
>>>>   > heartbeat-3.0.5-1.1.el6.x86_64
>>>>   >
>>>>   > (質問)
>>>>   > pingリソースのfail-countについて質問です。
>>>>   > pingリソースを利用しデフォルトゲートウェイへの疎通監視
>>>>   > を設定している2ノードクラスタ構成を組んでおります。
>>>>   > 先日弊社環境のネットワーク障害の影響で数分間、両ノードとも
>>>>   > デフォゲへの疎通が不安定な状態となり、上記のpingリソースでの
>>>>   > 異常を契機にクラスタグループリソースのF/Oが繰り返し行われました。
>>>>   > その後ネットワークが復旧後は、繰り返し行われていたF/Oも止まり、
>>>>   > サービスも正常に起動している状態となりました。
>>>>   >
>>>>   > 障害直後crm_monで状態をみても、fail-countが加算されてなく
>>>>   > failed actionも表示されなかったのですが、pingリソースで
>>>>   > F/Oの上限回数の設定はできるものでしょうか？（例えば3回F/O
>>>>   > 繰り返したら停止するとか）
>>>>   > fail-countについての情報を探し出せず、当メールにてご相談
>>>>   > させて頂きました。お手隙の時にご教授頂けますと幸いです。
>>>>   >
>>>>   > (現状設定値の一部↓)
>>>>   > primitive res_ping ocf:pacemaker:ping \
>>>>   >         params name="eth0_ping_set"
>> host_list="10.1.0.1"
>>>>   > multiplier="200" dampen="1"
>> debug="true"
>>>>   > attempts="10" \
>>>>   >         op monitor interval="10s"
> timeout="60"
>> \
>>>>   >         op start interval="0"
> timeout="60"
>>>>   > …中略…
>>>>   > property $id="cib-bootstrap-options" \
>>>>   >         dc-version="1.0.12-066152e" \
>>>>   >         cluster-infrastructure="Heartbeat" \
>>>>   >         stonith-enabled="false" \
>>>>   >         no-quorum-policy="ignore" \
>>>>   >         default-action-timeout="120s" \
>>>>   >         last-lrm-refresh="1463626573"
>>>>   > rsc_defaults $id="rsc-options" \
>>>>   >         resource-stickiness="INFINITY"
>>>>   >
>>>>   > 以上、宜しくお願い致します。
>>>>   > _______________________________________________
>>>>   > Linux-ha-japan mailing list
>>>>   > Linux-ha-japan@lists.osdn.me
>>>>   > http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>>>>   >
>>>>
>>>>   _______________________________________________
>>>>   Linux-ha-japan mailing list
>>>>   Linux-ha-japan@lists.osdn.me
>>>>   http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>>>
>>>
>>>   _______________________________________________
>>>   Linux-ha-japan mailing list
>>>   Linux-ha-japan@lists.osdn.me
>>>   http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>>>
>>
>>
>>
>> --
>> Nakamura
>> _______________________________________________
>> Linux-ha-japan mailing list
>> Linux-ha-japan@lists.osdn.me
>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>>
>
> _______________________________________________
> Linux-ha-japan mailing list
> Linux-ha-japan@lists.osdn.me
> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>

_______________________________________________
Linux-ha-japan mailing list
Linux-ha-japan@lists.osdn.me
http://lists.osdn.me/mailman/listinfo/linux-ha-japan

$B;3Fb$5$s(B
$B$4O"MmM-Fq$&$4$6$$$^$9!*(B
$B$3$A$i$3$=$9$_$^$;$s!"$*<j?t$*$+$1CW$7$^$7$?!#(B
$BCSED$5$s$N>pJs$b;29M$K$7$D$D!"2~$a$F3NG'$7$F$$$-$^$9!#(B
$BM-Fq$&$4$6$$$^$7$?!#(B

$B0J>e!"59$7$/$*4j$$CW$7$^$9!#(B


2016$BG/(B11$B7n(B29$BF|(B 18:51 <renayama19661014@ybb.ne.jp>:
> naka$B$5$s(B
> $BCSED$5$s(B
>
> $B$3$s$P$s$O!";3Fb$G$9!#(B
>
> $B:G=i$N(Bnaka$B$5$s$N$4<ALd$N2sEz$H$$$&0UL#$G$O!"CSED$5$s$,2sEz$7$?!#(B
>
>>$B;DG0$J$,$i!"%M%C%H%o!<%/8N>c$G$3$NF0:n$r<B8=$9$k$3$H$O$G$-$J$$$H;W$$$^$9!#(B
>>$B$J$*!"87L)$K$$$&$H!"B>$N%j%=!<%9$G$b!V(BF/O$B7+$jJV$7$?$iDd;_!W$H$$$&@_Dj$OHyL/$J$H$3$m$G(B
>>migration-threshold$B$K@_Dj$5$l$?!V8N>c>e8BCM!W$^$GF10l%N!<%I$G!V:F5/F0!W$9$k!"$H$$$&F0:n$K$J$k$N$G(B
>>$B%U%!%$%k%*!<%P$N>e8B2s?t$r@_Dj$9$k$3$H$O$G$-$J$$$O$:$G$9!#(B
>
> $B>e5-$N2sEz$,@5$7$$$G$9!#(B
>
> $B4*0c$$$G:.Mp$5$;$F$7$^$C$?$+$bCN$l$^$;$s!"?=$7Lu$"$j$^$;$s$G$7$?!#(B
>
> $B0J>e$G$9!#(B
>
>
>
> ----- Original Message -----
>> From: "renayama19661014@ybb.ne.jp" <renayama19661014@ybb.ne.jp>
>> To: "linux-ha-japan@lists.osdn.me" <linux-ha-japan@lists.osdn.me>
>> Cc:
>> Date: 2016/11/29, Tue 18:42
>> Subject: Re: [Linux-ha-jp] ping$B%j%=!<%9$N(Bfail-count$B$K$D$$$F(B
>>
>> naka$B$5$s(B
>> $BCSED$5$s(B
>>
>> $B$3$s$P$s$O!";3Fb$G$9!#(B
>>
>> $B$9$$$^$;$s!"A4$/$N;d$N4*0c$$$G$9!#(B
>>
>> fail-count$B$O!"(Bping RA$B$,8N>c(B(monitor)$B$r5/$3$7$?>l9g$K%"%C%W$9$k$b$N$G$"$C$F!"(B
>> ping$B$NABDL$,@Z$l$?>l9g$K$O!"4X78$7$^$;$s!#(B
>>
>> $B$h$C$F!"(Bnaka$B$5$s$N%1!<%9$G$O!"(Bfail-count$B$O%"%C%W$;$:$K!"%U%'%$%k%*!<%P!<$,H/@8$7$^$9!#(B
>> $B!t(B"eth0_ping_set" $B$r(Blocation$B$G5-:\$7$F$$$k$H;W$$$^$9$,!"$=$N@)Ls>r7o$G%U%'%$%k%*!<%P!<$,H/@8$7$^$9!#(B
>>
>> $B$3$NF0:n$O!"(BPacemaker1.1$B7O$G$bF1$8$G$9!#(B
>>
>> $BDs0F$7$?(Bcrmd-transition-delay$B$O$^$?!"JLJ*$G$9!#(B
>>
>> $B0J>e$G$9!#(B
>>
>>
>> ----- Original Message -----
>>> From: Keisuke Nakamura <k.xnakamu@gmail.com>
>>> To: linux-ha-japan@lists.osdn.me
>>> Cc:
>>> Date: 2016/11/29, Tue 18:22
>>> Subject: Re: [Linux-ha-jp] ping$B%j%=!<%9$N(Bfail-count$B$K$D$$$F(B
>>>
>>> $B;3FbMM!"CSEDMM(B
>>>
>>> $B$*@$OC$K$J$C$F$*$j$^$9!"(Bnaka$B$H?=$7$^$9!#(B
>>> $B$4@bL@M-Fq$&$4$6$$$^$9!*$H$F$b=u$+$j$^$9!#(B
>>> $BD:$$$?>pJs$r$b$H$K!"(Bping$B%j%=!<%9$,$I$s$J=hM}$r$7$F$k$+$r(B
>>> $BM}2r$9$k$H$3$m$+$i3NG'$7$F$$$-$^$9!#!J(Bheartbeat$B$N%m%0$K$h$/(B
>>> attrd_updater$B$N%a%C%;!<%8$OL\$K$7$F$?$N$G$9$,!"?($l$:$K(B
>>> $B$3$3$^$GMh$F$7$^$$$^$7$?!K(B
>>> ping$B!!(BRA$B$O(Bfailcount$B$r0];}$G$-$k$+!);d$NJ}$G$b3NG'$7$F$_$^$9!#(B
>>>
>>> $B<h$j5^$.8fNi$^$G!#(B
>>>
>>>
>>> 2016$BG/(B11$B7n(B29$BF|(B 9:57 Junko IKEDA <tsukishima.ha@gmail.com>:
>>>> $B$"$l!";3Fb$5$s$N%a!<%k$rFI$_B;$J$C$F$$$^$7$?$,(B
>>>> ping RA$B$O%U%'%$%k%+%&%s%H$r0];}$G$-$k$s$G$7$?$C$1!#(B
>>>> pingd RA$B$O(Bpingd$B%G!<%b%s$N8N>c2s?t$r0];}$7$F$?5$$,$7$F$^$7$?$,!"4*0c$$$7$F$^$7$?!#(B
>>>> $B<:Ni$7$^$7$?!#(B
>>>>
>>>> $BCSED=_;R(B
>>>>
>>>>
>>>> 2016/11/29 6:51 <renayama19661014@ybb.ne.jp>:
>>>>
>>>>> naka$B$5$s(B
>>>>>
>>>>> $B$3$s$K$A$O!";3Fb$G$9!#(B
>>>>>
>>>>> $B>\:Y$O%m%0$r8+$F$_$J$$$H$o$+$j$^$;$s$,!"(B
>>>>> Pacemaker1.0$B7O$N(Bping$B%j%=!<%9$GMxMQ$7$F$$$k(Battrd_updater$B!J(Battrd$B%W%m%;%9$X$NB0@-99?7!K$N;EMM>e!"(B
>>>>> $B8N>c8!CN$h$j$b!"8N>c%+%&%s%H$N%"%C%W$,CY$l$k$3$H$,860x$@$H;W$o$l$^$9!#(B
>>>>>
>>>>> property$B$K!V(Bcrmd-transition-delay$B!W%Q%i%a!<%?$,$"$j$^$9$N$G!"$3$l$r(B5s$B$J$I$H@_Dj$7$F$_$F$/$@$5$$!#(B
>>>>> $B$3$l$K$h$j!"A4BNE*$K8N>cH/@8;~$N%U%'%$%k%*!<%P!<$,(B5s$BDxEYCY$l$F$7$^$$$^$9$,!"8N>c%+%&%s%H$N@)8f$O(B
>>>>> $B$&$^$/$$$/$O$:$G$9!#(B
>>>>>
>>>>> CentOS6.2$B$H(BOS$B4D6-$,8E$$$G$9$,!"2DG=$G$"$l$P!"(BPacemaker1.1$B7O$NMxMQ$r$48!F$$5$l$k$3$H$r$*4+$a$7$^$9!#(B
>>>>>
>>>>> $B0J>e$G$9!#(B
>>>>>
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>> > From: Keisuke Nakamura <k.xnakamu@gmail.com>
>>>>> > To: linux-ha-japan@lists.osdn.me
>>>>> > Cc:
>>>>> > Date: 2016/11/25, Fri 14:03
>>>>> > Subject: [Linux-ha-jp] ping$B%j%=!<%9$N(Bfail-count$B$K$D$$$F(B
>>>>> >
>>>>> > $B4X78<T3F0L(B
>>>>> >
>>>>> > $B$*@$OC$K$J$C$F$*$j$^$9!#(Bnaka$B$H?=$7$^$9!#(B
>>>>> >
>>>>> > $B4D6-!'(B
>>>>> > CentOS 6.2(x86_64)
>>>>> > pacemaker-1.0.12-1.el6.x86_64
>>>>> > heartbeat-3.0.5-1.1.el6.x86_64
>>>>> >
>>>>> > ($B<ALd(B)
>>>>> > ping$B%j%=!<%9$N(Bfail-count$B$K$D$$$F<ALd$G$9!#(B
>>>>> > ping$B%j%=!<%9$rMxMQ$7%G%U%)%k%H%2!<%H%&%'%$$X$NABDL4F;k(B
>>>>> > $B$r@_Dj$7$F$$$k(B2$B%N!<%I%/%i%9%?9=@.$rAH$s$G$*$j$^$9!#(B
>>>>> > $B@hF|J@<R4D6-$N%M%C%H%o!<%/>c32$N1F6A$G?tJ,4V!"N>%N!<%I$H$b(B
>>>>> > $B%G%U%)%2$X$NABDL$,IT0BDj$J>uBV$H$J$j!">e5-$N(Bping$B%j%=!<%9$G$N(B
>>>>> > $B0[>o$r7@5!$K%/%i%9%?%0%k!<%W%j%=!<%9$N(BF/O$B$,7+$jJV$79T$o$l$^$7$?!#(B
>>>>> > $B$=$N8e%M%C%H%o!<%/$,I|5l8e$O!"7+$jJV$79T$o$l$F$$$?(BF/O$B$b;_$^$j!"(B
>>>>> > $B%5!<%S%9$b@5>o$K5/F0$7$F$$$k>uBV$H$J$j$^$7$?!#(B
>>>>> >
>>>>> > $B>c32D>8e(Bcrm_mon$B$G>uBV$r$_$F$b!"(Bfail-count$B$,2C;;$5$l$F$J$/(B
>>>>> > failed action$B$bI=<($5$l$J$+$C$?$N$G$9$,!"(Bping$B%j%=!<%9$G(B
>>>>> > F/O$B$N>e8B2s?t$N@_Dj$O$G$-$k$b$N$G$7$g$&$+!)!JNc$($P(B3$B2s(BF/O
>>>>> > $B7+$jJV$7$?$iDd;_$9$k$H$+!K(B
>>>>> > fail-count$B$K$D$$$F$N>pJs$rC5$7=P$;$:!"Ev%a!<%k$K$F$4AjCL(B
>>>>> > $B$5$;$FD:$-$^$7$?!#$*<j7d$N;~$K$465<xD:$1$^$9$H9,$$$G$9!#(B
>>>>> >
>>>>> > ($B8=>u@_DjCM$N0lIt"-(B)
>>>>> > primitive res_ping ocf:pacemaker:ping \
>>>>> > params name="eth0_ping_set"
>>> host_list="10.1.0.1"
>>>>> > multiplier="200" dampen="1"
>>> debug="true"
>>>>> > attempts="10" \
>>>>> > op monitor interval="10s"
>> timeout="60"
>>> \
>>>>> > op start interval="0"
>> timeout="60"
>>>>> > $B!DCfN,!D(B
>>>>> > property $id="cib-bootstrap-options" \
>>>>> > dc-version="1.0.12-066152e" \
>>>>> > cluster-infrastructure="Heartbeat" \
>>>>> > stonith-enabled="false" \
>>>>> > no-quorum-policy="ignore" \
>>>>> > default-action-timeout="120s" \
>>>>> > last-lrm-refresh="1463626573"
>>>>> > rsc_defaults $id="rsc-options" \
>>>>> > resource-stickiness="INFINITY"
>>>>> >
>>>>> > $B0J>e!"59$7$/$*4j$$CW$7$^$9!#(B
>>>>> > _______________________________________________
>>>>> > Linux-ha-japan mailing list
>>>>> > Linux-ha-japan@lists.osdn.me
>>>>> > http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>>>>> >
>>>>>
>>>>> _______________________________________________
>>>>> Linux-ha-japan mailing list
>>>>> Linux-ha-japan@lists.osdn.me
>>>>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>>>>
>>>>
>>>> _______________________________________________
>>>> Linux-ha-japan mailing list
>>>> Linux-ha-japan@lists.osdn.me
>>>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>>>>
>>>
>>>
>>>
>>> --
>>> Nakamura
>>> _______________________________________________
>>> Linux-ha-japan mailing list
>>> Linux-ha-japan@lists.osdn.me
>>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>>>
>>
>> _______________________________________________
>> Linux-ha-japan mailing list
>> Linux-ha-japan@lists.osdn.me
>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>>
>
> _______________________________________________
> Linux-ha-japan mailing list
> Linux-ha-japan@lists.osdn.me
> http://lists.osdn.me/mailman/listinfo/linux-ha-japan



--
Nakamura
_______________________________________________
Linux-ha-japan mailing list
Linux-ha-japan@lists.osdn.me
http://lists.osdn.me/mailman/listinfo/linux-ha-japan