Yusuke Iida
yusk.****@gmail*****
2015年 2月 26日 (木) 13:49:19 JST
北林さま 飯田と申します。 2015年2月26日 11:44 よしばー <kitab****@gmail*****>: > 松島様 > > ご丁寧に返信ありがとうございます。 > NICについての知識が深まりました。 > > ですが、挙動についての不明な点がございます。 > > ＜環境＞ > 【firstサーバ】 > サービス用NIC（eth0）；172.16.87.233 > 死活監視用NIC（eth1）；192.168.1.1 > 【secondサーバ】 > サービス用NIC（eth0）；172.16.87.234 > 死活監視用NIC（eth1）；192.168.1.2 > （2つともvmwareで作った仮想環境です） > > ネットワークに障害がおきた場合の検証がしたいのですが、 > 以下の手順で作業を行った場合、 > firstサーバからsecondサーバにリソースが動いてくれませんでした。 この時の挙動としては次のことが起こったのではないかと予想します。 1．service network restartにより、死活監視用NICが一旦停止する。 2．死活監視用NICにIPが再度割当たる前にcorosyncが通信異常を検知し、スプリットブレイン状態となる。 3．スプリットブレイン状態になったため、secondサーバでリソースの起動が実行されたが、vipcheckはvipが存在していることを検知して起動エラーとなった。 →スプリットブレイン時の2重起動防止のためこれは正しい動き > > （正常化同時、firstサーバにて） > # rm -f /etc/sysconfig/network-scripts/ifcfg-eth0(サービス用) > # service network restart > > (secondサーバにて) > # crm_mon -fAD > ↓↓ > Online: [ second ] > OFFLINE: [ first ] > > Node Attributes: > * Node second: > + ringnumber_0 : 192.168.1.2 is UP > > Migration summary: > * Node second: > vipcheck: migration-threshold=1 fail-count=1000000 last-failure='Tue Feb 24 1 > 0:42:22 2015' > > Failed actions: > vipcheck_start_0 on second 'unknown error' (1): call=36, status=complete, la > st-rc-change='Tue Feb 24 10:42:20 2015', queued=0ms, exec=2192ms > ↑↑ > > 以前お教えくださった以下URLにも、 > ”「ifdownとかip link set downとかでもよいのでは」と思うのですが、実はこれをやるとCorosyncのプロセスが落ちます。” > http://qiita.com/takehironet/items/08716d3a9d1165f47b5c > > とあったのですが、この手順の場合も > corosyncプロセスが落ちてしまったため、リソースの移動がされなかったということでしょうか。 corosyncが落ちてしまったかどうかはわからないため、ログやプロセスを確認してみてください。 > > ですが気になるのが、 > > （正常稼動時、firstサーバにて） > # rm -f /etc/sysconfig/network-scripts/ifcfg-eth1（死活監視用） > # service network restart > > (secondサーバにて) > # crm_mon -fAD > Online: [ first second ] > > Resource Group: web-group > vipcheck (ocf::heartbeat:VIPcheck): Started second > tomcat (ocf::heartbeat:tomcat): Started second > apache (ocf::heartbeat:apache): Started second > vip (ocf::heartbeat:IPaddr2): Started second > > Node Attributes: > * Node first: > + ringnumber_0 : 192.168.1.1 is UP > * Node second: > + ringnumber_0 : 192.168.1.2 is UP > > Migration summary: > * Node first: > vip: migration-threshold=1 fail-count=1 last-failure='Wed Feb 25 10:19:56 201 > 5' > * Node second: > > Failed actions: > vip_monitor_10000 on first 'unknown error' (1): call=80, status=complete, la > st-rc-change='Wed Feb 25 10:19:56 2015', queued=0ms, exec=0ms > Connection to the CIB terminated > > と、リソースが正常にfirstサーバからsecondサーバに移動しました。 > この挙動の違いはいったいなんなのでしょうか？；； この手順の場合だと、次の動きになっていると予想します。 1．service network restartによってサービス用NICについていた仮想IPが消えた。 2．firstサーバのIPaddr2がmonitor処理により、上記状態を検知しエラーを起こした。 3．secondサーバにfailoverした。 ちなみにネットワーク故障を再現する場合、私は次の方法を使ってます。 ・LANケーブルを抜く →最適 ・ネットワークスイッチのportを遮断する →スイッチがあるなら遠隔からでもできるし便利。 ・iptablesを使ってパケットを遮断する →お手軽、しかしちゃんとパケットの流れを把握して使わないと想定通り動かないこともある 以上、よろしくお願いします。 > > ご教授よろしくお願い致します。 > > > 2015/02/25 Takehiro Matsushima <takeh****@gmail*****>: >> 北林さん >> >> 松島です、お久しぶりです。 >> 順調でなによりでございます。 >> >> さて、 >>> ②「死活監視用」も「サービス用」のIPを１つにする場合 >> はNICを共有するということになると思います。 >> このNICはスイッチに接続されると思いますので、NIC故障はもちろん、スイッチの故障でもスプリットブレインになります。 >> トラフィックがバーストして死活監視が滞ると、ノード同士の接続が切断されたと判定される可能性もあります。 >> >> IPアドレス単体で見た場合には、大きな問題はないと考えられます。 >> >> >>> ①「死活監視用」のIPと「サービス用」のIPを分ける場合 >> は、NICが1つの場合と複数の場合が考えられます。 >> 前者は、例えば単純にNICに対してIPアドレスを複数設定した場合ですが、これは先の選択肢と同じになります。 >> また、VLANで複数の仮想インタフェイスを定義した場合も同様です。 >> >> 後者の場合、サービス用の系統からノード同士の通信経路は独立させられます。 >> IPMIを備えない機器であってもサービス用・死活監視用いずれか片方のみの故障であればスプリットブレインによる不整合は回避可能となります。 >> しかしながら複数枚のNICを機器に実装しようとすると、PCIeスロット等の空き数やLANケーブルの配線といった制約が出てまいります。 >> 私の会社ではノードあたりNICを8つ搭載したので、LANケーブルの本数、スイッチのポート数、パッチパネルのポート数を大きく消費しています。 >> >> 単純にIPアドレスについてのみ考えると、死活監視系をピアツーピアで構成するならば、両者の間でIPアドレスが一意であればよいので、 >> A系とB系で死活監視系のアドレスを固定できます。 >> したがって、複数のペアを量産する時にはcorosync.confやifcfg-ethXの設定を流用することで作業量を減らせます(Ansibleなどを使えば問題ではないのですが)。 >> >> >> 以上、IPアドレスというよりはNICについてになってしまいましたが、お答えになっておりますでしょうか。 >> 他社様におかれましてはまた違った内容になるのかもしれません。 >> >> ---- >> Takehiro Matsushima >> _______________________________________________ >> 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 > -- ---------------------------------------- METRO SYSTEMS CO., LTD Yusuke Iida Mail: yusk.****@gmail***** ----------------------------------------
Fork