Los sistemas de archivos raíz Xen DomU se vuelven de solo lectura en la conmutación por error de IP virtual iSCSI

9

Mis servidores Xen son openSUSE 11.1 con open-iscsi en nuestro clúster SAN iSCSI. Los módulos SAN están en un grupo de conmutación por error de IP detrás de una IP virtual a la que se conectan los iniciadores.

En el caso de que el servidor SAN primario se caiga, el secundario toma la función de servir como objetivo. Todo esto lo maneja el software LeftHand SAN / iQ y funciona bien en la mayoría de las situaciones.

El problema que tengo es que, ocasionalmente, algunas de mis Xen DomU tendrán su sistema de archivos raíz de solo lectura después de una conmutación por error de IP. No es coherente y le sucede a un subconjunto diferente cada vez que se produce una conmutación por error. Todos ejecutan la misma imagen de software openSUSE 11.1.

Los sistemas de archivos raíz para cada DomU están montados por open-iscsi en Dom0 y luego Xen usa el controlador de dispositivo de bloque estándar para exponerlo a DomU.

El síntoma exacto es que, como root como en ejecución, touch /testdevuelve el error "sistema de archivos de solo lectura". Sin embargo, la salida de mountmuestra que está montado como lectura-escritura. Por supuesto, todas las demás E / S en domU también están fallando en este momento, por lo que la máquina se cae con fuerza. Simplemente reiniciarlo xmdesde Dom0 sin siquiera volver a conectar la sesión iSCSI hace que todo vuelva a funcionar.

En el lado Dom0, los mensajes de syslog durante la conmutación por error son similares a los siguientes:

kernel: connection1:0: iscsi: detected conn error (1011)
iscsid: Kernel reported iSCSI connection 1:0 error (1011) state (3)
iscsid: connection1:0 is operational after recovery (1 attempts)

Me está costando entender en qué capa depurar este problema, ¿hay algo en el núcleo de DomU? o en el nivel Dom0 o Xen? Creo que es probable que haya algún parámetro en algún lugar que necesite ajustes para aumentar algún tipo de tiempo de espera, pero no estoy seguro de dónde buscar.

Realmente no creo que sea un problema con open-iscsi simplemente porque el dispositivo de bloque conectado aún se puede leer y escribir desde Dom0.

linux xen iscsi

— Kamil Kisiel
fuente

6

Finalmente resolví esto usando los siguientes consejos y configuraciones de la documentación de open-iscsi:

8.2 iSCSI settings for iSCSI root
---------------------------------

When accessing the root parition directly through a iSCSI disk, the
iSCSI timers should be set so that iSCSI layer has several chances to try to
re-establish a session and so that commands are not quickly requeued to
the SCSI layer. Basically you want the opposite of when using dm-multipath.

For this setup, you can turn off iSCSI pings by setting:

node.conn[0].timeo.noop_out_interval = 0
node.conn[0].timeo.noop_out_timeout = 0

And you can turn the replacement_timer to a very long value:

node.session.timeo.replacement_timeout = 86400

Después de configurar la conexión a cada LUN como se describió anteriormente, la conmutación por error funciona de maravilla, incluso si lleva varios minutos.

— Kamil Kisiel
fuente

1

Tuve el mismo problema con mysql prod db sentado en el volumen iscsi, con los mismos errores en / var / log / messages y el sistema de archivos en modo de solo lectura. Este consejo resolvió el problema.

— RainDoctor

2

Esto suena como un problema con el iniciador iSCSI ejecutándose en dom0. El iniciador no debería enviar fallas SCSI a la pila tan rápido. Probablemente desee configurar ConnFailTimeout en iscsi.conf, esta es la configuración que determina cuánto tiempo antes de considerar un error de conexión un error y lo envía a la pila SCSI.

También analizaría cuánto tiempo lleva realmente esa conmutación por error, puede tardar más de lo esperado. Si es así, tal vez la conmutación por error VIP tarde demasiado debido a problemas relacionados con ARP.

— Scott Dodson
fuente

Creo que esto es exactamente lo que necesito.

— Kamil Kisiel

0

¿Hay algún mensaje en dom0 que indique algún tipo de error de lectura / escritura o error scsi en el momento de la conmutación por error? Si es así, parece que este error de escritura se pasa a domU. DomU no "sabe" que es un dispositivo iSCSI, por lo que se comporta como si el disco subyacente se hubiera ido y vuelva a montar el sistema de archivos de solo lectura (consulte la página de manual de mount (1) - errors=continue / errors=remount-ro / errors=panic)

Desde la perspectiva de dom0, no se cambiará a solo lectura: este comportamiento de solo lectura es un sistema de archivos semántico, no un dispositivo de bloque semántico.

Usted menciona que "todas las demás E / S están fallando" en este momento, ¿se refiere a domU o dom0?

Por lo general, cuando configuro una solución iSCSI de HA, utilizo múltiples rutas en lugar de una toma de posesión de IP virtual: permite una mayor visibilidad para el host y no tiene una sesión iSCSI que desaparece repentinamente y luego necesita reiniciarse; siempre está ahí, solo hay dos . ¿Es esta una opción en este entorno?

— MikeyB
fuente

Se actualizó la descripción original con respuestas a sus preguntas. Supongo que podría buscar rutas múltiples, pero el sistema está más orientado a la conmutación por error de IP virtual en su forma actual. No estoy seguro de cómo entraría en juego la replicación a nivel de bloque con múltiples rutas, especialmente porque una de las unidades SAN necesita ser designada maestra. Gracias por señalarme la parte sobre el sistema de archivos. Creo que eso lo explica más o menos. Supongo que podría intentar cambiarlo al modo 'continuar', o tal vez considerar cambiar el sistema de archivos a algo más resistente como XFS.

— Kamil Kisiel

1

No hay nada inherentemente malo en ext3: tendrás problemas similares con XFS. Y no recomendaría usar onerror = continue: el sistema creerá que el bloque es ilegible y perderá datos. La ruta múltiple no está reflejada: no necesita preocuparse por ninguna replicación en el host. Simplemente se conectaría a través de iSCSI a los objetivos maestro y secundario y el host sabría que si el maestro fallaba, no pasaría un error a la pila sino que intentaría el mismo comando dirigido al objetivo secundario.

— MikeyB

Mi comentario sobre la replicación se refería al hecho de que los dos servidores SAN necesitan sincronizar sus datos. Internamente, creo que el sistema funciona de manera similar a drbd, con una de las unidades (la que actualmente tiene el VIP) que es el maestro. Puede funcionar con múltiples rutas, pero realmente me gustaría resolver este problema sin alejarme de la arquitectura actual. Debería haber una manera de hacer que esto funcione, de lo contrario, mis sistemas que montan directamente volúmenes iSCSI nunca tienen el problema de que el volumen sea de solo lectura.

— Kamil Kisiel el

-1

Um ... Parte del problema también es que no estás ejecutando / como RO. Las mejores prácticas de seguridad indican que debe tener "/" montado ro, y que cualquier sistema de archivos que necesite rw debe montarse por separado (es decir, / var y / tmp). Si hay directorios en / etc que necesitan escritura, se deben mover a / var / etc / path y enlazarlos a / etc.

"/" solo debe montarse RW en modo de usuario único.

La configuración de esta manera podría evitar la falla predeterminada en la situación anterior cuando se combina con las otras sugerencias.

— Miguel
fuente

2

¿Estás seguro de que estás respondiendo a la pregunta correcta?

— Kamil Kisiel