从数据恢复角度分析腾讯云静默损坏

Posted 2020-12-28

腾讯云在这次事件中的结论表述为因受所在物理硬盘固件版本Bug导致的静默错误，文件系统元数据损坏：
根据这个表述，故障应出现在硬盘固件故障导致的文件系统元数据损坏。这其中，涉及具备因果关系的三个知识点：
硬盘固件故障—>文件系统元数据损坏—>文件损坏。
在此大致画一下腾讯云可能用到的存储架构方案。

带*号的是不一定存在的存储链。事实上，这个逻辑肯定不准确，比如有些环节精减或不需要，有些环节有更详细的设计等。但是不是和真实场景一致不重要，重要的是，问题如果出现，总会出现在我列出的项或我没列出的项中(废话)，这些项是相互关联的。
我们再重复一下现象：硬盘固件故障(层1故障)导致的文件系统元数据损坏，从而导致部分文件校验出错，导致文件损坏。针对现象，努力从上述10个环节匹配，每一层会有可能出错，导致上述故障吗：

第1层：存储介质

以硬盘为例，每个构成数据的最小单位扇区都会有严格的校验，包括扇区头部的CRC校验以及地址标识校验。理论上，如果层1的数据出现磁力失真(或闪存状态丢失)等比特出错，其头部校验不匹配时，介质控制器就会向上层反馈错误(一般表现为坏扇区)，上层会启动修正模式进行修正。
当然也有例外，比如硬盘内部程序出错，根本不按上述原则执行，忽略校验值的情况下，任何对数据的篡改都是可以的。可以表现为腾讯所说的静默损坏（即层1在合理的逻辑里偷梁换柱)。这种情况，基本大帽子就能扣在硬盘固件BUG这上面了，但硬盘固件这种BUG是致命的，等同于我们存进银行的钱不知什么原因变多或变少，没有硬盘厂商站出来承认，也没有紧急发布BUG修复固件，完全归因于硬盘固件，可能偏激了些(也可能事件背后有固件BUG的原因，那也应该是添油加醋型的)。

第2层：RAID

RAID自身有冗余算法，可实现在部分介质（硬盘）损坏后，由其他成员及算法控制来接管损坏硬盘的数据服务，保证上层业务不中断，不出故障。但RAID也并非完全可靠。
一种错误是软RAID中的写漏洞(write hole)，如果是软RAID，这无法避免，可能导致腾讯本次事故。但软RAID是玩具产品，自然腾讯是不会用这种方案的。
还有可能的错误是buffer?dirty，当缓冲数据掉电清空，或有意无意损坏后，会导致数据出现本例的表现错误。但这个原因可以很容易推到控制器BUG上面，腾讯没提及这个原因，或者是他们没找到病根，或者的确和这个无关。
还有最可能的错误是RAID中超过冗余数量的磁盘损坏。比如RAID5只支持一块盘损坏，但现实中出现了：
情形1：同时2块或以上硬盘损坏
情形2：1块损坏后未及时重建，第2块又损坏
情形2出现的可能性非常大，几乎IT类公司没有不湿鞋的，只是数据或不重要，或未千万公众效应。本次腾讯事故，情形2导致的数据灾难，不是没有可能。想象一下，以RAID5为例，若底层RAID有硬盘坏，管理人员没及时跟进重建，希捷负载加重后，其他硬盘坏，是非常正常的事情。更有一种情况，与硬盘固件有关，就是硬盘已经有坏道了，但并未碰触到坏道区，这时表现一切完好，一旦重建，就会导致RAID崩溃。
一般而言，工程师的修复方法就是强制上线，让带病的硬盘强行工作，也可能不懂的工程师随便上线了旧掉线的硬盘，这时，就会表现为大多数数据可访问，但部分数据（尤其较新）出现损坏，与腾讯公开的表现相似。

第3层：虚拟卷层

虚拟卷往往用在大的云存储中心，简单地举例来说，如果由1000个硬盘构成的一个存储系统，再按8硬盘一组的方式进行存储划分，会有很多问题(高故障、空间利用不集中等)。为此，很多厂商开始提及虚拟化存储，方法各有不同，但基本就是存储池化---意思是所有可用的空间在确保案例的前提下，汇总到一个统一管理的“池”中，再根据需求灵活分配虚拟磁盘。
一种方法是把所有硬盘放到池子里，再切块组RAID，再组个存储池，再划分虚拟卷。华为把这个技术称为RAID2.0，其实HP EVA、3PAR也都按这个技术在实现(网络上的主流资料描述HP EVA的算法均有误)，DELL康贝(Compellent)都是这样实现。这种思路硬盘如果足够多，在使用前期安全性很好（有足够多的混在队伍中的替补，可以快速替换故障数据块），但后期随着损坏硬盘数量的增加(尤其越是自动替换，管理人员就越松懈)，故障率就会增加。
举个HP-EVA的例子，一组存储144个硬盘，在崩溃临界点，先后有近40个硬盘报故障。故障的根源其实来源于硬盘预警失效、控制器又完全呆傻的BUG。40个故障硬盘远远超过可以激活系统的故障数量，就导致所有部署在本存储上的数据全部下线。一般HP官方的最高解决办法(美国的一线)，就是用指令强行激活存储，让存储自己计算缺失数据，当数据的确落到坏道处无法校验生成时，就会用旧状态数据(EVA快速重建时会可能保留某些数据块的旧状态)或全0代替。这样，就会导致上层文件系统故障。文件系统故障就是表现为元文件故障，否则元文件没坏，文件系统就不会坏，顶多表现为文件内容不正确。
腾讯本次的事故也有这个可能。
另一种方法是把所有硬盘按xD+yP的方式构建RAID(如8个硬盘的数据，配一个硬盘的校验)，再把所有的RAID放到池里，再从池中划分虚拟磁盘。IBM DS8000、HP X20000、DELL EqualLogic都用这个方案。这是非常垃圾的方案，IBM和HP的上述两类存储都是上千万一套的产品，但故障风险极大，我们的国企，政府常用，也常出问题，只是没人知道。故障主要来源于不断放大的RAID风险，每一组RAID假设有1/10000的概率损坏(如第2层中的情形2)，如果1000个硬盘，有100组，损坏概率就放大了100倍，想想也可怕。但腾讯本次事故不太可能用IBM、HP、EMC的存储，因为太贵了，又不是存自己的核心数据。可能有小厂商或腾讯自己用软件定义的方式搭建本类存储，损坏的可能也就如同第2层中的情形2。

第4层：虚拟卷快照

快照是对某个数据集某个时间段的差异数据组合。快照集叠加到其父集上，就可以表现为最新的数据副本。集中在快照上的故障往往因人为发生，比如以为某个快照副本已经失效，删除后发现删错了；比如在回到某个快照状态时选错了，再也退不回去等等。
如果照着腾讯本次的事故，至少有一种可能会导致故障现象的发生：管理人员因故(迁移、维护等原因)对数据做了快照，在清理临时数据时不小心删除了快照副本，紧急抢救后，快照数据救回来有部分损坏，快照合并后表现为部分数据损坏。当然，这个可能性不大，腾讯本次事故中没有选择数据恢复专业公司介入(只要有选择数据恢复方案，北亚不会不知道)，应该不会有这种实施可能。

第5层：大数据或云存储层

出问题的腾讯云是基于虚拟化技术构建的，涉及虚拟化，就一定会设计资源的集中分配。涉及数据部分，单一或独立存储很难响应IO的不确定性峰谷请求，所以，腾讯应该会设计Hadoop之类的平台来提供数据资源分配。
在大数据平台的设计逻辑里，数据IO资源会以可能平均地分配在所有节点中。而管理他们的元数据或集中或分布式。逻辑上，用户数据与元数据是独立的。
但现在的大数据平台往往是基于传统单机文件系统为载体进行架构。单机文件系统的操作手段、命令并未废止。所以，在一些情况下，大数据平台出故障，可能会导致腾讯类似的数据灾难。
仅仅是举几个想象的例子。
如果维护人员不小心删除大数据平台下一层文件系统上的某些数据块，大数据平台的冗余也无法还原某个数据块的话，就会表现某个用户的虚拟机数据缺失。
如果维护人员没及时维护节点，某些节点损坏，超过了冗余级别，也会导致某个用户的虚拟机数据缺失（也有可能用VMware vSAN之类的技术，同样这种可能也存在）。
腾讯的事故是否如此，不得而知。

第6层：虚拟化文件系统

VMware?vsphere、Xen、KVM或Hyper-V是专门的虚拟化系统平台。这些虚拟化平台，为了实现块级别的同时访问，且适应虚拟机的大块分配原则，有时要设计自己的文件系统，最为典型的是VMware的VMFS。
以VMFS为例，对VMFS引发本次事故表现的可能举举例子，如下：
1、VMFS是典型的共享块设备文件系统，是基于每台VMWARE服务器的约定，如果接入存储网络的是普通单机，他可不管是不是共享，有时就会独占存储设备，导致VMFS的破坏。强行修复后，就会出现某台虚拟机数据损坏的情况。
2、VMFS管理时不小心删除数据，或扩容、缩容，也会导致VMFS文件系统损坏，修复后，可能出现某台虚拟机数据损坏的情况。

第7~8层：虚拟磁盘文件与快照

虚拟机的数据载体是虚拟磁盘，往往表现为宿主系统上的一个文件或一个独立区域。以文件形式表现的居多，如RAW、VMDK、VHD、VHDX、QCOW2等格式。
这些虚拟磁盘和普通文件表现相同，就会面临和普通文件一样的损坏可能。比如上层误删除文件、上层格式化、文件截断、文件迁移时中断等。这些文件一旦破坏，即使恢复回来，也可能不是100%，就会与腾讯本次数据灾难的表现相同。
磁盘文件快照与第四层的卷快照原理相似，Hyper-V对其称为差异磁盘，表述直接明了。快照文件丢失或损坏后，也可能与腾讯本次数据灾难表现相同。

第9层：虚拟机文件系统

分配给用户的虚拟机，其硬盘就是前文提到的虚拟磁盘文件，但进入虚拟机后，就等同于物理硬盘。这些硬盘也被正常操作方法分区、格式化、安装系统、安装应用等。不论Windows的NTFS、Linux的Ext4等，文件系统总会可能有突发性的灾难。但本次事帮显然不属于此，仅聊聊可能的数据风险。
一是来自误操作。如格式化、删除数据、同名文件覆盖等。
二是来自系统bug。但bug并非是特别明显的，有时是需要多方环境因素催化。举个例子，在NTFS上打开卷压缩，存入一个上百GB的文件，文件系统8成会崩溃，连现有文件都可能找不到(在早些年，我做了很多这处条件下的试验，最终确定的确是系统bug，最近未做实验，或许Microsoft已修正)。另一个例子，非常常见，在WINDOWS上运行ORACLE数据库，数据库文件的增长粒子设置过小(比如1M之类)，当数据大小到上百G时，不出5年，几乎肯定会崩溃(数据文件大小截为0，或内容交串出错)。

第10层：文件

这一层没什么好说的，往往是来自于上述几层的故障，导致文件损坏。除此之外，就谨防勒索病毒吧。

建议

数据灾难大方向有2个：人为灾难和不可抗力灾难。能给出的建议大概如下：
1、备份。
备份的重要性毫无疑问，但要讲方法，为避免硬件故障，就不能备份在同一个或同一类硬件载体上；为避免自然灾害，就要异地备份；为避免备份集过多带来的管理问题（找数据都费劲之类的），应制定良好的备份计划；为避免同类介质受环境的影响，就应该考虑不同介质的方案，如光存储与磁存储各自备份；为避免有意或无意破坏，备份集就应该设不同的存取权限，不能一把钥匙开所有门……
2、规范管理和实施。
很多企业级数据灾难往往来自于人为，因为任何一个系统，在涉及维护的时候，都必须工作在无保护状态，任何一个不小心都可能导致无法回溯的后果。制定严格的维护实施方案、备份计划、预警机制是非常重要的保障。
3、数据取舍。
太老的数据就删了吧，再对数据精简整理，再做详细的管理计划。要知道，娶妻越多，头顶发绿的机会就越大。