El "rescan-scsi-bus.sh" se puede usar para escanear nuevos LUN en una máquina CentOS/RHEL. Cuando se ejecuta 'rescan-scsi-bus.sh -i', el script también ejecuta un LIP_RESET (ISSUE_LIP) que puede causar una interrupción en la E/S en el servidor e incluso provocar una interrupción en el caso de un sistema que se ejecuta con mucha carga. .
¿Qué es LIP (protocolo de inicialización de bucle)?
LIP escanea la interconexión y hace que la capa SCSI se actualice para reflejar los dispositivos actualmente en el bus. Un LIP es, esencialmente, un restablecimiento de bus y provocará la adición y eliminación de dispositivos. Este procedimiento es necesario para configurar un nuevo destino SCSI en una interconexión de canal de fibra. Tenga en cuenta que issue_lip es una operación asíncrona. El comando puede completarse antes de que se complete todo el escaneo.
¿Qué puede causar el restablecimiento de LIP?
El método del protocolo de inicialización de bucle para escanear los HBA puede causar retrasos y tiempos de espera de E/S si el HBA/dispositivo está en uso y también puede eliminar dispositivos de forma inesperada. Por lo tanto, no se recomienda realizar el escaneo con este método en ningún servidor de producción donde los dispositivos SAN ya estén configurados en uso. Este tipo de escaneo se recomienda en un servidor recién construido para escanear todos los LUNS/Dispositivos. LIP normalmente se ejecuta cuando se inicia el servidor.
Cuándo usar issu_lip
Utilice el comando estándar rescan-scsi-bus.sh sin -i FLAG, rescan-scsi-bus.sh solo 'explorará' en busca de nuevos LUN. Preste la máxima atención al ejecutar rescan-scsi-bus.sh -i en Live/Production Environment, esto puede causar problemas graves.
El problema puede ser aún peor cuando se ejecuta rescan-scsi-bus.sh en el nodo RAC real o en cualquier software de agrupación en clúster que use el proceso de desalojo, esto se debe a la actividad de E/S que se bloqueará en el nodo donde rescan-scsi-bus. sh -i se ejecuta causando que incluso disk-heartbeat no pueda escribir 'información de latido'.
El restablecimiento de LIP también se puede lograr sin rescan-scsi-bus.sh -i, usando el comando:
# echo "1" > /sys/class/fc_host/host/issue_lip
Este método no se recomienda . El comando LIP es asíncrono, por lo que este comando puede regresar antes de que se complete la operación LIP. Debe monitorear el registro del sistema /var/log/messages para determinar cuándo se completó la operación LIP. Esto es esencialmente un restablecimiento de bus, por lo que cualquier operación de E/S en vuelo puede verse interrumpida. Utilice el script rescan-scsi-bus.sh en su lugar.
Cuando es necesario descubrir nuevos LUN, puede ejecutar:
# echo "1" > /sys/class/fc_host/host/issue_lip
Esto debería ayudar a que aparezcan nuevos LUN en el sistema, sin necesidad de ejecutar un comando rescan-scsi-bus.sh -i.
No se recomienda este método. El comando LIP es asíncrono, por lo que este comando puede regresar antes de que se complete la operación LIP. Debe monitorear el registro del sistema /var/log/messages para determinar cuándo se completó la operación LIP. Esto es esencialmente un restablecimiento de bus, por lo que cualquier operación de E/S en vuelo puede verse interrumpida. Utilice el script rescan-scsi-bug.sh en su lugar.
Conclusión
Cuando sea necesario ejecutar rescan-scsi-bus.sh -i en el entorno de producción, detenga todas las instancias de aplicaciones/bases de datos y luego siga con rescan-scsi-bus.sh -i. La forma más segura sería simplemente reiniciar el servidor planificado como cuando el reinicio del LIP de inicio del servidor se ejecuta automáticamente.
También tenga en cuenta que no es necesario ejecutar rescan-scsi-bus.sh -i cuando se pierde una ruta multirruta, se recuperará cuando se restablezca la ruta de almacenamiento back-end (esto se hace mediante la opción path_checker en multirruta). .conf).