NetApp Tech OnTap NetApp Logo
NetApp Tech OnTap
     
第二回:
そのストレージ縮小できますか?
シェアする NetAppオフィシャルFacebook

前回のコラムでは、NetAppストレージがマルチプロトコルであることと同時にESXのDatastoreについてもFCやiSCSI接続のDatastoreではなくNFSプロトコルを使って接続する方式にメリットがあることに触れましたが、「その詳細については次号に持ち越し」としていましたので(いくつかお叱りも受けてしまいました!)今回の連載においては特にSANストレージでは実現できない「NFSの魅力」について深掘りしたいと思います。

Datastoreの拡張が瞬時におこなえます

一般的なSANストレージにおいてストレージ領域の拡張を実施する際に、その準備段階も入れると、実は数時間もしくは一日作業になってしまいませんか?その背景としては①新規ディスク追加にともなうLUNの作成、②RAIDの構成変更作業、③リビルド時間、④LUNの認識作業、⑤ファイルシステムへの追加作業など、それぞれの作業ごとに時間を要してしまうことが上げられます。しかもそれぞれがやり直しが難しい事から、失敗が許されない作業であり、念入りに準備が必要になってしまうのです。

ところがネットアップのストレージではこのストレージの拡張作業が非常に簡単に、また高速に実行できてしまいます。たとえばESX用の領域が不足してストレージ領域を追加しなければならない場合、新規にディスクを用意して追加する作業からESXに拡張された領域を認識させるまで、数分で終えることができるのです。
少し細かい話ですが、RAID5、10もしくはRAID6の構成を基本とする多くの他社ストレージと違い、ネットアップのストレージはRAID-DP(RAID4ベースのダブルディスクパリティ)を採用しているため、新規ディスクの追加が追加ディスクの本数に依存すること無く、またRAIDの再構築(リビルド)が実行されることも無いため瞬時に拡張します。
(※この仕組みについては次回紹介いたします)
また、RAIDを拡張するとRAIDグループに紐付いたアグリゲートと呼ばれるストレージプールが同時に拡張されるのです。
これにより、ストレージプール上に作成された空き領域を使ってDatastore用のストレージ領域を自由にいつでも拡張することが可能になります。

このストレージのボリュームの持ち方によるメリットとして、例えばESXがDatastoreとして接続するストレージ領域はネットアップのストレージ上ではFlexVolumeと呼ばれる仮想化されたボリュームとなっているため、ストレージプール上で容量の定義の変更をおこなうだけでサイズ変更でき、瞬時にボリュームの拡張ができるのです。
下記の図にて、1,2分でストレージの拡張作業が可能と紹介していますが、実際には慣れた管理者であれば、30秒ほどでストレージ、ESX上の構成変更作業を終えることができてしまいます。

NFSじゃないとだめなのか?

SANストレージとは違って、NFSでボリュームを構成している場合、そのボリュームのファイルシステムの部分はネットアップ側で管理しているため、ESXの状態に関係なくストレージ上のデータ操作が可能です。さすがに稼働中の仮想マシンが動作しているVMDKディスクファイルに対してのデータ変更はできませんが、Datastoreのサイズ変更、Datastore及び仮想マシンのSnapshotバックアップ・リストア、重複排除による空き領域作成、同一ブロックを使って仮想マシンのクローン作成などはすべてオンラインで実行可能であることなど、NFSにしか出来ないオペレーションが数多く存在します。

しかもこれらのオペレーションはすべてストレージ上で完結するため、いずれも高速に実行できること、同一ブロックや差分ブロックを効率的に使うことで容量のオーバヘッドなく実行できることも大きな利点です。
お客様には「なぜこのようなオペレーションができるのか?」と、よく聞かれるのですが、ネットアップではファイルシステム内のDatastoreや仮想マシンのデータをネットアップのストレージ上で管理しているため、サーバに負荷をかけることなくストレージの機能を使い倒すことでこれらのオペレーションを実現できるのです。

一般的なストレージを使って運用していたお客様からすると、こうした便利な機能は、今までのESXの運用と大きく異なるため、疑い深いコメントをたくさんいただいてしまったりもします。そのようなときには一般的なファイルサーバを例に、「同じ原理でストレージ上の変更は問題にならず、WindowsやNFSクライアントから次回ストレージにアクセスしたときに新しい状態を認識する動作と同じです」と紹介することで、「なるほど、確かに!」とよくご納得頂いています。

また、「他社のNASストレージでも同じことができるか?」と、お問い合わせを受けることもありますが、ネットアップのストレージがもつアーキテクチャのように「DataOntap」(ストレージ専用OS)が「RAIDの部分とファイルシステム」(WAFL: ネットアップの独自ファイルシステム)を管理することで初めて先のようなオペレーションが実現可能になります。もしNASストレージのバックエンドにSANのストレージが接続している場合にはSANストレージを無視してNASストレージ上でファイルシステム内のデータ変更をおこなうことは基本的にはできないため、ネットアップのようなデータオペレーションは事実上難しいことになってしまいます。

NFS接続ならボリュームを大きくするだけでなく・・

「ネットアップのストレージならDatastoreを縮小できます。」このことを紹介すると多くのお客様が、信じられないような顔をされます。ESXのDatastore領域をオンラインで縮小できるストレージは他に無いため、自然な反応ですが、ネットアップのストレージとNFSプロトコルの大きな魅力なのです。

先にFlexVolumeの仕様として、ボリュームが仮想化されているため、アグリゲート(ストレージプール)上の容量の定義を変えるだけで瞬時に変更できることを紹介しましたが、ボリュームサイズの変更はサイズの定義の変更だけなので拡張だけではなく縮小もサポートしているのです。

また下記の図のようなオペレーションも容量の余っているボリュームサイズの縮小と容量不足のボリュームの拡張を実行するだけということもあり、実質20~30秒ほどで終了します。以前はストレージ上でサイズ変更の操作をおこない、ESX側でリスキャンを実行する2つのオペレーションが必要でしたが(それでも短時間で実行できましたが)、現在においてはネットアップが提供するvCenter用のプラグイン(Virtual Storage Console)を使う事でvCenter上からvSphereの管理がより簡単なオペレーションで実行することができるのです。
※プラグイン Virtual Storage Consoleについては別の機会に紹介いたします

このDatastoreを縮小できる運用はESX環境におけるストレージ運用を大きく変更し、ストレージに掛けるコストを大幅に削減しただけではなく、仮想環境のインフラ管理者、ストレージ管理者の負荷、工数を大幅に削減することができることから多くのお客様がネットアップのストレージでESXを運用するきっかけとなり、ネットアップにおける仮想化案件が急激に増える要因となりました。

NFS接続で実現する未使用領域の有効利用とは?

前述したように、LUNをオンラインで拡張できる機能をサポートするストレージ製品は多くありますが、縮小をサポートするストレージはほとんどありません。
もしDatastore上の領域が余ってしまった場合には無駄な領域として残しておくか、Datastoreを縮小させるために仮想マシンを別のDatastoreに退避させてからLUNを削除し、新たに適切なサイズのLUNを再作成する運用が必要になってしまいます。また、もうひとつの注意点としては、SAN接続の環境でESX上の仮想マシンを削除した場合、VMFS(ESX上で管理するファイルシステム)上では削除されますが、ストレージ内のLUN上ではデータとして残ったままとなります。意外に気が付かないSANストレージの動作ですが、特にシンプロビジョニング運用をおこなっている場合には大きな問題となってしまうでしょう。逆にNFS接続の場合にはファイルシステムの管理をストレージ側で実行しているため、ESX上で削除されたデータをストレージ上でも解放された領域として扱うことができます。この動作もファイルサーバと同じ原理でデータを消すだけで簡単に空き領域を作成できるため、一般的なSANストレージよりも利用効率を大きく向上できるのです。一見当然の動作ですが、SANストレージで構築したvSphereの管理者を長年悩ませていた問題であったため、ネットアップのストレージでこうした悩みが解決できたと多くのお客様に喜んで頂いてます。

SANストレージにおけるシンプロビジョニングの注意点

先にESX上で削除されたデータがSANストレージ上に反映されない動作がシンプロビジョニング環境において深刻な問題になると紹介しましたが、SANストレージでのシンプロビジョニングはESX上で確認できる使用量とストレージ上で確認できる使用量が異なって表示されるため、監視運用がよりシビアになります。多くの場合でSANストレージ上よりESX上での空き領域が多く表示されるため、SANストレージ上の使用量を正確に把握していないと、ESX上では書き込めるはずのデータがSANストレージ上では容量不足のため書き込めない(ESXとSANストレージ上で矛盾した状態)問題が発生してしまうため注意が必要です。
そしてSANストレージ上に作成された複数のLUNが物理ディスク領域を共有しているため、SANストレージ上の領域が枯渇した場合には全てのLUNに書き込みができなくなるなど、さらに深刻な問題が発生してしまう場合があります。

NFS環境において、もし領域が不足した場合には、プロトコルレベルで対象のボリュームに空き領域が無いため書き込みができないことをエラーとして返すことができるため、ストレージ全体に影響を及ぼすことはありません。(SANのシンプロビジョニング運用の場合にはVMFS上では空き領域となっているので領域不足のエラーを返さない)またネットアップのストレージではボリュームのポリシーで容量が使いきってしまった場合には自動的にストレージプール上の空き領域を使って自動拡張させるオプションもありますので、容量不足にともなうリスクを低減させることも可能な仕様となっています。

SANストレージにおけるシンプロビジョニング運用の問題を解決するため、最新のvSphere5においてはESX上の削除データに該当するストレージ上のブロックを解放する機能が追加されました。この機能を利用するにはVAAI(vStorage API for Array Integration)機能に対応したストレージが必要になります。VAAIによってSANストレージが進化したと捉えることもできますが、従来からネットアップのストレージをご利用いただいているお客様からは、「VAAIによって他社のSANストレージがネットアップのストレージに一部の機能が追いついてきているので、ネットアップさんも頑張ってください!」など応援のコメントをいただいてしまったりもします。
先般vSphere5が登場しましたが、実際にはvSphere4環境でのインストールベースも当面継続されていくこともありますので、この条件の場合には今回紹介した空き領域の解放機能などはまだまだネットアップの大きなアドバンテージとなります。もし機会がございましたら、是非ネットアップのストレージも視野に入れていただき、弊社パートナー及び弊社にご相談ください。
※VAAIサポート状況につきましては各社ストレージベンダーにご確認ください

今回、RAIDグループの拡張が瞬時に実行できる部分に触れましたが、次回ネットアップ独自のRAID-DPについて紹介予定です。RAIDの部分を売りにするストレージベンダーが無いため、わざわざRAIDの仕組みに力をいれて紹介することを不思議に思われる方も多くいらっしゃるのではないでしょうか。性能・信頼性・容量面において他社にはできない大きなアドバンテージがあるRAIDの仕組みですので次回のエントリーも是非楽しみにお待ちください。今回も多数の含みを残した終わり方となってしまいましたが、少しずつなるべくわかりやすく順次説明をしていきますので、次回まで今しばらくお待ちくださいませ。

※前回、ブログ形式にて掲載予定とお伝えいたしましたが、掲載予定のブログが準備中のため第二回につきましてもTechOnTap記事として配信しております。


大西宏和(Hirokazu Onishi)
技術本部 エンタープライズSE第二部 シニアシステムズエンジニア
NetApp


立教大学社会学部観光学科卒、外資系ストレージメーカを経て2002年NetCache(セキュリティアプライアンス製品)担当SEとして入社。
入社以来、パートナー及び仮想化ソリューションを担当、本年度よりハイタッチ向けプリセールスSE。
趣味は旅行とサッカー観戦。


関連情報
関連情報
第一回:NetAppは昔からユニファイドです
関連情報
 
Go further, faster TRUSTe
お問い合わせ   |   購入方法   |   フィードバック   |   採用情報  |   登録   |   プライバシーポリシー   |   © 2011 NetApp