工程师手记 | 磁带这个结，如何解？（上篇）

作者：Hitachi Vantara售前技术顾问 刘鸿岳

说起磁带库技术的历史，可谓源远流长。从IBM于1974年推出最初雏形 3850开始，已经有超过40年的发展。目前主要的磁带库制造商有三家，IBM、ORACLE(STK)、Quantum，合计占据市场份额的90%以上。磁带库的结构比较简单，主要是由驱动器、机柜臂、磁带介质槽位、控制卡组成。驱动器目前主要采用的是工业标准的LTO，制造商只有两家，即IBM和HP，磁带库厂商采用OEM方式。HP是个特别的公司，作为全球仅有两个生产LTO驱动器的厂商之一，它仅生产低端磁带库，高端磁带库与Quantum合作。IBM也是个特别的公司，蓝色巨人不是白叫的，从低端到高端，从驱动器到磁带库，什么都有。除此之外，IBM和ORACLE还生产企业级驱动器，但是用户量较少，主要用于Mainframe环境，价格也特别的高。在采用LTO驱动器的环境下，磁带库有什么区别呢？其实磁带介质槽位也没什么区别，仅仅是一个塑料架子而已，无非结构设计上有些细微不同。主要的区别还是在于机械臂，它才是决定磁带库的关键。从字面上理解，机械臂，自然是机械部件。它的主要工作就是把磁带介质在驱动器和槽位之间进行搬运，是干体力活儿的，由控制软件（例如备份软件）来操作，自己没有脑子。因此上，磁带库虽然与计算机密切相关，但是它从工作原理上来看更是一个机械设备，机械设备常见的问题它也不可避免。实际环境中，磁带库最常遇到的问题也是机械臂故障，尤其是低端磁带库，制造工艺差，故障率非常高。我有幸和磁带库及备份软件都打过交道，因此对行业有一点了解。

讲一个让我印象深刻的故事，如有雷同纯属巧合。

有一次，去用户公司参加一个服务相关的会，根据经过来判断，是个批斗会。这个用户备份环境规模比较大，其中一个备份域有一套磁带库配置48个驱动器（24个LTO5和24个LTO4）和近万盘磁带，还有超过100个Media server，上千个备份客户端。再加上内部环境比较复杂，每次去开会都是格外的谨慎。会议上，用户的问题主要围绕着两点：

• 1LTO4驱动器故障率高，备件更换时间长

另外一个磁带库使用竞争对手的产品，驱动器故障率低，怀疑产品质量有问题。

• 发生多起磁带介质数据无法读取的事故

长期保存数据的磁带，驱动器无法读取，怀疑磁带质量问题导致。

回来和公司相关人员进行讨论，从特殊途径拿到相关数据，经过详细的统计分析，发现一些问题：

• 磁带驱动器故障问题

• 用户采用的LTO4驱动器服役时间超过了6年。

• 承担了海量的小文件数据备份，写速度20MB/s左右，仅为驱动器性能标称值的1/6。因此，每天24小时不间断的运转才能勉强完成备份作业。LTO驱动器的建议工作时间为12小时/天，最大16小时/天，因此长年处于超负核运转，这是故障率高的主要原因。另外一个备份域不具备此业务特点，因此磁带库没有出现高故障率问题。

• LTO4驱动器2年前已经停产，备件处于库存消耗状态，因此无法保证更换时间。

• 磁带无法读取问题

• LTO磁带的保存标称值为15年，此数值是建立在极为理想的保存环境下。实际的保存时间根据具体环境情况决定，通常用户的环境下可保存2年到5年。目前发现的问题磁带全部是出库保存的，离开机房的条件下环境会相对更差，因此磁带数据损坏的机率就大大提升。

当时我给到用户的建议是：

1. LTO4驱动器生命周期已经结束，尽快进行升级。

2. 优化小文件备份环境。

3. 优化磁带介质保存环境。

然而……

任何事都没有表面看起来那么简单

--墨菲定律

                                             

我被用户怼回来了：

1. 为什么不及时通知用户更新换代的问题？为什么不强调风险？

2. 已经对小文件备份环境进行优化，你们有更好的解决方案吗?

3. 用户为磁带出库保存做了很大投入，不存在环境问题。

很明显，用户不愿意承担任何责任，想找人来背锅。考虑到下一步有采购驱动器的项目机会，认罪伏法，好好改造，这是唯一的出路。

服务事件的风波算是过去了，用户也开始准备升级的项目。组织相关人员开会，包括磁带库厂商，备份软件厂商，用户设备管理部，用户备份管理部。在会前准备时，我已经给用户提交了方案的初稿和驱动器的报价预算，此次会议主要讨论的就是可行性。方案大概的内容是：

• 24个LTO4全部淘汰，安装32个新的LTO6驱动器（驱动器槽位还有空余）

• 带库中的LTO4磁带进行统计，尽量多出库，为新的LTO6磁带预留位置。

• 备份软件配置新的LTO6驱动器，用于承担新的备份任务。

• LTO6驱动器可兼容LTO4磁带的读，将LTO4磁带数据转储到LTO6磁带中。

• 转储完成后LTO4磁带继续出库。

用户提出质疑，LTO6驱动器在容量和性能上都有提升，为什么需要配置32个？这个问题的提出，明显是因为超预算了。给用户的答复是小文件对并发要求比较高，之前24小时连续运转说明资源不足，所以至少要增加驱动器数量。

备份软件厂商也提出问题，驱动器读不同型号的磁带数据存在一定的风险，不能100%保证数据的可靠性。最佳方案是保留8个LTO4驱动器，安装32个LTO6驱动器（磁带库驱动器槽位还有空余），用于读出LTO4磁带内容，再由LTO6驱动器写入LTO6磁带，完成转储。其实备份软件提出的问题看似技术问题，实际是想增加更多的软件License数量，多分点蛋糕。

用户提出是否可以先安装24个驱动器，保留8个LTO4驱动器，转储结束后替换余下的8个LTO4驱动器。否则仅为了转储就多买8个License，升级结束后又用不到，实在是不必要的浪费。

备份软件厂商又开始强调变更复杂度，实施的时间长，言外之意是需要更多的实施费用。经过一段时间的讨论，用户决定根据目前的预算进行均衡，升级24个LTO6驱动器，保留4个LTO4驱动器。方案重新按照此架构设计，由备份软件和磁带库两个厂商配合完成。

所有准备工作完成，看似一切顺利了，然而，迟则生变。

欲知后事如何，细听下回分解……