Citrix Virtual Apps and Desktops Service en Azure

Introducción

Esta guía ayuda con el modelo de arquitectura e implementación de los servicios de Citrix Virtual Apps and Desktops 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 de Azure admiten todos los componentes de carga de trabajo y control necesarios para una implementación del servicio Citrix Virtual Apps and Desktops. 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: Operaciones incluye una amplia variedad de temas como administración de imágenes, supervisión de servicios, continuidad del negocio, soporte y otros. Hay varias herramientas disponibles para ayudar con la automatización de las operaciones, como Azure PowerShell, Azure CLI, ARM Templates y Azure API.

  • 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 Servicios de dominio de Azure AD. 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 proporciona una amplia gama de opciones de seguridad configurables y la capacidad de controlarlas para que los clientes puedan personalizar la seguridad para satisfacer los requisitos exclusivos 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 redes virtuales de Azure con la red local o en la nube del cliente se denomina redes híbridas. En esta sección se explican las opciones de conectividad de red y enrutamiento de servicios de red.

Planeando

Los tres casos más comunes para entregar aplicaciones y escritorios Citrix a través de Azure son:

  • Implementación Greenfield con Citrix Cloud que ofrece ubicaciones de recursos en Azure. Este caso se ofrece a través del servicio Citrix Virtual Apps and Desktops y se utiliza 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 quiere agregar Azure como una ubicación de recursos Citrix para nuevas implementaciones o migración.
  • Levanta y cambia. 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 Virtual Apps and Desktops Service

Citrix Cloud Virtual Apps and Desktops Service simplifica la entrega y administración de las tecnologías Citrix, ayudando a los clientes a ampliar las implementaciones de software locales existentes o a trasladar el 100% 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 en 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 (Current Branch for Business) por usuario la opción de ofrecer una experiencia de escritorio virtual de 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 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 guía de diseño sobre la escalabilidad y la economía de la prestación de servicios Citrix Virtual Apps and Desktops 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 Workspace y la jerarquía de los servicios fundacionales. En la capa superior, se encuentran las consideraciones de suscripción, grupo de recursos y diseño regional. Seguido de preguntas comunes sobre el almacenamiento de VM, el almacenamiento de perfiles de usuario y la administración/aprovisionamiento de imágenes maestras. También se proporciona orientación sobre la optimización de instancias reservadas con Autoscale y la planificación de Continuidad del Negocio y 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 después de la creación
  • Los tipos de recursos específicos tienen diferentes requisitos de nomenclatura
  • Las convenciones de nomenclatura coherentes facilitan la localización de los recursos y pueden indicar el rol 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 nombrar 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.
[Papel] 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 recursos en Azure, use 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
Puerta de enlace de red virtual Red virtual [System][Environment]##[Location]-vng WSCD01scu-vng
Puerta de enlace 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 Suscripción [System][Environment]-analytics CTXP-analytics
Etiquetas Recurso [Descriptive Context] Finance
Caja fuerte de llaves Suscripción [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 huella 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 Workspace de suscripción única

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 1.200 VDA de Citrix (puede ser de sesión, VDI agrupado o VDI persistente). Los límites están sujetos a cambios, compruebe lo siguiente para la mayoría límites de VDA actualizados. Consulte lo siguiente blog para obtener los números de escala de inicio y apagado más recientes dentro de una única suscripción,

Diagrama 2: Modelo de Workspace de suscripción única de Azure Azure-RA-Image-2

Modelo de Workspace multisuscripción

En este modelo, la infraestructura principal y la infraestructura Citrix están en suscripciones independientes para administrar la escalabilidad en implementaciones grandes. 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 de Azure y planificar sus recursos.

Componente Requisito
¿La suscripción a Azure solo contendrá recursos Citrix? Determine si la suscripción de Azure se utilizará para recursos dedicados de Citrix o si los recursos de Citrix se compartirán con otros sistemas.
¿Implementación de suscripción única o múltiple? Normalmente, varias implementaciones de suscripción son para implementaciones más grandes en las que las limitaciones de suscripción única son un problema y se necesitan controles de seguridad más granulares.
¿Qué límites de Azure es probable que se alcance? ¿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 Límites de suscripción a Azure mientras planifica la solución.
¿Qué permisos son necesarios para el principio de servicio CVAD en la suscripción de Azure? Citrix Virtual Apps and Desktops requiere crear grupos de recursos y recursos dentro de la suscripción. Por ejemplo, cuando al principio de servicio no se le puede conceder acceso completo a una suscripción, debe concederle acceso 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 suscripciones de desarrollo y prueba de producción permite la aplicación y el cambio de servicios globales de Azure en un entorno aislado y la utilización de recursos de silos. Esta práctica tiene ventajas para la seguridad, el cumplimiento de normas y el rendimiento de las suscripciones. 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 generalmente en 42 regiones de todo el mundo, con planes anunciados para 12 regiones más a partir de noviembre de 2018.

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 físicamente separadas dentro de una región de Azure. Cada zona de disponibilidad está formada por uno o más centros de datos equipados con alimentación independiente, refrigeración y redes. 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 de normas 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. Revise el sitio web mapa de regiones de Azure para conocer las últimas 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 usuarios y los centros de datos de 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 utilizar en Azure para garantizar que los recursos de VM colocados en un conjunto de disponibilidad se aíslan entre sí cuando se implementan en un centro de datos de Azure. Azure garantiza que las máquinas virtuales ubicadas en un conjunto de disponibilidad se ejecuten en varios servidores físicos, racks informáticos, 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 fiables en la nube.

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 VM dentro de los conjuntos de disponibilidad. Esto minimiza o elimina el tiempo de inactividad del servicio cuando Microsoft reinicia o redistribuye las VM. Esto también se puede ampliar a 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 proactivas sobre ellos según la programación del cliente, en lugar de en la programación 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

Eventos programados de Azure es un servicio de metadatos de Azure que proporciona avisos mediante programación a las aplicaciones para alertar de mantenimiento inmediato. Proporciona información sobre los próximos eventos de mantenimiento (por ejemplo, reinicio) para que el administrador de la aplicación pueda prepararse y limitar la interrupción. Aunque podría sonar como mantenimiento planificado, no lo es. La diferencia clave es que estos eventos se activan para el mantenimiento planificado y, a veces, para el mantenimiento no planificado. Por ejemplo, si Azure está realizando actividades de sanación del host y necesita mover máquinas virtuales con un breve aviso.

Estos eventos se consumen programáticamente y darán el siguiente aviso previo:

  • Congelación — 15 Minutos
  • Reinicio: 15 minutos
  • Reimplementación: 10 minutos

Recuperación ante desastres (RAD)

Azure puede proporcionar una solución de recuperación ante desastres altamente rentable para los clientes de Citrix que buscan obtener un valor inmediato gracias a 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

Bajo esta topología, la infraestructura de administración permanece local, 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 en la 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 pasar durante una interrupción antes de que la cantidad de datos perdidos durante ese período supere el umbral máximo permitido o la “tolerancia” del Plan de Continuidad del Negocio.
¿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 forma coherente en entornos de desarrollo, prueba y producción. Al desarrollar un proceso de gestión de imágenes, se debe tener en cuenta lo siguiente:

Aprovisionamiento a la carta

El cliente debe determinar si MCS se utiliza 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 a la carta de Azure, las VM solo se crean cuando Citrix Virtual Apps and Desktops inicia una acción de encendido, una vez que haya finalizado 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 cuentas de almacenamiento

El cliente debe decidir la estructura organizativa para almacenar las imágenes de origen (o doradas) 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 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 en contenedores de almacenamiento de Azure Blob. Los contenedores son carpetas que se pueden usar para separar imágenes de producción, prueba y desarrollo.

Replicación 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 pueden utilizarse 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 utilizar para almacenar datos de usuario de Citrix, información de perfil móvil o funcionar como destinos para 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 información 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 de respaldo/restauración existentes Punto único de falla. 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. Almacenamiento independiente (SAN, Cloud, 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 espacios de almacenamiento directo Alta disponibilidad. Multi-nodo y Multi-disco HA. Escalar hacia arriba o hacia fuera. 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 soporte de software de respaldo 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 replicación basada en archivos. Soporta PowerShell Basado en dominio. No se puede implementar en una configuración activo-activa.
Aplicaciones de almacenamiento de información de terceros Tecnologías de deduplicación. Mejor uso del espacio de almacenamiento. Coste extra. Herramientas de gestión propias.

Por lo general, los tipos de máquina virtual de file server recomendados son DS1, DS2, DS3, DS4 o DS5, con la selección adecuada en función de los requisitos de uso del cliente. Para obtener el mejor rendimiento, asegúrese de que se selecciona la compatibilidad con discos premium. Se puede encontrar información adicional en Microsoft Azure documentación.

Administración de costes de infraestructura

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

Instancias reservadas

Las instancias reservadas de VM (RI) de Azure reducen significativamente los costes (hasta un 72% en comparación con los precios de pago por uso) con términos de un año o tres años en máquinas virtuales (VM) Windows y Linux. Cuando los clientes combinan el ahorro de costes obtenido de las instancias de inversión de Azure con el valor agregado de la ventaja híbrida de Azure, pueden ahorrar hasta un 80%. 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.

Aunque las instancias reservadas de Azure requieren compromisos iniciales sobre la capacidad informática, también proporcionan 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 máquinas que necesitan escalarse automáticamente y excluir las instancias reservadas (o cargas de trabajo locales); puede encontrar más información aquí: Restringir la escala automática a determinadas máquinas de un grupo de entrega.

Citrix Autoscale

Autoscale es una función exclusiva del servicio Citrix Virtual Apps and Desktops que proporciona una solución consistente y de alto rendimiento para administrar de forma proactiva sus máquinas. Su objetivo es equilibrar los costes y la experiencia de usuario. Autoscale incorpora la obsoleta 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 Carga y basada en 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 Autoescala para que la escala automática 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 escala de recuento de sesiones 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 obtener más información 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 de 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

Al planificar una evaluación del usuario, la documentación de Manual y prácticas recomendadas de Citrix VDI proporciona una guía inestimable. 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
Número de usuarios ¿Cuántos usuarios se esperan dentro del entorno? ¿La fase de evaluación determinó el modelo VDI apropiado? (Virtual Apps o Virtual Desktops)
Casos de uso ¿Qué tipos de aplicaciones consumirán los usuarios finales? ¿Cuáles son los requisitos de VDA para las aplicaciones? ¿Cómo se entregarán mejor las aplicaciones? (Virtual Apps frente a Virtual Desktops)
Horas 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 esperado durante todo el día? (El consumo de usuarios durante horas específicas ayuda a identificar los requisitos del Workspace 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 de usuario y aplicación? ¿Los datos se contendrán únicamente en Azure, solo en las instalaciones o 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 el número de componentes dentro de la infraestructura del 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 comenzar con menor tamaño y escalar. 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?

Las siguientes preguntas de alto nivel deben revisarse para comprender mejor el caso de uso de un cliente y los recursos necesarios para 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 escalar horizontalmente cuando se necesita minimizar el impacto de un fallo de instancia única. La tabla siguiente proporciona algunos tipos de instancia de ejemplo para diferentes componentes de Citrix.

Componente Tipo de instancia recomendado
Delivery Controllers, Cloud Connectors DS2_v2 o DS2_v3 estándar con almacenamiento SSD Premium
Escalar cargas de trabajo de usuario de SO de servidor 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 VM Standard_DS5_v2 también eran competitivas en comparación con otras instancias
Escalar las cargas de trabajo de usuario de SO de servidor Las instancias Standard_F4_v2 y Standard_F8_v2 admiten un menor número de usuarios, sin embargo, proporcionan más flexibilidad en las operaciones de administración de energía debido a los tamaños de contenedores de usuarios 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 error son más pequeños al escalar hacia fuera.
Cargas de trabajo de usuario de SO de escritorio 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 su lectura. En todos los casos, los clientes deben evaluar los tipos de instancia con sus cargas de trabajo.

Para cargas de trabajo que requieren un uso intensivo de gráficos, considere las máquinas NVv4-series virtuales. 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 escenarios de visualización remota, streaming, juegos, codificación y VDI mediante marcos como OpenGL y DirectX. Estas máquinas virtuales están respaldadas por la GPU NVIDIA Tesla M60. Para obtener más opciones de GPU, consulte la otra ofertas de Azure.

Aunque la ampliación suele ser un modelo preferido para reducir el coste, la Escala automática 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 instancias más grandes. 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, la función Escala automática apaga las instancias más pequeñas antes, lo que reduce los costes. Puede obtener más información sobre las consideraciones de tamaño de instancia para Autoscale en 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 costes de transacción (E/S de almacenamiento) que deben tenerse en cuenta pero tienen costes más bajos por disco. 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 Workspace 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 identidades y acceso que proporciona servicios de directorio, control 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 de 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, creando una única identidad de usuario para la autenticación y autorización de todos los recursos, independientemente de la 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 ser difícil determinar qué combinación satisfará mejor las necesidades de una organización.

Consideraciones comunes sobre el diseño de identidad

Normalmente, la extensión del sitio de Active Directory de los clientes 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 utilizar AD Connect para replicar usuarios en Azure Active Directory, 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 a un usuario a administrar solo redes virtuales y a otro usuario a administrar todos los recursos de un grupo de recursos. Azure incluye varios roles integrados que puede usar.

Azure AD Authentication es compatible con Workspace Experience Service y con la autenticación Citrix ADC/StoreFront. Para 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 aún no es compatible con Workspace Experience Service, por lo que se requiere StoreFront como parte de la arquitectura de implementación. El servidor Azure MFA (Cloud Service, Azure MFA Server, Azure MFA NPS Extension) puede habilitar el uso de Azure MFA sin necesidad de una directiva SAML y el uso de Citrix FAS para SSON completo. Sin embargo, esta es una máquina virtual de IaaS y debe ser administrada por el cliente.

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 utiliza el proveedor Citrix Identity para administrar la información de identidad de todos los usuarios que acceden a Citrix Cloud. Los clientes pueden cambiar esto para usar Azure Active Directory (AD) en su lugar. Al usar Azure AD con Citrix Cloud, los clientes pueden:

  • Utilice su propio Active Directory para que puedan controlar la auditoría, las directivas de contraseñas e inhabilitar fácilmente las cuentas cuando sea necesario.
  • Configure la autenticación multifactor para un mayor nivel de seguridad frente a la posibilidad de robo de credenciales de inicio de sesión.
  • Utiliza una página de inicio de sesión con marca para que tus usuarios sepan que están iniciando sesión en el lugar 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 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 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}.

Permisos y delegación 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 permita una delegación adecuada entre equipos y promueva el concepto de mínimo 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 es cierto tanto para usuarios (principal de usuario) como para aplicaciones (principal 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 de ámbito de suscripción tienen derechos de colaborador para la suscripción aplicable utilizada por el entorno Citrix. Los principales de servicio de ámbito restringido tienen 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 proporcionando metadatos para organizarlos lógicamente en una taxonomía. Cada etiqueta consta de un nombre y un par de valores. 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 gestión.

Hay un límite de 15 etiquetas por recurso. Citrix MCS crea 2 etiquetas por VM, por lo que un cliente está limitado a 13 etiquetas para 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 nomenclatura. Hay directivas predeterminadas disponibles y la capacidad de aplicar directivas personalizadas. Las directivas de Azure se pueden aplicar en el nivel de suscripción o grupo de recursos. Se pueden definir varias directivas. Las directivas aplicadas en el nivel Grupo de recursos tienen prioridad sobre la directiva 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, sofisticados controles orientados al cliente y una infraestructura reforzada segura. Esta potente combinación ayuda a proteger las aplicaciones y los datos, respalda 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: principal de servicio de aplicaciones para acceder a grupos de recursos de Azure para realizar diferentes acciones. Para el tipo de recursos de cuenta de almacenamiento, MCS requiere el listkeys permiso 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 listkeys permiso

Para algunas organizaciones mantener el endpoint 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 detalles.

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 VM y acceso privilegiado seguro.
  • 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.
  • Configuración de grupos y reglas de seguridad de red para controlar el tráfico hacia máquinas virtuales.
  • Aprovisionamiento de firewalls de aplicaciones web para ayudar a defenderse de ataques dirigidos a sus aplicaciones web.
  • Se abordan las configuraciones del sistema operativo que no coinciden con las líneas base recomendadas.

Diseño de redes

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

Segmentación de redes virtuales

Las redes virtuales de Azure son similares a una LAN de la red local. La idea detrás de una red virtual de Azure es crear una única red basada en el 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 produce automáticamente y no es necesario configurar manualmente las tablas de enrutamiento.

Utilice un grupo de seguridad de red (NSG). Los NSG son dispositivos de inspección de paquetes simples y con estado que utilizan el enfoque de 5 tupla (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 permiso/denegación 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 ruta asociada.

Los NSG y UDR se aplican en el 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 comprobar 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 redes virtuales de Azure con la red local o en la nube de los clientes se conoce como redes híbridas. En esta sección se explican las opciones de conectividad de red y enrutamiento 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 punto a sitio (VPN): establecida entre una red virtual y un único 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: establecido 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 enrutador perimetral utilizado por el cliente. Los SLA están disponibles en los SKU de la puerta de enlace VPN. Las VPN de sitio a sitio utilizan IPSec a través de Internet.

Las rutas Express 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. El tiempo de configuración de estos proveedores debe tenerse en cuenta 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 escenarios 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 ADC y StoreFront tradicional, el enrutamiento óptimo de puerta de enlace también se puede utilizar para dirigir la conexión de un usuario a un ADC mediante el ISP de una oficina en lugar de Express Route o VPN a Azure.

Rutas definidas por el usuario (UDR)

Normalmente, los clientes usan una UDR para enrutar 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 enrutan 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

La interconexión de red virtual conecta sin problemas dos redes virtuales de Azure. Una vez interconectadas, las redes virtuales aparecen como una sola, para fines 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. Es un ajuste natural para la entrega de aplicaciones virtuales y escritorios.

  • 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 aplicaciones virtuales y usuarios de escritorio con la experiencia de la más alta calidad posible, incluso para medios enriquecidos 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 enrutamiento específico 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 perfecta que los usuarios ni siquiera se darán cuenta de que se ha producido ningú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 necesaria para establecer una base de red que se ajuste a las necesidades cambiantes de un entorno. En caso de fallo del centro de datos, Citrix ADC redirige automáticamente el tráfico de usuario a un sitio secundario, sin interrupciones para los usuarios. El equilibrio de carga y el equilibrio de carga global de servidores en varios centros de datos garantizan aún más el estado, las capacidades y la utilización óptimos del servidor.

Discuta con el cliente y defina el siguiente caso de uso para cada ubicación de recurso:

Método Access Consideraciones
Solo interno No se requiere un Citrix ADC si solo se necesita acceso interno.
Acceso externo a través de Citrix ADC Gateway Service. Citrix Cloud ADC Gateway Service proporciona ICA Proxy (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.

Citrix ADC está limitado a 500 Mbps por NIC de Azure. 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 de origen que puede adaptar en sus propios diseños detallados y guías de implementación: diagramas de origen.

Referencias

Operaciones

Identidad

Gobernanza

Seguridad

Monitor de Azure

Conectividad

Citrix Virtual Apps and Desktops Service en Azure

En este artículo