Il "rescan-scsi-bus.sh" può essere utilizzato per scansionare nuovi LUN in una macchina CentOS/RHEL. Quando viene eseguito 'rescan-scsi-bus.sh -i', lo script esegue anche un LIP_RESET (ISSUE_LIP) che potrebbe causare un'interruzione dell'I/O sul server e persino causare un'interruzione in caso di un sistema in esecuzione su un carico pesante .
Cos'è LIP (Loop Initialization Protocol)?
LIP esegue la scansione dell'interconnessione e fa sì che il livello SCSI venga aggiornato per riflettere i dispositivi attualmente sul bus. Un LIP è, essenzialmente, un reset del bus e causerà l'aggiunta e la rimozione del dispositivo. Questa procedura è necessaria per configurare una nuova destinazione SCSI su un'interconnessione Fibre Channel. Tieni presente che issue_lip è un'operazione asincrona. Il comando potrebbe essere completato prima del completamento dell'intera scansione.
Cosa può causare il ripristino LIP?
Il metodo del protocollo di inizializzazione del ciclo per eseguire la scansione degli HBA può causare ritardi e timeout di I/O se l'HBA/dispositivo è in uso e può anche rimuovere i dispositivi in modo imprevisto. Pertanto, l'esecuzione della scansione con questo metodo non è consigliata su alcun server di produzione in cui i dispositivi SAN siano già configurati in uso. Questo tipo di scansione è consigliato su un server di nuova creazione per eseguire la scansione di tutti i LUNS/Dispositivi. LIP viene normalmente eseguito all'avvio del server.
Quando usare issu_lip
Utilizzare il comando standard rescan-scsi-bus.sh senza -i FLAG, rescan-scsi-bus.sh eseguirà la "scansione" solo per i nuovi LUN. Prestare la massima attenzione durante l'esecuzione di rescan-scsi-bus.sh -i su Live/Production Environment, ciò potrebbe causare seri problemi.
Il problema può essere ancora peggiore quando rescan-scsi-bus.sh viene eseguito sul nodo RAC effettivo o su qualsiasi software di clustering che utilizza il processo di eliminazione, ciò è dovuto all'attività di I/O che verrà bloccata sul nodo in cui rescan-scsi-bus. sh -i viene eseguito e anche l'heartbeat del disco non riesce a scrivere "informazioni sull'heartbeat".
Il ripristino LIP può essere ottenuto anche senza rescan-scsi-bus.sh -i, utilizzando il comando:
# echo "1" > /sys/class/fc_host/host/issue_lip
Questo metodo è non consigliato . Il comando LIP è asincrono, quindi questo comando può tornare prima del completamento dell'operazione LIP. È necessario monitorare il registro di sistema /var/log/messages per determinare quando l'operazione LIP è stata completata. Questo è essenzialmente un reset del bus, quindi qualsiasi operazione di I/O in volo potrebbe essere interrotta. Utilizzare invece lo script rescan-scsi-bus.sh.
Quando è necessario rilevare nuove LUN, è possibile eseguire:
# echo "1" > /sys/class/fc_host/host/issue_lip
Questo dovrebbe aiutare a far apparire nuove LUN sul sistema, senza la necessità di eseguire un comando rescan-scsi-bus.sh -i.
Questo metodo non è raccomandato. Il comando LIP è asincrono, quindi questo comando può tornare prima del completamento dell'operazione LIP. È necessario monitorare il registro di sistema /var/log/messages per determinare quando l'operazione LIP è stata completata. Questo è essenzialmente un reset del bus, quindi qualsiasi operazione di I/O in volo potrebbe essere interrotta. Utilizzare invece lo script rescan-scsi-bug.sh.
Conclusione
Quando rescan-scsi-bus.sh -i deve essere realmente eseguito nell'ambiente di produzione, interrompere tutte le applicazioni/istanze di database e quindi seguire con rescan-scsi-bus.sh -i. Il modo più sicuro sarebbe semplicemente il riavvio del server pianificato come quando il ripristino LIP di avvio del server viene eseguito automaticamente.
Tieni inoltre presente che rescan-scsi-bus.sh -i non deve essere eseguito quando un percorso multipath viene perso, verrà recuperato quando verrà ripristinato il percorso di archiviazione back-end (questo viene fatto dall'opzione path_checker in multipath .conf).