Hosts y grupos de recursos

En esta sección se describe cómo se pueden crear grupos de recursos mediante una serie de ejemplos utilizando la interfaz de línea de comandos (CLI) xe. Se presenta una sencilla configuración de almacenamiento compartido basada en NFS y se analizan varios ejemplos sencillos de administración de VM. También contiene procedimientos para tratar los fallos físicos de nodos.

información general sobre los hosts y los grupos de recursos

Un fondo de recursos consta de varias instalaciones de host, enlazadas juntas a una única entidad administrada que puede alojar máquinas virtuales. Si se combina con almacenamiento compartido, un fondo de recursos permite que las VM se inicien en cualquier host que tenga suficiente memoria. Las máquinas virtuales se pueden mover dinámicamente entre hosts mientras se ejecutan con un tiempo de inactividad mínimo (). Si un host individual sufre una falla de hardware, el administrador puede reiniciar las máquinas virtuales con errores en otro host del mismo fondo de recursos. Cuando se habilita la alta disponibilidad en el fondo de recursos, las VM se mueven automáticamente a otro host cuando su host falla. Se admiten hasta 64 hosts por grupo de recursos, aunque esta restricción no se aplica.

Un grupo siempre tiene al menos un nodo físico, conocido como el maestro. Sólo el nodo maestro expone una interfaz de administración (utilizada por y la Interfaz de línea de comandos, conocida como la CLI xe). El maestro reenvía comandos a miembros individuales según sea necesario.

Nota:

Cuando falla el maestro de grupo, la reelección maestra sólo se lleva a cabo si la alta disponibilidad está habilitada.

Requisitos para crear agrupaciones de recursos

Un grupo de recursos es un agregado homogéneo (o heterogéneo con restricciones) de uno o más hosts, hasta un máximo de 64. La definición de homogéneo es:

• Las CPU del servidor que se une al grupo son las mismas (en términos del proveedor, el modelo y las características) que las CPU de los servidores que ya están en el grupo.

• El servidor que se une al grupo ejecuta la misma versión de software, en el mismo nivel de revisión, que los servidores que ya están en el grupo.

El software impone restricciones adicionales al unir un servidor a un grupo. En particular, comprueba que se cumplen las condiciones siguientes para el servidor que se une al grupo:

• El servidor no es miembro de un fondo de recursos existente.

• El servidor no tiene almacenamiento compartido configurado.

• El servidor no aloja máquinas virtuales en ejecución o suspendidas.

• No hay operaciones activas en curso en las máquinas virtuales del servidor, como el cierre de una máquina virtual.

• El reloj en el servidor se sincroniza al mismo tiempo que el maestro de grupo (por ejemplo, mediante NTP).

• La interfaz de administración del servidor no está vinculada. Puede configurar la interfaz de administración cuando el servidor se une correctamente al grupo.

• La dirección IP de administración es estática, ya sea configurada en el propio servidor o mediante una configuración adecuada en el servidor DHCP.

en los grupos de recursos pueden contener diferentes números de interfaces de red físicas y tener repositorios de almacenamiento locales de diferente tamaño . En la práctica, a menudo es difícil obtener varios servidores con las mismas CPU exactas, por lo que se permiten variaciones menores. Si es aceptable tener hosts con CPU variables como parte del mismo grupo, puede forzar la operación de unión de grupo pasando el--force parámetro.

Todos los hosts del grupo deben estar en el mismo sitio y conectados por una red de baja latencia.

Nota:

Los servidores que proporcionan almacenamiento NFS o iSCSI compartido para el grupo deben tener una dirección IP estática.

Un grupo debe contener repositorios de almacenamiento compartido para seleccionar en qué host ejecutar una máquina virtual y mover una máquina virtual entre hosts dinámicamente. Si es posible, cree un grupo después de que esté disponible el almacenamiento compartido. recomienda mover máquinas virtuales existentes con discos ubicados en almacenamiento local al almacenamiento compartido después de agregar almacenamiento compartido. Puede utilizar elxe vm-copy comando o utilizar para mover máquinas virtuales.

Crear un fondo de recursos

Los grupos de recursos se pueden crear usando o la CLI. Cuando un nuevo host se une a un fondo de recursos, el host de unión sincroniza su base de datos local con la de todo el 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 de unión en el grupo a menos que se compartan explícitamente los recursos después de que el host se une al grupo.

• El host de unión hereda los repositorios de almacenamiento compartido existentes en el grupo. Se crean 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 vinculadas se heredan, pero la información de política no lo es. Esta información de directiva, que debe reconfigurarse, incluye:

  • Las direcciones IP de las NICs 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 unida, el host de unión debe migrarse al vínculo después de la unión.

  • NIC de almacenamiento dedicadas, que deben reasignarse al host que se une desde 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 de grupo y la NIC de almacenamiento sólo funciona cuando está configurada correctamente. Consulte Administrar redespara obtener más información sobre cómo dedicar una NIC de almacenamiento desde la CLI.

Nota:

Sólo puede unir un nuevo host a un fondo de recursos cuando la interfaz de administración del host está en la misma VLAN etiquetada que la del fondo de recursos.

Para unir hosts host1 y host2 en un fondo de recursos mediante la CLI

1. Abra una consola en el host host 2.

2. Comando host host2 para unirse al grupo en host host1 emitiendo el comando:

   xe pool-join master-address = host1 master-username = administrators_username master-password = password
   

master-address Debe establecerse en el nombre de dominio completo del host host 1 . password`` Debe ser la contraseña de administrador establecida cuando se instaló host 1 .

pertenecen a un grupo sin nombre de forma predeterminada. Para crear el primer fondo de recursos, cambie el nombre del grupo sin nombre existente. Use tab-complete para encontrarpool_uuid:

xe pool-param-set name-label = “Nuevo grupo” uuid = pool_uuid

Crear grupos de recursos heterogéneos

simplifica la expansión de las implementaciones a lo largo del tiempo al permitir que se unan hardware de host dispare a un fondo de recursos, conocido como pools de recursos heterogéneos. Los grupos de recursos heterogéneos son posibles mediante el uso de tecnologías en CPU Intel (FlexMigration) y AMD (Extended Migration) que proporcionan “enmascaramiento” o “nivelación” de la CPU. Las funciones de enmascaramiento y nivelación de CPU permiten que una CPU se configure para que aparezca como una marca, modelo o funcionalidad diferente de la que realmente lo hace. Esta característica le permite crear grupos de hosts con CPU dispares, pero aún así admite la migración en vivo de forma segura.

Nota:

Nota:

Las CPU de los hosts que se unen a grupos heterogéneos deben ser del mismo proveedor (es decir, AMD, Intel) que las CPU de los hosts del grupo. Sin embargo, el tipo específico (familia, modelo y números de paso) no es necesario.

simplifica el soporte de grupos heterogéneos. Los hosts ahora se pueden agregar a los grupos de recursos existentes, independientemente del tipo de CPU subyacente (siempre que la CPU pertenezca a la misma familia de proveedores). El conjunto de entidades de grupo se calcula dinámicamente cada vez:

• Un nuevo host se une al grupo

• Un miembro del grupo abandona el grupo

• Un miembro del grupo se vuelve a conectar tras un reinicio

Cualquier cambio en el conjunto de características de agrupación 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 funciones se corrige en el arranque y persiste en las operaciones de migración, suspensión y reanudación. Si el nivel de grupo disminuye cuando un host con menos capacidad se une al grupo, se puede migrar una máquina virtual en ejecución a cualquier host del grupo, excepto el host recién agregado. Cuando mueve o migra una máquina virtual a un host diferente dentro o entre grupos, compara el conjunto de características de la máquina virtual con el conjunto de características del host de destino. Si se encuentra 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 CPU que utilice la máquina virtual. Si utiliza Equilibrio de carga de trabajo para seleccionar un host de destino óptimo para migrar la máquina virtual, no se recomendará un host con un conjunto de características incompatible como host de destino.

Agregar almacenamiento compartido

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

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

1. Abra una consola en cualquier host del grupo.

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

   xe sr-create content-type = user type = nfs name-label = “Ejemplo SR” shared = true \
   device-config: servidor = servidor \
   device-config: ruta de acceso de servidor = ruta
   

   device-config:server Es el nombre de host del servidor NFS ydevice-config:serverpath es la ruta de acceso del servidor NFS. Tal comoshared se establece en true, el almacenamiento compartido se conecta automáticamente a todos los hosts del grupo. Los hosts que se unan más tarde también están conectados al almacenamiento. El identificador universal único (UUID) del repositorio de almacenamiento se imprime en la pantalla.

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

   xe pool list
   

4. Establezca el almacenamiento compartido como predeterminado para toda la agrupación con el comando

   xe pool-param-set uuid = pool_uuid Default-sr = sr_uuid
   

   Dado que el almacenamiento compartido se ha establecido como predeterminado para toda la agrupación, todas las máquinas virtuales futuras tienen sus discos creados en almacenamiento compartido de forma predeterminada. Consulte Formatos de repositorio de almacenamientopara obtener información sobre la creación de otros tipos de almacenamiento compartido.

Quitar hosts de un fondo de recursos

Nota:

Antes de quitar cualquier host de un grupo, asegúrese de apagar todas las máquinas virtuales que se ejecutan en ese host. De lo contrario, puede ver una advertencia que indica que el host no se puede quitar.

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

Para quitar un host de un fondo de recursos mediante la CLI

1. Abra una consola en cualquier host del grupo.

2. Busque el UUID del host ejecutando el comando

   xe lista de host
   

3. Expulse el host requerido del grupo:

   xe pool-eject host-uuid = host_uuid
   

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

   Advertencia:

   No expulse un host de un fondo de recursos si contiene datos importantes almacenados en sus discos locales. Todos los datos se borran cuando se expulsa un host del grupo. Si desea conservar estos datos, copie la máquina virtual en el almacenamiento compartido en el grupo mediante , o el comandoxe vm-copy CLI.

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

Nota:

Cuando se quita un host de un grupo 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.

Preparar un grupo de hosts para el mantenimiento

Antes de realizar operaciones de mantenimiento en un host que forma parte de un fondo de recursos, debe deshabilitarlo. Al deshabilitar el host se impide que las VM se inicien en él. A continuación, debe migrar sus máquinas virtuales a otro host del grupo. Puede hacerlo colocando el host en el modo Mantenimiento usando . Consulte la Ayuda para obtener más información.

La sincronización de copia de seguridad se produce cada 24 horas. Al colocar el host maestro en modo de mantenimiento, se pierden las últimas 24 horas de actualizaciones de RRD para máquinas virtuales sin conexión.

Advertencia:recomienda

encarecidamente reiniciar todos los hosts antes de instalar una actualización y, a continuación, verificar su configuración. Algunos cambios de configuración sólo tienen efecto cuando se reinicia, por lo que el reinicio puede descubrir problemas de configuración que pueden provocar un error en la actualización.

Para preparar un host en un grupo para operaciones de mantenimiento mediante la CLI

1. Ejecute el siguiente comando:

   xe host-disable uuid =_host_uuid
   xe host-evacuar uuid =_host_uuid
   

   Este comando deshabilita el host y, a continuación, migre las máquinas virtuales en ejecución a otros hosts del grupo.

2. Realice la operación de mantenimiento deseada.

3. Habilite el host cuando finalice la operación de mantenimiento:

   xe habilitar host
   

4. Reinicie las máquinas virtuales detenidas y reanude las máquinas virtuales suspendidas.

Exportar datos del fondo de recursos

La opción Exportar datos de recursos permite generar un informe de datos de recursos para el grupo y exportarlo a un archivo..xls o .csv. Este informe proporciona información detallada sobre varios recursos del grupo, como servidores, redes, almacenamiento, máquinas virtuales, VDIS y GPU. Esta característica permite a los administradores realizar un seguimiento, planificar y asignar recursos en función de diversas cargas de trabajo, como CPU, almacenamiento y Red.

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

Servidor:

• Nombre
• Maestro de agrupaciones
• UUID
• Dirección
• Uso de CPU
• Red (KBs avg/máx)
• Memoria usada
• 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

VM:

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

GPU:

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

Nota:

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

Para exportar datos de recursos

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

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

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

Encendido del host

Encender los hosts de forma remota

Puede utilizar la función Encendido del host para encender y apagar un servidor de forma remota, ya sea desde o utilizando la CLI.

Para habilitar la alimentación del host, el host debe tener una de las siguientes soluciones de control de energía:

• Desactivar la tarjeta de red habilitada para LAN.

• Tarjetas de acceso remoto de Dell (DRAC). Para usar con DRAC, debe instalar el paquete complementario de Dell para obtener asistencia de DRAC. La compatibilidad con DRAC requiere instalar la utilidad de línea de comandos RACADM en el servidor con el controlador de acceso remoto y habilitar DRAC y su interfaz. RACIADM se incluye a menudo en el software de gestión DRAC. Para obtener más información, consulte la documentación de DRAC de Dell.

• Hewlett-Packard Integrated Lights-Out (iLO). Para utilizar con iLO, debe habilitar iLO en el host y conectar la interfaz a la red. Para obtener más información, consulte la documentación de HP iLO.

• Un script personalizado basado en la API de administración que le permite activar y desactivar la alimentación . Para obtener más información, vea Configuración de una secuencia de comandos personalizada para la característica Encendido del host en la sección siguiente.

El uso de la función de encendido del host requiere dos tareas:

1. Asegúrese de que los hosts del grupo admiten controlar la energía de forma remota. Por ejemplo, tienen la funcionalidad Wake on LAN, una tarjeta DRAC o iLO, o ha creado un script personalizado).

2. Habilite la funcionalidad de encendido del host mediante la CLI o .

Utilice la CLI para administrar la alimentación del host en

Puede administrar la función de encendido del host mediante la CLI o . Esta sección proporciona información sobre cómo administrarlo con la CLI.

El encendido del host está activado en el nivel del host (es decir, en cada uno de ellos ).

Después de habilitar el encendido del host, puede activar los hosts mediante la CLI o .

Para habilitar el encendido del host mediante la CLI

Ejecute el comando:

< host uuid >xe host set-poweron-mode host =\
poweron-mode = ("“,” wake-on-lan ",
“iLO”, “DRAC”, “personalizado”)
power-on-config = clave: valor


Para iLO y DRAC las claves son `power_on_ip` {#prmnmN7008A}, `power_on_user` {#prmnmN70090}, `power_on_password_secret` {#prmnmN70096}. Utilice `power_on_password_secret` {#prmnmN7009C} para especificar la contraseña si está utilizando la función secreta.

Para activar hosts de forma remota mediante la CLI

Ejecute el comando:

< host uuid >xe host power-on =

Configurar una secuencia de comandos personalizada para la función de encendido del host

Si la solución de alimentación remota de su servidor utiliza un protocolo que no es compatible de forma predeterminada (como Wake-On-Ring o Intel Active Management Technology), puede crear una secuencia de comandos Linux Python personalizada para encender los equipos de forma remota. Sin embargo, también puede crear scripts personalizados para las soluciones de alimentación remota iLO, DRAC y Wake on LAN.

En esta sección se proporciona información acerca de cómo configurar un script personalizado para Host Power On utilizando los pares clave/valor asociados con la llamada a la APIhost.power_on.

Cuando cree un script personalizado, ejecútelo desde la línea de comandos cada vez que desee controlar el encendido de forma remota . Alternativamente, puede especificarlo y utilizar las características de la interfaz de usuario para interactuar con ella.

La API está documentada en el documento, la API de gestión, que está disponible en el sitio web.

Advertencia:

No cambie los scripts proporcionados por defecto en el/etc/xapi.d/plugins/ directorio. Puede incluir nuevos scripts en este directorio, pero nunca debe cambiar los scripts contenidos en ese directorio después de la instalación.

Pares clave/valor {#host .power_on_mode}

Para usar Host Power On, configure lashost.power_on_mode teclashost.power_on_config y. Consulte la siguiente sección para obtener información sobre los valores.

También hay una llamada a la API que le permite establecer estos campos simultáneamente:

void host.set_host_power_on_mode (modo de cadena, < string, string > configuración del diccionario)

host.power_on_mode

• Definición: contiene pares clave/valor para especificar el tipo de solución de alimentación remota (por ejemplo, DRAC de Dell).

• Valores posibles:

  • Una cadena vacía, que representa el control de energía desactivado

  • “iLO”: Permite especificar HP iLO.

  • “DRAC”: permite especificar DRAC de Dell. Para utilizar DRAC, ya debe haber instalado el paquete complementario de Dell.

  • “wake-on-lan”: Permite especificar Wake on LAN.

  • Cualquier otro nombre (utilizado para especificar un script de encendido personalizado). Esta opción se utiliza para especificar un script personalizado para la administración de energía.

• Tipo: cadena

host.power_on_config

• Definición: Contiene pares clave/valor para la configuración del modo. Proporciona información adicional para iLO y DRAC.

• Valores posibles:

  • Si configuró iLO o DRAC como el tipo de solución de alimentación remota, también debe especificar una de las siguientes claves:

    • “power_on_ip”: La dirección IP que especificó configuró para comunicarse con la tarjeta de control de energía. También puede escribir el nombre de dominio para la interfaz de red en la que está configurado iLO o DRAC.

    • “power_on_user”: el nombre de usuario iLO o DRAC asociado al procesador de gestión, que puede haber cambiado desde la configuración predeterminada de fábrica.

    • “power_on_password_secret”: Especifica el uso de la función de secretos para proteger tu contraseña.

  • Para utilizar la función de secretos para almacenar su contraseña, especifique la clave “power_on_password_secret”.

• Tipo: Mapa (cadena, cadena)

Secuencia de comandos de ejemplo

La secuencia de comandos de ejemplo importa la API, se define como una secuencia de comandos personalizada y, a continuación, pasa parámetros específicos al host que desea controlar de forma remota. Debe definir los parámetrossession{#prmnmN8012E},remote_host{#prmnmN80134} ypower_on_config{#prmnmN8013A} en todos los scripts personalizados.

El resultado aparece cuando el script no tiene éxito.

import XenAPI
def custom(session,remote_host,
power_on_config):
result="Power On Not Successful"
for key in power_on_config.keys():
result=result+''
key=''+key+''
value=''+power_on_config[key]
return result
 

Nota:

Después de crear el script, guárdelo en /etc/xapi.d/plugins con una extensión.py.

Comunicarse con hosts y grupos de recursos

utiliza protocolos TLS para cifrar el tráfico de la API de administración. Cualquier comunicación entre los clientes (o dispositivos) API de administración ahora utiliza el protocolo TLS 1.2 de forma predeterminada. Sin embargo, si el cliente de la API de administración o el dispositivo no se comunican mediante TLS 1.2, se pueden utilizar protocolos anteriores para la comunicación.

utiliza los siguientes conjuntos de cifrado:

-TLS_RSA_WITH_AES_128_CBC_SHA256

-TLS_RSA_WITH_AES_256_CBC_SHA

-TLS_RSA_WITH_AES_128_CBC_SHA

-TLS_RSA_WITH_RC4_128_SHA

-TLS_RSA_WITH_RC4_128_MD5

-TLS_RSA_WITH_3DES_EDE_CBC_SHA

también le permite configurar su host o grupo de recursos para permitir la comunicación sólo a través de TLS 1.2. Esta opción permite la comunicación entre clientes (o dispositivos) de API de administración mediante el protocolo TLS 1.2. La opción sólo TLS 1.2 utiliza el conjunto de cifradoTLS_RSA_WITH_AES_128_CBC_SHA256.

Advertencia:

Seleccione la opción sólo TLS 1.2después de asegurarse de que todos los clientes y dispositivos de API de administración que se comunican con el grupo son compatibles con TLS 1.2.