ネットワーク vSphere パートナー

仮想スイッチのお作法~標準スイッチから分散スイッチへの道~

2回目:仮想スイッチのお作法#2 (分散スイッチはいつ使用する?)
– Back Number –
#1…仮想スイッチのお作法#1
#2…仮想スイッチのお作法#2
#3…vSphere 6. 5の分散スイッチの機能とアーキテクチャ#3
#4…分散スイッチの管理①#4
#5…分散スイッチの管理②#5
#6…Network I/O Control#6
こんにちは、ソフトバンク コマース&サービスの中川明美です。
前回、仮想スイッチの歴史とロードバランスの1つであるポートIDベースについてとりあげました。なぜポートIDベースについてとりあげたのか?
それは、なぜその設定が必要なのか、なぜその機能が追加されたのかを理解するためには、ポートIDベースを理解することが早道だからです。
現在、NICチーミングをデフォルト設定のまま構成することは少なくなりましたね。それらの設定を変更する際、状況に応じては、分散スイッチを選択する方が運用管理の煩雑さを避けることができます。今回は、あらためて分散スイッチのよさと、いつ使うのがよいのかをご紹介します。
◆標準スイッチと分散スイッチの違い
最初に、標準スイッチと分散スイッチの異なるところ/同じところを復習します。
<異なるところ>
異なるところは、ネットワークポリシーを管理する場所です。ネットワークポリシーには、「セキュリティ」「トラフィックシェーピング」「NICチーミング」があります。
「標準スイッチ」は各ESXiホストで作成しますが、ネットワークポリシーも各ESXiホストで管理します。
1
「分散スイッチ」は複数のESXiホストにまたがって作成され、ネットワークポリシーはvCenterサーバーで一元管理します。仮想マシンを複数のホスト間で移行する場合でも、仮想マシンに対して一貫したネットワーク構成を提供することができます。
ポリシーは各ESXiホストにプッシュインストールされます。vCenterサーバーとの通信が遮断されたとしても、ポリシーで設定した動作に支障がない仕組みを持っています。

2

<同じところ>
構成するコンポーネントの概念は同じです。先に、標準スイッチからコンポーネントの名前を確認します。

3
Port/Port Group
仮想NICが接続する仮想スイッチのポート(出入口)です。ポートには、「仮想マシンポートグループ」と「VMkernelポート」があります。仮想マシンポートグループは、名前の通り複数の仮想マシン用のポートです。

vmk#(0
から連番)
VMkernelポートに接続されている仮想NICには、「vmk#」という特別な名前が付けられます。ESXiホストが通信するために、vmk#にIPアドレスを付与します。

Uplink Port

物理NIC(Uplink)が接続する仮想スイッチのポート(出入口)です。
vmnic#(0から連番)
物理NICのことです。

Port/Port Group
の識別名:
左図では、MGMT/Production/vMotionが該当します。ネットワークポリシーの識別名でもあります。
次に分散スイッチです。

4

分散スイッチが標準スイッチと異なるのは次の2つです。
dvPort Group
分散スイッチのポートグループをdvPort Groupと呼びます。ポートは複数のESXiホストに分散配置されます。
dvUplink Ports
論理的な物理NICのポートです。論理的と表現したのは、複数のESXiホストの物理NICをグループ化し、1つのdvUplink Portに割り当てるからです。
分散スイッチでは、いくつの物理NICを割り当てるかを、「dvUplink Ports」の数として指定します。そして各dvUplink PortsにESXiホストの該当物理NICをアサインします。左図では、dvUplink Port 1に3台のESXiホストのvmnic2が割り当てられています。
※dvは「Distributed Virtual」の略
図3と図4の仮想マシンポートグループ「Production」に注目してください。
標準スイッチと分散スイッチを構成するPortとUplink Port(dvUplink Ports)は、同じ構成(図形)で描かれています。標準スイッチと分散スイッチは、単体のESXiホストで構成されるのか、複数のESXiホストにまたがって構成されるかだけの違いです!
本題に入ります!
◆vMotionを例にしたネットワークポリシー設定
前回のBlogで、下図のようにvMotion用にNICチーミングを構成することで、冗長化だけではなく、パフォーマンスの向上も期待できることをご紹介しました。それは2つの物理NICを活用できるからでしたね。
5
vMotionで必要な設定は次の通りです。
6
ESXiホストの台数が多くなると、なかなか煩雑な作業です。
たとえば、2つの物理NICを割り当てた標準スイッチで、vMotion用の設定を10台のESXiホストで構成するとなると・・・標準スイッチで、vMotion用のVMkernelポートを2つ作成し、各々でNICチーミングの設定をします。これを10回繰り返すことになります。
入力ミスや設定ミスが生じるかもしれません。分散スイッチであれば、ESXiホストが何台であろうと、ネットワークポリシーの設定は1回の作業で完了します。
管理するESXiホストの台数が多くなれば、分散スイッチに分がありますね。
◆分散スイッチはいつ使うの?
分散スイッチはいつ使うのがよいのでしょう。分散スイッチで提供される、「物理NIC負荷に基づいたルート」と「ネットワーク I/O コントロール」を例に説明します。
<物理NIC負荷に基づいたルート>
分散スイッチのみで提供しているロードバランスの方法(物理NICの選択方法)が、「物理NIC負荷に基づいたルート」です。
物理NIC負荷に基づいたルートは、ポートID と複数物理NICのアップリンク(物理NIC)数を取得し、仮想マシンのアップリンクの負荷を計算します。30 秒ごとにアップリンクを監視し、その負荷が使用量の75 パーセントを超えると、I/O の使用率が最も高い仮想マシンのポート ID を別のアップリンクへ移動します。名前の通り、負荷状況に応じて最適な物理NICを選択する方法です。
デフォルトのポートIDベースはポートによって物理NICが選択されるシンプルな方法ですから、アップリンクの負荷までは見ていません。
仮想マシンの台数が多い仮想デスクトップ環境の場合は、「物理NIC負荷に基づいたルート」を選択することをお勧めします。Horizon Bundleのライセンスでは、vSphere Desktop(vSphere Enterprise Plusと同等の機能) が含まれます。このライセンスであれば、分散スイッチを使用できますね!
<ネットワーク I/O コントロール>
CPUやメモリーのリソースコントロールと同様に、ネットワークリソースのコントロールができる機能です。設定値には、「シェア」「予約」「制限」があります。

7

最近注目されているHCI基盤を例に説明します。10Gbpsの物理NIC2枚構成の場合、図3のようなトラフィックごとの仮想スイッチを準備することができません。物理NICは仮想スイッチ間で共有できませんから、1つの仮想スイッチに複数のトラフィック(役割)を構成することになります。
ここで、パフォーマンスが気になりますね。分散スイッチであれば、トラフィックごとにネットワークリソースのコントロールが可能です。
デフォルトのネットワークリソースの割り当ては、すべて無制限です。帯域幅が飽和した場合に、ネットワーク I/O コントロールの「シェア値」を使用することで、帯域幅の割り当てをコントロールできます。管理者としては、より多くの仮想マシントラフィックに、より多くのiSCSIトラフィックに十分な帯域を割り当てたい、優先順位を付けたいと考えますよね。そのような場合に備え、ネットワークリソースのコントロールをご検討いただければと思います。
下図は、vSphere Web Clientのネットワークリソース割り当ての画面ショットです。

8
実際の設計/導入の場面では、下図のように1Gbps物理NICを接続した標準スイッチに管理ネットワークを、10Gbps物理NICを接続した分散スイッチにそれ以外のトラフィックを構成されることが多いと思います。下図は設計例の1つです。
この場合も複数のトラフィックを構成している分散スイッチは、ネットワーク I/O コントロールでのリソースコントロールをお勧めします!
1Gbpsと10Gbpsの混在環境では、「構成の上限(※)」にご注意ください。vSphere 6.5では、1Gbpsは4、10Gbpsは16です。
(※)vSphereの各バージョン毎に準備されているConfiguration maximum ガイドを参照下さい。
vSphere6.5のConfiguration maximum ガイドはこちら
9
◆まとめ
今回はあらためて仮想スイッチをとりあげました。分散スイッチは、Version 4.0から「vSphere Enterprise Plus」ライセンスで提供されています。上位ライセンスのため、標準スイッチと比べて、頻繁に導入する機会はなかったのではないかと思います。
しかし、この数年注目されつつある「VMware NSX」では、分散スイッチが前提となります。また、物理NICも10Gbpsが一般的になってきましたから、ネットワーク I/O コントロールの提案もしやすくなっている状況ではないでしょうか。
提案時のエンドユーザー様はコスト重視の傾向がありますが、導入後のトレーニングでは、「先に話してくれれば。。。」とよく言われました(笑)
費用がかかるからこそ、その効果を知っていただくために、事前の勉強会も必要なのでは?と特に感じています。その際にはこちらのBlogをテキストに勉強会を企画いただけたら嬉しく思います。
8
nakagawa