仮想化でプリセールスしてるSEの一日

VMware から Azure まで、インフラや仮想化の最新情報をベンダー色をできるだけ抑えて綴っていきます

Windows Server 2012 ODX 機能の使い勝手 - (1) T10 XCOPY を OS レベルで

f:id:ogawad:20190203195637p:plain:right

(1) (2) (3) (4) (deep dive)

連休前、Microsoft 主催で「Windows Server 2012 Community Day」というイベントがあり、
次のような Hyper-V の設計ポイントについての登壇の機会をいただきました。

量が多くて駆け足になってしまったせいもあり、本ブログで最新情報などいくつかフォローアップしていきたいと思います。資料内で聞きたいことや取り上げて欲しいなどご要望があれば、気軽にお声がけください。

Windows Server 2012 Hyper-V の本格採用に必要なエンタープライズ設計術
http://download.microsoft.com/download/C/F/2/CF2F9D51-5D9E-45FE-B134-D0783220DCE8/20130426-Ogawa.pdf

Windows Server 2012 の ODX とは?

ODX (Offloaded Data Transfer: オフロードデータ転送) の実体は XCOPY Lite という SCSI の拡張コピーコマンド*1 です。

VMware は vSphere 4.1 の頃から「VAAI FullCopy」という名称で実装しており、現在販売しているストレージのほとんどが対応しています。ですので、どういった技術かはもちろん、仮想マシンのプロビジョニングやクローン, Storage vMotion といったシーンでその恩恵を既に得られている方も多いでしょう。



ただ、クローンや Storage vMotion は常に行うものではありません。
「セットアップやメンテナンスで得するだけか...」とプライオリティを下げてしまいがちですが、Windows Server 2012 の ODX に関しては、結構違います。

ハイパーバイザーである vSphere の場合は、コピーというとそのような用途になってしまいますが、ODX は Hyper-V ではなく Windows OS レベルでの実装 ですので、想像している以上に色々なことを実現できるのです。


Windows Server 2012 の ODX は OS レベルで動作する

ODX が実際に動いているビデオを 1 つ公開してみたいと思います。
これは、実際に私が撮ったもので、Hyper-V を有効化していない単なる WS2012 物理サーバーを、StoreServ という昨年12月に ODX に対応したストレージにつなげて、SAN ボリューム間をファイルコピーしています。
利用するファイルは各種キャッシュから溢れるように 50GB 以上、また重複排除が掛からないように Iometer を 1 時間以上回した後の iobw.tst バイナリです。

ODX が無効な場合


最初は Write Cache に救われますが、その後スループットは 300 MB/sec あたりに落ち着きます。右下のリソースモニタでも足周りに結構な負荷 (%アクティブ) が掛かっているのが分かります。

ODX を有効にした場合


スループットはシングルコピーで 600 MB/sec、最後の方で行っている多重コピーでは合計で 1 GB/sec と、8Gbps FC の理論値 800 MB/sec*2 を超えています。
(ODX の転送速度や処理時間については 別途解説 します)
ここで最も重要なのは、リソースモニタを見ても 20KB 程度の転送しかなく、サーバーの足周りに一切の負荷が掛かっていないということです。


つまり、Hyper-V の ODX は仮想マシンの移行だけではなく、普通のファイルをコピー・移動するといった 日常のエクスプローラー操作でも恩恵を受けられます
専用のアプリケーションも必要はありません。



Windows Server 2012 がリリースされて 1 年が経とうとしていますが、
ODX に関するこれまでの説明が「仮想マシンのストレージ移行」であったため、vSphere VAAI と同じようなイメージを受けていた方が多いと思います。
しかし、実際に ODX に対応したストレージで試してみると、幅広く恩恵を受けられることが分かりました。次回 はここをもう少し深堀りしてみたいと思います。

*1:ESX の SPC-2 SCSI Reservation などと同じく ANSI T10 で標準化されています

*2:FC は 8b/10b 変換

VMware ESXi 5.x のパッチ適用とドライバのアップデートに注意!!

f:id:ogawad:20190203195705p:plain:right

私はサポート担当ではないので偏ったサンプリングかもしれませんが、昨年多かった問合せの1つが...
ESXi にパッチを当ててリブートしたら、
ネットワークに繋がらなくなって緊急事態!

最近落ち着いたようにも思いますが、
この原因がネットであることに気づいたので記事にしてみたいと思います。

No compatible network adapter found.
Please consult the products's Hardware Compatibility Guide (HCG) for a list of support adapters.



この現象について先に答えを言ってしまうと、
「アップデート手順のミスで NIC のドライバが消失してます...」


これは以前投稿した下記の話につながります。

VMware ESXi のインストール CD はベンダー配布版を使いましょう
http://d.hatena.ne.jp/ogawad/20120626/1340665114


一年近く経った現在では、国内外のサーバーベンダー 7 社すべてが
「Custom Image」と呼ばれる各社版インストール CD を作るようになりました。
但し、ベンダーによって Custom Image のスタンスはさまざまです。
NEC さんみたいに「重要:必ず Custom Image を使ってください」というとこもあれば、HP や IBM さんみたいに「Custom Image 使うと ISO をリビルドしなくて便利だよ」程度のとこもあります。


なお、複数の方から聞いた話で VMware 社のダウンロードページに公開されていない Custom Image については同社から一定以上のサポートを受けられないようです。サポートを重要視する場合は念のため代理店にご確認ください。



https://my.vmware.com/jp/web/vmware/info/slug/.../vmware_vsphere/5_1#drivers_tools


さて、この Custom Image ですが、以前書いた記事とおり、
VMware オリジナルのインストール CD に INBOX されていないデバイスドライバなどをベンダー各社が付け足したものです。

つまり、今回の現象は「ベンダーが追加したドライバが消されてしまったため、NIC をロードできない」ということになります。そして、ネットワークに繋がっていない ESXi ホストにドライバを転送するのはとても困難。。。


話を聞いていると、いずれもネット上の情報を参考にして
「esxcli software vib install」というコマンドでアップデートしたとのこと。

esxcli software vib install -d <フルパス: ESXi5xx-xxxxxxxxx.zip>


このコマンドが原因です。
「vib install」は、本来 -v と併用して使うもので、デバイスドライバみたいな特定のコンポーネント (VIB) を "クリアインストール" するためコマンド。

ですので、ESXi や RHEV みたいに "パッチ" と言いながら、
実際はハイパーバイザー丸ごと提供されるものに対して「vib install -d」を使うと、ハイパーバイザー全体が VMware オリジナルの状態に "クリアインストール" され、ベンダーがアドオンしたドライバが消失してしまうのです。


アドオンドライバを保持しつつ、
ESXi ホストを更新する正しいコマンドは「esxcli software profile update」

esxcli software profile update -d <フルパス: ESXi5xx-xxxxxxxxx.zip>
-p <プロファイル名>

なお、GUI ツールのVMware vSphere Update Manager」(VUM) を利用している場合は、きちんと正しいコマンドを使ってくれるので安心して大丈夫です。
vCenter ユーザーは無償で利用できますし、
スケジュール機能や vMotion 連動など非常に良くできている思います。
いくつかのベンダーは Linux の apt-get のように Update Manager と連動する HTTP オンラインレポジトリを公開しています。これを使えば ESXi ホストのパッチ、ベンダー固有のドライバ・ツールの更新作業・管理を一元化できて便利です。



#ここまで詳しく書いておけば、もう夜中に緊急電話は掛かって来ないよね...



2013.4.5 追記
本件と同様に profile update を推奨している公式 KB を教えていただきました。

VMware KB 2020972: VMware Security Patching Guidelines for ESXi and ESX
http://kb.vmware.com/kb/2020972




関連記事(ESXi, インストール, アップデート)

VMware vSphere Web Client を一時的に英語表示に切り替える

f:id:ogawad:20190203195705p:plain:right

「一時的に英語表示に切り替える」シリーズ


KB にもある内容ですが、
これまでせっかく書いてきたのでシリーズ化みたいな感じで書き留めておきます。


英語表記への切り替えは、エラーメッセージから解決を辿る際にグローバルの力を借りられます。
また、下記のように構築中に躓いてしまっても、英語表示なら発生しない、みたいなことも最近増えていますので、何かあった際は英語表示を試せるように方法を覚えておくとお得です。

vSphere Client で内部エラーが発生しました。
詳細:入力文字列の形式が正しくありません。

※ vSphere Client 5.1 の初期ビルドにおいて データストア作成 やライセンスキー適用画面で遭遇できます


VMware vSphere Web Client で表示言語を切り替える

vSphere Client と同様に、引数を加えるだけで変更できます。
ブラウザアプリで引数を渡すには Request.Form か URI.Query, Session/Cookie あたりですが、Web Client は URI クエリに対応しているので簡単です。

ログイン時の URL の最後に「?locale=en_US」を付けるだけ。

https://<Web Client Server>:9443/vsphere-client/?locale=en_US


日本語


URI クエリに「?locale=en_US」を付けると、、、

# は自動的に付与されます


簡単に英語表記にできます

VMware KB 1016403: Forcing a localized vSphere Client or vSphere Web Client installation to launch in a localized language/English
http://kb.vmware.com/kb/1016403

おまけ1


Web Client でアドレスバーが赤くなるのを消すには
SSL 証明書を正規 PKI のものに差し替える必要があります。
手順は下記の KB のとおりに進めることをお勧めします。

VMware KB 2034833: Implementing CA signed SSL certificates with vSphere 5.1
http://kb.vmware.com/kb/2034833

おまけ2


今回と似た話で、Web 上の PDF ファイルをリンクする際に「#page=ページ番号と最後につけると、ブラウザからアクセスする際に指定したページが開きます。プリセールス必携 Tips です。

例: http://www.vmware.com/.../vsphere-51-configuration-maximums_JA.pdf#page=5

VMware vSphere 5.1 の SR-IOV 構築手順 - (4) まとめ と SR-IOV の将来

f:id:ogawad:20190203195705p:plain:right

(1) (2) (3) (4)

まとめです。


SR-IOV の効果的なシナリオ

良いことばかり書いてしまいましたが、デメリットもあります。
vSphere 5.1 や KVM の SR-IOV はとてもピュアな実装です。
色々手を加えている Hyper-V と違い、VF を割り当てた仮想マシンは vMotion や HA・スナップショットなどが使えなくなります。




vMotion や HA が使えないなんて...
「仮想化のメリットが削がれる」と感じるかと思います。私もそう思います。


以前に Lync Server の例 を挙げましたが、こういった SR-IOV の対象になるようなエンタープライズ・クリティカル系のアプリは、MSCS や独自方式による 「アプリレベルの冗長化 が必要とされ、HA や vMotion といった仮想マシンレベルの冗長化は取らないケースがほとんどです。バックアップについても、ハイパーバイザースナップショットではなく、きちんとした手法が求められます。

ブログタイトルのとおり、それなりの数の実案件に携わらせていただいていますが、仮想マシンが数百になるような大規模統合基盤・社内プライベートクラウドでは、どうしても数%くらい MSCS/WSFC を必要とするサーバーが残るものです。


そして、高度な冗長化が求められるアプリは、得てして高い性能を求めます。
SR-IOV は vMotion や DRS でバンバン移動するような一般サーバー用ではなく、
従来 "ご法度" とされていた重鎮ミドルウェア、つまり エンタープライズアプリの仮想化を実現する機能 と捉えるべきです。


具体的に思い浮かべると、、
I/O が激しかったり、サポートがうるさいものばかり。


つまり今後は、

仮想マシンレベルの冗長化で良ければ SR-IOV は使わず VMware HA で冗長化
アプリレベルの冗長化が必要であれば SR-IOV + MSCS。

というような使い分けが、
顧客ニーズとテクノロジーの落としどころになってきそうです。


SR-IOV の将来

SR-IOV 単体だと Live Migration や HA はできませんが、
前回 のとおりソフトウェア仮想スイッチでは 10Gbps 超のスイッチングはかなり厳しく、将来的にはミドル〜ローエンド層の対応、つまり汎用化が必至です。
この部分については、IEEE 802.1Qbg (EVB: Edge Virtual Bridging) という
IEEE の標準規格があり、ネットワークベンダー各社が対応を進めています。

仮想スイッチ技術の標準「EVB」、ライブマイグレーション時の運用自動化へ
http://itpro.nikkeibp.co.jp/article/COLUMN/20110920/368989/


SR-IOV 対応 NIC/CNA は量産化されました。あとはこれに VEB (Virtual Ethernet Bridges)VEPA (Virtual Ethernet Port Aggregator) という拡張技術が加われば Live Migration や HA も実現できるようになります。




IEEE 802.1Qbg EVB, VEB/VEPA についての詳細は次の資料を参照ください。


ちなみに、Windows Server 2012 Hyper-V では SR-IOV と Live Migration の併用を既に実用化しています。こちらは VEB/VEPA ではなく、業界の誰もが「それやるか!?」と驚いた とても高度な実装 です。


VMware vSphere 5.1 で SR-IOV を利用するための要件

最後に、vSphere 5.1 で SR-IOV を利用するための要件をまとめておきます。

現行モデルであればそれほど大きな敷居はありません。
ですので現時点では SR-IOV は考えていなくても、これから仮想化用のハードウェアを調達するのであれば、将来のことも考えて SR-IOV 対応品を選んでおいた方が無難だと思います。*1
ハードウェア買い直すより、設定変更で済んだ方がマシですよね。


  • ハイパーバイザー
    • VMware ESXi 5.1 Enterprise Plus
    • GUI で設定したい場合には WebClient が必要
    • Distributed Switch (vDS) は不要


なお、上記のいくつかは VMware のマニュアルに記載がありますが、
最新情報については下記のチェックもお勧めします。

VMware KB 2038739: SR-IOV support status FAQ
http://kb.vmware.com/kb/2038739



2013.03.14 Cisco さんのホワイトペーパーを追加。一部の表現を変更しました。
2013.05.21 SR-IOV のゲストサポートに関する KB (2045704) を追記しました。

*1:ハードウェアが SR-IOV さえ対応していれば、IEEE 802.1Qbg EVB 対応は通常ファームウェア更新だけで済むと言われているため。

*2:VM-FEX + SR-IOV で VEPA っぽい動きを取ります。詳しくは こちら

VMware vSphere 5.1 の SR-IOV 構築手順 - (3) ゲスト側の設定

f:id:ogawad:20190203195705p:plain:right

(1) (2) (3) (4)

VF を割り当てた仮想マシンを立ち上げましたら、最後にドライバを適用します。


ゲストへの VF ドライバの適用

VF NIC を割り当てた仮想マシンを立ち上げた直後のデバイスマネージャーです。


SR-IOV の VF は仮想化によるエミュレーションではなく、物理 NIC のパススルーです。このため、ベアメタル時と同様に、ゲストのインストール CD にドライバが INBOX されていない NIC の場合は手動適用する必要があります*1

ドライバは通常サーバーベンダーのダウンロードサイトから探します。
VMware ESXi の項目を探しがちですが、ゲスト内に適用するドライバですので間違えないようご注意ください。なお、ドライバは次のように SR-IOV の仮想機能 (Virtual Function: VF) への対応が必要です。

...
バージョン:7.4.31.0
機能強化
・マルチポートネットワークアダプターに対して一貫性のあるデバイス命名(CDN)をサポートしました。
Microsoft標準フロー制御オプション“自動”をサポートしました。
・Single Root I/O Virtualization (SR-IOV) 仮想機能デバイスをサポートしました。

バージョン:7.4.29.0
機能強化
...


ゲストに VF ドライバを適用できれば、SR-IOV のセットアップは完了です。


パススルーですので、NIC の持つファンクションをフルに利用できます。
これも SR-IOV の魅力の1つです。もちろんチーミングも。



SR-IOV がパススルーするのはソフトウェア仮想スイッチ

(1) でも解説したとおり、SR-IOV は PCI パススルーの上位技術です。
vSphere は元々 PCI パススルー機能を有していたので、今回実装された SR-IOV も多くの設定が共通になっています。




なお、一連の構築手順の中で 仮想スイッチ (vSS, vDS) が一度も登場しなかったことに気づかれた方いますでしょうか??

これこそが SR-IOV の最大のキーポイントです。
vSwitch は複雑かつソフトウェア処理であるため CPU のロス(オーバーヘッド)や転送遅延に課題があります。

1Gbps であれば CPU で回して全然問題ないのですが、昨今主流の 10Gbps、そして今年から対応製品がどんどん出てくる 20Gbps, 40Gbps になると今日の CPU でも持ちません。CPU が耐えられなければ、せっかく新設した 10Gbps 超えネットワークもフルスピードを出せず、意味がなくなってしまう...

このような課題を根本から改善するのが SR-IOV というわけです。



なお、Microsoft の Web サイトにHyper-V を選ぶ理由」という、非常にアグレッシブなタイトルの資料があります。この資料の P.17 に「vSphere 5.1 の SR-IOV は Distributed Switch (vDS) が必要だから Hyper-V にしておいた方がいいよ」的なメッセージがあるのですが、これは間違いです。

vDS や vSS 以前の話で、
そもそも vSphere の SR-IOV はソフトウェア仮想スイッチを使っていません。

前述のとおり、仮想ネットワークの主な目標は、ネイティブ I/O の実現です。SR-IOV を使用すると、顧客は、仮想マシンから物理ネットワーク インターフェイス カードのアドレスを直接指定できるため、CPU のオーバーヘッドおよび待機時間を低減すると同時に、スループットを向上できます。vSphere 5.1 では、VMware は SR-IOV のサポートを導入しましたが、これには最高エディションの vSphere にのみ搭載されている vSphere Distributed Switch 機能が必要です。

http://download.microsoft.com/download/B/F/4/BF474812-BE9E-41CE-9F5F-6C6E2F0B5B22/Competitive_Advantages_of_Windows_Server_2012_Hyper-V_over_VMware_vSphere_5.1_ja.pdf#page=17


1ページが長くなってしまいました。残った「vMotion できるの?」「SR-IOV ってどんな時に使うの?」については 次回 をご覧ください。

*1:Windows Server 2012 の場合は SR-IOV VF ドライバがいくつか INBOX されています。しかし、バージョンが古すぎることもあるため、新しいバージョンが無いかの確認をお勧めします。

VMware vSphere 5.1 の SR-IOV 構築手順 - (2) ESXi ホスト側の設定

f:id:ogawad:20190203195705p:plain:right

(1) (2) (3) (4)

ハードウェア側で SR-IOV が有効になりましたら、次に ESXi 側の設定を行います。
設定手順は VMDirectPath I/O とほぼ一緒ですので、前回の最後にご紹介した
SR-IOV と VMDirectPath I/O の関係 を思い出すと理解しやすいかもしれません。


ESXi ハイパーバイザー側で SR-IOV を有効化する

下記は通常時の VMDirectPath I/O(PCI パススルー)の画面です。
SR-IOV はまだ有効になっていません。


ここで SR-IOV を有効にします。
PowerShellCLI 設定した Hyper-V と同様に、ESXi も CLI (esxcli) で設定します。

# esxcli system module parameters set -m <ドライバ> -p "max_vfs=<VF 数の配列>"

# esxcli system module parameters list -m be2net

Name               Type          Value     Description
 ----------------  ------------  --------  -------------------------------
heap_initial       int                     Initial heap size allocated for th...
heap_max           int           20971520  Maximum attainable heap size for t...
max_vfs            array of int            Number of Virtual Functions: 0 = d...
skb_mpool_initial  int                     Driver's minimum private socket bu...
skb_mpool_max      int                     Maximum attainable private socket ...
vlan_offload       uint                    Enable or disable VLAN HW offload ...
#
#
# esxcli system module parameters set -m be2net -p "max_vfs=16,16"
#
#
# esxcli system module parameters list -m be2net

Name               Type          Value     Description
 ----------------  ------------  -----  -------------------------------
Name               Type          Value  Description
heap_initial       int                  Initial heap size allocated for the d...
heap_max           int                  Maximum attainable heap size for the ...
max_vfs            array of int  16,16  Number of Virtual Functions: 0 = dis...
skb_mpool_initial  int                  Driver's minimum private socket buffe...
skb_mpool_max      int                  Maximum attainable private socket buf...
vlan_offload       uint                 Enable or disable VLAN HW offload fea...
#
#


SR-IOV を有効にするパラメータは 「max_vfs だけです。
このパラメータは項目名のとおり SR-IOV VF *1 の設定で、マニュアルには次のように書かれています。

コンマ (,) で区切られたリストに値を設定します。このリストは、個々の物理機能に設定する仮想機能数の一覧です。値 0 は、物理機能で SR-IOV が有効にならないことを意味します。

たとえば、デュアル ポートがあり、それらに次の値を設定したとします。

x,x
ここで、x は作成する VF 数です。

Emulex NIC の有効値は、ポート当たり 0 〜 16 です。
単一ホストの VF 合計が 64 ならば、デュアル ポート カード 2 枚を 16,16,16,16 に設定する必要があります。

http://pubs.vmware.com/vsphere-51/topic/com.vmware.vsphere.networking.doc/GUID-C5043E19-F84D-4E2E-9162-16D9967C2DB8.html

分かりにくいので少し解説すると、VF とは SR-IOV NIC に内蔵された仮想スイッチのポートです。このポート数は NIC によって異なり、今回利用した Emulex BE3 の場合は、上記マニュアルのとおり「1ポートあたり 16 VFs」になります。
これをカンマ区切りの配列として入力します。

  • Emulex BE3 2ポートモデル x 1枚の場合(計2ポート)
    • max_vfs=16,16
  • Emulex BE3 2ポートモデル x 2枚の場合(計4ポート)
    • max_vfs=16,16,16,16

なお、max_vfs の設定は GUI(ホストプロファイル)でも行えます。
但し、SR-IOV は vSphere 5.1 の新機能であるため WebClient で設定する必要があるそうです。従来の Win32 版の vSphere Client ではダメらしいのでご注意ください。


ESXi ハイパーバイザーで SR-IOV が有効になると、
先ほどの VMDirectPath I/O の画面が変化します。


冒頭の画像では 07:00.1 と 07:00.2 と2ポートしかなかった「Emulex〜」ですが、SR-IOV を有効にしたことで増殖しています。これが先ほど有効化した VF です。
今回の CNA は 16 VFs x 2ポートでしたので、合計 32 VFs が追加されています。


仮想マシンに VF NIC を割り当てる

ハイパーバイザーが VF を正しく認識したら、ゲストに VF NIC を割り当てます。

この作業は VM DirectPath I/O と全く一緒でPCIバイスとしてマップします。仮想マシンバージョンが 8 で良ければ vSphere Client でも設定可能です。




VF NIC は適当に割り当てるのではなく、次のような意識が必要があります。


Hyper-V は PF NIC をハイパーバイザー内の仮想スイッチに割り当てるので、このあたりは自動化されます。これに対し、VMware の場合は PF は完全にノータッチなため、管理者は上記のようなポイントの理解が必要ですが、それだけ柔軟な制御・設計が可能です。
一般的には、冗長化チーミング)を考慮して、物理ポートが異なる VF NIC をペアにして仮想マシンに割り当てていくことになると思います。



通常の仮想 NIC と比べて GUI からは何も設定できません。
構成情報ファイル (*.vmx) を覗くと、次のパラメータが追加されています。

pciPassthru0.present = "TRUE"
pciPassthru0.deviceId = "710"
pciPassthru0.vendorId = "19a2"
pciPassthru0.systemId = "50be25f8-ff8a-ae24-da12-2c768a53dd70"
pciPassthru0.id = "07:04.0"


仮想マシンの初回起動時には、下記パラメータも追加されます。「00-0c-29」から始まるこの MAC アドレスは物理 NIC の OUI ではなく VMware 社の登録 OUI です。つまり仮想アドレスですので pciPassthru0.generatedMACAddress を修正することで値を変更できます。

pciPassthru0.pciSlotNumber = "224"
pciPassthru0.MACAddressType = "generated"
pciPassthru0.generatedMACAddress = "00:0c:29:52:3b:ca"
pciPassthru0.generatedMACAddressOffset = "101"


仮想マシンを立ち上げるところまで来ました。
次回 はゲスト側の設定内容と制約事項について説明します。

*1:Virtual Function の略。SR-IOV NIC に内蔵された仮想スイッチのダウンリンクポートのこと。

VMware vSphere 5.1 の SR-IOV 構築手順 - (1) ハードウェアの設定

f:id:ogawad:20190203195705p:plain:right

(1) (2) (3) (4)


昨年、Windows Server 2012 Hyper-V における
SR-IOV (Single Root IO Virtualization) の構築方法をご紹介しました。

SR-IOV とは、通常ハイパーバイザー側にソフトウェア実装される「仮想スイッチ」機能を NIC の中に内蔵するという技術です。Intel-VT の NIC 版みたいなイメージ。

  • スイッチング処理に CPU 負荷が掛からない
  • レイテンシ(遅延)が圧倒的に小さい
  • 物理 NICスループットをフルに発揮できる

のように、仮想スイッチのデメリットを克服したシステムを実現できます。
実際 アプリ側が仮想化の条件として推奨し始めている ほか、10Gbps ファイルサーバーやバックアップサーバーといった I/O 系の仮想化 で非常に注目されています。但し、SR-IOV はゲスト側でチーミングが必要になるなど、正直使いづらい部分もあるため、アーキテクチャーの正しい理解が必要です。


基本的には、かなりエンタープライズな仮想化システムでの使われる技術ですが、この領域で最多のインストールベースを誇る VMware vSphere も、Hyper-V とほぼ同時期に出荷した最新のバージョン 5.1 で SR-IOV をサポートしました。


 VMware が選択される7つの理由 P.13 より。表示領域の都合で一部割愛しています。


ハードウェア側で SR-IOV を有効にする

それでは、実機を使って SR-IOV を設定していきたいと思います。

仮想化では、ハイパーバイザーに搭載される「仮想スイッチ」にを利用するのが通常ですが、SR-IOV はこれを利用せず、対応 NIC に内蔵されているハードウェアベースの仮想スイッチを使うことで、処理をオフロード・高速化するものです。
したがって、まずはハードウェア側で SR-IOV を有効化することが必要です。

サーバー

下記3点を有効化します。パラメーター名などは各社・機種ごとに異なりますので、各社へお問い合わせください。

  • 仮想化支援 (CPU, MEM)
    • Intel VT-x2 (EPT) もしくは AMD RVI
  • 仮想化支援 (I/O)
    • Intel VT-d もしくは AMD IOMMU
    • SR-IOV


NIC / CNA

SR-IOV を有効化します


これらの設定は ESXi をインストールしてしまった後でも大丈夫です。
なお、対応サーバーでも、装着する PCIe スロットによって SR-IOV を利用できないケースがあるようです。うまく動かないようであればスロットを変えて試してみると良いかもしれません。


ESXi の SR-IOV は VMDirectPath I/O がベース

まだ SR-IOV 対応ハードウェアが出回っていなかった vSphere 4.0 の頃、
VMware は「VMDirectPath I/O」(いわゆる PCI パススルー)を実装しました。


上記イメージ画像からも分かるとおり、SR-IOV は PCI パススルーの上位技術です。
このためか(もしくは急遽追加実装したか) ESXi 5.1 での SR-IOV 設定手順は多くが VMDirectPath I/O と共通になっています。


このあたりを踏まえつつ、次回 は ESXi 側の設定について解説します。