Citrix App Layering

Destinatarios

Este documento está destinado a profesionales técnicos, responsables de la toma de decisiones de TI, socios e integradores de sistemas. Esto permitirá 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 CitrixTech 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 tanto el funcionamiento de la App Layering como 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.

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

埃尔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.

埃尔sistema operativo y las aplicaciones se almacenan como disco virtual que contiene archivos y entradas del registro para una capa específica. Existen dos formas de incluir aplicaciones dentro de máquinas virtuales:

• Imagen publicada:este método combina la capa del 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 documentoArquitectura 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 manejable para la gestión de imágenes no persistente.

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 del núcleo, sistema operativo y dependencias de servicio del sistema son compatibles con la tecnología de App Layering.

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

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

• Compatibilidad con Azure:Citrix App Layering admite Microsoft Azure y facilita a los clientes de App Layering migrar a una plataforma Azure.

• Desacople las aplicaciones y los sistemas de Provisioning 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, la capa se actualizaría una vez, y las imágenes se regenerarían. Las actualizaciones a componentes como las herramientas de Hypervisor, Virtual Delivery Agents (VDA) y Citrix Provisioning son fáciles.

• Admite casos de uso complejos:拉斯维加斯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. Debido a que los dos modos de App Layering para la implementación de capas de aplicaciones 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 la operación de escritura entra en la capa de usuarios. Permite al usuario instalar aplicaciones y guardar los ajustes 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 el número de imágenes necesarias:埃尔astic Layering puede reducir significativamente el número de imágenes necesarias al entregar aplicaciones dinámicamente solo a los usuarios asignados al iniciar sesión. Las capas elásticas son compatibles tanto con Citrix Virtual Apps como con Citrix Virtual Desktops.

Casos de uso de Citrix App Layering

La App Layering es una adición importante a la gama de tecnologías de Citrix que proporciona muchos beneficios enumerados 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 de App Layering.

1-Demasiadas imágenes para administrar

大客户de Citrix岁admitir联合国期significativo de aplicaciones y un conjunto complejo de requisitos de usuario. Cuando se utiliza una tecnología de Provisioning basada en imágenes, el cumplimiento de estos requisitos suele requerir una gran cantidad de imágenes para administrar. Estas imágenes tienen que admitir diferentes grupos de usuarios o diferentes conjuntos de aplicaciones en conflicto. 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.

La App Layering permite a los administradores administrar el sistema operativo y las aplicaciones como entidades individuales mediante capas. Por ejemplo, Windows necesita parchearse, el parche se realiza en la capa del sistema operativo una vez y todas las imágenes que utilizan la capa del sistema operativo se actualizan por el dispositivo de App Layering. Si Microsoft Office se utiliza en 10 imágenes, la actualización de Office es más sencilla agregando una versión a la capa de Office. Eventualmente 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 requeridas. Elastic Layer permite a los administradores entregar aplicaciones dinámicamente durante el inicio de sesión. Para aplicaciones que no son utilizadas por todos, Elastic Layers permite crear la imagen de forma más genérica, al tiempo que proporciona personalización para cada usuario.

2-Compatibilidad con varios hipervisores y Azure

Muchas organizaciones se están moviendo 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.

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

Para comprender, en la funcionalidad de capas de aplicaciones multiplataforma, consulte la secciónSoporte multiplataforma de Citrix App Layeringa continuación.

3- Portabilidad de hipervisores para la migración

Las organizaciones a menudo se “atascan” con la tecnología de un proveedor simplemente porque sería prohibitivamente costoso migrar a la 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.

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 la capa elástica. 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.

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 manejan el OST de Outlook y los índices de una manera mucho más específica, de modo que la cantidad de E/S manejada por el contenedor es mucho 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 del registro que se cambian o agregan durante el empaquetado. Excluyendo la primera versión de la capa del sistema operativo, el dispositivo de capas de App Layering integrado con el Hypervisor crea capas. 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 se inicia la máquina de empaquetado, todos los cambios en la máquina de empaquetado se escriben en el disco de capa. Una vez finalizado el empaquetado, este disco se copia de nuevo en el dispositivo y todos los archivos y cambios del registro se escriben en la nueva capa y se almacenan en el repositorio de capas en formato VHD.

App Layering utiliza estos diferentes tipos de capas:

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

Capa del SO:埃尔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. Incluyendo el agente de broker, el sistema de Provisioning y las herramientas de Hypervisor si el Hypervisor es diferente del Hypervisor predeterminado. La capa de plataforma es también la capa de prioridad más alta y, a veces, el software se instala aquí para que se compila con la prioridad más alta.

Capas de aplicación:el tipo de capa principal. Utilizado para la mayoría de los programas de aplicaciones.

Capas de usuarios:capa de escritura elástica (consulte la sección siguiente). 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 capacidad de personalizar significativamente su experiencia VDI aunque estén utilizando un modelo de escritorio compartido.

Dispositivo de Citrix App Layering

埃尔dispositivo Citrix App Layering (appliance) proporciona tanto la interfaz administrativa para la App Layering como el motor para todos los procesos de aplicación Layering.

埃尔dispositivo de App Layering se implementa como una máquina virtual en el centro de datos donde tienen lugar el empaquetado de aplicaciones y la publicación de imágenes. El dispositivo de App Layering se basa en CentOS, configurado con 4 vCPU y 8 GB de RAM. Esta configuración no se debe cambiar ya que el dispositivo está diseñado para funcionar en esa configuración.

El dispositivo esta construido con dos迪斯科舞厅。埃尔primer disco es un disco de arranque de 30 GB para el sistema operativo. El segundo disco es el repositorio de capa de 300 GB. Este disco se puede ampliar o ampliar según sea necesario si se requiere 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 SMB para admitir el proceso de actualización del dispositivo y para almacenar Elastic Layers.

埃尔dispositivo solo se utiliza para administrar capas, imágenes y asignaciones de capa elástica. Virtual Desktops 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 Elastic Layer. El recurso compartido contiene estos archivos VHD más un conjunto de archivos JSON que proporcionan las asignaciones de capa a los usuarios.

埃尔dispositivo Citrix App Layering también aloja la consola de administración de capas de aplicaciones. 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 ladocumentación de producto.

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

• Crear y administrar capas de sistema operativo, plataforma y aplicación
• Crear plantillas de imagen publicadas
• Publicar y administrar imágenes en capas
• Asignar App Layering los roles de administrador a los usuarios
• 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 descargar estas tareas, los procesos de envasado y publicación se escalan mucho mejor y debido a las ventajas de las tecnologías utilizadas, el rendimiento del proceso también se mejora significativamente.

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

埃尔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.

注:La publicacion de pv aun没有创造性机构ar 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 de App Layering combina todas las capas en un único archivo de disco y carga ese archivo en el sistema de Provisioning 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 clonando la capa del sistema operativo, luego escribiendo en los archivos de las capas de aplicación una a la vez en orden de prioridad donde cuanto más nueva sea la capa mayor será su prioridad y finalmente escribiendo en la capa de la plataforma. El proceso de fusión para crear imágenes publicadas está avanzado. Cuando se crea una imagen, los sistemas de archivos, el Registro y las variables de entorno se fusionan, se vuelve a crear el almacén de controladores de Windows fusionando todos los controladores de terceros de diferentes capas.

Capa elástica:Estas capas son capas de aplicación que se asignan a los usuarios por pertenencia a grupos de Active Directory y se adjuntan durante o ligeramente 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 mientras minimiza el número de imágenes.

Conectores y configuraciones de conectores

El dispositivo de应用分层se integra con摔倒rvisores y sistemas de Provisioning mediante conectores.

Hay dos tipos de conectores: Hypervisor y Provisioning:

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

• Los conectores del sistema de Provisioningpermiten al administrador publicar una imagen en el sistema de aprovisionamiento. Actualmente, hay Provisioning System Connector 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 conector definen los parámetros necesarios para integrarse con el Hypervisor o el sistema de Provisioning. Una configuración suele incluir 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 conector, 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 SO
• Creación de capas y versiones de capa
• Publicar imágenes en capas en un Hypervisor 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 conector 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 del SO. Los conectores del 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 utilizar una conexión de Hypervisor para crear una máquina virtual en el Hypervisor.

Citrix Provisioning

埃尔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 de conector debe ser una cuenta de dominio con el permiso de administrador dentro de PVS.
2. La cuenta de servicio de conector también debe ser un administrador local en el servidor de Citrix Provisioning.
3. Se debe instalar un agente Citrix App Layering en cada servidor Citrix Provisioning definido en un conector. Solo se puede definir un agente por conector.

Referencia:Citrix Provisioning

Machine Creation Services

埃尔dispositivo Citrix App Layering puede aprovisionar y publicar directamente imágenes en capas en 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 Hypervisor. El conector MCS es casi idéntico a los conectores del hipervisor, excepto que el conector 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 lo implemente. El apagado de la imagen maestra y una instantánea de VM tomadas como parte de este proceso.

Scripts de conector

Este paso es una función opcional y avanzada 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 utiliza con mayor frecuencia con Citrix Provisioning, pero se puede utilizar con cualquier otro conector de publicación instalando el Agente de App Layering en un sistema Windows para ejecutar scripts en una imagen publicada. Copie los scripts en el equipo en el que está instalado el agente. Esta script se ejecuta después de una implementación correcta de una imagen en capas. Para utilizar esta funcionalidad, con una imagen maestra en un Hypervisor el script también tiene que interactuar con la plataforma de administración del Hypervisor. Por ejemplo, para vSphere, el script tendría que usar PowerCLI contra 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.

Obtenga más información sobre los scripts de ejemplo, consulte los siguientes artículos de asistenciaCTX226060yCTX226062.

Plantillas de imagen publicadas

Cuando它应用分层,el dispositivoAplicación de capas combina las capas de SO, Plataforma y App Layering para crear imágenes publicadas. Las imágenes se publican y, a continuación, se crean en un formato requerido por el sistema de Provisioning de destino. Por ejemplo, en caso de que los administradores estén publicando en Citrix Provisioning, el dispositivo crea un VHD y lo carga en el servidor de Provisioning 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 activado Elastic Layering o uno de los diferentes tipos de Capas de usuarios. Las plantillas de imagen son una instantánea puntual de la configuración de 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

埃尔agente de Citrix App Layering proporciona comunicaciones entre el dispositivo de App Layering y un servidor de Citrix Provisioning, un servidor de Hyper-V o simplemente una máquina con 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 desde el dispositivo.

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

Referencia:Instalar agente

Active Directory

埃尔dispositivo de App Layering se conecta a Active Directory tanto para autenticaciones 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 el inicio de sesión funciona, el usuario puede entrar en el dispositivo.

埃尔acceso a los servicios de directorio se requiere para los siguientes fines:

• Control de acceso basado en roles (RBAC)
• Asignación de capa elástica y de usuario

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 un cruce de directorios, consultedocumentación de 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 principal incluir todos los componentes que se actualizarían con Windows Update en la capa del sistema operativo para que Windows Update actualice todos. 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 por este motivo.

Es preferible no instalar aplicaciones de usuario final en la capa del SO porque todas las capas de aplicación creadas con una capa del SO en particular están vinculadas a esa capa del SO. Si una aplicación está instalada en la capa del sistema operativo, entonces cada imagen que usa esa capa para que esa aplicación incluya este proceso conduce a un problema cuando la estrategia es hacer que la capa del sistema operativo sea universal. La separación de las aplicaciones del sistema operativo es la clave para limitar el número de imágenes del sistema operativo a administrar. Incluso las aplicaciones con controladores, servicios y dispositivos del núcleo son compatibles con las capas de aplicaciones y no es necesario incluirlos en la capa del SO.

Durante, la creación de la capa del sistema operativo hay algunos puntos para recordar:

• Compruebe los sistemas operativos compatibles desde el enlace
• La capa del sistema operativo no está conectada al dominio. La unión de dominio es parte de la capa de plataforma
• Las herramientas de Hypervisor para el Hypervisor principal se instalan en la capa del sistema operativo. El Hypervisor donde se realiza la mayoría de los paquetes
• Las herramientas de Hypervisor para hipervisores alternativos se instalan en la capa de plataforma para ese Hypervisor
• Instalar componentes de.NET (desde Microsoft) y actualizaciones en la capa del SO
• Si se requieren tiempos de ejecución de Microsoft, se instalan en la capa del 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 necesite agregar un usuario o grupo local a las máquinas virtuales, esta tarea solo se puede realizar en la capa del SO porque el Administrador de cuentas de seguridad de Windows (SAM) capturado desde la capa del SO

Referencia:Crear una capa de SO

Capa de plataforma

Una capa de plataforma es una capa que contiene parámetros de configuración, herramientas y otro software necesario para ejecutar una imagen publicada en una plataforma determinada. 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 Provisioning de destino, broker e Hypervisor. Por ejemplo, una capa de plataforma de publicación para admitir Provisioning Services en vSphere para Citrix Virtual Apps tiene instalados Citrix VDA y los controladores de dispositivo PVS. Si vSphere no es el mismo Hypervisor en el que se realiza el empaquetado, esta capa también tiene instalado VMware Tools.

Capa de plataforma de empaquetado:Las capas de plataforma de empaquetado se utilizan si se requiere una capa de empaquetado para admitir máquinas de empaquetado. Estas capas a menudo no son necesarias, pero hay varios casos en los que uno tiene que ser necesario, incluyendo:

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

2. Si se requiere acceso a la máquina de empaquetado mediante el software VDA. Esta capa suele ser necesaria cuando se instalan controladores para periféricos USB que deben ver el dispositivo para instalarse correctamente. Al crear una capa de plataforma de empaquetado con el software VDA instalado y agregar la máquina de empaquetado 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 algunos puntos a recordar:

• Para Citrix Provisioning, el software del dispositivo de destino se instala sin ejecutar el Asistente para imágenes y, a continuación, se reinicia
• La instalación de controladores de dispositivos Citrix VDA y Citrix Provisioning se realiza en la capa de plataforma
• La联盟de人群se realiza en La卡帕de平台aforma, 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ículoCTX225997.

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 sistema de archivos y registro 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 del sistema de archivos y del registro se capturan en esa máquina. La máquina de empaquetado contiene la capa del SO y cualquier capa de aplicación requisito previo incluido. Un segundo disco virtual denominado Disco de paquete está conectado 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 (llamado subárbol RSD) utilizado para capturar todos los cambios del registro. Una vez finalizada la máquina de empaquetado, 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, consultedocumentación de producto.

La mayoría de las veces las aplicaciones se instalan con la misma configuración que el administrador usaría normalmente para el sistema de Provisioning que admite. Al crear capas de aplicaciones, siempre es importante trabajar para desactivar las actualizaciones automáticas. Debido a que el administrador generalmente 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:Instrucciones sobre App Layering

Capas elásticas

埃尔astic 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 SMB e integrarlas en el sistema de archivos mediante Citrix Composite File System (CFS). El servicio de capas de Citrix administra Elastic Layering en el VDA. Elastic Layer Repository es un recurso compartido SMB que contiene tanto los archivos VHD de capa como los archivos de configuración JSON que se utilizan para definir asignaciones de capas para el Servicio de capas. El Servicio de capas lee los archivos de configuración y, a continuación, monta archivos VHD de capa mediante unallamada de Windows SDK.

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 dentro de Elastic Layers:

1. Aplicaciones con controladores de núcleo
2. Aplicaciones con servicios que son dependencias para otros servicios de 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 aplicar en capas, pero las capas deben incluirse 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 que se almacenan en Elastic Layer Repository. Estos archivos se definen de la siguiente manera:

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

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

• MachineAssociations.json:科摩苏数量籼稻,定义la asociacion demáquinas con cualquier grupo de AD, el formato utiliza patrones de nombres de máquinas que contienen caracteres comodín para asociar un conjunto de equipos con 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. Esta configuración se define en la Consola de administración de App Layering en lasección Usuarios > Grupos.

Capa de usuarios

Las capas de usuarios proporcionan una experiencia más persistente para los usuarios, al tiempo que siguen siendo compatibles con un modelo de informática de escritorio compartido. Después, se monta 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 de una a una. Un usuario solo puede tener una capa de usuarios grabable por capa del sistema operativo y 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 del registro del “ámbito 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 incorporados 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 también. Estas entradas se procesan al iniciar sesión para proporcionar el conjunto completo de ubicaciones de alcance 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 capa elástica, 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 alcance 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.

埃尔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 Capa de usuarios. También es posible anular el tamaño máximo predeterminado de la capa de usuarios mediante una entrada del Registro en los VDA. Para cambiar el tamaño máximo predeterminado, agregue la siguiente sustitución del registro,

HKLM\Software\Unidesk\ULayer\

DWORD: DefaultUserLayerSizeInGb

VALUE:

Uso compartido de capa elástica y recursos compartidos de capa de usuarios

埃尔astic Layers son archivos VHD montados por el sistema operativo cliente o servidor a través de la red de VM. Las capas elásticas se montan como de solo lectura y muchas máquinas pueden montar exactamente el mismo archivo VHD. El servidor de archivos o recurso compartido utilizado para Elastic Layers está optimizado para la E/S de lectura.

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

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

埃尔repositorio de Elastic Layer y los recursos compartidos de capa de usuarios se definen en el dispositivo. El recurso compartido Elastic Layer se define en la secciónSistema>Configuracióny configuración. Esta ruta de acceso se puede cambiar en los agentes VDA mediante la directiva de grupo modificando los siguientes valores del 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 tener que volver a crear imágenes, consulte el artículo de CitrixCTX222107.

La ubicación utilizada para las capas de usuarios es asignada por el grupo de Active Directory y, por lo tanto, también es altamente escalable porque se pueden usar tantos recursos compartidos como se quiera. Estas asignaciones se definen enSistema>Ubicaciones de almacenamiento.

Para obtener más información sobre la arquitectura del recurso compartido Elastic Layers, consulte lasección Disponibilidad, Copia de seguridad y Recuperación.

Uso compartido de archivos de capa de usuarios

Durante el proceso de inicio de sesión cuando se configura una imagen para Capas de usuarios, el archivo VHD de capa de usuarios se crea en la primera vez que el usuario inicia sesión después de ser asignado a la imagen. El grupo de Active Directory define la configuración del recurso compartido de capa de usuarios en el dispositivo. Si un usuario está en varios grupos con recursos compartidos de capa de usuarios asignados, existe un orden de prioridad para el recurso compartido y su archivo de capa de usuarios creado en el recurso compartido de mayor prioridad. Los discos de capa de usuarios solo se pueden usar en un equipo a la vez.

Las capas de usuarios están vinculadas tanto al dominio como a la capa del SO para el escritorio en el que se inicia sesión. La ruta a una capa de usuarios concreta de la siguiente manera:

\\Server\Share\Users\Domain_Username\OSLayerID_OSLayerName

Las capas de usuarios requieren un uso intensivo de escritura. Se recomienda utilizar un recurso compartido de archivos 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.

La asignación de capas de usuarios se define en la secciónSistema>Ubicaciones de almacenamientode 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 Elastic Layers, consulte laseccion Disponibilidad Copia y de seguridad recup前者eración.

Integración de App Layering

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

Citrix App Layering y Citrix Provisioning Services

La creacion应用分层es facil de integrar反对Citrix Provisioning (PVS). La integración se facilita mediante la instalación del Agente de App Layering en uno o más servidores PVS. El agente proporciona la conectividad entre el dispositivo y Provisioning Services.

埃尔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 de App Layering en un servidor Citrix Provisioning. Existen 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, el Agente de App Layering descarga los discos virtuales en el almacén del servidor PVS cuando se publica la imagen. El agente utiliza 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 esta forma, la publicación y el procesamiento de scripts no afectan negativamente a las funciones de transmisión en la comunidad de servidores de Provisioning Services. Para admitir este diseño, es la forma más fácil de crear una comunidad de Citrix Provisioning “DEV” con un único servidor. Este servidor “DEV” también se puede utilizar para transmitir imágenes de prueba. Una vez que se ha probado la imagen, el disco virtual se puede replicar en la comunidad de Citrix Provisioning de producción para realizar pruebas e implementaciones posteriores.

Para obtener más información sobre este tipo de scripts, consulte la siguiente script de ejemplo del artículo de asistencia de CitrixCTX226060.

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 que se administrarían sin App Layering. El control de versiones no se utiliza cuando se utiliza App Layering. En su lugar, 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 utilizar 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供应它记忆reservada y联合国disco de caché conectado localmente para almacenar temporalmente los cambios del sistema de archivos local durante una sesión. Durante el uso de 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 mediante la App Layering, el archivo completo se copia en el volumen grabable de la máquina virtual para que pueda modificarse. Hace que el archivo completo también se copie en la caché de disco cuando Citrix Provisioning normalmente solo copiaría los bloques modificados en la caché.

埃尔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ículoCTX227454.

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.

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 de creación de equipos y Citrix App Layering

Para publicar imágenes en capas en Machine Creation Services, un conector de Machine Creation Services creado para el Hypervisor en el que se está publicando. 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.

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

在El conector MCS inicia la画像maestra de publicarla y ejecuta cualquier script de capa que se haya definido en cualquier capa. Después de ejecutar todos los scripts, la imagen maestra debe cerrarse y el Hypervisor 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 a Citrix Provisioning. La máquina virtual se denomina como el nombre de la plantilla de imagen publicada seguida de una marca de fecha y hora. Cuando se publica una nueva versión de la imagen, se trata de una nueva máquina virtual. A continuación, la nueva máquina virtual se utiliza para actualizar el catálogo existente para implementar los cambios. Cuando se utiliza 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 la zona horaria correcta establecida. Esta tarea garantiza que el BIOS virtual esté configurado correctamente. Si no se realiza esta tarea, la imagen arrancada resultante tiene su tiempo de descanso en unas horas según UTC. La mejor manera de crear la plantilla es usar un clon de la imagen dorada original utilizada para crear la capa del sistema operativo. Este paso garantiza que la configuración de hardware virtual coincida desde la capa del SO hasta la imagen maestra.

Compatibilidad con Citrix App Layering en diversas plataformas

La arquitectura Citrix App Layering está diseñada para admitir muchos hipervisores y sistemas de Provisioning 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.

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

Conector de App Layering de aplicaciones:los conectores de capas de aplicaciones se desarrollan en node.js y se ejecutan desde el dispositivo de capas de aplicaciones. 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. Obtenga más información sobre los múltiples hipervisores y los detalles y configuraciones de implementación de plataformas en la nube, consultedocumentación de producto.

Flujo de comunicación App Layering

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

dispositivo de App Layering

La Consola de administración de App Layering 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 de 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 su lugar, durante el Provisioning del dispositivo se solicita a los administradores una cuenta de usuario administrativo local.

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

El puerto 8161它para la administracion yconfiguración de ActiveMQ, pero el acceso a este puerto solo está disponible desde el dispositivo de App Layering.

Opcionalmente, el dispositivo de App Layering puede buscar actualizaciones y descargarlas desde servidores Citrix a través de Internet mediante HTTPS/443 o HTTP/80. Se accede a m.giftsix.com y cdn.citrix.com si hay conexión a Internet disponible.

Configuración del conector

Cada tipo de conector utiliza 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

埃尔dispositivo de App Layering habla con varios servidores y servicios de red en sus respectivos puertos. El dispositivo de 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 de Windows	SMB	445
Servidores de tiempo de red	NTP	123
Servidor DHCP	DHCP	UDP/67
dispositivo de App Layering	DHCP	UDP/68

埃尔servicio del agente

埃尔servicio del agente se puede utilizar para tres funciones distintas:

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

Se accede al servicio del 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 de 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 de capas de aplicaciones para registrar el Servidor de agentes. El dispositivo de 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 de App Layering.

Una vez que el agente y el dispositivo de App Layering han cambiado identidades, el dispositivo de capas de aplicaciones 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	Solicitud de comando al agente abierta
Agente	Ejecuta un comando de PowerShell como cuenta de usuario configurada
Agente	Transmite la respuesta al dispositivo de 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 del conector en el dispositivo de App Layering o en el archivo applayering.agent.log en el servidor del servicio del agente.

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

La función principal de Agent Service es transferir archivos a Citrix Provisioning o Hyper-V. Al transferir archivos, el agente utiliza el servicio de transferencia inteligente en segundo plano de Windows (BITS) 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联合国archivo funcionaasí:

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 cuenta de usuario configurada
BITS	Abre una conexión al conector de Citrix Provisioning en el puerto 3009 del dispositivo de App Layering
BITS	Descarga el archivo en la ubicación del repositorio especificada
dispositivo de App Layering	Comando para obtener el estado de la transferencia
Agente	Encuesta BITS en busca de estado e informes al dispositivo de App Layering
BITS	Acabados
Agente	Informa del estado completo al dispositivo de App Layering

Normalmente, la transferencia de archivos se ejecuta en el puerto 3009, que no está cifrado. Esta comunicación se realiza por razones de rendimiento: la sobrecarga de la ejecución en conexión HTTPS afecta significativamente el rendimiento. Sin embargo, el Agente se puede configurar para forzar HTTPS y utilizar 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 Connector. Por lo tanto, este usuario necesita permisos para realizar una conexión saliente desde el servidor de aprovisionamiento al puerto 3009 del dispositivo de App Layering, así como 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 y 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	Nutanix CVM Negro	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 manejado por 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 pueden tener varios componentes en los que las copias de seguridad son apropiadas. Incluye el dispositivo, recursos compartidos de capa elástica y recursos compartidos de capa de usuarios.

Copias de seguridad del dispositivo

埃尔dispositivo de App Layering, como se indicó anteriormente, no es necesario para que los usuarios finales utilicen plenamente la capa de aplicaciones; por lo tanto, no es necesario que el dispositivo esté altamente disponible. Sin embargo, debe considerarse un requisito para realizar una copia de seguridad del dispositivo con regularidad. Las copias de seguridad del dispositivo garantizan que todas las capas estén disponibles incluso si el dispositivo está destruido o dañado de alguna manera. Se puede utilizar cualquier tecnología de copia de seguridad de máquina virtual para el dispositivo de 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 es un proceso manual ahora.

Disponibilidad y recuperación ante desastres para Elastic Layers

Las capas elásticas son archivos montados en agentes de escritorios virtuales (VDA) durante el inicio de sesión mediante un montaje invitado de Windows desde un recurso compartido SMB. El Servicio de capas conecta las capas al iniciar sesión, pero nunca vuelve a conectar un archivo VHD desconectado. Por lo tanto, es fundamental asegurarse de que el servidor de archivos utilizado para Elastic Layers esté altamente disponible mediante el uso de algún tipo de sistema de archivos agrupados. El uso de varios destinos DFS-R no es suficiente para este caso de uso, porque si falla un destino, los archivos VHD montados no se pueden volver a asignar a otro destino hasta que ocurra 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.

Referencia:Guía de conceptos de disponibilidad y recuperación de App Layering 4.x

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 robocopy.

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 sincronizados los dos dispositivos 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.

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, las capas deben asignarse en el dispositivo DR las copia en el recurso compartido Elastic Layer 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 exportar manualmente, solo se pueden incluir en el proceso las capas seleccionadas. Actualmente, el proceso de importación y exportación debe ser iniciado 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 capas reales. Sin embargo, es posible en este modelo tener diferentes capas en cada sitio según sea necesario. Por ejemplo, si realmente es 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 con 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 realizar 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 robocopy, el proceso de sincronización debe realizarse fuera de horas (si se consideran horas fuera). El proceso tiene que comprobar constantemente si los archivos están disponibles para sincronizarse. Para las capas de usuarios, que pueden ser archivos de gran tamaño, robocopy no funcionaría bien, ya que siempre copiaría todo el archivo en lugar de los bloques que han cambiado. DFS-R sería una mejor opción porque copia solo bloques modificados. Sin embargo, la replicación en el nivel de almacenamiento sería aún mejor, ya que se sincronizaría de manera más uniforme a medida que se realizan cambios en lugar de esperar a que se eliminen los bloqueos de archivos.

Hay otras opciones que se admiten aquí también dependiendo 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 usuarios también se pueden revertir a puntos anteriores en el tiempo si se comete corrupción o error que afecta 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 que supone el ancho de banda para hacerlo, muchos clientes eligen proporcionar escritorios de recuperación ante desastres a los usuarios sin una capa de usuarios replicada. En este modelo, hay dos opciones. Se puede aprovisionar a los usuarios un grupo de entrega independiente en el sitio DR que también esté habilitado Capa de usuarios. A continuación, pueden iniciar sesión en el sitio de recuperación ante desastres 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.

Referencia:Copia de seguridad y recuperación Citrix App Layering

Fuentes

埃尔objetivo de esta arquitectura de referencia es ayudarle a planificar su propia implementación. Para facilitar esta tarea, 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

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

Descripción de la capa elástica

Guía de conceptos de disponibilidad y recuperación de Citrix App Layering

Optimización de App Layering y Windows

Guía antivirus App Layering

Comprender la receta de Office

Prácticas recomendadas App Layering