zerotier

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

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

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

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

@nullornull

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

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

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

@johnjiang85
疑问二其实是个商业问题，直接点说就是超售严重

至于架构上的问题，不能说运行多年相安无事就是合理且优质的
至少从这个事件上看，还有提升的空间

希望将来能有对应的技术分享
让我们可以深入了解云平台架构设计的前因后果
这也能让客户可以更加的放心

@jianpanxia 望科普！

拔掉一个 R6 阵列的 3 个盘......
ESXI 的母机操作系统挂了.....

@johnjiang85
问题泄露出来了底层架构的不合理, 加紧改善吧....

@xud6 #73
果然是用最省钱的方案构造最可靠的云...

@autogen #69
建议重新阅读坛内的过往的回复...

@johnjiang85 #60
SSD 的低延迟架构说实在有点超出我的知识范围了，期待各位大佬的科普

@autogen
在线迁移迁移过程中就能出问题了
疑问三依旧没有合理解答
如果正如现在公告描述的情况，暴露出来的问题真的不少...

@xud6 #62
想了想有道理，然而绕开缓存以后还是绕不开主控节点...
这个能关掉读取校验的巨锅....唉~

@xud6 #64
三副本该不会是单节点 0 吧？感觉 RAID61 才更为合理，不然可靠性依旧巨坑
且存储节点自身用 ZFS 能更上一层楼的避免各种异常...具体能否实现就看实验了

望科普！

@johnjiang85 #57
期待技术细节分享

@johnjiang85 #54
迁移不过缓存直接把请求压到最后的根节点是基本不可能的
对整个集群的性能是一个严重的拖累（假定为机械硬盘）

@xud6 #55
这个不知道腾讯云的具体实现我就不好说什么了
只是现在看起来....坑是越来越大了....

@xud6 #48
所以缓存很重要，ZFS 的原理和性能瓶颈是知道的，块存储集群其实也是为了解决这类问题
所以 CPU 资源配备理应足够，但感觉更大的瓶颈在内存上面，毕竟运算是需要数据来回搬的
具体没见到实现也不好说什么，只是。。。看起来。。。。计算资源是没配够了。

> RAIN 工作和 RAID 类似，正常工作中同一个 IO 操作只会访问一份数据，除非出错（或校验失败），本质上就是以某个数据源作为数据拷贝源，只是粒度更细。

关于这个，只能说别忘了这是 3 副本，不是 RAID-Z/Z2/Z3, 是 RAID1....

@johnjiang85
随机 -> 等效随机，不是实际随机
块与校验数据是一体的，写入的时候三副本并行写入必然三副本都会存在理论上一致的块，不做回读校验可以理解
但从你的回复中似乎理解错了这个校验数据的位置

另外，数据迁移如果请求源位于存储的主控节点，由集群的主控集群对外提供块存储访问请求支持的话
对于一个有着正常业务的三副本存储集群最底层的存储节点就根本不可能获得真正的顺序读取请求，一切都是随机
对于这类集群缓存是极其重要的，除非为纯固态集群。

既然要做缓存，那么直接访问指定节点的可能性就不存在了
毕竟涉及到一个很重要的问题：数据副本同步

这也是疑问 3 没想通的
既然是迁移，既然是同步，自然需要尽可能少量数据进行快照后的增量数据同步

正常说迁移一个镜像：
快照，同步数据，同步快照后增量，剩余数据到某个阈值
最高优先级断流同步，再重新服务，这是理想的无停机迁移
（也可以让集群 2 作为代理访问集群一的原始数据的同时同步到集群 2，但读延迟会增加）
对于业务来说近乎无感（实际上至少有百毫秒级的 IO 断流或者延迟）

为何是到 8 点多的一刀切切换？难道是停机迁移？

@johnjiang85
前提不存在，校验计算是接收到写入请求后在内存中进行计算
为了避免计算结果错误建议是使用 ECC 内存（应该没哪家是 DIY PC 做存储服务器吧？）
三副本的存储架构原则上根本不允许外部请求直接访问指定的节点，一切都是随机化
因为外部请求到达存储节点后几乎不可能有持续读取的可能
既然都是随机请求那么也没有把请求压到特定某个存储节点的必要了

这暴露出来的问题...