Las máquinas virtuales OpenStack tienen alta disponibilidad
Para tener en cuenta y garantizar la transición fluida de los sistemas de aplicaciones tradicionales a la computación en la nube, aunque la comunidad OpenStack no proporciona una solución completa de alta disponibilidad de máquinas virtuales, también proporciona algunos mecanismos de trabajo con monitoreo externo. Servicios para facilitar que los usuarios puedan implementar una alta disponibilidad de máquinas virtuales por sí mismos. Además, en la versión Liberty, OpenStack implementó y mejoró la interfaz NovaAPI relevante para cooperar mejor con sistemas externos de alta disponibilidad para monitorear los cambios en el estado del servicio Nova y realizar la conmutación por error de las máquinas virtuales. Por ejemplo, el RDO de Red Hat se basa en Pacemaker-remote para lograr una alta disponibilidad de máquinas virtuales, y la comunidad también utiliza Zookeeper para monitorear el servicio nova-compute para lograr una alta disponibilidad de máquinas virtuales.
En OpenStack, la llamada alta disponibilidad de la máquina virtual se refiere a cuando un nodo informático físico encuentra una falla de hardware (como daño en el disco, apagado causado por falla de CPU o memoria, falla de red física, falla de energía, etc.). El nodo se apaga automáticamente y las máquinas virtuales del nodo se reinician en otros nodos informáticos en buen estado del clúster. Si las máquinas virtuales se pueden migrar dinámicamente, esta es la mejor solución de alta disponibilidad. En la solución de alta disponibilidad de máquinas virtuales OpenStack, aunque el software utilizado es diferente, suele basarse en los tres pasos de monitorización, aislamiento y recuperación.
1) El propósito del monitoreo es determinar si el hipervisor tiene fallas y proporcionar una base para las operaciones de aislamiento. La función de monitoreo consta de dos partes, una es detectar fallas del host y la otra es activar tareas de respuesta automática (aislamiento y recuperación) después de una falla del host. Ha habido un debate en la comunidad sobre si las funciones de monitoreo deberían integrarse en Nova: se cree que el monitoreo de los servicios del nodo informático debería integrarse en el proyecto Nova, principalmente porque el servicio Nova ha adquirido, hasta cierto punto, la infraestructura. del cual depende su propio funcionamiento, o el propio Nova puede rastrear los nodos de cálculo activos. Sin embargo, el seguimiento y monitoreo de los nodos informáticos por parte de Nova solo puede detectar fallas del servicio de computación Nova. La falla del servicio de computación Nova no significa que la máquina virtual también falle. Es decir, si el servicio de computación Nova del nodo informático. es normal y la máquina virtual en el nodo es normal. No hay conexión necesaria con la falla de la máquina. También hay sugerencias de la comunidad para integrar funciones de monitoreo en el proyecto Heat, pero esta solución requiere que los usuarios finales de OpenStack usen la plantilla Heat para reiniciar la máquina virtual cuando falla (pero esta debería ser tarea del administrador de la nube, no del usuario). En el entorno actual de alta disponibilidad de OpenStack, Pacemaker combinado con Corosync es la herramienta de monitoreo de alta disponibilidad de servicios más utilizada. Sin embargo, por razones históricas, Corosync admite un número limitado de nodos informáticos y Pacemaker_remote propuesto por Redhat resuelve esta limitación.
2) El aislamiento es una operación clave en un clúster de alta disponibilidad. El llamado "cerebro dividido" del clúster generalmente se debe a operaciones de aislamiento imperfectas. En la alta disponibilidad del servicio Nova del clúster OpenStack, el aislamiento consiste en aislar completamente el nodo informático fallido del clúster y convertirlo en un nodo aislado.
En un entorno de instancias de alta disponibilidad, los nodos informáticos pueden fallar por diversos motivos. Antes de reiniciar la máquina virtual de un nodo informático fallido en otros nodos en buen estado, debe asegurarse de que la máquina virtual no exista. De lo contrario, pueden aparecer dos máquinas virtuales idénticas en un clúster de OpenStack al mismo tiempo. Peor aún, si la máquina virtual se implementa en un almacenamiento compartido, se ejecutarán dos máquinas virtuales idénticas al mismo tiempo. Escribir una copia de datos entre dos máquinas virtuales suele provocar daños en los datos y también puede provocar que aparezcan dos direcciones IP idénticas en la misma red. Por lo tanto, antes de que el software de alta disponibilidad pueda restaurar una máquina virtual fallida, el programa de monitoreo debe aislar el nodo informático fallido; de lo contrario, inevitablemente causará varios daños a la máquina virtual. Pacemaker proporciona capacidades de aislamiento para los nodos del clúster. Si utiliza otras herramientas de clúster, deberá implementar la funcionalidad de aislamiento usted mismo.
3) Después de monitorear la falla del nodo informático y aislar el nodo, se puede restaurar la máquina virtual del usuario. En Nova, la función principal de recuperación de máquinas virtuales es el comando Evacuar proporcionado por Nova. Cuando se llama a Evacuar, la máquina virtual en el nodo informático fallido será evacuada automáticamente y la máquina virtual se restaurará en el nuevo nodo. Para restaurar una máquina virtual, la máquina virtual debe crearse en un almacenamiento compartido. Alternativamente, puede crear una máquina virtual en un volumen proporcionado por Cinder. Sin embargo, el almacenamiento o los volúmenes compartidos no son un requisito previo para una implementación exitosa de la máquina virtual. Si la máquina virtual no se crea mediante las dos soluciones anteriores, la máquina virtual se restaurará en otros nodos, pero se trata de una recuperación con pérdidas (porque la máquina virtual simplemente utiliza la misma imagen básica de la máquina virtual original para recrear la misma). en otros nodos y los datos modificados desde la imagen base en la máquina virtual original no se pueden recuperar).
Actualmente OpenStack no dispone de una solución completa de monitorización, aislamiento y recuperación. Por lo tanto, los usuarios deben implementar ellos mismos el monitoreo de servicios y el aislamiento de nodos, al tiempo que activan operaciones de evacuación en los nodos informáticos fallidos. Si utiliza el administrador de recursos del clúster Pacemaker, deberá implementar un agente de recursos de evacuación en los nodos informáticos para permitir que Pacemaker active operaciones de evacuación en el nodo.
Nova proporciona la API Evacuate para recuperar máquinas virtuales en nodos informáticos fallidos, que es la base para lograr una alta disponibilidad de máquinas virtuales en nodos informáticos. Después de monitorear y aislar una falla en un nodo de computación, se puede desencadenar una operación de evacuación para recuperar las máquinas virtuales en el nodo. En esencia, Evacuate es una extensión de la función Reconstruir, o se basa en las necesidades de la máquina virtual HA, pero la función Reconstruir aún tiene su practicidad. La principal diferencia entre Rebuild y Evacuate es que Rebuild actualizará el disco de imagen de la máquina virtual, es decir, recreará una máquina virtual con la misma ID usando una nueva imagen, por lo que Rebuild no necesita disfrutar de almacenamiento. reinstalar con el mismo hardware otro sistema operativo (como reemplazar un sistema Windows con un sistema Linux) es una verdadera recuperación, incluidos los datos del sistema y del usuario. Además, la migración y la reconstrucción solo admiten máquinas virtuales en los estados activo y detenido, pero no en los estados en pausa, suspendido y apagado.
El proceso operativo específico de Evacuate depende de la configuración de la máquina virtual y de la arquitectura de almacenamiento subyacente. Si la máquina virtual se basa en un almacenamiento "efímero" del sistema de archivos local del nodo de cálculo, cree una operación de evacuación en un nodo diferente con la misma imagen que la máquina virtual original, y las máquinas virtuales nuevas y antiguas tendrán la misma configuración, por ejemplo. el mismo ID de instancia, ID de imagen, volumen adjunto, estilo, IP, etc. Si la máquina virtual está ubicada en un almacenamiento compartido, Evacuate reiniciará la máquina virtual en el otro nodo basándose en los mismos archivos de la máquina virtual, manteniendo la configuración de la máquina virtual sin cambios. Si la máquina virtual se basa en el backend de un volumen, Evacuate reconstruirá la máquina virtual y la iniciará desde el mismo volumen. Por lo tanto, las máquinas virtuales basadas en almacenamiento compartido y backends de volumen se pueden restaurar tal cual, mientras que las máquinas virtuales basadas en almacenamiento temporal local no pueden restaurar datos de usuario (datos ubicados en almacenamiento temporal).
1) Verifique la información de la máquina virtual antes de reconstruir (nova show? vmid). Registre el UUID, la dirección IP, el nombre del host y la instalación del volumen.
2) Realizar la operación de reconstrucción. Aquí, la imagen original cirros-image-name todavía se usa para reconstruir vm-name, y el usuario puede elegir cualquier otra imagen para reconstruir.
¿Estrella en ascenso? ¿reconstrucción? Nombre de la máquina virtual nombre de la imagen cirros
3) Verifique 3) la información de la máquina virtual después de la reconstrucción (¿pantalla nova? vmid). Observe si el nombre del host, el UUID, la dirección IP y el montaje del volumen han cambiado. Normalmente, estos parámetros deberían permanecer sin cambios después de la reconstrucción.
1) Guarde los datos del usuario en el sistema operativo de la máquina virtual antes de la evacuación para su verificación después de la evacuación.
[root@nfs-server ~]#? echo "Estos datos deben restaurarse después de la evacuación" >;? /root/test.txt
2) Verifique la información de la máquina virtual antes de la evacuación (nova show? vmid). Verifique el host de la máquina virtual y confirme el host de destino de la operación de evacuación. La evacuación requiere el uso de almacenamiento compartido o máquinas virtuales basadas en volúmenes, donde el servidor nfs es una máquina virtual basada en NFS. ¿Estrella en ascenso? Hipervisor - Computación del servidor 2
3) Cuando el nodo informático esté funcionando normalmente, realice la operación de evacuación. La operación de evacuación requiere que el servicio informático del host donde se encuentra la máquina virtual no pueda estar activo, de lo contrario no se permite su ejecución. //El nodo compute1 se ejecuta normalmente y no se permite la evacuación.
[root@controller1~]#nova evacuate nfs _ server compute2
¿Error? (BadRequest): ¿Calcular? ¿Atender? ¿de? calcular1? ¿Sí? ¿aún? ¿existir? usar. ? (HTTP? 400)
4) Realizar operaciones de evacuación cuando falla el nodo informático. Compute1 se utiliza para simular una falla de apagado y observar los cambios en el estado de la máquina virtual durante el proceso de evacuación.
//Apagar el nodo de la computadora 1
[root@compute1~]#Apagar
//Ejecutar evacuar, el nodo de destino es Compute2.
[root@controller1~]# nova evacuate nfs _ server compute2
5) Verifique los cambios en la máquina virtual después de la evacuación (nova show vmid). El host donde se encuentra la máquina virtual debe pasar de Compute1 a Compute2.
6) Verificar si los datos del usuario están disponibles después de la evacuación. Hay dos formas de verificar esto: cambiar la contraseña de raíz de la máquina virtual antes de la evacuación y ahora verificar si la contraseña de raíz todavía está disponible antes de la evacuación, los datos del usuario se almacenan en /root/test.txt; Ahora compruebe si los datos todavía existen.
[root@nfs-server ~]#? más /root/test.txt
Estos datos deben restaurarse después de la evacuación
7) Inicie el nodo Compute1 y verifique si la máquina virtual en el nodo Compute1 se recuperará automáticamente. En circunstancias normales, la máquina virtual que realiza la operación de evacuación no se restaurará en el nodo informático original. Durante el proceso de restauración del nodo informático original, la información relevante de la máquina virtual se borrará automáticamente.
La nube pública se basa en la alta disponibilidad de la aplicación en sí y tolera el tiempo de inactividad de las máquinas físicas hasta cierto punto, mientras que la nube privada se basa en la alta disponibilidad de los servidores. Para tener en cuenta y garantizar una transición fluida de los sistemas de aplicaciones tradicionales a la computación en la nube, se proporcionan algunos mecanismos de trabajo con servicios de monitoreo externos para que los usuarios puedan lograr una alta disponibilidad de sus propias máquinas virtuales. La alta disponibilidad de las máquinas virtuales generalmente se implementa en tres pasos: monitoreo, aislamiento y recuperación. El seguimiento y monitoreo de los nodos informáticos por parte de Nova se aísla mediante la detección de fallas en el servicio de computación de Nova. Pacemaker proporciona la función de aislamiento de los nodos del clúster, lo que requiere la implementación de un agente de recursos de evacuación en el nodo informático, lo que permite a Pacemaker activar operaciones de recuperación de evacuación en el nodo. Pacemaker y Corosync son las herramientas de monitoreo de servicios de alta disponibilidad más utilizadas, pero Corosync admite una cantidad limitada de nodos informáticos. Además, Pacemaker_remote propuesto por Redhat soluciona esta limitación. Para saber cómo resolver este problema, analícelo la próxima vez.