最近、仮想マシンをホストするために特別に構築した新しいサーバーボックスに Ubuntu Utopic 14.04 LTS をインストールしました。このボックスのネットワーク構成には 2 つの NIC が含まれており、2 つの NIC は仮想ブリッジを介してのみ公開されます。1 つはプライベート ネットワークに、もう 1 つはパブリック インターネットに公開されます。1 つのゲスト VM はタップ経由で両方のブリッジにアクセスし、特にホストと一般にプライベート ネットワークのファイアウォールとゲートウェイとして機能します。もう 1 つの VM は、プライベート ネットワーク上の別のゲスト サーバーになります。ホストは、対応するプライベート ブリッジを介してのみプライベート ネットワークに直接参加します。
その結果、eth0 も eth1 も、対応する仮想ブリッジのコンテキスト以外では「アップ」状態になることはありません。ただし、Ubuntu が起動すると、upstart のフェイルセーフは、フェイルセーフが課す 20/40/60 秒の遅延をシステムが乗り越えられるようになる前に、少なくとも eth0 が独立してアップ状態になっていると誤って想定 (主張?) していると思います。しかし、起動が完了し、ゲスト VM が自由に起動できるようになるまで、遅延が解消される見込みはほとんどありません。この矛盾がおわかりですか? 正直に言うと、eth0 も eth1 もアップ状態になるかどうかはわかりません。これまでフェイルセーフ状態に到達することが要求されます。
生の、反動的なレベルでは、私の不満な非Ubuntu側はフェイルセーフを撤去したいと思っています。なぜなら、構成変更のために再起動するたびに、99.9%絶対に起こらないステータス変更のために最大2分待たされるからです。意図的に結論として、フェイルセーフの依存関係はありません。フェイルセーフによって強制されている余分な手間をなくしたいだけです。
同様に、私は、Upstart が failsafe で何をしようとしているかについて、少なくともある程度はオープンな考えでいようとしています。これは私にとって初めての経験だからです。これに対する 1 つのアプローチとして、/etc/network/interfaces の設定方法を変更し、ブリッジ設定を独自の Upstart タスクに移動するという (非常に漠然とした) 情報を見ましたが、私はインターフェイス定義をそのままにして、満足して動作させておくことを本当に好みます。
では、選択肢は何でしょうか? フェイルセーフ タスクを削除するだけでよいのでしょうか、それとも条件を変更するように変更すればよいのでしょうか? もしそうなら、どのようにすればよいのでしょうか? インターフェイス ファイルをハックする必要がありますか?
答え1
まず、私自身の質問に答えてしまったことをお詫びします。
2 つ目は、実際に failsafe.conf の起動遅延問題を克服したことです。この質問に関して活発な議論が交わされていないことは承知していますが、同様の failsafe/起動遅延問題については、他のさまざまなスレッドで十分な議論が交わされているのを見ました。そこで、同様の問題を抱えている他の人たちのために、調査結果と解決策を投稿します。
概要
最初の投稿で述べたように、私が見た問題は、フェイルセーフ アップスタート ジョブがシステムの起動に不要な制約を課していたことでした。その後、問題をさらに調査し、フェイルセーフがなぜそのように動作していたのかを突き止めました。
分析
デフォルトでは、failsafe.conf は起動時に (ファイルシステムとループバック インターフェイスが利用可能になるとすぐに) 効果的に起動する開始条件を定義し、次の 2 つの停止条件のいずれかを定義します。
start on filesystem and net-device-up IFACE=lo
stop on static-network-up or starting rc-sysinit
フェールセーフの遅延の主張は、どちらの「停止」イベントも発生しなかったために生じた。2番目の条件であるrc-sysinitは、upstartが実行する最終的なシステム初期化タスクの1つであり、独自の開始条件を持っている。
start on (filesystem and static-network-up) or failsafe-boot
フェイルセーフなしで停止するrc-sysinitは明らかに起動。タイムアウトが経過すると、Failsafe は failsafe-boot イベントを発行します。failsafe が開始されると、「filesystem」が暗黙的に指定されるため、両方のイベントに共通する唯一の条件は「static-network-up」になります。Failsafe は、ネットワーク インターフェイスが「up」であるとは考えないため、実行されています。
原因
/etc/network/if-up.d を遡って作業すると、/etc/network/interfaces で定義されているすべてのネットワーク インターフェイスを反復処理する upstart スクリプトが定義されます。このインターフェイスは、ブート時に起動されるインターフェイスであることを意味する「auto」修飾子で定義されています。インターフェイスが「起動中」と見なされる方法の定義は、後で説明する重要な意味論的問題になります。
すべての「自動」構成のインターフェースが「アップ」の場合のみ、upstart スクリプトは有名な「static-network-up」イベントを発行します。これにより、rc-sysinit が起動してフェイルセーフを終了できるようになります。これが私の問題の根本原因です。私のネットワーク インターフェースはどれも、設計上、起動時に IP アドレスを持っていません。しかし、「static-network-up」は、インターフェースが「アップ」であるという考えを遵守しません。それなしIP アドレスなので、タイムアウトが経過するまでフェイルセーフはハングします。
私の場合、ボックス内の 2 つの物理 NIC をブリッジにスレーブ化し、タップを介して 2 つの異なる VM に公開します。1 つの VM は 1 つのタップを介して DHCP を提供し、もう 1 つは同じネットワーク上の単なるサーバーです。VM によってタップされたブリッジが適切に機能するには、NIC が少なくとも「UP」で、パケットを受動的に通過させる必要があります。したがって、/etc/network/interfaces で「auto」が適切であるように思われました。ないしかし、フェイルセーフの観点からは適切ではないため、唯一の解決策はフェイルセーフのセマンティクスに準拠したものでなければなりませんでした。
私の問題に対する解決策は 2 つありました。
- 定義したすべてのネットワーク インターフェイス (ループバック以外) から 'auto' 宣言を削除します。
- 以前は「自動」だったインターフェースを「手動で」起動するためのアップスタート ジョブを作成します。
私は、提供されたソリューションを模倣して、4つのデバイス（2つのタップと2つの仮想ブリッジ）のそれぞれ4つのジョブを定義しました。ここ。
この構成では、「自動」インターフェースがないため、ネットワーク スクリプトはすぐに「static-network-up」を発行し、フェールセーフを強制的に終了する必要があります。最終的な変更では、各タップのインターフェース定義に「post-up」句を追加して「brctl」を呼び出し、対応する仮想ブリッジを作成する必要がありました。これは、以前は「自動」構成の一部として実行されていました。
したがって、私の /etc/network/interfaces (一部) は次のようになります。
#auto tpRED (commented out)
iface tpRED inet manual
pre-up /usr/sbin/tunctl -t tpRED
post-up /sbin/brctl addbr brRED
#auto brRED
iface brRED inet manual
bridge_ports eth1 tpRED
bridge_hw xx:yy:aa:bb:cc:dd
厳しい試練
厳しいテスト？サーバーを再起動します。そして私がそうしたとき、フェイルセーフタイムアウトがなくなったそして、私のネットワークは機能的に同一の構成で起動しました。 うまくいきました!! 「UP」ネットワーク インターフェイスのセマンティクスをもっとうまく処理できればよかったのですが!!