ゲートウェイサーバーの背後にある負荷分散されたターミナルサーバー2008へのログインが遅い

Question

インターネットからアクセスするゲートウェイサーバーの背後に、負荷分散された（Session Brokerを使用した）ターミナルサーバー2008ファームがあります。私が抱えている問題は、セッションブローカーがログイン中にユーザーを別のサーバーに切り替えると、20〜30秒の遅延が発生することです。これは、セキュリティ層をSSLではなくRDPに強制しているという事実に関連していると思います。
代替テキストhttp://www.lytzen.name/blogimages/tsstructure.png

背景
ゲートウェイサーバーには、パブリックルーティング可能なIPアドレスとDNS名があるため、インターネットからアクセスでき、すべてのユーザーがこのルートを介してアクセスします（システムは、外部の顧客にホストされたアプリケーションへのアクセスを提供するために使用されます）。実際のターミナルサーバーには、内部IPアドレスしかありません。これは、VistaまたはWindows 7クライアントの場合、リモートデスクトップクライアントがサーバーとネゴシエートしてセキュリティレイヤーにSSLを使用することを除いて、非常にうまく機能します。これにより、TS1またはTS2が持つ自動生成された証明書が公開されますが、これらは内部の自動生成された証明書であるため、クライアントは証明書が無効であるという厳しい警告を受け取ります。サーバーにはパブリックルーティング可能なIPアドレスまたはDNS名がないため、サーバーに適切に承認された証明書を与えることができません。代わりに、グループポリシーを使用して、SSLではなくRDPを介して接続を強制します。

\Computer Configuration\Policies\Administrative Templates\Windows Components\Terminal Services\Terminal Server\Security\Require use of specific security layer for remote (RDP) connections

Windows 7ユーザーは、私が住むことができる「サーバーのIDを確認できません」という厳しい警告を受け取ることが少なくなりました。
エンドユーザーのマシンを十分に制御して、新しいルート証明書をインストールするように依頼することもできません。

TS1とTS2も、ゲートウェイサーバーにインストールされているSessionBrokerを使用して負荷分散されます。ラウンドロビンDNSを使用しているため、ユーザーの初期接続はGateway1を介してTS1またはTS2のいずれかになります。その後、TS1/TS2はセッションブローカーと通信し、ユーザーを他のサーバーに渡すことができます。つまりユーザーはTS2に接続できますが、セッションブローカーと通信した後、ユーザーはTS1に渡され、そこでセッションが実行されます。

このサーバーの切り替えが発生すると、私のセットアップでは、画面に「ようこそ」という単語が20〜30秒間表示された後、点滅します。「ようこそ」が再び表示され、通常のログイン画面で点滅します（つまり、「ユーザープロファイルマネージャーを待つ」 "など）。調査を行った結果、ユーザーがTS1に渡される前に（「ようこそ」が表示されている間）TS2に完全にログオンし、そこで再度ログインしていることが起こっていると思います。通常、「ようこそ」という言葉を見ると、左の小さな円が回転しますが、この遅延の間は回転せず、画面がフリーズしているように見えます。

このブログ投稿これは、CredSSPが使用されていないため、おそらくSSLを禁止してRDPを強制しているためだと思います。

私が試したこと

「ようこそ」の遅延を取り除くSSLを再度有効にしました。ただし、プロセスのかなり早い段階で新しい遅延が発生するようです。具体的には、RDPクライアントが「接続の初期化」と言っている場合、これは非常に遅くなります。私の証明書の問題が、かなりの困難なしにそのソリューションを使用することを妨げているという事実とは別に。
負荷分散を無効にしてみました（セッションブローカーファームからサーバーを削除するだけです）。接続に遅延はありません。
問題は、それがのみユーザーがあるサーバーから別のサーバーにぶつかったときに発生します。 TS1に直接接続して（もちろんゲートウェイ経由で）、どのサーバーに接続するかを確認して、これをテストしました。 実際に 接続されました。
念のため、ラウンドロビンDNSもバイパスして、影響があるかどうかを確認しました。セットアップは、基本的にここでのMSの推奨事項に沿っています。 TS Session Brokerロードバランシングステップバイステップガイド
専用のリダイレクタを使用するように変更してみました。基本的に、ラウンドロビンDNSを使用するのではなく、DNSをゲートウェイサーバーにポイントし、専用リダイレクタとして構成しました（ログオンを禁止し、ファームに追加します）。悲しいかな、同じ問題。

どんなアイデアや提案もありがたく受けました。

Frans · Accepted Answer

答えの並べ替え;

このセットアップを本番環境で実行し始めたとき、問題は軽減または解消されたように見えたため、ユーザーの負荷が小さい場合にのみ発生するようです。この種の意味があります。
RDPクライアント自体の[どこからでも接続]設定の[詳細設定]タブに、[ローカルアドレス用のRDゲートウェイサーバーをバイパスする]というわかりにくい小さなチェックボックスがあります。これはデフォルトでチェックされています。さて、私のセットアップでは、接続を試みるサーバー名として「ホスティング」を入力しただけなので、RDPクライアントはそのサーバーをローカルで見つけようとしますbeforeゲートウェイサーバーを介して接続しようとすると、長い遅延。そのボックスのチェックを外すだけで、少なくとも実際にゲートウェイサーバーに接続する少し前に、接続がはるかに高速になりました。

gisman · Answer

外部からゲートウェイへのrdwebにアクセスするには、外部DNSが登録された証明書と内部フレンドリ名を使用します。これにより、ファーム内のゲートウェイサーバーとターミナルサーバーの両方で使用できます。私のシナリオでは、rdwebがゲートウェイに外部アドレスを登録しています。次に、接続ブローカーを指します。内部アクセスは、内部的に登録されたDNSエイリアスxyzrdwebを介して行われます。これは、ファーム内の両方のターミナルサーバーに登録されます。事実上、xyzrdwebを使用すると、dnsを介して最初に取得されたレコードが返されます。内部ユーザーはゲートウェイをバイパスします。残念ながら、このシナリオの外部ユーザーは、完全に認証されるまでに最大1分半の初期接続が遅くなりますが、完全に認証されると、アプリケーションは瞬時に実行され、AdobePhotoshopなどのアプリの起動には約3〜4秒かかります。

J&#248;rgen Fundingsrud · Answer

別の種類の答えに少し遅れるかもしれませんが、とにかくここに投げ込みます。また、セットアップにもう1つの落とし穴があります。

まったく同じ問題が発生し、4つのサーバーすべて（rdgw、ts01、ts02、およびrdbroker）でログのブレッドクラムを追跡しました。また、すべてのサーバーで自己発行の証明書を使用していますが、RDGWと厳しい警告は、実際には、ログを確認する以外に遅延がどこにあるかを推定する手段を提供します。私のシナリオは、リダイレクトのイベントに大幅な遅延があるという元のポスターです。証明書promtsは、クライアントが最初のTS /リダイレクターにすばやく接続されていることを示しています。これがセッションが存在するTSである場合、すべてOKです。クライアントがリダイレクトされた場合、正しいTSへの接続には正確に23秒かかります。毎回！

ステップ6のMicrosoft（ http://technet.Microsoft.com/en-us/library/cc772418%28WS.10%29.aspx ）からのステップバイステップの説明を見て、初期接続TSクライアントにリダイレクトコマンドを発行し、正しいTSのIPアドレスを提供します。ここに私が見ている問題があります。 RDGWを介した最初の接続は、最初のTS /リダイレクタの内部FQDNを使用して行われます。リダイレクトされた接続は、FQDNではなく正しいTSの内部IPアドレスを使用して行われます。最初のTS /リダイレクタの内部IPアドレスを使用することで、この遅延を実際に再現できます。または、私のドメインと子ドメイン内の他のスタンドアロンTS。その場合、最初の接続でも23秒の遅延が発生します。

この問題についての私の見解は

リダイレクトはFQDNではなくIPアドレスによって行われます
RDGWまたはクライアントの実装にIPアドレスを使用した遅延の問題があります
落とし穴：Windows 8.1（6.3.9600）のRDPクライアントは、リダイレクトされたサーバーにまったく接続できません。ユーザーセッションが存在するTSではログオンイベントはログに記録されません。 RDPクライアントは、接続しようとすると永遠にハングします。タイムアウトすらしません。

編集;しかし、ええ、「ローカルアドレス用のRDゲートウェイサーバーをバイパスする」でうまくいきました。返されるIPアドレスは、私のクライアントのどのローカルサブネットにも近くないので、ちょっとばかげています。幸い、クライアント用のスクリプトを使用してRDPファイルを生成しているので、この問題をかなり簡単に回避できます。

joeqwerty · Answer

基本的に、互いに競合する2つの負荷分散メカニズムがあります。あなたは私がそれが起こっているのを見るのとまったく同じように問題を説明しました。 DNSラウンドロビンは着信接続を一方のサーバーに送信し、次にセッションブローカーがそれをもう一方のサーバーに送信してセッションの確立を遅らせます。

私の提案は、DNSラウンドロビンまたはセッションブローカーを使用することですが、両方を使用することはできません。

個人的には、SessionBrokerを使用します。 Session Brokerサーバーを指す単一のパブリックDNSレコードを作成し、TS1とTS2の間の着信接続の負荷分散を処理できるようにします。