• 戻る（リモートデスクトップサービス（旧ターミナルサービス））
  • リモート デスクトップ ライセンス
  • リモート デスクトップ ゲートウェイ
  • リモート デスクトップ Webアクセス
  • リモート デスクトップ接続ブローカー

• ログオフせずに「RD接続」を切断しただけのセッションは、
  一時停止されているだけであり、セッションのステートをサーバに保持している。
• このため、同一のユーザ アカウントで再度「RD 接続」することで、
  当該セッションの作業を続行することも可能である。

• 最もセッション数の少ない「RDセッション ホスト」に、
  「RD 接続」をリダイレクトするという負荷分散機能も有している
  （ただし、一般的な負荷分散機能が有しているサーバ ファーム
  中のノードの死活監視機能は有していないので、注意が必要）。
• リダイレクト先の決定は「RD セッション ホスト」の「重み」付けによって変更できる。
• また、「RD 接続ブローカ データベース」に「RD セッション ホスト」ファームに
  「RD 接続」した際に生成されたセッションの一覧が保持されており、負荷分散機能と組合せた場合、
  新しいセッションを開始させずに、「RD セッション ホスト」ファームの前回のセッションに再接続することが可能。

補足（接続ブローカーが「ただの負荷分散」ではない理由）: RDS の負荷分散が
Web サーバの負荷分散と決定的に違うのは、
セッションが特定のサーバに固定されている点にある。

【Web サーバの負荷分散】ステートレス
  要求1 → サーバA
  要求2 → サーバB    ← どこへ行ってもよい

【RDS の負荷分散】ステートフル
  初回接続 → サーバA でログオン、アプリを起動、作業中…
  切断
  再接続  → 【必ずサーバA に戻さなければならない】
             ↑ サーバB へ行くと、作業内容が消えたように見える

つまり、接続ブローカーは

機能	目的
負荷分散	新規セッションを空いているホストへ
セッションの再接続（reconnection）	切断済みセッションを持つホストへ確実に戻す

の2 つを同時に行う必要がある。
そして後者の方が重要である。
単純なラウンドロビン DNS だけでは

• 再接続時に別のホストに飛ばされ、
• 「作業していたアプリが消えた」（実際には元のホストで生きている）

という事故が起きる。
これが「接続ブローカーが必須」とされる理由である。

なお、本文が注意している
**「ノードの死活監視機能は有していない」**という指摘は重要で、
落ちたホストにも接続を振ってしまう可能性がある。
現在は接続ブローカーの高可用性構成
（複数台＋SQL Server による構成データベースの共有）と、
ホスト側の「新しい接続を許可しない」（ドレイン モード）を
組み合わせて運用する。

（記載なし）

• 「RD 接続ブローカ」にアクセス許可を設定
• 「RDセッション ホスト」をファームに参加させる。

補足（ラウンドロビン DNS の役割）: 接続ブローカーがあるのに
なぜ DNS の設定も要るのか、という点が分かりにくい。
接続の流れを追うと理解できる。

① クライアントが「farm.example.jp」に接続
      ↓ ラウンドロビン DNS が「とりあえずどれか」を返す
② セッション ホストA に接続（初期接続先）
      ↓ ホストA が接続ブローカーに問い合わせる
③ 接続ブローカー「この人は前回ホストB にいた」「または今はB が空いている」
      ↓ ホストA がクライアントをホストB にリダイレクト
④ ホストB に接続（最終的な接続先）

つまり、

役割	担当
最初の入口を分散する	ラウンドロビン DNS（どこでもよい）
正しいホストへ振り直す	接続ブローカー

という二段構えになっている。
ラウンドロビン DNS は負荷分散のためというより、
単一障害点を作らないための入口として機能している。

現在の Windows Server では、この初期接続の分散に
NLB や ハードウェア ロード バランサを使う構成も一般的である
（DNS より切り替えが速い）。

［RDゲートウェイ］についてはリモート デスクトップ ゲートウェイを参照。

補足（「ユーザ ログオン モード」がローリング アップグレードの鍵）: 見出しだけで
本文が無いため、要点を補っておく。

各セッション ホストにはログオン モードという設定があり、
これを使ってサービスを止めずに 1 台ずつ更新できる。

モード	新規接続	既存セッションへの再接続
許可する	○	○
許可しない（ドレイン）	✕	○
再接続も許可しない	✕	✕

中央のドレイン モードが要点で、

① ホストA をドレイン モードにする
     → 新規ユーザは B, C へ流れる
     → A で作業中の人はそのまま継続でき、再接続もできる
② A のセッションが自然にゼロになるのを待つ（または業務時間外に強制ログオフ）
③ A を更新して再起動
④ A を通常モードに戻し、B へ… と繰り返す

という手順になる。
利用者を追い出さずに更新できる点が価値であり、
クラウドで言えば
Azureの高可用性設計の
「更新ドメイン」に相当する考え方である。

移行メモ: 「インストール」および上記のうち
「RDセッション ホスト ファームへの RD 接続の確認」「RDゲートウェイ経由での確認」
「RemoteApp 設定の複製」「グループ・ポリシーを使用した設定」の各項は、
原典でも見出しのみで本文が存在しない。

---

Tags: 移行, Windows, 仮想化