La fonctionnalité Architecture Cloud Pod permet de lier plusieurs espaces ensemble afin de fournir un environnement unique et volumineux d'échange et de gestion de postes de travail et d'applications.
Un espace se compose d'un ensemble d'instances de Serveur de connexion, d'un stockage partagé, d'un serveur de base de données et des infrastructures vSphere et réseau requises pour héberger les pools de postes de travail et d'applications. Dans une implémentation Horizon 8 traditionnelle, vous gérez chaque espace indépendamment. Avec la fonctionnalité Architecture Cloud Pod, vous pouvez joindre plusieurs espaces ensemble pour former une implémentation Horizon 8 unique appelée fédération d'espaces.
Une fédération d'espaces peut s'étendre sur plusieurs sites et centres de données et ainsi simplifier l'effort d'administration requis pour gérer un déploiement d'Horizon 8 à grande échelle.
Le diagramme suivant présente un exemple d'une topologie Architecture Cloud Pod de base.
Dans l'exemple de topologie, deux espaces précédemment autonomes dans différents centres de données sont joints pour former une fédération d'espaces unique. Un utilisateur final de cet environnement peut se connecter à l'espace New York et recevoir un poste de travail ou une application dans l'un des deux espaces.
Lorsque vous utilisez Architecture Cloud Pod avec des dispositifs Unified Access Gateway, chacun d'entre eux doit être associé à un seul espace.
Composants clés d'Architecture Cloud Pod
Architecture Cloud Pod est créée à partir d'un petit nombre de composants qui fonctionnent ensemble pour que de nombreux espaces indépendants se comportent comme un seul système.
| Composant | Définition | Rôle |
|---|---|---|
| Espace | Ensemble composé d'instances de Serveur de connexion, d'un stockage partagé, d'un serveur de base de données et des infrastructures vSphere et réseau requises pour héberger les pools de postes de travail et d'applications. | Hébergement et attribution des postes de travail et applications aux utilisateurs connectés. |
| Fédération d'espaces | Deux espaces ou plus joints à l'aide de la fonctionnalité Architecture Cloud Pod. | Présentation des espaces joints sous la forme d'un environnement d'attribution logique unique. |
| Couche de données globale | Deuxième instance LDAP répliquée s'exécutant sur chaque instance du Serveur de connexion dans la fédération d'espaces. | Stockage et réplication de la topologie, des autorisations globales, des sites de base, des groupes d'accès à la fédération et des stratégies à l'échelle de la fédération d'espaces. |
| VIPA (View InterPod API) | Canal de communication entre espaces basé sur HTTPS. | Communication d'espace à espace en temps réel : lancement de sessions sur un espace distant, recherche de sessions existantes et échange des informations sur l'état de santé. |
| Site | Ensemble d'espaces bien connectés, généralement dans un centre de données, traités sur un pied d'égalité par Architecture Cloud Pod. | Modélisation de la localité du réseau de sorte que le processus d'attribution privilégie les ressources à proximité aux ressources atteintes via une liaison WAN plus lente. |
| Autorisation globale | Objet nommé liant des utilisateurs ou des groupes à des pools de postes de travail ou d'applications n'importe où dans la fédération, avec les stratégies qui régissent la recherche et l'allocation des ressources. | Ce qu'un utilisateur voit et sélectionne réellement dans Horizon Client. |
| Site de base | Relation facultative entre un utilisateur ou un groupe (ou un utilisateur/groupe et une autorisation globale spécifique) et un site. | Point de départ de la recherche d'une ressource, quel que soit l'espace par lequel l'utilisateur se connecte. |
Différences entre Architecture Cloud Pod et un déploiement d'Horizon 8 traditionnel
Dans un déploiement d'Horizon 8 traditionnel non fédéré, chaque espace est un îlot autonome : il dispose de ses propres instances du Serveur de connexion et de ses propres autorisations locales ; il ne reconnaît aucun autre espace. Un utilisateur se connectant à l'espace A peut uniquement se voir attribuer un poste de travail ou une application qui existe physiquement dans l'espace A.
Architecture Cloud Pod modifie cela de trois manières :
- Les autorisations locales deviennent globales. Vous autorisez un utilisateur ou un groupe à disposer d'une autorisation globale qui peut s'appuyer sur des pools de n'importe quel espace de la fédération, plutôt que sur un pool d'une instance spécifique du Serveur de connexion.
- Le processus d'attribution prend en charge la fédération et non plus seulement l'espace local. L'instance du Serveur de connexion à laquelle un utilisateur se connecte ( l'espace de connexion, également appelé espace d'attribution) peut utiliser VIPA pour demander aux autres espaces s'ils ont une ressource correspondante, selon un ordre déterminé par la stratégie d'étendue des autorisations globales et le site de base de l'utilisateur.
- La configuration et l'état sont partagés au lieu d'être cloisonnés. La topologie, les autorisations et les sites de base résident dans la couche de données globale et sont visibles depuis chaque espace. Les informations de session et de santé sont également visibles à l'échelle de la fédération d'espaces dans Horizon Console. (Exception : les bases de données des événements Horizon 8 ne sont pas partagées entre les espaces.)
Ce qui ne change pas : chaque pool de postes de travail ou d'applications existe toujours physiquement dans exactement un espace ; chaque espace reste entièrement capable de fonctionner de manière autonome. Architecture Cloud Pod est une couche d'attribution et de gestion qui s'ajoute à vos espaces existants sans toutefois les remplacer.
Cette page vous a-t-elle été utile ?