仮想デスクトップ導入の理想と現実、
そしてそのベストプラクティス

第二回:陥りがちな失敗パターン
「設計・構築の現実」

②デスクトップ仮想化「設計/構築」の現実

ケース4 「浅い設計」

状況

現状を把握し、その上でサイジングと概要構成が決まれば、後は各インストールコンポーネントを構築して完了、というふうに何も考えずに進められるほどデスクトップ仮想化は簡単ではありません。仮想デスクトップ特有の技術要素を考慮した設計を実施しないと、その後のフェーズ(構築・テスト)で問題が発覚します。問題が発生すると、解決に工数をとられることによるスケジュール遅延、追加予算の計上が必要になります。クリティカルな問題の場合はデスクトップ仮想化自体断念せざるを得ない状況も考えられます。設計では、どのような点に考慮する必要があるのか、以下に例をあげて説明します。

  • ネットワーク要件の変化
    デスクトップ仮想化に伴い、業務アプリケーションや社内の共有データなどビジネスに必要な情報へのアクセスの主体は各拠点のローカルPCからデータセンター内の仮想PCに変わります。アクセス元が変われば、ネットワークのトラフィックの流れも変わるため、既存システムのアクセス制御に変更が必要となる可能性があります。
    仮想化するデスクトップの台数が多いほど、データセンター内に大規模なIP空間が必要となります。既存のネットワーク機器では収容しきれない場合も考えられます。

  • ログオン / ログオフの要件の変化
    シンクライアント端末の電源オフは仮想PCのログオフとはなりません。(セッションが切断状態となりますが、仮想PCは使用中(ログオン中)の状態です。例えば、既存環境でローカルPCへのログオン/ログオフで就業管理を行っていた場合、注意が必要です。運用ルールを見直すか、就業管理のために別の仕組みを検討する必要があります。

  • 外部記憶媒体の取り扱い
    仮想デスクトップ環境では当然ながら各デスクトップはデータセンター内で稼働します。一方、USBメモリーやCD-Rドライブなどの記憶媒体は手元に持って使用する必要があります。手元の記憶媒体と仮想デスクトップの間を流れるデータは、ローカルPCの時のようにPCの内部バスを通る訳ではなく、ネットワーク上を流れます。外部記憶媒体のユーザーの使用率(どれくらいの量のデータがどのくらいの頻度でネットワーク上に流れるか)を予測し、狭帯域拠点のネットワーク増速、Citrixポリシーによる帯域幅の制御など、必要な対策を施す必要があります。
    別の観点で、仮想デスクトップ環境は様々なロケーションからのセキュアなアクセスを実現するソリューションです。端末(シンクライアントなど)とネットワークがあれば必要な情報にどこからでもアクセスできるようになります。そのような背景の中、外部記憶媒体へ情報を記録することが本当に必要か、改めて検討する必要があるでしょう。仮想デスクトップ化に伴い、デスクトップ及びユーザーのデータがデータセンターに集約され、セキュリティレベルは必然的に向上しますが、外部記憶媒体の使用によりそれが蔑ろになる恐れがあるためです。

  • 媒体以外の周辺機器の取り扱い
    記録媒体以外の機器(Webカメラ / USBスキャナーなど)も、デバイスは手元、制御はデータセンター内の仮想デスクトップであるため、記憶媒体と同様に特別なケアが必要です。デバイス毎にテストをし、デバイスを正常に認識するか、実際の使用感に問題ないか、帯域幅は許容範囲内かといった確認が必要です。最悪のケースは、導入に踏み込んでから初めてそれら周辺機器の使用がわかった場合で、且つ重要な業務でそのデバイスを使用しているにもかかわらず仮想デスクトップでは正常に動作しないといった状況です。プロジェクト全体のスケジュールを変更せざるを得ない事態に陥るでしょう。

  • 印刷要件の変化
    印刷に関しても周辺機器と同様に、プリンタードライバー/プリンターユーティリティがインストールされて、プリンターを制御するのはデータセンターの仮想デスクトップで、実際に紙に出力されるのはユーザー拠点側になります。これまでは、ネットワークプリンターやプリントサーバーを使用していた場合でも印刷時のトラフィックは拠点内のローカルネットワークに限定されていました。しかし、仮想デスクトップ環境では、多くの場合、印刷データはWANを越えて各拠点のプリンターに送られて来ます。これも、外部記憶媒体の要件と同様、印刷トラフィックの総量、印刷頻度の予測と、それに応じた対応(狭帯域拠点のWAN回線の増速、ネットワーク機器の増強)が必要です。

  • Active Directoryドメイン
    XenDesktop 7はActive Directoryと連携して動作します。しかしどのような構成のActive Directory構成でも仮想デスクトップ環境が無事に稼働するわけではありません。XenDesktop 7にとって望ましいActive Directory構成、そうではない構成とそれぞれ存在します。現行環境のActive Directoryの構成を把握し、XenDesktop 7を導入するために必要な変更を事前に見極める事が重要です。

  • ユーザープロファイル
    ローカルPCで運用しているケースの多くは、ユーザープロファイルの保存場所にローカルハードディスクを指定しているローカルプロファイルでの運用をされています。効率的な仮想デスクトップ環境を実現するためには、この方法を変更する必要があります。プール型の仮想デスクトップの場合、ログオンする度に前回とは違うデスクトップを使用する可能性があります。このように毎回異なるデスクトップでも同じユーザープロファイルを使用するためには、移動ユーザープロファイルに移行する必要があります。この場合、プロファイルを保存するストレージ領域が必要であったり、既存のプロファイルからのデータ移行が必要だったり、大がかりな準備が必要となります。

  • マルチメディア機能 (動画再生など)
    XenDesktop 7では、端末でのデスクトップ画面表示において、仮想PCから端末に画面の差分情報を特殊な圧縮技術で送ることにより快適な動作環境を実現します。ですが、動画は差分情報の連続なので必然的に更新情報が増え、結果としてネットワークに負荷をかけることになります。

  • セキュリティソリューション
    現在Windows OSでデスクトップを運用している環境では、多くの場合ウィルス対策製品を導入されています。これも、デスクトップ仮想化に向けて、これまでとは違った観点で注意が必要です。従来のローカルPCによるデスクトップ環境では、ウィルススキャン時の負荷はPC上に限定されます。個々人で使用されているPCの動作は多少重くなったとしても、PC間で互いに干渉し合うことはありません。仮想デスクトップ環境では、一般に仮想OSは共有ストレージに収容されております。ウィルススキャンが走ると、その共有ストレージへの負荷が集中します。何千台、何万台もの仮想デスクトップ上でスケジュールスキャンが同時に実行され、ストレージIOが逼迫し、全体的なスローダウンにつながる、こういったケースは何としてでも防ぐべきでしょう。
    プール型の仮想デスクトップを採用する場合は、パターンファイルの更新に注意が必要です。プール型仮想デスクトップでは、単一のOSイメージから各仮想デスクトップをブートするため、パターンファイル更新時は、配信元のOSイメージを更新すれば全ての仮想デスクトップに更新が伝播される。確かにそれは正しいですが、それでは毎日のように配信されるパターンファイルを毎回マスターのOSイメージに取り込んで、毎日仮想PCを再起動させて全台の仮想PCに反映させる、このような運用は現実的でしょうか。場合によっては、仮想デスクトップ側のキャッシュ上でパターンファイルの更新を行うことも検討が必要です。

  • その他特殊要件
    他にも現状ローカルPCで運用していた仕組みで再検討が必要なものは数多くあります。
    例えばPCに対し端末の認証(社内のネットワークに接続を許可するかの判定)を実施していた場合、シンクライアント専用機で同じ仕組みが使用可能か、使用出来ない場合の代替手段はあるか。そもそも単体では高度な機能を持たないシンクライアント専用機に対し端末認証を施す必要があるか、など検討が必要です。

結果

問題点が構築の段階で発覚した場合、その場での解決が難しい場合も多く、スケジュール遅延を余儀なくされます。設計を実施している段階でこれらを予測し、方式を決め、必要なリソース、タスクを定義する必要があります。

Next: 第三回:陥りがちな失敗パターン「展開の現実」

シトリックス コンサルティング サービスに関するお問い合わせ

シトリックスコンサルティングサービスは担当営業または販売代理店までお問い合わせください

 

ページトップへ