キャンセル
次の結果を表示 
次の代わりに検索 
もしかして: 

ACE: [事例] max-conn 復旧後、traffic を転送しない

ACE: lb-stats の基本的な確認方法(rserver)ACE: lb-stats の基本的な確認方法(sfarm) で lb-stats の確認方法について紹介したので、実際にどのような時に使うのか紹介します。

 

CSCuc84825 ACE drops packets even after recovered from max-conn

 

今回は上記不具合を実際に発生させ、どの部分に問題があるのか詳細な切り分けを行ってみます。

上記 Release-note に記載されている発生条件をまとめると下記になります。

 

- 複数の serverfarm に同一 rserver を assign (設定) する。

- 1 つの serverfarm に traffic を流し、rserver を max-conn 状態にする。

- 別の serverfarm に traffic を流す。(rserver が max-conn 状態なので、この通信は失敗する。 これは期待通りの動作。)

 

- その後、最初の serverfarm の connection を close (切断) する。

- max-conn 状態から解放されるので、2 番目の serverfarm へのアクセスも復旧するはずが復旧しない。

 

- predictor として leastconn を使用。

 

 

 

Lab で簡単に再現できるよう、下記のような設定を行い、traffic を流してみます。

port#80 と 81 を web server 用に設定し、port#80 用の serverfarm と port#81 用の serverfarm を作成し、それぞれの rserver を同一のものを使用。

max-conn に達しやすいよう max-conn の値を 2 に設定。

 

今回は下記のような設定を用いています。 (全ての設定は下に添付してあります。)

 

ACE4710a/Admin# show run rserver

Generating configuration....

 

rserver host s1

  ip address 192.168.78.41

  conn-limit max 2 min 2

  inservice

rserver host s2

  ip address 192.168.78.42

  conn-limit max 2 min 2

  inservice

 

 

ACE4710a/Admin# show run serverfarm sf_http

Generating configuration....

 

serverfarm host sf_http

  predictor leastconns

  rserver s1 80

    inservice

  rserver s2 80

    inservice

 

ACE4710a/Admin# show run serverfarm sf_http81

Generating configuration....

 

serverfarm host sf_http81

  predictor leastconns

rserver s1 81

    inservice

rserver s2 81

    inservice

 

 

設定通り動くことを確認した後、lb-stats で rserver や serverfarm の情報を確認してみます。

今回は、各 serverfarm に設定された rserver の情報を個別に確認するため、show np 1 lb-stats sfarm-real を使用しています。

 

log を全て貼り付けると長くなるので、以下の状態の log を添付しました。

それぞれの log を比較し、問題個所を探してみてください。

 

lb-stats_01.txt - traffic 送信前

lb-stats_02.txt - port#80 に対して 4 connection 張った直後 (rserver s1, s2 共に max-conn 状態)

 

lb-stats_03.txt - port#81 に対して 1 connection 張ろうとし、接続に失敗した後 (max-conn 状態なので期待通り)

lb-stats_04.txt - port#80 に対して張っている 4 connection 全てを切断した後

lb-stats_05.txt - port#81 に対して 1 connection 張ろうとし、接続に失敗した後 (CSCuc84825 発生中)

 

 

以下、変化している部分のみを抜き出して説明します。

読み進める前に、添付の log を比較してください。 diff ツールを使用すれば、簡単に差分が見つかると思います。

 

lb-stats_01.txt と lb-stats_02.txt を比較すると、

sfarm sf_http の Weight | RSId が消えています。 これは、rserver が両方とも max-conn に達しているためです。

rserver s1 port 80 と rserver s2 port 80 の Real State が 0 から 2 になっています。 これも max-conn に達しているためです。

 

lb-stats_02.txt と lb-stats_03.txt を比較すると、

今度は sfarm sf_http81 の Weight | RSId が消えています。 これは、rserver が両方とも max-conn に達しているためです。

 

lb-stats_03.txt と lb-stats_04.txt を比較すると、

 

sfarm sf_http の Weight | RSId が表示されました。 これは、rserver が max-conn から復旧したためです。

rserver s1 port 80 と rserver s2 port 80 の Real State が 2 から 0 に戻っています。 これも max-conn から復旧したためです。

 

lb-stats_04.txt と lb-stats_05.txt を比較すると、

Total Conn Drop Cnt が増加しているだけです。

 

....!

sfarm sf_http81 の Weight | RSId が消えたままです。

これが原因で sf_http81 のみ通信できない状態になってしまいました。

明らかに ACE の Data Plane 側 (Weight Bucket) の問題ということで、新規不具合登録されました。

 

 

また、Workaround の predictor roundrobin を用いた場合、ACE: lb-stats の基本的な確認方法(sfarm) に記載されているように、

Weight Bucket ではなく、Good List を用いるため問題が発生しません。

 

 

今回の例では port#80, 81 となる http 通信で動作を確認していますが、port# を同じにした場合も同様の結果となります。

上記設定の http/https は同じ port#80 を使用する通信になっているので、興味のある人は、同じ port# を使用する場合も同様の結果になることを確認してみてください。

 

 

1 回の log 出力のみでは、その出力が重要かどうか判断できない場合が多いですが、今回のようにそれぞれの状態における log を取得することで log のどこが変化したかや、どのような状態になっているべきかが比較/推測できるのでトラブルシューティング時には log を複数回取得するようにしてください。

バージョン履歴
改訂番号
1/1
最終更新:
‎03-22-2013 02:34 AM
更新者:
 
添付