Home > Blogs > Japan Cloud Infrastructure Blog > 月別アーカイブ: 2017年2月

月別アーカイブ: 2017年2月

ちょっとした技術的な TIPs のご紹介 (2017.02)

みなさん、こんにちは。VMwareでパートナー様を担当させて頂いてますSEの北村です。

今後、月に1回の頻度で VMware Blog (Cloud Infrastructure Blog と End-User Computing Blog) で、ちょっとした技術的なTIPs を投稿していこうと思っておりますので、お付き合いください。

今回は次の 2点をお伝えします。

1. vSphere (vCenter Server と ESXi) がサポート対象としている Active Directory の Domain Function Level について
2. CPU の EVC 互換の確認方法

では、それぞれについて記載していきます。

1. vSphere (vCenter Server と ESXi) がサポート対象としている Active Directory の Domain Function Level について
みなさん、VMware の Knowledge Base サイト (kb.vmware.com) はご存知でしょうか? 弊社製品におけるトラブルシューティングやサポート関連の情報などを公開しているサイトになるので、是非、ご活用頂けると幸いです。

さて、以下の Knowledge Base (略して KB という言い方をします) は、vCenter Server と ESXi がサポート対象としている Active Directory の Domain Function Level について記載しているのですが、最近、この KB が更新され、昨年末にリリースされた、vSphere 6.5 の情報が追記されました。

Versions of Active Directory supported in vCenter Server (2071592)
Versions of Active Directory supported in VMware ESXi (2113023)

ここで、大事な事をお伝えしますが、vSphere 6.5 から Windows 2003 Domain Function Level がサポートから外れました (Windows Server 2003 の延長サポートが既に終了となっていますので、その結果が繁栄されていると思われます)。

Versions of Active Directory supported in vCenter Server (2071592) より抜粋 (詳細は KBをご参照ください):
KB2071592

Versions of Active Directory supported in VMware ESXi (2113023) より抜粋 (詳細は KBをご参照ください):
KB2113023

それに伴い、「以前のバージョンの vSphere」 と 「Windows 2003 Domain Function Level」 で利用している環境を、vSphere 6.5 へバージョンアップすると、動作の可否に関わらず、vSphere 6.5としてはサポート外の構成となってしまいますので、バージョンアップをご検討されている場合はこの点ご注意ください。

vSphere 6.5 へのアップグレードには以下のドキュメントを参考にして下さい。

1. ブラウザで、http://www.vmware.com/jp/support/support-resources/pubs/vsphere-esxi-vcenter-server-6-pubs.html へ。
2. 「vSphere アップグレード ガイド」の PDF をクリック頂き、PDF版を参照するか、「vSphere 6.5 ドキュメント センター」リンクをクリック頂き、ブラウザの左側の「目次」で、「ESXi および vCenter Server 6.5 のドキュメント」→ 「vSphere のアップグレード」 の順で、クリック頂く事で、ブラウザ上で PDF 版と同じ内容を参照頂けます。

2. CPU の EVC 互換の確認方法
みなさんは、弊社の Compatibility Guide のサイトはご存知でしょうか? このサイトでは、弊社製品がサポートするハードウェア関連 (一部ソフトウェア) の情報を掲載しており、どのサーバ、どのCPU 、どのIOカード (NICやHBAなど) が弊社製品でサポートされているのかを確認頂く事ができます。

ちなみに、このページに掲載されている情報は、弊社が認定作業を実施していると思われがちですが、基本的には各ハードウェア・ベンダー様に認定作業を実施頂き、認定をパスしたハードウェアの情報を頂戴して弊社が掲載しています。

話を元に戻しますが、このサイトの1つとして、CPU Series というページがあります。ここでは、ESXi の各バージョンがサポート対象としている CPU や、Fault Tolerant 機能がサポート対象としている CPU、また、世代の異なる CPU 間での vMotion をサポートする為の機能、Enhanced vMotion Compatibility (EVC) を確認する事ができます。

特に、EVC は既存環境に新たに ESXi を追加する際に、既存サーバに搭載されている CPU と新たに追加するサーバに搭載されている CPU 間で vMotion、もしくは、DRS (DRSは仮想マシンの再配置を行う際に vMotion を利用しています) の互換性があるか、また、互換性を持たせる為に設定すべき EVC モードは何かを確認する事ができます。

例えば、既存環境では、① Intel Xeon E5-2690 を搭載しているサーバを使用していて、②その環境に新たに Intel Xeon E5-2690 v4 を搭載しているサーバを追加したいとします。かつ、①と②の間で vMotion または DRS を利用したいとします。

①の Intel Xeon E5-2690 は、Intel Xeon E5-2600 Series、②の Intel Xeon E5-2690 v4 は、Intel Xeon E5-2600-v4 Series になりますので、CPU Series のページで、それらを選択します。
HCL_EVC1

次に、”CPU / EVC Matrix” ボタンをクリックします。
HCL_EVC2

その結果 (上記) から、Intel Xeon E5-2690 (Intel Xeon E5-2600 Series) と Intel Xeon E5-2690 v4 (Intel Xeon E5-2600-v4 Series) の EVC モードが、Intel® Sandy-Bridge Generation である事がわかります。ちなみに、赤枠で囲まれた “Intel Xeon E5-2600 Series” や “Intel Xeon E5-2600-v4 Series” をクリックすると、それぞれの CPU のコードネーム (Code Name) を確認する事もできます。

どうでしょう、一見難しい様に思える異なる世代の CPU 間の EVC モードの確認が簡単に行える事をご理解頂けたと思います。

最後まで読んで頂きありがとうございます。今回は以上となります。またの機会をお楽しみに。

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

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

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

1回目:仮想スイッチのお作法#1 (仮想スイッチの歴史とポートIDベースロードバランス)

– Back Number –
#1…仮想スイッチのお作法#1
#2…仮想スイッチのお作法#2
#3…vSphere 6. 5の分散スイッチの機能とアーキテクチャ#3
#4…分散スイッチの管理①#4
#5…分散スイッチの管理②#5
#6…Network I/O Control#6

こんにちは、ソフトバンク コマース&サービスの中川明美です。
今回は、あらためて「仮想スイッチ」について取りあげます!!
私は、2009年から2015年までVMware認定インストラクターとして、「VMware vSphere : Install, Configure, Manage (5日間)」等の公認コースを実施してきました。
インストラクターとして得た、「ここがポイントですよ!」を共有しながら、標準スイッチと分散スイッチの同じところ/異なるところをご紹介していきます。
第1回目は、仮想スイッチの歴史とロードバランスのポートIDベースについてご紹介します。

◆仮想スイッチの歴史
Version3.5の知識のままvSphereを管理運用されているエンドユーザー様にお会いすることがあります。たとえば、vSphere HAや仮想スイッチです。仮想スイッチの1つである標準スイッチは3.5から変更点はありませんから支障がないのかもしれません。
しかし「ESXiホストの管理台数が増える」「ハードウェアの進化を活用する」となると、新しい知識(機能)が必要になります。そしてベストプラクティスも変更されていきます。
私は、エンドユーザー様にアップデートされた機能に興味をもっていただきたい場合、歴史(機能の変遷)の話をします。ご存知の時点から順に歴史の話をすると、興味をもっていただける傾向があります。では、歴史のお話を!
仮想スイッチの歴史は、公認コースのテキストを使用します。
Versionが上がれば機能が増えます。機能が増えればコースのスライド内容が変わるのは当然と思うかもしれません。しかし比較してみると、機能だけではなく、「思い(ベストプラクティス)」も伝わってくる気がします。順次見ていきましょう。

◆Version 3.5
古くからVMware製品に携わっている方には、懐かしい「サービスコンソールポート」です。3.xまでは管理ネットワークの接続タイプが必要でした。この図では、1つの「標準スイッチ」に複数の接続タイプが構成されています。1Gbps物理NIC3つの構成では、パフォーマンスに支障が出そうですね。
接続タイプ:3種類のネットワーク接続

1

◆Version 4.0
4.0になって、用途によって仮想スイッチを分ける例が紹介されています。この時は、用途別に仮想スイッチを分けるのは一般的でしたね。課題はESXホストの物理NICの数でした。冗長化を考慮するなら、最低2倍の物理NICが必要です。

2

◆Version 4.1
4.1になると、冗長化を意識した、複数の物理NICが搭載された図になっています。1Gbps物理NICが主流の時のベストプラクティスが見えてきますね。上の構成図は、10Gbps物理NICを使用した分散スイッチに適していますね!

3

◆Version 5.5
スライドの構成は、4.1以降変更はありません。しかし、各役割のVMkernelポートが1つという構成は最近ありませんね。vMotionであれば帯域確保や、iSCSIであればパスを増やす必要があります。その場合、複数のVMkernelポートを構成します。

4

◆なぜVMkernelポートは複数必要?
なぜVMkernleポートが複数必要なのかを知る前に、NICチーミングの「ロードバランス」を復習します。ロードバランスは物理NICの選択方法です。デフォルト値はポートIDベースです。ここでは仮想マシンポートグループを使用して、ポートIDベース確認します。物理NICは、仮想NICが割り当てられた仮想スイッチのポートによって選択されます。たとえば、下図は、VM①の仮想NICはポート0に割り当てられています。ポート0に接続されたVM①の通信は物理NICのvmnic0を使用します。同様にVM②はvmnic1を、VM③はvmnic2を使用します。すべての物理NICが選択されたため、残りのVM④は再びvmnic0を使用して通信をします。この説明はあくまでもイメージです。ポートIDベースは名前の通り、仮想NICが割り当てられたポートをベースに物理NICを選択し、ロードバランスをします。シンプルな物理NICの選択方法ですね。デフォルト値であることは納得です!

5

次に、VMkernelポートはどうでしょうか?
下図は、vMotionの構成例です。この仮想スイッチには、vMotion用のVMkernelポート(vmk0)が1つ構成され、物理NICが2つ(vmnic0/vmnic1)割り当てられています。VMkernelポートはESXiホストが通信をするために必要なポートですから、IPを付与するだけなら、1つでも支障はなさそうです。ただし、デフォルトのロードバランス設定はポートIDベースですから、フェイルオーバーが起きなければvmnic1は使用されません。ポートIDベースは、仮想NICが割り当てられた仮想スイッチのポートによって物理NICが選ばれるから。。。でしたね。この構成で冗長性は満たしていますが、2つの物理NICを十分に活用しているとは言えません。

6

ではどのように構成するのがベストでしょうか。参考までに次のKBをご確認ください。

-vSphere における複数 NIC の vMotion-
https://kb.vmware.com/kb/2014840

VMkernelはデフォルトのポートIDベースを使用します。複数の物理NICを活用するには、活用できるように構成をする必要があります。下図のように物理NICが2つあれば、VMkernelも2つ作成し、それぞれにActive-Standbyの設定をします。この構成をすることによって、2つの物理NICを活用し、帯域を拡張することができます。パフォーマンスを上げられますね。

7

VMkernelポートは、vMotion以外の用途として、「管理ネットワーク」「iSCSI/NFS」「FT」がありますね。管理ネットワークは、vSphere HAハートビートに影響がありますから、私は念には念を入れてロードバランスの値として、「明示的なフェイルオーバー」の設定を行っています。iSCSIでは、ポートバインドの設定が必要な場合もあります。参考までに次のポートバインドのBlogをご確認ください。

http://ja.community.dell.com/techcenter/b/weblog/archive/2012/04/05/equallogic-vsphere-portbind

◆まとめ
ポートIDベースの物理NICの選択方法を知ると、特にVMkernelポートではNICチーミングが必要な構成であることをご理解いただけたと思います。ESXiホストが少ない場合は、複数の標準スイッチにポリシーを構成するのも煩雑ではないかもしれません。しかし、VDI環境など多くのESXiホストがある環境では、ポリシーを一元管理できる分散スイッチが注目されてきますね。
次回は、分散スイッチを活用するシチュエーションについてご紹介します。

8

nakagawa