El kernel de Linux permite un control de bajo nivel sobre la forma en que se programa la E/S para bloquear los dispositivos. Los valores por defecto en varias distribuciones de Linux varían considerablemente. Las pruebas demuestran que la fecha límite suele ofrecer los mejores resultados, pero en ocasiones NOOP ha sido ligeramente mejor. La diferencia de rendimiento es mínima, pero pruebe ambas opciones si es necesario extraer el máximo rendimiento posible de una configuración de base de datos. CFQ es el valor predeterminado en muchas configuraciones y ha demostrado tener problemas de rendimiento significativos con cargas de trabajo de bases de datos.

Consulte la documentación relevante del proveedor de Linux para obtener instrucciones sobre la configuración del programador de E/S.

Algunos clientes se han encontrado con fallos durante la interrupción de la red porque el daemon multivía no se estaba ejecutando en su sistema. En versiones recientes de Linux, el proceso de instalación del sistema operativo y el daemon de rutas múltiples pueden dejar estos sistemas operativos vulnerables a este problema. Los paquetes están instalados correctamente, pero no están configurados para el inicio automático después de un reinicio.

Por ejemplo, el valor predeterminado para el demonio multiruta en RHEL 9.7 podría aparecer de la siguiente manera:

Esto se puede corregir con los siguientes comandos:

Establezca la profundidad de cola adecuada para los dispositivos SAN para evitar cuellos de botella de E/S. La profundidad de cola predeterminada en Linux a menudo se establece en 128, lo que puede generar problemas de rendimiento con las bases de datos Oracle. Establecer una profundidad de cola demasiado alta puede provocar una cola de E/S excesiva, lo que genera una mayor latencia y una reducción del rendimiento. Establecerlo demasiado bajo puede limitar la cantidad de solicitudes de E/S pendientes, lo que reduce el rendimiento general. Una profundidad de cola de 64 suele ser un buen punto de partida para las cargas de trabajo de bases de datos Oracle en ASA r2, pero es posible que sea necesario ajustarla en función de las características específicas de la carga de trabajo y las pruebas de rendimiento.

La duplicación de ASM puede requerir cambios en la configuración multivía de Linux para permitir que ASM reconozca un problema y cambie a un grupo de fallos alternativo. La mayoría de las configuraciones de ASM en ONTAP utilizan redundancia externa, lo que significa que la cabina externa ofrece protección de datos y ASM no refleja datos. Algunos sitios utilizan ASM con redundancia normal para proporcionar duplicación bidireccional, normalmente en diferentes sitios.

Para los sistemas ASA r2 que admiten rutas múltiples activo-activo, se deben ajustar estas configuraciones de rutas múltiples. Dado que todas las rutas están activas y tienen equilibrio de carga, no se requiere una cola indefinida. En lugar de ello, los parámetros de rutas múltiples deberían priorizar el rendimiento y la recuperación rápida. Este comportamiento es importante para la duplicación de ASM porque ASM debe recibir una falla de E/S para poder volver a intentar la E/S en un LUN alternativo. Si la E/S se pone en cola indefinidamente, ASM no puede activar una conmutación por error.

Defina los siguientes parámetros en Linux multipath.conf Archivo para LUN de ASM utilizados con la duplicación de ASM:

Estos valores crean un timeout de 120 segundos para los dispositivos ASM. El tiempo de espera se calcula como el polling_interval * no_path_retry como segundos. Puede que sea necesario ajustar el valor exacto en algunas circunstancias, pero un tiempo de espera de 120 segundos debería ser suficiente para la mayoría de los usos. Concretamente, 120 segundos deberían permitir que se produzca una toma de control o una devolución de la controladora sin que se produzca un error de I/O, lo que provocaría que el grupo de errores se desconectara.

A inferior no_path_retry Value puede reducir el tiempo necesario para que ASM cambie a un grupo de fallos alternativo, pero esto también aumenta el riesgo de una conmutación por error no deseada durante actividades de mantenimiento como la toma de control de un controlador. El riesgo se puede mitigar mediante una supervisión cuidadosa del estado de duplicación de ASM. Si se produce una conmutación al respaldo no deseada, los duplicados pueden volver a sincronizarse rápidamente si la resincronización se realiza con relativa rapidez. Para obtener información adicional, consulte la documentación de Oracle on ASM Fast Mirror Resync para ver la versión del software de Oracle en uso.