Home > Blogs > VMware Japan End-User Computing Blog

VMware、IBMとのパートナーシップを拡張し、IBM Cloud上からVMware Horizon Airを提供

みなさま、こんにちは。VMware でエンドユーザーコンピューティングのプロダクト マーケティングを担当している本田です。

本日のブログでは、2016年6月14日(US時間)に発表されたVMware Horizon Air に関する発表についてご紹介します。発表内容は、日本語の抄訳プレスリリースをvmware.com/jp 上に掲載しておりますが、米国本社の EUC Blogの内容が分かり易いので、今回はその日本語版をみなさまにお届けします。それでは、日本語版ブログをお楽しみください。

By Courtney Burry

近年ますます多くの顧客が、ワークロードやサービスのクラウドへの移行に期待を寄せています。これはビジネスや財務面で理にかなっているだけでなく、全社にサービスを提供する際のスピード感や提供するサービスの範囲を向上できるためです。このため今年は、DaaS(Desktop as a Service)と呼ばれる「サービスとしてのデスクトップおよびアプリケーション」が大きく勢いを増すのは間違いないでしょう。実際のところ、調査会社のIDCは、DaaSの市場規模が2014年の3.76億米ドルから2019年には14億米ドルを超える規模に成長すると予想しています。[1]また、 VMwareでも同様の需要を見込んでいます。

2年程前、VMwareではVMware vCloud Air上でVMware Horizon Airサービスを開始することで、アプリケーション、デスクトップおよびディザスタリカバリ(DR)をクラウド上のホスティング サービスとして利用できるようサポートしてきました。また、すべての地域においてこのサービスの需要拡大を見込んでいます。

今回の発表により、Horizon Airの顧客はまもなくvCloud Airに加えてIBM Cloudを利用し、すべてのWindowsデスクトップ(Windows 10デスクトップを含む)や公開アプリケーションを、幅広いデバイスに配布できるようになります。

vm_ibm

「サビスとしてのデスクトップおよびアプリケーション」を利用しようとする顧客にとって、これは朗報であると考えています。以下に、何点かその理由を挙げます。

  1.  より多くのロケーションからVMware Horizon Airの利用が可能に

このパートナシップにより、今後VMware Horizon Airの顧客は、全世界46ヶ所に広がるIBM Cloudのデータ センターにアクセスできるようになる予定です。これにより、単一またはマルチサイトでの展開時に、Horizon Airの顧客が利用できるロケーションの範囲と領域が拡張されます。

  1. IBM Cloud接続へのアクセス

IBMクラウド データ センター間の10 GBのバックボーン ネットワーク接続により、VMware Horizon Airの顧客は、データ センター間でイメージ、デスクトップおよびアプリケーションの高速移動が可能になり、エンドユーザーの生産性を損なうことがありません。

  1. 従来通りの低費用

今回、VMwareは価格の変更を行いません。したがって、VMware Horizon Airの顧客は、VMwareのStandard、Advanced、Enterpriseエディションのデスクトップおよびアプリケーション サービスを、従来通りの低額な月額または年額でのサブスクリプションで利用できます。

  1. 最高のSLAに基づくアジャイル インフラストラクチャ

IBM Cloudでは、デスクトップ、アプリケーション サービスおよびキャパシティへの高速アクセスがサポートされるので、エンドユーザーは数分から数時間でオンライン接続が可能となります。またIBM Cloudでは、カスタム ハードウェアを使用することで、VMware Horizon Airデスクトップおよびアプリケーションを利用しようとする顧客のニーズに最も合うよう構成されたソリューションが提供されます。

私たちVMwareは、クラウド サービスによりモビリティを実現することが成功への道である、との顧客の声を数多く耳にしてきました。また、その実現のため、選択肢や柔軟性が増すことを希望する、とも顧客は述べています。今回のIBMとのさらなるパートナシップの強化は、まさに顧客にそのようなサービスを提供するためのものです。

[1] Source: International Data Corporation (IDC), Worldwide Virtual Client Computing Desktop as a Service-Enabling Software Forecast, 2015-2019; Robert Young and David Laing

新卒 2 年目 SE が贈る 仮想デスクトップのキソ!第 8.2 回 ~ App Volumes を使ってみよう その2 ~

こんにちは、SEの川崎です。

前回に引き続き、『新卒2年目 SE 社員が贈る 仮想デスクトップのキソ!』シリーズ、スピンオフ版の第2段として、VMware App Volumes ™ (App Volumes)に関する記事をお届けいたします。まだ”その1”をご覧になっていない方はこちらよりご確認ください。

前回は App Volumes がどのような課題を解決するのか、リンククローン×流動割り当ての課題を確認するところからはじめ、App Volumes の全体像、構成要素、おおまかな導入の流れをご紹介しました。今回は、App Volumes の中でも鍵となる AppStack、Writable Volumes という2つの要素に着目しながら、それらが結局どう役立ってくれるのか、というところまでを見ていきます。

§3.AppStack と Writable Volumes とは? – 作成から運用まで –

§3-1.AppStack

この節では AppStack について、もう少し深く見ていきます。内容は次の通りです。

  • テンプレート
  • Provision(AppStackへのアプリケーションインストール)
  • Assign(ユーザとの紐付け)
  • バックアップの方法
  • RDSHでの利用

テンプレートについて

初期構成で設定したデータストア内の指定のパスに AppStack のテンプレートがあります。

AppStack の作成時には、このテンプレートを指定して作成します

図1.AppStack 作成時の画面イメージ、テンプレートを指定

図1.AppStack 作成時の画面イメージ、テンプレートを指定

デフォルトでは 20GB のサイズで作成されますが、容量は手順に従いカスタマイズすることも可能です。

Provision について

AppStack にアプリケーションをインストールする作業を Provision と呼びます。App Volumes Managerの管理コンソールから “Provisioning Computer” を指定して Provision を開始し、いくつかのアプリケーションをインストールします。

図2.provision 開始後の provisioning computer の画面イメージ

図2.provision 開始後の provisioning computer の画面イメージ

なお、一度作成した AppStack を修正したい場合には、Update 作業を行うことにより、一度既存AppStack の複製を作成した上で再度 Provision 作業を行うことが可能です。

Assign について

ユーザ、グループ、またはコンピュータに対して AppStack を Assign (AppStack との紐付け)します。即時または次回のログオンか再起動後にアタッチするよう、指定することが可能です。

図3.AppStack の assign 時の画面イメージ

図3.AppStack の Assign 時の画面イメージ

バックアップについて

Storage Group を構成することにより、複数のデータストア間で AppStack を複製して配置しておくことで冗長化が可能です。また、AppStack は読み取り専用で、管理者が新規に作成したり Update 作業を行ったりした際にしか変更は加わりませんので、変更が入ったタイミングで都度バックアップしておくことを推奨します。バックアップには、AppStack の格納されたデータストアを LUN ごとバックアップする方法や、vSphere Client などで個別にコピーする方法 などが挙げられます。AppStack の種類の数だけバックアップをとればよいので、規模が大きくなければ個別のコピーでもそれほど工数はかかりませんね。

図4.Storage Group を表示。"iSCSI-01", "iSCSI-02", "iSCSI-03" を要素として "iSCSIs" という Storage Group を構成。

図4.Storage Group を表示。”iSCSI-01″, “iSCSI-02”, “iSCSI-03” を要素として “iSCSIs” という Storage Group を構成。

図5.各データストア内に配置された AppStack

図5.各データストア内に配置された AppStack

RDSH 環境での利用

RDSH に対しても AppStack は利用可能ですが、Writable Volumes は利用できません。要件など詳細はドキュメントをご参照ください。(FAQも参考になります)

 

§3-2.Writable Volumes

この節ではWritable Volumesについて、少し深く見ていきます。内容は次の通りです。

  • テンプレート
  • 作成と割り当て
  • バックアップ

テンプレートについて

初期構成で設定したデータストア内の指定のパスにテンプレートがあります。Writable Volumes については、App Volumes 2.10では下記2通りのプロファイルが提供されています。

  • uia_only (user-installed application)
  • uia_plus_profile (user-installed application plus profile)

作成と割り当て

割り当てるユーザを指定し、テンプレートを選択して作成します。

図6.Writable Volumes の作成。テンプレートを選択。

図6.Writable Volumes の作成。テンプレートを選択。

Writable Volumes のサイズはデフォルトでは 10GB ですが、”Expand” が可能です。

図7.作成された Writable Volumes の一覧。"Expand" も可能。

図7.作成された Writable Volumes の一覧。”Expand” も可能。

バックアップについて

Writable Volumes はユーザがデスクトップ利用中は書き込みが発生している可能性があり、ユーザがログオフしているときがバックアップに望ましいタイミングになります。vmdk ファイルのバックアップは、ユーザログオフ中に LUN 単位でバックアップをとるか、AppStack 同様に個別にコピーする手法を用いることができます。サポートはされていませんが、Flings で提供されているツールが役に立つ場合もあります(弊社ブログでの紹介記事)。また、 Writable Volumes にユーザプロファイル、ユーザデータを保持せず、User-Installed Application のみの利用に絞ることによりバックアップを不要にする構成をとる設計もよく用いられます。その場合はユーザのデータやプロファイルはフォルダリダイレクトや移動ユーザプロファイル、User Environment Manager を利用して保持し、別途ファイルサーバ側をバックアップします。Writable Volumes のバックアップを取得しない場合は User-Installed Application は再構成時にユーザ側で再インストールが必要です。

§4.使い方とメリットを改めてみてみよう

全体像 – ある営業日と翌営業日の仮想デスクトップ利用状況

EUC8_benefit

図8.App Volumes を導入した環境での、ある2日間の仮想デスクトップ利用イメージ

 

§4-1.AppStack のメリット

営業系従業員向けのアプリケーション、技術系従業員向けのアプリケーションをそれぞれ AppStack 化しておくことにより(図9 – ①)、共通のデスクトッププールに接続していても、各ユーザの所属する部署に応じてデスクトップ内で利用できるアプリケーションを変えることが可能です。ユーザのログインに伴ってユーザに割り当てられた AppStack が仮想デスクトップに Attach され(図9 – ②)、ユーザはデスクトップ内でアプリケーションを利用することができます(図9 – ③)。

これにより、ユーザが自分の部署に応じたアプリケーションが利用できる状況を確保しつつ、デスクトッププールのマスターとなる仮想マシンイメージを一つに統一しておくことができます。管理者の方は、マスターのサービスパックアップデートや新しいアプリケーションの AppStack へのインストール作業は一度で済みますが、それにより全ユーザの環境をアップデートできます。

図9.AppStack が割り当て済みの環境での仮想デスクトップ利用イメージ

図9.AppStack が割り当て済みの環境での仮想デスクトップ利用イメージ

 

§4-2.Writable Volumes のメリット

各ユーザに Writable Volumes を割り当てておくことで(図10 – ①)、各ユーザは独自にインストールしたアプリケーションを別のデスクトップに接続しても使い続けることができます。ユーザがログインしたデスクトップには Writable Volumes が Attach され(図10 – ②)、ユーザが新規にインストールしたアプリケーションは Writable Volumes に保存されます(図10 – ③)。ユーザが別の仮想デスクトップにログインした際にも、そのユーザに割り当てられた Writable Volumes が Attach されることで、ユーザはアプリケーションを利用することができます。(図10 – ④)

ユーザには自由にアプリケーションをインストールできる環境が提供されますが、ユーザの総数と同数のデスクトップ用仮想マシンを確保しておく必要がありません。管理者は同時接続数を満たす数をベースにデスクトップの展開数を決定することができます。

図10.Writable Volumes が割り当て済みの環境での仮想デスクトップ利用イメージ

図10.Writable Volumes が割り当て済みの環境での仮想デスクトップ利用イメージ

 

§5.関連動画リンク

  • AppStack の Attach 時の動作イメージ動画

https://www.youtube.com/watch?v=Csn5eT93EFo

  • 構築の流れの動画

https://www.youtube.com/watch?v=yL7Zx2IAEes

おわりに

2回にわたり App Volumes についてお届けして参りましたが、いかがでしたでしょうか。この記事をきっかけに App Volumes について、少しでもイメージを持っていただけたなら幸いです。

 

新卒2年目社員が贈る 仮想デスクトップのキソ!
第1回 仮想デスクトップと Horizon 6 ( with View)
第2回 仮想デスクトップの基本構成
第3回 プール作成と割り当て
第3.5回 View Composer の仕組み
第4回 接続方法と接続元端末
第5回 公開アプリケーションのキソ
第5.5回 ThinAppによるアプリケーション仮想化のキソ
第6回 スケールアウト対応
第7回 完結編、仮想デスクトップと関連ソリューション総まとめ
第 8.1 回 App Volumes を使ってみよう その1
第 8.2 回 App Volumes を使ってみよう その2

新卒 2 年目 SE が贈る 仮想デスクトップのキソ!第 8.1 回 ~ App Volumes を使ってみよう その1 ~

こんにちは、SEの川崎です。

『新卒2年目 SE 社員が贈る 仮想デスクトップのキソ!』シリーズ、スピンオフ版の第2段は、第7回の補足として、VMware App Volumes ™ (App Volumes)に関する記事を2回にわけてお届けいたします。

App Volumes については、以前にも ブログ記事 がありますが、今回はインストール方法なども含めてもう少し具体的に見ていくことで、こんな用途で実際に使えそうだなというイメージをつけていただければと思います。

なお、本記事の内容はバージョン 2.10 をベースとして記載いたしますので、ご了承ください。(バージョン 3.0 のリリースノートにて本番環境での使用に 2.10 を推奨しているため)

§1.App Volumes の用途と利用シーン

§1-1.利用シーン

App Volumes の機能に入る前に、まずは App Volumes がどんな場面で役に立つのか、見ていきましょう。

仮想デスクトップのキソ!ブログの別の回でも扱っておりますが、「リンククローン」や「流動割り当て」という言葉は覚えておいででしょうか。リンククローンは、マスターVMとそのスナップショットからレプリカVMとその差分によって多数の仮想デスクトップを展開する方式で、OSイメージの管理やストレージ容量の削減で効果がありました(図1 – ①)。

流動割り当ては、各ユーザに対して特定のデスクトップを固定して割り当てず、ログオフ後に接続する度に異なるデスクトップ仮想マシンに接続する方式でした。これは、用意する仮想マシンが少なくてすむという利点がありました(図1 – ②)。

図1.リンククローン×流動割り当てイメージ

§1-2.App Volumesで解決される課題とは?

一見メリットが多いリンククローン×流動割り当てという方式ですが、App Volumes を利用しない、これまでの方法を前提として考えた場合には、いくつか課題がありました。

その主要なものがアプリケーションのインストールに関わる課題です。まず流動割り当てでは、仮にある仮想マシンにアプリケーションをユーザがインストールしても、次のログインで別のマシンにログインしては意味がなくなってしまいますので、専用割り当てにする必要があります。また、リンククローンで展開された仮想マシンは、更新や再構成の操作のたびに差分ディスクがリフレッシュされてしまい、アプリケーションは管理者がマスターイメージにインストールする必要がありました。(**通常ディスクや移動ユーザプロファイル、persona managementを利用してもアプリケーションインストール領域は通常は対象外になります、図2 – ①) しかしながら、ユーザ個別に利用するアプリケーションを全て管理者が代行してインストールすると、マスターイメージが肥大化しますし、管理者の工数も増えてしまいます(図2 – ②)。部署など特定の業務との関連のアプリケーションに絞ったとしても、全社に対してVDIを展開するような場合には、マスターイメージがいくつも存在し、その管理もそれなりに煩雑になってしまいます(図2 – ③)。

図2.リンククローン方式で複数のデスクトッププールを展開

これらの課題がApp Volumesで解決されます。App Volumes を利用した環境では、部署に固有のアプリケーションはAppStack化する(図3 – ①)、ユーザ固有のアプリケーションはWritable Volumesによって保持する(図3 – ②)、といった方法をとることで、マスターイメージは共通の一つのイメージに統一した上で、各ユーザには必要なアプリケーションを提供することができます (図3 – ③)。

図3.リンククローンとApp Volumes を利用した展開イメージ

§2. App Volumes を使おう

§2-1.App Volumes 2.10 の環境構成

はじめに、App Volumes を利用する際の全体像を見てみましょう。今回は VDI 環境の場合を例に、追加される関連コンポーネントを確認します。

図4. App Volumes 環境の全体像

図4. App Volumes 環境の全体像

なお、今回は App Volumes のコンポーネントに注目しているため、View 部分については簡略化しています。また、App Volumes は物理環境に対しても使用可能ですが、今回は扱いませんので詳細は弊社ドキュメントを参照ください。

2-2. 各コンポーネントの役割

EUC8_components_mgr App Volumes Manager (Windows Serverにインストール)
App Volumesの中核コンポーネントとして、管理者向けのWebコンソールを提供し、App Volumes管理、AppStackやWritable VolumesのAssignに利用します。
EUC8_components_db App Volumes Database
AppStack、Writable Volumes、ユーザ、コンピュータ、それらの紐付けなどに関する構成情報を格納するSQLサーバデータベース 
EUC8_components_agent App Volumes Agent
AppStackやWritable Volumesの割り当てを受けるWindows デスクトップにインストールするソフトウェア。
EUC8_components_prov Provisioning Computer
AppStack作成用コンピュータ。AppStackを Attach してアプリケーションをインストールする際に利用します。 
EUC8_components_appstack AppStack
一つまたは複数の仮想デスクトップにAttachされることで、ユーザは仮想マシンにもとからアプリケーションがインストールされていたかのようにアプリケーションを利用することができます。
 EUC8_components_writable Writable Volume:
ユーザごとに用意される、読み書き可能なボリュームです。ユーザのログインに応じて仮想マシンにAttachされ、セッションが変わってもユーザに固有の情報を保持するために使われます。保存内容としては、ユーザのインストールするアプリケーションとその設定情報、アプリケーションのライセンス情報、ユーザとコンピュータのプロファイル、データファイルになります。

 

 

2-3. 構築の大まかな流れ

構築のおおまかな流れとしては下記の5ステップになります。

図5. App Volumes 構築のおおまかな流れ

図5. App Volumes 構築のおおまかな流れ

  • App Volumes Managerをインストール
図6. App Volumes Manager インストール後のイメージ

図6. App Volumes Manager インストール後のイメージ

Windows Server にISOファイルをマウントし、App Volumes Manager をインストールします。

  • App Volumes Managerを構成
図7. App Volumes Manager 初期構成時の画面イメージ

図7. App Volumes Manager 初期構成時の画面イメージ

App VolumesのWebコンソールに接続し、構成作業を行います。

Active Directory、App Volumes の管理者グループ、vCenter Server、AppStack や Writable Volumes のテンプレートを格納するデータストア、などを登録します。

  • App Volumes Agentをインストール
図8. 仮想デスクトップのマスターとなる仮想マシンへ App Volumes Agent をインストール

図8. 仮想デスクトップのマスターとなる仮想マシンへ App Volumes Agent をインストール

仮想デスクトップにISOファイルをマウントして、App Volumes Agentをインストールします。インストールの設定中にApp Volumes Manager を指定します。

  • AppStack を準備
図9. AppStack の作成・割り当て完了時のイメージ

図9. AppStack の作成・割り当て完了時のイメージ

AppStack を作成して、必要とするユーザに割り当てます。詳しくは次回扱います。

  • Writable Volumesを準備
図10. Writable Volumes 作成・割り当て完了後のイメージ

図10. Writable Volumes 作成・割り当て完了後のイメージ

必要とするユーザに対して Writable Volumes を作成します。こちらも詳しくは次回扱います。

 

2-4. 環境ができあがるとどう見えるか

では、できあがった環境を確認してみましょう。

まずはWindows OS 内部から、ディスクの管理でマウントされているボリュームがどう見えるか確認します。

図11. App Volumes 利用時の Windows OS から見たボリュームの状態

図11. AppStack ・ Writable Volumes が Attach された仮想マシン (Windows OS 内から確認したボリュームの状態)

次に vSpehere Web Client から確認します。

図12. AppStack ・ Writable Volumes がAttach された仮想マシン (vSphere Web Client から確認した場合)

図12. AppStack ・ Writable Volumes が Attach された仮想マシン (vSphere Web Client から確認した場合)

おわりに

さて、今回はここまでのご紹介になります。続く”その2”では App Volumes の肝となる AppStack と Writable Volumesについて、作成方法などもう少し詳しいところを確認し、その上でユーザは実際にはどのように便利に利用できるのか、を説明して参ります。次回も楽しみにお待ちください!

 

新卒2年目社員が贈る 仮想デスクトップのキソ!
第1回 仮想デスクトップと Horizon 6 ( with View)
第2回 仮想デスクトップの基本構成
第3回 プール作成と割り当て
第3.5回 View Composer の仕組み
第4回 接続方法と接続元端末
第5回 公開アプリケーションのキソ
第5.5回 ThinAppによるアプリケーション仮想化のキソ
第6回 スケールアウト対応
第7回 完結編、仮想デスクトップと関連ソリューション総まとめ
第 8.1 回 App Volumes を使ってみよう その1
第 8.2 回 App Volumes を使ってみよう その2

Horizon 環境を Upgradeしてみよう

みなさま、初めまして。SEの兒玉(Kodama)です。

先日Horizon 7 がアナウンスされましたが、既存で Horizon (旧称  Horizon View )環境をお持ちのお客様はそろそろ新しいバージョンへのUpgradeもご検討されているのではないでしょうか。Upgrade後機能やパフォーマンスが向上していることもあります。例えば Horizon 6から、View 環境で公開デスクトップや公開アプリケーションも使え、利便性も大幅に向上しております。

Horizon 環境のUpgradeに関しては、View アップグレードガイドをみていただくことになります。ですが、vSphereの Upgrade と比べUpgrade対象コンポーネントも多く、実際どこから手をつけていいのか…とお困りのユーザさま、パートナーさまもいらっしゃいます。(前職で、実際わたしがそうでした…。)本記事では、この Upgrade マニュアルを読む前準備として、お役立ていただければと考えております。

※本記事の例では View 5.0 → View 6.2へのUpgrade(vCenter Server / ESXi / View Composer / Connection Server /View Agent)を前提にしております。

どこからUpgradeすればよいのか?

Horizon 環境をUpgradeするには
vCenter Server→ View Composer→ View Connection Server → View Agent → ESXi の順番でUpgradeしていきます。本例は View 5.0 から View 6.2 へのメジャーバージョンをまたいだUpgradeになりますので、少し注意が必要です。

View  アップグレード 6.2のマニュアルには下記のような記載があります。

〜マニュアル抜粋〜

Horizon 6 バージョン 6.2 へのアップグレードでは、次に示す旧バージョンの View コンポーネントがサポートされます。

■Horizon View 5.1 の最新メンテナンス リリース (5.1.3)
■Horizon View 5.2
■Horizon View 5.3 の最新メンテナンス リリース (5.3.4)

ということで…一旦 View 6.2と互換性のあるバージョンを経由する必要がありますので、 View 5.0 → 5.3.4 → 6.2という手順でUpgradeしていきます。経由バージョンをView 5.3.4 とした理由としては、 View 5 系の最新バージョンということで選択しています。

(作業時間/停止時間を考慮すると、一旦 View 5.3.4 でしばらく運用後 view 6.2 へ Upgradeすることも考えられますね。)

今回Upgradeする View 環境として以下の環境を想定してみました。

-vSphere基盤(ESXi 5.0 u3/vCenter Server 5.0 u3)
-View系(View Connection Server 5.0.0 /View Composer 5.0.0/ View Agent 5.0)

それぞれの役割については新卒ブログをご参照ください。

図1
図1 今回UpgradeするView基盤

コンポーネント間の互換性を確認しよう

Upgradeする際は、各コンポーネントのバージョン互換性をVMware Product Interoperability Matrixesで確認します。特にこちら3点の互換性を事前に確認しておくとよいでしょう。

-View Connection Server と vCenter Server
-vCenter Server と ESXi
-View Connection Server と View Agent

本記事では表1のように互換性をとりながらUpgradeしていきます。

表1:各コンポーネント Upgrade中のバージョン

対象製品 Upgrade前 経由するバージョン Upgrade後
ESXi 5.0 u3 6.0 u1
vCenter Server 5.0 u3 5.5. u3 6.0 u1
View Composer 5.0.0 5.3.4 6.2.1
View Connection Server 5.0.0 5.3.4 6.2.1
View Agent (Desktop) 5.0.0 5.3.4 6.2.1

ではUpgrade作業の流れを説明します。フェーズを2つにわけて進めていきます。

第1フェーズ:View 5.0.0 → View 5.3.4
第2フェーズ:View 5.3.4 → view 6.2.1

第1フェーズ: View 5.0.0 → View 5.3.4

1-1 vCenter ServerをUpgrade

ESXi 5.0 u3
vCenter Server 5.5 u3
View Connection Server 5.0.0
View Composer 5.0.0
View Agent 5.0.0

この1-1では vCenter Server 5.5.u3と View Connection Server 5.0.0の 互換性はありませんのですぐに1-2の作業 View Connection Serverと View Composerをあげます。

1-2 View 関連のUpgrade

ESXi 5.0 u3
vCenter Server 5.5 u3
View Connection Server 5.3.4
View Composer 5.3.4

View Agent 5.3.4

ここではView ComposerからUpgradeしていきます。この段階で、vCenter ServerとView Connection Serverの互換性がとれましたね。1-2 が終わった頃…作業時間もそこそこ長くなっているはずなので、ひとまず作業を中断して VDIのサービスを再開します。View 5.3.4 → View 6.2.1へのUpgrade作業(第2フェーズ)は、また作業できる時間をみながら実施してもよいでしょう。第2フェーズまでの間にView AgentのUpgradeは は順々に実施していくと、サービス停止の時間も短くできますね。

※1-2時点のESXi 5.0u3については vCenter Server 5.5 u3 / View 5.3.4と互換性があります。また次のフェーズで実施する vCenter Server 6.0u1と View 6.2.1とも互換性がありますので、フェーズ1ではESXiのupgradeは実施していません。

第2フェーズ: View 5.3.4 → View 6.2.1

第1フェーズと同様に vCenter Serverを6.0 U1へ View 関連を6.2.1へUpgradeします。

2-1 vCenter ServerのUpgrade

ESXi 5.0 u3
vCenter Server 6.0 u1
View Connection Server 5.3.4
View Composer 5.3.4
View Agent 5.3.4

2-2 View 関連のUpgrade

ESXi 5.0 u3
vCenter Server 6.0 u1
View Connection Server 6.2.1
View Composer 6.2.1

View Agent 5.3.4

2-3 ESXiのUpgrade

ESXiのUpgradeについては vCenter 5.5 u3でも vCenter 6.0 u1でも互換性がありますので、最後に残しておきました。DRSの機能を使いながら実施すると楽ですね〜

ESXi 6.0 u1
vCenter Server 6.0 u1
View Connection Server 5.3.4
View Composer 5.3.4
View Agent 6.2.1

1-2と同様に View AgentをUpgradeします。

まとめ

本例はシンプルな構成例ですが、View環境の簡単なUpgradeの手順をご紹介させてもらいました。View 5.x → View 6.x へのメジャーバージョンアップは、作業時間もそれなりかかってしまいますが、フェーズを分けることによって、停止時間を最小限にしてみました。また各コンポーネントの互換性確認が少し複雑ですが、ぜひ本記事が View 環境のUpgrade作業にお役に立てれば幸いです。

旧来の VMware Viewという製品名は Horizonに統一されました。本記事においてはマニュアル中の名称に沿って記載しております。あらかじめご了承ください。

VMware SE 兒玉伊佐央 (Kodama Isao)
(共同執筆 VMware SE 中村朝之)

新卒 2 年目 SE が贈る 仮想デスクトップのキソ!・ 第 3.5 回 ~ View Composer の仕組み ~

新卒 2 年目 SE が贈る 仮想デスクトップのキソ!・ 第 3.5 回 ~ View Composer の仕組み ~
はじめに
皆さんお久しぶりです!新卒 2 年目 VMware SE 野田です。3回目の記事でリンククローンについて少しふれましたが、リンククローンについてもう少し説明してほしい!とご要望が多かったため、リンククローン方式を使う場合のコンポーネントである ” View Composer ” の仕組みについてもう少し踏み込んでご紹介します。
それでは、仮想デスクトップの作成・再構成の仕組みからご紹介します。

プールの概念
第 3 章でも述べましたが、仮想デスクトップはプールと呼ばれる単位で管理します。各プールは「割り当て方式」と「仮想マシンの作成方式」の組み合わせによる、 4 通りの方法がありました。
EUC9_1
-図 1. 仮想デスクトップの作成パターン
その中でも、 View Composer の機能を用いた “ リンククローン方式 ” は仮想デスクトップの展開において、管理者の運用負荷を大幅に減らし、さらにストレージコストを最大限に抑えることができる方式です。

リンククローンの機能を提供する View Composer
EUC9_2
-図 2. View の構成図:リンクククローンは View Composer で提供される機能
図 2 は View を構成する全体像で、その中でも指で指し示してある View Composer がリンククローンの機能が使えるところです。つまり、リンククローン方式を使うのであれば View Composer が必須になります。リンククローン方式で得られるメリットは下記のようなものがあります。

◯ OS アップデートやパッチを素早く更新
◯セキュリティの向上
◯ストレージコストの大幅な削減

では、リンククローンはどのような仕組みで動いているのでしょうか。よく使われる機能が再構成とリフレッシュです。再構成とリフレッシュの説明をする前に、まずはリンククローン方式で作成される仮想マシンの仕組みについてご紹介します。

リンククローン方式による仮想マシンの作成
EUC9_3
-図 3. リンククローン方式でストレージコストが削減できる仕組み
フルクローン方式とは、名前からもご想像がつく通り、仮想マシンの完全な複製を作成することです。図 3 のように 9 台の仮想マシンを展開する場合、完全な複製を作成するので仮想マシン 9 台分のストレージの容量を消費します。では、リンククローン方式ではどうでしょうか。実は、リンククローン方式を使うと、レプリカ VM とその差分データの容量しか発生しないのでストレージの消費容量を大幅に抑えることができます。では、その仕組についてご説明します。

再構成の仕組み
リンククローンの機能で再構成というものがあります。これは仮想デスクトップのレプリカ VM を入れ替える機能です。例えば、現在展開している全ての仮想デスクトップにパッチの更新や OS の変更などを適用したい場合に使います。わかりやすく言うと、 OS にパッチを当てるときなどでは、マスター VM にパッチを当てた後、スナップショットを取得して、そのマスター VM を基に再構成を行うことで、展開した仮想デスクトップ全てがパッチを当てた後の状態になります。このように第 3 回の記事の仮想デスクトップの作成方法のところでもご紹介した、パッチ管理の簡素化、迅速な仮想デスクトップの構成変更が行えます。
EUC9_4
-図 4. 再構成時のディスクの使われ方
では、再構成を行った時、 vSphere 側ではどのような動きをしているのでしょうか。

EUC9_5
-図 5. 再構成時の vSphere 側の動き
図 5 のように再構成を開始すると、「 マスター VM のイメージ + スナップショット 」 = レプリカ VM が作成されます。そしてこのレプリカ VM が読み取り専用の仮想マシン ( レプリカ VM を共有利用するイメージ ) となって、複数の仮想マシンが展開されます。 vSphere 側から見ると仕組みが理解しやすいですね。容量に関しても、レプリカ VM と展開された仮想マシンの差分ディスクの容量しかかからないため、ストレージ容量の消費が抑えられます。
では次に、リンククローンの機能でリフレッシュと呼ばれる機能の説明です。

リフレッシュの仕組み
リンククローン方式で作成されたデスクトップは、ユーザーが操作する度に、その情報が差分ディスクに保存され、ディスクサイズがどんどん大ききなっていきます。このどんどん蓄積されていく差分ディスクの容量をリフレッシュで初期状態に戻します。つまり差分ディスクの拡大防止を行いストレージコストを抑えます。
EUC9_6
-図 6. 更新によって変わる差分ディスク容量
この機能、実はセキュリティを高める意味でも使われている機能です。ある一定期間に蓄積されたデータが更新によって全デスクトップ分きれいに削除されてデスクトップ展開時の初期状態に戻すことができます。よって定期的に更新をかけることで、セキュリティを高めた運用が可能です。

おわりに
View Composer の仕組みについて理解できたでしょうか。仮想デスクトップを展開する場合、このリンククローン方式を使うことによって運用管理が簡素化され、セキュリティも高めることができます。さらにリンククローン方式ではストレージコストも削減することができます。仮想デスクトップを作成する際はぜひリンククローン方式で作成してみてください!

新卒2年目社員が贈る 仮想デスクトップのキソ!
第1回 仮想デスクトップと Horizon 6 ( with View)
第2回 仮想デスクトップの基本構成
第3回 プール作成と割り当て
第3.5回 View Composer の仕組み
第4回 接続方法と接続元端末
第5回 公開アプリケーションのキソ
第5.5回 ThinAppによるアプリケーション仮想化のキソ
第6回 スケールアウト対応
第7回 完結編、仮想デスクトップと関連ソリューション総まとめ
第 8.1 回 App Volumes を使ってみよう その1
第 8.2 回 App Volumes を使ってみよう その2

ThinApp によるアプリケーション仮想化のキソ! : 新卒2年目SE社員が贈る 仮想デスクトップのキソ!

こんにちは。VMware SE の椨木です。
『新卒2年目 SE 社員が贈る 仮想デスクトップのキソ!』シリーズ、スピンオフ版の第1段は、VMware Horizon 6 (以下、Horizon 6)のどのエディションにもバンドルされている「アプリケーションの仮想化」を実現する製品、VMware ThinApp (以下、ThinApp)についてです。この記事を通して、

  • どういう時に「アプリケーションの仮想化」を行うと嬉しいの?
  • そもそも「アプリケーションの仮想化」ってなに?

という部分を一緒に理解していきましょう・・・!

§1. 「アプリケーションの仮想化」ってなに?

ThinApp が実現できる事としてよく使われる言葉が、「アプリケーションの仮想化」です。このブログのシリーズでは「デスクトップの仮想化」を主に取り扱ってきたわけですが、これは仮想基盤上でデスクトップを仮想化する事によって「物理端末やユーザとデスクトップ環境の紐づきの切り離し」を実現した製品であると言えます。

ThinApp はこの「仮想化」の概念をアプリケーションに取り入れ、アプリケーションを OS にインストールする際にインストールの前後の変化(差分)をキャプチャする事によって、「アプリケーションの実体ファイル」および「アプリケーションの起動時に必要となるファイル」、「アプリケーションの動作に必要となるレジストリ値」を把握し、ひとつの EXE ファイルにまとめることで「アプリケーションと OS の紐付きを切り離す」製品です。

 

Vurtual

図1: 様々な仮想化

 

これによって様々な利点が生まれるわけですが、ここでは

  • 古い OS で動いていたアプリケーションを新しい OS 上でも使えるようになる
  • アプリケーションの持ち運び・配信が簡単になる

という2つの「ThinApp が使われる理由」ともいうべき利点をご紹介します。

 

§2. 昔の OS で動作していたアプリケーションが使える!

ThinApp は、パッケージ化した EXE ファイルの中に、主に「「ファイルシステム操作」、レジストリ操作」、「プロセス生成」に関連する Windows API の呼び出しをエミュレートする軽量なアプリケーション実行環境(ThinApp VOS)を組み込みます。また、アプリケーションをインストールする際に、OS に配置する、EXE や DLL 等のファイルやレジストリ情報も、パッケージ化された EXE ファイルの中に収めます。そのため、パッケージ内のアプリケーションが、DLL やレジストリを呼び出すと、ThinApp VOS が、パッケージ内から動作に必要な情報を返すため、新しい Windows 環境でも、飛躍的に動作しやすくなっています。

これを利用すると、たとえば社内の Windows OS をアップデートした際でも、内製アプリケーションを改修する必要なく、新しい OS 上に移行して動作させる事が可能です。

 

ThinApp図2: ThinApp 化による「OS非依存アプリ」の作成

 

§3. アプリケーションの持ち運び・配信が簡単に!

§1 でも少しご紹介しました様に、ThinApp はアプリケーションのインストール時にキャプチャを行い、1つの EXE ファイルとしてパッケージ化する事ができる製品です。
これによって、普通はインストールが必要なアプリケーションも、EXE ファイルを持ち運ぶだけで使用できる、「インストール不要のアプリケーション」にする事ができます。
これを利用して、ThinApp は Horizon 6 と連携した仮想デスクトップへのアプリケーション配信を実現しています。

ファイルサーバなどに置いた ThinApp を Horizon Administrator 上で登録し、配信したいデスクトッププールを選択するだけで Horizon 6 で構築した仮想デスクトップへアプリケーションが配信されます。

 

admin

図3: Horizon 6 による ThinApp の管理

 

このアプリケーション配信によって、従来はアプリケーションのアップデートを行う際は、仮想デスクトップのマスターを変更して再適用する必要があるのに対して、ThinApp を用いる事でマスターの変更無しに新しいバージョンのアプリケーションが配信できるようになり、アプリケーション変更のハードルが劇的に下がります。またマスターイメージの削減にもつながります。

 

step

図4: ThinApp 化によるアプリ更新方法の変化

 

また、ThinApp は Active Directory と連携して使用可能なユーザーを指定できるので、全社員が同じデスクトッププールを使用しても、部署毎に使用可能なアプリケーションを制限する事も可能です。

 

pool

図5: ThinApp 化によるアプリケーション提供方法の変化 マスターイメージ削減になり管理がよりシンプルに

 

§4. アプリケーション仮想化の際の注意点

ここまで読んでいただいて、アプリケーション仮想化後の取り回しのしやすさから、
「もう何でも仮想化しちゃえばいいのでは?」
と思った方も居るかもしれません。

しかし、ThinApp で仮想化できるアプリケーションは、幾つかの要件を満たす必要があります。ここでは、アプリケーション仮想化時の注意点について確認しましょう。

  1.  「ユーザーモード」のアプリケーションであるか確認
    ThinApp で仮想化できるアプリケーションは「ユーザーモード」のアプリケーションのみです。「ユーザーモード」の他に、「カーネルモード」のアプリケーションもありますが、こちらは仮想化できません。
  2.  デバイスドライバを必要とするアプリケーションは仮想化できない
    プリンタのドライバや VPN クライアントソフト、アンチウィルスソフトウェアなど、デバイスドライバを使用するアプリケーションは ThinApp を使用して仮想化する事はできません。
  3.  Windows に関する設定は反映されないものもある
    Windows のアカウント情報・権限、ディスプレイの解像度やスクリーンセーバーの設定など、Windows に関する設定は反映されないものもあります。また、Windows OS のセキュリティパッチも仮想化する事はできません。

その他、一部の Windows API の使用ができない、シェル統合・シェル拡張に制限があるなど、細かい要件がありますので、アプリケーション仮想化の際はベストプラクティス(英語: http://kb.vmware.com/kb/1030290)をご一読いただく事をお勧めします。

 

§5.まとめ

今回は、ThinApp を用いた『アプリケーションの仮想化』についてのご紹介をしました。

「昔のアプリを長く使いたい」「仮想デスクトップのマスター更新を簡素化したい」と思っていたあなた、是非 ThinApp を使ってみてください!

執筆協力: vExpert 2015 山辺和篤

 

新卒2年目社員が贈る 仮想デスクトップのキソ!
第1回 仮想デスクトップと Horizon 6 ( with View)
第2回 仮想デスクトップの基本構成
第3回 プール作成と割り当て
第3.5回 View Composer の仕組み
第4回 接続方法と接続元端末
第5回 公開アプリケーションのキソ
第5.5回 ThinAppによるアプリケーション仮想化のキソ
第6回 スケールアウト対応
第7回 完結編、仮想デスクトップと関連ソリューション総まとめ
第 8.1 回 App Volumes を使ってみよう その1
第 8.2 回 App Volumes を使ってみよう その2

新卒2年目SE社員が贈る 仮想デスクトップのキソ! 第7回 ~完結編、仮想デスクトップと関連ソリューション総まとめ~

■はじめに

こんにちは。 新卒 2 年目の川崎です。”新卒2年目 SE が贈る 仮想デスクトップのキソ!”、第7回目のこの記事ではこれまでの6回の記事でご説明してきた VMware Horizon ® 6 によって実現される仮想デスクトップについて振り返りつつ、他の製品と連携させることで提供されるメリットや仮想デスクトップ以外も含めたエンドユーザーコンピューティングの全体像をお伝えして参ります。

§1. Horizon 6 の振り返り

第1回から第6回で扱ってきた Horizon 6 によって実現される仮想デスクトップ環境を振り返ります。

仮想デスクトップは、仮想環境上に OS (例えば Windows 7 や Windows 8 )をインストールした仮想マシンとして展開され、ユーザはラップトップやデスクトップ、シンクライアント、ゼロクライアント、モバイル端末など様々な端末からアクセスして利用可能です。

図1: 仮想デスクトップ利用イメージ

図1: 仮想デスクトップ利用イメージ

仮想デスクトップをユーザが使えるように構成するにあたり、Horizon 6 では View 接続サーバや View Agent、Horizon Client、View Composer というコンポーネントが登場し、これらが vSphere 環境や AD と連携して仮想デスクトップ環境が実現されます。

図2: Horizon 6 の基本コンポーネント

図2: Horizon 6 の基本コンポーネント

どのユーザがどの仮想デスクトップを使えるか、という点にいついては、ユーザとプール(=同種の仮想デスクトップリソースのまとまり)を事前にマッピングします。

 

図3: ユーザとプールのマッピング

図3: ユーザとプールのマッピング

Horizon 6 でユーザに提供されるのは、「仮想デスクトップ(または VDI )」という、1ユーザ1デスクトップで利用する方式で提供されるデスクトップのほかに、「 RDS (リモートデスクトップセッション)」方式で提供される公開デスクトップと公開アプリケーションがあり、ユーザのニーズに応じて適切な環境を構成可能です。

 

図4: VDI方式とRDS方式の比較

図4: VDI方式とRDS方式の比較

 

§2. VMware の考える EUC の全体像

仮想デスクトップ環境は、これまででご紹介したHorizon 6 の機能でも十分に構築可能ですが、ユーザと管理者の双方でより良いクライアント環境について様々な要望が生じるかもしれません。図5ではその例を示していますが、Horizon 6 だけでなく、VMware Horizon® の他の機能や AirWatch® by VMware を利用することにより多くのニーズに応えたクライアント環境を実現することが可能です。

 

図5: ユーザと管理者の考えるEUCの課題例

図5: ユーザと管理者の考えるEUCの課題例

実は図5に挙げた課題や要望は、Horizon と AirWatch により、下記のように解決して満たしていくことが可能です。

 

図6: Horizon と AirWatch により実現されるEUC全体像

図6: Horizon と AirWatch により実現されるEUC全体像

 

特にハイライトしたコンポーネントについてカテゴリを分けて説明していきます。

§2.1. サーバサイドの構成・管理について – SDDC との組み合わせ

◇コスト面( vSphere, VMware Virtual SAN™ 

コスト面について懸念点となりうるのは、コストの総額を抑えたいという点と、初期導入コストを抑えスケールアウト時に線形に投資を増やしたいという点ではないでしょうか。vSphere では多くの仮想マシンを一台の物理サーバ上で稼動させることができ、サーバについてはハードウェアコストを比較的抑えながら仮想基盤を準備することができます。一方、ストレージについては、共有ストレージはそれなりの規模感での導入が必要になり、スモールスタートして効果を見ながら徐々に部署ごとに導入していくといった展開の仕方にそぐわない場合があります。初期導入時に今後の展開を見越した規模で購入されるケースも多く、初期導入コストの高さは導入時のハードルの一つになりえます。Virtual SAN ではローカルのデータストアを活用しつつ共有ストレージとして扱うことができるため、仮想デスクトップ数に比例してサーバ数とディスクを増やし、ストレージコストを必要容量に比例させることが可能です。

 

図7: Virtual SAN データストアのイメージ

図7: ローカルディスクを共有ストレージとして扱うことが可能な Virtual SAN

◇ポリシーに基づくストレージ利用(Virtual SAN、VMware vSphere® Virtual Volumes™ 

一口に仮想デスクトップ環境といっても用途は様々で、ストレージに必要とされる性能や耐障害性も環境ごとにバラバラであることが考えられます。従来の方法では、ストレージ側で LUN を作成する際にRAID構成を決め、データストアに紐付いたストレージ性能に応じて仮想デスクトップへの割り当てがされていたと考えられます。しかしながら、これはLUNという単位に縛られ、柔軟な容量の伸縮や細かい単位でのストレージポリシーの変更には限界がありました。Virtual SAN や Virtual Volumes を利用した場合には、性能や耐障害性に関するポリシーを設定することで、ストレージ内に自動で適切な配置が行われます。Virtual SAN、Virtual Volumes それぞれの詳細やポリシーとして設定可能な項目については、リンク先をご参照ください。

<Virtual SAN> https://blogs.vmware.com/jp-cim/2013/11/vsphere-55-vsan-1.html

<Virtual Volumes> http://blogs.vmware.com/jp-cim/2015/05/vmware-vsphere-virtual-volumes-vvols.html

 

◇セキュリティ対策(VMware NSX、VMware vShield Endpoint™ 

仮想デスクトップもデスクトップとして利用される以上、セキュリティ対策は必要となります。ここで2点言及するのは、ネットワークをどう構成するか、とウィルス対策のようなセキュリティソリューションをどう活用するか、についてです。ネットワーク構成については、近年の情報漏洩問題や攻撃の報告から、ゼロトラスト型、あるいは拡散防止型と呼ばれる社内環境をファイアウォールで細かく区切る方式が推奨されます。ファイアウォールで区切られたセグメントが極小化するということで、マイクロセグメンテーションとも呼ばれますが、このような環境は NSX によりハイパーバイザ内で仮想マシンごとにファイアウォールを設置することで実現可能です。NSX は vSphere と連携して、vSphere Web Client の画面上からレイヤ4レベルのファイアウォールルールを、プールに属する仮想デスクトップのような vSphere 上のオブジェクト単位で設定可能です。また、レイヤ7のファイアウォールを希望される際には、Palo Alto Networks社と連携した対策が可能です。

 

図8: 分散ファイアウォールによるマイクロセグメンテーション

図8: 分散ファイアウォールによるマイクロセグメンテーション

ウィルス対策に関しては、McAfee社やTrend Micro社、Symantec社といったセキュリティベンダーのソリューションの利用が考えられます。vSphere 環境上でセキュリティソリューションを利用される際には、vShield Endpoint を利用することで、スキャン機能のハイパーバイザへのオフロードが可能です。これにより、エージェントのインストールなしに仮想デスクトップのスキャンが行えたり、スキャン時刻がずれるようスケジュールすることでパフォーマンスの低下を抑えたりすることが可能です。また、ウィルスが発見されるなど問題のある仮想マシンが発見された場合にはセキュリティベンダーが指定した仮想マシンについて、NSX によるファイアウォールルールを自動で変更して通信を遮断するといった対策も可能です。

http://vmware-juku.jp/solutions/vmware-nsx-vdi-security/

 

◇管理工数(VMware vRealize Operations for Horizon®(以下V4H))

仮想デスクトップは仮想環境上で動作し、リモートから接続するため、管理対象は仮想環境に関わるコンピューティング、ネットワーク、ストレージリソースと各ユーザのセッションが必要となります。このような環境を可視化し、一元的に管理して運用していくためのツールとして V4H が利用可能です。VMware vRealize Operations は vSphere 環境の運用管理を行う製品ですが、V4H では Horizon 環境向けのアダプタを追加してvRealize Operations を利用することにより、仮想デスクトップ環境に特化した監視が提供されます。

 

図9: V4Hによる仮想デスクトップ環境の監視

図9: V4Hによる仮想デスクトップ環境の監視

 

§2.2. ユーザサイドの構成・管理について – Horizon の機能で仮想デスクトップの多様なニーズに対応

*AirWatch の機能をご利用いただくことで、モバイル環境を中心に更に多様な環境に対応することができますが、今回は Horizon の機能に対象を絞ってご説明いたします。

 

ユーザサイドの構成や管理をサポートする Horizon の機能を紹介して参りますが、具体的な機能名を挙げる前に、ユーザや管理者にとって必要な機能とは何かを改めて見てみましょう。

仮想デスクトップにはフルクローン/リンククローンといった展開方法の違いや専有/流動といった割り当て方法の違いがありました。いずれの形式で展開・割り当てされた仮想マシンでも、事前にいくつかのアプリケーションがインストールされたデスクトップイメージを管理者が用意し、それを複製してユーザに渡すという点では同じです。この時、ユーザや管理者からは、次のような要望が上がる場合が考えられます。

≪ユーザの要望≫

  • 個別の自由なアプリケーションインストール
  • ユーザプロファイルの保持
  • アプリケーション利用申請から利用環境整備までの迅速さ(利用に申請が必要な場合)
  • 仮想デスクトップ外にあるアプリケーションへのアクセスの分かりやすさ
  • 環境に縛られず幅広いアプリケーションが利用できる環境

≪管理者の要望≫

  • リソース利用効率とユーザの利便性の両立
  • OSやアプリケーションの柔軟なカスタマイズ
  • アプリケーションの迅速な配信ときめ細かなアクセス制御
  • 多様なアプリケーションの一元管理

 

 

図10: アプリケーションとプロファイルの管理イメージ

図10: アプリケーションとプロファイルの管理イメージ

 

これらの要望には、仮想デスクトップが下記のような機能を備えることで応えていくことができます。

  • リンククローンや流動割り当てでもアプリケーションのインストールと保持が可能
  • ユーザのプロファイル情報(OS の設定情報、アプリケーションの設定情報、ユーザデータ)をユーザに紐付けて保持・管理
  • アプリケーションの迅速な配信
  • アプリケーションのカプセル化(仮想化)
  • 一元的なアクセス管理が可能なポータル

本稿では、アプリケーション管理、プロファイル管理、アクセス管理、という3つの視点で説明いたします。

 

◇アプリケーション管理

管理者が事前に仮想デスクトップイメージに含めたアプリケーションは当然利用可能となりますが、この他にユーザは権限を満たせば個別にデスクトップにアプリケーションのインストールを行うことができます。しかしながら、リンククローンの環境では更新時に差分ディスクにインストールされたアプリケーションデータは消えてしまいますし、流動割り当ての場合は各ユーザがログインの度に別のデスクトップの利用になりえます。VMware AppVolumes では、各デスクトップにWritable Volumes というアプリケーションのインストールデータを保持する仮想ディスクをつけることで、ユーザに紐付けた個別インストールアプリケーションの管理を行います。

一方で、管理者の目線では、ライセンス数の都合などで管理された範囲内でユーザにアプリケーション利用を提供したい場合が考えられます。AppVolumes のAppStack という機能では、アプリケーションがインストールされた仮想ディスクを直接各仮想デスクトップに読み取り専用としてつけることで、ユーザに対する紐付けのみでアプリケーションを利用可能に配信することが可能です。また、VMware ThinApp®という機能では、アプリケーションをカプセル化することで、異なる Windows OS 間でも環境に依存せずにアプリケーションを利用可能にします。ThinApp もユーザに対する割り当てが可能なため、仮想デスクトップ内にないアプリケーションを管理者が配信して利用させるもう一つの方法となります。

これらの方法によって、アプリケーションはユーザに紐付けた管理も可能となり、デスクトップリソースは共有しつつもユーザには個別のカスタマイズされたアプリケーション利用環境を提供することが可能となります。

 

◇プロファイル管理

ユーザに提供される仮想デスクトップは、管理者が事前にカスタマイズすることが可能です。この際、管理者側で事前に定義したい設定事項はGPOとして設定し、ドメインに参加している物理ラップトップ/デスクトップ同様に仮想デスクトップOSの管理が行えます。一方で、ユーザが個別に変更可能な部分に関する情報は、ユーザごとに保持する必要があります。Active Directoryの機能である移動ユーザプロファイルによって保持することも可能ですが、VMware User Environment Manager ( 以下UEM )という機能では、ユーザのOSレベルのプロファイルだけでなく、アプリケーションの設定情報やユーザデータもプロファイルとして管理または保持することが可能です。UEM により、管理者は事前にアプリケーションレベルでより細かくカスタマイズした環境を提供したり、ユーザ個別のプロファイルの反映された環境を提供する一方で基盤となる仮想デスクトップは共有のリソースとして構成したりすることが可能となります。

 

◇アクセス管理

ユーザが仮想デスクトップを利用する際にアクセスするのは、仮想デスクトップ内のアプリケーションやデータには限られません。社内システム上のアプリケーションは当然ながら、公開アプリケーションや XenApp により提供されるアプリケーション、ThinApp によりカプセル化されたアプリケーション、SaaS として社外の環境から提供されるアプリケーションなど様々です。Identitiy Manager(旧称:Workspace Portal )では、ユーザごとに権限の割り当てられている仮想デスクトップ、公開アプリケーション、ThinApp アプリケーション、XenApp アプリケーション、SaaS アプリケーションをポータルとして集めて表示し、一元的なアクセスポータルを提供します。ユーザはブラウザ経由でアクセスし、それぞれのコンポーネントを一度のみのログインで利用可能となります。Horizon Client では、仮想デスクトップと公開デスクトップ、公開アプリケーションへのアクセスを提供するため、より広い範囲で、VMware 製品以外の環境へのアクセスもシングルサインオンで提供する点が Identity Manager の差異となって参ります。

 

図11: Identity Manager のポータル画面イメージ

図11: Identity Manager のポータル画面イメージ

 

なお、以上で紹介しているコンポーネントに関して、Horizon 6 の各エディションで含まれるコンポーネントはホワイトペーパーをご参照ください。

https://www.vmware.com/files/jp/pdf/products/horizon-view/VMware-Horizon-View-Pricing-Licensing-FAQ.pdf

 

■まとめ

以上で全7回の連載は終了です。シリーズを通じていかがでしたでしょうか。仮想デスクトップとは、という基本的なところからHorizon 6の機能をベースに基本的な接続に必要な構成、オプションとして構成可能な選択肢を全般的に見てきました。この連載を機会に少しでも仮想デスクトップへの理解を深めていただければ幸いです。パフォーマンスのチューニング方法など細かい点については、まだまだ奥の深い部分もありますので、ぜひ他の記事や弊社ウェブページの資料もご参照ください。最後までお読みいただきありがとうございました。

 

新卒2年目社員が贈る 仮想デスクトップのキソ!
第1回 仮想デスクトップと Horizon 6 ( with View)
第2回 仮想デスクトップの基本構成
第3回 プール作成と割り当て
第3.5回 View Composer の仕組み
第4回 接続方法と接続元端末
第5回 公開アプリケーションのキソ
第5.5回 ThinAppによるアプリケーション仮想化のキソ
第6回 スケールアウト対応
第7回 完結編、仮想デスクトップと関連ソリューション総まとめ
第 8.1 回 App Volumes を使ってみよう その1
第 8.2 回 App Volumes を使ってみよう その2

新卒 2 年目 SE が贈る 仮想デスクトップのキソ!・ 第 6 回 ~ スケールアウト対応 ~

みなさん、こんにちは。新卒 2 年目に突入した氏田 ( Ujita ) です。第 6 回の仮想デスクトップ Blog では、仮想デスクトップを大規模に展開する方法についてお伝えします。

~ はじめに ~

過去のエントリ ( 第 2 回第 3 回 ) で、仮想デスクトップはマスタイメージを元に Pool 単位で展開されることをお伝えしました。しかし、仮想デスクトップを大規模に展開したい場合、単純に Pool の数を増やすだけでは対応できなくなってきます。なぜなら、各コンポーネントの上限値や仮想デスクトップのパフォーマンスを考慮する必要が出てくるからです。また、管理性や耐障害性の担保といった基盤側の対応も重要です。そこで、今回のブログでは、VMware Horizon 6 のスケールアウト方法だけでなく、仮想デスクトップ環境の管理性やパフォーマンスを担保する仕組みについてもご紹介します。

 

Horizon_Blog06_yujita_01

図 1 . 規模が拡大した場合の考慮事項

 

§ 1 . Horizon 6 のスケールアウト

§ 1 . 1 仮想デスクトップの管理単位

Horizon 6 には、階層構造の管理単位があり、小さい順から Pool 、Block 、Pod 、Cloud Pod と呼ばれます。図 2 に、各管理単位の仮想デスクトップ数と包含関係をまとめました。

 

Horizon_Blog06_yujita_02

図 2 . Horizon 6 の管理単位と包含関係

 

Pool や Block といった単位で設計・構築がしっかりできていれば、大規模な環境を構築する場合でも、同じものをスケールアウトさせるだけなので、規模の拡大が容易になります。

それでは、各管理単位について、実際の構成と共に紹介していきます。まずは、小規模な環境からです。

 

§ 1 . 2 Pool : 500 台程度の小規模な環境

過去のエントリ ( 第 3 回 ) でご紹介したとおり、仮想デスクトップは元となるマスタイメージから Pool 単位で展開されます。仮想デスクトップの管理の最小単位は、この Pool になりますが、500 台程度の規模であれば単一の Pool 、それよりも規模が大きくなる場合は Pool のスケールアウトで対応します。実際には、1 つのプールに最大 2,000 台の仮想デスクトップを展開できますが、再構成時の負荷や処理完了までの時間を考慮しなければならないため、約 500 台 / Pool を上限とすることが多いです。
通常 1 台の ESXi サーバあたりに 100 台程度の仮想デスクトップを動作させます。また、VMware vSphere HA ( 後述 ) 発動時のリソースを確保するために、サーバは N + 1 構成にされる事がほとんどです。従って、500 台程度の規模であれば、サーバ台数は 5 ~ 8 台程度となります ( 図 3 ) 。

 

Horizon_Blog06_yujita_03

図 3 . Pool の構成イメージ ( ~ 500 台 )

 

§ 1 . 3 Block : 2,000 台程度の中規模な環境

1 つの vCenter Server 配下で管理される仮想デスクトップのまとまりを Block と呼びます。1 つの vCenter Server で管理可能なデスクトップの数は 10,000 台ですが、障害範囲の限定や処理の分散の観点から、vCenter Server あたり 2,000 台程度として導入することが多いです ( ※ vCenter Server が停止した場合、仮想デスクトップの電源や再構成の処理ができなくなりますが、仮想デスクトップ環境が利用できなくなるわけではありません )。
Block は通常、複数の ESXi サーバクラスタから構成されます ( 図 4 ) 。

 

Horizon_Blog06_yujita_04

図 4 . Block の構成イメージ ( 500 ~ 2,000 台 )

 

なお、ユーザと仮想デスクトップの紐付けを管理する Connection Server は、規模に応じてスケールアウトすることが可能になっています。Connection Server あたりの最大同時接続数は 2,000 台なので、負荷分散や耐障害性を考慮し、Block の規模では Connection Server を 2 ~ 3 台程度導入します。

 

§ 1 . 4 Pod : 10,000 台までの大規模な環境

大規模な環境には、先ほどの Block をスケールアウトすることで対応します。複数の Block からなる仮想デスクトップ環境を Pod と呼びます。Pod の上限値が 10,000 台となっているのは、セキュリティサーバのクラスタ ( 最大 7 台 = 5 ( Active ) + 2 ( Standby ) ) で対応できる最大同時接続数が 10,000 台だからです。

 

Horizon_Blog06_yujita_05

図 5 . Pod の構成イメージ ( 2,000 ~ 10,000 台 )

 

Pod の規模になると、仮想デスクトップ環境は複数の Connection Server で構成されることになりますが、図 5 のようにロードバランサを挟むことで、ユーザは接続先の Connection Server を意識せずに仮想デスクトップを利用できます。

 

§ 1 . 5 Cloud Pod : 20,000 台までの大規模かつグローバルな環境

Horizon 6 より、Cloud Pod Architecture という機能が追加され、最大で 4 つの Pod を連携させ、20,000 台の仮想デスクトップにユーザをマッピングすることが可能になりました。Pod の連携は 2 拠点のデータセンターにまたがって構成できるため、ユーザとデスクトップのグローバルでのマッピングやデータセンターの災害対策にも対応できます ( 図 6 ) 。

 

Horizon_Blog06_yujita_06

図 6 . Cloud Pod ( 10,000 ~ 20,000 台、拠点間連携 )

 

図 6 のように、ユーザは接続先のデータセンターを意識することなく、他サイトの仮想デスクトップを利用できます。

 

§ 1 . 6 スケールアウトまとめ

仮想デスクトップの管理単位と上限台数を下記にまとめます。
• Pool ( ~ 500 台 )
– 単一のマスタイメージから展開される仮想デスクトップ数の推奨上限
• Block ( ~ 2,000 台 )
– vCenter Server あたりの仮想デスクトップ数の推奨上限
• Pod ( ~ 10,000 台 )
– Connection Server クラスタ ( 最大 7 台 ) の最大同時接続数
• Cloud Pod ( ~ 20,000 台 )
– 最大仮想デスクトップ数 : 20,000 台
– 最大 4 Pod 、2 拠点間の仮想デスクトップ環境を連携可能

仮想デスクトップ環境を拡大させていく際には、これらの上限値を意識し、管理単位毎にスケールアウトさせていくことが重要です。

 

§ 2 . 管理性、パフォーマンスの担保

仮想デスクトップ環境では、多くの仮想マシンを同時に管理しなければならないため、管理性やパフォーマンスを担保する仕組みが必要です。ただ、この辺りの仕組みは、長年仮想基盤を提供してきた VMware が一番得意とするところです。そのうえ、Horizon のライセンスには、仮想基盤を提供する vSphere の最上位ライセンス ( Enterprise Plus ) が含まれるため、vSphere 基盤の機能をフルに活用できます。ここでは、これら vSphere の機能を使い、管理性、パフォーマンスをどのように担保していくかについてお伝えします。

 

§ 2 . 1 vSphere HA ( High Availability ) ~ 障害時に仮想マシンを自動で再起動 ~

vSphere HA は、ESXi サーバが突然停止してしまった際に、そのサーバ上で動作していた仮想マシンを他のサーバで自動的に再起動してくれる機能です ( 詳しくはこちら )。仮想デスクトップ環境用に ESXi サーバクラスタを組む際は、HA を有効にし、サーバが 1 台落ちても他のサーバで仮想マシンを再起動できるようリソースに余力を持たせた設計にします。

 

Horizon_Blog06_yujita_07

図 7 . vSphere HA

 

§ 2 . 2 DRS ( Distributed Resource Scheduler ) ~ 仮想マシンを自動で最適配置 ~

DRS は、ESXi サーバクラスタのリソース ( CPU 、メモリ ) をプール化し、各サーバの負荷を自動的に分散してくれる機能です ( 詳しくはこちら )。仮想マシンの配置もリソースプールに対して行えるので、どの ESXi サーバに何台の仮想デスクトップを展開するか悩む必要もありません。また、クラスタのリソースを 1 つにまとめて管理できるため、リソースの残り容量が把握しやすいという利点もあります。

 

§ 2 . 3 分散仮想スイッチ vDS ( vSphere Distributed Switch ) ~ ネットワーク設定を一元管理 ~

リソースプール ( DRS を有効にしたクラスタ ) に対して仮想デスクトップを展開した場合は、負荷分散のため仮想マシンがサーバ間を自由に行き来できる状態になるので、各サーバのネットワーク設定を統一しておく必要があります。クラスタ内のサーバ台数が多い場合、この設定作業には手間がかかりますが、vDS を利用すると、仮想スイッチの設定が各 ESXi サーバへ自動的に配信されるので、設定の手間やミスを削減することができます ( 詳しくはこちら )。特に、業務部門毎に仮想デスクトップのネットワーク設定が異なる場合など、設定が煩雑になる際に有効です。

 

§ 2 . 4 Storage DRS ~ ストレージの負荷を自動で分散 ~

Storage DRS は、いわば DRS のストレージ版であり、特定のストレージに負荷が集中している場合、仮想マシンのファイル ( .vmdk ) を他のストレージに自動で移すことで、ストレージの負荷を分散してくれる機能です ( 図 8 ) 。Storage DRS は、管理者が指定したデータストアクラスタ内で有効になります。ちょうど、DRS がサーバクラスタ内で負荷分散するのと同じイメージです ( 詳しくはこちら )。

 

Horizon_Blog06_yujita_08

図 8 . Storage DRS

 

ちなみに、VMFS 形式の LUN あたりに展開すべきデスクトップの推奨台数は、最大で 128 台 ( VAAI 利用時は 140 台 ) なので、仮想デスクトップの数がこれ以上になる場合は、Storage DRS を有効にしたデータストアクラスタに展開することをお勧めします。

 

§ 2 . 5 View Storage Accelerator ~ マスタイメージの読み取り負荷を低減 ~

リンククローン ( 第 3 回 ) の場合、仮想デスクトップ Pool のマスタイメージは、同時に多くのユーザから読み込まれるため、ストレージの負荷が高くなってしまうという問題がありました。View Storage Accelerator を利用すると、マスタイメージのデータを各 ESXi サーバにキャッシュすることができるので、ストレージの負荷が低減し、仮想デスクトップの起動時間を短縮させることができます。企業で仮想デスクトップを利用している場合、始業時間に仮想デスクトップの起動が集中し、起動時間が遅くなることがあるため、View Storage Accelerator を有効にしておくことをお勧めします。

 

§ 2 . 6 vSphere機能のまとめ

Horizon の仮想デスクトップ環境では、上記でご説明した vSphere の上位機能が使い放題です。また、今回は説明を省かせていただきましたが、仮想マシン毎にサービスレベルを設定できる機能も利用可能です。Horizon では、これら基盤の機能を積極的に活用することで、管理性を一切損なうことなく仮想デスクトップ環境をスケールさせることができます。

 

Horizon_Blog06_yujita_09

図 9 . vSphere 機能のまとめ

 

~ おわりに ~

今回のブログ「スケールアウト対応」でお伝えしたかったことは、下記の 2 点です。
① 仮想デスクトップ環境は、管理単位 ( Pool 、 Block 、 Pod 、 Cloud Pod ) を意識することでスムーズに拡張できる
② vSphere の上位機能を活用することで、大規模環境でも管理性が損なわれない

仮想デスクトップ環境をスケールアウトさせる際には、考慮すべき事項が多く、少し難しく感じるかも知れませんが、上記の 2 点をしっかりと押さえることで柔軟な拡張が可能になります ( 実際、仮想デスクトップを 1 万台以上導入されているお客様はたくさんいらっしゃいます!)。
このブログをきっかけとして、一社でも多くのお客様に仮想デスクトップの導入を検討いただけたらと思います。

次回はいよいよ最終回となります。最終回では、川崎さんが Horizon 6 の魅力はまだまだこんなもんじゃないっ!というところをビシッ!!と示してくれる予定です。次回もお楽しみに!

VMware SE 氏田裕次

 

新卒2年目社員が贈る 仮想デスクトップのキソ!
第1回 仮想デスクトップと Horizon 6 ( with View)
第2回 仮想デスクトップの基本構成
第3回 プール作成と割り当て
第3.5回 View Composer の仕組み
第4回 接続方法と接続元端末
第5回 公開アプリケーションのキソ
第5.5回 ThinAppによるアプリケーション仮想化のキソ
第6回 スケールアウト対応
第7回 完結編、仮想デスクトップと関連ソリューション総まとめ
第 8.1 回 App Volumes を使ってみよう その1
第 8.2 回 App Volumes を使ってみよう その2

新卒 2 年目 SE が贈る 仮想デスクトップのキソ!・ 第 5回 ~Horizon からアプリケーションを起動!? “公開アプリケーションのキソ” ~

こんにちは。 前回に引き続き、新卒 2 年目の椨木(たぶき)です。

今回の新卒ブログ、“VMware Horizon 6 (with View)” (以下 “Horizon” とします)についてのキソをご紹介するものですが、第1回目から第3回目の記事では、デスクトップ環境を『まるまる』仮想化する方法についてお話してきました。この方式(VDI方式と呼びます)を使用すると、ユーザ一人ひとりに仮想デスクトップ環境(仮想マシン)を割り当てる事になるため、一つのデスクトップ内で複数のアプリケーションを起動し、使用する事ができます。しかし、一方で

『Web アプリケーションを使用したいだけなのでブラウザが使えれば問題ない!』

など、特定のアプリケーションのみを使用させたい・使用したい場合があるかと思います。
ここでは、そういった際に有用となるHorizon の機能の一つ、『Remote Desktop Service (RDS) を用いたアプリケーション配信(公開アプリケーション)』をご紹介します。

§1. Horizon Client からアプリケーションを起動する! ~公開アプリケーション~

Remote Desktop Service を用いたアプリケーション配信を使用すると、ユーザはHorizon Client から「デスクトップ環境」ではなく「アプリケーション」を使用できる様になります。
Horizon Client に表示されたアプリケーションのアイコンをクリックすると、目の前にアプリケーションが現れますが、このアプリケーションは仮想サーバ(Microsoft Windows Server)内で展開されたアプリケーションの画面情報のみがネットワークを通じて手元の端末で表示されている状態です。
図1はHorizon Client からアイコンをクリックしてMSペイントを表示させたものです。

 

rdshapp図1: Horizon を利用したRDS方式アプリケーション配信

 

この『Remote Desktop Service を用いたアプリケーション配信』機能は一般には『公開アプリケーション』方式と呼ばれており、技術的にはMicrosoft の Remote Desktop 方式を利用して、アプリケーションを配信します。この方式はVDIとは異なり、複数のユーザが共有して一つの仮想マシン (Windows Server) にインストールされたアプリケーションを使用する事ができます。

 

usecase図2: VDI 方式と更改アプリケーション方式の違い

 

ここからは、『Remote Desktop Service を用いたアプリケーション配信』機能を『公開アプリケーション』と呼んでご紹介します。

 

§2. 公開アプリケーションの特徴

「アプリケーションだけを配信する」公開アプリケーション、その大きな特徴2点をご紹介します。

 ■ライセンス料金の削減に寄与

これは第1回目の記事のサーバVDI と同様の理由なのですが、Windows 7 やWindows 8.1のようなクライアントOSを使用したVDIを使用するためには、「VDA」と呼ばれる買い切りできないライセンスが必要になります。
この買い切りできないライセンスが、VDIを使用すると大変高価になってしまう印象を持たれる一因となっていました。
公開アプリケーションはWindows Server OSを利用するので、VDAライセンスではなく、 RDS Device/User CAL /Windows CAL を使用すればよくなるため、導入時のコストを抑える事ができます。

また、複数のユーザで一つの仮想マシンを共有する様になるので、ユーザに対する仮想マシンの台数がVDI使用時より大幅に削減され、結果として仮想マシンを載せるためのESXi ホストの台数やホストを動作させるための電気代を削減する事が可能です。

 

■ 簡単に使用したいアプリケーションにアクセス

ユーザに使用させたいアプリケーションが非常に限定されている場合、デスクトップから毎回アプリケーションを選択するVDI方式よりも、アプリケーションの画面をいきなり見ることの出来る公開アプリケーションの方が簡単にアプリケーションを使用する事ができます。
公開アプリケーションは、

  1. 閉じられたネットワーク内のデスクトップPCからVDIのネットワークを通してWebブラウザ「だけ」使用したい
  2.  外出中、出張中に出先から社内アプリ「だけ」を使用できる様にしたい

など、特定のアプリケーションを使用できる環境を作成したいお客様に多くご採用いただいています。

 

§3. デスクトップ仮想化方式の使い分け

Horizon は、VDIはもちろん、公開デスクトップや公開アプリケーションにも対応したデスクトップ環境仮想化製品ですので、「どういった時にどのような方式を取れば良いのか解らない!」という方も居るのではないでしょうか。ここでは、様々なデスクトップ仮想化方式の使い分けの基準をご紹介します。

まずクライアントOSでしか動作しないアプリケーションを使用するユーザ「のみ」にクライアントOS VDIを割り当て、それ以外のユーザにはサーバOSを用いる方式を採用することで、VDAライセンスを最小限に抑えます。
次に、「サーバ VDI」と「公開アプリケーション」の使い分けですが、「VDI」は一つのデスクトップ環境を一人のユーザが専有する方式、「公開アプリケーション」は一つの仮想マシンを複数のユーザで共有する方式です。したがって、「公開アプリケーション」を使用すると、一つの Windows Server が落ちてしまった場合の影響範囲が「VDI」よりも大きくなる傾向があります。
よって、ユーザ単位で性能を保証したい場合や OS(仮想マシン) の停止に伴う影響範囲を小さくしたい場合には「サーバVDI」、それ以外の場合には「公開アプリケーション」を使用する事が望ましいです。

また、マルチセッション(複数のユーザが同一アプリケーションを使用する方式)に対応していないアプリケーションを使用する場合は「VDI」方式を採用する必要があります。

このように、ユーザの使用用途に合わせて正しく割り当てる仮想デスクトップ方式を決める事で、ライセンスコストはもちろん、サーバ台数の削減も行う事ができます。

 

vdiAndRdsh2図3: VDIと公開アプリケーションの使い分け

§4. まとめ

今回は「公開アプリケーション」についてご説明いたしました。
ユーザが使用したい、あるいは管理者がユーザに使用させたいアプリケーションが限定的である場合に、非常に有効な機能である事がお解かりいただけたかと思います。
この「公開アプリケーション」方式、これまでにご紹介してきた仮想デスクトップのコンポーネントにRDSホストを追加するだけで実現できます。
詳しい環境の構築方法については、2014年10月1日の記事をご覧ください。

 

manage図4: vSphere + Horizon で多様なデスクトップ環境を実現

 

「VDI」や「公開アプリケーション」、様々な方法を駆使して、ユーザのニーズにあったコストパフォーマンスの良い仮想デスクトップ環境を作りましょう!

新卒2年目社員が贈る 仮想デスクトップのキソ!
第1回 仮想デスクトップと Horizon 6 ( with View)
第2回 仮想デスクトップの基本構成
第3回 プール作成と割り当て
第3.5回 View Composer の仕組み
第4回 接続方法と接続元端末
第5回 公開アプリケーションのキソ
第5.5回 ThinAppによるアプリケーション仮想化のキソ
第6回 スケールアウト対応
第7回 完結編、仮想デスクトップと関連ソリューション総まとめ

第 8.1 回 App Volumes を使ってみよう その1
第 8.2 回 App Volumes を使ってみよう その2

新卒 2 年目 SE が贈る 仮想デスクトップのキソ!・ 第 4回 ~Horizon にいつでも何処でもアクセスする方法! “リモートアクセス環境構築のコツ” ~

こんにちは。 新卒 2 年目の椨木(たぶき)です。”新卒2年目 SE が贈る 仮想デスクトップのキソ!”、4回目のこの記事では自社データセンタ内の仮想デスクトップ環境に社外からアクセスする際の手法・注意点をご紹介します。

 

cafe

図1:  著者近影 Horizon で仕事の効率アップ!

 

どこからアクセスしてもデスクトップ環境のセキュリティを安全に保つことのできる仮想デスクトップは、

『出張先で社内データを見たい!』
『自分のPCで在宅勤務をしたい!』
『出先でタブレットを使って簡単に情報を見たい!』

といった要求に最適なソリューションです。
第2回の記事では、社内環境からアクセスする際の構成についてご紹介しましたが、上記のような「社外からのアクセス」の場合は、どの様な点に注意して仮想デスクトップ環境の構築を行えば良いのでしょうか?
この記事で一緒に確認していきましょう。

 

§1. 社外からHorizon への二つの経路

社外から“Horizon 6 ( with View )” (以下 “Horizon” とします)環境へのアクセスには大きく

  1.  VPN 方式
  2.  Horizon6 View Security Server 等を使用した”Proxy 方式”

の2つのアクセス方法があります(図2)。

 

VPNvsProxy

図 2. 2つの接続方式

1.の VPN 接続は Horizon へアクセスする端末を、VPN を使用して社内ネットワークに接続することで、あたかも社内から Horizon へアクセスしているかのような環境で仮想デスクトップを使用する方法です。

2.の Proxy 方式は Horizon 用の接続サーバを経由して仮想デスクトップにアクセスする方法です。
この2つの接続方法に必要となる構成を比較してみましょう。

VPN 接続方式は、社内ネットワーク接続用の VPN 環境をお持ちであれば、特別な機器や新しいセキュリティポリシーを必要とする事なく使用する事ができます。VPN トンネルを介して画面転送プロトコル ( PCoIP ) をやり取りする事になります。

Proxy 方式の接続は、「Horizon 6 View Security Server」あるいは「BIG-IP PCoIP Proxy」を社内ネットワークとインターネットの境界となる DMZ に設置し、このサーバを介して社内の仮想デスクトップ環境にアクセスする方式です。
この方式では、インターネット経由で暗号化された画面転送プロトコル ( PCoIP ) を直接やり取りします。

この2つの方式を比べると、既存の VPN 装置をお持ちの方は、Horizon 専用のコンポーネントが必要とならない分、VPN 接続の方が簡単に構築できるとお考えの方も多いと思います。
実際、仮想デスクトップの初期導入時は、外部アクセスについては既存の VPN 経由として既存機器を流用することで、スムーズな導入を実現されているお客様が多数いらっしゃいます。

では、どういった時に Proxy 方式を採用する必要があるのでしょうか。
次のセクションでは「接続端末の管理」の違いを例に挙げ、どちらの接続方式を選べばよいか考えていきましょう。

 

§2. 経路が変わると管理が変わる -接続端末をどう管理するか-

社内デスクトップ環境への社外からのアクセス方法がわかったところで、いよいよ外部から VDI へ接続!
・・・といきたいところですが、私物の PC や、タブレット端末・スマートフォンなどを社内デスクトップ環境に接続する際に気になるのはセキュリティです。在宅勤務や BYOD を実現する際に必ず挙がるこの問題に対して、Horizon はどのように対応しているのでしょうか。

まず VPN 方式を使用した場合は、接続端末は社内ネットワークへ直接接続されている状態と同等になるため、会社所有の端末と同じポリシーで管理する必要があります。例えば在宅勤務を行う際に、自宅の個人所有の PC を使えず、自宅用に会社支給の接続端末をもう1台割り当てる必要が出てきてしまいます。

一方で、Proxy 方式の場合は Proxy サーバを経由して画面情報のみを接続端末 ( Horizon Client がインストールされた端末)に送信するため、社内ネットワークには直接接続せずに仮想デスクトップ環境を利用可能になります。管理者からすると、接続端末の状態に依存せず、Horizon Client がインストールされてさえすれば接続を許容出来ることになります。
これによって、個人所有の端末が例えばウィルスに感染しているかなどを仮想デスクトップ環境管理者が心配する必要がなくなるので、管理者に負担をかける事無く外部からのデスクトップ環境の操作を実現する事が可能です。

このように、社外からどのような端末を今後接続する事が考えられるかを考え、今後のロードマップに合った接続方式を採用いただく必要があります。

 

§3. 二要素認証 –社外からの接続のセキュリティ強化-

社外からのアクセスの場合はよりセキュリティを強化するため、”二要素認証”の設定をされる方も多くいらっしゃいます。VPN 接続を使用していれば「VPN 接続の際の認証 + Horizon へのログイン」によってこの要件を満たすことができますが、Proxy 方式の接続の場合はワンタイムパスワードによる認証と組み合わせて二要素認証を実現します。
接続デバイスが多様になっていく中、デバイスに依存した認証方式 ( 証明書など ) よりは、人に紐付く認証方式を採用頂くことをオススメします!また、二要素認証を行うか行わないかは接続経路に応じて設定する事が可能です。実際、弊社の Horizon 環境も、社外アクセス時は図3 の様に RSA Secure ID の入力が必要になります ( 社内アクセス時は AD 認証のみで接続可能です )。

 

login2

図3: 弊社社内 Horizon 環境の二要素認証

 

RSA のほかにも Radius や、スマートカードによる認証、エコシステムパートナー様による指紋などの生体認証を利用した二要素認証も利用可能です。

 

§3. まとめ

今回は社外から Horizon 環境にアクセスする際の VPN 方式、Proxy 方式の2つの接続経路について、またその2つの経路における接続端末の管理・セキュリティの確保のためにはどのような方法があるかについてお伝えしました。
現在の社内のセキュリティポリシーやネットワーク環境はもちろん、「今後どのような働き方を仮想デスクトップで実現したいか」といった仮想デスクトップ使用のロードマップを考慮して、Horizon 環境へのアクセス方式を検討してみてください!

 

新卒2年目社員が贈る 仮想デスクトップのキソ!
第1回 仮想デスクトップと Horizon 6 ( with View)
第2回 仮想デスクトップの基本構成
第3回 プール作成と割り当て
第3.5回 View Composer の仕組み
第4回 接続方法と接続元端末
第5回 公開アプリケーションのキソ
第5.5回 ThinAppによるアプリケーション仮想化のキソ
第6回 スケールアウト対応
第7回 完結編、仮想デスクトップと関連ソリューション総まとめ
第 8.1 回 App Volumes を使ってみよう その1
第 8.2 回 App Volumes を使ってみよう その2