Virtualización de Citrix en Google Cloud

Introducción

En esta guía, le guiamos a través del diseño de un sistema de virtualización Citrix en GCP. A medida que avanza el viaje, discutimos las implicaciones de las decisiones que necesita tomar, y la curación de más recursos de referencia en el camino. Esta guía es un documento vivo. Asegúrate de marcarlo y revisa periódicamente para ver cómo cambian las cosas con el tiempo.

Comenzamos revisando lo común patrones de diseño de las tecnologías de virtualización de Citrix en Google Cloud. Algunos piensan en estos ‘patrones de diseño’ como ‘arquitecturas de referencia’, pero cuando trabajamos con infraestructura como código y servicios en la nube, los ‘patrones de diseño’ tienen mucho más sentido.

A continuación exploramos el Componentes y requisitos de la solución. Diseñamos los requisitos previos de la solución y le proporcionamos una visión general de los servicios/componentes necesarios para crear un ‘‘ubicación de recursos‘de Citrix Cloud.

A continuación, revisamos y excavamos más profundamente en los patrones de diseño, con una mayor comprensión de los servicios/componentes de un sistema de virtualización Citrix en Google Cloud. Por último, profundizamos en áreas temáticas específicas, incluyendo Diseño y administración de Virtual Delivery Agent (VDA), Citrix ADC/Gateway en Google Cloud, y Citrix StoreFront en Google Cloud.

Al realizar este viaje con nosotros, le animamos a compartir sus comentarios, contribuciones, preguntas, sugerencias y comentarios a lo largo del camino. Envíenos una línea por correo electrónico a el grupo de trabajo Citrix sobre Google SME.

Patrones de diseño para la virtualización de Citrix en Google Cloud

Reconocemos que diferentes clientes se encuentran en diferentes etapas en su ruta hacia “la nube”. Como tal, esbozamos tres patrones de diseño que representan un espectro desde “todos estamos dentro” hasta “llegaremos allí, pero nos puede llevar un tiempo”. Los tecnólogos observantes ven los elementos comunes entre los tres. Comienzan a ver cómo pueden combinar y combinar los servicios gestionados por el cliente y en la nube para satisfacer diferentes necesidades empresariales e influencias ambientales. Exploramos esta modularidad de subsistemas cuando revisitamos estos tres patrones de diseño más tarde en esta guía.

El patrón de diseño de la nube hacia adelante

Organizaciones de todas las formas y tamaños están haciendo el cambio a “la nube” y servicios administrados basados en suscripción. Para los clientes que están todos en “la nube” (o interesados en experimentar lo mejor de lo que la nube tiene para ofrecer), el patrón de diseño Cloud Forward es una gran combinación. El patrón de diseño Cloud Forward:

  • Utiliza servicios de última generación proporcionados en la nube de Citrix y Google.
  • Se utiliza comúnmente para nuevas implementaciones, además de la evaluación tecnológica, la corrección, la capacitación y otros casos de uso que valoran la simplicidad, la flexibilidad y la velocidad de implementación.
  • No requiere ninguna infraestructura ni licencias existentes, y se puede crear en menos de 30 minutos con plantillas de Google Deployment Manager, como el Citrix en el proyecto GCP GitHub.
  • Proporciona alta disponibilidad de todos los servicios críticos.
  • Crea un Citrix Cloud “ubicación de recursos” - la base de los otros dos patrones que se describen aquí.

Todo lo que necesita para comenzar es un proyecto GCP y tener acceso a una suscripción a Citrix Servicio de Virtual Apps and Desktops en la nube (CVADS). Las suscripciones de evaluación a Citrix Cloud están disponibles a través de distribuidores autorizados de Citrix y Citrix. Google también ofrece nuevos clientes un prueba gratuita que incluye $300 de crédito de Google Cloud.

Nota:

La versión de prueba gratuita de GCP no incluye el uso de imágenes de Windows Server, como se indica en Documento de capa gratuita de Google Cloud. Para usar imágenes de Windows Server, debe actualizar a una cuenta de pago en GCP. Tus créditos gratuitos seguirán aplicándose al actualizar a una cuenta de pago, tal como se indica en el documento de la capa gratuita de Actualizar a una sección de cuenta de pago Google Cloud.

Patrón de diseño Cloud Forward

Este patrón de diseño utiliza más de uno de todos los recursos clave (➊) implementados en zonas separadas en una región determinada de Google Cloud para obtener una alta disponibilidad.

Citrix Cloud Connectors (❷) es responsable de las comunicaciones hacia y desde Citrix Cloud (❻), mediante conexiones TLS salientes a los servicios de Citrix Cloud a través de Internet. Una vez instalado en instancias de VM de Windows Server unidas al dominio, Citrix Cloud actualiza y mantiene automáticamente el software Cloud Connector.

Las aplicaciones y los escritorios son proporcionados por instancias de VM de Windows o Linux, o ambas que ejecutan el software Virtual Delivery Agent (VDA) de Citrix (❸). El software Citrix VDA utiliza el sofisticado Citrix Tecnología HDX para proporcionar la mejor experiencia de usuario posible con aplicaciones y escritorios virtualizados. Los VDA se registran con Citrix Cloud Connectors, que son responsables de intermediar las conexiones de sesión HDX a los VDA. Las sesiones HDX se insertan en la VPC a través de Cloud Connectors de forma predeterminada, u opcionalmente a través de Citrix Gateway Service configurando la directiva de “rendezvous”. GPU de Google Cloud puede utilizarse como reserva de las instancias de VM de forma opcional para crear estaciones de trabajo virtuales, lo que a su vez acelera las aplicaciones con uso intensivo de gráficos.

Los VDA de Citrix se implementan con mayor frecuencia cerca de la infraestructura requerida por las aplicaciones que se entregan (❹). Por lo tanto, la infraestructura de aplicaciones normalmente se implementa o migra a la misma región que los VDA de Citrix.

Los usuarios finales utilizan Aplicación Citrix Workspace (❺) (CWA) para conectarse a aplicaciones y escritorios virtualizados e interactuar con ellos mediante la innovadora de Citrix Protocolo remoto de sesión HDX. El CWA está disponible para casi cualquier dispositivo o sistema operativo, incluyendo Chrome OS, Windows, OSX, iOS, Android y Linux.

Este patrón utiliza los siguientes servicios en la nube (❻) de Citrix, que son seguros y de alta disponibilidad por diseño:

  • Citrix Virtual Apps and Desktop Service: proporciona servicios de intermediación de sesiones, administración de cargas, administración de imágenes de instancia única, supervisión y administración de costes y capacidad.
  • Servicio Citrix Workspace: la interfaz de usuario de la solución. Este servicio web proporciona autenticación multifactor, presentación de contenido y servicios de inicio para la aplicación Citrix Workspace. Este servicio consolida el acceso a aplicaciones virtualizadas y escritorios, web y aplicaciones SaaS, además de los almacenes de archivos empresariales.
  • Servicio Citrix Gateway: proporciona acceso seguro a aplicaciones y escritorios virtualizados, además de aplicaciones web empresariales, a dispositivos de redes públicas.
  • Servicio de Citrix Analytics: utiliza tecnologías avanzadas de aprendizaje automático para proporcionar seguridad de nivel empresarial, rendimiento y análisis e informes del comportamiento de los usuarios.

Este patrón de diseño también se puede emparejar con una VPN/InterConnect de Google Cloud o una solución diseñada para fines específicos como Citrix SD-WAN (❼) para ampliar las inversiones existentes de Active Directory (❽) en Google Cloud o para proporcionar acceso a aplicaciones e infraestructura tradicionales, locales y administradas por el cliente.

El patrón de diseño híbrido

El patrón de diseño híbrido se basa en el patrón de diseño Cloud Forward. Presenta componentes de capa de acceso administrados por el cliente de Citrix (➊) para satisfacer de manera flexible las necesidades de casos de uso y datos demográficos específicos del cliente. Estos componentes administrados por el cliente incluyen lo siguiente:

  • Citrix ADC/Gateway(❷): implementado como dispositivos virtuales en GCP, este componente se utiliza a menudo para casos de uso que requieren uno o más de los siguientes:
    • Escenarios de autenticación avanzada, como SAML/OAUTH 2/federación OpenID, RADIUS, tarjeta inteligente y requisitos de acceso condicional.
    • Acceso a sesión altamente optimizado y flexible para dispositivos de usuario final en redes públicas.
    • Servicios de red avanzados como conmutación de contenido, firewall de aplicaciones web, almacenamiento en caché web integrado, mitigación de ataques, equilibrio de carga de aplicaciones y descarga SSL.
    • Capacidad para dirigir usuarios/dispositivos específicos a ‘almacenes’ específicos basados en directivas avanzadas, altamente flexibles y contextualmente conscientes. Las decisiones de directivas se pueden basar en los atributos del perfil de usuario, la ubicación, el tipo de dispositivo, el estado del dispositivo, los resultados de autenticación y mucho más.
  • Citrix StoreFront(❸): El predecesor del servicio Citrix Workspace, StoreFront es el proveedor “clásico” de servicios de interfaz de usuario de Citrix. Instalado en instancias de Windows Server administradas por el cliente, StoreFront se utiliza a menudo para casos de uso que requieren uno o más de los siguientes:
    • Alta disponibilidad extrema, capaz de sobrevivir a una gama más amplia de escenarios de falla, especialmente cuando se implementan en una configuración de alta disponibilidad.
    • Enrutamiento de sesiones flexible, con la capacidad de enrutar el tráfico de sesión de usuario interno directamente a los VDA mientras envía usuarios externos a través de Citrix Gateways.
    • Inicio de sesión único desde dispositivos locales administrados por el cliente.
    • La necesidad de proporcionar múltiples ‘almacenes’ con diferentes propiedades de configuración para admitir diversos casos de uso en el mismo sistema.
    • La necesidad de interfaces de usuario altamente personalizadas o de marca basadas en HTML.

patrón de diseño híbrido

Con el patrón de diseño híbrido, los componentes de la capa de acceso de Citrix se implementan en el entorno Google Cloud (➊) del cliente. Por lo general, los componentes se implementan en pares distribuidos en varias zonas para una alta disponibilidad.

Este patrón utiliza los dispositivos ADC/Gateway VPX (virtual) de Citrix para proxy de forma segura sesiones HDX en los VDA del entorno del cliente (❷). Los dispositivos Citrix ADC/Gateway se pueden utilizar con el servicio Citrix Workspace para servicios de proxy de sesión simples o escenarios complejos de autenticación, o ambos (opción A de la interfaz de usuario). También se puede emparejar con Citrix StoreFront (opción B de la interfaz de usuario).

Este patrón utiliza opcionalmente Citrix StoreFront (❸) para servicios de interfaz de usuario, lo que permite que el sistema cumpla los requisitos para casos de uso más complejos como se ha descrito anteriormente. Se empareja con Citrix ADC/Gateway, que maneja la autenticación además de los servicios proxy de sesión de UI y HDX.

El patrón de diseño de migración a la nube

El patrón de diseño de migración a la nube se basa aún más en el patrón de diseño híbrido. Permite a los clientes con inversiones existentes en tecnologías Citrix modernizar sistemáticamente su infraestructura, al tiempo que migran cargas de trabajo a la nube sin problemas. Esta migración se puede realizar a un ritmo que no interrumpa los sistemas y casos de uso existentes o críticos. Permite a los clientes tecnológicamente conservadores “adentrarse” en la nube, carga de trabajo por carga de trabajo, mitigando el riesgo en el camino según los términos del cliente. También permite al cliente rematar sistemáticamente al personal con las tecnologías más recientes y más capaces de Citrix y Google, y desarrollar su preparación para la nube organizativa a un ritmo manejable mientras utiliza sus inversiones existentes en tecnología, infraestructura, conocimiento, procesos y operacionalización procedimientos.

El patrón de diseño de migración a la nube comienza con el patrón híbrido descrito en la sección anterior. El sistema construido con el patrón híbrido se convierte en el nuevo entorno de vanguardia donde se implementan nuevas cargas de trabajo. El patrón de migración a la nube utiliza Citrix StoreFront (➊) o la interfaz de usuario de Citrix Workspace (❷), o ambos para conectar entornos de Citrix heredados (❸) al nuevo entorno, ya que ambas UI pueden presentar varios entornos de intermediación en una sola vista con un único inicio de sesión. Esto proporciona a los usuarios una única interfaz de usuario (❹) que pueden utilizar para acceder a ambos entornos. Esto permite al cliente implementar nuevas cargas de trabajo en Google Cloud (❺), mientras migra sistemáticamente las cargas de trabajo existentes a Google Cloud según lo exijan las oportunidades y limitaciones empresariales.

nube migración-diseño-patrón

Ahora que ha revisado los patrones de diseño, vamos a despegar un poco las capas. Vamos a explorar lo que se necesita para crear un sistema de virtualización Citrix en Google Cloud.

Componentes y requisitos de la solución

Prerrequisitos del sistema de virtualización

Para crear un sistema de virtualización Citrix en Google Cloud, necesita un mínimo de dos cosas para comenzar:

  • Un proyecto de Google Cloud
  • Suscripción a Citrix Virtual Apps and Desktops Service

Nota:

La prueba gratuita de GCP no incluye el uso de imágenes de Windows Server, como se indica en Documento de capa gratuita de Google Cloud. Para usar imágenes de Windows Server, debe actualizar a una cuenta de pago en GCP. Tus créditos gratuitos seguirán aplicándose al actualizar a una cuenta de pago, tal y como se indica Actualizar a una sección de cuenta de pago en el documento de la capa gratuita de Google Cloud.

¿Tienes tus requisitos previos alineados? ¡Bien! Ahora vamos a presentarte lo que estás construyendo.

Sugerencia:

La documentación del servicio Citrix Virtual Apps and Desktops Service es relevante ya que este servicio es el núcleo de la solución. Asegúrese de darle una lectura antes de empezar a construir, y manténgalo a mano para cuando necesite más información. Se puede encontrar en el sitio de documentos de Citrix.

Ubicación de recursos de Citrix Cloud

La base de un sistema de virtualización de Citrix en Google Cloud es una construcción de Citrix Cloud llamada “ubicación de recursos”. Una ubicación de recursos, en Citrix speak, es más o menos análoga a una región de GCP. Se trata de una agrupación de recursos bien conectada, en una red privada con Active Directory, salida de Internet (para utilizar servicios seguros en la nube de Citrix y Google) y algunas aplicaciones y datos que desea virtualizar y entregar de forma segura a cualquier dispositivo del mundo. Las aplicaciones y los escritorios virtualizados se entregan desde instancias de VM en GCP denominados “VDA”. Se trata de instancias de VM de Windows o Linux que ejecutan el software VDA de Citrix, lo que permite que las interfaces de usuario de escritorio o aplicación se puedan dirigir de forma remota a los dispositivos cliente mediante el protocolo de visualización HDX de Citrix. Los agentes VDA se registran con Cloud Connectors, que proxy de forma segura las comunicaciones con Citrix Cloud Services.

Sugerencia:

Una regla fundamental para ofrecer aplicaciones virtualizadas que debe tener en cuenta. Desea colocar las aplicaciones (que se ejecutan en los VDA de Citrix) cerca de los datos (infraestructura necesaria para las aplicaciones). No tener aplicaciones y datos locales entre sí puede dar como resultado una mayor latencia y aplicaciones más lentas, lo que en última instancia puede causar una experiencia de usuario degradada.

Las ubicaciones de recursos suelen crearse para que sean de alta disponibilidad, lo que significa que los servicios clave se distribuyen a través de zonas de la región GCP. Cuando proceda, se implementan más de una instancia de VM para servicios clave con fines de disponibilidad y capacidad de administración. Los servicios clave que necesita tener en una ubicación de recursos son:

  • *Microsoft Active Directory
  • *Conectores de Citrix Cloud
  • *Un método para una salida confiable de Internet, como Cloud NAT
  • *Citrix VDA (instancias de VM GCP con el software VDA de Citrix instalado debajo de las aplicaciones que se entregan)
  • Otra infraestructura, según sea necesario, para dar soporte a las aplicaciones que se entregan

Vamos a explorar más a fondo algunos de estos servicios*, ya que se requiere que dispongan de una ubicación funcional de recursos de Citrix Cloud en Google Cloud.

Microsoft Active Directory

Todos los patrones de diseño para los sistemas de virtualización Citrix en Google Cloud requieren Microsoft Active Directory. Para una experiencia de usuario convincente, los servicios de Active Directory deben estar disponibles en todas las regiones de GCP en las que haya implementado VDA, por lo que se considera un componente central de una ubicación de recursos de Citrix Cloud. AD se utiliza para la administración de configuración (directiva de grupo) además de la autenticación, aunque como aprendemos más adelante, AD no necesita ser el proveedor de identidades para el sistema. Muchos clientes amplían su AD existente a Google Cloud, aunque la virtualización de Citrix puede integrarse de forma flexible en varios diseños de AD y modelos de mantenimiento.

Al implementar Active Directory en Google Cloud, los clientes pueden crear o mantener sus propios controladores de dominio de Active Directory mediante instancias de Windows Server Servicio administrado para Microsoft Active Directory, utilizar Google o una combinación de ambos. Las confianzas de Active Directory también se pueden utilizar para conectar dos o más bosques o dominios de AD dependiendo de las necesidades del cliente.

Para los clientes que buscan minimizar la sobrecarga administrativa necesaria para crear y mantener servicios funcionales de Active Directory, Google Servicio administrado para Microsoft Active Directory (Administrado Microsoft AD para abreviar) es una opción que vale la pena considerar. Este servicio le proporciona un bosque o dominio de Active Directory completamente funcional sin la sobrecarga de crear y mantener instancias de VM de Windows Server. El servicio Administrado de Microsoft AD se basa en una infraestructura administrada por Google de alta disponibilidad y se entrega como un servicio administrado. Cada directorio se implementa en varias zonas GCP y la supervisión detecta y reemplaza automáticamente los controladores de dominio que fallan. No es necesario instalar software, y Google se encarga de todos los parches y actualizaciones de software. Con el Servicio administrado de Google para Microsoft Active Directory, puede usar herramientas administrativas nativas de Microsoft, administrar máquinas Windows y usuarios con la directiva de grupo de Microsoft. También puede unir instancias de VM a él e incluso configurar confianzas de Active Directory con instancias de AD existentes para admitir varios escenarios empresariales complejos.

Los clientes que optan por utilizar el servicio AD administrado de Google con tecnologías de virtualización Citrix pueden esperar que estas tecnologías funcionen, con algunas cosas importantes a tener en cuenta antes de hacerlo. Para empezar, no tendrá acceso de administrador de dominio, administrador de empresa u otro tipo “superusuario” a la instancia de AD. Sin embargo, tiene el control total de su propio contenedor en la raíz del directorio donde puede crear usuarios, equipos, grupos, unidades organizativas y directivas de grupo. También puede configurar y utilizar varios tipos de relaciones de confianza con otros directorios.

Algunas otras cosas que NO PUEDES hacer:

  • Cree objetos AD en cualquiera de los contenedores predeterminados (como /Computers): son de solo lectura. Esto da lugar a un error común que algunos clientes cometen al usar la tecnología de aprovisionamiento de Machine Creation Services (MCS) de Citrix: debe elegir crear las cuentas de máquina para los VDA administrados de MCS en un contenedor/unidad organizativa que pueda escribirse. Si no elige una ubicación de este tipo, MCS no puede crear las cuentas de máquina.
  • Instale y configure algunas funciones integradas de AD, como Servicios de Certificate Server. Como tal, esto afecta a los clientes que planean usar la tecnología Federated Authentication Services (FAS) de Citrix, que requiere Servicios de Certificate Services integrados de AD. Estos clientes deben crear y administrar su propio Active Directory en Google Cloud mediante instancias de VM de Windows Server.
  • Tener equivalencia de administrador del servidor local de forma predeterminada. En una instalación “fuera de la caja” de Active Directory, el grupo Administradores de dominio se agrega al grupo Administradores de servidor local de forma predeterminada. Si utiliza Google Managed Service for Microsoft AD, es posible que tenga que crear su propio grupo de administradores de servidores, agregarle sus propios usuarios, crear y aplicar una directiva de grupo para agregar su grupo al grupo Administradores de servidores integrado en servidores o estaciones de trabajo miembros.

Aunque las relaciones de confianza, la configuración del sitio/servicio, la replicación y otros temas relacionados con AD no se tratan aquí, Citrix ha proporcionado una amplia documentación sobre estos temas aplicable a los tres modelos de implementación.

Nota:

Para obtener más información sobre los requisitos de Active Directory para la virtualización de Citrix en Google Cloud, consulte Detalles técnicos de Citrix Cloud Connector. Además de cubrir niveles funcionales de Active Directory admitidos, este artículo también cubre escenarios de implementaciones para Cloud Connectors en Active Directory.

Importante:

La resolución de nombres DNS es importante para un sistema que funcione correctamente. DHCP en GCP siempre utiliza los servidores de nombres de Google. Para que las instancias de VM “encuentren” y se unan a la instancia de Active Directory en GCP, desea implementar zonas DNS administradas privadas, aunque no es necesario si utiliza el servicio de Microsoft AD administrado. Consulta Google Introducción a DNS en la nube para obtener más información.

La resolución de nombres DNS también es importante cuando se implementa la función Rendezvous de Citrix para el proxy de sesión HDX, incluido el uso de Transporte adaptable EDT/Citrix. Consulte Protocolo Rendezvous la documentación para obtener más detalles.

Citrix Cloud Connectors

Citrix Cloud Connectors funciona como un proxy seguro administrado en la nube para el sistema de virtualización Citrix. Cloud Connectors son instancias dedicadas y unidas a dominios de Windows Server en zonas separadas dentro de una región. También funciona como agente de sesión sin conexión si se interrumpe el acceso a Internet (“modo de caché de host local”), útil para implementaciones de misión crítica con requisitos de disponibilidad extrema. Analizamos esta función con más detalle a medida que nos adentramos en el patrón de diseño híbrido más adelante en este documento.

Los Cloud Connectors normalmente se implementan como un recurso N+1, mediante instancias de VM distribuidas en varias zonas de una región determinada. Esto permite escalar una ubicación de recursos y facilita la actualización automática del software Cloud Connector.

Nota:

Para obtener más información sobre el tamaño de instancias de Citrix Cloud Connectors, consulte consideraciones de escala y tamaño para Cloud Connectors.

Cloud Connectors puede sentarse en cualquier VPC donde puedan llegar a Active Directory y a los VDA de Citrix, y necesitan una salida fiable de Internet para funcionar correctamente. Un método simple y altamente disponible para proporcionar salida a Internet es Google Cloud NAT, aunque muchos otros métodos también son compatibles. Para casos de uso con estrictos controles de salida o requisitos de auditoría, el tráfico de salida de Cloud Connectors a Citrix Cloud puede ser proxied.

Nota:

Para obtener más información sobre los puertos y protocolos utilizados por las tecnologías de virtualización de Citrix, consulte Communication Ports Used by Citrix Technologies. Este documento proporciona la base para las reglas de firewall que establezca en Google Cloud.

VDA de Citrix

El último tipo de recurso que necesita para tener un sistema de virtualización de Citrix funcional se denomina VDA, y son la carga de trabajo real que usted está entregando. Como se mencionó anteriormente, se trata de instancias de VM de Windows o Linux que ejecutan el software “Virtual Delivery Agent” de Citrix, lo que permite que las interfaces de usuario de escritorio o aplicaciones se puedan enviar de forma remota a los dispositivos cliente mediante el protocolo de visualización HDX de Citrix. Los agentes VDA se pueden crear y administrar fuera del sistema mediante cualquier mecanismo de aprovisionamiento que desee. Por ejemplo, puede usar plantillas de Google Deployment Manager, pero para cualquier tipo de escala, desea utilizar la tecnología MCS de Citrix.

MCS automatiza la creación de ‘catálogos de máquinas’: grupos de VDA configurados idénticamente creados a partir de una o más instancias de VM “master’ de oro”. MCS utiliza instantáneas del disco persistente para capturar el estado del sistema operativo y la pila de aplicaciones instaladas. También utiliza los atributos de instancia de su instancia de máquina virtual “maestro dorado” para crear plantillas de instancia, que aplican estos atributos a los agentes VDA bajo administración de MCS. MCS también automatiza la actualización del disco del sistema en los VDA mediante instantáneas similares del disco ‘Golden Master’, y orquesta los esfuerzos de la función Autoscale para administrar automáticamente los costes y la capacidad.

Hay mucho más que saber sobre los VDA, pero profundizamos más adelante en esta guía. ¿No puede esperar? Dirígete directo a Consideraciones de diseño y administración de VDA.

Nota:

Consulte Communication Ports Used by Citrix Technologies para identificar las reglas de firewall que establece en Google Cloud.

Nota adicional:

Los agentes VDA no tienen que tener salida a Internet, y para ciertos casos de uso no lo hacen por diseño. Sin embargo, si los VDA tienen salida a Internet, la función “protocolo de rendezvous” puede ser habilitado a través de la directiva de Citrix, permitiendo que los dispositivos cliente (que ejecutan la aplicación Citrix Workspace) y el VDA se conecten de forma segura a través del servicio Citrix Gateway. Esto mejora la escalabilidad de Cloud Connectors, que a menudo son responsables de la proxy de las conexiones HDX en los VDA. La otra opción para hacer proxy conexiones HDX a través de redes públicas: implemente instancias de Citrix ADC/Gateway administradas por el cliente en el perímetro de la VPC.

Patrones de diseño - profundizando

Anteriormente en este documento presentamos tres patrones de diseño diferentes pero relacionados para la virtualización de Citrix en Google Cloud. Estos patrones se construyen uno encima del otro, sirviendo efectivamente casos de uso más complejos a lo largo del camino. Nos referimos a ellos como:

  • El patrón de diseño de la nube hacia adelante
  • El patrón de diseño híbrido
  • El patrón de diseño de migración a la nube

El patrón de diseño de la nube hacia adelante

Mencionamos que este es el patrón de diseño fundamental para la virtualización de Citrix en Google Cloud. Debe quedar claro que la arquitectura del patrón de diseño hacia adelante en la nube crea una ubicación de recursos de Citrix Cloud. Esta es la base común compartida a través de los tres patrones presentados aquí. Las diferencias entre los patrones radica en qué tecnologías se utilizan para dar servicio a los cinco componentes de un sistema de virtualización Citrix descritos en la tabla siguiente. Con el patrón de diseño avanzado en la nube, los servicios en la nube se utilizan para los cinco componentes:

Intermediación y administración de sesiones Citrix Virtual App and Desktop Service - (CVADS) (servicio en la nube)
Servicios de interfaz de usuario (UI) Servicio Citrix Workspace (servicio en la nube)
Autenticación Servicio Citrix Workspace, Active Directory como IdP
Proxy de sesión HDX Servicio Citrix Gateway (servicio en la nube)
Analytics Citrix Analytics Service (servicio en la nube)

Patrón de diseño hacia adelante en

El patrón de diseño hacia adelante de la nube se puede replicar mediante el mismo Active Directory (o no) en diferentes regiones de Google Cloud. Esto hace que el patrón sea útil para implementaciones con aplicaciones y datos distribuidos geográficamente. Este patrón, para implementaciones de producción, a menudo se extiende conectando la ubicación de recursos en GCP a centros de datos gestionados por el cliente mediante VPN de Google CloudInterconexión de Google Cloud, o un producto diseñado para fines específicos como SD-WAN de Citrix. Dicha conexión de red privada le permite ampliar servicios clave (como Microsoft Active Directory) a Google Cloud. Esto puede proporcionar a los VDA acceso a aplicaciones y recursos que aún no se han migrado. También puede actuar como conducto para migrar aplicaciones y datos a Google Cloud. Aunque no se muestra en el diagrama anterior, Citrix Workspace Environment Management Service se utiliza comúnmente, especialmente cuando los sistemas hacen su ruta a la producción. Workspace Environment Management Service utiliza tecnologías de administración inteligente de recursos y Profile Management para ofrecer el mejor rendimiento posible, inicio de sesión de escritorio y tiempos de respuesta de aplicaciones para implementaciones de Citrix Virtual Apps and Desktops. Consulte Administración del entorno de usuario/configuración más adelante en esta guía para obtener más detalles.

El patrón de diseño híbrido

Anteriormente también introdujimos el patrón de diseño híbrido. El patrón de diseño híbrido, una variante del patrón de avance en la nube, introduce implementaciones gestionadas por el cliente de tecnologías de capa de acceso de Citrix probadas para empresas para proporcionar servicios de interfaz de usuario, autenticación y funciones de proxy HDX. Estas opciones permiten al sistema de virtualización dar servicio a casos de uso más complejos, muchos de los cuales son comunes en las empresas que recién comienzan su viaje a la nube.

el patrón de diseño híbrido

Para poner el patrón de diseño híbrido en el contexto de los cinco componentes de un sistema de virtualización Citrix:

Función del sistema de virtualización: Proporcione:
Intermediación y administración de sesiones Citrix Virtual App and Desktop Service (CVADS) (servicio en la nube)
Servicios de interfaz de usuario (UI) Servicio Citrix Workspace (servicio en la nube) O Citrix StoreFront (gestionado por el cliente)
Autenticación Muchas combinaciones disponibles para el servicio Citrix Workspace (servicio en la nube) O Citrix StoreFront al introducir Citrix ADC/Gateway (gestionado por el cliente)
Proxy de sesión HDX Citrix Gateway Service (servicio en la nube) O Citrix ADC/Gateway (gestionado por el cliente)
Analytics Citrix Analytics Service (servicio en la nube)

Anteriormente le dimos los puntos más destacados de cuándo la introducción de Citrix ADC/Gateway y Citrix StoreFront es útil para introducir en el sistema de virtualización Citrix en Google Cloud:

  • Citrix ADC/Gateway(❷): implementado como dispositivos virtuales en GCP, este componente se utiliza a menudo para casos de uso que requieren uno o más de los siguientes:
    • Escenarios de autenticación avanzada, como SAML/OAUTH 2/federación OpenID, RADIUS, tarjeta inteligente y requisitos de acceso condicional.
    • Acceso a sesión altamente optimizado y flexible para dispositivos de usuario final en redes públicas.
    • Servicios de red avanzados como conmutación de contenido, firewall de aplicaciones web, almacenamiento en caché web integrado, mitigación de ataques, equilibrio de carga de aplicaciones y descarga SSL.
    • Capacidad para dirigir usuarios/dispositivos específicos a ‘almacenes’ específicos basados en directivas avanzadas, altamente flexibles y contextualmente conscientes. Las decisiones de directivas se pueden basar en los atributos del perfil de usuario, la ubicación, el tipo de dispositivo, el estado del dispositivo, los resultados de autenticación y mucho más.
  • Citrix StoreFront(❸): El predecesor del servicio Citrix Workspace, StoreFront es el proveedor “clásico” de servicios de interfaz de usuario de Citrix. Instalado en instancias de Windows Server administradas por el cliente, StoreFront se utiliza a menudo para casos de uso que requieren uno o más de los siguientes:
    • Alta disponibilidad extrema, capaz de sobrevivir a interrupciones de Internet y servicios en la nube.
    • Enrutamiento de sesiones flexible, con la capacidad de enrutar el tráfico de sesión de usuario interno directamente a los VDA mientras envía usuarios externos a través de Citrix Gateways.
    • Inicio de sesión único desde dispositivos locales administrados por el cliente.
    • La necesidad de proporcionar múltiples ‘almacenes’ con diferentes propiedades de configuración para admitir diversos casos de uso en el mismo sistema.
    • La necesidad de interfaces de usuario altamente personalizadas o de marca basadas en HTML.

Estos son los puntos más altos: hay muchos otros elementos funcionales que también puede ser importante tener en cuenta antes de elegir entre el servicio en la nube o los componentes gestionados por el cliente. Le proporcionamos una inmersión más profunda en Citrix ADC/Gateway y Citrix StoreFront en GCP en secciones posteriores. Puede utilizar diferentes combinaciones de tecnologías en cada capa para lograr resultados específicos o satisfacer necesidades específicas, a expensas de la simplicidad.

Por ejemplo: Los dispositivos Citrix ADC/Gateway VPX se pueden agregar a un sistema y utilizarse para autenticación o funcionalidad de proxy HDX al utilizar Citrix Workspace para servicios de interfaz de usuario. Esto le da al sistema la capacidad de admitir casi cualquier estrategia de identidad y autenticación (incluidos escenarios de federación), además de la capacidad de usar HDX Enlightened Data Transport para obtener el mejor rendimiento de sesión en redes subóptimas.

También puede introducir Citrix StoreFront para utilizarlo para los servicios de interfaz de usuario, en paralelo o en lugar de Citrix Workspace. StoreFront requiere Citrix ADC/Gateway para la mayoría de los casos de uso, pero esta combinación serviría para casos de uso con requisitos de alta disponibilidad extrema, requisitos de personalización de la interfaz de usuario pesados y la capacidad de crear múltiples ‘almacenes’ diferentes, con diferentes propiedades, para diferentes grupos de usuarios, propiedades de dispositivos , ubicaciones físicas, etc.

El patrón de diseño de migración a la nube

El patrón de diseño de migración a la nube está diseñado para permitir que un cliente ejecute un sistema de virtualización de Citrix heredado y Citrix Cloud en GCP en paralelo. Ambas opciones para proporcionar servicios de interfaz de usuario (servicio Citrix Workspace y Citrix StoreFront) pueden agregar recursos del entorno heredado y Citrix Cloud en una única interfaz de usuario. Esto proporciona al usuario una experiencia de acceso coherente independientemente de dónde se inicien los recursos.

Un ejemplo común: un cliente existente de Citrix, con una inversión sustancial en una implementación gestionada por el cliente de Citrix Virtual Apps and Desktops, quiere comenzar a ejecutar sus cargas de trabajo de aplicaciones y escritorios en GCP. Tal vez también tengan varias ‘comunidades Citrix’ que actualmente administran en las instalaciones. El cliente ha implementado Citrix StoreFront y, probablemente, dispositivos Citrix ADC/Gateway para proporcionar autenticación, servicios de interfaz de usuario y servicios proxy HDX.

En este caso, es probable que el cliente ya esté utilizando la capacidad de StoreFront para agregar aplicaciones y escritorios de sus múltiples ‘comunidades Citrix’ en una sola interfaz de usuario. Para empezar a moverse a Google Cloud, empezarían creando una ubicación de recursos de Citrix Cloud en una región de su elección. Suponiendo que todos están en la misma red, simplemente pueden agregar la nueva ‘comunidad Citrix’ a StoreFront e implementar su primera carga de trabajo virtualizada en Google Cloud. Esto les da la capacidad de ejecutar cargas de trabajo de Citrix en dos entornos, uno al lado del otro, algunos locales, otros en GCP, y migrar cargas de trabajo a GCP según lo permitan las prioridades empresariales.

nube migración-diseño-patrón

Este mismo cliente también puede ejecutar Citrix Workspace en paralelo con StoreFront y agregar las ‘comunidades Citrix’ heredadas a la interfaz de usuario de Workspace mediante la Agregación de sitios función Citrix Cloud. Ambas UI proporcionarían acceso a los mismos recursos para los mismos usuarios. Los usuarios finales se pueden migrar gradualmente a la interfaz de usuario del servicio Citrix Workspace según lo permitan las prioridades empresariales.

site-aggregation.png

La ventaja del enfoque de migración a la nube es que TI puede migrar las cargas de trabajo de aplicaciones y escritorios de la infraestructura local heredada a Google Cloud a un ritmo que les convenga. Los usuarios pueden seguir accediendo a sus aplicaciones y escritorios de la misma manera, independientemente de si la carga de trabajo se entrega en las instalaciones o desde Google Cloud.

Al utilizar Agregación de sitios, los clientes también pueden utilizar Citrix Analytics, proporcionándoles información sobre la seguridad, el rendimiento y las operaciones de su infraestructura local y alojada en la nube. Esto puede ayudar en el proceso de toma de decisiones sobre cuándo se debe mover una carga de trabajo de local a Google Cloud Platform. Citrix Security Analytics también se puede utilizar para garantizar que, a medida que las cargas de trabajo se distribuyan entre la infraestructura local y Google Cloud, se pueda aplicar la postura de seguridad del cliente.

Migración con Google VMware Engine

Si está considerando el patrón de diseño de migración a la nube, es probable que esté ejecutando Citrix en VMware hoy mismo. Para algunos clientes, la opción de ampliar su infraestructura basada en VMware existente a Google Cloud puede resultar atractiva. Para estos clientes, este ruta promete acelerar las migraciones de cargas de trabajo, mediante el conocimiento existente y las inversiones en procesos para llegar antes. Con Google Cloud VMware Engine, los clientes pueden aprovisionar y ejecutar centros de datos definidos por software VMware Cloud Foundation () basados en VCF (SDDC) en Google Cloud.

El servicio Virtual App and Desktops de Citrix permite el aprovisionamiento y la administración de imágenes de VDA en nubes públicas basadas en VMware VCF. Antes del lanzamiento, Google Cloud VMware Engine se sometió a una completa prueba de compatibilidad para convertirse en Citrix Ready Verificado. Ambas plataformas Citrix Provisioning (MCS y PVS) se probaron y funcionaron como se esperaba. Para obtener más información, consulte Google Cloud VMware Engine en Citrix Ready.

Cuando los clientes activan un SDDC basado en VCF mediante Google VMware Engine, el SDDC (que incluye computación, almacenamiento y redes, además de administración) está pegado a las redes VPC en Google Compute Engine. Esto le permite ejecutar cargas de trabajo en el SDDC o Google Compute Engine, proporcionando a los clientes opciones para varias cargas de trabajo. El siguiente diagrama lógico muestra la relación entre Google Cloud, Citrix Cloud y una instancia de SDDC administrada:

nube

Nota:

Los clientes que tienen un requisito firme de soporte completo de Citrix App Layering o PVS deben considerar la posibilidad de ejecutar su ubicación de recursos de Citrix Cloud en Google Cloud VMware Engine. Tanto Citrix App Layering como PVS están disponibles actualmente en plataformas basadas en VMware.

Si bien el diseño y la implementación de una solución de virtualización de Citrix en Google VMware Engine están fuera del ámbito de esta guía de diseño, la mayoría de los conceptos y componentes descritos en esta guía siguen siendo aplicables. Para obtener más información acerca de la configuración de una ubicación de recursos de Citrix Cloud en VMware (Cloud Foundation), consulte Documentación del servicio Citrix Virtual Apps and Desktops.

Resumen

Como puede ver, estos patrones proporcionan la máxima flexibilidad a los clientes existentes de Citrix y les permiten viajar a la nube según sus condiciones. No existe un enfoque prescriptivo único, sino que los clientes de Citrix pueden diseñar una solución y un enfoque de migración que mejor se adapte a su negocio. Para respaldar esto, los clientes que compren Citrix Cloud Licensing también reciben derechos de uso híbrido. Muchos clientes también tienen un Citrix Customer Success Manager asignado para guiarlos a lo largo del proceso. Consulte a su representante de ventas de Citrix para obtener más información.

Ahora que hemos recuperado un par de capas en el contexto de los patrones de diseño para la virtualización de Citrix en Google Cloud, vamos a profundizar en algunos temas más.

Consideraciones de diseño y administración de VDA

La parte más dinámica de un sistema de virtualización Citrix es el VDA. Recuerde que los VDA son los lugares donde se está realizando el trabajo real: las aplicaciones y escritorios que proporciona a los usuarios en un sistema de virtualización Citrix se ejecutan desde instancias de VM en GCP. Asegúrese de obtener esta capa correctamente, ¡pero no deje que la perfección se interponga en el camino del progreso! Haga tus deberes por delante. Establezca la expectativa con los usuarios de que el sistema cambiará con el tiempo… y construya procesos simples y efectivos para manejar el cambio: ¡es inevitable! Con la potencia y flexibilidad de la tecnología de virtualización de Citrix, la gestión del cambio no tiene que ser una carga importante.

En esta sección, hemos intentado romper lógicamente el tema para que podamos sumergirnos en profundidad sin perder contexto. Hacemos todo lo posible para proporcionarle los detalles que necesita en cada sección y dar a conocer las principales prácticas y recomendaciones a lo largo del camino.

Comenzamos examinando las diferentes opciones relacionadas con VDA para ofrecer su combinación de aplicaciones y escritorios, ¡y hay bastantes! A continuación, nos centramos en cómo configurar y usar las tecnologías de gestión de imágenes y flotas VDA de Citrix Cloud, incluidas MCS y la función Autoscale. A continuación, presentamos opciones de administración del entorno de usuario (configuración del registro, asignaciones de unidades e impresoras, etc.) y administración de la configuración de usuario (perfiles de usuario, capas de personalización, unidades domésticas, etc.), sumergimos en la optimización de costes y la gestión de la capacidad, y terminamos la sección con más ajuste del rendimiento consideraciones.

Esta es una cantidad ambiciosa de conocimiento para destilar - vamos a ir tras él!

Opciones y consideraciones de entrega de cargas de trabajo

A medida que comience su viaje de entrega de carga de trabajo, es importante que lo empecemos con el pie derecho. Eso significa tocar un par de elementos específicos que no son del VDA que deben ser considerados primero. Una de las conversaciones más importantes que un buen consultor de Citrix mantiene con un nuevo cliente es acerca de los casos de uso que va a prestar servicios. Estas conversaciones (más de una, porque las necesidades del cliente, el clima empresarial y la tecnología evolucionan con el tiempo) suelen llevar a la definición de grupos razonablemente bien definidos de usuarios y aplicaciones, los llamamos grupos de entrega. La mayoría de las opciones que vamos a desglosar en esta sección se reevalúan para cada grupo de entrega y caso de uso. Es común que los clientes tengan un poco de variación e incluso superposición entre los grupos de entrega. Sin embargo, al final del día, el elemento más fundamental de cada grupo de entrega es la combinación de aplicaciones, datos y servicios que se deben proporcionar. Una vez que lo haya definido, puede comenzar a evaluar las decisiones establecidas en esta sección.

Importante:

Para cada caso de uso o grupo de entrega, comience definiendo la combinación de aplicaciones, datos y servicios necesarios y, a continuación, trabaje en las siguientes consideraciones para decidir qué opciones de entrega pueden servir mejor para cada uno.

Sugerencia:

Los VDA se administran en una agrupación de recursos llamada catálogos de máquinas. Los catálogos de máquinas son grupos de instancias de máquinas virtuales que sirven un caso de uso común para un grupo de usuarios. Normalmente se basan en la misma plantilla de instancia de VM “maestro dorado” y heredan propiedades de instancia de VM y una copia generalizada del disco persistente.

Sistemas operativos VDA

¿Windows o Linux?

Ahora que ha definido las aplicaciones, los datos y los servicios necesarios para cada grupo de entrega/caso de uso, puede comenzar a considerar qué sistema operativo es el más adecuado para sus VDA. La pregunta más básica: ¿necesitas Windows o Linux? A menudo, esta decisión se vaya obligada por los requisitos de la aplicación o conjunto de aplicaciones que está entregando. Si la aplicación solo se ejecuta en Windows, ¡entonces Windows lo es! Lo mismo obviamente se aplica si la aplicación solo se ejecuta en Linux.

Las aplicaciones empresariales a menudo se basan en Windows, por lo que un gran porcentaje de las aplicaciones virtualizadas de Citrix se ejecutan en instancias de VM basadas en Windows en GCP. A veces se elige Windows porque es lo que el equipo de TI sabe, y el coste de hacer girar las competencias operativas en un nuevo sistema operativo como Linux se considera demasiado alto, por lo que Windows se usa incluso si el conjunto de aplicaciones puede ejecutarse en Linux. Sin embargo, si el conjunto de aplicaciones se puede ejecutar en Linux, vale la pena considerarlo: gran parte de la complejidad y una buena parte de los costes (sistema operativo Windows y licencias de cliente) se puede evitar.

SO de servidor o de escritorio?

Si puede usar Linux como sistema operativo, la elección de ‘servidor o escritorio’ es relativamente simple. Debe elegir una versión que tenga una GUI, que pueda ejecutarse en Google Cloudy sea compatible con Citrix Linux VDA.

Si implementa Windows, la elección de servidor frente a SO de escritorio se vuelve un poco más complicada. Ambas opciones comparten una interfaz gráfica de usuario común y ambas pueden presentar a los usuarios un escritorio virtual. De hecho, la mayoría de las aplicaciones Windows se ejecutan en sistemas operativos Windows Server y Windows 10 de escritorio, aunque a menudo los proveedores de aplicaciones no llaman la compatibilidad con Windows Server en su documentación. La implicación más importante de Windows Server frente a El escritorio de Windows 10 está concediéndolo, y es uno grande.

Las directivas de licencias de Microsoft son restrictivas cuando se ejecuta Windows 10 (o cualquier otro sistema operativo de escritorio) en nubes públicas. Estas restricciones basadas en directivas pueden hacer que sea más costoso ejecutar un sistema operativo de escritorio Windows en cualquier nube pública, incluido GCP. Para obtener más información acerca de las directivas de licencias de Microsoft, consulte a su especialista en licencias de Microsoft, pero lo siguiente le informará sobre este complejo tema:

Si ejecuta Windows en GCP, Windows Server sirve la mayoría de los casos de uso y mezclas de aplicaciones, y simplemente paga por el uso de licencias junto con el uso de instancias. A menudo es más rentable que un escritorio de Windows y termina siendo la opción para muchos sistemas de virtualización en Google Cloud.

¿Sistema operativo compartido (multiusuario) o un solo usuario (“VDI”)?

Una idea errónea común es que Windows Server no puede atender casos de uso de escritorio, independientemente de si está compartiendo el sistema operativo entre varios usuarios o si tiene una instancia de OS/VM por usuario. ¡Este error es falso! Cuando se implementa en modo multiusuario (es decir, el rol RDSH está instalado), Windows Server puede presentar a los usuarios un escritorio “alojado compartido”. Windows Server también se puede utilizar para casos de uso de “VDI”, y aunque no es tan rentable o escalable como la opción de SO multiusuario/compartido, es una opción legítima para un escritorio de un solo usuario. Llamamos a este modelo de entrega “Servidor VDI”.

En resumen, las siguientes combinaciones de opciones/sistemas operativos se pueden utilizar dependiendo del caso de uso:

Modelo de entrega Único o multiusuario Versiones/componentes comunes del sistema operativo Coste relativo para ejecutar en Google Cloud
Compartido alojado Multiusuario Windows Server (2016 o 2019), rol RDSH y Experiencia de escritorio habilitados.
VDI de servidor Único usuario Windows Server (2016 o 2019), Experiencia de escritorio habilitada. ⭐⭐⭐
VDI de escritorio Único usuario Windows 10 (se requieren licencias BYO y STN) ⭐⭐⭐⭐⭐

Otro concepto erróneo común es que los nodos sole-tenant (STN) de Google Cloud son necesarios para servir los casos de uso de “escritorio”. Los nodos de arrendatario único son necesarios para cumplir con los escenarios de licencias BYO de Microsoft, como el sistema operativo Windows 10 (escritorio). Como se mencionó anteriormente, Windows Server se puede utilizar para entregar un escritorio de un solo usuario (“VDI de servidor”) además de un escritorio multiusuario (hospedado compartido). Los nodos de arrendatario único también se pueden usar para instancias de Windows Server cuando trae sus propias licencias de Windows Server.

La mayoría de los sabores de Linux son capaces de múltiples usuarios de la caja. Por lo tanto, pueden implementarse en modelos Hosted Shared o “Server VDI”, con implicaciones de costes relativas similares.

Nota:

Para ayudar con el proceso de toma de decisiones, se compara el siguiente árbol de decisiones Escritorios compartidos alojados (escritorios multiusuario de SO de servidor) a escritorios VDI. El árbol no distingue explícitamente entre los modelos VDI cliente y VDI de servidor, pero las decisiones presentadas son válidas para ambos. Cuando un caso de uso sugiere que VDI es el modelo de entrega adecuado para su carga de trabajo, la VDI de servidor debe considerarse siempre que sea posible para ejecutarse en Google Cloud.

¿Escritorios publicados o aplicaciones publicadas?

Al final del día, las aplicaciones virtualizadas que entrega a los usuarios en un sistema de virtualización Citrix se ejecutan en VDA. Tiene opciones para presentarlas, lo que determina cómo interactúan los usuarios con ellos. Puede presentar al usuario o “publicar” aplicaciones y archivos individuales. También puede presentarles un escritorio en el que interactúen con aplicaciones y datos.

publicados-escritorios-publicados-aplicaciones

Ejemplo: un escritorio compartido alojado, que se presenta como una aplicación de ventana en la aplicación Citrix Workspace para Windows.

Hay más en esta opción (y muchos clientes usan ambas), pero aquí hay un intento de resumir:

Escritorios publicados (tanto compartidos alojados como VDI):

   
+ Proporcione a los usuarios una metáfora familiar para interactuar con las aplicaciones y los datos del sistema. Puede ser más fácil para los usuarios captar y obtener un uso productivo. Ideal para ofrecer entornos flexibles con muchas aplicaciones.
- Los usuarios esperan que las cosas funcionen como lo hacen en un escritorio. Está trabajando más para equilibrar la seguridad con el acceso y la funcionalidad, y está administrando un escritorio de Windows. Los perfiles de usuario, la configuración de las aplicaciones, el almacenamiento de datos y la administración de la configuración de escritorio se vuelven críticos. Doblemente, si los usuarios esperan que los ajustes se desplazen entre regiones.
- Requerir más recursos de instancia de VM: los servicios de escritorio de Windows consumen más recursos para cada usuario en comparación con las aplicaciones publicadas.

Aplicaciones publicadas:

   
+ Las aplicaciones publicadas suelen ser más fáciles de proteger, requieren menos recursos para entregar y pueden proporcionar a los usuarios una experiencia de usuario más sencilla. Citrix llama a esto “ventanas sin fisuras”.
- La experiencia del usuario puede complicarse con un mayor número de aplicaciones publicadas.
+ Todavía requiere la administración de perfiles de usuario, configuración de aplicaciones y almacenamiento de datos, pero a menudo es más simple y con más flexibilidad en la ejecución en comparación con los escritorios publicados.
+ Requerir menos recursos de instancias de VM frente a Presentación del escritorio de Windows. Por lo general, varias aplicaciones publicadas se ejecutan dentro de la misma sesión: una función Citrix llama a compartir sesiones.

¿Acordado o persistente?

Esta opción es otra propiedad del catálogo de máquinas y se define al crear el catálogo. El modelo de entrega compartida alojado generalmente utiliza VDA agrupados/no persistentes, pero ambos modelos VDI pueden utilizar catálogos de máquinas agrupados o persistentes. Con el modelo agrupado, MCS restablece las instancias del sistema operativo al cerrar sesión o reiniciar el VDA. Este modelo garantiza que los usuarios obtengan una imagen de sistema “limpia”, que a su vez se basa en su plantilla o instancia de máquina virtual de ‘imagen dorada’ e instantáneas de su disco persistente. Se los conoce como ‘agrupados’ como un grupo de agentes VDA se mantienen y los usuarios se conectan dinámicamente a un VDA disponible/no utilizado en el grupo. La configuración del usuario y los datos se pueden administrar de varias maneras diferentes. Con los agentes VDA agrupados, se manejan de manera que el usuario obtenga la misma configuración y experiencia independientemente del VDA en el que haya iniciado sesión. Consulte Administración del entorno de usuario/configuración en este documento para obtener más detalles sobre este tema.

Los catálogos de máquinas persistentes contienen instancias de VDA asignadas a usuarios individuales y persisten entre reinicios. Este modelo es útil para escenarios en los que los usuarios necesitan instalar sus propias aplicaciones (como entornos de desarrollador) y casos de uso en los que las aplicaciones necesarias no son compatibles con varios usuarios.

Las instancias agrupadas tienden a ser las más fáciles de administrar con el tiempo, ya que el MCS de Citrix puede actualizar los discos del sistema conectados a instancias agrupadas con unos pocos clics. La gestión de la capacidad y los costes también tiende a ser más eficaz, ya que un grupo inactivo de instancias puede servir a muchos usuarios. Las instancias agrupadas son un poco menos flexibles que las dedicadas, ya que los cambios en las instancias agrupadas no suelen persistir entre los reinicios. Tecnologías como Capa de personalización de usuarios de Citrix pueden utilizarse para persistir los cambios iniciados por el usuario en las sesiones en diferentes VDA agrupados, aunque solo es compatible con los casos de uso de “VDI” de un solo usuario.

Las instancias persistentes pueden ser más sencillas de implementar, pero más difíciles de administrar con el paso del tiempo, ya que tiene que manejar la aplicación de parches, actualizaciones y mantenimiento de OS/aplicaciones dentro de la máquina virtual. También puede ser más costoso desde una perspectiva de coste/capacidad, ya que a menudo es difícil predecir cuándo un usuario iniciará sesión. Esto significa que los usuarios deben esperar mientras se inicia su instancia o los administradores deben mantenerlos ejecutándose durante las ventanas de tiempo en las que se espera que cada usuario inicie sesión.

¿Administrado o no administrado?

Los catálogos creados y administrados por MCS pueden contener clones persistentes o no persistentes de instancias de VM de plantilla (o “maestro dorado”). Los catálogos de máquinas también se pueden aprovisionar con otro proceso o tecnología. De cualquier manera, desea asegurarse de que se creen como administrados de energía:

administrado-no administrado

Si no utiliza catálogos de máquinas administradas con energía, las funciones clave como Citrix Autoscale no funcionarán y no tendrá ayuda para administrar los costes y la capacidad. El uso de MCS para el aprovisionamiento y la administración de flotas de VDA aporta una serie de beneficios útiles a los administradores, pero también se pueden utilizar los VDA “no administrados” (aquellos aprovisionados fuera de Citrix). Cubrimos esos beneficios Gestión de flotas e imágenes más adelante en esta guía.

¿Aceleración de GPU?

Ciertos tipos de aplicaciones implementadas en VDA pueden beneficiarse de los recursos de GPU si están disponibles para la instancia de máquina virtual. Los tres modelos de entrega (alojados compartidos, VDI de servidor y VDI de escritorio, tanto para Linux como para Windows) pueden utilizar NVIDIA acelerado Instancias de GPU para cargas de trabajo de gráficos en Google Cloud. Estas GPU de estaciones de trabajo virtuales se pueden conectar a tipos de máquinas N1 de uso general para cargas de trabajo de uso intensivo de gráficos, como visualización 3D, diseño de chips, CAD/CAM, edición de gráficos y vídeo, e incluyen la licencia GRID requerida.

Con el controlador NVIDIA GRID adecuado instalado en la instancia, el software VDA de Citrix detecta la presencia de GPU y se configura adecuadamente.

Sugerencia:

La pila de protocolos de visualización HDX de Citrix realiza muchas funciones de autodetección y adaptación sobre la marcha para proporcionar la mejor experiencia posible al usuario. Sin embargo, también trata de equilibrar el rendimiento, la capacidad de respuesta y la riqueza de la UX con el consumo de ancho de banda. Por lo tanto, las cargas de trabajo con un uso intensivo de gráficos a menudo se benefician de algunos ajustes para obtener el equilibrio correcto. Consulte Descripción general de gráficos HDX para obtener más información. Tenga en cuenta que Citrix proporciona una plantilla de directiva denominada “Experiencia de usuario de muy alta definición” (como se describe en Diseño de directiva de línea base). Esta plantilla se puede utilizar como punto de partida para ajustar con precisión su entorno específico.

Gestión de flotas e imágenes

La virtualización de Citrix en Google Cloud incluye funciones integradas diseñadas para simplificar el aprovisionamiento de VDA y la administración de imágenes a escala. Estas funciones se denominan a menudo “Machine Creation Services” o MCS para abreviar. MCS utiliza cuentas de servicio IAM en Google Cloud para facilitar la administración de VDA en GCP.

Sugerencia:

Antes de sumergirse en la configuración y el uso de MCS en GCP, revise la documentación de Citrix sobre cómo configurar y usar MCS en Entornos de virtualización de Google Cloud Platform. Este documento le guía a través de la habilitación de las API de Google Cloud, la creación y configuración de la cuenta de servicio de IAM, la creación de conexiones y recursos de alojamiento y mucho más.

Problemas y limitaciones de MCS

MCS tiene un par de limitaciones importantes que debe conocer antes de implementar un sistema de virtualización Citrix en GCP hoy mismo. Dado que el conjunto de funciones de MCS se entrega como un servicio en la nube, puede esperar que esta lista cambie con el tiempo a medida que evolucione el servicio. Mientras tanto, necesita saber acerca de ellos para poder ajustar su plan de diseño y ejecución en consecuencia.

Las actuales problemas/limitaciones conocidas son:

  • Aprovisionamiento de VDA de Linux. MCS en GCP no se ha probado completamente para el aprovisionamiento de VDA de Linux, por lo que esta opción no es compatible actualmente. Ejecutar VDA Linux en Google Cloud, incluso con GPU conectadas, es. Para evitar este problema: aprovisionar instancias de VM Linux fuera de MCS mediante plantillas de Google Deployment Manager u otro mecanismo y, a continuación, agregue instancias previamente aprovisionadas a un catálogo de máquinas administrado con energía para la asignación y la administración de energía.

Importación de imágenes de VDA desde locales

Las imágenes VDA personalizadas son algo que muchos clientes ya pueden tener y quieren usar en GCP. Si bien es preferible implementar una nueva instancia nueva y configurarla desde cero, hay momentos en los que puede que no sea factible. Por ejemplo, puede haber una imagen base que se haya configurado de forma local en la que no se conocen los propietarios de aplicaciones o las dependencias de las aplicaciones, pero se confían en las operaciones empresariales críticas. Afortunadamente, en GCP puede importar su imagen local a GCP. La importación también es necesaria cuando se implementan variantes de SO cliente Windows (es decir, Windows 10), ya que los sistemas operativos cliente Windows no están disponibles de forma nativa en el catálogo de imágenes de Google Cloud. Para obtener más información, consulte importar un disco virtual.

Nota:

Antes de importar un disco existente, asegúrese de leer y comprender las diferencias importar un disco virtual de su entorno local. Siempre que sea posible, es preferible implementar nuevas instancias desde la biblioteca de imágenes pública y crear las imágenes maestras desde cero.

Uso de nodos sole-tenant en GCP

Google Cloud tiene una función denominada nodos sole-tenant que son útiles para varios casos de uso traer su propia licencia para el sistema operativo Windows, incluidos e implementación de VDA cliente de Windows en GCP. Al configurar nodos sole-tenant, puede configurarlos en una o más zonas dentro de una región GCP. Citrix MCS admite completamente el aprovisionamiento de VDA en nodos sole-tenant, pero no es consciente automáticamente de qué zonas GCP se implementan en los nodos sole-tenant. Si tiene la intención de implementar VDA en nodos de sole-tenant, asegúrese de consultar la Selección de zona GCP documentación para obtener más detalles.

Nota:

Para obtener un buen tutorial sobre la implementación de Windows 10 en GCP, consulte la Arrendatario único de Windows 10 de GCP con POC de creación de catálogo de VPC compartida opcional guía. El artículo cubre tanto la importación de imágenes personalizadas como el uso de nodos sole-tenant en GCP.

Optimización de costes y administración de capacidad

Cuando se ejecutan agentes VDA en Google Cloud, está pagando por los recursos informáticos, de almacenamiento y de red que utiliza. Esto significa que existe una correlación directa entre la cantidad de capacidad que consume y los costes en los que incurre. Las decisiones que toma y las prácticas que adopta tienen una correlación directa con el coste operativo del sistema de virtualización.

En primer lugar, asegúrese de elegir las opciones de entrega de carga de trabajo correctas: Los temas que acaba de leer si está leyendo esto de frente a atrás. ¡Estos pueden tener un impacto dramático en el coste total de la solución! Estas son algunas otras recomendaciones y temas a tener en cuenta a medida que trabaje para equilibrar el coste con la capacidad y optimizar la experiencia del usuario.

Aprovisionamiento bajo demanda

Cuando utiliza MCS para crear catálogos de máquinas no persistentes en Compute Engine, MCS utiliza el aprovisionamiento bajo demanda para reducir los costes de almacenamiento, proporcionar una creación de catálogos más rápida y proporcionar operaciones de potencia de instancias más rápidas. Con el aprovisionamiento bajo demanda, las instancias de Compute Engine solo se crean cuando el servicio Citrix Virtual Apps and Desktops inicia una acción de encendido. El aprovisionamiento bajo demanda se utiliza para catálogos de máquinas no persistentes.

Nota:

Algunos administradores consideran que el aprovisionamiento bajo demanda es confuso inicialmente, ya que las instancias de VDA no se muestran en la consola de Google Cloud hasta que MCS las encienda. Además, dado que las instancias reciben una nueva NIC virtual y una dirección MAC, las entradas DNS de Active Directory pueden tardar algún tiempo en actualizarse o replicarse correctamente. Los discos de identidad VDA NO persisten entre los reinicios y los eventos de creación/eliminación.

Ajuste del tamaño de las instancias de VDA

Ahora que ha obtenido alguna información sobre las decisiones importantes relacionadas con las opciones de entrega de cargas de trabajo, profundicemos en el tamaño correcto de las instancias de VDA. Para Modelos de entrega basados en VDI, seleccionar el tipo de instancia correcto es sencillo. Suponiendo que ha hecho algunos deberes y tiene una comprensión decente de los requisitos de recursos del sistema operativo, las aplicaciones y los usuarios de las instancias de VDI, puede simplemente asignar estos requisitos a tipos de instancia disponibles en la región de Google Cloud los que prefiera. No se preocupe si no tiene una combinación perfecta entre los tipos de instancias disponibles y los requisitos de carga de trabajo. Google Cloud admite tipos de instancia personalizados, que le permiten ajustar la forma de tus instancias de VDA a medida que avales. Los descuentos por uso sostenido y uso comprometido todavía se aplican a los tipos de instancias personalizadas, así que no permita que eso le disuada de ajustar según sea necesario para obtener el tamaño correcto por adelantado.

Además, la recomendaciones de tamaño función de Google Cloud se puede utilizar para identificar los ajustes en las formas VDA que desee realizar con el tiempo.

Ajuste del tamaño de las instancias de VDA

Nota:

Una cosa importante a tener en cuenta: el consumo de recursos de carga de trabajo puede cambiar con el tiempo. A veces, los eventos/actividades reducen los requisitos de recursos, como cuando un administrador aplica optimizaciones al entorno. Por el contrario, a veces estos requisitos aumentan, como cuando se aplica parches a una vulnerabilidad de SO o aplicación, o se aplica una actualización. Encuentre su base, pero es importante monitorear las tendencias de consumo a lo largo del tiempo y ajustar según sea necesario para encontrar el equilibrio óptimo entre el rendimiento del usuario y los costes.

Al seleccionar el tamaño de instancia correcto para los VDA compartidos alojados, las cosas se complican un poco más. Lo que está buscando en última instancia es un objetivo móvil: el equilibrio adecuado entre rendimiento, coste y capacidad de administración. Para complicar aún más las cosas, cada carga de trabajo es diferente. Las diferencias entre el sistema operativo, las aplicaciones, la configuración, el ajuste y las expectativas del usuario hacen que sea difícil definir las formas adecuadas para sus VDA. También tiende a cambiar con el tiempo.

Afortunadamente, las herramientas y técnicas para encontrar que los ‘Ricitos de Oro’ equilibrio entre rendimiento, coste y manejabilidad son bien conocidas y están completamente documentadas. Un excelente artículo que recomendaríamos comenzar con es Citrix Scalability in a Cloud World Edición 2018. Este artículo sigue siendo relevante hoy en día, ya que analiza las prácticas líderes en relación con la selección de instancias basadas en el rendimiento, la capacidad de administración, el coste, los modelos de precios disponibles y las pruebas de escalabilidad de LogInVSI. Estos conceptos y consideraciones siguen siendo válidos hoy en día, a pesar de que las opciones de instancia y los precios probablemente hayan cambiado desde su publicación inicial.

Otro artículo digno de mención es Tamaño adecuado de Citrix en Google Cloud Platform. Aunque un poco de fechas, este artículo profundiza aún más en las consideraciones y proporciona un ejemplo de cómo encontrar el tipo de instancia más rentable basado en el escalado de VDA único y los costes de la instancia.

Por último, para obtener información adicional sobre las estrategias para optimizar los costes de VDA, consulte esta información Resumen técnico de escala automática en Citrix TechZone. Ayuda a alinear las estimaciones de costes de instancia con las capacidades de la Citrix Autoscale función, incluido el uso del equilibrio de carga vertical.

Hablando de Citrix Autoscale, léalo y utilícelo: con un poco de pensamiento y un diseño inteligente, puede optimizar los costes de su flota de VDA y, al mismo tiempo, garantizar que tiene capacidad disponible para manejar las fluctuaciones esperadas e inesperadas en la demanda del sistema.

Hablando de patrones de demanda, desea invertir algo de tiempo y recursos para comprender los patrones únicos de cada carga de trabajo. Espere que cambien y evolucionen con el tiempo, y prepárese para ajustar su estrategia y tácticas de gestión de la capacidad para adaptarse.

Elegir los modelos de precios adecuados

Google Cloud ofrece varios precios modelos diferentes que los clientes pueden utilizar para los diferentes tipos de cargas de trabajo que ejecuta allí. Comprender los patrones de demanda para diferentes casos de uso puede ayudarle a elegir el modelo adecuado para cada recurso a fin de equilibrar el coste y la disponibilidad del servicio y el rendimiento. En un sistema de virtualización Citrix, los clientes suelen considerar el uso sostenido frente a modelos de descuento de uso comprometido para los recursos que se ejecutan en GCP. Los descuentos por uso sostenido pueden variar entre los tipos de instancia (N1 frente a N2, por ejemplo) y algunos tipos de instancias (como E2) no ofrecen descuentos de uso sostenido. Consulte Precios de instancias de VM para obtener más detalles.

A continuación se muestra un gráfico simplificado que ilustra el uso sostenido frente a los descuentos de uso comprometido para los tipos de instancia N1:

optimización de costes

Algunos recursos son únicos, altamente escalables y deben estar disponibles para que un sistema de virtualización Citrix funcione. Como tales, comúnmente se ejecutan las 24 horas del día, los 7 días de la semana y se implementan N+1 para la disponibilidad, y son excelentes candidatos para el descuento de uso comprometido. Esto incluye las instancias de Active Directory, Citrix Cloud Connectors, Citrix ADC/Gateway VPX y Citrix StoreFront VM.

Para las instancias de VDA, la elección no es tan simple, pero cuanto más claramente entienda sus patrones de demanda, más clara será la elección. Todo se reduce a cuánto tiempo necesita encenderse el VDA. Considere el siguiente gráfico (específico para los tipos de instancia N1), que es reproducible con un poco de matemáticas de fondo del sobre:

equilibrio

Este diagrama muestra que si un recurso (que se ejecuta en un tipo de instancia N1) estará activo durante más del 50% del tiempo durante un ciclo de facturación determinado, comenzará a ahorrar dinero si puede aplicar un descuento de uso comprometido durante 3 años. El punto de descanso en un descuento de uso comprometido de 1 año es de aproximadamente 82%. Si un recurso se va a encenderse durante más de eso durante un ciclo de facturación y el uso comprometido de 3 años no está disponible, entonces un uso comprometido de 1 año tiene sentido.

Consideraciones de ajuste del rendimiento

Muchos factores pueden contribuir a la percepción del rendimiento que los usuarios obtienen en su sistema de virtualización Citrix. Además de seleccionar la forma correcta de instancia de VM para sus VDA, otras áreas clave para investigar para la optimización del rendimiento son las siguientes:

Opciones de administración de configuración y entorno de usuario: las directivas son su amigo cuando administra y optimiza el rendimiento de sus usuarios. Las directivas controlan la configuración de Windows, aplicaciones, sesiones y mucho más. Para complicar aún más las cosas, hay varios motores de directivas que puede utilizar potencialmente, cada uno con su propio impacto en la experiencia del usuario. Elegir el motor de directivas adecuado y establecer líneas de base coherentes son importantes, y afortunadamente se tratan en profundidad Diseño de directiva de línea base. Además, Citrix Workspace Environment Management Service puede utilizar para optimizar la experiencia del usuario y simplificar la administración en un entorno diverso.

Optimización de Windows: Windows es un sistema operativo de propósito general y está diseñado para cubrir una amplia variedad de casos de uso, tipos de hardware, etc. Muchas de las configuraciones predeterminadas de Windows son innecesarias en un entorno de virtualización de Citrix. Afortunadamente Citrix Optimizer está disponible para ayudar e incluye muchas plantillas integrales que puede aplicar a sus VDA para obtener el mejor rendimiento posible y el menor uso general de recursos.

Ajuste antivirus: ejecutar software antivirus en Citrix VDA e infraestructura de soporte es una práctica sólida y recomendada. Sin embargo, si se instala o configura incorrectamente, puede causar estragos en la experiencia del usuario. Vea Prácticas recomendadas para Endpoint Security y antivirus para obtener una gran imprimación sobre cómo hacerlo bien.

Optimización del protocolo HDX: lapila de protocolos de pantalla HDX de Citrix realiza muchas funciones de autodetección y adaptación sobre la marcha para proporcionar la mejor experiencia posible al usuario. Intenta equilibrar el rendimiento, la capacidad de respuesta y la riqueza de la UX con el consumo de ancho de banda. En algunos casos de uso (como cargas de trabajo intensivas de gráficos o conexiones de red de baja o mala calidad) a menudo se benefician de algunos ajustes para obtener el equilibrio correcto. Consulte Descripción general de gráficos HDX para obtener más información. El SD-WAN de Citrix también puede ayudar a optimizar y medir la experiencia de usuario HDX.

Además, Citrix proporciona varias plantillas de directivas de sesión predefinidas que se pueden utilizar para adaptar de forma flexible la configuración a sus casos de uso específicos. Estas directivas se configuran y administran en Citrix Cloud Studio y se pueden aplicar mediante varios filtros. Estos filtros le permiten asegurarse de que se aplica la directiva correcta para optimizar escenarios específicos.

Optimización del protocolo HDX

Administración del entorno de usuario/configuración

Diseñar y administrar la configuración y los datos del usuario es uno de los elementos más complejos e importantes de un sistema de virtualización Citrix. Cuando se hace bien, el inicio de sesión/cierre de sesión es rápido y confiable. Las aplicaciones están preconfiguradas para los usuarios y los usuarios obtienen una experiencia coherente y predecible independientemente del VDA en el que inicien sesión. Cuando se hace mal o se ignora, la experiencia del usuario puede sufrir drásticamente.

Afortunadamente, las decisiones de administración de configuración y entorno de usuario son comunes en todos los sistemas de virtualización de Citrix, independientemente de los agentes VDA de plataforma que se implementen en. También están completamente documentados. Estas decisiones dependen en gran medida de la ubicación del usuario, la conectividad del usuario final y los requisitos de seguridad. Como tal, no vamos a tratar este tema en profundidad aquí, pero empezamos con algunas referencias. Hay muchas opciones disponibles que se pueden adaptar a sus necesidades específicas.

Los siguientes son algunos vínculos para comenzar:

   
Workspace Environment Management Service Workspace Environment Management Service utiliza tecnologías inteligentes de administración de recursos y Profile Management para ofrecer el mejor rendimiento posible, inicio de sesión en escritorios y tiempos de respuesta de aplicaciones para las implementaciones de Citrix Virtual Apps and Desktops.
Diseño de directiva de línea base En este artículo se describen varias decisiones de directivas que se deben tomar al usar directivas de Citrix.
Profile Management Un artículo que describe algunas prácticas recomendadas cuando se trata de Profile Management.
Planificar la implementación Un gran recurso para ayudar a planificar Profile Management en un sistema de virtualización Citrix.
Capa de personalización de usuarios de Citrix Para casos de uso de VDI (un solo usuario, instancia de sistema operativo único), la tecnología de capa de personalización de usuarios de Citrix se puede utilizar para simplificar drásticamente la administración del sistema. Citrix UPL permite a los administradores utilizar catálogos de máquinas agrupados/no persistentes, al tiempo que proporciona a los usuarios una experiencia de usuario coherente y personalizada en todas las instancias de VDA. La capa de usuario se conserva como archivo de disco duro virtual en un recurso compartido de archivos de Windows. Se monta en el VDA en el momento del inicio de sesión y captura los cambios del usuario dentro de la sesión, incluidas las aplicaciones instaladas por el usuario. La capa de usuario se monta en el VDA al iniciar sesión y se separa al cerrar sesión.

Almacenamiento de archivos y replicación de datos

La mayoría de los sistemas de virtualización Citrix en GCP requieren al menos acceso básico a un recurso compartido de archivos compatible con Windows para mantener la configuración del usuario, los datos de usuario y los datos de aplicaciones. Los recursos compartidos de archivos de Windows también se utilizan para almacenar Capas de personalización de usuarios de Citrix. Cuando estos recursos compartidos no están disponibles, la experiencia del usuario y la funcionalidad de la aplicación se ven afectadas. Es importante asegurarse de que cualquiera que sea la solución que elija proporcionar, los recursos compartidos de archivos compatibles con Windows estén altamente disponibles y se realice una copia de seguridad periódica de los datos.

Para implementaciones en varios sitios, también puede ser necesaria una replicación de datos confiable y eficiente para satisfacer las necesidades de disponibilidad, RPO y RTO. Esto es especialmente cierto para entornos donde los usuarios pueden conectarse a escritorios/aplicaciones en 2 o más regiones, y los datos de la aplicación/configuración de usuario deben estar disponibles en la región donde se ejecutan las aplicaciones o escritorios. La siguiente sección describe algunas soluciones a tener en cuenta para proporcionar servicios de almacenamiento de archivos y replicación de datos en GCP.

Aunque existen soluciones que no son de Windows para proporcionar recursos compartidos de archivos de Windows, la mayoría de estas soluciones no pueden ofrecer las capacidades de indexación necesarias para la funcionalidad de búsqueda dentro de un escritorio de Windows o aplicaciones como Microsoft Outlook que se ejecutan en Windows. Como tal, la mayoría de los clientes recurren a soluciones de servidor de archivos basadas en Windows, al menos para almacenar perfiles de usuario y datos de aplicaciones persistentes. Afortunadamente, tanto las opciones de servicio gestionado por el cliente como en la nube están disponibles para su uso cuando los sistemas de virtualización Citrix se ejecutan en GCP.

Administrado por el cliente: servidores de archivos Windows en Google Compute Engine

La primera solución que muchos clientes consideran para proporcionar servicios de archivos compatibles con Windows en GCP es crear sus propios servidores de archivos Windows en Compute Engine para servir cada ubicación de recursos en GCP. Dado que los servidores de archivos de Windows son necesarios para varios tipos diferentes de aplicaciones y cargas de trabajo, muchos talleres de TI pueden trabajar para crear y administrar los suyos propios, ya que esto es algo que saben hacer. En el nivel más básico, el cliente crea una o más instancias de Windows, adjunta discos más persistentes, une las instancias a su Active Directory y termina de configurar los Servicios de archivos de Windows.

Esta opción, como se puede imaginar, proporciona a los clientes el mayor control y flexibilidad. Aunque esto es muy atractivo para ciertos tipos de clientes y ciertos verticales, también tiene un coste: la responsabilidad de dimensionar, escalar, construir, administrar, aplicar parches, proteger y mantener todo desde el sistema operativo Windows hasta. Los clientes que opten por seguir esta ruta también deben asegurarse de que estos file servers estén altamente disponibles. Esto se logra a menudo mediante servidores de archivos en varias zonas y mediante Windows DFS-N/DFS-R Clusters de conmutación por error de Windows, o espacios de almacenamiento directamente. Es fácil terminar en una configuración no admitida (por Microsoft) si no tienes cuidado.

Nota:

Los clientes que consideren esta opción deben revisar Declaración de soporte técnico de Microsoft el uso de DFS-R y DFS-N para recursos compartidos de perfil itinerante y recursos compartidos de redirección de carpetas.

Terceros

Una solución alternativa es el uso de soluciones de terceros como Volúmenes en la nube de NetApp ONTAP o el Servicios de Cloud Volumes para GCP. Ambas soluciones le permiten crear recursos compartidos SMB compatibles que se pueden utilizar para sus necesidades de almacenamiento. El uso de soluciones de almacenamiento de terceros ofrece ventajas en lugar de administrar sus propios servidores de archivos de Windows, como una menor sobrecarga administrativa al administrar el almacenamiento. Consulte Servidores de archivos en el motor de computación para obtener más información.

Citrix ADC/Gateway VPX en Google Cloud

La implementación de Citrix ADC/Gateway en GCP es diferente de implementarlo en las instalaciones, aunque al final se administra usted mismo. Afortunadamente, la implementación de Citrix ADC/Gateway en GCP está completamente documentada. Recomendamos revisar los siguientes recursos antes de solidificar el diseño y comenzar la implementación:

  • Citrix ADC VPX en GCP en Citrix Docs: proporciona una visión general completa de Citrix ADC en GCP, incluidos modelos VPX compatibles, regiones GCP, tipos de instancias de Computer Engine y otras referencias de recursos.
  • Implementaciones de Citrix ADC VPX GCP Marketplace: Todas las soluciones de implementación de redes Citrix disponibles en GCP Marketplace. Funcional y relevante para las implementaciones de Citrix Gateway con CVAD/CVADS también.
  • Plantillas de GDM Citrix ADC: un repositorio de GitHub para plantillas GDM de Citrix ADC. Esta es una excelente referencia para un repositorio que aloja plantillas de Citrix ADC para implementar una instancia de Citrix ADC VPX en Google Cloud Platform.

Como se explica Citrix ADC VPX en GCP en Citrix Docs, hay dos opciones de implementación principales disponibles. Se trata de:

  • Independiente: las instancias individuales de Citrix ADC/Gateway se pueden implementar y administrar como entidades independientes. Esto se utiliza comúnmente para implementaciones de menor escala o POC donde la alta disponibilidad no es un requisito.
  • Alta disponibilidad: Este es el modelo más utilizado para entornos de producción: los pares de instancias de Citrix ADC/Gateway VPX se pueden implementar mediante una configuración de alta disponibilidad dentro de la misma zona o en varias zonas de la misma región. Excavamos esta opción más profundamente más adelante en esta sección.

Práctica recomendada:

Al implementar dispositivos Citrix ADC/Gateway en GCP, se recomienda utilizar direcciones IP externas de nivel Premium (regional). Al utilizar IP externas de nivel premium, el tráfico entra y sale de la ubicación de red perimetral más cercana al usuario. El tráfico atraviesa la red privada de Google para llegar a la región donde se implementa el recurso. Esto proporciona un mejor rendimiento, menor latencia y un rendimiento más consistente (menor fluctuación) en comparación con las direcciones IP externas de nivel estándar. Para obtener más información, consulta Google Cloud Niles de servicio de red.

ADC autónomo

Si bien Citrix ADC VPX generalmente admite tipos de implementación de NIC individuales, dobles o múltiples, Citrix recomienda utilizar al menos tres redes VPC para cada ADC cuando se implementa en GCP, con una interfaz de red en cada VPC para un rendimiento óptimo y separación de datos. Cuando se implementa para admitir Citrix Virtual Apps and Desktops, la interfaz de administración (NSIP) normalmente se conecta a la “Subred privada de infraestructura Citrix”, la IP de subred (SNIP) está conectada a la “Subred privada de Citrix VDA” y la IP virtual de Citrix Gateway (VIP) a la “Subred Pública”. El siguiente diagrama conceptual simplificado muestra esta configuración. Muestra una única instancia VPX en una sola zona: este patrón de diseño se duplicaría (probablemente en una segunda zona) para una configuración de alta disponibilidad:

ADC autónomo

A continuación se muestra una tabla que muestra el propósito de cada NIC junto con la red VPC asociada:

NIC Propósito Red VPC asociada
NIC 0 Sirve tráfico de administración (NSIP) (❶) Red de gestión
NIC 1 Sirve tráfico del lado del cliente (VIP) (❷) Red pública
NIC 2 Se comunica con servidores back-end (SNIP) (❸) Red de servidor back-end

Importante:

Las instancias de Citrix ADC VPX con tres NIC requieren un mínimo de 4 vCPU cuando se ejecutan en GCP. Consulte número máximo de interfaces de red para obtener más información.

Alta disponibilidad de ADC en todas las zonas

Como se mencionó anteriormente, este es el modelo de implementación más común para los sistemas de virtualización Citrix. Este modelo utiliza un par de Citrix ADC VPX en una única región implementada en varias zonas. La alta disponibilidad (activo/pasiva) se puede lograr de múltiples maneras. Puede utilizar un equilibrador de carga HTTPS de GCP con los ADC configurados de forma independiente entre sí o mediante Citrix ADCs HA configurado en modo Configuración de red independiente (INC). Se espera que esta última opción/arquitectura sea popular para las implementaciones en la nube pública, por lo que nos centramos en eso aquí.

Si bien existen posibles variantes para una arquitectura Citrix ADC/Gateway VPX en GCP, el siguiente diagrama muestra una solución de tres NIC de Citrix ADC HA. Esta solución se puede implementar Plantilla del Administrador de implementaciones con redes y subredes VPC preconfiguradas:

conceptual-arquitectura

Cuando utilice la plantilla de Google Deployment Manager, debe configurar las redes de VPC antes de implementar los dispositivos Citrix ADC. Las tres redes VPC deben consistir en la red de administración (❶), (❷) la red pública y (❸) la red de servidor backend y las subredes apropiadas dentro de cada red VPC.

flujo de tráfico

En el diagrama anterior, podemos ver que cada ADC tiene una IP virtual de puerta de enlace (VIP) diferente. Esta es una función de un Configuración de red independiente (INC). Cuando las VPX de un par HA residen en zonas diferentes, el ADC secundario debe tener una INC, ya que no pueden compartir direcciones IP asignadas, LAN virtuales o rutas de red. El NSIP y el SNIP son diferentes para cada ADC en esta configuración, mientras que el VIP de Citrix Gateway utiliza un Función de Citrix ADC llamada IPSetservidor virtual o multi-IP. Esta función se puede utilizar para clientes de diferentes subredes para conectarse al mismo conjunto de servidores. Con IPSet, puede asociar una IP privada a cada una de las instancias primaria y secundaria. A continuación, se puede asignar una IP pública al ADC principal en el par. En el caso de la conmutación por error, la asignación de IP pública cambia dinámicamente al nuevo primario.

Para obtener más información sobre cómo agregar un nodo remoto a un ADC para crear un par HA basado en INC-, consulte documentos de Citrix. Para obtener información general sobre la implementación de HA para ADC en la nube de Google, consulte Implementar un par de alta disponibilidad VPX en Google Cloud Platform.

Citrix StoreFront en Google Cloud

Citrix StoreFront es un componente de la pila de virtualización de Citrix que proporciona servicios de interfaz de usuario y también desempeña un papel en su estrategia de autenticación. StoreFront se puede ver como el predecesor administrado por el cliente del servicio Citrix Workspace, y se ha utilizado para front-end sistemas de virtualización de Citrix durante más de una década. StoreFront se entrega como un MSI/EXE descargable y se instala en una o más instancias de Windows Server. Varias instancias de StoreFront pueden compartir datos de configuración (y, opcionalmente, de suscripción) mediante la creación de grupos de servidores StoreFront. Para crear un subsistema de alta disponibilidad se utilizan varias instancias, front-end por un equilibrador de carga con reconocimiento de servicios como el dispositivo Citrix ADC/Gateway.

La implementación de Citrix StoreFront en Google Cloud no es muy diferente de implementarlo en las instalaciones. Al final, también administrará todos los componentes de StoreFront usted mismo.

Consulte las consideraciones Planificar una implementación de StoreFront generales que se aplican a todas las implementaciones, incluido StoreFront en Google Cloud.

La principal diferencia con StoreFront en GCP es que normalmente se implementan varias instancias de StoreFront en un grupo de servidores StoreFront en varias zonas de Google Cloud. Es importante tener en cuenta que las entidades habilitadas con este diseño dependen de la latencia entre zonas. Por lo Planifique su implementación/escalabilidad de StoreFronttanto, las implementaciones de grupos de servidores StoreFront solo se admiten cuando los vínculos entre servidores de un grupo de servidores tienen una latencia inferior a 40 ms (con suscripciones inhabilitadas) o menos de 3 ms (con suscripciones habilitadas). Aunque la latencia entre zonas en GCP suele ser inferior a 1 ms, asegúrese de medir las latencias entre instancias en todas las zonas en las que planea hospedar StoreFront y habilitar/inhabilitar las suscripciones en consecuencia.

Ya lo hemos llamado un par de veces antes en este documento, pero vale la pena llamarlo de nuevo: para entornos con requisitos de resiliencia extensos, Citrix recomienda encarecidamente una implementación de StoreFront para beneficiarse plenamente de la función Local Host Cache de Citrix Virtual Apps and Desktops servicio. Esta arquitectura proporciona resiliencia en caso de que Cloud Connectors no pueda llegar a Citrix Cloud. Si esto sucede, los usuarios podrán conectarse a sesiones nuevas y existentes durante un caso de interrupción. Para obtener más detalles, limitaciones e implicaciones de la activación de la caché del host local, consulte Caché de host local (CVADS).

Como se mencionó anteriormente, las implementaciones de StoreFront en Google Cloud deberían abarcar varias zonas de Google Cloud para obtener alta disponibilidad, pero recuerde tener en cuenta el diseño de Citrix ADC/Gateway. Normalmente, se recomienda utilizar Citrix ADC/Gateway delante de instancias de StoreFront para proporcionar equilibrio de carga, supervisión avanzada y mayor resistencia del servicio.

Virtualización de Citrix en Google Cloud