故障診斷 NetWorker 中的磁帶庫組態問題
Summary: 本文旨在幫助支援者和客戶確定檢測到的機器人無法成功配置的原因。
Symptoms
如果磁帶庫組態之前可正常運作,但突然遇到問題,請考慮可能會妨礙偵測和組態的變更:
- 升級機器人或磁帶裝置的韌體或驅動程式
- 新增、更換或移除磁帶硬體或其他磁帶庫元件
- 變更 NetWorker 軟體版本或作業系統修補程式
- 主機和機器人之間儲存傳輸的任何變更
如果程式庫從未運作過,請在 NetWorker 硬體相容性指南中確認硬體是否受支援。請記住,庫可能部分功能正常;僅探索並不能保證可用性或支援性。
- 使用 NetWorker 管理主控台偵測和設定自動儲存塔失敗
- 使用 jbconfig 偵測和設定自動儲存塔失敗
- 使用 jbedit 修改自動儲存塔配置失敗
- NetWorker 磁帶庫的偵測和組態包括兩個使用者階段:
- 裝置偵測、屬性枚舉和建立「未設定」屬性
- NSR 自動儲存塔和 NSR 裝置磁帶機物件的建立與關聯
- 若設定磁帶庫並非源自於偵測或存取問題,通常會導致偵測到的磁帶庫或磁碟機資源不一致:
- 驅動器序列號(在驅動器中檢測到或緩存在機器人中)
- 已使用相同驅動程式句柄設定的衝突裝置
- 特定的內部 SCSI 命令回應問題
- 機器人資訊和物理現實不一致
- 使用 jbconfig 自動設定僅限於執行命令的本機主機,且仍需要序列號偵測和檔案句柄符合
- jbconfig(選項 4)是一種手動方法,用於在不支援這些功能或出現問題的情況下嘗試覆蓋自動檢測
- Jbedit 是一個命令行工具,可用於編輯現有庫配置
Cause
磁帶庫組態問題的已知原因:
- 如何卸下未設定的裝置 (橘色扳手) (檢視本文需要使用 Dell 支援帳戶)
考慮可能影響 NetWorker 設定磁帶庫能力的因素或因素:
- 無法偵測和正確存取機器人或磁帶資源
- 機器人驅動程式、韌體或問題導致內部機器人資訊不一致
- 分區等機器人功能可能會混淆資源可用性或識別
- 動態全球命名,刻意遮蔽磁碟機 WWN 和 SN
- 衝突、預先存在的 NetWorker 組態資料庫資源
- 變更軟體版本後的程式碼瑕疵
Resolution
為了對庫配置問題進行故障排除,在考慮最後的已知更改(如果有)之後,通過將進程下放到其原始成分並單獨測試它們來繼續進行故障排除。
使用 -o:d 鍵執行時 ,NSRGet 目前會收集所有必要的資料。NetWorker:如何使用 NSRGet NetWorker 資料收集工具
磁帶庫組態:預備動作
- 命名持久性:為了確保磁帶庫配置仍然有效,存取驅動器的主機必須確保設備名稱持久綁定且不變 - 這可以防止將來出現驅動器排序問題的可能性(請參閱 NetWorker 中的磁帶庫驅動器排序問題)
- 若為 Windows,請參閱:實作 Windows 的磁帶裝置名稱持久性 (需要有 Dell 支援帳戶才能檢視此文章)
- 若為 Linux,請參閱:為 Linux 實作磁帶裝置名稱持久性 (需要有 Dell 支援帳戶才能檢視此文章)
- 裝置資源清理:在 「設備 」部分中,確保刪除所有將配置為庫驅動器的獨立磁帶設備
- 掃描裝置:在 「設備 」部分中,右鍵按下 「存儲節點 」容器,選擇 「掃描設備」,然後選擇要掃描 的所有節點 。
磁帶庫組態:元件
- 磁碟機屬性:NetWorker 需要裝置的多條資訊,才能在 NSR 自動儲存塔組態物件中建立其關聯:序列號和設備句柄。您可以使用下列命令手動取得:
cdi_inq -f <tape drive driver handle> -v inquire -lc
如果 inquire 和 cdi_inq 命令之間的序號不相符,這通常是動態全球命名的證據。 - 機器人特性:由於驅動器和機器人在其操作中在邏輯上是分開的,因此為了將磁帶裝載操作與設備讀/寫操作協調,機器人必須將驅動器的序列號與機器人的相應元素位址相關聯。若要取得這些配對:
sjisn <i.t.l or changer driver handle>
- NSR 儲存節點:如果在管理主控台使用者介面的 NetWorker 中設定程式庫,裝置偵測程序會將任何探索到的磁碟機或機器人新增至儲存節點資源,做為「未設定」的裝置 (使用者介面中的橘色扳手圖示)。由於它們不是不同的資源,因此無法刪除它們,並且將在配置過程後替換為可用資源。
nsrdb (可在 NetWorker 執行時壓縮資料夾)dvdetect -dlv -D9
(針對 UI 偵測問題進行故障診斷時) - NSR 自動儲存塔:選擇“未配置”庫並在使用者介面中運行“配置”後,NSR 點唱機將使用上述關聯構建:元素:序列號:設備句柄,以及從機器人收集的其他庫數據,例如插槽、墨盒和 I/E 埠位移。
nsrdb:此資料夾可在 NetWorker 執行時壓縮nsrjb:提供更簡單、人類可讀的程式庫設定版本jbconfig:可用於手動設定自動儲存塔jbedit:提供更簡單、人類可讀的程式庫設定版本
磁帶庫組態:抑製劑
以下是在先前確認偵測和存取後,可嘗試的幾個基本測試:
- 故障診斷 NetWorker 中的磁帶庫偵測問題 (需要有 Dell 支援帳戶才能檢視本文)
- 故障診斷 NetWorker 中的磁帶庫存取問題 (需要有 Dell 支援帳戶才能檢視本文)
- 檢查或刪除 NSR 儲存節點:資源中有多個屬性可能會阻止正確檢測和配置自動儲存塔,例如:
- 任何取消設定或欄位清單
- 略過 scsi 目標欄位
- 任何名稱或註冊欄位
您可以透過關閉 NetWorker,並在命令列連線至資源資料庫,安全地刪除 NSR 儲存節點資源。請務必先備份資源資料庫,方法是建立引導備份和建立 nsrdb 資料夾的 tar/.zip 檔案
cd <nsr/res directory> nsradmin -d nsrdb del type: nsr storage node (and answer yes to the storage node in question)
手動檢查 cdi_inq/查詢/sjisn/sjirjc 資源。由於磁帶庫的自動設定需要協調來自驅動器和機器人的數據,並交叉驗證其中一些值,請檢查輸出中的任何位置是否出現異常:
sjirjc <changer address>
確認應有磁碟機數量、匯入/匯出元素數量和插槽數量。
sjisn <changer address>
比較驅動器總數以查詢,sjirdtag和sjirjc總計;比較序列號和型號字串以查詢輸出。
sjirdtag <changer address>
將驅動器和插槽總數與其他輸出進行比較;尋找磁碟機的 pres_val=0 以指出問題。
cdi_inq -f <changer driver handle> -v
比較序列號和型號字串以查詢和輸出。
如果偵測不到序號,或是序列字串或磁碟機計數不相符,組態將會失敗。
- 硬體、韌體或 NetWorker 程式碼問題:如果任何裝置的報告或處理這些問題的程式碼中存在較低層級的問題,您可以使用下列環境變數啟用除錯,然後重新執行上述命令 (或 NSRGet -o:d) 以檢查線索或準備上報:
SJI_DEBUG=9 LUS_DEBUG=9 CDI_DEBUG=9 JBDEBUG=9 SCSI_DEBUG=9
程式庫組態 - jbconfig (自動)
- 如果無法使用常規 UI 機制檢測到庫,請嘗試使用命令 jbconfig - 這可能在半下放級別運行,但仍提供與 UI 幾乎相同的結果(並提供命名庫的功能,這在常規 UI 配置中不存在)。
- 在 jbconfig 對話框中選擇選項 2 以測試自動檢測和配置;系統會提示您處理任何共用設備或 NDMP 設備 - 遠端主機和 NDMP 不會自動處理,您必須使用 sjis 和查詢輸出來提供每個元素的主機/句柄配對。
磁帶庫組態 - jbconfig (手動)
- 如果 jbconfig 在選項 2 中失敗 - 您可以使用選項 4 重試,如果庫類型未出現在清單中,只需使用 #54(標準 SCSI 自動儲存塔)。這個選項需要手動輸入所有參數:
- 在機器人控制主機上查詢返回的庫SCSI位址或驅動檔句柄
- 每個主機:磁碟機元素配對的驅動程式句柄,根據機器人-本地 sjisn 輸出,與從每個儲存節點共用驅動器收集的查詢輸出進行比較
- 在自動儲存塔中設定的驅動器型號
- 如果 sjisn 和查詢輸出未顯示序列號,則機器人或驅動器可能不支援序列號;在這種情況下,剩下的唯一選項是清空庫,手動將單個磁帶連續移動到每個驅動器,並運行 MT-F <設備句柄> 狀態,直到為每個主機找到該驅動器元素的正確本地句柄。這在現代硬體中是罕見且出乎意料的。
如果上述建議都沒有説明,如果從調試中收集的證據表明存在任何內部異常,請根據您的操作系統或庫供應商尋求支援;否則,請在嘗試組態時收集偵錯輸出,並在 NetWorker 支援中呈報結果,以追蹤程式碼瑕疵的可能性。