# Overlay Networking Research Summary

**Date:** 2025-12-08  
**Task:** T015 S1  
**Status:** Research Complete

## Executive Summary

マルチテナントVMネットワーク分離のためのオーバーレイネットワーキングソリューションの調査結果。OVN、Cilium、Calico、カスタムeBPFソリューションを評価し、**OVNを推奨**する。

## 1. OVN (Open Virtual Network)

### アーキテクチャ
- **ベース**: OpenStack Neutronのネットワーク抽象化をOpen vSwitch (OVS)上に実装
- **コンポーネント**:
  - `ovn-northd`: 論理ネットワーク定義を物理フローに変換
  - `ovn-controller`: 各ホストでOVSフローを管理
  - `ovsdb-server`: ネットワーク状態の分散データベース
  - `ovn-nb` (Northbound DB): 論理ネットワーク定義
  - `ovn-sb` (Southbound DB): 物理フロー状態

### 機能
- ✅ マルチテナント分離（VXLAN/GRE/Geneveトンネル）
- ✅ 分散ルーティング（L3 forwarding）
- ✅ 分散ロードバランシング（L4）
- ✅ セキュリティグループ（ACL）
- ✅ DHCP/DNS統合
- ✅ NAT（SNAT/DNAT）
- ✅ 品質保証（QoS）

### 複雑さ
- **高**: OVSDB、OVNコントローラー、分散状態管理が必要
- **学習曲線**: 中〜高（OVS/OVNの概念理解が必要）
- **運用**: 中（成熟したツールチェーンあり）

### 統合の容易さ
- **PlasmaVMC統合**: OVN Northbound API（REST/gRPC）経由で論理スイッチ/ルーター/ポートを作成
- **既存ツール**: `ovn-nbctl`、`ovn-sbctl`でデバッグ可能
- **ドキュメント**: 豊富（OpenStack/OVN公式ドキュメント）

### パフォーマンス
- **オーバーヘッド**: VXLANカプセル化による約50バイト
- **スループット**: 10Gbps以上（ハードウェアオフロード対応）
- **レイテンシ**: マイクロ秒単位（カーネル空間実装）

## 2. Cilium

### アーキテクチャ
- **ベース**: eBPF（Extended Berkeley Packet Filter）を使用したカーネル空間ネットワーキング
- **コンポーネント**:
  - `cilium-agent`: eBPFプログラムの管理
  - `cilium-operator`: サービスディスカバリー、IPAM
  - `etcd`または`Kubernetes API`: 状態管理

### 機能
- ✅ マルチテナント分離（VXLAN/Geneve、またはネイティブルーティング）
- ✅ L3/L4/L7ポリシー（eBPFベース）
- ✅ 分散ロードバランシング
- ✅ 可観測性（Prometheusメトリクス、Hubble）
- ✅ セキュリティ（ネットワークポリシー、mTLS）

### 複雑さ
- **中**: eBPFの理解が必要だが、Kubernetes統合が成熟
- **学習曲線**: 中（Kubernetes経験があれば容易）
- **運用**: 低〜中（Kubernetesネイティブ）

### 統合の容易さ
- **PlasmaVMC統合**: Kubernetes API経由または直接Cilium API使用
- **既存ツール**: `cilium` CLI、Hubble UI
- **ドキュメント**: 豊富（Kubernetes中心）

### パフォーマンス
- **オーバーヘッド**: 最小（カーネル空間、eBPF JIT）
- **スループット**: 非常に高い（ハードウェアオフロード対応）
- **レイテンシ**: ナノ秒単位（カーネル空間）

### 制約
- **Kubernetes依存**: Kubernetes環境での使用が前提（VM直接管理は非標準）
- **VMサポート**: 限定的（主にコンテナ向け）

## 3. Calico

### アーキテクチャ
- **ベース**: BGP（Border Gateway Protocol）ベースのルーティング
- **コンポーネント**:
  - `calico-node`: BGPピア、ルーティングルール
  - `calico-kube-controllers`: Kubernetes統合
  - `etcd`または`Kubernetes API`: 状態管理

### 機能
- ✅ マルチテナント分離（BGPルーティング、VXLANオプション）
- ✅ ネットワークポリシー（iptables/Windows HNS）
- ✅ IPAM
- ✅ BGP Anycast（L4ロードバランシングに有用）

### 複雑さ
- **低〜中**: BGPの理解が必要だが、シンプルなアーキテクチャ
- **学習曲線**: 低（BGP知識があれば容易）
- **運用**: 低（シンプルな構成）

### 統合の容易さ
- **PlasmaVMC統合**: Calico API経由またはBGP直接設定
- **既存ツール**: `calicoctl`
- **ドキュメント**: 豊富

### パフォーマンス
- **オーバーヘッド**: 低（ネイティブルーティング）
- **スループット**: 高い（ハードウェアルーティング対応）
- **レイテンシ**: 低（ネイティブルーティング）

### 制約
- **BGP要件**: BGP対応ルーター/スイッチが必要（データセンター環境）
- **VMサポート**: Kubernetes統合が主（VM直接管理は限定的）

## 4. カスタムeBPFソリューション

### アーキテクチャ
- **ベース**: 独自のeBPFプログラムとコントロールプレーン
- **コンポーネント**: 独自実装

### 機能
- ✅ 完全なカスタマイズ性
- ✅ 最適化されたパフォーマンス
- ❌ 開発・保守コストが高い

### 複雑さ
- **非常に高**: eBPFプログラミング、カーネル開発、分散システム設計が必要
- **学習曲線**: 非常に高
- **運用**: 高（独自実装の運用負荷）

### 統合の容易さ
- **PlasmaVMC統合**: 完全にカスタマイズ可能
- **既存ツール**: 独自開発が必要
- **ドキュメント**: 独自作成が必要

### パフォーマンス
- **オーバーヘッド**: 最小（最適化可能）
- **スループット**: 最高（最適化可能）
- **レイテンシ**: 最小（最適化可能）

### 制約
- **開発時間**: 数ヶ月〜数年
- **リスク**: バグ、セキュリティホール、保守負荷

## 5. 比較表

| 項目 | OVN | Cilium | Calico | カスタムeBPF |
|------|-----|--------|--------|--------------|
| **成熟度** | 高 | 高 | 高 | 低 |
| **VMサポート** | ✅ 優秀 | ⚠️ 限定的 | ⚠️ 限定的 | ✅ カスタマイズ可能 |
| **複雑さ** | 高 | 中 | 低〜中 | 非常に高 |
| **パフォーマンス** | 高 | 非常に高 | 高 | 最高（最適化後） |
| **統合容易さ** | 中 | 高（K8s） | 中 | 低（開発必要） |
| **ドキュメント** | 豊富 | 豊富 | 豊富 | なし |
| **運用負荷** | 中 | 低〜中 | 低 | 高 |
| **開発時間** | 短（統合のみ） | 短（K8s統合） | 短（統合のみ） | 長（開発必要） |

## 6. 推奨: OVN

### 推奨理由

1. **VMファースト設計**: OVNはVM/コンテナ両方をサポートし、PlasmaVMCのVM中心アーキテクチャに最適
2. **成熟したマルチテナント分離**: OpenStackでの実績があり、本番環境での検証済み
3. **豊富な機能**: セキュリティグループ、NAT、ロードバランシング、QoSなど必要な機能が揃っている
4. **明確なAPI**: OVN Northbound APIで論理ネットワークを定義でき、PlasmaVMCとの統合が容易
5. **デバッグ容易性**: `ovn-nbctl`、`ovn-sbctl`などのツールでトラブルシューティングが可能
6. **将来の拡張性**: プラガブルバックエンド設計により、将来的にCilium/eBPFへの移行も可能

### リスクと軽減策

**リスク1: OVNの複雑さ**
- **軽減策**: OVN Northbound APIを抽象化したシンプルなAPIレイヤーを提供
- **軽減策**: よく使う操作（ネットワーク作成、ポート追加）を簡素化

**リスク2: OVSDBの運用負荷**
- **軽減策**: OVSDBクラスタリングのベストプラクティスに従う
- **軽減策**: 監視とヘルスチェックを実装

**リスク3: パフォーマンス懸念**
- **軽減策**: ハードウェアオフロード（DPDK、SR-IOV）を検討
- **軽減策**: 必要に応じて将来的にCilium/eBPFへの移行パスを残す

### 代替案の検討タイミング

以下の場合、代替案を検討：
1. **パフォーマンスボトルネック**: OVNで解決できない性能問題が発生
2. **運用複雑さ**: OVNの運用負荷が許容範囲を超える
3. **新機能要求**: OVNで実現できない機能が必要

## 7. 結論

**推奨: OVNを採用**

- マルチテナントVMネットワーク分離の要件を満たす
- 成熟したソリューションでリスクが低い
- PlasmaVMCとの統合が比較的容易
- 将来の最適化（eBPF移行など）の余地を残す

**次のステップ**: S2（テナントネットワークモデル設計）に進む