Use la función Arquitectura Cloud Pod para vincular varios pods para ofrecer un único entorno de administración de aplicaciones y escritorios de gran tamaño.
Un pod consta de un grupo de instancias del servidor de conexión, un almacenamiento compartido, un servidor de la base de datos e infraestructuras de red y de vSphere necesarias para alojar grupos de aplicaciones y escritorios. En una implementación de Horizon 8 tradicional, administre cada pod de forma independiente. Con la función Arquitectura Cloud Pod, puede conectar varios pods para formar una única implementación de Horizon 8 que recibe el nombre de federación de pods.
Una federación de pods puede expandirse a varios sitios y centros de datos y, de forma simultánea, simplificar el esfuerzo de administración necesario para administrar una implementación de Horizon 8 a gran escala.
El diagrama siguiente es un ejemplo de una topología de Arquitectura Cloud Pod básica.
En esta topología de ejemplo, se conectan dos pods previamente independientes de centros de datos diferentes para formar una federación de pods única. Un usuario final de este entorno puede conectarse al pod de Nueva York y recibir una aplicación o un escritorio en cualquier pod.
Cuando se utiliza Arquitectura Cloud Pod con dispositivos de Unified Access Gateway, cada dispositivo debe estar asociado a un único pod.
Componentes clave de la Arquitectura Cloud Pod
La Arquitectura Cloud Pod está formada por una pequeña cantidad de componentes que funcionan juntos para lograr que muchos pods independientes se comporten como un solo sistema.
| Componente | ¿Qué es? | De qué es responsable |
|---|---|---|
| Pod | Un conjunto de instancias del servidor de conexión, almacenamiento compartido, un servidor de bases de datos y la infraestructura de vSphere y de red necesaria para alojar grupos de escritorios y de aplicaciones. | Alojamiento y brokering de escritorios y aplicaciones para los usuarios conectados a ella. |
| Federación de pods | Dos o más pods unidos entre sí mediante la función Arquitectura Cloud Pod. | Presentar los pods unidos como un único entorno de brokering lógico. |
| Capa global de datos | Una segunda instancia de LDAP replicada que se ejecuta en cada instancia del servidor de conexión de la federación de pods. | Almacenar y replicar la topología, las autorizaciones globales, los sitios principales, los grupos de acceso de federación y las directivas en toda la federación de pods. |
| VIPA (View InterPod API) | Un canal de comunicación entre pods basado en HTTPS. | Comunicación entre pods en tiempo real: inicio de sesiones en un pod remoto, búsqueda de sesiones existentes e intercambio de estados. |
| Sitio | Una colección de pods conectados correctamente, por lo general en un centro de datos, tratados como iguales por la Arquitectura Cloud Pod. | Modelización de la localidad de la red para que el servicio de brokering pueda dar prioridad a los recursos cercanos frente a los recursos a los que se accede a través de un enlace WAN más lento. |
| Autorización global | Un objeto con nombre que vincula a usuarios o grupos con grupos de escritorios o de aplicaciones en cualquier lugar de la federación, además de las directivas que controlan cómo se localizan y asignan los recursos. | Lo que realmente ve y selecciona un usuario en Horizon Client. |
| Sitio principal | Una relación opcional entre un usuario o un grupo (o un usuario/grupo y una autorización global específica) y un sitio. | Establecer el punto de partida de la búsqueda de un recurso, independientemente del pod al que se conecte el usuario. |
En qué se diferencia la Arquitectura Cloud Pod de una implementación tradicional de Horizon 8
En una implementación tradicional y no federada de Horizon 8, cada pod es una isla independiente: cuenta con sus propias instancias del servidor de conexión, sus propias autorizaciones locales y no tiene conocimiento de la existencia de ningún otro pod. Un usuario que se conecta al pod A solo puede acceder a un escritorio o una aplicación que existan físicamente en el pod A.
La Arquitectura Cloud Pod cambia esto de tres formas:
- Las autorizaciones pasan a ser globales en lugar de locales. Se concede a un usuario o grupo una autorización global que puede estar respaldada por grupos de recursos de cualquier pod de la federación, en lugar de por un grupo de recursos de una instancia concreta del servidor de conexión.
- El brokering pasa a tener en cuenta la federación, en lugar de limitarse al ámbito local del pod. La instancia del servidor de conexión a la que se conecta un usuario (el pod de conexión, también denominado pod de brokering) puede utilizar VIPA para preguntar a otros pods si disponen de un recurso que coincida, siguiendo un orden controlado por la directiva de ámbito de las autorizaciones globales y el sitio principal del usuario.
- La configuración y el estado se comparten en lugar de aislarse. La topología, las autorizaciones y los sitios principales residen en la capa global de datos y son visibles desde cada pod. La información sobre sesiones y estado también se puede consultar en toda la federación de pods desde Horizon Console. (Excepción: las bases de datos de eventos de Horizon 8 no se comparten entre pods).
Lo que no cambia: cada escritorio o grupo de aplicaciones sigue existiendo físicamente en un único pod, y cada pod sigue siendo totalmente capaz de funcionar de forma autónoma. La Arquitectura Cloud Pod es una capa de administración y brokering que se suma a los pods existentes, no los reemplaza.
¿Le resultó útil esta página?