先日、１つの問題に１週間以上ハマって悶絶するも、絞りだすような勘と数えきれない再構築によって、命からがら解決することができました。
その問題とは、２台目以降のホストであるComputeNodeのVMがDHCPからアドレスを取得できない というもので、これについて多くの情報を仕入れたのでまとめておきます。
DHCPからIPアドレスが取得できない現象
ControllerNode１台で構築し（NetworkNodeは分けていない）、VMを作成する分には問題なくDHCPからアドレスがリースされるのに、ComputeNode単体ホストで作ったVMはアドレスを取得できない、という問題でした。その時どうなるかというと、VMからQuantumネットワークのDHCPサーバにリクエストは飛ぶものの、レスポンスが返せずにレスポンスパケットが永久に垂れ流され続ける状態になりました。
しかも、Quantumネットワークのrestart直後は一瞬、VMでアドレスを取得できるのに、すぐ疎通できなくなって結局DHCPレスポンスが繰り返されるという、中途半端な挙動も多々ありました。
要は、ControllerNode内部だけなら通らない経路で、ComputeNode単体との間の経路に何か問題があることはすぐアタリはついたのですが、調べてみるとDHCP失敗関連の情報があるわあるわ… 自分のネットワーク苦手意識もあり、全てなんとなく試していくも一向に当たらず途方にくれるのでした。
ネットワーク知識の守備範囲
Quantum周りで詰まった時に何が厳しかったかというと、必要とする知識の範囲です。すなわち、試す範囲が広く、組み合わせも多様ということ。今回だけでも考える必要があったのは
これくらいあり、1つ試してダメならコッチも変えて… と組み合わせまで疑うことになり、途中、何が確実に正しいのか、自分が何やってるのかすら混乱してきて、キレて何度も再構築するなど。
特にOVSはデリケートで、再構築するにも手順を間違えるとOSがハングしたり、
お前は今ナニと戦っているんだ状態に何度も陥りました。
DHCP問題まとめ
iptableのCHECKSUMターゲット
vhost_net カーネルモジュールが有効になっている時に、mangleテーブルにCHECKSUMターゲットを入れないと通らないという問題。Wheezyの場合はそもそも無効なので関係ないですが、藁にもすがる思いであえて有効にしたり iptables を加えたりするも、今回には関係ありませんでした。
|
1 |
iptables -A POSTROUTING -t mangle -p udp --dport bootpc -j CHECKSUM --checksum-fill |
quantum-l3-agent-INPUT
qrouterの quantum-l3-agent-INPUT チェインで、そもそも許可されていない疑惑。確かに追加することで、このチェインのこのルールでパケットカウントされ始めた環境条件もあり、有効そうだったのですが解決には至らず。
|
1 2 |
ip netns exec qrouter-a91fa6ce-d5f0-452b-a789-8d932f631e8e \ iptables -A quantum-l3-agent-INPUT -p udp --dport 67:68 --sport 67:68 -j ACCEPT |
brctl show に qvo interface
brctl show の表示に qvo*** というinterfaceが無ければダメなんじゃねって話。確かに無い！けど、どうやったらできるんじゃい！！には到達せず…
一応libvirtのパッチがあったけど、そこまでやらないと解決できるものじゃないはず、と確信していたのでスルー。
bridgeカーネルモジュールのsysctlパラメータ
openvswitch-brcompat を有効にすると brcompat_mod / openvswitch_mod モジュールが有効になりますが、BRCOMPATが無効な状態だと bridge モジュールが有効になります。（どちらも lsmod で確認）これは、bridge の機能を落とすことで解決を試みており、一応あえて bridge にして試したりもしましたが解決しないし、それまでの経験則で BRCOMPAT=yes の方が主流だと考えて、廃案としました。
|
1 2 |
cd /proc/sys/net/bridge for f in bridge-nf-*; do echo 0 > $f; done |
dnsmasq
全く同じdnsmasqプロセスが２つあったら変じゃね？って話。そんなことなく、正常運行でした。ただ、Quantumデーモンを落とした時に dnsmasq や quantum-ns-metadata-proxy プロセスが残るというバグ？があり、Quantum設定変更の際は restart ではなく
stop -> pkill dnsmasq -> start といった流れで慎重に行ったりしました。が、結果的には関係ありませんでした。
ていうか、ControllerNode内のVMが取得できてる時点で、DHCPサーバではなく経路が問題だとわかるし…
libvirt_use_virtio_for_bridges
/etc/nova/nova-compute.conf のデフォは libvirt_use_virtio_for_bridges=True だけど、DHCP問題に差し掛かったときに libvirt_use_virtio_for_bridges=False にすると解決することがある、という話。実際、私も試しましたが、これによって確かにアドレス取得に成功する場合がありました。しかし、VMの kvm プロセスのCPUが100％にお怒りになり続けるという現象と、一般的に True が主流ということで廃案にしました。
libvirt network
そして調査は libvirt にまで突入していく始末。さきほども書きましたが、bridge の sysctl を変更したり、
|
1 2 3 |
net.bridge.bridge-nf-call-ip6tables = 0 net.bridge.bridge-nf-call-iptables = 0 net.bridge.bridge-nf-call-arptables = 0 |
ネットワークインターフェースの設定にこんなのを入れると安定するかも！みたいな話。
|
1 2 3 4 5 6 7 8 9 10 |
auto br0 iface br0 inet static address 192.168.2.4 netmask 255.255.255.0 network 192.168.2.0 broadcast 192.168.2.255 gateway 192.168.2.2 bridge_ports eth0 bridge_stp on bridge_maxwait 0 |
ウチは brcompat だし！bridgeにして試してもうまくいかないし！で廃案。
あと、libvirtのXMLで、ネットワークのところに <driver name=’qemu’/> を入れたら… ってのも紹介されてるけど、<model type=’virtio/> で、vhost_net が有効で、iptablesのCHECKSUM非対応で、ホスト上のDHCPから直接取得しようとしてる、4つの条件が揃った場合に！とかあって、明らかに関係ないのに守備範囲だけが広がってく感覚にイライラするなど。
外道父版DHCP問題の原因と解決策
原因
原因が判明してしまえば、やはり苦手意識があったOVS周りで、やはり来たか…という感じでしたが、問題が起きていた間の設定は、Folsomや、初めてGrizzlyを構築した時には問題なかったために回り回って余計時間がかかってしまいました。OVSの設定は、
という感じで、ControllerNode・ComputeNodeの全ホスト共通で設定していたのですが、
これをComputeNodeの br-ex をやめて普通に eth0 がStaticAddressを持つように変更したら、DHCP問題 …… いうならば NetworkNode と ComputeNode 間の疎通問題が解決しました。なんとあっけない…
なぜ全ホストで br-ex ブリッジを作っていたかというと、なんとなく、というのもありますが、後々ネットワークの冗長化を作る時に必要なんじゃないか予想をしていたからで、何か確信があったわけではありませんでした。完全に不安ポイント的中！！
解決策
それまで、ネットワークの種類はなので、問題切り分けのしやすさを主眼において、OpenvSwitchのブリッジ設定は
とし、Quantum Agent はvlanでマッピングは
としました。各所にある br-ex, br-int の指定は全てデフォルトのままです。
切り分けという意味ではNetworkNodeも分けるべきでしょうが、とりあえずこれで解決したのと、tcpdumpなどでデバッグしやすくなって十分綺麗になりました。
ただ、別にこれが正解と確信しているわけではなく、世界中の人の設定を見るとブリッジやマッピングの構成が少しずつ違っているので、物理NICの数から始まって各種設定の組み合わせによって色々正解がありそうだな、と思う次第。
今回、引退したくなるほど苦しみましたが、結果的には深くダイブしたことで苦手分野の理解を促進できたので、晴れて一人前のOpenStackerになった気になっています！！
