SSDを利用してVDIのブートストームを回避（前）

仮想デスクトップ一斉起動時の速度低下を解消するSSD

仮想デスクトップインフラ（VDI）環境において、多数のユーザーが同時にログインするときに発生する「ブートストーム」。この問題を回避する最も合理的な方法を紹介しよう。

公開 2011年07月14日 09時03分

更新 2012年09月04日 15時06分

著者

Eric Siebert

[TechTarget]

印刷する

　デスクトップ仮想化、あるいは仮想デスクトップインフラ（VDI）は、システム管理の簡素化、セキュリティの一元化、データ保護などIT部門に数々の恩恵をもたらす（関連記事：企業にうってつけのデスクトップ環境を実現するVDI）。しかしVDIをサポートするためのストレージ環境においては、VDIの「ブートストーム」という問題を回避するために注意深い準備が必要とされる。

関連コンテンツ

　VDIブートストームは比較的単純な問題だ。仮想デスクトップのワークロードは、デスクトップユーザーの勤務時間（一般的には平日の午前8時ごろから午後5時ごろまで）に基づいて予測できる。標準的な仮想デスクトップによって発生する全体のストレージI/Oは、サーバのワークロードによるストレージI/Oと比べると非常に低い。そのため、ホスト上の仮想デスクトップマシンの密度は、仮想化されたサーバの密度よりもはるかに高いのが普通だ。逆に、デスクトップの起動時には大量のリソースが必要とされる。これはOSとアプリケーションのロードと実行中にディスクから大量の読み出しを行うからだ。

　ブートストームは、多数の仮想デスクトップが短時間（例えば午前8時から9時の間）に集中して起動するときに発生する。その結果、大量のストレージI/Oが集中的に発生し、ストレージサブシステムの処理が追い付かなくなる。ストレージサブシステムが大きなI/O負荷を処理するように設計されていなければ、ストレージサブシステムがDoS（サービス妨害）攻撃を受けたような状況が発生するのだ。

　そうなった場合、デスクトップユーザーの仮想デスクトップの速度が大幅に低下し、ほとんど使い物にならなくなってしまう。こういった状況が日常的に発生するとユーザーの不満が増え、VDIプロジェクトは失敗と見なされるだろう。そしてユーザーたちは、物理的なデスクトップに戻すように叫び始める。そういった事態は何としても避けなければならない。多くのメリットを持った優れた技術ソリューションでも、設計上の判断がまずいと悪いものに見えてしまうのだ。

　VDI向けに設計されていないストレージサブシステムを導入した場合でも、後から修正することは可能だが、最初から正しい判断を行った場合よりもはるかに高いコストが掛かる恐れがある。例えば、アップグレードしてもニーズに対応できないために、システムをすっかり入れ替える必要がある場合などだ。

　ユーザーが仮想デスクトップを起動してログインし、アプリケーションをロードしてしまえば、ストレージI/Oは通常、最低レベルに落ち着く。デスクトップVM（仮想マシン）の起動中と起動後のIOPS（1秒間当たりのI/O回数）には極端な差がある。このため、VDI環境向けのストレージを構築するのは容易ではないかもしれない。Windows 7が動作する標準的なデスクトップVMは、起動時に50～100IOPSを発生する。このVMが通常のワークロードを実行しているときは、平均IOPSが約5～10に低下する。このため、ブートストームによって生じるI/O要求を満たすには、最悪のシナリオに対応できるようにストレージ環境を構築する必要がある。

　ブートストームのI/O要求を処理できるようにストレージ環境を構築するのは、非常に高い費用が掛かる可能性がある。一般に、ストレージアレイのIOPSを高めるには、HDDの台数を増やし、より多くのHDDから分散して読み込みが行えるようにする必要がある。これは、実際に必要とするよりもはるかに多くのストレージ容量を保有することを意味する。例えて言うならば、ラッシュ時を除けば1車線か2車線で十分なのに、毎日1～2時間程度のラッシュアワーに対応するために8車線の高速道路を設計するようなものだ。その結果、高速道路の建設と維持に膨大な経費が掛かることになるのだ（関連記事：SSDがネットワークとCPU使用率に与える影響）。

VDIブートストーム問題をSSDで解決する

　ブートストームに対応するのに必要なIOPSを処理するためにストレージアレイ一式を新たに配備するのではなく、外科的なアプローチを利用した優れたソリューションがある。8車線の高速道路を建設するよりも、2本の相乗り専用レーン（すなわちSSD）を追加することによってピーク時のトラフィックに対処すればいいのだ。