Arquitectura de referencia: Citrix DaaS — AWS

Público y objetivo

Este documento pretende ayudar a los socios y clientes de Citrix a comprender las decisiones de diseño más críticas necesarias para implementar con éxito las tecnologías de virtualización de Citrix en la nube pública de Amazon. No pretende ser una referencia de “procedimientos”; Citrix considera esas guías de implementacióny ahora se entregan y mantienen por separado de las arquitecturas de referencia. En este documento, utilizamos Citrix Architectural Design Framework para organizar y presentar las principales prácticas, recomendaciones y patrones de diseño que utilizan Citrix y los socios consultores seleccionados de Citrix.

Visión general y resumen ejecutivo

Las tecnologías de virtualización y redes de Citrix han respondido satisfactoriamente a las necesidades de las empresas grandes y pequeñas durante casi tres décadas. Hay muchas maneras en que estas tecnologías pueden ser licenciadas, implementadas, integradas y administradas. Esta flexibilidad permite que las tecnologías Citrix atienden varios casos de uso, tipos de negocio, requisitos de integración y modelos operativos diferentes. Este documento está escrito para el cliente o socio de Citrix que está considerando o planea implementar estas tecnologías en la infraestructura de nube pública de AWS.

Tanto para los clientes existentes que buscan modernizar su infraestructura como para los nuevos clientes que quieren implementar tecnologías de virtualización y redes de Citrix, hay varias decisiones clave de alto y bajo nivel que deben tomarse a lo largo del ruta para facilitar una implementación correcta. Para ayudar a los clientes y socios a comprender estos puntos de decisión, hemos introducido y definido una terminología específica para establecer el contexto apropiado y, a continuación, hemos utilizado este contexto para resaltar las decisiones e implicaciones críticas a tener en cuenta al planificar su implementación.

Comenzamos definiendo dos modelos de adopción de tecnología primaria: Servicios gestionados por el cliente y servicios en la nube. A continuación, dividimos los componentes de un sistema de virtualización Citrix en varios subsistemas y los clasificamos según el modelo de adopción:

Modelo de adopción/función del subsistema Gestionado por el cliente (instalado desde binarios descargados) Servicio en la nube (proporcionado a través de Citrix Cloud)
Intermediación y administración de sesiones Citrix Virtual Apps and Desktops (CVAD) Citrix DaaS (DaaS)
Servicios de interfaz de usuario (UI) Citrix StoreFront Citrix Workspace (el servicio utilizado a través de la aplicación Citrix Workspace o el explorador web)
Autenticación Citrix StoreFront (más Citrix ADC/Gateway para la mayoría de los casos de uso) Citrix Workspace (más Citrix ADC/Gateway para ciertos casos de uso)
Proxy de sesión HDX Citrix ADC/Gateway Citrix Gateway Service

Adoptamos por los servicios en la nube, recomendando que la mayoría de las organizaciones utilicen o planean usar servicios en la nube cuando sea factible. No ofrecemos este soporte a ciegas, si bien creemos que los servicios en la nube, al final, ofrecen beneficios abrumadoramente positivos para nuestros clientes, reconocemos que no todas las organizaciones/implementaciones pueden utilizar servicios en la nube para todos los subsistemas hoy en día. A veces, los requisitos de casos de uso (con atributos técnicos o deficiencias en un servicio en la nube actualmente disponible/específico) necesitan adoptar una combinación de servicios en la nube y un componente gestionado por el cliente: nos centramos en estos en este documento. En otros casos, elementos no técnicos (directiva, consideraciones presupuestarias/contractuales, deficiencias de preparación para la nube, consideraciones de regulación/cumplimiento, etc.) pueden desalentar el uso de servicios en la nube. En estos casos, le recomendamos trabajar con su socio, ventas o equipo de ingeniería de Citrix para ayudarlo a superarlos. En el resto de este artículo, nos esforzamos mucho para identificar capacidades, funciones o atributos clave que ayudan a los clientes a decidir qué modelo de adopción usar para qué subsistema y cuándo.

A continuación, definimos y examinamos tres casos de implementación comunes, destacando qué modelo de adopción se utiliza para cada subsistema:

  • Greenfield/Cloud únicamente: Utiliza servicios en la nube para todos los subsistemas de virtualización de Citrix, además de servicios de nube pública de AWS.
  • Híbrido (que no debe confundirse con una “nube híbrida”): el modelo de implementación más común, el modelo híbrido utiliza DaaS para la intermediación y administración de sesiones, con opciones de servicios gestionados por el cliente y en la nube para los subsistemas restantes.
  • Lift and Shift: Como indica su nombre, este modelo utiliza CVAD, StoreFront y ADC/Gateway existentes gestionados por el cliente y migra estos componentes a AWS tal cual, o bien los instala en AWS como parte de una migración de carga de trabajo a los servicios de nube pública de AWS. Si bien este es un modelo de implementación válido para ciertos casos de uso específicos, viene con importantes advertencias.

Por último, utilizamos el bien documentado Citrix Architectural Design Framework para organizar y presentar las decisiones clave de diseño que deben tenerse en cuenta al implementar la tecnología de virtualización de Citrix en AWS. Nos centramos en “qué es diferente de Citrix on AWS” para mayor claridad, proporcionando enlaces a otros recursos para obtener información más detallada según sea necesario.

En última instancia, recomendamos que la mayoría de los clientes utilicen el modelo de implementación híbrida desde el primer día, mediante el servicio CVAD para la intermediación y administración de sesiones. Esto proporciona al cliente las capacidades clave necesarias para ejecutar de forma rentable un sistema de virtualización Citrix en AWS, reduce sustancialmente el coste y la complejidad, proporciona acceso a las últimas funciones y capacidades disponibles y simplifica la migración y el uso de otros servicios en la nube en el futuro. Los servicios en la nube O los componentes gestionados por el cliente se pueden utilizar para los subsistemas restantes (dependiendo de las necesidades específicas de los clientes), aunque recomendamos que los clientes tengan claro por qué están mediante componentes gestionados por el cliente y tengan un plan para pasar a servicios en la nube en el futuro una vez que los servicios en la nube satisfacer sus necesidades específicas.

Para obtener más información sobre las prácticas líderes de Citrix on AWS, los lectores pueden consultar los siguientes artículos de la guía para la nube:

Conceptos clave y casos de implementación

En esta sección, describimos algunos conceptos clave y casos de implementación antes de sumergirnos en consideraciones específicas para cada capa de Citrix Architectural Design Framework.

Modelos de adopción de tecnología

La tecnología Citrix DaaS se puede “consumir” o implementar de muchas maneras diferentes. Los métodos más comunes se pueden describir generalmente como servicios gestionados por el cliente y en la nube. También vale la pena mencionar un tercer modelo: Partner Managed. Describimos este modelo aquí para mayor claridad, pero desde la perspectiva del diseño arquitectónico, los dos primeros son los más relevantes.

¿Por qué estamos discutiendo modelos de adopción de tecnología en una arquitectura de referencia? La elección del modelo de adopción o de “consumo” tiene un impacto sustancial en el diseño del sistema, las capacidades, el coste y la delineación de las responsabilidades de gestión. Esta sección definirá y explorará estos modelos y proporcionará algunas orientaciones generales para ayudar a los clientes a tomar decisiones informadas mientras diseñan un sistema de virtualización Citrix.

Administrado por el cliente

Durante muchos años, las empresas que querían consumir tecnología no tuvieron más remedio que comprar, instalar, configurar y mantener toda la pila de tecnología necesaria para crear un sistema de virtualización Citrix. El software de virtualización de Citrix solo estaba disponible como binarios instalables. Los clientes que compraron el software de virtualización de Citrix descargarían estos archivos binarios (a menudo en forma de imagen de disco ISO descargable o ejecutables autoextraíbles) y luego instalarían, configuran y mantienen el software ellos mismos. El software Citrix (y el hardware de red) se instalaba más comúnmente en o en la infraestructura que el cliente poseía y mantenía, en centros de datos que también poseían y mantenían.

Conceptualmente hablando, un sistema de virtualización Citrix está compuesto por varios componentes diferentes de Citrix, muchos de los cuales describimos en detalle en este documento. También requieren diferentes capas de componentes de terceros que deben proporcionarse antes de que pueda hacer cualquier cosa con los bits de Citrix. En última instancia, todos ellos se unen para crear un sistema de virtualización funcional de Citrix. En aras de la claridad, este documento se refiere a este modelo de adopción de tecnología como “Customer Managed”. Utilizamos este término para describir varios componentes diferentes en un sistema de virtualización Citrix, incluidos los componentes de terceros necesarios en las capas situadas debajo, junto a los componentes de Citrix y “encima” de los componentes de Citrix. Este modelo también se puede llamar “Autogestionado”.

Hoy en día, los clientes tienen alternativas convincentes a un modelo de adopción gestionado por el cliente, pero algunos todavía adoptan elementos de su pila de tecnología mediante este modelo por varias razones. Si bien este modelo proporciona a los clientes el mayor control sobre cada componente, tiene un coste: el cliente asume la responsabilidad de administrar y mantener el componente, lo que incluye la seguridad, el funcionamiento, la aplicación de parches, la actualización y el mantenimiento de alta disponibilidad. Este modelo también se utiliza comúnmente para sistemas “aislados” (aquellos que no tienen acceso a Internet y, por lo tanto, tienen una capacidad limitada para utilizar servicios en la nube, a los que se accede de forma habitual y segura a través de redes públicas).

A continuación se muestra un ejemplo de la arquitectura de un sistema de virtualización Citrix que utiliza componentes 100% gestionados por el cliente implementados en AWS mediante servicios básicos de AWS IaaS como Elastic Compute Cloud (EC2) y redes de nube privada virtual (VPC). Estamos discutiendo algunos de los detalles de esta arquitectura en secciones posteriores de este documento, aunque usted puede notar inmediatamente las similitudes con el modelo de implementación mucho más simple de greenfield/solo cloud:

Diagrama 1: Implementación Lift and Shift 100% gestionada por el cliente con AWS solo como IaaS Diagrama 1: Implementación de elevación/cambio 100% gestionada por el cliente con AWS solo como IaaS.

Servicios en la nube

En los últimos 15 años, los avances tecnológicos en muchos campos diferentes han dado lugar a nubes públicas a gran escala, servicios sofisticados en la nube, arquitecturas de microservicios, marcos de entrega DevOps y ágil, modelos de licencias de suscripción y software y sistemas “siempre verdes”. Estos avances han revolucionado la forma en que se adquiere, adopta, suministra y mantiene la tecnología en casi todas las industrias del mundo.

Hoy en día, muchos de los componentes o capas que componen un sistema de virtualización Citrix están disponibles “como servicio”. A diferencia del modelo de adopción gestionado por el cliente (en el que los clientes compran tecnología como activo corporativo y construyen o mantienen sistemas por sí mismos), los clientes se “suscriben” a varios servicios, y el proveedor de servicios asume la responsabilidad de entregar y administrar estos servicios. Estos servicios a menudo se consumen a través de redes públicas (es decir, Internet), lo que lleva a algunos a llamar a este modelo de adopción de “Servicio en la nube” o “Servicio web”. En este artículo vamos a referirnos a este tipo de modelo de adopción como “Servicios gestionados en la nube”, o simplemente el modelo “Cloud Service”.

Citrix ofrece muchos de sus productos tradicionales ‘como servicio’, mediante los últimos avances tecnológicos de sus socios de plataforma para simplificar y agilizar la adopción, acelerar el ritmo de innovación, mejorar la calidad y ofrecer más valor incremental a sus clientes con el tiempo. Citrix llama a esta plataforma de prestación de servicios “Citrix Cloud” y representa el estado actual y futuro de la técnica de Citrix.

A continuación se muestra un ejemplo de la arquitectura de un sistema que utiliza 100% componentes de servicio en la nube para un sistema de virtualización Citrix en AWS. Estamos discutiendo los detalles de este diseño en una sección posterior de este documento:

Diagrama 2: 100 % de servicios en la nube en AWS con servicios gestionados de AWS Diagrama 2: 100 % de servicios en la nube en AWS con servicios gestionados de AWS

Administrado por socios

Aunque muchas organizaciones eligen crear su propio sistema de virtualización Citrix, algunos clientes buscan salir del negocio de administración de TI para que puedan centrar los recursos y la atención en servir a sus propios clientes y mercados. Para atender a estos clientes, Citrix trabaja con socios de integración que utilizan tecnologías Citrix para proporcionar un servicio de “productos acabados” a sus clientes.

Definir y diferenciar los diferentes socios de integración, tipos y ofertas disponibles están fuera del ámbito de este documento. Sin embargo, los partners de Citrix se enfrentan a las mismas opciones a las que se enfrentan los clientes al diseñar un sistema de virtualización Citrix. El partner de Citrix puede optar por utilizar uno o más servicios de Citrix Cloud, o puede elegir crear y administrar algunos componentes del sistema para las necesidades específicas de sus clientes. Por lo tanto, la orientación que se proporciona en este documento es relevante tanto para el partner de Citrix como para sus clientes, solo por diferentes razones.

Componentes del sistema de virtualización Citrix

Para comprender las implicaciones de las decisiones de diseño que detallamos más adelante en este documento, vamos a colocar los componentes de un sistema de virtualización de Citrix en “cubos” de mayor nivel que utilizaremos para guiar su proceso de toma de decisiones. Todos los sistemas de virtualización de Citrix, independientemente de cómo se implemente y se otorguen licencias, necesitan estos componentes disponibles para funcionar y proporcionar la mejor experiencia de usuario y más segura. No es raro que los clientes combinen y combinen componentes autogestionados y servicios en la nube, especialmente si tienen requisitos complejos de casos de uso, requisitos de integración de terceros o necesidades extremas de control o disponibilidad.

En la siguiente tabla se destacan estos componentes clave para mayor claridad. Detalles y recomendaciones sobre cuándo usar una opción frente a otra se tratan más adelante en este documento:

Modelo de adopción/función del subsistema Gestionado por el cliente (instalado desde binarios descargados) Servicio en la nube (proporcionado a través de Citrix Cloud)
Intermediación y administración de sesiones - El núcleo de cualquier sistema de virtualización Citrix: sin este subsistema central, no tiene aplicaciones ni escritorios, y no puede administrarlos. Este subsistema es donde se definen, aprovisionan y actualizan los catálogos de máquinas (colecciones de instancias de Citrix Virtual Delivery Agent o VDA). También es donde se crean grupos de entrega, se asignan aplicaciones o escritorios a los usuarios y se administran el entorno y las sesiones de usuario. CVAD - Citrix Virtual Apps and Desktops, ya sea versiones Long Term Service Release (LTSR) o versiones Current Release (CR). Si instala y configura un controlador de entrega en su entorno, esto es lo que está ejecutando. También significa que está instalando y administrando su propia infraestructura de Microsoft SQL Server. Las funciones administrativas de una implementación gestionada por el cliente (CVAD) incluyen Citrix Director y Citrix Studio. Los instala, configura y administra usted mismo mediante binarios LTSR/CR. Director también requiere la infraestructura de Microsoft SQL Server. Las licencias de Citrix también forman parte de este subsistema, ya que los clientes instalan, configuran y administran servidores de licencias y archivos de licencias de Citrix. DaaS: Citrix DaaS, quese entrega a través de Citrix Cloud. Si inicie sesión en Citrix Cloud e instala y registra conectores Cloud en su entorno, está mediante este servicio Citrix Cloud. Instala y registra Cloud Connectors en una instancia de Windows que administra y, a continuación, Citrix las mantiene siempre verdes y disponibles. Citrix Cloud también proporciona y mantiene la mayoría de las funciones administrativas a través de un explorador web a través de la consola de Citrix Cloud. Esto incluye las versiones de servicio en la nube de Citrix Studio y Citrix Director. No hay infraestructura adicional para que el cliente pueda mantener, mantener la alta disponibilidad o parche/actualizar: Citrix es el propietario de esta responsabilidad administrativa.
Servicios de interfaz de usuario (interfaz de usuario): Las aplicaciones nativas de Citrix Workspace (y los exploradores web para acceso sin cliente) se conectan finalmente a una URL. Los administradores de TI configuran el subsistema detrás de la URL para que coincida con los requisitos corporativos de autenticación y para presentar aplicaciones y escritorios virtualizados, aplicaciones SaaS y posiblemente mucho más para que los usuarios accedan. Citrix Storefront. También instalado/configurado desde binarios CVAD LTSR o CR, esta función proporciona una flexibilidad extrema para los casos de implementación más complejos. Normalmente se implementa en pares, con instancias de Citrix ADC/Gateway delante de ellas para obtener alta disponibilidad. Puede agregar y presentar aplicaciones y escritorios tanto de entornos gestionados por el cliente (CVAD) como de entornos gestionados/con intermediación (DaaS) de Citrix Cloud. Citrix Workspace (el servicio, no la aplicación Citrix Workspace). Se proporciona como un servicio en la nube a través de Citrix Cloud e incluye muchas capacidades de próxima generación que solo están disponibles con este servicio. Puede agregar y presentar aplicaciones y escritorios tanto de entornos gestionados por el cliente (CVAD) como de entornos gestionados/con intermediación (DaaS) de Citrix Cloud.
Autenticación: En este contexto, nos referimos a cómo se autentican los usuarios antes de acceder a aplicaciones virtualizadas y escritorios, archivos, aplicaciones SaaS y mucho más de Citrix. La autenticación en un entorno Citrix normalmente se configura en la capa de servicios de interfaz de usuario, aunque Citrix ADC/Gateway también se puede utilizar para la autenticación en todos los modelos de implementación. Cada una de las opciones del proveedor de servicios de interfaz de usuario (Citrix StoreFront o Citrix Workspace) tiene diferentes opciones de autenticación disponibles, algunas requieren un Citrix ADC/Gateway administrado por el cliente. Citrix StoreFront (más Citrix ADC/Gateway para la mayoría de los casos de uso). Los servicios de autenticación de usuarios se pueden proporcionar de varias maneras diferentes, aunque en última instancia requieren una instancia de Active Directory y cuentas de usuario válidas. Normalmente, el cliente administra la instancia de AD. Las instancias de Citrix ADC/Gateway también se pueden utilizar para proporcionar servicios de autenticación y proporcionar un montón de capacidades avanzadas que se utilizan comúnmente para entornos más complejos. Citrix Federated Authentication Services (FAS) también se puede instalar y utilizar para proporcionar SSO de sesión en casos de uso complejos. Citrix Workspace (más Citrix ADC/Gateway para ciertos casos de uso). Con Citrix Workspace (el servicio), los orígenes y requisitos de autenticación de usuario se configuran una vez para el arrendatario de Citrix Cloud y los utilizan todos los usuarios que utilizan esta URL. Está configurado para Active Directory de forma lista para usar, pero para casos de uso avanzados, se puede configurar para admitir otros proveedores de autenticación. Algunos ejemplos incluyen Azure AD, Okta, Citrix Gateway administrado por el cliente, Google Cloud ID u otros proveedores SAML/OpenID/RADIUS. Algunos casos requieren Citrix ADC/Gateways administrados por el cliente y Citrix Federated Authentication Services (FAS) para obtener la mejor experiencia de usuario.
Proxy de sesión HDX: la capacidad de conectar de forma segura y transparente usuarios/dispositivos fuera de la red corporativa privada a aplicaciones y escritorios entregados por CVAD/DaaS en el interior. AppliancesCitrix ADC/Gateway: Estos dispositivos (o instancias) suelen proporcionar una tonelada de funcionalidad adicional para un sistema de virtualización Citrix. Sin embargo, su trabajo principal es proxy de sesiones HDX de forma segura a sus VDA cuando los clientes están en redes públicas. Requiere instalación, configuración, certificados SSL, etc. Compatible con StoreFront (servicios de interfaz de usuario administrados por el cliente) y el servicio en la nube Workspace. También es compatible con las opciones de intermediación de sesiones administradas por Citrix y gestionadas por el cliente. Citrix Gateway Service: Proporcionado por Citrix Cloud, este servicio hace de intermediario con el tráfico de sesiones HDX a sus VDA y utiliza la infraestructura administrada de Citrix para realizar el trabajo. No requiere direcciones IP públicas, certificados SSL ni reglas de firewall de entrada para funcionar. Compatible con el servicio Citrix Workspace y las opciones de intermediación de sesiones administradas por Citrix Cloud y administradas por el cliente (CVAD y DaaS).

Prácticas líderes y recomendaciones

Ya sea que gestione el sistema de virtualización Citrix usted mismo o utilice Citrix o un socio autorizado para hacerlo, considere la posibilidad de utilizar servicios en la nube siempre que sea posible. Para casos de uso o entornos en los que el servicio en la nube no satisface sus necesidades, se pueden utilizar componentes gestionados por el cliente. Dicho esto: Citrix anima a los clientes a que tengan claro por qué están implementando componentes autogestionados y que estén preparados para migrar a servicios en la nube una vez que el servicio en la nube satisfaga sus necesidades específicas. Los servicios en la nube proporcionados por Citrix a través de Citrix Cloud están evolucionando rápidamente. Con el tiempo, puede esperar que proporcionen toda la funcionalidad necesaria para servir a todos los casos de uso excepto los más complejos. En última instancia, los servicios de Citrix Cloud minimizan la cantidad de infraestructura que el cliente es responsable de administrar y mantener. Citrix Cloud también proporciona servicios preintegrados de alta disponibilidad y garantiza que los clientes siempre tengan acceso a los servicios más recientes, más seguros y ricos en funciones.

Modelos de implementación comunes para Citrix Virtualization en AWS

Como proveedor de nube con la mayor funcionalidad, mayor comunidad de clientes, experiencia y madurez inigualables, AWS vaya a una amplia gama de clientes de diversas industrias trasladando sistemas e infraestructura a sus nubes. Con el tiempo han visto desarrollar casos de implementación/patrones de migración comunes. En esta sección, exploramos estos patrones o casos, analizamos cuándo y dónde puede considerar utilizarlos para llevar una carga de trabajo de Citrix Virtual Apps and Desktops a AWS, y ofrecemos algunas recomendaciones sobre los patrones que se deben tener en cuenta para casos de migración comunes.

Los tres casos más comunes para la entrega de Citrix Apps and Desktops en AWS son:

  • Implementación Greenfield/Solo en la nube, mediante los servicios de Citrix Cloud con “ubicaciones de recursos” en el servicio Amazon EC2 (Amazon Elastic Compute Cloud). Este caso se utiliza comúnmente cuando los clientes prefieren ir a un modelo de suscripción y externalizar la infraestructura del plano de control y la responsabilidad de administración a Citrix, o buscan experimentar o evaluar las capacidades proporcionadas por los servicios de Citrix Cloud.
  • Implementaciónhíbrida o migración de cargas de trabajo a AWS, mediante servicios de Citrix Cloud para intermediación y administración de sesiones, Workspace UI o StoreFront para agregar contenido, presentación de sesión/inicio de sesión, y también puede utilizar Citrix ADC/Gateways administrado por el cliente para proxy de sesión HDX, complejo casos de autenticación, o ambos.
  • Lift and Shift. Con este caso, los clientes básicamente trasladan o reimplementan su infraestructura autogestionada de Citrix a AWS, tratando la implementación en AWS del mismo modo que la implementación gestionada por el cliente existente. Con este caso, los clientes utilizan Citrix ADC/Gateway y Citrix StoreFront para agregar recursos de sitios locales y alojados en AWS. Esto facilita la migración de cargas de trabajo a AWS, aunque los clientes pueden mantener sus cargas de trabajo locales alrededor y simplemente agregar otro sitio en AWS. El nuevo sitio se puede utilizar para nuevas cargas de trabajo o para admitir casos de uso de recuperación ante desastres (DR) y failover. Este modelo se caracteriza por el uso de componentes administrados por el cliente para intermediación y administración de sesiones, servicios de interfaz de usuario, autenticación y proxy de sesión HDX.

En esta sección se definen estos casos con más detalle, incluidas las vistas generales arquitectónicas de cómo se diseña comúnmente cada caso. Usted encuentra que la práctica líder es utilizar los servicios de Citrix Cloudy, como tal, este documento se centrará en los modelos de implementación de intermediación de Citrix Cloud (“Greenfield” e “Hybrid”).

Implementación Greenfield

El ejemplo más común del modelo de implementación de campo verde es las implementaciones de prueba o prueba de concepto de la tecnología de virtualización de Citrix en la nube de AWS. Como esencialmente está comenzando desde cero, se puede experimentar la potencia de la ‘infraestructura como código’ ya que no está tratando de integrarse con un montón de ‘cosas ‘existentes. También es una oportunidad fantástica para “jugar con” varios servicios en la nube y evaluar su idoneidad para sus necesidades o las de sus clientes.

Una implementación de campo verde también es el sistema de virtualización Citrix más rápido y fácil que puede crear. Simplemente puede derribarlo cuando el sistema ya no es necesario y deja de pagar por los recursos que consumió. Todo lo que necesita para este tipo de implementación es una cuenta de AWS activa y una suscripción de prueba o de pago a Citrix Cloud y Citrix DaaS. Con estos dos recursos, puede utilizar las plantillas QuickStart CloudFormation de AWS para crear una implementación de referencia. Citrix y AWS han colaborado en la plantilla de inicio rápido de Citrix DaaS en AWS, que le ayuda a crear un sistema de virtualización Citrix completo desde cero o a crear una “ubicación de recursos” de Citrix Cloud en una VPC existente con un Active Directory existente. Cuando se implementa todo el sistema de virtualización de Citrix desde cero, el sistema resultante en AWS se construye estrechamente con los siguientes diagramas de arquitectura de referencia:

Diagrama 3: La arquitectura del sistema desplegado detalla los parámetros predeterminados. Citrix Cloud Services no se muestra Diagrama 3: detalle de la arquitectura del sistema implementado con la plantilla Citrix DaaS on AWS QuickStart y los parámetros predeterminados. Citrix Cloud Services no se muestra.

Diagrama 4: Arquitectura conceptual de implementación Greenfield/Cloud Only con servicios de AWS opcionales y Citrix Cloud Services Diagrama 4: Arquitectura conceptual de implementación Greenfield/Solo en la nube con servicios de AWS opcionales y Citrix Cloud Services.

Vale la pena señalar que este modelo de implementación (en realidad, los tres modelos de implementación) utiliza las zonas de disponibilidad de AWS para ofrecer un diseño de alta disponibilidad. Consulte Zonas de disponibilidad más adelante en este documento para obtener más contexto.

Como se mencionó anteriormente, este es un excelente lugar para comenzar cuando se aprende acerca de AWS y los servicios de Citrix Cloud. Muchos de los patrones de diseño que se muestran en el diagrama anterior se utilizan para tipos de implementación híbrida e incluso Lift and Shift, por lo que el aprendizaje de estos patrones de diseño se adapta perfectamente a un arquitecto de Citrix en AWS, independientemente del modelo de implementación.

Para resumir, el modelo de implementación de campo verde utiliza todos los servicios en la nube, al menos como punto de partida:

Componente del sistema de virtualización de Citrix Proporcione
Intermediación y administración de sesiones Citrix DaaS (“DaaS”, a través de Citrix Cloud)
Servicios de UI Servicio Citrix Workspace (a través de Citrix Cloud)
Autenticación Servicio Citrix Workspace (a través de Citrix Cloud)
Proxy de sesión HDX Servicio Citrix Gateway (a través de Citrix Cloud)
Procesamiento, redes y almacenamiento de máquinas virtuales Amazon Elastic Compute Cloud (Amazon EC2), Amazon Virtual Private Cloud (Amazon VPC), Amazon Elastic Block Store (Amazon EBS)
Active Directory y sistemas de archivos AWS Directory Service para Microsoft Active Directory y FSx para Windows File Server de Amazon (opcional)

Ya mencionamos que el modelo de implementación de campo verde se utiliza a menudo como punto de partida para pruebas de concepto y sistemas de prueba de tecnología. Si comienza con este modelo y luego coloca StoreFront o Citrix ADC/Gateway VPX en, aparentemente está creando nuestro siguiente tipo de modelo de implementación: híbrido.

Implementación híbrida

Con el modelo de implementación híbrida, los clientes pueden elegir instalar, configurar o administrar algunos de los componentes del sistema de virtualización de Citrix por sí mismos, pero no el subsistema de administración y intermediación de sesiones. En un modelo de implementación híbrida, este subsistema se proporciona como un servicio en la nube denominado “Citrix DaaS” y se entrega como una suscripción de Citrix Cloud.

El modelo de implementación híbrida es la implementación más común que se vaya hoy en día y es el modelo que Citrix recomienda para la mayoría de los clientes. Estas son algunas de las razones principales por las que tomamos esta posición:

  • Simplicidad: Con los servicios de Citrix Cloud, la simplicidad es un principio fundamental del diseño. Cuando se utilizan varios servicios en la nube, vienen preconfigurados para trabajar juntos, y cuando la configuración es necesaria, los flujos de trabajo y las opciones se simplifican drásticamente.
  • Ahorro en costes de infraestructura y licencias: Los servicios de virtualización de Citrix gestionados por el cliente a menudo requieren hardware y software adicionales para soportarlos, y estos tienen costes asociados a ellos. Un buen ejemplo es Microsoft SQL Server: los servicios de intermediación y administración administrados por el cliente requieren bases de datos, y si va a crear/administrar las suyas propias, debe proporcionarlas. Una alternativa es utilizar AWS Relational Database Service (Amazon RDS) para SQL Server.
  • Escalado automático: el servicio de intermediación administrada (DaaS) de Citrix incluye la función Citrix Autoscale, que proporciona capacidad de VDA integrada y funcionalidad de administración de costes. Esta función puede ahorrar a los clientes una cantidad sustancial de dinero en infraestructura cuando solo pagan por lo que usan. Cuando se ejecuta una carga de trabajo de virtualización de Citrix en AWS, esto suele significar la diferencia entre pagar descuentos de uso comprometido o pagar por el uso de VM a medida que vaya. El ahorro de costes puede ser espectacular en muchos casos de uso, y la función Citrix Autoscale ayuda a garantizar que solo consume lo que necesita.
  • Ahorros en administración : con los servicios en la nube, Citrix asume la responsabilidad de mantener los servicios altamente disponibles, eficientes, seguros y actualizados. Aún crea y administra sus VDA independientemente, pero no subestime el valor de delegar estas responsabilidades. Los servicios en la nube ayudan a liberar recursos de TI, lo que les permite centrarse en proporcionar un valor único a sus empresas en lugar de estas tareas críticas pero tediosas (y a menudo requieren mucho tiempo).
  • Actualizaciones “gratuitas” e innovación continua: Con la infraestructura gestionada por el cliente, el cliente tiene la carga de actualizar y aplicar parches a los componentes a su cargo. Con los servicios en la nube, la mayoría de esos esfuerzos de trabajo desaparecen. Los proveedores de servicios (Citrix o AWS, por ejemplo) tienden a innovar constantemente y llevan esas innovaciones a los clientes que consumen los servicios, a menudo sin requerir trabajo en nombre del cliente.
  • Acceso a más funciones, funcionalidades y servicios: Las plataformas modernas de prestación de servicios (como Citrix Cloud y AWS EC2) ofrecen a los proveedores de tecnología una forma eficaz y rentable de comercializar nuevas funciones, capacidades y servicios que de otro modo no serían posibles. Los proveedores como Citrix se comprometen a reunirse con el cliente dondequiera que se encuentren en su proceso de transformación digital, pero a veces la única forma de ofrecer nuevas capacidades de manera rentable es proporcionarlas como un servicio en la nube.
  • Flexibilidad: con DaaS como base de este modelo de implementación, los clientes pueden combinar y combinar los componentes de servicio en la nube o administrados por el cliente del sistema de virtualización Citrix. Esto permite que el sistema cumpla varios casos de uso diferentes y admita requisitos empresariales complejos para un sistema de virtualización Citrix. Exploramos estas opciones en profundidad en una sección posterior de este artículo.

Para resumir, el modelo de implementación híbrida utiliza lo siguiente:

Componente del sistema de virtualización de Citrix Proporcione
Intermediación y administración de sesiones Citrix DaaS (“DaaS”, a través de Citrix Cloud)
Servicios de UI Servicio Citrix Workspace (a través de Citrix Cloud) O Citrix StoreFront en Amazon EC2 (gestionado por el cliente)
Autenticación Servicio Citrix Workspace (a través de Citrix Cloud) O Citrix StoreFront en EC2 (Citrix ADC/Gateway opcional pero común)
Proxy de sesión HDX Citrix Gateway Service (a través de Citrix Cloud) O Citrix ADC/Gateway VPX en Amazon EC2 (Citrix ADC/Gateway opcional pero común)
Procesamiento, redes y almacenamiento de máquinas virtuales Amazon Elastic Compute Cloud (Amazon EC2), Amazon Virtual Private Cloud (Amazon VPC), Amazon Elastic Block Store (Amazon EBS)
Active Directory y sistemas de archivos AWS Directory Service para Microsoft Active Directory y FSx para Windows File Server de Amazon (opcional)

Dadas las opciones que un cliente puede elegir en el modelo de implementación híbrida y la flexibilidad que proporcionan los componentes gestionados por el cliente, no existe una arquitectura sucinta que se adapte a todos los clientes. Sin embargo, hay algunos patrones de diseño comunes que también se pueden mezclar o combinar para adaptarse a las necesidades de los clientes. Sin embargo, el patrón fundamental es el patrón de una “ubicación de recursos” de Citrix Cloud en AWS. También es el patrón creado por la plantilla QuickStart de Citrix DaaS en AWS y tiene un aspecto similar al siguiente diagrama arquitectónico:

Diagrama 5: Arquitectura conceptual, Citrix DaaS - Modelo de implementación híbrida en AWS Diagrama 5: Arquitectura conceptual, Citrix DaaS - Modelo de implementación híbrida en AWS.

Vale la pena señalar que este modelo de implementación también utiliza zonas de disponibilidad de AWS para ofrecer un diseño de alta disponibilidad. Consulte Zonas de disponibilidad más adelante en este documento para obtener más contexto.

También vale la pena señalar que el modelo de implementación híbrida (una ubicación de recursos de DaaS en AWS) se puede combinar con un modelo de nube híbrida, conectando los centros de datos y recursos gestionados por el cliente a AWS mediante AWS Direct Connect, AWS VPN u otras herramientas de red. Con este modelo, el Active Directory existente de los clientes a menudo se extiende a AWS y los clientes crean más “Ubicaciones de recursos” de Citrix Cloud que ofrecen aplicaciones, escritorios y recursos desde el centro de datos gestionado por el cliente. La arquitectura conceptual resultante tiene un aspecto similar al siguiente diagrama: Diagrama 6: Arquitectura conceptual, Citrix DaaS: implementación híbrida/modelo de nube híbrida Diagrama 6: Arquitectura conceptual, Citrix DaaS: implementación híbrida/modelo de nube híbrida.

Lift and Shift

Con referencia a nuestra definición de los componentes del sistema de virtualización de Citrix, cuando hablamos de un caso de implementación Lift and Shift, el componente clave es el subsistema de administración y intermediación de sesiones y la infraestructura asociada. Si está mediante una infraestructura de intermediación autoadministrada (está implementando Delivery Controllers en lugar de Cloud Connectors), a los efectos de este documento está levantando y cambiando.

Lift and Shift: Motivos a favor

A pesar de las instrucciones de Citrix en contra de este modelo, algunos clientes siguen optando por seguir este modelo e implementar/administrar los componentes del sistema de virtualización Citrix ellos mismos. Según CTX270373, el uso de nubes públicas, incluida AWS, solo se admite con las versiones de productos LTSR. Para los clientes que eligen el modelo de implementación Lift and Shift (autogestionado), a menudo encontramos que hay razones no técnicas detrás de él. La directiva, las presiones de tiempo, el miedo a lo desconocido, los déficits de habilidades percibidos, la pérdida de control y la adquisición de licencias entran en esta categoría. Sin embargo, hay algunas razones técnicas por las que este modelo es atractivo. que incluye:

  • Aislamiento del sistema: Algunos casos de uso, como los sistemas aislados sin acceso a Internet, hacen que el modelo de Lift and Shift resulte atractivo. Dado que los servicios en la nube requieren acceso a Internet saliente para funcionar, en una implementación estrictamente aislada, los servicios en la nube no funcionarán. Esto se aplica principalmente a Cloud Connectors (componente principal de los servicios de intermediación de sesiones administradas), ya que necesitan conectividad de Internet saliente para comunicarse con los servicios de Citrix Cloud y utilizarlos. Algunos clientes pueden considerar la posibilidad de utilizar un proxy de salida seguro para Cloud Connectors (manteniendo toda la otra infraestructura estrictamente aislada). Esta es a menudo una concesión adecuada que permite utilizar los servicios de intermediación gestionada, pero incluso esto puede no ser una opción para algunos clientes y casos de uso.
  • Flexibilidad de configuración: “complejo” de una persona es “flexible” de otra persona, y la flexibilidad ha sido un sólido conjunto de infraestructura de virtualización de Citrix gestionada por el cliente durante más de dos décadas. A lo largo de los años, la tecnología ha ganado un montón de funciones que soportan algunos casos de uso muy nicho e integraciones de terceros. Los servicios de Citrix Cloud se centran en la simplicidad y la preintegración. Al hacerlo, algunas de estas funciones e integraciones de nicho no están disponibles. Por lo tanto, algunos casos perimetrales siguen siendo mejor atendidos por una pila administrada por el cliente. Dicho esto, dado el rápido ritmo de innovación que llega a los servicios de Citrix Cloud, estos casos perimetrales son cada vez más raros.
  • Control: Algunas organizaciones, culturas y modelos de negocio exigen tanto control como sea posible. Con los componentes de virtualización de Citrix gestionados por el cliente, los clientes pueden poseer completamente su destino. Este control tiene un coste (infraestructura, complejidad, personal, etc.), pero “control a toda costa” es algo para algunos clientes.

Para resumir, el modelo de implementación Lift and Shift utiliza lo siguiente:

Componente del sistema de virtualización de Citrix Proporcione
Intermediación y administración de sesiones Citrix Virtual Apps and Desktops (gestionado por el cliente mediante LTSR o CR descargable) en Amazon EC2
Servicios de UI Citrix StoreFront en Amazon EC2 (gestionado por el cliente)
Autenticación Citrix StoreFront en EC2 (Citrix ADC/Gateway opcional pero común)
Proxy de sesión HDX Citrix ADC/Gateway VPX en Amazon EC2 (gestionado por el cliente)
Procesamiento, redes y almacenamiento de máquinas virtuales Amazon Elastic Compute Cloud (Amazon EC2), Amazon Virtual Private Cloud (Amazon VPC), Amazon Elastic Block Store (Amazon EBS)
Active Directory y sistemas de archivos Instancias de Windows Server gestionadas por el cliente en EC2; AWS Directory Service para Microsoft Active Directory y FSx de Amazon para Windows File Server (opcional)

En su forma más sencilla, la implementación Lift and Shift de la tecnología de virtualización de Citrix en AWS se asemeja a una implementación tradicional administrada por el cliente local. Utiliza un ‘sitio’ CVAD implementado en una región de AWS y utiliza como mínimo los servicios básicos de AWS IaaS como máquinas virtuales EC2 y redes de VPC. Como se mencionó anteriormente, requiere que el cliente construir/configurar/mantener todos los componentes del sistema, además de servicios de soporte como bases de datos SQL. El siguiente diagrama muestra este modelo de implementación: Diagrama 1: Arquitectura Conceptual, CVAD: Modelo de implementación Lift and Shift en AWS Diagrama 1: Arquitectura Conceptual, CVAD: Modelo de implementación Lift and Shift en AWS.

Vale la pena señalar que este modelo de implementación también utiliza zonas de disponibilidad de AWS para ofrecer un diseño de alta disponibilidad. Consulte Zonas de disponibilidad más adelante en este documento para obtener más contexto.

Un modelo de implementación gradual suele combinarse con un modelo de infraestructura de nube híbrida, que utiliza AWS Direct Connect, AWS VPN o una tecnología de red similar para conectar un centro de datos y recursos gestionados por el cliente a AWS. Opcionalmente, los clientes pueden adoptar algunos de los servicios en la nube más avanzados de AWS (para proporcionar una medida de simplificación con la transición), y también pueden optar por alojar algunos servicios (como bases de datos SQL, licencias de Citrix, Citrix StoreFront y Citrix ADC/Gateway), ya sea en AWS, en datos gestionados por el cliente centro, o ambos dependiendo de sus inversiones existentes, requisitos de casos de uso, y tal. En el siguiente diagrama se muestra una arquitectura conceptual de este modelo de implementación (mediante AWS RDS para SQL Server o SQL Server local). Solo se necesita una instancia activa de Citrix Licensing, pero hemos mostrado varias para describir las opciones disponibles: Diagrama 8: Arquitectura Conceptual, CVAD: Modelo de implementación Lift and Shift con modelo de infraestructura de nube híbrida y servicios de nube gestionados de AWS Diagrama 8: Arquitectura conceptual CVAD: Modelo de implementación Lift and Shift con modelo de infraestructura de nube híbrida y los servicios de nube administrados de AWS.

Lift and Shift: Motivos en contra

A estas alturas ya se ha dado cuenta de que la práctica/recomendación líder de Citrix es NO usar Lift and Shift al completo. Usted puede estar preguntándose por qué, o de dónde viene esto. En referencia a nuestro desglose de los componentes del sistema de virtualización de Citrix, el subsistema de administración y intermediación de sesiones es el componente más crítico que debe considerar NO usar Lift and Shift. Recomendamos encarecidamente a los clientes que consideren utilizar los servicios en la nube de Citrix para la intermediación y la administración de sesiones (implementar solo Cloud Connectors, frente a la implementación de Delivery Controllers + bases de datos SQL + servidores Director + servidores Citrix Licensing). Estas son algunas de las razones principales por las que tomamos esta posición (y podrían sonar familiares):

  • Simplicidad: Mientras que los servicios de intermediación de sesiones gestionados por el cliente proporcionan lo último en flexibilidad de control y configuración, se produce a costa de la complejidad y los requisitos de mantenimiento continuos. Con los servicios de Citrix Cloud, la simplicidad es un principio fundamental del diseño. Cuando se utilizan varios servicios en la nube, vienen preconfigurados para trabajar juntos, y cuando la configuración es necesaria, los flujos de trabajo y las opciones se simplifican drásticamente.
  • Ahorro en costes de infraestructura y licencias: Los servicios de virtualización de Citrix gestionados por el cliente a menudo requieren hardware y software adicionales para soportarlos, y estos tienen costes asociados a ellos. Un buen ejemplo es Microsoft SQL Server: los servicios de intermediación administrados por el cliente requieren bases de datos, y si va a crear/administrar las suyas propias, debe proporcionarlas.
  • Hablando de ahorro de costes de infraestructura, esto trae consigo un diferenciador crítico entre las dos opciones de intermediación de sesiones: Autoscaling. El servicio de intermediación administrada (DaaS) de Citrix incluye la función Citrix Autoscale, que proporciona capacidad de VDA integrada y funcionalidad de administración de costes. Esta función puede ahorrar a los clientes una cantidad sustancial de dinero en infraestructura cuando solo pagan por lo que usan. Cuando se ejecuta una carga de trabajo de virtualización de Citrix en AWS, esto suele significar la diferencia entre pagar descuentos de uso comprometido o pagar por el uso de VM a medida que vaya. El ahorro de costes puede ser espectacular en muchos casos de uso, y la función Citrix Autoscale ayuda a garantizar que solo consume lo que necesita. Nota importante: Esta función solo está disponible para los clientes del servicio Citrix Cloud (Citrix DaaS); no está disponible para la infraestructura de intermediación administrada por el cliente (versiones LTSR o CR de Citrix Virtual Apps and Desktops). - Ahorros en la administración: con los servicios en la nube, Citrix (y AWS en este caso) asume la responsabilidad de mantener los servicios altamente disponibles, eficientes, seguros y actualizados. Aún crea y administra sus VDA independientemente, pero no subestime el valor de delegar estas responsabilidades. Los servicios en la nube ayudan a liberar recursos de TI, lo que les permite centrarse en proporcionar un valor único a sus empresas en lugar de estas tareas críticas pero tediosas y, a menudo, requieren mucho tiempo.
  • Actualizaciones “gratuitas” e innovación continua: Con la infraestructura gestionada por el cliente, el cliente tiene la carga de actualizar y aplicar parches a los componentes a su cargo. Con los servicios en la nube, la mayoría de esos esfuerzos de trabajo desaparecen. Los proveedores de servicios (Citrix y AWS en este caso) tienden a innovar constantemente, y llevan estas innovaciones a los clientes que consumen los servicios, a menudo sin necesidad de ningún trabajo en nombre del cliente.
  • Acceso a más funciones, funcionalidades y servicios: las modernas plataformas de prestación de servicios (como Citrix Cloud y Amazon EC2) ofrecen a los proveedores de tecnología una forma eficaz y rentable de comercializar nuevas funciones, capacidades y servicios que de otro modo no serían posibles. Los proveedores como Citrix se comprometen a reunirse con el cliente dondequiera que se encuentren en su proceso de transformación digital, pero a veces la única forma de ofrecer nuevas capacidades de manera rentable es proporcionarlas como un servicio en la nube.

Lift and Shift: Más recursos

Antes de que nacieran los servicios de Citrix Cloud, los clientes ya estaban implementando con éxito las tecnologías de virtualización de Citrix en AWS. En esos días, Citrix llamó a los productos Virtual Apps and Desktops XenApp y XenDesktop. Se realizó un amplio trabajo en la creación y publicación de arquitecturas de referencia y guías de implementación para este caso de implementación. Una buena parte de los detalles de estos recursos obsoletos todavía se aplica a implementaciones que deben seguir este ruta hoy.

Para los clientes que DEBEN seguir esta ruta, los siguientes recursos publicados le proporcionan detalles útiles de fondo que puede utilizar para ayudarle a tener éxito. Recomendamos revisar estos materiales antes de continuar con este documento, ya que estamos destacando importantes decisiones de diseño que han cambiado desde que se completaron estos trabajos:

Decisiones en cuanto a diseño

En esta sección se analizan las decisiones clave de diseño que se deben tener en cuenta al diseñar su sistema de virtualización Citrix en AWS. Recorremos cada capa del marco de diseño arquitectónico Citrix, explorando áreas clave para que usted tenga en cuenta.

Acerca del marco de diseño arquitectónico de Citrix

La solución Virtual Apps and Desktops de Citrix (el nombre de familia de productos que se refiere colectivamente a las tecnologías de virtualización de Citrix) permite a las organizaciones crear, controlar y administrar máquinas virtuales, entregar aplicaciones y escritorios e implementar directivas de seguridad granulares. La solución Citrix Virtual Apps and Desktops proporciona un marco unificado para desarrollar una oferta completa de espacio de trabajo digital. Esta oferta permite a los usuarios de Citrix acceder a aplicaciones y escritorios independientemente del sistema operativo y la interfaz de sus dispositivos.

El marco de diseño arquitectónico de Citrix se basa en un modelo de capa unificado y estandarizado. Proporciona un marco coherente y de fácil acceso para comprender la arquitectura técnica de la mayoría de los casos comunes de implementación de Virtual Apps and Desktops. Estas capas se representan en el siguiente diagrama conceptual: Diagrama 9: Arquitectura conceptual, Citrix Virtual Apps and Desktops Diagrama 9: Arquitectura conceptual, Citrix Virtual Apps and Desktops.

  • Capa de usuario: Esta capa define los grupos de usuarios y las ubicaciones del entorno Citrix.
  • Capa de acceso: Esta capa define el modo en que los usuarios acceden a los recursos.
  • Capa de control: Esta capa define los componentes que controlan la solución Citrix.
  • Capa de recursos: Esta capa define el aprovisionamiento de cargas de trabajo de Citrix y cómo se asignan los recursos a los usuarios dados.
  • Capa de plataforma: Esta capa define los elementos físicos en los que se ejecutan los componentes del hipervisor y el marco de proveedor de servicios en la nube para alojar las cargas de trabajo de Citrix.
  • Capa de operaciones: Esta capa define las herramientas que soportan la entrega de las soluciones principales.

Consideraciones de capa de usuario

En Citrix Architectural Design Framework, la capa Usuario describe los grupos de usuarios, sus ubicaciones, requisitos específicos y mucho más. La capa de usuario establece adecuadamente la dirección general del entorno de cada grupo de usuarios. Esta capa incorpora los criterios de evaluación de las prioridades empresariales y los requisitos de grupos de usuarios para definir estrategias efectivas para los dispositivos de punto final y la aplicación Citrix Workspace. Estas decisiones de diseño afectan a la flexibilidad y la funcionalidad de cada grupo de usuarios.

Al diseñar e implementar un sistema de virtualización Citrix en cualquier plataforma, las decisiones y estrategias adoptadas después de una cuidadosa evaluación establecen las bases para muchas otras decisiones que los clientes deben tener en cuenta a medida que recorren las otras capas de Citrix Architectural Design Framework. Como tal, esta es una capa crítica para entender a fondo y hacer lo correcto.

Consideraciones de capa de acceso

En Citrix Architectural Design Framework, la capa Access define el modo en que los usuarios acceden a los recursos de AWS. El diseño de su capa de acceso es fundamental para la funcionalidad que ofrece cualquier sistema de virtualización de Citrix. Controla cómo se autentican los usuarios en el sistema. También controla la forma en que los usuarios ven e inician aplicaciones y escritorios virtualizados, además de qué tipo de aplicaciones y contenido están disponibles para ellos. Además, la capa de acceso controla cómo y cuándo las sesiones se conectan de forma segura o se conectan directamente.

En el contexto de los componentes del sistema de virtualización de Citrix que definimos anteriormente, la capa de acceso contiene los siguientes componentes y opciones:

Componente del sistema de virtualización de Citrix Proporcione
Servicios de UI Citrix Workspace (proporcionado por Citrix Cloud) O Citrix StoreFront en Amazon EC2 (gestionado por el cliente)
Autenticación Servicio Citrix Workspace (Citrix ADC/Gateway opcional) O Citrix StoreFront en EC2 (Citrix ADC/Gateway opcional pero común)
Proxy de sesión HDX Citrix Gateway Service (proporcionado por Citrix Cloud) O Citrix ADC/Gateway VPX en Amazon EC2 (gestionado por el cliente)

La tabla siguiente contiene puntos de decisión críticos al determinar qué componente de capa de acceso se va a implementar, pero la opción no es binaria. Citrix admite varios métodos de acceso diferentes que se pueden personalizar para adaptarse a sus necesidades.

Consideraciones de autenticación y servicio de IU

Tenga en cuenta lo siguiente al elegir cómo quiere proporcionar servicios de interfaz de usuario para su sistema de virtualización Citrix en AWS:

Atributo/Capacidad Gestionado por el cliente (instalado desde binarios descargados) Servicio en la nube (proporcionado a través de Citrix Cloud)
Capacidad para presentar e iniciar aplicaciones y escritorios virtualizados desde múltiples “Citrix Farms”. : Tanto entornos antiguos (XenApp y XenDesktop 7.x, Citrix Virtual Apps and Desktops CR/LTSR) como Citrix DaaS. : Tanto entornos antiguos (XenApp y XenDesktop 7.x, Citrix Virtual Apps and Desktops CR/LTSR) como Citrix DaaS. Consulte este artículo para obtener más información.
Capacidad para crear múltiples ‘Almacenes’ con diferentes configuraciones para diferentes casos de uso, incluidos los requisitos de autenticación. : StoreFront se puede configurar con varias almacenes diferentes y, cuando se combina con Citrix ADC/Gateway VPX, puede aplicar reglas sofisticadas para dirigir determinados dispositivos o grupos de usuarios a diferentes almacenes. Para obtener más información, consulte Cómo funciona SmartAccess para Citrix Virtual Apps and Desktops. Un caso común que requiere dos StoreFront Stores sería cuando los usuarios necesitan aplicaciones publicadas desde dentro de un escritorio publicado. Otro caso común sería el requisito de tener un solo almacén interno (sin acceso a Citrix Gateway) para un caso de uso específico y otro Store configurado para el acceso interno y remoto. Consulte Configurar y administrar almacenes para obtener más información. NO: Workspace Service es esencialmente un único almacén, en una única URL. Todos los usuarios utilizan la misma configuración de almacén y espacio de trabajo. Los requisitos de autenticación se configuran una vez y se aplican a todos los usuarios del arrendatario de Workspace.
Capacidad para enumerar, lanzar y SSO en aplicaciones SaaS y web mediante el servicio Citrix Secure Private Access, aprovechando el filtrado web y las directivas de control de seguridad mejoradas, además de los análisis avanzados mejorados de ML. NO: Requiere el uso de Citrix Workspace. : Con Citrix Gateway Service, es tan simple como “activar” la integración en Citrix Cloud Console. Las aplicaciones SaaS se definen simplemente a partir de un asistente basado en web, y los administradores pueden utilizar una lista sustancial de aplicaciones predefinidas como punto de partida.
Capacidad para acceder, indexar/buscar contenido de Citrix Files (anteriormente ShareFile) a través de la aplicación Citrix Workspace y los exploradores web (HTML). NO: StoreFront no tiene la capacidad de integrar contenido basado en archivos en las UI HTML de Workspace App o StoreFront. : Habilitado de forma predeterminada en función de la suscripción a Citrix Cloud. Aporta contenido basado en archivos de los usuarios de varios orígenes (incluidos los recursos compartidos de archivos locales) a la interfaz de usuario de Workspace, tanto HTML como Workspace App.
Capacidad para presentar e iniciar conexiones a escritorios físicos mediante la función Citrix Remote PC Access. SÍ, independientemente de si la intermediación es manejada por CVAD o DaaS. SÍ, independientemente de si la intermediación es manejada por CVAD o DaaS.
Para casos de uso de múltiples sitios y DR, la capacidad de controlar granularmente el comportamiento de inicio de sesión mediante Preferencia de zona y conmutación por error. : Utilizar las zonas Citrix para implementaciones en varias regiones y zonas de disponibilidad de AWS es una excelente manera de expandir este-oeste y limitar la base de usuarios afectada en caso de interrupción, y permite la preferencia de región y la conmutación por error a la zona principal sin problemas. Consulte la documentación de CVAD Zones. Parcial: El servicio Workspace no incluye la preferencia de zona completa y la funcionalidad de conmutación por error, pero se puede implementar un efecto similar mediante zonas de inicio para usuarios o aplicaciones. Consulte la documentación de Citrix DaaS Zones para obtener más información
Capacidad de intermediar conexiones nuevas y existentes cuando falla una conexión entre una ubicación/zona de recursos y Citrix Cloud, o cuando las bases de datos situadas debajo de Citrix Delivery Controllers no están disponibles. : Utiliza la función Caché de host local tanto en Cloud Connectors como en Delivery Controllers para proporcionar resiliencia para estos dos posibles casos de falla. Para entornos con requerimientos de resiliencia extensos, Citrix recomienda implementar StoreFront con caché de host local. Para obtener más información, consulte Caché de host local (CVAD). : Cloud Connectors utiliza la función Caché de host local para intermediar conexiones de recursos en caso de que se produzca un error en la comunicación de Citrix Cloud. Esto requiere servidores StoreFront pasivos accesibles por las ubicaciones de recursos para gestionar casos de conmutación por error. Para obtener más información, consulte Caché de host local (DaaS).
Capacidad para configurar y utilizar una ‘URL de vanidad’ personalizada para el consumo del usuario final. - El cliente tiene el control total de las URL y los certificados utilizados y presentados a los usuarios. Requiere certificados SSL, creación y administración de alias DNS e instancias de Citrix ADC/Gateway para la entrada a través de redes públicas. Parcial: Todos los espacios de trabajo se entregan desde el dominio cloud.com, aunque los clientes pueden configurar su propio prefijo personalizado (customername.cloud.com).
Capacidad para redirigir de forma inteligente usuarios en la red directamente a VDA y usuarios fuera de la red a través de Citrix ADC/Gateway VPX o Citrix Gateway Service. : StoreFront utiliza ‘balizas’ definidas por el administrador, que la aplicación Citrix Workspace utiliza para determinar si un usuario está dentro o fuera de la red. Próximamente: Se espera que esta función esté disponible en Citrix Workspace con el lanzamiento del Servicio de ubicación de red una vez que esté disponible de forma general. Para obtener más información, consulte Vista previa del Servicio de ubicación de red.
Capacidad de utilizar Citrix Gateway Service para servicios proxy de sesión HDX simples y preconfigurados. NO: Si el acceso fuera de la red a las aplicaciones virtualizadas de Citrix es un requisito (y se encuentra en el 99% de las implementaciones), StoreFront requiere el uso de la funcionalidad de proxy de sesión de Citrix ADC/Gateway administrada por el cliente para HDX. : Esta función está aprovisionada y habilitada de forma predeterminada para todos los nuevos arrendatarios de Citrix Workspace.
Incluye autenticación multifactor integrada a través de Active Directory y TOTP. : Citrix ADC incluye la funcionalidad TOTP integrada para su uso con autenticadores de terceros y también admite aplicaciones, dispositivos/servicios de terceros. : Citrix Workspace incluye esta función, incluida la recuperación de dispositivos OTP de autoservicio y las notificaciones automáticas de inserción a los usuarios finales. Admite aplicaciones de autenticación de Citrix y de terceros.
Capacidades de SSO (virtualizadas, SaaS y aplicaciones web) Parcial: SSO a aplicaciones virtualizadas desde la caja. : SSO a aplicaciones web, SaaS y virtualizadas disponibles de forma nativa con Citrix Workspace. Gateway Service y Secure Private Access incluyen filtros web y controles de directivas.
Posibilidad de elegir entre varios métodos de autenticación predefinidos y hacer que el método elegido se aplique a todos los usuarios del sistema. - con más opciones y flexibilidad. Citrix StoreFront le permite crear varias almacenes y los métodos de autenticación se configuran por almacén. Se pueden configurar una o más opciones por almacén, y los administradores pueden seleccionar entre las opciones de nombre de usuario/contraseña de Active Directory, autenticación SAML, paso a través de dominio, tarjeta inteligente, HTTP Basic y PassThrough desde Citrix Gateway. También se puede habilitar el restablecimiento de contraseñas de autoservicio. Consulte Configurar el servicio de autenticación para obtener más información. Cuando Citrix ADC/Gateway (gestionado por el cliente) se implementa y utiliza con StoreFront, se pueden configurar varias opciones de autenticación, junto con una lógica adicional para dirigir a los usuarios a un almacén específica según sea necesario para admitir casi cualquier caso de uso. Citrix StoreFront y Citrix ADC/Gateway se recomiendan cuando se requieren integraciones complejas y métodos de autenticación diferentes para diferentes casos de uso. : Actualmente, Active Directory, Azure AD, Token de Active Directory + TOTP, Azure AD y Citrix Gateway son opciones compatibles actualmente. Las opciones de Okta y Google Cloud ID están en vista previa o próximamente. Consulte Espacios de trabajo seguros para obtener más información. A excepción de Citrix Gateway, la opción de autenticación se aplica a todos los usuarios y a todos los servicios proporcionados a través del arrendatario/URL de Citrix Workspace. Con la opción Citrix Gateway, los clientes pueden admitir varias opciones de autenticación (RADIUS MFA, tarjeta inteligente, federación, directivas de acceso condicional, etc.) y aplicarlas de manera flexible a diferentes grupos de usuarios y casos de uso. Para obtener más información, consulte Conectar un dispositivo Citrix Gateway local como proveedor de identidades con Citrix Cloud.
Capacidad de inicio de sesión inicial en sesiones en VDA cuando se inician aplicaciones o escritorios Windows virtualizados mediante proveedores de identidades federadas SÍ, el Servicio de autenticación federada (FAS) de Citrix habilita el inicio de sesión único para los VDA cuando se utiliza un proveedor de identidad federado, como SAML (lenguaje de marcado de aserción de seguridad). Próximamente: Mediante el uso del Servicio de autenticación federada (FAS) de Citrix con Citrix Workspace. Esta función se encuentra en vista previa a partir de esta escritura. Consulte Habilitar SSO para espacios de trabajo con Citrix FAS para obtener más información.

Consideraciones del proxy de sesión HDX

Tenga en cuenta lo siguiente al elegir cómo quiere proporcionar la funcionalidad de proxy de sesión HDX para su sistema de virtualización Citrix en AWS:

Atributo/Capacidad Gestionado por el cliente (Citrix ADC/Gateway VPX en AWS) Servicio en la nube (servicio Citrix Gateway proporcionado por Citrix Cloud)
Servicio simple y preconfigurado, que proporciona proxy HDX sin sobrecarga administrativa NO: Como componente gestionado por el cliente, estos dispositivos requieren licencias, instalación, configuración y mantenimiento. SÍ,Citrix Gateway Service es una solución proxy HDX completa, administrada por Citrix, que se ofrece como un servicio en la nube.
Posibilidad de utilizar el protocolo de transporte basado en EDT (UDP) de Citrix HDX. Para obtener más información, consulte Adaptive Transport y How to Configure HDX Enlightened Data Transport Protocol. : Esta función optimiza el tráfico de sitios de alta latencia y está disponible para instancias de ADC/puerta de enlace administradas por el cliente. Todavía no - Esta función está en vista previa a partir de esta escritura. Actualmente, el servicio de puerta de enlace solo admite conexiones basadas en TCP a VDA.
Capacidad para proporcionar equilibrio de carga, comprobación del estado, descarga SSL y varios otros servicios avanzados de red y entrega de aplicaciones para la infraestructura administrada por el cliente. : Los dispositivos Citrix ADC/Gateway VPX ofrecen capacidades sofisticadas y líderes en la industria, muchas de las cuales se pueden habilitar simplemente aplicando el tipo de licencia apropiado al dispositivo. NO: para los entornos con intermediación de Citrix CVAD y Citrix DaaS, Gateway Service proporciona un acceso simple y seguro a las aplicaciones virtualizadas que se ejecutan en los entornos AWS del cliente o en las instalaciones.
Soporte para Equilibrio de Carga de Servidor Global (GSLB) configurable por el cliente entre centros de datos, zonas y regiones. : Las instancias de Citrix ADC/Gateway gestionadas por el cliente se pueden configurar para GSLB, aunque el cliente es responsable de la configuración y la administración. NO,… sin embargo, no hay necesidad real de hacerlo: el servicio Gateway utiliza 14 o más POP en todo el mundo más GSLB integrado para garantizar que los usuarios obtengan el mejor rendimiento de sesión posible independientemente del lugar del mundo en el que se encuentren.
Requiere el uso de la interfaz de usuario de Citrix Workspace para la presentación y el lanzamiento de sesiones HDX. NO: Es posible utilizar instancias de Citrix ADC/Gateway VPX administradas por el cliente con interfaz de usuario de Workspace y StoreFront. : El servicio de puerta de enlace solo se puede configurar a través de la interfaz de usuario de Citrix Workspace para proxy HDX; NO proporciona capacidades de proxy HDX para Citrix StoreFront.
Requiere recursos adicionales en instancias de Cloud Connector para realizar sesiones proxy en redes seguras. NO: Mientras que Cloud Connectors realiza la validación de tíquets STA para instancias de Citrix ADC/Gateway VPX administradas por el cliente, no se necesitan recursos adicionales, ya que todas las sesiones HDX se realizan mediante proxy a través de las VPX. : Hoy en día, el servicio de puerta de enlace utiliza conexiones TCP salientes y de larga duración desde las instancias de Cloud Connector a Citrix Cloud para reenviar el tráfico HDX a redes privadas. Esto requiere consideraciones de recursos adicionales al dimensionar y configurar instancias de Cloud Connector. Consulte este artículo para obtener más información. Nota: Este requisito es discutible para la mayoría de los casos de uso una vez que el servicio de puerta de enlace y los agentes VDA pueden utilizar el protocolo/función Rendezvous. Esto requiere Citrix VDA 1912 o posterior.
Capacidad para ser utilizado con arrendatarios de Citrix Cloud Government. : Se admiten implementaciones de ADC/Gateway/StoreFront basadas en AWS EC2 y tanto en las instalaciones como en AWS EC2. : Citrix Workspace está disponible en Citrix Cloud Government.
Capacidad para admitir nubes y entornos de AWS aislados sin conectividad a Internet saliente. : Las implementaciones administradas por el cliente de ADC/Gateway (y StoreFront) son compatibles tanto para instancias locales como basadas en AWS EC2. NO: Los entornos de AWS aislados no tienen acceso a Citrix Cloud o Citrix Cloud Government, por lo que Gateway Service y Workspace Service no están disponibles actualmente.

Resumen, recomendaciones y prácticas líderes

Ahora que hemos revisado algunos de los atributos/funciones/capacidades que ayudan a impulsar las decisiones de los servicios gestionados por el cliente frente a los servicios en la nube para los subsistemas de la capa de acceso, examinemos las decisiones de nivel superior en el contexto de los modelos de implementación que definimos anteriormente.

Capa de acceso: Implementación en Greenfield/Solo Cloud

Dado que el modelo de implementación de campo verde o solo en la nube utiliza servicios en la nube en todos los ámbitos, las implicaciones específicas de AWS en el diseño de su sistema de virtualización Citrix son sencillas: no las hay. No es necesario compilar ni configurar nada en AWS, ya que todo lo necesario para los servicios proxy de interfaz de usuario y HDX se proporciona para usted, configurado y listo para salir de la caja.

La capa de acceso de una implementación de Citrix es un requisito clave para entregar aplicaciones y escritorios virtuales a los usuarios. Si un punto de acceso no es accesible o falla, los usuarios no pueden acceder a sus recursos. El diseño y la implementación de la red pueden ser complicados, pero con Citrix Gateway Service y Citrix Workspace, la redundancia, la conmutación por error, el mantenimiento y la presencia global forman parte del paquete, sin necesidad de conocimientos de red. la huella de infraestructura sustancialmente. Al mover la capa de acceso a un modelo de servicios en la nube, los usuarios pueden acceder de forma segura a los recursos de red desde cualquier parte del mundo. Este enfoque requiere menos esfuerzos de implementación y mantenimiento, por lo que es una excelente opción si quiere ponerse en marcha rápidamente, tener un personal de TI limitado o si la infraestructura no es su enfoque. Con todo lo preconfigurado, este modelo de implementación es el menos personalizable, pero para implementar un sistema simple, seguro, totalmente funcional y accesible globalmente, utilizar Citrix Workspace y Gateway Service para su capa de acceso es el ruta a seguir.

Capa de acceso: implementación híbrida

Con el modelo de implementación híbrida, va a crear y administrar algunos de los componentes del sistema de virtualización de Citrix; de lo contrario, se trata de una implementación de campo verde o solo en la nube por definición. Con el modelo híbrido, es posible que esté implementando Citrix ADC/Gateway VPX en AWS o incluso en las instalaciones, y dependiendo de sus necesidades, también podría implementar Citrix StoreFront en AWS o en las instalaciones. Los clientes que han realizado inversiones significativas en sus soluciones de identidad y puerta de enlace locales pueden beneficiarse de la capacidad de usar Citrix Gateway como proveedor de identidad para Workspace.

Este modelo de implementación es común para implementaciones centradas en la seguridad, implementaciones con infraestructura local actual (ADC o StoreFront) y sitios de DR/failover para centros de datos administrados por el cliente existentes. Una de las consideraciones clave para este modelo es mantener los usuarios, recursos y puntos de acceso lo más cerca posible. Elija regiones de AWS cerca de las ubicaciones de recursos locales en las que quiere implementar la capa de acceso. Siempre que sea posible, mantenga sus ADC y servidores StoreFront lo más cerca posible entre sí. Aquí es donde las cosas pueden ponerse difíciles. Tenga en cuenta la secuencia de lanzamiento de Citrix Virtual Apps and Desktops al diseñar la implementación híbrida, teniendo en cuenta especialmente que todo el tráfico se redirige a través de Citrix ADC.

Con Citrix ADC/Gateway y StoreFront como instancias basadas en EC2 en AWS, también existe mucho más potencial para la personalización. Además de los múltiples almacenes StoreFront, la autenticación multifactor y varias funciones ADC líderes del sector, las implementaciones híbridas también pueden utilizar servicios nativos de AWS, como Relational Database Service (RDS) y AWS Directory Services. Las implementaciones híbridas permiten una transición a la nube más gradual y dejan espacio para ajustes en la arquitectura a lo largo del ruta, en lugar de los métodos de Lift and Shift.

El enfoque híbrido requiere un mayor nivel de experiencia y un mayor tiempo de entrega para la implementación que el modelo de solo campo y nube, pero puede servir como un estado de transición sólido entre una implementación tradicional administrada por el cliente o en las instalaciones y el estado solo en la nube.

Capa de acceso: Implementación Lift and Shift

Con el modelo de implementación Lift and Shift heredado, está implementando tanto Citrix ADC/Gateway VPX como Citrix StoreFront en AWS, o puede reutilizar las implementaciones locales existentes de estas tecnologías para el mismo propósito. Este tipo de implementación tiende a tener el menor tiempo de entrega para los clientes con entornos de virtualización de Citrix locales existentes, y también es la transición más fácil desde la perspectiva de operaciones y mantenimiento. El personal con experiencia en la gestión de un entorno local tiene un tiempo de aumento más corto con el modelo de implementación Lift and Shift, ya que la infraestructura de Citrix permanece prácticamente sin cambios. Para la capa de acceso específicamente, este método es sencillo y permite muchas personalizaciones. Lift and Shift es un gran primer paso para las implementaciones existentes que se van a la nube o para regiones de AWS nuevas o aislados, pero puede ser un obstáculo para adoptar una arquitectura de avance en la nube en el futuro.

Citrix ADC/Gateway VPX en AWS

La implementación de Citrix ADC/Gateway en AWS es diferente de implementarlo en las instalaciones, aunque al final los gestiona usted mismo. Afortunadamente, la implementación de Citrix ADC/Gateway en AWS está exhaustivamente documentada, por lo que recomendamos revisar los siguientes recursos antes de solidificar el diseño y comenzar la implementación:

Si bien existen posibles variantes para una arquitectura de Citrix ADC/Gateway VPX en AWS, el siguiente diagrama (de la Guía de implementación de inicio rápido de Citrix ADC for Web Applications) muestra una implementaciónde pares Citrix HA Multi-AZ implementada por la plantilla de inicio rápido (con bloques de subredes/CIDR predeterminados):

Diagrama 10: Arquitectura conceptual, Citrix ADC/Gateway VPX en AWS con HA en todas las zonas de disponibilidad Diagrama 10: Arquitectura conceptual, Citrix ADC/Gateway VPX en AWS con HA en todas las zonas de disponibilidad.

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

  • Autónomo: 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 que se implementa con más frecuencia para entornos de producción: se pueden implementar pares de instancias Citrix ADC/Gateway VPX mediante el modo Citrix HA nativo en AWS. Con versiones de firmware anteriores, el par se implementa en la misma zona de disponibilidad de AWS. A partir del firmware de Citrix ADC 12.1, se pueden implementar pares de dispositivos VPX de alta disponibilidad en las zonas de disponibilidad (AZ). Elfuncionamiento de la alta disponibilidad en AWS explica la diferencia entre la implementación de un par de ADC dentro de la misma AZ y entre AZ. Excavamos esta opción más profundamente más adelante en esta sección.

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

Diagrama 11: asignación de interfaz de instancia Citrix ADC VPX para implementaciones de CVAD/DaaS Diagrama 11: asignación de interfaz de instancia Citrix ADC VPX para implementaciones de CVAD/DaaS.

Alta disponibilidad de ADC en todas las zonas de disponibilidad

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 ADC implementados en zonas de disponibilidad mediante la función HA (activo/pasiva) nativa de Citrix ADC o una combinación de las funciones nativas de Balancing de carga de servicio global (GSLB) e IPSet de Citrix ADC. Esta última opción (que se hizo factible a principios de 2020) permite una configuración activa/activa en las AZs, y funciona permitiendo que el ADC actúe como una fuente DNS autorizada. Se espera que esta nueva opción/arquitectura sea popular para las implementaciones de nube pública, por lo que nos centramos en eso aquí.

Los servicios basados en dominios para equilibradores de carga en la nube permiten la detección automática de servicios dinámicos en la nube. Al implementar los ADC de Citrix en varias AZs en una configuración activo-activa, puede utilizar recursos en la nube en diferentes AZs para optimizar la alta disponibilidad/recuperación ante desastres. Cada AZ puede contener recursos de nube en la conocida infraestructura de pod, para permitir la administración sencilla de actualizaciones, parches y escalabilidad para la expansión. Para obtener información detallada sobre la configuración de GSLB entre las AZ de AWS, consulte la documentación de Citrix.

Diagrama 12: Flujo de tráfico antes y después de la conmutación por error de HA en la implementación de HA Multi-AZ Diagrama 12: Flujo de tráfico antes y después de la conmutación por error de HA en la implementación de HA Multi-AZ

En el diagrama anterior, podemos ver que cada ADC tiene una IP virtual de puerta de enlace (VIP) diferente. Esto es característico de una configuración de red independiente (INC). Cuando las VPX de un par HA residen en zonas de disponibilidad diferentes, el ADC secundario debe tener una INC, ya que no pueden compartir direcciones IP asignadas, LAN virtuales o rutas de red. El NSIP es diferente para cada ADC en esta configuración, mientras que los SNIP y los VIP de equilibrio de carga utilizan una función especial de Citrix ADC llamada IPSet, o servidores virtuales multi-IP, que se pueden usar para que los clientes de diferentes subredes se conecten 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 las implementaciones de GSLB en AWS, la IP del servicio puede formar parte del IPSet para el tráfico IPv4 e IPv6.

Para obtener más información sobre cómo agregar un nodo remoto a un ADC para crear un par de alta disponibilidad basado en INC, consulte los documentos de Citrix.

Citrix StoreFront en AWS

La implementación de Citrix StoreFront en AWS no es muy diferente de implementarlo en las instalaciones y, al final, también administra todos los componentes de StoreFront usted mismo. Consulte Planificar la implementación de StoreFront para conocer las consideraciones generales que se aplican a todas las implementaciones, incluida StoreFront en AWS. La principal diferencia es que normalmente se implementan varias instancias de StoreFront en un grupo de servidores StoreFront en varias zonas de disponibilidad de AWS. Es importante tener en cuenta que las entidades habilitadas con este diseño dependen de la latencia entre AZs. Según el plan de la implementación/escalabilidadde StoreFront, las implementaciones de grupos de servidores de StoreFront solo se admiten cuando los enlaces entre servidores de un grupo de servidores tienen una latencia inferior a 40 ms (con las suscripciones inhabilitadas) o inferior a 3 ms (con las suscripciones habilitadas). Asegúrese de medir las latencias entre instancias en todas las AZs que planea hospedar StoreFront y habilitar/inhabilitar las suscripciones en consecuencia.

Ya mencionamos esto en la tabla Consideraciones sobre el servicio de interfaz de usuario y la autenticación anteriormente en este documento, pero vale la pena volver a mencionarlo: para los entornos Citrix DaaS con amplios requisitos de resistencia, Citrix recomienda encarecidamente una implementación de StoreFront para aprovechar al máximo desde la función Caché de host local (disponible en los tipos de infraestructura de intermediación de sesiones CVAD y DaaS). Para CVAD, esto proporciona resiliencia si hay una interrupción de la base de datos. Para DaaS, esta arquitectura proporciona resistencia en caso de que Cloud Connectors no pueda llegar a Citrix Cloud. En cualquier caso, los usuarios desconectados 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é de host local, consulte Caché de host local (DaaS) y Caché de host local (CVAD).

Si bien nos referimos al tema de la resiliencia, Citrix también recomienda que la implementación de StoreFront abarque varias AZs (si la región de AWS incluye varias AZs), pero recuerde tener en cuenta el diseño de ADC. Citrix ADC se utiliza a menudo delante de instancias de StoreFront para proporcionar equilibrio de carga y resistencia adicional del servicio.

Al utilizar Citrix Zones, la redundancia de StoreFront se puede integrar mediante la distribución de zonas satélite en dos o más AZ en una VPC con un solo sitio. Usar Zones es una excelente manera de tener recursos lo más cerca posible de los usuarios y altamente disponibles. Las zonas satelitales contienen servidores StoreFront, Delivery Controllers y recursos de aplicaciones y escritorios, dejando la zona principal con la configuración completa de la infraestructura, incluido el servidor de licencias y SQL. Esto permite la escalabilidad de la interfaz de usuario web de StoreFront y se puede organizar la creación/destrucción de zonas. Mantener las Zonas más pequeñas permitirá una escalabilidad óptima de este a oeste y reducirá el impacto en caso de interrupción.

StoreFront en AWS es totalmente personalizable, incluidos los grupos de aplicaciones destacadas, la página de presentación, el color y el logotipo, y las aplicaciones y los escritorios se pueden organizar de la mejor manera según sus necesidades específicas. StoreFront en AWS también requiere una administración y una ingeniería bien informadas para mantenerse al día, pero puede proporcionar una interfaz de usuario web potente, especialmente cuando se integra con Citrix ADC.

Consideraciones de capa de recursos

El diseño de capa de recursos se centra en la personalización, las aplicaciones y el diseño de imágenes. La capa de recursos es donde los usuarios interactúan con escritorios y aplicaciones. Al implementar un sistema de virtualización Citrix en AWS, los aspectos clave que hay que tener en cuenta (aparte de todo lo “normal” que no cubriremos aquí) son:

  • Almacenamiento CIFS y replicación de datos: Independientemente de las herramientas que utilice para administrar la configuración de personalización de usuarios (el perfil de Windows de los usuarios y las carpetas redirigidas), debe tener recursos compartidos de archivos de Windows para almacenarlos. Si tiene VDA en varias regiones (y los usuarios pueden acceder a las aplicaciones/escritorios en más de una), entonces también tiene que lidiar con la replicación de datos. Muchas aplicaciones también usan recursos compartidos de archivos de Windows, por lo que el almacenamiento CIFS y la replicación de datos también son importantes para ellos.
  • Diseño de imágenes: Citrix App Layering y Citrix Provisioning Services (PVS) no admiten actualmente Amazon EC2: los clientes que alojan una ubicación de recursos en AWS utilizan Machine Creation Services para la creación, gestión y actualización de flotas de VDA.

Almacenamiento CIFS y replicación de datos

La mayoría de los sistemas de virtualización de Citrix en AWS 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. Cuando estos recursos compartidos no están disponibles, la experiencia del usuario y la funcionalidad de la aplicación sufren, por lo que es importante asegurarse de que cualquier solución que elija para proporcionar recursos compartidos de archivos compatibles con Windows esté altamente disponible 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 la configuración de datos de aplicación/usuario debe estar disponible en la región donde se ejecutan las aplicaciones o escritorios. En la siguiente sección se describen algunas soluciones a tener en cuenta para proporcionar servicios de replicación de datos y almacenamiento CIFS en AWS.

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 servicios gestionados por el cliente como en la nube están disponibles para su uso cuando los sistemas de virtualización Citrix se ejecutan en AWS.

Administrado por el cliente: servidores de archivos de Windows en Amazon EC2

La primera solución que muchos clientes consideran para proporcionar servicios de archivos compatibles con Windows en AWS es crear sus propios servidores de archivos Windows en EC2 para servir cada ubicación de recursos en AWS. 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 dedicarse a crear y administrar los suyos propios, ya que esto es algo que saben hacer. En el nivel más básico, el cliente activa una o más instancias de Windows EC2, adjunta un volumen adicional de Amazon Elastic Block Store (EBS), une las instancias a su Active Directory y se ocupa de configurar y 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 con servidores de archivos en varias zonas de disponibilidad y con Windows DFS-N/DFS-R, aunque es fácil terminar en una configuración no admitida (según Microsoft) si no tiene 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. Un punto más a tener en cuenta, ya que el sistema de virtualización de Citrix se ejecutará en AWS: un nuevo evento de implementación o migración puede brindar una excelente oportunidad para evaluar el uso de un servicio en la nube para los servicios de archivos de Windows en lugar de crear el suyo propio. Afortunadamente, Amazon tiene algunas opciones de servicio en la nube que vale la pena considerar. Ahora tocamos algunos de estos.

Servicio en la nube: Amazon FSx para Windows File Server

FSx for Windows File Server de Amazon es un servicio en la nube que los clientes pueden utilizar en AWS. FSX para Windows File Server proporciona un sistema de archivos Windows nativo y totalmente administrado y almacenamiento basado en SSD con un rendimiento uniforme de submilisegundos. Dado que FSx se basa en Windows Server, ofrece un sistema de archivos totalmente nativo y compatible con Windows que proporciona almacenamiento y protección para los sistemas de virtualización Citrix en AWS. FSX para Windows File Server también es Citrix Ready Verified, lo que significa que esta solución compatible con AWS ha sido validada por Citrix para que sea compatible con Citrix Virtual Apps and Desktops. Aunque Citrix no es compatible oficialmente con Citrix, el servicio es fundamentalmente nativo de Microsoft Windows file server: solo lo gestiona AWS en lugar del cliente. Para obtener más información, consulte Amazon FSX para Windows File Server en Citrix Ready.

Para los equipos de TI, esta es una excelente opción que elimina muchas de las tareas más mundanas o de bajo valor en torno a la implementación y administración del almacenamiento de información. Lo que es más importante, el uso de FSx descarga la seguridad, la protección/copia de seguridad de datos, el cumplimiento normativo, las tareas de actualización y parches de software y el supervisión de la infraestructura de almacenamiento de información para asegurarse de que cumple los niveles de servicio requeridos. Los equipos de TI pueden tratar todo el servicio de archivos FSx como una única plataforma operativa en lugar de administrar un servidor de archivos del sistema operativo Windows, almacenamiento, redes, etc. Además, FSx admite todas las herramientas de administración comunes que ya utiliza, como la integración con Active Directory (AD), los espacios de nombres DFS de Windows, la replicación DFS y otras.

Cada sistema de archivos administrado por FSX que cree se convierte esencialmente en un servidor de archivos de alta disponibilidad y durabilidad en una zona de disponibilidad específica. Para dar servicio a un sistema de virtualización Citrix, los clientes deben asegurarse de que estos “file systems” estén altamente disponibles. Esto se puede lograr aprovisionando sistemas de archivos administrados por FSx en varias zonas de disponibilidad y mediante Windows DFS-N/DFS-R para crear recursos compartidos de archivos de Windows de alta disponibilidad, aunque es fácil terminar en una configuración no admitida (por Microsoft) si no tiene cuidado.

Nota: Dado que FSx es un servidor de archivos de Windows, 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.

Más opciones de servicios en la nube

Además del servicio de archivos de Windows administrado por primera vez de Amazon, AWS admite muchas opciones más amplias y ricas en funciones, algunas de las cuales se integran con tecnologías de almacenamiento locales tradicionales. Aunque estas otras opciones están fuera del ámbito de este documento, hay muchas opciones entre las que elegir. Un buen lugar para empezar a explorar las opciones es AWS Marketplace. Estos tipos de soluciones pueden ser especialmente relevantes para casos de uso más complejos y de varias regiones donde se necesita replicación de datos fiable y resistente.

Almacenamiento de información y replicación de datos CIFS: Resumen y Conclusiones

Los clientes pueden administrar su propio recurso compartido de archivos DFS de alta disponibilidad, beneficiarse de esto como un servicio de AWS (FSx) para ahorrar en el esfuerzo de administración o utilizar soluciones de dispositivos de almacenamiento de terceros para extenderse en un entorno local. Citrix recomienda que los clientes analicen los pros y los contras de cada uno para determinar la solución adecuada para ellos.

Diseño y gestión de imágenes

En un sistema de virtualización de Citrix en AWS, las aplicaciones y los escritorios se entregan a través de instancias EC2 denominadas “VDA” (el nombre del software Virtual Delivery Agent de Citrix, que se instala en instancias de Windows o Linux que contienen las aplicaciones que entrega el sistema de virtualización Citrix). Se aprovisiona y mantiene un grupo de VDA idénticos en “Catálogos de máquinas”, una construcción de administración definida y mantenida a través del subsistema de administración e intermediación de sesiones (tanto DaaS como CVAD). La creación, el tamaño y la administración de estas instancias es clave, ya que muchos sistemas tienen un gran número de VDA y la pila de software en un VDA cambia con frecuencia a medida que se aplican revisiones, service packs y actualizaciones de software. Analizamos algunas de las consideraciones de nivel superior en esta sección.

Administración de imágenes y aprovisionamiento de VDA

En AWS EC2, los sistemas de virtualización de Citrix utilizan la tecnología de aprovisionamiento de Machine Creation Services (MCS) de Citrix para la implementación de VDA y la administración de imágenes. MCS utiliza una cuenta de servicio de IAM en EC2 para orquestar el proceso de masterización (convertir una instantánea del disco del sistema de una máquina virtual de plantilla en una AMI generalizada), el proceso de clonación (creación y administración de una flota de instancias de VDA basadas en la AMI creada a partir de la instantánea de la máquina virtual de plantilla), escalar automáticamente Entrega Grupos, actualización de imágenes implementadas y mucho más. Trataremos de MCS en AWS con mucho más detalle en las secciones Consideraciones sobre la capa de control de este documento.

Nota: los clientes que ya utilizan MCS para sus entornos locales pueden notar algunas diferencias entre las opciones disponibles al aprovisionar máquinas en AWS. Las instancias de VDA administradas por MCS en EC2 tienen dos discos conectados: el disco del sistema (una copia de lectura/escritura de la AMI de imagen de plantilla creada durante el proceso de masterización) y un disco de personalidad de 1 GB. Dependiendo del tipo de catálogo de máquinas y las opciones de conexión de alojamiento configuradas, el disco del sistema (y a veces la instancia de máquina virtual) se eliminará al apagar y volver a crearse en “encendido” (para catálogos agrupados o compartidos) o se conservarán (para tipos de catálogo persistentes). Consulte CTX234562 para obtener más información.

Modelos de entrega y persistencia

Elegir los modelos de entrega adecuados es fundamental y tiene implicaciones amplias que van más allá de los costes. La tecnología de virtualización de Citrix admite tres modelos de entrega principales, que se pueden combinar y combinar y utilizar en combinación para admitir muchos casos de uso diferentes. Los tres modelos de entrega son:

  • Compartido hospedado: el modelo compartido alojado utiliza con mayor frecuencia un sistema operativo Windows Server con el rol RDSH instalado, aunque las instancias de Linux pueden proporcionar la misma funcionalidad para aplicaciones compatibles. Con este modelo, una única instancia de VDA puede admitir varios usuarios simultáneos, cada uno ejecutando un escritorio completo o conectándose a una o más aplicaciones publicadas. Cuando se utiliza el OS/RDSH de Windows Server con la experiencia de escritorio y los componentes relacionados instalados, los escritorios y las aplicaciones parecen y sienten que se ejecutan en un sistema operativo de escritorio Windows. Dado que cada usuario de una instancia determinada comparte instancia del sistema operativo, los administradores suelen preinstalar y configurar la combinación de aplicaciones en instancias compartidas alojadas, y los usuarios no tienen derechos de administrador local para el sistema operativo. Las instancias compartidas alojadas también se pueden ejecutar en infraestructura compartida y se pueden consumir mediante modelos de precios de instancias reservadas y bajo demanda. Por lo general, los administradores implementan una flota de instancias para admitir el modelo compartido alojado, y los tipos de servicios en la nube y gestionados por el cliente de subsistemas de intermediación de Citrix proporcionan sofisticadas capacidades de equilibrio de carga para garantizar que cada usuario experimente un rendimiento adecuado. Las instancias compartidas alojadas también pueden utilizar tipos de instancias en reserva por GPU en AWS para aumentar el rendimiento de cargas de trabajo con un uso intensivo de gráficos que pueden beneficiarse de una GPU, aunque el proveedor de GPU puede requerir licencias adicionales. Tanto el SO de servidor Windows como las licencias CAL de RDS se pueden “alquilar” bajo el modelo de licencias SPLA de Microsoft, aunque los clientes pueden evitar estos costes adicionales mediante Linux como sistema operativo. Este modelo es, sin duda, el más rentable para ejecutarse en AWS.
  • VDI de servidor: el modelo “VDI de servidor” (Infraestructura de escritorio virtual) también utiliza un sistema operativo Windows Server, y con la experiencia de escritorio y los componentes relacionados instalados, se vaya y se siente al usuario como un sistema operativo de escritorio Windows. La función RDSH no se instala con este modelo, por lo que una instancia admite un usuario a la vez, y a veces los usuarios reciben derechos elevados para el SO de servidor para que puedan instalar sus propias aplicaciones. Al igual que las instancias compartidas alojadas, las instancias VDI de servidor también se pueden ejecutar en infraestructura compartida, se pueden consumir mediante modelos de precios de instancias reservadas y bajo demanda, pueden usar tipos de instancias en reserva por GPU y las CAL de Microsoft OS y RDS se pueden “alquilar” bajo el modelo de licencia SPLA de Microsoft. Dadas las herramientas disponibles en la actualidad, el 99% de las aplicaciones Windows se pueden instalar y ejecutar en el sistema operativo Windows Server, y aunque a veces los proveedores de software no admiten explícitamente sus aplicaciones en Windows Server, la mayoría de las aplicaciones Windows se ejecutan tan bien en Windows Server como en un SO de escritorio Windows. También vale la pena señalar que las instancias de VDI de servidor también pueden utilizar tipos de instancias en reserva por GPU en AWS para aumentar el rendimiento de cargas de trabajo con un uso intensivo de gráficos que pueden beneficiarse de una GPU, aunque el proveedor de la GPU puede requerir otras licencias. Este es el segundo modelo de entrega más rentable que se ejecuta en AWS.
  • VDI de cliente: el modelo de entrega de VDI cliente normalmente utiliza un sistema operativo de escritorio Windows como Windows 10 o Windows 7, aunque también se puede usar una versión del sistema operativo Linux compatible. VDI de cliente es un modelo 1:1, lo que significa que cada usuario único requiere su propia instancia de sistema operativo. Los clientes que son nuevos en la tecnología de virtualización de Citrix suelen entrar en este tipo de proyectos pidiendo VDI de cliente, a pesar de que hay modelos más rentables disponibles. Su vernácula también puede haber sido influenciada por otros proveedores de virtualización cuyas pilas de tecnología no admiten modelos de implementación de VDI de servidor o compartidos alojados. El modelo VDI del cliente, mientras se vaya ‘simple’ en la superficie, se complica mucho más a medida que se adentra en él, aunque la mayor parte de la complejidad se puede evitar mediante Linux como sistema operativo. La mayor parte de esta complicación está impulsada por los requisitos de licencia de Microsoft para el sistema operativo de escritorio Windows que, a diferencia de Windows Server, no está disponible a través del programa de licencias SPLA de Microsoft. Como tal, los clientes deben traer su propia licencia para estos productos. Además, las instancias VDI de cliente basadas en escritorio de Windows no se pueden ejecutar en la infraestructura compartida. Esto significa que las instancias VDI de cliente deben ejecutarse en instancias dedicadas de AWS o en hosts dedicados de AWS. Esto aumenta sustancialmente el coste y la complejidad de administrar la infraestructura requerida, reduce la flexibilidad y las opciones de control de costes, y resulta costoso rápidamente. Como es de esperar, las instancias de VDI cliente también pueden utilizar tipos de instancias en reserva por GPU en AWS para aumentar el rendimiento de cargas de trabajo con un uso intensivo de gráficos que pueden beneficiarse de una GPU, aunque el proveedor de la GPU puede requerir más licencias. La VDI de cliente es el modelo de entrega más caro para ejecutarse en AWS. Para ambos modelos VDI, otra consideración importante es el modelo de persistencia. Las instancias de VDI se pueden asignar aleatoriamente a usuarios sin persistencia (agrupadas) o los usuarios pueden tener máquinas asignadas que persisten y sean personalizadas (dedicadas). Las instancias agrupadas pueden ser más fáciles de administrar con el tiempo, ya que todas las instancias de un grupo determinado son idénticas. El MCS de Citrix puede actualizar los discos del sistema conectados a instancias agrupadas con unos pocos clics, y la administración de capacidad/costes es más eficaz, ya que un grupo de instancias inactivo puede servir a muchos usuarios. Las instancias agrupadas son un poco menos flexibles que las dedicadas, ya que los cambios del usuario final en las instancias agrupadas no suelen persistir entre los reinicios, aunque tecnologías como la capa de usuario de Citrix App Layering o la capa de personalización lanzadas en CVAD 1912 se pueden utilizar para minimizar el impacto en la experiencia del usuario. Las instancias dedicadas también pueden ser más difíciles de administrar desde una perspectiva de costes, ya que a menudo es difícil predecir cuándo un usuario iniciará sesión, el usuario debe esperar mientras se inicie su instancia o los administradores deben mantenerlas ejecutándose durante las ventanas de tiempo donde se espera que cada usuario inicie sesión.

Aunque ya lo hemos mencionado anteriormente, lo volveremos a mencionar aquí para mayor claridad: se pueden usar varios tipos de Linux en un sistema de virtualización Citrix, siempre y cuando una o más aplicaciones se ejecuten en Linux. La tecnología de virtualización de Citrix admite modelos de entrega compartidos y VDI alojados, modelos persistentes y agrupados y tipos de instancias en reserva por GPU. Las experiencias de usuario y administrador son diferentes a las de las instancias basadas en Windows, pero los VDA basados en Linux suelen ser mucho menos costosos de ejecutar ya que no requieren licencias de Microsoft.

Por último, volvamos a examinar la consideración de la aceleración de la GPU. Los tres modelos de entrega (tanto para Linux como para Windows) pueden utilizar instancias de GPU aceleradas de NVIDIA en AWS. Las instancias de la serie G se pueden utilizar para casos de uso acelerado de gráficos, pero aún no son comercialmente viables para uso general. Tenga en cuenta que Citrix no admite la GPU AWS Elastic en la actualidad, pero dado que la GPU Elastic solo funciona para OpenGL, su impacto en las cargas de trabajo de gráficos típicas de la empresa es mínimo.

Entonces, ¿qué modelos de entrega usas? Vale la pena señalar que puede mezclar y combinar modelos de entrega en el mismo sistema para satisfacer las necesidades de diferentes grupos de usuarios o casos de uso. El modelo de entrega más rentable desde el punto de vista de la infraestructura es el host compartido. La combinación de SO de servidor con concurrencia multiusuario es altamente eficiente, y el número de usuarios por máquina virtual se puede dimensionar según el tipo de usuario (por ejemplo, trabajador de tareas frente a trabajador de conocimiento frente a usuario avanzado) para garantizar una gran experiencia. Para situaciones en las que los usuarios y las aplicaciones requieren capacidades adicionales que no se satisfacen con el host compartido, VDI es el ruta a seguir. La VDI de servidor debe evaluarse primero: es sustancialmente más rentable ejecutar que Windows 10 VDI para cargas de trabajo de Windows, y VDI de servidor puede ofrecer un escritorio que se vaya y se siente similar a Windows 10. Además, Server VDI no tiene el requisito de EULA de Microsoft para usar instancias/hosts dedicados: VDI de cliente (implementación de Windows 10 o, a veces, Windows 7) lo hace. En el caso de cargas de trabajo basadas en Windows en AWS, la VDI de cliente debe considerarse como último recurso y debe implementarse únicamente cuando no sean posibles los modelos de entrega de VDI de servidor y compartidos alojados.

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. 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 AWS, ya que es considerablemente más rentable y más fácil de administrar.

Modelo de facturación de instancias de AWS

Una vez que haya decidido qué modelo de entrega usar (host compartido, VDI de servidor o VDI cliente), el siguiente paso es planificar un modelo de facturación bajo demanda por hora o un modelo de facturación reservado. Lo ideal es que se paguen tantos VDA como sea posible por horas con el modelo de facturación a petición y se utilice la función de escalabilidad automática de Citrix para controlar los costes. Mediante el uso de Citrix Autoscale (una función exclusiva del subsistema de intermediación de servicios en la nube de DaaS), las máquinas virtuales se encienden según sea necesario con anticipación a las horas pico. Sin embargo, durante las horas pico fuera de las horas pico, las máquinas virtuales se apagan, por lo que es importante consolidar las cargas con el modelo compartido con host y, para todos los modelos, garantizar que los usuarios guarden su trabajo e idealmente cerrar sesión correctamente de sus sesiones. La capacidad de instancia reservada se puede utilizar para componentes de infraestructura como Cloud Connectors (que permanecen en 24/7) y un número predeterminado de VDA que siempre permanecerán activos (por ejemplo, el 10% del pico). Además de ofrecer un descuento significativo en comparación con los precios bajo demanda, las instancias de reserva también proporcionan una reserva de capacidad cuando se utilizan en una zona de disponibilidad específica.

Gestión de Costes y Tamaño de Instancias de VDA

Al ejecutar una flota de agentes VDA en AWS, elegir el tipo de instancia adecuado para sus diferentes cargas de trabajo (VDA) es una decisión clave, con importantes consideraciones de rendimiento, capacidad de administración y costes. Elija una instancia demasiado pequeña y el rendimiento puede sufrir. Elija una instancia demasiado grande y pagará por los recursos que no está mediante. Elegir el tipo de instancia correcto termina siendo un acto de equilibrio y, a menudo, requiere un ajuste preciso para cada carga de trabajo específica.

El tipo de instancia de AWS EC2 que elija para sus VDA depende en gran medida de la carga de trabajo y el tipo de entrega específicos. Sin embargo, como pauta general, las instancias de la serie “M” suelen ser más adecuadas para compartidas en host, mientras que las instancias de la serie “T” son adecuadas para VDI. La serie “M” tiene CPU y RAM equilibradas diseñadas para el consumo de recursos en su mayoría predecible en múltiples sesiones en un host. Las series “T” son de naturaleza “explotable” diseñadas para las funciones en su mayoría impredecibles de VDI (por ejemplo, un minuto un usuario está inactivo y al siguiente está ejecutando un cálculo macro). Para obtener más información sobre la selección y el precio del tipo de instancia, los lectores pueden consultar la presentación de estimación de costes de Citrix on AWS (en la sección de fuentes).

Para obtener más información sobre la selección de instancias (especialmente en lo que respecta al modelo de entrega compartida alojada), consulte Citrix Scalability in a Cloud World “Edición 2018. Este artículo, aunque es ligeramente anticuado, analiza las prácticas principales con respecto a la selección de instancias basadas en el rendimiento, la capacidad de administración, el coste, los modelos de precios reservados frente a la demanda y las pruebas de escalabilidad 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.

Nota: Algunos tipos de instancias de AWS más recientes no se mostrarán de forma predeterminada en el asistente de creación de catálogos de máquinas de Studio (ya sea CVAD o DaaS). La interfaz de usuario se rellena con tipos de instancias de un archivo XML estático que reside en Delivery Controllers (CVAD) o Cloud Connectors (DaaS). Este XML se puede modificar para incluir tipos de instancias más recientes, pero este archivo se sobrescribe con valores predeterminados durante las actualizaciones (tanto las actualizaciones de Cloud Connector iniciadas por Citrix como las actualizaciones de Delivery Controller iniciadas por el cliente). Consulte CTX139707 para obtener más información sobre cómo actualizar la lista de tipos de instancias de AWS disponibles. Durante esta ronda de pruebas (una referencia puntual), el tipo de instancia M5.2XLarge (8 vCPU, 32 GB de RAM) resultó ser el ganador en términos de $/usuario/hora (con una carga de trabajo de muestra estándar del sector). Sus números, dadas las funciones específicas de su carga de trabajo y los precios disponibles de AWS, pueden variar, pero el proceso y las herramientas se pueden utilizar para aproximar los costes mensuales de IaaS con mayor precisión. Independientemente de cómo determine los tipos de instancia con los que comience, es importante supervisar el uso a lo largo del tiempo y ajustar según sea necesario para mantener el equilibrio entre la disponibilidad de recursos, el consumo y el coste. Los clientes deben considerar el uso de servicios como Citrix Analytics for Performance, ya que la información que proporcionan estos servicios puede desempeñar un papel clave para mantener el rendimiento alto y los costes bajos.

Diseño de aplicaciones

Una consideración adicional incluye el diseño de la aplicación. A medida que los clientes planean migrar cargas de trabajo a una plataforma en la nube como AWS, deben asegurarse de que el rendimiento de las aplicaciones no se vea afectado. Una regla general que se ha aplicado desde hace más de 20 años es que los datos deben residir lo más cerca posible de la carga de trabajo. Esto significa que las arquitecturas de aplicaciones más complejas deben respetar esta regla. Un ejemplo de esto incluye aplicaciones con front-end y back-end (base de datos). Para evitar agregar latencia que afectará al performance de las aplicaciones, tanto el front-end como el back-end deben migrarse. Una alternativa sería un enfoque híbrido que utilizara una combinación de cargas de trabajo locales (para aplicaciones complejas) y alojadas en la nube (para aplicaciones simples). Es importante consultar siempre con los proveedores de aplicaciones para obtener compatibilidad. La matriz de decisiones de Tech Zone vinculada compara los diferentes métodos de entrega alojados compartidos, que incluyen aplicaciones compartidas alojadas (de un solo uso y multiuso) y escritorios compartidos alojados. El proceso de toma de decisiones de segmentación de cargas de trabajo que se describen en este artículo se puede utilizar como guía para el proceso de diseño de la carga de trabajo.

Una última palabra sobre el diseño de la aplicación: el dispositivo Enterprise Layer Manager no se ejecuta actualmente en AWS y actualmente no admite la exportación de imágenes en capas a un formato de disco consumible inmediatamente para su uso en AWS. Si el soporte de App Layering en AWS es fundamental para la migración o la implementación, envíe un correo electrónico a aws@citrix.com con información sobre su proyecto. Se le agregará a la lista para ser un candidato a los primeros adoptantes para futuras versiones, y su voz será escuchada. Para obtener más información sobre Citrix App Layering, consulte la documentación del producto y la arquitectura de referencia de App Layering.

Consideraciones de capa de control

En Citrix Architectural Design Framework, la capa Control define los componentes que controlan la solución Citrix. Esto incluye componentes como Active Directory (bosque/dominio, unidad organizativa y estructura de grupos de usuarios, directivas de grupo, etc.), uso de bases de datos Microsoft SQL, licencias Citrix, intermediación y administración de sesiones, administración de cargas y aprovisionamiento de VDA y administración de imágenes. Al igual que en las secciones anteriores de este documento, aquí nos centramos en las consideraciones más importantes para los sistemas de virtualización de Citrix en AWS, y proporcionamos enlaces a la documentación y orientación existentes sobre otros.

Una de las decisiones más impactantes que está tomando para los componentes de la capa de control es la elección de intermediación y administración de sesiones. Esta decisión es fundamental, con implicaciones sustanciales en el coste, la complejidad, la disponibilidad y los esfuerzos de mantenimiento continuos. Comenzamos revisando los modelos de implementación que presentamos anteriormente en este documento y, a continuación, profundizamos en las consideraciones específicas de AWS.

Capa de control: Implementación Greenfield/Solo en la nube

El modelo de implementación de campo verde o solo en la nube utiliza servicios en la nube en todo el bordo. n). Las implicaciones específicas de AWS en el diseño de su sistema de virtualización Citrix son mínimas, pero le guiamos a través de ellas de todos modos. Dado que Citrix Cloud proporciona la mayoría de los componentes administrativos y de infraestructura como servicio, no tendrá que preocuparse por las bases de datos SQL, los servidores de licencias Citrix, los servidores de Citrix Director y mucho más.

Capa de control: implementación híbrida

Recuerde que con el modelo de implementación híbrida, va a crear o administrar algunos de los componentes del sistema de virtualización de Citrix, de lo contrario, se trata de una implementación de campo verde o solo en la nube por definición. Lo interesante aquí es que, en el contexto de la capa Control, son casi idénticos.

Capa de control: Implementación Lift and Shift

Con el modelo de implementación Lift and Shift heredado, está implementando todos los componentes clave de la capa de control (incluidos Active Directory y todos los componentes de intermediación y gestión de sesiones de Citrix) en AWS. Si tiene que ir por el sendero “Lift and Shift”, es a la vez una bendición y una maldición. Es una bendición porque la mayoría de estas consideraciones han sido documentadas a fondo en varios trabajos publicados que ya están disponibles. Es una maldición que tendrá mucho más trabajo por hacer tanto por adelantado como con el tiempo para construir, administrar, proteger y mantener estos componentes.

Si usa “Lift and Shift”, querrá revisar y hacer referencia a lo siguiente antes de continuar: colectivamente, abarcan la mayoría de las decisiones de diseño que debe considerar para implementar correctamente Citrix en AWS mediante el modelo de implementación de elevación y desplazamiento:

Consideraciones de Active Directory

Todos los modelos de implementación para sistemas de virtualización Citrix en AWS requieren Microsoft Active Directory. Para una experiencia de usuario convincente, los servicios funcionales de Active Directory deben estar disponibles en todas las regiones de AWS en las que haya implementado VDA. La estructura y complejidad de la implementación de Active Directory se deben considerar cuidadosamente, pero afortunadamente la virtualización de Citrix se puede integrar de forma flexible con varios diseños de AD y modelos de mantenimiento diferentes.

Al implementar Active Directory en AWS, los clientes pueden crear o mantener sus propios controladores de dominio de Active Directory mediante instancias de Windows Server, usar AWS Directory Service for 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 los gastos administrativos necesarios para crear y mantener servicios de Active Directory funcionales, el servicio de directorio de AWS para Microsoft Active Directory (también conocido como AWS Managed Microsoft AD) 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. AWS Managed Microsoft AD se basa en una infraestructura gestionada por AWS de alta disponibilidad. Cada directorio se implementa en varias zonas de disponibilidad y la supervisión detecta y reemplaza automáticamente los controladores de dominio que fallan. Además, la replicación de datos y las instantáneas diarias automatizadas están configuradas para usted. No es necesario instalar software y AWS gestiona todos los parches y actualizaciones de software. Con AWS Managed Microsoft AD, puede utilizar herramientas administrativas nativas de Microsoft, administrar máquinas Windows y usuarios con la directiva de grupo de Microsoft, unir instancias EC2 e instancias de AWS RDS para SQL Server e incluso configurar confianzas de Active Directory con instancias de AD existentes para admitir diversas empresas complejas casos.

Los clientes que opten por utilizar el servicio AWS Managed Microsoft AD con tecnologías de virtualización de Citrix pueden esperar que estas tecnologías funcionen con este servicio de AWS, aunque hay algunas consideraciones 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.

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 MCS de Citrix: debe elegir crear las cuentas de máquina para sus VDA administrados de MCS en un contenedor/unidad organizativa que se pueda escribir; si no elige tal ubicación, MCS no podrá 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 utilizarán la tecnología Federated Authentication Services (“FAS”) de Citrix (que requiere servicios de certificados integrados de AD): estos clientes deben crear y administrar su propio Active Directory en AWS mediante instancias de EC2 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 el servicio AWS Managed Microsoft AD, debe 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 de 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 tratarán en este documento, Citrix ha proporcionado amplia documentación sobre estos temas aplicable a los tres modelos de implementación.

**Nota: ** AWS Directory Service for Microsoft Active Directory es una oferta de “Citrix Ready Verified”. Aunque Citrix no es compatible oficialmente con Citrix, el servicio es fundamentalmente nativo de Microsoft Active Directory: solo lo gestiona AWS en lugar del cliente. Este servicio de AWS tiene algunas limitaciones impuestas para entregarlo como un servicio a escala, y las limitaciones actualmente conocidas y de mayor impacto para un entorno de Citrix se enumeran aquí. Para obtener más información sobre los requisitos de Active Directory para las implementaciones de campo ecológico e híbridas (entornos que utilizan Citrix Cloud y el servicio CVAD para la intermediación y la administración de sesiones), 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 describen los escenarios de implementación de Cloud Connectors en Active Directory.

Para obtener más información sobre los requisitos de Active Directory para las implementaciones de elevadores y turnos (entornos que utilizan la intermediación y la administración de sesiones gestionadas por el cliente a través de las versiones LTSR o CR de Citrix Virtual Apps and Desktops), consulte los requisitos del sistema CVADy los niveles funcionales de Active Directory.

Intermediación de sesiones y consideraciones de administración

Como probablemente ya haya recopilado, la elección de cómo proporcionar servicios de intermediación y administración de sesiones es fundamental, y tiene implicaciones de amplio ámbito en el coste general, la capacidad de administración, el mantenimiento y las capacidades disponibles para su sistema de virtualización Citrix. Como ya hemos comentado, Citrix recomienda el uso del servicio Citrix Cloud (DaaS) para este componente crítico, pero para ciertos requisitos y casos, puede ser necesario o recomendable implementar un subsistema de administración y intermediación de sesiones administrado por el cliente (a través de las versiones CVAD LTSR o CR). En la siguiente tabla se destacan algunos de estos requisitos y casos para su consideración:

Atributo/Capacidad CVAD administrado por el cliente (versiones Citrix Virtual Apps and Desktops, LTSR o CR) Cloud Service DaaS (Citrix DaaS, proporcionado por Citrix Cloud)
Requiere conectividad de Internet saliente a Citrix Cloud. NO: Delivery Controllers no requieren conectividad a Internet saliente, aunque deben poder comunicarse con la infraestructura de AWS para que funcione el aprovisionamiento de MCS. : Cloud Connectors se comunican a través de Internet con Citrix Cloud, aunque estas conexiones se pueden utilizar por proxy. Consulte Cómo configurar un servidor proxy para Citrix Cloud Connector para obtener más información. Para implementaciones estrictamente aisladas, esto suele ser un obstáculo.
Requiere que el cliente proporcione servicios de base de datos Microsoft SQL de alta disponibilidad. : CVAD (tanto en tipos de versión LTSR como CR) requiere que el cliente proporcione servicios de base de datos Microsoft SQL de alta disponibilidad. Estos se pueden proporcionar mediante la creación de servidores SQL en instancias de EC2 o mediante el servicio AWS RDS for SQL Server. NO: DaaS no requiere que los clientes toquen el servidor SQL: los servicios de base de datos de alta disponibilidad los proporciona la plataforma de entrega de Citrix Cloud y son transparentes para los clientes.
Requiere que el cliente aplique parches y actualizaciones al software Citrix a lo largo del tiempo para mantener la seguridad y la compatibilidad, así como para obtener acceso a nuevas funciones y capacidades. : Los clientes son responsables de la instalación, configuración, parches, protección y actualización tanto del software Citrix como del sistema operativo subyacente para todos los componentes de un sistema de intermediación y administración de sesiones basado en CVAD. También son responsables de mantener la alta disponibilidad de cada componente, incluidos Citrix Delivery Controllers, instalaciones de Studio, Director y Citrix Licensing. NO: Citrix actualiza y mantiene automáticamente los Cloud Connectors (el único componente administrativo y de intermediación de sesiones que reside en la VPC del cliente). Los clientes son responsables de la aplicación de parches y mantenimiento del sistema operativo Windows Server en las instancias de EC2 Cloud Connector, y las nuevas funciones y capacidades están disponibles inmediatamente, sin necesidad de que el cliente actualice manualmente los Cloud Connectors.
Capacidad para usar los servicios avanzados proporcionados por Citrix Cloud, incluida la función de escalabilidad automática de Citrix. A veces, no todos los servicios avanzados están disponibles para implementaciones de CVAD gestionadas por el cliente y, cuando lo están, pueden requerir la instalación y configuración de componentes adicionales. La función Escalado automático no está disponible para entornos CVAD. SÍ, DaaS está diseñado para funcionar “desde el primer momento” con otros servicios de Citrix Cloud y, por lo general, estos servicios están preconfigurados para que el cliente simplemente los active. La función de escalabilidad automática, que proporciona la capacidad de controlar de forma granular la cantidad y el estado de energía de los VDA, tiene un gran impacto en las implementaciones de VDA en la nube pública. Puede proporcionar ahorros sustanciales en costes de infraestructura en casos en los que usted está pagando solo por la capacidad que necesita.
Capacidad de tener un control completo sobre todos los componentes del subsistema, incluyendo el momento de las actividades de actualización y mantenimiento. : Dado que cada componente es instalado, configurado y mantenido por el cliente, el cliente tiene un control completo sobre el control de versiones, configuración y disponibilidad de cada componente (aunque con un coste sustancialmente mayor de infraestructura, complejidad y sobrecarga administrativa). NO: con DaaS, los clientes renuncian a cierta medida de control, pero obtienen simplicidad, menores costes de infraestructura y gastos administrativos sustancialmente reducidos.
Capacidad para obtener licencias basadas en usuarios simultáneos frente a usuarios nombrados. - CVAD puede ser licenciado por CCU. - La licencia CCU está disponible. Consulte este blog para obtener más información.

Cloud Connectors, Delivery Controllers y Ubicaciones de Recursos

Dado que tanto los modelos de campo ecológico como los híbridos utilizan servicios en la nube (DaaS) para la intermediación y la administración de sesiones, debe implementar Cloud Connectors para crear una ubicación de recursos en cada región en la que planea alojar los VDA. Al crear una ubicación de recursos en una región, se crea una configuración de alta disponibilidad mediante la implementación de instancias n+1 de Cloud Connector y la distribución de Cloud Connectors entre las zonas de disponibilidad de esa región. Los Cloud Connectors normalmente se colocan en subredes privadas separadas de los VDA para simplificar la aplicación de directivas de seguridad, y las instancias de Cloud Connector deben tener acceso a Internet saliente para facilitar la conexión a Citrix Cloud. Colocarlos en una subred independiente de los agentes VDA permite a los administradores aplicar directivas de redirección diferentes a los dos tipos de recursos diferentes.

Diagrama 13: patrón de diseño de ubicación de recursos de Citrix DaaS con subredes separadas para los VDA y Cloud Connectors Diagrama 13: patrón de diseño de la ubicación de recursos de Citrix DaaS con subredes separadas para los VDA y los Cloud Connectors.

Los mismos conceptos generales se aplican cuando hablamos de Delivery Controllers (CVAD), aunque usamos el término zona frente a ubicación de recursos en el subsistema de intermediación gestionada por el cliente. También tenga en cuenta que las instancias de Cloud Connector en EC2 son excelentes candidatos para precios reservados, ya que se ejecutan en cualquier momento en el que el sistema necesita estar activo. Consulte este artículo para obtener más información sobre el tamaño de las instancias de Cloud Connector.

Consideraciones sobre el diseño de sitios de Citrix DaaS

Ubicaciones y zonas de recursos

El uso de zonas de Citrix (que no debe confundirse con las zonas de disponibilidad) puede ayudar a los usuarios de regiones remotas a conectarse a los recursos sin forzar necesariamente a sus conexiones a atravesar grandes segmentos de la WAN. En un entorno Citrix DaaS, cada ubicación de recursos se considera una zona. Cuando se crea una ubicación de recursos y se instala un Cloud Connector, se crea automáticamente una zona para usted. Cada zona puede contener un conjunto de recursos diferente, en función del entorno y las necesidades que usted tenga. Para obtener más información sobre las zonas, consulte el siguiente enlace.

Catálogos de máquinas, grupos de entrega y ubicaciones de recursos

Los administradores de Citrix deben asegurarse de que los VDA también se distribuyen entre las zonas de disponibilidad (AZ). Una zona de disponibilidad de AWS (AZ) es uno o varios centros de datos discretos con alimentación, redes y conectividad redundantes en una región de AWS, una ubicación física en todo el mundo donde los centros de datos de clúster de AWS. Una nube privada virtual (VPC) es una red virtual que abarca las zonas de disponibilidad de la región. Las subredes son un subcomponente necesario de una VPC y las interfaces de red virtuales están conectadas a una sola subred. Cada subred debe residir completamente dentro de una zona de disponibilidad y no puede abarcarse zonas. Al iniciar los VDA en zonas de disponibilidad independientes, puede proteger sus aplicaciones de los fallos de una sola ubicación. Consulte ¿Qué es una Amazon VPC? para obtener más información. Para asegurarse de que los VDA están distribuidos entre AZs, puede crear un catálogo de máquinas por zona de disponibilidad (mediante una conexión de host por zona de disponibilidad) que luego se puede asignar a un único grupo de entrega.

Aprovisionamiento en AWS: Machine Creation Services

A partir del lanzamiento de CVAD 1811, se puede utilizar la autenticación basada en roles al crear una conexión de host para el aprovisionamiento de MCS en AWS. Una función de IAM o una cuenta de usuario de IAM asociada a un Delivery Controller o Cloud Connector en una instancia de EC2 se puede utilizar en lugar de la clave secreta y la clave de API de un usuario, lo que permite una mayor seguridad, derechos administrativos delegados y entornos basados en PKI con credenciales temporales y tokens de sesión. Para configurar una conexión de host mediante la autenticación basada en roles, primero cree un rol de IAM con los permisos descritos en CTX140429. Asocie esta función a una instancia de EC2 con un Delivery Controller CVAD 1811+ o un Cloud Connector. En versiones de CVAD anteriores a 1811, los administradores deben proporcionar la clave de API (clave de acceso) y la clave secreta de un usuario de IAM para crear una conexión de host.

Después de crear la conexión de host, cree un catálogo de máquinas como se describe aquí mediante una AMI creada a partir de la imagen maestra de VDA en AWS. Para obtener más información sobre MCS en AWS, consulte los siguientes artículos: Citrix MCS on AWS Deep Dive 1 y How MCS works after pooled VM are created in AWS.

Otro elemento que debe tenerse en cuenta al implementar VDA en AWS mediante MCS es la inicialización del volumen de EBS (también conocida como precalentamiento o hidratación). Para los volúmenes que se restauraron a partir de instantáneas, los bloques de almacenamiento deben retirarse de Amazon S3 y escribirlos en el volumen antes de poder acceder a ellos. Esta acción preliminar lleva tiempo y puede provocar un aumento significativo en la latencia de las operaciones de E/S la primera vez que se accede a cada bloque. El rendimiento del volumen se logra después de que todos los bloques se hayan descargado y escrito en el volumen. Consulte Inicialización de volúmenes de Amazon EBS en Windows para pasos recomendados de AWS para inicializar volúmenes de Amazon EBS en instancias de Windows y consulte Inicialización de volúmenes de Amazon EBS en instancias de Linux para Linux.

Consulte Consideraciones sobre la capa de infraestructura (o plataforma) para obtener más información sobre el diseño de VPC en relación con MCS.

Solución de problemas de Servicios de creación de máquinas

En esta sección se enumeran algunos problemas comunes y enlaces de recomendaciones/resolución asociados.

Consideraciones sobre la capa de infraestructura (o plataforma)

En Citrix Architectural Design Framework, la capa Infraestructura (o Plataforma) define los elementos físicos donde se ejecutan las cargas de trabajo de Citrix. En este documento, eso se refiere, por supuesto, a AWS. AWS ofrece muchos servicios en la nube (165+) y es a la vez el más antiguo y más grande de los proveedores de nube de hiperescala existentes en la actualidad. También fue la primera nube pública admitida por la tecnología de virtualización Citrix, y es una opción convincente para clientes nuevos o existentes de Citrix que quieren mover cargas de trabajo de virtualización de Citrix existentes o ejecutar nuevas en “la nube”.

Infraestructura como código y modelo de objetos de AWS

Para comprender cómo se integran y ejecutan las tecnologías de virtualización de Citrix en AWS, es útil comenzar con una comprensión básica del modelo de objetos detrás de algunos de sus servicios clave o relevantes. Esto también nos permite describir la plataforma de AWS en términos que son familiares para la mayoría de los profesionales de TI. Para facilitar esta comprensión, consultamos el siguiente diagrama que representa el patrón de diseño de una ubicación de recursos de DaaS en AWS:

Diagrama 14: Patrón de arquitectura/diseño de “ubicación de recursos” implementado para Citrix DaaS y AWS Diagrama 14: Patrón de arquitectura/diseño de “ubicación de recursos” implementadopara Citrix DaaS en AWS.

Este patrón de diseño es la base de la mayoría de las arquitecturas de sistemas de virtualización de Citrix en AWS. Tampoco es solo un patrón masivo, sino que se basa en varios patrones de diseño diferentes, bien mantenidos y documentados para TI empresarial en AWS. Estos patrones se representan, documentan y reproducen mediante plantillas de AWS CloudFormation. AWS proporciona una biblioteca de plantillas de inicio rápido que se pueden ejecutar tal cual, en capas (“anidadas”) con otras plantillas e incluso duplicar y personalizar para sus propias necesidades específicas. Esto pone de relieve algunas de las otras ventajas importantes de la infraestructura de nube pública: la infraestructura como código y la naturaleza de “pagar por uso” de muchos servicios en la nube. En breve profundizamos más en la infraestructura como código en el mundo de la virtualización de Citrix, pero enfatizamos el punto con un punto de contacto rápido que probablemente resuene para los lectores esperados de este documento: para muchos arquitectos de TI empresariales, tener acceso a una amplia biblioteca de servicios, patrones de diseño y herramientas tecnológicas al ámbito de su mano es impresionante. ¿Combinado con la capacidad de pagar por los recursos a medida que los consume y simplemente eliminarlos cuando haya terminado? Esta es una forma poderosa de aprender o evaluar cosas nuevas, y hace que el ROI de las inversiones a escala sea mucho más fácil de entender y comunicar.

Volvamos al modelo de objetos de AWS por un momento: el objeto de nivel superior del diagrama 14 es la región de AWS. Puede pensar en las regiones de AWS como clústeres de centros de datos bien conectados pero separados estratégicamente denominados zonas de disponibilidad. Cada región suele incluir 2 o más zonas de disponibilidad, que constan de uno o más edificios físicos con alimentación, red y conectividad redundantes. En el momento de redactar este informe, AWS tiene 23 regiones en todo el mundo, que constan de 69 zonas de disponibilidad, pero es importante tener en cuenta que invierten constantemente en nuevas regiones y zonas de acceso. Estos números, aunque asombrosos para la mayoría de EE. UU., probablemente ya están obsoletos para el momento en que lees esto. Esto pone de relieve una de las otras ventajas de pasar a la infraestructura de nube pública en AWS: usted continúa beneficiándose de las inversiones que están realizando (a una escala mucho más allá del ámbito de la mayoría de las organizaciones de TI o incluso de los gobiernos) a lo largo del tiempo. Esta continua evolución/mejora, aunque desalentadora para las organizaciones de TI y las culturas empresariales aversión al cambio, proporciona un amplio conjunto de beneficios de empoderamiento para TI empresarial a medida que se adapta a este “nuevo” modelo.

Las opciones de adopción de la región de AWS a menudo se basan en la proximidad, los servicios disponibles, el coste, el cumplimiento normativo o el SLA. Si bien elegir una o más regiones adecuadas para su sistema de virtualización Citrix está fuera del ámbito de este documento, tenga en cuenta al menos lo siguiente al tomar sus decisiones:

  • Si tiene uno o varios centros de datos gestionados por el cliente que está conectando a AWS, considere una o varias regiones que proporcionan la conectividad de red de latencia más baja a sus centros de datos y oficinas principales.
  • Todas las regiones no pueden tener los servicios o tipos de instancia de AWS que está buscando. AWS implementa nuevos servicios o tipos de instancia inicialmente en algunas regiones principales y, a continuación, se expande al resto con el tiempo. Además, las regiones más nuevas no pueden tener tipos de instancia más antiguos: haga su investigación antes de compilar siempre que sea posible.
  • Los sitios CVAD y las ubicaciones de recursos de DaaS están vinculados a una región específica. La alta disponibilidad para componentes individuales de una ubicación de sitio/recurso (como conectores en la nube, servidores StoreFront e instancias VPX de ADC/Gateway) se logra colocando recursos en varias zonas de disponibilidad de una región determinada.
  • No se exceda por la borda distribuyendo su infraestructura entre regiones: si bien es fácil hacerlo en AWS, tenga en cuenta el coste y la complejidad en relación con la recompensa que espera antes de escalar cualquier sistema. Usted termina pagando por el tráfico de red y el tráfico de almacenamiento también a veces. Los costes pueden ser triviales para el tráfico mientras es local en una región, pero aumenta cuando el tráfico atraviesa regiones o Internet.

Al intensificar una capa en el Diagrama 14 ahora, veamos algunas de las construcciones de red en este patrón de diseño. La construcción de red principal en AWS es la VPC o “Virtual Private Cloud”. Las VPC son una construcción regional (abarcan AZs): usted tiene al menos una VPC en cada región en la que implemente la tecnología de virtualización de Citrix. Las VPC tienen un bloque CIDR de direcciones IP definido, que debe ser único si el diseño de red redirige el tráfico entre varias VPC. Las VPC se dividen en subredes, y las subredes están vinculadas a una zona de disponibilidad (es decir, no abarcan AZs en una región).

Las subredes también tienen diferentes atributos y objetos asociados a ellas, incluidas las directivas de redirección y las directivas de seguridad. Esta es la razón por la que los patrones de diseño resaltados en este documento (y otra documentación de Citrix) recomiendan colocar los VDA en subredes separadas de Cloud Connectors, para que pueda asignar diferentes directivas de redirección y seguridad a los VDA y Cloud Connectors.

El acceso saliente a Internet desde cualquier subred de una VPC (una construcción regional) se puede gestionar de muchas maneras diferentes, pero un método común es usar puertas de enlace NAT para proporcionar conectividad de Internet a subredes privadas. Las subredes públicas a menudo reciben servicio de puertas de enlace de Internet, que facilitan la redirección de las conexiones entrantes a los servicios que usted hace accesibles desde Internet.

Las subredes también se etiquetan comúnmente como “públicas” y “privadas”. Una subred pública es una subred con direcciones IP redirigibles por Internet asignadas (además de las direcciones IP privadas) y está asociada a una tabla de rutas que tiene una ruta a una puerta de enlace de Internet (IGW) para el tráfico de Internet entrante y saliente. Una subred privada es una subred con solo direcciones IP privadas asignadas y está asociada a una tabla de rutas que tiene una ruta para el acceso a Internet saliente a través de una puerta de enlace NAT o instancias NAT que residen en una subred pública. En un sistema de virtualización Citrix, el servidor virtual Gateway (VIP) normalmente reside en una subred pública, ya que acepta conexiones entrantes desde dispositivos cliente a través de Internet y se utiliza para proxy de forma segura el tráfico de virtualización de Citrix en subredes privadas de una VPC.

Existen muchas formas de crear redes en AWS, con muchas funciones y técnicas innovadoras disponibles que no puede obtener en ningún otro lugar. No vamos a presentarlos todos aquí, pero dos herramientas/técnicas que vale la pena analizar son el emparejamiento de VPC y las puertas de enlace de tránsito. Estas dos construcciones ayudan a introducir la redirección del tráfico entre VPC de manera simple (emparejamiento de VPC) o en un modelo más compatible con la nube híbrida y preparado para la empresa (puertas de enlace de tránsito).

Hay mucho más en lo que podemos encontrar aquí, y para los curiosos y motivados, hay una montaña de conocimiento de dominio público disponible a su ámbito para aprender más. Por ahora, vamos a traer esto de nuevo para diseñar patrones debajo de todos los diagramas que ha visto en este documento.

Uno de los atributos atractivos de la plataforma de AWS es que se ha creado en API de consumo público. ¿Por qué es esto convincente? Por un lado, esto significa que gran parte de cualquier tipo de componente de infraestructura que pueda ejecutar en AWS se puede crear de forma reproducible a partir de código. Cuando se combina con un servicio de implementación potente e integral, como AWS CloudFormation, los clientes cuentan con un marco potente para aprender, personalizar, implementar y administrar los sistemas de TI. El concepto de infraestructura como código puede ser nuevo o desconcertante para muchos tecnólogos tradicionales centrados en la empresa, pero puede ser transformador una vez adoptado y practicado.

Como mencionamos anteriormente, AWS proporciona una biblioteca de plantillas de inicio rápido basadas en CloudFormation que se pueden ejecutar tal cual, en capas (“anidadas”) con otras plantillas e incluso duplicarse y personalizarse para sus propias necesidades específicas. AWS gestiona y mantiene esta biblioteca de plantillas, en cooperación con socios tecnológicos como Citrix, y estas plantillas suelen ser de código abierto (lo que significa que pueden duplicarse y modificarse según sea necesario). En el momento de redactar este documento, las siguientes plantillas de inicio rápido están disponibles para las tecnologías Citrix en AWS:

  • Citrix ADC para aplicaciones web: Implementa instancias de Citrix ADC VPX de alta disponibilidad en AWS. Si bien el enfoque de los casos de uso difiere ligeramente, este patrón de diseño también es funcional y relevante para las implementaciones de Citrix Gateway con CVAD/DaaS.

Resumen: Descripción de los patrones de diseño para Citrix en AWS

¿Confundido ya? Si es así, no se alarme: este puede ser el comienzo de su viaje a la nube pública de Citrix on AWS, y simplemente hemos desfilado la superficie de muchos temas profundos aquí. Con suerte, sin embargo, hemos ilustrado con éxito los siguientes puntos destacados:

  • Infrastructure as Code es un concepto poderoso que puede revolucionar la forma en que se diseñan, construyen y mantienen sistemas completos.
  • Al implementar sistemas en la nube pública de AWS, los diferentes componentes de una solución determinada pueden representarse mediante código y crearse bajo demanda mediante AWS CloudFormation y otras tecnologías.
  • Estos componentes se representan mediante plantillas de pila cuando se utiliza AWS CloudFormation, y las plantillas se pueden copiar y modificar, según sea necesario, para lograr los resultados deseados.
  • Las plantillas se pueden anidar y crear sistemas completos (como una ubicación de recursos de DaaS completamente funcional en AWS) a partir de los patrones de diseño individuales (plantillas).
  • La plantilla Quick Start de Citrix DaaS en AWS se basa en tres plantillas básicas administradas y mantenidas por AWS, que están bien documentadas. Comience con los siguientes enlaces para obtener más información sobre cada uno de ellos:
  • Mediante el uso de plantillas y la realización de compilaciones de prueba, un tecnólogo empresarial puede aprender, evaluar y diseñar sistemas que satisfagan las necesidades específicas de su organización o cliente.

Capa de infraestructura de AWS: recursos adicionales

Los siguientes recursos se pueden utilizar para obtener más información sobre la virtualización de Citrix sobre los requisitos y prácticas líderes de AWS:

Consideraciones de capa de operaciones

En esta sección se definen las actividades operativas que los administradores realizan periódicamente. Muchos de ellos no son específicos de AWS y se detallan en la documentación publicada existente. En las tablas siguientes, hemos resumido algunas de las tareas más importantes o específicas de AWS. Los lectores pueden consultar el tema Supervisar en la documentación del producto Citrix para obtener más información.

Tareas bajo demanda

En la tabla siguiente se describen las tareas que se espera realizar bajo demanda en función de los requisitos de la aplicación y los esfuerzos de solución de problemas.

Componente Tarea Descripción
Genérico Actualizar la base de conocimientos Cuando Citrix Team soluciona problemas relacionados con el entorno, debe identificar soluciones a los problemas. Debe crearse KBA para cada problema para ayudar a las futuras actividades de solución de problemas.
Citrix DaaS Modificar imagen Las imágenes deben actualizarse según sea necesario para admitir solicitudes. Es probable que las actualizaciones sean mensuales, pero es posible que se requieran actualizaciones más frecuentes para las pruebas.
Citrix DaaS Publicar imagen Cuando se modifican las imágenes, se prueban y publican.
AWS Verificar el inicio de la instancia Cuando se inicie una nueva instancia a través de MCS, compruebe que la instancia se ha creado en la consola de AWS y que haya IP disponibles en el grupo para la VPC dada. Las máquinas aprovisionadas por MCS no se crearán si no hay IP disponibles en el grupo de VPC.
AWS Verificar la eficacia de la imagen en las instalaciones Una instancia creada a partir de cualquier imagen local debe probarse para su capacidad de lanzamiento y viabilidad antes de ser usada para actualizar instancias de producción.
AWS Modificar permisos de usuario/grupo de IAM Según sea necesario, los permisos de usuario y grupo de IAM deben revisarse para reducir el número de usuarios con acceso administrativo e implementar la metodología de “privilegios mínimos”.
AWS Modificar grupos de seguridad Según sea necesario, los grupos de seguridad deben revisarse para otorgar o quitar acceso a diferentes protocolos de tráfico de varias IPs o intervalos de IP. Las reglas de entrada y salida deben modificarse para implementar bloqueos de tráfico de red.
AWS y Citrix DaaS Actualizar máquinas en un catálogo de máquinas Según sea necesario, actualice las imágenes de la máquina para incluir las modificaciones necesarias. Se debe crear una nueva AMI de la imagen modificada y usarla para actualizar el catálogo de máquinas. Consulte la sección Proceso de actualización y actualización de este documento para obtener más detalles.
AWS y Citrix DaaS Revertir actualizaciones a un catálogo de máquinas Según sea necesario, en el caso de que se deba revertir una imagen de máquina, se puede utilizar una AMI anterior con la última configuración de trabajo conocida para actualizar máquinas en el catálogo de máquinas.

Tareas periódicas diarias

En la siguiente tabla se describen las tareas que deben realizarse diariamente.

Componente Tarea Descripción
Genérico Revisar Citrix Director, el Monitor de rendimiento de Windows, el registro de eventos y otras alertas del software de supervisión Deben comprobar si hay advertencias o alertas en Citrix Director, registros de eventos u otro software de supervisión. Deben investigar la causa raíz de la alerta, si la hay. Nota: Se puede configurar un equipo y un monitor para mostrar el panel de Citrix Director para crear una pantalla de aviso para el departamento de Citrix, de modo que el estado del entorno sea claramente visible. Las recomendaciones de supervisión para Citrix Virtual Apps and Desktops se incluyen en la sección Supervisión de la guía de mejores prácticas de Virtual Apps and Desktops.
Genérico Verificar las copias de seguridad completadas correctamente Verificar que todas las copias de seguridad programadas se hayan completado correctamente, Esto puede incluir, entre otros, datos de usuario (perfiles de usuario/carpetas de inicio), datos de aplicaciones, bases de datos de Citrix, configuración de Citrix StoreFront y archivos de licencia de Citrix.
Genérico Probar el acceso al entorno. Simular una conexión interna y externa para validar que los recursos de escritorio y aplicaciones estén disponibles antes de que la mayoría de los usuarios inicien sesión durante el día. Esta conexión se probará durante todo el día e incluso se puede automatizar.
Citrix Virtual Apps and Desktops Comprobar el estado encendido o apagado de las máquinas virtuales. Compruebe que el número adecuado de escritorios inactivos y servidores de aplicaciones están encendidos y registrados con Delivery Controllers para confirmar la disponibilidad de las cargas de trabajo de los usuarios.
AWS Realizar comprobaciones de estado de la instancia Compruebe la consola de AWS para verificar el estado de las instancias y el hardware subyacente. Todas las instancias deben pasar las dos comprobaciones de estado cuando se enciende.
Citrix Virtual Apps and Desktops Realizar copias de seguridad incrementales de bases de datos relacionadas con Citrix Realice copias de seguridad de datos incrementales de las siguientes bases de datos Citrix: Base de datos de sitio, base de datos de registro de configuración, base de datos de supervisión

Tareas periódicas semanales

En la tabla siguiente se describen las tareas que se van a realizar semanalmente.

Componente Tarea Descripción
Genérico Revisar las revisiones y revisiones más recientes Revisar, probar e implementar las revisiones hotfix Citrix más recientes y comprobar si los Delivery Controllers y las máquinas virtuales de servidor o escritorio las requieren. Para las actualizaciones de Microsoft implementadas a través de SCCM o WSUS en máquinas de AWS, todas las máquinas reciben estas actualizaciones cuando se enciende. Si se emplea Citrix Power Management, puede haber máquinas en el catálogo de máquinas que no estén activadas de forma regular. Al realizar actualizaciones de imágenes, es mejor utilizar una instancia maestra dinámica que esté encendida durante todos los ciclos de actualización. A continuación, se pueden crear AMI a partir de esta instancia e incluir todos los parches necesarios. Nota: Las revisiones necesarias deben probarse mediante el proceso de prueba recomendado antes de la implementación en Producción.
Genérico Crear un informe de estado del entorno Citrix. Cree un informe sobre el rendimiento general del entorno (estado del servidor, uso de recursos, experiencia del usuario) y el número de problemas de Citrix (tasa de cierre, problemas abiertos, etc.).
Genérico Revisar el informe del estado. Revise el informe de estado de Citrix para identificar tendencias o problemas comunes.
Genérico Mantener la base interna de conocimientos de asistencia. Cree scripts de KBA y resolución de problemas para abordar las solicitudes de soporte de nivel 1 y de nivel 2. Revise KBA y scripts de resolución de problemas para determinar la precisión, el cumplimiento y la viabilidad.
Citrix Virtual Apps and Desktops Comprobar informes de registro de configuración Confirme que los cambios en todo el sitio de Citrix implementados durante la semana anterior se aprobaron mediante el control de cambios.
Citrix Virtual Apps and Desktops Realizar copias de seguridad completas de bases de datos relacionadas con Citrix Realice copias de seguridad completas de datos de las siguientes bases de datos Citrix: Base de datos del sitio, base de datos de registro de configuración, base de datos de supervisión.
AWS Realizar instantáneas de todos los volúmenes de EBS Todos los volúmenes de Elastic Block Storage se van a realizar instantáneas de forma periódica. Las instantáneas se pueden administrar y arreglar en la consola de AWS EC2.

Tareas periódicas mensuales

En la tabla siguiente se describen las tareas que se deben realizar mensualmente.

Componente Tarea Descripción
Genérico Realizar una evaluación de la capacidad. Realice una evaluación del performance del entorno y la capacidad del entorno Citrix para determinar la utilización del entorno y cualquier requisito de escalabilidad. Revise los informes mensuales de las herramientas de supervisión para evaluar el rendimiento y la capacidad del entorno, incluyendo, entre otros: asignación de cómputos de servidor virtual (CPU y RAM), Licencias y ancho de banda de red. Adquirir software o licencias y crear servidores adicionales según sea necesario. Nota: Las recomendaciones para realizar una evaluación de la capacidad se incluyen en Decisión de diseño: Escalabilidad con un solo servidor.
Genérico Revisar acceso con privilegios elevados Revise qué usuarios y grupos tienen permisos elevados para el entorno y evalúe si se requiere acceso elevado continuo. Elimine todas las cuentas que ya no requieran estos derechos administrativos. Principalmente, solo los usuarios y roles de IAM que se van a utilizar para asignar privilegios elevados, con acceso restringido estrictamente a cuentas de usuario individual, local o raíz.

Tareas periódicas anuales

En la tabla siguiente se describen las tareas que se van a realizar anualmente.

Componente Tarea Descripción
Genérico Realizar una evaluación de las directivas de Citrix. Revise las directivas de Citrix y determine si son necesarias nuevas directivas y deben actualizarse las directivas existentes.
Genérico Revisar actualizaciones de software. Revisar y evaluar el requisito de nuevas versiones o actualizaciones del software de Citrix.
Genérico Realizar la prueba del Plan de Continuidad del Negocio (BCP)/Recuperación ante desastres (DR) Realizar una prueba funcional de BCP/DR para confirmar la disponibilidad de DR. Este plan consiste en incluir una prueba de restauración anual para validar el proceso de restauración real a partir de datos de copia de seguridad funciona correctamente.
Genérico Realizar una evaluación de aplicaciones. Revisar el uso de aplicaciones fuera y dentro del entorno Citrix. Evalúe la validez de agregar más aplicaciones al sitio Citrix, quitar aplicaciones que ya no son necesarias o actualizar las aplicaciones a la versión más reciente.
AWS Evaluar los accesos a grupos de seguridad de red A medida que se agregan o eliminan funciones o aplicaciones de los servidores de la infraestructura Citrix o de los servidores de aplicaciones, los grupos de seguridad de red asociados a esas instancias también deben evaluarse y modificarse si es necesario, para agregar o quitar puertos o protocolos.

Fuentes

El objetivo de esta arquitectura de referencia es ayudarle con la planificación de su propia implementación. Para facilitar este trabajo, nos gustaría proporcionarle diagramas fuente que puede adaptar en sus propios diseños detallados y guías de implementación: diagramas fuente.

Arquitectura de referencia: Citrix DaaS — AWS