关于“腾讯云用户数据丢失故障”最新公告的一些细节的疑问

@nullornull

其实，题中的疑问心中早已有答案，虽说是依据现有的公告进行推测...
但没有技术资料的支撑，一切只凭经验，这样的答案显然是不适合写出来的，毕竟有失严谨...
最终发出一些对细节的疑问，让各位自行推测，也能在讨论的过程中相互学习增长见识...

总结的话大概是没有的，毕竟不同的人有不同的看法，不同的业务有不同的方案。

就事论事的讨论问题，并冷静的表述自己的看法，以理服人
在讨论过程中互相学习增长经验，这才是 V 站该有的氛围

对公告的楼主的个人理解
第一，元凶“磁盘静默错误”到底是个什么东西？是硬盘 bug ？在数据转移前，这个 bug 就存在，但是在数据转移后才发生错误，在正常使用下，bug 其实没事，换言之，应该该是腾讯的数据转移工具也是采用的默认设置，且没有测试出 bug 的情况下最终引发问题的，仅仅说磁盘 bug 是不准确的。
第二，事件的起因，是仓库 1 空间使用率额过高转移到仓库 2 的，个人认为即便是云盘大小可调会引起使用略变化，但正常情况下，磁盘使用率不应该像 CPU 使用率这样变化不定的，而是规划了多少个用户之后，不在容纳新用户，新用户会使用另外一块磁盘，但这里将以磁盘使用率高为名，将老用户转移到新仓库，再回收老仓库不合理。十一事情的真正原因可能就是大家所说的超售，超售就是给你多少 G 硬盘，实际没那么多，因为你当时也没用到那么多，所以没什么问题，但在于销售沟通出现问题的时候，就出现紧急转移新硬盘的事件了。
第三、数据校验是什么，为什么没有按规范校验数据，个人认为你从网上下载一个操作系统，然后开始安装，却老出现错误，后来发现是下载的系统有问题，原来用的是迅雷，你下载地址没问题，但是迅雷给你的数据是从另一个地址来的，这种情况下我们本地校验和网上对的对比就行了，但是很多情况下我们从网上下载东西不会去校验，但对数据安全来说就必须校验。
第四、为什么没有按规范操作区校验，以及早早删除了原来的数据，在其他帖子里大家都说运维背锅，因为在小公司根本就没有流畅规范，全靠运维个人水平来避免错误的，只有在中等公司，才会在有规范当时培训监督不严格的情况下发生违反规范的情况下发生，对于腾讯这样的公司，这种情况应该是不可能发生的，所以只有一种情况，由规范之外引发的特殊情况要求运维去操作，既然不在规范内，这时候按规范来操作就来不及了，而且运维没必要给自己不痛快，所以极有可能是在领导默认下没有按照规范操作的，而领导的无奈可能其他部门的施压无奈破例，源头再次指向超售。
第五，可靠性是什么？硬件可靠性不高，可以通过硬件软件的相互配合来提高可靠性，硬件技术都是现成的，所以你可以宣传你的可靠性是多少，但前提一就是按规范来操作，当硬件不可靠的时候，发现改正不可靠，如果没按找规范操作，的确大部分情况下仍然是不会出问题的，只是就几率来说其实降低了成千上万倍了。
第五，楼主所担忧的更大的问题是什么呢？按规范来操作，可靠性是比较高的，没什么好喷的，但是是什么原因导致不按规范来操作的？说白了还是管理混乱的问题，当其他部门超出要求，必然会超过技术承载能力，超出承载能力，必然带来不规范操作，其结果可想而知。

云存储行业相关，我就经验做下推测，不代表我在腾讯这次事故上的立场。



首先是一些基础判断：

1. 所谓”三副本“除了高 iops 用途的，都不是三份完全副本，不管是 aws 也好还是国内厂商也好，都没有这个可能。三分完全副本会导致基础硬盘成本变成三倍。目前云服务的定价机制是靠低存储价格吸引用户，盈利点在针对读写行为的收费上，用得越多费用越高。如果把云存储费用和硬盘成本做对比，收费较高的 aws 大概是 1.5 倍基准，所以理论上没有可能这样设计。

2. 逻辑上的三副本，字面意义上会有暗示，损失两份副本还可以恢复。实际的存储模式可能是 (X+2) 的 EC 编码，意思是原始文件分 (X+2) 份，其中 X 份数据，2 份校验信息，分散写入到 (X+2) 份介质当中，可以容忍同时有 2 份介质损坏还可以重建。存储效率上 X=7 的时候，额外存储占用约为 30%，理论上已经有盈利可能了。当然实际上根据厂商的设计，(9+2)/(17+3) 都很常见，取决于对存储效率和安全系数的平衡。厂家宣称的可靠性 (Reliability) 就是由此通过某种模型推导出来的。



从腾讯的宣传来看，云存储用的是 SDS (Software defined storage) 方案。在这种方案下，具体的硬件不重要，因为 SDS 本身要解决的问题就是摆脱对特定硬件的依赖。根据其用途和支持的特性，我猜测它是类似 ceph 的分布式存储方案。分布式存储和传统（包括 zfs ）在内，有着本质的不同，不能拿来类比或者套用理解。

我这里假定腾讯使用的是类 ceph 方案，仅仅是因为 ceph 恰好可以支持故障复盘中的操作行为，也有可能是自研方案，后面会以 ceph 做例子来解释。



Ceph 方案用作云硬盘存储后端，是靠 RADOS 协议，在原生对象存储之上，抽象出块存储支持的。这种情况下对存储池做在线扩容迁移，有两种方案，一种是标准的 RBD 镜像操作，另一种是将目标存储池作为原存储池的缓存层，做对象级别的复制。考虑到复盘描述中运维人员可以选择部分云硬盘作为迁移对象而不是全部复制迁移，缓存层迁移又不需要回收过程，我倾向于实际的操作是第一种也就是 RBD 镜像的方式。

有关“加速迁移”的问题，我认为确实有可能存在 cpu 瓶颈。原理上，客户端（数据读取端，ceph client 的含义和一般意义上的客户端不同）独立连接各个存储介质，读取到分块后本地重组校验，这个过程是消耗 cpu 的。所谓瓶颈比较大的原因可能在于目标存储池也在提供服务，为避免复制过程中的高 cpu 占用和 IO 占用对在线系统造成冲击，人为限制的结果。

源数据被目标存储池读出的过程是不可能被”加速“的，任何一个存储系统都会把校验做在读取时，基本的逻辑是系统可以读不出数据，但读出的数据一定要保证是正确的。反过来，写入过程是有可能被”加速“的。这是因为在写入之后立即读取做写入验证的意义不大，没有人能保证下次读取的时候这些数据还是正确的。但这一点正在逐渐改变，随着存储量数量级的增长，曾经被认为小概率的 BitRot/SilentCorruption 成了常规事件，正在越来越多地影响存储系统。（注：这里的校验是文件系统级别的。）

对于 ceph 来说，写入目标存储池的”加速“手段，只有不写入校验信息一个手段，不仅减少了校验运算，还省去了部分空间占用。以目前 BlueStore 做存储后端（可以理解为 raw 文件系统），可以由 bluestore_csum_type 来控制是否同时写入 checksum 校验信息，可选参数有 none/crc32c/crc32c_16/crc32c_8/xxhash32/xxhash64，默认 crc32c。如果要关闭数据校验，就是将该参数由 crc32c 修改为 none。（注：这里的校验是 raw 级别的。）

事故的成因很清楚了：硬盘自身的校验由于 bug 固件失效，raw 存储级别的校验又被人为禁用了，写入的过程因为某些意外（宇宙射线等等）导致写入错误，但由于缺少强制的写入验证，待到读取时才从文件系统级别的校验发现错误，为时已晚。



我个人认为，问题最严重的地方不在于取消校验导致此次事故，而是整个扩容后的目标存储池都是没有写入校验信息的（按推理来说扩容前的存储池设置也是一样没有校验的），潜在受影响的其实是所有的存储数据，虽然出事故的只有小部分。换句话说，腾讯的存储方案可能自设计之初就没有对 BitRot/SilentCorruption 做针对性应对。



PS
我不是很赞同关于存储超售的说法，即使有超售行为，通常也是建立在对客户存储占用率建模基础之上的，只要配合适当的迁移方案，不是什么大问题。再有 ceph 的分布式设计会有一些不灵活的地方，一方面要预留足够的空余存储来保证存储节点意外失效后的自修复，另一方面随着硬件的更替，原有的设计参数比如 pg 等等可能不适合新的存储设计了，需要迁移或者重新平衡来更新节点的存储布局。

至于疑问三，在线迁移结束之前，io 还是指向仓库 I 的。指向仓库 II 之后三分钟就发现异常了。

所以第二份公告的目的其实就是运维（临时工）背锅，真正的原因被掩盖，大家也难以真正放心。

@zhuang #83
获益良多，虽说部分观点与现在的公告逻辑略有出入
毕竟按照公告说法，异常在源数据仓库不在目标数据仓库，写入异常不成立

关于疑问三其实是没想通为什么是一刀切形式的仓库切换
按理说所有在线的虚拟机都需要一个短暂的快照后增量同步的操作
或许这 3 分钟就是重定向 IO 后的增量同步过程吧。

但...三分钟时间内删除了源数据？不太敢想...

@mhycy 公有云架构是优先考虑成本的。土豪公司可以考虑私有云定制

@webjin1
本来存储系统搭建的原则也是用最便宜的零件构造足够可靠的系统（虽说这个可靠是要看场合的）...
所以家用 NAS 从不推荐红盘、紫盘、黑盘、企业盘
（显然做不到这一点用高价零件的可靠性也是差不多的）

@mhycy

我的观点基础还是一样的，不存在物理上的三副本，只存在逻辑上的三副本，所以关于“哪一个副本失效”的描述都是不准确的。

读取时逻辑上存在的三副本或者说 (X+2) 块数据是正常的，这是因为从 VM 三分钟就能发现 IO 异常来看，VM 还是在线且正常工作的。假如仓库 I 的数据已经异常了，那么早在迁移之前就会出现问题。

因为没有人能保证，存储介质中的数据在读取时还是正确的，所以验证行为都是在读取时发生的，写入的时候是盲目信任的。

由仓库 I 向仓库 II 的迁移，读取过程必然伴随校验行为，也就是说，仓库 II 在写入之前已经确认了，文件系统级别上的数据是正确的。之后切换仓库指向，发生 IO 错误，说明仓库 II 的数据是异常的。那么极大概率错误是发生在向仓库 II 的写入过程中的。

我猜测仓库 II 的硬盘存在静默错误，错误表现为读取的时候，硬盘固件对读取到的内容做 CRC 校验，如果不一致应当丢弃并向操作系统报错，但固件 bug 使得所有校验都能通过，操作系统按照对待正确数据的方法进行处理，因而导致 IO 异常。

实际写入错误可能非常少，但是按照上一次公告的内容，错误出在了文件系统 metadata 的部分，因而导致数据写乱了。

至于公告怎么写的，那是另外一回事，当然我是就个人经验做出的推断，可能和事实不符。



Ceph 的架构是这样的：VM<--->RADOS GW<--->Storage，VM 发出的 IO 请求要先经过 GW，GW 可以在 Storage 切换的过程中推迟对 IO 请求的处理，也可以临时返回失败等待 VM 下一次重试。

迁移的过程是，GW 暂停对相关 BD IO 的处理，确认镜像的状态为一致，切换指向，恢复 IO 处理。对于 VM 来说，除了短暂的 IO 延迟上升以外，没有其他影响。

确认镜像状态一致是个逻辑层面的行为，写入了就认为是正确的。如果给出足够的时间，等待一次完整的 scrubbing （通过读取来验证数据状态）完成，还是有机会发现差异的。

三分钟删除源这是策略层面的问题，可能是过于自信了吧。

@zhuang 从 tx 的声明里面看，他们的迁移是手工作业，这个个人觉得才是最难理解的地方。
至于迁移完成后立刻删除源的原因，因为仓库 I 要满了呀，所以运维才会发起迁移动作，迁移完毕以后当然就是要释放仓库 I 的这部分空间了呀

我靠了 23333，我发那个没人看 2333
我观点是，根据我之前发的帖子来说，腾讯云的云硬盘同步原则应该是服从多数原则，因为 TX 云说的是因为仓库搬迁，我不知道他说的这个仓库是物理上的机柜之间进行搬迁，还是说在网络内的 Copy 和 Paste，因为云硬盘本身也是物理硬盘阵列上虚拟出的一个空间，而物理空间不足，不选择加磁盘，也不选择物理移动，而是转移数据，真的是富到家里有带宽了。然后呢是在迁移的时候没有开启数据校验，但可是如果说存在 3 备份的话，那么其一定是有一个主从绑定关系的，如果你三副本一起换硬盘，那么三副本就是一坏两个好(因为当时说一块硬盘的元数据挂了)，然后呢数据完整的迁移过去了。即使回掉仓 1 的数据，仓 2 应该是一坏两好，当然因为这个是搬迁扩容，不可能说数据在网络传输的过程中损坏，或者物理搬运损坏的。因为按第二公告的说的两次失误来说，这和主盘错误，未经检验就同步两仓库无关，应该也不会有从一个盘直接复制三份这种傻帽行为。另外是第一个公告说文件系统元数据损坏，并且是该主控的 bug 引发静默错误，但是我觉得如果读写不一致，应该早就发现了，毕竟硬盘不可能一块一块买，metadata 丢失，新硬盘能跑起来？毕竟这个不是校验的问题，系统跑不起来不可能不报警吧？

会不会是关了校验，并行读取？
因为开校验的话就要同时读 3 份数据
网络带宽不成问题
写入的时候复制 3 份同时写

迁移的负载不能影响正常业务，所以迁移优先级最低，不能使用全部读取能力。写入侧是空机，所以满速写入


@nciyuan 家里有带宽才能开云啊，内网带宽几十 G，只要不影响正常业务，干嘛不用

@akira 不会是纯手工
内部有运维工具，一般是脚本，不一定是一键 gui
所以可以手动强制很多参数，然后安全意识不足，随手打了

@mhycy #87
讲真，my book 比桌面版 wd 硬盘便宜，拆出来反而是企业级的氦气盘体
我现在的 NAS 就是 raidz2，6 盘 nas
备份计划？不存在的……又没什么重要数据，纯属玩票性质

@akira

我前面解释过，如果是 ceph 方案，逻辑上的满了和物理上满了是两回事。迁移完成后多久删除源数据是个策略问题，这里确实不妥。

举个例子，EC (7+2) 编码 12 盘方案，可以容忍两盘失效。实际上安全存储空间只占存储池的 10/12，这是因为一旦发生 2 盘损坏的情形，ceph 会将重建的部分写入剩下的 10 盘。另外由于分布式存储 deterministic 的分配算法，总共 9 分块写入 12 块硬盘中，各个硬盘的写入量可能并不均衡。从我的经验来看，要么根据一个警戒标准提前进行扩容，要么根据实际的增长速率来预期扩容。

第二个问题是，手工操作是不是意味着运维水平低？

从运维的角度上说，区别是不是手工仅仅从一两行描述是看不出来的。这个例子里，扩容是一个引入新设施的过程，从具体的硬件搭配到软件参数的调试都离不开人类决策，敢于线上迁移（相对离线迁移）很大程度上说明对于运维的水平有自信。（如果一切真如公告所说的话）

我的看法是取决于这样的迁移行为是不是频发，如果是，有没有固定的工作流程，这样的工作流程是否能纳入日常审计范围，异常处置又是什么模式。理想情况，这个运维行为可以无人值守双向可逆，但事实情况能够人工介入回滚已经是非常好了。

对于整个事件，如果要我表个态，我会认为腾讯的软件系统存在设计上的不足，没有对 BitRot/SilentCorruption 做应对。但运维水平方面不好判断，一方面能看到自信到爆表的线上迁移行为，另一方面又是激进到难以置信的回收策略……我觉得更大的可能是公告不可信吧。

作为一个 ceph 初级工程师，我觉得腾讯云第二次解释挺清楚的。如果用的是 ceph 的话，使用过程中关闭 scrub （校验）也不是没有，前东家就这么干的，毕竟 scrub 消耗磁盘性能。读的话只从主副本读，刚好静默错误发生在了主副本上，数据拷到新集群，上面三个副本存的都是出了错的数据。这样就 GG 了，感觉挺合理的。
楼上有人说三副本可能实际上用的 EC，我没进过 bat 这种大厂，但见过的环境说副本的就是用副本，ec 是便宜，但底层用了 ec 还敢宣称是三副本的感觉是有点石乐志。亚马逊好像有个冰川存储，那个应该是 ec，因为便宜。

腾讯云这次公关水平为零。
做错按照规矩陪就是，客户不满意就赔到满意。谁叫你做错了？ 只要稳住一波，宣传成本都剩下好几百万了。现在看来，中小企会被阿里完全收入囊中。

腾讯云做了两件事是送人头的：

1、过早提及营收，这次时间跟之前送券连夜截回事件相当于口碑扫地。送券截回伤站长，数据丢失伤企业客户。谁还会把东西放你这？或者说大头放阿里，备份放腾讯会成为日后通识。

2、过分强调备案转移。不是腾讯云接入的一律不让放，那你要知道有多少是阿里的。之前打的价格战不就是白忙活了么？

这样的情况，我一直在想，腾讯云就是为了做大点，随时准备卖身给阿里的 :) 要不然前期也不会那么积极送人头。

股价跌了也不要慌啊，盘子还在呢？做云计算的前期有谁不亏点呀。

@zhuang
获益良多，感谢科普！

@songxinyingpg #95
请教，scrub 消耗磁盘性能的原因在哪里？

@ryd994 #93
感谢信息分享

@lyhiving #96
虽说一直都不信任任何云服务的可靠性，但经历了腾讯这件事，大概是不会把商业数据放上去了
毕竟有备份恢复起来也是很麻烦的...