bondingを使用し、CentOS6上のKVMにvlan環境を整える　〜 KVM + bonding + bridge + vlan - Yota.log

# bondingを使用し、CentOS6上のKVMにvlan環境を整える　〜 KVM + bonding + bridge + vlan

June 24, 2013

networkな（？）良い感じなネタがあったので投下。
備忘録な感じ。
これができたからといってどうというわけでも無いんだけど。
まあ趣味的な感じで。

某友人の言葉を借りると、「気持ち悪いネットワークな話。ネットワーク屋さんは何言ってるのか本当に謎で気持ち悪い」が満載かも。
こっちとしては普通なんだけど。

詰まった点はbrの名前とかvirsh editがちゃんと反映されてないとか変な部分。

## 環境

[bash]
$ cat /etc/redhat-release
CentOS release 6.4 (Final)
[/bash]

## 最初に補足

適宜tcpdumpやping辺りで通信を確認した方が良い。
[bash]
$ tcpdump -i [interface]
or
$ ping [ipaddr]
[/bash]

特に有効なのはtcpdump。
しっかりtag vlanなpacketが入ってきてるかをチェックすべし。
bridgeなのでおそらく問題は怒らないと思うけど。
iptablesとか設定してる人は結構ややこしくなる可能性あるので注意。
\

## bonding

bondingの有効化から。

[bash]
$ vi /etc/modprobe.d/bonding.conf
alias bond0 bonding

$ modprobe bonding
[/bash]

これでkernelのbonding機能が使えるようになる。
modprobeはLinux kernelにmoduleを追加したりするコマンド。
確認は
[bash]
$ lsmod | grep bonding
[/bash]
くらいでオッケー？

\

次、bondingしたいinterfaceの設定をする。

bondingってのは複数のinterfaceを一つのinterfaceに見せるっていう技術。
冗長性や効率性を上がるっていうやつ。

[bash]
$ vi /etc/sysconfig/network-scripts/ifcfg-ethXX
DEVICE=ethXX
HWADDR=XX:XX:XX:XX:XX:XX
TYPE=Ethernet
ONBOOT=yes
NM_CONTROLLED=no
BOOTPROTO=none
IPV6INIT=yes
MASTER=bond0
SLAVE=yes
[/bash]

interfaceの設定はこんな感じ。

[bash]
$ vi /etc/sysconfig/network-scripts/ifcfg-bond0
DEVICE=bond0
ONBOOT=yes
BOOTPROTO=static
IPV6INIT=yes
BONDING_OPTS="mode=6 miimon=100"
[/bash]

このBONDING_OPTSのmode6は送受信共に負荷分散してくれるっていう設定。
何やってるか謎。
mode0はround robin、激遅。packet lossもあった。
mode1はactive-stanbyみたいな。同じパケットを全部のNICから流すみたいなmodeもあったけどどこで使うか謎。
全体的に冗長性高める構成。NIC壊れるってそうそう無いと思うけど、network系は冗長性・耐障害性が命だから。
ifdownで実験しても落ちないみたい。sshとかのsessionも生きるらしい。
eth0とeth1でmode1組んでる場合は、設定で変えることも可能だけど、eth0がprimaryでeth1がsecondaryってな具合。
primaryのNICが死んだ場合はeth1がeth0のHWADDRを引き継いで通信するんだとか。
っていうか、ifconfig bond0とか見たらそんな感じでした。実験はしてない。
ifdownくらいでやればいいと思うけど。
miimonは、確か設定したms毎にNICの生死判定をするってやつだったはず。

#
もしかしたら、bondingのdeviceを多く設定すると、mode5とか6が使えなくなるのかも。
# bondingするdevice数は2が良い。

\

## vlan

次は、vlanを有効化
[bash]
$vi /etc/sysconfig/network
#以下を追加
VLAN=yes
VLAN_NAME_TYPE=DEV_PLUS_VID_NO_PAD
[/bash]

VLAN_NAMEは4種類くらいあるけど、これが良いな。
deviceを認識できるのが良いってのと、NO PADDINGなところ。
DEV_PLUS_VIDだとvlan id指定するときにeth0.0001みたいになるから微妙…。
VxLANだとどうなるんですかね。長いPADDINGが見れる？いや、要らない。

次はbond0にvlanを割り当て。
vlan idが100とかだったら
[bash]
$ vi /etc/sysconfig/network-scripts/ifcfg-bond0.100
DEVICE=bond0.100
ONBOOT=yes
BOOTPROTO=none
BRIDGE=br100

IPV6INIT=yes
# /etc/sysconfig/network でNETWORKINGIPV6もyesにすること
[/bash]

注意は、bond0のvlanはbond0.100とかでやるけど、bridgeは特にそんなことは必要ないっていう点。
多分、bridgeはbridgeのidだけ指定されてたら良いのかな、ってところ。
なので、br100の100の部分に特に意味はないと予想。
ここでは分かりやすくするために便宜上100としてるけど。

\

## bridge

bridgeの設定

[bash]
$ vi /etc/sysconfig/network-scripts/ifcfg-br100
DEVICE=br100
BOOTPROTO=none
ONBOOT=yes
TYPE=Bridge
[/bash]

これでKVM host側の設定は終了。
br0.100とかやっちゃうとダメ。

[bash]
$ service network restart
[/bash]

で設定の有効化。

\

## KVM の xml edit

次にVMにbridgeを割り当てる作業。
virt installとかだと普通にbridge指定するだけ。
今回僕は、既存のVMのbridge設定を書き換えたので、その方法を記述。

[bash]
$ vi /etc/libvirt/qemu/[virtual machine name].xml
# bridgeの変更
<source bridge=‘br100′>
[/bash]

ここ書き換えるだけでは設定は反映されなくて、defineし直す必要がある。
しかし、ここでVMは起動していてはいけないので #
networkがstartした状態だとダメなのかも。stopしたら書き換わる？

[bash]
$ virsh console [virtual machine name]
shutdown -h now
[/bash]

くらいでshutdownして

[bash]
$ virsh define /etc/libvirt/qemu/[virtual machine name].xml
[/bash]

でbridge設定が反映される。

[bash]
$ virsh dumpxml [virtual machine name]
[/bash]

で現在の設定を確認できる。

\

## 最後に

後は、vm内のnetwork設定をいつも通りやれば良い。
言わずもがなだと思うけど、ちゃんと指定したvlanのip帯を設定すること。

気になるのは、1つのVMに複数のNICを作成して、それぞれに別のvlan
idを割り振る方法。
新しいvnet作ってそいつに割り当てかな。
おいおい探すとして、設定は完了。
\

## ifdownしてみる

sshやiperfなんかで通信中にifdownしてみたりしたけど継続して通信できたってことは良い感じ。
かと思いきや、ifupするとnetがdown。
network restartをvm側でかけるはめに。
->
時間たったら繋がった。tcpdumpでpacket監視してたら始めは流れて来なかったが、しばらくして流れ始め、pingも通る。
[bash]
64 bytes from [ipv6]: icmp_seq=4 ttl=56 time=46.8 ms
64 bytes from [ipv6]: icmp_seq=38 ttl=56 time=50.3 ms
[/bash]
icmp_seq見たら分かるけど、一気に4から38になってるので、それくらいは待たないといけないみたい。
結局、障害発生 ->
ifupでは結構通信復活に時間がかかる結果に。pingの例だと30秒くらい。
tcpdumpで一度promiscにしてpacket上らせると無理矢理感あるけど繋がるの早くなったような気が。

ちなみに、ifdownとかifupした後のnetwork restart時に
[bash]
Bringing up interface eth0: WARN : [ipv6_add_route] ‘No route to host’
adding route ‘::/0’ via gateway ‘XXXX:XX::1’ through device ‘eth0’
[/bash]
みたいなwarningが出たりする。
[bash]
$ ping6 XX::XX
connect: Network is unreachable
[/bash]
もう一度network restartすると消える。
なんだこれ。（＊その後何度か繰り返したが、何度restartしても消えなくなった。かと思ったら消えたり。謎。）
ifcfg-*にはちゃんとIPV6INIT書いてるんだけど．．．。

あと、iperf実験してると途中で繋がらなくなったり…。
iptablesは切ってるので問題ないとして、学科の装置が影響してる可能性も考えないと。
って思ったらVMのiptablesを切ってなかった…。アホか。
そのうちiperfの結果を載せる。

bondingのNICに問題発生->復旧した場合、
＊　時間が経てば繋がる
っぽいのでservice restartは要らないかな、という結論。
ここにたどり着くまでの長さ。

謎な部分はとりあえず放置。
\

## ついでに

今の状態だと、KVM
hostにnetworkで接続できないはずなので、設定用のIPを適当なinterfaceに振るべき。
NICが2つしかない場合はbondingせずに、eth0をKVM
host用、eth1をVMへのbridge用とか。
いや、でも冗長性考えるならbonding作った方が良いのかな？
NICが3つ以上ある場合はbondingした方がメリットでかいかも。
NICが1つの場合は一つでbridge振っていろいろ頑張るしかないか。

ちなみに使っているKVM hostにはNICが6つあったのでbondを3つ作成。
うち一つは何故かしっかり通信できないので仕方なく2つで通信。
GigabitとtenGigaの2つのbond。
tenGigaを使いたいけど、なんかいろいろ動作が不安。
要実験ってところだけど、めんどくさいなぁ。

« Previous

【ほこ×たて@ie_003】絶対に居場所を特定するストーキングツール vs 絶対に居場所を特定させない設定（仮）【対策編】

Next »

【ほこ×たて@ie_004】絶対に居場所を特定するストーキングツール vs 絶対に居場所を特定させない設定（仮）【番外編】