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.

Introducción a los servidores y grupos de recursos HASH (0x2e68218)

Un grupo de recursos consta de varias instalaciones de servidor HASH (0x2e68218), enlazadas a una única entidad administrada que puede alojar máquinas virtuales. Si se combina con almacenamiento compartido, un grupo de recursos permite que las VM se inicien en cualquier servidor HASH (0x2e68218) que tenga suficiente memoria. Las máquinas virtuales se pueden mover dinámicamente entre servidores HASH (0x2e68218) mientras se ejecutan con un tiempo de inactividad mínimo (migración en vivo). Si un servidor HASH individual (0x2e68218) sufre un error de hardware, el administrador puede reiniciar las máquinas virtuales con errores en otro servidor HASH (0x2e68218) en el 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 HASH (0x2e6c8e8) y la interfaz de línea de comandos HASH (0x2c1a078), 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 servidores HASH (0x2e68218), 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 está ejecutando la misma versión del software HASH (0x2c1a078), 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, HASH (0x2c1a078) 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.

Los servidores HASH (0x2e68218) de los grupos de recursos pueden contener diferentes números de interfaces de red físicas y tener repositorios de almacenamiento locales de tamaño variable. 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 compartidos para seleccionar en qué servidor HASH (0x2e68218) ejecutar una máquina virtual y mover una máquina virtual entre servidores HASH (0x2e68218) dinámicamente. Si es posible, cree un grupo después de que esté disponible el almacenamiento compartido. Se recomienda mover máquinas virtuales existentes con discos ubicados en almacenamiento local al almacenamiento compartido después de agregar almacenamiento compartido. Puede usar elxe vm-copy comando o usar HASH (0x2e6c8e8) para mover máquinas virtuales.

Crear un fondo de recursos

Los grupos de recursos se pueden crear utilizando HASH (0x2e6c8e8) 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 HASH (0x2e6c8e8) o la CLI, y los PBD deben reconectarse 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. ConsulteAdministrar 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 servidores HASH (0x2e68218) host1 y host2 en un fondo de recursos mediante la CLI

  1. Abra una consola en el host del servidor HASH (0x2e68218) 2.

  2. Comando HASH (0x2e68218) servidor host2 para unirse al grupo en HASH (0x2e68218) servidor 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 del servidor HASH (0x2e68218) 1 . password Debe ser la contraseña de administrador establecida cuando se instaló el host 1 del servidor HASH (0x2e68218).

Los servidores HASH (0x2e68218) 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="New Pool" uuid=pool_uuid

Crear grupos de recursos heterogéneos

HASH (0x2c1a078) 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:

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

HASH (0x2c1a078) 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. Al mover o migrar una máquina virtual a un host diferente dentro o entre grupos, HASH (0x2c1a078) 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, consulteFormatos 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 servidor HASH (0x2e68218) del grupo.

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

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

    device-config:server Es el nombre de host del servidor NFS ydevice-config:serverpath es la ruta de acceso del servidor NFS. Comoshared se establece en true, el almacenamiento compartido se conecta automáticamente a todos los servidores HASH (0x2e68218) del grupo. Todos los servidores HASH (0x2e68218) que se unen 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 piscina 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 piscina, todas las máquinas virtuales futuras tienen sus discos creados en almacenamiento compartido de forma predeterminada. ConsulteFormatos de repositorio de almacenamientopara obtener información sobre la creación de otros tipos de almacenamiento compartido.

Quitar servidores HASH (0x2e68218) de un fondo de recursos

Nota:

Antes de quitar cualquier servidor HASH (0x2e68218) 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 servidores HASH (0x2e68218) 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 host-list
    
  3. Expulse el host requerido del grupo:

    xe pool-eject host-uuid=host_uuid
    

    El servidor HASH (0x2e68218) 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 HASH (0x2e6c8e8) o el comandoxe vm-copy CLI.

Cuando los servidores HASH (0x2e68218) 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 servidores HASH (0x2e68218). Las máquinas virtuales no se inician hasta que se hayan cambiado los discos virtuales asociados a ellas para que apunten al almacenamiento compartido visto por otros servidores HASH (0x2e68218) en el 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 servidores HASH individuales (0x2e68218) sean expulsados (o físicamente fallen) 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 servidores HASH (0x2e68218) para 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 servidor HASH (0x2e68218) en el grupo. Puede hacer esto colocando el servidor HASH (0x2e68218) en el modo de mantenimiento usando HASH (0x2e6c8e8). Consulte la Ayuda de HASH (0x2e6c8e8) para obtener más detalles.

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:

Recomendamos reiniciar todos los servidores HASH (0x2e68218) 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 HASH (0x2e68218), por lo que el reinicio puede descubrir problemas de configuración que pueden hacer que la actualización falle.

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

  1. Ejecute el siguiente comando:

    xe host-disable uuid=HASH(0x2e68218)_host_uuid
    xe host-evacuate uuid=HASH(0x2e68218)_host_uuid
    

    Este comando deshabilita el servidor HASH (0x2e68218) y, a continuación, migre las máquinas virtuales en ejecución a otros servidores HASH (0x2e68218) del grupo.

  2. Realice la operación de mantenimiento deseada.

  3. Habilite el servidor HASH (0x2e68218) cuando se complete la operación de mantenimiento:

    xe host-enable
    
  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.

Nota:

Exportar datos del fondo de recursos está disponible para los clientes HASH (0x2c1a078) HASH (0x2e72eb8) o aquellos que tienen acceso a HASH (0x2c1a078) a través de sus derechos de Citrix Virtual Apps and Desktops.

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

Servidor:

  • Nombre
  • Maestro de grupo
  • 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 servidor HASH (0x2e68218).

Para exportar datos de recursos

  1. En el panel de exploración HASH (0x2e6c8e8), 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 característica Encendido del servidor HASH (0x2e68218) para activar y desactivar un servidor de forma remota, ya sea desde HASH (0x2e6c8e8) o mediante 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 utilizar HASH (0x2c1a078) con DRAC, debe instalar el paquete complementario de Dell para obtener compatibilidad con 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 HASH (0x2c1a078) 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 encender y apagar el encendido a través de HASH (0x2c1a078). 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 HASH (0x2e6c8e8).

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

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

El encendido del host está habilitado en el nivel de host (es decir, en cada HASH (0x2c1a078)).

Después de habilitar el encendido del host, puede activar los hosts mediante la CLI o HASH (0x2e6c8e8).

Para habilitar el encendido del host mediante la CLI

Ejecute el comando:

xe host-set-power-on-mode host=<host uuid> \
    power-on-mode=("" , "wake-on-lan",  "iLO", "DRAC","custom") \
    power-on-config=key:value

Para iLO y DRAC las claves sonpower_on_ip{#prmnmN7008A},power_on_user{#prmnmN70090},power_on_password_secret{#prmnmN70096}. Usepower_on_password_secret{#prmnmN7009C} para especificar la contraseña si está utilizando la función secreta. Para obtener más información, consulte Secretos.

Para activar hosts de forma remota mediante la CLI

Ejecute el comando:

xe host-power-on host=<host uuid>

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 activar los equipos HASH (0x2c1a078) de forma remota. Sin embargo, también puede crear scripts personalizados para las soluciones de alimentación remota iLO, DRAC y Wake on LAN.

Esta sección proporciona información acerca de la configuración de una secuencia de comandos personalizada para Host Power On utilizando los pares clave/valor asociados con la llamada a API HASH (0x2c1a078)host.power_on.

Cuando cree un script personalizado, ejecútelo desde la línea de comandos cada vez que desee controlar la energía de forma remota en HASH (0x2c1a078). Alternativamente, puede especificarlo en HASH (0x2e6c8e8) y usar las características de interfaz de usuario HASH (0x2e6c8e8) para interactuar con él.

La API HASH (0x2c1a078) está documentada en el documento, la API de administración HASH (0x2c1a078), que está disponible en eldocumentación del desarrolladorsitio 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(string mode, Dictionary<string,string> config)
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”. Para obtener más información, consulte Secretos.

  • Tipo: Mapa (cadena, cadena)

Secuencia de comandos de ejemplo

La secuencia de comandos de ejemplo importa la API HASH (0x2c1a078), 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 servidores HASH (0x2e68218) y grupos de recursos

HASH (0x2c1a078) utiliza protocolos TLS para cifrar el tráfico de la API de administración. Cualquier comunicación entre HASH (0x2c1a078) y clientes de API de administración (o dispositivos) 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.

HASH (0x2c1a078) 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

HASH (0x2c1a078) 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 HASH (0x2c1a078) y clientes de API de administración (o dispositivos) 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 HASH (0x2e68218) son compatibles con TLS 1.2.

Habilitar la indagación IGMP en su grupo HASH (0x2e68218)

HASH (0x2e68218) envía tráfico de multidifusión a todas las máquinas virtuales invitadas, lo que provoca una carga innecesaria en los dispositivos host, al exigirles que procesen los paquetes que no han solicitado. La activación de la indagación IGMP impide que los hosts de una red local reciban tráfico para un grupo de multidifusión al que no se hayan unido explícitamente, y mejora el rendimiento de la multidifusión. La indagación IGMP es especialmente útil para aplicaciones de multidifusión IP con uso intensivo de ancho de banda, como IPTV.

Puede habilitar la indagación IGMP en un grupo usando HASH (0x2e6c8e8) o la interfaz de línea de comandos. Para habilitar la indagación IGMP mediante HASH (0x2e6c8e8), vaya a Propiedades del grupo y seleccione Opciones de red . Para obtener más información, consulte la Ayuda de HASH (0x2e6c8e8). Para obtener los comandos xe, consultepiscina-igmp-snooping.

Notas:

  • La indagación IGMP sólo está disponible cuando el back-end de red utiliza Open vSwitch.

  • Al habilitar esta característica en un grupo, también puede ser necesario habilitar el consulta IGMP en uno de los conmutadores físicos. O bien, la multidifusión en la subred retrocederá a la difusión y puede disminuir el rendimiento de HASH (0x2e68218).

  • Al habilitar esta característica en un grupo que ejecuta IGMP v3, la migración de VM o la conmutación por error de vínculo de red da lugar a que la versión IGMP cambie a v2.

  • Para habilitar esta característica con la red GRE, los usuarios deben configurar una consulta IGMP en la red GRE. Alternativamente, puede reenviar el mensaje de consulta IGMP desde la red física a la red GRE. O bien, el tráfico de multidifusión en la red GRE se puede bloquear.