最近、会社はopenstackの仮想マシンでいくつかの重要なビジネスを実行しており、いくつかの仮想マシンをロードバランシングと高可用性クラスタにしたいと考えています。
ロードバランシングのために、Gバージョンはhaproxyプラグインを統合しました。これは、haproxy設定のカプセル化レイヤーを提供し、量子を通してロードバランシングプールを簡単に作成し、同じホストまたは異なるホスト上の仮想マシンにロードバランシング機能を提供します。
このモードでは、ホスト上で haproxy が実行されています。
残念ながら、openstack 経由で haproxy を高可用性にすることはまだできません。
高可用性を実現するには、VMのVIPをフロートさせる必要があります。
ただし、仮想マシンの作成後、この仮想マシンインスタンスで使用できるのは指定したIPのみです。
このため、高可用性のデフローティングVIPをVMに展開することは不可能です。
当然のことながら、パブリッククラウド環境では、ユーザーが仮想マシンに追加のアドレスを設定して回ることはできません。
しかし、プライベートクラウド環境では、このルールは厄介です。
openstackでVMを作成し、nova bootの--nicオプションでNICとIPアドレスを指定します：
--nic net-id=${NETWORK_ID},v4-fixed-ip=${Host_IP}
ずっとiptablesのルールが原因だと思っていました。そこで、ホストマシンのiptablesルールを調べてみました。
これらの openstack が自動生成したルールを分析すると、入力、フォワード、出力の各チェーンはデフォルトで accept 状態になっていることがわかります。各チェーンのパケットのホッピングとフィルタリングを分析すると、新しいアドレスが VM に設定されている場合、それはフィルタリングされません。
何度も翻弄された挙句、結局、IP制限の原因は職場のebtablesにあることが判明しました
ebtablesは、レイヤ2データリンク層のフィルタリングに特化したLinuxです。
nova経由でVMを作成すると、libvirt用のxml設定ファイルが生成されます。
パスの指定: /etc/libvirt/nwfilter/nova-base.xml
内部では、VM上のアドレスを制限する以下のルールが定義され、レイヤ2でフィルタリングが行われます。
その後、各VMごとにxmlファイルが作成され、各VMのxml設定にはnova-base.xmlの設定が含まれます。
VMの1つのxmlコンフィギュレーションを開くと、このコンフィギュレーション・ファイルは指定されたIPのみをレイヤ2で通過可能にするため、他の手動でコンフィギュレーションされたアドレスは利用できないことがわかります。
Libvirt は、これらの xml で設定されたルールを通過して ebtables ルールを生成し、最終的に ebtables で制限を行うことができます。
どうやって割るんですか？
nova-base.xmlファイルを修正します。
<filterref filter='no-mac-spoofing'/> です。
<filterref filter='no-ip-spoofing'/> です。
<filterref filter='no-arp-spoofing'/> です。
その後、libvirt プロセスを再起動すると、libvirt は xml 内の設定を再読み込みし、新しい ebtables ルールを生成します。
修正後、新しいVMを作成してnova-computerプロセスを再起動したり、ホストを直接再起動しても、このベースファイルは変更されなくなりました。
そして、新星のソースコードを修正することもあります。
ソースコードは以下にあります。
1行目 98
no-mac-spoofing,no-ip-spoofing,no-arp-spoofingの行を削除し、これら3つのオプションなしでnova-base.xmlファイルを生成します。
この記事は"ブログからのものです。
