SDDCシリーズ 第3回: 仮想化が従来型ストレージの欠点を露呈
全４回シリーズ「Software-Defined Data Centerの到来、および、ストレージ、ネットワーキングとサーバーの主要動向」 第3回
ストレージとSoftware-Defined Data Centerに関する第1回の投稿では、標準化やハードウェア、抽象化のブレークスルーが、コンピューティングやネットワーキングにどのように劇的な変化をもたらしたのかについてご紹介しました。ハイパーバイザーが下位のコンピューティングソースを抽象化しプールするのと同様に、似たような方法を使ってストレージのバックエンドの複雑さを抽象化し、取り除く必要があります。同時に、その「何か」は、抽象化された基本的なオブジェクト、すなわちVMをネイティブで理解する必要があります。VMではなく、LUNとボリュームが基本的な構成要素であるディスクベースのストレージの限界を考えると、これは口で言う程たやすいことではありません。
丸い穴に四角い杭(くい)
この問題を回避するために、APIを使って仮想化製品を従来型ストレージに対応させようとしているベンダーもいれば、従来型ストレージを改造して仮想化環境を認識させることができないかと考えているベンダーもあります。
このテーマに関して、米VMware社のダンカン・エピング氏が最近、洞察力のある意見を投稿しています。ダンカンは次のような意見を述べています :
「Software-Defined Storage (SDS)領域の利用には、多くのストレージプラットフォームを大幅に変更する必要が出てきます。なぜなら、ほとんどのストレージプラットフォームは設計時にこのような利用を全く想定していないからです。今のところプログラムで数千の新しいオブジェクトを生成できるプラットフォームはほとんどありません。さらに、多くのプラットフォームのAPIは公開されていません。しかし、今日の問題は、多くのストレージシステム上で公開APIがない点だけではありません。それらのAPIを使ってさえもストレージシステムを効率良く管理することが不可能なプラットフォームであることも問題なのです」
問題は公開APIだけではない、という点において、私はダンカン氏に完全に同意します。APIを使って従来型のシステムを設定しようと試みれば、人工知能に似た何かが必要となり、簡単なことではないのは明らかです。加えて、ストレージのベンダーは、プログラムで管理可能なVMを認識するアーキテクチャを実装する必要が出てきます。ここでもまた、ベンダーは自らのシステムを再設計し、核となるOSとファイルシステムに変更を加え、本質的に自社製品をコモディティ化することになる何らかの標準を採用する必要がでてきます。現在、進んでこれを実行したがる既存ベンダーはいないでしょう。
相変わらずの従来手法
仮想化を認識するレイヤーを開発しなければ、SDDCに最適化された仮想化を認識するストレージを考え出すのに従来のベンダーは頭を抱えることになります。したがって、仮想化インフラをネイティブに理解しないLUNとボリュームをベースとした従来型ストレージの採用となり、それはVMレベルのデータ管理やトラブルシューティング、データ保護を行わないということを意味することになります。
また、従来型ストレージを使用して、仮想化環境上のエンタープライズアプリケーションに対応しようとすると、これらの欠点が輪をかけて目につくようになります。仮想化されたデータベースやビジネスインテリジェンスおよびコラボレーティブアプリケーションからのランダムI/O要求に対しては、ディスクの本数ばかり増えてしまうだけにとどまらず、根本的な問題さえ解決できません。それはまた、不必要な過剰容量の追加となり、さらに多くの領域とエネルギーの浪費や管理のオーバーヘッドの増加につながります。何か支障が出た時やパフォーマンスの問題が露呈した場合、その根本的な原因がどこにあるのか見当もつかないでしょう。
本シリーズの最終回となる次の投稿では、これらの問題を打開するシステムを構築するにはどうすれば良いのかについて考えていきます。
「第2回: ストレージのバリアを越えて」を読む
