Capa de control de la metodología de diseño

La capa de control es la cuarta capa de la metodología de diseño.

Active Directory

Decisión: Diseño de bosques

Los bosques de las implementaciones de varios bosques, de forma predeterminada, no tienen relaciones de confianza entre dominios. Un administrador de AD puede establecer relaciones de confianza entre varios bosques, lo que permite a los usuarios y a los equipos de un bosque autenticarse y acceder a los recursos de otro bosque.

Para los bosques que tienen relaciones de confianza entre dominios, se recomienda configurar los parámetros adecuados para permitir que los Delivery Controllers se comuniquen con los dos dominios. Cuando no se configuran las relaciones de confianza adecuadas, se deben configurar varios sitios de XenDesktop para cada bosque. En esta sección se describen los requisitos de almacenamiento por producto y se ofrecen cálculos por tamaño. Para obtener más información, consulte el artículo CTX134971 de Citrix: Successfully Deploying XenDesktop in a Complex Active Directory Environment.

Decisión: Estructura de unidades organizativas

Los componentes de infraestructura para una implementación de XenApp y XenDesktop deben residir en sus propias unidades organizativas (OU) dedicadas para separar trabajadores y controladores con fines administrativos. Al tener sus propias unidades organizativas, los objetos que hay dentro tendrán una mayor flexibilidad con su administración, al tiempo que permitirán a los administradores de Citrix obtener un control delegado.

A continuación se puede ver un ejemplo de estructura de unidad organizativa de Citrix.

Imagen de unidad organizativa de Citrix

Decisión: Grupos de usuarios

Siempre que sea posible, se deben asignar permisos y autorizaciones a grupos de usuarios en lugar de hacerlo a usuarios individuales, lo que elimina la necesidad de modificar una gran cantidad de permisos para recursos y derechos de usuario al crear, modificar o eliminar cuentas de usuario. Ejemplo de aplicación de permisos:

  • Una aplicación publicada para un grupo de 1000 usuarios requiere la validación de un solo objeto para los 1000 usuarios.
  • La misma aplicación publicada en 1000 cuentas de usuario individuales requiere la validación de los 1000 objetos.

Base de datos

La mayoría de los productos Citrix que se describen en este documento requieren una base de datos. En la siguiente tabla se describe el uso por producto:

En este cuadro:

  • Y indica Disponible.
  • O indica Opcional.
Producto Datos de configuración Datos de runtime Datos de registro de auditorías/cambios Datos de supervisión
XenDesktop Y Y Y Y
Provisioning Services Y   O  
DesktopPlayer Y Y Y Y

Decisión: Edición

Existen varias ediciones de Microsoft SQL Server 2012: Express, Web, Standard, Business Intelligence y Enterprise. En función de las prestaciones de las diversas ediciones de SQL Server disponibles, la edición Standard se utiliza a menudo para alojar las bases de datos de XenApp y XenDesktop en entornos de producción.

La edición Standard ofrece una cantidad adecuada de funciones para satisfacer las necesidades de la mayoría de los entornos. Para obtener más información sobre las bases de datos compatibles con los productos Citrix, consulte Citrix Database Support Matrix. Las diferentes versiones de los productos Citrix admiten diferentes versiones de SQL Server; por lo tanto, es importante consultar la tabla de compatibilidad para asegurarse de que la versión de SQL Server utilizada sea compatible con el producto Citrix que se va a implementar.

Decisión: Tamaño del servidor de la base de datos

SQL Server debe tener el tamaño correcto para garantizar el rendimiento y la estabilidad de un entorno. Como todos los productos Citrix utilizan SQL Server de una manera diferente, no se puede proporcionar una recomendación de tamaño que sirva para todo. En su lugar, a continuación se indican recomendaciones de tamaño de SQL Server por producto.

XenApp y XenDesktop

Los brokers de XenApp y XenDesktop utilizan la base de datos como un bus de mensajes para las comunicaciones del broker, el almacenamiento de datos de configuración y el almacenamiento de datos de supervisión y de registros de configuración. Las bases de datos se utilizan constantemente, y el impacto en el rendimiento de SQL Server puede considerarse alto.

Según los resultados de las pruebas de escalabilidad interna de Citrix, se recomienda la siguiente especificación de SQL Server para un servidor que aloje todas las bases de datos de XenDesktop:

  • 2 núcleos/4 GB de RAM para entornos de hasta 5000 usuarios
  • 4 núcleos/8 GB de RAM para entornos de hasta 15 000 usuarios
  • 8 núcleos/16 GB de RAM para entornos con más de 15 000 usuarios

Los archivos de bases de datos y los registros de transacciones deben estar alojados en subsistemas de disco duro separados para poder hacer frente a una gran cantidad de transacciones. Por ejemplo, registrar 20 000 escritorios virtuales durante 15 minutos de múltiples arranques simultáneos provoca aproximadamente 500 transacciones por segundo, y el inicio de sesión de 20 000 usuarios durante 30 minutos de múltiples arranques simultáneos provoca aproximadamente 800 transacciones por segundo en la base de datos del sitio de XenDesktop.

Provisioning Services

Además de datos de configuración estática, los servidores de aprovisionamiento almacenan información de runtime y de auditorías en la base de datos. En función del patrón de arranque y de administración, el impacto en el rendimiento de la base de datos se puede considerar entre bajo y medio.

A partir de esta categorización, se recomienda, como buen punto de partida, una especificación de SQL Server de 4 núcleos y 4 GB de RAM. SQL Server debe supervisarse con atención durante la fase de pruebas y la fase piloto para determinar su configuración óptima.

Decisión: Tamaño de las instancias

Al asignar el tamaño de una base de datos SQL, hay dos aspectos importantes:

  • Archivo de base de datos: Contiene datos y objetos como tablas, índices, procedimientos almacenados y vistas almacenadas en la base de datos.
  • Archivo de registro de transacciones: Contiene un registro de todas las transacciones y modificaciones de la base de datos realizadas por cada transacción. El registro de transacciones es un componente esencial de la base de datos y, si hay un error en el sistema, es posible que el registro de transacciones sea necesario para devolver la base de datos a un estado coherente. El uso del registro de transacciones varía según el modelo de recuperación de bases de datos que se utilice:
    • Recuperación simple: No se necesita ninguna copia de seguridad de los registros. El espacio de los registros se recupera automáticamente para mantener pocos requisitos de espacio, lo que esencialmente elimina la necesidad de administrar el espacio de los registros de transacciones. Los cambios realizados en la base de datos desde la copia de seguridad más reciente no están protegidos. En caso de desastre, esos cambios deben volver a hacerse.
    • Recuperación completa: Se necesitan copias de seguridad de los registros. Los archivos de datos de bases de datos perdidas o dañadas no provocan ninguna pérdida de trabajo. Los datos de cualquier punto arbitrario en el tiempo se pueden recuperar (por ejemplo, antes de un error de aplicación o usuario). Para crear reflejos de las bases de datos, se necesita una recuperación completa.
    • Registro masivo: Se necesitan copias de seguridad de los registros. Esto complementa el modelo de recuperación completa que permite operaciones de copia masiva de alto rendimiento. Normalmente no se utiliza para bases de datos de Citrix.

Para obtener más información, consulte Microsoft Developer Network: Modelos de recuperación (SQL Server).

Para estimar los requisitos de almacenamiento, es importante comprender el consumo de espacio en disco de las entradas comunes de bases de datos. En esta sección se describen los requisitos de almacenamiento por producto y se ofrecen cálculos por tamaño. Para obtener más información, consulte el artículo CTX139508 de Citrix: XenDesktop 7.x Database Sizing.

XenDesktop: General

XenApp 7.x y XenDesktop 7.x utilizan tres bases de datos distintas:

  • Base de datos de configuración del sitio: Contiene datos de runtime dinámico y de configuración estática.
  • Base de datos de supervisión: Contiene datos de supervisión a los que se puede acceder a través de Director.
  • Base de datos de registros de configuración: Contiene un registro para cada cambio administrativo realizado en el sitio (accesible a través de Studio).

Base de datos del sitio

Como la base de datos de un sitio de XenApp o XenDesktop contiene datos de configuración estática y datos de runtime dinámico, el tamaño del archivo de la base de datos depende no solo del tamaño físico del entorno, sino también de los patrones de usuario. Todos estos factores afectan al tamaño del archivo de la base de datos:

  • La cantidad de sesiones conectadas
  • La cantidad de agentes VDA configurados y registrados
  • La cantidad de transacciones que se producen durante el inicio de sesión
  • Transacciones de latidos de VDA

El tamaño de la base de datos del sitio se basa en la cantidad de agentes VDA y de sesiones activas. En la tabla siguiente se muestra el tamaño máximo típico de la base de datos que Citrix observa al hacer pruebas de escalado en XenApp y XenDesktop con una cantidad determinada de usuarios, aplicaciones y métodos de entrega de escritorios.

Usuarios Aplicaciones Tipos de escritorio Tamaño máximo esperado (MB)
1000 50 Compartido alojado 30
10 000 100 Compartido alojado 60
100 000 200 Compartido alojado 330
1000 N/D Alojado agrupado 30
10 000 N/D Alojado agrupado 115
40 000 N/D Alojado agrupado 390

Nota

Estos tamaños son solamente orientativos. El tamaño real de las bases de datos puede variar ligeramente según la implementación debido al modo de mantenimiento de las bases de datos.

Determinar el tamaño del registro de transacciones de la base de datos de un sitio es difícil por factores que pueden influir en el registro, entre ellos:

  • El modelo de recuperación de la base de datos SQL
  • La velocidad de inicios en horas punta
  • La cantidad de escritorios que se entregan

Durante las pruebas de escalabilidad en XenDesktop, Citrix observó un índice de crecimiento del registro de transacciones de 3,5 MB por hora cuando el sistema está inactivo, y un índice de crecimiento por usuario y día de unos 32 KB. En un entorno grande, el uso del registro de transacciones requiere una administración delicada y copias de seguridad continuas para, así, evitar un crecimiento excesivo. Esto se puede lograr con tareas programadas o planes de mantenimiento.

Base de datos de supervisión

De las tres bases de datos, normalmente la base de datos de supervisión es la más grande, ya que contiene información histórica del sitio. Su tamaño depende de muchos factores, como, por ejemplo:

  • La cantidad de usuarios
  • La cantidad de sesiones y conexiones
  • La cantidad de trabajadores
  • Configuración del período de retención: Los clientes Platinum pueden conservar los datos durante más de un año (de forma predeterminada, 90 días). Los clientes que no son Platinum pueden conservar los datos durante un máximo de 7 días (de forma predeterminada, 7 días).
  • Cantidad de transacciones por segundo. El servicio de supervisión tiende a realizar actualizaciones en lotes. Es raro que la cantidad de transacciones por segundo supere las 20.
  • Transacción en segundo plano provocada por llamadas de consolidación regulares del servicio de supervisión.
  • Procesamiento nocturno realizado para eliminar datos que están fuera del período de retención configurado.

En la tabla siguiente se muestra el tamaño estimado de la base de datos de supervisión durante un período de tiempo en diferentes casos. Estos datos son una estimación basada en los datos vistos en pruebas de escalado en XenApp y XenDesktop (se presupone que una semana laboral es de 5 días).

Usuarios Tipo 1 semana (MB) 1 mes (MB) 3 meses (MB) 1 año (MB)
1000 HSD 20 70 230 900
10 000 HSD 160 600 1950 7700
100 000 HSD 1500 5900 19 000 76 000
1000 VDI 15 55 170 670
10 000 VDI 120 440 1400 5500
40 000 VDI 464 1700 5400 21 500

Estimaciones con 2 conexiones y 1 sesión por usuario con una semana laboral de 5 días

Usuarios Tipo 1 semana (MB) 1 mes (MB) 3 meses (MB) 1 año (MB)
1000 HSD 30 100 330 1300
10 000 HSD 240 925 3000 12 000
100 000 HSD 2400 9200 30 000 119 000
1000 VDI 25 85 280 1100
10 000 VDI 200 750 2500 9800
40 000 VDI 800 3000 9700 38 600

Nota

Las 100 000 pruebas HSD se basan en un entorno de pruebas que consta de:

  • 2 Delivery Controllers
  • 43 trabajadores de escritorios compartidos alojados
  • 3 servidores SQL, configurados con bases de datos en un grupo de disponibilidad AlwaysOn.

Para obtener más información, consulte este artículo de Citrix Support: XenDesktop 7.x Database Sizing.

El tamaño del registro de transacciones de la base de datos de supervisión es muy difícil de estimar, pero las pruebas de escalabilidad en XenApp y XenDesktop han mostrado un índice de crecimiento de unos 30,5 MB por hora cuando el sistema está inactivo, y un índice de crecimiento por usuario y día de unos 9 KB.

Base de datos de registros de configuración

La base de datos de registros de configuración suele ser la más pequeña de las tres bases de datos. Su tamaño y el tamaño del registro de transacciones relacionado varían en función de las actividades administrativas diarias que se inician desde scripts de Studio, Director o PowerShell, por lo que su tamaño es difícil de estimar. Cuantos más cambios de configuración se realicen, más grande será la base de datos. He aquí algunos factores que pueden afectar al tamaño de la base de datos:

  • La cantidad de acciones realizadas en Studio, Director y PowerShell.
  • Las pequeñas transacciones que tienen lugar en la base de datos cuando no se están produciendo cambios en la configuración.
  • El índice de transacciones durante las actualizaciones. Las actualizaciones se realizan por lotes siempre que sea posible.
  • Los datos eliminados manualmente de la base de datos. Los datos de la base de datos de registros de configuración no están sujetos a ninguna directiva de retención, por lo que no se eliminan a menos que un administrador lo haga manualmente.
  • Las actividades que afectan a sesiones o usuarios, como, por ejemplo, los cierres y reinicios de sesión.
  • El mecanismo empleado para implementar escritorios.

En entornos de XenApp que no utilizan MCS, el tamaño de la base de datos tiende a caer entre 30 y 40 MB. Para entornos con MCS, el tamaño de la base de datos puede superar fácilmente los 200 MB debido a que se registran todos los datos de compilaciones de VM.

Base de datos temporal

Además de las bases de datos de sitio, supervisión y registros de configuración, SQL Server ofrece una base de datos temporal de todo el sistema (tempdb). Esta base de datos temporal se utiliza para almacenar datos de aislamiento de instantáneas de lectura confirmada. XenApp 7.x y XenDesktop 7.x utilizan esta función de SQL Server para reducir la contención de bloqueos en las bases de datos de XenApp y XenDesktop. Citrix recomienda que todas las bases de datos de XenApp 7.x y XenDesktop 7.x utilicen el aislamiento de instantáneas de lectura confirmada. Para obtener más información, consulte How to Enable Read-Committed Snapshot in XenDesktop.

El tamaño de la base de datos tempdb dependerá de la cantidad de transacciones activas, pero en general no se espera que ocupe más que unos pocos MB. El rendimiento de la base de datos tempdb no afecta al rendimiento de la intermediación de XenApp y XenDesktop, ya que cualquier transacción que genere nuevos datos requiere espacio en tempdb. XenApp y XenDesktop tienden a tener transacciones de corta duración, lo que ayuda a mantener el tamaño de tempdb pequeño.

Tempdb también se utiliza cuando las consultas generan muchos resultados intermedios. En el artículo sobre cómo optimizar el rendimiento de tempdb de Microsoft TechNet puede encontrar instrucciones e información sobre el tamaño de tempdb.

Provisioning Services

La base de datos de la comunidad de servidores de Provisioning Services contiene datos de configuración estática y de registros de configuración (registros de auditoría). Los requisitos de tamaño de los registros descritos a continuación se pueden utilizar para ayudar a asignar un tamaño a la base de datos:

Elemento de configuración Espacio en la base de datos necesario (KB) Cantidad de elementos (ejemplo) Total (KB)
Configuración de la comunidad de servidores base 112 - 112
Grupo de usuarios con acceso a la comunidad 50 10 250
Sitio 4 5 20
Colección de dispositivos 10 50 500
Vista de la comunidad 4 10 40
Relación entre la vista de la comunidad y el dispositivo 5 1 5000
Vista del sitio 4 5 20
Relación entre la vista del sitio y el dispositivo 5 1 5000
Dispositivo 2 5000 10 000
Programa de arranque del dispositivo 10 - -
Relación entre el dispositivo y el disco 35 1 175 000
Relación de la impresora del dispositivo 1 - -
Datos de personalidad del dispositivo 1 - -
Estado del dispositivo (cuando se inicia) 1 5000 5000
Propiedad personalizada del dispositivo 2 - -
Disco virtual 1 20 20
Versión del disco virtual 3 5 300
Localizador de discos 10 1 200
Propiedad personalizada del localizador de discos 2 - -
Servidor 5 10 50
IP de servidor 2 1 20
Estado del servidor (cuando se inicia) 1 20 20
Propiedad personalizada del servidor 2 - -
Almacén de discos virtuales 8 5 40
Relación entre el almacén de discos virtuales y el servidor 4 1 40
Conexión con XenServer (VirtualHostingPool) 4 - -
Tarea de actualización de discos virtuales 10 10 100
Cambio administrativo (auditoría habilitada) 1 10 000 10 000
Total     211 732 KB (~212 MB)

Durante la configuración de la comunidad de servidores de Provisioning, se crea una base de datos con un tamaño de archivo inicial de 20 MB. Debido a la naturaleza de los datos en la base de datos de la comunidad de servidores de Provisioning, el registro de transacciones no debería crecer rápidamente, a menos que se realice una gran cantidad de configuraciones.

A diferencia de XenApp, que también ofrece la capacidad de realizar un seguimiento de los cambios administrativos, la información relacionada no se escribe en una base de datos dedicada, sino directamente en la base de datos de la comunidad de servidores de Provisioning Services. Para limitar el tamaño de la base de datos de Provisioning Services, se recomienda archivar periódicamente los datos del registro de auditoría.

Decisión: Ubicación de la base de datos

XenApp y XenDesktop utilizan tres bases de datos diferentes: configuración del sitio, supervisión y registro de configuración. Las tres bases de datos se pueden alojar en el mismo servidor o en servidores diferentes. Una configuración idónea sería alojar la base de datos de supervisión en un servidor diferente de las bases de datos de configuración del sitio y registro de configuración. Es preferible separar la base de datos de supervisión porque registra más datos, los cambios ocurren con más frecuencia y los datos no se consideran tan vitales como los de las demás bases de datos.

Nota

No es posible cambiar la ubicación de la base de datos de registros de configuración cuando está habilitado el registro obligatorio.

Decisión: Alta disponibilidad

En la siguiente tabla, se destaca el impacto en XenApp, XenDesktop y Provisioning Services cuando se produce una interrupción del servicio de la base de datos:

Componente Impacto de la interrupción de la base de datos
Base de datos de configuración del sitio Los usuarios no podrán conectarse o volver a conectarse a un escritorio virtual. Nota: La caché de host local permite a los usuarios con escritorios compartidos alojados, aplicaciones de explorador y de Windows alojadas y escritorios personales volver a conectarse a sus aplicaciones y escritorios incluso cuando la base de datos del sitio no esté disponible.
Base de datos de supervisión Director no mostrará ningún dato histórico y Studio no se puede iniciar. La intermediación de las solicitudes de usuario entrantes y de las sesiones de usuario existentes no se verá afectada.
Base de datos de registros de configuración Si el permiso para cambios cuando se desconecta la base de datos se ha habilitado en las preferencias de registros de XenApp y XenDesktop, las interrupciones de la base de datos de registros de configuración no tendrán ningún impacto (excepto los cambios de configuración que no se registran). De lo contrario, los administradores no podrán realizar ningún cambio en la configuración del sitio de XenApp y XenDesktop. Los usuarios no se ven afectados.
Base de datos de comunidades de servidores de Provisioning Services Cuando se habilita la compatibilidad con bases de datos sin conexión y la base de datos en cuestión deja de estar disponible, el proceso de transmisión por streaming utiliza una copia local de la base de datos para obtener información sobre el servidor de aprovisionamiento y los dispositivos de destino admitidos por el servidor. Esto permite que los servidores de aprovisionamiento y los dispositivos de destino sigan funcionando. Sin embargo, cuando la base de datos no tiene conexión, la consola y las funciones de administración que se indican a continuación dejan de estar disponibles: incorporación automática de dispositivos de destino, creación y actualizaciones de discos virtuales, cambios de contraseña de Active Directory, inicio de Stream Process, servicio de actualización de imágenes y administración basada en PowerShell y MCLI. Si no se ha habilitado la compatibilidad con bases de datos sin conexión, todas las funciones de administración dejarán de estar disponibles y el arranque y la conmutación por error de los dispositivos de destino fallarán.

Nota

Revise las opciones de alta disponibilidad para bases de datos de terceros (por ejemplo, App-V, SCVMM o vCenter) con el proveedor de software respectivo.

Además de las opciones integradas de la redundancia de las bases de datos, Microsoft SQL Server, así como el hipervisor subyacente (en entornos virtuales), ofrecen una serie de funciones de alta disponibilidad. Estas permiten a los administradores garantizar que el impacto de las interrupciones de un solo servidor sea mínimo (si las hay) en la infraestructura de XenApp y XenDesktop. Las siguientes funciones de alta disponibilidad de SQL o del hipervisor están disponibles:

  • Alta disponibilidad a nivel de VM: Esta opción de alta disponibilidad solo está disponible para servidores SQL virtuales, que deben marcarse para la alta disponibilidad en la capa del hipervisor. Si la máquina virtual o el host del hipervisor subyacente se apagan de forma inesperada, el hipervisor intentará reiniciar la máquina virtual inmediatamente en otro host. Aunque la alta disponibilidad a nivel de VM puede minimizar los tiempos de inactividad en caso de apagón, no puede protegerse contra daños a nivel del sistema operativo. Esta solución es menos costosa que la creación de reflejos o clústeres porque utiliza una función de hipervisor integrada. Sin embargo, el proceso automático de conmutación por error es más lento, ya que puede llevar tiempo detectar una interrupción e iniciar el servidor SQL virtual en otro host. Esto puede interrumpir el servicio a los usuarios.
  • Reflejo: El reflejo de bases de datos aumenta la disponibilidad de las bases de datos con conmutaciones por error casi instantáneas. El reflejo de bases de datos se puede utilizar para mantener una única base de datos en espera o reflejada que se corresponda con una base de datos principal o de producción. El reflejo de bases de datos se ejecuta con una operación síncrona en modo de alta seguridad o una operación asíncrona en modo de alto rendimiento. En el modo de alta seguridad con conmutación por error automática (recomendado para XenDesktop) se necesita una tercera instancia de servidor, conocida como “testigo”, que permite que el reflejo del servidor actúe como un servidor en espera activa. La conmutación por error de la base de datos principal al reflejo de la base de datos tiene lugar automáticamente, y normalmente se completa en unos segundos. Se recomienda habilitar la alta disponibilidad a nivel de VM (o una funcionalidad similar de reinicio automático) para, al menos, el testigo con el objetivo de garantizar la disponibilidad del servicio SQL en caso de interrupción de varios servidores.

Nota

Microsoft planea eliminar la creación de reflejos como una opción de alta disponibilidad en una versión futura de SQL Server y no recomienda su uso en el desarrollo de redes nuevas. Consulte el artículo de Microsoft Creación de reflejo de la base de datos (SQL Server) para obtener más información.

  • Instancias de clúster de conmutación por error AlwaysOn: Los clústeres de conmutación por error permiten la alta disponibilidad para una instancia completa de Microsoft SQL Server. Un clúster de conmutación por error es una combinación de dos o más nodos o servidores que utilizan un almacenamiento compartido. Una instancia de clúster de conmutación por error AlwaysOn de Microsoft SQL Server, presentada en SQL Server 2012, aparece en la red como un único equipo, pero tiene una funcionalidad que ofrece la conmutación por error de un nodo a otro si el nodo actual deja de estar disponible. La transición de un nodo al otro nodo es directa para los clientes conectados al clúster. Las instancias de clúster de conmutación por error AlwaysOn requieren un grupo de recursos de clústeres de conmutación por error de Windows Server (WSFC). La cantidad de nodos admitidos en el grupo de recursos WSFC dependerá de la edición de SQL Server (consulte la tabla que figura en Decisión: Edición, sección anterior de este capítulo). Para obtener más información, consulte MSDN: Instancias de clúster de conmutación por error de AlwaysOn (SQL Server).
  • Grupos de disponibilidad AlwaysOn: Los grupos de disponibilidad AlwaysOn son una solución de alta disponibilidad y recuperación ante desastres para empresas integrada en Microsoft SQL Server 2012 que permite a los administradores maximizar la disponibilidad de una o más bases de datos de usuarios. Los grupos de disponibilidad AlwaysOn requieren que las instancias de Microsoft SQL Server residan en los nodos de clústeres de conmutación por error de Windows Server (WSFC). Al igual que los clústeres de conmutación por error, un único nombre de red o IP virtual se expone a los usuarios de la base de datos. A diferencia de los clústeres de conmutación por error, no se necesita almacenamiento compartido, ya que los datos se transfieren mediante una conexión de red. Se admiten la replicación sincrónica y la asincrónica en uno o más servidores secundarios. A diferencia de la creación de reflejos o clústeres, los servidores secundarios se pueden utilizar de manera activa para procesar solicitudes entrantes de solo lectura, copias de seguridad o comprobaciones de integridad. Esta función se puede utilizar para descargar solicitudes de enumeración de recursos de usuario a un servidor SQL secundario en entornos de XenDesktop para, en esencia, ampliar horizontalmente la infraestructura de un servidor SQL. Como los datos de los servidores secundarios activos pueden retrasarse varios segundos con respecto al servidor principal, la función de redirección de solo lectura no se puede utilizar para otras solicitudes de base de datos de XenDesktop en ese momento. Para obtener más información, consulte MSDN: Grupos de disponibilidad AlwaysOn (SQL Server).

En la siguiente tabla se describen las funciones de alta disponibilidad recomendadas para las bases de datos de Citrix:

En la tabla:

  • Y indica “Recomendado”.
  • o indica “Viable”.
  • N indica “No se admite”.
  • T indica que solo se aplica en entornos de prueba.
Componente Nivel de VM: Alta disponibilidad Creación de reflejos Instancias de clúster de conmutación por error de AlwaysOn Grupos de disponibilidad AlwaysOn
Base de datos del sitio T Y o o
Base de datos de registros de configuración T o o o
Base de datos de supervisión T Y o o
Base de datos de comunidades de servidores de Provisioning Services T Y o o
Base de datos de DesktopPlayer T N o o

Citrix Licensing

Citrix ofrece a las organizaciones la flexibilidad de varios modelos de licencias que se adaptan a casos de uso comunes. Los diferentes modelos de licencias varían según el producto Citrix utilizado, pero pueden incluir el modelo por usuario/dispositivo y el modelo por usuario simultáneo. Varios productos Citrix utilizan el servidor de licencias, mientras que otros productos requieren una licencia para instalarse en el propio producto.

Citrix License Server

  • XenDesktop
  • XenApp
  • Provisioning Services
  • XenServer

En el producto:

  • NetScaler
  • NetScaler Gateway

Para obtener más información sobre las licencias de XenDesktop 7.x, consulte CTX128013: XenDesktop Licensing.

Para obtener más información sobre las licencias de Microsoft, consulte el documento de Microsoft Licensing Microsoft’s Virtual Desktop Infrastructure Technology.

Decisión: Tamaño

Las pruebas internas de escalabilidad han demostrado que un único servidor virtual de licencias con dos núcleos y 2 GB de RAM puede emitir aproximadamente 170 licencias por segundo o 306 000 licencias cada media hora. Si fuera necesario, se puede ampliar la especificación del servidor de licencias para admitir una mayor cantidad de solicitudes de licencia por segundo.

Decisión: Alta disponibilidad

Para los entornos más corrientes, basta con un único servidor de licencias. En caso de que el servidor de licencias no esté disponible, los productos Citrix dependientes entrarán en un período de gracia de 30 días, lo que ofrece tiempo más que suficiente para resolver problemas de conectividad o bien restaurar o reconstruir el servidor de licencias.

Nota

  • Si el servidor de licencias y el producto Citrix no se comunican en 2 latidos (entre 5 y 10 minutos), el producto Citrix entrará en un período de gracia y solo permitirá conexiones durante un máximo de 30 días. Una vez que se haya restablecido la comunicación con el servidor de licencias, este conciliará las licencias temporales y las reales.
  • Un registro CNAME en DNS es una forma práctica de hacer referencia al servidor de licencias. El uso de registros CNAME permite cambiar el nombre del servidor de licencias sin actualizar los productos Citrix.

Si se necesita redundancia adicional, Citrix admite las siguientes soluciones de alta disponibilidad para el servidor de licencias.

  • Agrupación en clústeres de Windows: Los servidores de clúster son grupos de equipos que trabajan juntos para aumentar la disponibilidad. La agrupación en clústeres permite que el rol del servidor de licencias cambie automáticamente en caso de que se produzca un error. Para obtener más información sobre la agrupación en clústeres, consulte el artículo de Citrix Docs Clustered License Servers.
  • Duplicación del servidor de licencias: Cree una copia de seguridad a nivel de VM del servidor de licencias. Esta copia de seguridad no debe almacenarse en el mismo host que el servidor de licencias. En su lugar, debe almacenarse en una ubicación segura, como una solución de almacenamiento de alta disponibilidad, o bien hacer una copia de seguridad en una cinta o disco. El servidor duplicado no está activo y permanecerá en espera hasta que surja la necesidad de restaurar el servidor de licencias activo. Si el servidor de licencias se restaura con esta copia de seguridad, las licencias nuevas deben volver a descargarse en el servidor.

Para obtener más información, consulte Citrix Docs: Licensing Architecture Overview.

Cada método permite a un administrador intercambiar un servidor de una licencia por otro sin interrumpir el servicio; esto presupone que el cambio se produce durante el período de gracia y que se tienen en cuenta las siguientes limitaciones.

  • Los archivos de licencias harán referencia al servidor especificado durante el proceso de asignación. Esto significa que los archivos de licencias solo se pueden utilizar en un servidor con la misma información de enlace (nombre de host) que la del servidor especificado anteriormente.
  • Dos servidores de licencias unidos a dominios y basados en Windows no pueden compartir nombre y estar activos en el entorno al mismo tiempo.
  • Dado que los servidores de licencias no se comunican entre sí, las licencias adicionales deben colocarse tanto en el servidor de licencias activo como en el de seguridad.

Decisión: Optimización

Para optimizar el rendimiento del servidor de licencias, debe ajustarse la cantidad de subprocesos de “recepción” y “procesamiento”. Si el recuento de subprocesos establecido es demasiado bajo, las solicitudes se pondrán en cola hasta que haya un subproceso disponible. Por el contrario, si la cantidad de subprocesos establecida es demasiado alta, el servidor de licencias se sobrecargará.

Los valores óptimos dependen del hardware del servidor, de la configuración del sitio y del volumen de solicitudes de licencias. Citrix recomienda probar y evaluar diferentes valores para determinar la configuración adecuada. Establecer el máximo de subprocesos de procesamiento en 30 y el máximo de subprocesos de recepción en 15 es un buen punto de partida para implementaciones a gran escala.

Esta optimización mejorará la capacidad del servidor de licencias de Citrix para proporcionar licencias porque aumenta su capacidad para recibir y procesar solicitudes de licencia.

Para obtener más información, consulte Citrix Docs: Improving Performance by Specifying Thread Use.

Delivery Controllers

Decisión: Tamaño del servidor

La escalabilidad de los Delivery Controllers se basa en la utilización de la CPU. Cuantos más núcleos de procesador haya disponibles, más escritorios virtuales podrá admitir un controlador. Cada solicitud de inicio, registro, enumeración y lanzamiento de escritorios afecta al procesador del controlador. A medida que la avalancha de solicitudes se intensifica, la utilización de la CPU del controlador aumenta. Si la CPU alcanza un umbral crítico, aproximadamente el 80%, el sitio tendrá que ampliarse vertical u horizontalmente.

La incorporación de núcleos de CPU adicionales a un Delivery Controller reducirá la utilización general de la CPU, lo que permitirá a un solo controlador admitir más escritorios. Esto solo es factible cuando se trata de controladores virtualizados, ya que agregar CPU virtuales es bastante fácil. La otra opción es agregar otro controlador a la configuración del sitio. El controlador tendría la misma configuración que otros controladores, y la carga se distribuiría de manera uniforme entre todos los controladores, lo que ayudaría a reducir la carga global en cada controlador.

Las pruebas han demostrado que un único Delivery Controller, mediante la siguiente configuración, puede admitir más de 5000 escritorios.

Componente Especificación
Procesador 4 CPU virtuales
Memoria 4 GB de RAM
Red Tarjeta NIC virtual enlazada
Almacenamiento de host Almacenamiento compartido de 40 GB
Sistema operativo Windows Server 2012 R2
XenDesktop 7

La siguiente fórmula se puede utilizar para calcular la cantidad de Delivery Controllers necesarios para un sitio de Citrix.

Imagen de la cantidad de Delivery Controllers

Decisión: Alta disponibilidad

Si el servidor que aloja el Delivery Controller no está disponible, los usuarios no podrán acceder a sus escritorios virtuales o aplicaciones publicadas. Por lo tanto, se deben implementar al menos dos Delivery Controllers (redundancia N+1) por zona en diferentes servidores físicos para evitar que este componente se convierta en un punto de fallo único. De este modo, si falla un controlador, los demás pueden gestionar las conexiones y administrar el sitio.

Las ubicaciones de todos los Delivery Controllers se especifican en el VDA, lo que le permite recurrir a la conmutación por error automática si la comunicación con un Delivery Controller no está disponible. El VDA comprueba las siguientes ubicaciones por orden y se detiene en el primer lugar en el que encuentre el Delivery Controller:

  1. Una ubicación de almacenamiento persistente mantenida para la función de actualización automática. Esta ubicación contiene información acerca de los Controllers si la actualización automática está habilitada, después de la primera vez que el VDA se haya registrado correctamente después de la instalación. Para su registro inicial después de la instalación, o cuando la actualización automática está inhabilitada, el VDA comprueba las siguientes ubicaciones.
  2. Configuración de directivas (Delivery Controllers, SID de Delivery Controllers).
  3. La información del Delivery Controller bajo la clave del Registro ListofDDCs de VDA. El programa de instalación del VDA rellenará inicialmente estos valores a partir de la información indicada al instalar el VDA.
  4. Detección por unidades organizativas. Este es un método antiguo, que se mantiene para la compatibilidad con versiones anteriores.
  5. El archivo Personality.ini creado por Machine Creation Services.

Citrix Consulting recomienda utilizar la función de actualización automática (habilitada de forma predeterminada). Esta función simplificará la administración del entorno porque mantiene actualizados los VDA al agregar y quitar Delivery Controllers.

Decisión: Caché de host local

Aunque la base de datos SQL tenga alta disponibilidad, existe el riesgo de no tener acceso a la base de datos si falla la conexión de red entre el Delivery Controller y la base de datos SQL, lo cual es preocupante para los sitios que abarcan ubicaciones geográficas.

Para no correr este riesgo, los Delivery Controllers pueden utilizar la Caché de host local. Esta función crea una copia local de la base de datos SQL, que se utiliza solo si el Delivery Controller pierde contacto con la base de datos.

Al utilizar la Caché de host local, se debe tener en cuenta lo siguiente:

  • Elecciones: Cuando las zonas pierden contacto con la base de datos SQL, se produce una elección mediante la que se nombra a un único Delivery Controller como el principal. Todos los controladores restantes pasan al modo inactivo. Un orden alfabético simple determina el ganador de la elección.
  • Tamaño: Cuando se utiliza el modo de caché de host local, un único Delivery Controller es el responsable de todos los registros, enumeraciones, inicios y actualizaciones de VDA. El controlador elegido debe tener suficientes recursos (de CPU y de RAM) para gestionar toda la carga de la zona. Un solo controlador puede escalar a 10 000 usuarios, lo que influye en el diseño de la zona.
    • RAM: Los servicios de caché de host local pueden consumir más de 2 GB de RAM en función de lo que dure la interrupción y de los inicios de usuario durante la interrupción.
    • CPU: La caché de host local puede usar hasta 4 núcleos en un solo socket.
    • Almacenamiento: Durante el modo de caché de host local, el espacio de almacenamiento aumentó 1 MB cada 2-3 minutos con un promedio de 10 inicios de sesión por segundo.
  • Opciones de energía: Los recursos virtuales apagados no se iniciarán cuando el Delivery Controller se halle en modo de caché de host local. Los escritorios virtuales agrupados que se reinician al final de una sesión se colocan en modo de mantenimiento.
  • Consolas: Al utilizar el modo de caché de host local, Studio y PowerShell no están disponibles.

Decisión: Cifrado de XML Service

En una sesión habitual, el servidor de StoreFront pasa credenciales a Citrix XML Service en un Delivery Controller. El protocolo XML de Citrix utiliza texto no cifrado para intercambiar todos los datos, a excepción de las contraseñas, que se transmiten mediante ofuscación.

Si se puede interceptar el tráfico entre los servidores de StoreFront y los Controllers de XenDesktop, este será vulnerable a los ataques siguientes:

  • Los atacantes pueden interceptar el tráfico XML y robar información y tíquets de los conjuntos de recursos.
  • Los atacantes capaces de descifrar la ofuscación pueden obtener credenciales de los usuarios.
  • Los atacantes pueden suplantar el Controller de XenDesktop e interceptar solicitudes de autenticación.

Para la mayoría de las organizaciones, el tráfico XML de Citrix se aislará en la red dedicada física o virtual de un centro de datos, lo que hace improbable la interceptación. Sin embargo, por motivos de seguridad, piense en usar el cifrado SSL para enviar datos de StoreFront a través de una conexión HTTP segura.

Decisión: Administración de carga de SO de servidor

Las directivas de administración de carga predeterminadas se aplican a todos los grupos de entrega de SO de servidor. La configuración predeterminada establece en 250 el máximo de sesiones que un servidor puede alojar y no tiene en cuenta el uso de CPU ni de la memoria. La limitación de la cantidad de sesiones no indica una carga verdadera, lo que puede provocar una sobrecarga de los grupos de entrega de SO de servidor y, en consecuencia, una degradación del rendimiento o una infrautilización de los grupos de entrega de SO de servidor, que se traduce en un uso ineficiente de los recursos.

Citrix Consulting recomienda crear directivas de administración de carga “personalizadas” y exclusivas para cada grupo de entrega en función de las pruebas de rendimiento y escalabilidad. Se pueden aplicar varias reglas y umbrales a cada grupo de entrega según los cuellos de botella identificados en los recursos durante las pruebas. Para obtener más información sobre las configuraciones de directivas de administración de carga disponibles, consulte Citrix Docs: Load Management policy settings.

Si no se pueden realizar pruebas adecuadas antes de la fase de producción, Citrix Consulting recomienda implementar la siguiente directiva de administración de carga “personalizada”, que se puede aplicar a todos los servidores como referencia:

  • Uso de CPU: Carga completa = 80%.
  • Prioridad de procesos excluidos para el uso de CPU: Por debajo de lo normal o Bajo.
  • Uso de memoria: Carga completa = 80%.
  • Carga base de uso de memoria: Notificar carga cero (MB) = 786.
  • Número máximo de sesiones: X.

La directiva “Número máximo de sesiones” se incluye para poner límites, lo que se considera una práctica recomendad para reforzar la resistencia. Las organizaciones pueden elegir un valor inicial de 250 (indicado por la “X”). Se recomienda encarecidamente que este y otros valores se personalicen en función de los resultados de las pruebas de escalabilidad.

Cloud Connector

XenApp y XenDesktop Service dentro de Citrix Cloud utiliza un conjunto de servicios contenidos en Citrix Cloud Connector. Se debe colocar un conjunto redundante de máquinas virtuales de Cloud Connector en cada centro de datos o ubicación de recursos que contenga hosts de VDA.

Decisión: Tamaño del servidor

La escalabilidad de Cloud Connector se basa en la utilización de la CPU. Cuantos más núcleos de procesador estén disponibles, más escritorios virtuales puede admitir un Cloud Connector. Cada solicitud de arranque, registro, enumeración e inicio de escritorios afecta al procesador del Cloud Connector. A medida que la avalancha de solicitudes se intensifica, la utilización de la CPU del Cloud Connector aumenta. Si la CPU alcanza un umbral crítico, aproximadamente el 80%, el sitio tendrá que ampliarse vertical u horizontalmente.

Las pruebas han demostrado que un único Controller de Cloud Connector, mediante la siguiente configuración, puede admitir 5000 escritorios.

Componente Especificaciones locales Especificaciones alojadas en Azure
Cantidad de máquinas virtuales (con tolerancia de fallos N+1) 3 6 instancias Standard_A2_V2
Procesadores por VM 4 CPU virtuales 2 CPU virtuales
Memoria por VM 4 GB de RAM 4 GB de RAM
Almacenamiento de host por VM 40 GB de almacenamiento compartido 200 GB de almacenamiento temporal
Sistema operativo Windows Server 2012 R2 Windows Server 2012 R2

Provisioning Services

Citrix Provisioning Services (PVS) emplea tecnología de streaming para simplificar la implementación de máquinas virtuales y físicas. Los equipos se aprovisionan y se reaprovisionan en tiempo real a partir de una misma imagen de disco compartida. De esta forma, los administradores no necesitan administrar ni instalar revisiones para cada sistema individualmente. Toda la administración de imágenes se realiza en la imagen maestra.

Decisión: Topología

Una comunidad de servidores de Provisioning Services representa el nivel superior de la infraestructura de Provisioning Services, que se puede desglosar en sitios. Todos los servidores de aprovisionamiento de una comunidad comparten la misma base de datos SQL y el mismo servidor de licencias de Citrix.

Cada sitio es una entidad lógica que contiene servidores de aprovisionamiento, grupos de discos virtuales y colecciones de dispositivos de destino. Aunque todos los sitios de una comunidad comparten la misma base de datos, los dispositivos de destino solo pueden conmutar por error a otros servidores de aprovisionamiento del mismo sitio.

Imagen de estructura de sitio de PVS

Hay factores que deben tenerse en cuenta al determinar la topología general de Provisioning Services:

  • Red: Los servidores de aprovisionamiento se comunican constantemente con la base de datos de la comunidad para obtener los parámetros de configuración del sistema. Por lo tanto, se deben crear comunidades independientes para cada ubicación física en la que residen los dispositivos de destino, a menos que estén conectados al servidor de base de datos mediante una conexión rápida y sólida.
  • Administración: Es posible que las organizaciones deban mantener la separación de las funciones administrativas a nivel departamental, regional o nacional. Las comunidades adicionales de Provisioning Services agregarán cierta complejidad a la administración del entorno. Sin embargo, esta sobrecarga suele limitarse a la configuración inicial, la creación de escritorios y las actualizaciones de imágenes.
  • Organización: Una razón práctica para crear varios sitios son los cambios en una organización. Por ejemplo, es posible que dos empresas se hayan fusionado recientemente por adquisición, pero necesitan mantener los recursos separados mientras se lleva a cabo la integración. Configurar la organización para que utilice sitios independientes es una forma de mantener a las empresas separadas pero administradas de forma centralizada a través de la consola de Provisioning Services.

Cree sitios adicionales solamente si los requisitos comerciales lo justifican. Un único sitio por comunidad es más fácil de administrar y no requiere configuración adicional.

Decisión: Colecciones de dispositivos

Las colecciones de dispositivos ofrecen la posibilidad de crear y administrar grupos lógicos de dispositivos de destino. La creación de colecciones de dispositivos simplifica la administración de dispositivos, ya que permite que las acciones se realicen a nivel de la colección en lugar de a nivel de los dispositivos de destino.

Imagen de la estructura de una colección de dispositivos

Las colecciones de dispositivos pueden representar ubicaciones físicas, intervalos de subredes, chasis o diferentes departamentos en una organización. Las colecciones también se pueden utilizar para separar de manera lógica los dispositivos de destino de producción de los de prueba y mantenimiento.

Piense en la posibilidad de crear colecciones de dispositivos según la asignación de discos virtuales para identificar rápidamente el estado de todos los dispositivos de destino asignados a un disco virtual concreto.

Decisión: Alta disponibilidad

Provisioning Services es un componente esencial de la infraestructura de escritorios virtuales. Se deben seguir las siguientes recomendaciones para minimizar los puntos únicos de fallo:

  • Servidor de Provisioning: Siempre deben implementarse al menos dos servidores de aprovisionamiento por sitio. Se debe incorporar una redundancia suficiente en el diseño para que un fallo de un solo servidor no reduzca la cantidad total de dispositivos de destino que pueden admitirse por sitio. El archivo de arranque de Provisioning Services debe configurarse para una alta disponibilidad. En el archivo de arranque se pueden incluir hasta cuatro servidores de Provisioning. Los dispositivos de destino intentarán establecer contacto con los servidores en el orden en que aparecen en la lista. Es posible que el servidor que responde no sea necesariamente el servidor que proporcionará servicios de streaming al dispositivo de destino. Si se habilita el equilibrio de carga, es posible que el dispositivo de destino se reasigne a otro servidor del sitio que esté menos cargado que los demás.
  • Discos virtuales y almacenamiento: Para los almacenes de discos virtuales alojados localmente, en almacenamiento conectado directamente (DAS) o en una red de área de almacenamiento (SAN), la replicación debe utilizarse para sincronizar los discos virtuales. Si utiliza el almacenamiento conectado a la red (NAS), compruebe que los discos virtuales estén alojados en un recurso compartido de red de alta disponibilidad.
  • Redes: Los servidores de aprovisionamiento deben tener tarjetas de interfaz de red redundantes. Si el servidor de aprovisionamiento se implementa como un servidor físico, las tarjetas NIC redundantes deben asociarse y, si el servidor de aprovisionamiento se implementa como un servidor virtual, el hipervisor subyacente debe incorporar tarjetas NIC redundantes.

Nota

Los dispositivos de destino solamente realizan una conmutación por error en las tarjetas NIC que se encuentran en la misma subred que la tarjeta NIC de arranque PXE.

El Protocolo trivial de transferencia de archivos (TFTP) es un protocolo de comunicaciones utilizado para transferir archivos de configuración o arranque entre máquinas. Los servicios de aprovisionamiento pueden utilizar TFTP para entregar el archivo del programa de arranque a los dispositivos de destino. Hay varias opciones disponibles para hacer que el servicio TFTP esté altamente disponible. Algunas de las opciones más utilizadas son:

  • Round robin de DNS: Se crea una entrada DNS para el servicio TFTP con varios registros A correspondientes a los servicios TFTP presentes en los servidores de aprovisionamiento de la comunidad. Este método no se recomienda ya que no se supervisa el estado del servicio TFTP. Podrían enviarse clientes a un servidor que no funciona.
  • Equilibrador de carga de hardware: Utilice un equilibrador de carga de hardware, como, por ejemplo, Citrix NetScaler, para crear IP virtuales que correspondan a los servidores de aprovisionamiento. NetScaler puede redirigir el tráfico de manera inteligente entre los servidores de aprovisionamiento. En caso de que uno de los servidores deje de estar disponible, NetScaler detendrá automáticamente la redirección de solicitudes TFTP a ese servidor. Este es el mejor método para hacer que TFTP esté altamente disponible, pero puede ser complicado de configurar.
  • Varias entradas de la opción 66 de DHCP: Este método es fácil de implementar, pero requiere un servicio DHCP que admita la introducción de varias entradas en la opción 66. El servidor DHCP de Microsoft permite una entrada de la opción 66, por lo que este método no sería factible en entornos con servicios DHCP de Microsoft. Si utiliza un servidor o un dispositivo DHCP que no sean de Microsoft, consulte con el fabricante para comprobar que se admiten varias entradas de la opción 66.

Hay otras opciones disponibles que pueden lograr el mismo resultado sin tener que utilizar TFTP:

  • DHCP proxy: Utilice el servicio PXE de los servidores de aprovisionamiento para proporcionar la información del programa de arranque. Si uno de los servidores está inactivo, el siguiente servidor disponible de la comunidad puede proporcionar dicha información. Este método requiere que los servidores de aprovisionamiento se hallen en el mismo dominio de difusión que los dispositivos de destino. Si hay otros servicios PXE presentes en la red (Altiris, SCCM, etc.), es posible que se necesiten varias redes VLAN para evitar que los servicios PXE interfieran entre sí.
  • Administrador BDM: Utilice el administrador de dispositivos de arranque o BDM para crear un archivo de programa de arranque que se coloca en el disco duro local o se utiliza como archivo ISO de arranque. Si se utiliza el archivo ISO, configure los dispositivos de destino para que se inicien desde la unidad de CD/DVD-ROM y coloque dicho archivo en una ubicación de red compartida de alta disponibilidad o en el almacenamiento local de cada dispositivo de destino. Cuando se utiliza uno de estos dos métodos, el servicio TFTP no se utiliza en absoluto.

La alta disponibilidad siempre debe incorporarse al diseño de Provisioning Services. Aunque es posible que la alta disponibilidad necesite recursos adicionales y un coste superior, ofrecerá un entorno muy estable para reducir al mínimo el impacto que podrían sufrir los usuarios si se produce alguna interrupción de los servicios.

Decisión: Entrega del programa de arranque

Un dispositivo de destino inicia el proceso de arranque al cargar, primero, un programa de arranque que inicializa la sesión de streaming entre el dispositivo de destino y el servidor de aprovisionamiento. Hay tres métodos en los que el dispositivo de destino puede recibir el programa de arranque:

Mediante las opciones de DHCP:

  1. Cuando el dispositivo de destino arranca, el dispositivo de destino difunde la dirección IP y la información de arranque. DHCP procesará esta solicitud y proporcionará una IP y la configuración de las opciones 66 (el nombre o la dirección IP del servidor TFTP de Provisioning Services) y 67 (el nombre del archivo del programa de arranque) del ámbito.

    Nota

    Si utiliza un equilibrador de carga para el servicio TFTP, la dirección del equilibrador de carga se introduce en la opción 66.

  2. Mediante TFTP, se solicita el archivo del programa de arranque desde el dispositivo de destino al servidor de aprovisionamiento. El dispositivo de destino descarga el archivo de arranque del servidor de aprovisionamiento.

  3. El dispositivo de destino arranca con la imagen de disco virtual asignada.

Nota

Se necesita configurar la ayuda de UDP/DHCP cuando los destinos no se hallan en la misma subred que los servidores DHCP para recibir difusiones PXE.

Mediante transmisiones PXE:

  1. Cuando un dispositivo de destino arranca, difunde una dirección IP y la información de arranque. DHCP procesará esta solicitud y proporcionará una dirección IP. Además, todos los servidores de aprovisionamiento que reciben la difusión devolverán la información del servidor de arranque y del nombre del archivo de arranque. El dispositivo de destino combinará la información recibida e iniciará el proceso de arranque.

  2. Mediante TFTP, se solicita el archivo del programa de arranque desde el dispositivo de destino al servidor de aprovisionamiento que responda primero. El dispositivo de destino descarga el archivo de arranque del servidor de aprovisionamiento.

Nota

  • Compruebe que no hay otros servicios PXE activos en la misma subred, como el servicio PXE Altiris; de lo contrario, aíslelos mediante redes VLAN porque, si no, podría haber conflictos con Provisioning Services.
  • Se necesita configurar la ayuda de UDP/DHCP cuando los destinos no se hallan en la misma subred que los servidores DHCP y PVS para recibir difusiones PXE.

Mediante Boot Device Manager: Boot Device Manager (BDM) crea un archivo de arranque que los dispositivos de destino obtienen a través de un CD/DVD físico, una imagen ISO montada o como un disco duro virtual asignado al dispositivo de destino. Una partición de BDM se puede actualizar de una de las tres maneras siguientes:

  • Por colección
  • Por grupo de dispositivos seleccionados
  • Por dispositivo único

En la siguiente tabla hay un resumen de las ventajas y los inconvenientes de cada método de entrega:

Método de entrega Ventajas Inconvenientes
Opciones de DHCP Fácil de implementar Requiere cambios en el servicio DHCP de producción. El servicio DHCP solo puede permitir una entrada de opción 66. Requiere la ayuda de UDP/DHCP para destinos en diferentes subredes.
PXE Fácil de implementar Puede interferir con otros servicios PXE activos en la misma subred. Requiere la ayuda de UDP/DHCP para destinos en diferentes subredes.
ISO de BDM No requiere servicios PXE o TFTP Se necesitan acciones adicionales para arrancar dispositivos de destino físicos. La ISO de BDM se considera un punto de fallo único si se utiliza un solo archivo.
Partición BDM La actualización de la partición de arranque BDM no requiere PXE, TFTP ni TSB; se la considera un cargador de arranque de fase única. En el momento del arranque, encuentra automáticamente toda la información necesaria sobre el servidor PVS y no necesita de servicios externos proporcionados por PXE, TFTP o TSB. Se crea una partición adicional de 8 MB para cada dispositivo de destino.

Nota

Al configurar el archivo del programa de arranque, se pueden enumerar hasta cuatro servidores de aprovisionamiento. El orden en el que aparecen los servidores de aprovisionamiento en la lista determina el orden en que se accede a ellos. Si el primer servidor no responde, se establecerá contacto con el siguiente servidor de la lista.

Decisión: Formato de los discos virtuales

Provisioning Services admite el uso de discos virtuales dinámicos o de tamaño fijo:

  • Disco de tamaño fijo: Para los discos virtuales en modo privado, el tamaño fijo evita la fragmentación del disco y ofrece un mejor rendimiento de escritura en comparación con los discos dinámicos.
  • Disco dinámico: Los discos dinámicos requieren menos espacio de almacenamiento que los discos de tamaño fijo, pero ofrecen un rendimiento de escritura significativamente inferior. Aunque los discos virtuales en modo compartido no escriben en el disco virtual, el tiempo necesario para completar las operaciones de combinación de los discos virtuales se prolongará con los discos dinámicos. Esto no es frecuente, ya que cada vez más entornos eligen crear discos virtuales durante las actualizaciones.

Como la mayoría de las operaciones de lectura tendrán lugar en la caché del sistema en RAM, no hay ningún cambio significativo en el rendimiento tanto si se utilizan discos dinámicos como si se usan de tamaño fijo. Además, los discos dinámicos requieren mucho menos espacio de almacenamiento. Por lo tanto, se recomiendan los discos dinámicos.

Decisión: Replicación de discos virtuales

Los discos virtuales alojados de manera local, en un almacenamiento conectado directamente o en una red SAN deben replicarse en los almacenes de discos virtuales cada vez que se crea o se cambia un disco virtual. Provisioning Services admite la replicación de discos virtuales de almacenes locales en el servidor de aprovisionamiento, así como la replicación en varios sitios con almacenamiento compartido. La replicación de discos virtuales se puede realizar de forma manual o automática:

  • Manual: La replicación manual es simple, pero puede llevar mucho tiempo en función de la cantidad de discos virtuales y almacenes de discos virtuales. Si se produce un error durante el proceso de replicación, los administradores pueden detectarlos de inmediato y tomar las medidas adecuadas para resolverlos. El riesgo de la replicación manual es la incoherencia de los discos virtuales en los servidores de aprovisionamiento, lo que provocará que el equilibrio de carga y la conmutación por error no funcionen correctamente. Por ejemplo, si un disco virtual se replica en tres servidores y uno de los discos virtuales se actualiza, ese disco virtual ya no es idéntico y no se tiene en cuenta si se produce una conmutación por error en el servidor. Aunque se ejecute la misma actualización en dos de los discos virtuales, las marcas de hora de cada uno son diferentes, por lo que los discos virtuales ya no son idénticos.
  • Automatizada: Para entornos grandes, la replicación automatizada es más rápida que el método manual debido a la cantidad de discos virtuales y almacenes de discos virtuales necesarios. Algunas herramientas automatizadas, como Microsoft DFS-R, admiten la limitación del ancho de banda y la compresión diferencial remota entre archivos (CF-RDC), que utilizan la heurística para determinar si los archivos de destino son similares al archivo que se va a replicar. Si es así, CF-RDC utilizará bloques de estos archivos para minimizar la cantidad de datos transferidos a través de la red. El riesgo de la replicación automatizada radica en que el administrador normalmente no supervisa los eventos de replicación en tiempo real y no responde rápidamente cuando se producen errores, a menos que la herramienta de automatización tenga una función para dar alertas. Algunas herramientas se pueden configurar para reiniciar automáticamente el proceso de copia en caso de fallo. Por ejemplo, Robocopy admite la “reanudación de copias” si se interrumpe la conexión de red.

Para proyectos medianos y grandes, utilice una herramienta para automatizar la replicación de discos virtuales. Seleccione una herramienta capaz de reanudar las conexiones si hay interrupciones en la red, copiar atributos de archivo y conservar la marca de hora original.

Nota

El equilibrio de carga y la alta disponibilidad no funcionarán a menos que los discos virtuales tengan marcas de hora idénticas.

Decisión: Tamaño del servidor

Normalmente, un servidor de Provisioning Services se define con las siguientes especificaciones:

Componente Especificación
Modelo Virtual
Procesador Entre 4 y 8 CPU
Memoria Más de 2 GB (cantidad de discos virtuales * 2 GB)
Red Tarjeta NIC de 10 Gbps
Red 40 GB de almacenamiento compartido
Almacenamiento en discos virtuales Según la cantidad de imágenes/revisiones
Sistema operativo Windows Server 2012 R2

Modelo

Citrix Provisioning Services se puede instalar en servidores virtuales o físicos:

  • Virtuales: Ofrecen aprovisionamiento rápido de servidores, instantáneas para casos de recuperación o reversión rápidos y la capacidad de ajustar recursos del servidor sobre la marcha. Los servidores virtuales de aprovisionamiento permiten que los dispositivos de destino se distribuyan entre más servidores, lo que ayuda a reducir el impacto de los fallos de servidor. La virtualización utiliza de forma más eficiente los recursos del sistema.
  • Físicos: Ofrecen un nivel de escalabilidad por servidor superior al de los servidores virtuales. Los servidores físicos de aprovisionamiento mitigan los riesgos asociados a las máquinas virtuales que compiten por recursos de hipervisor subyacentes. En general, se prefieren los servidores virtuales de aprovisionamiento cuando se puede disponer y se garantiza la disponibilidad de suficientes recursos de procesador, memoria, disco y red.

Nota

Para obtener una alta disponibilidad, los servidores virtuales de Provisioning deben distribuirse entre varios hosts de virtualización. La distribución de los servidores virtuales entre varios hosts eliminará un punto de fallo único y no colapsará toda la comunidad de servidores de Provisioning Services en caso de que se produzca un error en el host.

CPU

Provisioning Services no requiere mucha CPU. Sin embargo, si no se asignan suficientes CPU, esto afectará a la optimización de los flujos de red. La cantidad de flujos que un servidor de Provisioning Services puede admitir simultáneamente se determina mediante la siguiente fórmula:

Máximo de flujos = Cantidad de puertos x Cantidad de subprocesos/puerto

De forma predeterminada, el servicio de streaming se configura con 20 puertos de red secuenciales y 8 subprocesos por puerto. Por lo tanto, de forma predeterminada, un servidor de aprovisionamiento puede admitir 160 destinos simultáneos. Si se necesitan más de 160 flujos, Provisioning Services cambia continuamente de dispositivos de destino en streaming.

Idealmente, si el entorno necesita admitir más de 160 destinos simultáneos, la cantidad de puertos y subprocesos por puerto se puede ajustar en la consola de Provisioning Services. El mejor rendimiento se obtiene cuando los subprocesos por puerto no superan la cantidad de núcleos disponibles en el servidor de aprovisionamiento. Si el servidor de aprovisionamiento no tiene suficientes núcleos, el servidor mostrará una mayor utilización de CPU, y los dispositivos de destino a la espera del procesamiento de solicitudes tendrán una latencia de lectura más elevada.

Aunque Provisioning Services no necesita mucha CPU, la asignación de 2 CPU requerirá un intervalo de puertos de red contiguos más amplio.

  • Se recomiendan 4 CPU virtuales para entornos pequeños (hasta 500 máquinas virtuales aproximadamente).
  • Se recomiendan 8 CPU virtuales para entornos más grandes.

RAM

El sistema operativo Windows que aloja Provisioning Services almacena parcialmente en la caché los discos virtuales de la memoria (caché del sistema), lo que reduce las lecturas necesarias desde el almacenamiento. La lectura desde el almacenamiento es significativamente más lenta que la lectura desde la memoria. Por lo tanto, los servidores de Provisioning Services deben tener suficiente memoria asignada para sacar el máximo partido a este proceso de almacenamiento en caché.

La siguiente fórmula se puede utilizar para determinar la cantidad óptima de memoria que se debe asignar a un servidor de aprovisionamiento:

RAM total del servidor = 2 GB + (Cantidad de discos virtuales * 2 GB)

Red

A diferencia de la mayoría de los demás componentes de XenApp y XenDesktop, Provisioning Services no provoca cuellos de botella en la CPU. La escalabilidad de Provisioning Services se basa en el rendimiento de la red.

En la siguiente tabla se muestra la cantidad aproximada de datos que Provisioning Services necesita para arrancar diferentes sistemas operativos:

Sistema operativo Uso medio de datos de arranque (MB)
Windows 10 x64 240
Windows 8 x86 178
Windows 8 x64 227
Windows 7 x86 166
Windows 7 x64 210
Windows 2012 225
Windows 2012 R2 232
Windows 2008 R2 251
Windows Vista x86 190
Windows Vista x64 240

El tiempo necesario para arrancar los dispositivos de destino se puede estimar con la siguiente fórmula:

Imagen de la fórmula de los segundos de arranque

Sistema operativo Cantidad de VM Procesamiento de red Tiempo de arranque
Windows 10 x64 500 1 Gbps 960 segundos (16 minutos)
Windows 10 x64 500 10 Gbps 96 segundos (1 minuto y 36 segundos)

Se recomienda utilizar una red de 10 Gbps con Provisioning Services. Si no hay una red de 10 Gbps disponible, piense en la agregación de enlaces para ofrecer ancho de banda adicional a los servidores de aprovisionamiento, o bien en una red de streaming física dedicada.

Sugerencia

Los firewalls pueden incrementar la latencia y crear cuellos de botella en el ancho de banda en entornos de Provisioning Services. Si no se puede evitar el uso de firewalls, consulte el documento técnico de Citrix CTX101810 (Communication Ports Used By Citrix Technologies) para obtener la lista de los puertos que deben habilitarse para disponer de una funcionalidad completa.

Crecimiento

A medida que crece la comunidad, los administradores tendrán que decidir si agregar más recursos a los servidores de aprovisionamiento o si agregar más servidores de aprovisionamiento a la comunidad.

Hay una serie de factores de entorno que deben tenerse en cuenta al determinar si los servidores de Provisioning deben ampliarse de forma vertical u horizontal:

  • Redundancia: La distribución de la carga de usuarios por más servidores menos potentes ayuda a reducir la cantidad de usuarios afectados por un fallo único de los servidores de aprovisionamiento. Si la empresa no puede permitirse la pérdida de un único servidor de alta especificación, piense en la ampliación horizontal.
  • Tiempos de conmutación por error: Cuantos más dispositivos de destino estén conectados a un único servidor de aprovisionamiento, más tardarán en conmutar en caso de que el servidor falle. Piense en la ampliación horizontal para reducir el tiempo que necesitan los dispositivos de destino para conmutar a otro servidor.
  • Capacidad del centro de datos: Es posible que el centro de datos tenga limitaciones de espacio, energía o refrigeración. Si es así, piense en la ampliación vertical.
  • Costes de hardware: Al principio, la ampliación vertical puede parecer más rentable. Sin embargo, llegará el momento en el que la ampliación horizontal resulte, en realidad, más rentable. Para determinarlo, debe realizarse un análisis de los costes.
  • Costes de alojamiento: Puede haber costes de alojamiento y mantenimiento en función de la cantidad de servidores físicos utilizados. Si es el caso, piense en la ampliación vertical para reducir el coste a largo plazo de estas sobrecargas.

Decisión: Configuración de red

Como se ha mencionado anteriormente, es esencial que el tamaño de la red sea el adecuado para evitar que los cuellos de botella en la red prolonguen el tiempo de acceso al disco y afecten directamente al rendimiento de los escritorios virtuales. En el siguiente diagrama se describe una infraestructura de red común de Provisioning Services:

Imagen de configuración de red PVS de ejemplo

Se recomienda la siguiente configuración de red para la descripción de las secciones de la red dentro del diagrama:

  • Conexión de subida de PVS: Todo acceso a los discos desde los dispositivos de destino se transferirá mediante la conexión de subida de red de PVS. Esto significa que cientos o incluso miles de dispositivos utilizarán esta conexión de red. Por lo tanto, es vital que esta conexión sea redundante y pueda hacer conmutar por error sin que haya tiempo de inactividad. Además, Citrix recomienda un ancho de banda mínimo de 1 Gbps por cada 500 dispositivos de destino. Para los servidores de aprovisionamiento virtuales, se debe configurar una cuota QoS correspondiente o una conexión de subida de red física y dedicada para garantizar un rendimiento óptimo.
  • Conexión de subida de hipervisor: Utilizada por todos los dispositivos de destino de PVS alojados en un host de hipervisor determinado. Por lo tanto, se recomienda encarecidamente la redundancia con conmutación por error transparente. A menos que los dispositivos de destino soporten una elevada carga de trabajo de E/S o realicen tareas con muchas operaciones de E/S (por ejemplo, los arranques) simultáneamente, un ancho de banda de 1 Gbps es suficiente para esta conexión de subida.
  • Conexión de subida de VM: Todo el tráfico de red de una máquina virtual, incluido el tráfico de streaming de PVS, recorrerá esta conexión de red virtual. A menos que la carga de trabajo sea extremadamente elevada en E/S, un ancho de banda de 100 Mbps es suficiente para manejar cargas máximas incluso durante tareas con muchas operaciones de E/S, como los arranques desde discos virtuales. Por ejemplo, un servidor con Windows 2012 R2 leerá aproximadamente 232 MB durante un período de 90 segundos desde el disco virtual hasta que se muestre la pantalla de inicio de sesión de Windows. Durante este período se puede constatar una velocidad media de datos de 20,5 Mbps con picos de hasta 90 Mbps.

Se recomienda la siguiente configuración de cambio para Provisioning Services:

  • Inhabilitar Spanning Tree o Habilitar PortFast: En entornos cambiantes, el protocolo de Spanning Tree o árbol de expansión (STP) pone los puertos en un estado de bloqueo mientras transmite unidades de datos de protocolo puente (BPDU) y escucha para cerciorarse de que las BPDU no están en ninguna configuración de bucle invertido. El puerto no se coloca en un estado de reenvío hasta que la red converge, lo que, en función del tamaño de la red, puede prolongarse lo suficiente como para provocar tiempos de espera del entorno de ejecución anterior al arranque (PXE). Para resolver este problema, inhabilite STP en edgeports conectados a clientes o habilite PortFast.
  • Control de tormentas: El control de tormentas es una función disponible en los conmutadores de Cisco que permite establecer un umbral mediante el cual se puede suprimir el tráfico de multidifusión, difusión o unidifusión. Su propósito es evitar que remitentes dañinos o erróneos inunden una LAN y afecten al rendimiento de la red. Los servidores de PVS pueden enviar una gran cantidad de tráfico por diseño que caiga dentro de un umbral de control de tormentas, por lo que la función debe configurarse en consecuencia.
  • Ayudante de difusión: Se necesita el ayudante de difusión para dirigir las difusiones de los clientes a los servidores que, de otro modo, no se redirigirían. En un entorno de PVS es necesario reenviar solicitudes de arranque PXE cuando los clientes no están en la misma subred que los servidores. Si es posible, el diseño de red recomendado es tener a los servidores de PVS en la misma subred que los dispositivos de destino. Esto mitiga el riesgo de degradación del servicio debido a otros componentes de la infraestructura de red.

Al seleccionar una interfaz de red para Provisioning Services, se deben tener en cuenta las siguientes funciones de interfaz de red:

  • Descarga TCP: La descarga de tareas de E/S a la interfaz de red reduce el uso de CPU y mejora el rendimiento general del sistema; sin embargo, Streaming Service de PVS puede verse afectado de manera negativa cuando la descarga de envíos grandes (Large Send Offload) está habilitada debido al trabajo adicional realizado en el adaptador de red. Muchos adaptadores de red tendrán habilitada de forma predeterminada la descarga de envíos grandes y la descarga de sumas de comprobación TCP.

Nota

Si la descarga de envíos grandes está habilitada y el conmutador por el que pasa el tráfico no admite el tamaño de tramas enviado por el motor de la descarga de envíos grandes, el conmutador quitará la trama que cause la retransmisión de datos. Durante dicha retransmisión, el sistema operativo segmentará las tramas en lugar del adaptador de red, lo que puede provocar una grave degradación del rendimiento.

  • Escalado en el lado de la recepción (RSS): El escalado en el lado de la recepción permite equilibrar los paquetes recibidos de un adaptador de red entre varias CPU, lo que permite equilibrar la carga de las conexiones TCP entrantes y evitar que se produzcan cuellos de botella en una sola CPU. En Windows Server 2008 R2 y Windows Server 2012/2012 R2, RSS está habilitado de forma predeterminada.

Nota

Para obtener más información sobre prácticas recomendadas en redes de PVS, consulte Best Practices for Configuring Provisioning Services Server on a Network.

Para las implementaciones de Provisioning Services en redes de ancho de banda bajo (1 Gbps o más lentas), el rendimiento puede mejorarse al aislar el tráfico de streaming de los demás tráficos de red de la LAN.

Microsoft no admite la formación de equipos de tarjetas NIC con Hyper-V en Windows Server 2008 R2, pero hay soluciones de terceros disponibles. Microsoft admite la formación de equipos de tarjetas NIC con Hyper-V en Windows Server 2012/2012 R2. Todas las consultas de asistencia relativas a la formación de equipos con Hyper-V deben dirigirse al fabricante de la tarjeta NIC en cuestión.

Decisión: Afinidad de subred

La afinidad de subred de Provisioning Services es un algoritmo de equilibrio de carga que ayuda a garantizar que los dispositivos de destino estén conectados al servidor de aprovisionamiento más adecuado. Al configurar la afinidad de subred, se ofrecen las siguientes opciones:

  • None: Ignora las subredes y utiliza el servidor menos ocupado.
  • Best Effort: Utiliza la combinación de tarjeta NIC y servidor menos ocupado desde la misma subred. Si no existe una combinación de servidor y tarjeta NIC disponible en la subred, selecciona el servidor menos ocupado fuera de la subred. Si existen varios servidores disponibles en la subred seleccionada, ejecuta el equilibrio de carga entre esos servidores. Esta es la opción predeterminada.
  • Fixed: Se utiliza la combinación de tarjeta NIC y servidor menos ocupado desde la misma subred. Ejecuta el equilibrio de carga entre los servidores en esa subred. Si no existe una combinación de tarjeta NIC y servidor en la misma subred, no arranque los dispositivos de destino asignados a este disco virtual.

En los ejemplos siguientes se muestran configuraciones de red comunes para servidores físicos de aprovisionamiento. Se pueden implementar configuraciones similares para servidores virtuales de aprovisionamiento sin comprometer el rendimiento ni la funcionalidad.

Diseño de servidor blade

Los servidores de aprovisionamiento y los dispositivos de destino que admiten residen en el mismo chasis. En la mayoría de los casos, el chasis tendrá un conmutador dedicado de 10 Gbps compartido entre todos los servidores blade del chasis.

Imagen del diseño del contenedor del servidor blade

La opción de afinidad de subred “Best Effort” se utiliza para mantener el tráfico de Provisioning Services dentro del mismo chasis. Si el servidor de aprovisionamiento deja de estar disponible, los dispositivos de destino pasarán al segundo servidor de aprovisionamiento del segundo chasis, pero al mismo sitio de Provisioning Services.

Diseño de estanterías

El segundo ejemplo se basa en un diseño de estanterías que emplea conmutadores de estantería para mantener el tráfico de aprovisionamiento dentro de ella.

Imagen del diseño de una estantería de PVS

A diferencia del diseño del chasis del servidor blade, aquí no se utiliza la función de afinidad de subred. En su lugar, se configurará un sitio de Provisioning Services con dos servidores de aprovisionamiento por estantería de servidores. Esto garantizará que los dispositivos de destino se transmitan desde servidores de aprovisionamiento que se hallen en la misma estantería.

Experiencia sobre el terreno

Fabricación: Un fabricante está diseñando una solución de Provisioning Services para admitir cinco mil escritorios virtuales. A la empresa le preocupa que el tráfico de streaming de Provisioning Services cree un cuello de botella en la red y que esto afecte a otras aplicaciones. La empresa eligió crear el entorno en servidores blade para que el tráfico de aprovisionamiento esté contenido dentro del contenedor del servidor blade y no afecte a otros tráficos de la red.

Decisión: Caché de lectura

Con PVS Accelerator, un proxy de PVS puede residir en el dominio de control de XenServer en un host donde el streaming de un disco virtual de Provisioning Services se almacena en caché en el proxy antes de enviarlo a la máquina virtual. Con la memoria caché, los arranques siguientes (o cualquier solicitud de E/S) de la máquina virtual ubicada en el mismo host se pueden distribuir por streaming desde el proxy en lugar de transferirlos desde el servidor a través de la red. PVS Accelerator requiere más recursos locales en el host de XenServer, pero la transmisión por streaming desde el servidor a través de la red ahorra recursos, lo que mejora de manera efectiva el rendimiento.

Imagen de la caché de lectura de PVS

PVS Accelerator es una prestación que solo ofrece en XenServer. El uso de esta tecnología integrada reduce la carga en el servidor de PVS, la utilización general de la red y el tiempo que tarda en arrancar una máquina virtual.

Imagen de PVS Accelerator

Para obtener más información sobre la relación entre XenServer y Provisioning Services, consulte la entrada del blog XenServer and PVS: Better Together.

Decisión: Caché de escritura

Como la imagen maestra es de solo lectura, cada máquina virtual tiene un disco en el que se puede escribir para almacenar todos los cambios. El administrador debe decidir dónde almacenar el disco de caché de escritura.

Servidor de PVS: Almacenamiento local

El almacenamiento local de Provisioning Services contiene las unidades de caché de escritura para cada máquina virtual de destino. Aunque esta es la configuración predeterminada, es cierto que aumenta los requisitos de ancho de banda de red e incrementa el uso del servidor de Provisioning Services.

Imagen del almacenamiento local del lado del servidor

Servidor de PVS: Almacenamiento compartido

El almacenamiento compartido asociado al servidor de Provisioning Services contiene las unidades de caché de escritura para cada máquina virtual de destino. Esta opción aumenta los requisitos de ancho de banda de red e incrementa el uso del servidor de Provisioning Services. También coloca datos temporales (caché de escritura) en un costoso almacenamiento compartido.

Imagen del almacenamiento compartido del lado del servidor

VM: Almacenamiento local

El almacenamiento local asociado a la máquina virtual contiene las unidades de caché de escritura para cada máquina virtual de destino. Esta opción emplea un almacenamiento local de bajo coste y no consume recursos adicionales en el servidor de Provisioning Services. Sin embargo, el almacenamiento local debe ser capaz de admitir las operaciones IOPS de todas las máquinas virtuales del host.

Imagen del almacenamiento local de VM

VM: Memoria caché en RAM

La RAM asociada a la máquina virtual contiene las unidades de caché de escritura para cada máquina virtual de destino. Esta opción ofrece un alto rendimiento debido a la velocidad de la RAM. Sin embargo, si la memoria caché de la RAM se queda sin espacio, la máquina virtual no se podrá utilizar. Para emplear esta opción, se deben asignar cantidades significativas de RAM a cada máquina virtual, lo que incrementa el coste total.

Imagen de la memoria caché de VM en RAM

VM: Memoria caché en RAM con desbordamiento en disco

Se utiliza una combinación de memoria RAM y almacenamiento local para la memoria caché de escritura. En primer lugar, las operaciones de escritura se almacenan en la memoria caché de la RAM, lo que ofrece un alto rendimiento. A medida que se consume la memoria caché de la RAM, los bloques grandes se eliminan de la caché de la RAM y se colocan en el disco de caché de escritura del almacenamiento local. Esta opción permite un rendimiento elevado con un coste reducido de almacenamiento local.

El uso de esta tecnología integrada reduce las operaciones IOPS de escritura en un 95%.

Imagen de la memoria caché de VM en RAM

La opción recomendada es la caché en RAM con desbordamiento en disco.

Imagen de la memoria caché de VM en RAM

Decisión: Antivirus

De forma predeterminada, la mayoría de los productos antivirus analizan todos los archivos y procesos, lo que causa un impacto significativo en el rendimiento de Provisioning Services. Para obtener más información sobre cómo se puede optimizar el software antivirus para Provisioning Services, consulte CTX124185: Provisioning Services Antivirus Best Practices.

El software antivirus puede causar problemas por bloqueo de archivos en los servidores de aprovisionamiento. El almacenamiento de discos virtuales y la caché de escritura deben excluirse de los análisis antivirus para evitar problemas de contención de archivos.

Cuando un disco virtual se halla en modo estándar y necesita reiniciarse, descarga todas las definiciones de virus cargadas anteriormente. Esto puede empobrecer el rendimiento al reiniciar varios dispositivos de destino a la vez, lo que a menudo provoca una congestión de la red, mientras que la operación persiste. En casos extremos, el dispositivo de destino y el servidor de aprovisionamiento pueden ralentizarse y consumir más recursos de los necesarios. Si el software antivirus lo admite, los archivos de definición se deben redirigir a la unidad de caché de escritura para que se conserven después de cada reinicio.

Machine Creation Services

Machine Creation Services (MCS) emplea una tecnología de clonación de discos para simplificar la implementación de máquinas virtuales. Los equipos se aprovisionan y se reaprovisionan en tiempo real a partir de una misma imagen de disco compartida. De esta forma, los administradores no necesitan administrar ni instalar parches para cada sistema individualmente. En vez de eso, los administradores llevan a cabo toda la administración de imágenes en la imagen maestra.

Decisión: Ubicación de almacenamiento

Machine Creation Services permite a los administradores dividir un escritorio virtual en varios componentes y almacenar esas piezas en diferentes matrices de almacenamiento.

Almacenamiento compartido

La primera opción utiliza el almacenamiento compartido para el disco del sistema operativo y el disco de diferenciación.

Imagen del almacenamiento compartido de MCS

Aunque esta opción permite compartir la imagen maestra en varios hosts de hipervisor, ejerce una mayor presión en la matriz de discos de almacenamiento, ya que también debe alojar el disco de diferenciación, que son datos temporales.

Almacenamiento híbrido

La segunda opción utiliza el almacenamiento compartido para el disco del sistema operativo y el almacenamiento de hipervisor local para el disco de diferenciación.

Imagen del almacenamiento híbrido de MCS

Esta es la opción más común, la cual ofrece al administrador las ventajas de compartir la imagen maestra en varios hosts de hipervisor mientras descarga operaciones IOPS de escritura costosas y temporales en un almacenamiento de hipervisor local barato.

Almacenamiento IntelliCache de XenServer

La tercera opción utiliza el almacenamiento compartido para el disco del sistema operativo, el almacenamiento de hipervisor local para el disco de diferenciación y el almacenamiento local de XenServer para una caché local del disco del sistema operativo.

Esta opción es exclusiva para las implementaciones de XenServer. Ofrece el mismo valor que la estrategia del almacenamiento híbrido, al tiempo que reduce las operaciones IOPS de lectura del almacenamiento compartido. Si la RAM de XenServer es limitada, IntelliCache puede coexistir con la caché de lectura basada en la RAM de XenServer.

Imagen de IntelliCache de MCS

Decisión: Tipo de clonación

Machine Creation Services incorpora dos tipos de técnicas de clonación.

  • Ligera: Cada VM del catálogo utiliza un único disco virtual de solo lectura para todas las lecturas. Un segundo disco virtual, único para cada VM, captura toda la actividad de E/S de escritura.
  • Completa: Cada VM del catálogo recibe una copia completa de la imagen de disco maestra. Cada máquina virtual posee completamente el disco, lo que permite la actividad de lectura/escritura. La tecnología de clonación completa solo está disponible para escritorios virtuales personales, donde una máquina virtual dedicada guarda todos los cambios en un disco local.

Los administradores deben tener en cuenta lo siguiente al decidir entre la tecnología de clonación ligera y la completa:

  Clon ligero Clon completo
Requisitos de espacio de almacenamiento Tiene el mayor ahorro de espacio de almacenamiento. Se comparte una única imagen de disco maestra en varias máquinas virtuales. Solo el disco de diferenciación (las operaciones de escritura) consume espacio, que continúa creciendo hasta que se reinicia la VM. Se necesita mucho espacio de almacenamiento. Cada VM recibe una copia completa de la imagen maestra. El tamaño sigue creciendo a medida que se aplican cambios en la máquina virtual.
Copia de seguridad/Restauración Difícil. Muchas soluciones de terceros de copia de seguridad o recuperación ante desastres no admiten discos instantáneos o delta, lo que dificulta o imposibilita que las copias de seguridad o el traslado a otras matrices de almacenamiento de las máquinas virtuales aprovisionadas. Fácil. La VM existe en un solo disco virtual, lo que facilita la copia de seguridad y la restauración.
Velocidad de aprovisionamiento Rápido. Solo se necesita una imagen de disco. Lento (puede mitigarse). Cada VM requiere una copia completa de la imagen maestra. Las tecnologías de optimización del almacenamiento de información pueden ayudar a mitigar este problema.
Rendimiento Más lento. Una operación de E/S de lectura puede llevarse a cabo dos veces: una para el disco maestro y otra para el disco de diferenciación, lo que aumenta la cantidad de operaciones IOPS de lectura. Más rápido. Todas las operaciones de lectura/escritura se dirigen a un solo disco.
Múltiples arranques simultáneos Impacto elevado. En caso de múltiples arranques simultáneos, todos los discos de diferenciación se redimensionan para contener todas las operaciones de escritura desde el inicio de Windows, lo que aumenta la carga en el almacenamiento ya que todo ocurre a la vez. Impacto reducido.

Decisión: Caché de lectura

Durante el arranque y el inicio de sesión, los escritorios virtuales experimentan un nivel elevado de operaciones IOPS de lectura en el almacenamiento, lo que puede ejercer presión en el subsistema de almacenamiento subyacente. Al implementarse en Citrix XenServer, los modos de VDI compartidos y agrupados emplean una caché de lectura basada en RAM alojada en cada XenServer.

Imagen de la caché de lectura de MCS

El uso de esta tecnología integrada reduce las operaciones IOPS de lectura entre un 50 y un 80%.

Imagen de la matriz de la caché de lectura de MCS

Decisión: Caché de escritura

Durante estados estacionarios, los escritorios virtuales experimentan un nivel elevado de operaciones IOPS de escritura en el almacenamiento, lo que puede ejercer presión en el subsistema de almacenamiento subyacente. Los modos VDI compartidos y agrupados pueden utilizar una caché de escritura basada en RAM con la RAM de grupos no paginada del sistema operativo de las máquinas virtuales.

Imagen de la caché de escritura de MCS

El uso de esta tecnología integrada reduce las operaciones IOPS de escritura en un 95%.

Imagen de la matriz de la caché de escritura de MCS

Seguridad

En función de los requisitos de la organización, se deben implementar diferentes estándares de seguridad dentro de la solución. Es aconsejable consultar los siguientes documentos:

Capa de control de la metodología de diseño