Hacer frente a los fallos de las
En esta sección se proporcionan detalles sobre cómo recuperarse de varios casos de error. Todos los casos de recuperación de errores requieren el uso de uno o más de los tipos de copia de seguridad enumerados en Copia de seguridad.
Fallas de miembros
En ausencia de HA, los nodos maestros detectan los fallos de los miembros al recibir mensajes de latidos regulares. Si no se ha recibido ningún latido durante 600 segundos, el maestro asume que el miembro está muerto. Hay dos maneras de recuperarse de este problema:
-
Repare el host muerto (por ejemplo, reiniciándolo físicamente). Cuando se restablece la conexión con el miembro, el maestro vuelve a marcar el miembro como activo.
-
Apague el host e indique al maestro que se olvide del nodo miembro mediante el comando
xe host-forgetde la CLI. Una vez que se ha olvidado el miembro, todas las máquinas virtuales que se estaban ejecutando allí se marcan como sin conexión y se pueden reiniciar en otros servidores de Citrix Hypervisor.Es importante asegurarse de que el servidor de Citrix Hypervisor esté realmente fuera de línea, de lo contrario, podrían producirse daños en los datos de la VM.
No divida su grupo en varios grupos de un solo host mediante el uso de
xe host-forget. Esta acción puede provocar que todos asignen el mismo almacenamiento compartido y corrompan los datos de la VM.
Advertencia:
- Si va a volver a utilizar el host olvidado como host activo, realice una nueva instalación del software Citrix Hypervisor.
- No utilice el comando
xe host-forgetsi HA está habilitada en el grupo. Inhabilite primero HA, luego olvide el host y, a continuación, vuelva a habilitar HA.
Cuando un servidor de Citrix Hypervisor miembro falla, es posible que todavía haya máquinas virtuales registradas en estado de ejecución. Si está seguro de que el servidor miembro de Citrix Hypervisor está definitivamente inactivo, utilice el comandoxe vm-reset-powerstate CLI para establecer el estado de energía de las máquinas virtuales en halted. Consulte vm-reset-powerstate para obtener más información.
Advertencia:
El uso incorrecto de este comando puede provocar daños en los datos. Utilice este comando solo si es necesario.
Antes de poder iniciar las máquinas virtuales en otro servidor de Citrix Hypervisor, también debe liberar los bloqueos del almacenamiento de máquinas virtuales. Solo en un host a la vez puede usar cada disco en una SR. Es clave hacer que el disco sea accesible para otros servidores de Citrix Hypervisor una vez que un host haya fallado. Para hacerlo, ejecute el siguiente script en el maestro de grupo para cada SR que contenga discos de cualquier máquina virtual afectada: /opt/xensource/sm/resetvdis.py host_UUID SR_UUID master
Solo necesita proporcionar la tercera cadena (“master”) si el host que falló era el maestro de SR en el momento del bloqueo. (El maestro de SR es el maestro de grupo o un servidor de Citrix Hypervisor que utiliza almacenamiento local).
Advertencia:
Asegúrese de que el host esté inactivo antes de ejecutar este comando. El uso incorrecto de este comando puede provocar daños en los datos.
Si intenta iniciar una VM en otro servidor de Citrix Hypervisor antes de ejecutar el script resetvdis.py, recibirá el siguiente mensaje de error: VDI <UUID> already attached RW.
Fallas maestras
Cada miembro de una agrupación de recursos contiene toda la información necesaria para asumir el rol de maestro si es necesario. Cuando se produce un error en un nodo maestro, se produce la siguiente secuencia de eventos:
-
Si la HA está habilitada, se elige automáticamente otro maestro.
-
Si la HA no está habilitada, cada miembro espera a que el maestro regrese.
Si el maestro vuelve a subir en este punto, restablece la comunicación con sus miembros y el funcionamiento vuelve a la normalidad.
Si el maestro está muerto, elija uno de los miembros y ejecute el comando xe pool-emergency-transition-to-master en él. Una vez que se haya convertido en el maestro, ejecute el comando xe pool-recover-slaves y los miembros ahora apuntan al nuevo maestro.
Si repara o reemplaza el servidor que era el maestro original, simplemente puede abrirlo, instalar el software Citrix Hypervisor y agregarlo al grupo. Dado que los servidores de Citrix Hypervisor del grupo se obligan a ser homogéneos, no hay necesidad real de convertir el servidor reemplazado en el maestro.
Cuando un servidor de Citrix Hypervisor miembro pasa a ser maestro, compruebe que el repositorio de almacenamiento del grupo predeterminado esté establecido en un valor adecuado. Esta comprobación se puede realizar mediante el comando xe pool-param-list y verificando que el parámetro default-SR apunta a un repositorio de almacenamiento válido.
Fallos de agrupación
En el desafortunado caso de que falle toda la agrupación de recursos, debe volver a crear la base de datos del grupo desde cero. Asegúrese de realizar copias de seguridad periódicas de los metadatos de su grupo mediante el comando xe pool-dump-database CLI (consulte pool-dump-database).
Para restaurar un grupo que ha fallado por completo:
-
Instale un conjunto nuevo de hosts. No los juntes en esta etapa.
-
Para el host designado como maestro, restaure la base de datos del grupo desde la copia de seguridad mediante el comando
xe pool-restore-database(consulte pool-restore-database). -
Conéctese al host maestro mediante XenCenter y asegúrese de que todo el almacenamiento compartido y las máquinas virtuales estén disponibles nuevamente.
-
Realice una operación de unión a un grupo en los hosts miembros recién instalados restantes e inicie las máquinas virtuales en los hosts apropiados.
Hacer frente a la falla debido a errores de configuración
Si la máquina host física está operativa pero la configuración del software o del host está dañada:
-
Ejecute el siguiente comando para restaurar el software y la configuración del host:
xe host-restore host=host file-name=hostbackup <!--NeedCopy--> -
Reinicie en el CD de instalación del host y seleccione Restaurar desde la copia de seguridad.
Fallo de máquina física
Si la máquina host física ha fallado, utilice el procedimiento apropiado de la siguiente lista para recuperarse.
Advertencia:
Las máquinas virtuales que se ejecuten en un miembro anterior (o en el host anterior) que hayan fallado seguirán marcadas como
Runningen la base de datos. Este comportamiento es por seguridad. Iniciar simultáneamente una VM en dos hosts diferentes provocaría una corrupción grave del disco. Si está seguro de que las máquinas (y las máquinas virtuales) están fuera de línea, puede restablecer el estado de energía de la máquina virtual aHalted:
xe vm-reset-powerstate vm=vm_uuid --forceLas máquinas virtuales se pueden reiniciar mediante XenCenter o la CLI.
Para reemplazar un maestro fallido por un miembro aún en ejecución:
-
Ejecute los comandos siguientes:
xe pool-emergency-transition-to-master xe pool-recover-slaves <!--NeedCopy--> -
Si los comandos se ejecutan correctamente, reinicie las VM.
Para restaurar un grupo con todos los hosts fallidos:
-
Ejecute el comando:
xe pool-restore-database file-name=backup <!--NeedCopy-->Advertencia:
Este comando solo se ejecuta correctamente si el equipo de destino tiene un número adecuado de NIC con el nombre adecuado.
-
Si la máquina de destino tiene una vista del almacenamiento diferente a la de la máquina original, modifique la configuración de almacenamiento mediante el comando
pbd-destroy. A continuación, ejecute el comandopbd-createpara volver a crear configuraciones de almacenamiento. Consulte comandos pbd para obtener documentación de estos comandos. -
Si ha creado una configuración de almacenamiento, utilice
pbd-plugo el elemento de menú Almacenamiento > Reparar repositorio de almacenamiento en XenCenter para usar la nueva configuración. -
Reinicie todas las VM.
Para restaurar una VM cuando el almacenamiento de VM no esté disponible:
-
Ejecute este comando:
xe vm-import filename=backup metadata=true <!--NeedCopy--> -
Si la importación de metadatos falla, ejecute el comando:
xe vm-import filename=backup metadata=true --force <!--NeedCopy-->Este comando intenta restaurar los metadatos de la máquina virtual según el “mejor esfuerzo”.
-
Reinicie todas las VM.