干存储运维的迟早会碰到磁带库换驱动器。尤其TS4500这种大型企业级磁带库驱动器坏了要换换完重启TSM里却冒出来一个“查得到、用不了、删不干净”的驱动器——这就是大家常说的“幽灵设备”。不夸张地说这个坑我在生产环境踩过不止一次后来把整套更换流程梳理清楚之后才彻底告别“换一个驱动器熬一个通宵”的局面。这篇指南我会从TSM怎么看待磁带驱动器的底层逻辑讲起把更换TS4500驱动器的完整操作一步步拆开重点说明为什么换完硬件后TSM会残留“幽灵设备”以及在哪个环节做什么动作能避免它。适合正在维护TSM现在叫IBM Spectrum Protect和TS4500磁带库的备份管理员、存储运维工程师参考也适合第一次接触磁带库更换操作的同事先读一遍再动手。1. 为什么磁带库换驱动器会留下“幽灵设备”1.1 TSM里的驱动器到底是什么在理解“幽灵设备”之前先要掰扯清楚TSM眼中的磁带驱动器长什么样。TSM管理磁带库时并不会实时去物理扫描每一个硬件它是在自己数据库里维护了一张“设备表”。这张表里记录了库的序列号、驱动器逻辑名、element地址、控制路径、数据路径等信息。磁带库里的物理驱动器插在不同槽位每个槽位都对应一个element address元素地址。比如TS4500控制面板上能看到驱动器安装的物理插槽号以及对应的element地址常见的是256、257……这类数值具体以库面板显示为准。TSM就是通过这个element地址再配合SCSI Media Changer介质转换器简称SMC设备去找到真正的物理驱动器。所以磁带驱动器的“身份”在TSM里等于库名 驱动器名 element地址 设备路径。任何一个环节和物理环境对不上就会出问题。这也是“幽灵设备”的根源——TSM数据库里的身份信息发生了“失真”。1.2 “幽灵设备”是怎么形成的你可能会想不就是换一块硬件吗旧驱动器拔出来新驱动器插进去库自己能识别TSM重新扫一下不就行了实际没那么简单。“幽灵设备”高发的典型场景是操作人员直接从TS4500机架上拔掉旧驱动器装上备件没有在TSM里先删除原来的驱动器定义。新驱动器安装到了和旧驱动器不同的物理插槽比如旧的插在3号位新的插到了5号位。更换后在TSM里不去做路径清理只重新扫库或直接checklib。结果就是TSM数据库里仍然记录着旧的element地址和旧的设备路径。当TSM再按照这份“过期地图”去找驱动器时要么找到的是完全陌生的硬件要么干脆找不到设备状态变成Unavailable、Recovering这类卡死状态。更麻烦的是就算你在TSM里想删掉这条记录系统也会提示“驱动器正在使用中”或“路径依赖无法删除”删不掉、改不了、用不了——这就是备份圈里俗称的“幽灵设备”。我把一次真实翻车现场简单描述一下某台TS4500分两个库分区其中一个分区里的LTO8驱动器报错同事直接换了备件槽位从5挪到6。换完在TSM里做checklib结果任务一直卡在“Library scan in progress”后来用q drive查旧驱动器显示Available但一到挂载就报错同时多了一条“幽灵”的下降路径。最后只能停机维护手动清定义折腾了一整晚。所以这个问题的核心结论是TSM不是即插即用的系统它的设备信息是“定义”出来的不是“发现”出来的。谁跳过了“先删后加”的流程谁就等于亲手埋雷。2. 更换驱动器前的准备工作2.1 先摸清TSM里的“设备档案”动手换硬件前最重要的一步永远是“盘点现状”。很多工程师拿到备件就直接冲进机房这是大忌。在机房现场你需要拿到的信息包括待更换的驱动器在TSM里的逻辑名例如DRIVE1、LTO8_01这台驱动器对应的物理槽位和element地址它在TSM里的path定义依赖的是哪个系统设备文件例如AIX下是/dev/rmt5、/dev/smc0Linux下可能是/dev/st4和/dev/sg8它绑定的存储池、脚本任务、 scheduled backup 有没有正在使用这台驱动器。可以通过TSM命令行快速盘点dsmadmc -idadmin -password*** -dataonlyyes q drive dsmadmc -idadmin -password*** -dataonlyyes q pathq drive会列出这个库里所有驱动器的名称和状态q path能看到服务器到库和服务器到驱动器的路径关系。两条命令都要看因为一个驱动器要正常工作必须同时具备“库路径”和“驱动器路径”。另外一个实用做法把TS4500控制面板或者登录TS4500的Web管理界面打开进入“驱动器状态”页面截图或拍照记录每个槽位上驱动器的型号、序列号、固件版本和element地址。这样换完硬件之后就有原始资料可以对比新驱动器是否被正常识别。2.2 维护窗口和配置备份不能省磁带库驱动器更换不是“顺手”能干的活它直接影响备份任务的可用性所以维护窗口一定要正式申请建议至少预留2到4小时。特别要提醒的是有些环境里TSM和数据库应用还有联动关系比如备份策略、副本策略、归档任务等停机前最好把TSM的调度器暂停掉。配置备份这一步经常被忽略但它才是容错的关键。TSM里执行以下命令把当前设备定义和路径配置导出dsmadmc -idadmin -password*** -dataonlyyes -outfile/backup/tsm_devices_before_change.txt q drive fd dsmadmc -idadmin -password*** -dataonlyyes -outfile/backup/tsm_paths_before_change.txt q path fd再从系统层面确认一下磁带设备文件清单。比如AIX环境下lsdev -Cc tape lsdev -Cc smcLinux下常用lsscsi -g这些输出建议一并保存。万一后续定义路径时发现设备文件对不上至少还能通过“更换前的快照”判断是不是系统扫描出了问题。3. 正确的驱动器更换流程3.1 先在TSM中把旧驱动器“摘干净”我个人的经验是如果驱动器已经处于故障状态但TSM还认着它那么第一步是尝试让它正常下线# 先把库设为维护模式或暂停使用该驱动器的存储池 disable drive 库名 驱动器名 update drive 库名 驱动器名 onlineno然后删除对应路径和驱动器定义。注意先后顺序先删路径再删驱动器。TSM中路径是驱动器的依赖对象直接删驱动器通常会被拒绝。delete path TSM服务器名 驱动器名 srctypeserver desttypedrive library库名 delete drive 库名 驱动器名如果系统提示“驱动器仍在运行/使用中”可以用q mount看看有没有活动挂载有就等任务结束或手动卸带再执行上面的删除。删除成功后q drive里应该看不到这台驱动器的名字了。这一步等于把TSM数据库里的“过期身份信息”彻底除掉。后续物理换的新驱动器对TSM来说就是一张白纸从零定义就好自然不会产生身份错乱。3.2 物理更换的操作顺序和细节TS4500的驱动器模块支持热插拔但生产环境建议先把该驱动器的活动任务排空再妥善操作。具体物理更换流程大致如下准备好防静电手环、螺丝刀、新驱动器注意型号和固件版本。在TS4500控制面板或Web界面中确认待更换驱动器状态做好标记。如果是带线缆的驱动器先拔掉SAS/FC光纤线再拔电源线如果是模块化抽取式按照机架导轨操作慢慢抽出。插入新驱动器插到位后固定锁扣。接好线缆注意线序最好和旧驱动器保持一致否则库内线路管理会乱。等待TS4500重新扫描并识别新驱动器面板上状态通常会从Empty变成Ready或Online。记录新驱动器的物理插槽号、element地址、序列号、固件版本。这里有个特别容易踩的坑很多人换完驱动器之后线缆接的是新的口但系统层面和TSM层面并不知道。所以必须确保服务器端识别到的设备文件和库控路径对应的是同一个物理驱动器。如果线缆顺序错了新驱动器的设备文件可能对应的是另一个槽位后面定义路径时就会张冠李戴。3.3 让TSM重新认识新驱动器物理更换完成、TS4500面板状态正常后回到TSM操作。首先确认服务器端已经能看到新设备AIX下执行cfgmgr lsdev -Cc tape lsdev -Cc smcLinux下根据实际环境可以通过重新扫描SCSI总线或重启服务器主机总线适配器HBA驱动来发现。看到新的/dev/stX或/dev/rmtX设备文件后再回到TSM。如果TS4500有多个驱动器、库里有多个分区建议先做一次库内容同步checklib 库名 checklabelno接着定义新驱动器。element地址一定要和TS4500面板上显示的一致define drive 库名 新驱动器名 element面板上看到的element地址然后定义服务器到驱动器的路径define path TSM服务器名 新驱动器名 srctypeserver desttypedrive library库名 device/dev/rmtX如果库路径/dev/smc0之前也被删过还需要重新定义库路径define path TSM服务器名 库名 srctypeserver desttypelibrary library库名 device/dev/smc0最后验证一下新驱动器是否正常audit library 库名 checklabelno q drive fd做完audit libraryTSM会再次核对库内状态。如果驱动器状态显示Available路径是Online那基本就稳了。这时候建议再跑一个手工的backup/restore小任务实际用一次新驱动器确认读写正常再收工。4. 如何避免“幽灵设备”卷土重来4.1 把“先删后加”固化到维护流程里回头看所有“幽灵设备”案例本质上都是制造了“信息差”TSM的数据库和物理硬件不一致。要根治就需要把“先删后加”变成铁律而不是凭操作者临场发挥。我建议把整个更换流程做成一个Checklist每次执行都逐项打钩阶段动作是否完成更换前暂停TSM调度、备份配置和q drive/q path快照是/否更换前TSM中删除路径、删除驱动器定义是/否更换中记录旧驱动器物理槽位、element地址选择同型号备件是/否更换后TS4500面板确认新驱动器状态Ready并记录新element地址是/否更换后系统层确认新设备文件是/否更换后TSM中define drive、define path、audit library是/否验证手工备份任务读写测试是/否这条清单可以打印出来贴在机房也可以放到运维知识库每次做变更之前先过一遍。特别是在备件到场、多人协同操作时分工会更明确不会出现“A拔了设备B以为定义已经删了”这种乌龙。4.2 出现“幽灵设备”后的清理思路如果真的没有遵照流程已经出现“幽灵设备”也不要慌按照依赖关系倒着清理通常能解掉。所谓“幽灵设备”在TSM中无非表现为三种形态驱动器和路径都在但驱动器的element地址对应的物理槽位已经不是原来的设备路径状态异常比如path显示Unavailable或Offline驱动器定义残留但又无法直接删除。清理顺序建议是先处理路径再处理驱动器定义。如果路径被别的依赖占用可以尝试先把库设为维护模式再用update path把设备文件指向正确的新设备。如果确认物理上已经不存在这个驱动器但TSM还在用则先delete path再delete drive。遇到删不掉的情况多半是存在未释放的挂载或调度任务用q mount和q session查一下必要时停掉TSM调度器再清理。这里有个比较隐蔽的小坑如果TS4500做了库分区某一个分区出问题可能会连带另一个分区的路径。清理时建议一次只处理一个库分区避免影响正常业务的备份任务。还有一个进阶建议在TSM服务器上配置设备状态告警对驱动器的q drive状态变化做监控。一旦发现驱动器变为Unavailable或Recovering第一时间告警避免故障驱动器长时间被“冷冻”在系统里。监控工具可以是简单的Shell脚本 dsmadmc定时查询也可以在现有监控平台里加一个自定义脚本。5. 常见问题与排查技巧实录5.1 换完驱动器后TSM里查不到新设备这个现象通常不是TSM的问题而是服务器系统层面没有正确更新设备。检查顺序先看TS4500面板确认新驱动器已经被库识别、状态是Ready再看服务器端lsdev -Cc tapeAIX或lsscsi -gLinux确认对应设备文件存在如果系统里没有执行AIX的cfgmgr或Linux的SCSI扫描命令也可以检查HBA卡的线缆连接和交换机Zone配置如果系统层有设备文件再到TSM里做checklib。实际遇到过的情况是新驱动器的FC线接到了另一个HBA口导致AIX上看到的是一个全新的rmt设备而TSM里定义路径使用的还是旧设备名。此时需要用update path把设备文件改成新的rmt号或者干脆删掉新定义重新定义一遍。5.2 驱动器显示Unavailable或Recovering换驱动器后TSM里驱动器状态卡在Unavailable或Recovering是“幽灵设备”最常见的状态。排查时先从物理层排除TS4500面板上驱动器状态是否正常服务器端到驱动器的连接是否正常线缆有没有插牢SMC控制路径是否正常q path里库路径是不是Online。如果物理层没问题再检查TSM里的element地址。尤其是新驱动器和旧驱动器的插槽位置不一致时必须在define drive时使用新的element地址。很多Unavailable状态其实就源于element地址和物理槽位对应不上。还有一种情况audit library之后TSM自动发现了一个“额外”的驱动器但没自动定义路径。这时候只要补定义路径就能解决不要贸然去删除。5.3 系统设备文件不更新路径指到旧设备AIX环境尤其容易遇到这种情况。更换驱动器后旧设备文件不会自动消失新设备可能需要cfgmgr之后才出现。如果两个驱动器的WWPN完全相同但序列号不同AIX可能仍用原来的rmt设备名指向新驱动器但底层SCSI信息已经变了导致报错。排查方法是重新扫描后对比新旧设备文件的序列号lsdev -Cc tape -long cat /proc/scsi/scsi # Linux环境确认设备文件对应关系。如果发现路径指向错误继续用update path调整TSM里的设备名或者干脆在系统里删除多余设备后重新扫描。经常有人问能否把系统层不用的rmt设备删掉。AIX下可以用rmdev -dl rmt5但要注意如果这个设备被TSM路径占用先把TSM路径删掉或更新掉再删系统设备。顺序反了会导致rmdev报错“Device Busy”。5.4 驱动器更换后的固件版本检查最后聊一个容易忽略的细节TS4500里的驱动器固件版本最好与库控制器固件、TSM支持的版本保持兼容。换备件的时候如果拿到的是一个旧固件版本的驱动器TS4500可能识别正常但挂载、读写时会出现奇怪问题。在TS4500的Web管理界面可以查看每个驱动器的固件版本并执行在线升级。建议更换后检查一下固件如果明显落后于库内其他同型号驱动器优先升级到一致版本再纳入TSM生产使用。我个人的习惯是备件到货后先在测试环境把固件刷到和现场一致再拿去机房更换。这样可以缩短现场维护窗口时间也能避免因固件不兼容导致的“换了等于没换”尴尬局面。写在最后的一点经验磁带库驱动器更换这件事技术难度不算高真正考验人的是对设备关系的理解和对流程的执行力。我踩过几次坑之后最大的体会就是凡是涉及TSM和磁带库的变更永远把“数据库定义”当成和“物理硬件”同等重要的对象来对待先删后加、先查后改、核对element地址这三条做到位几乎可以避开所有“幽灵设备”问题。如果你所在的团队经常要换TS4500驱动器我强烈建议把上面那张Checklist贴到值班室的墙上或者直接做成运维工单模板。前几次换驱动器的时候每一步都截图留底后面做复盘和知识库沉淀时就能省很多事。
TS4500磁带库驱动器更换指南：从根源杜绝TSM幽灵设备
干存储运维的迟早会碰到磁带库换驱动器。尤其TS4500这种大型企业级磁带库驱动器坏了要换换完重启TSM里却冒出来一个“查得到、用不了、删不干净”的驱动器——这就是大家常说的“幽灵设备”。不夸张地说这个坑我在生产环境踩过不止一次后来把整套更换流程梳理清楚之后才彻底告别“换一个驱动器熬一个通宵”的局面。这篇指南我会从TSM怎么看待磁带驱动器的底层逻辑讲起把更换TS4500驱动器的完整操作一步步拆开重点说明为什么换完硬件后TSM会残留“幽灵设备”以及在哪个环节做什么动作能避免它。适合正在维护TSM现在叫IBM Spectrum Protect和TS4500磁带库的备份管理员、存储运维工程师参考也适合第一次接触磁带库更换操作的同事先读一遍再动手。1. 为什么磁带库换驱动器会留下“幽灵设备”1.1 TSM里的驱动器到底是什么在理解“幽灵设备”之前先要掰扯清楚TSM眼中的磁带驱动器长什么样。TSM管理磁带库时并不会实时去物理扫描每一个硬件它是在自己数据库里维护了一张“设备表”。这张表里记录了库的序列号、驱动器逻辑名、element地址、控制路径、数据路径等信息。磁带库里的物理驱动器插在不同槽位每个槽位都对应一个element address元素地址。比如TS4500控制面板上能看到驱动器安装的物理插槽号以及对应的element地址常见的是256、257……这类数值具体以库面板显示为准。TSM就是通过这个element地址再配合SCSI Media Changer介质转换器简称SMC设备去找到真正的物理驱动器。所以磁带驱动器的“身份”在TSM里等于库名 驱动器名 element地址 设备路径。任何一个环节和物理环境对不上就会出问题。这也是“幽灵设备”的根源——TSM数据库里的身份信息发生了“失真”。1.2 “幽灵设备”是怎么形成的你可能会想不就是换一块硬件吗旧驱动器拔出来新驱动器插进去库自己能识别TSM重新扫一下不就行了实际没那么简单。“幽灵设备”高发的典型场景是操作人员直接从TS4500机架上拔掉旧驱动器装上备件没有在TSM里先删除原来的驱动器定义。新驱动器安装到了和旧驱动器不同的物理插槽比如旧的插在3号位新的插到了5号位。更换后在TSM里不去做路径清理只重新扫库或直接checklib。结果就是TSM数据库里仍然记录着旧的element地址和旧的设备路径。当TSM再按照这份“过期地图”去找驱动器时要么找到的是完全陌生的硬件要么干脆找不到设备状态变成Unavailable、Recovering这类卡死状态。更麻烦的是就算你在TSM里想删掉这条记录系统也会提示“驱动器正在使用中”或“路径依赖无法删除”删不掉、改不了、用不了——这就是备份圈里俗称的“幽灵设备”。我把一次真实翻车现场简单描述一下某台TS4500分两个库分区其中一个分区里的LTO8驱动器报错同事直接换了备件槽位从5挪到6。换完在TSM里做checklib结果任务一直卡在“Library scan in progress”后来用q drive查旧驱动器显示Available但一到挂载就报错同时多了一条“幽灵”的下降路径。最后只能停机维护手动清定义折腾了一整晚。所以这个问题的核心结论是TSM不是即插即用的系统它的设备信息是“定义”出来的不是“发现”出来的。谁跳过了“先删后加”的流程谁就等于亲手埋雷。2. 更换驱动器前的准备工作2.1 先摸清TSM里的“设备档案”动手换硬件前最重要的一步永远是“盘点现状”。很多工程师拿到备件就直接冲进机房这是大忌。在机房现场你需要拿到的信息包括待更换的驱动器在TSM里的逻辑名例如DRIVE1、LTO8_01这台驱动器对应的物理槽位和element地址它在TSM里的path定义依赖的是哪个系统设备文件例如AIX下是/dev/rmt5、/dev/smc0Linux下可能是/dev/st4和/dev/sg8它绑定的存储池、脚本任务、 scheduled backup 有没有正在使用这台驱动器。可以通过TSM命令行快速盘点dsmadmc -idadmin -password*** -dataonlyyes q drive dsmadmc -idadmin -password*** -dataonlyyes q pathq drive会列出这个库里所有驱动器的名称和状态q path能看到服务器到库和服务器到驱动器的路径关系。两条命令都要看因为一个驱动器要正常工作必须同时具备“库路径”和“驱动器路径”。另外一个实用做法把TS4500控制面板或者登录TS4500的Web管理界面打开进入“驱动器状态”页面截图或拍照记录每个槽位上驱动器的型号、序列号、固件版本和element地址。这样换完硬件之后就有原始资料可以对比新驱动器是否被正常识别。2.2 维护窗口和配置备份不能省磁带库驱动器更换不是“顺手”能干的活它直接影响备份任务的可用性所以维护窗口一定要正式申请建议至少预留2到4小时。特别要提醒的是有些环境里TSM和数据库应用还有联动关系比如备份策略、副本策略、归档任务等停机前最好把TSM的调度器暂停掉。配置备份这一步经常被忽略但它才是容错的关键。TSM里执行以下命令把当前设备定义和路径配置导出dsmadmc -idadmin -password*** -dataonlyyes -outfile/backup/tsm_devices_before_change.txt q drive fd dsmadmc -idadmin -password*** -dataonlyyes -outfile/backup/tsm_paths_before_change.txt q path fd再从系统层面确认一下磁带设备文件清单。比如AIX环境下lsdev -Cc tape lsdev -Cc smcLinux下常用lsscsi -g这些输出建议一并保存。万一后续定义路径时发现设备文件对不上至少还能通过“更换前的快照”判断是不是系统扫描出了问题。3. 正确的驱动器更换流程3.1 先在TSM中把旧驱动器“摘干净”我个人的经验是如果驱动器已经处于故障状态但TSM还认着它那么第一步是尝试让它正常下线# 先把库设为维护模式或暂停使用该驱动器的存储池 disable drive 库名 驱动器名 update drive 库名 驱动器名 onlineno然后删除对应路径和驱动器定义。注意先后顺序先删路径再删驱动器。TSM中路径是驱动器的依赖对象直接删驱动器通常会被拒绝。delete path TSM服务器名 驱动器名 srctypeserver desttypedrive library库名 delete drive 库名 驱动器名如果系统提示“驱动器仍在运行/使用中”可以用q mount看看有没有活动挂载有就等任务结束或手动卸带再执行上面的删除。删除成功后q drive里应该看不到这台驱动器的名字了。这一步等于把TSM数据库里的“过期身份信息”彻底除掉。后续物理换的新驱动器对TSM来说就是一张白纸从零定义就好自然不会产生身份错乱。3.2 物理更换的操作顺序和细节TS4500的驱动器模块支持热插拔但生产环境建议先把该驱动器的活动任务排空再妥善操作。具体物理更换流程大致如下准备好防静电手环、螺丝刀、新驱动器注意型号和固件版本。在TS4500控制面板或Web界面中确认待更换驱动器状态做好标记。如果是带线缆的驱动器先拔掉SAS/FC光纤线再拔电源线如果是模块化抽取式按照机架导轨操作慢慢抽出。插入新驱动器插到位后固定锁扣。接好线缆注意线序最好和旧驱动器保持一致否则库内线路管理会乱。等待TS4500重新扫描并识别新驱动器面板上状态通常会从Empty变成Ready或Online。记录新驱动器的物理插槽号、element地址、序列号、固件版本。这里有个特别容易踩的坑很多人换完驱动器之后线缆接的是新的口但系统层面和TSM层面并不知道。所以必须确保服务器端识别到的设备文件和库控路径对应的是同一个物理驱动器。如果线缆顺序错了新驱动器的设备文件可能对应的是另一个槽位后面定义路径时就会张冠李戴。3.3 让TSM重新认识新驱动器物理更换完成、TS4500面板状态正常后回到TSM操作。首先确认服务器端已经能看到新设备AIX下执行cfgmgr lsdev -Cc tape lsdev -Cc smcLinux下根据实际环境可以通过重新扫描SCSI总线或重启服务器主机总线适配器HBA驱动来发现。看到新的/dev/stX或/dev/rmtX设备文件后再回到TSM。如果TS4500有多个驱动器、库里有多个分区建议先做一次库内容同步checklib 库名 checklabelno接着定义新驱动器。element地址一定要和TS4500面板上显示的一致define drive 库名 新驱动器名 element面板上看到的element地址然后定义服务器到驱动器的路径define path TSM服务器名 新驱动器名 srctypeserver desttypedrive library库名 device/dev/rmtX如果库路径/dev/smc0之前也被删过还需要重新定义库路径define path TSM服务器名 库名 srctypeserver desttypelibrary library库名 device/dev/smc0最后验证一下新驱动器是否正常audit library 库名 checklabelno q drive fd做完audit libraryTSM会再次核对库内状态。如果驱动器状态显示Available路径是Online那基本就稳了。这时候建议再跑一个手工的backup/restore小任务实际用一次新驱动器确认读写正常再收工。4. 如何避免“幽灵设备”卷土重来4.1 把“先删后加”固化到维护流程里回头看所有“幽灵设备”案例本质上都是制造了“信息差”TSM的数据库和物理硬件不一致。要根治就需要把“先删后加”变成铁律而不是凭操作者临场发挥。我建议把整个更换流程做成一个Checklist每次执行都逐项打钩阶段动作是否完成更换前暂停TSM调度、备份配置和q drive/q path快照是/否更换前TSM中删除路径、删除驱动器定义是/否更换中记录旧驱动器物理槽位、element地址选择同型号备件是/否更换后TS4500面板确认新驱动器状态Ready并记录新element地址是/否更换后系统层确认新设备文件是/否更换后TSM中define drive、define path、audit library是/否验证手工备份任务读写测试是/否这条清单可以打印出来贴在机房也可以放到运维知识库每次做变更之前先过一遍。特别是在备件到场、多人协同操作时分工会更明确不会出现“A拔了设备B以为定义已经删了”这种乌龙。4.2 出现“幽灵设备”后的清理思路如果真的没有遵照流程已经出现“幽灵设备”也不要慌按照依赖关系倒着清理通常能解掉。所谓“幽灵设备”在TSM中无非表现为三种形态驱动器和路径都在但驱动器的element地址对应的物理槽位已经不是原来的设备路径状态异常比如path显示Unavailable或Offline驱动器定义残留但又无法直接删除。清理顺序建议是先处理路径再处理驱动器定义。如果路径被别的依赖占用可以尝试先把库设为维护模式再用update path把设备文件指向正确的新设备。如果确认物理上已经不存在这个驱动器但TSM还在用则先delete path再delete drive。遇到删不掉的情况多半是存在未释放的挂载或调度任务用q mount和q session查一下必要时停掉TSM调度器再清理。这里有个比较隐蔽的小坑如果TS4500做了库分区某一个分区出问题可能会连带另一个分区的路径。清理时建议一次只处理一个库分区避免影响正常业务的备份任务。还有一个进阶建议在TSM服务器上配置设备状态告警对驱动器的q drive状态变化做监控。一旦发现驱动器变为Unavailable或Recovering第一时间告警避免故障驱动器长时间被“冷冻”在系统里。监控工具可以是简单的Shell脚本 dsmadmc定时查询也可以在现有监控平台里加一个自定义脚本。5. 常见问题与排查技巧实录5.1 换完驱动器后TSM里查不到新设备这个现象通常不是TSM的问题而是服务器系统层面没有正确更新设备。检查顺序先看TS4500面板确认新驱动器已经被库识别、状态是Ready再看服务器端lsdev -Cc tapeAIX或lsscsi -gLinux确认对应设备文件存在如果系统里没有执行AIX的cfgmgr或Linux的SCSI扫描命令也可以检查HBA卡的线缆连接和交换机Zone配置如果系统层有设备文件再到TSM里做checklib。实际遇到过的情况是新驱动器的FC线接到了另一个HBA口导致AIX上看到的是一个全新的rmt设备而TSM里定义路径使用的还是旧设备名。此时需要用update path把设备文件改成新的rmt号或者干脆删掉新定义重新定义一遍。5.2 驱动器显示Unavailable或Recovering换驱动器后TSM里驱动器状态卡在Unavailable或Recovering是“幽灵设备”最常见的状态。排查时先从物理层排除TS4500面板上驱动器状态是否正常服务器端到驱动器的连接是否正常线缆有没有插牢SMC控制路径是否正常q path里库路径是不是Online。如果物理层没问题再检查TSM里的element地址。尤其是新驱动器和旧驱动器的插槽位置不一致时必须在define drive时使用新的element地址。很多Unavailable状态其实就源于element地址和物理槽位对应不上。还有一种情况audit library之后TSM自动发现了一个“额外”的驱动器但没自动定义路径。这时候只要补定义路径就能解决不要贸然去删除。5.3 系统设备文件不更新路径指到旧设备AIX环境尤其容易遇到这种情况。更换驱动器后旧设备文件不会自动消失新设备可能需要cfgmgr之后才出现。如果两个驱动器的WWPN完全相同但序列号不同AIX可能仍用原来的rmt设备名指向新驱动器但底层SCSI信息已经变了导致报错。排查方法是重新扫描后对比新旧设备文件的序列号lsdev -Cc tape -long cat /proc/scsi/scsi # Linux环境确认设备文件对应关系。如果发现路径指向错误继续用update path调整TSM里的设备名或者干脆在系统里删除多余设备后重新扫描。经常有人问能否把系统层不用的rmt设备删掉。AIX下可以用rmdev -dl rmt5但要注意如果这个设备被TSM路径占用先把TSM路径删掉或更新掉再删系统设备。顺序反了会导致rmdev报错“Device Busy”。5.4 驱动器更换后的固件版本检查最后聊一个容易忽略的细节TS4500里的驱动器固件版本最好与库控制器固件、TSM支持的版本保持兼容。换备件的时候如果拿到的是一个旧固件版本的驱动器TS4500可能识别正常但挂载、读写时会出现奇怪问题。在TS4500的Web管理界面可以查看每个驱动器的固件版本并执行在线升级。建议更换后检查一下固件如果明显落后于库内其他同型号驱动器优先升级到一致版本再纳入TSM生产使用。我个人的习惯是备件到货后先在测试环境把固件刷到和现场一致再拿去机房更换。这样可以缩短现场维护窗口时间也能避免因固件不兼容导致的“换了等于没换”尴尬局面。写在最后的一点经验磁带库驱动器更换这件事技术难度不算高真正考验人的是对设备关系的理解和对流程的执行力。我踩过几次坑之后最大的体会就是凡是涉及TSM和磁带库的变更永远把“数据库定义”当成和“物理硬件”同等重要的对象来对待先删后加、先查后改、核对element地址这三条做到位几乎可以避开所有“幽灵设备”问题。如果你所在的团队经常要换TS4500驱动器我强烈建议把上面那张Checklist贴到值班室的墙上或者直接做成运维工单模板。前几次换驱动器的时候每一步都截图留底后面做复盘和知识库沉淀时就能省很多事。
