Grupos de recursos
Un grupo de recursos ** comprende múltiples instalaciones de host XenServer, unidas entre sí en una única entidad administrada que puede alojar máquinas virtuales. Si se combina con el almacenamiento compartido, un grupo de recursos permite iniciar las máquinas virtuales cualquier Host XenServer que tiene 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 CLI xe). El coordinador del grupo envía 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 pools de recursos
Si bien puede organizar sus hosts de XenServer como hosts independientes , 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 múltiples hosts. Las ventajas de organizar sus hosts XenServer en grupos de recursos incluyen las siguientes:
- Movilidad de VM: cuando sus VM se ejecutan en un grupo y tienen sus discos en el almacenamiento compartido del grupo, estas VM se pueden mover dinámicamente entre hosts de XenServer mientras aún se encuentran en ejecución (migración en vivo). Además, si un host XenServer individual sufre una falla de hardware, el administrador puede reiniciar las máquinas virtuales fallidas en otro host XenServer en el mismo grupo de recursos.
- Alta disponibilidad Esta característica funciona para proteger las máquinas virtuales en su carga de trabajo y garantizar que tengan un tiempo de inactividad mínimo en casos de fallas 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 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 elegir que el equilibrio de carga de trabajo siga automáticamente sus recomendaciones de ubicación y migre sus máquinas virtuales entre los hosts del grupo. Para obtener más información, consulte Equilibrio de la carga de trabajo.
- Ubicación de máquinas virtuales antiafinidad: garantiza 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 VM.
- 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 VM dentro de él juntos. Para obtener más información, consulte XenCenter.
Requisitos para crear grupos de recursos
Al diseñar su implementación de XenServer y decidir acerca de 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 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 qué tan similares sean las CPU, el grupo se divide en 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ónde CPU. Estas características permiten configurar una CPU para parecer como proporcionando una marca, modelo o conjunto de características diferente al que realmente proporciona. Estas capacidades le permiten crear grupos de hosts con diferentes CPU, pero aún así admitir migraciones en vivo de manera segura. Como resultado de esta función de enmascaramiento o nivelación, es posible que no obtenga el rendimiento completo de sus CPU.
Requisitos para unirse al anfitrión
XenServer verifica que se cumplan las siguientes condiciones para que el host se una al grupo:
-
Debe ejecutar la misma versión de XenServer, con el mismo nivel de parche, que los hosts que ya están en el grupo.
-
El host que se une no es miembro de un grupo de recursos existente.
-
El host que se une no tiene almacenamiento compartido configurado.
-
El host que se une no aloja ninguna máquina virtual en ejecución o suspendida.
-
No hay operaciones activas en curso en las máquinas virtuales del host que se une, como por ejemplo una máquina virtual que se apaga o se exporta.
-
El reloj del host que se une está sincronizado con la misma hora que el coordinador del grupo (por ejemplo, mediante NTP).
-
La interfaz de administración del host que se une no está vinculada. Puede configurar la interfaz de administración cuando el host se une correctamente al grupo.
-
La dirección IP de administración del host que se une es estática, ya sea configurada en el mismo host o utilizando 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 complementarios en 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 garantiza que se aplique una licencia coincidente al host que se une. Sin embargo, si está uniéndose a un grupo mediante la CLI xe, le recomendamos que asigne una licencia correspondiente al host antes de unirlo al grupo.
-
El host que se une debe estar en el mismo sitio que el grupo y conectado mediante 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 NFS o iSCSI compartido para el grupo deben tener una dirección IP estática o una concesión DHCP estática.
Tamaño de piscina recomendado
El límite de configuración indicado de 64 es la cantidad máxima 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 gestión o rendimiento para la mayoría de las cargas de trabajo. Tenga en cuenta los siguientes factores al decidir cuál es 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 pool. Un grupo más grande reduce la cantidad de administración necesaria y le permite administrar más hosts juntos. Sin embargo, algunas operaciones de administración, por ejemplo, aplicar 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 que la que necesita 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 principal, 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 hagan que sea mejor utilizar 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 aumenta la cantidad esperada de operaciones simultáneas. A medida que aumenta la carga en la pila de herramientas, es probable que aumente el tiempo necesario para cada operación. Como resultado, un grupo grande puede funcionar considerablemente más lento que dos grupos más pequeños.
-
Aislamiento de fallas: 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 aprovisionamiento fino 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 grupo se monitorean continuamente entre sí y comunican su estado. A medida que el grupo aumenta de tamaño, aumenta el volumen de mensajes que cada host debe enviar y recibir como parte de esta supervisión. Si hay una carga alta en el dominio de control, esto puede aumentar la probabilidad de que se pierdan algunos de estos mensajes de monitoreo. En situaciones extremas, los mensajes perdidos pueden provocar que los hosts inesperadamente tomen medidas de seguridad. Al utilizar la función de alta disponibilidad, recomendamos utilizar grupos más pequeños, con un máximo de 16 hosts, para reducir el riesgo de cercas inesperadas.
Para la mayoría de los casos de uso de Citrix Virtual Apps and Desktops, recomendamos un tamaño de grupo de 16 hosts, con un tamaño máximo de 32.
Además de considerar estos factores al planificar el tamaño de su piscina, observe y controle el comportamiento de su piscina para determinar si necesita cambiar el tamaño de la piscina en su entorno de carrera.
Comunicarse con hosts y grupos de recursos de XenServer
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 por parte del cliente en la funcionalidad criptográfica del producto.
XenServer utiliza los siguientes conjuntos de cifrado:
- ECDHE-RSA-AES256-GCM-SHA384
- ECDHE-RSA-AES128-GCM-SHA256
SSH
Cuando se utiliza un cliente SSH para conectarse directamente al host de XenServer, se pueden utilizar los siguientes algoritmos:
Cifras:
- AES128-CTR
- AES256-CTR
- aes128-gcm@openssh.com
- aes256-gcm@openssh.com
Macs:
- HMAC-SHA2-256
- HMAC-SHA2-512
- HMAC-SHA1
KexAlgoritmos:
- curva25519-sha256
- ECDH-SHA2-NISTAP256
- ECDH-SHA2-NETCP384
- ECDH-SHA2-NISTAP521
- diffie-hellman-grupo14-sha1
Algoritmos de HostKey:
- ECDSA-SHA2-NISTAP256
- ECDSA-SHA2-NISTAP384
- ECDSA-SHA2-NISTAP521
- SSH-ED25519
- SSH-RSA
Importante:
No admitimos modificaciones por parte del cliente en la funcionalidad criptográfica del producto. Sin embargo, si desea deshabilitar el acceso SSH a un host XenServer, consulte Deshabilitar el acceso SSH para un host o Deshabilitar el acceso SSH para un grupo.
¿Qué sucede cuando un host se une a un grupo de recursos?
Cuando un nuevo host se une a un grupo de recursos, el host de unión sincroniza su base de datos local con la de todo el grupo y hereda algunas opciones de configuración del grupo:
-
La configuración de almacenamiento local, remoto y de VM se agrega a la base de datos de todo el grupo. Esta configuración se aplica al host que se une en el grupo, a menos que los recursos se compartan explícitamente después de que el host se una al grupo.
-
El host de unión hereda los repositorios de almacenamiento compartido existentes en el grupo. Se crean los registros PBD adecuados 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: el estructural los detalles de las NIC, VLAN e interfaces enlazadas se heredan, pero política La información no lo es. Esta información de directiva, que se debe reconfigurar, 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 de grupo tienen interfaces de administración en una interfaz vinculada, el host de unión debe migrarse al enlace después de unirse.
-
NIC de almacenamiento dedicado, que se deben reasignar al host de unión desde XenCenter o la CLI, y los PBD reconectados 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.
-