白澤さま こんにちは。大澤です。 お力になれたのであれば幸いです。 環境構築、大変ですよね。 また何かありましたらお気軽にお尋ねください。 大澤 ________________________________________ 差出人: Linux-ha-japan <linux****@lists*****> が ほしちえ <chi.e****@gmail*****> の代理で送信 送信日時: 2024年5月15日 10:35 宛先: linux****@lists***** 件名: Re: [Linux-ha-jp] 管理LANの指定につきまして 大澤様 お世話になっております。白澤です。 pcs host authで指定したLANの用途については、クラスタ操作に 限られそうなのですね。 いろいろご検証までいただき、ありがとうございます。 このように試せばよいのか！と勉強になります。 何かと併用させると、併用LANの故障時の操作はちょっと特殊になってしまいそう ということで了解いたしました。 「この場合何か問題があるだろうか・・・」という漠然とした質問に 道筋を見せていただきまして、本当にありがとうございます。 構築を引き続き頑張ってみます。 以上、どうぞよろしくお願いいたします。 > 2024/05/13 11:38、osawa****@newso*****のメール: > > 白澤さま > > こんにちは。大澤です。 > なるほど、管理LAN(pcs host authで指定したもの)とSTONITH-LAN(IPMI用のLAN)とを別系統にして、 > 管理LANのみをサービスLANあるいはレプリケーション用のLANと兼用する、ということですね。 > こちらこそ至らず申し訳ありません。 > > 特に問題はない・・・と思います。 > 面白そうだったので、試しに管理LANとサービスLANを兼用させて > そのNICの通信を遮断して > 色々なコマンドを叩いてみたのですが、 > 以下のような結果になりました。 > > ・ 管理LANを遮断した状態で > ー pcs cluster start --all ： 自ノードの起動は成功・対向ノードの起動は失敗 > ー pcs cluster stop --all ： 自ノードの停止は成功・対向ノードの停止は失敗 > ー pcs status --full ： 成功(ただし対向ノードのpcsdが停止していると表示される) > ー pcs node standby ： 自ノードのスタンバイ化、対向ノードのスタンバイ化とも成功 > ・ PG-REX起動後、プライマリの管理LANを遮断 > ー＞ pingリソースが故障を検知してスイッチオーバー(成功) > ー＞ その状態から手動でpg-rex_switchoverしようとすると失敗 > > おそらく、ですけれども、 > pcs host authで指定したLANが使用されるのは > pcs cluster start --all, pcs cluster stop --all, > あとおそらくpcs cluster destroy --all など、 > クラスタを操作するコマンドのみではないかと思います。 > （他のコマンドはcibを書き換えてIC-LAN経由で情報を伝えているはず) > また、管理LANが故障していても、自ノードの操作はできます。 > ですので、 > 例えばサービスLANと管理LANを兼用している状態でそのLANが故障したとして、 > 各ノードの停止などの操作を行いたい場合に > 操作をしたいノードにいちいち接続して操作をしなければならない、という不便さはありますが > 他には特に困るようなことはない・・・のではないでしょうか。 > > 以上、ご参考になりましたら幸いです。 > > > 大澤 > > > > > ________________________________________ > 差出人: Linux-ha-japan <linux****@lists*****> が ほしちえ <chi.e****@gmail*****> の代理で送信 > 送信日時: 2024年5月10日 15:05 > 宛先: linux****@lists***** > 件名: Re: [Linux-ha-jp] 管理LANの指定につきまして > > 大澤様 > > ご返信ありがとうございます。 > 白澤です。 > > 記述が足りず申し訳ありません、前メールの「管理LAN」とは、25P「3.3.4.HAクラスタ構築」項目の > 「(3)各ノードのホスト名、管理用LANのIPアドレスを指定し、ノードの認証を行います。」という部分の > 表現のことでした。 > 例：pcs host auth pgrex01 addr=172.20.144.41 pgrex02 addr=172.20.144.42 > 上記例ですと管理LAN＝STONITH-LANかと思います。 > このノードの認証コマンド実施時の指定IPをS-LANやD-LANにした場合、何かどこかの設定と矛盾など > 発生するのでしょうか。 > > 経緯といたしましては、今回、もともと私のほうで実施していたSTONITHまわりの構成（HW制御ボードと直接つなぐ）ですと > 上記「管理LAN」にSTONITH-LANを指定したコマンドがうまくいかない状態でしたので、試しにS-LANのIPを向けてコマンドをうったところ > ノードの認証（＝クラスタの構築？）ができてしまったのですが、その状態に何か問題はあるのかしらと思いまして… > クラスタ構成についてまだ知識が少ないので、妙なことを書いておりましたら申し訳ありません。 > >> STONITHはクラスタの運用にとって非常に重要な機能なので、 >> STONITH-LANはなるべく独立させた方がよいと、個人的には思います。 > →確かにいざ停止したいときにそのLANが何かと併用ではリスクが上がってしまうこととなりますね。 > ただ、各種動作自体はするとのことで、ご検証までいただきまして、勉強になります。 > 本当にありがとうございます。 > > > > >> 2024/05/09 18:29、osawa****@newso*****のメール: >> >> 白澤さま >> >> こんにちは。大澤です。 >> >> >> 解決の一助になれたようでよかったです。 >> あの図は「ネットワークを介してお互いに制御し合いますよ」という表現だと思います。 >> >>> 別のIP（D-LANやS-LAN）を指定することでも問題ないのでしょうか？ >>> （それともやはり何か弊害があり、管理LANは可能ならDやSとは切り離されている方が望ましい？） >> D-LAN/S-LANとSTONITH-LANの兼用ですか。 >> ぱっと思いつく弊害は、例えば >> 「S-LANが故障 → 何らかの理由でスイッチオーバー失敗 → 対向ノードをSTONITHしたい」 >> となったときにSTONITHできなくなってしまうなど、 >> ネットワーク故障に加えてさらに故障が発生したときにサービス停止に陥る恐れがあるのでは？ >> ・・・くらいでしょうか。 >> STONITHはクラスタの運用にとって非常に重要な機能なので、 >> STONITH-LANはなるべく独立させた方がよいと、個人的には思います。 >> ・・・が、兼用していても動作はしますので、試しに使う分には問題ないはずです。 >> （さっき試しにやってみましたが、S-LANとSTONITH-LANを兼用していても、 >> プライマリの起動/スタンバイの起動/スイッチオーバー/スイッチバック すべて問題なく動作しました) >> >> >> 大澤 >> >> ________________________________________ >> 差出人: Linux-ha-japan <linux****@lists*****> が ほしちえ <chi.e****@gmail*****> の代理で送信 >> 送信日時: 2024年5月9日 9:41 >> 宛先: linux****@lists***** >> 件名: Re: [Linux-ha-jp] 管理LANの指定につきまして >> >> >> 大澤様 >> >> ご返信ありがとうございます。 >> 白澤です。 >> >> はい、ドキュメントの18pの図的に直接なのかなと思い、直接接続しておりました。スイッチ経由に変更すれば確かに問題ないですね。 >> ご指摘ありがとうございます！ >> >> ちなみになのですが、このノードの認証部分について、172.20.144.（STONITH用）ではなく別のIP（D-LANやS-LAN）を指定することでも問題ないのでしょうか？ >> （それともやはり何か弊害があり、管理LANは可能ならDやSとは切り離されている方が望ましい？） >> >> どうぞよろしくお願いいたします。 >> >>> 2024/05/08 16:02、osawa****@newso*****のメール: >>> >>> 白澤さん、こんにちは。 >>> 大澤と申します。 >>> >>> いまは、HW制御ボードのマネジメントポートと、対抗ノードのNIC(eno6)を >>> 直接LANケーブルで接続されている、ということでよろしいでしょうか？ >>> もしそうでしたら、 >>> マネジメントポートとeno6は直接つなぐのではなく、それぞれスイッチに接続してみてください。 >>> （IPMIはネットワーク経由でハードウェアを操作しますので） >>> >>> >>> 大澤 >>> >>> ________________________________________ >>> 差出人: Linux-ha-japan <linux****@lists*****> が ほしちえ <chi.e****@gmail*****> の代理で送信 >>> 送信日時: 2024年5月8日 10:56 >>> 宛先: linux****@lists***** >>> 件名: [Linux-ha-jp] 管理LANの指定につきまして >>> >>> お世話になります。 >>> 白澤と申します。 >>> >>> 現在、「PG-REX15利用マニュアル_第2.0.0版(公開用利用者マニュアル).docx」を参考に >>> 機器を構築中です。 >>> マニュアルの記載について質問させてください。 >>> >>> 19P「3.1.2 本マニュアルで使用するIPアドレス」に >>> 以下の通りSTONITH-LANが定義されております。 >>> • STONITH-LAN >>> – pgrex01-eno6 : 172.20.144.41 >>> – pgrex02-eno6 : 172.20.144.42 >>> >>> また、同資料の18P図によると、上記2台のeno6はHW制御ボードと直接配線されているように >>> 見えます。 >>> >>> 上記を踏まえて、25P（3.3.4HAクラスタ構築）なのですが、 >>> (3)のサンプルコマンドの管理LANのIP指定が以下のようにeno6のものになっております。 >>> === >>> (3) 各ノードのホスト名、管理用LANのIPアドレスを指定し、ノードの認証を行います。(いずれか１つのノードで実行) >>> # pcs host auth pgrex01 addr=172.20.144.41 pgrex02 addr=172.20.144.42 >>> Username: hacluster >>> Password: >>> pgrex01: Authorized >>> pgrex02: Authorized >>> === >>> >>> 18Pの図と同様に構成（eno6にあたるNICを制御ボードに接続）いたしますと、 >>> pgrex01側からは172.20.144.42が参照できず、 >>> またpgrex02側からは172.20.144.41が参照できません。 >>> >>> pgrex01で上記pcsコマンドを打った場合： >>> pgrex01: Authorized >>> Error: Unable to communicate with pgrex02 >>> pgrex02で上記pcsコマンドを打った場合 >>> pgrex02: Authorized >>> Error: Unable to communicate with pgrex01 >>> >>> どこか資料の読み取りを間違えていそうな箇所をご指摘いただけませんでしょうか？ >>> >>> >>> 以上、どうぞよろしくお願いいたします。 >>> _______________________________________________ >>> Linux-ha-japan mailing list >>> Linux****@lists***** >>> https://urldefense.com/v3/__https://lists.osdn.me/mailman/listinfo/linux-ha-japan__;!!GCTRfqYYOYGmgK_z!4eo4xkgDqYveA723u3kB0fkv9HVDyrOnr01-2T-HR8ZjDbZyadDpu30SZrmzB1H0zDZJ2tTF5fwDR3gF92dMT1sawg$ >>> _______________________________________________ >>> Linux-ha-japan mailing list >>> Linux****@lists***** >>> https://urldefense.com/v3/__https://lists.osdn.me/mailman/listinfo/linux-ha-japan__;!!GCTRfqYYOYGmgK_z!-hdlQ8nWqdm9T0uAG-AYOKCe3x6fwRxkZiU4v_3N_avzw09IKrDIz2JpA-Zivd3c6-x5CWXrbALWqsNXZKF8V7U2LA$ >> _______________________________________________ >> Linux-ha-japan mailing list >> Linux****@lists***** >> https://urldefense.com/v3/__https://lists.osdn.me/mailman/listinfo/linux-ha-japan__;!!GCTRfqYYOYGmgK_z!-hdlQ8nWqdm9T0uAG-AYOKCe3x6fwRxkZiU4v_3N_avzw09IKrDIz2JpA-Zivd3c6-x5CWXrbALWqsNXZKF8V7U2LA$ >> _______________________________________________ >> Linux-ha-japan mailing list >> Linux****@lists***** >> https://urldefense.com/v3/__https://lists.osdn.me/mailman/listinfo/linux-ha-japan__;!!GCTRfqYYOYGmgK_z!-63l6eVRBdvJA3YI6lya7flRX721tA5D4McabhaeNSX6pKOwWY97q1-3GnQ0xujMd9A-bmLYsfKQ5-eg6VgcSajpAA$ > _______________________________________________ > Linux-ha-japan mailing list > Linux****@lists***** > https://urldefense.com/v3/__https://lists.osdn.me/mailman/listinfo/linux-ha-japan__;!!GCTRfqYYOYGmgK_z!-63l6eVRBdvJA3YI6lya7flRX721tA5D4McabhaeNSX6pKOwWY97q1-3GnQ0xujMd9A-bmLYsfKQ5-eg6VgcSajpAA$ > _______________________________________________ > Linux-ha-japan mailing list > Linux****@lists***** > https://urldefense.com/v3/__https://lists.osdn.me/mailman/listinfo/linux-ha-japan__;!!GCTRfqYYOYGmgK_z!4eoFQt9sB48mLBTMLsuol9XO15TVd7ec-Jt-NTwKTKAnm_HuIGv4mbggwkvMumjCszPghzQDxmMxp2gGAVI_UlWSQQ$ _______________________________________________ Linux-ha-japan mailing list Linux****@lists***** https://urldefense.com/v3/__https://lists.osdn.me/mailman/listinfo/linux-ha-japan__;!!GCTRfqYYOYGmgK_z!4eoFQt9sB48mLBTMLsuol9XO15TVd7ec-Jt-NTwKTKAnm_HuIGv4mbggwkvMumjCszPghzQDxmMxp2gGAVI_UlWSQQ$
Fork