ケースの背景
1.故障の説明
-オペレーターのBOSSシステムがサーバーにオーダーを送信すると、1日に約600件のオーダーが失敗し、失敗したオーダーは手作業で入力する必要があり、作業効率に大きく影響します；
-パケットロスなしでサーバーとボスに継続的にpingを送信；
-アプリ部門とアプリベンダーはアプリとルールをチェックし、すべて問題ないと言っています；
-ネットワーク管理者は、ネットワーク機器の性能をチェックし、すべてが正しく設定されていることを確認します；
-ボスシステムで同期パケットを取得したマネージャが、PIXで取得したパケットよりも大きいパケットロスを疑いますが、他のすべてのアプリケーションとpingは正常であり、ネットワークパケットロスを確信することはできません。
2.ネットワークトポロジー
図1 ネットワーク・トポロジー
ケーススタディ
オーダー投入に失敗するケースは、ボスからのリクエストをサーバが受信しない場合と、リクエストを受信してもサーバが応答しない場合があり、ユーザからボスとピクスのパケットキャプチャに矛盾があるとの報告があったため、ボスとピクスのパケットキャプチャを選択。
バックトラックシステムとポータブルのパケットを別々に抽出し、比較のために分析しました。
6503では、10.238.230.50および10.238.103.86で複数のsynパケット非応答セッションがキャプチャされたため、注文の取り下げに失敗した問題が実際に存在することが確認されました。一方、PIXポータルではセッションがキャプチャされなかったため、サーバー側はボスからの申請要求を受信しておらず、この現象はサーバー側とは関係ありません。
図2のように：
図2 ボス側のTCPセッション
PIXの前に取得したデータをもう一度見てください：
図3 pix側TCPセッション
サーバーがボスシステムからのリクエストパケットを受信していないのは、パケットがドロップされているからですか？トポロジーから、データはルーティングとスイッチングデバイスを通過し、パケットはファイアウォールに到達せず、リンク上の他のすべてのアプリケーションは正常であり、ネットワークはパケットをドロップする説得力がありません。
さらに分析を進めると、4,452パケットのうち、FINタグを持つパケットが2,498個と、ネットワーク内に多数のFINパケットが存在することが判明。
FINパケットをフィルタリングした結果、FINパケットのほとんどがボスサーバーから送信されていることがわかりました。
TCPセッションを見つけ、タイミングダイアグラムでセッションのFINパケットをチェックすると、1つのセッションに複数のFIN位置1のパケットがあり、反対側からの確認応答がないことがわかります。
FIN+ACKが1に設定され、ウィンドウが0に設定されたパケットが1つのセッションで大量に送信されるケースがネットワークに多数あり、これらのセッションは10.238.230.50に関連しています。つまり、10.238.230.50には閉じられていないTCPセッションが多数存在することになり、これは正常ではないため、さらに原因を分析する必要があります。
簡単に説明すると、通信中のクライアントとサーバー間のTCP状態の移行は以下のようになります：
-クライアントTCP状態の移行：
-
サーバーTCP状態の移行：
closed->listen->syn
-received->ESTABLISHED->CLOSE_WAIT->LAST_ACK->CLOSED10.238.230.50のバックエンドにログインし、netstatでホストのセッション状態をチェック。
10.238.230.50には、colse_waitのステータスを持つ約5000の接続があります。 colse_waitのセッションは、接続がまだFIN+ACKパケットを送信していないことを意味します。通常、colse_waitは少なくとも2時間維持され、システムが新しい接続要求を処理するためのリソースを使い果たすまで、時間の経過とともに解放されないセッションが増えていきます。
結論の分析
10.238.230.50には、解放されていないTCPコネクションがたくさんあります。TCPにはキュー制限があり、キューがいっぱいになると、TCPは着信SYNを処理せず、RSTアンサーを送信しません。キューがいっぱいになった原因は、アプリケーションとOSがビジー状態になっているためです。実際には、これらのパケットはボスシステムが営業所から受信したSYNパケットですが、ボスシステムのキューが一杯かビジー状態であるために処理されていません。
10.238.230.50サーバーとの接続を閉じる過程で、ウィンドウが0になります。これは、システムがcolse_waitセッションの処理に忙しく、ボスとサーバー間の通信が異常になることが原因である可能性があります。
注文の送信に失敗する原因は、ボスシステムのキューが満杯またはビジー状態で、接続要求を処理するリソースがないためです。
推奨事項の分析
10.238.230.50と10.254.126.227、10.238.159.90のアプリケーション通信とアプリケーションを確認してください。
tcp_keepalive_*関連のパラメータを変更。
