NetApp Tech OnTap NetApp Logo
NetApp Tech OnTap
     
1から学ぶVMware on NetApp
第八回:古いゲストOSを使用する場合の落とし穴―
「アライメントの重要性」についてご存じですか?
シェアする NetAppオフィシャルFacebook

はじめに

前回、Virtual Storage Console(VSC)4.0概要について紹介したこともあり、多くの方が最新バージョンのVSCをダウンロードして新しい機能を試されたようです。現状VSC 4.0はベータ版ではありますが、バックアップ、リカバリ、クローニングなど大半の機能に関しては、過去からお使いいただいている機能のメンテナンスリリースとなるため、従来通りの操作でほとんどのオペレーションが可能です。VSC4.0の正式版リリースも近づいてきておりますので、今しばらくお待ちください。

今回ですが、VSC4.0の新機能となる、Optimization and Migration機能と仮想化環境を構築するにあたって重要なポイントの一つとなる「アライメント」について紹介します。

古いOSをそのまま仮想化してしまうと・・・

古いサーバーを統合するために、仮想化を導入するケースは多いのではないでしょうか。
古いハードウェア上のリソースを移行したり、古いバージョンのOSをvSphere上にインストールすることは簡単に実行できるようになっていますが、簡単に仮想化をおこなうことができる故に、落とし穴もあったりします。

実際にvSphere環境を運用しているお客様とお話している中で、Windows2003、WindowsXPなどのOSは仮想化の対象としてvSphere環境上に数多く配置していることを伺ったりするのですが、古いバージョンのWindows OSを仮想化する際のチューニングポイントがあることをお客様に紹介すると、驚きや感謝のコメントをいただいたりすることが少なくありません。

このチューニングポイントですが、OSがインストールされているパーティションの開始位置を変更するだけで、パフォーマンスが劇的に改善されるのです。

Windows2003、WindowsXPなどのOSは通常の方法でインストールした場合、VMDKの先頭から32256バイト(LBA63)の位置にCドライブ用のパーティションを作成してOSがインストールされますが、この32256バイトのスペースがストレージにとっては非常に中途半端なサイズのため、パフォーマンス問題を引き起こす原因となってしまっているのです。

ネットアップのファイルシステム(WAFL)ブロックサイズは4KBですが、先の32256バイトのスペースをこのブロックサイズに割り当てると、7.875ブロック分のサイズとなり、以降のOS用パーティションが中途半端な位置から開始されてしまうため、OSが管理するブロックとネットアップが管理するブロックがズレてしまう現象が発生しているのです。

ネットアップはFASがvmware ESXに対応した当初から、この問題に対して無償ツール「MBRtools」により、対処方法を提供してきました。ESX上からMBRtoolsを実行することで、パーティションオフセットが最適化されているVMDK(Aligned VMDK)、最適化されていないVMDK(Misaligned VMDK)を確認し、パーティションオフセットが最適化されていないVMDKに対しては、オフセット値を変更することができるようになっています。

この「MBRtools」による、オフセット値変換作業は、VMDK内のデータを書き換える必要があるため、仮想マシンを停止(Power OFF)しなければならないことは仕方のないことですが、VSC4.0において新たに追加されたOptimization and Migration機能を使うことにより、オンラインでVMDKとネットアップ上のブロックのズレを解消する手段を提供できるようになりました。(Optimization and Migration機能については後半部分にて紹介いたします)

ブロックのズレが引き起こす性能影響

今回紹介したブロックのズレですが、実際にストレージに対して、どれくらいの余計な負荷をかけてしまうのでしょうか?私自身もこの問題を知った当初は、VMDKの1ブロックが、ストレージ上の2ブロックに該当するため、純粋に2倍の負荷と想定していました。確かに、Read処理については、1ブロック処理するためにストレージから2ブロック読み込むため、2倍の負荷となり、実測値としても約2倍の負荷がかかっていることを確認できるのですが、実はWrite処理についてはそれ以上の負荷を発生させてしまう動作となっているのです。

図においてブロックのズレが引き起こす内部動作を紹介しています。
Write I/Oについては2倍以上の余計なI/Oが内部動作として発生してしまっています。書き込み時においては該当ブロックをネットアップのファイルシステム上にそのまま書きこむことができないため、まず、ファイルシステムから該当する2ブロックを読み出し、ストレージコントローラ上で書き込み予定のデータとマージする処理を実行します。その後、それぞれのマージされたブロックを更新ブロックとして処理するため、最終的に約4倍もの負荷となってしまうのです。

Guest OS 初期オフセットサイズ

この、パーティション開始オフセットサイズの確認方法について、以下一例として上げております。
(1) ESX上からネットアップが提供するMBRtoolsを使って確認 (scanコマンド)
(2) vCenter上からネットアップが提供するVSCを使って確認 (Optimization and Migration機能からScan)
(3) 仮想マシン上のWindows OSから msinfo32.exeを実行 (Cドライブのパーティション開始オフセットサイズを確認)

今回、図中の表において、一部ではありますが各種Guest OSが初期値で定義する、パーティション開始オフセットサイズを紹介しています。

Windows XP、2003、Red Hat EL5、Solaris10など、比較的古いバージョンのOSについては32256バイト(LBA63)を採用しているため、これらのOSを仮想化する場合には注意が必要です。

逆にWindows7、2008、Red Hat EL6においてはオフセットサイズにネットアップ側で採用している4096バイトのブロックサイズで割り切れる値が採用されておりますので、チューニングをすることなく、最適化されたパフォーマンスの効果を得ることができます。また、先頭のパーティションオフセットサイズが1048576バイトとなっておりますので、OSベンダー側もこの問題を把握し、各社ストレージ製品毎に異なるブロックサイズを意識して、対応できるような仕様に変更したことが想定されます。

オフセットサイズを最適化して、性能検証を実施

今回紹介した、VMDKとネットアップ上のブロックのズレがどれぐらい性能に対して影響を与えてしまうか、実際の計測値を図中の表にて紹介しております。

検証項目としては、以下の条件、計測値をもとに比較しました。

【検証環境】
Windows 2003 仮想マシン×2台
- パーティション開始オフセット 非最適化(初期値32256バイト)
 - パーティション開始オフセット 最適化後(32768バイト)

負荷ツール
 - Simulated I/O
  ※http://support.netapp.com より入手可能(無償)
 - Read 100% 4KB Random I/O
 - Write 100% 4KB Random I/O

計測項目
 (1) NetApp FAS Disk Read (Simulated I/O Read時)
 (2) NetApp FAS Disk Write (Simulated I/O Write時)
 (3) NetApp FAS Disk Utilization(Disk busy率)
 (4) Windows 2003ホスト IOPS
 (5) Windows 2003ホスト Latency(レスポンスタイム)

※(1)(2)(3)FAS上の該当時間帯におけるSysstatコマンド出力結果平均、(4)(5)ホスト上で実行したSimulated I/O結果出力表示。

図中の検証結果より、パーティション開始オフセットサイズを最適化することにより、Read、Write共に大幅に改善されることが確認できます

今回、Read I/Oについては検証環境のハードウェアスペックの関係から負荷をかけきれず、ネットアップFAS側に余裕があったため、ホスト上からの計測結果としてはほぼ同一の結果となってしまいましたが、ブロックのズレが引き起こしていたFAS上の無駄なI/Oを改善できたことは、検証結果より確認できました。
また、Write I/Oについては驚くような結果となっております。FAS上のDisk Writeが約6倍向上し、Windowsホスト上のIOPS値が約16倍、レスポンスタイムについては90%以上改善される結果となりました。

このパーティション開始オフセットサイズのチューニングですが、実際に多くのお客様が実施し、その効果を体験いただいております。本来であれば、性能不足に対して、一般的にはハードウェアを増強して対応するところを、ネットアップであればツールを使い仮想マシンのチューニングだけで対応できたため、多くのお客様に喜んでいただくことができました。そして現在においては弊社のプロフェッショナルサービス部門においてもパーティション開始オフセットサイズのチューニングサービスを提供できるようになりました。大量の仮想マシンを短時間でオフセットサイズを変える必要がある場合などにはご相談いただければ幸いです。

VSC新機能 Optimization and Migration

ここまでで紹介した、パーティション開始オフセットサイズのチューニングですが、唯一の欠点として、仮想マシンを停止して実行しなければならないことがあります。商用サービスとして提供しているお客様にとっては仮想マシンの停止を伴うオペレーションはやはりハードルが高い作業となってしまいます。こちらを解決するために、VSC4.0からオンラインで、VMDKとネットアップのファイルシステムのズレを解消する機能がOptimization and Migrationとして提供されました。

このOptimization and Migrationは、vCenter上で稼働する仮想マシンのパーティション開始オフセットサイズをスキャンし、状態別(オフセットサイズ毎)に分類します

(1) Aligned - Actually aligned : オフセットサイズが最適化されている仮想マシン
(2) Misaligned - Online Migration : オフセットサイズが最適化されていない仮想マシン、Online Migrationでブロックのズレを解消できるオフセットサイズ
(3) Misaligned - Offline Migration : オフセットサイズが最適化されていない仮想マシン、Online Migrationでブロックのズレを解消できないオフセットの状態(複数のVMDKが異なるオフセットサイズになっているなど)
(4) Aligned - Functionally aligned : Misalign状態の仮想マシン専用のDatastoreに配置されている仮想マシン

残念ながら、Offline Migrationに分類された仮想マシンについては、オフセットサイズを最適化するために、仮想マシンの停止が必要となってしまいますが、Online Migrationに分類された仮想マシンについては、vmwareのStorage vMotion機能と連携して、パフォーマンスが最適化されたDatastoreにオンラインで移動することで、仮想マシンを停止することなく、ストレージ上の負荷を改善することができるようになりました。

VSC: Online Alignment

上記において、ミスアライメント状態の仮想マシン専用Datastoreを使うことにより、ブロックのズレを解消できること紹介しましたが、Storage vMotionだけでは仮想マシンはそのままの状態なのにも関わらず、何故ブロックのズレが解消されるのか不思議に思われた方もいるのではないでしょうか。

タネ明かしではありませんが、仕掛けとしては、まず、ネットアップ上にLUNを作成し、専用のDatastoreを事前に準備します。そして、そのLUN上にVMFSを作成する際にPrefixを調整して、意図的にネットアップFASのファイルシステムのブロックに対してズレを発生させたDatastoreをVSCが作成しています。カンが鋭い方はお気づきになられたかもしれませんが、このVMFSのズレがVMDK上のズレを吸収して、結果として最適化されたI/Oに変換されているのです。

ただ、こちらの対処法も、注意が必要です。VMDKの中身は変更されていないため、もし、この仮想マシンを他のDatastoreに移動した場合には、再びI/Oのオーバーヘッドが発生してしまうため、あくまでも一時的な対処方法として利用することをおすすめいたします。そしてお客様のメンテンナンスのタイミングでVMDK上のパーティション開始オフセットサイズを最適化することが、現時点でのベストプラクティスになることが想定されます。

Alignment 関連資料

今回紹介した、パーティション開始オフセットサイズが引き起こす問題についてvmware社からはKBとして、ネットアップからはテクニカルレポートとして皆様に技術情報としてお伝えしております。
ネットアップとしてはvmware以外のハイパーバイザー利用時にも発生する問題であるため、MBRtoolsを使えない、他のハイパーバイザーにも対応できるような、解決策なども紹介しています。
また、ネットアップFASに依存する問題ではなく、一般的なストレージの問題となりますので、vSphere環境を運用中であれば、是非とも仮想マシンの状態をご確認いただくことをお勧めいたします。
※ネットアップとしては、FASのブロックサイズが4キロバイトのため、オフセットサイズ32256バイトを採用しておりますが、各社ストレージ製品毎にブロックサイズが異なるため、この値が必ずしも最適化できる値にはならないことご了承ください。

今回のコンテンツはいかがでしたか。今までこのようなブロックのズレによるパフォーマンス問題について、一般的にはストレージの性能不足などと片付けられることが多いのではないでしょうか。
しかし、ネットアップFASを使っている場合には、部分書き込み(パーシャルライト)を発生させているファイル(VMDK)を特定したり、パーシャルライトの量を表示するコマンドをFAS上に実装しているため、vSphere環境におけるパフォーマンス問題の原因を比較的容易に特定できる大きなメリットがあります、今後、vSphere環境用のストレージを導入する際にはこのようなポイントも考慮していただくことで、より安定した仮想化基盤の構築を実現できると考えております。

次回については、「VSC Provisioning and Cloning」機能について紹介予定です。
来月まで今しばらくお待ちくださいませ。


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


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


関連情報
関連情報
第一回:NetAppは昔からユニファイドです
第二回:そのストレージ縮小できますか?
第三回:ネットアップなら
"工場出荷時状態から"3分で構築できます
第四回:一味違うネットアップのSnapshot
第五回:ストレージのクローン機能を使ってみませんか
第六回:効果絶大!ネットアップの重複排除
第七回:最強のvCenterプラグイン:「Virtual Storage Console(VSC)4.0」
関連情報
 
Go further, faster TRUSTe
お問い合わせ   |   購入方法   |   フィードバック   |   採用情報  |   登録   |   プライバシーポリシー   |   © 2012 NetApp