Red Hat OpenShift のネットワーキング・アーキテクチャは、無数のコンテナ化アプリケーションのための堅牢でスケーラブルなフロントエンドを提供します。サービスは Pod タグに基づいて単純な負荷分散を行い、ルートはこれらのサービスを外部ネットワークに公開します。これらの概念はマイクロサービスについては効果的ですが、OpenShift Virtualization 上の仮想マシンで実行されるアプリケーションについては容易に適用できない場合があります。この場合、既存のサーバー管理インフラストラクチャがすでに導入されており、仮想マシンへのフルアクセスが常に利用可能であることが前提とされています。
前回の記事では、OpenShift Virtualization のインストールと設定方法、および基本的な仮想マシンの実行方法について説明しました。この記事では、OpenShift Virtualization クラスタを設定する際の各種オプションについて説明し、他の一般的なハイパーバイザーと非常によく似た方法で仮想マシンが外部ネットワークにアクセスできるようにする方法を説明します。
OpenShift の外部ネットワークへの接続
OpenShift は、内部 Pod ネットワークに加えて、外部ネットワークにアクセスするように設定することができます。そのために、OpenShift クラスタで NMState Operator を使用します。NMState Operator は OpenShift Operator Hub からインストールできます。
NMState Operator は、OpenShift の CNI プラグインである Multus と連携して動作し、Pod が複数のネットワークと通信できるようにします。Multus についてはすでに優れた記事を参照できるため、ここでは詳細な説明を省略し、NMState と Multus を使用して仮想マシンを複数のネットワークに接続する方法について説明します。
NMState コンポーネントの概要
NMState Operator をインストールすると、3 つの CustomResoureDefinitions (CRD) が追加され、これにより、クラスターノードでネットワークインターフェースを設定できるようになります。これらのオブジェクトは、OpenShift ノードでネットワークインターフェースを設定する際に操作します。
NodeNetworkState
(
nodenetworkstates.nmstate.io) は、各クラスターノードに 1 つの NodeNetworkState (NNS) オブジェクトを設定します。オブジェクトのコンテンツには、該当するノードの現在のネットワーク状態に関する詳細が表示されます。NodeNetworkConfigurationPolicies
(
nodenetworkconfigurationpolicies.nmstate.io) は、ノードのグループでさまざまなネットワークインターフェースを設定する方法を NMState Operator に伝えるポリシーです。つまり、これらは OpenShift ノードの設定変更を表します。NodeNetworkConfigurationEnactments
(
nodenetworkconfigurationenactments.nmstate.io) は、 NodeNetworkConfigurationEnactment (NNCE) に適用された各 NodeNetworkConfigurationPolicy (NNCP) オブジェクトの結果を保存します。各ノード、各 NNCP に対して 1 つの NNCE があります。
これらの定義を使用して、OpenShift ノードのネットワークインターフェースの設定に進むことができます。この記事で使用している演習のハードウェア構成には、3 つのネットワークインターフェースが含まれています。1 つ目は enp1s0 です。これは、ブリッジ br-ex を使用して、クラスターのインストール時にすでに設定されています。これは、下記の Option #1 で使用しているブリッジとインターフェースです。2 つ目のインターフェース enp2s0 は、enp1s0と同じネットワーク上にあります。ここでは、これを使用して以下の Option #2 の OVS ブリッジ br0 を設定します。最後に、インターフェース enp8s0 は、インターネットアクセスおよび DHCP サーバーのない別のネットワークに接続されています。このインターフェースを使用して、以下の Option #3 で Linux ブリッジ br1 を設定します。
オプション #1：単一の NIC を持つ外部ネットワークを使用する
OpenShift ノードにネットワーク用の単一の NIC しかない場合、仮想マシンを外部ネットワークに接続するための唯一の選択肢は、br-ex ブリッジを再利用することです。これは、OVN-Kubernetes クラスターで実行されるすべてのノードのデフォルトです。 .つまり、このオプションは、古い Openshift-SDN を使用しているクラスターでは使用できない可能性があります。
クラスターの基本動作にネガティブな影響を与えずに br-ex ブリッジを完全に再設定することはできないため、代わりにそのブリッジにローカルネットワークを追加する必要があります。これを実行するには、 NodeNetworkConfigurationPolicy 設定を使用できます。
$ cat br-ex-nncp.yaml
apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
name: br-ex-network
spec:
nodeSelector:
node-role.kubernetes.io/worker: ''
desiredState:
ovn:
bridge-mappings:
- localnet: br-ex-network
bridge: br-ex
state: presentほとんどの場合、上記の例はどの環境でも同じで、br-ex ブリッジにローカルネットワークを追加します。一般的に変更される部分は、NNCP の名前 (.metadata.name) とローカルネットの名前 (.spec.desiredstate.ovn.bridge-mappings) のみです。この例では、それらはどちらも br-ex-network ですが、名前は任意であり、互いに同じである必要はありません。localnet に使用されている値は、NetworkAttachmentDefinitionを設定するときに必要になるため、後で使用できるようにその値をメモしてください。
NNCP 設定をクラスターノードに適用します。
$ oc apply -f br-ex-nncp.yaml
nodenetworkconfigurationpolicy.nmstate.io/br-ex-network次のコマンドを使用して、NNCP と NNCE の進行状況を確認します。
$ oc get nncp
NAME STATUS REASON
br-ex-network Progressing ConfigurationProgressing
$ oc get nnce
NAME STATUS STATUS AGE REASON
lt01ocp10.matt.lab.br-ex-network Progressing 1s ConfigurationProgressing
lt01ocp11.matt.lab.br-ex-network Progressing 3s ConfigurationProgressing
lt01ocp12.matt.lab.br-ex-network Progressing 4s ConfigurationProgressingこの場合、br-ex-network という名前の単一の NNCP が各ノードの NNCE を生成しています。数秒後、プロセスが完了します。
$ oc get nncp
NAME STATUS REASON
br-ex-network Available SuccessfullyConfigured
$ oc get nnce
NAME STATUS STATUS AGE REASON
lt01ocp10.matt.lab.br-ex-network Available 83s SuccessfullyConfigured
lt01ocp11.matt.lab.br-ex-network Available 108s SuccessfullyConfigured
lt01ocp12.matt.lab.br-ex-network Available 109s SuccessfullyConfiguredこれで、NetworkAttachmentDefinition に移ることができます。これは、作成した新しいネットワークに仮想マシンをアタッチする方法を定義します。
NetworkAttachmentDefinition の設定
OpenShift コンソールで NetworkAttachmentDefinition を作成するには、仮想マシンを作成するプロジェクト (この例では vmtest) を選択し、Networking > NetworkAttachmentDefinitions に移動します。次に、Create network Attachment Definition という名前の青いボタンをクリックします。
Console に、NetworkAttachmentDefinition を作成するために使用するフォームが表示されます。
Name フィールドは任意ですが、この例では、NNCP に使用していた名前と同じ名前 (br-ex-network) を使用しています。Network Typeの場合は、OVN Kubernetes secondary localnet network を選択する必要があります。
Bridge mapping フィールドに、先ほど設定したローカルネットの名前 (この例では br-ex-network) を入力します。このフィールドは「bridge mapping (ブリッジのマッピング)」を要求するので、「br-ex」と入力したくなるかもしれませんが、実際には、br-ex に接続済みの、作成したローカルネットを使用する必要があります。
また、コンソールを使用する代わりに、YAML ファイルを使用して NetworkAttachmentDefinition を作成できます。
$ cat br-ex-network-nad.yaml
apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
name: br-ex-network
namespace: vmtest
spec:
config: '{
"name":"br-ex-network",
"type":"ovn-k8s-cni-overlay",
"cniVersion":"0.4.0",
"topology":"localnet",
"netAttachDefName":"vmtest/br-ex-network"
}'
$ oc apply -f br-ex-network-nad.yaml
networkattachmentdefinition.k8s.cni.cncf.io/br-ex-network created上記の NetworkAttachmentDefinition YAML で、.spec.config の name フィールドは NNCP のローカルネットの名前であり、 netAttachDefName は namespace/名前であり、.metadata セクションの 2 つの同一フィールドに一致する必要があります (この場合は vmtest/br-ex-network)。
仮想マシンは IP アドレス指定に静的 IP または DHCP を使用するため、 NetworkAttachmentDefinition
仮想マシンの NIC 設定
仮想マシンで新しい外部ネットワークを使用するには、仮想マシンの Network interfaces セクションを変更し、Network タイプとして新しい vmtest/br-ex-network を選択します。MAC アドレスをこの形式でカスタマイズすることも可能です。
引き続き、通常どおりに仮想マシンを作成します。仮想マシンが起動すると、仮想 NIC は外部ネットワークに接続されます。この例では、外部ネットワークに DHCP サーバーがあるため、IP アドレスが自動的に割り当てられ、ネットワークへのアクセスが許可されます。
br-ex 上の NetworkAttachmentDefinition と localnet を削除する
上記の手順を元に戻したい場合は、まず NetworkAttachmentDefinitionを使用している仮想マシンがないことを確認してから、コンソールを使用して削除してください。または、 以下のコマンドを使用します。
$ oc delete network-attachment-definition/br-ex-network -n vmtest
networkattachmentdefinition.k8s.cni.cncf.io "br-ex-network" deleted次に、NodeNetworkConfigurationPolicy を削除します。ポリシーを削除しても、OpenShift ノードの変更は元に戻りません。
$ oc delete nncp/br-ex-network
nodenetworkconfigurationpolicy.nmstate.io "br-ex-network" deletedNNCP を削除すると、関連するすべての NNCE も削除されます。
$ oc get nnce
No resources found最後に、以前に使用していた NNCP YAML ファイルを変更しますが、ブリッジマッピングの状態を present からabsent に変更します。
$ cat br-ex-nncp.yaml
apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
name: br-ex-network
spec:
nodeSelector:
node-role.kubernetes.io/worker: ''
desiredState:
ovn:
bridge-mappings:
- localnet: br-ex-network
bridge: br-ex
state: absent # Changed from present更新した NNCP を再び適用します。
$ oc apply -f br-ex-nncp.yaml
nodenetworkconfigurationpolicy.nmstate.io/br-ex-network
$ oc get nncp
NAME STATUS REASON
br-ex-network Available SuccessfullyConfigured
$ oc get nnce
NAME STATUS STATUS AGE REASON
lt01ocp10.matt.lab.br-ex-network Available 2s SuccessfullyConfigured
lt01ocp11.matt.lab.br-ex-network Available 29s SuccessfullyConfigured
lt01ocp12.matt.lab.br-ex-network Available 30s SuccessfullyConfiguredlocalnet 設定はこれで削除されました。NNCP を問題なく削除することができます。
オプション #2：専用 NIC 上の OVS ブリッジで外部ネットワークを使用する
OpenShift ノードは、異なる物理 NIC を使用する複数のネットワークに接続することができます。(ボンディングや VLAN などの) 多数の設定オプションが存在しますが、この例では、OVS ブリッジを設定するために専用の NIC を使用します。ボンディングの作成や VLAN の使用など、高度な設定オプションの詳細については、このドキュメントを参照してください。
このコマンドを使用して、すべてのノードインターフェースを表示できます (便宜上、ここでは出力を省略しています)。
$ oc get nns/lt01ocp10.matt.lab -o jsonpath='{.status.currentState.interfaces[3]}' | jq
{
…
"mac-address": "52:54:00:92:BB:00",
"max-mtu": 65535,
"min-mtu": 68,
"mtu": 1500,
"name": "enp2s0",
"permanent-mac-address": "52:54:00:92:BB:00",
"profile-name": "Wired connection 1",
"state": "up",
"type": "ethernet"
}この例では、すべてのノードの未使用のネットワークアダプターは enp2s0 です。
前述の例と同様に、未使用の NIC (この場合は enp2s0) を使用して、br0 という名前の新しい OVS ブリッジをノードに作成する NNCP から始めます。NNCP は次のようになります。
$ cat br0-worker-ovs-bridge.yaml
apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
name: br0-ovs
spec:
nodeSelector:
node-role.kubernetes.io/worker: ""
desiredState:
interfaces:
- name: br0
description: |-
A dedicated OVS bridge with enp2s0 as a port
allowing all VLANs and untagged traffic
type: ovs-bridge
state: up
bridge:
options:
stp: true
port:
- name: enp2s0
ovn:
bridge-mappings:
- localnet: br0-network
bridge: br0
state: present上記の例についてまず注目すべき点は、.metadata.name フィールドです。これは任意のフィールドであり、NNCP の名前を特定します。また、ファイルの末尾で、単一の NIC の例の br-ex の場合と同様に、 localnet の bridge-mapping を新しい br0 ブリッジに追加していることがわかります。
ブリッジとして br-ex を使用した前の例では、すべての OpenShift ノードにこの名前のブリッジがあると想定することができるため、すべてのワーカーノードに NNCP を適用しています。ただし、今回のシナリオでは、同じネットワークに対して異なる NIC 名を持つ異種ノードを使用できます。その場合は、各ノードタイプにラベルを追加して、どの設定を持つかを識別する必要があります。次に、上記の例の .spec.nodeSelector を使用して、この設定で動作するノードにのみ設定を適用することができます。他のノードタイプの場合は、基礎になる NIC 名が異なる場合でも、NNCP と nodeSelector を変更して、それらのノードに同じブリッジを作成できます。
この例では、NIC 名がすべて同じであるため、すべてのノードに同じ NNCP を使用できます。
次に、単一の NIC の例の場合と同じように NNCP を適用します。
$ oc apply -f br0-worker-ovs-bridge.yaml
nodenetworkconfigurationpolicy.nmstate.io/br0-ovs createdこれまでと同様、NNCP と NNCE が正常に作成され、適用されるまでには少しの時間がかかります。NNS で新しいブリッジを確認できます。
$ oc get nns/lt01ocp10.matt.lab -o jsonpath='{.status.currentState.interfaces[3]}' | jq
{
…
"port": [
{
"name": "enp2s0"
}
]
},
"description": "A dedicated OVS bridge with enp2s0 as a port allowing all VLANs and untagged traffic",
…
"name": "br0",
"ovs-db": {
"external_ids": {},
"other_config": {}
},
"profile-name": "br0-br",
"state": "up",
"type": "ovs-bridge",
"wait-ip": "any"
}NetworkAttachmentDefinition の設定
OVS ブリッジの NetworkAttachmentDefinition を作成するプロセスは、単一の NIC を使用した前述の例と同じです。どちらの場合も OVN ブリッジマッピングを作成するためです。現在の例では、ブリッジマッピング名は br0-network です。したがって、NetworkAttachmenDefinition 作成形式で使用します:
または、YAML ファイルを使用して NetworkAttachmentDefinition を作成できます。
$ cat br0-network-nad.yaml
apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
name: br0-network
namespace: vmtest
spec:
config: '{
"name":"br0-network",
"type":"ovn-k8s-cni-overlay",
"cniVersion":"0.4.0",
"topology":"localnet",
"netAttachDefName":"vmtest/br0-network"
}'
$ oc apply -f br0-network-nad.yaml
networkattachmentdefinition.k8s.cni.cncf.io/br0-network created仮想マシン NIC の設定
先ほどと同様に、NIC ネットワークについて vmtest/br0-network という名前の新しい NetworkAttachmentDefinition を使用して、仮想マシンを通常どおりに作成します。
仮想マシンが機動すると、NIC はノード上の br0 ブリッジを使用します。この例では、br0 の専用 NIC が br-ex ブリッジと同じネットワーク上にあるので、以前と同じサブネットから IP アドレスを取得し、ネットワークアクセスが許可されています。
NetworkAttachmentDefinition および OVS ブリッジを削除する
NetworkAttachmentDefinition と OVS ブリッジを削除するプロセスは、前の例とほぼ同じです。NetworkAttachmentDefinition を使用している仮想マシンがないことを確認してから、コンソールまたはコマンドラインからこれを削除します。
$ oc delete network-attachment-definition/br0-network -n vmtest networkattachmentdefinition.k8s.cni.cncf.io "br0-network" deleted次に、NodeNetworkConfigurationPolicy を削除します (ポリシーを削除しても、OpenShift ノードの変更は元に戻らないことに注意してください)。
$ oc delete nncp/br0-ovs
nodenetworkconfigurationpolicy.nmstate.io "br0-ovs" deletedNNCP を削除すると、関連する NNCE も削除されます。
$ oc get nnce
No resources found最後に、前に使用した NNCP YAML ファイルを変更します。ただし、インターフェースの状態を「up」から「absent」に変更し、ブリッジマッピングの状態を「present」から「absent」に変更します。
$ cat br0-worker-ovs-bridge.yaml
apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
name: br0-ovs
spec:
nodeSelector:
node-role.kubernetes.io/worker: ""
desiredState:
Interfaces:
- name: br0
description: |-
A dedicated OVS bridge with enp2s0 as a port
allowing all VLANs and untagged traffic
type: ovs-bridge
state: absent # Change this from “up” to “absent”
bridge:
options:
stp: true
port:
- name: enp2s0
ovn:
bridge-mappings:
- localnet: br0-network
bridge: br0
state: absent # Changed from present更新された NNCP を再適用します。NNCP が正常に処理されたら、削除できます。
$ oc apply -f br0-worker-ovs-bridge.yaml
nodenetworkconfigurationpolicy.nmstate.io/br0-ovs createdオプション #3：専用 NIC 上の Linux ブリッジで外部ネットワークを使用する
Linux ネットワークでは、OVS ブリッジと Linux ブリッジの両方が同じ目的を果たします。どちらを使うかは、最終的には環境でのニーズによって決まります。インターネット上には、両方のブリッジタイプのメリットとデメリットを説明した無数の記事を見つけることができます。つまり、Linux ブリッジは OVS ブリッジよりも成熟し、単純化されていますが、機能がそれほど充実していません。OVS ブリッジは Linux ブリッジよりも多くのトンネルのタイプや他の最新の機能を提供するという利点がありますが、トラブルシューティングがそれほど容易ではありません。OpenShift Virtualization の目的では、MultiNetworkPolicy などを考慮すると、Linux ブリッジではなく OVS ブリッジをデフォルトで使用するように設定する必要がありますが、どちらのオプションでもデプロイメントは成功します。
仮想マシンのインターフェースが OVS ブリッジに接続されている場合、デフォルトの MTU は 1400 になることに留意してください。また、仮想マシンのインターフェースが Linux ブリッジに接続されている場合は、デフォルトの MTU は 1500 です。クラスターの MTU サイズに関する詳細については、公式のドキュメントを参照してください。
ノードの設定
前の例と同様に、専用の NIC を使用して新しい Linux ブリッジを作成します。参考までに、ここでは Linux ブリッジを DHCP サーバーのないネットワークに接続します。そのため、このネットワークに接続された仮想マシンに、これがどのような影響を与えるかがわかります。
この例では、br1 という名前の Linux ブリッジを、インターフェース enp8s0 上に作成しています。このブリッジは 172.16.0.0/24 ネットワークに接続されており、このネットワークにはインターネットアクセスも DHCP サーバーもありません。NNCP は次のようになります。
$ cat br1-worker-linux-bridge.yaml
apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
name: br1-linux-bridge
spec:
nodeSelector:
node-role.kubernetes.io/worker: ""
desiredState:
interfaces:
- name: br1
description: Linux bridge with enp8s0 as a port
type: linux-bridge
state: up
bridge:
options:
stp:
enabled: false
port:
- name: enp8s0
$ oc apply -f br1-worker-linux-bridge.yaml
nodenetworkconfigurationpolicy.nmstate.io/br1-worker created先ほどと同様に、NNCP と NNCE は作成して適用されるまで数秒かかります。
NetworkAttachmentDefinition の設定
Linux ブリッジの NetworkAttachmentDefinition を作成するプロセスは、先の 2 つの例とは少し異なります。それは、今回は OVN ローカルネットに接続していないためです。Linux ブリッジの接続の場合は、新しいブリッジに直接接続します。NetworkAttachmenDefinition 作成フォームは次のようになります:
ここでは、CNV Linux bridge の Network Type を選択し、実際のブリッジの名前を Bridge name フィールドに入力します。この例では、br1 です。
仮想マシン NIC 設定
今度は別の仮想マシンを作成しますが、NIC ネットワークに vmtest/br1-network という名前の新しい NetworkAttachmentDefinition を使用します。これにより、NIC が新しい Linux ブリッジにアタッチされます。
仮想マシンが機動すると、NIC はノード上の br1 ブリッジを使用します。この例では、専用 NIC は DHCP サーバーのないネットワーク上にあり、インターネットアクセスもないため、nmcli を使用して NIC に手動 IP アドレスを付与し、ローカルネットワークのみで接続を検証します。
NetworkAttachmentDefinition と Linux ブリッジを削除する
前の例と同様に、NetworkAttachmentDefinition と Linux ブリッジを削除するには、まず仮想マシンが NetworkAttachmentDefinition を使用していないことを確認します。コンソールまたはコマンドラインからこれを削除します。
$ oc delete network-attachment-definition/br1-network -n vmtest
networkattachmentdefinition.k8s.cni.cncf.io "br1-network" deleted次に、NodeNetworkConfigurationPolicy: を削除します。
$ oc delete nncp/br1-linux-bridge
nodenetworkconfigurationpolicy.nmstate.io "br1-linux-bridge" deletedNNCP を削除すると、関連するすべての NNCE も削除されます (ポリシーを削除しても、OpenShift ノードの変更は元に戻りません)。
$ oc get nnce
No resources found最後に、NNCP YAML ファイルを変更して、インターフェースの状態を up から absent に変更します。
$ cat br1-worker-linux-bridge.yaml
apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
name: br1-linux-bridge
spec:
nodeSelector:
node-role.kubernetes.io/worker: ""
desiredState:
interfaces:
- name: br1
description: Linux bridge with enp8s0 as a port
type: linux-bridge
state: absent # Changed from up
bridge:
options:
stp:
enabled: false
port:
- name: enp8s0更新された NNCP を再適用します。NNCP が正常に処理された後は、削除できます。
$ oc apply -f br1-worker-linux-bridge.yaml
nodenetworkconfigurationpolicy.nmstate.io/br1-worker createdOpenShift Virtualization の高度なネットワーク
多くの OpenShift Virtualization ユーザーは、Red Hat OpenShift にすでに組み込まれているさまざまな高度なネットワーク機能を活用できます。ただし、従来のハイパーバイザーから移行されるワークロードが増えるにつれ、既存のインフラストラクチャの活用が必要になるかもしれません。そのため、OpenShift Virtualization ワークロードを外部ネットワークに直接接続することが必要になる場合があります。NMState Operator と Multus ネットワークを連携させることで、パフォーマンスと接続性を実現する柔軟な方法を提供し、従来のハイパーバイザーから Red Hat OpenShift Virtualization への移行を容易にできます。
OpenShift Virtualization の詳細については、このトピックに関するこちらのブログ記事もぜひご覧ください。また、Red Hat の Web サイトで製品情報をご覧いただけます。この記事で取り上げているネットワークのトピックの詳細については、Red Hat OpenShift のドキュメント に必要な情報がすべて記載されています。デモをご覧になる場合、または OpenShift Virtualization をご自身で使用される場合は、営業担当者までお問い合わせください。
執筆者紹介
Matthew Secaur is a Red Hat Principal Technical Account Manager (TAM) for Canada and the Northeast United States. He has expertise in Red Hat OpenShift Platform, Red Hat OpenShift Virtualization, Red Hat OpenStack Platform, and Red Hat Ceph Storage.
チャンネル別に見る
自動化
テクノロジー、チームおよび環境に関する IT 自動化の最新情報
AI (人工知能)
お客様が AI ワークロードをどこでも自由に実行することを可能にするプラットフォームについてのアップデート
オープン・ハイブリッドクラウド
ハイブリッドクラウドで柔軟に未来を築く方法をご確認ください。
セキュリティ
環境やテクノロジー全体に及ぶリスクを軽減する方法に関する最新情報
エッジコンピューティング
エッジでの運用を単純化するプラットフォームのアップデート
インフラストラクチャ
世界有数のエンタープライズ向け Linux プラットフォームの最新情報
アプリケーション
アプリケーションの最も困難な課題に対する Red Hat ソリューションの詳細
仮想化
オンプレミスまたは複数クラウドでのワークロードに対応するエンタープライズ仮想化の将来についてご覧ください
