Arquitectura de referencia empresarial de XenServer®

Informació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 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 la ejecución predecible y de alto rendimiento de las cargas de trabajo. 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 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 VM 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 donde 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 cambiantes necesidades de las cargas de trabajo y organizativas.

Esta arquitectura asume el uso de almacenamiento de bloques remoto, la administración de identidades integrada a través de Active Directory y la administración segura mediante TLS. Las capacidades opcionales como el equilibrio de cargas de trabajo (WLB), la alta disponibilidad (HA) y la recuperación ante desastres (DR) se pueden incorporar 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 control operativo sólido. No está optimizada para escenarios especializados, como discos de VM 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 como guía de diseño y como marco operativo, lo que permite a las organizaciones implementar XenServer de manera coherente y compatible, al tiempo que conservan la flexibilidad para ampliar y evolucionar la plataforma con el tiempo.

Supuestos y alcance

La arquitectura se basa en un conjunto de supuestos 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 1.000 máquinas virtuales, con implementaciones generales que escalan añadiendo grupos adicionales en lugar de expandir un único 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, asegurando un acceso consistente y fiable al almacenamiento compartido.
  • Los hosts deben tener suficiente RAM para soportar 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 de XenServer (mínimo 46 GB, idealmente 70 GB) o la capacidad de arrancar desde SAN.
  • Los hosts deben usar firmware UEFI; el BIOS heredado no es compatible con XenServer 9.

• 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 son proporcionadas principalmente por la plataforma de almacenamiento subyacente, incluyendo capacidades como el aprovisionamiento ligero para permitir la asignación activa en uso y el multipathing. La conectividad de almacenamiento continua y fiable es un requisito crítico.

• La red sigue un modelo de estricta separación entre el tráfico de gestió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, evitando 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 gestión se aseguran 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 gestión.

• Operacionalmente, 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 sin interrupciones 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 uno de ellos 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 arquitectónicas y adaptaciones 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 en 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, es posible utilizar 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 la implementación de CVAD
• Infraestructura de CVAD
• Cargas de trabajo generales de virtualización de servidores

Cada grupo de recursos tendrá los siguientes atributos

• Protocolo LVM utilizado para todo el almacenamiento en bloque remoto. No se recomienda utilizar el protocolo GFS2.
• Alta disponibilidad para la gestión del Coordinador de grupo
• Uso de TLS 1.2 para todas las comunicaciones de gestión
• Opcional: Equilibrio de carga de trabajo (WLB) para las máquinas virtuales de carga de trabajo
• Opcional: Alta disponibilidad (HA) de las máquinas virtuales 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 grupos de recursos dentro de los centros de datos o entre ellos para proporcionar la carga de trabajo donde sea necesario.

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

Configuración del grupo de recursos principal

Al construir un nuevo grupo 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 agregar otros hosts a este grupo. Los hosts adicionales obtendrán la configuración a medida que se agreguen al grupo 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 en 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 de 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 relevante para obtener más detalles:

• DaaS
• CVAD 2507 y posteriores
• CVAD anteriores a 2507

Cualquier conexión de terceros al grupo de recursos debe usar 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 la pila de herramientas de administración falla, SSH se habilite automáticamente

Habilitar el arranque seguro

Los hosts de XenServer 9 se pueden configurar para que se ejecuten con el arranque seguro habilitado en el firmware. Esto aplica la verificación de firmas en cada etapa del proceso de arranque, lo que reduce el riesgo de que se ejecute código no confiable o malicioso antes de que el sistema operativo del host esté completamente cargado.

Habilite el arranque seguro en la configuración del firmware de cada host. Todos los módulos del kernel de Dom0 en XenServer 9 están firmados, por lo que el funcionamiento estándar del host no se ve afectado. Se admiten grupos mixtos en los que el arranque seguro está habilitado en algunos hosts y deshabilitado en otros.

Para conocer los pasos de configuración completos, consulte Arranque seguro para XenServer 9.

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 NIC separadas o mediante el uso de VLAN con las mismas NIC. Si se utiliza almacenamiento basado en red, se recomienda encarecidamente utilizar NIC 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 funcionar con NIC 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 y, al mismo tiempo, maximizar la disponibilidad del ancho de banda. Esto requerirá que los conmutadores se configuren con una configuración coincidente. Si los conmutadores no se pueden configurar para admitir LACP, el modo activo-activo es beneficioso para las redes de máquinas virtuales. Las redes de administración pueden usar el modo 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 a las NIC para garantizar que no haya un único punto de fallo en el transporte de red y deben utilizar fuentes de alimentación separadas o suministros redundantes; consulte Prácticas recomendadas de red para obtener todos los detalles.

Todos los hosts del pool 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 espera 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 VM 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, a fin de 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 subredes apropiadas en cada una. Consulte a su proveedor de almacenamiento para obtener más recomendaciones.

Configuración del almacenamiento del pool de recursos

Se debe habilitar la multirruta. 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 en toda 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á toda la capacidad 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 SAN utiliza mejor el almacenamiento disponible al asignar espacio de almacenamiento en disco a los VDI a medida que se escriben datos en el disco virtual, en lugar de asignar el tamaño virtual completo del VDI por adelantado. La cantidad de almacenamiento utilizada debe ser supervisada 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 supervisar la utilización del almacenamiento; si la capacidad de la SAN se agota de tal manera que no es posible 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 utilizar 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 lleve un tiempo considerable, retrasando el despliegue de imágenes actualizadas.

Estrategia de resiliencia

Los pools de recursos de XenServer, junto con sus recursos de almacenamiento, se operan dentro de un único centro de datos (o dentro de una colección de centros de datos muy próximos).

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

Estos se consideran por separado a continuación.

Resiliencia dentro de un centro de datos

Aunque 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 funcionalidades están disponibles:

• Alta disponibilidad de la gestión (mediante elecciones automáticas de coordinador durante interrupciones no planificadas)
• Alta disponibilidad de cómputo de carga de trabajo (mediante el reinicio automático de VM en interrupciones no planificadas)
• Resiliencia del almacenamiento (mediante rutas múltiples de almacenamiento)
• Resiliencia de red (mediante la agregación de enlaces de red y 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 interrupción de la carga de trabajo, facilitando la aplicación de actualizaciones de seguridad y mejoras de características.

Estas funcionalidades proporcionarán una implementación altamente resiliente que se opera completamente dentro de un centro de datos o entre centros de datos cercanos. No admitirá la resiliencia entre 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 las VM tienen patrones de utilización materialmente diferentes y variables en el tiempo durante su ejecución y desea 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 monitorizar; incluye una ventana de mantenimiento diario 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 en el 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 durante su vida útil. Si se utiliza WLB, cada vez que una máquina virtual se detiene y se vuelve a iniciar, 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 se 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 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 se pueden dejar como predeterminados. Esto configurará la función WLB para que haga recomendaciones a un administrador, y el administrador tendrá que aplicar estas acciones.

La configuración predeterminada y esperada para este esquema 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 se pueden optimizar 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 con 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, cuando sea posible.
  • Valor inicial recomendado del umbral crítico: 90%
  • Valor inicial recomendado de ponderación de métrica: Más importante
• Memoria libre: No se obtiene un rendimiento específico 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 VM ejecutando cargas de trabajo de red pesadas, y evitar el impacto en otras VM sea relevante.
  • 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 configurarla 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 del almacenamiento y las estructuras modernas, 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 configurarse 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 pool 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 pool de recursos.

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

Una de las 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 una LUN disponible, no importa cuál se seleccione. Se asignará una pequeña cantidad (<5 GB) de espacio de esta 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 de >16 hosts.
• La 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 de 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 la 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 administración

Si el host que no se puede contactar es el coordinador y las operaciones de administración no están disponibles, todos los demás hosts del grupo 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 grupo. 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 establecida en reiniciar para 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 HA de VM. Las siguientes son sugerencias para algunos casos de uso.

Guía de decisiones (HA de VM): Utilice HA de VM para cargas de trabajo donde el reinicio automático después de una interrupción inesperada del host mejora materialmente la continuidad del servicio, y donde el grupo tiene un tamaño N+1 para absorber la interrupción. Evite la HA de VM para cargas de trabajo donde 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 la HA se establecerán por defecto en ‘No reiniciar’. La HA deberá reconfigurarse después de añadir las VM al entorno, si es necesario.

• VM de PVS y MCS no persistentes: No configure estas VM con ninguna 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 a través de 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: Estas deben configurarse en ‘Reiniciar’. La configuración diseñada 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) para que esta configuración sea posible.

• Cargas de trabajo de virtualización de servidores generales (cualquier carga de trabajo que no se utilice para ejecutar VDA de Citrix): Estas deben configurarse en ‘Reiniciar’. La configuración diseñada 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) para 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 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 la DR si es necesario, con consideraciones adicionales de diseño y operativas.

Guía de decisiones 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 máquinas virtuales en un sitio secundario.
• Evitar cuando: Necesite una 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 ejecución 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 empresarial crítica 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 en las que 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 se pueden utilizar 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 se pueden recuperar hasta que se restablezca 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 en un único grupo de recursos de recuperación. Las cargas de trabajo no se pueden distribuir a varios grupos de recuperación.

Importante:

El proceso de replicación de almacenamiento que refleja los datos de las 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 desde el entorno principal al entorno de copia de seguridad
• Todo el almacenamiento utilizado para los metadatos del Pool debe replicarse desde el 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 Administración de versiones de XenServer en implementaciones para obtener detalles sobre cómo lograr esto).

Modelo de operaciones

Administración de versiones de XenServer en 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 actualizaciones 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 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 las versiones de software de XenServer. Las versiones están disponibles a través de Internet desde la CDN de XenServer o mediante los mecanismos de entrega de canales 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 mediante los mecanismos de entrega de canales 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 utilizar para garantizar que la versión esperada de XenServer se implemente en los entornos de UAT y producción. Es posible sincronizar las 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 tener una antigüedad superior a 6 meses.

Gestión de controladores con Driver Multi-Versioning (DMV)

XenServer 9 introduce Driver Multi-Versioning (DMV), que ofrece versiones de controladores aprobadas a través del canal estándar de actualizaciones de host en streaming, eliminando la necesidad de discos de controladores separados en la mayoría de los casos.

DMV permite a los operadores seleccionar entre varias versiones de controladores aprobadas disponibles en el flujo de actualización. XenServer presenta solo variantes de controladores compatibles con el hardware de cada host. Si se aplica un controlador incorrecto, se puede seleccionar e instalar la versión correcta sin reinstalar el host, aunque se requiere un reinicio para que el cambio surta efecto. XenServer 9 aplica la validación de controladores firmados, bloqueando los binarios de terceros no aprobados.

Para obtener más información, consulte Controladores multiversión.

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 se pueden poner a disposición 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 de la utilización, 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 de 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 (/es-es/xenserver/9/monitor-performance/monitor-snmp.html) y puede proporcionar alertas que se integran en esas herramientas de terceros.

Nota:

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

Supervisión del uso

Se pueden configurar alertas 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/9/monitor-performance/alerts.html#system-alerts)

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 han sido manipulados.

Si esto está configurado, 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 los datos quedan a su discreción, según las políticas de seguridad internas.

Modelo de planificación de capacidad

Dimensionamiento del grupo de recursos

Cada grupo de recursos debe contener suficientes recursos para que, si un host está inactivo, el grupo de recursos pueda operar la carga de trabajo completa. Esto permitirá:

• Que se produzcan interrupciones planificadas según sea necesario en 1 host a la vez
• Que las actualizaciones del grupo de recursos se realicen sin ninguna 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 grupo 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 sobreasignación de CPU durante una 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 grupo 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 períodos de tiempo durante actividades como la actualización/renovación de hardware, se debe tener en cuenta la falla 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 a continuación asumen que todas las VM en el grupo de recursos tienen la misma especificación.

Optimización NUMA

XenServer 9 habilita la optimización de la ubicación NUMA de forma predeterminada. Cuando las vCPU y la memoria de una VM caben dentro de un único nodo NUMA en el host, las cargas de trabajo logran una menor latencia de acceso a la memoria y un rendimiento más consistente. Esto también puede permitir una mayor densidad de VM por host, reduciendo la necesidad de servidores adicionales.

Para obtener los mejores resultados, dimensione las VM para que su memoria quepa dentro de un único nodo NUMA físico. Si una VM requiere más memoria de la que puede proporcionar un solo nodo, XenServer distribuye la VM entre varios nodos y el beneficio de optimización se reduce. El dimensionamiento de VM que excede los límites del nodo NUMA debe tratarse como una excepción en lugar de la norma.

Las métricas NUMA por VM están disponibles para supervisar la ubicación y detectar infracciones de afinidad. Consulte Optimización de NUMA en XenServer 9 para obtener más detalles.

Cálculos de capacidad del grupo de recursos

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 admitir la aceleración y debe tenerse en cuenta en estos cálculos.

Entradas

Salidas

Nota:

Durante un fallo del host, mantenimiento u 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.