对 NetWorker 中的磁带库配置问题进行故障处理
Summary: 本文旨在帮助支持者和客户确定检测到的机器人无法成功配置的原因。
Symptoms
如果库配置以前正常工作,没有出现问题,并且突然遇到问题,请考虑可能妨碍检测和配置的更改:
- 升级机器人或磁带设备的固件或驱动程序
- 添加、更换或移除磁带硬件或其他库组件
- 更改 NetWorker 软件版本或作系统修补程序
- 对主机和机器人之间的存储传输的任何更改
如果库从未正常工作过,请在 NetWorker 硬件兼容性指南中确认硬件受支持。请记住,库可以部分正常工作;仅发现并不能保证可用性或可支持性。
- 使用 NetWorker Management Console 检测和配置自动存储塔失败
- 使用 jbconfig 检测和配置自动存储塔失败
- 使用 jbedit 修改自动存储塔配置失败
- NetWorker 磁带库的检测和配置包含两个用户阶段:
- 设备检测、属性枚举和“未配置”属性的创建
- 创建和关联 NSR 自动存储塔和 NSR 设备磁带机对象
- 不是由检测或访问问题引起的磁带库配置问题通常指向检测到的磁带库或驱动器资源不一致:
- 驱动器序列号(在驱动器中检测到或在机器人中缓存)
- 已使用相同驱动程序句柄配置的冲突设备
- 特定的内部 SCSI 命令响应问题
- 机器人信息与物理现实不一致
- 使用 jbconfig 的自动配置仅限于运行命令的本地主机,并且仍然需要序列号检测和文件句柄匹配
- jbconfig(选项 4)是一种手动方法,用于尝试覆盖不支持这些功能或有问题的自动检测
- jbedit 是一个命令行工具,可用于编辑现有的库配置
Cause
库配置问题的已知原因:
- 如何卸下未配置的设备(橙色扳手)( 需要戴尔支持帐户才能查看本文)
考虑可能影响 NetWorker 配置磁带库能力的元素或因素:
- 无法检测并正确访问机器人或磁带资源
- 机器人驱动程序、固件或导致内部机器人信息不一致的问题
- 机器人功能(如分区),这可能会混淆资源可用性或识别
- 动态全球命名,有意屏蔽驱动器 WWN 和 SN
- 冲突的、预先存在的 NetWorker 配置数据库资源
- 更改软件版本后的代码缺陷
Resolution
要对磁带库配置问题进行故障处理,在考虑上次已知更改(如果有)之后,继续将该过程下放到其基元成分并单独进行测试来进行故障处理。
使用 -o:d 开关运行时, NSRGet 当前会收集所有必需的数据。NetWorker:如何使用 NSRGet NetWorker 数据收集工具(英文版)
库配置:准备
- 命名持久性:为了确保库配置保持有效,访问驱动器的主机必须确保设备名称永久绑定且保持不变 - 这可以防止将来出现驱动器排序问题(请参阅 NetWorker 中的磁带库驱动器排序问题故障处理)
- 对于 Windows,请参阅:为 Windows 实施磁带设备名称持久性 (需要戴尔支持帐户才能查看本文)
- 对于 Linux,请参阅:为 Linux 实施磁带设备名称持久性 (需要戴尔支持帐户才能查看本文)
- 设备资源清理:在 Devices 部分中,确保删除将配置为库驱动器的所有独立磁带设备
- 扫描设备:在 设备 部分中,右键单击 存储节点 容器,选择 扫描设备,然后选择要扫描 的所有节点 。
库配置:组件
- 驱动器属性: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 中的磁带库检测问题进行故障处理 (需要戴尔支持帐户才能查看本文)
- 对 NetWorker 中的磁带库访问问题进行故障处理 (需要戴尔支持帐户才能查看本文)
- 检查或删除 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/inquire/sjisn/sjirjc 资源。由于磁带库的自动配置需要协调来自驱动器和机器人的数据,并交叉验证其中的一些值,请检查输出中是否出现异常:
sjirjc <changer address>
确认预期的驱动器数量、导入/导出元素数量和插槽数量。
sjisn <changer address>
将驱动器总数与 inquire、sjirdtag 和 sjirjc 总数进行比较;比较序列号和型号字符串以查询输出。
sjirdtag <changer address>
将驱动器和插槽总数与其他输出进行比较;查找驱动器的 pres_val=0 以指示问题。
cdi_inq -f <changer driver handle> -v
比较序列号和型号字符串,以查询和 sjisn 输出。
如果无法检测到序列号,或者序列字符串或驱动器计数不匹配,则配置将失败。
- 硬件、固件或 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,您必须使用 sjisn 和 inquire 输出来提供每个元素的主机/句柄配对。
Library configuration - jbconfig (手动)
- 如果使用选项 2 时 jbconfig 失败 - 您可以使用选项 4 重试,并且如果库类型未出现在列表中,则只需使用 #54(标准 SCSI 自动存储塔)。此选项需要手动输入所有参数:
- 库 SCSI 地址或驱动程序文件句柄,通过在机器人控制主机上查询返回
- 每个主机:驱动器元素配对的驱动程序句柄,根据机器人本地 sjisn 输出,与从共享驱动器的每个存储节点收集的查询输出进行比较
- 自动存储塔中配置的驱动器型号
- 如果 sjisn 和 inquire 输出未显示序列号,则机器人或驱动器可能不支持序列号;在这种情况下,剩下的唯一选项是清空库,手动将单个磁带盒连续移动到每个驱动器,然后运行 MT -f <device handle> status,直到找到该驱动器元素的每个主机的正确本地句柄。这在现代硬件中是罕见且出乎意料的。
如果上述建议均无济于事,则在从调试收集的证据表明存在任何内部异常的情况下,请与您的作系统或库供应商联系适当的支持;否则,在尝试配置时收集调试输出,并在 NetWorker 支持中上报结果,以检查代码缺陷的可能性。