V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  mhycy  ›  全部回复第 39 页 / 共 186 页
回复总数  3708
1 ... 35  36  37  38  39  40  41  42  43  44 ... 186  
2018-08-08 12:19:54 +08:00
回复了 mhycy 创建的主题 云计算 关于“腾讯云用户数据丢失故障”最新公告的一些细节的疑问
@johnjiang85
正因为了解,才产生疑问
2018-08-08 12:18:48 +08:00
回复了 mhycy 创建的主题 云计算 关于“腾讯云用户数据丢失故障”最新公告的一些细节的疑问
@nullornull #6
参考 ZFS 的实现,块存储集群的一般而言实现类似于 ZFS,读校验绕不开
对不上 hash 就需要三副本读取修复,除非出现 hash 碰撞,那么需要等到巡检才能发现了
2018-08-08 12:14:42 +08:00
回复了 mhycy 创建的主题 云计算 关于“腾讯云用户数据丢失故障”最新公告的一些细节的疑问
@johnjiang85
所以...什么情况下关闭校验可以提速呢?
https://www.v2ex.com/t/477885

看起来有更深层的问题
人祸只是让问题暴露出来了而已
2018-08-08 12:00:43 +08:00
回复了 mhycy 创建的主题 云计算 关于“腾讯云用户数据丢失故障”最新公告的一些细节的疑问
@lyl35023
一开始也是这么想的
但涉及到大量快照后增量数据同步的问题
而且...既然仓库 1 数据搬迁到仓库 2 的时候是错的,为什么业务能读取到正确数据?
2018-08-08 10:07:27 +08:00
回复了 mhycy 创建的主题 程序员 关于腾讯云事件“前沿数控技术生产数据完全丢失”的看法
@nullornull
这样的运维都能进腾讯。。。唉
2018-08-07 13:47:06 +08:00
回复了 mhycy 创建的主题 程序员 关于腾讯云事件“前沿数控技术生产数据完全丢失”的看法
@iConnect
所以确实没想通。。。

倒是因为这个事件围观各个帖子涨了不少存储领域的见识也算是有所收获
@ryd994
感谢科普!
@ryd994
能做块级存储集群的软件方案,不考虑读取写入校验是基本不可能存在的。
注意,要做到块级存储集群只可能是软件方案而不是硬件的 RAID 整列
能在各个计算节点互相飘的方案也只有走网络的 iSCSI 方案
(如果有别的方案希望给我科普一下,我实施过的只有 iSCSI )

RAID 保证 uptime 不保证数据这点没错,但考虑到上层软件冗余与纠错... 这锅还是甩不掉啊...
而且 RAID6 的情况下本来就自带有错误发现的能力(读取过程中两个结果互相对比)
于是... 锅还是甩不掉...
@void1900
然而架构合理的情况下公告太不靠谱了...
所以...腾讯云依旧存在问题...

作为经历过各类云服务长毛事件的一代人(例如当年的 QQ 中转站)
我就没相信过任何云服务会可靠,数据在手才是自己的
提到的各种可靠性数字是一个字都不信的(没有单位,没有标准,作为广告都能算是虚假宣传)
云服务本身是否可靠,能否作为主业务节点,需要实际情况实际分析...
例如现在的各种负面...

另: 我关于是否选择云服务的看法可以看看这帖子的回复(#47 )
https://www.v2ex.com/t/476956
@void1900
搞不懂你是在杠还是在讨论问题
本来我觉得你在贴头说的话还挺有理的
然后在回复这个帖子前重新看了回复对了下 id
现在我都不知道该怎么和你聊下去了

理性讨论问题是基本的礼貌与对别人的尊重且对双方的技术提升都能有所帮助,希望你懂这个道理。
@void1900
按照准则这个故障原因是日常不是异常
@void1900
给个场景?
@void1900
硬件 RAID 最基础最基础的低成本高可靠选项是 RAID6,不是 RAID5

RAID1 的存储成本过高
RAID5 存在两个磁盘损坏无法修复的可能性
RAID10 存在特定两个磁盘损坏后无法修复的问题(除非其中的 1 不止一个磁盘)
RAID50 存在特定两个磁盘损坏后无法修复的问题
RAID60 存在特定三块磁盘损坏后无法修复的问题

假设现在情况真的是磁盘回报异常,那么算是静默错误,当成磁盘写入全 0 好了
且故障真的是固件 BUG 引发,那么非同固件且非同批次磁盘构建阵列这个准则是否已经违反?

所以说在正确构建阵列的情况下这是概率极低的事件
除非。。。阵列卡出 BUG 了
@void1900
重新阅读回复,你会知道为什么同时损坏理应概率极低
@void1900
构建磁盘阵列的时候,静默错误是个必然需要考虑的异常情况
(事实上依据观察 V 站的各位似乎考虑到这个问题的并不多)

针对的是单个磁盘回报不正确数据的情况,该如何尽早的发现尽早的排除
在支持静默错误发现的阵列系统例如:ZFS
静默翻转 /静默写入读出不一致是不可能导致整个磁盘阵列丢失数据的
因为软件层面上会实时的校验读取到的数据与元数据是否一致(显然元数据也是冗余的)
对于异常磁盘一次读出就尽早修正并且抛出警告了
如果问题出自硬盘底层固件,那么问题范围也仅仅可能局限在一个磁盘阵列节点也不可能全存储系统的崩溃
高可用磁盘底层架构为非同批次、非同固件的等容量、等架构磁盘组建硬件 /软件 RAID
此磁盘柜应配合巡检定期校验数据是否可用,并尽早踢出异常磁盘
三备份应是基于此磁盘架构的冗余备份架构,无论是实时互备还是定时冷备

一般云 VPS 服务的自动迁移依赖独立的磁盘柜与计算集群实现
那么在腾讯的这个案例上,可能存在三台阵列柜、一套磁盘阵列网关与若干计算节点组成的计算机群
丢失数据的范围为一个集群(假定整个集群都出现静默错误,且真的存在三备份架构)

那么问题来了
1、为什么现在只有一家公司发声?
2、如果真的是三备份架构,为什么会三套存储设备同时故障?
3、为何阵列损坏后没有任何警告、通知直接就是静默错误?

假设现在的信息都为真实信息,没有人为修饰掩盖
有以下推断:
1、不存在三套设备互备的磁盘架构
2、这个软件 BUG 不在硬盘而在软件分布式上面
3、假设 2 推断为假,软件 BUG 位于磁盘,则阵列架设没有严格遵守高可用原则进行设计
4、假设 2 推断为真,那么更有可能的情况是 BUG 位于阵列卡,数据位于单一母机,丢失范围为一台母机
5、假设 2 推断为真,数据存在集群上面,且 BUG 位于自研的分布式存储平台上,那么...不多说了

说实在,怎么想都想不出来为什么一个成熟的云平台能搞到数据全丢
甚至有点怀疑是不是有人手动的“ rm -rf ”然后后续业务直接写花了集群
2018-08-06 14:06:52 +08:00
回复了 Felldeadbird 创建的主题 云计算 前沿数控的云事故,是不是说明云并不安全?
吹归吹,好好了解下云平台的架构(特指云服务器平台)就会知道,那东西本质上就是一个虚拟机。
问题来了:虚拟机的安全性与可靠性由什么来决定?

归根结底还是对技术的不了解,对数据的不负责。
2018-08-06 10:52:00 +08:00
回复了 zhazhadi 创建的主题 问与答 为什么 虚拟专用网络 能加速
@Backlitz
因为你真的不懂
2018-08-06 09:33:42 +08:00
回复了 zhazhadi 创建的主题 问与答 为什么 虚拟专用网络 能加速
@Backlitz
不懂别乱说

代理加速器一般是使用更高优先级的线路(例如 CN2、MPLS )或者路由更好的落地服务器(某些特定的直连机房)
以在路由配置不妥的直连环境下人为的创造一个相对优化合理的虚拟链路

而现在,某些方案下,代理加速器使用的是 SDN (软件定义网络)技术
在不可靠的公有网络上创造一个相对可靠、快速的私有网络
同时在加入更多的冗余技术、选择更好的落地服务器,结合上文提到的更高优先级线路( CN2 )
提供更加快速、可靠、成本相对较低的虚拟链路方案。
1 ... 35  36  37  38  39  40  41  42  43  44 ... 186  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2584 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 32ms · UTC 13:21 · PVG 21:21 · LAX 06:21 · JFK 09:21
Developed with CodeLauncher
♥ Do have faith in what you're doing.