Arquitectura de referencia: App Layering

Audiencia

Este documento está dirigido a profesionales técnicos, responsables de la toma de decisiones de TI, partners e integradores de sistemas. Esto permite al administrador explorar y adoptar Citrix App Layering para ayudar a administrar la entrega de imágenes y aplicaciones a sus usuarios finales. El lector debe tener una comprensión básica de los productos Citrix, los servicios de administración de imágenes y los conceptos de virtualización de aplicaciones. Para obtener más información sobre la administración de imágenes, consulte la arquitectura de referencia en Citrix Tech Zone.

Objetivo del presente documento

Este documento proporciona una descripción técnica y conceptos arquitectónicos para administrar y entregar aplicaciones mediante las tecnologías de Citrix App Layering. Este documento incluye cómo funciona App Layering y la integración con Citrix Virtual Apps and Desktops en diferentes plataformas.

Descripción general de Citrix App Layering

Citrix App Layering es una solución flexible para proporcionar un conjunto complejo de aplicaciones de Windows a un conjunto diverso de usuarios en cualquier plataforma compatible no persistente.

Citrix App Layering realiza la administración de imágenes de una manera única. El sistema operativo y las aplicaciones se dividen en diferentes contenedores llamados “Capas”. Las capas se crean y actualizan de forma independiente, luego se compilan en “imágenes publicadas” para distribuirlas mediante cualquier sistema de aprovisionamiento compatible.

Una vez creadas las bibliotecas de aplicaciones, se implementan diferentes conjuntos de imágenes en muchas plataformas mediante cualquier combinación de capas.

AL-Image-1

El objetivo principal de Citrix App Layering es simplificar la administración de aplicaciones de Windows mediante una única interfaz. Permite al administrador crear y gestionar aplicaciones empresariales independientemente de los hipervisores subyacentes o la infraestructura de nube.

El sistema operativo y las aplicaciones se separan en unidades administrables discretas. Incluso si se requieren muchas imágenes para controlar correctamente el acceso a las aplicaciones, cada sistema operativo y sus aplicaciones se administran como una sola instancia. En este enfoque, no es necesario realizar actualizaciones en todas las imágenes del entorno. Simplifica el entorno a la vez que reduce el tiempo de administración, la complejidad y los costes asociados con los sistemas operativos y la administración de aplicaciones.

El sistema operativo y las aplicaciones se almacenan como un disco virtual que contiene archivos y entradas de registro para una capa específica. Hay dos formas de incluir aplicaciones en las máquinas virtuales:

  • Imagen publicada: este método combina la capa de SO, una capa de plataforma y un conjunto de capas de aplicaciones para crear una imagen para sistemas de aprovisionamiento como Citrix Provisioning o Citrix Machine Creation Services. App Layering puede publicar imágenes en varios sistemas de aprovisionamiento e hipervisores desde el mismo conjunto de capas.

Para obtener más información sobre la administración de imágenes de Citrix, consulte el documento Arquitectura de referencia.

  • Capas elásticas: pocas capas de aplicación se adjuntan a una máquina virtual durante el inicio de sesión en función de la pertenencia al grupo de AD y la asignación de aplicaciones. Permite una mayor flexibilidad en la asignación de aplicaciones al permitir la entrega dinámica de aplicaciones a imágenes estandarizadas.

La separación de las aplicaciones y la personalización del sistema operativo proporciona una solución flexible y administrable para la administración de imágenes no persistentes.

Por qué Citrix App Layering

Citrix App Layering proporciona una solución rentable para administrar un conjunto complejo de aplicaciones en varios entornos con diferentes requisitos de empaquetado. Casi todas las aplicaciones que están integradas con controladores de kernel, sistemas operativos y dependencias de servicios del sistema son compatibles con la tecnología App Layering.

La adopción del enfoque de Citrix App Layering para la administración de imágenes tiene muchas ventajas:

  • Simplifica la administración de imágenes maestras para PVS y MCS: Citrix App Layering es una solución de administración de imágenes única que admite los modelos de aprovisionamiento utilizados con hipervisores de Citrix y de terceros. Con App Layering, tanto la administración como las actualizaciones de las imágenes se simplifican sin la edición directa ni la creación de imágenes inversas.

  • Soporte de Azure: Citrix App Layering admite Microsoft Azure y facilita a los clientes de App Layering la migración a una plataforma de Azure.

  • Separe las aplicaciones y los sistemas de aprovisionamiento de la imagen: Citrix App Layering separa el empaquetado de la imagen. En la administración de imágenes normal, las actualizaciones de una imagen se realizan para cada imagen por separado. Mediante App Layering una capa puede ser parte de muchas imágenes. Para actualizar todas las imágenes, es posible que la capa se actualice una vez y que las imágenes se regeneren. Las actualizaciones de componentes como las herramientas de hipervisor, los Virtual Delivery Agents (VDA) y las herramientas de Citrix Provisioning son fáciles.

  • Admite casos de uso complejos: las aplicaciones complejas con controladores del núcleo, servicios de sistemas, controladores de terceros y acceso a la consola pueden ser compatibles con Citrix App Layering. Gracias a los dos modos de implementación de la capa de aplicaciones de App Layering, casi todas las aplicaciones son compatibles.

  • Capa de usuarios de escritorio sin persistencia: La capa de usuarios es una capa elástica de escritura. Un usuario inicia sesión en un escritorio, la mayoría de las operaciones de escritura se realizan en la capa de usuarios. Permite al usuario instalar aplicaciones y guardar los valores de configuración que están fuera del perfil de usuario. También almacena los archivos de datos del usuario haciendo que su escritorio parezca persistente con los beneficios de un modelo de escritorio compartido.

  • Reduce la cantidad de imágenes necesarias: Elastic Layering puede reducir significativamente la cantidad de imágenes necesarias al entregar aplicaciones de forma dinámica solo a los usuarios asignados al iniciar sesión. Las capas elásticas son compatibles con Citrix Virtual Apps y Citrix Virtual Desktops.

Casos prácticos de Citrix App Layering

App Layering es una adición importante a la cartera de tecnología de Citrix que ofrece muchas de las ventajas enumeradas anteriormente. Aunque proporciona beneficios, App Layering no significa usarlo para todos los casos de uso. En esta sección, se describen varios de los casos de uso más relevantes para mostrar los beneficios de la tecnología App Layering.

1-Demasiadas imágenes para administrar

Muchos clientes de Citrix deben admitir una cantidad significativa de aplicaciones y un conjunto complejo de requisitos de usuario. Cuando se utiliza una tecnología de aprovisionamiento basada en imágenes, el cumplimiento de estos requisitos suele requerir una gran cantidad de imágenes para su administración. Estas imágenes deben admitir diferentes grupos de usuarios o diferentes conjuntos de aplicaciones conflictivas. A menudo, también hay cierta superposición en las aplicaciones implementadas en cada imagen.

Citrix App Layering simplifica la administración de este complejo caso.

AL-Image-2

La App Layering permite a los administradores administrar el sistema operativo y las aplicaciones como entidades individuales mediante capas. Por ejemplo, Windows necesita un parche, el parche se aplica a la capa del sistema operativo una vez y todas las imágenes que utilizan la capa del sistema operativo se actualizan mediante el dispositivo App Layering. Si se usa Microsoft Office en 10 imágenes, actualizar este Office es más sencillo agregando una versión a la capa Office. Finalmente, todas esas 10 imágenes se actualizan automáticamente.

Cuando se agrega Elastic Layering, también es posible reducir significativamente el número de imágenes necesarias. Elastic Layer permite a los administradores entregar aplicaciones de forma dinámica durante el inicio de sesión. Para las aplicaciones que no todos usan, Elastic Layers permite que la imagen se cree de forma más genérica y, al mismo tiempo, proporciona personalización para cada usuario.

2-Soporte para varios hipervisores y Azure

Muchas organizaciones están migrando a un entorno híbrido de múltiples nubes que combina recursos locales y en la nube para mejorar la experiencia del usuario. Citrix App Layering proporciona portabilidad de imágenes al admitir la mayoría de los hipervisores, además de Microsoft Azure, simplemente creando una capa de plataforma diferente para cada entorno deseado.

AL-Image-3

Normalmente, una configuración mixta de hipervisor y nube híbrida obliga a los administradores a mantener varios conjuntos diferentes de imágenes y aplicaciones en varias plataformas de administración diferentes. Con la tecnología App Layering, el mismo sistema operativo y las mismas aplicaciones que se utilizan en las instalaciones se pueden enviar a la nube o a otro hipervisor con poco o ningún trabajo adicional.

Para obtener información sobre la funcionalidad multiplataforma de App Layering, consulte la sección Soporte multiplataforma de Citrix App Layering que aparece a continuación.

3- Portabilidad de hipervisores para la migración

Las organizaciones suelen quedarse «atrapadas» con la tecnología de un proveedor simplemente porque es prohibitivamente caro migrar a una nueva tecnología. Además, las empresas a menudo se fusionan con otras organizaciones que han tomado diferentes decisiones tecnológicas. Una de las ventajas distintivas de la App Layering es la capacidad de pasar de una plataforma a otra simplemente creando una capa de plataforma diferente y migrando el dispositivo de aplicación Layering mediante la exportación de importación a la nueva plataforma.

AL-Image-4

Permite una migración transparente, por ejemplo, de vSphere a Citrix Hypervisor o de un Hypervisor local a Azure.

4-Persistencia para escritorios VDI compartidos

Muchas organizaciones tienen varios usuarios que requieren un alto nivel de persistencia en los escritorios. Incluyendo usuarios avanzados de cualquier grupo, desarrolladores, ingenieros, arquitectos, etc. Las capas de usuarios de App Layering proporcionan una cantidad significativa de persistencia sobre una arquitectura de escritorio agrupada.

La capa de usuarios se monta al iniciar sesión y cualquier escritura posterior en el escritorio se escribe en la capa de usuarios. La mayoría de las aplicaciones se pueden instalar en la capa de usuarios. Las reglas para lo que funciona en la capa de usuarios son las mismas que para Elastic Layering. Siempre y cuando la aplicación no instale controladores del núcleo, controladores de terceros y los servicios que son dependientes de otros servicios durante el arranque, son el trabajo más probable en la capa de usuarios.

AL-Image-5

Para casos de uso que requieren persistencia, la capa de usuarios es la mejor opción. Para casos de uso para admitir solo archivos OST de Microsoft Outlook y archivos de índice, la capa de usuario puede no ser la mejor opción. La capa de usuario está diseñada para manejar todas las escrituras en el escritorio VDI después de que el usuario inicie sesión. Otras tecnologías, como Citrix Profile Management Outlook Container o FSLogix Profile u Office 365 Container, gestionan el OST y los índices de Outlook de una manera mucho más específica, de modo que la cantidad de E/S gestionada por el contenedor es menor. Todas estas soluciones ahora manejan la administración del OST de Outlook, los archivos de streaming de Outlook y los archivos de índice de Outlook, de modo que la compatibilidad con la indexación ya no es una razón para elegir una tecnología sobre otra.

Descripción técnica de la creación de Citrix App Layering

Tipos de capas

Una capa es un disco virtual que contiene los archivos y las entradas de registro que se cambian o agregan durante el empaquetado. Excluyendo la primera versión de la capa del sistema operativo, las capas las crea el dispositivo App Layering integrado con el hipervisor. Un administrador crea una capa, el dispositivo aprovisiona dinámicamente una máquina de empaquetado con un disco de arranque y un disco de capa. Cuando la máquina de embalaje arranca, todos los cambios de la máquina de embalaje se escriben en el disco de capas. Cuando se completa el empaquetado, este disco se copia de nuevo en el dispositivo y todos los archivos y cambios de registro se escriben en la nueva capa y se almacenan en el repositorio de capas en formato VHD.

App Layering usa los siguientes tipos de capas:

  • Capas del sistema operativo
  • Capas de plataforma
  • Capas de aplicación
  • Capas de usuarios completas

AL-Image-7

Capa del SO: El sistema operativo como Windows 10 o Windows Server 2019. Construido a partir de una máquina virtual “Gold Image” en el hipervisor.

Capa de plataforma: La capa de plataforma incluye el software necesario para admitir una plataforma en particular. Incluir el agente de agente, el sistema de aprovisionamiento y las herramientas del hipervisor si el hipervisor es diferente del hipervisor predeterminado. La capa de plataforma también es la capa de prioridad más alta y, a veces, el software se instala aquí para que se compile con la prioridad más alta.

Capas de aplicaciones: el tipo de capa principal. Se utiliza para la mayoría del software de aplicaciones

Capas de usuario: una capa elástica (consulte la sección siguiente) que se puede escribir. Las capas de usuarios se montan al iniciar sesión y, una vez montadas, casi todas las escrituras de escritorio van a la capa de usuarios. Esta capa ofrece a los usuarios la posibilidad de personalizar significativamente su experiencia de VDI aunque usen un modelo de escritorio compartido.

Dispositivo Citrix App Layering

El dispositivo Citrix App Layering (dispositivo) proporciona tanto la interfaz administrativa para App Layering como el motor para todos los procesos de App Layering.

El dispositivo App Layering se implementa como una máquina virtual en el centro de datos donde se empaquetan las aplicaciones y se publican las imágenes. El dispositivo App Layering se basa en CentOS y está configurado con 4 vCPU y 8 GB de RAM. Estos parámetros no se deben cambiar, ya que el dispositivo está diseñado para funcionar en esa configuración.

El dispositivo está construido con dos discos. El primer disco es un disco de arranque de 30 GB para el sistema operativo. El segundo disco es el repositorio de capas de 300 GB. Este disco se puede ampliar o ampliar según sea necesario si se necesita más espacio.

Durante el proceso de creación de capas y publicación de imágenes, el dispositivo Citrix App Layering guarda los archivos de disco virtual en formato VHD en su repositorio de capas dentro del dispositivo. El dispositivo interactúa con un recurso compartido para pequeñas y medianas empresas para respaldar el proceso de actualización del dispositivo y almacenar Elastic Layers.

El dispositivo solo se usa para administrar las capas, las imágenes y las asignaciones de Elastic Layer. Los escritorios virtuales y los servidores de aplicaciones virtuales no interactúan directamente con el dispositivo. Cuando se asigna una capa de forma elástica, el dispositivo copia la capa en el recurso compartido de Elastic Layer. El recurso compartido contiene estos archivos VHD más un conjunto de archivos JSON que proporcionan las asignaciones de capas a los usuarios.

El dispositivo Citrix App Layering también aloja la consola de administración de App Layering. La implementación del dispositivo App Layering es el primer paso del proceso de instalación. Después de instalar el dispositivo, se accede a la consola de administración para completar los pasos de instalación.

Para obtener más información sobre la instalación del dispositivo Citrix App Layering, consulte la documentación del producto.

AL-Image-6

La consola de administración de Citrix App Layering es una aplicación basada en web alojada en el dispositivo de App Layering. La consola de administración de App Layering proporciona la interfaz para:

  • Cree y administre las capas del sistema operativo, la plataforma y la aplicación
  • Crear plantillas de imágenes publicadas
  • Publicar y gestionar imágenes en capas
  • Asignar a los usuarios las funciones de administrador de App Layering
  • Administrar la configuración del dispositivo y del sistema, como la retención de tareas y registros, la configuración de seguridad y los recursos compartidos de archivos de red

Motores de composición

Nuevo en la versión 1910 y posteriores es una función llamada Compositing Engines. Los motores de composición descartan la mayoría de las tareas de empaquetado y publicación que también puede realizar el Appliance de App Layering. Al eliminar estas tareas, los procesos de empaquetado y publicación escalan mejor y, debido a las ventajas de las tecnologías utilizadas, también se mejora el rendimiento del proceso.

Un motor de composición se crea mediante un conector de hipervisor como una máquina virtual Windows PE que lleva a cabo un conjunto de tareas de publicación y, a continuación, se reinicia en una máquina de empaquetado o imagen publicada. El motor de composición se utiliza para crear discos de capa almacenados en caché, crear máquinas de empaquetado y publicar imágenes. En el momento de escribir esta arquitectura de referencia, existen motores de composición para HyperV y vSphere introducidos en las versiones 1910 y 1911, respectivamente.

Los motores de composición tienen las siguientes funciones:

  • Dispositivo ligero y efímero que ejecuta Windows PE
  • Autocomposición
  • Controlado a través de API REST
  • Formatos de disco de hipervisor compatibles (VHD, VHDX y VMDK)
  • Apoyo UEFI (Gen2)
  • Arranque seguro en imágenes publicadas (solo si no se utilizan capas elásticas o capas de usuario)
  • iSCSI se utiliza para conectar discos alojados en el Appliance de App Layering.
  • No hay límite en el número de trabajos de publicación simultánea (existe un límite práctico)

Ventajas de los motores de composición

El uso de motores de composición es una opción. En el conector HyperV y vSphere Connector hay una casilla de verificación para habilitar “Descarga composición”. Esta configuración también está disponible en los conectores Machine Creation para vSphere y VMware Horizon View. La ventaja significativa de Compositing Engine es que se ejecuta en un dispositivo Windows con acceso directo a discos de hipervisor. Esto proporciona los mecanismos para admitir máquinas GEN2 en HyperV, formatos ESX VMDK nativos con Thin Provisioning en vSphere y UEFI en ambos. El rendimiento de empaquetado y publicación se mejora porque los archivos de capa grandes se procesan menos y se escriben directamente en discos del hipervisor por el motor de composición que se conecta de nuevo al Appliance de App Layering para acceder a las capas mediante conexiones iSCSI.

Nota: La publicación de PVS aún no se puede realizar con un motor de composición, por lo que todavía no es posible publicar directamente un archivo VHDX o una máquina virtual GEN2 en PVS.

Entrega de capas

Las capas se pueden entregar de dos maneras. Como parte de una imagen publicada en la que el dispositivo App Layering combina todas las capas en un único archivo de disco y carga ese archivo en el sistema de aprovisionamiento o donde las capas se montan al iniciar sesión y se ponen a disposición de los usuarios de forma dinámica.

Imagen publicada: aquí se combinan un sistema operativo, una plataforma y un conjunto de capas de aplicación en un único archivo de disco que se publica en un sistema de aprovisionamiento, como Citrix Provisioning o Machine Creation Services. El proceso comienza con la clonación de la capa de sistema operativo, luego se escriben los archivos de las capas de aplicación de uno en uno por orden de prioridad, donde cuanto más nueva sea la capa, mayor será su prioridad y, por último, se escribirá en la capa de plataforma. El proceso de combinación para crear imágenes publicadas está avanzado. Cuando se crea una imagen, se combinan los sistemas de archivos, el registro y las variables de entorno, se vuelve a crear el almacén de controladores de Windows, combinando todos los controladores de terceros de diferentes capas.

Capa elástica: Estas capas son capas de aplicaciones que se asignan a los usuarios por pertenencia al grupo de Active Directory y se adjuntan durante o poco después del inicio de sesión. Las capas elásticas son dinámicas, lo que permite a los administradores personalizar la experiencia del usuario y, al mismo tiempo, minimizar la cantidad de imágenes.

Configuraciones de conectores y conectores

El dispositivo App Layering se integra con hipervisores y sistemas de aprovisionamiento mediante conectores.

Hay dos tipos de conectores: hipervisor y aprovisionamiento:

  • Los conectores de hipervisor proporcionan el mecanismo para interactuar con un hipervisor. Actualmente, hay conectores de hipervisor para Citrix Hypervisor, vSphere, Hyper-V, Nutanix AHV, Azure y Azure Gov.

  • Los conectores del sistema de Provisioning permiten al administrador publicar una imagen en el sistema de aprovisionamiento. Actualmente, hay un conector de sistema de aprovisionamiento para Citrix Provisioning, Citrix Machine Creation Services en cada hipervisor y Horizon View.

Un único dispositivo puede conectarse a cualquier número de hipervisores o sistemas de Provisioning si tiene más conectores definidos. Las configuraciones de los conectores definen los parámetros necesarios para la integración con el hipervisor o el sistema de aprovisionamiento. Una configuración normalmente incluye credenciales para la autenticación, una ubicación de almacenamiento, una plantilla de VM y cualquier otra información necesaria para interactuar con el entorno en el que los administradores crean capas o publican imágenes. El administrador puede crear varias configuraciones de conectores, cada una configurada para acceder a una ubicación única en el entorno. Los conectores se utilizan para:

  • Importación de una imagen dorada al crear una capa de sistema operativo
  • Creación de capas y versiones de capas
  • Publicar imágenes en capas en un hipervisor o Provisioning Service. Una configuración de conector también puede incluir un script de PowerShell para ejecutarse en un servidor de Provisioning Services o un sistema con un agente de host para realizar el procesamiento posterior de una imagen publicada

Referencia: Configuraciones de conectores

Tipos de conectores

En esta sección se definen los tipos de conectores disponibles en Citrix App Layering.

Conectores de hipervisor

Los conectores de hipervisor se utilizan al crear capas o importar una imagen dorada para crear la capa de sistema operativo. Los conectores de hipervisor, al empaquetar, crean dinámicamente una máquina de empaquetado en el almacenamiento y el host definidos por la configuración del conector. También se puede usar una conexión de hipervisor para crear una máquina virtual en el hipervisor.

Citrix Provisioning

El conector de Citrix Provisioning se integra con un agente de App Layering en un servidor de Citrix Provisioning para publicar una imagen directamente en el servidor de Provisioning como un disco virtual. Los requisitos previos para Citrix Provisioning son:

  1. La cuenta de servicio del conector debe ser una cuenta de dominio con el permiso de administrador en PVS.
  2. La cuenta de servicio del conector también debe ser un administrador local en el servidor de Citrix Provisioning.
  3. Se debe instalar un agente de Citrix App Layering en cada servidor de Citrix Provisioning definido en un conector. Solo se puede definir un agente por conector.

Referencia: Citrix Provisioning

Machine Creation Services

El dispositivo Citrix App Layering puede aprovisionar y publicar directamente imágenes en capas en los hipervisores como máquinas virtuales que se utilizan como imagen maestra para MCS. Los conectores permiten que las imágenes en capas se publiquen directamente en el hipervisor. El conector de MCS es casi idéntico a los conectores de hipervisor, excepto que el conector de MCS inicia la máquina virtual publicada, lo que permite que cualquier script definido en capas se ejecute en la imagen maestra antes de que MCS la implemente. El cierre de la imagen maestra y una instantánea de VM tomada como parte de este proceso.

Scripts de conectores

Este paso es una función opcional y avanzada que está disponible al crear una configuración de conector. Para utilizar esta función, configure un script de PowerShell opcional para que se ejecute en el servidor Agent definido en la configuración del conector. Este paso se usa con mayor frecuencia con Citrix Provisioning, pero se puede usar con cualquier otro conector de publicación instalando App Layering Agent en un sistema Windows para ejecutar scripts en una imagen publicada. Copie los scripts en la máquina en la que está instalado el agente. Esta script se ejecuta después de una implementación correcta de una imagen en capas. Para usar esta funcionalidad, con una imagen maestra en un hipervisor, el script también debe interactuar con la plataforma de administración del hipervisor. Por ejemplo, en vSphere, es posible que el script necesite usar PowerCLI en vCenter para ejecutar código en la máquina virtual Master Image.

Algunas variables preestablecidas están disponibles para permitir que los scripts sean reutilizables con diferentes imágenes de plantilla y configuraciones de conectores diferentes. Las variables también contienen información que identifica la máquina virtual como parte de la imagen publicada.

Para obtener más información sobre los scripts de ejemplo, consulte los siguientes artículos de soporte CTX226060 y CTX226062.

Plantillas de imagen publicadas

Al usar App Layering, el dispositivo App Layering fusiona las capas de SO, Plataforma y Aplicación para crear imágenes publicadas. Las imágenes se publican y, a continuación, se crean en el formato requerido por el sistema de aprovisionamiento de destino. Por ejemplo, en caso de que los administradores publiquen en Citrix Provisioning, el dispositivo crea un VHD y lo carga en el servidor de aprovisionamiento definido como un disco virtual. En caso de que la solución utilice Machine Creation Services en Citrix Hypervisor, el dispositivo crea un VHD, lo carga en Citrix Hypervisor y crea una máquina virtual de imagen maestra mediante el VHD.

Para definir la configuración de una imagen publicada, se utiliza una plantilla de imagen. La plantilla de imagen define qué capas de SO, plataforma y aplicación se incluyen en la imagen. También define el conector utilizado para publicar la imagen, el tamaño de la imagen resultante en GB, si la imagen tiene habilitado Elastic Layering o uno de los diferentes tipos de capas de usuarios. Las plantillas de imagen son instantáneas puntuales de la configuración de la imagen, no admiten el control de versiones. Sin embargo, las plantillas de imagen se pueden clonar y modificar si se requieren versiones ligeramente diferentes de la misma imagen.

Agente de App Layering

El agente Citrix App Layering proporciona comunicaciones entre el dispositivo App Layering y un servidor Citrix Provisioning, un servidor Hyper-V o simplemente una máquina Windows utilizada como servidor de scripts. El Agente de App Layering también se puede utilizar para automatizar los scripts después de publicar imágenes en otros hipervisores como Citrix Hypervisor o vSphere. Para Citrix Provisioning e Hyper-V, App Layering Connector se pone en contacto con el agente de App Layering y le pide que transfiera el VHD que el dispositivo ha compilado al servidor del agente. Esta transferencia se inicia desde el agente mediante BITS y el archivo se descarga del dispositivo.

Los detalles del agente de capas de aplicaciones Citrix se pueden encontrar en la documentación de Citrix.

Referencia: Install Agent

Active Directory

El dispositivo App Layering se conecta a Active Directory tanto para la autenticación en el dispositivo como para la asignación de capas elásticas. Cuando un administrador inicia sesión en el dispositivo, intenta iniciar sesión en Active Directory con las mismas credenciales. Si ese inicio de sesión funciona, se permite que el usuario entre en el dispositivo.

Se requiere acceso a los servicios de directorio para los siguientes fines:

  • Control de acceso basado en roles (RBAC)
  • Asignación de capas elásticas y de usuarios

Durante el enlace inicial con el servicio de directorio, el dispositivo de App Layering es compatible con SSL 3.0 Secure Socket Layer y la seguridad de las capas de transporte TLS 1.1 y 1.2.

Para crear una unión de directorios, consulte la documentación del producto.

Capas

En la siguiente sección se describen los usos de cada tipo de capa con más detalle.

Capa de sistema operativo

Una capa de SO es aquella que contiene el sistema operativo Windows. Es una práctica habitual incluir todos los componentes que puedan actualizarse con Windows Update en la capa del sistema operativo para que Windows Update actualice todos ellos. Por este motivo, todos los roles y componentes del sistema operativo, como las bibliotecas de tiempo de ejecución de.NET y Visual C++, se incluyen como parte de la imagen del sistema operativo.

Es preferible no instalar aplicaciones de usuario final en la capa de SO porque todas las capas de aplicaciones creadas con una capa de SO en particular están vinculadas a esa capa de sistema operativo. Si se instala una aplicación en la capa de SO, cada imagen que utilice esa capa para incluir esa aplicación en este proceso genera un problema cuando la estrategia es hacer que la capa de sistema operativo sea universal. La separación de las aplicaciones del sistema operativo es la clave para limitar la cantidad de imágenes del sistema operativo que se deben administrar. Incluso las aplicaciones con controladores, servicios y dispositivos de núcleo se admiten en las capas de aplicaciones y no es necesario incluirlas en la capa de sistema operativo.

Durante la creación de la capa del sistema operativo, hay algunos puntos a tener en cuenta:

  • Compruebe los sistemas operativos compatibles desde el enlace
  • La capa de SO no está conectada al dominio. La unión al dominio es parte de la capa de plataforma
  • Las herramientas de hipervisor para el hipervisor principal se instalan en la capa de sistema operativo. El hipervisor en el que se realiza la mayoría del empaquetado
  • Las herramientas de hipervisor para hipervisores alternativos se instalan en la capa de plataforma para ese hipervisor.
  • Instalar componentes de.NET (de Microsoft) y actualizaciones en la capa de SO
  • Si se requieren tiempos de ejecución de Microsoft, se instalan en la capa de sistema operativo
  • Funciones y características de Windows, como las funciones de RDS instaladas en la capa del sistema operativo, de modo que se pueda actualizar con Windows Update
  • En caso de que se deba agregar un usuario o grupo local a las máquinas virtuales, esta tarea solo se puede realizar en la capa del sistema operativo porque el Administrador de cuentas de seguridad (SAM) de Windows se capturó desde la capa del sistema operativo

Referencia: Crear una capa de sistema operativo

Capa de plataforma

Una capa de plataforma es una capa que contiene opciones de configuración, herramientas y otro software necesario para ejecutar una imagen publicada en una plataforma en particular. Se pueden crear dos tipos de capas de plataforma:

Capa de plataforma de publicación: este tipo de capa de plataforma se utiliza para incluir el software requerido por un sistema de aprovisionamiento, un agente y un hipervisor de destino. Por ejemplo, una capa de plataforma de publicación para admitir Provisioning Services en vSphere for Citrix Virtual Apps tiene instalados los Citrix VDA y los controladores de dispositivos PVS. Si vSphere no es el mismo hipervisor en el que se realiza el empaquetado, esta capa también tiene VMware Tools instalado.

Capa de plataforma de embalaje: las capas de plataforma de embalaje se utilizan si se requiere una capa de embalaje para soportar las máquinas de embalaje. Estas capas no suelen ser necesarias, pero hay varios casos en los que debe ser necesaria, entre ellos:

  1. Si una capa debe empaquetarse en un hipervisor diferente al estándar. Por ejemplo, si la mayoría de las capas se crean en Hyper-V, pero por alguna razón, se crea una capa en particular dentro de vSphere, se utiliza una capa de plataforma de empaquetado con VMware Tools para admitir la máquina de creación de paquetes en vSphere.

  2. Si se requiere acceso a la máquina empaquetadora mediante el software VDA. Esta capa suele ser necesaria cuando se instalan controladores para periféricos USB que deben ver el dispositivo para que se instale correctamente. Si se crea una capa de plataforma de creación de paquetes con el software de VDA instalado y se agrega la máquina de creación de paquetes a un catálogo aprovisionado manualmente en Studio, se puede admitir este tipo de acceso.

Creación de una capa de plataforma

Para la creación de la capa de plataforma hay que recordar algunos puntos:

  • Para Citrix Provisioning, el software del dispositivo de destino se instala sin ejecutar Imaging Wizard y, a continuación, se reinicia
  • La instalación de los controladores de dispositivos Citrix VDA y Citrix Provisioning se realiza en la capa de plataforma
  • La unión de dominios se realiza en la capa de plataforma, lo que significa que se pueden crear varias capas de plataforma para admitir diferentes dominios
  • La capa de plataforma también es la capa de prioridad más alta, por lo que se pueden instalar algunos componentes opcionales, incluido el software de inicio de sesión único, como Imprivata, herramientas de Hypervisor para hipervisores alternativos y Citrix Workspace Environment Management Agent.

Para obtener más información sobre la creación de la capa de plataforma, consulte el artículo CTX225997.

Capa de aplicación

Las capas de aplicaciones se utilizan para empaquetar la mayoría de las aplicaciones Las capas de aplicaciones contienen objetos de registro y de sistema de archivos para una aplicación o grupo de aplicaciones. Al crear o modificar una capa, se crea dinámicamente una máquina de empaquetado y todos los cambios en el sistema de archivos y el Registro se capturan en esa máquina. La máquina de empaquetado contiene la capa de sistema operativo y cualquier capa de aplicaciones de requisitos previos incluida. Un segundo disco virtual denominado Disco de paquete se conecta a la máquina de empaquetado como volumen grabable. Ese disco captura todos los cambios del sistema de archivos durante el empaquetado y también contiene un subárbol del registro (denominado subárbol RSD) que se utiliza para capturar todos los cambios del registro. Una vez finalizada la máquina empaquetadora, solo se descarga el disco del paquete. Se elimina el disco de arranque.

Para obtener más información sobre la creación y edición de capas de aplicaciones, consulte la documentación del producto.

La mayoría de las veces, las aplicaciones se instalan con la misma configuración que el administrador utilizaría normalmente para el sistema de aprovisionamiento compatible. Al crear capas de aplicaciones, siempre es importante intentar inhabilitar las actualizaciones automáticas. Porque el administrador normalmente no quiere que las aplicaciones se actualicen automáticamente después de la implementación. Citrix ha documentado el proceso de creación de capas para algunas aplicaciones comunes. Tesis App Layering “Recetas” se puede encontrar en el siguiente enlace.

Referencia: Recetas de App Layering

Capas elásticas

Elastic Layering es un método para implementar dinámicamente la aplicación en una sesión virtual durante el inicio de sesión del usuario mediante el montaje de capas almacenadas como archivos VHD en un recurso compartido de SMB y la integración en el sistema de archivos mediante Citrix Composite File System (CFS). Citrix Layering Service administra Elastic Layering en el VDA. Elastic Layer Repository es un recurso compartido de SMB que contiene los archivos VHD de capa y los archivos de configuración JSON que se utilizan para definir las asignaciones de capas para Layering Service. Layering Service lee los archivos de configuración y, a continuación, monta los archivos VHD de capa mediante una llamada al SDKde Windows.

La tecnología Elastic Layering no admite todas las aplicaciones porque las capas elásticas se montan durante el inicio de sesión. Los siguientes requisitos de aplicación excluyen el uso de aplicaciones en Elastic Layers:

  1. Aplicaciones con controladores Kernel
  2. Aplicaciones con servicios que son dependencias de otros servicios en tiempo de arranque
  3. Aplicaciones que modifican el almacén de controladores de Windows, como controladores de impresora de terceros

Las aplicaciones con estos requisitos se pueden poner en capas, pero las capas se deben incluir en la imagen publicada.

Archivos de configuración (JSON)

Como se mencionó anteriormente, las asignaciones de Elastic Layer se definen en un conjunto de archivos.JSON almacenados en el repositorio de Elastic Layer. Estos archivos se definen de la siguiente manera:

  • ElasticLayerAssignment.json: este archivo contiene información sobre la asignación de usuarios y grupos a las capas de aplicación. Este archivo contiene una entrada para cada ID de grupo o usuario que tenga aplicaciones asignadas y, en el SID de ese objeto de AD, se enumeran las asignaciones de capas.

  • Layers.json: este archivo define las capas del repositorio y los metadatos sobre la capa. Este archivo se utiliza para obtener la ruta utilizada para montar el VHD.

  • MachineAssociations.json: Como su nombre indica, define la asociación de máquinas con cualquier grupo de AD, el formato utiliza patrones de nombre de máquina que contienen comodines para asociar un conjunto de equipos a un grupo de AD definido. Cuando un usuario inicia sesión en una máquina que coincide con el patrón, recibe las capas elásticas asignadas a ese grupo. Estos ajustes se definen en la consola de administración de App Layering en la sección Usuarios > Grupos.

Capa de usuarios

Las capas de usuarios proporcionan una experiencia más persistente para los usuarios y, al mismo tiempo, admiten un modelo de computación de escritorio compartido. Una vez montada una capa de usuarios, la mayoría de las escrituras del sistema se redirigen a la capa de usuarios. Esta capa permite soporte para lo siguiente:

  • Los parámetros de perfil y datos de cada usuario se almacenan en la capa de usuario
  • Las aplicaciones instaladas por el usuario se admiten en la capa de usuarios siempre y cuando las aplicaciones cumplan las reglas permitidas por Elastic Layers

Las capas de usuarios se asignan una a una. Un usuario solo puede tener una capa de escritura de usuario por capa de sistema operativo por dominio. Por lo tanto, el usuario solo puede iniciar sesión en un grupo de entrega o grupo con un escritorio mediante la misma capa de SO y la misma combinación de capa de plataforma con la capa de usuarios habilitada. Esta capa se crea como un disco virtual en un recurso compartido de archivos cuando el usuario inicia sesión por primera vez.

A partir de la versión 1910, la capa de usuario completa admite la persistencia del índice de búsqueda entre sesiones. Para admitir esto, el servicio de búsqueda de Windows se establece en DISABLED (4) en los VDA cuando se inician. Cuando el usuario inicia sesión en el servicio Ulayer cambia el tipo de inicio del servicio Windows Search a START_ON_DEMAND (3). Antes de habilitar WSearch, el servicio uLayer también debe asegurarse de que la configuración de registro de «alcance de rastreo» del indexador sea correcta. El ámbito de rastreo es un conjunto de claves del Registro que determinan las áreas de los datos del usuario que se van a indexar. La entrada en el ámbito de rastreo proviene de los valores predeterminados integrados en la imagen base, pero también puede provenir de las capas elásticas y de la configuración de la capa de persistencia del usuario. Estas entradas se procesan al iniciar sesión para proporcionar el conjunto completo de ubicaciones de ámbito de rastreo, y hay una sobrecarga modesta pero mensurable para crear esto para cada inicio de sesión. Para evitar esta sobrecarga, el servicio uLayer genera una cadena hash para representar la implementación de la imagen base (por ejemplo, la instancia BIC) y las asignaciones de capas elásticas, y almacena esta cadena en el archivo\ Program Files\ Unidesk\ Etc\ UserLayer.json del usuario como «IndexerHash». En inicios de sesión posteriores, esta cadena se compara con el IndexerHash recalculado y solo cuando difieren se reconstruye el ámbito de rastreo.

Se pueden utilizar los siguientes tipos de capas de usuarios:

  • Completo: todos los datos de un usuario, configuración y aplicaciones instaladas localmente se almacenan en su capa de usuario
  • Office 365: solo los datos y la configuración de Outlook del usuario se almacenan en su capa de usuario. Los índices de búsqueda se vuelven a crear cada inicio de sesión.
  • Sesión Office 365: solo los datos y la configuración de Outlook del usuario se almacenan en su capa de usuario. Los índices de búsqueda se vuelven a crear cada inicio de sesión.

Nota: En caso de utilizar la capa de Office 365, se recomienda utilizar Citrix Profile Management para mantener la configuración de Outlook.

El tamaño máximo predeterminado de una capa de usuarios es 10 GB. Este tamaño se puede modificar definiendo una cuota para el recurso compartido de la capa de usuarios. También es posible anular el tamaño máximo predeterminado de la capa de usuarios mediante una entrada de registro en los VDA. Para cambiar el tamaño máximo predeterminado, agregue la siguiente anulación del registro:

HKLM\Software\Unidesk\ULayer\

DWORD: DefaultUserLayerSizeInGb

VALUE: <Size in GB>

Recursos compartidos de capas elásticas y de capas de usuarios

Las capas elásticas son archivos VHD montados por un sistema operativo de cliente o servidor en la red de máquinas virtuales. Las capas elásticas se montan como de solo lectura y muchas máquinas pueden montar el mismo archivo VHD. El servidor de archivos o el recurso compartido utilizado para Elastic Layers están optimizados para la E/S de lectura.

Las capas de usuario son capas elásticas grabables. La capa de usuarios se monta en lectura/escritura en un solo escritorio. El servidor de archivos o el recurso compartido utilizado para las capas de usuarios están optimizados para la E/S de escritura. Cuando se utilizan las capas de usuarios, el rendimiento del almacenamiento es fundamental para la experiencia del usuario. Los arreglos de almacenamiento flash son muy recomendables para el recurso compartido de capa de usuarios.

La arquitectura de Elastic Layers es ampliamente escalable. La ruta del repositorio compartido de Elastic Layer se define en el registro HKLM de VM para cargas de trabajo de VDI y RDS. Este diseño permite tener un número ilimitado de réplicas para distribuir la carga.

AL-Image-8

El repositorio de Elastic Layer y los recursos compartidos de capa de usuarios se definen en el dispositivo. El recurso compartido de Elastic Layer se define en la sección Sistema > Parámetros y configuración. Esta ruta se puede cambiar en los VDA mediante la directiva de grupo modificando los siguientes valores de registro:

HKLM\SOFTWARE\Unidesk\ULayer\RepositoryPath

Value = \\Server\Share

Para implementaciones de VDI grandes, este valor del Registro permite utilizar varios repositorios de Elastic Layer para diferentes conjuntos de escritorios. Para obtener más información sobre cómo cambiar el repositorio de Elastic Layer en el registro sin volver a generar imágenes, consulte el artículo CTX222107de Citrix.

La ubicación utilizada para las capas de usuarios la asigna el grupo Active Directory y, por lo tanto, también es altamente escalable, ya que se pueden usar tantos recursos compartidos como se desee. Estas asignaciones se definen en Sistema>Ubicaciones de almacenamiento.

Para obtener más información sobre la arquitectura del recurso compartido de Elastic Layers , consulte la sección Disponibilidad, respaldo y recuperación.

Compartir archivos de capa de usuarios

Durante el proceso de inicio de sesión, cuando se configura una imagen para las capas de usuario, el archivo VHD de la capa de usuario se crea la primera vez que el usuario inicia sesión después de haber sido asignado a la imagen. La configuración de uso compartido de la capa de usuarios la define el grupo Active Directory en el dispositivo. Si un usuario está en varios grupos con recursos compartidos de capa de usuarios asignados, hay un orden de prioridad para el recurso compartido y su archivo de capa de usuarios se crea en el recurso compartido de mayor prioridad. Los discos de capa de usuarios solo se pueden usar en una máquina a la vez.

Las capas de usuarios están vinculadas tanto al dominio como a la capa de sistema operativo para el escritorio en el que se inicia sesión. La ruta a una capa de usuarios en particular es la siguiente:

\\Server\Share\Users\Domain_Username\OSLayerID_OSLayerName

Las capas de usuarios requieren una escritura intensiva. Se recomienda usar un recurso compartido de archivos que esté optimizado para escrituras. Si el recurso compartido de capa de usuarios es diferente del recurso compartido de capa elástica, la asignación de usuario definida por grupos de usuarios de AD.

AL-Image-9

La asignación de capas de usuarios se define en la sección Sistema>Ubicaciones de almacenamiento de la Consola de App Layering. Introduzca el recurso compartido y el grupo asociado al recurso compartido.

Para obtener más información sobre la arquitectura del recurso compartido de Elastic Layers , consulte la sección Disponibilidad, respaldo y recuperación.

Integración de App Layering

La siguiente sección describe la integración de Citrix App Layering con sistemas de aprovisionamiento e hipervisores.

Citrix App Layering y Citrix Provisioning Services

App Layering es fácil de integrar con Citrix Provisioning (PVS). La integración se facilita mediante la instalación de App Layering Agent en uno o más servidores PVS. El agente proporciona la conectividad entre el dispositivo y Provisioning Services.

AL-Image-10

El diagrama anterior muestra la publicación de imágenes en capas mediante Citrix Provisioning. Las imágenes se administran y distribuyen de forma centralizada para su implementación mediante la publicación desde el dispositivo App Layering en un servidor Citrix Provisioning. Hay varias arquitecturas que se pueden crear para admitir Citrix Provisioning. La arquitectura más utilizada es integrar un único servidor PVS de producción que se utiliza como punto de integración. A continuación, App Layering Agent descarga los discos virtuales en el almacén del servidor PVS cuando se publica la imagen. El agente usa el servicio BITS de Windows para realizar la transferencia.

Cuando se publican imágenes, es posible configurar scripts de Connector PowerShell para que se ejecuten en la imagen después de cargar la imagen. Al utilizar esta función, si los scripts utilizan un procesador intensivo, es aconsejable utilizar un servidor de Provisioning de almacenamiento previo que no se utilice para realizar la transmisión. De este modo, la publicación y el procesamiento de scripts no afectan negativamente a las funciones de streaming de Provisioning Services Farm. Para respaldar este diseño, es la forma más sencilla de crear una granja de Citrix Provisioning «DEV» con un solo servidor. Este servidor “DEV” también se puede utilizar para transmitir imágenes de prueba. Una vez que se haya probado la imagen, el disco virtual se puede replicar en la granja de producción de Citrix Provisioning para realizar más pruebas e implementaciones.

Para obtener más información sobre este tipo de scripting, consulte el siguiente script de ejemplo del artículo de asistencia de Citrix CTX226060.

Cuando se publica una imagen en Citrix Provisioning, la imagen se denomina de acuerdo con el nombre de plantilla de imagen con una marca de fecha y hora para el control de versiones. Los discos virtuales se administran en Provisioning Services de la misma manera en que se administrarían sin App Layering. El control de versiones no se usa cuando se usa App Layering. En cambio, cada vez que se publica una nueva imagen, se crea un disco virtual completo con una nueva marca de fecha y hora. Si se necesita un cambio de emergencia en la imagen, se puede usar el control de versiones de Citrix Provisioning para modificar rápidamente la imagen. Luego, el mismo cambio se puede agregar a la capa apropiada después de que el problema se haya solucionado rápidamente.

Impacto de Elastic Layering en los discos de caché de Citrix Provisioning

Citrix Provisioning utiliza memoria reservada y un disco de caché conectado localmente para almacenar temporalmente los cambios del sistema de archivos local durante una sesión. Al usar App Layering y Citrix Provisioning, el tamaño de los discos de caché debe ser mayor que sin App Layering. Cada vez que se abre un archivo, para la operación de escritura con App Layering, se copia todo el archivo en el volumen grabable de la máquina virtual para que se pueda modificar. Hace que todo el archivo también se copie en la caché de disco, cuando Citrix Provisioning normalmente solo copia los bloques modificados en la caché.

AL-Image-11

El diagrama anterior muestra las escrituras en el disco de caché con y sin el controlador de filtro de App Layering instalado en los destinos del servidor de Provisioning Services. Para obtener más información sobre el almacenamiento en caché con Elastic Layers, consulte el artículo CTX227454.

Capa de usuarios y disco de caché de Citrix Provisioning

Cuando se utilizan capas de usuarios, solo se utiliza el disco de caché de aprovisionamiento antes de que un usuario inicie sesión.

AL-Image-12

En este caso, el disco de partición grabable local solo se usa durante el arranque. Una vez que un usuario ha iniciado sesión, todas las modificaciones de archivos nuevos se redirigen al disco de Capa de usuarios en el recurso compartido de archivos y no al disco virtual transmitido, lo que significa que la caché de aprovisionamiento ya no ve E/S en la partición grabable.

Servicios Citrix App Layering y Machine Creation

Para publicar imágenes en capas en Machine Creation Services, se creó un conector de Machine Creation Services para el hipervisor en el que se va a publicar. La configuración de Connector incluye las credenciales de cuenta de servicio utilizadas para acceder al Hypervisor, además de hosts, ubicaciones de almacenamiento, plantillas, etc.

El conector se utiliza entonces para publicar una imagen en capas como una máquina virtual “Imagen maestra” en el hipervisor.

AL-Image-13

El conector MCS inicia la imagen maestra después de publicarla y ejecuta cualquier script de capa que se haya definido en cualquier capa. Después de ejecutar todos los scripts, se debe cerrar la imagen maestra y el hipervisor tomará una instantánea de la máquina virtual. Una vez completado este proceso, la imagen maestra se puede implementar mediante Machine Creation Services. El nombre de la máquina virtual es similar al de Citrix Provisioning. La máquina virtual se denomina como el nombre de la plantilla de imagen publicada, seguido de una marca de fecha y hora. Cuando se publica una nueva versión de la imagen, se trata de una máquina virtual nueva. A continuación, la nueva máquina virtual se utiliza para actualizar el catálogo existente para implementar los cambios. Al usar MCS, es importante que la plantilla utilizada para crear las imágenes maestras se haya creado a partir de una máquina virtual real. La máquina se ha iniciado en Windows y tiene configurada la zona horaria correcta. Esta tarea garantiza que la BIOS virtual esté configurada correctamente. Si no se realiza esta tarea, la imagen iniciada resultante tiene un tiempo de descanso de algunas horas en función de UTC. La mejor manera de crear la plantilla es usar un clon de la imagen dorada original utilizada para crear la capa de sistema operativo. Este paso garantiza que la configuración del hardware virtual coincida desde la capa del sistema operativo hasta la imagen maestra.

Soporte multiplataforma de Citrix App Layering

La arquitectura Citrix App Layering está diseñada para admitir muchos hipervisores y sistemas de aprovisionamiento sin crear capas específicas para ninguna plataforma. A medida que muchas organizaciones avanzan hacia entornos de nube múltiple o híbrida, Citrix App Layering facilita esta migración.

AL-Image-14

App Layering admite varias plataformas en varios hipervisores con la combinación de conectores y capas de plataforma.

Conector de App Layering: los conectores de App Layering se desarrollan en node.js y se ejecutan desde el dispositivo App Layering. Los conectores proporcionan integración a todas las plataformas compatibles, incluidos los hipervisores y los sistemas de Provisioning.

Capa de plataforma: esta capa es similar a una capa de aplicación, excepto que siempre tiene la prioridad más alta y al publicar imágenes, las “recetas” de limpieza se ejecutan de manera diferente en capas de plataforma que las capas de aplicaciones. Las capas de plataforma son donde se instalan los controladores de software para una “plataforma” definida. Por ejemplo, cuando se utiliza Citrix Provisioning, el software VDA y el software PVS se instalan en la capa de plataforma.

Los conectores App Layering y las capas de plataforma se combinan para admitir las plataformas disponibles. Para obtener más información sobre los detalles y configuraciones de implementación de múltiples hipervisores y plataformas en la nube, consulte la documentación del producto.

Flujo de comunicación App Layering

App Layering usa pocas conexiones y puertos. Estos flujos de comunicación se documentan a continuación. Para obtener más información sobre las comunicaciones y los requisitos, consulte la documentación del producto .

dispositivo de App Layering

App Layering Management Console es una consola basada en Microsoft Silverlight a la que se accede a través de TCP/IP en el puerto 80 (HTTP) o 443 (HTTPS).

Acceso al dispositivo de administración

Protocolo Puerto
HTTP 80
HTTPS 443
SSH 22
Descarga de registro 8888

Además de HTTP y HTTPS, los administradores pueden acceder a la máquina virtual del dispositivo App Layering directamente mediante SSH en el puerto 22. No se permite el acceso en puertos Telnet o FTP no seguros. SSH se utiliza para iniciar sesión en el dispositivo como “root” para obtener acceso completo y se utiliza una cuenta de “administrador” para acceder a un menú limitado y configurar los ajustes de red. En Azure, “root” y “administrator” están inhabilitados. En cambio, se solicita a los administradores durante el aprovisionamiento del dispositivo una cuenta de usuario administrativo local.

Al exportar registros desde la consola de administración, se genera un enlace de descarga y se presenta en los detalles de la tarea. El puerto 8888 se utiliza para descargar los registros.

El puerto 8161 se utiliza para la administración y configuración de ActiveMQ, pero el acceso a este puerto solo está disponible desde el dispositivo App Layering.

De manera opcional, el dispositivo App Layering puede comprobar si hay actualizaciones y descargarlas de los servidores Citrix a través de Internet mediante HTTPS/443 o HTTP/80. Se puede acceder a [www.citrix.com](cdn.citrix.com) y cdn.citrix.com si hay una conexión a Internet disponible.

Configuración de Connector

Cada tipo de conector usa un puerto diferente. La lista actual de conectores es:

Conector puerto HTTP puerto HTTPS Puertos internos
Azure 3000 3500 3001/3501
Citrix Hypervisor 3002 3502 3003/3501
vSphere 3004 3504 3005/3505
Nutanix 3006 3506 3007/3507
Citrix Provisioning 3009 3509 3010/3510
Hyper-V 3012 3512 3011/3511

Los conectores se abren como una página web independiente dentro de la consola de administración. Cada conector tiene un puerto de escucha HTTP y HTTPS. Cuando se abre un conector, el administrador se redirige a una interfaz basada en HTML5 en una ficha nueva. El explorador del administrador debe poder acceder al dispositivo de App Layering en los puertos enumerados anteriormente para cada conector.

Puertos varios

El dispositivo App Layering se comunica con varios servidores y servicios de red en sus puertos respectivos. El dispositivo App Layering se conecta a los siguientes servicios en los siguientes puertos TCP:

Destino Protocolo Puerto
Servidor de Active Directory LDAPS (LDAP sobre SSL) 636
Servidor de Active Directory LDAP 389
Servidor de Active Directory DNS 53
Servidores de archivos Windows SMB 445
Servidores horarios de red NTP 123
Servidor DHCP DHCP UDP/67
dispositivo de App Layering DHCP UDP/68

El servicio de agente

El Servicio de agente se puede usar para tres funciones independientes:

  • Integración con Citrix Provisioning
  • Integración con Hyper-V
  • Integración con un servidor de scripting general

Se accede al Servicio de agente en los siguientes puertos.

Servidor del agente Destino Función o protocolo Puerto
Todo dispositivo de App Layering Registro o HTTPS 443
Todo Servidor del agente Comandos del dispositivo App Layering o SOAP 8016
Todo dispositivo de App Layering Exportación de registros 8787
Citrix Provisioning dispositivo de App Layering Carga de disco o HTTP 3009
Citrix Provisioning dispositivo de App Layering Carga de disco o HTTPS 3509

En la instalación inicial del Agente de App Layering, el instalador abre una conexión en el puerto 443 con el dispositivo App Layering para registrar el servidor del agente. El dispositivo App Layering almacena el FQDN y el nombre corto del host del servicio del agente, y el registro del servidor del agente contiene un registro del dispositivo App Layering.

Una vez que el agente y el dispositivo de App Layering han intercambiado identidades, el dispositivo de App Layering se comunica directamente con el servicio del agente en un canal SOAP seguro en el puerto 8016. La mayoría de las comunicaciones entre el dispositivo y el agente funcionan de la siguiente manera:

Host Acción
dispositivo de App Layering Hola al agente en el puerto 8016
dispositivo de App Layering Se abrió una solicitud de comando al agente
Agente Ejecuta un comando de PowerShell como la cuenta de usuario configurada
Agente Transmite la respuesta al dispositivo App Layering en el canal de solicitud existente
Agente Adiós

Los detalles del comando real que se envía a menudo se pueden ver en el registro de Connector en el dispositivo App Layering o en el archivo applayering.agent.log en el servidor de Agent Service.

Cuando se le pide al dispositivo que genere un paquete de registros, transmite una solicitud a todos los servicios de agente que se hayan registrado en el dispositivo solicitando registros al agente. Cada servicio de agente genera su propio paquete de registros y lo devuelve al dispositivo App Layering en el puerto 8787.

La función principal del Servicio de agente es transferir archivos a Citrix Provisioning o Hyper-V. Al transferir archivos, el agente usa el Servicio de transferencia inteligente en segundo plano (BITS) de Windows en el servidor de servicio del agente para extraer el disco virtual al servidor y colocarlo en el almacén o cargar o descargar un VHD desde Hyper-V.

El proceso de transferencia de un archivo funciona de la siguiente manera:

Host Acción
dispositivo de App Layering Hola al agente en el puerto 8016
dispositivo de App Layering Solicitud de comando para la carga de archivos
Agente Ejecuta BITS como la cuenta de usuario configurada
BITS Abre una conexión al conector de Citrix Provisioning en el puerto 3009 del dispositivo App Layering
BITS Descarga el archivo en la ubicación del repositorio especificada
dispositivo de App Layering Comando para obtener el estado de transferencia
Agente Sondea BITS para conocer el estado y los informes al dispositivo App Layering
BITS Acabados
Agente Informa del estado completo al dispositivo App Layering

Normalmente, la transferencia de archivos se ejecuta en el puerto 3009, que no está cifrado. Esta comunicación se realiza por motivos de rendimiento: la sobrecarga de ejecución en una conexión HTTPS afecta significativamente al rendimiento. Sin embargo, el agente se puede configurar para forzar HTTPS y usar 3509 en su lugar.

Cuando el agente ejecuta BITS, proporciona a BITS dos cosas: la URL para la descarga del archivo y la ruta del archivo de destino. BITS se ejecuta como la cuenta de usuario configurada en el conector. Por lo tanto, este usuario necesita permisos para establecer una conexión saliente desde el servidor de Provisioning al puerto 3009 del dispositivo App Layering y también derechos para escribir un archivo en el almacén de discos virtuales.

Hipervisores

Los conectores de hipervisor utilizan los siguientes puertos.

Conector Destino Puerto
Azure e Hyper-V Administración de Azure 443
Citrix Hypervisor Citrix Hypervisor 5900
vSphere Centro virtual 443
vSphere Hosts ESX para transferencias de discos 443
Nutanix CVM de Nutanix 9440

Estos puertos son los mismos puertos que también utilizan las consolas de administración basadas en el explorador del Hypervisor. La App Layering utiliza llamadas API bien definidas a través del servicio web normal del hipervisor para las comunicaciones con el hipervisor.

Para las cargas y descargas de archivos de vSphere no se realizan mediante la comunicación con vCenter. Y se gestiona mediante comunicación directa con un host ESXi. Por este motivo, los conectores de vSphere requieren que se defina un host y el firewall del host debe configurarse para permitir el acceso desde el dispositivo de App Layering en el puerto 443.

Motores de composición

Los motores de composición se conectan de nuevo al Appliance de App Layering para conexiones iSCSI en el puerto 3260 y realizan llamadas API al dispositivo en el puerto 443. App Layering Appliance realiza llamadas API a los motores de composición también en el puerto 443.

Disponibilidad, Backup y Recuperación

App Layering puede tener varios componentes en los que las copias de seguridad son adecuadas, incluidos el dispositivo, los recursos compartidos de capa elástica y los recursos compartidos de capa de usuarios.

Nota:

Si bien esta sección describe la disponibilidad de los agentes de conexión, la recuperación y la disponibilidad de su infraestructura de agentes de VDI no se tratan aquí. Consulte la documentación y el equipo de soporte del software de agente de conexión de escritorio para obtener más información sobre sus opciones de recuperación.

Cualquier estrategia de disponibilidad para App Layering debe encajar en el diseño general de disponibilidad y recuperación de toda la solución de espacio de trabajo. Los pools y los grupos de entrega ya están altamente disponibles porque están repartidos entre hosts y pools de almacenamiento.

El almacenamiento puede estar altamente disponible de diferentes maneras. Un método común es usar un arreglo de almacenamiento con un alto grado de redundancia, incluidos varios procesadores o cabezales de almacenamiento y tecnología RAID. Sin embargo, también es posible obtener una mayor disponibilidad mediante el almacenamiento local basado en un controlador RAID local y los discos flask en cada host, y la distribución de las máquinas administradas en los hosts. Si un host falla por cualquier motivo, otros hosts se están ejecutando con máquinas administradas del grupo de escritorios disponibles para recoger las sesiones de usuario.

Las redes también pueden estar fácilmente disponibles porque los hipervisores están diseñados teniendo en cuenta la disponibilidad. Sin embargo, es importante asegurarse de tener al menos dos rutas de red disponibles para cada máquina administrada de su entorno.

Los componentes específicos de App Layering son el dispositivo, Elastic Layers y User Layers.

Backups de dispositivos

El dispositivo App Layering, como se indicó anteriormente, no es necesario para que los usuarios finales puedan usar App Layering por completo, por lo tanto, no es un requisito hacer que el dispositivo tenga una alta disponibilidad. Sin embargo, debe considerarse un requisito hacer copias de seguridad del dispositivo con regularidad. Las copias de seguridad del dispositivo garantizan que todas las capas estén disponibles, incluso si el dispositivo se destruye o se daña de alguna manera. Se puede usar cualquier tecnología de respaldo de máquinas virtuales para el dispositivo App Layering. También es posible utilizar dos dispositivos y la función de importación y exportación para mantenerlos sincronizados. Sin embargo, este paso ahora es un proceso manual.

Disponibilidad y recuperación ante desastres para capas elásticas

Las capas elásticas son archivos que se montan en agentes de escritorios virtuales (VDA) durante el inicio de sesión mediante un montaje en invitado de Windows desde un recurso compartido de SMB. Layering Service conecta las capas al iniciar sesión, pero nunca vuelve a conectar un archivo VHD desconectado. Por lo tanto, es fundamental garantizar que el servidor de archivos utilizado para Elastic Layers tenga una alta disponibilidad mediante el uso de algún tipo de sistema de archivos en clúster. El uso de varios destinos DFS-R no es suficiente para este caso de uso, porque si un destino falla, los archivos VHD montados no se pueden volver a asignar a otro destino hasta que se produzca otro inicio de sesión.

Para Recuperación ante desastres, hay dos modelos que se pueden utilizar para manejar Elastic Layers; un modelo de replicación o un modelo de dispositivo dual.

Modelo de Replicación

En este modelo, los recursos compartidos de Elastic Layer se pueden replicar mediante cualquier tecnología de replicación del sistema de archivos. Este modelo puede incluir tecnologías como DFS-R, Microsoft Storage Replica, Veeam, NAS vendor replication, Zerto, VMware vSphere Replication e incluso robocopia.

AL-Image-15

A continuación, los agentes VDA del centro de datos de DR se pueden apuntar al recurso compartido de Elastic Layer en ese centro de datos mediante GPO. Puede encontrar una plantilla de GPO para configurar la ubicación del repositorio aquí: CTX222107.

Modelo de dispositivo doble

En este modelo, se instala un dispositivo en cada centro de datos. La funcionalidad de importación y exportación proporcionada por el dispositivo se utiliza para mantener los dos dispositivos sincronizados desde una perspectiva de capa. Aquí los administradores administran las capas de DR por separado y crean imágenes en DR desde un dispositivo local.

AL-Image-16

Si se elige esta opción, la sincronización se transfiere a través de la WAN desde el recurso compartido SMB definido durante la operación de importación y exportación. A continuación, se deben asignar capas en el dispositivo de recuperación ante desastres, copiarlas en el recurso compartido de capa elástica en DR. En este modelo, también es posible desarrollar una solución que no sincronice todas las capas sino solo las capas deseadas. Dado que las capas se eligen para la exportación manualmente, solo las capas seleccionadas se pueden incluir en el proceso. Actualmente, el proceso de importación y exportación debe iniciarse manualmente.

En el modelo de dispositivo dual, se deben crear conectores y permisos para recursos compartidos elásticos en cada lado. Los únicos objetos que se importan son las propias capas. Sin embargo, en este modelo es posible tener diferentes capas en cada sitio según sea necesario. Por ejemplo, si realmente se trata de un caso de sitio activo-activo.

Disponibilidad y recuperación ante desastres para capas de usuarios

Las capas de usuarios son similares a las capas elásticas en el sentido de que son archivos VHD montados por Windows al iniciar sesión mediante un montaje en invitado. Sin embargo, se montan como grabables y los archivos están bloqueados por el escritorio de Windows. Esta tarea hace que las opciones para hacer copias de seguridad y replicar estos discos sean mucho más difíciles que las capas elásticas normales.

Debido a esta limitación, en caso de que se utilice DFS-R o un script de robocopia, el proceso de sincronización debe realizarse fuera del horario laboral (si hay horas consideradas fuera de horario). El proceso tiene que comprobar constantemente si los archivos están disponibles para sincronizarse. Para las capas de usuario, que pueden ser archivos grandes, es posible que la copia automática no funcione bien, ya que siempre puede copiar todo el archivo en lugar de los bloques que han cambiado. DFS-R podría ser una mejor opción porque solo copia bloques modificados. Sin embargo, la replicación a nivel de almacenamiento podría ser incluso mejor, ya que podría sincronizarse de manera más uniforme a medida que se realizan los cambios en lugar de esperar a que se eliminen los bloqueos de archivos.

Hay otras opciones que también se admiten aquí en función de la tecnología elegida para almacenar los archivos VHD de la capa de usuarios. Si el servidor de archivos admite el Servicio de instantáneas de volumen (VSS), se crean instantáneas de VSS para permitir la copia de seguridad y la replicación de las capas de usuarios. Al variar la frecuencia del proceso, las capas de usuario también se pueden revertir a puntos anteriores en el tiempo si se cometen daños o errores que afecten negativamente al usuario.

Si un Controller de almacenamiento admite NDMP, esta función también se puede utilizar para copias de seguridad de la capa de usuarios. NDMP trabaja a nivel de almacenamiento para realizar copias de seguridad del almacenamiento NAS directamente en disco o cinta mediante instantáneas NAS.

Debido a la dificultad de replicar discos grandes y al gasto del ancho de banda para hacerlo, muchos clientes optan por proporcionar escritorios de recuperación ante desastres para los usuarios sin una capa de usuarios replicada. En este modelo, hay dos opciones. Los usuarios pueden aprovisionar un grupo de entrega independiente en el sitio de DR que también esté habilitado para la capa de usuarios. Luego, pueden iniciar sesión en el sitio de DR y preconfigurar esa capa con lo que necesitan. O bien, se puede aprovisionar a los usuarios con un escritorio de recuperación ante desastres no persistente normal. En este último caso, a menudo resulta beneficioso mezclar Citrix Profile Management con la capa de usuarios para que la configuración del usuario se pueda replicar en el sitio de recuperación ante desastres.

Recuperación ante desastres multisitio por componentes

El enfoque de la recuperación ante desastres en varios sitios es similar al de la recuperación local. Para las imágenes, debe usar un proceso de replicación. Si usa Citrix Provisioning, puede usar Robocopy para copiar sus discos vDisk en el sitio secundario. Si usa Machine Creation Services o Horizon View en vSphere, necesita un proceso para replicar máquinas virtuales como Veeam, Zerto, VMware vSphere Replication o Site Recovery Manager. Esto también funciona para proteger el ELM.

Para Elastic Layers, la replicación de SAN o una copia con scripts funcionan. Si utiliza capas de usuarios, debe replicar a nivel de SAN/NAS para que los bloques cambiados se puedan replicar en el sistema de archivos en clúster utilizado para el recurso compartido.

Este enfoque es mejor que tener varios conectores definidos en el ELM y publicar directamente en ambos sitios porque, al publicar, debe componer la imagen y cargarla en el almacén. Si utiliza un proceso que replica la imagen ya creada, se omite el proceso de composición y es más eficiente.

Nota:

Si quiere una configuración diferente para las imágenes implementadas en la recuperación ante desastres, es mejor publicar directamente desde el ELM. Esto le permite definir diferentes capas en las plantillas de imagen para su recuperación.

También es posible usar dos dispositivos ELM, uno en cada sitio. A continuación, puede utilizar la función de exportación/importación para mantener esos ELM sincronizados desde la perspectiva de la capa. A continuación, puede tratar la recuperación por separado y crear imágenes allí desde un ELM local.

AL-Image-17

Si elige esta opción, la sincronización se transfiere a través de la WAN al recurso compartido de SMB definido en Configuración. A continuación, las capas se pueden sincronizar con el recurso compartido de SMB utilizado en el segundo sitio, mediante Robocopy con el modificador /MIR. Actualmente, el proceso de importación y exportación debe iniciarse manualmente.

También puede sincronizar solo las capas deseadas en lugar de todas las capas. Si te gusta esta opción, ponte en contacto con el arquitecto de la solución App Layering para obtener más información.

En el modelo Dual ELM, se deben crear conectores y permisos para Elastic Shares en cada lado. Los únicos objetos que se importan son las capas reales. Sin embargo, en este modelo es posible tener diferentes capas en cada sitio, según sea necesario.

Fuentes

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

Referencias

Se hace referencia a los siguientes recursos para comprender mejor Citrix App Layering:

Documentación del producto App Layering

Cómo crear una capa de plataforma

Comprensión de las capas elásticas

Optimizaciones de Windows y App Layering

Guía de antivirus de App Layering

Comprenda la receta de Office

Mejores prácticas de App Layering

Arquitectura de referencia: App Layering

En este artículo