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

临时工干的？

吸取教训

从上面了解到，犯了几个错误，都是低级错误。。也不知道 OPS 哪里来的自信呀

1. 关闭了数据校验
2. 未确认迁移后数据是否正确就删除源数据

作为非运维的技术人员的我觉得，其实还是技术问题，这么重要的操作早就应该要实现自动化了吧，操作的时间长点也没关系，一个严谨的自动化程序从技术层面保证平稳的迁移，人工操作从来就是不靠谱的。

@bdnet
“操作的时间长点也没关系”
看楼上的分析
很可能是超卖导致不立刻迁移已经来不及了

@mhycy 没有热备吗？

@songxinyingpg

主要的问题还是公告的内容不够细致，很难做完整的判断。


先说发生静默错误的硬盘在哪里的问题。

从公告来看，仓库迁移完成三分钟内即报错，说明 VM 一直在线且有 IO 行为。如果主副本是在有静默错误的硬盘上，为什么迁移之前没有发生错误呢？假如主副本出错，理论上 VM 早就有感知了。

我觉得理论上有一种可能，就是（在基于 ceph 方案的前提下）腾讯基于 libRADOS 重写了 RBD 的实现，启用了并行读取的功能。客户端发出读取请求的时候，同时向三个 osd 发送请求，非主副本每次响应都比主副本更快，使得 VM 可以从两个正常副本获得正确数据，然后 ceph 内部再将非主副本的数据同步到主副本上。在执行仓库迁移的时候，又单独从主副本复制了错误的数据。

如果出错硬盘在扩容后的仓库中，这个问题就不需要什么假设了。复制来源是正常的，写入的时候已经出错，再次读取的时候发现错误。



关于三副本的问题，物理三副本完全说得过去。考虑有可能是逻辑三副本的实现是因为最初没有公布复盘，只说硬盘固件 bug，因而对于三副本的说法产生了怀疑。

另外 EC 在 RBD 这种应用环境，如果 cpu 不是瓶颈的话，相对副本池的性能还要好一点。但是要牺牲一点延迟，从实际应用来看，VM 到 RGW 的延迟是大头，ceph 延迟不是很关键。副本池是不支持并行读取的，高 io 队列很影响性能。用 EC 池不一定单纯为了省成本。



@mhycy

这里一并回复关于 scrubbing 的问题。

Scrub 有两种，light/deep，前者只校验 metadata，后者还校验文件本身。Scrubbing 的过程就是延迟的写入验证，把硬盘上的文件读一遍，验证一下，以便提前发现问题。

因为它不仅占用 IO 还要消耗 cpu 资源，所以配置的参数重点在多长时间进行一次，什么时间进行，一次进行允许操作多少数据块。可以理解成某种计划任务。

关闭这个校验对仓库迁移这个时间段来说一点意义都没有。真正有意义的就是我之前提到的，写入时禁用 crc32c 校验。

@zhuang 楼上一种解释我认为是比较有可能的
故障硬盘也不是全坏，比如只有 5%，读取的时候校验错误就立刻纠正并回写了。当然回写并没有实际上纠正，因为这是硬件故障。因为比例很小，所以也没有触发报警。
为了不影响生产，迁移读取不能用满带宽。考虑现在的云带宽都是几十 G，瓶颈更可能在磁盘。
但是写入是可以满的，所以直接把三副本当 stipe 读。写的时候一份变三份写。
于是一份错误变成 3 份错误
随手删了旧集群
发现新集群报警，傻眼

逻辑三副本应该不会。这算是很弱智的设计错误了吧。同一个故障域下，多少份副本都只能算一份。

我手上就有一块 320G 的硬盘有这问题，读取正常，写入的数据在某个字节上均为 FF，却不会报错。

这里有两个问题:
1.静默错误是磁盘针对少数 LBA 偶发的随机性错误，可能导致用户云盘中少数 LBA 数据错误，而不会整个云盘数据丢失。
2.按照腾讯的说法，原来的三份已经删除了，新的三份是一致的，那么他如何确定是磁盘静默错误导致而不是迁移过程中程序出错导致的呢？

@seabiscuit09
1.元数据损坏会造成大量数据读不出来，如果再加上写入时使用了错误的元数据，那么直接写花了。

2.如果是说明中的错误，那么在迁移前可能就已经报警了。
实现应该这样，用户读操作发到这个盘，读取后校验发现错误，控制器协调再次从其他副本读取并将正确数据写回，同时应该有故障计数。

@gamexg 感谢你的回复。
1.如果是元数据损坏，按照腾讯的技术能力，做数据恢复应该不是难事，即使不能完全恢复，部分恢复也是应该的，目前并没有看到这方面的信息，用户说的是全部丢失。
2.我说的是按照腾讯给出的信息，并不能必然推导出磁盘 silent error, 并没有这样的证据。而且 silent error 是非常严重的问题，厂商需要紧急修复，召回，赔偿的，目前腾讯并没有公布是哪家厂商，为啥宁可自己背锅，也不说明是哪家厂商。

@zhuang
ceph 的 QOS 最近才有进展，用 ceph 的可能太小了。

云硬盘的价格，即使按腾讯的算，用真正的三副本也有得多。

写入时禁用校验不可能。
1.校验信息本来就已经存在，不需要再计算一次。
2.如果没有校验信息，腾讯是发现不了错误的。

至于为什么切换之后才报错因为原仓库有正确的数据完成自我修复，而新的仓库没有就成了不可修复错误。大容量存储有单份数据出错是很正常的，并不会有人关心。

@seabiscuit09
1.最初的信息就是腾讯给客户恢复了数据，但是数据有污染，客户认为不能接受。
2.前面有说是 SSD 那很可能是 ODM 产品。

@seabiscuit09 #109 只有部分数据未能恢复，并不是全部数据。
“腾讯云监控到异常后，第一时间向用户告知故障状态，并立即组织文件系统专家并联合厂商技术专家尝试修复数据。遗憾的是，虽经多方努力，最终仍有*部分数据*完整性校验失败。”

静默错误我不知道企业级硬盘是什么情况。
家用级的碰到过硬盘完全挂了读取出来的全部是 0。
也碰到过巡检发现硬盘部分数据校验失败，系统自动从正确硬盘恢复了数据，但是一段时间巡检又发现部分数据校验错误，直接更换了故障磁盘后没再碰到。
非阵列的也听到过每次重启后 windows 桌面设置等信息丢失，和对方确认后确定是硬盘有坏道了。
这些看起来都是硬盘提供了错误数据，不熟悉硬盘工作原理，猜测是硬盘自身虽然带校验，但是发现校验失败后多次重复读取还是错误数据就会直接将错误数据返回给上层，内部再使用预留扇区替换故障扇区并增加故障计数。

@gamexg #112 对了，我记得一些测试硬盘是否有故障的软件就是根据读取延迟来确认，如果某些扇区读取延迟很大，可以怀疑这个扇区存在问题，硬盘内部多次重试才读取到了正确数据。

@ryd994
写的时候会有回写缓存，而且 RAIN 的瓶颈主要在主控节点上，磁盘性能可以通过增加节点数量解决。

@gamexg
不会是硬盘内部检测到错误再返回 0 或者故障数据，腾讯应该还没傻到用这种硬盘。估计是硬盘直接返回了错误的数据，这种事情在 SSD 上发生过。

@xud6

不是说三副本没有可能，我也觉得 ec 宣传成三副本不是很理智，只是当初普遍猜测可能三副本不存在才导致数据不能恢复。现在两份公告都出来，如果认为公告全部属实的话（我现在认为都是真的），假设最少的推测应该是仓库 II 硬盘有静默 bug，复制过去的时候发生了写入错误，切换指向导致新读取的数据有误，造成 VM IO 异常。

本身公有云的存储定价就已经比硬盘本身采购价便宜了，盈利模型是基于多年成本平摊和 IO 及带宽额外收费。行业里 aws 的税前利润率在 50% 左右，国内这些可能在 30% 附近，在这种情况下，三副本留给盈利的空间还是不少的，至于八个九的可靠性？我觉得这个价钱蛮难做的。



关于你提到的校验的问题：

第一层是硬盘硬件层面的，逻辑 512K 扇区实际是 520K，多出来 8K 用作硬件校验。但这次事故中因为 bug 导致失效。

正常情况下，如果读取的数据与校验信息不匹配，那硬盘应该向操作系统反馈读取失败，有 bug 的情况下即使校验不通过，也被当作了正常数据。

第二层是存储后端层面的，以前 ceph 底层存储是建立在某种文件系统上的，这几年 bluestore 已经成熟，可以将硬盘本身作为块存储对待了，少了一层文件系统。由于替代了文件系统的作用，bluestore 默认是有写入校验信息的。但用户可以通过手工设定参数，在配置存储池的时候取消对应的校验。我说的禁用校验是说的这一层。

在这一层上 ceph 模拟了一个 fsck 行为，scrub 就是 fsck，可以是 metadata 层面的也可以是 object 层面的。我从来没有尝试过禁用校验，但极大概率禁用之后 fsck 将无法运作。

假如第二层的校验没有被禁用，那么静默错误是能够被定时 scrub 检测到的。

但为什么运维人员会自信地认为校验可以关闭，猜测是在迁移到 bluestore 之前，下面还有一层文件系统，出错会被发现。但由于 bluestore 替代了文件系统的作用，这个时候再关闭校验就不明智了。这里关闭校验确实可以加快迁移速度，符合公告中的说法。

第三层是对象或者说文件层面的了，这里可以简化为 VM 镜像文件。

更高层就是 VM 内虚拟硬盘上的文件系统了，比如 ext4 等等。

这里每一层的校验信息都是由当前一层处理的，异常就向更高一层反馈错误，并抛弃数据，正常的情况下，返回的是不包含当前层校验信息的纯数据。所以不存在什么校验信息已经存在，不需要再计算一次。默认情况下，仓库 II 读取到文件准备写入的时候，传递给 osd 的数据，会被 bluestore (libRADOS) 加上当前层的 crc32c 校验写入，osd 所在主机的 cpu 负责 crc32c 的重新计算，这个校验行为对于上层是透明的。

如果复盘事故，说发现错误的是腾讯就没意思了，腾讯的虚拟机三分钟就检测到了 VM 的异常，那是因为 VM 的 IO 请求由于 metadata 出错映射到了不该读写的位置上因而报错，真正感知到或者说校验层面上没通过是 VM 虚拟硬盘的文件系统发现的。此时 ceph 还认为 VM 镜像的块存储是正常的呢。

如果仓库 II 是按照合理的方式构建的（比如三副本所在硬盘来自三个不同批次），目前的推理也不需要更多假设。镜像迁移的过程中，复制读取出来的数据是正常的，但写入的第一个主副本恰好发生在了存在静默错误的硬盘上。按照 ceph 的架构，客户端只负责一次写入，由一个主副本复制出三个的过程是 ceph osd 内部完成的，一份错误扩散到了三份。这样就能解释为什么三副本会失效了。



腾讯这次事故给我的启示是，bit 级的错误比如 BitRot/SilentCorrupt 已经是个很严峻的问题了，目前硬盘自身的 BER 大概是 10^14~10^15 上下，差不多 12TB 的水平，这个数据量在今天不过是一块硬盘而已。虽然常用指标叫做 URE (Unrecoverable Read Error)，但实际错误的发生是写入的过程，或者是写入后发生了 bit 翻转等等，原因是错误只有被读取到的时候才会被发现。

这一次的问题就出在写入出错上，但即使硬盘没有问题，还是有可能因为宇宙射线等等原因造成写入错误，这才是问题的关键。但目前看腾讯无论是设计还是运维，都没有对这个问题有足够的重视。

至于八个九的可靠性，那就更不用说了，都是建立在软件万无一失，从来不会发生 BitRot/SilentCorrupt 这种事的基础上的，模型是有问题的，不然出了事情总不能都怨用户是那宇宙唯一吧。目前来说，大概真实的六个九就足够了，达到这个水平的意思是该去别的地方做工作了，比如完善运维机制，修订空间释放策略等等。

@zhuang #116
我只能说不要拿 ceph 硬套，不是只有 ceph 一种实现，也不是 ceph 的实现方式才是最好的。
腾讯 cbs 用的肯定不是 cbs，ceph 能正真意义上提供能拿来做虚拟机存储的性能也是最近的事，时间上是来不及的。
随手 google 了一个： http://www.sohu.com/a/160635754_505802

卤煮追根究底的态度让人敬佩。