NetWorker: Troubleshooting von Problemen bei der Bestellung von Bandbibliothekslaufwerken

In einem Plug 'n Play-Betriebssystem werden Geräten SCSI-Zieladressen in der Reihenfolge der Erkennung zugewiesen.

Da die SAN-Erkennungsreihenfolge variiert und ein Verbindungsverlust eine Plug-and-Play-Neuzuordnung auslöst, ändern sich die Zielnummern und können nicht fixiert bleiben.

Plug-and-Play benennt Geräte basierend auf der Enumerationsreihenfolge um, sodass jede absichtliche oder versehentliche Verbindungsunterbrechung dazu führen kann, dass Geräten neue Namen zugewiesen werden.

Ein Problem bei der Laufwerksreihenfolge beschreibt eine Bedingung, bei der der von NetWorker konfigurierte Treibername für ein Gerät nicht mit dem tatsächlichen Namen übereinstimmt. Dies ist in den meisten Fällen darauf zurückzuführen, dass sich der Treibername im Betriebssystem nach der Erstkonfiguration der NetWorker-Bibliothek ändert. Dies ist in der Regel ein Plug 'n Play-Betriebssystemproblem, das Windows und Linux betrifft.

Es gibt viele Fehler und Bedingungen, die mit diesem Problem verbunden sind, einschließlich, aber nicht beschränkt auf:

• Error: 'nsrd: media info: failed unloading drive `{driver handle}' to slot {slot number}, error '69''
• Error: '{hostname} the destination component full'
• Error: '{driver handle} read open error, no such device or address'
• Error: 'opening: I/O error'
• Error: 'nsrd: Jukebox '{jukebox}' failed: expected volume '{volid}' got {volid}'
• Error: 'nsrd: Jukebox '{jukebox}' failed: expected volume '(volume_name)' got 'NULL''
• Error: 'read open error, device not ready'
• Error: 'nsrjb: Jukebox error, All allocated drives are not usable, unrecoverable operation errors'
• Error: 'nsrd: Jukebox '{jukebox}' failed: expected volume '{volid}' got {volid}'
• Error: 'nsrd: Jukebox '{jukebox}' failed: expected volume '{volume}' got 'NULL''
• Error: 'read open error, device not ready'
• Error: 'nsrjb: Jukebox error, All allocated drives are not usable, unrecoverable operation errors'
• Error: 'nsrd: media warning: {driver handle} reading: read open error: No media in drive.'
• Error: 'inventory: Bar code label `{barcode}' does not match media db bar code label, updating media db'
• Error: 'Illegal request, medium not present'
• Error: 'nsrd: media info: failed unloading drive `{driver handle}' to slot {slot number}'

NetWorker erstellt das Bibliotheksobjekt während der Ersteinrichtung und verknüpft Bandlaufwerke mit den vom Betriebssystem generierten Gerätehandles, die sie gerade haben. Es handelt sich um eine statische Zuordnung, die die Beziehung zum Zeitpunkt der Konfiguration widerspiegelt. Eine Bibliothek kann z. B. über zwei Geräte verfügen:
Physisches Laufwerk 1 = \\.\Tape0 (oder vielleicht /dev/nst0 unter Linux)
Physisches Laufwerk 2 = \\.\Tape1 (oder /dev/nst1)

In Plug & Play-Systemen wie Windows oder Linux kann jedes Verschwinden eines Geräts – einschließlich Neustarts oder Verbindungsänderungen – dazu führen, dass das Betriebssystem die Geräte umbenennt. Insbesondere bei einem SAN, bei dem die Geräteerkennung ungeordnet sein kann, können die Geräte beim nächsten Neustart anders benannt werden, z. B. im Gegensatz zu den oben genannten:
Physisches Laufwerk 1 = \\.\Tape1  or /dev/nst1
Physisches Laufwerk 2 =  \\.\Tape0  or /dev/nst0

Befehle an diese Geräte funktionieren möglicherweise weiterhin, vorausgesetzt, es gibt ein Gerät, das den gewünschten Namen verwendet. NetWorker verliert den Überblick über Gerätenamen, da die Treiber-Handle-Zuordnungen der Bibliothek nicht mehr mit den physischen Elementen übereinstimmen, nachdem das Betriebssystem die Geräte umbenannt hat. NetWorker kann z. B. eine Bandkassette in ein Laufwerk einlegen, aber einen veralteten, falschen Gerätenamen verwenden und nach der Umbenennung des Betriebssystems Befehle an das falsche Laufwerk ausgeben. Dies kann zu einer Vielzahl von Fehlern führen, vorausgesetzt, es wird ein unerwartetes Volume (oder gar keines) Volume gefunden. Es gibt viele mögliche Ursachen für Laufwerksreihenfolgebedingungen:

• Manuelle Fehlkonfiguration der Bibliothek mithilfe von jbconfig oder jbedit Befehle
• Neustart von Host, Storage-Adapter, Storage-Verbindungshardware oder Bandgeräten
• Vorübergehender Verlust der Verbindung zu einem Gerät
• Deaktivieren und erneutes Aktivieren des Geräts im Betriebssystem
• Betriebssystem-Updates
• Treiberupdates für Geräte oder Storage-Adapter

Dauerhafte Benennung:

Dies gilt als Best Practice und kann vom Support empfohlen werden, selbst wenn keine Probleme auftreten, um Sie proaktiv zu schützen. Nutzen Sie die Informationen aus den folgenden Artikeln:

• Implementieren der Anwendungsausfallsicherheit für Bandgerätenamen unter Windows
• Implementieren der Anwendungsstabilität für Bandgerätenamen für Linux

Manuelle Neukonfiguration
Wenn Sie die Anwendungsresilienz nicht sofort aktivieren und Ihre Bibliothek neu konfigurieren können, gibt es mehrere manuelle Alternativen, die in Betracht gezogen werden können:

1. NMC-Neukonfiguration: Sie können die NetWorker-Konfiguration aktualisieren, indem Sie die Option Reconfigure der Bibliotheksinstanz verwenden, um die Gerätedefinitionen für alle betroffenen Geräte zu entfernen, und dann die verbleibenden Bandgeräteinstanzen aus dem Container Geräte löschen, bevor Sie erneut scannen und mit den korrigierten, neuen Namen neu konfigurieren.

2. jbconfig -Befehl überprüfen, ob sie ausgeführt werden: Diese Befehle sind nach wie vor Teil der NetWorker-Suite, werden jedoch nicht mehr verwendet und erfordern erweiterte Kenntnisse in NetWorker sowie in Bandbibliotheken und Storage-Transporttechnologien.
   • Um von Grund auf neu zu beginnen, verwenden Sie jbconfig Für die Steuerung der manuellen Bibliothekserstellung: Anleitung zum manuellen Konfigurieren einer NetWorker-Bandbibliothek mit dem Befehl jbconfig
3. Erzwungene Umbenennung: Möglicherweise ist es möglich, Geräte zu deaktivieren oder zu löschen und sie in der Reihenfolge zu lesen/erneut zu aktivieren, die ihrer aktuellen Konfiguration in NetWorker entspricht. In einem einfachen Windows-Szenario für die oben genannten Szenarien könnten beispielsweise beide Geräte deaktiviert werden, indem zuerst die als Tape0 konfigurierte Instanz in NetWorker erneut aktiviert wird, um das Betriebssystem zu zwingen, dieses Gerät erneut Tape0 zu nennen. Die Linux-Methodik wäre ähnlich, aber die Verwendung der Datei /proc/scsi/scsi zum direkten Löschen und erneuten Scannen von Geräten.