Capítulo 12. Almacenamiento

Si la ruta no es fiable, como cuando la conexión se corta con frecuencia, multipathd aún seguirá intentando usar esa ruta. El tiempo de espera antes de que multipathd se de cuenta de que la ruta ya no es accesible es de 300 segundos, lo cual da la impresión de que multipathd se ha detenido.

Para corregir este error, se han agregado dos nuevas opciones de configuración: delay_watch_checks y delay_wait_checks. La opción delay_watch_checks establece el número de ciclos que multipathd debe vigilar la ruta hasta que se conecte en línea. Si la ruta falla bajo ese valor asignado, multipathd no la usará. multipathd confiará entonces en la opción delay_wait_checks para decirle cuántos ciclos consecutivos deben pasar antes de que la ruta se invalide nuevamente. Esto evita que las rutas que no son confiables sean utilizadas inmediatamente después de la reconexión en línea.

Los usuarios eran capaces de dividir su configuración entre archivos /etc/multipath.conf y otros archivos de configuración. Esto evitaba que los usuarios configuraran el archivo de configuración principal para todas las máquinas y mantuviera la información de configuración en archivos independientes para cada máquina.

Para solucionar este problema, se ha agregado la opción config_dir en el archivo multipath.config. Los usuarios deben cambiar la opción config_dir ya sea a una cadena vacía o a un nombre de ruta de directorio calificado. Cuando se establece algo diferente a una cadena vacía, multipathd leerá en orden alfabético todos los archivos .conf. Luego aplicará exactamente las configuraciones como si hubieran sido agregadas al archivo /etc/multipath.conf. Si no ser hace este cambio, config_dir se predeterminará a /etc/multipath/conf.d.

El mapeador de dispositivos (DM) ha sido actualizado a la versión 4.0 de la corriente principal de desarrollo, la cual proporciona una cantidad de correcciones de errores y mejoras con respecto a la versión anterior, incluidas un importante actualización de rendimiento DM crypt; actualización de DM core para soportar Multi-Queue Block I/O Queueing Mechanism (blk-mq).

El comando dmstats proporciona soporte a userspace para estadísticas device-mapper I/O . Esto permite al usuario crear, manejar y reportar contadores de E/S, métrica e histograma de latencia para regiones de dispositivos device-mapper. Los campos de estadística ahora están disponibles en los reportes dmsetup y el comando dmstats agrega nuevos modos de reporte diseñados para usar con información de estadísticas. Para obtener más información sobre el comando dmstats, por favor consulte la página de manual dmstats(8).

SCSI T10 DIX recibe soporte total en Red Hat Enterprise Linux 7.2, únicamente las siguientes HBAs y matrices de almacenamiento y no en LUN utilizadas para arrancar desde un entorno SAN. Además, T10 DIX recibe soporte en RHEL 7 solamente en hardware nativo, no en huéspedes virtualizados.

* EMULEX LPe16000/LPe16002

* QLOGIC QLE2670/QLE2672

* FUJITSU ETERNUS DX100 S3

* FUJITSU ETERNUS DX200 S3

* FUJITSU ETERNUS DX500 S3

* FUJITSU ETERNUS DX600 S3

* FUJITSU ETERNUS DX8100 S3

* FUJITSU ETERNUS DX8700 S3

* FUJITSU ETERNUS DX8900 S3

* FUJITSU ETERNUS DX200F

* FUJITSU ETERNUS DX60 S3

Soporte para DIX sigue en Muestra de tecnología para otros HBA y matrices de almacenamiento .

Observe que T10 DIX requiere base de datos o algún otro software que proporcione generación y revisiones de suma de verificación en bloques de discos. Ningún sistema de archivos Linux tiene esta funcionalidad.

LVM caché ha recibido soporte total desde Red Hat Enterprise Linux 7.1. Esta funcionalidad le permite a los usuarios crear volúmenes lógicos (LVs) con un dispositivo rápido pequeño ejecutándose como una memoria caché para dispositivos grandes más lentos. Consulte la página de manual lvmcache(7) para obtener información sobre cómo crear volúmenes lógicos cache.

Observe las siguientes restricciones en el uso de caché LV:

*LV cache debe ser un dispositivo de alto nivel. No puede utilizarse como un LV de grupo fino, una imagen de un LV RAID u otros subtipos de LV.

* La LV sub-LV caché (la LV de origen, LV de metadatos, y el LV de datos) solamente pueden ser del tipo lineal, en bandas o RAID.

* Las propiedades de la memoria caché LV no se pueden cambiar después de crearlas. Para cambiar las propiedades caché, retire la caché como se describe en lvmcache(7) y vuélvala a crear con las propiedades deseadas.

Se ha escrito una nueva política dm-cache smq que reduce el consumo de memoria y mejora el rendimiento en la mayoría de los casos de uso. Ahora, esta nueva política caché es la predeterminada para los volúmenes lógicos LVM cache. Los usuarios que prefieran usar la política caché mq de legado aún pueden hacerlo al proveer un argumento —cachepolicy durante la creación del volumen lógico caché.

Los grupos de volúmenes LVM ahora pueden asignarse a un propietario. El propietario de grupo de volúmenes es el ID de sistemas de un host. Únicamente el host con ID de sistema determinado puede usar el Grupo de volúmenes (VG). Esto puede beneficiar los grupos de volúmenes que existen en dispositivos compartidos, visibles a múltiples hosts, que de otra manera no estarían protegidos del uso simultáneo de hosts múltiples. Los grupos de volúmenes LVM en dispositivos compartidos con un ID de sistema asignado solo pertenecen a un host y están protegidos de otros hosts.