樋口さん こんばんは、山内です。 >migration-threshold=1の設定を１にし、再度障害を再現しましたが以下のようにFOせずFAILEDになってしまいました。 FOしない状態が発生した故障～のログを添付していただけますでしょうか？ ※できれば、crm_reportコマンドで取集される、/var/lib/pacemaker/配下のファイルも頂けると幸いです。 sfexなど利用する方法もありますが、stonithリソースを使わない場合には、FOに失敗してサービス停止が発生する可能性が残ります。 fence_scsiを利用する方法もありますが、この場合、両ノード(ACT/STB)から共有ストレージが見えていてアクセス可能な必要があります。 ※お聞きした範囲では、ACTからしか共有ストレージは見えていないはずですので、fence_scsiは利用できないのではないかと思います。 また、fence_scsiを利用する場合には、watchdogサービスも必要となります。 ※こちらに関しては、MLで森さんが回答されたREHLの情報も参考になるかと思います。 fence_scsiは、REHL構成ではfence_agentsパッケージに含まれるものになります。 お使いのディストリビューションで配布されているかどうかご確認ください。 ※RHELなどではインストールした時には/usr/sbinに配置されます。 以上です。 ----- Original Message ----- >From: Yuki Higuchi <Yuki.****@ibm*****> >To: renay****@ybb***** >Cc: linux****@lists***** >Date: 2021/1/13, Wed 16:41 >Subject: RE: filesystemのFOに関して > > >山内さん > >お世話になっております、樋口です。 > >migration-threshold=1の設定を１にし、再度障害を再現しましたが以下のようにFOせずFAILEDになってしまいました。 > > >また、以前他の方に質問させていただいた際に以下のコメントをいただいたため、 > >”STONITH機能が利用できない場合は、リソースの故障には対応可能であるがノード故障やスプリットブレイン対策ができない" > >リソースのstop故障からのリソース移動はSTONITHを使わずとも対応できるかと思っていたのですが、STONITHを使う以外に方法はないのですね…（SFEXを使用しても同じでしょうか？） > >パブリッククラウド環境下での構築という制約がある中で、共有ディスクを用いたSTONITH機能(fence_scsi)を推奨いただいたのですが、 >構築中の環境内にfence_scsiプラグインが見えない状況なのですが、アドオンとして追加する必要があるということでしょうか？ > >[root ＠ hfmn10t external]# pwd >/usr/lib64/stonith/plugins/external >[root ＠ hfmn10t external]# >[root ＠ hfmn10t external]# ll >合計 176 >-rwxr-xr-x 1 root root 1753 6月 14 2019 drac5 >-rwxr-xr-x 1 root root 14131 6月 14 2019 dracmc-telnet >-rwxr-xr-x 1 root root 11101 6月 14 2019 ec2 >-rwxr-xr-x 1 root root 4034 6月 14 2019 hetzner >-rwxr-xr-x 1 root root 5275 6月 14 2019 hmchttp >-rwxr-xr-x 1 root root 2911 6月 14 2019 ibmrsa >-rwxr-xr-x 1 root root 11541 6月 14 2019 ibmrsa-telnet >-rwxr-xr-x 1 root root 6602 6月 14 2019 ipmi >-rwxr-xr-x 1 root root 7865 6月 14 2019 ippower9258 >-rwxr-xr-x 1 root root 7613 6月 14 2019 kdumpcheck >-rwxr-xr-x 1 root root 6829 6月 14 2019 libvirt >-rwxr-xr-x 1 root root 9125 6月 14 2019 nut >-rwxr-xr-x 1 root root 7357 6月 14 2019 rackpdu >-rwxr-xr-x 1 root root 16168 6月 14 2019 riloe >-rwxr-xr-x 1 root root 13358 6月 14 2019 stonith-helper >-rwxr-xr-x 1 root root 9683 6月 14 2019 vcenter >-rwxr-xr-x 1 root root 5045 6月 14 2019 vmware >-rwxr-xr-x 1 root root 5460 6月 14 2019 xen0 >-rwxr-xr-x 1 root root 2247 6月 14 2019 xen0-ha >[root ＠ hfmn10t external]# > >長文になってしまい大変申し訳ございませんがよろしくお願いいたします。 > > > > > > >----- 元のメッセージ ----- >>送信元: renay****@ybb***** >>宛先: Yuki Higuchi <Yuki.****@ibm*****> >>Cc: "linux****@lists*****" <linux****@lists*****> >>件名: [EXTERNAL] Re: filesystemのFOに関して >>日付: 2021年1月13日 (水) 1:43 PM >> >>樋口さん >> >>こんにちは、山内です。 >> >>共有ストレージは、ACTのみから見えていると解釈しました。 >> >>以下のように故障などからの閾値(migration-threshold)を１に設定していただけますか？ >> >>### Resource Defaults ### >>rsc_defaults resource-stickiness="INFINITY" \ >> migration-threshold="1" >> >>この場合、リソース故障が発生してfail-countが1以上になると、リソースは他ノードへ追い出されることになります。 >>この閾値は、リソース毎に設定することも可能です。 >> >> >>また、頂いた設定では、stonithが設定されていないので、リソースのstop故障からのリソース移動ができないはずです。 >> >>リソースのstop故障からのフェイルオーバーを安全・正常に動作させるのであれば、必要であれば、クラウド環境で利用可能な >>stonithリソースを設定することをお勧めします。 >> >>以上、宜しくお願いいたします。 >> >> >>----- Original Message ----- >>>From: Yuki Higuchi <Yuki.****@ibm*****> >>>To: renay****@ybb***** >>>Cc: linux****@lists***** >>>Date: 2021/1/13, Wed 12:14 >>>Subject: RE: filesystemのFOに関して >>> >>> >>>山内さん >>> >>>ご連絡ありがとうございます、樋口です。 >>> >>>共有ディスク（ファイルストレージ）はAct機でのみマウントされている状態で、Sby機ではFO後にマウントされる想定です。 >>> >>>crm設定ファイルを添付いたします。 >>> >>>よろしくお願いいたします。 >>> >>>----- 元のメッセージ ----- >>>>送信元: renay****@ybb***** >>>>宛先: Yuki Higuchi <Yuki.****@ibm*****> >>>>Cc: "linux****@lists*****" <linux****@lists*****> >>>>件名: [EXTERNAL] Re: filesystemのFOに関して >>>>日付: 2021年1月12日 (火) 11:06 PM >>>> >>>>樋口さん >>>> >>>>こんばんは、山内です。 >>>> >>>>共有ディスクということですので、両ノードからディスクは見えているとすると、「 >>>>1)diskdを共有ディスクに対しても設定して、locacation成約に追加する。 >>>>2)migration-thresholdを1など小さい値に設定する。 >>>> >>>>が考えられると思います。 >>>>※クラウド環境とのことですので、こちらで手元せ確認出来ませんが・・ >>>> >>>>再度、現在の最終的な設定ファイルを開示していただけますでしょうか？ >>>> >>>>以上、宜しくお願いいたします。 >>>> >>>> >>>> >>>>----- Original Message ----- >>>>>From: Yuki Higuchi <Yuki.****@ibm*****> >>>>>To: renay****@ybb***** >>>>>Cc: linux****@lists***** >>>>>Date: 2021/1/12, Tue 18:41 >>>>>Subject: filesystemのFOに関して >>>>> >>>>> >>>>>山内さん >>>>> >>>>>毎度お世話になっております、樋口です。 >>>>> >>>>>PacemakerにおけるリソースのFOの試験を実施している最中なのですが、以下問題が発生してしまい、お力添えをいただきたいです。 >>>>> >>>>>【事象】 >>>>>filesystemの試験として共有ディスクへのLANを不通にした際にFOが起こらない。 >>>>> >>>>>【実施事項】 >>>>>・共有ディスクとしてクラウドサービスのファイルストレージを使用。 >>>>> Pacemaker起動時やAct機のreboot等によるFO実施時にはAct機にてmountされることは確認済。 >>>>>・Act機において、共有ディスクへの接続に使用しているインターフェイス(eth1)を ifconfig eth1 down コマンドにてダウンを実施。 >>>>>・crm_mon -rfAコマンドを実施して確認したところ、以下のようにFAILED hfmn10tと失敗したままFOされない。 >>>>> >>>>>Online: [ hfmn10t hfmn20t ] >>>>>Full list of resources: >>>>> Resource Group: grpTrac >>>>> vipcheck (ocf::heartbeat:VIPcheck): Started hfmn10t >>>>> ipaddr2 (ocf::heartbeat:IPaddr2): Started hfmn10t >>>>> filesystem (ocf::heartbeat:Filesystem): FAILED hfmn10t >>>>> Clone Set: clnDiskd [prmDiskd] >>>>> Started: [ hfmn10t hfmn20t ] >>>>> Clone Set: clnPing [prmPing] >>>>> Started: [ hfmn10t hfmn20t ] >>>>>Node Attributes: >>>>>* Node hfmn10t: >>>>> + default_ping_set : 100 >>>>> + diskcheck_status_internal : normal >>>>> + ringnumber_0 : 192.168.d.xx is UP >>>>> + ringnumber_1 : 192.168.d.yy is UP >>>>>* Node hfmn20t: >>>>> + default_ping_set : 100 >>>>> + diskcheck_status_internal : normal >>>>> + ringnumber_0 : 192.168.d.zz is UP >>>>> + ringnumber_1 : 192.168.d.aa is UP >>>>>Migration Summary: >>>>>* Node hfmn10t: >>>>> filesystem: migration-threshold=1000000 fail-count=1 last-failure='Tue Jan 12 18:14:10 2021' >>>>>* Node hfmn20t: >>>>>Failed Resource Actions: >>>>>* filesystem_monitor_10000 on hfmn10t 'unknown error' (1): call=33, status=Timed Out, exitreason='', >>>>> last-rc-change='Tue Jan 12 18:14:10 2021', queued=0ms, exec=0ms >>>>> >>>>>度々の質問になってしまい恐縮ですが、よろしくお願いいたします。 >>>>> >>>>> >>>>> >>>> >>> >>> >>> >>> >> > > > >
Fork