Arquitectura de referencia: Citrix Virtualization 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.

Empezamos por revisar los patrones de diseño comunes para 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, analizaremos los componentes y requisitos de la solución. Presentamos los requisitos previos de la solución y le ofrecemos una descripción general de los servicios y componentes necesarios para crear una “ubicación de recursos” de Citrix Cloud.

Luego revisamos y profundizamos 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, como el diseño y la administración de Virtual Delivery Agent (VDA), NetScaler ADC/Gateway en Google Cloudy Citrix StoreFront en Google Cloud.

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. Exploraremos esta modularidad de los subsistemas cuando revisemos estos tres patrones de diseño más adelante 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 infraestructura ni licencias existentes, y se puede crear en menos de 30 minutos con plantillas de Google Deployment Manager, como el proyecto GitHub de Citrix on GCP.
  • Proporciona alta disponibilidad de todos los servicios críticos.
  • Crea una “ubicación de recursos” de Citrix Cloud, la base de los otros dos patrones descritos aquí.

Todo lo que necesita para empezar es un proyecto de GCP y acceder a una suscripción a Citrix Desktops-as-a-Service (DaaS). 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 a los nuevos clientes una prueba gratuita que incluye 300 USD de crédito de Google Cloud.

Nota:

La prueba gratuita de GCP no incluye el uso de imágenes de Windows Server, como se indica en el documento de la capa gratuita de Google Cloud. Para usar imágenes de Windows Server, debe actualizar a una cuenta de pago en GCP. Los créditos gratuitos seguirán aplicándose al actualizar a una cuenta de pago, como se indica en la sección Actualización a una cuenta de pago del documento Capa gratuita de 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 la sofisticada tecnología HDX de Citrix para ofrecer 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 NetScaler Gateway Service configurando la directiva de “rendezvous”. Las instancias de VM pueden contar con el respaldo de las GPU de Google Cloud para crear estaciones de trabajo virtuales y, a su vez, acelerar 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 la aplicación Citrix Workspace (❺) (CWA) para conectarse e interactuar con aplicaciones y escritorios virtualizados mediante el innovador protocolo de comunicación remota de sesiones HDXde Citrix. 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 DaaS: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 costos 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.
  • NetScaler Gateway Service: proporciona acceso seguro a aplicaciones y escritorios virtualizados, además de aplicaciones web empresariales, a dispositivos en redes públicas.
  • Citrix Analytics Service: utiliza tecnologías avanzadas de aprendizaje automático para proporcionar informes y análisis de comportamiento de usuarios, rendimiento y seguridad de nivel empresarial.

Este patrón de diseño también se puede combinar con una VPN o interconexión de Google Cloud para extender las inversiones existentes en Active Directory (❽) a Google Cloud o para proporcionar acceso a aplicaciones e infraestructuras tradicionales, locales y administradas por el cliente.

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 Desktops-as-a-Service (DaaS) (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 NetScaler Gateway (servicio en la nube)
Análisis Citrix Analytics Service (servicio en la nube)

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, en el caso de las implementaciones de producción, suele ampliarse al conectar la ubicación de los recursos en GCP a los centros de datos gestionados por los clientes mediante Google Cloud VPN , Google Cloud Interconnect . 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. Si bien no se muestra en el diagrama anterior, el servicio Citrix Workspace Environment Management se usa comúnmente, especialmente a medida que los sistemas se dirigen 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 información.

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:

  • NetScaler ADC/Gateway(❷): implementado como dispositivos virtuales en GCP, este componente se usa 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.

hybrid-design-pattern

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 NetScaler 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 NetScaler ADC/Gateway, que maneja la autenticación además de los servicios proxy de sesión de UI y HDX.

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 DaaS (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 NetScaler ADC/Gateway (gestionado por el cliente)
Proxy de sesión HDX NetScaler Gateway Service (servicio en la nube) O NetScaler ADC/Gateway (gestionado por el cliente)
Análisis Citrix Analytics Service (servicio en la nube)

Hay muchos otros elementos funcionales que puede que también le parezca 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 NetScaler 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 NetScaler 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 los escenarios de federación), además de la capacidad de utilizar el Enlightened Data Transport de HDX 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 NetScaler 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 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.

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 NetScaler 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.

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.

cloud-migration-design-pattern

Este mismo cliente también puede ejecutar Citrix Workspace en paralelo con StoreFront y agregar las “granjas de Citrix” heredadas a la interfaz de usuario de Workspace mediante la función Citrix Cloud Site Aggregation . 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.

Con Site Aggregation, los clientes también pueden usar Citrix Analytics, lo que les brinda 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 (SDDC ) basados en VMware Cloud Foundation(VCF) en Google Cloud.

Citrix DaaS permite el aprovisionamiento y la administración de imágenes de los VDA en nubes públicas basadas en VMware VCF. Antes del lanzamiento, Google Cloud VMware Engine se sometió a una prueba de compatibilidad integral para convertirse en Citrix Ready Verified. 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:

cloud

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 Cloud VMware Engine están fuera del alcance de esta guía de diseño, la mayoría de los conceptos y componentes que se describen en esta guía siguen siendo aplicables. Para obtener más información sobre la configuración de una ubicación de recursos de Citrix Cloud en VMware (Cloud Foundation), consulte la documentación de Citrix DaaS.

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
  • Una suscripción a Citrix DaaS

Nota:

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

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

Sugerencia:

La documentación de Citrix DaaS es relevante, ya que este servicio es la base 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 fiable 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, usar el servicio administrado de Google para Microsoft Active Directoryo 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 de Active Directory funcionales, el Servicio administrado de Google para Microsoft Active Directory (para abreviar Microsoft AD administrado) 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 PUEDE 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 tratar los niveles funcionales de Active Directory compatibles , en este artículo también se abordan los escenarios de implementación de 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 la descripción general de DNS de Google Cloud para obtener más información.

La resolución de nombres DNS también es importante al implementar la función Rendezvous de Citrix para el proxy de sesión HDX, incluido el uso del transporte adaptativo EDT/Citrix. Consulte la documentación del protocolo Rendezvous para obtener más información.

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 las instancias para 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 se puede redirigir mediante proxy.

Nota:

Para obtener más información sobre los puertos y protocolos que utilizan las tecnologías de virtualización de Citrix, consulte Puertos de comunicación utilizados por 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íjase directamente a Consideraciones de diseño y administración de VDA

Nota:

Consulte Puertos de comunicación que utiliza 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 de Internet, la función “protocolo de encuentro” se puede habilitar mediante la directiva de Citrix, lo que permite que los dispositivos cliente (que ejecutan la aplicación Citrix Workspace) y el VDA se conecten de forma segura a través del servicio NetScaler 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 NetScaler ADC/Gateway administradas por el cliente en el perímetro de la VPC.

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 sus 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 un grupo de recursos denominado 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 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 se pueda ejecutar en Google Cloudy que 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.

SO compartido (multiusuario) o usuario único (“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, el siguiente árbol de decisiones compara los escritorios compartidos alojados (escritorios multiusuario con SO de servidor) con los 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.

Aplicaciones publicadas o escritorios publicados

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.

published-desktops-published-apps

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.

Combinado 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. Las tecnologías como la capa de personalización de usuarios de Citrix se pueden utilizar para conservar los cambios iniciados por el usuario en las sesiones de diferentes VDA agrupados, aunque solo es compatible con 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 gestionado

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:

managed-unmanaged

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). Cubriremos estos beneficios en Gestión de flotas e imágenes más adelante en esta guía.

Aceleración 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 usar instancias de GPU aceleradas de NVIDIA 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 llamada “Experiencia de usuario de muy alta definición” (como se describe en Diseño de políticas de referencia). Esta plantilla se puede utilizar como punto de partida para ajustar con precisión su entorno específico.

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 correctas de entrega de cargas de trabajo, los temas que acaba de leer si está leyendo esto de principio a fin. ¡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 Citrix DaaS 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 los modelos de entrega basados en VDI, seleccionar el tipo de instancia correcto es sencillo. Suponiendo que haya hecho algunos deberes y conozcas bien los requisitos de recursos del sistema operativo, las aplicaciones y los usuarios de las instancias de VDI, puede simplemente asignar estos requisitos a los tipos de instancias disponibles en la región de Google Cloud que elijas. 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 instancias personalizados, que le permiten modificar la forma de las instancias de VDA sobre la marcha. 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 función de recomendaciones de tamaño de Google Cloud se puede utilizar para identificar los ajustes en las formas de los VDA que quieras hacer 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 supervisar 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 artículo excelente con el que recomendaríamos empezar es Citrix Scalability in a Cloud World 2018 Edition. 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 que vale la pena mencionar es el tamaño correcto 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 los VDA, consulte este informe técnico de escalabilidad automática en Citrix TechZone. Ayuda a alinear las estimaciones de costes de las instancias con las capacidades de la función de escalabilidad automática de Citrix, 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.

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 políticas correcto y establecer líneas de base consistentes son importantes y, afortunadamente, se tratan en profundidad en el Diseño de políticas de referencia. Además, el servicio Citrix Workspace Environment Management se 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 ayudarlo e incluye muchas plantillas integrales que puede aplicar a sus VDA para obtener el mejor rendimiento posible y la menor utilización 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. Consulte Prácticas recomendadas de seguridad de endpoints y antivirus para obtener informació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.

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

Elegir los modelos de precios adecuados

Google Cloud ofrece varios modelos de precios diferentes que los clientes pueden usar para los diferentes tipos de cargas de trabajo que ejecutas 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. Consulta los precios de las instancias de VM para obtener más información

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:

optimizing-cost

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, NetScaler 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:

break-even

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.

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 fiable 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. A menudo, esto se logra mediante servidores de archivos en varias zonas y mediante Windows DFS-N/DFS-R, clústeres de conmutación por error de Windowso espacios de almacenamiento de forma directa. Es fácil terminar en una configuración no admitida (por Microsoft) si no tienes cuidado.

Nota:

Los clientes que estén considerando esta opción deben revisar la declaración de soporte de Microsoft con respecto al uso de DFS-R y DFS-N para compartir perfiles móviles y recursos compartidos de redirección de carpetas.

Terceros

Una solución alternativa es utilizar soluciones de terceros, como Cloud Volumes ONTAP de NetApp o Cloud Volumes Services 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. Consulta Servidores de archivos en Compute Engine para obtener más información.

Citrix NetScaler VPX en Google Cloud

La implementación de Citrix NetScaler Gateway en GCP es diferente a la implementación local, aunque al final los administra usted mismo. Afortunadamente, la implementación de Citrix NetScaler en GCP está bien documentada. Recomendamos revisar los siguientes recursos antes de solidificar el diseño y comenzar la implementación:

  • Citrix NetScaler VPX en GCP en Citrix Docs: proporciona una descripción general completa de Citrix NetScaler en GCP, incluidos los modelos VPX compatibles, las regiones de GCP, los tipos de instancias de Computer Engine y otras referencias de recursos.
  • Implementacionesde Citrix NetScaler VPX en GCP Marketplace : todas las soluciones de implementación de redes de Citrix disponibles en GCP Marketplace. También es funcional y relevante para las implementaciones de Citrix Gateway con Citrix Virtual Apps and Desktops y Citrix DaaS.
  • PlantillasGDM de Citrix NetScaler: un repositorio de GitHub para plantillas de GDM de Citrix NetScaler. Esta es una referencia excelente para un repositorio que aloja plantillas de Citrix NetScaler para implementar una instancia de Citrix ADC VPX en Google Cloud Platform.

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

  • Independiente: las instancias individuales de Citrix NetScaler 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 que se implementa con más frecuencia en los entornos de producción: se pueden implementar pares de instancias de Citrix NetScaler Gateway VPX 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:

Cuando implementes dispositivos Citrix NetScaler Gateway en GCP, te recomendamos usar direcciones IP externas de nivel Premium (regionales). 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 Niveles del servicio de red deGoogle Cloud.

NetScaler independiente

Si bien Citrix NetScaler VPX generalmente admite tipos de implementación de NIC únicas, dobles o múltiples, Citrix recomienda usar al menos tres redes de VPC para cada NetScaler cuando se implementa en GCP, con una interfaz de red en cada VPC para un rendimiento y una separación de datos óptimos. Cuando se implementa para admitir Citrix Virtual Apps and Desktops, la interfaz de administración (NSIP) suele estar conectada a la “Subred de infraestructura privada de Citrix”, la IP de subred (SNIP) está conectada a la “Subred privada de Citrix VDA” y la IP virtual de NetScaler 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:

NetScaler independiente

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 NetScaler VPX con tres NIC requieren un mínimo de 4 vCPU cuando se ejecutan en GCP. Consulte el número máximo de interfaces de red para obtener más información.

Alta disponibilidad de NetScaler 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 VPX de Citrix NetScaler en una sola región implementadas en varias zonas. La alta disponibilidad (activo/pasiva) se puede lograr de múltiples maneras. Puedes usar un balanceador de cargas HTTPS de GCP con los NetScalers configurados de forma independiente o con Citrix NetScalerSS HA configurado en el 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 la arquitectura Citrix NetScaler Gateway VPX en GCP, el siguiente diagrama muestra una solución Citrix NetScaler HA de tres NIC. Esta solución se puede implementar mediante la plantilla de Google Deployment Manager con redes y subredes de VPC preconfiguradas:

conceptual-architecture

Al utilizar la plantilla de Google Deployment Manager, debe configurar las redes de VPC antes de implementar los dispositivos Citrix NetScaler. 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.

traffic-flow

En el diagrama anterior, podemos ver que cada NetScaler tiene una IP virtual (VIP) de puerta de enlace diferente. Esta es una característica de una configuración de red independiente (INC). Cuando las VPX de un par de alta disponibilidad residen en zonas diferentes, el NetScaler secundario debe tener un INC, ya que no pueden compartir direcciones IP, LAN virtuales ni rutas de red mapeadas. El NSIP y el SNIP son diferentes para cada NetScaler de esta configuración, mientras que el Citrix Gateway VIP utiliza una función de Citrix NetScaler llamada IPSet, o servidores virtuales con varias direcciones 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 NetScaler para crear un par de alta disponibilidad basado en INC, consulte los documentos de Citrix. Para obtener información general sobre la implementación de alta disponibilidad para NetScaler en Google Cloud, consulte Implementar un par de alta disponibilidad VPX en Google Cloud Platform.

Arquitectura de referencia: Citrix Virtualization en Google Cloud