NetWorker: Felsökning av problem med beställning av bandbibliotek
Sammanfattning: I den här artikeln beskrivs ett välkänt problem med bandbibliotek i en SAN-miljö som leder till att enhetsnamn ändras av operativsystemet, vilket leder till programfel.
Symptom
I ett Plug 'N Play-operativsystem tilldelas enheter SCSI-måladresser i identifieringsordningen.
Eftersom SAN-identifieringsordningen varierar och anslutningsförlust utlöser Plug-and-Play-ommappning ändras målnumren och kan inte förbli fasta.
Plug-and-Play byter namn på enheter baserat på uppräkningsordning, så eventuella avsiktliga eller oavsiktliga anslutningsavbrott kan leda till att enheter tilldelas nya namn.
Ett problem med enhetsbeställning beskriver ett tillstånd där NetWorkers konfigurerade drivrutinsnamn för en enhet inte matchar det faktiska namnet. Det här är oftast ett resultat av att drivrutinsnamnet ändras i operativsystemet efter den inledande NetWorker-bibliotekskonfigurationen. Detta är vanligtvis ett Plug 'N Play-operativsystemproblem som påverkar Windows och Linux.
Det finns många fel och villkor som är associerade med det här problemet, inklusive, men inte begränsat till:
- Fel: '
nsrd: media info: failed unloading drive `{driver handle}' to slot {slot number}, error '69'' - Fel: '
{hostname} the destination component full' - Fel: '
{driver handle} read open error, no such device or address' - Fel: '
opening: I/O error' - Fel: '
nsrd: Jukebox '{jukebox}' failed: expected volume '{volid}' got {volid}' - Fel: '
nsrd: Jukebox '{jukebox}' failed: expected volume '(volume_name)' got 'NULL'' - Fel: '
read open error, device not ready' - Fel: '
nsrjb: Jukebox error, All allocated drives are not usable, unrecoverable operation errors' - Fel: '
nsrd: Jukebox '{jukebox}' failed: expected volume '{volid}' got {volid}' - Fel: '
nsrd: Jukebox '{jukebox}' failed: expected volume '{volume}' got 'NULL'' - Fel: '
read open error, device not ready' - Fel: '
nsrjb: Jukebox error, All allocated drives are not usable, unrecoverable operation errors' - Fel: '
nsrd: media warning: {driver handle} reading: read open error: No media in drive.' - Fel: '
inventory: Bar code label `{barcode}' does not match media db bar code label, updating media db' - Fel: '
Illegal request, medium not present' - Fel: '
nsrd: media info: failed unloading drive `{driver handle}' to slot {slot number}'
Orsak
NetWorker skapar biblioteksobjektet under den första installationen och länkar bandenheterna till de OS-genererade enhetsreferenser som de har för tillfället. Det är en statisk association som återspeglar relationen vid tidpunkten för konfigurationen. Ett bibliotek kan till exempel ha två enheter:
Fysisk enhet 1 = \\.\Tape0 (eller kanske /dev/nst0 i Linux)
Fysisk enhet 2 = \\.\Tape1 (eller /dev/nst1)
I Plug-and-Play-system som Windows eller Linux kan alla enheter som försvinner, inklusive omstarter eller anslutningsändringar, göra att operativsystemet byter namn på enheterna. Speciellt på ett SAN, där enhetsidentifieringen kan vara störd, kan enheterna namnges annorlunda vid nästa omstart, till exempel i motsats till ovanstående:
Fysisk enhet 1 = \\.\Tape1 or /dev/nst1
Fysisk drivenhet 2 = \\.\Tape0 or /dev/nst0
Kommandon till dessa enheter kan fortfarande fungera, förutsatt att det finns någon enhet som använder det önskade namnet. NetWorker förlorar kontakten med enhetsnamn eftersom bibliotekets drivrutinshandtagsassociationer inte längre matchar de fysiska elementen när operativsystemet byter namn på enheterna. NetWorker kan till exempel läsa in en bandkassett i en enhet men använda ett inaktuellt, felaktigt enhetsnamn och utfärda kommandon till fel enhet efter att operativsystemet har bytt namn. Detta kan resultera i en mängd olika fel, förutsatt att en oväntad volym (eller ingen alls) hittas. Det finns många möjliga orsaker till beställningsförhållanden för drivenheter:
- Manuell felkonfiguration av biblioteket med hjälp av
jbconfigellerjbeditKommandon - Omstart av värd, lagringsadapter, maskinvara för lagringsanslutning eller bandenheter
- Tillfällig förlust av anslutning till en enhet
- Inaktivera och återaktivera enheten i operativsystemet
- Uppdateringar av operativsystem
- Drivrutinsuppdateringar för enhet eller lagringsadapter
Upplösning
Beständig namngivning:
Detta anses vara bästa praxis och kan rekommenderas av supporten även om du inte har problem med att proaktivt skydda dig. Använd informationen i följande artiklar:
- Implementera programmotståndskraft för bandenhetsnamn för Windows
- Implementera programmotståndskraft för bandenhetsnamn för Linux
Ytterligare information
Manuell omkonfigurering
Om du inte omedelbart kan aktivera programmotståndskraft och konfigurera om biblioteket finns det flera manuella alternativ som kan övervägas:
- NMC-omkonfigurering: Du kan uppdatera NetWorker-konfigurationen med hjälp av alternativet Konfigurera om för biblioteksinstansen för att ta bort enhetsdefinitionerna för alla berörda enheter och sedan ta bort de överblivna bandenhetsinstanserna från enhetscontainern innan du genomsöker och konfigurerar om med de korrigerade, nya namnen.
jbconfigKommandot: Dessa kommandon är fortfarande en del av NetWorker-sviten, men används inte längre, och kräver mer avancerad kunskap om både NetWorker och tekniker för bandbibliotek och lagringstransport.- Om du vill börja om från början använder du
jbconfigFör manuell kontroll för att skapa bibliotek: Så här konfigurerar du ett NetWorker-bandbibliotek manuellt med kommandot jbconfig
- Om du vill börja om från början använder du
- Framtvingad namnändring: Det kan vara möjligt att inaktivera eller ta bort enheter och läsa/återaktivera dem i den ordning som motsvarar deras aktuella konfiguration i NetWorker. I ett enkelt Windows-scenario för ovanstående kan man till exempel inaktivera båda enheterna och återaktivera instansen som är konfigurerad som Tape0 i NetWorker först, för att tvinga operativsystemet att namnge enheten Tape0 en gång till. Linux-metoden skulle vara liknande, men med /proc/scsi/scsi-filen för att direkt ta bort och genomsöka enheter igen.