Linux
Sugerir cambios
PDF
Temas de configuración específicos del sistema operativo Linux.
Tablas de ranuras TCP Linux NFSv3
Las tablas de ranuras TCP son equivalentes a NFSv3 a la profundidad de la cola del adaptador de bus de host (HBA). En estas tablas se controla el número de operaciones de NFS que pueden extraordinarias a la vez. El valor predeterminado suele ser 16, que es demasiado bajo para un rendimiento óptimo. El problema opuesto ocurre en los kernels más nuevos de Linux, que pueden aumentar automáticamente el límite de la tabla de ranuras TCP a un nivel que sature el servidor NFS con solicitudes.
Para obtener un rendimiento óptimo y evitar problemas de rendimiento, ajuste los parámetros del núcleo que controlan las tablas de ranuras TCP.
Ejecute el sysctl -a | grep tcp.*.slot_table command, y observe los siguientes parámetros:
# sysctl -a | grep tcp.*.slot_table sunrpc.tcp_max_slot_table_entries = 128 sunrpc.tcp_slot_table_entries = 128
Todos los sistemas Linux deben incluir sunrpc.tcp_slot_table_entries, pero solo algunos incluyen sunrpc.tcp_max_slot_table_entries. Ambos deben establecerse en 128.
| Precaución |
|---|
Si no se establecen estos parámetros, puede tener efectos significativos en el rendimiento. En algunos casos, el rendimiento es limitado porque el sistema operativo linux no está emitiendo suficiente I/O. En otros casos, las latencias de I/O aumentan cuando el sistema operativo linux intenta emitir más operaciones de I/O de las que se pueden mantener. |
Opciones de montaje de Linux NFS
En la siguiente tabla, se enumeran las opciones de montaje de NFS de Linux para una instancia única.
| Tipo de archivo | Opciones de montaje |
|---|---|
Directorio Raíz de ADR |
|
Archivos de control Archivos de datos Rehacer registros |
|
ORACLE_HOME |
|
La siguiente tabla enumera las opciones de montaje de NFS de Linux para RAC.
| Tipo de archivo | Opciones de montaje |
|---|---|
Directorio Raíz de ADR |
|
Archivos de control Archivos de datos Rehacer registros |
|
CRS/votación |
|
Específico |
|
Compartido |
|
La diferencia principal entre las opciones de montaje de instancia única y RAC es la adición de actimeo=0 a las opciones de montaje. Esta adición tiene el efecto de deshabilitar el almacenamiento en caché del sistema operativo del host, lo que permite que todas las instancias del clúster RAC tengan una vista coherente del estado de los datos. Aunque utilice el init.ora parámetro filesystemio_options=setall tiene el mismo efecto de deshabilitar el almacenamiento en caché de host, sigue siendo necesario utilizarlo actimeo=0.
La razón actimeo=0 es necesario para el uso compartido ORACLE_HOME Despliegues es para facilitar la consistencia de archivos como los archivos de contraseñas de Oracle y spfiles. Si cada instancia de un clúster de RAC tiene un dedicado ORACLE_HOME, entonces este parámetro no es necesario.
Por lo general, los archivos que no son de base de datos se deben montar con las mismas opciones utilizadas para los archivos de datos de instancia única, aunque las aplicaciones específicas pueden tener requisitos diferentes. Evite las opciones de montaje noac y.. actimeo=0 si es posible, ya que estas opciones desactivan la lectura anticipada y el almacenamiento en búfer de nivel de sistema de archivos. Esto puede causar graves problemas de rendimiento en procesos como extracción, traducción y carga.
ACCESO y GETATTR
Algunos clientes han observado que un nivel extremadamente alto de otros IOPS, como EL ACCESO y GETATTR, puede dominar sus cargas de trabajo. En casos extremos, las operaciones como las de lectura y escritura pueden ser tan bajas como el 10 % del total. Este es un comportamiento normal con cualquier base de datos que incluya el uso actimeo=0 y/o. noac En Linux, porque estas opciones provocan que el sistema operativo Linux vuelva a cargar constantemente los metadatos de los archivos del sistema de almacenamiento. Las operaciones como EL ACCESO y GETATTR son operaciones de bajo impacto que se proporcionan desde la caché de ONTAP en un entorno de base de datos. No se deben considerar IOPS auténticos, como lecturas y escrituras, que crean una demanda real de sistemas de almacenamiento. Sin embargo, estas otras IOPS crean una cierta carga, sobre todo en entornos RAC. Para solucionar esta situación, habilite DNFS, que omite la caché de buffers del sistema operativo y evita estas operaciones de metadatos innecesarias.
NFS directo de Linux
Una opción de montaje adicional denominada nosharecache, Es necesario cuando (a) DNFS está activado y (b) un volumen de origen se monta más de una vez en un único servidor (c) con un montaje NFS anidado. Esta configuración se ve principalmente en entornos que admiten aplicaciones SAP. Por ejemplo, un único volumen de un sistema NetApp podría tener un directorio ubicado en /vol/oracle/base y un segundo en /vol/oracle/home. Si /vol/oracle/base está montado en /oracle y.. /vol/oracle/home está montado en /oracle/home, El resultado son montajes NFS anidados que se originan en la misma fuente.
El sistema operativo puede detectar el hecho de que /oracle y /oracle/home residen en el mismo volumen, que es el mismo sistema de archivos de origen. A continuación, el sistema operativo utiliza el mismo identificador de dispositivo para acceder a los datos. Al hacerlo, se mejora el uso del almacenamiento en caché del sistema operativo y algunas otras operaciones, pero interfiere con DNFS. Si DNFS debe acceder a un archivo, como spfile , activado /oracle/home, puede intentar utilizar erróneamente la ruta de acceso incorrecta a los datos. El resultado es una operación de I/O con errores. En estas configuraciones, agregue nosharecache la opción de montaje a cualquier sistema de archivos NFS que comparta un volumen de origen con otro sistema de archivos NFS en ese host. Al hacerlo, se fuerza al sistema operativo Linux a asignar un identificador de dispositivo independiente para ese sistema de archivos.
Linux Direct NFS y Oracle RAC
El uso de DNFS ofrece ventajas especiales de rendimiento para Oracle RAC en el sistema operativo Linux, ya que Linux no dispone de un método para forzar la entrada/salida directa, que se necesita con RAC para lograr coherencia entre los nodos. Como solución alternativa, Linux requiere el uso de actimeo=0 Opción de montaje, que hace que los datos de archivo caduquen inmediatamente desde la caché del sistema operativo. Esta opción, a su vez, fuerza al cliente NFS de Linux a volver a leer constantemente los datos de atributos, lo que daña la latencia y aumenta la carga en la controladora de almacenamiento.
Al habilitar DNFS se omite el cliente NFS del host y se evita este daño. Varios clientes han informado de mejoras significativas en el rendimiento en clústeres RAC y reducciones considerables en la carga de ONTAP (especialmente con respecto a otras IOPS) al habilitar DNFS.
Linux Direct NFS y archivo oranfstab
Al utilizar DNFS en Linux con la opción multipathing, se deben utilizar varias subredes. En otros sistemas operativos, se pueden establecer varios canales DNFS mediante el LOCAL y.. DONTROUTE Opciones para configurar varios canales DNFS en una sola subred. Sin embargo, esto no funciona correctamente en Linux y puede resultar en problemas de rendimiento inesperados. Con Linux, cada NIC utilizada para el tráfico DNFS debe estar en una subred diferente.
Programador de I/O.
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.
Accesos múltiples
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 daemon multipath en RHEL5,5 puede aparecer del siguiente modo:
[root@host1 iscsi]# chkconfig --list | grep multipath multipathd 0:off 1:off 2:off 3:off 4:off 5:off 6:off
Esto se puede corregir con los siguientes comandos:
[root@host1 iscsi]# chkconfig multipathd on [root@host1 iscsi]# chkconfig --list | grep multipath multipathd 0:off 1:off 2:on 3:on 4:on 5:on 6:off
Duplicación de ASM
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.
La configuración de Linux que se muestra en la "Documentación de utilidades de host de NetApp" Incluya parámetros multivía que generen la cola indefinida de I/O. Esto significa que una I/O en un dispositivo LUN sin rutas activas espera tanto tiempo como sea necesario para que finalice la I/O. Esto suele ser deseable ya que los hosts Linux esperan todo el tiempo necesario para que se completen los cambios de ruta SAN, para que se reinicien los switches FC o para que un sistema de almacenamiento complete una conmutación al respaldo.
Este comportamiento de puesta en cola ilimitada provoca un problema con el mirroring de ASM debido a que ASM debe recibir un error de I/O para que vuelva a intentar I/O en un LUN alternativo.
Defina los siguientes parámetros en Linux multipath.conf Archivo para LUN de ASM utilizados con la duplicación de ASM:
polling_interval 5 no_path_retry 24
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.
Opciones de montaje de Linux xfs, ext3 y ext4
|
NetApp recomienda usar las opciones de montaje predeterminadas. |