読者です 読者をやめる 読者になる 読者になる

CA MOBILE エンジニアブログ

株式会社シーエー・モバイルのエンジニアブログです

【旧ブログ】BIG-IPソフトウェアバグ×OneConnect×Apache化

NetWork

BIG-IP(OS10.0.1)のソフトウェアバグに巻き込まれたよ

今回のネタはBIG-IPのソフトウェアバグに巻き込まれた時のお話。

先日、弊社にて導入していたBIG-IP(OS:10.0.1 Active-Standby構成)が気がついたらAct-Staが勝手に入れ替わっている事象が発生。

旧Act機の/var/log/tmm見たら下記の様なログが。。

XXX  X 02:11:23 local/XXX notice panic: ../net/nexthop.c:138: Assertion "nexthop ref valid" failed.

こんどは旧Act機の/var/log/ltm見たら下記の様なログが。。

XXX  X 02:11:23 local/XXX notice sod[1937]: 01140029:5: HA daemon_heartbeat tmm fails action is go offline down links and restart.

ふむ。 さっそく調査。

いろいろ調べたらどうもOSが悪さしてるっぽい。

本内容を元にベンダに確認取ったらやっぱりバグとして報告が上がってました。

【SOL11854】 TMM dumps core with an 'Assertion "nexthop ref valid" failed' message when the nexthop reference counter wraps  http://support.f5.com/kb/en-us/solutions/public/11000/800/sol11854.html

何でもBIG-IPでトラフィックを処理・管理するためのプロセス(tmm)がクラッシュしてしまうというソフトウェアの不具合らしいです。 そしてtmmプロセスのクラッシュにより、BIG-IP内で異常が発生したと検出され、勝手にActive-standbyが切り替わったらしいです。

対策としてはOSのアップグレード(10.1.0以降へ)しかないらしい。。 そんなワケでリスクを洗い出しアップグレード準備。

当時でたばかりのメジャーバージョン(11系)まで上げるか迷いましたが、世間的に導入実績に乏しかったため今回は10.0.1から10.2.3まで上げるコトに。

下記手順です。

0.ライセンスのRe-Activate実施
 (0-1)GUIでSystem > License > Re-Activateと押下。
 (0-2)Activation Method 欄で"manual"を選択してNext押下。
 (0-3)Dossier に表示された文字列をメモ帳とかにコピー。
 (0-4)並行してブラウザでhttps://activate.f5.com/license/にアクセス
 (0-5)”Enter your dossier ”欄に(0-3)の文字列を入力しNext押下。
 (0-6)表示されるLicense File をダウンロード
 (0-7)License File (0-3)のLicense欄に参照させてNext押下。
 (0-8)エラー等発生していない事を確認してからBIG-IPリブート

1.イメージファイルの準備?アップグレード実施
 (1-1)BIGIP-10.2.3.112.0.isoを落としてきて実機の/shared/imagesにコピー。
 ※ちなみに10.0.1からアップグレードする場合はCLIからしか出来ない罠。
 (1-2)下記コマンドを実行

# im /shared/images/BIGIP-10.2.3.112.0.iso

 (1-3)下記コマンドを実行

# image2disk --format=volumes /shared/images/BIGIP-10.2.3.112.0.iso

 (1-4)インストール完了後勝手にリブート

2.インストール後確認作業
 (2-1)下記コマンドを実行。versionが10.2.3になっている事を確認。

# b version
Kernel:
Linux 2.6.18-164.11.1.el5.1.0.f5app
Package:
BIG-IP Version 10.2.3 112.0
Final Edition

 (2-2)その他設定を確認。不明な差異やエラーが出ていないことを確認。

ちなみに10.0から10.2へ上げる場合、仕様変更のため下記項目に注意すること!

●HTTP及びHTTPS MonitorのSend String設定について
 自動でCR/LF文字を追加しない仕様に変更になったお陰で10.2.0以前でSend String設定にて手動で二重にCR/LF文字を設定していない場合、10.2.0以降へバージョンアップを行うとMonitorがDown判定となります。

 ・v10.1.0 以前の HTTP Monitor 設定例

 -------------------------------------------
 monitor http_test {
 defaults from http
 recv "bigip"
 send "GET /index.html HTTP/1.0"
 }
 -------------------------------------------

 ・v10.2.0 の HTTP Monitor 設定例

 -------------------------------------------
 monitor http_test {
 defaults from http
 recv "bigip"
 send "GET /index.html HTTP/1.0\r\n\r\n" <== ★
 }
 -------------------------------------------

※バージョンアップ後は★のようにSend StringにCR/LF文字を手動で二重に追加してください。

●負荷分散方式を"Fastest"モードに設定している場合
 通常だとL7レベルのProfile(例:HTTP Profile)が適用されていない場合は理論上は"Least Connection"モードとして動作するのですが、10.1.0以降"Fastest"モードの仕様変更の影響によりL7レベルのProfileが適用されていない場合"Least Connection"モードとして動作せず分散先が偏る事象が発生します。

 ベンダからの仕様にも記載ありましたね。
  【SOL6406】 Overview of Least Connections, Fastest, Observed, and Predictive load balancing modes   http://support.f5.com/kb/en-us/solutions/public/6000/400/sol6406.html


ひとまずこれで完了しましたが、BIG-IPって頻繁にHot Fix出るのでいつまで経っても安定する気配が無いですね。 さっさとメジャーアップデート(最近だと11.1.0かな)することにします。

BIG-IP OneConnectについて

今回はBIG-IPのProfileの一つであるOneConnect設定の事例紹介を。

我がインフラグループには各部署のシステム開発担当者から日々依頼や相談が舞い込んで来るのですが、先日、ある担当者からこんな問い合わせを受けました。

複数の他キャリア端末(例:docomoau)から同時にアクセスした所ユーザーエージェントにはしっかりとdocomoau両方表示されているが、リアルサーバ(apache)のログには全てdocomoのIP帯域からアクセスが来てる」

ふむ。

対象のwebサーバはBIG-IP配下という事でVirtual Servers設定周りを確認してみる事に。 よくよく調査し、下記の設定が怪しいと判断。

"OneConnect Profile"

OneConnectはBIG-IPのProfileの一つで、複数のクライアントコネクションを同時に集約し負荷低減に効果のある機能です。

ただ、デフォルトのOneConnect profileでは、全てのクライアント(Source Mask が0.0.0.0のため)からのリクエストを同一のコネクションに纏めてしまう為、場合によってはクライアントIPアドレスが一つしか見えない現象が起き、ロギングで問題が発生する事例もあるとの事。

今回の事象は正にこれが原因でした。

Source Maskを255.255.255.0に設定したProfileを作成して該当のVirtual Serversへ反映させてやると。

無事、解決。

BIG-IPをApache化してみたよ

今回のテーマは、「BIG-IPってApacheのように動くのか?」

具体的には下記のようなコトがやれればいいかなぁ。。と。

・クライアントからのリクエストURLに基づいて複数あるwebサーバの中から特定のサーバに振り分ける。
複数のURL・ポートに対してクライアント側からは1つのURL・ポートであるかのように見せる。

こんな流れになれば良いのかなぁ。。と。

http://www.cam.co.jp  ⇒ http://cam1.co.jp
http://www.cam.co.jp/aa ⇒ http://cam2.co.jp
http://www.cam.co.jp/bb ⇒ http://cam3.co.jp
http://www.cam.co.jp/bbb ⇒ http://cam3.co.jp:1111

ここでのポイントはApacheのモジュールmod_proxy(ProxyPass)をiRuleにて表現してあげるコトです。 これが可能になれば、サーバ側で別々のポートを利用している場合でもクライアント側からは同一ポートでアクセス出来るため分かりやすいですね。

★設定手順

1.Data Groupを作成
◆ポイント
・定義の際は"クライアント側ホストネーム”"サーバ側ホストネーム"の順で記載する。 例:http://www.cam.co.jp http://cam1.co.jp http://www.cam.co.jpへのリクエストがBIG-IPで書き換わり、 http://cam1.co.jpへ振り分けられます。

・Data Group名は反映させたいバーチャルサーバ名にする。 Data Group = ProxyPass【バーチャルサーバ名】

2.iRule作成 下記URLを参考にiRule作成 http://devcentral.f5.com/Wiki/default.aspx/iRules/proxypass.html ※会員用ページのため、閲覧にはID/PWが必要ですが。。。

3.バーチャルサーバにiRuleを適用する。

これでどうだ。

・・・

・・・

うーん。。うまくいかないなぁ。

iRuleをよくよく見直したら、BIG-IPのバージョンによって パラメータを変更する必要があるみたいでして。 (iRule雛形はv9.0 自社にあったBIG-IPはv10.0)

○具体的にはココ set static::RewriteResponsePayload 0  ← 1に修正

これでどうだ

・・・

・・・

OK!こちらの意図どおり動作してくれました。