IDCFクラウドでポートミラーリングしたいときに
IDCF Cloud Advent Calendar 2016 の12/12が埋まってないので個人的に責任（ｗ）をとって埋めておきますね。
突然ですが、ポートミラーリングが必要になるケースってありますよね。
例えば、通信の中身をチェックしなければならないときとか。
もっと具体的に言うと、IDS/IPSで入口対策するときや、振る舞い検知などの出口対策のときです。
このようなセキュリティ用途の機械やサーバーをインライン型で入れると、ここがボトルネックになりかねないので、ポートミラーリング型で入れる。
でも、クラウドだとポートミラーリングってどうやってやるのでしょうか。
オンプレだとL2スイッチなどのネットワーク機器の方でミラーリングできますけど。
と、言うことで、ここではIDCFクラウドでポートミラーリングする際の構成方法を紹介します。
今回想定する、ネットワーク構成は以下です。
追加ネットワーク（192.168.0.0/21）を作成し、そこにwebサーバーが接続されてます。
同じネットワークに、ポートミラーリング型のIDS/IPS（192.168.5.254）を設置します。
そして、標準ネットワーク（10.11.0.0/21）と追加ネットワークに両方接続するかたちで、ロードバランサーやルータ（またはプロキシ）のような仮想マシンを設置します。この仮想マシンの追加ネットワーク側のNIC（192.168.1.1）からIDS/IPSにポートミラーリングするとします。
前置きが長くなりましたが、今時のLinuxであればiptablesで一発です。
構成図のLB/Routerのマシンにて、以下のコマンドを入れます。
iptables -t mangle -A PREROUTING -i eno33557248 -j TEE --gateway 192.168.5.254
ここで、
i eno33557248 はNICのインターフェース名です。eth0的なもの等環境に合わせてください。
gateway 192.168.5.254 はミラーリング先のIPアドレスになります。
一つ補足すると、IDS/IPS等のミラーリング先で、IPアドレスを持たないマシンというケースもままあると思います。この時は、IDS/IPSの該当のNICのMACアドレスを調べ、そのMACアドレスに対して無理やりIPアドレスを指定してしまいましょう。今回のケース（192.168.5.254にミラーリングしたい）だとLB/Routerのマシンにて、以下のコマンドを入れます。
arp -s 192.168.5.254 00:AA:BB:CC:DD:EE
00:AA:BB:CC:DD:EEの部分は、ミラーリング先のMACアドレスを入れます。
ARPテーブルを静的に入れてるだけです。
このように、iptabelsのTEEとARPを組み合わせると、簡単にポートミラーリングが実現できます。
是非お試しください。
ニーズはかなり少なさそうですが。
gpu.7XLM40でChainer
IDCF Cloud Advent Calendar 2016 の12/11が中々埋まらないので個人的に責任（ぇ）をとって埋めておきますね。
IDCFクラウドのGPUインスタンスgpu.7XLM40が搭載しているTesla M40はディープラーニング用とのことなので、前回のエントリに続き、手元にあるJetson TK1と比較してみます。
今回は国産のフレームワークであるChainerを試してみましょう。
前回のエントリの通り、CUDAまで入っている前提で進めます。
まずは、NVIDIA謹製のDeepLearning高速化ライブラリ cuDNN を入れます。
以下からダウンロードします。
以下のようにダウンロードしたファイルをCUDAインストールディレクトリに展開します。
# tar zxf cudnn-8.0-linux-x64-v5.1.tgz -C /usr/local/
次にChainerをpipでインストールします。
# apt install python-dev python-pip -y # pip install chainer
以下のようにMNISTサンプルを動かして時間を比較しましょう。
# wget https://github.com/pfnet/chainer/archive/v1.19.0.tar.gz # tar xzf v1.19.0.tar.gz # python chainer-1.19.0/examples/mnist/train_mnist.py
Jetson TK1の場合、
# python train_mnist.py -g 0 GPU: 0 # unit: 1000 # Minibatch-size: 100 # epoch: 20 epoch main/loss validation/main/loss main/accuracy validation/main/accuracy elapsed_time 1 0.191052 0.0946279 0.942567 0.9685 15.3752 2 0.0759313 0.079524 0.975899 0.974 27.6975 3 0.0477192 0.0753355 0.984999 0.9782 39.9687 4 0.036118 0.0776683 0.988181 0.98 52.2688 5 0.0288793 0.0803554 0.990682 0.9784 64.564 6 0.0237394 0.0802068 0.992365 0.9808 76.8615 7 0.0206044 0.0778168 0.993249 0.9809 89.1331 8 0.0188643 0.0854813 0.993732 0.9793 101.466 9 0.0161048 0.0746344 0.994749 0.9832 113.725 10 0.0121589 0.0872302 0.996382 0.9827 125.995 11 0.0171261 0.0819404 0.994816 0.9819 138.278 12 0.012826 0.109307 0.996232 0.9796 150.613 13 0.00925115 0.107072 0.997199 0.9793 162.971 14 0.0152739 0.0923335 0.995265 0.9823 175.281 15 0.013186 0.106915 0.995599 0.9815 187.636 16 0.00774953 0.0932978 0.997649 0.9833 199.973 17 0.00556501 0.095636 0.998332 0.983 212.293 18 0.0136293 0.102989 0.996166 0.9824 224.661 19 0.0108599 0.0967607 0.997266 0.9819 236.958 20 0.00808728 0.108585 0.997465 0.9811 249.314
gpu.7XLM40の場合、
# python train_mnist.py -g 0 GPU: 0 # unit: 1000 # Minibatch-size: 100 # epoch: 20 epoch main/loss validation/main/loss main/accuracy validation/main/accuracy elapsed_time 1 0.192398 0.103778 0.941517 0.9661 3.31695 2 0.0745933 0.0841857 0.977366 0.9727 6.05998 3 0.0486797 0.074385 0.983998 0.9786 8.80333 4 0.0367712 0.0739067 0.987615 0.978 11.5473 5 0.027089 0.0893926 0.991115 0.9742 14.2486 6 0.0233483 0.0714004 0.992715 0.9805 16.9643 7 0.0221298 0.0675429 0.993066 0.9814 19.6585 8 0.0181648 0.0812684 0.994115 0.9812 22.3716 9 0.0163283 0.108464 0.994815 0.9746 25.0874 10 0.0138237 0.0710016 0.995482 0.9848 27.7974 11 0.0133834 0.0990396 0.995915 0.9791 30.5191 12 0.013658 0.0909462 0.995599 0.9812 33.2338 13 0.0133063 0.0876385 0.995949 0.9827 35.9592 14 0.0093469 0.0917807 0.997065 0.9817 38.6743 15 0.0119297 0.0796671 0.996416 0.9853 41.3877 16 0.0118582 0.10504 0.996482 0.9808 44.1021 17 0.00992382 0.0811633 0.997066 0.9837 46.817 18 0.00825741 0.102598 0.997582 0.9821 49.5329 19 0.00609279 0.0972261 0.998366 0.9819 52.2437 20 0.0118044 0.105861 0.996865 0.9804 54.9529
20epoch回すのに、
Jetson TK1は、249.314sec、
gpu.7XLM40は、54.9529sec、
5倍くらいの差がでました。さすがM40速いといいたいところですが
もっと差が出ても良さそうですが、層が浅いせいかな。
次回は別のDeepLearningのフレームワークで試してみる。
IDCFクラウドのGPUインスタンス
IDCF Cloud Advent Calendar 2016 の12/10が空いていたので個人的に責任（ぉ）をとって埋めておきますね。
新リージョンこと東日本リージョン2と併せて、GPUインスタンスであるgpu.7XLM40がリリースされてます。
56vCPUなので7XL（XL=8vCPU）、NVIDIAのGPU TeslaのモデルからM40となってます。
このあたりのGPUなんちゃらの話は、12/8のアドカレの通りオフィシャルのテックブログに書かれてます。
手元にあるGPUとしてJetson TK1があったので、gpu.7XLM40と比べてみます。
本題の前に、上記テックブログのエントリーでは、CentOSにCUDA入れてますが、以降ではUbuntu14.04を使ってるので、インストールコマンドだけ書いておきます。
# apt update && apt upgrade -y && reboot # wget http://developer.download.nvidia.com/compute/cuda/repos/ubuntu1404/x86_64/cuda-repo-ubuntu1404_8.0.44-1_amd64.deb # dpkg -i cuda-repo-ubuntu1404_8.0.44-1_amd64.deb # apt update # apt install cuda -y # reboot # export PATH=/usr/local/cuda-8.0/bin${PATH:+:${PATH}} # export LD_LIBRARY_PATH=/usr/local/cuda-8.0/lib64${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}
ここでwgetしてるリポジトリファイルの最新は以下から入手してください。
昔と違ってCUDA入れるのも楽になりましたよねー、動作確認としてはCUDAと一緒に入る以下のコマンドで。
# nvidia-smi Fri Nov 25 21:36:06 2016 +-----------------------------------------------------------------------------+ | NVIDIA-SMI 361.93.02 Driver Version: 361.93.02 | |-------------------------------+----------------------+----------------------+ | GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. | |===============================+======================+======================| | 0 Tesla M40 24GB On | 0000:03:00.0 Off | 0 | | N/A 38C P8 17W / 250W | 0MiB / 22944MiB | 0% Default | +-------------------------------+----------------------+----------------------+ +-----------------------------------------------------------------------------+ | Processes: GPU Memory | | GPU PID Type Process name Usage | |=============================================================================| | No running processes found | +-----------------------------------------------------------------------------+
では、Jetson TK1とgpu.7XLM40比べていきましょう。
前提として、Jetson TK1はCUDA6.5、gpu.7XLM40は上記のとおりCUDA8.0です。
Jetson TK1は、Keplerが 192 CUDA Core。
gpu.7XLM40は、Maxwellが 3072 CUDA Core。
では、CUDAのsmplesを動かして比較してみましょう。
まずはbandwidthTestでデータ転送速度を見ます。
$ ./bandwidthTest
| Jetson TK1 | gpu.7XLM40 | |
|---|---|---|
| Host to Device(MB/s) | 998.2 | 7907.7 |
| Device to Host(MB/s) | 5464.7 | 8288.7 |
| Device to Device(MB/s) | 11901.5 | 211407.8 |
わかってましたが桁違いの差ですね。
次にnbodyでFLOPSを見ます。
$ ./nbody -benchmark -numbodies=16384 $ ./nbody -benchmark -numbodies=16384 -fp64 $ ./nbody -benchmark
| Jetson TK1 | gpu.7XLM40 | |
|---|---|---|
| -numbodies=16384(GFLOP/s) | 13.356 | 3216.793 |
| -numbodies=16384 -fp64(GFLOP/s) | 0.865 | 142.198 |
| -numbodies=131072(GFLOP/s) | 13.393 | 4003.906 |
こちらも圧倒的な差ですね。Maxwell倍精度遅いと言っても、Jetson TK1と比べると圧倒的な差ですね。
今日はここまで、次回はTesla M40の用途に合わせてDeep Learningの性能を見ていきましょう。
IDCFクラウドのHighio.5XL128.g2について
IDCF Cloud Advent Calendar 2016 の12/7がキャンセルされたので個人的に責任（謎）をとって埋めておきますね。
今日はIDCFクラウドの2つのVMタイプ、Highio.5XL128とHighio.5XL128.g2について。
そもそも、Highio.5XL128.g2の存在にお気づきでしょうか。
西日本リージョンだとg2が利用できます。
このg2、仮想化アーキテクチャを一新し、ディスクI/Oへの仮想化のオーバーヘッドを大幅に低減しベアメタルに近い性能を体験できます、といってもダイレクトパススルーではないですが。
では、tpcc-mysqlの性能を見ていきましょう。
赤がHighio.5XL128、青がHighio.5XL128.g2、緑がHighio.3XL128です。
ついでに、Highio.3XL128も一緒にやりましたが、もともと3XL128よりもだいぶ速かった5XL128がg2になりより高速な結果となっています。
計測内容としては次の通り。
■MySQLバージョン
MySQL Server Community Edition 5.6.30
公式RPMバイナリ使用
■MySQLコンフィグ
skip-name-resolve max_connections = 1000 thread_cache_size = 1000 innodb_buffer_pool_size = 90G innodb_log_file_size = 2G innodb_flush_method=O_DIRECT innodb_write_io_threads=16 innodb_read_io_threads=8 innodb_io_capacity=10000 innodb_max_dirty_pages_pct=60 innodb_adaptive_flushing=1 innodb_log_files_in_group=2 innodb_thread_concurrency=0 innodb_purge_threads=1
./tpcc_start -d tpcc -u root -w 1500 -c 30 -l 3600 -i 60 -r 0
MySQLサーバーのローカルで実行
初回1回実行した結果
■OS
CentOS 7.2
■datadir
仮想マシンのdatadirは追加ディスク（DATAディスク）をゼロ埋めした後に、データを入れている。
以上、g2の速さがお分かりいただけたと思いますが、g2になっても価格は同じ。
でも西日本リージョンでのみ利用可能となっています。
東日本リージョンの場合で5XL128で性能が足りない場合はベアメタルサーバーもあります。
このあたりはIDCFクラウド本の6.3章に私が書いています（宣伝）。
www.idcf.jp
IDCFクラウドオブストでs4cmd
IDCF Cloud Advent Calendar 2016 の12/5が空いていたので個人的に責任（？）をとって埋めておきますね。
IDCFクラウドのオブジェクトストレージ（以下オブスト）に、s3cmd使ってデータをやり取り、遅いですよね、嫌になっちゃいますよね。
実はオブストに並列にアクセスできればもっともっと速くなります。
ここにs4cmdというスレッド対応した素晴らしいツールがあります。
github.com
中身はbotoを使ってるんですが、AWS S3用にガリっとエンドポイントが書かれてるので、そこを修正してあげればオブストでも利用できます。
Ubuntuで入れた場合だと具体的には
/usr/local/lib/python2.7/dist-packages/botocore/utils.py /usr/local/lib/python2.7/dist-packages/botocore/data/endpoints.json
の2つです。
では早速、s3cmdとs4cmdで性能比較してみましょう。
テストファイルとして以下用意しました。
10MByteのバイナリファイル10個、
1MByteのバイナリファイル10個、
100KByteのバイナリファイル10個、
1KByteのバイナリファイル10個、
合計40個、112MByte。
次のように実行して、timeコマンドのreal timeの値で比較すると
$ time s3cmd sync ./testdata/ s3://cmdtest/testdata/ $ time s4cmd sync ./testdata/ s3://cmdtest/testdata/
s3cmd sync は10秒
s4cmd sync は1秒
でした。
試してみる価値ありそうですよね。
もしさくっと試してみたい場合は「IDCFCloud CLI toolset on Ubuntu」というコミュニティテンプレートを作ったのでそちらからどうぞ。
以上、アドカレまだ日にち空いてますので、是非埋めてください！
2500Base-Xをベンチマーク
前回のとおり、2500Base-Xをベンチマークしていきましょう。
ScalewayのC2Sタイプを2台作成、OSはUbuntu14.04。
2台間をプライベートIPで通信し、内部通信とします。
最近私は、ネットワークのベンチマークのツールはiperf3をよく使いますが、
Ubuntu14.04には標準パッケージにないので、iPerfオフィシャルのdebパッケージを利用。
# wget https://iperf.fr/download/iperf_3.1/iperf3_3.1.2-1_amd64.deb # wget https://iperf.fr/download/iperf_3.1/libiperf0_3.1.2-1_amd64.deb # dpkg -i libiperf0_3.1.2-1_amd64.deb iperf3_3.1.2-1_amd64.deb
2台目（10.1.70.155）をサーバーとして実行。
# iperf3 -s
まずはTCPで、帯域を測りましょう。
1台目（10.1.69.243）をクライアントとして以下実行。
# iperf3 -c 10.1.70.155 Connecting to host 10.1.70.155, port 5201 [ 4] local 10.1.69.243 port 48520 connected to 10.1.70.155 port 5201 [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 282 MBytes 2.37 Gbits/sec 0 675 KBytes [ 4] 1.00-2.00 sec 281 MBytes 2.35 Gbits/sec 44 624 KBytes [ 4] 2.00-3.00 sec 280 MBytes 2.35 Gbits/sec 0 638 KBytes [ 4] 3.00-4.00 sec 280 MBytes 2.35 Gbits/sec 0 648 KBytes [ 4] 4.00-5.00 sec 281 MBytes 2.36 Gbits/sec 0 648 KBytes [ 4] 5.00-6.00 sec 281 MBytes 2.35 Gbits/sec 0 650 KBytes [ 4] 6.00-7.00 sec 280 MBytes 2.35 Gbits/sec 2 634 KBytes [ 4] 7.00-8.00 sec 280 MBytes 2.35 Gbits/sec 0 648 KBytes [ 4] 8.00-9.00 sec 281 MBytes 2.36 Gbits/sec 0 655 KBytes [ 4] 9.00-10.00 sec 280 MBytes 2.35 Gbits/sec 2 649 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 2.74 GBytes 2.35 Gbits/sec 48 sender [ 4] 0.00-10.00 sec 2.74 GBytes 2.35 Gbits/sec receiver iperf Done.
2.35Gbps出ている。
ほぼほぼ2.5Gbps使いきれてる様子。すごいちゃんと帯域出るのか。
次にUDPで、pps処理性能を測りましょう。
# iperf3 -u -b 0 -l 64 -c 10.1.70.155 Connecting to host 10.1.70.155, port 5201 [ 4] local 10.1.69.243 port 42226 connected to 10.1.70.155 port 5201 [ ID] Interval Transfer Bandwidth Total Datagrams [ 4] 0.00-1.00 sec 14.0 MBytes 117 Mbits/sec 228730 [ 4] 1.00-2.00 sec 13.9 MBytes 117 Mbits/sec 228370 [ 4] 2.00-3.00 sec 14.0 MBytes 117 Mbits/sec 228660 [ 4] 3.00-4.00 sec 13.9 MBytes 117 Mbits/sec 227960 [ 4] 4.00-5.00 sec 13.9 MBytes 117 Mbits/sec 227810 [ 4] 5.00-6.00 sec 13.9 MBytes 117 Mbits/sec 228080 [ 4] 6.00-7.00 sec 13.9 MBytes 117 Mbits/sec 227740 [ 4] 7.00-8.00 sec 13.9 MBytes 117 Mbits/sec 227770 [ 4] 8.00-9.00 sec 13.9 MBytes 117 Mbits/sec 227940 [ 4] 9.00-10.00 sec 13.9 MBytes 117 Mbits/sec 227820 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [ 4] 0.00-10.00 sec 139 MBytes 117 Mbits/sec 0.003 ms 1875/2280861 (0.082%) [ 4] Sent 2280861 datagrams iperf Done.
だいたい22万pps、
10G NICには及ばないとしてもまずまずの性能は出ているんじゃないでしょうか。
2.5G NICとしては、ちゃんと性能も出てるし十分だけど、
10G NICが安くなってきた今、2.5Gの費用感がぜんぜんわからないので何とも。。。
でも、やっぱりScaleway良いなー、ハードウェア的にいつもおもしろい。
2500Base-Xって何だ？
C2タイプがリリースされたScalewayですが、そのリリース時のブログを見ると
we're introducing next generation 2500Base-X networking as a standard feature
とのことで、ネットワークは2500Base-Xを使ってるようですが、2500Base-Xて初耳でした。
内部通信なら2.5Gbps出るとのこと。
今回はこいつを調べてみた。
せっかくのベアメタルですからハードウェア情報さらりと見れるだろうし。
Ubuntu14.04のC2Sでサーバー作成。中を見ていきましょう。
# apt-get install ethtool -y # ethtool eth0 Settings for eth0: Supported ports: [ FIBRE ] Supported link modes: 2500baseX/Full Supported pause frame use: Symmetric Supports auto-negotiation: Yes Advertised link modes: 2500baseX/Full Advertised pause frame use: Symmetric Advertised auto-negotiation: Yes Speed: 2500Mb/s Duplex: Full Port: FIBRE PHYAD: 0 Transceiver: external Auto-negotiation: on Supports Wake-on: pumbg Wake-on: g Current message level: 0x00000007 (7) drv probe link Link detected: yes
おお、ホントに2500baseXと出てくる、しかも速度も2500Mb/sとあるし。
ポートは、ファイバーとあるので、2.5GBASE-Tではない様子。
ドライバはどうなってるか見てみると、
# ethtool -i eth0 driver: igb version: 5.3.0-k firmware-version: 0.0.0 bus-info: 0000:00:14.0 supports-statistics: yes supports-test: yes supports-eeprom-access: yes supports-register-dump: yes supports-priv-flags: no
igb！
なんとIntel NICですか、Intelが出していれば、それなりに知名度あると思ったけど、そんな存在知らなかった。
ハードウェアの情報をもう少し見てみる。
# apt-get install lshw -y # lshw -c network *-network description: Ethernet interface product: Ethernet Connection I354 2.5 GbE Backplane vendor: Intel Corporation physical id: 14 bus info: pci@0000:00:14.0 logical name: eth0 version: 03 serial: 00:07:cb:03:98:8c width: 64 bits clock: 33MHz capabilities: pm msi msix pciexpress bus_master cap_list ethernet physical fibre autonegotiation configuration: autonegotiation=on broadcast=yes driver=igb driverversion=5.3.0-k duplex=full firmware=0.0.0 ip=10.1.71.39 latency=0 link=yes multicast=yes port=fibre resources: irq:0 memory:80000000-8001ffff ioport:1040(size=32) memory:80020000-80023fff
IntelのI354、初耳。バックプレーンとあるので、シャーシに組み込まれてるのか。
独自デザインと言う実機の写真見ても、集積型だから、こういった用途向けに出荷してるんだろうね。
The C2 #servers, 100% designed by our R&D teams for the #cloud. Request your invite now! https://t.co/v6eAjWpNTo pic.twitter.com/CF3fBIPB3c
— scaleway (@scaleway) March 9, 2016
igbのドライバのREADMEには、
The igb driver supports 2.5 Gbps operating speed on 2500BASE-KX only for I354-based network connections.
とあり、2500BASE-KXとありKXなので、やはりバックプレーンでの実装なのでしょう。
