Documentación de productos
Citrix Tech Zone
Ver PDF

Arquitectura de referencia: Citrix DaaS - Azure

May 12, 2023
Author:  Loay Shbeilat
Special thanks:  Nitin Mehta

Introducción

Esta guía ayuda con el modelo de arquitectura e implementación de Citrix DaaS en Microsoft Azure.

La combinación de Citrix Cloud y Microsoft Azure permite aumentar los recursos virtuales de Citrix con mayor agilidad y elasticidad, ajustando el uso a medida que cambian los requisitos. Las máquinas virtuales en Azure admiten todos los componentes de control y carga de trabajo necesarios para una implementación de Citrix DaaS. Citrix Cloud y Microsoft Azure tienen integraciones comunes de plano de control que establecen identidad, gobernanza y seguridad para operaciones globales.

Este documento también proporciona orientación sobre requisitos previos, consideraciones de diseño de la arquitectura y orientación de implementación para entornos de clientes. El documento destaca las decisiones de diseño y las consideraciones de implementación en los siguientes cinco principios arquitectónicos clave:

  • Operaciones: Las operaciones incluyen una amplia variedad de temas, como la administración de imágenes, la supervisión de servicios, la continuidad del negocio, el soporte y otros. Hay varias herramientas disponibles para ayudar con la automatización de las operaciones, incluidas Azure PowerShell, la CLI de Azure, las plantillas ARM y la API de Azure.

  • Identidad: Una de las piedras angulares de toda la imagen de Azure es la identidad de una persona y su acceso basado en roles (RBAC). La identidad de Azure se administra a través de Azure Active Directory (Azure AD) y Azure AD Domain Services. El cliente debe decidir el camino a seguir para su integración de identidad.

  • Gobernanza: La clave de la gobernanza es establecer las directivas, los procesos y los procedimientos asociados con la planificación, la arquitectura, la adquisición, la implementación y la administración operativa de los recursos de Azure.

  • Seguridad : Azure ofrece una amplia gama de opciones de seguridad configurables y la capacidad de controlarlas para que los clientes puedan personalizar la seguridad para cumplir con los requisitos únicos de las implementaciones de su organización. Esta sección ayuda a comprender cómo las capacidades de seguridad de Azure pueden ayudarle a cumplir estos requisitos.

  • Conectividad : la conexión de las redes virtuales de Azure con la red local/en la nube del cliente se denomina red híbrida. En esta sección se explican las opciones de conectividad de red y redirección de servicios de red.

Planificación

Los tres casos más comunes para entregar Citrix Apps and Desktops a través de Azure son:

  • Implementación Greenfield con Citrix Cloud que ofrece ubicaciones de recursos en Azure. Este caso se entrega a través de Citrix DaaS y se usa cuando los clientes prefieren ir a un modelo de suscripción y externalizar la infraestructura del plano de control a Citrix.
  • Ampliar una implementación local en Azure. En este caso, el cliente tiene una capa de control local actual y le gustaría agregar Azure como ubicación de recursos de Citrix para nuevas implementaciones o migraciones.
  • Lift and Shift. Con este caso, los clientes implementan su infraestructura de Citrix Management en Azure y tratan a Azure como un sitio, mediante Citrix ADC y StoreFront para agregar recursos de varios sitios.

Este documento se centra en el modelo de implementación de Citrix Cloud. Los clientes pueden planificar y adoptar estos servicios en función de las necesidades de su organización:

Citrix DaaS

Citrix DaaS simplifica la entrega y la administración de las tecnologías Citrix, lo que ayuda a los clientes a ampliar las implementaciones de software existentes en las instalaciones o a migrar el 100 por ciento a la nube. Proporcione acceso seguro a aplicaciones Windows, Linux y web, así como a escritorios virtuales Windows y Linux. Administre aplicaciones y escritorios de forma centralizada en varias ubicaciones de recursos, manteniendo al mismo tiempo una excelente experiencia para el usuario final.

Citrix Virtual Desktops Essentials Service

Los clientes de Citrix y Microsoft tienen más opciones para implementar Windows 10 Enterprise dentro de su organización. Citrix Virtual Desktops Essentials Service acelera la migración a Windows 10 Enterprise para los clientes que prefieren las soluciones en la nube de Microsoft Azure. Esto permite a los clientes que tienen licencia de Windows 10 Enterprise (sucursal actual para empresas) por usuario la opción de ofrecer una experiencia de escritorio virtual Windows 10 Enterprise de alto rendimiento desde Azure.

Citrix Virtual Apps Essentials Service

Citrix Virtual Apps Essentials, el nuevo servicio de virtualización de aplicaciones, combina la potencia y la flexibilidad de la plataforma Citrix Cloud con la visión simple, prescriptiva y fácil de consumir de Microsoft Azure RemoteApp. Citrix Virtual Apps Essentials proporciona un rendimiento y una flexibilidad superiores al trasladar la infraestructura de back-end a la nube, lo que simplifica la entrega de aplicaciones sin sacrificar la administración ni la experiencia del usuario final.

Arquitectura de referencia conceptual

Esta arquitectura conceptual proporciona directrices comunes para la implementación de una ubicación de recursos de Citrix Cloud en Azure, que se analizarán en las siguientes secciones.

Azure-RA-Image-1

Diagrama 1: Arquitectura de referencia conceptual de Citrix Cloud

Consulte la guía de diseño sobre la escalabilidad y la economía de la entrega de Citrix DaaS en Microsoft Azure

Operaciones

En el área temática de operaciones, esta guía profundiza en la planificación de los requisitos del entorno del espacio de trabajo y la jerarquía de los servicios básicos. En la capa superior, se encuentran las consideraciones de suscripción, grupo de recursos y diseño regional. Seguidas de preguntas comunes sobre el almacenamiento de VM, el almacenamiento de perfiles de usuario y la administración y el aprovisionamiento de imágenes maestras. También se proporciona orientación sobre la optimización de instancias reservadas con escalabilidad automática y la planificación de la continuidad del negocio y la recuperación ante desastres.

Convenciones de nomenclatura

La denominación de los recursos en Microsoft Azure es importante porque:

  • No se puede cambiar el nombre de la mayoría de los recursos
  • Los tipos de recursos específicos tienen diferentes requisitos de denominación
  • Las convenciones de nomenclatura coherentes facilitan la localización de los recursos y pueden indicar la función de un recurso

La clave del éxito con las convenciones de nomenclatura es establecerlas y seguirlas en todas sus aplicaciones y organizaciones.

Al asignar nombres a las suscripciones de Azure, los nombres detallados facilitan la comprensión del contexto y el propósito de cada suscripción. Seguir una convención de nomenclatura puede mejorar la claridad cuando se trabaja en un entorno con muchas suscripciones.

Un patrón recomendado para asignar nombres a las suscripciones es:

Variable Ejemplo Descripción
[Sistema] CTX (Citrix), CORE (Azure) Identificador de tres letras para el producto, aplicación o servicio que admite el recurso.
[Función] XAW (XenApp Workers), VDA (Virtual Delivery Agent), CC (Cloud Connector), CVA (Citrix Virtual Apps) Identificador de tres letras para un subsistema del servicio.
[Entorno] D, T, P (desarrollo, pruebas o producción) Identifica el entorno del recurso
## 01, 02 Para recursos que tienen más de una instancia con nombre (servidores web, etc.).
[Ubicación] WU (Oeste de EE. UU.), UE (Este de EE. UU.), SCU (Centro Sur de EE. UU.) Identifica la región de Azure en la que se implementa el recurso

Al asignar nombres a los recursos en Azure, utilice prefijos o sufijos comunes para identificar el tipo y el contexto del recurso. Si bien toda la información sobre el tipo, los metadatos y el contexto está disponible mediante programación, la aplicación de afijos comunes simplifica la identificación visual. Al incorporar afijos en la convención de nomenclatura, es importante especificar claramente si el afijo está al principio del nombre (prefijo) o al final (sufijo).

Un esquema de nomenclatura bien definido identifica el sistema, el rol, el entorno, el recuento de instancias y la ubicación de un recurso de Azure. La nomenclatura se puede aplicar mediante una directiva de Azure.

Servicio Ámbito Patrón sugerido Ejemplo
Suscripciones Global [System][Environment]##[Location]-sub WSCD01scu-sub
Grupos de recursos Global [System]-[Role]-[Environment]##-[Location]-rg CTX-Apps-P01-CUS-rg
Red virtual Grupo de recursos [System][Environment]##[Location]-vnet CTXP01cus-vnet
Subred Red virtual principal [Descriptive Context] DMZ - 10.0.1.0/24 Infrastructure - 10.0.2.0/24
Cuenta de almacenamiento Grupo de recursos [System][Role][Environment]##[Location] Nota: Deben ser caracteres alfanuméricos en minúscula ctxinfd01scu
Contenedor Cuenta de almacenamiento [Descriptive Context] vhds
Máquina virtual Grupo de recursos [System][Role][Environment]##[Location] Nota: Debe tener 15 caracteres o menos. CTXSTFD01scu
Interfaz de red Grupo de recursos [vmname]-nic# CTXSTFD01scu-nic1
IP públicas Grupo de recursos [vmname]-pip CTXSTFD01scu-pip
Pasarela de red virtual Red virtual [System][Environment]##[Location]-vng WSCD01scu-vng
Gateway de red local Grupo de recursos [System][Environment]##[Location]-lng WSCD01scu-lng
Juegos de Disponibilidad Grupo de recursos [System][Role]-as CTXSTF-as
Equilibrador de carga Grupo de recursos [System][Role]-lb CTXNSG-lb
Espacios de trabajo Subscription [System][Environment]-analytics CTXP-analytics
Etiquetas Recurso [Descriptive Context] Finance
Caja fuerte de llaves Subscription [System][Environment]-vault CTXP-vault

Suscripciones

La selección de un modelo de suscripción es una decisión compleja que implica comprender el crecimiento de la presencia de Azure del cliente dentro y fuera de la implementación de Citrix. Incluso si la implementación de Citrix es pequeña, es posible que el cliente tenga una gran cantidad de otros recursos que están leyendo o escribiendo en gran medida contra la API de Azure, lo que puede tener un impacto negativo en el entorno Citrix. Lo contrario también es cierto, ya que muchos recursos Citrix pueden consumir un número excesivo de llamadas API disponibles, lo que reduce la disponibilidad de otros recursos dentro de la suscripción.

Modelo de espacio de trabajo de suscripción

En un modelo de suscripción único, toda la infraestructura principal y la infraestructura Citrix se encuentran en la misma suscripción. Esta es la configuración recomendada para implementaciones que requieren hasta 2,500 VDA de Citrix (puede ser de sesión, VDI agrupado o VDI persistente). Los límites están sujetos a cambios; consulte lo siguiente para conocer los límites de VDA más actualizados. Consulte el siguiente blog para obtener los últimos números de escala de inicio y cierre dentro de una sola suscripción:

Diagram-2: Modelo de espacio de trabajo de suscripción única de Azure Azure-RA-Image-2

Modelo de Workspace multisuscripción

En este modelo, la infraestructura principal y la infraestructura de Citrix están en suscripciones separadas para administrar la escalabilidad en grandes implementaciones. A menudo, las implementaciones empresariales con diseño de infraestructura de varias regiones se dividen en varias suscripciones para evitar que se alcancen los límites de suscripción de Azure.

Azure-RA-Image-3

Diagrama 3: Modelo de Workspace Multi-Subscription de Azure

Las siguientes preguntas proporcionan orientación para ayudar a los clientes a comprender las opciones de suscripción a Azure y planificar sus recursos.

Componente Requisito
¿La suscripción a Azure solo contendrá recursos de Citrix? Determine si la suscripción de Azure se utilizará para recursos de Citrix dedicados o si los recursos de Citrix se compartirán con otros sistemas.
¿Implementación de una o varias suscripciones? Por lo general, las implementaciones de suscripciones múltiples son para implementaciones más grandes en las que las limitaciones de una sola suscripción son un problema y se necesitan controles de seguridad más detallados.
¿Qué límites de Azure es probable que se alcancen? ¿Cuántos recursos hay en un grupo de recursos? Los grupos de recursos tienen límites y Machine Creation Services (MCS) requiere 2 o 3 discos por recurso de VM. Revise los límites de suscripción de Azure mientras planifica la solución.
¿Qué permisos son necesarios para el principio de servicio CVAD en la suscripción de Azure? Citrix DaaS requiere la creación de grupos de recursos y recursos dentro de la suscripción. Por ejemplo, cuando al principio de servicio no se le puede conceder acceso total a una suscripción, se le debe conceder acceso de Colaborador a un grupo de recursos creado previamente.
¿Se crearán los entornos de desarrollo y pruebas en suscripciones separadas de production? El aislamiento de las suscripciones de desarrollo y pruebas de Production permite la aplicación y el cambio de los servicios globales de Azure en un entorno aislado y la utilización de recursos de silos. Esta práctica tiene beneficios para la seguridad, el cumplimiento y el rendimiento de la suscripción. La creación de suscripciones independientes para estos entornos agrega complejidad a la administración de imágenes. Estas compensaciones deben considerarse en función de las necesidades del cliente.

Regiones de Azure

Una región de Azure es un conjunto de centros de datos implementados dentro de un perímetro definido por latencia y conectados a través de una red regional dedicada de baja latencia. Azure ofrece a los clientes la flexibilidad necesaria para implementar aplicaciones donde se necesitan. Azure está disponible en general en 59 regiones de todo el mundo, y se han anunciado planes para 19 regiones más a finales de 2022.

Una geografía es un mercado discreto, que normalmente contiene dos o más regiones de Azure, que conservan los límites de residencia de datos y cumplimiento de normas. Las geografías permiten a los clientes con necesidades específicas de residencia de datos y cumplimiento de normas mantener sus datos y aplicaciones cerca.

Las zonas de disponibilidad son ubicaciones separadas físicamente dentro de una región de Azure. Cada zona de disponibilidad está compuesta por uno o más centros de datos equipados con alimentación, refrigeración y redes independientes. Las zonas de disponibilidad permiten a los clientes ejecutar aplicaciones de misión crítica con alta disponibilidad y replicación de baja latencia. Para garantizar la resiliencia, hay un mínimo de tres zonas separadas en todas las regiones habilitadas.

Considere estos factores al elegir su región.

Componente Requisito
Cumplimiento y residencia de datos ¿Los clientes tienen requisitos específicos de cumplimiento de normas o residencia de datos? Microsoft puede copiar datos de clientes entre regiones dentro de un geográfico determinado para redundancia de datos u otros fines operativos. Por ejemplo, Azure Globally Redundant Storage (GRS) replica datos de Blob y Table entre dos regiones dentro del mismo Geo para mejorar la durabilidad de los datos si hay un desastre importante del centro de datos. Algunos servicios de Azure no permiten al cliente especificar la región en la que se implementará el servicio. Estos servicios pueden almacenar datos de clientes en cualquiera de los centros de datos de Microsoft a menos que se especifique. Consulte el sitio web de mapas de Azure Regions para conocer las actualizaciones
Disponibilidad del servicio Revise la disponibilidad del servicio dentro de las regiones provisionales. La disponibilidad de servicios por región ayuda al cliente a determinar qué servicios están disponibles dentro de una región. Aunque se puede admitir un servicio de Azure en una región determinada, no todas las funciones del servicio están disponibles en nubes soberanas, como Azure Government, Alemania y China.
Determine las regiones de destino de Azure para la implementación de Citrix. Revise la proximidad de la región de Azure a los centros de datos de usuarios y clientes
¿Se requieren varias regiones de Azure? Por lo general, se consideran varias regiones de Azure por las siguientes razones de alto nivel: Proximidad a los datos de la aplicación o a los usuarios finales; redundancia geográfica para la continuidad del negocio y la recuperación ante desastres; disponibilidad de funciones o servicios de Azure

Juegos de Disponibilidad

Un conjunto de disponibilidad es una capacidad de agrupación lógica que se puede usar en Azure para garantizar que los recursos de VM colocados dentro de un conjunto de disponibilidad estén aislados entre sí cuando se implementan en un centro de datos de Azure. Azure garantiza que las máquinas virtuales colocadas dentro de un conjunto de disponibilidad se ejecuten en varios servidores físicos, racks de procesamiento, unidades de almacenamiento y conmutadores de red. Si se produce un error de hardware o software de Azure, solo se ve afectado un subconjunto de las máquinas virtuales y la aplicación general permanece en funcionamiento y permanece disponible para los clientes. Los conjuntos de disponibilidad son una capacidad esencial cuando los clientes quieren crear soluciones de nube fiables.

Cada componente de una implementación de Citrix debe estar en su propio conjunto de disponibilidad para maximizar la disponibilidad general de Citrix. Por ejemplo, se debe usar un conjunto de disponibilidad independiente para Cloud Connectors, otro para Citrix Application Delivery Controllers (ADC), StoreFront, etc.

Una vez optimizados los conjuntos de disponibilidad, el siguiente paso es crear resiliencia en torno al tiempo de inactividad de las VM dentro de los conjuntos de disponibilidad. Esto minimiza o elimina el tiempo de inactividad del servicio cuando Microsoft reinicia o vuelve a implementar las VM. Esto también se puede ampliar a los eventos de mantenimiento planificados. Hay dos funciones que puede utilizar que pueden aumentar la fiabilidad del servicio general.

Estas dos funciones no protegen contra mantenimiento/bloqueos no planificados.

  • Mantenimiento planificado de Azure
  • Eventos programados de Azure

Mantenimiento planificado de Azure

Azure realiza actualizaciones periódicamente para mejorar la fiabilidad, el rendimiento y la seguridad de la infraestructura de host en Azure. Si el mantenimiento requiere un reinicio, Microsoft envía un aviso. Con Azure Planned Maintenance, es posible capturar estos avisos y tomar medidas al respecto de manera proactiva según el cronograma del cliente, en lugar de según el cronograma de Microsoft.

Utilice la función de mantenimiento planificado enviando notificaciones por correo electrónico al propietario del servicio de cada nivel (para la intervención manual) y cree runbooks para automatizar la protección del servicio.

Eventos programados de Azure

Azure Scheduled Events es un servicio de metadatos de Azure que notifica mediante programación a las aplicaciones para alertar sobre el mantenimiento inmediato. Proporciona información sobre los próximos eventos de mantenimiento (por ejemplo, el reinicio) para que el administrador de la aplicación pueda prepararse y limitar las interrupciones. Si bien puede parecer un mantenimiento planificado, no lo es. La diferencia clave es que estos eventos se desencadenan por el mantenimiento planificado y, a veces, por el mantenimiento no planificado. Por ejemplo, si Azure está realizando actividades de reparación de hosts y necesita mover las máquinas virtuales con poca antelación.

Estos eventos se consumen mediante programación y se avisará con la siguiente antelación:

  • Congelar â 15 minutos
  • Reiniciar â 15 minutos
  • Redespliegue â 10 minutos

Recuperación ante desastres (DR)

Azure puede proporcionar una solución de DR altamente rentable para los clientes de Citrix que buscan obtener un valor inmediato de la adopción de la nube en la actualidad. La topología del modelo de implementación determina la implementación de la solución DR.

Ampliación de la arquitectura

Con esta topología, la infraestructura de administración permanece en las instalaciones, pero las cargas de trabajo se implementan en Azure. Si el centro de datos local no es accesible, los usuarios conectados existentes permanecen conectados, pero no serán posibles nuevas conexiones porque la infraestructura de administración no está disponible.

Para proteger la infraestructura de administración, preconfigure Azure Site Recovery para recuperar la infraestructura de administración en Azure. Este es un proceso manual y una vez recuperado, su entorno puede ser operativo. Esta opción no es perfecta y no puede recuperar componentes como ADC VPX; sin embargo, para las organizaciones con un objetivo de tiempo de recuperación (RTO) más flexible, puede reducir los costes operativos.

Arquitectura de Hosting

Al implementar esta topología, la infraestructura de administración de Citrix se implementa en Azure y se trata como un sitio independiente. Esto proporciona aislamiento funcional de la implementación local en caso de que se produzca un error en el sitio. Utilice Citrix ADC y StoreFront para agregar recursos y proporcionar a los usuarios una conmutación por error casi instantánea entre los recursos de producción y recuperación ante desastres.

La presencia de Citrix Infrastructure en Azure significa que no es necesario invocar procesos manuales ni restaurar sistemas antes de que los usuarios puedan acceder a su Workspace principal.

Arquitectura de servicios de nube

Cuando se usa Citrix Cloud, Azure se convierte en otra ubicación de recursos. Esta topología proporciona la implementación más sencilla, ya que Citrix como servicio aloja los componentes de administración, y las cargas de trabajo de recuperación ante desastres se pueden lograr sin implementar una infraestructura duplicada que lo admita. La experiencia del usuario durante la conmutación por error en caso de un desastre puede ser perfecta.

Los elementos de la tabla siguiente ayudan al cliente a planificar la recuperación ante desastres:

Componente Requisito
¿Cuáles son los requisitos de RTO y RPO del entorno Citrix? RTO: Duración específica del tiempo y nivel de servicio dentro del cual se debe restaurar un proceso de negocio después de un desastre. RPO: el intervalo de tiempo que puede transcurrir durante una interrupción antes de que la cantidad de datos perdidos durante ese período supere el umbral o “tolerancia” máximo permitido del plan de continuidad empresarial.
¿Cuál es el resultado deseado cuando se produce una interrupción del servicio en toda la región donde se implementa la aplicación de máquina virtual de Azure? Estas opciones deben revisarse en consonancia con el RTO y el RPO del cliente para DR. La recuperación ante desastres de un entorno Citrix en Azure se puede abordar con Azure Site Recover, el sitio secundario pasivo y el sitio activo de Site Azure Site. La recuperación solo admite SO de servidor (infraestructura Citrix y VDA de servidor). No se admite el SO cliente (por ejemplo, escritorios persistentes creados con plantillas ARM). Además, los catálogos de máquinas creados por MCS (VDA de servidor o cliente) se deben volver a crear mediante una tarea de recuperación.

Grupos de recursos

Los grupos de recursos (RG) de Azure son una colección de activos en grupos lógicos para el aprovisionamiento, la supervisión y el control de acceso fáciles o incluso automáticos, y para una administración más eficaz de sus costes. La ventaja de usar RG en Azure es agrupar los recursos relacionados que pertenecen a una aplicación juntos, ya que comparten un ciclo de vida unificado desde la creación hasta el uso y, finalmente, el desaprovisionamiento.

La clave para tener un diseño correcto de los grupos de recursos es comprender el ciclo de vida de los recursos que se incluyen en ellos.

Los grupos de recursos están vinculados a catálogos de máquinas en el momento de la creación y no se pueden agregar ni cambiar más adelante. Para agregar grupos de recursos adicionales a un catálogo de máquinas, se debe quitar y volver a crear el catálogo de máquinas.

Administración de imágenes

La administración de imágenes es el proceso de creación, actualización y asignación de una imagen que se aplica de manera uniforme en los entornos de desarrollo, pruebas y producción. Al desarrollar un proceso de administración de imágenes, se debe tener en cuenta lo siguiente:

Aprovisionamiento a la carta

El cliente debe determinar si MCS se debe usar para administrar las máquinas no persistentes de Azure o crear sus propias plantillas de Azure Resource Manager (ARM). Cuando un cliente usa MCS para crear catálogos de máquinas, la función de Provisioning bajo demanda de Azure reduce los costes de almacenamiento, proporciona una creación de catálogos más rápida y operaciones de energía de máquinas virtuales (VM) más rápidas. Con el aprovisionamiento bajo demanda de Azure, las máquinas virtuales se crean solo cuando Citrix DaaS inicia una acción de encendido, después de que se completa el aprovisionamiento. Una máquina virtual es visible en el portal de Azure solo cuando se está ejecutando, mientras que en Citrix Studio, todas las máquinas virtuales son visibles, independientemente del estado de alimentación. Citrix puede administrar la energía de las máquinas creadas a través de plantillas ARM o MCS mediante una conexión de host de Azure en Citrix Studio.

Contenedores de la cuenta

El cliente debe decidir la estructura organizativa para las imágenes de origen (o doradas) de almacenamiento a partir de las cuales crear las máquinas virtuales mediante Citrix Machine Creation Services (MCS). Las imágenes de Citrix MCS se pueden obtener a partir de instantáneas, discos administrados o no administrados, y pueden residir en almacenamiento estándar o premium. Se accede a los discos no administrados a través de cuentas de almacenamiento de uso general y se almacenan como VHD dentro de los contenedores de almacenamiento de blob de Azure. Los contenedores son carpetas que se pueden usar para separar imágenes de producción, prueba y desarrollo.

Réplica de imágenes

El cliente debe determinar el proceso adecuado para replicar imágenes entre regiones y cómo se puede utilizar la tecnología de Citrix App Layering dentro de la estrategia general de administración de imágenes. Los scripts de PowerShell se pueden usar con Azure Automation para programar la replicación de imágenes. Puede encontrar más información sobre Citrix App Layering aquí, pero tenga en cuenta que Elastic Layering requiere un recurso compartido de archivos SMB que no resida en Azure Files. Consulte la sección File Servers para conocer las tecnologías de uso compartido SMB compatibles que admiten capas elásticas.

Tecnologías de servidores de archivos

Azure ofrece varias tecnologías de servidor de archivos que se pueden usar para almacenar datos de usuarios de Citrix, información de perfiles móviles o funcionar como destinos para los recursos compartidos de Citrix Layering. Estas opciones incluyen las siguientes:

  • Servidor de archivos independiente
  • Servidores de archivos con Réplica de almacenamiento
  • Scale Out File Server (SOFS) con Storage Spaces Direct (S2D)
  • Sistema de archivos distribuido â Replicación (DFS-R)
  • Dispositivos de almacenamiento de terceros de Azure Marketplace (como NetApp y otros)

El cliente debe seleccionar las tecnologías de servidor de archivos que mejor satisfagan sus requisitos empresariales. En la tabla siguiente se describen algunas ventajas y consideraciones para cada una de las diferentes tecnologías de servidor de archivos.

Opciones Ventajas Consideraciones
Servidor de archivos independiente Bien conocido y probado. Compatible con productos en reserva/restauración existentes Punto único de fallo. Sin redundancia de datos. Parche mensual, medido en minutos.
Servidores de archivos con Réplica de almacenamiento Replicación a nivel de bloque SMB 3.0. Independiente del almacenamiento (SAN, nube, local, etc.). Ofrece replicación sincrónica y asincrónica. Se recomienda cuando se requiere acceso a varias regiones Se necesita conmutación por error manual. Utiliza el doble de espacio en disco. La conmutación por error manual sigue teniendo tiempo de inactividad, medido en minutos. Dependencia DNS.
SOFS en Storage Spaces Direct Altamente disponible. Alta disponibilidad de múltiples nodos y discos. Realice una ampliación vertical o una horizontal. SMB 3.0 y 3.1. Conmutación por error transparente durante actividades de mantenimiento planificadas y no planificadas. Recomendado para el almacenamiento de perfiles de usuario en Azure Utiliza 2 a 3 veces espacio en disco. El mantenimiento de software de reserva de terceros puede ser limitado por el proveedor. No es compatible con la implementación en varias regiones
Sistema de archivos distribuido â Replicación Tecnología comprobada para la replicación basada en archivos. Compatible con PowerShell Basado en dominios. No se puede implementar en una configuración activa-activa.
Aplicaciones de almacenamiento de terceros Tecnologías de desduplicación. Mejor uso del espacio de almacenamiento. Coste extra. Herramientas de gestión propias.

Los tipos de máquinas virtuales de servidor de archivos recomendados suelen ser DS1, DS2, DS3, DS4 o DS5, con la selección adecuada según los requisitos de uso del cliente. Para obtener el mejor rendimiento, asegúrese de que se selecciona la compatibilidad con discos premium. Puede encontrar orientación adicional en la documentaciónde Microsoft Azure.

Administración de costes de infraestructura

Hay dos tecnologías disponibles que se pueden usar para reducir los costes del entorno Citrix en Azure, las instancias reservadas y Citrix Autoscale.

Instancias reservadas

Las instancias reservadas de máquinas virtuales (RI) de Azure reducen significativamente los costos (hasta un 72 por ciento en comparación con los precios de pago por uso) con plazos de uno o tres años en las máquinas virtuales (VM) de Windows y Linux. Cuando los clientes combinan los ahorros de costes obtenidos con las IR de Azure con el valor agregado de la Ventaja híbrida de Azure, pueden ahorrar hasta un 80 por ciento. El 80% se calcula en función de un compromiso de instancia reservada de Azure de tres años de Windows Server en comparación con la tarifa normal de pago por uso.

Si bien las instancias reservadas de Azure requieren compromisos iniciales sobre la capacidad informática, también ofrecen flexibilidad para intercambiar o cancelar instancias reservadas en cualquier momento. Una reserva solo cubre los costes de cómputos de máquina virtual. No reduce ninguno de los cargos adicionales de software, redes o almacenamiento. Esto es bueno para la infraestructura de Citrix y la capacidad mínima necesaria para un caso de uso (horas de encendido y apagado).

La función Citrix Autoscale admite instancias reservadas, así como para reducir aún más los costes. Ahora puede utilizar la escala automática para ráfagas en la nube. En un grupo de entrega, puede etiquetar las máquinas que deben escalarse automáticamente y excluir las instancias reservadas (o las cargas de trabajo locales). Puede encontrar más información aquí: Restringir la escalabilidad automática a ciertas máquinas de un grupo de entrega.

Citrix Autoscale

Autoscale es una función exclusiva de Citrix DaaS que proporciona una solución coherente y de alto rendimiento para administrar la energía de forma proactiva de sus máquinas. Su objetivo es equilibrar los costes y la experiencia de usuario. Autoscale incorpora la antigua tecnología Smart Scale en la solución de administración de energía de Studio.

Tipo de máquina Basado en programación Basado en carga Basado en carga y programación
Máquinas con SO de servidor que alojan aplicaciones publicadas o escritorios compartidos alojados (VDI de servidor) Se admite Se admite Se admite
Máquinas con SO de escritorio que alojan escritorios VDI persistentes estáticos (dedicados) Se admite. Durante los períodos en que las máquinas están apagadas (por ejemplo, después de las horas de trabajo), los usuarios pueden activar las máquinas para que se encienda a través de Citrix Receiver. Puede configurar el retardo de apagado de Autoscale para que Autoscale no apague automáticamente las máquinas antes de que el usuario pueda establecer una sesión. Se admite solo para máquinas sin asignar. Se admite solo para máquinas sin asignar.
SO de escritorio: Alojamiento de máquinas: Escritorios VDI aleatorios no persistentes (escritorios VDI agrupados) Se admite Se admite. Utilice la métrica de escalado Session Count y establezca el número máximo de sesiones en 1. Se admite. Utilice la métrica de escala de recuento de sesiones y establezca el número mínimo de máquinas en 1.

Azure-RA-Image-4

Diagrama 4: Flujo de escala automática de Citrix

Puede leer más sobre Citrix Autoscale aquí.

Optimización de la experiencia del usuario final

La optimización de la experiencia del usuario final incluye equilibrar la percepción del usuario final sobre la capacidad de respuesta con las necesidades empresariales de mantenerse dentro de un presupuesto. En esta sección se analizan los conceptos de diseño y las decisiones en torno a proporcionar un entorno que tenga el tamaño correcto para el negocio y el usuario final.

Definición del espacio de trabajo del usuario

Revise las siguientes preguntas de alto nivel para comprender mejor los casos de uso existentes y los recursos necesarios para sus usuarios finales.

Temática Pregunta
La cantidad de usuarios ¿Cuántos usuarios se esperan en el entorno? ¿La fase de evaluación determinó el modelo de VDI adecuado? (Aplicaciones virtuales o escritorios virtuales)
Casos de uso ¿Qué tipos de aplicaciones consumirán los usuarios finales? ¿Cuáles son los requisitos de los VDA para las aplicaciones? ¿Cómo se entregarán mejor las solicitudes? (Aplicaciones virtuales frente a escritorios virtuales)
Horario de trabajo del grupo de usuarios ¿Cuándo accederán los usuarios al entorno? ¿Cuáles son las horas pico? ¿Cuál es el consumo previsto a lo largo del día? (El consumo de usuarios durante horas específicas ayuda a identificar los requisitos del espacio de trabajo para la automatización de escalado y la compra de instancias reservadas de Azure)
Ubicación ¿Dónde se encuentran los usuarios finales? ¿Los espacios de trabajo deben implementarse en varias regiones o solo en una sola región?
Datos de usuario y aplicación ¿Dónde se almacenan los datos del usuario y de la aplicación? ¿Los datos se incluirán únicamente en Azure, solo en las instalaciones o en una combinación de ambos? ¿Cuál es la latencia máxima tolerable para acceder a los datos del usuario?

Tipos de instancia de VM de Azure

Cada componente de Citrix utiliza un tipo de máquina virtual asociado en Azure. Cada serie de VM disponible se asigna a una categoría específica de cargas de trabajo (propósito general, optimizado para el cálculo, etc.) con varios tamaños que controlan los recursos asignados a la VM (CPU, Memoria, IOPS, red, etc.).

La mayoría de las implementaciones de Citrix utilizan los tipos de instancia de la serie D y la serie F. La serie D se utiliza comúnmente para los componentes de infraestructura de Citrix y, a veces, para las cargas de trabajo del usuario cuando requieren memoria adicional más allá de lo que se encuentra en los tipos de instancias de la serie F. Los tipos de instancia de la serie F son los más comunes en el campo para las cargas de trabajo de los usuarios debido a sus procesadores más rápidos que traen consigo la percepción de la capacidad de respuesta.

¿Por qué Serie D o Serie F? Desde la perspectiva de Citrix, la mayoría de los componentes de infraestructura (Cloud Connectors, StoreFront, ADC, etc.) utilizan la CPU para ejecutar los procesos principales. Estos tipos de máquinas virtuales tienen una proporción equilibrada entre CPU y memoria, están alojados en hardware uniforme (a diferencia de la serie A) para un rendimiento más consistente y soporte de almacenamiento premium. Ciertamente, los clientes pueden y deben ajustar sus tipos de instancia para satisfacer sus necesidades y su presupuesto.

El tamaño y la cantidad de componentes de la infraestructura de un cliente siempre dependerán de los requisitos, la escala y las cargas de trabajo del cliente. Sin embargo, con Azure tenemos la capacidad de escalar dinámicamente y a la carta. Para los clientes preocupados por los costes, el mejor enfoque es empezar con algo más pequeño y ampliarlo. Las máquinas virtuales de Azure requieren un reinicio al cambiar el tamaño, por lo que planifique estos eventos solo dentro de las ventanas de mantenimiento programadas y bajo las directivas de control de cambios establecidas.

¿Qué tal Scale-Up o Scale-Out?

Se deben revisar las siguientes preguntas de alto nivel para comprender mejor el caso de uso de un cliente y los recursos que necesitan sus usuarios finales. Esto también les ayuda a planificar su carga de trabajo con suficiente antelación.

La ampliación es mejor cuando el coste por usuario y hora debe ser el más bajo y se puede tolerar un impacto mayor en caso de que la instancia falle. Se prefiere el escalamiento horizontal cuando es necesario minimizar el impacto de una falla de una sola instancia. La siguiente tabla proporciona algunos tipos de instancias de ejemplo para diferentes componentes de Citrix.

Componente Tipo de instancia recomendado
Delivery Controllers, conectores de DS2_v2 o DS2_v3 estándar con almacenamiento SSD premium
Escale las cargas de trabajo de los usuarios Se identificó que las VM Standard_F16s_v2 con Virtual App tienen el coste $/ usuario/hora más bajo en comparación con otras instancias. Las máquinas virtuales Standard_DS5_v2 también eran competitivas en costes en comparación con otras instancias
Escalamiento horizontal de cargas de trabajo de usuarios Las instancias Standard_F4_v2 y Standard_F8_v2 admiten un menor número de usuarios, pero ofrecen más flexibilidad en las operaciones de administración de energía debido a que los contenedores de usuarios son más pequeños. Esto permite que las máquinas se desasignen de manera más eficaz para ahorrar costes en instancias de pago por uso. Además, los dominios de fallas son más pequeños cuando se escala de manera horizontal.
Cargas de trabajo de los usuarios Standard_F2_v2 tiene el coste de doble núcleo más bajo y funciona bien con Windows 10.

El último estudio de tipo de instancia se realizó para proporcionar una gran visión en esta área y recomendamos encarecidamente la lectura. En todos los casos, los clientes deben evaluar los tipos de instancia con sus cargas de trabajo.

Para cargas de trabajo con uso intensivo de gráficos, considere las máquinas virtuales de la serie NVv4. Están equipados con procesadores AMD EPYC 7002 y la GPU Radeon MI25 virtualizada. Estas máquinas virtuales están optimizadas y diseñadas para VDI y visualización remota. Con las GPU particionadas, NVv4 ofrece el tamaño adecuado para cargas de trabajo que requieren recursos de GPU más pequeños al precio más óptimo. Alternativa, la serie NVv3 está optimizada y diseñada para casos de visualización remota, streaming, juegos, codificación y VDI mediante marcos como OpenGL y DirectX. Estas máquinas virtuales cuentan con la GPU NVIDIA Tesla M60. Para ver más opciones de GPU, consulte las demás ofertas de Azure.

Si bien el escalado suele ser el modelo preferido para reducir el coste, Autoscale puede beneficiarse de instancias más pequeñas (de 15 a 20 sesiones por host). Las instancias más pequeñas alojan menos sesiones de usuario que las de mayor tamaño. Por lo tanto, en el caso de instancias más pequeñas, AutoScale pone a las máquinas en estado de drenaje mucho más rápido porque tarda menos tiempo en cerrar la última sesión de usuario. Como resultado, Autoscale apaga antes las instancias más pequeñas, lo que reduce los costes. Puede obtener más información sobre las consideraciones sobre el tamaño de las instancias para Autoscale en la documentación oficial.

Almacenamiento

Al igual que cualquier otro equipo, las máquinas virtuales de Azure utilizan discos como lugar para almacenar un sistema operativo, aplicaciones y datos. Todas las máquinas virtuales de Azure tienen al menos dos discos: un disco del sistema operativo Windows y un disco temporal. El disco del sistema operativo se crea a partir de una imagen y tanto el disco del sistema operativo como la imagen se almacenan en Azure como discos duros virtuales (VHD). Las máquinas virtuales también pueden tener discos adicionales conectados como discos de datos, también almacenados como VHDs.

Los discos de Azure están diseñados para ofrecer durabilidad de nivel empresarial. Existen tres niveles de rendimiento para el almacenamiento que se pueden seleccionar al crear discos: discos SSD premium, SSD estándar y almacenamiento HDD estándar, y los discos pueden estar administrados o no administrados. Los discos administrados son los predeterminados y no están sujetos a las limitaciones de la cuenta de almacenamiento, como los discos no administrados.

Microsoft recomienda Discos administrados sobre el disco no administrado. Los discos no administrados solo deben considerarse por excepción. El almacenamiento estándar (HDD y SSD) incluye los costes de transacción (E/S de almacenamiento) que deben tenerse en cuenta, pero tienen costes por disco más bajos. Almacenamiento Premium no tiene costes de transacción, pero tiene costes por disco más altos y ofrece una experiencia de usuario mejorada.

Los discos no ofrecen SLA a menos que se utilice un conjunto de disponibilidad. Los conjuntos de disponibilidad no son compatibles con Citrix MCS, pero deben incluirse con Citrix Cloud Connector, ADC y StoreFront.

Identidad

La sección se centra en los controles de identidad, la planificación del usuario del espacio de trabajo y la experiencia del usuario final. La consideración principal del diseño es administrar identidades en los arrendatarios de Azure y Citrix Cloud.

Microsoft Azure Active Directory (Azure AD) es una solución en la nube de administración de acceso e identidad que proporciona servicios de directorio, gobierno de identidades y administración de acceso a aplicaciones. Un único directorio de Azure AD se asocia automáticamente a una suscripción de Azure cuando se crea.

Cada suscripción a Azure tiene una relación de confianza con un directorio de Azure AD para autenticar usuarios, servicios y dispositivos. Varias suscripciones pueden confiar en el mismo directorio de Azure AD, pero una suscripción solo confía en un solo directorio de Azure AD.

Las soluciones de identidad de Microsoft abarcan capacidades locales y basadas en la nube, y crean una identidad de usuario única para la autenticación y la autorización de todos los recursos, independientemente de su ubicación. Este concepto se conoce como identidad híbrida. Existen diferentes opciones de diseño y configuración para la identidad híbrida que utilizan soluciones de Microsoft y, en algunos casos, puede resultar difícil determinar qué combinación satisfará mejor las necesidades de una organización.

Consideraciones comunes de diseño de identidad

Por lo general, la extensión del sitio de Active Directory del cliente a Azure utiliza el uso de la replicación de Active Directory para proporcionar identidad y autenticación con Citrix Workspace. Un paso común es usar AD Connect para replicar el usuario en Azure Active Directory, lo que le proporciona la activación basada en suscripción necesaria para Windows 10.

Se recomienda extender los servicios locales de dominio de Active Directory a la subred de red virtual de Azure para obtener funciones y extensibilidad completas. El control de acceso basado en roles (RBAC) de Azure ayuda a ofrecer la administración precisa de accesos para los recursos de Azure. Demasiados permisos pueden exponer y dar cuenta a los atacantes. Muy pocos permisos significan que los empleados no pueden realizar su trabajo de manera eficiente. Mediante RBAC, el administrador puede dar a los empleados los permisos exactos que necesitan.

Autenticación

Los servicios de dominio (AD DS o Azure AD DS) son necesarios para la funcionalidad central de Citrix. RBAC es un sistema de autorización creado en Azure Resource Manager que proporciona una administración de acceso minuciosa de los recursos en Azure. RBAC le permite controlar de forma granulada el nivel de acceso que tienen los usuarios. Por ejemplo, puede limitar un usuario para que solo administre redes virtuales y otro usuario para que administre todos los recursos de un grupo de recursos. Azure incluye varias funciones integradas que puede usar.

La autenticación de Azure AD se admite para la autenticación de Citrix Workspace, Citrix DaaS y Citrix ADC/StoreFront. Para obtener SSON completo con Azure AD, se debe usar Citrix Federated Authentication Service (FAS) o Azure AD DS (para los servicios de dominio principales).

Citrix FAS admite Single Sign-On (SSO) en DaaS en Citrix Workspace. Por lo general, se adopta Citrix FAS si utiliza uno de los siguientes proveedores de identidad:

  • Azure Active Directory
  • Okta
  • SAML 2.0
  • Citrix Gateway

Resultados de Active Directory y Azure Active Directory

  • Arrendatario aprovisionado de Azure Active Directory
  • Lista de roles organizativos deseados para Azure RBAC con asignación a roles de Azure personalizados o integrados
  • Lista de niveles de acceso de administrador deseados (cuenta, suscripción, grupo de recursos, etc.)
  • Procedimiento para conceder acceso/rol a nuevos usuarios para Azure
  • Procedimiento para asignar elevación JIT (justo a tiempo) a los usuarios para tareas específicas

A continuación se muestra un ejemplo de arquitectura de diseño de espacio de nombres y flujo de autenticación.

Azure-RA-Image-5

Diagrama 5: Arquitectura del diseño del espacio de nombres y el flujo de autenticación

Administración de Citrix Cloud + Azure AD

De forma predeterminada, Citrix Cloud usa el proveedor de identidades de Citrix para administrar la información de identidad de todos los usuarios que acceden a Citrix Cloud. Los clientes pueden cambiarlo para usar Azure Active Directory (AD) en su lugar. Al usar Azure AD con Citrix Cloud, los clientes pueden:

  • Use su propio Active Directory, de modo que puedan controlar las auditorías, las directivas de contraseñas y inhabilitar cuentas fácilmente cuando sea necesario.
  • Configurar la autenticación de varios factores para conseguir un mayor nivel de seguridad frente a la posibilidad de robo de credenciales de inicio de sesión.
  • Usar una página de inicio de sesión personalizada con su propia marca, de forma que los usuarios sepan que están entrando en el sitio correcto.
  • Usar la federación con el proveedor de identidades que usted prefiera, incluidos ADFS, Okta y Ping, entre otros.

Citrix Cloud incluye una aplicación de Azure AD que permite a Citrix Cloud conectarse con Azure AD sin necesidad de iniciar sesión en una sesión activa de Azure AD. El inicio de sesión de Citrix Cloud Administrator permite que las identidades de Azure AD se utilicen en el arrendatario de Citrix Cloud de los clientes.

  • Determine si los administradores de Citrix Cloud utilizan Citrix Identity o Azure AD para acceder a Citrix Cloud, la URL seguirá el formato https://citrix.cloud.com/go/{Customer Determined}
  • Identificar la URL de autenticación para la autenticación de Azure AD en Citrix Cloud

Gobernanza

Azure Governance es una colección de conceptos y servicios diseñados para habilitar la administración de los diversos recursos de Azure a escala. Estos servicios proporcionan la capacidad de organizar y estructurar sus suscripciones de forma lógica, para crear, implementar y reutilizables paquetes nativos de recursos de Azure. Este tema se centra en establecer las directivas, los procesos y los procedimientos asociados con la planificación, la arquitectura, la adquisición, la implementación, el funcionamiento y la administración de recursos de Azure.

Inicio de sesión de Citrix Cloud Administrator

Determine si los administradores de Citrix Cloud usan su Citrix Identity, Active Directory Identity o Azure AD para acceder a Citrix Cloud. La integración de Azure AD permite la autenticación multifactor en Citrix Cloud para los administradores. Identifique la URL de autenticación para la autenticación de Azure AD en Citrix Cloud. La URL sigue el formato https://citrix.cloud.com/go/{Customer Determined}.

Delegación y permisos de RBAC

Con Azure AD, los clientes pueden implementar sus directivas de gobierno mediante el Control de acceso basado en roles (RBAC) de los recursos de Azure. Una de las herramientas principales para la aplicación de estos permisos es el concepto de grupo de recursos. Piense en un grupo de recursos como un paquete de recursos de Azure que comparten el ciclo de vida y la propiedad administrativa.

En el contexto de un entorno Citrix, estos deben organizarse de manera que permitan una delegación adecuada entre los equipos y promuevan el concepto de menor privilegio. Un buen ejemplo es cuando una implementación de Citrix Cloud utiliza un Citrix ADC VPX aprovisionado desde Azure Marketplace para acceso externo. Aunque es una pieza central de la infraestructura de Citrix, los ADC de Citrix pueden tener un ciclo de actualización independiente, un conjunto de administradores, etc. Esto exigir la separación de los ADC de Citrix de los demás componentes de Citrix en grupos de recursos independientes para que los permisos de Azure RBAC se puedan aplicar a través de las zonas administrativas. del arrendatario, la suscripción y los recursos.

Principal de servicio de MCS

Para tener acceso a los recursos protegidos por un arrendatario de Azure AD, la entidad que requiere acceso debe estar representada por una entidad de seguridad. Esto se aplica tanto a los usuarios (principal de usuario) como a las aplicaciones (entidad de servicio). La entidad de seguridad define la directiva de acceso y los permisos para el usuario/aplicación en el arrendatario de Azure AD. Esto habilita funciones básicas como la autenticación del usuario/aplicación durante el inicio de sesión y la autorización durante el acceso a los recursos.

Determine los permisos asignados a la entidad de servicio utilizada por el servicio Citrix MCS.

Los principales de servicio del ámbito de la suscripción tienen derechos de Colaborador para la suscripción correspondiente que utiliza el entorno Citrix. Los principales de servicio de alcance limitado tienen un RBAC granular aplicado a los grupos de recursos que contienen la red, las imágenes maestras y los VDA. Se recomienda que los principales del servicio de ámbito estrecho limiten los permisos solo a los permisos requeridos por el servicio. Esto se adhiere al concepto de seguridad de “menos privilegio”.

Etiquetado

El cliente aplica etiquetas a sus recursos de Azure y proporciona metadatos para organizarlos de forma lógica en una taxonomía. Cada etiqueta consta de un par de nombre y valor. Por ejemplo, pueden aplicar el nombre “Entorno” y el valor “Producción” a todos los recursos en producción.

El cliente puede recuperar todos los recursos de su suscripción con ese nombre y valor de etiqueta. Las etiquetas les permiten recuperar recursos relacionados de diferentes grupos de recursos. Este enfoque es útil cuando el administrador necesita organizar los recursos para la facturación o la administración.

Hay un límite de 15 etiquetas por recurso. Citrix MCS crea 2 etiquetas por máquina virtual, por lo que un cliente tiene un límite de 13 etiquetas para las máquinas MCS. Las máquinas MCS no persistentes se eliminan durante el reinicio. Esto elimina las funciones específicas de Azure VM, como etiquetas, diagnósticos de arranque Si se requieren etiquetas, se recomienda crear una directiva de Azure Append y aplicarla a los grupos de recursos de MCS aplicables.

Directiva de Azure

Las directivas de Azure pueden controlar aspectos como el etiquetado, los SKU permitidos, el cifrado, la región de Azure y la convención de nombres. Hay directivas predeterminadas disponibles y la capacidad de aplicar directivas personalizadas. Las directivas de Azure se pueden aplicar a nivel de suscripción o de grupo de recursos. Se pueden definir varias directivas. Las directivas aplicadas a nivel de grupo de recursos tienen prioridad sobre la directiva de nivel de suscripción.

Identifique los aspectos de Azure que deben controlarse y estandarizarse en todo el entorno Citrix. La cuota dura obliga a la directiva y no permite excepciones. Auditorías de cuotas flexibles para la aplicación de directivas y notificar si no se cumple la directiva. Consulte la documentación de Azure para obtener información más detallada para definir las directivas.

Azure-RA-Image-6

Diagrama 6: Directiva de acceso de Azure Governance y RBAC

Seguridad

La seguridad está integrada en todos los aspectos de Azure. Azure ofrece ventajas de seguridad únicas derivadas de la inteligencia de seguridad global, controles sofisticados orientados al cliente y una infraestructura reforzada y segura. Esta potente combinación ayuda a proteger las aplicaciones y los datos, contribuye a los esfuerzos de cumplimiento de normas y proporciona seguridad rentable para organizaciones de todos los tamaños.

Asegurar el aprovisionamiento de cuentas de almacenamiento mediante el servicio CVAD

Como se ha indicado anteriormente, MCS es el servicio (dentro de CVAD) responsable de hacer girar las máquinas en la suscripción del cliente. MCS utiliza una identidad AAD: el principal del servicio de aplicaciones para acceder a los grupos de recursos de Azure y realizar diferentes acciones. Para el tipo de recursos de cuenta de almacenamiento, MCS requiere el permiso listkeys para adquirir la clave cuando sea necesario para diferentes acciones (escritura/lectura/eliminación). Según nuestra implementación actual, un requisito de MCS para:

  • La red de la cuenta de almacenamiento es el acceso desde Internet público.
  • Cuenta de almacenamiento RBAC tiene permiso listkeys

Para algunas organizaciones mantener el dispositivo de punto final de la cuenta de almacenamiento público es una preocupación. A continuación se muestra un análisis de los activos creados y almacenados al implementar máquinas virtuales con disco administrado (el comportamiento predeterminado).

  • Almacenamiento de tablas: Mantenemos la configuración de la máquina y los datos de estado en el almacenamiento de tablas en la cuenta de almacenamiento principal (o una secundaria, si la principal se está utilizando para discos Premium) para el catálogo. No hay información confidencial en las tablas.
  • Bloqueos: para ciertas operaciones (asignación de máquinas a cuentas de almacenamiento, replicación de discos), utilizamos un objeto de bloqueo para sincronizar operaciones de múltiples instancias de plug-in. Esos archivos son blobs vacíos y no incluyen datos confidenciales.

Para catálogos de máquinas creados antes del 15 de octubre de 2020, MCS crea una cuenta de almacenamiento adicional para discos de identidad:

  • Importación de disco: Al importar discos (identidad, instrucción), cargamos el disco como un blob de página. A continuación, creamos un disco administrado a partir del blob de página y eliminamos el blob de página. Los datos transitorios incluyen datos confidenciales para nombres de objetos de equipo y contraseña. Esto no se aplica a todos los catálogos de máquinas creados después del 15 de octubre de 2020.

Se recomienda utilizar una entidad de servicio de ámbito restringido aplicada a grupos de recursos específicos para limitar los permisos solo a los permisos requeridos por el servicio. Esto se adhiere al concepto de seguridad de “menos privilegio”. Consulte CTX219243 y CTX224110 para obtener más información.

IaaS - Supervisión del Centro de seguridad de Azure

Azure Security Center analiza el estado de la seguridad de los recursos de Azure. Cuando el Centro de seguridad identifica posibles vulnerabilidades de seguridad, crea recomendaciones que guían al cliente a través del proceso de configuración de los controles necesarios. Las recomendaciones se aplican a los tipos de recursos de Azure: máquinas virtuales (VM) y equipos, aplicaciones, redes, SQL e Identity and Access. Hay algunas prácticas recomendadas que debe seguir:

  • Controle el acceso a las VM y proteja el acceso
  • Aprovisionamiento de antimalware para ayudar a identificar y eliminar software malintencionado.
  • Integre su solución de antimalware con el Centro de seguridad para supervisar el estado de su protección.
  • Mantenga sus máquinas virtuales actualizadas y asegúrese de que en la implementación las imágenes creadas incluyen la ronda más reciente de Windows y actualizaciones de seguridad.
  • Reimplemente periódicamente las máquinas virtuales para forzar una versión nueva del sistema operativo.
  • Configurar reglas y grupos de seguridad de red para controlar el tráfico a las máquinas virtuales.
  • Aprovisionamiento de firewalls de aplicaciones web para ayudar a defenderse de los ataques dirigidos a sus aplicaciones web.
  • Abordar configuraciones de SO que no coinciden con las líneas base recomendadas.

Diseño de redes

La seguridad de la red se puede definir como el proceso de protección de los recursos contra ataques o accesos no autorizados mediante la aplicación de controles al tráfico de la red. El objetivo es garantizar que solo se permita el tráfico legítimo. Azure incluye una infraestructura de red sólida para complementar sus requisitos de conectividad de aplicaciones y servicios. La conectividad de red es posible entre los recursos ubicados en Azure, entre los recursos locales y los alojados en Azure, y hacia y desde Internet y Azure.

Segmentación de redes virtuales

Las redes virtuales de Azure son similares a una LAN en la red local. La idea detrás de una red virtual de Azure es crear una red única basada en un espacio de direcciones IP privadas en la que los clientes puedan colocar todas sus máquinas virtuales de Azure. La práctica recomendada es segmentar el espacio de direcciones más grande en subredes y crear controles de acceso a la red entre subredes. El enrutamiento entre subredes se realiza automáticamente y no es necesario configurar manualmente las tablas de enrutamiento.

Utilice un grupo de seguridad de red (NSG). Los NSG son dispositivos simples de inspección de paquetes con estado que utilizan el enfoque de 5 tuplas (la IP de origen, el puerto de origen, la IP de destino, el puerto de destino y el protocolo de capa 4) para crear reglas de permitir/denegar para el tráfico de red. Las reglas permiten o deniegan el tráfico hacia y desde una única dirección IP, hacia y desde varias direcciones IP, o hacia y desde subredes enteras.

Los clientes pueden crear rutas personalizadas o definidas por el usuario denominadas Rutas definidas por el usuario (UDR) en Azure para anular las rutas predeterminadas del sistema de Azure o para agregar rutas adicionales a la tabla de rutas de una subred. En Azure, los administradores pueden crear una tabla de rutas y, a continuación, asociar la tabla de rutas a cero o más subredes de red virtuales. Cada subred puede tener cero o una tabla de redirección asociada a ella.

Los NSG y los UDR se aplican a nivel de subred dentro de una red virtual. Al diseñar una red virtual Citrix en Azure, se recomienda diseñar la red virtual teniendo esto en cuenta, creando subredes para componentes similares, permitiendo la aplicación granular de NSG y UDR según sea necesario. Un ejemplo de esto sería segmentar la infraestructura de Citrix en su propia subred, con una subred correspondiente para cada caso de uso.

Identifique los puertos y protocolos necesarios para Citrix y las tecnologías de soporte. Revise para verificar que estos puertos estén permitidos dentro de los grupos de seguridad de red utilizados en el entorno. Los grupos de seguridad de red pueden limitar las comunicaciones entrantes y salientes a un conjunto definido de IP, redes virtuales, etiquetas de servicio o grupos de seguridad de aplicaciones.

Azure-RA-Image-7

Diagrama 7: Centro de seguridad de Azure y seguridad de red mediante NSG y ASG

Conectividad

La conexión de las redes virtuales de Azure con la red local o en la nube de los clientes se denomina redes híbridas. En esta sección se explican las opciones de conectividad de red y redirección de servicios de red. Los clientes pueden conectar sus equipos y redes locales a una red virtual mediante cualquier combinación de las siguientes opciones:

  • Red privada virtual (VPN) punto a sitio: se establece entre una red virtual y un solo equipo en la red del cliente. Cada equipo que quiera establecer conectividad con una red virtual debe configurar su conexión. Este tipo de conexión es ideal para empezar con Azure o para desarrolladores, ya que requiere poco o ningún cambio en la red existente del cliente. La comunicación entre su equipo y una red virtual se envía a través de un túnel cifrado a través de Internet.
  • VPN de sitio a sitio: establecido entre un dispositivo VPN local y una puerta de enlace VPN de Azure que se implementa en una red virtual. Este tipo de conexión habilita cualquier recurso local que el cliente autorice para acceder a una red virtual. La comunicación entre el dispositivo VPN local y una Gateway VPN de Azure se envía a través de un túnel cifrado a través de Internet.
  • Azure ExpressRoute: se establece entre la red del cliente y Azure, a través de un socio de ExpressRoute. Esta conexión es privada. El tráfico no pasa por Internet.

Las principales consideraciones para la conectividad de Azure a cliente son el ancho de banda, la latencia, la seguridad y el coste. Las VPN de sitio a sitio tienen límites de ancho de banda más bajos que Express Route y dependen del rendimiento del router perimetral utilizado por el cliente. Los SLA están disponibles en las SKU de la puerta de enlace VPN. Las VPN de sitio a sitio utilizan IPSec a través de Internet.

Las rutas expresas son conexiones privadas dedicadas y no a través de Internet. Esto da como resultado una menor latencia cuando se usa Express Route. Además, Express Route puede escalar hasta 10 Gbps. Express Route se configura mediante un partner certificado. Estos proveedores deben tener en cuenta el tiempo de configuración durante la planificación del proyecto. Los costes de Express Route tienen un componente de Microsoft y un componente de proveedor de Express Route.

Normalmente, estas conexiones se comparten entre varios servicios (replicación de bases de datos, tráfico de dominio, tráfico de aplicaciones, etc.) En una implementación de nube híbrida puede haber casos en los que los usuarios internos requieren su tráfico ICA para pasar por esta conexión para acceder a sus aplicaciones Citrix en Azure, por lo tanto supervisar su ancho de banda es fundamental.

Con el ADC y el StoreFront tradicional, también se puede utilizar el enrutamiento de puerta de enlace óptimo para dirigir la conexión de un usuario a un ADC mediante el ISP de una oficina, en lugar de la ruta exprés o la VPN a Azure.

Rutas definidas por el usuario (UDR)

Normalmente, los clientes usan una UDR para redirigir el tráfico de Azure a un dispositivo de firewall dentro de Azure o una red virtual específica. Por ejemplo, tráfico Norte/Sur desde un VDA a Internet. Si se redirigen grandes cantidades de tráfico a dispositivos de firewall de terceros dentro de Azure, esto puede crear un cuello de botella de recursos o un riesgo de disponibilidad si estos dispositivos no tienen el tamaño o la configuración adecuada. Los NSG se pueden utilizar para complementar firewalls de terceros y deben utilizarse en la medida de lo posible cuando corresponda. Piense en Azure Network Watcher si se necesita introspección de tráfico.

Emparejamiento de redes virtuales

El emparejamiento de redes virtuales conecta sin problemas dos redes virtuales de Azure. Una vez emparejadas, las redes virtuales aparecen como una sola, por motivos de conectividad. El tráfico entre máquinas virtuales de las redes virtuales interconectadas se redirige a través de la infraestructura troncal de Microsoft, al igual que el tráfico se redirige entre máquinas virtuales de la misma red virtual, a través de direcciones IP privadas únicamente.

Azure admite:

  • Emparejamiento de redes virtuales: Conexión de redes virtuales dentro de la misma región de Azure
  • Emparejamiento global de redes virtuales: Conexión de redes virtuales en todas las regiones de Azure

Los clientes que implementen cargas de trabajo en varias redes virtuales deben considerar utilizar el emparejamiento de redes virtuales para habilitar la comunicación entre máquinas virtuales entre redes virtuales.

Azure-RA-Image-8

Diagrama 8: Conectividad y rutas del centro de datos

SD-WAN

La tecnología WAN definida por software (SD-WAN) permite ofrecer una gran experiencia de usuario, incluso en conexiones difíciles. Se adapta perfectamente a la entrega de aplicaciones y escritorios virtuales.

  • Agrega todo el ancho de banda disponible en una conexión activa/activa, proporcionando más ancho de banda.
  • Utilice la exclusiva tecnología HDX Quality of Experience para optimizar el rendimiento y ajustar las directivas de red.
  • Garantice conexiones siempre activas para los usuarios de aplicaciones virtuales y escritorios con una experiencia de la mejor calidad posible, incluso para contenido multimedia enriquecido y vídeo de alta definición.

Los clientes que utilizan VPN pueden usar SD-WAN para agregar redundancia a Azure y la conectividad del centro de datos del cliente o para proporcionar redirección específica de la aplicación. Citrix SD-WAN redirige automáticamente el tráfico a través de cualquier conexión disponible. De hecho, la experiencia es tan fluida que los usuarios ni siquiera se darán cuenta de que se ha producido algún cambio. Su dirección IP de acceso principal permanece sin cambios, lo que permite a los usuarios acceder a sus aplicaciones y datos mediante los mismos métodos y dispositivos.

Citrix ADC

Citrix ADC en Microsoft Azure garantiza que las organizaciones tengan acceso a aplicaciones y activos seguros y optimizados implementados en la nube y proporciona la flexibilidad para establecer una base de red que se ajuste a las necesidades cambiantes de un entorno. En caso de que se produzca una falla en el centro de datos, Citrix ADC redirige automáticamente el tráfico de los usuarios a un sitio secundario, sin interrupciones para los usuarios. El equilibrio de carga y el equilibrio de carga de servidores globales en varios centros de datos garantizan aún más el estado, las capacidades y la utilización óptimas del servidor.

Hable con el cliente y defina el siguiente caso de uso para cada ubicación de recursos:

Método Access Consideraciones
Solo interno No se requiere un Citrix ADC si solo se necesita acceso interno.
Acceso externo a través del servicio Citrix ADC Gateway. El servicio Citrix Cloud ADC Gateway proporciona el proxy ICA (solo conectividad remota segura).
Acceso externo a través de Citrix ADC VPX implementado en Azure Resource Location Un cliente debe considerar un dispositivo Citrix ADC VPX en Azure si necesita lo siguiente: 1. Autenticación multifactor con SSON 2 completo. Análisis de dispositivos de punto final 3. Directivas avanzadas de autenticación o autenticación previa 4. Directivas de Citrix SmartAccess. Nota: Estos requisitos indican la necesidad de autenticación en Citrix ADC en lugar del servicio Experiencia de espacio de trabajo. StoreFront es necesario si la autenticación es administrada por un servidor virtual de Citrix ADC Gateway.

Citrix ADC: Modelo de implementación

Las implementaciones activo-activas utilizan nodos de Citrix ADC independientes que se pueden escalar horizontalmente mediante Azure Load Balancer. Los pares activo-pasivo facilitan la conmutación por error con estado del tráfico ICA en caso de fallo de nodo, sin embargo, están limitados a la capacidad de un único VPX. Los nodos activo-pasivo también requieren Azure Load Balancer.

Se recomiendan varias NIC para aislar el tráfico SNIP, NSIP y VIP para maximizar el rendimiento disponible para Citrix ADC Gateway u otros servicios.

Fuentes

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

Referencias

Operaciones

Identidad

Gobernanza

Seguridad

Monitor Azure

Conectividad

Arquitectura de referencia: Citrix DaaS - Azure
May 12, 2023
Author:  Loay Shbeilat
Special thanks:  Nitin Mehta
May 12, 2023
Author:  Loay Shbeilat
Special thanks:  Nitin Mehta

En este artículo

Comentarios sobre el sitio | Condiciones legales y de privacidad | Preferencias de cookies | Parámetros de consentimiento | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.