Les rubriques précédentes décrivent chacun des éléments d'Architecture Cloud Pod. Cette rubrique décrit étape par étape ce qui se passe concrètement entre le moment où un utilisateur final se connecte et celui où il affiche un poste de travail distant ou une application publiée.
- L'utilisateur lance Horizon Client (ou un navigateur) et se connecte à l'URL d'un serveur. Il peut s'agir de l'adresse d'une instance spécifique d'Unified Access Gateway ou du Serveur de connexion, ou encore d'un nom DNS unique qu'un équilibreur de charge ou un service DNS résout vers l'espace le plus proche. L'instance du Serveur de connexion que le client atteint en premier est désignée dans ce guide comme « espace de connexion » ou « espace d'intermédiation ».
- L'utilisateur s'authentifie. L'authentification s'effectue au niveau de l'espace de connexion, à l'aide des informations d'identification Active Directory ou, si le mode Workspace ONE est activé, après une redirection préalable pour se connecter via Omnissa Access. Les utilisateurs configurés pour l'accès non authentifié ignorent cette étape pour les droits applicatifs.
- L'espace de connexion résout les autorisations de l'utilisateur à partir de la couche de données globale. Étant donné que les autorisations globales sont des données répliquées, l'espace de connexion n'a pas besoin de contacter un autre espace pour savoir à quelles autorisations globales de postes de travail et d'applications l'utilisateur appartient (directement ou via l'appartenance à un groupe). À ce stade, les restrictions du Serveur de connexion et les stratégies de restrictions des clients sont également évaluées : une autorisation dont les balises ne correspondent pas à celles de l'instance du Serveur de connexion ou dont le groupe de restrictions des clients n'inclut pas le périphérique de l'utilisateur est exclue de la liste avant même que le client ne puisse la voir.
- Horizon Client affiche les autorisations globales restantes, ainsi que les raccourcis configurés. L'utilisateur en sélectionne une.
- L'espace de connexion détermine où commencer la recherche d'une ressource. Si l'option Utiliser le site de base de l'autorisation globale est activée, la recherche commence sur le site de base de l'utilisateur, soit sur son propre site de base global, soit, s'il est configuré, sur le site de base de remplacement propre à l'autorisation, qui est prioritaire. Si aucun site de base ne s'applique, la recherche commence sur le site auquel l'utilisateur est actuellement connecté.
- L'espace de connexion applique la stratégie d'étendue de l'autorisation globale pour décider jusqu'où la recherche est autorisée à s'étendre au-delà de ce point de départ : uniquement à l'espace de connexion (Dans l'espace/LOCAL), à n'importe quel espace du même site (Dans le site/SITE) ou à n'importe quel espace de toute la fédération (Tous les sites/ANY).
- La recherche elle-même s'exécute d'abord localement, puis s'étend progressivement. Si un pool de postes de travail ou d'applications correspondant avec une capacité disponible existe dans l'espace local, il est utilisé. Sinon, l'espace de connexion utilise VIPA pour interroger des instances homologues du Serveur de connexion dans une étendue progressivement plus large (d'abord le reste du site local, puis les autres sites, par ordre de préférence) jusqu'à ce qu'il trouve une ressource ou que l'étendue autorisée soit épuisée. Si une stratégie Distribution de charge de session (Indice de charge, Nombre de sessions ou Aucune) est configurée, la recherche sélectionne le pool ou la batterie de serveurs dont la charge est la plus faible dans l'espace le moins chargé, en fonction de cette stratégie.
- Pour une autorisation de poste de travail dédié, cette séquence de recherche et d'allocation ne se produit qu'une seule fois par utilisateur. Après l'attribution initiale d'un poste de travail spécifique, toutes les connexions ultérieures (à partir de ce site, d'un autre site ou d'un autre périphérique) sont directement échangées avec ce même poste de travail, contournant ainsi la recherche de portée/site de base. Les autorisations flottantes répètent la recherche complète sur chaque connexion.
- L'espace qui possède la ressource choisie prépare la session (en mettant sous tension ou en déverrouillant la machine virtuelle ou en acceptant une nouvelle session RDS), puis l'espace de connexion relaie les informations de connexion à Horizon Client.
- Horizon Client ouvre la session de protocole d'affichage (Blast ou PCoIP, selon la stratégie de protocole de l'autorisation) directement sur l'espace propriétaire de la ressource, généralement via le dispositif Unified Access Gateway couplé à cet espace. Il peut s'agir ou non du même dispositif que celui via lequel l'utilisateur s'est connecté pour la première fois à l'étape 1.
- La nouvelle session est enregistrée dans la couche de données globale. C'est pourquoi elle est immédiatement visible depuis Horizon Console sur n'importe quel espace, avec les balises utilisateur, l'espace hôte, l'espace d'échange et le site.
- Si l'utilisateur se déconnecte, puis se reconnecte, l'espace de connexion recherche dans la couche de données globale une session existante n'importe où dans la fédération avant de démarrer une nouvelle recherche, puis y reconnecte l'utilisateur le cas échéant. Il peut toutefois se produire des sessions multiples, notamment si un espace hébergeant une session est hors ligne et que l'utilisateur en démarre une nouvelle ailleurs. Dans ce cas, Horizon Client invite l'utilisateur à choisir une session et la stratégie Nettoyage automatique des sessions redondantes détermine si les sessions que l'utilisateur ne sélectionne pas sont nettoyées automatiquement ou conservées jusqu'à leur fermeture manuelle.
- Si la redirection du site de base est activée, un utilisateur qui se connecte à un site autre que son site de base désigné est redirigé de manière transparente vers l'URL de son site de base, sans avoir à se réauthentifier via Unified Access Gateway, ce qui réduit ainsi le trafic de liaison.
Le scénario de l'agent commercial en assurance santé dans l'Exemple : configuration d'une architecture Cloud Pod de base détaille cette même séquence avec des noms concrets d'espace, de site et d'autorisation. Il constitue un complément utile aux étapes décrites ci-dessus.
Cette page vous a-t-elle été utile ?