>汽车>>正文

大师问答|Hash哈希算法与SDS软件定义存储之间的问题

原标题:大师问答|Hash哈希算法与SDS软件定义存储之间的问题

【问】:目前来看,超融合涉足的厂商数量非常多,各种超融合方案都出现了,不过,业内出现过一个超融合客户,掉电后,虚拟机都起来不了。这是为何?Hash哈希算法与SDS软件定义存储之间有着怎样的关系?

【大师】:原理上来说,不是有纠删码或者多副本来保障么。

一般用兼容性好的硬件都不会有什么大问题,CPU用INTEL,内存用三星,加速卡用INTEL,网卡用Intel原装。加速卡很关键,最好提前做兼容性测试,不然鬼知道什么时候出幺蛾子事情。

可是,SDS部署了的存储节点确实出现了死机,怎么理解?

从原理和架构角度看,SDS和传统存储没有本质区别。看的是产品健壮性如何,这也是不少存储厂商和用户表明的观点。

有趣的是,有个用户用分布式nas软件和机架服务器搭建的架构用了一段时间,有天手贱把一台服务器的一根网线拔了,看看能不能切换,结果遭遇了宕机和丢数据。从原理看,不应该是这样等结果,可是为什么会这样呢?

SDS服务器死机后,数据的迁移、平衡都必须生效,否则就会出现你们说的“系统是玩具”的现象。

最关键问题,就是系统健壮性好不好。能否应对各种错误,如网络断线,网络丢包,服务器死机,磁盘插拔,磁盘坏死,磁盘变慢,各种硬件问题都要考虑到如何在软件层面进行容错和处理,还不能影响客户的业务,让客户无感知。

简单地说,大型分布式的难点不应该就是在多副本保障的强一致性设计和性能保障之间寻求平衡吗?

然而,其实分布式存储的故障恢复有几个难点所在:

一是,故障恢复用多少时间?1秒,还是1分钟,10分钟,不同的level是不同的水平。

二是,集群大了还能这么可靠吗?几个节点没问题,到几百几千呢?这也是一个级别的问题。

三是,连续性故障发生,坏了了一台机器,紧接着又坏了一台……大型分布式系统节点动荡在所难免,要保证稳定也不简单。

理论上说,哈希散列算法这些都是现成的,metadata数据结构要么tree要么kv,再复杂点就采用kv做一层tree做二层的混合结构。metadata管理也就是独立出来和zookeeper两种玩法,协议堆栈也是标准化,能做的就是找平衡和开发企业级数据管理特性,如重删、压缩、快照、dr、备份等企业级功能或应用。

就高可用而言,分布式目前看最可靠的数据保障方式是copie+zokeeper,ce做rebuilding存在效率问题,当然也有优化的用area区隔的方法,但是万变不离其宗。

你见过100万台服务器做的SDS软件定义存储系统吗?据说Hash哈希算法理论在这样的大规模实际生产环境下会出问题的,真的吗?

SAN存储环境三位数节点的集群规模就到头了,强一致性特点就不允许你有那么多节点之间做一致性的协商调度。

不过,1万节点的数据规模如amazon s3已经实现了。可是,s3 metadata数据结构是啥?用的啥容错方式?协议堆栈是不是标准化的?似乎都是一个秘。

容量、性能、可用性、可靠性、可伸缩性是互相平衡的,规模大了其他的自然受影响,其他要素类推。

现在常见的几种哈希散列算法的应用优势场景,以及zookeeper的枚举算法如何具体实现,这些也是很重要的思路,可以帮助大家理解s3的价值。

这么说吧,hash算法在稍微大一点的SDS集群里面是不好用的。不能作为寻址的方法,容易导致数据在硬件出问题的情况下,大量的无意义迁移。

如果不考虑是块级的散列,还是是节点级的,又或者object级的,就说不好用,这未免太武断了。

当然不一样,效率不同。

做分布式设计的时候难道首先不应该考虑散列方法吗?什么数据规模,什么应用场景选择什么样的散列方式。

为什么效率不一样?数量级不一样,应对的算法当然不能一样。算法调整很多时候都是找平衡,这一头上去了,那一头就下来。

kv的寻址效率比tree高难道不是常识吗?小规模下差别不大,关键还是数量级,如果基于块,那肯定没得选,KV就OK了。

hash的特点仅仅是在空间集合内部,任意索引的性能比较一致,不一定代表效率高。

要看长远的,小规模下就是B族tree,又稳定又快速,就像三体里说的老式的物理化学能驱动,还能压榨出很大潜力,但是大规模下肯定得考虑KV,星际旅行得靠曲率驱动。

这个比喻严密,十分生动。

本次答疑:谢华、元峰、陈靓、张鹏、赵波、杨海俊、刘军、常平、何庆、孙辉、雪飞、黄昆、马总mushroom

对此,你怎么看?

欢迎文末留言评论。

欢迎提问返回搜狐,查看更多

责任编辑:

声明:该文观点仅代表作者本人,搜狐号系信息发布平台,搜狐仅提供信息存储空间服务。
阅读 ()
投诉
免费获取
今日搜狐热点
今日推荐