古い記事ですが、Slashdot 本家に Firewall Failover With pfsync And CARPという記事があった。良いなぁ。と linux 周りを眺めていたら ct_sync? という conntrackd 実装している方が、以前全てカーネルスペースで実装しようとしていた形跡を発見。ML にも入らず日々ダラダラ過ごしていたところ、conntrackd なるものを発見。ct_sync より勢いがありそうな感じで今後に期待....というのが今更ながらの前置き。そうそう CARP と conntrackd 使ってみたらしき ML への投稿があった気がする。
元気が無いのでまたまた貢献できないと思ふぅ。商用ファイアウォール製品と比較して、辛いな。と思う部分ですので、頑張って下さい。
2007年6月26日火曜日
conntrackd のオプション
目に余る逸脱ぶりなので、ちょっと戻る。-c の ``external cache'' という言葉に戸惑う。相変わらず内部、外部キャッシュの意味を理解していない.... conntrack-tools/src/main.c から
(プライマリ) 外部のキャッシュをコミット
static const char usage_client_commands[] =
"Client mode commands:\n"
" -c, commit external cache to conntrack table\n"
(プライマリ、バックアップ) キャッシュのクリア
" -f, flush internal and external cache\n"
(バックアップ) カーネルの conntrack テーブルのクリア
" -F, flush kernel conntrack table\n"
内部キャッシュの表示
" -i, display content of the internal cache\n"
外部キャッシュの表示
" -e, display the content of the external cache\n"
停止
" -k, kill conntrack daemon\n"
統計情報表示
" -s, dump statistics\n"
(プライマリ) カーネルの conntrack テーブルとの再同期
" -R, resync with kernel conntrack table\n"
(ん? script_.*.sh にない) NACK モードにて他ノードとの再同期
" -n, request resync with other node (only NACK mode)\n"
どーゆ経過か知らないけどキャッシュ内容の XML 出力
" -x, dump cache in XML format (requires -i or -e)";
linux で Gigabit
New Reno では Gbit は辛いらしいと、どこかで目にした後うろうろしていたら
で試してないっと...
How to achieve Gigabit speeds with Linuxというドキュメントを見付けた。要約してみると
- interrupt coalescence (ハードウェアで割り込み回数減らす)
# ethtool -c eth1
ガーン。他 -k や -g。ethtool(8) 参照
Coalesce parameters for eth1:
Cannot get device coalesce settings: Operation not supported- NAPI対応のドライバ
- 送信キュー長の変更
- ifconfig だけど流行? であれば
ip link set eth1 txqueuelen 2000
あれ? デフォルト ip link ls eth0 で 1000 ある。 - 受信キュー長の変更
sysctl –w sys.net.core.netdev_max_backlog=2000
ちなみにデフォルトは# cat /proc/sys/net/core/netdev_max_backlog
1000- TCP輻輳ウィンドウ 指数増加閾値上限なし
sysctl –w sys.net.ipv4.route.flush=1
こちらは /proc 下のパーミッションがls -l /proc/sys/net/ipv4/route/flush
--w------- 1 root root 0 2007-06-26 22:05 /proc/sys/net/ipv4/route/flush- SACK を無効に
- 競合がない...目一杯自分だけのテストなので
sysctl -w net.ipv4.tcp_sack=0
- TCPバッファサイズの変更
- 上限
- net.core.rmem_max
- net.core.wmem_max
- net.ipv4.tcp_mem
デフォルト値- net.ipv4.tcp_rmem
- net.ipv4.tcp_wmem
で試してないっと...
2007年6月20日水曜日
VMware workstation 6.0
Open Tech Press の記事 に VMWare6 すばらしい。らしき書かれていて眺めると
しかも x86_64 もあったので、早速 Upgrade して試してみたところ、まぁ上記通りライブラリ含めて 64bit になっていたし、ウィンド閉じようとすると daemon で稼働させるか聞いてくる。
2.6.22-rc をホストとした場合 sk_buff 周りの変更に vmnet が対応しておらず、ここから patch 持ってきてあてておく。cvut.cz にあった any-any-update が最近更新されていないのが少々恐い。
あとは個人的にネットワークは hostonl のインターフェースのみとして /usr/lib/vmware/net-services.sh いじって dhcp 止めるのとインターフェースのアップを vmware_bg_exec から vmware_exec へ。他 /etc/rc2.d/S19 番目。これやっておかないと dhcp の relay が動かんから。
# lguest が 32bit のみだから試すにあたって? 目的のための手段のための手段のための...
今回のWorkstation 6では、ユーザインタフェースなしでVMを実行できる。Workstationのウィンドウを閉じると、VMを電源オフにするかバックグラウンドで実行を続けるかの選択肢が表示される。これは、Webサーバなど、後で接続したいサービスをVMが実行している場合に便利だ。と私にとって魅力的なものが。# もしかして Server でもできていた?
しかも x86_64 もあったので、早速 Upgrade して試してみたところ、まぁ上記通りライブラリ含めて 64bit になっていたし、ウィンド閉じようとすると daemon で稼働させるか聞いてくる。
2.6.22-rc をホストとした場合 sk_buff 周りの変更に vmnet が対応しておらず、ここから patch 持ってきてあてておく。cvut.cz にあった any-any-update が最近更新されていないのが少々恐い。
あとは個人的にネットワークは hostonl のインターフェースのみとして /usr/lib/vmware/net-services.sh いじって dhcp 止めるのとインターフェースのアップを vmware_bg_exec から vmware_exec へ。他 /etc/rc2.d/S19 番目。これやっておかないと dhcp の relay が動かんから。
# lguest が 32bit のみだから試すにあたって? 目的のための手段のための手段のための...
2007年6月6日水曜日
帯域増と転送速度
「10M から 100M に増速しました」増速? みたいな話のあと
「ファイル転送したけど転送時間あまり変わらないですね」
「いやぁ RTT が短くなった訳ではないですので、あまり期待しないで下さい」
....むーん、増速の速度って何よ。検索サイトに long fat pipe でお尋ねしましょう。
エンドユーザに実感してもらうには ftp がてっとり早いということで proftpd 入れて SO_SNDBUF SO_RCVBUF あたりを設定ファイルで...と調べたら tcpSendWindow tcpReceiveWindow とか...ではなく SocketOptions の rcvbuf sndbuf で指定するらしい。
カーネルコンパイルのオプション眺めると輻輳制御のアルゴリズム色々あるなぁ。10Gbit とかいう世界になると何が良いのでしょうか?
# /proc/sys/net/ipv4 以下や、ndd -set /dev/tcp も忘れずに。
「ファイル転送したけど転送時間あまり変わらないですね」
「いやぁ RTT が短くなった訳ではないですので、あまり期待しないで下さい」
....むーん、増速の速度って何よ。検索サイトに long fat pipe でお尋ねしましょう。
エンドユーザに実感してもらうには ftp がてっとり早いということで proftpd 入れて SO_SNDBUF SO_RCVBUF あたりを設定ファイルで...と調べたら tcpSendWindow tcpReceiveWindow とか...ではなく SocketOptions の rcvbuf sndbuf で指定するらしい。
カーネルコンパイルのオプション眺めると輻輳制御のアルゴリズム色々あるなぁ。10Gbit とかいう世界になると何が良いのでしょうか?
# /proc/sys/net/ipv4 以下や、ndd -set /dev/tcp も忘れずに。
2007年5月29日火曜日
kqemu
仮想化で使ったことが無かった qemu に挑戦。debian 使っているので、DebianでQEMUを高速化する(kqemuモジュール)がとっても参考になった。細かな話だけど module-assistant の部分はどこかの madwifi のコンパイル方法にもあったが
# 目的のための手段のための手段のための...が目的に
m-a a-i kqemuかな。QEMUのサイトにあるlinux-0.2.img.bz2 (8 MB)でも良いけど。debian であれば qemu-make-debian-root なるものがあったり qemu-img もあるけど。その後 ここや ここを参照しつつ
おぉ...と思ったら slashdot に こんな 記事が。さて...
# dd if=/dev/zero of=disk.img bs=1M seek=2047 count=1
# losetup /dev/loop0 disk.img
# cfdisk -s 63 -h 16 /dev/loop0
....(1つのパーティションで bootable に)
# losetup -o 32256 /dev/loop0 disk.img
# mkfs -t ext3 /dev/loop0
# losetup -d /dev/loop0
# mkdir rootfs
# mount -o offset=32256,loop disk.img rootfs
# debootstrap --arch amd64 etch rootfs http://ring.asahi-net.or.jp/archives/linux/debian/debian
....
# chroot rootfs /bin/bash
# apt-get install kernel-image-2.6-amd64-generic grub
....
# mkdir /boot/grub
# update-grub
# cp /usr/lib/grub/x86_64-pc/* .
# exit
# umount root
# exit
# /usr/sbin/grub --no-floppy
# grub --no-floppy
Probing devices to guess BIOS drives. This may take a long time.
GNU GRUB version 0.97 (640K lower / 3072K upper memory)
[ Minimal BASH-like line editing is supported. For
the first word, TAB lists possible command
completions. Anywhere else TAB lists the possible
completions of a device/filename. ]
grub> device (hd0) disk.img
device (hd0) disk.img
grub> root (hd0,0)
root (hd0,0)
Filesystem type is ext2fs, partition type 0x83
grub> setup (hd0)
setup (hd0)
Checking if "/boot/grub/stage1" exists... yes
Checking if "/boot/grub/stage2" exists... yes
Checking if "/boot/grub/e2fs_stage1_5" exists... yes
Running "embed /boot/grub/e2fs_stage1_5 (hd0)"... 15 sectors are embedded.
succeeded
Running "install /boot/grub/stage1 (hd0) (hd0)1+15 p (hd0,0)/boot/grub/stage2 /
Done.
grub> quit
quit
# qemu-system-x86_64 disk.img
# 目的のための手段のための手段のための...が目的に
登録:
投稿 (Atom)