Situación horrible: sistemas de archivos montados simultáneamente por varias instancias de SO independientes

¿Cómo salgo de esta situación de manera segura?

Los detalles son los siguientes:

Un servidor xen tiene dispositivos de bloque asignados a máquinas virtuales. Pero estos dispositivos también se han montado dentro de Xen.

De hecho, 44 de estos dispositivos de bloque se han montado de esta manera. Para empeorar las cosas, cada dispositivo físico se ve en 4 rutas y cada una de ellas está montada en un punto de montaje separado. En otras palabras, los dispositivos se montan 5 veces cada uno.

El sistema operativo invitado VM ve la ruta a través de un pseudo dispositivo PowerPath (asignado como un dispositivo phy: block a domU)

Algunos de los dispositivos están formateados como ext2 y reiserfs.

No es necesario que me explique los riesgos de corrupción del sistema de archivos involucrados aquí.

Me temo que incluso solo desmontar los sistemas de archivos puede causar corrupción, y creo que en este momento extraer la alimentación del host es la opción más segura .

Tenga en cuenta que las aplicaciones, bases de datos Oracle en su mayor parte, en todas las máquinas virtuales todavía se están ejecutando y en uso.

Descubrí esto al investigar el uso elevado de la CPU en dom0. Hay un proceso de "búsqueda" que no se puede matar, con cwd -> / media / disk-12 que se monta desde / dev / sdf1, que pertenece a / dev / emcpowerr

Antes de que alguien pregunte, la única vez que he visto que los procesos no se pueden eliminar y continúo usando CPU y RAM (a diferencia de un proceso difunto / zombie), es cuando hay E / S comprometidas pendientes, por ejemplo, la sincronización devuelta pero aún no físicamente en el disco . Más comúnmente esto ocurre en la E / S de cinta.

Sugerencias?

PD: ¿Esperaba que los dispositivos estuvieran "reservados" una vez montados, para evitar este tipo de cosas? ¿O eso no es posible en Linux?

EDITAR: en primer lugar, estoy convencido de que KDE dentro del hipervisor) es el culpable. Parece que KDE está montando los dispositivos que puede al iniciar sesión para crear iconos de escritorio. Sin embargo, no ocurre lo mismo en otros servidores Xen, pero todos los demás servidores están ejecutando una versión mucho más antigua de SLES y KDE ... V4 parece ser el infractor, con 3.4 comportándose mejor).

Además, dos máquinas virtuales no críticas se han bloqueado. Después de apagarlos, no se iniciarían nuevamente debido a la corrupción del sistema de archivos. La máquina virtual principal / de producción todavía se está ejecutando y la base de datos en ella todavía funciona, pero claramente esta es una bomba de tiempo. El cliente está intentando reconstruir el entorno en otra máquina virtual en otro servidor, pero tiene problemas para configurar algunos de los componentes, por lo que estamos esperando ...

En cualquier caso, siento que ninguna de las respuestas ha sido más que "las mejores prácticas siempre se cierran con gracia". Y espero obtener algo más concreto ... En cualquier caso, creo que esta situación puede justificar un poco más de cuidado. pensando. ¿El cierre provocará una sincronización de E / S sobresaliente, en particular las actualizaciones de metadatos del sistema de archivos desde el hipervisor, y provocará una posible corrupción importante del sistema de archivos?

— Johan
fuente

Y en este momento, cualquier copia de seguridad realizada antes de "cerrar" puede simplemente respaldar datos dañados, aunque en esta situación es más probable que los metadatos del sistema de archivos estén dañados, en lugar de los contenidos del archivo.

— Johan

Me temo que perderá al menos algunos de los datos en cualquier caso. Apagar el host físicamente o terminar las máquinas virtuales con fuerza podría tener la consecuencia no deseada de estropear todo (es decir, incluso aquellos sistemas de archivos que solo se montan una vez). Probablemente trataría de terminar todo lo más limpio posible para minimizar las pérdidas. Y, por supuesto, asegurarse de que no vuelva a suceder.

— Peter

En cuanto a prevenirlo, IIUC puede intentar establecer permisos en el dispositivo en dom0 una vez que lo abre el invitado, pero dado que los permisos fs (en los archivos del dispositivo) pueden ser cruzados por la raíz (a menos que tenga un kernel parcheado) podría No necesito ayuda.

— Peter

Con respecto a su script de publicación: si los dispositivos son visibles a través de múltiples rutas, entonces el núcleo probablemente ni siquiera sabe que son todos el mismo dispositivo, entonces, ¿cómo podría "reservarlo"? En cuanto a la exportación de un dispositivo de dom0 a múltiples domU, le permite hacerlo porque es posible que desee hacerlo a propósito (por ejemplo, con un sistema de archivos que lo admita o montado solo en todas partes).

— Celada

@Celada Pensé en eso, pero hay formas de "bloquear" dispositivos: PowerPath debería (en el caso de Solaris) reservar todas las rutas principales de un dispositivo (en el momento en que se inicializa). Además, los comandos de "reserva" SCSI son administrados por el dispositivo de destino, por lo que una vez que se reserva un objetivo, debe negarse a permitir una reserva en cualquiera de las rutas para ese dispositivo. Al menos esa es mi comprensión limitada.

— Johan

Respuestas:

Si los discos se escriben desde un único punto de montaje, no se está haciendo daño. Realice un apagado limpio (si lo desea, haga una copia de seguridad del estado suspendido) repare las monturas. No ejecute nada excepto las aplicaciones necesarias en el Dom0. Si, OTOH, las particiones se escriben desde múltiples rutas, eso es MALO y empeora cada segundo. Tirar del enchufe.

— Forma de vida alienígena
fuente

No tengo ninguna razón concreta, pero mi instinto me dice que lo siguiente puede ser el mejor enfoque:

Cerrar aplicaciones
Copie todos los datos de la VM a través de la red a una ubicación de respaldo.
Desmontar los sistemas de archivos desde la VM.
Apaga la VM. (Solo hay una VM en ejecución en este host ahora).
Asegúrese de que no haya domUs configurados para iniciarse automáticamente.
Desconecte la alimentación del host para evitar que el hipervisor realice acciones de "cierre", sincronización de E / S pendientes, etc.
Arranque la máquina virtual, con la esperanza de que el hipervisor en sí sobrevivió al power-yank.
Si falla, reconstruya el entorno. (Los discos de arranque de las máquinas virtuales están basados en archivos, pero los puntos de montaje de datos residen en un disco externo asignado como dispositivos de bloque)
Compruebe si el hipervisor está montando algún sistema de archivos que pertenezca a domUs. Desmontar estos antes de que se inicie cualquier domU)
Desactive el montaje automático de KDE.
Inicie la VM y fuerce una comprobación completa de FS.

Alternativa a 11: inicie la VM y monte los sistemas de archivos sin un fsck completo.

El razonamiento es que no quiero que el hipervisor Xen tenga más posibilidades que las absolutamente necesarias para causar corrupción en los sistemas de archivos domU.

— Johan
fuente

No soy un experto en Xen y todavía no tengo experiencia con él. Pero mi enfoque si estuviera en su lugar sería: primero sé que podría perder datos (tal vez incluso todos); segundo, trataría de crear instantáneas y luego suspender las máquinas virtuales, restableciéndolas en un entorno seguro diferente.
No quiero darte falsas esperanzas, pero creo que tendrás suerte si puedes recuperar algo.

Advertencia : seguir estos consejos puede hacer que pierda todos los datos. Esto depende de usted para ver si vale la pena el riesgo o no.

Con mucha suerte, sus aplicaciones siguen funcionando porque los datos que están utilizando están en memoria volátil. Debería intentar aprovechar esta situación (intente evaluar si ese podría ser el caso por aplicaciones) y exportar los datos en vivo a un recurso compartido de red si las aplicaciones ofrecen dicha función. Si hay datos en el disco, esta función de exportación podría "bloquearse" de forma muy similar a su finddeclaración o bloquearse (y bloquear la aplicación o el sistema operativo) debido a los datos del disco modificados / dañados.

Entonces podría intentar hacer una instantánea en vivo, las instrucciones en el siguiente artículo: Crear instantáneas en Xen . Iría por la instantánea byte por byte, aunque podría atascarse como tu findcomando ... Sin embargo, no daría tanta esperanza.

Antes de ejecutar el comando anterior, debe leer este documento de Citrix, que ayuda a comprender las instantáneas en Xen (PDF) .

Les deseo buena suerte.

— Huygens
fuente

Gracias. El cliente tiene una exportación de la base de datos. Creo que simplemente usaron FTP para sacarlo de la VM, pero es posible montar un recurso compartido de red y exportar directamente a eso.

— Johan

He estado jugando con la idea de suspender la VM y luego llevar una copia completa a otro host y luego intentar a) Reanudarlo desde el modo de suspensión, o b) arrancarlo, seguido de un reinicio y fsck. La idea es que, dado que todavía tengo la VM suspendida en el host original, puedo reanudarla si la copia no funciona en el otro host.

— Johan

Además, el problema con volver a una copia de seguridad es que se teme que todas las copias de seguridad realizadas durante los últimos meses estén corruptas.

— Johan

@Johan, esto es más que probablemente cierto, la mayoría, si no todas, las copias de seguridad (ya que ocurrió el problema) probablemente estén dañadas. Lo mismo podría ser cierto para la exportación de la base de datos. ¡Buena suerte otra vez, la necesitarás!

— Huygens