HOME > ストレージ管理ソリューション部会 > Storage Magazine翻訳記事

HCIにおけるハイパーバイザサポートの進化

ハイパーコンバージド・インフラストラクチャーにおける過去と現在のハイパーバイザのあり方と、高まりつつあるKVMの人気を吟味する。

2018年9月号Storage Magazineより
Scott Lowe

この2～3年の間に、ハイパーコンバージド・インフラストラクチャー（HCI）は、データセンター・アーキテクチャー市場の中で日に日に複雑さを増すセグメントになった。ハイパーコンバージェンスの定義は、この技術がより対象を絞り込んだ製品に使われて細分化を続けるとともに拡張してきた。時とともに進化してきたHCIの重要な一面は、ハイパーバイザのサポートである。

ハイパーコンバージェンスにおけるハイパーバイザの使用例は様々だ。一般的なハイパーコンバージド・システムの初期の製品はVMwareおよび（後になって）Microsoftのような会社が提供する機能を拡張することに主眼を置いていた。VMware vSphere やMicrosoft Hyper-V用の初期のハイパーコンバージド製品は、見た目や機能が今日(こんにち)のハイパーコンバージド製品に入っているハイパーバイザにそっくりだ。しかし、ざっくり言うとこれらの製品は中小企業のために簡素化とストレージコストの低減を目指して作られたものだった。しかし、時がたつにつれて、一部のHCIベンダーは、従来のハイパーバイザの代替としてオープンソースのKVM（Kernel-based Virtual Machine）に目をつけた。HCIのパイオニアであるNutanixはKVMベースのハイパーバイザを使っているベンダーの中の1社だが、ベンダーは他にもある。

この数年間、HCIで使われているハイパーバイザの実例を調べるとともに、ハイパーコンバージェンスの中のハイパーバイザの役割がどう変化してきたか、どう進化を続けているかを検証しよう。

vSphereの興隆

初期のHCIベンダーにとってvSphereのサポートは極めて合理的なことだった。MicrosoftのHyper-VやKVMの成長によって市場支配に陰りが出てきたものの、VMwareは（今でもそうだが）ハイパーバイザ市場のリーダーだった。Emailのオフプロミスへの移行中、CRM（顧客管理）プラットフォームのデプロイなどのニーズを仮想化より安く満たしてくれる選択肢を探している企業は、パブリッククラウドに注目し始めた。これらの変化のせいで、vSphereを含むオンプレミス・サービスのニーズは少なくなった。VMwareはもちろん、新しいサービスや、Amazonデータセンター内のvSphereを直接操作できる機能をはじめとする新しいオペレーション方法の追加などを行うことによって、懸命にvSphereの凋落への対抗策を打っている。

vSphereの市場支配の理由のひとつは、VMwareが過去15年成長する中で生まれてきた広範なエコシステムだ。今日(こんにち)、vSphereをサポートする製品を提供している会社は、数千とまではいかなくとも数百は存在する。

KVMの世界に入る

このようにvSphereの広大なエコシステムと成熟した機能を考慮すると、なぜ人々はKVMが気になるのだろうという疑問がわいてくる？理由のひとつはコストだが他にもいくつか理由がある。

KVMによって、企業はハイパーバイザのライセンス費用を減らすことができる。エンタープライズのライセンスモデルで言えば、Hyper-Vは一般的にそれほど高価ではない。しかし、vSphereのユーザーはここ数年上がり続けるコスト問題に直面しており、CIOおよびその他の意思決定者に難しい選択を迫っている。vSphereは多くのデータセンターの中核になっており、それを別なものに置き換えるのはコストがかかり、技術的にも難しい。しかし、vSphereとその競合のハイパーバイザの価格差が広がるにつれて、企業が「VMware課税」を回避するという経済的理由がクローズアップされてきた。企業内では。たとえ困難であっても、大きな変化に取り組むことを正当化しやすくなった。

この機会を見て、HCIベンダーはKVMのサポートの導入や、そのオープンソース・ハイパーバイザをベースとしてプラットフォームの構築を行った。多くのハイパーコンバージド製品がシンプルに設計されているためKVM用ハイパーコンバージェンスもシンプルな形で始まった。最も多く使われているのは仮想ストレージアプライアンス（Virtual Storage Appliance：VSA）と呼ばれるものだ。VSAはハイパーコンバージド・ノード上で稼働しながらローカルストレージを管理し、クラスター内の他ノードで稼働するVSAと連携するVMである。このVSAのモデルは柔軟性を提供し、HCIベンダーがスワッピングをサポートしていれば、ハイパーバイザをスワップアウトすることもできる。一部のベンダーは初期の頃から、vSphereの他にHyper-VやKVMのサポートも行っていた。

一部のハイパーコンバージド会社は、単にKVMをサポートに加えるのではなく、自社のプラットフォーム全体を、KVMハイパーバイザをベースに構築した。このようなケースでは、KVMはアーキテクチャーの核となっており、他のハイパーバイザをサポートする予定を持たない。VSAセントリックのハイパーバイザのサポート形態がVSAを使うのに対し、複数のハイパーバイザをサポートしないHCIアーキテクチャーではこのストレージ管理の抽象化について心配する必要がない。ローカルノードのOSがローカルストレージへのアクセスを提供してくれるし、いくつかのケースでは、カーネルのハイパーバイザ・モジュールがこの目的を達成してくれるからだ。VSAを持たないアーキテクチャーには、単純化のメリットがあり、製品の作り方によってはパフォーマンスのメリットもある。

さらに、KVMを自社プラットフォームの重要部分として選択した、Cloudistics Inc., Nutanix, Scale ComputingなどのHCIベンダーは、現在のエンタープライズ内のハイパーバイザに期待される一連の機能を満たすべく、KVMを修正、拡張してきた。例えば、Scale ComputingはScribe（Scale Computing Reliable Independent Block Engine）という名前の特許技術が使われたストレージシステムを製品に加えている。Scribeは技術的にKVMに追加されているのではないが、Scale Computing版KVMと連携して、VSAや他のストレージ機能に依存する他のHCIプラットフォームをパフォーマンスの面で凌駕している。もちろん、ストレージはハイパーコンパージドプラットフォーム全体のほんの一面にすぎない。CloudisticsとNutanixは自社のプラットフォームにより多くのネットワーク機能を持ち込み、KVMハイパーバイザと共にユーザーが使える機能を追加している。例えば、Cloudisticsは、ソフトウェア定義のネットワーク（SDN）の機能を追加し、より深いレベルでアプリケーションのコントロールを可能にしている。Nutanixは最近Flowをリリースした。この製品は、ネットワークの先進的機能とアプリケーション・セントリックのネットワークセキュリティ機能を提供する。 NutanixのFlowサービスはKVMをベースとしたAHV仮想化と緊密に連携している。AHVはNutanix Acropolis用のハイパーバイザ、即ち同社のHCI用OSである。

新興ベンダーのリスクは重大な懸念事項か？

KVMやその他のここに挙げられたハイパーバイザを使うことにはトレードオフがある。VMwareのエコシステムは広大であり、VMwareがすぐに無くなることはないだろう。Nutanixは2016年に上場し、経営は順調に見える。しかし、KVMセントリックのハイパーコンバージド・システムを提供するCloudistics、Maxta、Scale Computingなど他の新興ベンダーは、いまだに未上場のままだ。そして、その技術がどんなに強力に見えても、あなたが製品を買った会社が長く保たずに潰れてしまうリスクも常につきまとう。

私のアドバイスはこうだ。どうせ、あなたのハイパーバイザ・ベンダーが永久に存続するかなんてわかりっこないのだから（そもそもそんなこと、どうやってわかる？）、もっと短い時間軸で考えてみよう。もしあなたの会社の更改サイクルが3年～5年ならば、あなたにとってハイパーバイザ・ベンダーが存続すべき時間は、その長さだ。製品を購入後ベンダーが5年以上もてば、あなたは次の更改サイクルに入っているだろう。

教育、スキル、トレーニング

仮想化に関わったことがある企業ならば、その期間の長短にかかわらず、VMwareやMicrosoftについての熟練したスキルを持ったITスタッフがいることだろう。それゆえ、KVMを学ぶことは、非常に高い障壁になるかもしれない。HCIのような新しいアーキテクチャーに挑戦しようとしているならなおさらである。

とはいえ、実はこれに関して重要なポイントがある。KVMをハイパーバイザの唯一のオプションとして使うHCIには、使いやすいインターフェースが入っており、これが切り替えに伴う複雑さを、全てとまではいかないがそのほとんどをカバーしてくれる。私のラボには、私がプロジェクトのテストと構築に使っているノードのScale Computingクラスターがある。このシステムのハイパーバイザ管理インターフェースは、言わせてもらえば露骨なほど何もかもむき出しである。これは否定的な意味で言っているのではない。また、自分はコマンドについてのうるさ方ではないのだが、それにしてもScale Computingの管理インターフェース機能は随分少ない、と言わせてもらおう。全てはただただpoint&clickだ。例えば、VMを他のノードに移そうと思ったら、”Move VM”のアイコンをクリックしてノードを選ぶだけだ。スナップショットをリモートのクラスターに送るためのスケジュールを設定するには、クリックを２、３回するだけだ。他のKVMセントリックのハイパーコンバージド・プラットフォーム（例えばCloudisticsやNutanix、AHV）は、Scale Computingよりもハイパーバイザの機能が多い。反面、これらはより複雑だ。一部の人にとってはそれがメリットだし、他の人々にとってはそうでない。もしあなたが、仮想化について確固とした土台を持っているのであれば、一部の製品にはないような深いレベルの設定パラメーターが欲しいと思うかもしれない。個々のパラメーターを調整せずに、どうやってクラスターを最大限に活かせるというのだ？　あなたが望むハイパーバイザの設定変更機能のレベルを得られるように、思いつきで買う前に、ハイパーコンバージド製品をよく比較検討することだ。

おそらくスキルが関係する最大の課題は、数百あるいは数千のVMをいかにVSphereからKVMに移行するかということだ。Red Hatのvirt-v2vやCarboniteのHC3 Move Powered は、VMやWindows ServerからKVMフォーマットへの移行を手助けしてくれる。

HCIのなかのKVMの未来

vSphereが未だに市場を支配し、Hyper-Vが伸び続け、企業がさらなるワークロードのためにクラウドに注目しているこの時に、何故ハイパーコンバージド・ベンダーはKVMの道を選んだのだろうか？　前述したとおり、コストはその大きな要因である。KVMはVMwareほど高価でなく、HCIベンダーはユーザーがKVMに移行した時にできる諸々の機能の穴を埋めることで良いビジネスをしている。

その一方で、状況はさらに先に進んでいる。HCIベンダーはユーザーに対する自社の差別化と完全なプラットフォームを提供する方法を模索している。価値を最大化するためには、ベンダーはすべてのスタックをコントロールしなければならない。vSphereまたはHyper-Vしか使わないハイパーコンバージド・ベンダーにとって、ハイパーバイザをカストマイズする余地はほとんどない。あらゆるハイパーコンバージド・システムの核となる部分であるハイパーバイザの内容を、自社製品やユーザーのニーズに合わせるべく変更したくてもできないのだ。KVMはオープンソースなので、状況は違ってくる。ベンダーは、HCIプラットフォームの設計ゴールにあわせるために必要な変更は何でもできる。

パブリッククラウドは、HCIのベンダーがKVMセントリックモデルを採用するさらに良い理由を提供してくれた。GoogleとAmazonは、KVMベースのワークロードのサポートを提供している。GoogleのCloud Platformは多大な修正と堅牢化が施されたKVMベースのハイパーバイザ上で稼働する。また、2017年後半に、AmazonがNitro KVMベースのハイパーバイザをリリースした。Amazonは、全てのインスタンスをNitroに変換し、Xenのハイパーバイザをお役御免にする予定だ。これにより、アーキテクチャー間で常にワークロードを変換する必要がなくなり、パブリッククラウドとオンプレミスのデータセンター環境にまたがるハイブリッドクラウド環境を作成するのは、これまで以上に容易になった。KVMセントリックのHCIシステムを採用したものにとって、HCIベンダーとKVMセントリックのクラウドプロバイダーがパートナーシップを結ぶのを見るのはごく普通になりつつある。このパートナーシップによって、企業はオンプレミスとクラウドにまたがる環境を作成するのが容易になった。私はオープンソースこそが企業の全てのシステムが進むべき道、とは思わない。しかしハイパーコンバージェンスに限って言えば、KVMのオープンな性質によって、ベンダーが統合的HCIプラットフォームを構築する際、ものすごい魅力になっているのは間違いないと思う。

ユーザーにとってもメリットがある。コスト、選択の幅、ワークロード・アプリケーション、データセンターについての考え方など、新たなソリューションが見えてきた。しかし、もちろんマイナス面もある。そこにはITスタッフのスキルセットを修正したり、VMwareに比べれば未熟なエコシステムに適応したり、vSphereのような他社の確立した統合的テクノロジーから移行しなければならないことも含まれる。KVMセントリックのハイパーコンバージド・システムを提供しているベンダーは、これらのマイナス面を少しでもなくすよう努力している。今は高価なハイパーバイザを使っている既存プラットフォームの領域のほとんどで、KVMセントリックのハイパーコンバージド・システムが既存システムに拮抗する勢力になる日がいずれ来る、と私は期待している。

著者略歴：Scott LoweはActualTech MediaのCEOにして、1610 Groupの元CIO・創業者・経営コンサルタント。Twitterアカウントは@OtherScottLowe.