Arquitectura de referencia para Citrix Virtual Apps and Desktops en 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 se pretende que sea una referencia “Cómo” - Citrix los consideraGuías de implementación, y ahora se entregan y mantienen por separado deArquitecturas 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 lossocios consultores seleccionados de Citrix。

Visión general y resumen ejecutivo

拉斯维加斯tecnologias de virtualizacion y de Citri红x 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 desean 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 camino 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: Serviciosgestionados por el clienteyservicios en la nube。A continuación,componentes de un sistema de virtualización Citrixdescomponemos el en múltiples subsistemas, y los categorizamos por 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	CitrixVirtual Apps and Desktops (CVAD)	Servicio Citrix Virtual Apps and Desktops (CVADS)
Servicios de interfaz de usuario (UI)	CitrixStoreFront	CitrixWorkspace (el servicio utilizado a través de la aplicación Citrix Workspace o el explorador web)
Autenticación	CitrixStoreFront (más Citrix ADC/Gateway para la mayoría de los casos de uso)	CitrixWorkspace (más Citrix ADC/Gateway para ciertos casos de uso)
Proxy de sesión HDX	CitrixADC/Gateway	CitrixGateway Service

Adoptamos porlos servicios en la nube, recomendando que lamayoría de las organizaciones utilicen o planean usar servicios en la nubecuando 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 queno 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 escenarios 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(no debe confundirse con una “nube híbrida”): el modelo de implementación más común, el modelo híbrido utiliza CVADS para intermediación y administración de sesiones, con opciones de servicio gestionado por el cliente y servicio 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 documentadoCitrixArchitectural Design Frameworkpara 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 elmodelo de implementación híbridadesde el primer día, mediante el servicio CVAD para laintermediacion y administracion de对话。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 utilizando 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:

• Prácticas líderes para Citrix Cloud en AWS - Parte 1
• Prácticas líderes para Citrix Cloud en AWS - Parte 2
• Prácticas líderes para Citrix Cloud en AWS - Parte 3

Conceptos clave y escenarios de implementación

En esta sección, describimos algunos conceptos clave y escenarios de implementación antes de sumergirnos en consideraciones específicas para cada capa deCitrixArchitectural Design Framework。

Modelos de adopción de tecnología

La tecnología Citrix Virtual Apps and Desktops se puede “consumir” o implementar de muchas maneras diferentes. Los métodos más comunes se pueden describir generalmente como serviciosgestionados por el clientey en lanube。También vale la pena mencionar un tercer modelo:合作伙伴管理。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 elmayor 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 utilizacomú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 100% gestionada por el cliente, Lift/Shift mediante AWS como IaaS solamente.

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”。

Citrixofrece 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

Administrado por socios

Aunque很多organizaciones eligen crear 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.	CVADS - Servicio Citrix Virtual Apps and Desktops, entregado a través de Citrix Cloud. Si inicia sesión en Citrix Cloud e instala y registra conectores Cloud en su entorno, está utilizando 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.	CitrixStorefront。También instalado/configurado desde binarios CVAD LTSR o CR, esta función proporciona una flexibilidad extrema para los escenarios 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 clientes (CVAD) como de entornos administrados/intermediados de Citrix Cloud (CVADS).	CitrixWorkspace(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 clientes (CVAD) como de entornos administrados/intermediados de Citrix Cloud (CVADS).
Autenticación:在埃斯特contexto, nos referimos科莫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.	CitrixStoreFront(másCitrixADC/Gatewaypara 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.	CitrixWorkspace(másCitrixADC/Gatewaypara 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 escenarios 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 sin problemas usuarios/dispositivos fuera de la red corporativa privada a aplicaciones y escritorios proporcionados por CVAD/CVADS en el interior.	AppliancesCitrixADC/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.	CitrixGateway Service: Proporcionado por Citrix Cloud, este servicio proxia 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 con las opciones de intermediación de sesiones administradas por el cliente y administradas por Citrix Cloud (CVAD y CVADS).

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 utilizarservicios en la nube真爱永远,海洋可能。帕拉卡索uso de entor阿nos 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 escenarios de implementación/patrones de migración comunes. En esta sección, exploramos estos patrones o escenarios, 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 escenarios de migración comunes.

Los tres escenarios 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íbridao 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 escenarios de autenticación, o ambos.
• Levantar y cambiar。反对埃斯特卡索,洛杉矶客户基本camente 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 escenarios con más detalle, incluidas las vistas generales arquitectónicas de cómo se diseña comúnmente cada caso. Usted encuentra que laprá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 Virtual Apps and Desktops Service. 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 inicioServicio Citrix Virtual Apps and Desktops en AWSrápido, que le ayuda a crear un sistema completo de virtualización de Citrix 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: detalle de la arquitectura del sistema implementada mediante la plantilla CVADS en AWS QuickStart y los parámetros predeterminados. No se muestran los servicios de Citrix Cloud.

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

Vale la pena señalar que este modelo de implementación (en realidad, los tres modelos de implementación) utilizaZonas de disponibilidad de AWSpara proporcionar un diseño de alta disponibilidad. ConsulteZonas de disponibilidadmá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 de elevación y desplazamiento, 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, elmodelo de implementación de campo verdeutiliza 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	Servicio Citrix Virtual Apps and Desktops (“CVADS”, 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 de archivos sistema	AWS Directory Service para Microsoft Active DirectoryyFSx de Amazon para Windows File Server(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íbri

Con el modelo de implementación híbrida, los clientes pueden optar por instalar/configurar/administrar algunos deComponentes del sistema de virtualización Citrixellos mismos, pero no elsubsistema de intermediación y administración de sesiones。En un modelo de implementación híbrido, este subsistema se proporciona como un servicio en la nube denominado “Citrix Virtual Apps and Desktops Service” (CVADS para abreviar) y se entrega como una suscripción desde 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:洛杉矶监狱服务公司icios 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: de virtualizacion de Los servicios Citrix管理nados 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.
• Autoescalado: El servicio de intermediación administrada (CVADS) de Citrix incluyeFunción de escala automática de Citrix, que proporciona capacidad de VDA incorporada 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 de Citrix Cloud (CVADS). NO está disponible para la infraestructura de intermediación gestionada por el cliente (versiones CVAD LTSR o CR).-Ahorros en la gestión:洛杉矶监狱服务公司icios en la nube, Citrix asume la responsabilidad de mantener los servicios altamente disponibles, rendimientos, 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 mas一些必要,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 CVADS como base de este modelo de implementación, los clientes pueden combinar y combinar componentes de servicio en la nube o gestionados 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, elmodelo de implementación híbridautiliza lo siguiente:

Componente del sistema de virtualización de Citrix	Proporcione:
Intermediación y administración de sesiones	Servicio Citrix Virtual Apps and Desktops (“CVADS”, a través de Citrix Cloud)
Servicios de UI	Servicio Citrix Workspace (a través de Citrix Cloud)OCitrixStoreFront en Amazon EC2 (gestionado por el cliente)
Autenticación	Servicio Citrix Workspace (a través de Citrix Cloud)OCitrixStoreFront en EC2 (Citrix ADC/Gateway opcional pero común)
Proxy de sesión HDX	CitrixGateway Service (a través de Citrix Cloud)OCitrixADC/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 de archivos sistema	AWS Directory Service para Microsoft Active DirectoryyFSx de Amazon para Windows File Server(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 plantillaServicio Citrix Virtual Apps and Desktops en AWSQuickStart y tiene un aspecto similar al siguiente diagrama arquitectónico:

Diagrama 5: Arquitectura conceptual, CVADS: modelo de implementación híbrido en AWS.

Vale la pena señalar que este modelo de implementación también utilizaZonas de disponibilidad de AWSpara proporcionar un diseño de alta disponibilidad. ConsulteZonas de disponibilidadmá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 CVADS en AWS) se puede combinar con un modelo de nube híbrida, conectando centros de datos/recursos gestionados por el cliente a AWS mediante AWS Direct Connect, AWS VPN, Citrix SD-WAN 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, CVADS: Implementación híbrida/Modelo de nube híbrida.

Elevación y cambio

Refiriéndose a nuestra definición deComponentes del sistema de virtualización Citrix, cuando hablamos de un caso de implementación de elevación y desplazamiento, el componente clave es el subsistema deintermediacion y administracion de对话y la infraestructura asociada. Si está utilizando unainfraestructura de intermediación autoadministrada(está implementando Delivery Controllers en lugar de Cloud Connectors), a los efectos de este documentoestá levantando y cambiando.

Levantar y Shift - por qué

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. PorCTX270373lo tanto, el uso de nubes públicas, incluida AWS, solo se admite con versiones de productos LTSR. Para los clientes que eligen el modelo de implementación de elevación y cambio (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 elevación y cambio 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, elmodelo de implementación de elevación y desplazamientoutiliza lo siguiente:

Componente del sistema de virtualización de Citrix	Proporcione:
Intermediación y administración de sesiones	CitrixVirtual Apps and Desktops (gestionado por el cliente mediante LTSR o CR descargable) en Amazon EC2
Servicios de UI	CitrixStoreFront en Amazon EC2 (gestionado por el cliente)
Autenticación	CitrixStoreFront en EC2 (Citrix ADC/Gateway opcional pero común)
Proxy de sesión HDX	CitrixADC/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 de archivos sistema	Instancias de Windows Server administradas por el cliente en EC2;AWS Directory Service para Microsoft Active DirectoryyFSx de Amazon para Windows File Server(opcional)

En su forma más sencilla, la implementación 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 de elevación y desplazamiento en AWSDiagrama 1: Conceptual Architecture, CVAD: Lift and Shift Deployment Model en AWS.

Vale la pena señalar que este modelo de implementación también utilizaZonas de disponibilidad de AWSpara proporcionar un diseño de alta disponibilidad. ConsulteZonas de disponibilidadmás adelante en este documento para obtener más contexto.

一个杂烩汤,联合国de implementacion de elevacion莫德罗y cambio se combina con un modelo de infraestructura de nube híbrida, mediante AWS Direct Connect, AWS VPN, Citrix SD-WAN o tecnología de red similar para conectar un centro de datos gestionado por el cliente y recursos 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 opciones disponibles:Diagrama 8: Arquitectura conceptual, CVAD: modelo de implementación de elevación y cambio con modelo de infraestructura de nube híbrida y servicios en la nube gestionados por AWSDiagrama 8: Conceptual Architecture, CVAD: Lift and Shift Deployment Model with Hybrid Cloud modelo de infraestructura y servicios en la nube gestionados por AWS.

Levantar y Shift - ¿por qué no

A estas alturas ya se ha dado cuenta de que la práctica/recomendación líder de Citrix es NO hacer un cambio y un cambio completo. Usted puede estar preguntándose por qué, o de dónde viene esto. Refiriéndose a nuestro desglose deComponentes del sistema de virtualización Citrix, el subsistema deintermediacion y administracion de对话es el componente mas critico, desea常人NO levantar y cambiar. 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: de virtualizacion de Los servicios Citrix管理nados 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 (CVADS) de Citrix incluyeFunción de escala automática de Citrix, que proporciona capacidad de VDA incorporada 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 (servicio Citrix Virtual Apps and Desktops); 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 gestión- Con los servicios en la nube, Citrix (y AWS en este caso) asume la responsabilidad de mantener los servicios de alta disponibilidad, rendimiento, 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 mas一些必要,funcionalidades y servicios:de prestacion de las现代化plataformas 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:

• CitrixXenApp y XenDesktop 7.6 en la arquitectura de referencia de AWS(blog)
• Arquitectura de referencia de Citrix XenApp y XenDesktop 7.6 en Amazon Web Services(guía)
• Uso de AWS y Amazon RDS con Citr目录服务ix Virtual Apps and Desktops(blog)
• Implementación de Citrix Virtual Apps and Desktop con AWS Directory Service y Amazon RDS, versión 1.0(guía de implementación)

Decisiones sobre el 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 su dispositivo.

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 escenarios comunes de implementación de Virtual Apps and Desktops. Estas capas se muestran en el siguiente diagrama conceptual:Diagrama 9: Arquitectura conceptual, servicio Citrix Virtual Apps and DesktopsDiagrama 9: Conceptual Architecture, Citrix Virtual Apps and Desktops Service.

• 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 endpoints 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.

Afortunadamente, estas consideraciones ya están bien documentadas y no difieren sustancialmente entre los sistemas implementados en AWS y cualquier otra plataforma de hardware o nube. Para obtener información detallada sobre las consideraciones de diseño de esta capa, consulte elManual de Citrix VDI y prácticas recomendadas para XenApp y XenDesktop 7.15 LTSRdocumento y laCapa de usuarios de la metodología de diseñopágina en particular, para obtener más detalles.

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 laComponentes del sistema de virtualización Citrixque hemos definido anteriormente, la capa de acceso contiene los siguientes componentes y opciones:

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

中国国际广播电台La手鼓siguiente "分的决定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 desea 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””.	SÍ: Tanto los entornos heredados (XenApp y XenDesktop 6.5/7.x, Citrix Virtual Apps and Desktops CR/LTSR) como el servicio Citrix Virtual Apps and Desktops.	SÍ: Tanto los entornos heredados (XenApp y XenDesktop 6.5/7.x, Citrix Virtual Apps and Desktops CR/LTSR) como el servicio Citrix Virtual Apps and Desktops. Consulteeste artículopara obtener más detalles.
Capacidad para crear múltiples ‘Almacenes’ con diferentes configuraciones para diferentes casos de uso, incluidos los requisitos de autenticación.	SÍ: 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, consulteCó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. ConsulteConfigurar y administrar almacenes帕拉obtener mas给。	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 SaaS y aplicaciones web mediante el servicio Citrix Secure Workspace Access, aprovechando el filtrado web y las directivas de control de seguridad mejoradas, además de análisis avanzado mejorado en ML.	NO: Requiere el uso de Citrix Workspace.	SÍ: 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.	SÍ: 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ónAcceso a Citrix Remote PC。	SÍ: Independientemente de si la intermediación es manejada por CVAD o CVADS.	SÍ: Independientemente de si la intermediación es manejada por CVAD o CVADS.
Capacidad para guiar el trabajo de los usuarios y automatizar tareas repetitivas mediante el uso de microaplicaciones integradas con diferentes SaaS y aplicaciones personalizadas.	NO: La función de microaplicaciones no está disponible actualmente con Citrix StoreFront.	SÍ: Presenta a los usuarios un ‘feed’ en la interfaz de usuario del espacio de trabajo que muestra de forma inteligente notificaciones, tareas y flujos de trabajo definidos por microaplicaciones personalizadas y de la consola del generador de Microapp de bajo código. ConsulteFunciones de Workspace Intelligence: MicroaplicacionesyMicroaplicacionesen Citrix Docs para obtener más información.
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.	SÍ: 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. ConsulteDocumentación de CVAD Zonas。	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. Para obtener más detalles, consulteDocumentación de CVADS Zonas。
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.	SÍ: Utiliza la función Caché de host local tanto en Cloud Connectors como en Delivery Controllers para proporcionar resiliencia para estos dos posibles escenarios de falla.Para entornos con requerimientos de resiliencia extensos, Citrix recomienda implementar StoreFront con caché de host local.Para obtener más información, consulteCaché de host local (CVAD)。	SÍ: 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 escenarios de conmutación por error. Para obtener más información, consulteCaché de host local (CVADS)。
Capacidad para configurar y utilizar una ‘URL de vanidad’ personalizada para el consumo del usuario final.	SÍ- 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 sí puedenconfigurar su propio prefijo personalizado(nombrecliente.cloud.com).
Capacidad para enrutar 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.	SÍ: 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, consulteVista previa del servicio de ubicación de red。
Capacidad de utilizar Citrix网关服务对位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.	SÍ: 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.	SÍ: Citrix ADC incluye la funcionalidad TOTP integrada para su uso con autenticadores de terceros y también admite aplicaciones, dispositivos/servicios de terceros.	SÍ: 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.	SÍ: SSO a aplicaciones web, SaaS y virtualizadas disponibles de forma nativa con Citrix Workspace. El servicio de puerta de enlace y el Secure Workspace Access incluyen filtrado 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.	SÍ- 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. ConsulteConfigurar el servicio de autenticación帕拉obtener mas给。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.	SÍ: 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. ConsulteEspacios de trabajo seguros帕拉obtener mas给。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, consulteConectar 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Í: CitrixServicio de autenticación federada(FAS) habilita el SSO a los VDA cuando se utiliza un proveedor de identidades federado como SAML (Security Assertion Markup Language).	Próximamente: Mediante el uso de CitrixServicio de autenticación federada(FAS) con Citrix Workspace. Esta función se encuentra en vista previa a partir de esta escritura. ConsulteHabilitar el SSO para espacios de trabajo con Citrix FAS帕拉obtener mas给。

Consideraciones del proxy de sesión HDX

Tenga en cuenta lo siguiente al elegir cómo desea 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 (CitrixGateway Serviceproporcionado 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Í:CitrixGateway Servicees una solución completa de proxy HDX, administrada por Citrix, que se entrega como un servicio en la nube.
Posibilidad de utilizar el protocolo内在basado en EDT (UDP) de Citrix HDX. Para obtener más información, consulteTransporte adaptableyCómo Configurar el Protocolo de HDX Enlightened Data Transport。	SÍ: 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.	SÍ: 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 entornos de intermediación Citrix CVAD y CVADS, el servicio Gateway proporciona acceso sencillo y seguro a las aplicaciones virtualizadas que se ejecutan en entornos AWS o en entornos locales del cliente.
Soporte para Equilibrio de Carga de Servidor Global (GSLB) configurable por el cliente entre centros de datos, zonas y regiones.	SÍ: 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 ello: el servicio Gateway utiliza14 o más POP en todo el mundo más GSLB integradopara garantizar que los usuarios obtengan el mejor rendimiento posible de la sesión, independientemente de dónde en el mundo 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.	SÍ: 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 tickets 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.	SÍ: 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. Consulteeste artículopara obtener más detalles.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.	SÍ: Se admiten implementaciones de ADC/Gateway/StoreFront basadas en AWS EC2 y tanto en las instalaciones como en AWS EC2.	SÍ: Citrix Workspace está disponible en Citrix Cloud Government.
Capacidad para admitir nubes y entornos de AWS aislados sin conectividad a Internet saliente.	SÍ: 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 administradas por el cliente frente a las de servicios en la nube para los subsistemas de capa de acceso, examinemos las decisiones de nivel superior en el contexto de lasmodelos de implementaciónque 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.

拉卡帕de acceso de una implementacion de Citrixes 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 desea 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 camino 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 puerta de enlace e identidad locales pueden beneficiarse de la capacidad de usoCitrixGateway como proveedor de identidades 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 desea 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 cuentaSecuencia de lanzamiento de Citrix Virtual Apps and Desktopsal diseñar la implementación híbrida, teniendo en cuenta especialmente que todo el tráfico se enruta a través del 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 camino, en lugar de los métodos de elevación y desplazamiento.

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 de elevación y desplazamiento

Con el modelo de implementación de elevación y cambio 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 de elevación y turnos, 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. El levantamiento y el cambio 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.

CitrixADC/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:

• CitrixADC VPX en AWS en Citrix Docs: proporciona una descripción general completa de Citrix ADC en AWS, incluidos modelos VPX compatibles, regiones de AWS, tipos de instancias EC2 y referencias de recursos adicionales.
• Diseño de referencia validado de Citrix ADC y Amazon Web Servicesen Citrix Docs/Advanced Concepts - incluye más detalles y guía de implementación.
• Plantilla de inicio rápido de CloudFormation de Citrix ADC para aplicaciones web: funcional y relevante para las implementaciones de Citrix Gateway con CVAD/CVADS también, aunque Citrix y AWS están trabajando en un inicio rápido adicional para este caso de uso específico.
• Read.Mede Citrix ADC en la plantilla de AWS QuickStart CloudFormation, una excelente referencia para los productos Citrix Networking disponibles en AWS Marketplace, y también proporciona ID de AMI para todas las regiones, tipos de instancia y modelos de firmware disponibles.

Si bien existen posibles variantes para una arquitectura Citrix ADC/Gateway VPX en AWS, el siguiente diagrama (deGuía de implementación de inicio rápido de Citrix ADC para aplicaciones web) muestra una implementación de par Citrix HA Multi-AZ tal como se implementó mediante la plantilla de inicio rápido (con subredas/bloques CIDR predeterminados):

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

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

• Standalone: 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.

• High Availability: Este es el modelo más comúnmente implementado para entornos de producción: los pares de instancias de Citrix ADC/Gateway VPX se pueden implementar mediante el modo nativo de Citrix HA en AWS. Con versiones de firmware anteriores, el par se implementa en la misma zona de disponibilidad de AWS.A partir de Citrix ADC 12.1, los pares de dispositivos VPX de alta disponibilidad se pueden implementar en las zonas de disponibilidad (AZ).Cómo funciona la alta disponibilidad en AWSexplica la diferencia entre implementar un par de ADC dentro de la misma zona de disponibilidad y entre AZs. 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 de Citrix ADC VPX para implementaciones de CVAD/CVADSDiagrama 11: Asignación de interfaz de instancia de Citrix ADC VPX para implementaciones de CVAD/CVADS.

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 en la nube de lo familiarInfraestructura pod, para permitir actualizaciones, parches y escalabilidad fáciles de administrar para la expansión. Para obtener información detallada sobre la configuración de GSLB entre las AZs de AWS, consulteDocumentación de Citrix。

Diagrama 12: Flujo de tráfico antes y después de la conmutación por error de HA en implementación de HA Multi-AZDiagrama 12: Flujo de tráfico antes y después de la conmutación por error de alta disponibilidad 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 unConfiguració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 un servidor virtual especial脂肪酸的Citrix ADC llamada IPSeto multi-IP, que se puede utilizar para clientes de diferentes subredes para conectarse al mismo conjunto de servidores. Con IPSet, puede asociar una IP privada a cada una de las instancias primaria y secundaria. A continuación, se puede asignar una IP pública al ADC principal en el par. En el caso de la conmutación por error, la asignación de IP pública cambia dinámicamente al nuevo primario. Para 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 HA basado en INCC, consultedocumentos de Citrixy veaeste videodesde el canal de YouTube de Citrix.

CitrixStoreFront 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 las consideracionesPlanificar una implementación de StoreFrontgenerales que se aplican a todas las implementaciones, incluido 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ñodependen de la latencia entre AZs。Por loPlanifique su implementación/escalabilidad de StoreFronttanto, las implementaciones de grupos de servidores StoreFront solo se admiten cuando los vínculos entre servidores de un grupo de servidores tienen una latencia inferior a 40 ms (con suscripciones inhabilitadas) o menos de 3 ms (con suscripciones habilitadas). Asegúrese de medir las latencias entre instancias en todas las AZs que planea hospedar StoreFront y habilitar/inhabilitar las suscripciones en consecuencia.

Ya lo mencionamos en laConsideraciones de autenticación y servicio de IUtabla anterior en este documento, pero vale la pena llamarlo de nuevo:para los entornos Citrix Virtual Apps and Desktops Service con requisitos de resiliencia extensos, Citrix recomienda encarecidamente una implementación de StoreFront para beneficiarse plenamente del host local Función de caché(disponible en los tipos de infraestructura de intermediación de sesiones CVAD y CVADS). Para CVAD, esto proporciona resiliencia si hay una interrupción de la base de datos. Para CVADS, esta arquitectura proporciona resiliencia 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é del host local, consulteCaché de host local (CVADS)yCaché 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 utilizarZonas Citrix, la redundancia de StoreFront se puede crear mediante la difusión de zonas satelitales a través de dos o más AZs en una VPC con un único 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 confiable y eficiente para satisfacer las necesidades de disponibilidad, RPO y RTO. Esto es especialmente cierto para entornos donde los usuarios pueden conectarse a escritorios/aplicaciones en 2 o más regiones, y 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 consideren esta opción deben revisar elDeclaración de soporte técnico de Microsoftuso de DFS-R y DFS-N para recursos compartidos de perfil itinerante y recursos compartidos de redirección de carpetas.

Un punto más a tener en cuenta ya que el sistema de virtualización Citrix se ejecutará en AWS: un nuevo evento de implementación o migración puede proporcionar 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 de Amazon para Windows File Serveres un servicio en la nube que los clientes pueden consumir 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, consulteAmazon 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 Windows, los clientes que consideran esta opción deberían revisar el usoDeclaración de soporte técnico de Microsoftde DFS-R y DFS-N para recursos compartidos de perfil itinerante 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 opciones es en elAWS 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 confiable y resistente.

Almacenamiento de给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

在联合国sistema de virtualizacion de Citrix 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). Un grupo de agentes VDA idénticos se aprovisionan y mantienen en “Catálogos de máquinas”, una construcción de administración definida y mantenida a través del subsistema de intermediación y administración de sesiones (tanto CVADS 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. Analizamos MCS en AWS con mucho más detalle en lasConsideraciones de capa de controlsecciones 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). ConsulteCTX234562帕拉obtener mas给。

Modelos de entrega y persistencia

Elegir洛杉矶莫德罗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:fre el莫德罗compartido alojado它反对市长cuencia 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 respaldadas 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莫德罗“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 respaldadas 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 respaldadas 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 respaldadas 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.帕拉读经台莫德罗VDI,一部分consideracion破碎nte 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 inicia 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 respaldadas 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。de所以de La combinacion servidor concurrenci监狱a 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 camino 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, se compara el siguiente árbol de decisionesEscritorios compartidos alojados (escritorios multiusuario de SO de servidor) a escritorios VDI。El árbol no distingue explícitamente entre los modelos VDI cliente y VDI de servidor. 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. Idealmente, el mayor número posible de VDA se pagarán por horas con el modelo de facturación bajo demanda y utilice laCitrixAutoscalefunción 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 CVADS), las máquinas virtuales se encienden según sea necesario con anticipación para 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á utilizando. 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 detalles sobre la selección de tipos de instancia y los precios, los lectores pueden consultar la secciónPresentación de estimación de costes de Citrix on AWS(en fuentes).

Para obtener más información acerca de la selección de instancias (especialmente en lo que se aplica al modelo de entrega compartido alojado) vayaCitrixScalability 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 aparecerán de forma predeterminada en el asistente de creación de catálogo de máquinas de Studio (ya sea CVAD o CVADS). La interfaz de usuario se rellena con tipos de instancia de un archivo XML estático que reside en Delivery Controllers (CVAD) o Cloud Connectors (CVADS). 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). ConsulteCTX139707para obtener más información sobre cómo actualizar la lista de tipos de instancias de AWS disponibles.

Para tener una mejor idea de cómo se dimensionan normalmente las instancias en AWS (o en cualquier otra plataforma), consulte estoblog detallado de AWS LogInVSI。Durante esta ronda de pruebas (una referencia de punto en el tiempo), el tipo de instancia M5.2Xlarge (8vCPU, 32 GB de RAM) resultó ser el ganador en términos de $/usuario/hora (con una carga de trabajo de muestra estándar de la industria). 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 deberían considerar la posibilidad de utilizar servicios tales como:CitrixAnalytics for PerformanceLa información que proporcionan estos servicios puede desempeñar un papel clave para mantener el rendimiento al alza y reducir los costes.

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 decisión de la Tech Zone vinculada compara las diferentesMétodos de entrega compartidos alojados, que incluyen las aplicaciones compartidas alojadas (de uso único y multiuso) y los 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 la compatibilidad con App Layering en AWS es fundamental para su migración o implementación, envíe un correo electrónicoaws@citrix.comcon 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, consultedocumentación de productoyArquitectura 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 de elevación y desplazamiento

Con el modelo de implementación de elevación y cambio 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 tienes que ir por el sendero de “levantar y cambiar”, 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:

• CitrixXenApp y XenDesktop 7.6 en la arquitectura de referencia de AWS(blog)
• Arquitectura de referencia de Citrix XenApp y XenDesktop 7.6 en Amazon Web Services(guía)
• Uso de AWS y Amazon RDS con Citr目录服务ix Virtual Apps and Desktops(blog)
• Implementación de Citrix Virtual Apps and Desktop con AWS Directory Service y Amazon RDS, versión 1.0(guía de implementación)
• Manual de Citrix VDI y prácticas recomendadas para XenApp y XenDesktop 7.15 LTSR(documento)

Consideraciones de Active Directory

身体de implementacion para sistema莫德罗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 ServerAWS Directory Service para Microsoft Active Directory, uso o una combinación de ambos. Las confianzas de Active Directory también se pueden utilizar para conectar dos o más bosques o dominios de AD dependiendo de las necesidades del cliente.

Para los clientes que buscan minimizar la sobrecarga administrativa necesaria para crear y mantener servicios funcionales de Active Directory, la opciónAWS Directory Service para Microsoft Active Directory(también conocida 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 escenarios.

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 PUEDES hacer:

• Cree objetos AD en cualquiera de los contenedores predeterminados (como /Computers): son de solo lectura. Esto da lugar a un error común que algunos clientes cometen al usar la tecnología de aprovisionamiento 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 para Microsoft Active Directoryes una oferta “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 a la hora de ofrecerlo como un servicio a escala, y aquí se enumeran las limitaciones más impactantes que se conozcan actualmente para un entorno Citrix.

Para obtener más información sobre los requisitos de Active Directory para implementaciones híbridas y de campo verde (entornos que utilizan Citrix Cloud y el servicio CVAD para la intermediación y administración de sesiones), consulteDetalles técnicos de Citrix Cloud Connector。Además de cubrirniveles funcionales de Active Directory admitidos, este artículo también cubreescenarios de implementaciones para Cloud Connectors en Active Directory。

Para obtener más información sobre los requisitos de Active Directory para las implementaciones de elevación y desplazamiento (entornos que utilizan la intermediación y administración de sesiones administradas por el cliente mediante las versiones LTSR o CR de Citrix Virtual Apps and Desktops), consulteDescripción técnica de CVAD, Active DirectoryyRequisitos del sistema CVAD,含量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 alcance 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 (CVADS) para este componente crítico, pero para ciertos requisitos y escenarios, puede ser necesario o recomendable implementar un subsistema de intermediación y administración de sesiones gestionado por el cliente (a través de versiones CVAD LTSR o CR). En la siguiente tabla se destacan algunos de estos requisitos y escenarios para su consideración:

Atributo/Capacidad	CVAD administrado por el cliente (versiones Citrix Virtual Apps and Desktops, LTSR o CR)	Servicio en la nube CVADS (Servicio Citrix Virtual Apps and Desktops, 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.	SÍ: Cloud Connectors se comunican a través de Internet con Citrix Cloud, aunque estas conexiones se pueden utilizar por proxy. ConsulteCómo configurar un servidor proxy para Citrix Cloud Connectorpara obtener más detalles. 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.	SÍ: 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: CVADS no requiere que los clientes toquen el servidor SQL: los servicios de base de datos de alta disponibilidad son proporcionados por 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.	SÍ: 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 delsistema operativo Windows Serveren 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 utilizar servicios avanzados proporcionados por Citrix Cloud, incluido elFunción de escala 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Í: CVADS está diseñado para funcionar “fuera de la caja” con otros servicios de Citrix Cloud, y estos servicios suelen estar preconfigurados, por lo que el cliente simplemente los enciende. ElFunción de escalado automático, que proporciona la capacidad de controlar granularmente la cantidad y el estado de potencia de los VDA, es impactante para las implementaciones de VDA en la nube pública. Puede proporcionar ahorros sustanciales en costes de infraestructura en escenarios 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.	SÍ: 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 CVADS, los clientes renuncian a cierta medida de control, pero obtienen simplicidad, reducen los costes de infraestructura y reducen sustancialmente la sobrecarga administrativa.
Capacidad para obtener licencias basadas en usuarios simultáneos frente a usuarios nombrados.	SÍ- CVAD puede ser licenciado por CCU.	SÍ- La licencia CCU está disponible. Para obtener más detalles, consulteeste blog。

Cloud Connectors, Delivery Controllers y Ubicaciones de Recursos

Dado que tanto los modelos de campo verde como los híbridos utilizan los servicios en la nube (CVADS) para la intermediación y la administración de sesiones, se implementa Cloud Connectors para crear unaubicación de recursos在地区en la, planea alojar VDA。艾尔crear una ubicación de recursos en una región, se crea una configuración de alta disponibilidad mediante la implementación de instanciasn+1de 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 enrutamiento diferentes a los dos tipos de recursos diferentes.

Diagrama 13: Patrón de diseño de ubicación de recursos de CVADS con subredes separadas para VDA y Cloud ConnectorsDiagrama 13: Patrón de diseño de ubicación de recursos de CVADS con subredes separadas para VDA y 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. Consulteeste artículopara obtener más información sobre el tamaño de las instancias de Cloud Connector.

Consideraciones sobre el diseño del sitio de Citrix Virtual Apps and Desktops

Ubicaciones y zonas de recursos

El usoZonas de Citrix(no debe confundirse con las zonas de disponibilidad) puede ayudar a los usuarios de regiones remotas a conectarse a recursos sin obligar necesariamente a sus conexiones a atravesar grandes segmentos de la WAN. En un entorno de Citrix Virtual Apps and Desktops Service, 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 lo siguienteenlace。

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?帕拉obtener mas给。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, la autenticación basada en roles se puede utilizar al crear una conexión de host paraAprovisionamiento 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 autenticación basada en roles, primero cree una función de IAM con los permisos descritos enCTX140429。Asociar este rol a una instancia de EC2con 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. A continuaciónartículose describe cómo configurar una conexión de host de esta manera.

Después de crear la conexión de host, cree un catálogo de máquinas tal como se describeaquí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:CitrixMCS en AWS Deep Dive 1yCómo funciona MCS después de crear máquinas virtuales agrupadas en AWS。

Otro elemento que debe tenerse en cuenta al implementar VDA en AWS mediante MCS esInicialización del volumen de EBS(también conocido 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. ConsulteInicialización de volúmenes de Amazon EBS en Windowslos pasos recomendados de AWS para inicializar volúmenes de Amazon EBS en instancias de Windows y consulteInicialización de volúmenes de Amazon EBS en Linuxpara instancias de Linux.

ConsulteConsideraciones sobre la capa de infraestructura (o plataforma)para obtener más detalles 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.

• Algunos tipos de instancias de AWS más recientes no se mostrarán de forma predeterminada en el asistente de creación de catálogo de máquinas en Studio (ya sea CVAD o CVADS). La interfaz de usuario se rellena con tipos de instancia de un archivo XML estático que reside en Delivery Controllers (CVAD) o Cloud Connectors (CVADS). 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). ConsulteActualizar tipos de instancias de AWS para XenDesktoppara obtener más información sobre cómo actualizar la lista de tipos de instancias de AWS disponibles.
• El aprovisionamiento de MCS falla en AWS EC2 cuando se utilizan instancias dedicadas
• No se puede crear una conexión de alojamiento de AWS en Citrix Cloud DDC cuando el proxy está configurado en el servidor del conector
• 艾尔crear变化con MCS y AWS se产生联合国埃罗r “xDDS: 2367399E”
• Configurar la instancia de Volume Worker para utilizar la VPC del catálogo de máquinas y no la VPC predeterminada
• Cómo garantizar la compatibilidad de regiones al utilizar XenApp y XenDesktop MCS en AWS
• Sugerencias para la solución de problemas del campo para Machine Creation Services en AWS

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 desean 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, nos referimos al siguiente diagrama que representa el patrón de diseño de una ubicación de recursos CVADS en AWS:

Diagrama 14: Arquitectura/patrón de diseño implementado de “Ubicación de recursos” a partir del servicio Citrix Virtual Apps and Desktops Service en la plantilla de AWS Quick Start CloudFormationDiagrama 14: Arquitectura/patrón de diseño implementado “Ubicación de recursos” a partir del servicioCitrixVirtual Apps and Desktops Service en AWSQuick Start CloudFormation plantilla.

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 medianteAWS CloudFormationplantillas. AWS proporciona una biblioteca que se puede ejecutar talPlantillas de inicio rápidocual, agrupar en capas (“anidada”) con otras plantillas e incluso duplicarse 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 alcance 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.

Volver al modelo de objetos de AWS por un momento: el objeto de nivel superior del diagrama 14 es elRegión de AWS。Puede pensar en las regiones de AWS como clústeres de centros de datos bien conectados pero estratégicamente separadosZonas 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 alcance 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 alcance 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 CVADS están enlazados 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 enruta 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 enrutamiento 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 enrutamiento y seguridad a los VDA y Cloud Connectors.

El acceso a Internet saliente desde cualquier subred de una VPC (una construcción regional) se puede manejar de muchas maneras diferentes, pero un método común es utilizarPuertas de enlace NATpara proporcionar conectividad a Internet a subredes privadas. Las subredes públicas suelen ser servidas porInternet Gateways, lo que facilita el enrutamiento de las conexiones entrantes a servicios a los que se puede acceder 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 enrutables 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 presentarles a todos aquí, pero dos herramientas/técnicas que vale la pena examinar sonPeering VPCypuertas de enlace de tránsito。Estas dos construcciones le ayudan a introducir el enrutamiento del tráfico entre VPC simplemente (Peering VPC) o en un modelo más apto para la empresa y amigable en la nube híbrida (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 alcance 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 formareproducible a partir de código。Cuando se combina con un servicio de implementación potente e integralAWS CloudFormation, como, por ejemplo, los clientes disponen de un potente marco para aprender, personalizar, implementar y administrar sistemas de TI. El concepto deInfraestructura como códigopuede ser nuevo o perplejo 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 CloudFormation basada en la que se puede ejecutar talPlantillas de inicio rápidocual, agrupar en capas (“anidadas”) con otras plantillas e incluso duplicarse y personalizar 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:

• Servicio Citrix Virtual Apps and Desktops en AWS: Implementa una “Ubicación de recursos” de Citrix Cloud Virtual Apps and Desktops Service de alta disponibilidad en AWS.
• CitrixADC para aplicaciones web: Implementa instancias de Citrix ADC VPX de alta disponibilidad en AWS. Aunque el enfoque del caso de uso difiere ligeramente, este patrón de diseño es funcional y relevante para las implementaciones de Citrix Gateway con CVAD/CVADS también. Citrix y AWS están trabajando en un inicio rápido adicional para este caso de uso específico.

Ya hemos discutido cómo se relaciona el patrón de diseño “Citrix ADC for Web Applications” con el patrón de diseño de ubicación de recursos CVADS en la plantilla “Citrix Virtual Apps and Desktops Service on AWS”, así que vamos a desglosar un par de plantillas fundamentales que subyacen a ambas. Para simplicidad, lo llamamos la “plantilla CVADS”.

Si abrimos laplantilla QuickStart de CVADSen CloudFormation Designer, obtenemos una representación visual de esta plantilla. A partir de este visual, podemos ver que esta plantilla utiliza tres pilas o plantillas “anidadas” separadas:

Diagrama 15: Plantilla CVADS en CloudFormation Designer con pilas anidadasDiagrama 15: Plantilla CVADS en CloudFormation Designer con pilas anidadas.

En el diagrama 15, CitrixResourceLocationStack está “en la parte superior”, y las otras tres pilas anidadas debajo de él son pilas fundamentales, administradas y mantenidas por AWS.

La plantilla “VPCStack”establece la mayor parte de la base de red debajo de la plantilla CVADS. VPCStack es responsable de crear los siguientes componentes del diagrama de pila CVADS. Todas las demás pilas se construyen sobre estos recursos y parámetros:Diagrama 16: Resultados de compilación de ejemplos de vPCStackDiagrama 16: VPCStack muestra genera resultados.

Además de vPCStack viene el RDGWStack y AdStack. ElPlantilla RDGWStackestablece la infraestructura para proporcionar acceso de consola remota administrativa a la red creada por VPCStack. Se representa en naranja en el diagrama 17. ElPlantilla AdStack, que se ejecuta en paralelo a RDGWStack, crea la infraestructura de Active Directory para un sistema. Incluye opciones para crear AD en instancias de IaaS y también utilizar el servicio AWS Active Directory. Para nuestro patrón de diseño de ejemplo, está construyendo el objeto AD DS Service en rojo:Diagrama 17: VPStack + RDGWStack + resultados de compilación de muestra de AdStack.

Finalmente, CitrixResourceLocationStack (la pila ‘maestra’, que llama a las tres pilas anidadas) se ejecuta, construyendo sobre las tres pilas de base. Es responsable de crear Cloud Connectors y VDA en AWS, y utiliza las API de Citrix Cloud para crear la ubicación de recursos, la conexión de alojamiento, el catálogo de máquinas y el grupo de entrega en su arrendatario de Citrix Cloud. ¿El resultado final? Una ubicación de recursos de Citrix Cloud totalmente funcional que se ejecuta en AWS:Diagrama 18: Resultados de compilación de ejemplo de CitrixResourceLocationStack (más pilas anidadas)Diagrama 18: CitrixResourceLocationStack (más pilas anidadas) resultados de compilación de ejemplo.

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, creando sistemas completos (como una ubicación de recursos CVADS en AWS que funcione plenamente) a partir de los patrones de diseño individuales (plantillas).
• La plantilla de inicioServicio Citrix Virtual Apps and Desktops en AWSrápido se basa en tres plantillas de base administradas/mantenidas de AWS, que están bien documentadas. Comience con los siguientes enlaces para obtener más información sobre cada uno de ellos:
  • La plantilla VPCStack:https://aws.amazon.com/quickstart/architecture/vpc/
  • La plantilla RDGWStack:https://aws.amazon.com/quickstart/architecture/rd-gateway/
  • La plantilla de AdStack:https://aws.amazon.com/quickstart/architecture/active-directory-ds/
  • 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:

• Communication Ports Used by Citrix Technologies: una buena referencia global para los puertos de comunicación utilizados por diferentes componentes de la pila de virtualización de Citrix.

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 consultarMonitor, temala documentación del producto Citrix para obtener más información.

Tareas bajo demanda

En la手鼓siguiente se describen las他利亚问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.
CitrixVirtual Apps and Desktops	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.
CitrixVirtual Apps and Desktops	Publicar imagen	Cuando se modifican las imágenes, se prueban y publican.
AWS	Verificar el inicio de la instancia	Cuando se inicia 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我	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 rangos de IP. Las reglas de entrada y salida deben modificarse para implementar bloqueos de tráfico de red.
AWS y Citrix Virtual Apps and Desktops	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 Virtual Apps and Desktops	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:c !绝对可能!onfigurar 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 de Citrix Virtual Apps and Desktops se incluyen en laSupervisiónsección de la guía de prácticas recomendadas 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.
CitrixVirtual 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.
CitrixVirtual Apps and Desktops	Realizar copias de seguridad增量de基地s 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手鼓siguiente se describen las他利亚问se van a realizar semanalmente.

Componente	Tarea	Descripción
Genérico	Revisar las revisiones y revisiones más recientes	Revisar, probar e implementar lasrevisiones hotfixCitrix mas recientes y comprobar si洛杉矶交付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.
CitrixVirtual Apps and Desktops	Comprobarinformes 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.
CitrixVirtual 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手鼓siguiente se describen las他利亚问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 incluyenDecisión: Administración de la capacidaden la secciónSupervisiónde la guía Citrix Virtual Apps and Desktop Prácticas recomendadas.
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手鼓siguiente se describen las他利亚问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 de la功能德尔计划Continuidad del底片ocio (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 de origen que puede adaptar en sus propios diseños detallados y guías de implementación:diagramas de origen。