NetWorker: Rozwiązywanie problemów z wykrywaniem bibliotek taśmowych w oprogramowaniu NetWorker
Podsumowanie: Ten artykuł ma na celu pomóc administratorom pomocy technicznej i NetWorker w określeniu przyczyn niemożności wykrycia biblioteki przez hosta.
Instrukcje
Jeśli biblioteka działała wcześniej i nagle przestała, należy wziąć pod uwagę ostatnią znaną zmianę jako prawdopodobną przyczynę:
- Nieobsługiwana zmiana adresu biblioteki po ponownym uruchomieniu, ponownym wykryciu i zmianie nazwy urządzenia
- Możliwe uszkodzenia spowodowane przepięciem, awarią zasilania lub innym zdarzeniem środowiskowym
- Zdarzenia awarii lub rekonfiguracja sprzętu transportowego
- Instalacja, zmiana lub usunięcie oprogramowania lub sterowników związanych z transportem lub robotyką
Jeśli biblioteka nigdy nie działała, sprawdź, czy sprzęt jest obsługiwany w Podręczniku zgodności sprzętu NetWorker (wymaga zalogowania się na konto pomocy technicznej firmy Dell).
- Nie można wykryć instalacji biblioteki taśmowej w węźle pamięci masowej lub serwerze NetWorker
- Nie można utworzyć kopii zapasowej danych, ponieważ nie można użyć sprzętu do tworzenia kopii zapasowych.
Aby zdiagnozować błędy wykrywania biblioteki, najpierw rozważ wszelkie ostatnie zmiany. Następnie podziel proces odkrywania od najniższych poziomów i przetestuj każdy etap.
Czasami pożądane jest przejście do bardziej rozwiniętego etapu odkrywania, w oparciu o dostępne dowody. Jeśli host A nie wykryje robota, podczas gdy host B odniesie sukces, robot prawdopodobnie nie ponosi winy. Hosty mogą używać różnych przełączników, co sprawia, że jest to pierwszy obszar do zbadania. Inne różnice w tym przykładzie obejmują samego hosta, prawdopodobnie system operacyjny, HBA, podział na strefy, okablowanie itp.
Jeśli host wykrył robota przed wystąpieniem problemu, skup się na elementach, które najprawdopodobniej uległy zmianie. Zbadanie awarii lub znanych zmian konfiguracji po zdarzeniu.
Użyj następujących poleceń, aby najpierw ustalić, czy system operacyjny może wykryć bibliotekę. Zawsze upewnij się, że poprawki systemu operacyjnego są aktualne, zwłaszcza jeśli dotyczą pamięci masowej.
nsrget -o:d na serwerze i węzłach, których dotyczy problem.
-o:d na każdym hoście z taśmami, na których taśmy są zajęte pisaniem. Można to sprawdzić w konsoli NetWorker Management Console (NMC) w sekcji Monitoring -> Devices.
Poniższy artykuł zawiera informacje na temat uzyskiwania i używania NSRGET: NetWorker: Korzystanie z narzędzia gromadzenia danych NSRGet NetWorker
Wykrywanie biblioteki: System operacyjny:
- Windows: Urządzenia niewykrywane przez podsystem Plug-and-Play (PnP) mogą nie być dostępne dla NetWorker. Nigdy nie ma instancji biblioteki bez sterownika, ponieważ istnieje sterownik ogólny, nawet jeśli sterownik dostawcy nie jest zainstalowany. StorPort to niskopoziomowy składnik sterownika pamięci masowej systemu Windows, który należy sprawdzić pod kątem waluty.
devmgmt.msc (Menedżer urządzeń)
devcon drivernodes *CHANGER*
- Linux: Pokaż, które urządzenia klasy SCSI zostały wykryte i wyliczone przez podsystem. Linux wykorzystuje
sgsterownik dla bibliotek, chyba że zainstalowano sterownik Atape firmy IBM (niezalecane).
cat /proc/scsi/scsi (pokaż wykryte biblioteki)
echo "- - -" > /sys/class/scsi_host/host#/scan (wymuszenie ponownego wykrywania)
- Solaris:
cfgadmlubluxadmPortu/dump_mappolecenia mogą wyliczać urządzenie Biblioteki. Jeśli to się nie uda,update_drvmoże być używany zarówno do zapewnienia wykrywania, jak i możliwości dołączeniasgeninstancji sterownika.
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: Użyj
cfgmgrw większości okoliczności; JeśliAtapesterownik jest w użyciu, użyjlsdev. W takim przypadku - upewnij się, żeAtape smcSterownik jest wymieniony jako "zdefiniowany" i "niedostępny" (co powoduje konflikty).
cfgmgr -v | grep -i changer
lsdev -Cc tape
rmdev -l smc0 (jeśli lsdev pokazuje, że jest dostępny)
- HP-UX:
ioscanjest jedynym poleceniem wymaganym do wyliczenia urządzeń klasy zmieniacza.
ioscan -FnkC autoch
Dla NetWorker
inquire (poniżej), aby się powiodło, może być konieczne usunięcie pliku pamięci podręcznej wykrywania urządzeń tymczasowych:
rm -f /tmp/lgto_scsi_devlist
- Openvms: Użyj tych poleceń, aby zweryfikować łączność:
mcr sysman IO AUTOCONFIGURE
show device gk/full
- NetWorker: Polecenia te mają charakter referencyjny i zazwyczaj działają z wyższym poziomem niż polecenia systemu operacyjnego podane powyżej. Mogą one być przydatne przy próbie zdiagnozowania problemu niższego poziomu przez dostarczenie dodatkowych informacji lub błędów jako wskazówek dotyczących danego problemu, ale nie oczekuje się, że zakończą się sukcesem, jeśli operacje niższego poziomu kończą się niepowodzeniem.
inquire -lc
lusbinfo -v
changers
dvdetect -dlV -D9
lusbinfo i changers może nie istnieć na wszystkich platformach. W razie potrzeby można zwiększyć poziomy debugowania, ustawiając zmienną środowiskową LUS_DEBUG:
UNIX:
export LUS_DEBUG=9
Windows:
set LUS_DEBUG=9
AIX:
lusdebug ffff
Spróbuj również:
SJI_DEBUG=9, SCSI_DEBUG=9, JBDEBUG=9
Dodatkowe informacje
Upewnij się, że rozumiesz, że problemy z robotyką, które okazały się poza zakresem aplikacji NetWorker (czytaj: nie mogą zostać wykryte przy użyciu standardowych metod systemu operacyjnego), nie są objęte pomocą techniczną NetWorker.
Aby uzyskać więcej informacji, patrz: NetWorker: Rozwiązywanie problemów z biblioteką taśmową w oprogramowaniu NetWorker
Dział pomocy technicznej może udzielić wskazówek przy użyciu powyższych kryteriów, ale nie dysponuje zasobami dotyczącymi systemu operacyjnego, HBA ani robotyki. To ograniczenie może prowadzić do przedłużającego się i bezskutecznego rozwiązywania problemów.