NetWorker: Solución de problemas de detección de librerías de cintas en NetWorker
Resumen: El objetivo de este artículo es ayudar a los administradores de soporte y de NetWorker a determinar las causas de la incapacidad de un host para detectar una librería.
Instrucciones
Si la biblioteca funcionaba anteriormente y repentinamente no lo está, considere el último cambio conocido como la causa probable:
- Cambio no controlado en la dirección de la biblioteca después del reinicio, el redescubrimiento y el cambio de nombre del dispositivo
- Posibles daños debido a una sobrecarga eléctrica, una interrupción u otro evento ambiental
- Eventos de falla o reconfiguración del hardware de transporte
- Instalación, modificación o eliminación de software o controladores relacionados con el transporte o la robótica
Si la biblioteca nunca funcionó, confirme que el hardware sea compatible con la Guía de compatibilidad de hardware de NetWorker (es necesario iniciar sesión en la cuenta de soporte de Dell).
- No se puede detectar la instalación de la biblioteca de cintas en el servidor o el nodo de almacenamiento de NetWorker
- No se puede realizar una copia de seguridad de los datos debido a que el hardware de copia de seguridad no se puede utilizar.
Para diagnosticar fallas de detección de bibliotecas, primero considere los cambios recientes. A continuación, desglose el proceso de descubrimiento desde sus niveles más bajos y pruebe cada etapa.
A veces es deseable avanzar a una etapa más avanzada de descubrimiento, basada en la evidencia disponible. Si el host A no detecta el robot mientras que el host B tiene éxito, es probable que el robot no tenga la culpa. Los hosts pueden utilizar diferentes switches, lo que los convierte en la primera área que se debe investigar. Otras diferencias en este ejemplo incluyen el host, posiblemente el sistema operativo, HBA, zonificación, cableado, etc.
Si el anfitrión detectó el robot antes del problema, concéntrese en los elementos con más probabilidades de haber cambiado. Investigue las fallas o los cambios en la configuración conocidos después del evento.
Utilice los siguientes comandos para establecer primero si el sistema operativo puede detectar la librería. Siempre asegúrese de que los parches del sistema operativo estén actualizados, especialmente en lo que respecta al almacenamiento.
nsrget -o:d en el servidor y los nodos afectados.
-o:d en cualquier host con cintas donde las cintas estén ocupadas escribiendo. Puede comprobar esto desde NetWorker Management Console (NMC) en Monitoring -> Devices.
En el siguiente artículo, se proporciona información sobre cómo obtener y usar NSRGET: NetWorker: Cómo utilizar la herramienta de recolección de datos de NetWorker NSRGet
Detección de librerías: Sistema operativo:
- Windows: Es posible que NetWorker no pueda acceder a los dispositivos no detectados por el subsistema Plug-and-Play (PnP). Nunca hay una instancia de una biblioteca sin un controlador, ya que existe un controlador genérico incluso si no hay instalado un controlador de proveedor. StorPort es el componente del controlador de almacenamiento de Windows de bajo nivel cuya moneda se debe comprobar.
devmgmt.msc (Administrador de dispositivos)
devcon drivernodes *CHANGER*
- Linux: Muestra qué dispositivos de clase SCSI ha detectado y enumerado el subsistema. Linux utiliza el método
sgcontrolador para bibliotecas, a menos que el controlador Atape de IBM esté instalado (no se recomienda).
cat /proc/scsi/scsi (mostrar librerías detectadas)
echo "- - -" > /sys/class/scsi_host/host#/scan (redetección forzada)
- Solaris:
cfgadmoluxadmPuerto /dump_mapLos comandos pueden enumerar un dispositivo de biblioteca. En su defecto,update_drvse puede utilizar para garantizar tanto la detección como la capacidad de conectar unsgeninstancia del controlador.
cfgadm -lavo show_FCP_dev
for FCI in `luxadm -e port | cut -f1`; do luxadm -e dump_map $FCI; done
rm -f /dev/scsi/changer/*; update_drv -f sgen -v
- AIX: Uso
cfgmgren la mayoría de las circunstancias; SiAtapeEl controlador está en uso, uselsdev. En este caso, asegúrese de queAtape smcEl controlador aparece como "Definido" y no "Disponible" (lo que provoca conflictos).
cfgmgr -v | grep -i changer
lsdev -Cc tape
rmdev -l smc0 (si lsdev muestra que está disponible)
- HP-UX:
ioscanes el único comando necesario para enumerar los dispositivos de clase de cambiador.
ioscan -FnkC autoch
Para NetWorker
inquire comando (a continuación) Para que se ejecute correctamente, es posible que deba quitar el archivo temporal de caché de descubrimiento de dispositivos:
rm -f /tmp/lgto_scsi_devlist
- OpenVMS: Utilice estos comandos para verificar la conectividad:
mcr sysman IO AUTOCONFIGURE
show device gk/full
- NetWorker: Estos comandos se proporcionan como referencia y, por lo general, se ejecutan a un nivel más alto que los comandos del sistema operativo proporcionados anteriormente. Pueden ser útiles para intentar diagnosticar un problema de nivel inferior proporcionando información adicional o errores como pistas para el problema en cuestión, pero no se espera que tengan éxito si fallan las operaciones de nivel inferior.
inquire -lc
lusbinfo -v
changers
dvdetect -dlV -D9
lusbinfo y changers Es posible que no exista en todas las plataformas. Si lo desea, puede aumentar los niveles de depuración mediante la configuración de la variable de entorno LUS_DEBUG:
UNIX:
export LUS_DEBUG=9
Windows:
set LUS_DEBUG=9
AIX:
lusdebug ffff
Pruebe también:
SJI_DEBUG=9, SCSI_DEBUG=9, JBDEBUG=9
Información adicional
Asegúrese de comprender que los problemas de robótica que se muestran fuera del alcance de NetWorker como una aplicación (léase: no se pueden detectar con los métodos estándar del sistema operativo) no están dentro del alcance del soporte de NetWorker.
Para obtener más información, consulte: NetWorker: Solución de problemas de librerías de cintas en NetWorker
El soporte puede proporcionar orientación utilizando los criterios anteriores, pero no tenemos recursos de proveedores de SO, HBA o robótica. Esta limitación puede llevar a una solución de problemas prolongada y fallida.