-
Notifications
You must be signed in to change notification settings - Fork 0
MS_RDConnectionBroker
- 戻る（リモートデスクトップサービス（旧ターミナルサービス））
- リモート デスクトップ ライセンス
- リモート デスクトップ ゲートウェイ
- リモート デスクトップ 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, 仮想化
このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。