【超融合分享连载-1】从分布式存储说起

yeslab官方

作为新技术分享，今天YESLAB果丹皮和大家闲话一个未来多个IE方向都要考查的主题——超融合。

考虑到有很多备考IE的同学是从零起点学起的，超融合这个字眼儿听起来又虚头巴脑地，我可以换一个比较好理解的说法。虽然未必100%准确，但是业内很多人提到超融合，会认为这是一个和分布式存储很接近的概念。

这样大家就理解了吧？那我就从分布式存储和超融…

好吧，好吧，我从头慢慢说。

一些历史专家和历史爱好者们，在提到汉人和蒙古草原上那些游牧民族部署军队的差异时，会这样讲：汉人往往用单独的运粮部队来押运粮草，也要有专门的粮仓来储备粮草。比如说，汉人派出一支10万人的部队，其中2万人是运粮部队。

喏，就是下面这样：

在扎营之后呢，整支部队还要由粮草部队向各个部队提供军粮。因为军中有统一的储粮、运粮编制，我们在这里姑且称之为集中式军粮部署。最终，这些粮食都是给军队运的，也会给所有士兵分享。

反过来，蒙古草原上的游牧民族在出征的时候，则基本不存在押粮部队的编制。一人几匹马，其中负责作战的是战马，还会有负责平时骑的马，叫作走马。因为战士也喝这种马的奶，所以大家如果愿意的话也可以叫它奶妈马。蒙古大军甚至每个战士5-10匹马，每个人都有专门给自己运粮饷的驮马。这样靠驮马和奶……马，以及一些或随军、或……正好路过的牲口，就基本解决了部队的粮食问题。

差不多，就是下面这样了：

于是，在需要吃饭的时候，大家吃点肉干、再来点马奶子就可以解决问题了。当然，这里所说的马奶子可不是马奶子葡萄，而是正儿八经的马奶。所以迄今为止，一些源自蒙古草原游牧民族的兄弟民族，仍然保留着喝马奶子的传统。

总之，由于是每个人自己携带食物，所以我们姑且称之为分布式军粮部署。

有同学可能想问，什么集中式、分布式？总之每个人都是要分配口粮的，这两种方式有什么区别呢？

同学们，有没有屯粮地点和运粮部队，这里面的区别可大了。因为我们今天要聊的主题是分布式，所以我们今天只说集中式的缺点，而且只挑一些重点的问题来谈。

首先，“集中式部署军粮”会增加成本。比如说，运粮部队自己就得吃粮、也得发饷，这一点相信大家也不会怀疑。古人说“千里不运粮”，在一定程度上就是因为不够本儿。从这个角度上看，如果没有运粮部队，也就节省了额外支付运粮部队的成本。

其次，中国专有这么一号军事家，喜欢烧人粮仓、断人粮道、劫人运粮部队。这一点相信看古装剧的同学都有印象。

显然，如果游牧民族真的不统一押运、存储粮草的话，那么这类军事家在应对与游牧部落的战争时，恐怕就要重新设计军事方针了。换句话说，集中式部署军粮存在单点故障的问题。因为一旦粮道被断，整支军队都要面临断炊的风险。

当然，集中式部署军粮还存在其他一些问题。比如说，由屯粮地点向各个作战部队提供粮草也是需要时间的，也难免会在转运过程中产生先后次序，甚至厚此薄彼的问题。这也就是说，集中式部署军粮会增加延迟、产生次序的问题。另外，运粮部队与作战部队的调度也需要经过认真协调，所以集中式部署军粮会增加互操作和统一管理的问题，增加协调和管理的难度。

好吧好吧，历史背景先说这么多。现在我们把粮草理解成数据，把粮仓理解成在数据中心当中统一存储数据的空间，把运粮部队理解成存储网络传输协议，集中式存储和分布式存储的区别大家也就理解了。

所谓集中式部署，就是在数据中心（是的，超融合是用于数据中心的技术）里部署专门的存储空间，这是如今数据中心常用的做法。再往前推几年，也基本上就是部署数据中心唯一的做法。

所以你看，图中有一套单独的存储设备，还有一个单独的存储网络。大凡是这样的集中式设计方案，往往躲不开前面所说的几个缺点：增加成本、单点隐患、协调不便、管理复杂、产生延迟等等，反正就是各种不好。

分布式存储解决了这样的问题，因为这种环境没有集中式地部署存储设备，而把存储资源分布在了每一台服务器当中。于是，就变成了下面这样的物理环境：

有同学看到这里大概会觉得完全不能接受：这都已经快变成企业局域网了，这是技术进步吗？怎么看起来像是退化？

fair enough。同学们，这里向大家提一个问题：

假如你是一位蒙古草原上骁勇善战的英雄，某一次和战友一起出征，结果你的奶马不幸在战争中阵亡、驮马走失，装口粮的袋子也在战斗中被敌人抢走了。现在打完收工，眼看今天一点口粮都没有了，那你打算怎么办呢？

直接和战友要也许是个法子，但由于不能确保成功率，所以不能形成制度。因为……你确定人人都会给你？万一人家不给怎么办……

于是，很多同学接下来的想法就是：我可以找部队里的小队长。让他从战友们的口粮那里调度口粮给我啊。毕竟，别人那里确实有的吃啊，不是说分布式部署不会出现单点故障吗？部队里总有人负责调度整个团队的资源吧？

没错，既然避免了单点故障，就意味着可以从别处获得资源，否则每个点都会单点故障。所以，在自己山穷水尽的时候，如果有来自整个团队的支持，对于饥肠辘辘的战士是很重要的！

然而，企业网数通网和云数据中心网络在这方面存在巨大的区别，这个区别来自于这两种网络在功能上的区别：

对于企业网络来说，它在设计上的初衷就不是对外提供资源。一台企业客户端的资源耗尽了，企业网中也没有道理会配备有这种类似于小队长的机制，来帮助这台客户端协调其他设备上的资源。所以，在这类网络环境中，我的就是我的，你的也……就是你的，物理资源基本上以物理设备为界，有着泾渭分明的所属划分。

但对于云数据中心来说，请求资源的人不在乎他/她要的东西在你的数据中心里面转（3声）了多少道手儿，他只关心自己要的东西有没有、对不对、好不好，给他/她提供得及时不及时。为了让大家都能更快、更好、更正确地请求到云数据中心里面的资源，云数据中心里面的服务器必须不分彼此通力合作。

然而，做到通力合作不能靠在机房里给设备贴标语喊口号，这需要一系列实打实的技术发展作为支撑。比如，云数据中心里面的各种资源需要在逻辑上进行汇总，这个套路叫作“资源池化”，显然属于一种虚拟化技术。在另一方面，这些资源毕竟只能在逻辑上被网络之外的人看成是一个整体，但它们又确实是不同的设备，所以云数据中心里面需要有一种类似于小队长的机制来负责资源的调度和协调。总之，在分分合合之后，这些设备才能实现对外整齐划一地提供资源输出。大家可以看下面这张SmartX解释超融合架构的图：

(图片来自google)

看到了吧？存储资源确实分布在各个x86计算机上。但是在对外的时候，它们逻辑化为一个统一的存储池。这张图充份呼应了我们刚刚提到的、资源池化的概念。

综上所述，虽然架构乍一看更像企业网，但是如果没有更强大的虚拟化技术作为支撑、性能更卓越的计算资源提供运算、更先进的软件定义方式进行统一协调和管理，更高速的网络带宽实现转发，上面这种把存储资源融合到计算服务器中的做法，还就真的没法运用在云数据中心当中！

有同学看到这里想问：为什么大家都说SSD的发展是超融合架构出现的诱因呢？还有，前面说今天只强调分布式的优势，显然是在暗示集中式也有它的优势，那集中式的优势又是什么呢？

这两个问题下次分享的时候，果丹皮再给大家解释，这样下期的主题我就有了。

那么，说了半天分布式存储，分布式存储和超融合到底是啥关系？

目前谈到超融合，大家还是倾向于把它理解为分布式存储。但是，现在已经有越来越多的解决方案开始利用超融合架构当中的服务器来统一虚拟化（其实就是融合）包括网络设备在内的其他设备，最终实现数据中心的全x86化——也就是最终整个数据中心里除了（和桌面电脑在本质上没有任何区别的）服务器之外，啥别的用电器（不包括电灯和空调！）都没有。所以，同学们现在可以把分布式存储看成是超融合的一个重要环节。

在前面几次新技术分享中，果丹皮先给大家提供一些关于超融合的概念，后面我们搞几个分布式存储的实验，帮助大家直观地看一看超融合是怎么操作的。

最后，为了避免精通历史的同学跟咱们较真，果丹皮来一段免责声明：其实蒙古草原的游牧民族虽然相对农耕民族屯粮运粮较少，但人家也不是完全不屯粮的。《史记 卫将军骠骑列传》就有“遂至窴颜山赵信城，得匈奴积粟食军。军留一日而还，悉烧其城馀粟以归”的记载。这里的历史背景纯粹是为了引出分布式存储及其优势，所作的铺垫。

小乔

Lapot16

fjq0215

从分布式存储说起

wjlovezzd

好东西谢谢楼主分享

xin11369

Ai乐乐

ITcloud

很形象啊

lok7120

thank you for sharing

Ai乐乐

可以可以

wang@sugon

不错不错

Reboot_Memory

感谢分享！

xuelongraori

感谢分享！！！！！

luo2201

念卿儿

thank  you