第2回　Hyper-Vと最新のストレージ・テクノロジの併用：Windows Server 2012 R2時代のHyper-Vサーバ設計術（2/4 ページ）

NASストレージの比較

　Windows Server 2012のHyper-Vより、 SMB 3.0プロトコルに対応したNASストレージへの仮想マシンの配置がサポートされている。VMwareにおけるNFSデータ・ストアと同じ位置付けだ。現時点では本格採用にあたっては、細かな点でまだ発展途上な面も残るが、今後主流になり得るものでもあるため、長所短所は知っておこう。

　各種NASストレージの機能比較を次に示しておく。

NASストレージを利用する場合の考慮ポイント

　では、仮想マシンをNASストレージに配置する場合に考慮しなければならない課題を解説しよう。

●SMBプロトコルのバージョンに注意

　Hyper-V仮想マシンの配置に利用する場合、単にSMB（CIFS）に対応していればよいというものでなく、最新規格であるSMBプロトコルのVer.3.0に対応していなければならない。（Windows Server 2012と共に）SMB 3.0が登場して1年が経過したが、サポートしているのはまだ一握りの製品だけだ。オープンソースのSambaも現時点では対応していない。このため、SambaベースのNASストレージ、例えばオープンソースの「Free NAS」や家電量販店などで販売されている小型のNAS製品は現状利用できない。

　また、一口にSMB 3.0といっても、メーカーによって多少の“方言”があることも覚えておきたい。Hyper-VホストからのI/Oはいろいろとセンシティブであり、Windows OS以外のストレージの場合、一見問題なく接続できているように見えても思いもよらないトラブルに見舞われることもある。SMB 3.0に対応しているかどうかだけでなく、「Hyper-VホストからのSMB 3.0アクセス」をきちんとサポートしているか、ベンダに確認しておこう。

●ネットワーク設計が意外と難しい

　通常、ストレージは性能やセキュリティの観点から、業務用や管理用とは分離した専用回線を用意するのが一般的だ。これに対し、SMBはファイル共有用のプロトコルであるがゆえ、アクセス認証が必要になる。つまり、ストレージ・ネットワークのどこかにActive Directoryドメイン・コントローラ（DC）が必要であり、その結果DCとHyper-VホストはWindowsネットワークのマルチホーム構成を取らなければならない。

図2「NASストレージにはSMBのマルチホーム構成が必要」
SMBストレージを利用する場合、アクセス認証のためにActive Directoryのドメイン・コントローラやHyper-Vホストをストレージ用ネットワークにも接続させなければならず、管理用とストレージ用のマルチホーム構成での運用を強いられる。この2つのネットワークを統合したり、ルーティングしたりすることで回避できるが、その場合は仮想ディスクに対して厳格なセキュリティ管理が必要だ。

●帯域とプロセッサ負荷に注意

　SMBはイーサネットをベースにするため、前述のiSCSIと同じく性能不足のリスクがある。10GbEを用意すれば解決できるが、そうなると割安感はなくなり、また速度に比例してプロセッサに多大な負荷が掛かってしまう。

●RDMAで一部の課題を克服

　ただし、この3つ目の課題はハードウェアの技術で克服することも可能だ。サーバとストレージ間のイーサネット・ネットワークの代わりに「RDMA（Remote Direct Memory Access）」に対応した次世代ネットワークを用意できれば、SMBダイレクト機能によってプロセッサに負荷を掛けずに低遅延で通信できる。

• 「強化されたファイル共有プロトコルSMB 3.0の概要」（連載 Windows Server 2012クラウドジェネレーション）

　現行製品でRDMAを実現するには2つの方式がある。1つは「CEE（Converged Enhanced Ethernet）」と呼ばれるロスレス型のイーサネット上でRDMAを実現する「RoCE（RDMA over Converged Ethernet）」であり、もう1つはHPCの分野で広く利用されている「InfiniBand」だ。

　「InfiniBandなんて手の届かない世界」と考えがちであるが、実際に検討するとむしろ安価である。56GbpsのInfiniBandと、10Gbpsイーサネット、16Gbps FCのポート単価はほぼ同じだ。つまり、ストレージ・ネットワークをInfiniBandで構成すれば、同じコストでSANストレージより4倍程度高速というアドバンテージがある。

　筆者も実際にテストしたことがあるが、これまでのセオリーをすべて覆されてしまうぐらい速い。具体例を挙げれば、Fusion-io社の超高速半導体ストレージをリモートからネットワーク越しにアクセスしても、ローカルと変わらないI/O性能を得られる。

　コストも性能も文句ないInfiniBandであるが、最大の懸念はイーサネットではないことだ。トポロジなどさまざまな点が異なっており、従来培ってきたネットワークの運用ノウハウはあまり役に立たないかもしれない。また、現時点ではSMB 3.0と56Gbps InfiniBandに両方に対応したストレージ装置はほぼ皆無であり、前述のマルチホーム運用の課題も残る（InfiniBandについては最終回で解説する）。

●スケールアウト・ファイル・サーバ

　Windows Server 2012／R2には、「スケールアウト・ファイル・サーバ（SOFS）」という、主にHyper-Vに向けた機能がある。

　SOFSとは、InfiniBandまで拡張できるSMBストレージをx86サーバとソフトウェアで作ってしまおう、というものだ。EMCやNetAppなどのNASストレージも、箱を開ければその中身はIntel Xeonプロセッサで動く“x86サーバ”であり、そこに独自開発のストレージ専用OSを動かすことで“ストレージ”と見立てている。であれば、1台のx86サーバにWindows Serverを動かし、共有フォルダを設定すれば、そのファイル・サーバは“自作のNASストレージ”とも言えるだろう。

　しかし、Hyper-Vホストは万一のサーバ障害のために冗長化しているのに、同じx86サーバを使うこの自作ストレージはシングル構成でよい、というのは矛盾している。そこで、複数のサーバでWSFCによる共有フォルダの冗長構成が必要となる。ただし、単にWSFCでクラスタリングするだけではノード切り替えの際にダウンタイムがあり、Hyper-V側がI/Oエラーを起こしてしまう。このような背景で新規追加されたのが「SOFSモード」である。

図3「Windows Server OSのスケールアウト・ファイル・サーバ機能」
これはWindows Server 2012 R2のファイル・サーバの種類の選択画面。Windows Server 2012以降のWSFCには、Hyper-VやSQL Serverなどのデータを安全にファイル・サーバに格納できるよう「SOFSモード」が追加されている。
　 （1）スケール・アウト・ファイル・サーバ構成にするにはこれを選択する。

　しかしながら、この機能を使って実際に設計・構築していくと「あれ？」と感じることがある。ファイル・サーバにWSFCを構成するには、SANストレージが必要なのだ。SANの各設備を用意した上で、さらに10GbpsやInfiniBandなどのネットワーク機器も必要になるため、高額な機器を二重に用意しなくてはならない。SOFSはNASとSANの2つのネットワークを仲介する“プロキシ・サーバ”として働くが、Hyper-Vは元々SANストレージに直接アクセスでき、不自由もしていない。SOFSの導入にあたっては、この追加機器への二重投資に対する導入効果をきちんと考える必要があるだろう。

　「結局はSANストレージが必要」ということで、現時点では残念な部分が残るSOFSであるが、業界ではVMwareのVSA（Virtual Storage Appliance）や同社が現在開発中のVirtual SAN、Red Hat Storage Serverなどサーバの内蔵ディスクを利用した分散ストレージが流行の兆しを見せている。SOFSもこういった製品のように、SANストレージに頼るのではなく、自身で高可用化機構が実装されれば、“Software-Defined Storage”として広く利用されるようになるはずだ。今後の改良に強く期待したい。

図4「SOFSの構成イメージ」
NASとSANの2つのネットワークを仲介するプロキシ・サーバのように動作するSOFSであるが、WSFCをベースにしているために結局SANストレージが必要になる。サーバやネットワーク機器を二重投資することになるため、導入にあたっては投資対効果をきちんと判断しよう。