python + dpkt で pcap解析 - 2.パケット生成と保存

前回(python + dpkt -> pcap解析 – 1.読み込みから解析開始まで) に引き続き、dpktの使い方を見ていく。

次はこの辺りか。

  • パケットの生成と保存
  • 読み込んだパケットをフロー分類して別のファイルに保存

既に解析ではないね...うん...

ソース見れば分かる人はBitbucketへどうぞ。

まず「パケット生成と保存」をしてみる。

パケット生成の基本は、 dpktのフロントページ に書いてある通りだ。

今回は、SYN Flood辺りを想定して、SYNパケットを沢山作ってそれをpcapファイルに出力してみる。

ステップは簡単だ。

  • Step.1 : dpkt(とsocket)のimport
  • Step.2 : Ethernet, IPv4, TCPの各ヘッダをオブジェクトとして生成
  • Step.3 : pcap(libpcap)形式でファイルを開く
  • Step.4 : 送信元アドレスを増加させながらpcapファイルに書き込む
# -*- coding: utf-8 …
more…

python + dpkt で pcap解析 - 1.読み込みから解析開始まで

以前から小規模ではあるが、pythonでパケット分析をするためのモジュールdpkt(http://code.google.com/p/dpkt/)を使用している。

元々dokuwikiの方には少しだけ書いているのだが、整理がてらblogにも書いてみる。

まずはこの2つ。

  • *.pcapファイルの読み込み
  • 読み込んだバイナリデータの簡単な解析

ソース見れば分かる人はBitbucketへどうぞ。

windows、Linuxのいずれも使い方は変わらないはずだ。

手元の環境は windows XP/7 + Python 2.7.3 だが、好きにすればいいだろう。

dpkt自体は、

easy_install dpkt

でインストールする方法と、

http://code.google.com/p/dpkt/ からダウンロードしてきて

python setup.py config
python setup.py …
more…

ZFS SATAディスク交換例 – camcontrol使えない編

1TB*5台で構成されているRAIDZの空き容量が不足しているので、全部2TBに交換してオンラインマイグレーションする。

zpoolのオンラインマイグレーションは、

  • zpoolのautoexpandプロパティを使用する
  • zpool online -e を使用する

の2パターンがあるが、FreeBSD 8.2(zpool v15)以前では使用出来ず再起動したので、実際は「オンラインマイグレーションする予定でした。」が正しい。

その一部ログを単に貼り付けるだけですよ、っと。

現在の接続状況

# camcontrol devlist -v
scbus0 on mpt0 bus 0:
<ATA WDC WD10EADS-00L 1A01>        at scbus0 target 0 lun 0 (da0,pass0)
<ATA ST2000DL003-9VT1 CC3C>        at scbus0 target 1 lun …
more…

ZFS SATAディスク交換例 - atacontrol編

1TB*5台で構成されているRAIDZの空き容量が不足しているので、全部2TBに交換してオンラインマイグレーションする。

その一部ログを単に貼り付けるだけですよ、っと。

現在の接続状況

# atacontrol list
ATA channel 0:
    Master:      no device present
    Slave:       no device present
ATA channel 2:
    Master:  ad4  SATA revision 2.x
    Slave:       no device present
ATA channel 3:
    Master:  ad6  SATA revision 2.x
    Slave:       no device present
ATA channel 4:
    Master:  ad8 …
more…

iSCSI BootしていたWindows Server 2008 R2を救えなかった時の話

先日、ストレージサーバのNICを交換した。

契機は、messagesに"kernel: em0: discard frame w/o packet header"が多発していたからだが、それはこの際無視。

そのNICの交換に合わせて、iSCSI Bootしている端末のSingle Port NIC(9400PT)もDual Port NIC(9402PT)に入れ替えた。

そしたらiSCSI BootしていたWindows Server 2008 R2が起動できなくなった。

その復旧を試みたけど諦めたという話。

主にVirtualBoxの話になるよ。

調べてみると、iSCSI Boot用のNICを交換すると起動できなくなるバグがあるらしい。

情報としてはこの辺り。

more…

TX100 S3のその後 2

おおよそ問題が収束したのでサクっと書いておく。

エアフロー問題が浮上してるけど、後で工夫して何とかしようと思う。

1.UEFIの対応問題

BIOSの設定を行うことで回避

2.BIOSのアップデートに関する問題の未解決

疑問は残るが、問題は顕在化していない

3.LSI SASカードの認識不能問題

BR10iを使用することで回避

4.オンボードNICが新しくてドライバが無い問題(OpenIndianaのみ)

2012/02/09 のアップデートでバックポートされたから、普通にpkg update network/e1000gすれば済むようになったっぽい。

http://pkg.openindiana.org/dev/ のドライバでは対応していないが、 http://pkg.openindiana.org/dev-il/ のドライバであれば対応している。

OpenIndiana 151aでの回避方法。

# pkg set-publisher -P -O http://pkg.openindiana.org/dev-il/ openindiana.org …
more…

TX100 S3のその後

写真を撮ったはいいが、その後の進捗は思わしくない。いつものことですが。

前回書いたとおり、ストレージサーバとして仕立て上げる予定。幾つか問題を抱えているので覚書として残しておく。

OSはOpenIndianaがいいのだけど、FreeBSDでもいいかもしれない...などと悩みが増えただけだった。

1.UEFIの対応問題

OpenIndianaはインストーラに従うと、デフォルトで GPT + ZFS。

FreeBSDはインストーラに従うと、デフォルトで GPT + UFS。

GPTを認識出来ないとブートシーケンスでコケる。

TX100 S3の初期設定では、UEFIがdisableになっていたので、これを有効にする必要がありそう。

ご使用上の留意・注意事項には「UEFIモードでのOSインストールに失敗する場合があります」と書かれているのは一体...?

http://jp.fujitsu.com/platform/server/primergy/manual/manual-tx100s3-201110.html

設定出来ないらしいのだが、GPTを使う以上それは無理というものなので、とりあえずBIOSでUEFIをenableにして、数回の停止/起動が正常に実施可能なことを確認し、OpenIndiana/FreeBSDの両名でひとまず安定したものと見なした。

2.BIOSのアップデートに関する問題の未解決

先の問題に先駆けて、BIOSのアップデートによって状況が改善されることを盲目に期待して、11 …

more…

TX100 S3がキタヨー

富士通から絶賛発売中の静音PCサーバ PRIMERGY TX100 S3が到着した。

http://primeserver.fujitsu.com/primergy/products/lineup/tx100s3/

軽く中身を見ていく。

(しかし、注文から2週間もかかるなんて...売れてるのか他が忙しいのか...)

今回は、OSレスの最小構成になっているはず。

  • ベースユニット: PYT103T3E タワーベースユニット(250W電源(0-Watt function) 1)
  • CPU: PYBCP10CD Celeron プロセッサー G530(2.40GHz / 2コア / 2MB)
  • メモリ: PYBME02UA 2GB(1333 UDIMM1)

以下写真ぺたぺた。

とりあえず外観。表と裏。

image0

image1

付属品など。

image2

開帳。

image3

緑色のHDDレールみたいなのが付いている部分が、3.5inchシャドウベイ、という扱いなのだろう。

ケーブルの取り回しが予め想定された程度に固定されている。

付属のSATAケーブル …

more…

ZFS Benchmark - RAID10編

構成ディスク台数の増加に伴うZFS性能変動をfioを用いて測定する。

前略raid10編。 測定環境は ZFS Benchmark – 環境構成編(http://www.ainoniwa.net/ssp/?p=224) を参照。

OpenIndianaは元気に伸びた。FreeBSDは若干伸び悩んでるよう。

こう見ると逆に2台構成のミラー測定値に疑問が出るのだが、まぁ順当に伸びるということで。

FreeBSDはやっぱりOpenIndianaに水を開けられている。

予想外にFreeBSDの方が性能の伸びが良い。当てにはならないけどCPU使用率も速度に対して低く見える。

逆にOpenIndianaは6台構成(ミラー*3ストライプ)の方がRandom時は安定するか。

Random Readに関しては差が小さい、および台数による性能変動がほとんどないことは分かってる。

I/O Blockingの観点から言うとレイテンシに全て持っていかれているということなんだろうかね。

少しずつ性能向上してる。OpenIndiana/FreeBSD双方で同様の傾向と測定値。

台数を増やしたほうが若干良い値。

性能差で言えばOpenIndianaの方がいいが、これがどれだけの体感差を生むか予測できてない。

総評

  • RAID10は安定して全体的な性能向上と耐障害性を得られるように感じる。(後でRAIDZ2と比較した方がいいかもしれない)
  • RAIDZ/Z2/Z3に見られた部分的に性能が落ち込みすぎることも少なそうなので、安定的に性能向上が見込めるように見える(若干そう言いがたい部分もあるが)。
  • FreeBSDとの対比では語りにくいが、4KiB Read/Writeの結果は実運用におけるRAIDZ/Mirror …
more…

ZFS Benchmark - RAIDZ3編

構成ディスク台数の増加に伴うZFS性能変動をfioを用いて測定する。

前略raidz3編。 測定環境は ZFS Benchmark – 環境構成編(http://www.ainoniwa.net/ssp/?p=224) を参照。

RAIDZ3でも相変わらずOpenIndianaは綺麗にスケールする。

FreeBSDは少し8台目でもたついてるけど、7台構成ならほぼ同等じゃないかな。

OpenIndianaの方がガタつきが激しい稀有な例。

どちらも、5台構成時にほぼピークが来てしまっているのは一体何なんでしょう。

例えば9台構成の時に再度大きく性能向上するのであれば、データディスク本数を3+(2+4n)にしたほうがいいのかなー、とか妄想出来る。

これまた明確に異なる特性が見える。

OpenIndianaの8台構成は追試した方がいいかもしれないが、それ以外の性能差は小さい気がする。

6台構成が良いのは両者共通。
WriteとReadでかなり本数別特性が異なるように見受けられるなぁ。

まぁ、大体一緒。

まぁ、大体一緒。

総評

  • 構成本数によって大きく差が出る部分が見られた。
  • 特性からすると、OpenIndianaでは7本、FreeBSDでは8本で組むといいのかもしれない。
more…