End-to-End-Benutzerverbindungs-Workflow in einer Cloud-Pod-Architektur-Umgebung

In den vorangegangenen Themen werden die Bestandteile der Cloud-Pod-Architektur einzeln beschrieben. In diesem Thema wird Schritt für Schritt erläutert, was tatsächlich passiert, von dem Moment an, in dem ein Endbenutzer eine Verbindung herstellt, bis er einen Remote-Desktop oder eine veröffentlichte Anwendung sieht.

1. Der Benutzer startet Horizon Client (oder einen Browser) und stellt eine Verbindung zu einer Server-URL her. Dabei kann es sich um die Adresse einer bestimmten Unified Access Gateway- oder Verbindungsserver-Instanz oder um einen einzelnen DNS-Namen handeln, den ein Lastausgleichsdienst oder ein DNS-Dienst in den nächstgelegenen Pod auflöst. Die Verbindungsserver-Instanz, die der Client zuerst erreicht, wird an anderer Stelle in diesem Handbuch als Verbindungs-Pod oder Brokering-Pod bezeichnet.
2. Der Benutzer authentifiziert sich. Die Authentifizierung erfolgt für den Verbindungs-Pod mithilfe von Active Directory-Anmeldedaten oder, wenn der Workspace ONE-Modus aktiviert ist, indem Sie zunächst zur Anmeldung über Omnissa Access umgeleitet werden. Benutzer, die für einen nicht authentifizierten Zugriff konfiguriert sind, überspringen diesen Schritt für Anwendungsberechtigungen.
3. Der Verbindungs-Pod ermittelt die Berechtigungen des Benutzers aus der globalen Datenschicht. Da es sich bei globalen Berechtigungen um replizierte Daten handelt, muss der Verbindungs-Pod keinen anderen Pod kontaktieren, um zu erfahren, bei welchen globalen Desktop- und Anwendungsberechtigungen der Benutzer (direkt oder über die Gruppenmitgliedschaft) Mitglied ist. An dieser Stelle werden auch die Verbindungsserver-Einschränkungen und Clienteinschränkungsrichtlinien ausgewertet: Eine Berechtigung, deren Kennzeichen nicht mit den Kennzeichen der Verbindungsserver-Instanz übereinstimmen oder deren Clienteinschränkungsgruppe das Gerät des Benutzers nicht enthält, wird aus der Liste herausgefiltert, bevor der Client sie überhaupt sieht.
4. Horizon Client zeigt dem Benutzer die verbleibenden globalen Berechtigungen sowie alle konfigurierten Verknüpfungen an. Der Benutzer wählt eine Option aus.
5. Der verbindende Pod bestimmt, wo mit der Suche nach einer Ressource begonnen werden soll. Wenn für die globale Berechtigung „Start-Site verwenden“ aktiviert ist, startet die Suche an der Start-Site des Benutzers – entweder seine eigene globale Start-Site oder, sofern eine solche konfiguriert ist, die Überschreibung der Start-Site nach Berechtigung, die Vorrang hat. Wenn keine Start-Site zutrifft, beginnt die Suche bei der Site, mit der der Benutzer derzeit verbunden ist.
6. Der verbindende Pod wendet die Geltungsbereichsrichtlinie der globalen Berechtigung an, um zu entscheiden, wie weit sich die Suche von diesem Startpunkt aus nach außen erstrecken darf: nur der Verbindungs-Pod (innerhalb des Pods/LOKAL), jeder Pod in derselben Site (innerhalb der Site/SITE) oder jeder Pod im gesamten Verbund (alle Sites/BELIEBIG).
7. Die Suche selbst wird zuerst lokal ausgeführt und erstreckt sich dann nach außen. Wenn ein übereinstimmender Desktop- oder Anwendungspool mit verfügbarer Kapazität im lokalen Pod vorhanden ist, wird dieser verwendet. Andernfalls verwendet der verbindende Pod VIPA, um Peer-Verbindungsserver-Instanzen in immer größerem Umfang abzufragen – zuerst den Rest der lokalen Site, dann andere Sites in der bevorzugten Reihenfolge – bis eine Ressource gefunden wird oder der zulässige Geltungsbereich ausgeschöpft ist. Wenn eine Richtlinie für die Verteilung der Sitzungslast (Lastindex, Anzahl der Sitzungen oder Keine) konfiguriert ist, wählt die Suche den Pool oder die Farm mit der geringsten Last innerhalb des Pods mit der geringsten Last gemäß dieser Richtlinie aus.
8. Für eine dedizierte Desktop-Berechtigung wird diese Such- und Zuteilungssequenz nur einmal pro Benutzer ausgeführt. Nachdem ein bestimmter Desktop erstmalig zugewiesen wurde, wird jede spätere Verbindung – von dieser Site, einer anderen Site oder einem anderen Gerät – direkt zurück zu demselben Desktop vermittelt, wobei die Suche nach dem Geltungsbereich/der Start-Site umgangen wird. Bei dynamischen Berechtigungen wird die vollständige Suche bei jeder Verbindung wiederholt.
9. Der Pod, dem die ausgewählte Ressource gehört, bereitet die Sitzung vor (Einschalten oder Entsperren der virtuellen Maschine oder Annehmen einer neuen RDS-Sitzung), und der verbundene Pod gibt die Verbindungsdetails an Horizon Client weiter.
10. Horizon Client öffnet die Anzeigeprotokollsitzung (Blast oder PCoIP, gemäß der Protokollrichtlinie der Berechtigung) direkt für den Pod, dem die Ressource angehört – in der Regel über die mit diesem Pod gekoppelte Unified Access Gateway-Appliance. Dabei kann es sich um dieselbe Appliance handeln, über die der Benutzer in Schritt 1 erstmals eine Verbindung hergestellt hat.
11. Die neue Sitzung wird wieder in der globalen Datenschicht aufgezeichnet, weshalb sie sofort von der Horizon Console aus auf jedem Pod angezeigt wird, der mit dem Benutzer, dem Hosting-Pod, dem Brokering-Pod und der Site gekennzeichnet ist.
12. Wenn der Benutzer die Verbindung trennt und später wiederherstellt, überprüft der verbindende Pod die globale Datenschicht auf eine vorhandene Sitzung an einer beliebigen Stelle im Verbund, bevor er eine neue Suche startet, und verbindet den Benutzer erneut mit dieser, wenn eine solche gefunden wird. Es können immer noch mehrere Sitzungen entstehen, z. B. wenn ein Pod, der eine Sitzung hostet, offline geschaltet wird und der Benutzer an anderer Stelle eine neue startet. In diesem Fall fordert Horizon Client den Benutzer auf, eine Sitzung auszuwählen, und die Richtlinie „Redundante Sitzungen automatisch bereinigen“ legt fest, ob die Sitzungen, die der Benutzer nicht auswählt, automatisch bereinigt oder für eine manuelle Abmeldung beibehalten werden.
13. Wenn die Start-Site-Umleitung aktiviert ist, wird ein Benutzer, der eine Verbindung zu einer anderen Site als seinem designierten. Start-Site herstellt, transparent auf die URL seiner Start-Site umgeleitet, ohne dass er aufgefordert wird, sich über das Unified Access Gateway erneut zu authentifizieren, wodurch der Backhaul-Datenverkehr reduziert wird.

Das Szenario eines Krankenversicherungsvertriebs-Agenten in Beispiel: Vorgehensweise zum Einrichten einer grundlegenden Cloud-Pod-Architektur-Konfiguration geht dieselbe Sequenz mit konkreten Pod-, Site- und Berechtigungsnamen durch und ist eine nützliche Hilfestellung zu den oben genannten Schritten.