EnglishFrançaisDeutschEspañolItaliano日本語한국어NederlandsPortuguês (Brasil)中文 (简体)中文 (繁體, 台灣)
Skip to main content

2026 年 9 月 1 日

Horizon Service Universal Broker の概要

この記事では、Horizon 制御プレーン サービスの 1 つである Universal Broker について簡単に説明します。Universal Broker はクラウドベースのサービスであり、実行中のインフラストラクチャに関係なく、複数のポッドのデプロイにまたがるリソースの仲介を可能にします。また、このサービスは、ユーザーとポッドの地理的サイトに基づいてインテリジェントな仲介の決定を行います。

Universal Broker の概要

Omnissa の第 1 世代のクラウドベースの仲介テクノロジーである Universal Broker は、テナントに次の 1 つ以上がある場合に使用できます。

  • Horizon ポッド - Horizon Connection Server テクノロジーに基づくポッド
  • Horizon Cloud on Microsoft Azure ポッド、およびこれらすべてのポッドがポッド マニフェスト 2298.0 以降を実行している。

Universal Broker ソリューションのシステム コンポーネントがどのように連携して割り当てへのユーザーの接続要求を管理するかの詳細については、 Universal Broker のシステム アーキテクチャとコンポーネントを参照してください。

Universal Broker システム アーキテクチャの概要図

主な機能

Universal Broker は、次の主要な機能を提供します。

  • すべてのリモート リソースに対する単一の接続 FQDN

    エンド ユーザーは、Universal Broker 構成設定で定義した完全修飾ドメイン名 (FQDN) に接続することで、環境内のマルチクラウド割り当てにアクセスできます。単一の Universal Broker FQDN を介して、ユーザーは環境内の任意のサイトにある任意の参加ポッドから割り当てにアクセスできます。ポッド間に内部ネットワークは必要ありません。

    Universal Broker の単一の FQDN 接続の図

  • 最適なパフォーマンスのためのグローバルなポッド接続と認識

    Universal Broker は、マルチクラウド割り当てに参加しているすべてのポッドとの直接接続を維持し、各ポッドの可用性ステータスを常に認識します。その結果、Universal Broker はエンド ユーザーの接続要求を管理し、これらのポッドから直接仮想リソースにルーティングできます。パフォーマンスの低下や遅延の問題の原因となるグローバル サーバ ロード バランシング (GSLB) やポッド間のネットワーク通信は必要ありません。

  • スマート仲介

    Universal Broker は、地理的サイトとポッド トポロジの認識に基づいて、最短のネットワーク ルートに沿って割り当てからエンド ユーザーにリソースを仲介できます。

仲介およびエンドユーザーのデスクトップ プールとリモート アプリケーション

割り当ては、Horizon Universal Console の概念的なエンティティです。コンソールを使用した割り当てとは、エンド ユーザーの仮想デスクトップとリモート アプリケーションのプールを定義し、それらの使用資格をエンド ユーザーに付与する方法です。たとえば、 コンソールで、VDI デスクトップの割り当てまたは RDSH リソースの割り当てを作成し、それらの割り当ての使用資格をエンド ユーザーに付与します。

Universal Broker は、資格のある割り当てへのクライアント ユーザーの接続要求を管理し、その要求を満たす適切なリソースへの接続セッションをネゴシエートします。Universal Broker は、地理的な場所とポッド トポロジを認識します。この情報を使用して、Universal Broker は、サイトの構成とリソースの可用性に基づいて、ユーザーの接続要求を満たすのに最適なリソースを検索します。

ポッド タイプごとに使用可能な割り当てタイプのリストについては、次のセクションを参照してください。

Microsoft Azure にデプロイされた Horizon Cloud ポッドのリソースを使用したエンド ユーザー割り当て

ポッド フリート内の Horizon Cloud ポッドの Universal Broker 構成が完了すると、次の割り当てタイプが可能になります。

クラウド接続された Horizon ポッドからのリソースを使用したエンド ユーザーの割り当て

ポッド フリート内の Horizon ポッドの Universal Broker 構成が完了すると、次の割り当てタイプが可能になります。

メモ

ほとんどのソフトウェアと同様に、現在のリリースにはいくつかの機能に関する考慮事項と既知の制限があります。詳細については、 Universal Broker - 機能の考慮事項と既知の制限を参照してください。

Universal Broker のシステム アーキテクチャとコンポーネント

この記事では、参加しているポッド内および Horizon Cloud 制御プレーンで実行される Universal Broker のシステム コンポーネントについて詳しく説明します。Universal Broker は、第 1 世代の Horizon Cloud デプロイでのエンド ユーザー割り当てに推奨されるコネクション ブローカです。

Universal Broker の主な機能の概要については、 Horizon Service Universal Broker の概要を参照してください。

Universal Broker ソリューションのシステム アーキテクチャは、仲介されたリソースの配置先が Horizon ポッド(Horizon Connection Server テクノロジー ベース)か Microsoft Azure の Horizon Cloud ポッドかによって若干異なります。

Horizon ポッドの Universal Broker のシステム アーキテクチャ

次のコンポーネントは、Horizon ポッド(Horizon Connection Server テクノロジー ベース)からのマルチクラウド割り当てのクラウドベースの仲介のための Universal Broker ソリューションを構成しています。

  • Universal Broker サービスは、Horizon Cloud に接続されている Universal Broker クラウド内で実行されるマルチテナント クラウド サービスです。各顧客は、 Universal Broker 設定の構成の説明に従って構成された一意の専用 FQDN を使用して Universal Broker サービスに接続します。
  • Universal Broker クライアントは、クラウド接続された各 Horizon Cloud ポッドの Horizon Cloud Connector 内で実行されます。このコネクタのバージョン 1.5 以降では、Universal Broker クライアントはそのコネクタの一部であり、Horizon Cloud Connector をポッドとペアリングすると自動的にインストールされます。
  • Universal Broker プラグインは、マルチクラウド割り当てに参加するすべてのクラウド接続ポッドの Horizon Connection Server 内で実行されます。Horizon ポッド - Connection Server への Universal Broker プラグインのインストールの説明に従って、参加しているポッド内の各 Connection Server インスタンスにプラグインをダウンロードしてインストールする必要があります。

次の図は、Universal Broker が Horizon ポッド環境のコンポーネントと連携して、外部エンド ユーザーから割り当て内のリモート リソースへの接続要求をどのように管理するかを示しています。

メモ: 次に示すシナリオには、企業ネットワーク外の外部ネットワークに配置された Horizon Client が含まれ、ポッドに外部 Unified Access Gateway が構成されています。

Horizon ポッドの Universal Broker のシステム アーキテクチャ

  1. Horizon Client から、エンド ユーザーは仲介の FQDN を介して Universal Broker サービスに接続することにより、仮想デスクトップを要求します。サービスは、XML-API プロトコルを使用して Horizon Client ユーザーを認証し、接続セッションを管理します。
  2. サイト 1 のポッド 1 がデスクトップの最適なソースであると判断した後、Universal Broker サービスは、ポッド 1 とペアリングされた Horizon Cloud Connector で実行されている Universal Broker クライアントにメッセージを送信します。
  3. Universal Broker クライアントは、ポッド 1 内の各 Connection Server インスタンスで実行される Universal Broker プラグインにメッセージを転送します。
  4. Universal Broker プラグインは、エンド ユーザーの要求を満たすために使用できる最適なデスクトップを識別します。
  5. Universal Broker サービスは、ポッド 1 の一意の FQDN(通常はポッド 1 ロード バランサの FQDN)を含む応答を Horizon Client に返します。Horizon Client は、ロード バランサとの接続を確立して、デスクトップとのプロトコル セッションを要求します。
  6. ローカル ロード バランサを通過した後、要求はポッド 1 の Unified Access Gateway に送信されます。Unified Access Gateway は、要求が信頼されていることを検証し、Blast Secure Gateway、PCoIP Secure Gateway、およびトンネル サーバを準備します。
  7. Horizon Client ユーザーは指定されたデスクトップを受信し、構成されたセカンダリ プロトコル(Blast Extreme、PCoIP、または RDP)に基づいてセッションを確立します。

Universal Broker 通信に使用されるポートの詳細については、 Horizon ポッド - Universal Broker の DNS、ポート、およびプロトコルの要件を参照してください。

Microsoft Azure の Horizon Cloud ポッドに対する Universal Broker のシステム アーキテクチャ

次のコンポーネントは、Microsoft Azure の Horizon Cloud ポッドからの VDI および RDSH 割り当てのクラウドベースの仲介のための Universal Broker ソリューションを構成しています。

  • Universal Broker サービスは、Horizon Cloud に接続されている Universal Broker クラウド内で実行されるマルチテナント クラウド サービスです。各顧客は、 Universal Broker 設定の構成の説明に従って構成された一意の専用 FQDN を使用して Universal Broker サービスに接続します。
  • Universal Broker クライアントは、Microsoft Azure に参加している各 Horizon Cloud ポッド内で実行されます。

メモ: 次に示すシナリオには、企業ネットワーク外の外部ネットワークに配置された Horizon Client が含まれ、ポッドに外部 Unified Access Gateway が構成されています。

Microsoft Azure の Horizon Cloud ポッドに対する Universal Broker のシステム アーキテクチャ

  1. Horizon Client から、エンド ユーザーは仲介の FQDN を介して Universal Broker サービスに接続することにより、仮想リソースを要求します。サービスは、XML-API プロトコルを使用して Horizon Client ユーザーを認証し、接続セッションを管理します。
  2. サイト 1 のポッド 1 にユーザーの要求に最適なリソースがあると判断した後、Universal Broker サービスはポッド 1 内で実行されている Universal Broker クライアントにメッセージを送信します。
  3. Universal Broker クライアントは、ポッド 1 内のアクティブなポッド マネージャにメッセージを転送します。
  4. アクティブなポッド マネージャは、エンド ユーザーの要求を満たすために使用できる最適なリソースを識別します。
  5. Universal Broker サービスは、ポッド 1 の一意の FQDN(通常はポッド 1 の Microsoft Azure ロード バランサの FQDN)を含む応答を Horizon Client に返します。Horizon Client はロード バランサとの接続を確立して、リソースとのプロトコル セッションを要求します。
  6. Microsoft Azure ロード バランサを通過した後、要求はポッド 1 の Unified Access Gateway に送信されます。Unified Access Gateway は、要求が信頼されていることを検証し、Blast Secure Gateway、PCoIP Secure Gateway、およびトンネル サーバを準備します。
  7. Horizon Client ユーザーは指定されたリソースを受信し、構成されたセカンダリ プロトコル(Blast Extreme、PCoIP、または RDP)に基づいてセッションを確立します。

Universal Broker 通信に使用されるポートの詳細については、 Horizon Cloud ポッドのポートとプロトコルの要件の「Universal Broker で必要なポートとプロトコル」セクションを参照してください。

Universal Broker - 機能に関する考慮事項と既知の制限

このドキュメント ページでは、Universal Broker に関連する機能に関する考慮事項の一部と、サポートが制限されている、またはサポートされていない Horizon 機能のリストを提供します。

機能に関する考慮事項

  • Horizon ポッドと Horizon Cloud ポッドの両方を含むポッド フリートでは、作成する各エンド ユーザー割り当ては、1 つのポッド タイプからの VDI デスクトップのみで構成する必要があります。たとえば、複数の Horizon ポッドにわたるデスクトップで構成される割り当てと、複数の Horizon Cloud ポッドにわたるデスクトップで構成される割り当てのいずれかを作成できます。ただし、Horizon ポッドと Horizon Cloud ポッドの両方にわたるデスクトップで構成される割り当てを作成することはできません。
  • テナントをシングルポッド ブローカ構成から Universal Broker に移行した場合は、追加の考慮事項が適用されます。Universal Broker への移行後のテナント環境の新機能を参照してください。

VDI マルチクラウド割り当てあたりのポッドの最大数の制限

VDI マルチクラウド割り当てでサポートされるポッドの最大数は 5 です。この制限は、Horizon Connection Server タイプのポッドと Horizon Cloud on Microsoft Azure タイプのポッドの両方に適用されます。5 つ以上使用すると、Universal Broker の同時負荷が増加します。同時負荷が増大すると、エンド ユーザーがクライアントで割り当ての表示タイルをクリックして、サービスがそのユーザーを仮想デスクトップにログインさせようとしたときに、エラーが発生する可能性があります。

仮想リソース

仮想リソースの仲介の場合、このリリースの Universal Broker は Windows オペレーティング システムのみをサポートします。Linux ベースのデスクトップはサポートされていません。

このリリースでは、管理者が作成したデスクトップおよびアプリケーションへのショートカットはサポートされていません。

メモ: 特定のユーザーは、Universal Broker によって仲介された専用割り当てから最大で 1 つの割り当てられたデスクトップを受信できます。割り当てに複数のポッドのデスクトップが含まれていてもかまいません。

Horizon Web Client と Horizon Client for Chrome

エンド ユーザーは、サポート対象の Web ブラウザで Horizon Web Client を実行するか、Horizon Client for Chrome 5.4 以降を実行することで、Universal Broker サービスにリソースを要求できます。Universal Broker サービスが自己署名証明書を使用する Unified Access Gateway インスタンスに要求をリダイレクトすると、クライアント アプリケーションは認証局が無効であることを示すエラー メッセージを表示します。

この動作は設計によるものです。要求されたリソースに接続するために、ユーザーは証明書のエラー メッセージのプロンプトに従って自己署名証明書を受け入れることができます。

認証

このリリースの Universal Broker は、UPN および NETBIOS 形式の Windows ユーザー名とパスワードによるクライアント ユーザー認証をサポートします。

次のリストに示すように、テナントのポッド フリートの現在の状態に応じて、RADIUS または RSA を介した 2 要素認証もサポートされます。

また、クライアントで Universal Broker を使用し、2 要素認証が構成されている場合のエンドユーザー エクスペリエンスについて説明している次のセクションも確認してください。現在の動作は、ポッドのゲートウェイ FQDN を直接使用する場合の動作とは異なります。

  • Horizon ポッドのみ

    RADIUS 認証と RSA SecurID 認証の両方がサポートされます。

  • Horizon Cloud on Microsoft Azure のデプロイのみ

    すべてのポッドがマニフェスト 3139.x 以降で、ポッドで [ポッドの編集] ウィザードを実行するときに RSA SecurID と RADIUS の両方のオプションが選択対象として表示される場合は、RSA SecurID と RADIUS の両方の認証がサポートされます。それ以外の場合は、RADIUS タイプのみがサポートされます。

  • Horizon ポッドと Horizon Cloud on Microsoft Azure デプロイの混在

    混合フリートでサポートされる認証タイプは、Horizon Cloud on Microsoft Azure のデプロイが RSA SecurID オプションを構成するための条件を満たしているかどうかによって異なります。

    • Horizon Cloud on Microsoft Azure 環境がこれらの条件を満たしていない場合は、RADIUS 認証のみがサポートされます。
    • Horizon Cloud on Microsoft Azure のデプロイがこれらの条件を満たしている場合、RADIUS 認証と RSA SecurID 認証の両方がサポートされます。 満たすべき条件は、ポッドがマニフェスト 3139.x 以降を実行しており、ポッドで [ポッドの編集] ウィザードを開くと、RSA SecurID オプションと RADIUS オプションの両方が選択可能になっていることです。

2 要素認証が構成されている場合

2 要素認証が含まれる場合、エンド ユーザーは、ポッドのゲートウェイ FQDN を直接使用する場合とは少し異なる Universal Broker FQDN を使用するときに、1 つの認証フローを経験します。

  • Universal Broker 認証フローでは、エンド ユーザーは Windows Active Directory (AD) 認証情報を 2 回入力するように求められます。1 回目は Universal Broker FQDN に最初に接続するとき、もう 1 回は構成された RADIUS または RSA SecurID システムで 2 要素認証が正常に完了した後です。
  • ポッドのゲートウェイ認証フローを使用する場合、エンド ユーザーは、最初にポッドのゲートウェイ FQDN に接続するときに、Windows Active Directory (AD) 認証情報を一度入力するように求められます。

メモ: Universal Broker の使用時に 2 つの Active Directory プロンプトが表示されないようにするには、Access と統合し、Access で 2 要素認証を構成することを検討してください。

現在サポートされていないユーザー認証およびアクセス方法

次のユーザー認証およびアクセス方法は、現在サポートされていません。

  • スマート カード
  • 証明書
  • SAML 認証(Omnissa Access との統合外)
  • 現在のユーザーとしてログイン
  • 匿名アクセス

サポート対象外のアイテムの 1 つがサポートの対象となる場合、そのエントリは上記のリストから削除され、サポートの発表は「 既存のクラウド接続ポッドを使用している現在のユーザー向け - Horizon Cloud リリースについて」というタイトルのページに記載されます。このページでは、サポートが追加されたリリースに対応するセクションにステートメントが表示されます。

リモート デスクトップ機能

次の機能は、このリリースの Universal Broker ではサポートされていません。

  • URL リダイレクト
  • セッション共同作業

その他の機能

次の機能も、このリリースの Universal Broker ではサポートされていません。

  • キオスク モード
  • タイミング プロファイル(ユーザー セッションのトラブルシューティング用)
  • OPSWAT ベースのエンドポイント コンプライアンス チェック

このページは役に立ちましたか?

このトピックについてフィードバックを送信

このトピックは役に立ちましたか?

個人情報や機密情報は入力しないでください。

リンクを生成しています…