这是一个创建于 2781 天前的主题，其中的信息可能已经有所发展或是发生改变。
前言
源公告贴地址在此： 关于客户“前沿数控”数据完整性受损的技术复盘
昨日在 "腾讯云的事，是不是很多人以为三副本就是备份，不应该丢数据，很靠谱...." #28 帖子中做出了一些个人的推断
甚至有点怀疑是不是有人手动的“ rm -rf ”然后后续业务直接写花了集群
今天的这份公告的信息算是印证了部分的猜测
正文
公告中提到的部分细节因经验不足产生疑问，希望各位大佬可拍砖指教
疑问 1
在 14:05 时，运维人员从仓库Ⅰ选择了一批云盘搬迁至新仓库Ⅱ，为了加速搬迁，手动关闭了迁移过程中的数据校验；
一个按照高可用、高可靠、数据可信的原则构建的存储架构
显然读取过程中的块级校验是必不可少的，否则数据的可信性无从谈起
（因为根本不知道读取出来的数据是否为异常数据）
校验过程必然需要消耗一定的资源
类似于 ZFS, 需要大量的 CPU 资源进行读取过程中的校验
所以一般的实现方案会把存储与计算分离开来, 降低互相之间的影响
在公告中提到的一点 "为了加速搬迁"
为了实现读取过程中的校验，必然需要消耗一定的资源
独立的存储平台，自然也需要为了这个消耗的资源配备足量的运算资源
读取校验理应默认开启, 且对性能影响近乎无感 (增加了运算延迟)
而在这个公告中提到的"为了加速搬迁"...
那么....
- 什么情况下关闭校验可以加速搬迁？
疑问 2
在 20:27 搬迁完成之后，运维人员将客户的云盘访问切至仓库Ⅱ，同时为了释放空间，对仓库Ⅰ中的源数据发起了回收操作；
- 什么情况下才能让运维人员那么着急回收空间释放资源？
疑问 3
在 20:27 搬迁完成之后，运维人员将客户的云盘访问切至仓库Ⅱ 到 20:30 监控发现仓库Ⅱ部分云盘出现 IO 异常。
- 在线迁移为什么 14:05 分开始的数据迁移要到 20:30 分才发现 IO 异常？
(不了解腾讯云底层的实现架构, 学艺不精没想通, 望各位大佬回帖指教)
 | 1 lyl35023 2018 年 8 月 8 日 这个疑问 3 不成立，20：27 分才搬迁完成，然后将用户访问切到仓库 2。在搬迁过程中，访问还是打到正常的仓库 1 里的,所以不会在这期间发现仓库 2 的异常 |
 | 2 mhycy OP |
 | 3 johnjiang85 2018 年 8 月 8 日 @mhycy 仓库 1 是 3 副本的，正常对读取到的数据块都有校验，只要不是 2 个以上副本错误都是可以读取到正确数据（这里迁移的过程中关闭了校验），并且会自动修正错误的一个副本。读取不到的数据块就需要常规巡检发现，但是巡检都是低优先级操作一搬速度很慢，巡检一次的周期会非常长。 |
 | 4 nullornull 2018 年 8 月 8 日 |
| 5 mhycy OP @johnjiang85 所以...什么情况下关闭校验可以提速呢？ |
| 6 nullornull 2018 年 8 月 8 日 @johnjiang85 刚看到你的回复,我写的时候没有看到不好意思,多谢指教. |
| 7 mhycy OP |
| 8 johnjiang85 2018 年 8 月 8 日 @nullornull 第二篇技术复盘对了解分布式存储的人信息是足够了的，但即使是技术人员对分布式存储原理和机制了解的人并不多，确实还是会有一些疑问的。 |
| 9 mhycy OP @johnjiang85 正因为了解，才产生疑问 |
 | 12 xud6 2018 年 8 月 8 日 疑问 1： 在 10G 以上的网络中，Hash 计算本身就能成为瓶颈，腾讯至少用了 40G，有部分应该用了 100G。 |
| 14 xud6 2018 年 8 月 8 日 疑问 2： 因为 Thin provisionin。腾讯云好几个区域云硬盘经常缺货，剩余空间小是很可能的。可能当时已经到了不马上迁移就会因为剩余空间用完导致批量停机的情况。 |
| 15 johnjiang85 2018 年 8 月 8 日  4 @mhycy 疑问 1： 什么情况下关闭校验可以加速搬迁。 分布式存储的读取校验并不是只是校验本副本的 hash （其实存储更多是 crc 校验本数据块，当并不是所有的存储都会有 crc 校验），而是说要把 3 副本的数据都读出来进行对比校验，这样关闭校验可以节省大量的磁盘 I/O，速度就算快不了一倍也差不多。 疑问 2：什么情况下才能让运维人员那么着急回收空间释放资源？ 这个没什么疑问，就是源仓库空间水位太高，且写增长非常快，当然这些都不能把保留 24 小时变成立即回收，至少人员持续观察 30 分钟无异常还是必须要有的，所以不排除运维人员长时间工作疲劳、减少告警等其他原因。 疑问 3：前面大家有回复。 |
 | 16 qiuqiuer 2018 年 8 月 8 日 via Android 只能是疼讯的错 |
| 18 mhycy OP |
| 19 johnjiang85 2018 年 8 月 8 日 另外还有些概念需要科普下，存储计算分离一般是对业务来说的，存储本身的存储和计算是一体的，是按照计算好的配比提前配置好的存储和计算资源的配比，当然计算资源确实不会成为瓶颈。 |
| 20 mhycy OP @johnjiang85 #19 所以可能性就只剩下一个了 另：前一个回答关于 IO 描述有误 块数据 hash 和块自身是一体的且一般不是 CRC 算法 读取过程中如果没有校验出异常只会产生一次磁盘读取请求 所以开不开校验应该没有太大区别 除非。。。 |
 | 21 firefox12 2018 年 8 月 8 日 1 不知道 都在讨论些什么东西，首先 腾讯不能承认 自己没有 3 备份， 也不能承认是存储程序出现问题。因为第一 如果存储程序出现问题，那么其他所有人的数据怎么办？这个后果太可怕。 如果没有 3 备份，那么就是虚假宣传，这也是不能接受的。3 备份的话，以我的经验看，其实很少有存储这么做了，因为成本太高。现在都是 9+3 这种所罗门做法。 好了 就算它是 3 备份，其实逻辑上也是不对的，因为 3 备份都是程序自己实时备份的，从来没听说过 ops 手动备份的，即使要迁数据，也是程序迁。因为如果备份靠 ops 手动备份的话，3 备份的意义就不存在了。你 ops 一天没有备份，你的 3 备份意义何在？ 所以 以上 2 点不能触碰的前提下，只能让一个操作人员背一下，其实最容易出问题的就是操作人员，他手一抖可能就真的没了。因为架构设计上的问题，也许很多东西就真的找不回来了。 也许真相就是操作手抖，但是这个宣布出来，腾讯的声郁 也就完了，因为你不知道 那天你的数据就会被手抖，所以 运维手抖也是不能被提及的。 所以 目前的解释 是最好，也是最可以说得通的。至于背后的真相 只有他们内部知道了。 最后说一下 赔偿，这里的人觉得 1000 多万的赔偿请求是合理的，这种人不是傻就是坏。 你也买过硬盘，你硬盘坏过没有？你让希捷 西数赔你 100 个亿了？ 腾讯的云计算没有打保票说 100% 安全，该赔多少按照法律来。我在 aws 上运行个虚拟机，突然卡死了里面运行的程序说不定能让中国超过美国呢， 我是不是要让 aws 赔个 10 亿给我？ 说起这个 我只想说腾讯的危机处理真的太弱了， 阿里家直接把用户的可执行程序都删除了，那家要求赔钱了？谁敢要求赔 1000 万啊？ 谁说可执行程序没有价值吗？万一世界上就这么一份了呢？ |
| 23 firefox12 2018 年 8 月 8 日 最后提一句 如果是 3 备份方式，有一块硬盘静默错误，但是备份应该是实时发生的，至少另 2 块盘的数据应该是正确的，并不会出现 3 块盘都有问题数据的情况。所以 这份通告 看看就可以了。 |
| 24 johnjiang85 2018 年 8 月 8 日 1 @firefox12 云的块存储因为要求高 IOPS，一搬都是 3 副本的。EC 纠删码性能要比三副本低很多，尤其是在数据有频繁随机读写（主要是修改）的时候，性能差距太大，一般用在对成本控制比较严且对随机读写性能要求不高的场景。 |
| 25 firefox12 2018 年 8 月 8 日 @johnjiang85 但是出问题的是对象存储吧？ |
| 26 johnjiang85 2018 年 8 月 8 日 这里貌似迁移的过程中关闭了校验，且正好选中了静默错误的这块盘作为迁移源，没有和其他 2 个正确副本做校验，直接读取到了错误的数据(磁盘静默错误会导致数据块本身的 hash/crc 校验失效不会报错，除非存储系统自己加了额外的数据块校验信息并且进行校验)，写入到了仓库 2 的 3 个副本中就都是错误的，因为分布式存储一般写入只会写入校验信息，并不会进行实际的校验，只有读取的时候才会做数据校验 |
| 27 johnjiang85 2018 年 8 月 8 日 @firefox12 出问题的是 CBS，块存储，且是系统盘。 |
| 28 johnjiang85 2018 年 8 月 8 日 1 @johnjiang85 腾讯云的对象存储叫 COS，默认高频是 3 副本，低频是 EC 纠删码存 1.33 份，可以自己选。 |
| 29 xud6 2018 年 8 月 8 日 1 @firefox12 这里的 3 备份是三向镜像，类似 raid，和一般的备份不是一回事。而且这次是从一个存储系统迁移到另一个存储系统，而三向镜像发生在存储系统内。 |
| 30 mhycy OP |
| 33 johnjiang85 2018 年 8 月 8 日 @mhycy 我并不是做存储的，主要是做网络的，存储了解，但没做过，具体架构细节我也不清除。 |
| 34 johnjiang85 2018 年 8 月 8 日 @mhycy 存储了解的意思是了解部分分布式存储的原理，但不了解出问题的 CBS 的架构。 |
| 36 firefox12 2018 年 8 月 8 日 @johnjiang85 好吧 cbs 块存储， 你家的 3 备份机制，写的时候不校验 checksum 就直接写进去的？ 一块硬盘静默错误，写的时候数据是对的，但是那读的时候读不出来，但是另外 2 块写的也是正确数据。否则 3 备份的内容不一致了，最后听谁的？对了 你会说延迟写， 你延迟多久啊？一天一个月？ 你一个月备份一次 那叫 3 备份？ 好了 按照这个通告说法， 磁盘静默错误， 本身第一块盘的数据全掉，然后读的时候，关掉了校验，但是也能读出来，什么错也没有，所以也没有发现问题，然后错误的数据把 2 块本来有好的数据的盘也覆盖了。然后又删除了第一块磁盘的数据。 怎么说 另外 2 快盘上还应该能恢复出上次备份的一个版本。哪怕 10 天前，1 个月以前的。对不起空间不够，也全都删除了？真这样的话， 另外 2 快盘上的数据是可以实验室开盘恢复出来的。请恢复一个老版本把？ |
| 37 johnjiang85 2018 年 8 月 8 日 @firefox12 建议你先看下公告的具体内容吧。 |
| 38 mhycy OP @johnjiang85 #26 块级校验码与块数据同步存放在一个物理块上，静默错误不可能让块校验码与块数据对的上号的 难道数据 00 的校验码等于 00 ？ 如果读取校验实施正确的话，理应是不造成过于严重的性能瓶颈的，除非计算资源与存储规模失配 且，三副本基于成本考虑理应可以提供类似 R0 的同步读取能力，读 IO 高写 IO 低 （由主控节点发起的并行写入，有同步开销） 直接杜绝了直接访问的可能... 如果真如回复的这样，可以以某个数据源作为源进行数据拷贝源.... 这暴露的问题更为严重啊 |
| 39 johnjiang85 2018 年 8 月 8 日 @mhycy 静默错误是有可能导致磁盘本身的块校验时效。存储系统的块校验和三副本校验公告是迁移过程中把校验关了，根本没校验，这个就是严重的问题。。。 |
| 40 firefox12 2018 年 8 月 8 日 因为分布式存储一般写入只会写入校验信息，并不会进行实际的校验，只有读取的时候才会做数据校验。 绝对不会。这样会造成多端数据不一致。没有一个可以判断的标准。 而且写的时候都是 stream 流，根本没有任何压力。考虑到断线恢复的情况，对写入流进行 checksum 检查是最基本设计。 还有你说复制数据没有开校验，也就算了。但是老副本去了哪里呢？直接被新数据覆盖在上面吗？那家文件系统新文件是直接覆盖掉老文件的？所以，要么就是没有老副本，要么就是老副本很早以前就一直是错的了。 最后没点数了，不回了。 |
 | 41 PP 2018 年 8 月 8 日 via iPad 感谢楼主及评论部分中各位 V 友的讨论，非常务实，非常有帮助。 腾讯云给出了复盘声明，我想接下来社会力量要做的应该是设计和进行复现实验，只有通过复现来完全还原前沿数控和腾讯各自描述的关键细节，那么腾讯的复盘声明才是可信的，除此以外别无他法。 前沿数控蒙受了重大损失，后续处理也比较慌乱，特别是将技术诉求和商业诉求混为一谈，甚至没有考虑采取法律手段。尽管前沿数控在这一事件中存在一系列的业余和教训，但是具体涉及商业和法律的事务还是由前沿数控自己处理比较好，看客帮不上忙。 腾讯云对事故进行的调查，从时间上看是不及时并且不主动的，这同腾讯云的业务稳定性和长期商业利益相悖。复盘结论在被社会力量充分浮现之前只能作为腾讯云一家之言，对事故受害方前沿数控进行善后是腾讯云的当前责任，如何提升业务稳定性并且逐渐恢复市场信心会是腾讯云今后很长一段时间内的常规工作重心。 技术人员在这一事件中应该大有收获。质疑和讨论是正题，掐架和捉贼是失焦。很高兴通过许多 V 友的评论和讨论学习到了新的知识和思考方法，这里一并致谢！同时，非常期待这次事故的实验复现。 |
| 42 johnjiang85 2018 年 8 月 8 日 @firefox12 写入会计算校验信息并写入，但是不进行校验是我了解的原理，工程实现怎么做的细节不清除。 老副本的问题还是去看下公告的第二个违规操作吧，数据立马会收掉了，仓库 1 还一直有非常多的客户再写入的。也就是楼主的疑问 2. |
| 43 mhycy OP @johnjiang85 前提不存在，校验计算是接收到写入请求后在内存中进行计算 为了避免计算结果错误建议是使用 ECC 内存（应该没哪家是 DIY PC 做存储服务器吧？） 三副本的存储架构原则上根本不允许外部请求直接访问指定的节点，一切都是随机化 因为外部请求到达存储节点后几乎不可能有持续读取的可能 既然都是随机请求那么也没有把请求压到特定某个存储节点的必要了 这暴露出来的问题... |
| 44 johnjiang85 2018 年 8 月 8 日 @firefox12 我的意思是写入的时候不校验计算出来的块校验信息，3 副本之间的校验信息对比肯定要做的。 |
| 45 johnjiang85 2018 年 8 月 8 日 @mhycy 实际的用户访问业务系统确实是你说的，随机（ hash 或者 range 或者 hash+range ）打散的，但是数据迁移据我了解没去做随机打散访问请求，就是指定的其中一个副本去访问的，这里的流程是有问题的。 |
| 46 PP 2018 年 8 月 8 日 via iPad 1 更正： “复盘结论在被社会力量充分浮现之前只能作为腾讯云一家之言” 应为 “复盘结论在被社会力量充分复现之前只能作为腾讯云一家之言” |
| 47 johnjiang85 2018 年 8 月 8 日 @mhycy 当然一个副本也是随机散列到不同磁盘上的，所以这里其实并不是数据完全丢失，其实是丢失了一部分数据，主要是部分系统元数据从这块磁盘上读的错误，影响了更多的实际数据。 |
| 48 xud6 2018 年 8 月 8 日 1 @mhycy #36 随机访问和持续读写的速度有很大差距，机械盘更加明显。计算资源与存储规模匹配是按照正常工作负载进行的。对虚拟化系统存储，随机访问是正常的工作负载而持续读写只有在少数情况下才会出现。至于造成性能瓶颈，可以看 zfs 的 sha256。 RAIN 工作和 RAID 类似，正常工作中同一个 IO 操作只会访问一份数据，除非出错（或校验失败），本质上就是以某个数据源作为数据拷贝源，只是粒度更细。 |
| 49 firefox12 2018 年 8 月 8 日 @johnjiang85 写入不校验块校验信息是不存在的，如果是这么设计的话，那么比现在掉了一个用户的信息还糟糕。tx 存储我还是认识人的，他们没这么弱。 仓库 1 没空间删除数据可以接受，仓库 2 3 复制出错误数据也可以解释。那么仓库 2 3 的上一个副本去哪里了呢？难道仓库 2 3 也没空间，老副本赶紧都删除了？还是说错误的新副本把老副本给覆盖了？ |
| 50 johnjiang85 2018 年 8 月 8 日 @mhycy #43 我#45 #47 的回答想了下确实是有问题的，因为我也不了解细节，我了解到的信息也只是公开的故障复盘报告。所以应该还是去随机访问的，但是正好访问到了出问题的这个副本的这个磁盘，导致读取到了错误的数据，并且没有进行校验。 |
| 51 mhycy OP @johnjiang85 随机 -> 等效随机，不是实际随机 块与校验数据是一体的，写入的时候三副本并行写入必然三副本都会存在理论上一致的块，不做回读校验可以理解 但从你的回复中似乎理解错了这个校验数据的位置 另外，数据迁移如果请求源位于存储的主控节点，由集群的主控集群对外提供块存储访问请求支持的话 对于一个有着正常业务的三副本存储集群最底层的存储节点就根本不可能获得真正的顺序读取请求，一切都是随机 对于这类集群缓存是极其重要的，除非为纯固态集群。 既然要做缓存，那么直接访问指定节点的可能性就不存在了 毕竟涉及到一个很重要的问题：数据副本同步 这也是疑问 3 没想通的 既然是迁移，既然是同步，自然需要尽可能少量数据进行快照后的增量数据同步 正常说迁移一个镜像： 快照，同步数据，同步快照后增量，剩余数据到某个阈值 最高优先级断流同步，再重新服务，这是理想的无停机迁移 （也可以让集群 2 作为代理访问集群一的原始数据的同时同步到集群 2，但读延迟会增加） 对于业务来说近乎无感（实际上至少有百毫秒级的 IO 断流或者延迟） 为何是到 8 点多的一刀切切换？难道是停机迁移？ |
| 52 johnjiang85 2018 年 8 月 8 日 @firefox12 只有仓库 I 和仓库 II， 仓库 II 中的 3 副本数据因为读取就是没校验的错误数据，写入的全错；仓库 I 中 3 副本 1 份错误的，2 份正确的，正常的操作都不会有问题，也可以自动修复。但是把客户的操作切到仓库 II 之后，仓库 I 的数据回收就会把 3 个副本全部删除掉了，然后其他客户的写入又会把这 3 个副本原本的数据空间覆盖掉。 |
| 53 mhycy OP @xud6 #48 所以缓存很重要，ZFS 的原理和性能瓶颈是知道的，块存储集群其实也是为了解决这类问题 所以 CPU 资源配备理应足够，但感觉更大的瓶颈在内存上面，毕竟运算是需要数据来回搬的 具体没见到实现也不好说什么，只是。。。看起来。。。。计算资源是没配够了。 > RAIN 工作和 RAID 类似，正常工作中同一个 IO 操作只会访问一份数据，除非出错（或校验失败），本质上就是以某个数据源作为数据拷贝源，只是粒度更细。 关于这个，只能说别忘了这是 3 副本，不是 RAID-Z/Z2/Z3, 是 RAID1.... |
| 54 johnjiang85 2018 年 8 月 8 日 @mhycy 嗯对，就是写入的时候是没有回读校验的，毕竟我也只是半把刀，有些名词不提就想不起来。 缓存是有的，但是迁移没有通过缓存。 具体的迁移流程细节就完全不清除了，理论上应该是这个流程，镜像加快照流水。 |
| 57 johnjiang85 2018 年 8 月 8 日 理论、协议和工程实现有时候差距还是不小的，尤其涉及到具体管理的时候，也不能说一定就是坑吧，当然具体实现我也不了解。 |
| 58 mhycy OP |
| 59 mhycy OP @johnjiang85 #57 期待技术细节分享 |
| 60 johnjiang85 2018 年 8 月 8 日 @mhycy #58 我找人问了下，确认是 SSD |
| 61 johnjiang85 2018 年 8 月 8 日 @mhycy #59 我并不是 CBS 存储的产品和研发部门的，是其他部门的，细节要看后续有没有架构分享之类的内容了。 回这篇帖子主要是也了解过分布式存储的一些东西，虽然没有做过，并且这个帖子是在讨论技术，而不是在互怼。 |
 | 63 yanhao1991 2018 年 8 月 8 日 一直以为他们宣传的三副本是指数据很安全。。。 |
| 64 xud6 2018 年 8 月 8 日 @yanhao1991 三副本只是 RAID10 的升级版而已。而且云存储硬盘的可靠性要比普通企业级低，比企业级 raid10 高不了太多。 |
 | 65 autogen 2018 年 8 月 8 日 迁移完成之后要做好验证，灰度切流量，发现错误马上回滚； 把磁盘容量告警调低一些，留出 1~7 天的写入量，这样就不用急着删； 要按照公司的规定来做事，出事了可以怪研发 怪测试 怪服务器供应商，免得砸自己饭碗 |
| 66 mhycy OP |
| 68 mhycy OP @johnjiang85 #60 SSD 的低延迟架构说实在有点超出我的知识范围了，期待各位大佬的科普 |
| 71 johnjiang85 2018 年 8 月 8 日 @mhycy #68 这个我也不清楚了。 #67 可能之前没有正确理解的意思，疑问 3 是否是迁移过程中仓库 I 的读取到这个磁盘的请求也一直没有报出 I/O 错误？ 我的理解可能是这样的，首先是只是部分数据读出来的不一致，并不是所有数据，且这部分数据大部分数据是冷数据，存在读取很少或根本没有读取到情况；仓库 I 一直正常的完整读取，即使是读取到这个副本的错误数据，校验失败，但是直接读取其他两个正常的副本进行了校验，在业务方看来读取是正常的，错误数据占比非常小，根本达不到报警的阈值， 只是排队去做异步修复了。 只是个人推测。 |
| 72 johnjiang85 2018 年 8 月 8 日 因为磁盘可以正常读取，不会报错，只是读出来的数据不对，也不会触发硬件的异常告警。 |
| 73 xud6 2018 年 8 月 8 日 @mhycy #66 作为参考 azure 在三向镜像之下用的 raid5。而且按微软说法 raid5 只是为了维护方便(blind swap)，在数据安全性上的意义不大。 |
| 75 mhycy OP @johnjiang85 问题泄露出来了底层架构的不合理, 加紧改善吧.... |
 | 76 jianpanxia 2018 年 8 月 8 日 看楼主一直拿 ZFS 来反推，我就问问楼主对分布式存储很了解？分布式存储就类 ZFS 一种架构？ TX 用的就和 ZFS 架构一样？ |
| 77 mhycy OP @jianpanxia 望科普！ |
| 78 johnjiang85 2018 年 8 月 8 日 @mhycy 75 目前从实际应用来看架构上除了存储集群太小（具体多大算大 /小 /合适，这个数据我也没接触过，不清楚）之外，对应的疑问 2，其他的没看到什么硬伤，毕竟运行了这么多年，更多的是流程、规范和细节上（比如计算资源配比、存储容量告警阈值等）可优化的点。 |
| 79 mhycy OP @johnjiang85 疑问二其实是个商业问题，直接点说就是超售严重 至于架构上的问题，不能说运行多年相安无事就是合理且优质的 至少从这个事件上看，还有提升的空间 希望将来能有对应的技术分享 让我们可以深入了解云平台架构设计的前因后果 这也能让客户可以更加的放心 |
| 80 nullornull 2018 年 8 月 8 日 @mhycy 楼主,我有个建议,不知是否合适,我通读完这个主题,准备把你的疑问以及大家目前认可的答案,以及对此合理的推测,相关建议整理出来,但是我发现这个还是楼主做比较合适,不知道楼主有什么看法,这样对关注此问题的人也很有帮助. 当然我也和楼主一样期望腾讯云后续会有更细节的技术分享,这样不仅可以让使用腾讯云的客户放心,也可以表明腾讯云对这方面的态度. |
| 81 mhycy OP 1 @nullornull 其实，题中的疑问心中早已有答案，虽说是依据现有的公告进行推测... 但没有技术资料的支撑，一切只凭经验，这样的答案显然是不适合写出来的，毕竟有失严谨... 最终发出一些对细节的疑问，让各位自行推测，也能在讨论的过程中相互学习增长见识... 总结的话大概是没有的，毕竟不同的人有不同的看法，不同的业务有不同的方案。 就事论事的讨论问题，并冷静的表述自己的看法，以理服人 在讨论过程中互相学习增长经验，这才是 V 站该有的氛围 |
 | 82 pinews 2018 年 8 月 8 日 2 对公告的楼主的个人理解 第一，元凶“磁盘静默错误”到底是个什么东西？是硬盘 bug ？在数据转移前，这个 bug 就存在，但是在数据转移后才发生错误，在正常使用下，bug 其实没事，换言之，应该该是腾讯的数据转移工具也是采用的默认设置，且没有测试出 bug 的情况下最终引发问题的，仅仅说磁盘 bug 是不准确的。 第二，事件的起因，是仓库 1 空间使用率额过高转移到仓库 2 的，个人认为即便是云盘大小可调会引起使用略变化，但正常情况下，磁盘使用率不应该像 CPU 使用率这样变化不定的，而是规划了多少个用户之后，不在容纳新用户，新用户会使用另外一块磁盘，但这里将以磁盘使用率高为名，将老用户转移到新仓库，再回收老仓库不合理。十一事情的真正原因可能就是大家所说的超售，超售就是给你多少 G 硬盘，实际没那么多，因为你当时也没用到那么多，所以没什么问题，但在于销售沟通出现问题的时候，就出现紧急转移新硬盘的事件了。 第三、数据校验是什么，为什么没有按规范校验数据，个人认为你从网上下载一个操作系统，然后开始安装，却老出现错误，后来发现是下载的系统有问题，原来用的是迅雷，你下载地址没问题，但是迅雷给你的数据是从另一个地址来的，这种情况下我们本地校验和网上对的对比就行了，但是很多情况下我们从网上下载东西不会去校验，但对数据安全来说就必须校验。 第四、为什么没有按规范操作区校验，以及早早删除了原来的数据，在其他帖子里大家都说运维背锅，因为在小公司根本就没有流畅规范，全靠运维个人水平来避免错误的，只有在中等公司，才会在有规范当时培训监督不严格的情况下发生违反规范的情况下发生，对于腾讯这样的公司，这种情况应该是不可能发生的，所以只有一种情况，由规范之外引发的特殊情况要求运维去操作，既然不在规范内，这时候按规范来操作就来不及了，而且运维没必要给自己不痛快，所以极有可能是在领导默认下没有按照规范操作的，而领导的无奈可能其他部门的施压无奈破例，源头再次指向超售。 第五，可靠性是什么？硬件可靠性不高，可以通过硬件软件的相互配合来提高可靠性，硬件技术都是现成的，所以你可以宣传你的可靠性是多少，但前提一就是按规范来操作，当硬件不可靠的时候，发现改正不可靠，如果没按找规范操作，的确大部分情况下仍然是不会出问题的，只是就几率来说其实降低了成千上万倍了。 第五，楼主所担忧的更大的问题是什么呢？按规范来操作，可靠性是比较高的，没什么好喷的，但是是什么原因导致不按规范来操作的？说白了还是管理混乱的问题，当其他部门超出要求，必然会超过技术承载能力，超出承载能力，必然带来不规范操作，其结果可想而知。 |
 | 83 zhuang 2018 年 8 月 8 日 8 云存储行业相关，我就经验做下推测，不代表我在腾讯这次事故上的立场。 首先是一些基础判断： 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 之后三分钟就发现异常了。 |
| 84 pinews 2018 年 8 月 8 日 1 所以第二份公告的目的其实就是运维（临时工）背锅，真正的原因被掩盖，大家也难以真正放心。 |
| 85 mhycy OP @zhuang #83 获益良多，虽说部分观点与现在的公告逻辑略有出入 毕竟按照公告说法，异常在源数据仓库不在目标数据仓库，写入异常不成立 关于疑问三其实是没想通为什么是一刀切形式的仓库切换 按理说所有在线的虚拟机都需要一个短暂的快照后增量同步的操作 或许这 3 分钟就是重定向 IO 后的增量同步过程吧。 但...三分钟时间内删除了源数据？不太敢想... |
| 87 mhycy OP @webjin1 本来存储系统搭建的原则也是用最便宜的零件构造足够可靠的系统（虽说这个可靠是要看场合的）... 所以家用 NAS 从不推荐红盘、紫盘、黑盘、企业盘 （显然做不到这一点用高价零件的可靠性也是差不多的） |
| 88 zhuang 2018 年 8 月 8 日 2 @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 （通过读取来验证数据状态）完成，还是有机会发现差异的。 三分钟删除源这是策略层面的问题，可能是过于自信了吧。 |
 | 89 akira 2018 年 8 月 9 日 @zhuang 从 tx 的声明里面看，他们的迁移是手工作业，这个个人觉得才是最难理解的地方。 至于迁移完成后立刻删除源的原因，因为仓库 I 要满了呀，所以运维才会发起迁移动作，迁移完毕以后当然就是要释放仓库 I 的这部分空间了呀 |
 | 90 nciyuan 2018 年 8 月 9 日 via Android 我靠了 23333，我发那个没人看 2333 我观点是，根据我之前发的帖子来说，腾讯云的云硬盘同步原则应该是服从多数原则，因为 TX 云说的是因为仓库搬迁，我不知道他说的这个仓库是物理上的机柜之间进行搬迁，还是说在网络内的 Copy 和 Paste，因为云硬盘本身也是物理硬盘阵列上虚拟出的一个空间，而物理空间不足，不选择加磁盘，也不选择物理移动，而是转移数据，真的是富到家里有带宽了。然后呢是在迁移的时候没有开启数据校验，但可是如果说存在 3 备份的话，那么其一定是有一个主从绑定关系的，如果你三副本一起换硬盘，那么三副本就是一坏两个好(因为当时说一块硬盘的元数据挂了)，然后呢数据完整的迁移过去了。即使回掉仓 1 的数据，仓 2 应该是一坏两好，当然因为这个是搬迁扩容，不可能说数据在网络传输的过程中损坏，或者物理搬运损坏的。因为按第二公告的说的两次失误来说，这和主盘错误，未经检验就同步两仓库无关，应该也不会有从一个盘直接复制三份这种傻帽行为。另外是第一个公告说文件系统元数据损坏，并且是该主控的 bug 引发静默错误，但是我觉得如果读写不一致，应该早就发现了，毕竟硬盘不可能一块一块买，metadata 丢失，新硬盘能跑起来？毕竟这个不是校验的问题，系统跑不起来不可能不报警吧？ |
 | 91 ryd994 2018 年 8 月 9 日 via Android 会不会是关了校验，并行读取？ 因为开校验的话就要同时读 3 份数据 网络带宽不成问题 写入的时候复制 3 份同时写 迁移的负载不能影响正常业务，所以迁移优先级最低，不能使用全部读取能力。写入侧是空机，所以满速写入 @nciyuan 家里有带宽才能开云啊，内网带宽几十 G，只要不影响正常业务，干嘛不用 |
| 92 ryd994 2018 年 8 月 9 日 via Android |
| 93 ryd994 2018 年 8 月 9 日 via Android @mhycy #87 讲真，my book 比桌面版 wd 硬盘便宜，拆出来反而是企业级的氦气盘体 我现在的 NAS 就是 raidz2，6 盘 nas 备份计划？不存在的……又没什么重要数据，纯属玩票性质 |
| 94 zhuang 2018 年 8 月 9 日 1 @akira 我前面解释过，如果是 ceph 方案，逻辑上的满了和物理上满了是两回事。迁移完成后多久删除源数据是个策略问题，这里确实不妥。 举个例子，EC (7+2) 编码 12 盘方案，可以容忍两盘失效。实际上安全存储空间只占存储池的 10/12，这是因为一旦发生 2 盘损坏的情形，ceph 会将重建的部分写入剩下的 10 盘。另外由于分布式存储 deterministic 的分配算法，总共 9 分块写入 12 块硬盘中，各个硬盘的写入量可能并不均衡。从我的经验来看，要么根据一个警戒标准提前进行扩容，要么根据实际的增长速率来预期扩容。 第二个问题是，手工操作是不是意味着运维水平低？ 从运维的角度上说，区别是不是手工仅仅从一两行描述是看不出来的。这个例子里，扩容是一个引入新设施的过程，从具体的硬件搭配到软件参数的调试都离不开人类决策，敢于线上迁移（相对离线迁移）很大程度上说明对于运维的水平有自信。（如果一切真如公告所说的话） 我的看法是取决于这样的迁移行为是不是频发，如果是，有没有固定的工作流程，这样的工作流程是否能纳入日常审计范围，异常处置又是什么模式。理想情况，这个运维行为可以无人值守双向可逆，但事实情况能够人工介入回滚已经是非常好了。 对于整个事件，如果要我表个态，我会认为腾讯的软件系统存在设计上的不足，没有对 BitRot/SilentCorruption 做应对。但运维水平方面不好判断，一方面能看到自信到爆表的线上迁移行为，另一方面又是激进到难以置信的回收策略……我觉得更大的可能是公告不可信吧。 |
 | 95 songxinyingpg 2018 年 8 月 9 日 2 作为一个 ceph 初级工程师，我觉得腾讯云第二次解释挺清楚的。如果用的是 ceph 的话，使用过程中关闭 scrub （校验）也不是没有，前东家就这么干的，毕竟 scrub 消耗磁盘性能。读的话只从主副本读，刚好静默错误发生在了主副本上，数据拷到新集群，上面三个副本存的都是出了错的数据。这样就 GG 了，感觉挺合理的。 楼上有人说三副本可能实际上用的 EC，我没进过 bat 这种大厂，但见过的环境说副本的就是用副本，ec 是便宜，但底层用了 ec 还敢宣称是三副本的感觉是有点石乐志。亚马逊好像有个冰川存储，那个应该是 ec，因为便宜。 |
 | 96 lyhiving 2018 年 8 月 9 日 1 腾讯云这次公关水平为零。 做错按照规矩陪就是，客户不满意就赔到满意。谁叫你做错了？ 只要稳住一波，宣传成本都剩下好几百万了。现在看来，中小企会被阿里完全收入囊中。 腾讯云做了两件事是送人头的： 1、过早提及营收，这次时间跟之前送券连夜截回事件相当于口碑扫地。送券截回伤站长，数据丢失伤企业客户。谁还会把东西放你这？或者说大头放阿里，备份放腾讯会成为日后通识。 2、过分强调备案转移。不是腾讯云接入的一律不让放，那你要知道有多少是阿里的。之前打的价格战不就是白忙活了么？ 这样的情况，我一直在想，腾讯云就是为了做大点，随时准备卖身给阿里的 :) 要不然前期也不会那么积极送人头。 股价跌了也不要慌啊，盘子还在呢？做云计算的前期有谁不亏点呀。 |
| 98 mhycy OP @songxinyingpg #95 请教，scrub 消耗磁盘性能的原因在哪里？ |
| 100 mhycy OP |
Select Language