vSphere 管理者向けの OpenShift Virtualization：ネットワーク構成の概要

OpenShift Virtualization は、アプリケーションにコンテナ化アーキテクチャを採用してモダナイゼーションを進めているが、仮想化もデータセンターのデプロイ戦略に欠かせないと考える企業向けの Red Hat のソリューションです。

率直に言って、コンテナ化できないアプリケーションもまだ一部存在しますが、それは問題ありません。OpenShift Virtualization は、コンテナと仮想マシンの必要性を統合プラットフォームでまとめて管理する、より先進的なパラダイムを提供することでこの問題に対処します。

Red Hat が対処しなければならない懸念の 1 つは、お客様が新しいソリューションをスムーズに導入できるよう、同等の機能を提供するほか、お客様が慣れ親しんでいる製品や構成と同様のカスタマーエクスペリエンスを維持するにはどうすればよいかということです。

情報テクノロジー・エコシステムでの作業に慣れた人は通常、慣れ親しんだ原則を新しいシステムに適用しようとします。多くのシステム管理者にとって、データセンター仮想化ソリューションといえば VMware vSphere でした。この環境で作業する人々は多くの設計ソリューションを導入しましたが、それらは仮想マシンや仮想データセンターのデプロイと設定のベストプラクティスとして採用されてきたものでした。IT の分野に携わる人々にとって、そうした設計上の決定はほとんど常識のようになっており、計画中の他の環境でも同様の決定を適用しようとします。

このブログシリーズでは、企業とその仮想化管理者が以前のハイパーバイザー環境を取り扱ってきた方法と、OpenShift Virtualization の環境で同様のアクションや構成を実行する方法の間の違いについて見ていきます。

まず、複数ネットワーク設計に焦点を当てます。これは、VMware vSphere などの他の仮想化ソリューションで一般的に使用されています。仮想化環境に精通している人であれば、これは ESXi ホストがさまざまなネットワークをサポートし、各仮想ネットワークが仮想データセンター内の異なる機能を担う設計であることをご存じでしょう。このネットワークの分離は、ホスト上の物理 NIC をそれぞれ別のスイッチやネットワークアップストリームとケーブル接続する、アップリンクを介して追加の VLAN をトランキングしてハイパーバイザー内の vSwitch または Distributed vSwitch で目的に基づいて適切にタグ付けされていることを確認するなど、いくつかの方法で実現できます。通常、ネットワークは少なくとも次のように細分化されます。

1. ESXi ホスト、vCenter 仮想マシン、およびデプロイ対象となるその他のサードパーティ管理ホストのための管理ネットワーク
2. ESXi ホストがホスト間でゲストのライブマイグレーション (vMotion と呼ばれる機能) をサポートし、高可用性を実現するためのホスト移行ネットワーク 
3. 仮想マシンにバッキングストレージまたはゲストマッピングされたストレージを提供するストレージリソースに ESXi ホストがアクセスするためのホストストレージネットワーク
4. 仮想ゲスト自体にネットワーク接続を提供する仮想マシンネットワーク

上記に加えて、顧客環境のユースケースに応じて、独自のネットワーク構成と用途が生じるのが一般的です。仮想スイッチングは、その性質上、多数のさまざまな構成を簡単に実装できます。一般的な方法でネットワークを定義することに慣れている人たちは、OpenShift Virtualization のような、異なる方法で行うソリューションの導入を決定する際に驚くかもしれませんが、これは自然なことです。

以降のセクションでは、上記の主なユースケースを個別に見ていき、OpenShift Virtualization がこれらのニーズにどのように対処するかを説明します。

デフォルトでは、OpenShift Virtualization は単一の内部 pod ネットワークとともにインストールされます。Kubernetes 環境にデプロイされるその他のアプリケーションと同様、この内部ネットワークは pod のライフサイクル中に pod 自体との通信に使用されます。仮想ゲストに対するあらゆる基本的な管理機能は、OpenShift コンソール、virtctl CLI ユーティリティー、または oc コマンドを使用して、内部 API ネットワークを介して実行できます。OpenShift Virtualization のこのネットワークは、VMware vSphere の内部管理ネットワークと基本的に同じ動作を実行します。

上記の単純な構成で説明した管理機能のように、OpenShift 環境のすべてのネットワーク機能はデフォルトの pod ネットワーク上で処理することが可能ですが、多くの場合、これは望ましいとは言えません。仮想ゲストのマイグレーションやストレージアクセスなどの一部のタスクは、専用ネットワークによる直接アクセスを行ったほうが大きなメリットを得られます。移行ポリシーを使用して使用帯域幅を制限し、ゲストのマイグレーションなど特定のアクションのパフォーマンスを調整することはできますが、ほとんどの企業ユーザーにとって、ゲストのマイグレーション、ストレージ、仮想ゲストアクセスなどの追加機能にはそれ専用のネットワークを使用することが望ましく、また、VMware vSphere 環境を運用した経験がある場合はより親しみのある方法でもあります。

そのため、OpenShift は、Multus CNI プラグインを使用してこれを実行します。これにより、ワーカーノードで使用可能な追加のネットワークインタフェース、SR-IOV、または Linux ブリッジデバイスを構成し、必要に応じて個々の pod にアタッチすることが可能になります。

Multus をインストールする前に、基盤となるネットワークを適切に設定する必要があります。Linux ブリッジの場合は、 nmstate Operator を使用して実行します。SR-IOV デバイスの場合は、SR-IOV Operator を使用します。ネットワーク環境を設定したら、追加の物理インタフェース、SR-IOV デバイス、またはそれらを定義する Linux ブリッジの使用方法を OpenShift に指示するネットワークアタッチメント定義の設定を開始できます。

次に、ライブマイグレーションの設定について詳しく見ていきます。ライブマイグレーションは多くの帯域幅を必要とするため、VMware vSphere のデプロイメントには、多くの場合、vMotion をサポートするために定義された専用のネットワークがあります。専用のネットワークがないインフラストラクチャでライブマイグレーションのイベントが発生した場合、仮想ゲストなどの共有ネットワークリソースに悪影響がもたらされることがあります。また、ノードが使用不能になって複数のゲストを同時にマイグレーションせざるを得なくなった場合、その影響は環境自体の管理にも及ぶ可能性があります。OpenShift Virtualization には、ライブマイグレーションのイベントがクラスタのプライマリーネットワークやパフォーマンスに悪影響を与えないようにするオプションが複数あります。

1 つ目は、マイグレーションに使用できる帯域幅の量を制限するなどのルールを含む移行ポリシーを定義することです。また、OpenShift Virtualization の [Overview] 設定でクラスタ設定を変更し、ライブマイグレーション専用のネットワークを定義することもできます。このメニューでは、一度に実行できるライブマイグレーションの数を制限し、帯域幅を確保することもできます。また、それらのライブマイグレーションに使用するネットワークを変更することもできます。

これを行うには、ワーカーノード上の専用のネットワークインタフェースに対するネットワークアタッチメント定義を作成し、仮想化をサポートするように設定されたワーカーノード間のみの接続を許可するプライベートネットワークを定義して、それを選択します。こうすると、ゲストがマイグレーション対象として選択されたり、ホストがメンテナンス状態になってすべてのゲストが退避する必要が生じたりしたときに、ライブマイグレーション専用のネットワークが使用されるので、プライマリー OpenShift ネットワーク・インフラストラクチャへの負担が増加することを防げます。

ストレージリソースのネットワークは、OpenShift クラスタに使用されているストレージプロバイダーによって異なります。多くのストレージプロバイダーには自社ストレージシステム用のネイティブ CSI 準拠ドライバーがあり、ストレージ接続に関して自社で指定したベストプラクティスを自動的に適用します。

仮想ゲストをサポートするストレージクラスの設定で、OpenShift Virtualization の観点から推奨されるベストプラクティスがいくつかあります。たとえば、VM 用にプロビジョニングされた永続ボリュームは RWX モードに設定し、仮想ゲストを別のノードにマイグレーションする必要が生じた場合に追加のノードが永続ボリュームにアクセスできるようにします。マイグレーションの場合と同様、ワーカーノードは、デフォルトの管理ネットワークを介してストレージにアクセスするように設定するか、NFS または iSCSI ベースの永続ボリュームの接続を提供する別のネットワークをアタッチします。多くの場合、指定されたストレージシステムへの API 呼び出しの初期化は OpenShift の管理またはデフォルトの pod ネットワークで行います。CSI ドライバーは、プロビジョニングされたボリュームが利用可能なストレージネットワーク上で正しくマッピングされているかどうかを検証します。

最後に、VM で実行しているアプリケーション、または仮想マシンへの直接のパブリックアクセスについて見ていきます。アプリケーションをコンテナ化する準備ができていない場合、現在仮想マシンで実行しているアプリケーションを、コンテナで実行しているアプリケーションと同じように扱うことが可能です。そのためには、アクセスできるようにするアプリケーションを識別するタグを仮想マシンに適用します。そのタグを使用して識別し、仮想マシン上のアプリケーションが必要とするポートに対して Kubernetes サービスを作成します。次に、仮想ゲスト全体を公開するのではなく、OpenShift ルートを作成してデフォルトの OpenShift pod ネットワーク経由でアプリケーションに直接アクセスできるようにして、このサービスを公開できます。これは、コンテナ化されたアプリケーションの場合とまったく同じです。

仮想ゲストに対するこのアクセス方法は、アプリケーションを仮想化からコンテナ化へと移行する際の一ステップとして使用できます。仮想マシンのゲスト OS への直接アクセスを使用する従来のアプローチを使用する場合は、ネットワークアタッチメント定義を作成して、Linux ブリッジ、または仮想ゲストのホスティングが可能な各ワーカーノード上にある SR-IOV デバイスをバインドします。こうすると、仮想ゲストには外部 IP が 1 つ割り当てられ、ユーザーは SSH や任意のリモートアクセスプロトコルを使用してゲストに直接アクセスできます。

仮想ゲストに追加のネットワークを接続する際には注意点が 1 つあり、ゲスト仮想マシンがクラスタ内の別ノードにマイグレーションする必要が生じた場合にも高可用性を維持できるよう、Linux ブリッジ、使用可能な物理インタフェース、VLAN タグはクラスタ内の全ワーカーノードで同一に定義し、使用できるようにしておく必要があります。

デプロイされた OpenShift Virtualization ソリューションのネットワークアーキテクチャ上でも VMware vSphere など他の一般的なハイパーバイザー環境と同様のパフォーマンスと動作を実現するように設定する方法があることを知っていれば、お客様がこの製品でより魅力的なエクスペリエンスを得られるようにするのに役立ちます。Red Hat では、優れたエクスペリエンスを提供すれば顧客満足度が向上し、製品の導入も進んで、アプリケーションのモダナイゼーションが促進されると考えています。 

アプリケーションのモダナイゼーションと OpenShift Virtualization のメリットについてさらに詳しい情報をお求めの場合は、Red Hat Summit Connect や OpenShift Virtualization ロードショーなど、今後開催されるライブイベントに参加することをご検討ください。これらのイベントでは、製品概要の紹介や OpenShift Virtualization 専用のハンズオンラボの提供を行っています。