云磁盘故障的技术解读
|
副标题[/!--empirenews.page--]
腾讯云磁盘故障导致“前沿数控”数据丢失一事，有关各方进行了一系列解读，但大多没有摆脱借题炒作之嫌，真正地技术解读倒是被弃之一旁，这也是一种悲哀！ 在国内环境条件下，对于故障进行技术解读是一个很困难的事情，主要障碍在于事件的信息披露，牵涉到追责的问题，当事方常常不能如实透露事件真相，从而让技术解读成为了无源之水。 为腾讯云点赞！ 与国内大多数故障事件不同，腾讯云对于云磁盘故障信息披露，实事求是的态度值得点赞！ 试想如果腾讯云坚持以“部分云硬盘IO异常”为由进行搪塞，那么真相就不会公之于众，更谈不上什么技术分析。就像人会生病一样，IT系统会发生故障，其实是最正常不过的事情，没有什么好隐瞒的！ 在8月8日声明中，腾讯云故障进行了还原。 首先是云存储系统扩容要进行数据迁移，在数据迁移过程中，为了追求速度，人为/运维违章操作，没有进行数据校验，原有数据过早删除。恰逢磁盘静默错误，导致数据无法恢复！ 这里提到了磁盘静默错误，简单说就是数据处理过程都是正常的，但是使用时才会发现数据错误，造成静默数据错误，磁盘本身的原因主要是固件错误以及硬盘介质本身的原因（如噪声、电磁等）。 横向扩展和数据迁移 此次故障原因清楚了，但也衍生、延展出来更多技术话题。 首先，数据迁移是由存储系统扩容引起的。对于云存储来说，不是横向扩展Scale out吗？扩容就是了，为什么要进行数据迁移呢? 这是一个非常有意思的话题。 为此，我也请教了软件定义存储的专业厂商，得到鹏云网络、华云网际等厂商专家的支持！在技术方面，他们是很有实力的厂商。以鹏云网络为例，创始人陈靓曾长期担任美国亚马逊AWS 核心构架师，带领团队进行 S3 云存储系统深度优化，并主持 Glacier 存储系统的设计和研发。 专家提示说，软件定义存储或者称云存储有不同的技术实现方式，有Paxos /Raft 、Zookeeper、DHT（Distributed Hash Table）等不同元数据管理方法。 其中，DHT是根据一致性哈希的方式计算出来，其好处是极大降低了元数据服务存储压力和访问压力。但弱点在于对于容量规模要有很好的预计，如果涉及添加节点，移除节点，添加磁盘，移除磁盘的情况，由于哈希环会发生变化，一部分数据需要重新分布，会在集群中产生不必要的数据迁移，而且数据量往往非常大。 这也是为什么，有推测认为腾讯云存储采用了DHT方式来构建，当然推测未经过证实。 实际上，即使不采用DHT。云存储单一资源池的规模也是有上限的，也就是说，集群内节点数量是由最佳实践的。以VSAN为例，有64个节点数量的限制；Ceph（DHT）是256，超过出这个限，节点之间网络通信的复杂度，以及效率都难以得到保障。 对于腾讯云存储来说，对外提供公有云服务，同时支持多个用户，数据规模和增长速度达到上限，这是可以想象的事情。因此，数据迁移在所难免！这一点，鹏云网络、华云网际的专家都是肯定的。 数据迁移的话题 专家指出：数据迁移不是灾难，磁盘静默错误也不是大问题，甚至违章操作关闭检验也不是致命的问题！ 那么数据是怎么丢的呢？ 实际上，磁盘静默错误是非常小概率的事件，是个别磁盘问题。要知道云存储数据有多副本保护，完全可以应对小概率事件导致的错误。 试想一下，如果是对云存储系统进行完整的数据迁移，即使关闭了校验，仍然有三副本(或者两副本)数据存储，应该可以应对磁盘静默错误。 那么，副本为什么没有发挥作用呢？ 据专家推测，其数据迁移的过程并没有进行完整的数据迁移；估计就是迁移了主数据样本，并制作了三副本保护，迁移过程违章关闭了检验。如果主数据有误，其制作的副本数据也是错误的。加上，原有数据删除过早，造成了难以挽回的错误。 所以数据迁移、静默错误、关闭校验都不是问题的元凶！一系列问题叠加才是数据丢失的根本原因。 试想，腾讯云支持租户众多，为什么只有“前沿数控”中招了呢？只能说这是一个小概率事件！ “对于云存储或称软件定义存储，高性能和高可扩展度是必须考虑的因素，以鹏云ZettaStor DBS为例，可从几台服务器起步，扩展至上百万台服务器规模 , 且保持稳定和高性能。从底层进行磁盘性能优化，实现了同样数量磁盘3倍以上的性能表现。”专家说。 全流程数据校验更是需要着重考虑问题。分布式缓存一致、全流程数据校验、磁盘修复等全方位技术手段，也是鹏云ZettaStor DBS的显著特征。 快照和备份的话题 当事件发生之后，数据保护肯定是一个绕不开的话题。 （编辑：上饶站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
