Open vSwitchからOVN移行｜マルチテナントL2/L3仮想ネットワーク段階構築・切り戻し設計

Open vSwitchとOVNの違いを理解する

Open vSwitch（OVS）は長年にわたりLinux上の仮想スイッチング基盤として広く使われてきました。しかし、マルチテナント環境でL2/L3の論理ネットワークを大規模に管理しようとすると、OVS単体では制御プレーンの分散管理・ACLの一元管理・論理ルーターの扱いが複雑になりがちです。

OVN（Open Virtual Network）はOVSの上位レイヤーとして設計された論理ネットワーク抽象化フレームワークです。OVNはOVSのデータプレーン能力をそのまま活用しつつ、論理スイッチ・論理ルーター・ACL・NAT・ロードバランサーなどの概念を中央集権的に管理できる制御プレーンを提供します。

OVSとOVNの主な違いは以下の通りです。

• 制御プレーン：OVSはフロールールを個別ノードに直接設定する必要がありますが、OVNはovn-northdとovn-sbdbを中心とした集中管理で、論理ネットワーク定義が自動的にフロールールへ変換されます。
• 論理ルーター：OVNは論理ルーターをネイティブに持ち、テナント間・VLAN間のルーティングをソフトウェアで実装できます。OVS単体では外部ルーティングデーモンとの連携が必要でした。
• ACL管理：OVNはACLをポートグループ単位で定義でき、変更が全ノードに自動配布されます。OVSでは各ノードにフロールールを手動で同期する必要があります。

移行前の準備：既存OVS構成の把握と依存関係の整理

OVSからOVNへの移行は、既存ネットワーク構成をそのままOVNの論理モデルに対応させる作業です。移行前に現状を正確に把握しておくことが重要です。

現行OVS構成の確認コマンド

既存のブリッジ・ポート・フロー設定を把握するために、以下のコマンドで確認します。

# ブリッジ一覧
ovs-vsctl list-br

# 各ブリッジのポート確認
ovs-vsctl list-ports br-int

# フロールールの確認
ovs-ofctl dump-flows br-int

# OVSデータベース全体の確認
ovs-vsctl show

確認すべき項目として、VXLANトンネルの設定・VLANタグマッピング・外部ルーティング設定（BGP/OSPFデーモンとの連携）・セキュリティグループ相当のフロールールが挙げられます。これらをOVNの論理オブジェクト（Logical Switch、Logical Router、ACL）にどう対応させるかを移行前に設計しておきます。

OVNコンポーネントの構成確認

OVNは以下のコンポーネントで構成されます。

• ovn-northd：北向きDB（NB DB）を読み取り、論理ネットワーク定義をフロールールに変換して南向きDB（SB DB）に書き込むデーモン。
• OVN NB DB（ovn-nb）：論理ネットワーク定義を格納するOVSDBデータベース。管理者はここに論理スイッチ・ルーター・ACLを定義します。
• OVN SB DB（ovn-sb）：ovn-northdが生成したフロールールと、各ハイパーバイザーのChassis情報を格納します。
• ovn-controller：各ハイパーバイザーで動作し、SB DBを参照してローカルのOVSにフロールールを注入するデーモン。

段階的移行手順：テナントネットワークの切り替え

本番環境での移行は一括切り替えではなく、テナント単位での段階移行が推奨されます。以下に、ハイパーバイザー1台ずつOVNに移行する手順を示します。

OVNパッケージのインストールとデーモン起動

Ubuntu 24.04 / RHEL 9系での一般的なインストール手順は以下の通りです（パッケージ名はディストリビューションによって異なります）。

# Ubuntu 24.04
sudo apt install ovn-central ovn-host

# RHEL 9 / Rocky Linux 9
sudo dnf install ovn ovn-central ovn-host

# サービス起動（中央ノード）
sudo systemctl enable --now ovn-ovsdb-server-nb ovn-ovsdb-server-sb ovn-northd

# 各ハイパーバイザー上で起動
sudo systemctl enable --now ovn-controller

論理ネットワークの定義（NB DBへの設定）

テナントAのL2ネットワーク（192.168.10.0/24）を想定例として、論理スイッチと論理ルーターを定義します。

# 論理スイッチの作成
ovn-nbctl ls-add tenant-a-sw1

# 論理スイッチポートの作成（VMに対応）
ovn-nbctl lsp-add tenant-a-sw1 tenant-a-vm1
ovn-nbctl lsp-set-addresses tenant-a-vm1 "52:54:00:12:34:56 192.168.10.101"

# 論理ルーターの作成
ovn-nbctl lr-add tenant-a-router

# ルーターポートの作成
ovn-nbctl lrp-add tenant-a-router tenant-a-router-to-sw1 02:ac:10:01:00:01 192.168.10.1/24

# スイッチ側のルーターポートを接続
ovn-nbctl lsp-add tenant-a-sw1 tenant-a-sw1-to-router
ovn-nbctl lsp-set-type tenant-a-sw1-to-router router
ovn-nbctl lsp-set-addresses tenant-a-sw1-to-router router
ovn-nbctl lsp-set-options tenant-a-sw1-to-router router-port=tenant-a-router-to-sw1

ACLの設定

テナント内通信を許可し、テナント間通信を遮断するACLの設定例（想定例）を示します。

# デフォルト拒否ポリシーの設定
ovn-nbctl acl-add tenant-a-sw1 to-lport 100 "ip" drop
ovn-nbctl acl-add tenant-a-sw1 from-lport 100 "ip" drop

# 同一テナント内通信を許可
ovn-nbctl acl-add tenant-a-sw1 to-lport 200 "ip4.src == 192.168.10.0/24" allow-related
ovn-nbctl acl-add tenant-a-sw1 from-lport 200 "ip4.src == 192.168.10.0/24" allow-related

移行後の検証：疎通確認とフロールール確認

移行後は実際の通信確認とフロールールの整合性確認を行います。OVNには専用のトレーシングツールが用意されています。

ovn-traceによる論理パス確認

ovn-traceはパケットがOVNの論理パイプラインをどう通過するかをシミュレートするツールです。実際にパケットを流さずに設定の整合性を確認できます。

# tenant-a-sw1上でVM間通信をシミュレート（想定例）
ovn-trace tenant-a-sw1 \
  'inport == "tenant-a-vm1" &&
   eth.src == 52:54:00:12:34:56 &&
   eth.dst == 52:54:00:12:34:57 &&
   ip4.src == 192.168.10.101 &&
   ip4.dst == 192.168.10.102'

SB DBのフロー確認

ovn-northdが生成したフロールールがSB DBに正しく書き込まれているかを確認します。

# 論理フローの確認
ovn-sbctl lflow-list tenant-a-sw1

# Chassisの確認（各ハイパーバイザーが登録されているか）
ovn-sbctl show

# OVSへのフロー注入状況確認（各ハイパーバイザー上で実行）
ovs-ofctl dump-flows br-int | grep -i cookie

よくあるつまずき

移行後の確認で一般的に問題になる点として、以下が挙げられます。

• Chassisが登録されない：ovn-controllerがSB DBへ接続できていない場合に発生します。ovn-controllerのovn-remote設定（SB DBのIPアドレス）を確認してください。
• 論理ポートにChassis情報が紐付かない：VMのポートをOVSのインターフェースに紐付けるexternal_ids:iface-idが正しく設定されているかを確認します。
• ACLが意図通りに機能しない：ovn-traceで論理パイプラインをトレースし、どの段階でdropが発生しているかを特定します。

切り戻し設計：OVSへの復元手順

OVNへの移行後に問題が発生した場合の切り戻し手順も事前に設計しておきます。OVNはOVSの上に乗る形で動作しているため、切り戻しはovn-controllerを停止してOVSのフロールールを直接管理状態に戻す形になります。

切り戻し手順の概要

1. 対象ハイパーバイザーでovn-controllerを停止し、OVNが注入したフロールールを削除する。
2. 事前に取得しておいたOVSのフロールールスナップショットを復元する。
3. 外部ルーティングデーモン（FRRouting等）との再接続を確認する。
4. 通信疎通を確認後、次のハイパーバイザーへ切り戻しを展開する。

# 移行前のスナップショット取得（移行前に必ず実施）
ovs-ofctl dump-flows br-int > /var/backup/ovs-flows-br-int.txt

# ---（切り戻し時）---

# ovn-controllerの停止
sudo systemctl stop ovn-controller

# OVNのDB接続設定を解除
ovs-vsctl remove Open_vSwitch . external_ids ovn-remote

# OVNが注入したフロールールのクリア
ovs-ofctl del-flows br-int

# スナップショットからフロールールを復元
ovs-ofctl add-flows br-int /var/backup/ovs-flows-br-int.txt

重要なのは、移行前にスナップショットを取得しておくことです。OVNによるフロールール注入後はこのスナップショットが唯一の切り戻し基準となります。スナップショットファイルはノードごとに作成し、管理サーバー上にも保管しておくことが推奨されます。

段階移行中の並行運用リスク

一部のハイパーバイザーがOVN管理下で、残りがOVS直接管理の状態では、テナントVMが異なる管理ドメインに分散するケースがあります。この期間中はOVNとOVS間でVXLANトンネルが正しく確立されているか、BFD（Bidirectional Forwarding Detection）による検出が設定されているかを確認します。移行対象のハイパーバイザーをテナント単位でまとめて切り替える設計にすると、この期間を短縮できます。

2026年時点の現行環境差分と注意点

OpenStack NeutronとOVNの統合状況

OpenStack Zed以降、NeutronのOVNバックエンド（neutron-ovn-metadata-agent）が事実上の標準構成となっています。従来のML2/OVS構成からML2/OVNへの移行はOpenStack Antelope（2023）以降でサポートされており、2026年時点ではRHEL OpenStack Platform 18以降ではML2/OVNがデフォルト構成です。既存のML2/OVS環境を維持している場合は、将来的なサポート終了スケジュールを確認することが推奨されます。

OVNとKubernetes（OVN-Kubernetes）

OVN-KubernetesはKubernetesのCNIプラグインとしてOVNを利用する実装で、OpenShiftではデフォルトのネットワークバックエンドとして採用されています。KubernetesのServiceやNetworkPolicyがOVNの論理オブジェクトに直接マッピングされるため、OVNの概念を理解しておくとOVN-Kubernetesのトラブルシュートに応用できます。

OVSDBのraft対応とHA構成

OVN NB DB / SB DBはOVN 20.06以降でraftベースのクラスタリングをサポートしています。2026年時点では3ノード構成のraftクラスターが本番環境の標準的なHA構成です。移行時にスタンドアロン構成でテストを行った場合は、本番投入前にHA構成への切り替え手順も検証しておく必要があります。

# raftクラスターの状態確認
ovs-appctl -t /var/run/ovn/ovnnb_db.ctl cluster/status OVN_Northbound
ovs-appctl -t /var/run/ovn/ovnsb_db.ctl cluster/status OVN_Southbound

OVNのInterconnect機能（OVN IC）

OVN 21.09以降に実装されたOVN Interconnect（OVN IC）は、複数のOVNクラスターをまたいだ論理ネットワーク間のルーティングを実現する機能です。データセンター間・可用性ゾーン間の論理ルーティングをOVN ICで管理する構成が2025年以降増加しています。既存のOVS構成でBGPによるインターコネクトを実装していた場合、OVN ICへの置き換えが選択肢となります。ただし、OVN ICは実装が比較的新しいため、ディストリビューション同梱版のOVNバージョンがICをサポートしているかを事前に確認することが重要です。