Windows Server 2012のHyper-Vより、 SMB 3.0プロトコルに対応したNASストレージへの仮想マシンの配置がサポートされている。VMwareにおけるNFSデータ・ストアと同じ位置付けだ。現時点では本格採用にあたっては、細かな点でまだ発展途上な面も残るが、今後主流になり得るものでもあるため、長所短所は知っておこう。
各種NASストレージの機能比較を次に示しておく。
SMB 3.0 | SMB 3.0 + RDMA | ||
伝送方式 | イーサネット | ロスレス・イーサネット | InfiniBand |
現在主流の転送帯域 | 10Gbps 1Gbps |
10Gbps | 54Gbps 32Gbps |
ゲスト・クラスタリングの実現方式 | VHDX共有 仮想NIC |
VHDX共有 | |
プロセッサ負荷の軽減 | × | ○ | |
設計・構築の容易さ | △ | × | |
対応機器の豊富さ | △ | × | |
適合するシステム規模 | 中〜小 | 大〜中 | |
表3「Windows Server 2012 R2のHyper-VにおけるNASストレージの比較」 ほかのハイパーバイザと違い、Hyper-VはNFSには非対応であることに注意しよう。SMB/CIFSに対応するNASストレージは数多くあるが、SMB 3.0のサポートが必要である。 |
では、仮想マシンをNASストレージに配置する場合に考慮しなければならない課題を解説しよう。
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ネットワークのマルチホーム構成を取らなければならない。
SMBはイーサネットをベースにするため、前述のiSCSIと同じく性能不足のリスクがある。10GbEを用意すれば解決できるが、そうなると割安感はなくなり、また速度に比例してプロセッサに多大な負荷が掛かってしまう。
ただし、この3つ目の課題はハードウェアの技術で克服することも可能だ。サーバとストレージ間のイーサネット・ネットワークの代わりに「RDMA(Remote Direct Memory Access)」に対応した次世代ネットワークを用意できれば、SMBダイレクト機能によってプロセッサに負荷を掛けずに低遅延で通信できる。
現行製品で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モード」である。
しかしながら、この機能を使って実際に設計・構築していくと「あれ?」と感じることがある。ファイル・サーバに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”として広く利用されるようになるはずだ。今後の改良に強く期待したい。
Copyright© Digital Advantage Corp. All Rights Reserved.