NICの冗長化設定
障害に備えてNICを冗長化するのは一般的な手法ですが、方法は各種あります。
種類の紹介は省略しますが、右のおすすめ本にある「サーバ／インフラを支える技術」
が非常に参考になります。
冗長化の名称はbond、ボンディング、チーミング、いろいろな呼び方があります。
今回はその中でも802.3ad利用の場合についてのトラブル事例を。
openfilerのNICを冗長化と帯域幅の拡大を目的として802.3adという方法でbondを構成しています。
この方法は、スイッチ側が対応していなければ利用できないのですがスイッチと連携して
冗長化と帯域幅の拡大を自動的におこなってくれたりするプロトコルです。
他のbond設定では2本のうち1本は待機のため無通信だったり、通信に制限があったりします。
紹介した本にも書いてあるのですが、一番トラブルが少ないのは1本を完全に待機状態
で保持するアクティブ-バックアップ方式だと思います。
アクティブのNICに障害が生じた場合にのみバックアップのNICが起動します。
通常のトラフィックであれば問題ないのですが、openfilerのようにストレージ用
としては、やはり帯域を考えて２本同時に利用したくなります。
前回実験した限りでは802.3adにしても送信と受信でNICを使い分けているだけで
瞬間最大帯域はまったく大きくならなかったのですがそのまま利用していました。
トラブルというのは、仮想マシンの反応が非常に遅くなりESXを再起動したのですが
ストレージが安定しません。つながったり、固まったりを繰り返します。
iscsi_trgt: cmnd_skip_pdu(454) 9d360 1e 0 4096 iscsi_trgt: data_out_start(1037) unable to find scsi task 9d361 d5731
こういった感じのエラーがたくさん表示されます。
原因は、スイッチの設定が消えてしまって802.3adが正常動作していない事でした。
起動後に再設定をおこなったのですが、起動中なので正常に認識しません。
再起動しようにも中途半端に固まるので操作もままならない状態です。
なんとか、マルチパスを利用してbondを組んでいないパスに優先変更できて
ようやくストレージが安定しました。
今回のトラブルで、802.3adの問題点として
- 障害がおこるとうまく他のパスに切り替わらない場合がある
- さらに完全に機能停止しないので被害が拡大する
- 安いスイッチでは逆に信頼性が落ちる
- 再設定をするには物理的にLANケーブルを抜く必要があるので遠隔操作できない
これらは802.3ad自体の問題ではないと思います。実装と環境の問題です。
結果として安いスイッチを利用しているとダメということですが
もっと高いスイッチなら解消するものでしょうか？さわったことすらありませんが。
ちなみに安いと言っても10万以上するDELLのスイッチで PowerConnect 6248 というL3スイッチと PowerConnect 5424 というL2スイッチです。
＃中身はCiscoのOEMだと言われていますが詳細は不明です。
これがくせ者でWEB画面で設定をするだけでフリーズしてしまったり、冗長化のために
スタック構成を組んでいるのに両方ともフリーズしたり・・・
スイッチが高機能化することで逆に信頼性が落ちてきている感じです。
安定動作をしている間は問題ないのですが、機器の増設に伴う設定の変更を
しようとするとトラブルが発生する場合があるので困ります。
ルータはYAMAHA製のRTX1100とRTX1200を利用しているのですが、これらは
どんな無茶な設定をおこなってもフリーズしたことはありません。
音楽を聴きながらVPNの経路を無理矢理切り替えたことがあるのですがまったく途切れませんでした。
今回のトラブルから冗長化の構成を根本から見直す必要がありそうです。
前の記事にも書いたようにvSphere4ではマルチパスが改善されていますので
bondに頼らずにマルチパスだけで構成するのもよいかもしれません。
また、ベターな構成ができあがったらメモ書き記事でも書こうかと思います。
