いますぐ実践! Linuxシステム管理

[バックナンバーのトップへ] [Linux システム管理のトップへ]


いますぐ実践! Linux システム管理 / Vol.161 / 読者数:1309名

こんばんは、うすだです。

世の中にはさまざまな転職サイトがありますが、どの転職サイトも、大抵は、 適正年収を計算してくれるサービスを提供しています。

たいしてあてにならんだろうと、常日頃から思っていたのですが、先日、 魔がさしたのでしょうか、某サイトで適正年収を試算してもらいました。

ネット上で、自分のプロフィールを入力後、5分くらい質問に答えていると、 あっという間に適正年収を算出してくれました。

で、気になる結果ですが…

「あなたの適正年収は 400万円です」

という冷たい文面が、ブラウザに出力されました…。

…たしかに、突出してすごい技術を持っているとか、 若くしてたくさんの部下を従えているとか、そんなことはまったくありません。 でもしかし、そこそこは技術を持っていると思いますし、 組込み系はそれなりに需要があると思いますし…。
(ええ、まあ、つまり、技術ばっかりじゃダメってことですね。)

そういえば、数年前にも試算してもらって、ヘコんだような気がします。
いまから数年後、きれいさっぱり忘れたころにまた試して落ち込むのかと思うと、 さらにドヨーンとした気持ちになりました。

転職を考えているひとに対して逆効果では? という余計なお節介は置いておきまして、 今回もはりきってまいりたいと思います。

今回のお題 - bonding でフォールトトレラントなNICにする

前回は、bonding というものを使って、 複数の NIC を束ねて 1つの NIC として使用する方法を、ご紹介しました。

Vol.160 - bonding で複数のNICをまとめて使う
http://www.usupi.org/sysad/160.html

しかし、サーバたるもの、速ければいいってものでもありません。
いくら速くても、なんらかのトラブルですぐに通信できなくなってしまいますと、 困ってしまいますよね。
コストや手間などにもよりますが、できることなら、 ちょっとくらいではヘコたれないモノであって欲しいと思います。

そこで今回は、またしても bonding を使って、 ある NIC が通信できなくなっても通信しつづけるようにする方法を、ご紹介します。


bonding にはいくつかモードがありましたが(前回を参照してください)、 その中に、active-backup というモードがあります。
(すみません、前回は、なぜか active-nr と書いていました。(修正済です))

active-backup を使いますと、 普段は1つのNICだけを(アクティブなNICとして)使用しますが、 そのNICのリンクがなくなりますと、待機している他のNICをアクティブに切替えます。

 

なにはともあれ実践、というわけで、まずは設定からやってみましょう。
手動で行う場合でも、modprobe.conf などに記述する場合でも、 mode= で指定するモードに、active-backup を指定します。

modprobe コマンドを実行する際の例を、以下に示します。

  # modprobe bonding mode=active-backup miimon=1000

miimon には、MII を監視する間隔を、ミリ秒で指定します。
そして、前回に書いた通りの手順で、セットアップを行ってください。

ちなみに、modprobe.conf などを書き換えて試す場合は、 書き換えた後に再起動を行ってください。

 

設定が済みますと、/proc/net/bonding/bond0 が以下のようになると思います。 (NIC が 2つ(eth0, eth1) の場合の例です。)

  $ cat /proc/net/bonding/bond0
  Ethernet Channel Bonding Driver: v3.0.3 (March 23, 2006)

  Bonding Mode: fault-tolerance (active-backup)
  Primary Slave: None
  Currently Active Slave: eth0
  MII Status: up
  MII Polling Interval (ms): 1000
  Up Delay (ms): 0
  Down Delay (ms): 0

  Slave Interface: eth0
  MII Status: up
  Link Failure Count: 0
  Permanent HW addr: 01:23:45:67:89:ab

  Slave Interface: eth1
  MII Status: up
  Link Failure Count: 0
  Permanent HW addr: 00:11:22:33:44:55

Bonding Mode が active-backup になっています。(当り前ですね…)
そして、Currently Active Slave が eth0 ですので、 アクティブな NIC が eth0 になっていることがわかります。


active-backup の設定が終わりましたので、いろいろ試してみましょう。

まず、eth0 側のケーブルを引っこ抜いてみましょう。
すると、miimon で指定した時間が経過後、eth0 のリンクがないのを検知して、 eth1 に切り替わる…と思います。

  # cat /proc/net/bonding/bond0
  ...
  Currently Active Slave: eth1
  ...
  Slave Interface: eth0
  MII Status: down
  Link Failure Count: 1
  Permanent HW addr: 01:23:45:67:89:ab
  ...

eth0 のリンクがないことを検知し、 アクティブを eth1 に切替えていることがわかります。
実際に、ping などでネットワークの動作を確認しておいてください。

さて、お次は、eth0 にケーブルを再接続しましょう。
すると、eth0 のリンクアップを検知するはずです。

  # cat /proc/net/bonding/bond0
  ...
  Currently Active Slave: eth1
  ...
  Slave Interface: eth0
  MII Status: up
  Link Failure Count: 1
  Permanent HW addr: 01:23:45:67:89:ab
  ...

はい、eth0 のリンクは検知していますね。
ただ、アクティブなNICは eth1 のままです。
で、今度は、eth1 側のケーブルを引っこ抜きますと、 eth0 に切り替わりネットワークは引き続き動作しつづけます。

  # cat /proc/net/bonding/bond0
  ...
  Currently Active Slave: eth0
  ...
  Slave Interface: eth1
  MII Status: down
  Link Failure Count: 1
  Permanent HW addr: 00:11:22:33:44:55

ちなみに、たとえば、eth0 のリンクが復活したら、 eth0 をアクティブにしたくなることもあると思います。
そんなときは、ifenslave コマンドで切替えることができます。

  # ifenslave -c bond0 eth0

-c オプション(もしくは --change-active オプション)で、 アクティブな NIC を設定することができます。


ところで、MII によるリンクの監視が可能かどうかは、 NIC(のドライバ)が対応しているかどうかによります。
それを確認するには、mii-tool コマンドを使用します。

  # mii-tool eth0
  eth0: negotiated 100baseTx-FD flow-control, link ok

インターフェース名を指定して、link ok などと言われれば、 そのNICは対応しています。
ですが、

  # mii-tool eth1
  SIOCGMIIPHY on 'eth1' failed: Operation not supported

このように、エラーになる場合は、対応していません。

では、そんなNICは bonding に使用できないかといいますと、そんなことはなく、 別の方法がちゃんとあります。

それは、定期的にARPリクエストを送信して、レスポンスが返ってくるかどうかで、 そのNICのリンクの有無を判断する、という方法です。

具体的には、bonding のロードの際、miimon の代わりに、 arp_interval と arp_ip_target を指定します。

  # modprobe bonding arp_interval=2000 arp_ip_target=192.168.1.1

arp_interval には、ARPリクエストの送出間隔を、ミリ秒で指定します。
arp_ip_target には、ARPリクエストを送信する相手を指定します。
複数指定することも可能で、その場合は , で区切ります。
複数指定した場合は、 指定したマシンのうちいずれかからのレスポンスがあればよいようです。

あとは、実際にケーブルを抜くなどして、リンクの有無の検知を確認してくださいませ。


おっとそれから、とある疑問が頭をよぎりました。

それは、今までの balance-rr などのモードを使用していて、 あるNICのリンクがなくなったときにどうなるのか、という疑問です。

はい、結論から申し上げますと、おおかたの予想通り、 リンクのあるNIC だけで動作しつづけます。

というわけで、active-backup 以外のモードでも、 フォールトトレラントな動作をしてくれます。
ですので、普段からNICをフル活用して速度も追い求めたい、という貴兄には、 balance-rr などのモードを引き続き使用していただければと思います。


以上、bonding を使用した、フォールトトレラントなNICの実現方法を、 ご紹介しました。

結局、いままでのモードでも、リンクのないNICを使わずに動作しつづけますので、 今回ご紹介した active-backup のもろもろは、やってみた、 という程度の内容でしかないかもしれません。

…いやいや、ですが、やはり、実践することが大事なのです。
ですので、結果がわかっていても、ぜひ、自ら体験して、 それを脳ミソに刻み込んで、自分のモノにしていただければと思います。

宿題の答え

前回の宿題は、

  bonding により受信速度が向上するかどうか、確かめてみましょう。

でした。

前回同様、速度は wget コマンドで計測します。
また、WWWサーバ側(送信側)も、wget コマンドを実行する側(受信側)も、 bonding を用いて、100BASE-TX の2つの NIC を束ねて使用しています。

[wget による受信速度]
  1つだけ実行:     19.37 MB/sec
  2つ同時に実行:   10.76 MB/sec, 9.61 MB/sec

ちなみに、wget コマンドを実行している間に受信した、パケットとそのバイト数は、 以下の通りです。
(wget コマンドの前後で ifconfig コマンドを実行し、差を計算しただけですので、 厳密な値ではありません。以降も同様です。)

[受信側の受信パケット数とバイト数]
  eth0: 74,156 packets, 112,143,440 bytes
  eth1: 74,155 packets, 112,252,198 bytes

というわけで、かなり均等に受信していることがわかります。

ここからは私の憶測です。
bonding を使用しているマシンは、複数のインターフェースから、 送信元の MAC アドレスが同じパケットを送出しています。
スイッチングHUBは、その度に学習して、 その MAC アドレスが接続されているインターフェースを(頻繁に)切替えるため、 受信もうまく分散されているのではないか、と思われます。
以上、私の憶測でした。

ちなみに、送信側が 100BASE-TX の NIC 1つだけの場合の受信速度の計測結果は、 以下の通りです。

[wget による受信速度]
  1つだけ実行:     11.22 MB/sec
  2つ同時に実行:    5.71 MB/sec, 5.77 MB/sec

[受信側の受信パケット数とバイト数]
  eth0: 85,901 packets, 130,044,856 bytes
  eth1: 56,974 packets,  86,254,586 bytes

さきほどの結果よりも半分強くらいの速度だと思いますので、 bonding による速度の向上は、結構効果があるように思います。

さらにちなみに、送信側が 100BASE-TX の NIC 1つだけで、 2台の場合の受信速度の計測結果を、以下に示します。

[wget による受信速度]
  それぞれに1つ実行: 10.78 MB/sec, 6.73 MB/sec

[受信側の受信パケット数とバイト数]
  eth0: 87,611 packets, 132,602,152 bytes
  eth1: 59,955 packets,  90,747,584 bytes

最初の結果より少し劣るのが気になりますが、 おそらく偏りが生じたことによるものだと思います。(たまたまだと思います。たぶん。)

今回の宿題

今回の宿題は、

  リンクの状態を監視して、変化があったらメールで通知しましょう。

です。

bonding でうまいこと運用できたとしても、NIC が壊れたり、 ケーブルが抜けていることに気づかないまま、というのはよろしくないですよね。
(なんだかいつものパターンですが、大事なことだと思いますよ。)

定期的に監視して、変化があったらメールで通知するよう、仕込んでみてくださいませ。

あとがき

あとがきでは、みなさまのお役に立つことを書かねば、と常に思っているのですが、 今回は、ちょっと余裕がありません。

というのも、今朝起きてから、左肩が痛いのです。
前日何かをした、というわけでもありませんので、寝ている間、 無意識になにかをやらかしたのではないかと思います。

で、起きたときはそれほどでもなかったのですが、時間の経過とともに、 痛みのボルテージがじわじわと上がってきまして、すみません、 連休明け大丈夫だろうかとか、もうそんなことしか考えられません。

とはいえ、考えているだけでは埓があきません。
ですので、いろいろ検索してみたところ、非外傷性の場合、 中年以上だと肩関節周囲炎(いわゆる50肩)、 中年未満だと上腕二頭筋長頭炎(使いすぎによる炎症)の疑いがある、 と書かれているサイトがありました。

…わたくし、39歳なんですが、やっぱり「中年」なんでしょうか。
冒頭に引き続き、なにかを突き付けられたような気分です。

まあ、連休明けに改善していなかったら、潔く病院へ行こうと思います。
みなさまも、お身体には、十分お気をつけください。

 

今回も、ここまで読んでいただき、誠にありがとうございました。
次回は、8月2日(日) 未明にお会いしましょう!

 

「いますぐ実践! Linux システム管理」の解除は、以下からできます。
http://www.usupi.org/sysad/ (まぐまぐ ID:149633)

バックナンバーは、こちらにほぼ全部そろっています。
http://www.usupi.org/sysad/backno.html

「栗日記」 - 連休があるとアクセス数が…。いやがんばって描きます。
http://www.usupi.org/kuri/ (まぐまぐ ID:126454)
http://usupi.seesaa.net/ (栗日記ブログ)
http://usupi.org/k/ (モバイル栗日記)


[バックナンバーのトップへ] [Linux システム管理のトップへ]

トップ

バックナンバー
    [日付順] [目的別]

プロフィール

▼ リンク

独学Linux
Linuxデスクトップ環境に関する情報が満載です。 メルマガもありますよ。
Server World
CentOS 6をサーバとしたときの設定例が、これでもかというくらいたくさん載っています。 CentOS以外のディストリビューション(Fedora, Ubuntu)も充実しています。
LINUXで自宅サーバーを構築・導入(Fedora9)
Fedora9のインストールの仕方から管理方法まで、詳しく載っています。 SearchManには情報がもりだくさんです。
マロンくん.NET
〜サーバ管理者への道〜
Linuxをサーバとして使用するための、いろいろな設定方法が載っています。 マロンくんもかわいいです。 なんといっても、マロンくんという名前がいいですね!!
日経Linux
今や数少なくなってしまったLinuxの雑誌。ニュースやガイドもあります。
Linux Square − @IT
@ITが提供する、Linux の情報が満載。 載っていない設定方法はないんじゃないでしょうか。
gihyo.jp…技術評論社
Linuxに限らず様々な技術情報が満載のサイト。 SoftwareDesign誌も、 ソフトウェア技術者は必見です。
SourceForge.JP Magazine
Linux に限らず、オープンソース関連の記事が網羅されています。
ITmediaエンタープライズ:Linux Tips 一覧
Tips というより FAQ 集でしょうか。わからないことがあれば覗きましょう。
IBM developerWorks : Linux
開発者向けですが、勉強になりますよ。
Yahoo!ニュース - Linux
Yahoo!のLinuxに関するニュース一覧です。
栗日記
システム管理とかと全然関係ありませんが、毎日栗の絵を描いています。
システム管理につかれちゃったとき、癒されたいときに、ご覧ください。:-)
WEB RANKING - PC関連
ランキングに参加してみました。押してやってください。

▼ 作ってみました

Add to Google

▼ せんでん




▼ 最近読んだ本

▼ 気に入ってる本