RDSHにおける負荷分散方式について

2016年最初の、また、記念すべき(?)50投稿目のネタは、絶賛オススメ中の「RDSH」です。

今回は、Horizon 6.2で強化された「負荷分散」機能について色々と試してみたところ、意外にハマりましたので、、紹介したいと思います。

RDSHにおける負荷分散方式は、以下の2つの方式から選択可能です。

1. 接続数が少ないホストにセッションを割り振る
2. 負荷の小さいホストにセッションを割り振る New!!

「1」は元々あったデフォルトの分散方式で、「2」がHorizon 6.2で追加された分散方式です。

ユーザー数が多い環境などでRDSHを複数台構成する場合、どのホストにユーザーのセッションを割り振られるのか、気になるところだと思います。

それぞれの方式でどのようにセッションが割り振られるのか、実際に設定内容を確認しながら紹介していきたいと思います。

例によって長文となってしまいましたので、、、ご興味のある方は続きをどうぞ。

VMware HorizonがTouch IDをサポート

少し前のUpdateですが、iOS版 Horizon Client 3.5.1でTouch IDがサポートされました。
リリースノートはこちら。

Horizon Viewにおける標準的な認証標準機能としてはパスワード認証のみなので、セキュリティの観点ではあまりよい状況とは言えず、ICカード認証やRADIUS認証などの多要素認証を組み合わせてご利用頂くことで認証におけるセキュリティレベルを高めることが出来ます。

組み合わせ可能な多要素認証として、RSA Secure IDやRADIUSをこれまでサポートしていましたが、「Touch ID」はiOS標準の機能かつ生体認証なのでセキュリティレベルが高い(盗むことが難しい)ということもあって、どのような動きをするのかさっそく試してみました。

結論から言いますと、これはあくまで個人的にですが期待していたものとは少し違いました。。

本機能は、ユーザー名/パスワードの入力を「Touch ID」で"代用する"(利便性を高める)機能であり、ユーザー名/パスワード入力後の2要素認証として「Touch ID」を"強制する"(セキュリティレベルを高める)機能ではありませんでした。

ちょっと残念ではありましたが、、iOSが提供するTouch IDと連携出来るようになったことが大きな前進であると捉え、今後のアップデートで"強制出来る"ようになることを期待しましょう。

せっかくですので、「試してみたい」という方や「画面を見てみたい」という方のために、実際に確認した際の手順などを紹介しておきます。ご興味のある方は続きをどうぞ。

RDSH 自動ファームの構成ガイド

長らく更新が滞ってしまいましたが、、久々に投稿させて頂きます。

そんな私は最近、Horizonの中でも「RDSH」推しです。(笑

仮想デスクトップもよいですが、ユーザーさんが使いたいのは「アプリケーション」であって「デスクトップ」ではないという持論があり、VMwareさんの掲げる「One Cloud, Any Application, Any Device」の一端(Windows Application, Any Device)を担うテクノロジーだと思っています。もちろん、「デスクトップ」を使いたい場合には「公開デスクトップ」機能で対応可能です。

そんなRDSHですが、Horizonの最新バージョンである6.2で多くの機能強化が行われました。

リリースノートから抜粋すると以下の通りです。
・View Composerへの対応
・Cloud Pod アーキテクチャへの対応
・拡張ロードバランシング
・グラフィックス(3D vDGA および GRID vGPU)のサポート

View ComposerやCloud Podアーキテクチャといった大規模展開を見据えた機能強化に加え、これまでセッション数の少ないRDSHにセッションを割り振るといった単純な負荷分散しか出来ませんでしたが、CPU/メモリリソースの使用状況を踏まえた、より適切な負荷分散が可能になっています。さらにvDGA/vGPUのサポート。
まさに、RDSHのためのリリースと言っても過言ではないと思います。(笑

今回は、そんな機能強化の中から、「View Composer対応」についてご紹介します。

本機能は簡単に言ってしまうと、RDSHをたくさん展開したい場合に、1台ずつ構築せずとも、一気に10台、20台と展開することが可能になる、かつ技術的にはView ComposerによるLinked Cloneが採用されているため、OSなどの共通部分のディスク容量削減も可能です。

RDSHの環境においても、Windows Updateやアプリケーションの更新など、ホスト数が多くなってくると1台ずつ作業を行うのは大変ですし、何よりオペレーションミスによってファーム内のRDSHの状態(アプリバージョンなど)に差異が出てしまうことは避けたいところです。

イメージとしては、仮想デスクトップをView Composer(Linked Clone)で展開する場合と同じです。View Composerで展開されたファームのことを「自動ファーム」と呼びます。

それでは、実際に「自動ファーム」を構成する手順について紹介していきたいと思います。

久々の投稿ということもあり、、いつにも増して長文となっております。。
ご興味のある方は続きをどうぞ。

移動ユーザープロファイルからPersona Managementへの切り替え方法

Horizon Viewにおいてユーザープロファイルをファイルサーバーなどに外部保管する仕組みとして、一般的なのは「移動ユーザープロファイル」ですが、ログオン/ログオフ時にプロファイルがダウンロード/アップロードされる仕組みのため、毎回リフレッシュ(初期化)するようなリンククローン環境だとプロファイルのサイズによってログオン/ログオフに時間がかかります。

そんな時に是非試して頂きたいのが、「Persona Management」です。

Persona Managementは、移動ユーザープロファイルとほぼ同じ仕組みですが、ログオン/ログオフ時の待ち時間の低減や一斉ログオンなどで集中するストレージ負荷を低減するために、定期的かつバックグラウンドでデータを転送するのが特徴です。

ログオン時にはすべてのプロファイルを一気にダウンロードするのではなく、ログオンするために必要な最小限のプロファイルのみダウンロードし、ログオン処理を完了させ、残りのデータはバックグラウンドでダウンロードを行います。また、更新されたデータを定期間隔でアップロードを行い、ログオフ時にアップロードされるデータ量を低減することで、ログオフ時間を短縮します。バックグラウンドでダウンロードされるデータなどはユーザーによってバラバラですので、一斉ログオン時などで集中するI/Oも分散出来るという仕掛けです。

Horizon View Standardから使える標準機能ですし、追加でサーバーを構成する必要もありませんので、現在移動ユーザープロファイルで運用されているのであれば追加コストなしで、Persona Managementに切り替え可能です。

ということで、今回は「移動ユーザープロファイルからPersona Managementに切り替える方法」について紹介したいと思います。

ちょっと長文になってしまいましたので、ご興味のある方は続きをどうぞ。

Microsoft EdgeでVMwareの各種Webコンソールにアクセスしてみた

皆さん、Windows 10 へのアップグレードはお済ですか？(笑

私もさっそく検証で利用しているPCをWindows10にアップグレードしてみたのですが、仕事柄、VMware製品に携わることが多く、検証作業やパラメータ確認など、多くの時間を共に過ごすであろう各種WebコンソールがMicrosoft Edgeで正しく動作するのか気になるところ。

ということで、各Webコンソールの動作を確認してみましたが、思ったより(!?)優秀でした。

vSphere Web ClientやView Administratorなど、EUC製品を中心に試した結果をご紹介しておきますので、ご興味のある方は続きをどうぞ。

VMware Horizon View の歴史

今、私が一番お世話になっている「VMware Horizon View」について、ちょっと歴史を振り返るいい機会がありましたので、バージョン履歴や追加された機能などを簡単に纏めてみました。

何に役立つという訳ではありませんが、今よりもう少し「好き」になれると思います。(笑
リリースノートへのリンクも貼っていますので、ご興味のある方はどうぞ。

既存のThinAppパッケージをWorkspace Portal用に変換する方法

Workspace Portalを使ってThinAppパッケージを配信する場合、既存のパッケージをそのまま流用したいというのは当前だと思いますが、そのままWorkspace Portal用のThinAppリポジトリに格納しただけでは、パッケージアプリケーションのプッシュに失敗してしまいます。

実は、Workspace PortalではThinAppパッケージをカタログ情報として独自のバージョン情報やGUIDで管理しています。

そのため、これらの情報の元となる"AppID"が必要となるのですが、ThinAppパッケージに"AppID"を登録する方法は3つあります。

1. [relink]コマンドを使用する
2. "Package.ini"にWorkspace パラメータを追加してから再ビルドする
3. Setup Capture内でWorkspace Portal設定を有効にして再パッケージングする

どの方法で"AppID"を登録するのかは、操作可能なパッケージの状態によって変わります。

パッケージ(exeファイル)しか残っていない場合・・・・・・・・・・・・・・・・[1]
プロジェクトフォルダが残っている場合・・・・・・・・・・・・・・・・・・・・・・・[2]
新規作成やバージョンアップなど再パッケージングを行う場合 ・・・[3]

それぞれのケースごとに具体的な手順を紹介しますので、ご興味のある方は続きをどうぞ。