Administrar sus pools

Este artículo describe algunas de las acciones que puede realizar para administrar su pool.

Para administrar hosts individuales, consulte Administrar sus hosts.

Crear un pool de recursos

Los pools de recursos se pueden crear usando XenCenter® o la CLI. Cuando un nuevo host se une a un pool de recursos, el host que se une sincroniza su base de datos local con la del pool y hereda algunas configuraciones del pool:

• La configuración de almacenamiento de VM, local y remoto se añade a la base de datos de todo el pool. Esta configuración se aplica al host que se une al pool a menos que explícitamente haga que los recursos se compartan después de que el host se una al pool.

• El host que se une hereda los repositorios de almacenamiento compartido existentes en el pool. 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, 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 pool 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 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 pool, 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.

  • Reconfigure la interfaz de administración y muévala a una NIC física antes de añadir el host al pool. Después de que el host se haya unido al pool, puede volver a configurar la interfaz de administración.

Antes de crear un pool de recursos, revise los requisitos para el pool y el host que se une. Para obtener más información, consulte Pools de recursos.

Añadir un host a un pool usando la CLI de xe

1. Actualice su pool y el host que se une al mismo nivel antes de intentar la unión. Puede hacerlo de una de las siguientes maneras:

   • Actualice el host que se va a unir al mismo nivel que el pool:

     • (Recomendado) Sincronizando el host que se va a unir con el pool y actualizando a partir de los archivos de actualización que se encuentran en el coordinador del pool. Para obtener más información, consulte Actualizar al nivel del pool.
     • Descargando un paquete de actualización que coincida con el nivel del pool y usándolo para actualizar el host que se va a unir.

   • Actualice tanto el pool como el host que se va a unir al nivel más reciente:

     • Sincronizando el host y el pool con el mismo canal de actualización y aplicando las últimas actualizaciones.
     • Mediante el mecanismo de actualizaciones sin conexión para aplicar el nivel más reciente de actualizaciones tanto al host como al pool.

   Para obtener más información sobre estos métodos de actualización, consulte Aplicar actualizaciones mediante XenCenter o Aplicar actualizaciones mediante la CLI xe.

2. Abra una consola en el host XenServer® que desea unir a un pool.

3. Una el host XenServer al pool emitiendo el comando:

   xe pool-join master-address=<address of pool coordinator> master-username=<administrator username> master-password=<password>
   <!--NeedCopy-->
   

   master-address debe establecerse en el nombre de dominio completo del coordinador del pool. password debe ser la contraseña de administrador establecida cuando se instaló el coordinador del pool.

Nota:

Cuando se une un host a un pool, la contraseña de administrador del host que se une se cambia automáticamente para que coincida con la contraseña de administrador del coordinador del pool.

Los hosts XenServer pertenecen a un pool sin nombre de forma predeterminada. Para crear su primer pool de recursos, cambie el nombre del pool sin nombre existente. Use la función de autocompletar con tabulador para encontrar pool_uuid:

xe pool-param-set name-label="New Pool" uuid=pool_uuid
<!--NeedCopy-->

Crear pools de recursos heterogéneos

XenServer simplifica la expansión de las implementaciones a lo largo del tiempo al permitir que hardware de host dispar se una a un pool de recursos, conocido como pools de recursos heterogéneos. Los pools de recursos heterogéneos son posibles gracias al uso de tecnologías en las CPU de Intel (FlexMigration) y AMD (Extended Migration) que proporcionan “enmascaramiento” o “nivelación” de la CPU. Las funciones de enmascaramiento y nivelación de la CPU permiten configurar una CPU para que parezca que proporciona una marca, modelo o funcionalidad diferente de la que realmente tiene. Esta función le permite crear pools de hosts con CPU dispares, pero aun así admitir de forma segura la migración en vivo.

Nota:

Las CPU de los hosts de XenServer que se unen a grupos heterogéneos deben ser del mismo proveedor (es decir, AMD, Intel) que las CPU de los hosts que ya están en el grupo. Sin embargo, no es necesario que los hosts sean del mismo tipo a nivel de familia, modelo o números de paso.

XenServer simplifica la compatibilidad con grupos heterogéneos. Ahora se pueden agregar hosts a grupos de recursos existentes, independientemente del tipo de CPU subyacente (siempre que la CPU sea de la misma familia de proveedores). El conjunto de características del grupo se calcula dinámicamente cada vez que:

• Un nuevo host se une al grupo

• Un miembro del grupo abandona el grupo

• Un miembro del grupo se vuelve a conectar después de un reinicio

Cualquier cambio en el conjunto de características del grupo no afecta a las máquinas virtuales que se están ejecutando actualmente en el grupo. Una máquina virtual en ejecución continúa utilizando el conjunto de características que se aplicó cuando se inició. Este conjunto de características se fija en el arranque y persiste durante las operaciones de migración, suspensión y reanudación. Si el nivel del grupo disminuye cuando un host menos capaz se une al grupo, una máquina virtual en ejecución se puede migrar a cualquier host del grupo, excepto al host recién agregado. Cuando mueve o migra una máquina virtual a un host diferente dentro o entre grupos, XenServer compara el conjunto de características de la máquina virtual con el conjunto de características del host de destino. Si se determina que los conjuntos de características son compatibles, se permite la migración de la máquina virtual. Esto permite que la máquina virtual se mueva libremente dentro y entre grupos, independientemente de las características de la CPU que esté utilizando la máquina virtual. Si utiliza el equilibrio de carga de trabajo para seleccionar un host de destino óptimo para migrar su máquina virtual, no se recomendará un host con un conjunto de características incompatible como host de destino.

Agregar almacenamiento compartido

Esta sección muestra un ejemplo de cómo se puede crear almacenamiento compartido (representado como un repositorio de almacenamiento) en un servidor NFS existente. Para obtener una lista completa de los tipos de almacenamiento compartido admitidos, consulte Almacenamiento.

Para agregar almacenamiento compartido NFS a un grupo de recursos mediante la CLI

1. Abra una consola en cualquier host de XenServer del grupo.

2. Cree el repositorio de almacenamiento en server:/path emitiendo el siguiente comando:

   xe sr-create content-type=user type=nfs name-label="Example SR" shared=true \
       device-config:server=server \
       device-config:serverpath=path
   <!--NeedCopy-->
   

   device-config:server es el nombre de host del servidor NFS y device-config:serverpath es la ruta en el servidor NFS. Como shared está establecido en true, el almacenamiento compartido se conecta automáticamente a todos los hosts de XenServer del grupo. Cualquier host de XenServer que se una más tarde también se conecta al almacenamiento. El identificador único universal (UUID) del repositorio de almacenamiento se imprime en la pantalla.

3. Busque el UUID del grupo ejecutando el siguiente comando:

   xe pool-list
   <!--NeedCopy-->
   

4. Establezca el almacenamiento compartido como predeterminado para todo el grupo con el siguiente comando:

   xe pool-param-set uuid=pool_uuid default-SR=sr_uuid
   <!--NeedCopy-->
   

   Como el almacenamiento compartido se ha establecido como predeterminado para todo el pool, todas las VM futuras tendrán sus discos creados en el almacenamiento compartido por defecto. Para obtener información sobre cómo crear otros tipos de almacenamiento compartido, consulte Crear un SR.

Eliminar hosts de XenServer de un pool de recursos

Nota:

Antes de eliminar cualquier host de XenServer de un pool, asegúrese de apagar todas las VM que se ejecutan en ese host. De lo contrario, podría ver una advertencia indicando que el host no se puede eliminar.

Cuando se elimina (expulsa) un host de un pool, la máquina se reinicia, se reinicializa y se deja en un estado similar a una instalación nueva. No expulse hosts de XenServer de un pool si hay datos importantes en los discos locales.

Para eliminar un host de un pool de recursos mediante la CLI

1. Abra una consola en cualquier host del pool.

2. Busque el UUID del host ejecutando el siguiente comando:

   xe host-list
   <!--NeedCopy-->
   

3. Expulse el host requerido del pool:

   xe pool-eject host-uuid=host_uuid
   <!--NeedCopy-->
   

   El host de XenServer se expulsa y se deja en un estado recién instalado.

   Advertencia:

   No expulse un host de un pool de recursos si contiene datos importantes almacenados en sus discos locales. Todos los datos se borran cuando se expulsa un host del pool. Si desea conservar estos datos, copie la VM al almacenamiento compartido del pool mediante XenCenter o el comando CLI xe vm-copy.

Cuando los hosts de XenServer que contienen VM almacenadas localmente se expulsan de un pool, las VM estarán presentes en la base de datos del pool. Las VM almacenadas localmente también son visibles para los otros hosts de XenServer. Las VM no se inician hasta que los discos virtuales asociados a ellas se hayan cambiado para apuntar al almacenamiento compartido visto por otros hosts de XenServer en el pool, o se hayan eliminado. Por lo tanto, recomendamos que mueva cualquier almacenamiento local a almacenamiento compartido al unirse a un pool. Moverse a almacenamiento compartido permite que los hosts individuales de XenServer sean expulsados (o fallen físicamente) sin pérdida de datos.

Nota:

Cuando se elimina un host de un pool que tiene su interfaz de administración en una red VLAN etiquetada, la máquina se reinicia y su interfaz de administración estará disponible en la misma red.

Rotar el secreto del pool

El secreto del pool es un secreto compartido entre los hosts de un pool que permite al host demostrar su pertenencia a un pool.

Dado que los usuarios con el rol de Administrador de pool pueden descubrir este secreto, es una buena práctica rotar el secreto del pool si uno de estos usuarios abandona su organización o pierde su rol de Administrador de pool.

Puede rotar el secreto del pool usando XenCenter o la CLI de xe.

XenCenter

Para rotar el secreto del pool de un pool usando XenCenter, complete los siguientes pasos:

1. En el panel de Recursos, seleccione el pool o cualquier host del pool.
2. En el menú Pool, seleccione Rotar secreto del pool.

Cuando rota el secreto del pool, también se le pide que cambie la contraseña de root. Si rotó el secreto del pool porque cree que su entorno ha sido comprometido, asegúrese de cambiar también la contraseña de root del coordinador del pool. Para obtener más información, consulte Cambiar la contraseña.

CLI de xe

Para rotar el secreto del pool usando la CLI de xe, ejecute el siguiente comando en un host del pool:

xe pool-secret-rotate
<!--NeedCopy-->

Si rotó el secreto del pool porque cree que su entorno ha sido comprometido, asegúrese de cambiar también la contraseña de root. Para obtener más información, consulte Cambiar la contraseña.

Configurar el acceso SSH

El acceso SSH a su pool de XenServer está habilitado de forma predeterminada. Si desea deshabilitar el acceso SSH a su pool de XenServer, ejecute el siguiente comando:

xe pool-disable-ssh pool=<pool_uuid_or_name_label>
<!--NeedCopy-->

Este comando deshabilita SSH. El pool rechaza las nuevas conexiones SSH, pero no desconectar ninguna sesión existente.

Para habilitar el acceso SSH a su pool de XenServer, ejecute el siguiente comando:

xe pool-enable-ssh pool=<pool_uuid_or_name_label>
<!--NeedCopy-->

Para establecer el tiempo de espera de habilitación temporal de SSH del pool actual (segundos):

xe pool-param-set uuid=<pool-uuid> ssh-enabled-timeout=<seconds>
<!--NeedCopy-->

El parámetro de tiempo de espera determina la duración del servicio SSH. Cuando se establece en 0, SSH permanece activo indefinidamente. Cuando se establece en un número entero positivo (segundos), SSH se deshabilita automáticamente después del período especificado. Los cambios de configuración tienen efecto inmediato en las sesiones SSH activas posteriores y cada vez que el usuario habilita SSH.

Nota:

El valor máximo que puede establecer para ssh-enabled-timeout es de 172800 segundos (lo que equivale aproximadamente a 2 días).

Para establecer el tiempo de espera de inactividad de la consola SSH del pool actual (segundos)

xe pool-param-set uuid=<pool-uuid> console-idle-timeout=<seconds>
<!--NeedCopy-->

Configure el tiempo de espera de sesión inactiva para las conexiones de consola VNC y SSH utilizando un valor entero no negativo en segundos, donde 0 deshabilita el tiempo de espera (las sesiones nunca caducan) y los valores positivos (por ejemplo, 3600) terminan automáticamente las sesiones inactivas después de la duración especificada, con la configuración aplicándose a las sesiones de consola recién creadas después de la configuración.

Para establecer el modo automático de SSH del pool actual

xe poolparam-set uuid=<pool-uuid>  ssh-auto-mode=true
<!--NeedCopy-->

Configure la gestión automática de SSH basada en el estado de salud del servicio XAPI. Cuando el modo automático está habilitado, la activación de SSH sigue el estado de XAPI: SSH se deshabilita cuando XAPI está en buen estado y se habilita cuando XAPI no está en buen estado.

Modo automático habilitado + ssh_enabled_timeout = 0: La activación manual de SSH a través de pool.enable_ssh deshabilita permanentemente el modo automático.

Modo automático habilitado + ssh_enabled_timeout > 0: La activación manual de SSH deshabilita temporalmente el modo automático; el modo automático se restaura a la configuración original cuando expira el tiempo de espera. (Cuando se produce un reinicio del sistema durante un período de tiempo de espera de SSH activo, la configuración original del modo automático se pierde y se restablece a habilitado al expirar el tiempo de espera/recuperación).

Para el valor del parámetro del pool en cualquiera de estos comandos, puede usar un selector de pool. Para obtener más información, consulte Comandos de pool.

Puede gestionar el acceso SSH para todos los pools en un pool de XenServer al mismo tiempo. Para obtener más información, consulte Deshabilitar el acceso SSH para un pool.

Comportamiento de unión / expulsión de pool

• Unión – Cuando un servidor se une a un pool, se heredan las configuraciones de SSH (tiempo de espera de SSH habilitado, tiempo de espera de consola inactiva, modo automático).

• Expulsar – Cuando un servidor es expulsado de un pool, se restauran las configuraciones predeterminadas.

  • XenServer 8.4: SSH habilitado, modo automático desactivado

Definición del nuevo control de administración de SSH

Establezca la nueva API de XAPI pool.set_ssh_auto_mode a nivel de pool para configurar SSH

set_ssh_auto_mode: Configure para habilitar o deshabilitar el modo automático de SSH. Cuando el modo automático está habilitado, el estado de SSH depende del estado de XAPI: SSH está deshabilitado cuando XAPI está en buen estado, y SSH está habilitado cuando XAPI no está en buen estado.

Cuando un usuario establece el modo automático en habilitado y el ssh_enabled_timeout actual es 0, habilitar SSH con pool.enable_ssh deshabilitará permanentemente el modo automático.

Cuando un usuario establece el modo automático con pool.set_auto_mode como habilitado o deshabilitado, esto se denomina la “configuración original del modo automático”. Si el ssh_enabled_timeout actual se establece en un número positivo (por ejemplo, 1800 segundos), habilitar SSH con pool.enable_ssh deshabilitará temporalmente el modo automático. Cuando el período de tiempo de espera expire, SSH se deshabilitará automáticamente y el modo automático se restaurará a su configuración original.

Cuando un usuario establece ssh_enabled_timeout en un número positivo (por ejemplo, 3600 segundos) y reinicia el host (o reinicia XAPI) antes de que expire el período de tiempo de espera, una vez que expire el período de tiempo de espera, SSH se deshabilitará automáticamente y el modo automático se restaurará a verdadero, ya que el reinicio habrá perdido la configuración original del modo automático.

Cuando configure ssh_enabled_timeout en un número positivo (por ejemplo, 180 segundos) y XAPI falle posteriormente, si XAPI permanece en un estado fallido cuando expire el período de tiempo de espera, SSH permanecerá habilitado hasta que XAPI se reinicie. Tras el reinicio de XAPI, SSH se deshabilitará automáticamente y el modo automático se restaurará a verdadero, ya que el reinicio del sistema provoca la pérdida de la configuración original del modo automático.

This command disables SSH. The hosts refuse new SSH connections, but do not disconnect any existing sessions.

To enable SSH access to all hosts in your pool, run the following command:

xe pool-enable-ssh ```

Both of these commands attempt to make a change on all hosts in the pool. If the command fails on one or more of the hosts in your pool, the command continues to run for all other hosts in the pool. The command returns a list of any hosts where the command fails.

You can manage the SSH access for an individual host. For more information, see Disable SSH access for a host.–>

Habilitar el snooping de IGMP en su pool de XenServer

XenServer envía tráfico de multidifusión a todas las máquinas virtuales invitadas, lo que provoca una carga innecesaria en los dispositivos del host al requerirles que procesen paquetes que no han solicitado. La habilitación del snooping de IGMP evita que los hosts de una red local reciban tráfico para un grupo de multidifusión al que no se han unido explícitamente, y mejora el rendimiento de la multidifusión. El snooping de IGMP es especialmente útil para aplicaciones de multidifusión IP que consumen mucho ancho de banda, como IPTV.

Notas:

• Al habilitar esta función en un pool, también puede ser necesario habilitar el interrogador IGMP en uno de los conmutadores físicos. De lo contrario, la multidifusión en la subred recurre a la difusión y puede disminuir el rendimiento de XenServer.

• Al habilitar esta función en un pool que ejecuta IGMP v3, la migración de VM o la conmutación por error de enlace de red da como resultado el cambio de la versión de IGMP a v2.

• Para habilitar esta función con una red GRE, los usuarios deben configurar un interrogador IGMP en la red GRE. Alternativamente, puede reenviar el mensaje de consulta IGMP desde la red física a la red GRE. De lo contrario, el tráfico de multidifusión en la red GRE puede ser bloqueado.

Puede habilitar el snooping IGMP en un grupo mediante XenCenter o la CLI de xe.

XenCenter

1. Vaya a Propiedades del grupo.
2. Seleccione Opciones de red. Aquí puede habilitar o deshabilitar el snooping IGMP.

CLI de xe

1. Obtenga el UUID del grupo:

   xe pool-list

2. Habilite/deshabilite el snooping IGMP para el grupo:

   xe pool-param-set [uuid=pool-uuid] [igmp-snooping-enabled=true|false]

Después de habilitar el snooping IGMP, puede ver la tabla de snooping IGMP mediante la CLI de xe.

Ver la tabla de snooping IGMP

Utilice el siguiente comando para ver la tabla de snooping IGMP:

ovs-appctl mdb/show [bridge name]

Nota:

Puede obtener el nombre del puente usando xe network-list. Estos nombres de puente pueden ser xenbr0, xenbr1, xenapi o xapi0.

Esto genera una tabla con cuatro columnas:

• puerto: El puerto del conmutador (OVS).
• VLAN: El ID de VLAN del tráfico.
• GRUPO: El grupo de multidifusión que solicitó el puerto.
• Antigüedad: La antigüedad de este registro en segundos.

Si el GRUPO es una dirección de grupo de multidifusión, esto significa que se recibe un mensaje de informe IGMP en el puerto del conmutador asociado. Esto significa que un receptor (miembro) del grupo de multidifusión está escuchando en este puerto.

Considere el siguiente ejemplo que contiene dos registros:

El primer registro muestra que hay un receptor escuchando en el puerto 14 para el grupo de multidifusión 227.0.0.1. El Open vSwitch reenvía el tráfico destinado al grupo de multidifusión 227.0.0.1 a los puertos de escucha solo para este grupo (en este ejemplo, el puerto 14), en lugar de transmitirlo a todos los puertos. El registro que vincula el puerto 14 y el grupo 227.0.0.1 se creó hace 15 segundos. Por defecto, el intervalo de tiempo de espera es de 300 segundos. Esto significa que si el conmutador no recibe más mensajes de informe IGMP en el puerto 14 durante 300 segundos después de añadir el registro, el registro caduca y se elimina de la tabla.

En el segundo registro, el GRUPO es consultor, lo que significa que se han recibido mensajes de consulta IGMP en el puerto asociado. Un consultor envía periódicamente mensajes de consulta IGMP, que se transmiten a todos los puertos del conmutador, para determinar qué nodos de red están escuchando en un grupo de multidifusión. Al recibir un mensaje de consulta IGMP, el receptor responde con un mensaje de informe IGMP, lo que hace que el registro de multidifusión del receptor se actualice y evite la caducidad.

La columna VLAN indica la VLAN en la que reside un receptor/consultor. ‘0’ significa VLAN nativa. Si desea ejecutar multidifusión en alguna VLAN etiquetada, asegúrese de que haya registros en la VLAN.

Nota:

Para el escenario de VLAN, debe tener un registro de consultor con un valor de columna VLAN igual al ID de VLAN de la red; de lo contrario, la multidifusión no funcionará en la red VLAN.

Habilitar la compresión de flujo de migración en su pool de XenServer

Durante la migración en vivo de una VM, su memoria se transfiere como un flujo de datos entre dos hosts utilizando la red. La función de compresión de flujo de migración comprime este flujo de datos, acelerando la transferencia de memoria en redes lentas. Esta función está deshabilitada por defecto, pero se puede cambiar usando XenCenter o la CLI de xe. Para obtener más información, consulte Propiedades del pool - Avanzado y Parámetros del pool. Alternativamente, puede habilitar la compresión al migrar una VM usando la línea de comandos. Para obtener más información, consulte el comando vm-migrate en Comandos de VM.

Exportar datos del pool de recursos

La opción Exportar datos de recursos le permite generar un informe de datos de recursos para su pool y exportar el informe a un archivo .xls o .csv. Este informe proporciona información detallada sobre varios recursos en el pool, como hosts, redes, almacenamiento, máquinas virtuales, VDI y GPU. Esta función permite a los administradores rastrear, planificar y asignar recursos basándose en diversas cargas de trabajo como CPU, almacenamiento y red.

Nota:

La exportación de datos del pool de recursos está disponible para los clientes de XenServer Premium Edition.

La lista de recursos y varios tipos de datos de recursos que se incluyen en el informe:

Servidor:

• Nombre
• Coordinador de pool
• UUID
• Dirección
• Uso de CPU
• Red (KB promedio/máximo)
• Memoria utilizada
• Almacenamiento
• Tiempo de actividad
• Descripción

Redes:

• Nombre
• Estado del enlace
• MAC
• MTU
• VLAN
• Tipo
• Ubicación

VDI:

• Nombre
• Tipo
• UUID
• Tamaño
• Almacenamiento
• Descripción

Almacenamiento:

• Nombre
• Tipo
• UUID
• Tamaño
• Ubicación
• Descripción

Máquinas virtuales:

• Nombre
• Estado de energía
• Ejecutándose en
• Dirección
• MAC
• NIC
• Sistema operativo
• Almacenamiento
• Memoria utilizada
• Uso de CPU
• UUID
• Tiempo de actividad
• Plantilla
• Descripción

GPU:

• Nombre
• Servidores
• Ruta del bus PCI
• UUID
• Consumo de energía
• Temperatura
• Memoria utilizada
• Utilización del equipo

Nota:

La información sobre las GPU solo está disponible si hay GPU conectadas a su host XenServer.

Para exportar datos de recursos

1. En el panel de navegación de XenCenter, seleccione Infraestructura y, a continuación, seleccione el grupo.

2. Seleccione el menú Grupo y, a continuación, Exportar datos de recursos.

3. Busque una ubicación donde desee guardar el informe y, a continuación, haga clic en Guardar.