iSCSI+zfs
不要低估内网性能

别最后搞一个寻性姿势
今后非有关部门批准，不得提供复制试卷

让你自己百度并没有问题，这样说的话大概率是因为你的答案百度上一定有
大公司一般不会这样，因为用的都是自研技术，让你去百度，也不可能比原作者亲自解答更准确

@wclebb 能怎么想，反正 gce 又没中国业务
aws，azure，gce，IBM，Oracle 目前大概这个顺序
前两家加起来占市场 7 成以上
而且没有一家能在中国直接运营，全都要靠国内代理
on call 只能隔靴搔痒，甚至不能直接远程操作而只能发邮件

@qiukong 我不懂你是从哪里看出自带备份的
这段只是说”我们快照系统真牛逼，你赶紧买“
实际上用户有没有买呢？看这个架势恐怕是没有的
三度冗余是冗余了，全挂了，你就是那最倒霉的 10^-10 概率，他往地上一坐你还真没什么办法。
sla 就是这时候用的。sla 不满足，按什么标准赔偿，这都是协议里有的。不能接受的话加钱加冗余加到接受为止
用户不懂就更搞笑了，你有两千万的数据还不懂得看 sla，哄谁呢？
按数据价值赔偿也很搞笑，又没有按数据价值多交钱。我买了 1GB 的盘，别的没存，就存了价值一千万比特币密钥。回头坏了你赔。别说 ebs，glacier 都不敢接这需求。

@coderdusk 用户对故障没有责任
但是你对自己的系统，自己的数据，还是要上点心的

@coderdusk 我的意思是：
问题在于腾讯云瞎 JB 宣传，你宣传了就要做到，做不到就要赔钱
其他云并没有这样宣传，aws 直接说 failure rate 在 0.1-0.2%，但注意这只是文档，sla 里并没有。
没有 sla，没有广告宣传，就不必负责
你不能说这个事情用户没有责任吧？腾讯云往地上一坐：对，你就是那 10^-10 的倒霉的。
到时候你的数据呢？
又能说什么呢？证明它实际上没有达到 9 个 9 么？
证明了又能怎样呢？给你十倍赔偿呗

是不能搞受害者归因，但是还有一句话叫君子不立于危墙之下。加害者是承担责任了，然而受伤的还是受害者。自我保护不是为了打赢官司，而是为了保护自己。

@loqixh 卧槽你哪来的，我 azure 可不敢这么吹
同一数据中心跨机房冗余储存是有，为了高可用
但是如果全灭的话也是白瞎
异地冗余请加钱

@jmk92 那也不是免费送啊
既然有这个服务，那就是要加钱才有的

mmm，刚才看漏了
Amazon EBS volumes are designed for an annual failure rate (AFR) of between 0.1% - 0.2%, where failure refers to a complete or partial loss of the volume, depending on the size and performance of the volume. This makes EBS volumes 20 times more reliable than typical commodity disk drives, which fail with an AFR of around 4%. For example, if you have 1,000 EBS volumes running for 1 year, you should expect 1 to 2 will have a failure. EBS also supports a snapshot feature, which is a good way to take point-in-time backups of your data.

@jmk92 备份是要加钱的，你买 snapshot，买 s3，买 glacier，就没这破事了

只能说 pm 傻逼，瞎 JB 吹（我数了，9 个 9 ）
正规做法应该是虚拟磁盘只保证 uptime 和性能
要数据安全请扔到离线储存服务
你看看 aws ebs 有没有 data resilience 的 sla ？

@coderdusk 你这个比喻不合适
承运人有保障乘客安全的义务，这是运管所规定的
但是云服务没有保证你数据安全的义务，就像你买辆车瞎 JB 开，怪车怎么不保障安全。你怎么不要求硬盘厂赔钱呢？有 mtbf 的保证的，实际上达不到又怎样？看看 backblaze 的统计

@OneNian 可以是，rdma 只要网络撑得住，除了多一个内网延迟，其他都和本地盘一样。
然后，现在都是 30G 50G 的网络
本来计算节点和储存节点分离就是这么玩的

@mhycy 我只是提供了一种假说而已
解释你们之前说的三硬盘为什么能一起挂
腾讯云具体什么架构，只有他们自己知道

除了 iSCSI 还有 rdma 呢

关于 raid6，标准里似乎并不包含你说的读取中两个结果对比的功能。不然也不会有这篇论文了：RAID Architecture with Correction of Corrupted Data in Faulty Disk Blocks。raid 本身并不提供校验，因此纠正也无从谈起。如果你说的是非标准 raid，那 zfs 就是一例

关于为什么一块硬盘固件错误会影响三块，可能是这样的：
假设某硬盘固件有误，写入数据的一半全是 0
这时候阵列还是在线的，因为没人知道这块硬盘是错的
我们继续使用，刚好文件系统要用到这些数据，于是读取这一段
阵列卡依然不知道有问题，于是就挑了这块坏的数据
文件系统遇到一两个错误，未必就会立刻崩溃，于是数据修改后又写回去了，注意此时所有副本都已经丢失，如果用户数据也在这一段，那数据已经丢失
最后终于，某个系统文件出错，系统崩溃，这时候文件系统已经不成样子了，就算成样子，数据也已经没了

raid 不保数据不一致。raid 的前提假设就是如果硬盘挂了，就会瞬间彻底离线。这也是为什么某些硬盘有读取超时时直接报错，为的就是提前通知 raid 控制器，防止阻塞整个阵列。

raid 只保 uptime，不保数据可靠性，这必须牢记。


@mhycy
@jadec0der
@type

不是，你想要什么样的不杂活？
让你独立开发新系统？还是让你重写核心业务？

@opengps “云服务器可以自动漂移到其他母鸡上继续运行”
你说的是 live migration 么？
技术上可行，实际上直接给你在另一台 host 上重启比较快
你说的 host 硬盘故障问题不存在。因为计算节点和储存节点是分离的。计算节点不储存用户数据，通过网络挂载。本地 SSD 是有，但是本地 SSD 不保数据
计算节点能故障啥？要么网络要么 CPU，这都不是可以热迁移的情况。唯一有用的就是如果要维护节点，可以把虚拟机迁移走再维护。但是其实现在都有在线升级的能力，必须关机维护的情况非常少（比如去年的 spectre 就是一例）。完全可以等用户自己业务需要关机的时候，逐步退役，最后再把剩下的全部重启一遍。反正 sla 只保 uptime，不保证不重启