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

[mhycy]

前言

源公告贴地址在此： 关于客户“前沿数控”数据完整性受损的技术复盘

昨日在 "腾讯云的事，是不是很多人以为三副本就是备份，不应该丢数据，很靠谱...." #28 帖子中做出了一些个人的推断

甚至有点怀疑是不是有人手动的“ rm -rf ”然后后续业务直接写花了集群

今天的这份公告的信息算是印证了部分的猜测

正文

公告中提到的部分细节因经验不足产生疑问，希望各位大佬可拍砖指教

---

疑问 1

在 14:05 时，运维人员从仓库Ⅰ选择了一批云盘搬迁至新仓库Ⅱ，为了加速搬迁，手动关闭了迁移过程中的数据校验；

一个按照高可用、高可靠、数据可信的原则构建的存储架构
显然读取过程中的块级校验是必不可少的，否则数据的可信性无从谈起
（因为根本不知道读取出来的数据是否为异常数据）

校验过程必然需要消耗一定的资源
类似于 ZFS, 需要大量的 CPU 资源进行读取过程中的校验
所以一般的实现方案会把存储与计算分离开来, 降低互相之间的影响

在公告中提到的一点 "为了加速搬迁"
为了实现读取过程中的校验，必然需要消耗一定的资源
独立的存储平台，自然也需要为了这个消耗的资源配备足量的运算资源
读取校验理应默认开启, 且对性能影响近乎无感 (增加了运算延迟)
而在这个公告中提到的"为了加速搬迁"...
那么....

• 什么情况下关闭校验可以加速搬迁？

---

疑问 2

在 20:27 搬迁完成之后，运维人员将客户的云盘访问切至仓库Ⅱ，同时为了释放空间，对仓库Ⅰ中的源数据发起了回收操作；

• 什么情况下才能让运维人员那么着急回收空间释放资源？

---

疑问 3

在 20:27 搬迁完成之后，运维人员将客户的云盘访问切至仓库Ⅱ 到 20:30 监控发现仓库Ⅱ部分云盘出现 IO 异常。

• 在线迁移为什么 14:05 分开始的数据迁移要到 20:30 分才发现 IO 异常？

(不了解腾讯云底层的实现架构, 学艺不精没想通, 望各位大佬回帖指教)

[lyl35023]

这个疑问 3 不成立，20：27 分才搬迁完成，然后将用户访问切到仓库 2。在搬迁过程中，访问还是打到正常的仓库 1 里的,所以不会在这期间发现仓库 2 的异常

[mhycy]

@lyl35023
一开始也是这么想的
但涉及到大量快照后增量数据同步的问题
而且...既然仓库 1 数据搬迁到仓库 2 的时候是错的，为什么业务能读取到正确数据？

[johnjiang85]

@mhycy 仓库 1 是 3 副本的，正常对读取到的数据块都有校验，只要不是 2 个以上副本错误都是可以读取到正确数据（这里迁移的过程中关闭了校验），并且会自动修正错误的一个副本。读取不到的数据块就需要常规巡检发现，但是巡检都是低优先级操作一搬速度很慢，巡检一次的周期会非常长。

[nullornull]

@lyl35023 一开始我也准备这么回复楼主,然后我想了下,就和楼主想法一样了.
@mhycy
我还有个疑问,复盘公告中说"当天上午 11:57，我们的运维人员收到仓库Ⅰ空间使用率过高告警，准备发起搬迁扩容",而公告中描述的"本次事故起源自因磁盘静默错误导致的单副本数据错误"好像并没有对仓库Ⅰ的数据的正确性造成影响,导致迁移的直接原因是"仓库Ⅰ空间使用率过高告警",这个空间使用率过高和磁盘静默错误有什么关系,还请各位大佬指教下.

[mhycy]

@johnjiang85
所以...什么情况下关闭校验可以提速呢？

[nullornull]

@johnjiang85 刚看到你的回复,我写的时候没有看到不好意思,多谢指教.

[mhycy]

@nullornull #6
参考 ZFS 的实现，块存储集群的一般而言实现类似于 ZFS，读校验绕不开
对不上 hash 就需要三副本读取修复，除非出现 hash 碰撞，那么需要等到巡检才能发现了

[johnjiang85]

@nullornull 第二篇技术复盘对了解分布式存储的人信息是足够了的，但即使是技术人员对分布式存储原理和机制了解的人并不多，确实还是会有一些疑问的。

[mhycy]

@johnjiang85
正因为了解，才产生疑问

[swulling]

@mhycy 如果了解就不会有这几个疑问了。

第二次技术复盘足够清晰

[mhycy]

@swulling 这就是第二次复盘暴露出来的问题，没敢把猜测写出来

[xud6]

疑问 1：
在 10G 以上的网络中，Hash 计算本身就能成为瓶颈，腾讯至少用了 40G，有部分应该用了 100G。

[mhycy]

@xud6 不会，具体可以查看各个处理器的 hash 性能，限制集群规模的瓶颈就在这

[xud6]

疑问 2：
因为 Thin provisionin。腾讯云好几个区域云硬盘经常缺货，剩余空间小是很可能的。可能当时已经到了不马上迁移就会因为剩余空间用完导致批量停机的情况。

[johnjiang85]

@mhycy
疑问 1： 什么情况下关闭校验可以加速搬迁。
分布式存储的读取校验并不是只是校验本副本的 hash （其实存储更多是 crc 校验本数据块，当并不是所有的存储都会有 crc 校验），而是说要把 3 副本的数据都读出来进行对比校验，这样关闭校验可以节省大量的磁盘 I/O，速度就算快不了一倍也差不多。

疑问 2：什么情况下才能让运维人员那么着急回收空间释放资源？
这个没什么疑问，就是源仓库空间水位太高，且写增长非常快，当然这些都不能把保留 24 小时变成立即回收，至少人员持续观察 30 分钟无异常还是必须要有的，所以不排除运维人员长时间工作疲劳、减少告警等其他原因。

疑问 3：前面大家有回复。

[qiuqiuer]

只能是疼讯的错

[mhycy]

@xud6 显然这就是问题

[mhycy]

@johnjiang85
疑问一与现实有出入，建议参考 zfs 原理

疑问二暴露出的问题就不多说了

疑问三在实际架构流程公布前无法得到正确答案

[johnjiang85]

另外还有些概念需要科普下，存储计算分离一般是对业务来说的，存储本身的存储和计算是一体的，是按照计算好的配比提前配置好的存储和计算资源的配比，当然计算资源确实不会成为瓶颈。

[mhycy]

@johnjiang85 #19
所以可能性就只剩下一个了

另：前一个回答关于 IO 描述有误
块数据 hash 和块自身是一体的且一般不是 CRC 算法
读取过程中如果没有校验出异常只会产生一次磁盘读取请求
所以开不开校验应该没有太大区别
除非。。。