Arquitectura de referencia empresarial de XenServer®

Descripción general

Esta arquitectura de referencia define un enfoque recomendado para diseñar, implementar y operar XenServer con el fin de admitir cargas de trabajo a escala empresarial. Proporciona una base validada para alojar entornos de Citrix Virtual Apps and Desktops™ (CVAD), así como la virtualización general de servidores, con un enfoque en la escalabilidad, la resiliencia y la simplicidad operativa.

La arquitectura se basa en el concepto del grupo de recursos de XenServer como la unidad central de escala y administración. Cada grupo de recursos está diseñado para operar dentro de un único centro de datos (o un conjunto de centros de datos estrechamente conectados) y admite una ejecución de cargas de trabajo predecible y de alto rendimiento. Las implementaciones se pueden escalar horizontalmente añadiendo grupos de recursos adicionales para satisfacer las crecientes necesidades de capacidad y organizativas.

Principios de diseño

Los siguientes principios resumen el enfoque de diseño:

• Grupo de recursos como unidad de escala: Implemente y administre cargas de trabajo dentro de grupos de recursos bien definidos, y escale horizontalmente añadiendo grupos adicionales.
• Aislamiento de cargas de trabajo por diseño: Alinee los grupos de recursos con tipos de cargas de trabajo específicos para garantizar un rendimiento y un comportamiento operativo coherentes.
• Modelo de capacidad N+1: Mantenga una capacidad suficiente para tolerar un único fallo de host sin afectar la disponibilidad de la carga de trabajo.
• Separación de responsabilidades: Separe claramente el tráfico de administración, de máquinas virtuales y de almacenamiento para garantizar el rendimiento, la resiliencia y la seguridad.
• Estrategia de resiliencia explícita: Trate la resiliencia dentro del centro de datos y la recuperación ante desastres entre centros de datos como preocupaciones arquitectónicas distintas.
• Simplicidad operativa: Introduzca capacidades opcionales solo cuando proporcionen un valor claro, evitando complejidades innecesarias.

Juntos, estos principios proporcionan un marco coherente para diseñar entornos XenServer que sean escalables, resilientes y fáciles de operar, al tiempo que se mantienen adaptables a las cargas de trabajo y los requisitos organizativos en evolución.

Esta arquitectura asume el uso de almacenamiento en bloque remoto, gestión de identidades integrada a través de Active Directory y gestión segura mediante TLS. Las capacidades opcionales como el equilibrio de carga de trabajo (WLB), la alta disponibilidad (HA) y la recuperación ante desastres (DR) pueden incorporarse según los requisitos de la carga de trabajo, pero cada una introduce consideraciones operativas adicionales que deben planificarse explícitamente. La arquitectura de referencia está destinada a entornos empresariales que requieren un rendimiento predecible y un fuerte control operativo. No está optimizada para escenarios especializados como discos de máquinas virtuales individuales muy grandes (>2 TB) o cargas de trabajo intensivas en GPU, que pueden requerir diseños o adaptaciones alternativas.

En general, este documento sirve tanto como guía de diseño como marco operativo, lo que permite a las organizaciones implementar XenServer de manera coherente y compatible, manteniendo la flexibilidad para extender y evolucionar la plataforma con el tiempo.

Suposiciones y alcance

La arquitectura se basa en un conjunto de suposiciones fundamentales sobre la escala, la infraestructura y las prácticas operativas.

• Todo el hardware utilizado debe figurar en la Lista de compatibilidad de hardware (HCL) de XenServer.

• Se espera que cada grupo de recursos admita hasta 1000 máquinas virtuales, con implementaciones generales que escalan añadiendo grupos adicionales en lugar de expandir un solo grupo indefinidamente, hasta un máximo de 200 grupos. Se asume que todos los hosts dentro de un grupo operan dentro de un límite de red estrechamente acoplado, lo que garantiza un acceso coherente y fiable al almacenamiento compartido.
  • Los hosts deben tener suficiente RAM para admitir la carga de trabajo requerida y el dominio de control con cualquier requisito de caché de rendimiento (consulte Dimensionamiento del grupo de recursos), hasta un máximo de 6 TB.
  • Los hosts deben tener almacenamiento local para el SO XenServer (mínimo 46 GB, idealmente 70 GB) o la capacidad de arrancar desde SAN.

• Se asume que el almacenamiento se proporciona a través de sistemas remotos basados en bloques, con XenServer utilizando repositorios de almacenamiento basados en LVM. La eficiencia y la resiliencia se proporcionan principalmente por la plataforma de almacenamiento subyacente, incluidas capacidades como el aprovisionamiento ligero para permitir la asignación activa en uso y la rutas múltiples. La conectividad de almacenamiento continua y fiable es un requisito fundamental.

• La red sigue un modelo de estricta separación entre el tráfico de administración, de máquinas virtuales y de almacenamiento. Para lograr esto, los hosts deben estar equipados con un mínimo de 2 NIC y 2 conexiones de canal de fibra, o 4 NIC. Esta separación se combina con interfaces de red enlazadas para proporcionar resiliencia y rendimiento, al tiempo que se evitan configuraciones que introduzcan dependencias innecesarias o limitaciones de rendimiento.

• La seguridad y la identidad se tratan como parte integral del diseño. Las comunicaciones de administración se protegen mediante TLS, y se asume la integración con Active Directory para la autenticación y el control de acceso basado en roles. Se espera que el acceso administrativo siga las prácticas de seguridad empresariales estándar, con un uso restringido de cuentas locales y una exposición controlada de las interfaces de administración.

• Operativamente, los grupos de recursos están diseñados en torno a un modelo de capacidad N+1, lo que permite que las cargas de trabajo sigan ejecutándose durante el mantenimiento del host o en caso de fallo de un solo host. Se espera que las actualizaciones y mejoras se apliquen regularmente para mantener la compatibilidad y la seguridad. Cuando se requiere la recuperación ante desastres, se implementa como un proceso operativo coordinado en lugar de una capacidad de conmutación por error perfecta o totalmente automatizada.

Se pueden incorporar capacidades opcionales cuando sea necesario, pero no se asumen por defecto. Estas incluyen:

• Equilibrio de carga de trabajo (WLB)
• Alta disponibilidad (HA) para cargas de trabajo
• Recuperación ante desastres (DR) entre centros de datos

Cada una de estas introduce una complejidad operativa adicional y debe adoptarse en función de requisitos claros de carga de trabajo y de negocio.

Fuera del alcance

Esta arquitectura de referencia no está diseñada para todos los escenarios y no debe tratarse como una solución universal. En particular, no aborda directamente:

• Cargas de trabajo que requieren discos virtuales individuales de más de 2 TB
• Cargas de trabajo aceleradas por GPU o dependientes de GPU
• Arquitecturas que requieren una movilidad de carga de trabajo activa-activa y sin interrupciones entre centros de datos geográficamente dispersos

En estos casos, los elementos de este diseño aún pueden ser aplicables, pero se requerirán consideraciones y adaptaciones arquitectónicas adicionales.

Definiciones

Términos y definiciones para facilitar la lectura y comprensión de esta arquitectura de referencia.

Plano de arquitectura

Las expectativas para los grupos de recursos son las siguientes:

• Cada grupo de recursos está diseñado para hasta 1000 máquinas virtuales en ejecución.
• Cada grupo de recursos está ubicado completamente dentro de un único centro de datos o entre centros de datos cercanos.
• Cada grupo de recursos se destina a un caso de uso específico, donde todas las cargas de trabajo tienen características similares en cuanto a disponibilidad y rendimiento. Para implementaciones pequeñas, son posibles los casos de uso mixtos, pero se debe tener cuidado al considerar el equilibrio de carga y los modos de fallo de los grupos de recursos.

Ejemplos de casos de uso únicos son:

• Escritorios virtuales para una implementación de CVAD
• Servidores de aplicaciones para una implementación de CVAD
• Infraestructura CVAD
• Cargas de trabajo de virtualización de servidores generales

Cada pool de recursos tendrá los siguientes atributos

• Protocolo LVM utilizado para todo el almacenamiento de bloques remoto. No se recomienda utilizar el protocolo GFS2.
• Alta disponibilidad para la gestión del Coordinador de Pool
• Uso de TLS 1.2 para todas las comunicaciones de gestión
• Opcional: Equilibrio de carga de trabajo (WLB) para las VM de carga de trabajo
• Opcional: Alta disponibilidad (HA) de las VM de carga de trabajo
• Opcional: Recuperación ante desastres (DR)
• Opcional: XenServer Conversion Manager instalado

Nota:

El diseño se puede escalar creando múltiples pools de recursos dentro de los centros de datos o entre ellos para proporcionar la carga de trabajo donde sea necesaria.

Construya cada pool de recursos según se define en las secciones siguientes.

Configuración del Pool de Recursos Principal

Al construir un nuevo pool de recursos, la mejor práctica es configurar un host independiente con la configuración de red y almacenamiento según sea necesario, y luego añadir otros hosts a este pool. Los hosts adicionales adquirirán la configuración a medida que se añadan al pool de recursos.

Configurar el control de acceso basado en roles

Conecte todos los grupos de recursos a un dominio de Active Directory de confianza para permitir que los usuarios y grupos de AD se administren y auditen fácilmente, y para controlar el acceso y los permisos a los grupos de recursos de XenServer.

Nota:

No utilice la cuenta predeterminada (root) para la administración, excepto en condiciones de emergencia en las que no sea posible autenticarse mediante credenciales de AD (por ejemplo, fallo del controlador de dominio de AD).

Aprovisionamiento de certificados para hosts

Todos los hosts de todos los grupos de recursos deben tener un certificado TLS aprovisionado para su uso en la red de administración. Para las cargas de trabajo CVAD, los hosts deberán ser resolubles por su FQDN en DNS.

Todos los hosts deben tener un certificado aprovisionado; este puede ser un certificado comodín compartido o un certificado por host.

Nota:

Algunas aplicaciones que utilizan las API de XenServer, como algunas versiones anteriores de Citrix Apps and Desktops, requieren el uso de un certificado individual para cada host y no permiten el uso de certificados comodín. Consulte la documentación pertinente para obtener más detalles:

• DaaS
• CVAD 2507 y posteriores
• CVAD anterior a 2507

Cualquier conexión de terceros al grupo de recursos debe utilizar TLS y el FQDN para direccionar los hosts en el grupo de recursos.

Protección de la comunicación con el grupo de recursos

• Deshabilitar el puerto 80
• Establezca SSH en modo Automático para que, si el conjunto de herramientas de administración falla, SSH se habilite automáticamente.

Configuración de red del grupo de recursos

Se requiere separación para las siguientes redes:

• Red de administración
• Red de máquinas virtuales
• Red de almacenamiento (si se utiliza almacenamiento basado en red)

Esta separación se puede proporcionar mediante NICs separadas o mediante el uso de VLANs con las mismas NICs. Si se utiliza almacenamiento basado en red, se recomienda encarecidamente usar NICs separadas por razones de rendimiento.

Redes de administración y de máquinas virtuales

Las redes de administración y de máquinas virtuales deben operar en NICs enlazadas para proporcionar resistencia y rendimiento.

Los enlaces deben configurarse como enlaces LACP siempre que sea posible para garantizar la mejor respuesta a la pérdida de conectividad al tiempo que se maximiza la disponibilidad del ancho de banda. Esto requerirá que los conmutadores se configuren de forma coincidente. Si los conmutadores no se pueden configurar para admitir LACP, la configuración activo-activo es beneficiosa para las redes de máquinas virtuales. Las redes de administración pueden usar activo-pasivo sin ningún impacto. Para obtener más información, consulte Tipos de enlace.

Siempre que sea posible, los conmutadores deben estar interconectados con las NICs para garantizar que no haya un único punto de fallo en el transporte de red y deben usar fuentes de alimentación separadas o redundantes; consulte Prácticas recomendadas de red para obtener todos los detalles.

Todos los hosts del grupo deben tener direcciones IP fijas en la red de administración; XenServer no admite el escenario en el que la dirección IP del host emitida por DHCP cambia. Si se utilizan direcciones DHCP fijas, se debe esperar que el entorno DHCP esté disponible de forma fiable (por ejemplo, como parte de la infraestructura de red) y no debe ser proporcionado por una máquina virtual que se ejecute en un host que dependa de ese servidor DHCP. Se recomienda el direccionamiento estático para la infraestructura.

Todas las redes de administración de hosts deben permitir la conexión a servidores NTP sincronizados para garantizar que sus relojes permanezcan alineados; esta debe ser la misma fuente de tiempo que se utiliza para el Active Directory que proporciona las cuentas de equipo y de usuario para el control de acceso basado en roles para garantizar que no se produzca una desviación del reloj que interrumpa las rutas de comunicación. Esto también garantizará que haya marcas de tiempo coherentes para todos los registros del sistema.

Los requisitos completos de conectividad necesarios para habilitar el funcionamiento del entorno se enumeran aquí.

Redes de almacenamiento

Cuando se utiliza almacenamiento basado en red, la mejor práctica es usar el soporte de rutas múltiples del almacenamiento, lo que requiere redes independientes (es decir, subredes diferentes). Esto normalmente significa usar NIC individuales en lugar de enlaces y configurar las subredes apropiadas en cada una. Consulte a su proveedor de almacenamiento para obtener más recomendaciones.

Configuración del almacenamiento del grupo de recursos

Se debe habilitar la función de rutas múltiples. Esto debe configurarse individualmente en todos los hosts, y debe haber al menos 2 rutas disponibles para todos los recursos de almacenamiento. Estas rutas deben ser diversas a través de la infraestructura de red/canal de fibra.

LVM es un almacenamiento de aprovisionamiento grueso, por lo que XenServer requerirá la cantidad total de almacenamiento necesaria para los discos de VM creados. Esto significa que cada disco y plantilla ocupará la capacidad total disponible, incluso si solo se utilizan pequeñas porciones de esos discos.

La recomendación es utilizar SAN que proporcionen su propia función de aprovisionamiento ligero para garantizar un uso eficiente del almacenamiento. El aprovisionamiento ligero de la SAN utiliza mejor el almacenamiento disponible asignando espacio de almacenamiento en disco a las VDI a medida que se escriben datos en el disco virtual, en lugar de asignar el tamaño virtual completo de la VDI por adelantado. La cantidad de almacenamiento utilizada debe ser monitoreada cuidadosamente por el administrador utilizando las herramientas proporcionadas por el proveedor de la SAN.

Si se utiliza el aprovisionamiento ligero en la SAN, es importante monitorear la utilización del almacenamiento; si la capacidad de la SAN se agota de tal manera que no se pueden realizar más escrituras, esto puede provocar fallos en las VM y/o corrupción de datos.

Si se utiliza MCS para aprovisionar cargas de trabajo para entornos Citrix®, se recomienda usar un número reducido de LUN grandes para esto, ya que la imagen dorada debe copiarse en todos los LUN, lo que puede ser lento y hacer que el aprovisionamiento de imágenes tarde un tiempo considerable, retrasando el despliegue de imágenes actualizadas.

Estrategia de resiliencia

Los grupos de recursos de XenServer, junto con sus recursos de almacenamiento, operan dentro de un único centro de datos (o dentro de una colección de centros de datos cercanos).

Estos grupos de recursos se pueden configurar para ser resilientes a fallos locales de servidor, almacenamiento y red dentro del centro de datos. Además, los grupos de recursos se pueden usar en combinación para proporcionar funciones de recuperación ante desastres en caso de que un centro de datos falle y cause la pérdida de un grupo de recursos completo.

Estos se consideran por separado a continuación.

Resiliencia dentro de un centro de datos

Si bien las cargas de trabajo dentro de un centro de datos pueden protegerse mediante una configuración completa de DR como se describe a continuación, existen mecanismos de resiliencia dentro de cada grupo de recursos para garantizar la alta disponibilidad de los recursos. Estos mecanismos están diseñados para ser automatizados y utilizados con mayor frecuencia para proteger contra problemas más comunes y localizados. Las siguientes facilidades están disponibles:

• Alta disponibilidad de la administración (mediante elecciones de coordinador automatizadas durante interrupciones no planificadas)
• Alta disponibilidad de cómputo de cargas de trabajo (mediante reinicio automático de VM en interrupciones no planificadas)
• Resiliencia del almacenamiento (mediante rutas múltiples de almacenamiento)
• Resiliencia de la red (mediante la agregación de enlaces de red y las configuraciones de conmutadores)

Para lograr esto, se espera que el grupo de recursos opere con un mínimo de N+1 hosts, donde N es el número de hosts necesarios para operar la carga de trabajo. Esto proporciona la capacidad de operar el grupo de recursos a plena capacidad con un host no disponible.

Nota:

La capacidad de host N+1 permite actualizar y mejorar los grupos de recursos sin interrupciones en la carga de trabajo, lo que facilita la aplicación de actualizaciones de seguridad y mejoras de funciones.

Estas facilidades proporcionarán una implementación altamente resiliente que se opera completamente dentro de un centro de datos o a través de centros de datos cercanos. No admitirá la resiliencia a través de centros de datos geográficamente dispersos. La única forma de admitir esto es a través de la función de DR descrita a continuación (consulte Resiliencia entre centros de datos).

Capacidades opcionales

Equilibrio de carga de trabajo (WLB)

• Usar cuando: Las cargas de trabajo de VM tienen patrones de utilización materialmente diferentes y variables en el tiempo durante su ejecución, y se desean recomendaciones automatizadas y/o reequilibrio para mantener el rendimiento.
• Evitar cuando: Las cargas de trabajo son muy uniformes (por ejemplo, muchas VM VDI no persistentes similares) donde la ubicación inicial y las operaciones normales del ciclo de vida ya proporcionan un equilibrio adecuado, o donde las migraciones son operativamente indeseables.
• Impacto operativo: Añade un dispositivo adicional para operar y supervisar; incluye una ventana de mantenimiento diaria durante la cual el procesamiento de WLB no está disponible.

WLB se puede utilizar para mantener la mejor utilización y rendimiento del host a medida que el uso de la carga de trabajo cambia con el tiempo.

Importe el dispositivo al grupo de recursos y utilice la red de administración para su conectividad. El dispositivo de equilibrio de carga de trabajo (WLB) se puede descargar desde la página de descargas de XenServer.

Se debe utilizar el tamaño predeterminado para el dispositivo (2 GB de RAM, 30 GB de disco y 2 vCPU).

Idoneidad de la carga de trabajo

WLB solo debería ser necesario cuando la demanda de carga de trabajo cambia dinámicamente dentro de las máquinas virtuales a lo largo de su vida útil. Si se utiliza WLB, cada vez que una máquina virtual se detiene y se inicia de nuevo, se coloca de forma óptima para la carga de trabajo actual de inmediato, por lo que las máquinas virtuales solo deberían necesitar moverse a medida que cambia la utilización del host. Cuando el caso de uso proporciona muchas máquinas virtuales similares que realizan tareas similares, hay poco valor en usar WLB y puede confiar en la ubicación inicial de la máquina virtual para proporcionar el equilibrio de carga de trabajo.

Ajustar la ventana de mantenimiento de la base de datos

El dispositivo WLB realiza un mantenimiento rutinario diariamente. Por defecto, esto ocurre a las 00:05 UTC. Esto debe configurarse para que ocurra cuando haya poca actividad en el grupo de recursos, ya que habrá una interrupción del procesamiento de WLB de hasta 30 minutos durante este proceso. Esto no afecta el funcionamiento normal, solo las decisiones de optimización de la ubicación; WLB completará las acciones tan pronto como se complete su mantenimiento.

Configuración de parámetros de WLB

Muchos ajustes de configuración pueden dejarse como predeterminados. Esto configurará la función WLB para hacer recomendaciones a un administrador, y el administrador tendrá que aplicar estas acciones.

La configuración predeterminada y esperada para este plano solo requiere que se ajusten los ‘Umbrales críticos’ y las ponderaciones para permitir que los grupos de recursos operen al máximo rendimiento. Estos pueden optimizarse con el uso, pero algunos valores iniciales sugeridos son los siguientes:

• Utilización de CPU: El valor predeterminado para esto es un umbral crítico del 90% con una ponderación máxima. Esto asegurará que una vez que la CPU de un host alcance una carga promedio del 90% durante los últimos 1,5 minutos, el servicio WLB evaluará ubicaciones alternativas para ejecutar las máquinas virtuales.

  • Si el rendimiento de sus máquinas virtuales se ve afectado por utilizaciones de CPU más bajas, puede ajustar este umbral crítico con el objetivo de mantener el uso promedio de CPU en un valor más bajo en todos los hosts, siempre que sea posible.
  • Valor de umbral crítico inicial recomendado: 90%
  • Valor de ponderación de métrica inicial recomendado: Más importante
• Memoria libre: No hay un rendimiento específico que se gane al mantener memoria libre en los hosts, por lo que migrar máquinas para mantener la memoria libre es una sobrecarga que no es necesaria.
  • Valor de umbral crítico inicial recomendado: 0
  • Valor de ponderación de métrica inicial recomendado: Menos importante
• Lectura y escritura de red: Los valores predeterminados para estos son 25 MB/s. Esto significa que si algún host está utilizando más ancho de banda para lecturas o escrituras, se considerará para reubicación. Este parámetro no es relevante a menos que tenga algunas máquinas virtuales ejecutando cargas de trabajo de red pesadas y sea relevante evitar el impacto en otras máquinas virtuales.
  • Para muchas aplicaciones, este no es un factor relevante, y la ponderación debe establecerse en la configuración menos importante.
  • Para muchas redes modernas, este es un valor muy bajo y, si esta configuración es relevante, recomendamos establecerla para permitir un buen uso de este ancho de banda antes de considerar la migración a otro host.
  • Valor de umbral crítico inicial recomendado: 90% del ancho de banda disponible
  • Valor de ponderación de métrica inicial recomendado: Importancia media
• Lectura y escritura de disco: Los valores predeterminados para esto son 25 MB/s. Esto significa que si algún host está utilizando más ancho de banda para lecturas o escrituras, se considerará para reubicación. Este parámetro no es relevante a menos que tenga algunas VM ejecutando cargas de trabajo de disco pesadas y evitar el impacto en otras VM sea relevante. Si se utiliza almacenamiento remoto, a menos que el ancho de banda de la estructura sea el cuello de botella, esto no tiene valor, ya que cualquier impacto en el almacenamiento remoto afectará el rendimiento de todas las VM que utilicen ese almacenamiento, independientemente del host en el que se esté operando.
  • Para la mayoría de los almacenamientos y estructuras modernos, este es un valor bajo y, si esta configuración es relevante, debe establecerse en un valor más alto para permitir un buen uso del ancho de banda. Esto debe establecerse lo suficientemente alto como para que el mantenimiento regular fuera del horario laboral en las VM no provoque una migración masiva cuando no sea necesario.
  • Valor de umbral crítico inicial recomendado: 90% del ancho de banda disponible
  • Valor de ponderación de métrica inicial recomendado: Importancia media

Alta disponibilidad (HA) para el grupo de recursos

La documentación completa de HA está disponible aquí

Hay 2 elementos a considerar para XenServer con respecto a la alta disponibilidad

• HA de gestión: La capacidad de mantener automáticamente las operaciones de gestión cuando hay una interrupción inesperada del host coordinador en el grupo de recursos
• HA de VM: La capacidad de mantener las operaciones de carga de trabajo cuando hay una interrupción inesperada de un host en el grupo de recursos

Ambos aspectos requieren configuraciones específicas de almacenamiento y red. Esto se cubre en las secciones siguientes.

Uno de los LUN de almacenamiento disponibles se seleccionará como el SR de latido de XenServer (consulte Latidos para la disponibilidad para una explicación completa de este requisito). Si hay más de un LUN disponible, no importa cuál se seleccione. Se asignará una pequeña cantidad (<5 GB) de espacio de este LUN para proporcionar la función de HA.

Esta arquitectura de referencia está diseñada para soportar el mantenimiento de la carga de trabajo dentro de los límites de la pérdida inesperada de un solo host. La configuración ‘Fallos a tolerar’ debe establecerse en 1.

Nota:

Es importante tener en cuenta las siguientes características al usar HA

• El pool de recursos debe tener al menos 3 hosts
• El fencing se refiere al mecanismo que aísla forzosamente un host que se considera fallido o inseguro, asegurando que no pueda acceder a recursos compartidos (especialmente almacenamiento compartido) antes de que las máquinas virtuales se reinicien en otro lugar. Cuanto mayor sea el pool de recursos, mayor será el impacto del fencing del host y más probable será que ocurra debido a los requisitos de la ruta de comunicación. Se debe prestar especial atención a este respecto a los pools >16 hosts.
• HA debe deshabilitarse durante las operaciones de mantenimiento del host / pool de recursos para reducir el riesgo de interrupciones inesperadas mientras se realizan estas actividades de mantenimiento.
• Al usar HA, se debe tener cuidado para asegurar que la conectividad de almacenamiento al SR del archivo de estado de HA y la red no se interrumpan. La interrupción de estas conexiones puede hacer que los hosts se aíslen inesperadamente para proteger las operaciones del pool de recursos. Esto significa que se debe prestar especial atención al realizar el mantenimiento de la infraestructura para asegurar que no se pierda la conectividad.

Enfoques alternativos para HA de gestión

Si utiliza HA para proporcionar conectividad de gestión fiable y de alta disponibilidad, entonces también deben considerarse los siguientes enfoques para evitar las limitaciones mencionadas anteriormente.

Implementar la monitorización del host

Integre los hosts de XenServer con una solución de monitorización de terceros para detectar cuándo un host no responde.

Recuperar manualmente la conectividad de gestión

Si el host que no se puede contactar es el coordinador y las operaciones de gestión no están disponibles, entonces todos los demás hosts en el pool de recursos entrarán en modo de emergencia y permitirán que se establezca conectividad remota con ellos para elegir a uno de ellos como nuevo coordinador del pool. Esto se puede realizar utilizando los enlaces de lenguaje remoto. A continuación se muestran ejemplos para xe CLI y PowerShell.

xe CLI:

xe -s <server_IP> -u <username> -pw <password> host-is-in-emergency-mode                     -> Confirm election possibility
xe -s <server_IP> -u <username> -pw <password> pool-emergency-transition-to-master           -> Designate current host as new master
xe -s <server_IP> -u <username> -pw <password> pool-recover-slaves                           -> Reconfigure member servers to new coordinator

<!--NeedCopy-->

PowerShell:

Invoke-XenPool -XenAction EmergencyTransitionToMaster          -> Designate current host as new master
Invoke-XenPool -XenAction RecoverSlaves                        -> Reconfigure member servers to new coordinator

<!--NeedCopy-->

HA de VM

VM de equilibrio de carga de trabajo (WLB)

Esta VM debe tener la prioridad de reinicio configurada para reiniciar, a fin de garantizar que ninguna función de WLB se pierda después de una interrupción inesperada. Debe estar en el primer grupo de inicio 0.

Otras VM

Dependiendo del uso exacto de XenServer, se pueden configurar VM adicionales para usar VM HA. A continuación, se presentan sugerencias para algunos casos de uso.

Guía de decisión (VM HA): Utilice VM HA para cargas de trabajo en las que el reinicio automatizado después de una interrupción inesperada del host mejora sustancialmente la continuidad del servicio, y donde el grupo tiene un tamaño N+1 para absorber la interrupción. Evite VM HA para cargas de trabajo en las que la intermediación/orquestación externa ya proporciona un comportamiento de reinicio o escalado horizontal (por ejemplo, muchas cargas de trabajo CVAD no persistentes), o donde el orden de reinicio y las dependencias son difíciles de controlar.

Nota:

Las VM añadidas al grupo de recursos después de configurar HA se establecerán de forma predeterminada en ‘No reiniciar’. Será necesario reconfigurar HA después de añadir VM al entorno, si es necesario.

• VM de PVS y MCS no persistentes: No configure estas VM con HA. Asegúrese de que estén configuradas en Do Not Restart. Otras VM deben estar disponibles para proporcionar servicios inmediatos a los usuarios finales, y Citrix Virtual Apps and Desktops proporcionará funciones de administración de energía para admitir el reinicio de estas VM, ya sea cuando un usuario final lo requiera o mediante funciones de escalado automático para admitir la demanda esperada (consulte AutoScale). Esto proporcionará un resultado más optimizado para el entorno combinado de Citrix.

• VM persistentes de MCS: Deben configurarse en ‘Reiniciar’. La configuración que se está diseñando debe garantizar que haya suficiente RAM y CPU disponibles para operar todas las VM del grupo cuando haya 1 host fuera de servicio (por actualización, mantenimiento o interrupción), de modo que esta configuración sea posible.

• Cargas de trabajo de virtualización de servidor generales (cualquier carga de trabajo que no se utilice para ejecutar VDA de Citrix): Deben configurarse en ‘Reiniciar’. La configuración que se está diseñando debe garantizar que haya suficiente RAM y CPU disponibles para operar todas las VM del grupo cuando haya 1 host fuera de servicio (por actualización, mantenimiento o interrupción), de modo que esta configuración sea posible. Las VM se pueden configurar para usar los grupos de inicio y los retrasos según sea necesario para garantizar que la carga de trabajo se reinicie según sea necesario. Esto podría usarse para priorizar cargas de trabajo de las que dependen otros servicios, como Active Directory, DHCP y los proveedores de servicios DNS.

Resistencia entre centros de datos

Opcional:

Recuperación ante desastres (DR) entre centros de datos. Esta arquitectura de referencia puede admitir DR si es necesario, con consideraciones adicionales de diseño y operativas.

Guía de decisión para DR

• Usar cuando: Tenga un requisito empresarial definido para la resiliencia del sitio, una plataforma de almacenamiento con capacidad de replicación y procedimientos de recuperación acordados (RPO/RTO) que requieran la recuperación de VM en un sitio secundario.
• Evitar cuando: Necesite movilidad frecuente de la carga de trabajo entre sitios, o no tenga la capacidad operativa para probar y ejecutar procesos de conmutación por error/recuperación. Para CVAD, no asuma que la conectividad del hipervisor y los certificados se conmutarán por error sin problemas sin un diseño coordinado de DR de CVAD.
• Impacto operativo: La DR no está totalmente automatizada; la conmutación por error/recuperación requiere manuales de procedimientos planificados, acceso a los controles de replicación de almacenamiento y pruebas periódicas.

La configuración de Recuperación ante Desastres (DR) de XenServer descrita aquí es un modo de resiliencia que se espera que sea una operación de uso poco frecuente para soportar interrupciones extremas e imprevistas de la infraestructura. Esta operación no está automatizada y la recuperación requiere una planificación y operación cuidadosas. El modelo de DR permite la operación de cargas de trabajo en una ubicación temporal que puede no ser una ubicación óptima, pero que soportará la operación crítica del negocio durante un período de interrupción.

El modelo de DR de XenServer es una solución compleja y existen otras formas de protegerse contra fallos del sitio. Por ejemplo, para cargas de trabajo de Citrix donde se utilizan máquinas virtuales no persistentes para proporcionar servicios, se pueden aprovisionar máquinas virtuales adicionales en sitios de recuperación para proporcionar servicios temporales. Estas opciones deben considerarse antes de utilizar la función de DR de XenServer, ya que pueden ser más fáciles de implementar.

Se recomienda evitar el uso de DR para cargas de trabajo de Citrix VDI a menos que tenga una solución de DR adecuada para CVAD. No es seguro asumir que la misma conexión de hipervisor puede conmutar por error a un sitio de DR de XenServer, ya que las asignaciones de red y certificados pueden hacer que esto no sea fiable.

Para mitigar el riesgo de un fallo del centro de datos y la pérdida de la carga de trabajo (o partes críticas de la carga de trabajo), se puede utilizar una ubicación de centro de datos secundaria para proporcionar funciones de recuperación ante desastres. Hay más documentación disponible aquí.

Uno o más grupos de recursos en el sitio de DR pueden utilizarse para otras cargas de trabajo además de ser la ubicación de recuperación para las cargas de trabajo, pero debe mantener la capacidad de reserva necesaria para permitir que las cargas de trabajo adicionales se ejecuten cuando sea necesario.

No es necesario que la carga de trabajo completa se opere en el sitio de DR cuando ocurre un evento de fallo. Las cargas de trabajo parciales pueden recuperarse hasta que se restaure la operación completa en el sitio principal; sin embargo, existe el requisito de que las cargas de trabajo deben recuperarse de 1 grupo de recursos a un único grupo de recursos de recuperación. Las cargas de trabajo no pueden distribuirse a múltiples grupos de recuperación.

Importante:

El proceso de replicación de almacenamiento que replica los datos de los LUN en el sitio principal al sitio de DR debe configurarse fuera del conjunto de herramientas de XenServer y la reconfiguración de esto debe estar disponible para el administrador responsable de la conmutación por error, ya que necesitan romper y restablecer la replicación como parte de las operaciones relacionadas con este proceso (consulte la sección de operaciones para obtener más detalles).

Al construir esta implementación:

• Todo el almacenamiento utilizado para los discos virtuales de las máquinas virtuales debe replicarse del entorno principal al entorno de copia de seguridad
• Todo el almacenamiento utilizado para los metadatos del grupo debe replicarse del entorno principal al entorno de copia de seguridad
• La infraestructura de hardware en su sitio de DR no tiene que coincidir con el sitio principal, pero debe usar el mismo proveedor de procesadores. Se debe configurar suficiente memoria, CPU y capacidad de red en el grupo de recursos en espera para permitir que todas las máquinas virtuales conmutadas por error requeridas se vuelvan a crear e inicien.
• El grupo de recursos de XenServer en el sitio de recuperación debe tener el mismo nivel de versión y parche o ser más reciente que el sitio principal (consulte Gestión de versiones de XenServer en implementaciones para obtener detalles sobre cómo lograr esto).

Modelo de operaciones

Gestión de versiones de XenServer en las implementaciones

Las implementaciones de XenServer se construyen a partir de uno o más grupos de recursos, a través de uno o más centros de datos para proporcionar una implementación escalable, robusta y segura capaz de entregar cargas de trabajo de alto rendimiento a escala.

Estas implementaciones pueden proporcionar entornos de prueba y producción, y se puede construir un flujo de trabajo para implementar cambios a través de estos entornos.

Opcional:

Las fases de prueba de host y prueba de carga de trabajo son opcionales. La arquitectura de referencia admite operar con o sin estas fases.

Las etapas de prueba de host y prueba de carga de trabajo no tienen por qué ser etapas separadas; se pueden combinar. Esto puede ser ventajoso, ya que reduce el tiempo para implementar cambios en producción. El flujo de actualización de XenServer es robusto y está completamente probado, lo que permite la implementación continua. Para mantener la seguridad, la robustez y el rendimiento, es importante minimizar el tiempo que tardan las actualizaciones en llegar a producción.

Las expectativas para cada fase son las siguientes:

• Pruebas de lanzamiento anticipado: Esta fase está destinada a la visibilidad temprana de las actualizaciones y la validación de las características. Los hosts en esta fase están configurados para usar el canal de lanzamiento anticipado, que normalmente proporciona acceso a nuevas versiones 2 semanas antes que el canal normal. Los hosts en esta fase deben tener conectividad saliente a Internet (ya sea directamente o a través de un servidor proxy) para acceder a la Red de distribución de contenido (CDN) de XenServer.
• Pruebas de host: El propósito de esta fase es probar los procesos de actualización de la versión del software de XenServer. Las versiones están disponibles a través de Internet desde la CDN de XenServer o a través de los mecanismos de entrega del canal sin conexión.
• Pruebas de carga de trabajo/UAT: Esta fase permite probar los hosts de XenServer con una carga de trabajo similar a la de producción para validar la escala y la resiliencia. Las versiones están disponibles a través de Internet desde la CDN de XenServer o a través de los mecanismos de entrega del canal sin conexión.
• Implementaciones de producción: Los hosts que ejecutan cargas de trabajo de producción se pueden actualizar siguiendo las fases de prueba anteriores (directamente o a través de los mecanismos de entrega sin conexión).

Nota:

Las actualizaciones sin conexión se pueden usar para garantizar que la versión esperada de XenServer se implemente en los entornos de UAT y producción. Es posible sincronizar actualizaciones directamente desde otro grupo de recursos; sin embargo, si hay actualizaciones sincronizadas pero aún no aplicadas al grupo de origen, pueden aplicarse al grupo de destino, lo que resultaría en una versión de parche superior en el grupo de destino.

Para mantener el soporte, todos los grupos de recursos deben actualizarse regularmente y no deben quedar obsoletos por más de 6 meses.

Supervisión del grupo de recursos

Cuando se producen alertas en el grupo de recursos para cualquiera de los hosts o máquinas virtuales, estas están disponibles en la sección Alertas de XenCenter®.

Estas alertas también pueden estar disponibles en una herramienta de supervisión externa a través de la integración SNMP o mediante la integración SMTP de correo electrónico.

Hay 2 tipos de supervisión a considerar.

• Supervisión del uso, para garantizar que cualquier problema de capacidad inesperado se identifique rápidamente y se pueda actuar en consecuencia.
• Supervisión de eventos del sistema para garantizar que la infraestructura funciona correctamente y que no se producen cambios inesperados.

Estos se detallan a continuación para ser considerados en el diseño para la integración.

La integración con productos de supervisión de terceros se puede realizar a través de la función SNMP descrita aquí y puede proporcionar alertas que se integran en esas herramientas de terceros.

Nota:

Al añadir un nuevo host al grupo, debe reconfigurar los ajustes de SNMP para asegurarse de que el nuevo host se incluya en cualquier integración SNMP (consulte restricciones para obtener más detalles).

Supervisión del uso

Hay alertas que se pueden configurar para detectar cosas como el uso excesivo de la CPU; consulte Alertas de rendimiento para obtener más detalles.

A continuación se muestra un ejemplo de los datos proporcionados en las trampas SNMP activadas para estos eventos.

2026-02-19 09:44:35 <UNKNOWN> [UDP: [10.71.64.14]:53876->[10.81.143.35]:162]:
iso.3.6.1.2.1.1.3.0 = Timeticks: (196826250) 22 days, 18:44:22.50       iso.3.6.1.6.3.1.1.4.1.0 = OID: iso.3.6.1.4.1.60953.1.10.1   iso.3.6.1.4.1.60953.1.10.1.1.0 = STRING: "add"  iso.3.6.1.4.1.60953.1.10.1.2.0 = STRING: "OpaqueRef:eea63153-f96c-25f5-17b9-08ce49e7ccf4"   iso.3.6.1.4.1.60953.1.10.1.3.0 = STRING: "83a9c805-a172-f1b2-55d4-081ec180893b" iso.3.6.1.4.1.60953.1.10.1.4.0 = STRING: "ALARM"    iso.3.6.1.4.1.60953.1.10.1.5.0 = INTEGER: 3     iso.3.6.1.4.1.60953.1.10.1.6.0 = STRING: "VM"       iso.3.6.1.4.1.60953.1.10.1.7.0 = STRING: "681e4064-16cb-4d0c-9c2c-887623bc623f" iso.3.6.1.4.1.60953.1.10.1.8.0 = STRING: "20260219T09:45:55Z"       iso.3.6.1.4.1.60953.1.10.1.9.0 = STRING: "The memory required by the control domain on \"Control domain on host: pm-demolab-3\" is about 5.7% of its allocated memory. Occasional performance degradation can be expected when memory swapping is forced to happen.
This alarm is set to be triggered when the memory required by the control domain is above 5.0% of its allocated memory."
<!--NeedCopy-->

Supervisión de eventos del sistema

Las alertas del sistema se describen (/es-es/xenserver/8/monitor-performance/alerts.html#system-alerts) aquí.

A continuación, se muestra un ejemplo de los datos proporcionados en las trampas SNMP activadas para estos eventos.

2026-02-19 09:43:39 <UNKNOWN> [UDP: [10.71.64.14]:46982->[10.81.143.35]:162]:
iso.3.6.1.2.1.1.3.0 = Timeticks: (196820650) 22 days, 18:43:26.50       iso.3.6.1.6.3.1.1.4.1.0 = OID: iso.3.6.1.4.1.60953.1.10.1   iso.3.6.1.4.1.60953.1.10.1.1.0 = STRING: "add"  iso.3.6.1.4.1.60953.1.10.1.2.0 = STRING: "OpaqueRef:ca95e2da-06b7-9aa5-fa4b-ddf007a50c59"   iso.3.6.1.4.1.60953.1.10.1.3.0 = STRING: "525e459c-51bc-c71c-9c52-dcd747e9a84f" iso.3.6.1.4.1.60953.1.10.1.4.0 = STRING: "ALL_RUNNING_VMS_IN_ANTI_AFFINITY_GRP_ON_SINGLE_HOST"      iso.3.6.1.4.1.60953.1.10.1.5.0 = INTEGER: 3iso.3.6.1.4.1.60953.1.10.1.6.0 = STRING: "Pool"  iso.3.6.1.4.1.60953.1.10.1.7.0 = STRING: "419d6735-5d11-56b1-8cdc-2853ce709a27"     iso.3.6.1.4.1.60953.1.10.1.8.0 = STRING: "20260219T09:44:59Z"   iso.3.6.1.4.1.60953.1.10.1.9.0 = STRING: "<body><message>Breach on VM anti-affinity rules</message><VM_group>3224f9d9-9492-06f7-3c92-da610cde33a8</VM_group><host>ce2a3c26-6bbc-4d23-8626-fba28d3dc651</host></body>"
<!--NeedCopy-->

Registro remoto

El propósito principal de esto es permitir la participación del soporte. Para garantizar la disponibilidad de estos datos durante la resolución de problemas, se puede configurar el reenvío de syslog. Esto permite recuperar los registros en caso de que no se puedan recuperar directamente del host, o si hay alguna razón para sospechar que los registros del host pueden haber sido manipulados.

Si esto está configurado, entonces debe configurarse en todos los hosts del pool.

Estos datos pueden consumir un espacio significativo. El uso y la retención de esta función y de los datos quedan a su discreción, según las políticas de seguridad internas.

Modelo de planificación de capacidad

Dimensionamiento del pool de recursos

Cada pool de recursos debe contener suficientes recursos para que, si un host falla, el pool de recursos pueda operar toda la carga de trabajo. Esto permitirá:

• Que se produzcan interrupciones planificadas según sea necesario en 1 host a la vez
• Que se realicen actualizaciones del pool de recursos sin interrupción de la carga de trabajo
• Garantizar una interrupción mínima de la carga de trabajo si 1 host falla inesperadamente

Para lograr esto, se espera que todos los hosts del pool de recursos tengan la misma capacidad para soportar la carga de trabajo (es decir, la misma configuración, RAM, CPU). Esto puede resultar en un mayor nivel de sobrecompromiso de CPU durante la interrupción, pero se espera que sea de corta duración hasta que se resuelva la condición de interrupción.

Si se pierde más de 1 host en un pool de recursos, ya no será posible mantener toda la carga de trabajo y puede haber una interrupción de la carga de trabajo hasta que se recuperen los hosts.

Nota:

Si los hosts no tienen una capacidad idéntica durante ciertos períodos de tiempo en actividades como la actualización/renovación de hardware, se debe prever el fallo del host con más memoria.

Cálculos de capacidad del grupo de recursos

En esta arquitectura de referencia, hemos asumido que cada grupo de recursos tiene un propósito específico. Como resultado, los cálculos siguientes asumen que todas las máquinas virtuales del grupo de recursos tienen la misma especificación.

Dom0 tiene un tamaño de 32 GB de RAM. Sin embargo, si se utiliza el acelerador PVS, esto deberá aumentarse en al menos 5 GB por vdisk para soportar la aceleración y debe tenerse en cuenta en estos cálculos.

Entradas

Salidas

Nota:

Durante un fallo del host, mantenimiento o una operación de actualización vm_host = vm_pool_max / (hosts_total - 1)

Ejemplo práctico

• vm_host_max = (1000 - 32 - 2) / 16 = 60 max VMs per Host
• vm_pool_max = 60 * (8 - 1) = 420 max VMs per pool
• srs_total = 420 * (3 + 0) / 1000 = 1.26 SRs (>1 so need 2 SRs spread over 2 LUNS)
• Funcionamiento normal:
  • vm_host = 420 / 8 = 52.5 VMs per host (round down to 52)
  • host_cpu_overcommit = ((52 * 4) + 16 + 2) / 128 = 1.77 vCPU per pCPU
• Durante una interrupción de un solo host o una operación de actualización/mantenimiento:
  • vm_host = 420 / 7 = 60 VMs per host
  • host_cpu_overcommit = ((60 * 4) + 16 + 2) / 128 = 2.01 vCPU per pCPU

Nota:

No se utiliza el Control Dinámico de Memoria (DMC) para proporcionar sobreaprovisionamiento de RAM. XenServer no lo admite durante el funcionamiento normal. Solo se espera que se utilice durante períodos cortos de mantenimiento planificado y controlado cuando no haya otra opción disponible para mantener la carga de trabajo requerida en funcionamiento.

Si el sobreaprovisionamiento es demasiado alto, el número de máquinas virtuales para el pool deberá reducirse hasta que alcance un punto aceptable.