手当たり次第に書くんだ

飽きっぽいのは本能

Xen は NFV 基盤に使えるのか – 機能より製品認定が問題になる

Xen は、VMware ESXi に比較的近い構造を持つオープンソースのハイパーバイザーです。

Linux カーネルに仮想化機能を組み込む KVM とは異なり、Xen Hypervisor がハードウェア上で直接動作し、その上に管理用の Dom0 とゲスト用の DomU が配置されます。

では、Xen は通信事業者の NFV 基盤として使えるのでしょうか。

結論から言えば、Xen は NFV に必要な機能を備えています。問題は機能の有無ではなく、搭載する仮想アプライアンスが、その Xen 製品と構成を正式にサポートしているかです。

NFV に必要な制御機能は備えている

NFV では、仮想マシンが起動するだけでは不十分です。パケット処理性能や遅延を安定させるため、CPU、メモリ、NIC の配置を制御する必要があります。

機能Xen の対応用途
SR-IOV対応NIC の VF を VM へ直接割り当てる
CPU ピニング対応vCPU を特定の物理 CPU へ固定する
HugePage対応TLB ミスやページ管理の負荷を抑える
NUMA 配置対応CPU、メモリ、NIC の物理的な距離を揃える
PCI パススルー対応物理デバイスを VM へ直接割り当てる

SR-IOV の VF、ピニングした CPU、HugePage を割り当てたメモリを同じ NUMA ノードへ寄せる、といった設計も可能です。

したがって、「Xen には NFV 向けの性能機能が足りない」という理解は正しくありません。

参考
書籍
参考書籍

作って理解する仮想化技術

ハイパーバイザー、仮想 CPU、メモリ、I/O など、仮想化基盤の下回りを確認したい場合の参考書籍です。価格や在庫、内容はリンク先で確認してください。

Amazon で見る

このリンクは Amazon アソシエイトリンクです。

Xen から KVM へ主流が移った構造

Xen は特殊なハイパーバイザーではありません。かつては Red Hat 系 Linux でも標準的な仮想化基盤でした。

RHEL 5 では Xen がサポートされ、途中から KVM も追加されました。RHEL 6 ではホスト側の仮想化基盤が KVM へ一本化され、CentOS もこの方針を引き継ぎました。

この変化を、Xen と KVM の機能差だけで説明することはできません。重要なのは、Linux カーネル本流との関係です。

KVM は 2007 年 2 月公開の Linux 2.6.20 でカーネル本流へ統合されました。通常の Linux カーネルそのものを仮想化基盤として発展させられるため、カーネルの開発、デバイスドライバ、保守の流れに乗りやすい構造でした。

一方、Xen では Dom0 として動作するための機能が長く Linux カーネル本流に揃わず、ディストリビューション側は Xen 用のパッチを含むカーネルを維持する必要がありました。基本的な Dom0 対応が Linux 2.6.37 に入り、ネットワークバックエンドが 2.6.39、ブロックバックエンドが 3.0 に入ることで、Linux 3.0 世代になって一通りの Dom0 機能が本流で利用できるようになりました。

つまり、主流の移動には次のような非対称性がありました。

XenKVM
Xen 用 Dom0 カーネルの差分を維持する必要があった通常の Linux カーネルに統合された
ハイパーバイザーと Linux の境界をまたいで保守するLinux の開発・保守基盤をそのまま利用できる
Dom0 機能の本流統合に時間を要した2007 年からカーネル本流で発展した

これは、単に「人気が KVM へ移った」という話ではありません。アップストリームとの距離が保守コストを左右し、その上に QEMU、libvirt、OpenStack、各 Linux ディストリビューションの対応が積み上がりました。

なお、これだけを RHEL 6 が KVM を選んだ唯一の理由と断定することはできません。しかし、KVM 側へ開発と製品対応が集まりやすくなった構造的な背景としては重要です。

「起動できる」と「正式に提供できる」は別である

仮想アプライアンスの対応状況を確認すると、「VMware と KVM は対応し、Xen はすべて非対応」という単純な構図ではないことが分かります。

製品公式資料から確認できる位置づけ
F5 BIG-IP VELinux KVM、Xen Project、Citrix XenServer、VMware ESXi などをサポート
Cisco CSR 1000VVMware ESXi、KVM、Citrix XenServer、Hyper-V などをサポート
Cisco Catalyst 8000V現行の導入ガイドは VMware ESXi、KVM、主要パブリッククラウドなどを案内し、Xen を展開先として列挙していない
Palo Alto VM-Series現行のプライベートクラウド対応一覧は ESXi、KVM、Nutanix、Hyper-V、OpenStack などを列挙し、Xen を含めていない

ここで重要なのは、Xen 対応製品が存在しないことではありません。実際に F5 BIG-IP VE は Xen Project の導入手順を公開しており、旧 Cisco CSR 1000V も Citrix XenServer と Xen 用のVIF-netfrontを正式に扱っていました。

一方で、後継の Cisco Catalyst 8000V では現在の導入先として Xen が列挙されず、Palo Alto VM-Series の現行対応一覧にも Xen はありません。

したがって問題は、Xen という方式が技術的に動くかではなく、使用する製品とバージョンについて、採用予定の Xen 実装まで認定が継続されているかです。

たとえば、KVM 向けの QCOW2 イメージを変換または調整し、Xen 上で起動できる可能性はあります。しかし、起動に成功しても正式サポートを意味しません。非認定環境で障害が発生すれば、ベンダーから認定環境での再現を求められることが想定されます。これは実際の回答を引用したものではなく、非認定構成を採用した場合に一般に生じるサポート上のリスクです。

認定はハイパーバイザー名だけでは決まらない

もう一つ注意すべきなのは、「Xen 対応」「KVM 対応」という名前だけで判定できないことです。

たとえば、Xen Project、Citrix XenServer、XCP-ng、AWS EC2 は、すべて Xen との関係を持ちますが、同じ認定構成ではありません。AWS 上の製品対応が、そのままオンプレミスの XCP-ng 対応を意味するわけではありません。

また、F5 の対応表では KVM でvirtioを利用する場合の条件や、構成によって SR-IOV がサポートされない可能性まで記載されています。Palo Alto VM-Series も、KVM 上で SR-IOV を使用する場合はインターフェースを Layer 3 として構成する条件を示しています。

つまり、サポート対象は次の組み合わせで決まります。

  • 製品名と製品バージョン
  • Xen Project、XenServer、XCP-ng などの基盤製品とバージョン
  • 仮想 NIC と仮想ディスクのドライバ
  • SR-IOV で使用する NIC、VF ドライバ、ファームウェア
  • CPU モデル、CPU ピニング、NUMA 配置
  • HugePage の使用条件
  • ライブマイグレーションなどの運用機能
  • 障害時にベンダーが再現環境として認める構成

共通基盤では認定範囲も機能になる

自社開発システムだけを載せるのであれば、Xen を自分たちで検証し、必要な構成を作り込むことはできます。

しかし、複数ベンダーの仮想ルーター、ファイアウォール、ロードバランサーを載せる共通基盤では事情が異なります。ある製品が現在は Xen に対応していても、その後継製品や将来バージョンで対応が継続されるとは限りません。

共通基盤の価値は、ハイパーバイザー単体の性能だけでは決まりません。搭載できる製品の種類、認定構成の幅、アップグレード経路、障害時の支援まで含めて決まります。この意味では、エコシステムと認定範囲も基盤機能の一部です。

まとめ

Xen は、SR-IOV、CPU ピニング、HugePage、NUMA 配置など、NFV に必要な制御機能を備えています。技術的に NFV へ不向きなハイパーバイザーではありません。

ただし、商用 VNF の共通基盤として採用する場合は、次の順序で確認する必要があります。

  1. 搭載予定の全製品について、Xen 系基盤の正式対応を確認する
  2. 「Xen 対応」を製品名とバージョンまで分解し、XCP-ng など採用予定の実装が対象か確認する
  3. SR-IOV、VF ドライバ、CPU ピニング、NUMA、HugePage を使用した構成も認定範囲か確認する
  4. バージョンアップ後も対応が継続されるか、後継製品を含めて確認する
  5. 障害時にベンダーが認定環境での再現を要求する条件を確認する
  6. 以上を満たした後で、性能と運用性を PoC する

Xen で「動かせるか」と、Xen 上で商用サービスとして「提供し続けられるか」は別の問題です。

ハイパーバイザー選定では、機能表だけでなく、製品認定が将来にわたって維持される範囲まで評価する必要があります。

参考資料

あわせて読みたい:

Xen は NFV 基盤に使えるのか – 機能より製品認定が問題になる

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)

トップへ戻る