仮想ネットワークの有効化
有効化はデータセンター上のウィザードから行います: データセンター › 仮想ネットワーク › 有効化（Activate）。どのモードでも同じ 5 つのステップを実行しますが、ステップ 2 の内容がモードによって異なります。
ライセンス
有効化には、Cockpit ライセンスに仮想ネットワークの権利（エンタイトルメント）が必要です。ライセンスに含まれていない場合は、サブスクリプションに追加して更新されたライセンスをインポートしてから開始してください（概要の注意点を参照）。
開始する前に、データセンター内のすべてのホストが Cockpit に接続されている必要があります。ウィザードは各ホストに対応可能な機能を問い合わせるため、通信できないホストを含めることはできません。
ステップ 1 — 名前とモード
デプロイメントに名前を付け、概要で説明した 3 つのモードから 1 つを選択します。モードは後から変更できません。切り替えるには、一度無効化してから再度有効化する必要があります。
ステップ 2 — 各モードに必要な設定
Vapor ネイティブ OVN デプロイメントの形成
セントラルを選択します。これは OVN データベースを RAFT クラスターとして実行するホストです。
- 1、3、または 5 台。 ウィザードは 2 台および 4 台を拒否します。偶数は、それより 1 つ少ない奇数よりも決定的に劣ります。2 台のセントラルはお互いに過半数票を取ることができないため、いずれか 1 台がダウンするとクラスター全体がダウンします。
- クラスターへの分散配置。 データセンターに 3 つ以上のクラスターがある場合、ウィザードはデフォルトで 1 クラスターにつき 1 台のセントラルを割り当てます。クラスターは通常、ラックや障害ドメインに対応します。1 つのラック内に 3 台のセントラルを配置するとホスト障害には耐えられますが、ラック障害には耐えられません。
- 既存のデータベース。 選択したセントラルが以前の運用から OVN データベースをすでに保持している場合、事前チェックでそれが警告されます（下記参照）。それらのファイルには、以前提供していた論理構成全体が含まれている可能性があります。ウィザードは明示的な確認なしにそれらを上書き・置換することはありません。
データセンター内の他のすべてのホストはシャーシとして参加します。単一セントラルのデプロイメントも動作しますが、冗長性はありません（ラボ環境向けです）。
既存の外部 OVN デプロイメントへの参加
ノースバウンドおよびサウスバウンドのデータベースアドレスを入力します（例: tcp:10.0.0.1:6641 および tcp:10.0.0.1:6642）。
外部データベースがクラスター化されている場合は、カンマ区切りですべてのメンバーを列挙してください: tcp:10.0.0.1:6641,tcp:10.0.0.2:6641,tcp:10.0.0.3:6641。OVN クライアントはクラスターリーダーとのみ通信するため、単一のアドレスだけを指定すると、リーダーシップが他のメンバーに移った瞬間に通信できなくなります。データベースに TLS が必要な場合は、tcp: の代わりに ssl: を使用してください。
ブリッジマッピングは任意であり、すべてのホストに適用されます。外部デプロイメントがプロバイダーネットワークを要求していない限り、空のままで構いません。
既存の Kube-OVN クラスターへの参加
ここでは何も手入力しません。ウィザードは各ホストを検出し、検出結果を表示します。
| 項目 | 意味 |
|---|---|
| Kube-OVN | そのホストで kube-ovn が稼働しているかどうか。ホストに kubeconfig がある場合は Kubernetes API 経由で検出し、ない場合はホスト上の kube-ovn デーモンから直接検出します（ワーカーノードには通常 kubeconfig がありません）。 |
| Node | Kubernetes のノード名。 |
| --enable-external-vpc | kube-ovn-controller のフラグ。下記の危険警告を参照してください。 |
| Northbound (discovered) | kube-ovn が報告したデータベースアドレス。 |
デプロイメントのアドレスは、最初に応答したホストのアドレスで自動入力され、読み取り専用で表示されます。CNI の検出結果よりも確実に正しいと判断できる場合のみ、Override the discovered addresses にチェックを入れて上書きしてください。ホストごとに異なるアドレスが報告される場合、それらは異なる kube-ovn クラスターに属しており、1 つのデータセンターは 1 つのクラスターにしか参加できません。
kube-ovn ノードでないホストは除外されます
kube-ovn ノードではないホストは、このモードに参加できません。もし参加させると、kube-ovn が認知していないシャーシとしてサウスバウンドデータベースに登録されてしまい、kube-ovn のコントローラーが再起動するたびに未知のシャーシとして削除されてしまいます。同様に、Vapor に OVN クライアントツールがインストールされていないノードも、参加したデータベースを読み取ることができないため参加できません。
そのようなホストは理由とともに excluded（除外）として記録され、設定は一切適用されません。後から参加させるには、原因を修正（kube-ovn、または ovn-common と openvswitch-switch パッケージをインストール）した上で、Sync を実行してください。
--enable-external-vpc フラグ
kube-ovn のコントローラーは、ノースバウンドデータベースを自身の排他的な管理対象として扱います。Kubernetes リソースにマッピングできないオブジェクトはすべてリークとみなしてクリーンアップします。論理スイッチポートは 360 秒タイマーで、論理スイッチとルーターはコントローラー再起動時に一括で削除されます。この外部オブジェクトの削除を免除するスイッチが、kube-ovn-controller デプロイメントの --enable-external-vpc=true フラグであり、デフォルトは false になっています。
このフラグが有効になっていないと、Cockpit を通じて作成したすべてのネットワークは、コントローラーが次回再起動するまでしか残らず、その後消滅してしまいます（数週間後に再起動され、誰も原因を結び付けられない状態になる恐れがあります）。事前チェックでこのフラグが報告されます。設定されていない場合、ウィザードは明示的な確認の同意なしには適用を進めません。事前にフラグを設定することを推奨します。
ステップ 3 — ホストとカプセル化
データセンター内のホストごとに 1 行ずつ、Geneve トンネルに使用するカプセル化 IP が表示されます。ウィザードはホスト自身が提案した内容から自動入力します。ホストがトンネルトラフィック用により適したインターフェース（専用のストレージネットワークやオーバーレイネットワークなど）を持っている場合は、該当行を編集してください。
ウィザードが強制する 2 つのルール:
- 1 ホストにつき 1 アドレス。 2 台のホストが同じカプセル化 IP を共有すると、トンネルが確立しないファブリックが形成されてしまいます。
- あるホストのアドレスを別のホストへコピーしないこと。 各行は該当ホスト独自のアドレスである必要があります。
Vapor ネイティブモードでは、セントラルのカプセル化 IP が、各ホストが接続するデータベースアドレスにもなります。
ステップ 4 — 事前チェック (Preflight)
ウィザードは変更を加える前に、データセンター全体を検証します。各チェックはホストごとに詳細とともに表示されます。fail は有効化をブロックし、warn は確認と同意が必要となります。
| チェック項目 | 検証内容 |
|---|---|
| Central quorum | 1、3、または 5 台のセントラル（Vapor ネイティブ）。 |
| Encapsulation path | すべてのホストが他のすべてのホストのカプセル化 IP に到達できること。これは単なるサブネットの比較ではなく、ホスト間の実際の実機プローブ（通信確認）です。 |
| Geneve MTU headroom | トンネル化された 1500 バイトのゲストフレームサイズのパケットを用いた実プローブ。ここでの warn は、通信経路自体は機能しているものの、このファブリック上のゲストはより小さい MTU（1500 バイトアンダーレイで 1442）を使用するか、アンダーレイを 1558 に引き上げる必要があることを意味します。これを放置すると、接続はできるもののフルサイズパケットを通過できない VM ができてしまいます。 |
| Existing OVN databases | セントラル候補のホストにすでにデータベースファイルが存在しているか。稼働中のクラスターに属している場合は合格しますが、スタンドアロンの場合は警告され、replace databases（データベース置換）の確認が表示されます（事前にバックアップしてください）。 |
| Kube-OVN membership | 各ホストが参加可能かどうか。除外されたホストは理由とともに一覧表示されます。 |
| Kube-OVN external VPC | 前述のコントローラーフラグの確認。 |
| Per-host checks | Vapor による各参加ホストの事前チェック: パッケージが存在するか、データベースに到達可能か、そのホストでカプセル化 IP が有効か、参加するセントラルが参加先クラスターメンバーに到達可能か。 |
エラー（fail）がなく、すべての警告（warn）を確認・承認すると、有効化に進むことができます。
ステップ 5 — 適用と検証
ウィザードは進行状況に応じて各ホストの状態を表示します。Vapor ネイティブモードでは、設計上順次実行されます（最初のセントラルがブートストラップし、他のセントラルが 1 台ずつ参加し、その後にシャーシが並列に参加します）。そのため、一瞬ではなく数十秒かかります。
各ホストは 2 つのレベルで報告されます: applied（Vapor が設定を受け入れた）および registered（ホストがサウスバウンドデータベースにシャーシとして実際に登録された）。ホストは一方が完了していてももう一方が完了していない場合がありますが、ウィザードがどちらの状態であるかを正確に伝えます。
完了時:
- Active — すべてのホストが正常に参加しました。Finish をクリックするとデプロイメント画面に移動します。
- Partial または Error — 一部のホストが失敗しました。失敗したホストごとにエラーが表示されます。Retry failed hosts はすべてのメンバーに再適用し、メンバーリストを再配布します。Close はデプロイメントをそのままの状態にし、仮想ネットワークタブにも同じ状態と再試行オプションが表示されます。
一部が失敗する（Partial）最も一般的な原因は、適用時にホストに接続できなかったことです。原因を解決して再試行してください。事前に何かを取り消す必要はありません。
有効化後の流れ
すべてのホストの Host › 設定 › ネットワーク › 仮想ネットワーク にシャーシ情報が表示され、データセンターのタブにはファブリックのインベントリが表示されるようになります。その後の日常的な運用手順については、仮想ネットワークの運用で解説しています。