[計画フェーズの落とし穴] 提案時の構成で機器を買ってしまってよい?(2)

前回から、仮想デスクトップの導入における落とし穴を取り上げている。仮想デスクトップの案件においては、ユーザーのユースケースにより、想定されるリソースとそれに合わせて集約率が変わるため、提案時の想定の構成を検討せずにそのまま購入するべきではない。

なお、集約率や構成の見直しは全体のコストに大きく影響するので機器発注前にもある程度検討を進めておきたい。

前回は仮想プロジェクトのフェーズのうち、「アセスメント」と「設計」のフェーズで、提案時の構成を見直すべきポイントを説明した。今回は「テスト」と「移行」フェーズにおける落とし穴について解説する。

[テストフェーズ]負荷テスト結果を受けての検討

モジュラー型の最小の構成をパイロットのために用意したあとで、負荷テストを計画する。これにより、想定する負荷をかけた際のサイジングの妥当性を確認することができる。このフェーズでは必ずしも構成を見直す必要はなく、試験での想定負荷やボトルネックを確認し、パイロット時の確認の観点とする。

負荷テストでは、大まかには以下の2つの観点で確認を行う。

1. シングルサーバスケーラビリティ
2. ログオンストーム

1.シングルサーバスケーラビリティ

シングルサーバスケーラビリティは、1台のハイパーバイザーにどれだけ集約を行うかの確認である。この場合、LoginVSIなどのロードテストツールを用いて実際にワークロードを流して集約率を上げた場合のレスポンスタイムを計測することで、限界となる集約率を計測する。以下にシングルサーバースケーラビリティ試験の負荷のイメージを示す。

ワークロードには可能な範囲で業務で利用するアプリを選定することが望ましいが、ロードテストツールで完全な動作を再現することは難しい。そのため、最低限、ツール組み込みのワークロードに加えて、業務アプリの起動・停止などを含むワークロードを作成する。

この時点でツール組み込みのワークロードで集約率を計測しておくことで、今後の拡張時にCPUなどが変更になった場合の参考とすることができる。特にLoginVSIは業界標準のツールであるため、公開されているベンチマークが多い。また、パイロット以降のフェーズで組み込みのワークロードに対する、実際の負荷状況を確認することで補正値として使用することができる。

この試験では、実際の集約率よりも多いVM数の試験を行う事で余裕度を確認できる。CPUの限界性能を確認する上ではVM数を設計の集約率よりも増やす必要があるが、メモリに余裕がない場合は、メモリオーバーコミットの構成となってしまう。メモリのオーバーコミットを設計として想定していない場合は、swapが余分に発生するなど、ネックのかかり方が変わってしまうので、あらかじめ一時的にメモリ増設などをして確認を行う事を検討する。

2.ログオンストーム

ログオンストームは、想定するログオンピーク時のレートでログオンを行うことで、管理系コンポーネントのサイジングを確かめる試験だ。この試験では、ログオンスクリプトの処理や、移動ユーザープロファイルの読み込み時の ファイルサーバーの負荷などについても確認する。下図にログオンストーム試験の負荷のイメージを示す。

仮想デスクトップに関わる管理コンポーネントはログオン時に負荷ピークが来るものがほとんどであるため、朝の出勤時などログオンが集中する時間帯のログオンレートを確認して試験を行う。

例えば、朝の9時00分のログオンレートがピークで、1分間に100ユーザーがログオンすることがわかっていれば、1分間に100ユーザー以上のログオン負荷をかければよい。

ログオンレートは通常対象となるユーザー数が多くなるほど増加するが、業種により大きく異なるので注意する。例えば、内勤の社員が多い業種では朝の出勤時にログオン時間が集中することが多いので、必要なログオンレートが、営業などの外勤の社員が多い業種に比べると高くなる傾向にある。

[移行フェーズ]パイロットの結果を受けての検討

パイロットフェーズでの稼働状況を確認して、本番稼働前に集約率や構成の調整を行う。

ここまでのフェーズで十分な事前検討を行っているので、大きなぶれは想定されないが、ユーザーが想定と異なる使い方を行い、負荷が高めに出ることや、逆に低めに出ることが想定されるので、負荷テスト結果から想定されるボトルネックを中心に確認を行う。

注意点は、パイロット参加者の同時使用率が本番と同様かどうかだ。本番業務で使用する端末との並行稼働を行うと、実際には仮想デスクトップ側の使用率が低くなる可能性がある。その状態でのハイパーバイザー側の負荷を確認しても、下図のように実際よりも使用率が低いために負荷が軽い状態となってしまう。

そのため、パイロット中の同時利用率がおおむね分かった段階で、下図のようにハイパーバイザーのホストを何台か停止しておき、同時利用数が用意している仮想デスクトップの数と同等程度になるように調整して負荷量を確認するなどの対処が考えられる。

　　　　　　　　　　　　　　＊　　　　　＊　　　　　＊

以上、前回と今回の2回にわたり、仮想デスクトップの導入における、サイジングに関する落とし穴を取り上げた。具体的には、「想定する構成を見直すタイミングを設けることの重要性」「各フェーズにおいてタイミングで確認する観点」について述べてきた。予算やスケジュールの都合ですべてのフェーズで見直しがかけられない場合も想定されるが、その場合、特に購入前のフェーズでの検討を進めることで、後続のフェーズでのぶれを減らすことができる。

峰田 健一（みねた けんいち）

シトリックス・システムズ・ジャパン（株）
コンサルティングサービス部 プリンシパルコンサルタント

サーバー仮想化分野のエンジニアを経て、シトリックス・システムズ・ジャパンに入社。
主に大規模顧客のデスクトップ・アプリケーション仮想化のコンサルティングに従事している。