Grupos de recursos
Un grupo de recursos comprende varias instalaciones de host de XenServer® unidas en una única entidad administrada que puede alojar máquinas virtuales. Si se combina con almacenamiento compartido, un grupo de recursos permite iniciar máquinas virtuales en cualquier host de XenServer que tenga suficiente memoria.
El coordinador del grupo (anteriormente “maestro del grupo”) es un servidor del grupo de recursos que expone una interfaz de administración (utilizada por XenCenter® y la interfaz de línea de comandos de XenServer, conocida como xe CLI). El coordinador del grupo reenvía los comandos a los miembros individuales según sea necesario.
Este artículo describe los conceptos, requisitos y mejores prácticas con respecto a los grupos de recursos. Para obtener información sobre cómo crear y administrar sus grupos, consulte Administrar sus grupos.
Ventajas de los grupos de recursos
Aunque puede organizar sus hosts de XenServer como hosts independientes, que son efectivamente un grupo de uno, XenServer está optimizado para hosts agrupados en grupos de recursos con almacenamiento compartido. Varias de nuestras funciones, como la alta disponibilidad y la migración en vivo, solo están disponibles en grupos de recursos de varios hosts. Las ventajas de organizar sus hosts de XenServer en grupos de recursos incluyen las siguientes:
- Movilidad de máquinas virtuales: Cuando sus máquinas virtuales se ejecutan en un grupo y tienen sus discos en el almacenamiento compartido del grupo, estas máquinas virtuales se pueden mover dinámicamente entre hosts de XenServer mientras aún se ejecutan (migración en vivo). Además, si un host de XenServer individual sufre un fallo de hardware, el administrador puede reiniciar las máquinas virtuales fallidas en otro host de XenServer en el mismo grupo de recursos.
- Alta disponibilidad Esta función protege las máquinas virtuales de su carga de trabajo y garantiza un tiempo de inactividad mínimo en caso de fallos de hardware o de host. Cuando la alta disponibilidad está habilitada en el grupo de recursos, las máquinas virtuales pueden reiniciarse automáticamente en otro host si su host falla. Si el coordinador del grupo falla, la alta disponibilidad elige otro coordinador del grupo. Para obtener más información, consulte Alta disponibilidad.
- Equilibrio de carga de trabajo El equilibrio de carga de trabajo puede evaluar su grupo de recursos y la carga de trabajo de las máquinas virtuales que se ejecutan en él para recomendar la ubicación óptima para sus máquinas virtuales. También puede optar por que el equilibrio de carga de trabajo siga automáticamente sus recomendaciones de ubicación y migre sus máquinas virtuales entre hosts del grupo. Para obtener más información, consulte Equilibrio de carga de trabajo.
- Ubicación de máquinas virtuales antiafinidad: Asegúrese de que las máquinas virtuales de un grupo estén distribuidas uniformemente entre los hosts de un grupo. Para obtener más información, consulte Ubicación de máquinas virtuales.
- Facilidad de administración: En lugar de administrar cada host de XenServer individualmente, agregue el grupo de recursos a XenCenter y administre todos los hosts, SR y máquinas virtuales dentro de él de forma conjunta. Para obtener más información, consulte XenCenter.
Requisitos para crear grupos de recursos
Al diseñar su implementación de XenServer y decidir la configuración de su grupo, tenga en cuenta los siguientes requisitos:
Requisitos de hardware
Todos los servidores de un grupo de recursos de XenServer deben tener CPU ampliamente compatibles, es decir:
-
El proveedor de CPU (Intel, AMD) debe ser el mismo en todas las CPU de todos los servidores.
-
Todas las CPU deben tener la virtualización habilitada.
Dependiendo de la similitud de las CPU, el grupo es de uno de los siguientes tipos:
-
Grupo homogéneo: Un grupo de recursos homogéneo es un agregado de servidores con CPU idénticas. Las CPU de un servidor que se une a un grupo de recursos homogéneo deben tener el mismo proveedor, modelo y características que las CPU de los servidores que ya están en el grupo.
-
Grupo heterogéneo: La creación de grupos heterogéneos es posible gracias al uso de tecnologías en las CPU Intel (FlexMigration) y AMD (Extended Migration) que proporcionan enmascaramiento o nivelación de CPU. Estas características permiten configurar una CPU para que parezca que proporciona una marca, modelo o conjunto de características diferente de lo que realmente hace. Estas capacidades le permiten crear grupos de hosts con diferentes CPU, pero aún así admitir de forma segura las migraciones en vivo. Como resultado de este enmascaramiento o nivelación de características, es posible que no obtenga el rendimiento completo de sus CPU.
Requisitos del host de unión
XenServer comprueba que se cumplen las siguientes condiciones para el host que se une al grupo:
-
Debe ejecutar la misma versión de XenServer, con el mismo nivel de actualización, que los hosts que ya están en el grupo.
-
El host de unión no es miembro de un grupo de recursos existente.
-
El host de unión no tiene almacenamiento compartido configurado.
-
El host de unión no aloja ninguna máquina virtual en ejecución o suspendida.
-
No hay operaciones activas en curso en las máquinas virtuales del host de unión, como el apagado o la exportación de una máquina virtual.
-
El reloj del host de unión está sincronizado con la misma hora que el coordinador del grupo (por ejemplo, mediante NTP).
-
La interfaz de administración del host de unión no está agrupada. Puede configurar la interfaz de administración cuando el host se una correctamente al grupo.
-
La dirección IP de administración del host de unión es estática, configurada en el propio host o mediante una configuración adecuada en su servidor DHCP.
-
La interfaz de administración del host que se une está en la misma VLAN etiquetada que la del grupo de recursos.
-
El host que se une debe configurarse con los mismos paquetes suplementarios y la misma revisión que los hosts que ya están en el grupo.
-
El host que se une debe tener la misma licencia de XenServer que los hosts que ya están en el grupo. Puede cambiar la licencia de cualquier miembro del grupo después de unirse al grupo. El host con la licencia más baja determina las características disponibles para todos los miembros del grupo.
Si agrega un host a un grupo mediante XenCenter, XenCenter se asegura de que se aplique una licencia coincidente al host que se une. Sin embargo, si está realizando una unión de grupo mediante la CLI de xe, le recomendamos que asigne una licencia coincidente al host antes de unirlo al grupo.
-
El host que se une debe estar en el mismo sitio que el grupo y conectado por una red de baja latencia.
Requisitos de almacenamiento
El almacenamiento compartido utilizado por el grupo de recursos tiene los siguientes requisitos:
- Los servidores que proporcionan almacenamiento compartido NFS o iSCSI para el grupo deben tener una dirección IP estática o una concesión DHCP estática.
Tamaño de grupo recomendado
El límite de configuración indicado de 32 es el número máximo de hosts que admitimos en un grupo. Sin embargo, no es un tamaño de grupo recomendado, ya que a menudo no es el tamaño óptimo desde el punto de vista de la administración o el rendimiento para la mayoría de las cargas de trabajo. Considere los siguientes factores al decidir el mejor tamaño para su implementación:
-
Consideraciones de administración: La mayor parte de la administración de XenServer se realiza a nivel de grupo. Un grupo más grande reduce la cantidad de administración requerida y le permite administrar más hosts juntos. Sin embargo, algunas operaciones de administración, por ejemplo, la aplicación de actualizaciones a un grupo, pueden tardar más si tiene más hosts, ya que la operación debe realizarse secuencialmente en cada host del grupo. En este caso, es posible que necesite una ventana de mantenimiento más larga para completar ciertas operaciones en un grupo grande de lo que necesitaría para varios grupos más pequeños.
-
Uso compartido de recursos: Un grupo de XenServer normalmente comparte recursos, como repositorios de almacenamiento, entre hosts. Un grupo más grande permite que más hosts compartan recursos, lo que puede tener beneficios. Por ejemplo, en su entorno de Citrix Virtual Apps and Desktops™ puede tener más hosts compartiendo una imagen dorada, en lugar de tener que crear varias copias en diferentes grupos. Sin embargo, los dispositivos particulares que elija para sus recursos compartidos pueden tener consideraciones de rendimiento específicas que hacen que sea mejor usar agrupaciones más pequeñas de hosts.
-
Rendimiento del plano de control: En un grupo de XenServer, todas las operaciones son administradas por el coordinador del grupo. La carga en la pila de herramientas de este host aumenta a medida que agrega más hosts al grupo: hay más actividades en segundo plano de cada host y el número esperado de operaciones concurrentes aumenta. A medida que aumenta la carga en la pila de herramientas, es probable que aumente el tiempo que lleva cada operación. Como resultado, un grupo grande puede funcionar notablemente más lento que dos grupos más pequeños.
-
Aislamiento de fallos: Si XenServer u otro componente crítico para el grupo (por ejemplo, un dispositivo de almacenamiento) tiene un problema, en un grupo más grande esto podría tener un mayor impacto en sus cargas de trabajo que si esa carga de trabajo se divide en varios grupos más pequeños.
-
Almacenamiento GFS2: Si utiliza almacenamiento GFS2 para el aprovisionamiento ligero en almacenamiento en bloque, XenServer admite un máximo de 16 hosts. Esto se debe a las limitaciones en la implementación de GFS2 y al aumento de las comunicaciones necesarias entre los hosts para administrar el almacenamiento.
-
Alta disponibilidad: Si utiliza nuestra funcionalidad de alta disponibilidad para proteger sus máquinas virtuales, todos los hosts del pool se supervisan continuamente entre sí y comunican su estado. A medida que el pool aumenta de tamaño, el volumen de mensajes que cada host tiene que enviar y recibir como parte de esta supervisión aumenta. Si hay una carga alta en el dominio de control, esto puede aumentar la probabilidad de que se pierdan algunos de estos mensajes de supervisión. En escenarios extremos, la pérdida de mensajes puede hacer que los hosts se aíslen inesperadamente por seguridad. Al utilizar la función de alta disponibilidad, le recomendamos que utilice pools más pequeños, con un máximo de 16 hosts, para reducir el riesgo de aislamiento inesperado.
Para la mayoría de los casos de uso de Citrix Virtual Apps and Desktops, recomendamos un tamaño de pool de 16 hosts, con un tamaño máximo de 32.
Además de considerar estos factores al planificar el tamaño de su pool, observe y supervise el comportamiento de su pool para determinar si necesita cambiar el tamaño del pool en su entorno en ejecución.
Comunicarse con hosts XenServer y pools de recursos
TLS
XenServer utiliza el protocolo TLS 1.2 para cifrar el tráfico de la API de administración. Cualquier comunicación entre XenServer y los clientes (o dispositivos) de la API de administración utiliza el protocolo TLS 1.2.
Importante:
No admitimos modificaciones del cliente a la funcionalidad criptográfica del producto.
XenServer utiliza los siguientes conjuntos de cifrado:
- ECDHE-RSA-AES256-GCM-SHA384
- ECDHE-RSA-AES128-GCM-SHA256
SSH
Al utilizar un cliente SSH para conectarse directamente al host XenServer, se pueden utilizar los siguientes algoritmos:
Cifrados:
- aes128-ctr
- aes256-ctr
- aes128-gcm@openssh.com
aes256-gcm@openssh.com
MACs:
- hmac-sha2-256
- hmac-sha2-512
- hmac-sha1
Algoritmos Kex:
- curve25519-sha256
- ecdh-sha2-nistp256
- ecdh-sha2-nistp384
- ecdh-sha2-nistp521
Algoritmos de clave de host:
- ecdsa-sha2-nistp256
- ecdsa-sha2-nistp384
- ecdsa-sha2-nistp521
- ssh-ed25519
- ssh-rsa
Importante:
No admitimos modificaciones de los clientes a la funcionalidad criptográfica del producto. Sin embargo, si desea deshabilitar el acceso SSH a un host de XenServer, consulte Deshabilitar el acceso SSH para un host o Deshabilitar el acceso SSH para un grupo.
¿Qué ocurre cuando un host se une a un grupo de recursos?
Cuando un nuevo host se une a un grupo de recursos, el host que se une sincroniza su base de datos local con la del grupo y hereda algunas configuraciones del grupo:
-
La configuración de almacenamiento de VM, local y remoto se añade a la base de datos de todo el grupo. Esta configuración se aplica al host que se une al grupo, a menos que explícitamente comparta los recursos después de que el host se una al grupo.
-
El host que se une hereda los repositorios de almacenamiento compartido existentes en el grupo. Se crean los registros PBD apropiados para que el nuevo host pueda acceder automáticamente al almacenamiento compartido existente.
-
La información de red se hereda parcialmente al host que se une: los detalles estructurales de las NIC, las VLAN y las interfaces enlazadas se heredan, pero la información de política no. Esta información de política, que debe reconfigurarse, incluye:
-
Las direcciones IP de las NIC de administración, que se conservan de la configuración original.
-
La ubicación de la interfaz de administración, que permanece igual que la configuración original. Por ejemplo, si los otros hosts del grupo tienen interfaces de administración en una interfaz enlazada, el host que se une debe migrarse al enlace después de unirse.
-
Las NIC de almacenamiento dedicadas, que deben reasignarse al host que se une desde XenCenter o la CLI, y los PBDs deben volverse a conectar para enrutar el tráfico en consecuencia. Esto se debe a que las direcciones IP no se asignan como parte de la operación de unión al grupo, y la NIC de almacenamiento funciona solo cuando esto está configurado correctamente. Para obtener más información sobre cómo dedicar una NIC de almacenamiento desde la CLI, consulte Administrar redes.
-