NFV 実装の主要な利点は以下のとおりです。

Red Hat OpenStack Platform では、OVS-DPDK および SR-IOV 設定の自動化が追加され、NFV デプロイメントがサポートされています。さらに、ハイパーコンバージドインフラストラクチャー (HCI: Hyper-converged Infrastructure) ソリューションをお求めのお客様は、コンピュートのサブシステムと Red Hat Ceph Storage ノードを共存させることができます。NFV ユースケースにおいて、このハイパーコンバージドモデルを使用すると、初期コストの軽減、初期デプロイメントのフットプリントの縮小、稼働率の最大化、管理の効率化などが実現されます。また、一部制約はありますが、Real-Time KVM ハイパーバイザーなどのテクノロジープレビューサービスのデプロイメントもサポートしています。テクノロジープレビューとして提供されている機能のサポート範囲に関する詳しい情報は、「テクノロジプレビュー機能のサポート範囲」を参照してください。

コンポーザブルロールを使用して、カスタムのデプロイメントロールを作成できるようになりました。コンポーザブルロールを使用すると、各ロールにサービスを追加/削除することができます。

コンポーザブルロールに関する詳しい情報は「コンポーザブルサービスとカスタムロール」を参照してください。

欧州電気通信標準化機構 (ETSI) は、ヨーロッパの情報通信技術 (ICT: Information and Communication Technology) の標準を開発する独立した標準化組織です。

ネットワーク機能の仮想化 (NFV) は、プロプライエタリーのハードウェアデバイスの使用に伴う問題への対処に重点を置いています。NFV を使用すると、ユースケースの要件や経済的な利点によっては、ネットワーク固有の設備をインストールする必要性が軽減されます。ETSI Industry Specification Group for Network Functions Virtualization (ETSI ISG NFV) は、VF を確実にサポートするために必要な要件、リファレンスアーキテクチャー、インフラストラクチャー仕様を設定します。

Red Hat では、通信事業者 (CSP) の IT とネットワークのコンバージェンス実現を支援するオープンソースベースのクラウド最適化ソリューションを提供しています。Red Hat OpenStack には、SR-IOV や DPDK-OVS などの NFV 機能を追加しています。

通常、NFV プラットフォームには以下のコンポーネントが含まれます。

Red Hat の NFV 向けのソリューションには、ETSI モデルに含まれる NFV フレームワークの異なるコンポーネントとしての役割を果たすことのできる各種製品が含まれます。NFV ソリューションには、Red Hat ポートフォリオの以下の製品が統合されます。

Red Hat OpenStack Platform director は完全な OpenStack 環境をインストールおよび管理します。director は、アップストリームの OpenStack TripleO プロジェクトをベースとしています。TripleO とは、「OpenStack-On-OpenStack」の頭文字の「O」が 3 つあることを意味しています。このプロジェクトは、OpenStack コンポーネントを活用して、完全に機能する OpenStack 環境をインストールします。これには、アンダークラウドと呼ばれる、最小限の OpenStack ノードが含まれます。アンダークラウドは、オーバークラウド (実稼働環境用の OpenStack ノードとして使用される一連のベアメタルシステム) のプロビジョニングと制御を行います。director は、リーンかつ堅牢な Red Hat OpenStack Platform の完全な環境を簡単にインストールできる方法を提供します。

アンダークラウドおよびオーバークラウドのインストールに関する詳しい情報は『Red Hat OpenStack Platform director のインストールと使用方法』を参照してください。

NFV 機能をインストールするには、以下の設定手順を追加で行う必要があります。

NFV のプランニングガイドラインと設定については、『ネットワーク機能仮想化 (NFV) のプランニングおよび設定ガイド』を参照してください。

高速データパスには、以下のようなオプションがあります。

以前は、x86 システムの全メモリーは、システム内のどの CPU からでも同等にアクセスできていたために、システム内で操作を行う CPU、Uniform Memory Access (UMA) を参照する CPU がどれでも、メモリーのアクセス時間は同じでした。

Non-Uniform Memory Access (NUMA) では、システムメモリーは、特定の CPU またはソケットに割り当てられるノードと呼ばれるゾーンに分割されます。CPU のローカルにあるメモリーには、そのシステムのリモートの CPU に接続されているメモリーにアクセスするよりも高速です。通常、NUMA システム上のソケットにはそれぞれローカルのメモリーノードがあり、別の CPU のローカルにあるノードのメモリーや、全 CPU で共有されるバス上のメモリーよりもコンテンツに早くアクセスできます。

同様に、物理 NIC はコンピュートノードのハードウェア上の PCI スロットに配置されます。これらのスロットは、特定の NUMA ノードに関連付けられた特定の CPU ソケットに接続されます。 パフォーマンスを最適化するには、CPU の設定で指定されているのと同じ NUMA ノードにデータパス NIC を接続します。

NUMA を使用しない場合のパフォーマンスへの影響は大きく、一般的に、パフォーマンス 10 % 以上が影響を受けます。各 CPU ソケットには、仮想化を目的とする個別の CPU として扱われる複数の CPU コアを配置することができます。

OpenStack Compute は、インスタンスの起動時にスマートなスケジューリングや配置の意思決定を行います。管理者はこのような機能を活用すると、NFV や高性能コンピューティング (HPC) などの特化されたワークロードを対象にするカスタマイズされたパフォーマンスフレーバーを構築することができます。

以下の図では、2 つのノードからなる NUMA システムの例と、CPU コアとメモリーページを利用可能にする方法の例が提供されています。

CPU ピニングは、指定のホスト内にある特定の物理 CPU 上で特定の仮想マシンの仮想 CPU を実行する機能のことです。vCPU ピニングでは、ベアメタルシステムへのピニングタスクと同様の利点が得られます。仮想マシンは、ホストのオペレーティングシステムのユーザー空間タスクとして実行されるので、ピニングすることでキャッシュの効率性が向上されます。

詳しい情報は、「Configure CPU Pinning with NUMA」を参照してください。

物理メモリーは、ページと呼ばれる連続した一連のリージョンに分割されます。効率化を図るため、システムは、各メモリーバイトにアクセスするのではなく、ページ全体にアクセスしてメモリーを取得します。このような変換を実行するには、システムは、最新のページまたは頻繁に使用されるページの物理から仮想アドレスのマッピングが含まれるトランスレーションルックアサイドバッファー (TLB: Translation Lookaside Buffers) をチェックします。検索したマッピングが TLB にない場合には、プロセッサーは全ページテーブルで同じ処理を反復して、アドレスマッピングを判断する必要があるため、パフォーマンスペナルティーの原因となります。そのため、対象のプロセスがなるべく TLB ミスを回避できるように TLB を最適化することが推奨されます。

x86 システムの一般的なページサイズは 4KB で、他にこれよりもページサイズが大きいものもあります。ページサイズが大きいと、全体的なページ数が少なくなるので、TLB に仮想から物理アドレスの変換を保存可能なシステムメモリー量が増えることになります。その結果、TLB ミスの可能性が低くなり、パフォーマンスが向上します。ページサイズが大きいと、プロセスはページに割り当てる必要があため、メモリーを無駄にする可能性が高くなりますが、すべてのメモリーが必要となることはあまりありません。そのため、ページサイズを選択する際には、より大きいページを使用してアクセス時間を早くするか、より小さいページを使用して最大限にメモリーが使用されるようにするかで、トレードオフが生じます。