nova-network から OpenStack Networking (neutron) への移行¶

OpenStack には 2 つのネットワークモデルがあります。 1 つはレガシーネットワーク (nova-network) と呼ばれ、 Compute プロジェクト (nova) の一部のサブプロセスです。このモデルにはいくつか制限があり、例えば、複雑なネットワークトポロジーを作成する、バックエンド実装にベンダー固有の技術を利用する、テナント専用のネットワークリソースを提供する、といったことはできません。これらの制限が、 OpenStack Networking (neutron) のモデルが作成された主な理由です。

この節では、レガシーネットワークモデルのクラウドを OpenStack Networking モデルに移行する手順を説明します。この手順では、移行に対応するために compute と networking の両方に追加の変更が必要です。ここでは、全体の手順と、Networking と Compute の両方に必要となる機能について説明します。

現在の手順は、レガシーネットワークを廃止予定としその後削除するために、最小限で必要な移行手順です。 Compute と Networking の両チームは、レガシーネットワークから OpenStack Networking (neutron) への「ボタン 1 つ押すだけ」の移行作業は、レガシーネットワークを将来廃止予定に削除するにあたっての、必須の要件ではないという点で合意しています。この節では、単純なユースケースで移行を可能にするために設計された手順とツールについて説明します。

ユーザーは、是非、これらのツールを使用し、テストし、フィードバックを行い、自分の環境に適した機能を持つように機能追加を行ってください。こうした活動に参加せずに、自分のユースケースにもっと適したものになるまで待っていると、できあがったものはあまり望ましいものにはなっていないことでしょう。

影響と制限事項¶

レガシーネットワークの nova-network サービスから OpenStack Networking (neutron) への移行手順には、いくつか制限があり、クラウドの運用状態への影響があります。あなたのクラウドとユーザーにとって、この手順が受け入れ可能なものかを判断する上で、この内容を理解するのは不可欠です。

管理面での影響¶

移行が完了するまでは、Networking REST API は公開 API としては読み出し専用になります。移行中は、Networking REST API を読み書きできるのは nova-api だけで、Networking への変更ができるのは nova-api 経由だけとなります。

Compute REST API は移行中全体を通じて利用できますが、データベースの移行中の短い期間だけは読み出し専用になります。 Networking REST API は、レガシーネットワークの DB に格納されていた情報を再構築するのに必要な前情報を (nova-api に) 公開する必要があります。

Compute では、データモデルにハイパーバイザー単位にブール値の “has_transitioned” フラグが必要で、このフラグは移行作業中に使用されます。移行手順が一度完了すると、このフラグはそれ以降は必要ありません。

運用面での影響¶

幅広いデプロイメントの選択肢に対応するため、ここで説明する移行手順では、ハイパーバイザーを順に再起動 (rolling restart) していく必要があります。個々のハイパーバイザーの再起動をどのくらいの早さで、いつ行っていくかについては、オペレーターが制御できます。

移行作業を途中で止めることもできます。一部のハイパーバイザーはレガシーネットワークで、一部ハイパーバイザーは Networking を使っているという状況で、(例えば、テストや問題の調査などで) 長い時間止めることもでき、その間も Compute API は完全に機能し続けます。個々のハイパーバイザーは、移行のこの段階であれば、もう一度再起動を行う必要はありますが、レガシーネットワークに切り戻すこともできます。

様々なデプロイメントでの需要に対応するため、ここで説明する手順は、簡単に自動化できますが、まだ自動化はされていません。オペレーターは、この移行手順を実行するのに、手動作業をいくつか実行したり、簡単なスクリプトを書く必要があることでしょう。

性能面での影響¶

移行の途中では、 nova-network API 呼び出しは内部で Networking の呼び出しに変換されます。そのため、移行前や移行後の API と比べると、違った、性能特性、おそらく低い性能性能になることでしょう。

移行手順の概要¶

neutron-server を最終的な設定内容で開始します。例外は、 REST API が nova-api による読み書きに限定されるという点だけです。
Compute REST API を読み出し専用にします。
DB のダンプ/リストアツールを使って、現在のレガシーネットワークの設定に対応する Networking のデータ構造を作成します。
nova-api プロキシーを有効にします。nova-api プロキシーは、(Networking REST API 経由で) Networking の情報から Compute の内部オブジェクトを再作成します。
Compute REST API を読み書き両用に戻します。この時点で、レガシーネットワーク用の DB は使用されなくなり、新しい変更は Networking DB に格納されなくなります。これ以降は新規の変更を保持したままロールバックはできません。

注釈

この時点で、Networking DB が真の情報源になりますが、 nova-api は唯一の公開された読み書き可能な API です。

次に、各ハイパーバイザーを移行する必要があります。以下の手順を行います。

ハイパーバイザーを無効にします。サポートされている場合は、対象のコンピュートノードからライブマイグレーションや退避 (evacuate) を行うよいタイミングでしょう。
nova-compute を無効化します。
Networking エージェントを有効化します。
Compute のハイパーバイザーデータベース/設定に “has_transitioned” フラグをセットします。
ハイパーバイザーを再起動します (もしくは「賢い」動かしたまま移行できるツールがあればそれを実行します)。
ハイパーバイザーを有効に戻します。

この時点で、すべてのコンピュートノードの移行が完了しましたが、依然として nova-api と Compute ゲートウェイが使用されています。最後に、以下の手順を行い OpenStack Networking を有効にします。

Networking ノード (L3 ノード) を立ち上げます。新しいルーターは Compute ゲートウェイと同じ MAC+IP を持つので、ある程度の即時の切り替えが可能です。ただし、NAT などの状態管理が必要なコネクションはこの限りではありません。
Networking API を読み書きモードにして、レガシーネットワークを無効にします。

これで移行は完了です!