HorizonとWANについて

今回は、

「HorizonとWANについて」

という、タイトルでお送りします。

 

少し前に、ユーザさんにHorizonのVDI環境を実装した際の話ですが、、、

「Horizonだけなぜかパフォーマンスが悪い」

という、システムエンジニアとして腕を疑われるようなことがありました。

まぁ、もともと大した腕ではないんですけど(笑

 

そんなこんなで、掛けられた嫌疑を晴らす・・ために、トラブルシューター?としての意地も掛けて切り分けを行った結果、

  • ホスト側の負荷は高くない
  • WANを介した事務所で遅い
  • インターネットからUAG経由でアクセスした場合には遅くならない

ということが、事象としてあるようでした。

 

ここまで読んでいただいているとお気づきかもしれませんが、

Horizonの問題ではなく、ネットワーク・・・WANの問題ではないだろうか?

となると思います。

っが、

他のシステムの通信は、WANを介してもパフォーマンスの問題はない。。。

ネットワーク機器上の流量を見ても上限振り切っていることもない。

 

???

うーん、、、通信パケット見てみるしかないかな・・・と、

数か所で元・先の通信を取得したところ・・・、

 

あ!!!

と、言う情報がありました。

 

Horizon側(正確にはvSphere)で設定しているQoS(DSCPの値)がWANを介した途端に無くなっていたんです。。。

ぉぉぉぉ・・・・、納得。

これは、、、WANのところで何かされてますね。。

 

ユーザさんに回線業者に問い合わせてもらったところ、どうも、WANを構成するサービス(WVS)は、特定通信のみ(接続先/元のIP・IP範囲によって)を契約に従って優先かつ保証帯域以上に通信をバーストさせ、その他は帯域保障内の通信だけに制限&場合によっては破棄するように制御している様です。

この仕組みについて情報ソースはありません。。。
回線業者の特別契約かも知れません※。
※回線業者でも情報公開してないように思われます。

 

そんなこんなで、問題原因さえ特定できてしまえれば、こちらのもんです。

解決方法は、契約の内容をお客さんから回線業者に連絡してもらって
契約を変えていただくことでした。

 

こういう話では、、、

既存の他の通信は帯域を十分に使えているのに、
導入したHorizonだけ通信帯域が使えないのは設定とか問題があるのではないか?

と新システム側で調べることになることが多いので

Horizonに限らず、、、ですが、読んでいただいた方の
今後のトラブルの参考になれば幸いです。

 

Horizon環境で使用するマスタはどうするべきなのか

今回は、

「Horizon環境で使用するマスタはどうするべきなのか」

というタイトルでお送りします。

 

これまた、運用支援している現場で見ている私見に満ちた王道から外れたアウトロー?な話でで以下の2種類について書きます。

  • Horizonのデスクトップ用のマスタ
  • AppVolumesのAppStack作成用のマスタ
    (プロビジョニング用マシンというべきか・・?)

 

  • Horizonのデスクトップ用のマスタ

Horizonのマスターは「ADに参加させる」「ADに参加させない」どちらが良いのか。

正直な話、、、参加させていても普段の運用では問題が出ていません。 

 

マスターがDomainに参加していて困ることといえば、AppVolumesを使っている環境で、クローンしてマスターの数を増やそうとしたときです。

普通にクローンしてSysprep 掛けて別のマスターにするには、
ドメインに参加してるので)ネットワークに接続せずに、
ドメインから離脱→Sysprepを掛けなければいけないですが、
ネットワークから切り離される(AppVolManagerと通信できない)と、
AppVolumesAgentの入ったマシンは起動しなくなってしまうんです。

 

なので、対策としては、、、
1.元のマスターの方もメンテナンスして、
  ドメインから抜けて再参加をやる
  (でないと、セキュアチャネルが破損してどちらにせよドメインに繋がらない。)

2.元マスター側でネットワークを切って
  ドメインから抜けたスナップショットを作り、その状態でクローンする。

と、いうことをやる必要があるかな・・・と考えて、次の作業の計画を立てています。

これは、実際にやる機会があるので、結果は追記するかもしれません。

 

  • AppVolumesのAppStack作成用のマスタ

こちらは、、、

1年くらい前に聞いた話では、まっさらからAgentだけ入れた状態で、AppStackを作成するべきという話だったのですが、どうも最近はユーザが使用するデスクトップ(マスタ)に近い状態で作成することが推奨されているようです。

 

まっさらな状態からやっても必要なものはデスクトップで利用される際にはうまく処理はするんでしょうけど、後者の方がAppStackの仕組みを考えると、確かに素直に動きそうな気はしますね。

 

AppVolumesの方もユーザさんに「推奨方式がどうも変わってきている様で、、、」というのは話しているので、バージョンアップとかのタイミングでちょっと様子は見てみたいと思います。

NSXでのマイセグについて(その2)

今回も、前回・・(NSXでのマイセグについて(その1))と同じような

NSXでのマイセグについて(その2)」

と、言うタイトルでおおくりします。

 

前回に引き続き・・・。 

タイトルだけだと、、、え??この件、いまさら・・・?

と、思われる方も多いと思うんですが・・・、

そんな、他の多くの方が書かれている話ではなく!!

 現場で気づいたりしたことを書いていきますので、

足を運んで頂いたなら、、、最後まで読んでいただくと、、、
得られることもある(かも?)と思います!!

 

ということで、Windows FWで運用していた話をNSXのDFW(Distributed Fire Wall:分散ファイアウォール)に実装して運用したときに受けた問合せ、、、という話の第2弾です。

 

第2回:グループポリシーでWindows Firewallを制御して
通信制御しているお客さんで発生した問題。
Win7のときのポリシーをwin10に移植したら発生した問題。。。)

 

問題としては・・・、

以下のことを、お客様から問い合わせを受けたことに起因します。


許可した「リモートサイト」以外は接続を許可していないのに
Microsoft Edgeでは、なぜか接続できる(できてしまう)。。。
IEchromeでは、接続できないのに。。。

 

これは、なぜなのか?

 

『そんな馬鹿な。。。』、と、実際の環境を自分自身で

見てみたら、確かにできていました。。。


このお客様の環境では、

DFW(NSX)が入っていたので、「そっち(DFW)で実装した方が確実です。」
と、DFW側でユーザ環境を動かせるようにしましょう、、、と、

ワークアラウンドを提供して逃げましたが、、、。

と、いうことで、どちらかというと、

DFWの話よりもWINFWの問題があって、

その回避策でDFWを提供したんですよー、という話になってますが、、、

 

 

どなたか、、こんな話を他に聞いたことあれば、、、
(逆に)教えてください。。。

 

 

vSphere5.5からの移行について

今回は、

「vSphere5.5からの移行について」

という、タイトルでお送りします。

 

エンドユーザ先で5.5から移行を行おうとした際に、

いくつか問題になったことを纏めていきます。

あ、この件はオンプレで、オンプレの5.5からオンプレの新しい環境に移行した際の話です。

クラウド移行の話については、弊社の他の方がまとめてくれるはずなので、、、そちらを参考にしてください。。。

 

問題になった事項をピックアップすると、

・EVCの問題

・VDS/VSSの問題

この2点ですね。。。

 

まず、

EVCの方に関しては、、、

vMotionでの移行自体は直接の問題にはなりませんでした!

なぜかというと、古いレベルから新しいレベルに動かすことは普通にできます。

と、いうわけなので、、、

問題点は移行した仮想マシンが、移行先のホストのEVCとレベルが合わなくなっていることです。

これは、新しいCPUの機能が使えないだけ?なので現状維持という意味では特に問題ありませんが、解決するためには1オペレーション必要になります。

仮想マシンのシャットダウン」からの「仮想マシン起動」

・・・あ、2オペですね・・・(笑

ともかく、仮想マシン停止・・・ゲストOSをシャットダウンしてもらって、電源が完全に落ちた状態から、仮想マシンの電源を入れ直すということが必要です。

仮想マシンの再起動ではEVCの動作レベルが変わりません。。。)

 

 

次に、

VDS/VSSの件、、、。

これは、5.5というバージョンによる制約になります。

5.5は、仮想マシンのオンライン移行(vMotion)時にネットワークの変更を行うことが出来ないから…5.5環境vDSから6.xvDSに移行ができない・・・仕様なんです。

(既に、サポート対象外になっているはずなので、、サポートの方に問い合わせてませんが。。。)

なので、どうするか!

考えつきました。。。

5.5環境内で、vDSからvSSにネットワークラベルの変更を行う。

6.x環境内にも5.5のvSSと同じ名前のネットワークラベルをvSSで用意。

5.5から6.xにvMotion実施。(ネットワークはvSS同士で)

移行先の環境でネットワークラベルをvDSの元々目的のものに変更。

 

これで、、、シームレスに移行できます。。。!!

苦肉の策ではありますが、同じような環境で困ってる方、、、

相談いただければ、、、ご助言できることもあるかもしれません。。

VMware Horizonのデスクトップと3rd-PartyのSSO製品との連携について

今回は、

VMware Horizonのデスクトップと3rd-PartyのSSO製品との連携について」

というタイトルで、お送りします。

 

エンドユーザ様に納品したシステムの構成になりますが、

そのエンドユーザ様で利用されているSingle Sign onのシステムが(ご存知かもしれませんが)「Passlogy社のPasslogic」でした。

 

Passlogyさんの公開ナレッジとしても公表されていないので、

実はかなりレア?先進的?な構成を組んできました!!

 

とか、ちょっと調子に乗ったIntroductionを書きましたが、

VMware有識者というか、、メーカの方にお話を伺っても

やれるとしたらこの機能(TrueSSO連携)を使うしかない(はず)。

というお言葉もあり、紆余曲折しながらではありましたが、

顧客要件である「Horizonで管理されたデスクトップにログインする際にSSO製品の認証処理(AD認証ではなくPasslogicのローカル認証)だけで、ログイン可能にする」ということを実現しました!!

 

そもそも、なにが問題だったのか・・・、なぜ回避できているのかとかも以下にまとめていきます。

 

VMware Workspace Oneにログインし、カタログ上のHorizon デスクトッププールにログインする場合、そもそもWorkspace Oneにログインしている時点でADへの認証を行っているので、Horizonのデスクトップへのログインも問題なくシームレスに行きます。

 

っが、

Passlogicのような製品でローカル認証を行って、HorizonのデスクトップにアクセスしようとするとADへの認証が行われずに、Horizonのデスクトップで「認証を済ませてからアクセスしてこい」と言わんばかりに、デスクトップ側からログイン情報の入力を求められてしまう為、SSOにならないのです。

 

その為、そのAD認証をごまかす(言葉を選べ!とよく言われます・・・)ために、TrueSSOの仕組みを使って、デスクトップで求められるADの認証を回避できる。。。というわけです。

 

 

因みにTrueSSOの仕組みというのは、Microsoft社のADCSのEnterprise CAの機能を使って、証明書認証によってデスクトップ側の認証を回避するという仕組みです。

 

ご興味がある方がいらっしゃれば、、今後解説しますー!

 

NSXでのマイセグについて(その1)

今回は、

NSXでのマイセグについて」

と、言うタイトルでおおくりします。

 

タイトルだけだと、、、え??この件、いまさら・・・?

と、思われる方も多いと思うんですが・・・、

そんな多くの方が書かれている話ではなく!!

 

相変わらず・・・(笑、)

現場で気づいたりしたことを書いていきますので、

足を運んで頂いたなら、、、最後まで読んでいただくと、、、
得られることもある(かも?)と思います!!

 

ということで、Windows FWで運用していた話をNSXのDFW(Distributed Fire Wall:分散ファイアウォール)に実装して運用した、、、という話です。

 

第1回:

これまでの環境(Windows ファイアウォール)で運用していた

サーバに関して、DFWに移行した後は統合して管理したいから、

そのままポリシーを移行できないかな?

という要件で問題が発生した話。。。

 

 

ユーザから連携された通りの、

同じポリシーを設定しても、

想定通りの動作に行きません。。。

 

当たり前ではあるんですが、、、

Windowsでは、使うサービスが自動的に許可されるものがあるので

意識しなくてもいいものが、

DFWに移行したときには、明示的に許可してやらないと、、、

許可されてなくてブロックされてしまい、

通信できない。。。ということに陥ります。

 

。。。。。。

。。。

 

 

まぁ、、!

そこにはまったから、、、この記事書いてるんです・・・が!、

 

そういうわけで!!

 

同じようなWindows ファイアウォールから分散ファイアウォールに移す時には、、、

画面転送プロトコルの一つである・・・

RDP

PCoIP

Blast・・・

などなど

は必要に応じて許可しないといけないです。

 

「同じようにしておいて。」「既存環境同様で。」に、、、

惑わされちゃいけません。。。

。。。

ほんとにですよ!。

 

 

ということで、続き(少し現場で焦った話??トラブりかけた話?)は第2回(その2)に書きます。

PasslogicとNetScalerについて

今回は、

「PasslogicとNetScalerについて」

というタイトルでお送りします。

 

今回はVMwareネタではありませんが、

Horizonでも二要素認証でよく利用する「Passlogic」と、

Citrix社のVDIで利用している環境では普通に使われるNetScalerの話です。

(NetScalerは、、、普通のネットワーク機器として、Load Balancerとかとしてもつかわれますけどね。。。)

 

お客さんの環境で、これまで(2014年導入)の環境で利用していたものをPasslogicのバージョン・・・というか、製品を変えなければいけないということから始まり、対応した話です。

 

まず、変更した物。

Passlogic Standard(3.7)⇒Passlogic Enterprise(4.1.2)

一応、NetScalerも11.0から12.0には変えてますが、、、関係は無いと思います。

 

 

構成:

PasslogicをReverseProxyとして、NetScaler(および内部のStoreFront)に連携する方式。

StoreFront・・・というか、StoreFrontと内部ネットワーク内のStoreが複数ある形。

 

まず、そもそもNetScalerに対してReverseProxy連携(のSSO設定)で用意されているNetScaler25という設定ではNetScalerに連携できない。。。

ブラウザのデバッグモードを使用してどうにか問題を解決できたら、次の問題。

 

旧バージョン(Standard)では、ゲートウェイサーバごとに連携するストアの設定が可能だったので、この構成でも接続できていたんですが、、、

Enterprise版(というかバージョン)ではゲートウェイサーバの管理が個別には行えなくなって、認証サーバ側での統合管理だけになってしまった様で、複数のStoreをカバーできなくなってしまったんですよね。。。

 

こちらの問題はPasslogy社に問合せさせてもらっても、仕様上どうしようもない。。。

ということだったんで、いらないStoreを整理する方向にしています・・・。

 

同じ名称の製品でもこういうことがあるので、ご注意ください。。。