- PR -

ネットワークに問題があると思うのですが・・・

«前のページへ 1|2
投稿者投稿内容
kaz
ぬし
会議室デビュー日: 2003/11/06
投稿数: 5403
投稿日時: 2006-01-30 20:41
こんばんわ．
引用:

progmanさんの書き込み (2006-01-30 17:00) より:

L2SWで、telnet,pingはOKでアプリケーション通信はNGの状況ってどういうケース
があるでしょう。

いや，L2SW とかではなく，その application そのものに原因があるのでは？
という話があるんじゃないかと．．．
progman
大ベテラン
会議室デビュー日: 2005/06/08
投稿数: 227
投稿日時: 2006-01-31 09:21
>いや，L2SW とかではなく，その application そのものに原因があるのでは？
>という話があるんじゃないかと．．．
まず、アプリケーションを疑うべき材料がありますね
というふうに書いたつもりなんですが、そういうふうにはおもえないかな？

流しのエンジニア
常連さん
会議室デビュー日: 2003/10/17
投稿数: 48
投稿日時: 2006-01-31 10:10
引用:

ぐりりんさんの書き込み (2006-01-29 14:52) より:

もし、2のサーバのNICに異常があって、冗長化しているもうひとつのNICに切り替わろうとしたときに、
Bondingの設定がうまくいかずエラーが出たりはしないのでしょうか？

以下は全て仮定の話です。

仮に、通信経路（NIC, Switch, 配線）に異常があって、切り替わったことが、引き金になったとします。

その場合でも、アプリケーションは、下位層は単にTCP/IPのプロトコルスタックとしてやり取りしているだけでしょうから、特にシステムの状態をモニタリングする機構を組み込んでいない限りは、アプリケーションは状況を検出することはないと思いますし、影響も特に無いと思います。

ただ、切り替わるときは、一時的にネットワークから切り離されたような状態になるかと思うので、多少のタイムアウトは発生する可能性があります。

その時に、アプリケーション側のタイムアウトがシビアであり、タイムアウト発生後のリトライ動作がうまくいかないというような、ネットワークを含めたシステム全体が正常に動作しているときには発現しない症状が現れるかもしれません。

切り替わりが発生していないまでも、トラフィックが高いと発生するなどということもあるかもしれません。

他の稼動中のシステムや検証システムでは発生しないというのは、こういった条件が発生していないから、たまたま見過ごされているだけかもしれません。

なので、「ネットワークに問題がある」というのは言い切れないかと思います。
Wind
ベテラン
会議室デビュー日: 2004/11/10
投稿数: 73
投稿日時: 2006-01-31 10:23
> Bondingする際にはL2スイッチの設定も必要だったと思うのですが、私の勘違いでしょうか？
Linuxは門外漢なのでよく判らないですが、NICの冗長化を行う際、L2側の設定が必要か不必要かは、冗長化の手法によって異なります。

# Linuxカーネルで実現していようとも、ベンダー提供のDriverで実現していようとも
# 最終的な結論は同じかと。

NICの冗長化は3つのモードがあります。

1）フォルトトレーラントモード
いわゆるActive-Passive。通常時はActive側のみで動き、Active側でLinkが落ちると、Passive側がActiveになり、処理を引き継ぎます。
冗長化という観点からは、耐障害性のみを提供。

2）ロードバランスモード（別名：TLBモード）
Active-Activeモードですが、処理は冗長化対象NICの間でローテーションしながら順に処理を行っていきます。
但し、ロードバランスがとられるのは送信時のみで、受信パケットはプライマリNICが受信します。
LinuxのBondingだと、これがDefaultのようです。
冗長化という観点からは、耐障害性と負荷分散を提供。

3）EtherChannelモード（別名：SLBモード）
ロードバランスモードと同じような感じですが、NICが接続されたSwitchと協調して動く為、送信パケット、受信パケットも共にロードバランスされます。
このモードの時のみ、上層のSwitchの設定（CiscoだとFEC）が必要になります。
冗長化という観点からは、耐障害性と負荷分散を提供。

ぐりりんさんのNICの冗長化に対する認識とSIベンダーのNICの冗長化に対する認識が異なる為、冗長化がされているされていないの議論になったんじゃないかと推測。
SIerのNICの冗長化の認識がフォルトトラーラントモードなら、片側のNICで送受信しててもなんら問題ないです。

# 仮想NICがない、って事なら問題外ですけどね。

試しにActive側のNICからケーブルを引き抜いて、もう片側で処理を引き継げば冗長化はなされていると見て問題ないかと。

んで、問題の障害の件ですが、以下の情報がないとNetwork側の問題と判断できません。

# 逆に判断材料がないからApp側の問題では？　といわれるわけで。
# そんなわけで、わたしはApp、Network共に疑ってます。

・Server1とServer2は同じセグメント？
・App側でエラーを吐いた時、Serverの状況はどうだった？　例えばCPU利用率とか。
・PingやTelnetはOKだったという事ですが、その時にAppは不通でした？
・Appが不通になった時の復旧方法は？　単にリブートしてOKですか？
・Appが不通になった時のnetstatの結果は？　他のリソースがPortを食い尽くしてませんでしたか？

正直、Pingは通るけどTelnetはNG、とかの方が楽でしたねぇ。
そういう場合はケーブル交換すると直ったりするので。
«前のページへ 1|2

スキルアップ／キャリアアップ（JOB@IT）