Keisuke Nakamura
k.xna****@gmail*****
2016年 10月 27日 (木) 18:14:53 JST
ひばり様、浜田様、各位 お世話になっております。nakaと申します。 度々申し訳ありません。 もしどなたが御存じであれば。。 > # pacemaker1.0系だと、上記LVMのソースコードにexclusiveの > # 制御はされていないようですね。さすがに旧バージョンの設定 > # 通りにはいかなかったです。。 手元にある別の下記環境、 CentOS 6.2(x86_64) pacemaker-1.0.12-1.el6.x86_64 heartbeat-3.0.5-1.1.el6.x86_64 こちらでは ・lvm.confはデフォルト設定（volume_listは何も定義していない） ・pacemakerのLVMのRAに「exclusive=true」の記述無し のまま運用していても、待機系OS再起動時には特に共有ディスクが活性化される こともなく、もちろんスプリットブレイン状態にもなりませんでした。 この差は何なのか？なにかしら情報をお持ちでしたらご教授頂けると幸いです。 ・pacemkaer1.0と1.1の違いによるソースコード(/usr/lib/ocf/resource.d/heartbeat/LVM)の違い ・OS(6.2と7.2)の違い ・lvm2のバージョンの違い 等、構成が異なる部分を確認しないといけないのは重々承知しておりますが、 何かしら情報をお持ちでしたらと思い、問合せさせて頂きました。 以上、宜しくお願い致します。 2016年10月21日 18:17 Keisuke Nakamura <k.xna****@gmail*****>: > ひばり様、浜田様 > > お世話になっております。nakaと申します。 > > ひばり様浜田様のご尽力のおかげで、事象解消することができました。 > 有難うございます。 > >> 上記はシェルを直接実行するのではなく、 >> RAを編集した上でPacemakerを実行するとを >> 意図していました。 > そうですよね、、失礼致しました。 > > 私も/usr/lib/ocf/resource.d/heartbeat/LVMを > ざっと眺めてみました。浜田様のご指摘の通り、 > LVMのRAにexclusive=trueを追記したところ、正常に > RAが起動し動作しました！ > > 参考までにRH社の「High_Availability_Add-On_Administration」マニュアルに > exclusiveの記述がありました。 > https://access.redhat.com/documentation/ja-JP/Red_Hat_Enterprise_Linux/7/html/High_Availability_Add-On_Administration/s1-resourcegroupcreatenfs-HAAA.html > > volume_listの修正と上記RAの追記で、待機系のOS再起動後も特に > スプリットブレインは発生せず。sfexについては素のパーティションを > 用意して準備したいと思います。 > > # pacemaker1.0系だと、上記LVMのソースコードにexclusiveの > # 制御はされていないようですね。さすがに旧バージョンの設定 > # 通りにはいかなかったです。。 > > 諸々ご確認頂き大変助かりました。 > とても勉強になりました。。 > > 以上、宜しくお願い致します。 > > > 2016年10月20日 19:58 Michiro Hibari <l0510****@shiba*****>: >> naka様 >> >> ひばりです。 >> >> gvsの結果をお見せ頂きありがとうございます。 >> クラスタオプションが原因ではなかったようですね。 >> >>> あとは/usr/lib/ocf/resource.d/heartbeat/LVM >>> のシェバン（最初の行）に-xオプションを追加して >>> 実行すると詳細なログが出力されるので手がかりを >>> 得られるかもしれません。 >> >> 言葉足らずですいません。 >> >> 上記はシェルを直接実行するのではなく、 >> RAを編集した上でPacemakerを実行するとを >> 意図していました。 >> >> そうすると corosync.logに詳細なログが >> 出るようになるはずです。 >> >> ocf-shellfuncsはPacemakerがRAを呼び出す >> 際にはちゃんと読み込まれますので大丈夫です。 >> heartbeatパッケージをインストールする必要は >> ありません。 >> >> >> 2016/10/20 19:30 "Keisuke Nakamura" <k.xna****@gmail*****>: >> >>> ひばり様 >>> >>> お世話になっております。 >>> >>> ご確認頂き有難うございます。 >>> vgsコマンドは正常表示のようです。(vg00とvgua01を参照できます。) >>> /usr/lib/ocf/resource.d/heartbeat/LVMを実行しますと、ファイルがないと >>> 怒られました。 >>> >>> # vgs >>> VG #PV #LV #SN Attr VSize VFree >>> vg00 1 7 0 wz--n- 51.09g 0 >>> vgua01 1 2 0 wz--n- 11.00g 0 >>> >>> # sh /usr/lib/ocf/resource.d/heartbeat/LVM >>> /usr/lib/ocf/resource.d/heartbeat/LVM: 行 30: >>> /lib/heartbeat/ocf-shellfuncs: そのようなファイルやディレクトリはありません >>> >>> pacemakerのバージョンがあがって、heartbeatのパッケージが入らなくなったから >>> でしょうかね。LVMのRAを利用するには、corosyncだけでは足りないってことなんでしょうかね。 >>> 明日heartbeatパッケージ（heartbeat-2.1.4-1.rhel5.x86_64.RPMS.tar.gz）あたりを追加で >>> 入れてみようかな。。 >>> >>> 以上、宜しくお願い致します。 >>> >>> >>> 2016年10月20日 17:31 Michiro Hibari <l0510****@shiba*****>: >>> > naka様 >>> > >>> > ひばりです。 >>> > お世話になっております。 >>> > >>> > resource-agentsのバージョンが3.9.7でしたら、 >>> > RAには先のメールに記載した処理が実装されております。 >>> > >>> > 色々と情報を確認してばかりで申し訳ないのですが、 >>> > vgsの実行結果もお見せいただけないでしょうか。 >>> > >>> > あとは/usr/lib/ocf/resource.d/heartbeat/LVM >>> > のシェバン（最初の行）に-xオプションを追加して >>> > 実行すると詳細なログが出力されるので手がかりを >>> > 得られるかもしれません。 >>> > >>> > >>> > 2016/10/20 16:02 "Keisuke Nakamura" <k.xna****@gmail*****>: >>> >> >>> >> ひばり様、浜田様 >>> >> >>> >> >>> >> お世話になっております。nakaと申します。 >>> >> ご確認頂き有難うございます。 >>> >> >>> >> > ★★★★★★★★★★★★★★★★★★ >>> >> > （活性化） >>> >> > # vgchange --addtag pacemaker vgua01 >>> >> > # vgchange -ay --config activation{volume_list=[\"@pacemaker\"]} >>> >> > vgua01 >>> >> > >>> >> > （非活性化） >>> >> > # vgchange -an vgua01 >>> >> > # vgchange --deltag pacemaker vgua01 >>> >> > ★★★★★★★★★★★★★★★★★★ >>> >> >>> >> 上記コマンドを手動で実施すると、正常にvgua01を活性/非活性化することができました。。 >>> >> >>> >> # vgchange -ay vgua01 >>> >> 0 logical volume(s) in volume group "vgua01" now active >>> >> # vgchange --addtag pacemaker vgua01 >>> >> Volume group "vgua01" successfully changed >>> >> # vgchange -ay --config activation{volume_list=[\"@pacemaker\"]} vgua01 >>> >> 2 logical volume(s) in volume group "vgua01" now active >>> >> # vgchange -an vgua01 >>> >> 0 logical volume(s) in volume group "vgua01" now active >>> >> # vgchange --deltag pacemaker vgua01 >>> >> Volume group "vgua01" successfully changed >>> >> >>> >> resource-agentsはバージョン「3.9.7」です。 >>> >> このバージョンが古いのでしょうかね？ >>> >> >>> >> # rpm -qi resource-agents >>> >> Name : resource-agents >>> >> Version : 3.9.7 >>> >> Release : 1.2.6f56.el7 >>> >> Architecture: x86_64 >>> >> Install Date: 2016年09月12日 10時44分49秒 >>> >> Group : System Environment/Base >>> >> Size : 1873911 >>> >> License : GPLv2+ and LGPLv2+ >>> >> Signature : (none) >>> >> Source RPM : resource-agents-3.9.7-1.2.6f56.el7.src.rpm >>> >> Build Date : 2016年04月07日 13時28分39秒 >>> >> Build Host : build-centos71 >>> >> Relocations : (not relocatable) >>> >> Vendor : Linux-HA Japan >>> >> URL : https://github.com/ClusterLabs/resource-agents >>> >> Summary : Open Source HA Reusable Cluster Resource Scripts >>> >> Description : >>> >> A set of scripts to interface with several services to operate in a >>> >> High Availability environment for both Pacemaker and rgmanager >>> >> service managers. >>> >> >>> >> resource-agentsバージョンの改訂履歴を探してみます。。 >>> >> 取り急ぎ。 >>> >> >>> >> 2016年10月19日 19:00 Michiro Hibari <l0510****@shiba*****>: >>> >> > naka様 浜田様 >>> >> > >>> >> > ひばりです。 >>> >> > お世話になっております。 >>> >> > >>> >> > volume_list = [ "vg00" ] ★vg00はローカルでの使用。 >>> >> > >>> >> > 上記設定をlvm.confに行った時点でvolume_listで指定した >>> >> > VG以外をvgchange等のlvmコマンドで操作することが >>> >> > 出来なくなります。 >>> >> > ＃クラスタでLVMのボリュームを制御する際は、クラスタの管理外 >>> >> > ＃クラスタ管理対象のボリュームが操作されないように上記設定を >>> >> > ＃行います。 >>> >> > >>> >> > そのため手動で共有ディスクの活性化を行えないこと >>> >> > 自体は正常な動作といえます。 >>> >> > >>> >> > ただ、Pacemakerはvolume_listをRA内部で実行する >>> >> > コマンド上で書き換えていますので、本来であれば >>> >> > Pacemaker起動時にvgua01がACT側のノードで活性化される >>> >> > はずです。 >>> >> > >>> >> > 具体的には以下の処理を行っていますので、 >>> >> > まずは手動で下記コマンドを実行し、VGが活性化できるかを >>> >> > ご確認ください。 >>> >> > >>> >> > ★★★★★★★★★★★★★★★★★★ >>> >> > （活性化） >>> >> > # vgchange --addtag pacemaker vgua01 >>> >> > # vgchange -ay --config activation{volume_list=[\"@pacemaker\"]} >>> >> > vgua01 >>> >> > >>> >> > （非活性化） >>> >> > # vgchange -an vgua01 >>> >> > # vgchange --deltag pacemaker vgua01 >>> >> > ★★★★★★★★★★★★★★★★★★ >>> >> > >>> >> > resource-agentsのバージョンが古いと上記の処理が >>> >> > 実装されていませんので、念のため上記の実行結果と合わせて >>> >> > resource-agentsのバージョンもお教え下さい。 >>> >> > >>> >> > なお、浜田様からメールを頂いておりますが >>> >> >> そもそも、LVM はクラスタに対応していないと思います。 >>> >> > (snip) >>> >> >> たまたま、何らかのロック機構が働いて、 >>> >> >> LVMを活性化できないおかげでデータが破壊されずに済んでいる、 >>> >> > >>> >> > LVMをクラスタで制御することは可能です。 >>> >> > LVMは複数ノードからの活性化を想定していませんが、 >>> >> > LVMを複数ノードで活性化しないように正しく >>> >> > 設定を行えば問題ありません。 >>> >> > ＃そのためにvolume_listの設定を行っています。 >>> >> > >>> >> >> ・LVMの設定ファイルを書き換えるリソースエージェントを開発する。 >>> >> > PacemakerのLVM RAは既に対応しております。 >>> >> > （★部の処理が組み込まれている） >>> >> > >>> >> > その他、clvmは複数ノードからの活性化(LVMの操作）に対応した >>> >> > LVMとなりますが、その上に載るファイルシステムがGFSのような >>> >> > 複数ノードからのマウントに対応してるものでない場合、 >>> >> > clvmを利用してもファイルシステムをマウントできるノードは >>> >> > 1つとなりますので、今回のようにxfsを扱う場合、clvmは >>> >> > オーバースペックかもしれません。 >>> >> > >>> >> > >>> >> > 2016/10/19 17:05 "Keisuke Nakamura" <k.xna****@gmail*****>: >>> >> >> >>> >> >> ひばり様、各位 >>> >> >> >>> >> >> お世話になっております。nakaと申します。 >>> >> >> 先日のlvm.confの件、頂いた回答やネット上の情報を参考にしましたがどうもうまくいかず悩んでおります。。 >>> >> >> >>> >> >> 【やったこと】 >>> >> >> /etc/lvm/lvm.confの編集。 >>> >> >> ↓下記の通り設定。 >>> >> >> >>> >> >> volume_list = [ "vg00" ] ★vg00はローカルでの使用。 >>> >> >> use_lvmetad = 0 >>> >> >> locking_type = 1 >>> >> >> >>> >> >> initramfsの再作成 >>> >> >> dracut -H -f /boot/initramfs-$(uname -r).img $(uname -r) >>> >> >> >>> >> >> OSリブート >>> >> >> >>> >> >> これで、確かにOS起動時にはローカル(vg00)は活性状態、クラスタ共有ディスク(vgua01)は非活性に >>> >> >> なるのですが、手動で共有ディスク(vgua01)の活性化(vgchange -a y)はできない状態でした。 >>> >> >> pacemakerでのLVMリソースの起動も失敗してしまいます。volume_listをコメントアウトすると、 >>> >> >> 正常に活性化できます。何か足りない設定があるのかな、、 >>> >> >> >>> >> >> とここまで書いて、既にpacemakerの話ではなく、OSのLVMの話になってますよね。 >>> >> >> pacemaker(+corosync)でLVMのクラスタ共有ディスクを使う場合に他に考慮が必要なのでしょうか。。 >>> >> >> >>> >> >> 何か些細なことでも気になる点等ございましたらご指摘頂けると助かります。 >>> >> >> 参考までに、「crm resouce start vgua01(LVMリソース)」後のcorosync.logを添付致します。 >>> >> >> >>> >> >> Naka >>> >> >> >>> >> >> _______________________________________________ >>> >> >> Linux-ha-japan mailing list >>> >> >> Linux****@lists***** >>> >> >> http://lists.osdn.me/mailman/listinfo/linux-ha-japan >>> >> >> >>> >> > >>> >> > _______________________________________________ >>> >> > Linux-ha-japan mailing list >>> >> > Linux****@lists***** >>> >> > http://lists.osdn.me/mailman/listinfo/linux-ha-japan >>> >> > >>> >> >>> >> >>> >> >>> >> -- >>> >> Nakamura >>> >> _______________________________________________ >>> >> Linux-ha-japan mailing list >>> >> Linux****@lists***** >>> >> http://lists.osdn.me/mailman/listinfo/linux-ha-japan >>> > >>> > >>> > _______________________________________________ >>> > Linux-ha-japan mailing list >>> > Linux****@lists***** >>> > http://lists.osdn.me/mailman/listinfo/linux-ha-japan >>> > >>> >>> >>> >>> -- >>> Nakamura >>> _______________________________________________ >>> Linux-ha-japan mailing list >>> Linux****@lists***** >>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan >> >> >> _______________________________________________ >> Linux-ha-japan mailing list >> Linux****@lists***** >> http://lists.osdn.me/mailman/listinfo/linux-ha-japan >> > > > > -- > Nakamura -- Nakamura
Fork