VDI(デスクトップ仮想化)は、セキュリティ面や運用コスト/工数、また業務効率などに関してメリットがあります。しかしながら導入前の事前準備などをしっかりと行わないと、導入後に想定外の事態に見舞われる場合があります。
VDI導入には、サーバーの構築や専用ソフトウエアの準備が必要ですのでそれ相当の初期コストが発生しています。従って想定外の事態が発生したからと言って簡単に取りやめることもできません。
今回はそのような失敗を起こさないように、実際にどのような事態がどのような原因で発生しているのかを見ていきましょう。
失敗(1)レスポンスの低下
VDI導入後に、最も多く発生する失敗事例が「レスポンスの低下」です。事象としては「朝の始業時や特定の時間帯」が特に遅かったり、時間不定で発生したりとさまざまなパターンがあります。さらに「特定の端末のみ」で発生するケースもあります。ケース別に見てみましょう。
「朝の始業時のログインの際や特定の時間帯」にレスポンスが低下する
朝一番の始業時のログインが異常に時間が掛かるというケースです。多くの場合は、サーバーやストレージのサイジングが適切ではなかったために発生します。サイジングとは、これから稼働させる予定のシステム/サービスに適した規模のサーバーなどのリソースを見積もって準備することです。サイジングは、個別の利用状況などをすべて調査してから実施するのがベストではありますが、現実的にはさまざまな制約があるために、ある一定の範囲/領域などを対象に調査を実施し、その結果に基づいて全体像を明らかにする方法も効果的です。
具体的には、ユーザーのリソース消費量(CPUやメモリ、HDDなどの使用量)、IOPS(In/Out per Second、記憶ディスクへのアクセス頻度)の実態を調査した上で、その実測値から必要十分なリソース量を算出した上で、具体的なサーバーのサイジングを行います。しかしこういった調査を行わずに一般論や推測を頼りに行ってしまった場合や、導入費用を無理に切り詰めた場合には適切なサイジングができず、特にアクセスが集中する時間帯を中心にレスポンス低下を招いてしまいます。もちろんリソースが極端に不足している場合は、特にアクセスが集中していない時間帯でもレスポンスが低下します。
「特定端末」のレスポンスが低下する
特定の端末にレスポンス低下が発生している場合は、その端末で使用している特定のアプリケーションやデータ処理が原因になっているケースがあります。該当のアプリケーションの動作チェックなどをVDI導入前に十分に行っていないケースが考えられますので、個別に原因究明を行う必要があります。
また、特にレスポンス低下が発生していなくても、その端末のユーザーが元々非常にハイスペックなPC端末を使用していた場合などは、VDI移行によってレスポンスの低下を感じるケースもあります。そういった場合は、異常が発生していないかどうか確認した上でユーザーに状況を説明する必要があります。
また、VDIは物理PCに比べCPU処理やディスク性能(IOPS)が非常に低い環境になってしまいます。ユーザーが物理PCを使っていた時に当たり前のようにしていたことがレスポンス低下に繋がってしまいます。例えばアプリケーションを何個も起動したままにしていたり、ブラウザのタブを10個以上作っていたりする場合です。対処法としては、そういった使い方に耐えられるレベルまでリソースを追加するか、正しい使い方をユーザーに説明する必要があります。
失敗(2)移行後に必要なアプリケーションが使えなくなった
個別の事前調査をしっかりと行っていなかったことが原因で、当該のアプリケーションが移行対象から外れてしまっていることで発生します。使用アプリケーションまたはデスクトップ環境上のアプリケーションの見直しが必要となります。
失敗(3)特定のアプリケーションが正常に動作しない
アプリケーションが移行対象になっていても、正常に動作しないケースがあります。事前調査が適切でなかったか、想定外の原因で不具合が発生している可能性があります。個別の原因調査を行った上で対策を講じる必要があります。
失敗(4)ファイルサーバーなどの周辺システムやプリンターなどの周辺機器へのアクセスが遅くなった
導入前の実態調査において、VDIの基盤となるサーバーのみを対象とし、周辺のシステムや機器にまで及んでいなかったことが原因で発生します。周辺システムの運用管理者などを交えて対策を講じたり、個別の機器ごとに原因調査や対処をする必要があります
失敗(5)周辺機器が使えなくなった
これも前項と同様に事前調査での漏れや想定外の事象によって発生するケースが多い不具合です。個別の原因調査が必要ですが、周辺機器のドライバーを更新したり、使用する機器を見直すなど比較的単純な対処方法で改善されるケースがあります。
失敗(6)仮想化ソフトなどのバージョンが混在して運用工数やリスクが増加する
企業規模が大きくなるとVDI(デスクトップ仮想化)環境を支店ごとや地域ごとなどに分けて段階的に導入していくケースが多くなります。企業規模やその他の条件によっては復数年にわたって全国での導入を進める場合もあります。このような場合は、サーバーのOSや仮想化ソフトウエアなどのバージョンが拠点間などで異なってしまう場合があります。異なるバージョンのOSやソフトウエアを同時に運用するとなるとトラブル発生のリスクが増え、なおかつトラブル対策を含むさまざまな運用の手間も増加することになります。
マイクロソフトのVDIをご検討中の方へ
ここまで見てきたように、導入後に発生する想定外の事態は、導入前にしっかりとした実態調査が行われていないことが原因となって発生するケースが多くなっています。導入後のトラブルを防止するためには、事前の実態調査やPoCが重要な役割を果たすことを認識しておく必要があるでしょう。
例えば、
- GPUを必要とするアプリも遅延なくサクサク動くのか?
- 社内ネットワークやオンプレミス接続におけるベストな構成が分からない。
- 障害やメンテナンスなどの頻度が高かったらどうしよう。
これらの不安を解消するためには、検証でスモールスタート、その後社内へ展開することが一般的です。
しかし、検証用の費用を社内で調整するのも一苦労ですよね。
そこで、MicrosoftのAzure Virtual Desktopを検証したいとお考えの方へ向けて、少しでもお客様のご負担を減らしてお試しいただけますよう、現在、日本マイクロソフトより検証用として支援金のご用意がございます。
マイクロソフト支援金額:1社につき最大100万円
適用:先着順(※枠に限りがあり、現在10社限定とさせていただいております)
1社につき最大100万円とは、AVD検証時に必要となる初期構築費用を補うための支援金です。
ご要件にもよりますが、一般的な構成にて検証を実施いただく場合には、マイクロソフトからの支援金で全て補うこともできるので、構築費用は実質「無償」で検証いただけます。
今だけのキャンペーンですので、ご興味をお持ちいただいた際にはお早めにお問い合わせくださいませ。
いまだけの期間限定パッケージですので、ご興味をお持ちいただけましたらお早めにお問い合わせください!