Dieser Artikel bietet eine kurze Einführung in den Universal Broker, einen der Dienste der Horizon-Steuerungsebene. Der Universal Broker ist ein cloudbasierter Dienst, der die Vermittlung von Ressourcen ermöglicht, die sich über mehrere Pod-Bereitstellungen erstrecken, unabhängig von der Infrastruktur, auf der sie ausgeführt werden. Der Dienst trifft auch intelligente Brokering-Entscheidungen basierend auf den geografischen Standorten der Benutzer und Pods.

Übersicht über Universal Broker

Universal Broker, die neueste cloudbasierte Brokering-Technologie von VMware, kann verwendet werden, wenn Ihr Mandant über mindestens eine der folgenden Komponenten verfügt:

  • Horizon Pods – Pods, die auf der Horizon Connection Server-Technologie basieren
  • Horizon Cloud on Microsoft Azure-Pods und auf all diesen Pods wird das Pod-Manifest 2298.0 oder höher ausgeführt.

Detaillierte Informationen dazu, wie die Systemkomponenten der Universal Broker-Lösung zum Verwalten von Benutzerverbindungsanfragen an Zuweisungen zusammenarbeiten, finden Sie unter Systemarchitektur und Komponenten von Universal Broker.


Allgemeines Diagramm der Universal Broker-Systemarchitektur

Wichtige Funktionen

Universal Broker bietet die folgenden wichtigen Funktionen:

  • Einzelner Verbindungs-FQDN für alle Remoteressourcen

    Endbenutzer können auf Multi-Cloud-Zuweisungen in Ihrer Umgebung zugreifen, indem sie eine Verbindung mit einem vollqualifizierten Domänennamen (FQDN) herstellen, den (bzw. die) Sie in den Konfigurationseinstellungen für Universal Broker definieren. Über den einzelnen Universal Broker-FQDN können Benutzer auf Zuweisungen aus allen teilnehmenden Pods auf jeder Site in Ihrer Umgebung zugreifen. Es ist keine interne Vernetzung zwischen Ihren Pods erforderlich.


    Diagramm einer einzelnen FQDN-Verbindung für Horizon Universal Broker
  • Globale Pod-Konnektivität und Informationen für eine optimale Leistung

    Universal Broker behält die direkte Konnektivität für jeden Pod bei, der an Multi-Cloud-Zuweisungen teilnimmt, und bleibt bezüglich des Verfügbarkeitsstatus der einzelnen Pods auf dem Laufenden. Folglich kann Universal Broker Verbindungsanfragen von Endbenutzern verwalten und direkt über diese Pods an virtuelle Ressourcen weiterleiten. Es besteht keine Notwendigkeit für einen globalen Serverlastausgleich (GSLB) oder eine podübergreifende Netzwerkkommunikation, die zu Leistungseinbußen und Latenzproblemen führen kann.

  • Intelligentes Brokering

    Universal Broker kann Ressourcen aus Zuweisungen entlang der kürzesten Netzwerkroute an Endbenutzer vermitteln, basierend auf der Kenntnis Ihrer geografischen Standorte und Pod-Topologie.

Brokering und Endbenutzer-Desktop-Pools und Remoteanwendungen

Zuweisungen sind konzeptionelle Einheiten in der Horizon Universal Console. Mithilfe der -Konsole definieren Sie mithilfe von Zuweisungen Pools von virtuellen Endbenutzer-Desktops und Remoteanwendungen und sie Ihren Endbenutzern zuweisen. In der Konsole erstellen Sie beispielsweise Zuweisungen von VDI-Desktops oder Zuweisungen von RDSH-Ressourcen und erteilen dann Ihren Endbenutzern Berechtigungen für diese Zuweisungen.

Der Universal Broker verwaltet die Verbindungsanforderung eines Clientbenutzers mit einer Zuweisung und handelt eine Verbindungssitzung mit einer geeigneten Ressource aus, die diese Anforderung erfüllt. Der Universal Broker kennt die geografische Lokalität und die Pod-Topologie. Anhand dieser Informationen sucht Universal Broker nach den besten Ressourcen, um die Verbindungsanforderungen der Benutzer basierend auf der Site-Konfiguration und Ressourcenverfügbarkeit zu erfüllen.

In den folgenden Abschnitten finden Sie eine Liste der verfügbaren Zuweisungstypen nach Pod-Typ.

Endbenutzerzuweisungen, mit Ressourcen aus Horizon Cloud-Pods, die in Microsoft Azure bereitgestellt wurden

Wenn die Universal Broker-Konfiguration für die Horizon Cloud-Pods in Ihrer Pod-Flotte abgeschlossen ist, sind diese Zuweisungstypen möglich:

Endbenutzerzuweisungen mit Ressourcen aus cloudverbundenen Horizon-Pods

Wenn die Universal Broker-Konfiguration für die Horizon-Pods in Ihrer Pod-Flotte abgeschlossen ist, sind diese Zuweisungstypen möglich:

Hinweise

Wie bei fast jeder Software gibt es auch bei der aktuellen Version einige Überlegungen zu den Funktionen und bekannten Einschränkungen. Weitere Informationen finden Sie unter Universal Broker – Überlegungen zu Funktionen und bekannte Einschränkungen.

Systemarchitektur und Komponenten von Universal Broker

Dieser Artikel bietet eine detaillierte Darstellung der Systemkomponenten von Universal Broker, die innerhalb der teilnehmenden Pods und auf der Horizon Cloud-Steuerungsebene ausgeführt werden. Universal Broker ist die neueste cloudbasierte Brokering-Technologie von VMware und der empfohlene Verbindungs-Broker für Endbenutzerzuweisungen in neuen Bereitstellungen.

Eine Übersicht über die wichtigsten Funktionen von Universal Broker finden Sie unter Einführung in VMware Horizon Service Universal Broker.

Die Systemarchitektur der Universal Broker-Lösung unterscheidet sich geringfügig, je nachdem, ob die vermittelten Ressourcen in Horizon-Pods (basierend auf der Horizon Connection Server-Technologie) oder in Horizon Cloud-Pods in Microsoft Azure enthalten sind.

Systemarchitektur von Universal Broker für Horizon-Pods

Die folgenden Komponenten umfassen die Universal Broker-Lösung für das cloudbasierte Brokering von Multi-Cloud-Zuweisungen von Horizon-Pods (basierend auf der Horizon Connection Server-Technologie).

  • Der Universal Broker-Dienst ist ein Cloud-Dienst mit mehreren Mandanten, der in der Universal Broker-Cloud ausgeführt wird, die mit Horizon Cloud verbunden ist. Jeder Kunde stellt mithilfe eines eindeutigen, dedizierten FQDN, der wie unter Konfigurieren von Universal Broker-Einstellungen beschrieben konfiguriert ist, eine Verbindung mit dem Universal Broker-Dienst her.
  • Der Universal Broker-Client wird im Horizon Cloud Connector aller mit der Cloud verbundenen Horizon-Pods ausgeführt. Ab Version 1.5 dieses Connectors ist der Universal Broker-Client Teil dieses Connectors und wird automatisch installiert, wenn Sie den Horizon Cloud Connector mit Ihrem Pod koppeln.
  • Das Universal Broker-Plug-In wird im Horizon Connection Server für alle mit der Cloud verbundenen Pods ausgeführt, die an Multi-Cloud-Zuweisungen teilnehmen. Sie müssen das Plug-In auf jede Verbindungsserverinstanz in einem teilnehmenden Pod herunterladen und installieren, wie unter Horizon Pods – Installieren des Universal Broker-Plug-Ins auf dem Verbindungsserver beschrieben.

In folgendem Diagramm wird veranschaulicht, wie Universal Broker mit den Komponenten in Ihrer Horizon-Pod-Umgebung arbeitet, um Verbindungsanforderungen von Ihren externen Endbenutzern zu Remoteressourcen in einer Zuweisung zu verwalten.

Hinweis: Das dargestellte Szenario umfasst den Horizon Client, der sich in einem externen Netzwerk außerhalb Ihres Unternehmensnetzwerks befindet, wobei ein externes Unified Access Gateway auf dem Pod konfiguriert ist.

Systemarchitektur von Universal Broker für Horizon-Pods

  1. In Horizon Client fordert der Endbenutzer einen virtuellen Desktop an, indem er über den Brokering-FQDN eine Verbindung mit dem Universal Broker-Dienst herstellt. Der Dienst verwendet das XML-API-Protokoll, um den Horizon Client-Benutzer zu authentifizieren und die Verbindungssitzung zu verwalten.
  2. Nachdem ermittelt wurde, dass Pod 1 in Site 1 die beste verfügbare Quelle für den Desktop ist, sendet der Universal Broker-Dienst eine Meldung an den Universal Broker-Client, der auf dem mit Pod 1 gekoppelten Horizon Cloud Connector ausgeführt wird.
  3. Der Universal Broker-Client leitet die Nachricht an das Universal Broker-Plug-In weiter, das in jeder der Verbindungsserverinstanzen in Pod 1 ausgeführt wird.
  4. Das Universal Broker-Plug-In gibt den besten verfügbaren Desktop an, der die Anforderung des Endbenutzers erfüllt.
  5. Der Universal Broker-Dienst gibt eine Antwort an Horizon Client zurück, die den eindeutigen FQDN von Pod 1 (in der Regel der FQDN des Lastausgleichsdiensts von Pod 1) enthält. Horizon Client stellt eine Verbindung mit dem Lastausgleichsdienst her, um eine Protokollsitzung auf dem Desktop anzufordern.
  6. Nach dem Durchlaufen des lokalen Lastausgleichsdiensts wird die Anforderung an das Unified Access Gateway für Pod 1 übergeben. Das Unified Access Gateway überprüft, ob die Anforderung vertrauenswürdig ist, und bereitet Blast Secure Gateway, PCoIP Secure Gateway und den Tunnelserver vor.
  7. Der Horizon Client-Benutzer erhält den angegebenen Desktop und richtet eine Sitzung basierend auf dem konfigurierten sekundären Protokoll (Blast Extreme, PCoIP oder RDP) ein.

Weitere Informationen zu den für die Universal Broker-Kommunikation verwendeten Ports finden Sie unter Horizon-Pods – DNS-, Port- und Protokollanforderungen für Universal Broker.

Systemarchitektur von Universal Broker für Horizon Cloud-Pods in Microsoft Azure

Die folgenden Komponenten umfassen die Universal Broker-Lösung für das cloudbasierte Brokering von VDI- und RDSH-Zuweisungen von Horizon Cloud-Pods in Microsoft Azure.

  • Der Universal Broker-Dienst ist ein Cloud-Dienst mit mehreren Mandanten, der in der Universal Broker-Cloud ausgeführt wird, die mit Horizon Cloud verbunden ist. Jeder Kunde stellt mithilfe eines eindeutigen, dedizierten FQDN, der wie unter Konfigurieren von Universal Broker-Einstellungen beschrieben konfiguriert ist, eine Verbindung mit dem Universal Broker-Dienst her.
  • Der Universal Broker-Client wird in allen teilnehmenden Horizon Cloud-Pods in Microsoft Azure ausgeführt.
Hinweis: Das dargestellte Szenario umfasst den Horizon Client, der sich in einem externen Netzwerk außerhalb Ihres Unternehmensnetzwerks befindet, wobei ein externes Unified Access Gateway auf dem Pod konfiguriert ist.

Systemarchitektur von Universal Broker für Horizon Cloud-Pods in Microsoft Azure

  1. In Horizon Client fordert der Endbenutzer eine virtuelle Ressource an, indem er über den Brokering-FQDN eine Verbindung mit dem Universal Broker-Dienst herstellt. Der Dienst verwendet das XML-API-Protokoll, um den Horizon Client-Benutzer zu authentifizieren und die Verbindungssitzung zu verwalten.
  2. Nachdem ermittelt wurde, dass Pod 1 in Site 1 die beste verfügbare Ressource für die Anforderung des Benutzers ist, sendet der Universal Broker-Dienst eine Meldung an den Universal Broker-Client, der in Pod 1 ausgeführt wird.
  3. Der Universal Broker-Client leitet die Nachricht an den aktiven Pod Manager in Pod 1 weiter.
  4. Der aktive Pod-Manager gibt die beste verfügbare Ressource an, die die Anforderung des Endbenutzers erfüllt.
  5. Der Universal Broker-Dienst gibt eine Antwort an Horizon Client zurück, die den eindeutigen FQDN von Pod 1 (in der Regel der FQDN des Lastenausgleichsdienstes („Load Balancer“) von Microsoft Azure für Pod 1) enthält. Horizon Client stellt eine Verbindung mit dem Lastausgleichsdienst her, um eine Protokollsitzung mit der Ressource anzufordern.
  6. Nach dem Durchlaufen des Lastenausgleichsdienstes („Load Balancer“) von Microsoft Azure wird die Anforderung an das Unified Access Gateway für Pod 1 übergeben. Das Unified Access Gateway überprüft, ob die Anforderung vertrauenswürdig ist, und bereitet Blast Secure Gateway, PCoIP Secure Gateway und den Tunnelserver vor.
  7. Der Horizon Client-Benutzer erhält die angegebenen Ressource und richtet eine Sitzung basierend auf dem konfigurierten sekundären Protokoll (Blast Extreme, PCoIP oder RDP) ein.

Weitere Informationen zu den für die Universal Broker-Kommunikation verwendeten Ports finden Sie im Abschnitt „Für Universal Broker erforderliche Ports und Protokolle“ in Port- und Protokollanforderungen für einen Horizon Cloud-Pod mit der Manifestversion vom September 2019 oder höher.

Universal Broker – Überlegungen zu Funktionen und bekannte Einschränkungen

Diese Dokumentationsseite enthält einige Überlegungen zu Funktionen im Zusammenhang mit Universal Broker sowie eine Liste der Horizon-Funktionen, die eingeschränkt oder nicht unterstützt werden.

Überlegungen zu Funktionen

  • In einer Pod-Flotte, die sowohl Horizon-Pods als auch Horizon Cloud-Pods enthält, muss jede von Ihnen angelegte Endbenutzerzuweisung aus VDI-Desktops mit nur einem Pod-Typ bestehen. Beispielsweise können Sie eine Zuweisung bestehend aus Desktops erstellen, die mehrere Horizon-Pods umfassen. Alternativ können Sie eine Zuweisung bestehend aus Desktops erstellen, die sich über mehrere Horizon Cloud-Pods erstrecken. Sie können jedoch keine Zuweisung erstellen, die aus Desktops besteht, die sich über eine Kombination aus Horizon-Pods und Horizon Cloud-Pods erstrecken.
  • Zusätzliche Überlegungen gelten, wenn Sie Ihren Mandanten von einer Einzel-Pod-Broker-Konfiguration auf Universal Broker umgestellt haben. Siehe Was ist neu in Ihrer Mandantenumgebung nach dem Übergang zu Universal Broker?.

Maximale Anzahl von Pods pro VDI Multi-Cloud-Zuweisungsgrenze

Die unterstützte maximale Anzahl von Pods in einer VDI-Multi-Cloud-Zuweisung beträgt fünf (5). Diese Grenze gilt sowohl für Pods vom Typ Horizon Connection Server als auch für Pods vom Typ Horizon Cloud on Microsoft Azure. Verwendung von mehr als fünf Pods erhöht die gleichzeitige Last auf Universal Broker. Das Erhöhen dieser gleichzeitigen Last kann dazu führen, dass bei Endbenutzern Fehler auftreten, wenn sie auf die angezeigte Kachel der Zuweisung im Client klicken und der Dienst versucht, den Benutzer beim virtuellen Desktop anzumelden.

Virtuelle Ressourcen

Für das Brokering virtueller Ressourcen unterstützt diese Version von Universal Broker ausschließlich Windows-Betriebssysteme. Linux-basierte Desktops werden nicht unterstützt.

Diese Version unterstützt keine vom Administrator erstellten Verknüpfungen mit Desktops und Anwendungen.

Hinweis: Ein bestimmter Benutzer kann höchstens einen zugewiesenen Desktop aus einer dedizierten von Universal Broker vermittelten Zuweisung empfangen, auch wenn die Zuweisung Desktops aus mehreren Pods enthält.

Horizon HTML Access und Horizon Client für Chrome

Endbenutzer können mithilfe von Horizon HTML Access in einem unterstützten Webbrowser oder durch Ausführen von Horizon Client für Chrome 5.4 oder höher Anforderungen an die Ressourcen des Universal Broker-Diensts stellen. Wenn der Universal Broker-Dienst die Anforderung an eine Unified Access Gateway-Instanz umleitet, die ein selbstsigniertes Zertifikat verwendet, zeigt die Clientanwendung eine Fehlermeldung mit dem Hinweis an, dass die Zertifizierungsstelle ungültig ist.

Dieses Verhalten entspricht dem Konzept. Zum Herstellen einer Verbindung mit der angeforderten Ressource kann der Benutzer das selbstsignierte Zertifikat akzeptieren, indem er den Anweisungen in der Zertifikatsfehlermeldung folgt.

Authentifizierungsmethoden

Diese Version von Universal Broker unterstützt die Client-Benutzerauthentifizierung über den Windows-Benutzernamen und das zugehörige Kennwort im UPN- und NetBIOS-Format.

Die Zwei-Faktor-Authentifizierung über RADIUS oder RSA wird je nach aktuellem Status der Pod-Flotte des Mandanten wie in der folgenden Liste ebenfalls unterstützt.

Lesen Sie auch den folgenden Abschnitt, der das Verhalten der Endbenutzer beschreibt, wenn Universal Broker in ihren Clients verwendet wird und die Zwei-Faktor-Authentifizierung konfiguriert ist. Das aktuelle Verhalten unterscheidet sich von dem Verhalten, wenn die Gateway-FQDNs eines Pods direkt verwendet werden.

Nur Horizon-Pods
Sowohl RADIUS- als auch RSA SecurID-Authentifizierung werden unterstützt.
Nur Horizon Cloud on Microsoft Azure-Bereitstellungen
Wenn bei Ausführung des Assistenten „Pod bearbeiten“ auf den Pods alle Pods die Manifestversion 3139.x oder höher aufweisen und die Optionen RSA SecurID und RADIUS für die Auswahl sichtbar sind, werden sowohl RSA SecurID- als auch RADIUS-Authentifizierung unterstützt. Andernfalls wird nur der RADIUS-Typ unterstützt.
Mischung aus Horizon-Pods und Horizon Cloud on Microsoft Azure-Bereitstellungen
In einer gemischten Flotte hängen die unterstützten Authentifizierungstypen davon ab, ob Ihre Horizon Cloud on Microsoft Azure-Bereitstellungen die Bedingungen erfüllen, für die die RSA SecurID-Option konfiguriert ist:
  • Wenn Ihre Horizon Cloud on Microsoft Azure-Bereitstellungen diese Bedingungen nicht erfüllen, wird nur RADIUS-Authentifizierung unterstützt.
  • Wenn Ihre Horizon Cloud on Microsoft Azure-Bereitstellungen diese Bedingungen erfüllen, werden sowohl die RADIUS- als auch die RSA SecurID-Authentifizierung unterstützt.

Die zu erfüllenden Bedingungen sind die Pods, auf denen Manifest 3139.x oder höher ausgeführt wird. Wenn Sie den Assistenten „Pod bearbeiten“ auf den Pods öffnen, werden sowohl die Option „RSA SecurID“ als auch die Option „RADIUS“ zur Auswahl angezeigt.

Wenn die Zwei-Faktor-Authentifizierung konfiguriert ist

Bei der Zwei-Faktor-Authentifizierung durchlaufen Ihre Endbenutzer bei Verwendung des Universal Broker-FQDN einen Authentifizierungsablauf, der sich leicht von dem Ablauf bei direkter Verwendung des Gateway-FQDN eines Pods unterscheidet.

  • Im Universal Broker-Authentifizierungsablauf werden die Endbenutzer zweimal zur Eingabe ihrer Windows Active Directory (AD) Anmeldedaten aufgefordert: einmal bei der ersten Verbindung mit dem Universal Broker-FQDN und dann erneut nach erfolgreichem Abschluss der Zwei-Faktor-Authentifizierung mit dem konfigurierten RADIUS- oder RSA SecurID-System.
  • Bei Verwendung des Authentifizierungsablaufs des Gateways eines Pods werden die Endbenutzer aufgefordert, ihre Windows Active Directory (AD) Anmeldedaten einmal einzugeben, wenn sie zum ersten Mal eine Verbindung mit dem Gateway-FQDN des Pods herstellen.
Hinweis: Um die Anzeige von zwei AD-Eingabeaufforderungen bei Verwendung von Universal Broker zu vermeiden, sollten Sie die Integration in VMware Workspace ONE Access in Betracht ziehen und die Zwei-Faktor-Authentifizierung in VMware Workspace ONE Access konfigurieren.

Derzeit nicht unterstützte Benutzerauthentifizierungs- und Zugriffsmethoden

Die folgenden Benutzerauthentifizierungs- und Zugriffsmethoden werden derzeit nicht unterstützt.

  • Smartcard
  • Zertifikat
  • SAML-Authentifizierung (außerhalb der Integration mit VMware Workspace ONE)
  • Als aktueller Benutzer anmelden
  • Anonymer Zugriff

Wenn sich eines der nicht unterstützten Elemente für den Support qualifiziert, wird sein Eintrag aus der vorstehenden Liste entfernt und die Ankündigung des Supports wird auf der Seite mit dem Titel Für aktuelle Kunden mit vorhandenen cloudverbundenen Pods – Informationen zu Horizon Cloud Service-Versionen angegeben. Auf dieser Seite wird die Anweisung in dem Abschnitt aufgeführt, der der Version entspricht, in der der Support hinzugefügt wurde.

Remote-Desktop-Funktionen

Die folgenden Funktionen werden in dieser Version von Universal Broker nicht unterstützt.

  • URL-Inhaltsumleitung
  • Sitzungszusammenarbeit

Weitere Funktionen

Die folgenden Funktionen werden in dieser Version von Universal Broker auch nicht unterstützt.

  • Kiosk-Modus
  • Timing-Profil (für die Fehlerbehebung bei Benutzersitzungen)
  • OPSWAT-basierte Überprüfungen der Endpoint-Konformität