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 en el 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 (/es-es/xenserver/8/hosts-pools/manage-pools).
Ventajas de los grupos de recursos
Aunque puede organizar sus hosts de XenServer como hosts autónomos, lo que en la práctica es 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 están en ejecución ((/es-es/xenserver/8/vms/migrate)). 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 fallo de hardware o del host. Cuando la alta disponibilidad está habilitada en el grupo de recursos, las máquinas virtuales pueden reiniciarse automáticamente en otro host cuando su host falla. Si el coordinador del grupo falla, la alta disponibilidad elige otro coordinador del grupo. Para obtener más información, consulte (/es-es/xenserver/8/high-availability).
- 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 (/es-es/xenserver/8/wlb).
- Ubicación de máquinas virtuales antiafinidad: Asegúrese de que las máquinas virtuales de un grupo se distribuyan uniformemente entre los hosts de un grupo. Para obtener más información, consulte (/es-es/xenserver/8/vms/placement).
- 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 (/es-es/xencenter/current-release).
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 fabricante de la 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 fabricante, 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 de 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á enlazada. 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 estar configurado 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 funciones 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 se une a un 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 centro de datos que el grupo, o en un centro de datos que cumpla la definición de proximidad cercana, y estar conectado por una red de baja latencia (menos de 5 ms de tiempo de ida y vuelta) y alto ancho de banda (al menos 10 Gbps).
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 64 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 podrían tener consideraciones de rendimiento específicas que hagan 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 el toolstack 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 el toolstack, es probable que aumente el tiempo que tarda 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 requeridas 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, los mensajes perdidos pueden hacer que los hosts se aíslen inesperadamente por seguridad. Al utilizar la función de alta disponibilidad, 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.
Comunicación con hosts de 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 de la API de administración (o dispositivos) 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 de 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
KexAlgorithms:
- curve25519-sha256
- ecdh-sha2-nistp256
- ecdh-sha2-nistp384
- ecdh-sha2-nistp521
HostKeyAlgorithms:
- ecdsa-sha2-nistp256
- ecdsa-sha2-nistp384
- ecdsa-sha2-nistp521
- ssh-ed25519
- ssh-rsa
Importante:
No admitimos modificaciones del cliente 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 agrega 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 sigue siendo la misma 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 PBD deben volver a conectarse 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 solo funciona cuando está configurada correctamente. Para obtener más información sobre cómo dedicar una NIC de almacenamiento desde la CLI, consulte Administrar redes.
-