番外·如果袁绍也懂超融合......

     今天的分享，让我们从1800年前的一场经典之战说起......

     公元200年十月，曹操夜袭乌巢，一战定乾坤，取得了官渡之战的胜利，这才有了三分天下有其一的魏国基业。当时名微众寡的曹操之所以能够以弱胜强，完全是因为乌巢乃是袁绍军队的屯粮之所，失去了补给的袁绍军队顿时战意全无，溃不成军，最终沦为军事斗争的牺牲品。

     “长平之战”、“彭越挠楚”，这些脍炙人口的成语背后，无不印证着一句老话-“兵马未动，粮草先行。”可见粮草对于军事行动的重要性是无与伦比的。

     回到各位熟悉的IT世界，过去的种种“救场”经历告诉笔者，许多用户出现“业务停摆”是由于为业务提供支撑的后端集中式存储出现了故障导致的。客观地来说，企业数据中心在计算和网络层面的高可用性已经相当成熟。但就“存储的高可用性”来说，因为成本等因素的制约，往往成了数据中心这个木桶的“短板”。就好像是将所有粮食囤积在乌巢的袁绍那样，如果业务的“粮草大营-存储”因为主客观的原因出现了故障并且缺少有效的恢复方案时，那对业务造成的影响是绝对致命的。

0x01.解决方案

     既然存储与计算、网络一样，都是数据中心必不可少的基础设施，工程师自然要对存储基础设施进行包括高可用性、高可恢复性、高性能、高安全在内的一系列设计考量。解决方案大致可分为“存储双活”“高可恢复性设计”等等。不过碍于篇幅，今天笔者只想聊一聊“超融合”这种方案。其实“超融合”的理念，之前就有技术大拿分享过，拿战争来举例，它就像是“游牧民族”的战斗方式。既然粮草大营存在的意义就是为打仗的兵士提供补给，那么为什么不让士兵自己带上补给去打仗呢？

如果袁绍也懂超融合，让袁军的每一名士兵都像“游牧民族”一样，自己保管十天的干粮与曹军对峙，那历史的轨迹可能就真的发生了改变。这种类似“人粮超融合”的作战方式可能会带来一些意想不到的优势：

第一，“不将鸡蛋放在一个篮子里”

     如果一小队袁绍的部队遭受到了曹军的伏击，除了人力的损失外，粮草的损失相当有限，不会影响主力部队的正常运作。

     同样地，在采用超融合架构下，如果服务器上的一块硬盘或者整台服务器出现了故障离线，群集本身的“数据存储”并不会因此离线。其他虚拟机可以正常对外提供业务。由于服务器故障而导致异常关机的虚拟机，可以在触发vSphere HA之后，重新恢复业务生产。超融合架构就像“放鸡蛋”那样，将数据分布在每一台服务器、每一个磁盘组、每一块磁盘中，是“游牧民族式”的分布式数据存储，天生具备的高可用性是巨大的优势。

  第二，减少投入，降低成本

     采用了“分布式粮草解决方案”的袁绍，将原本留守乌巢的人员编入战斗部队，加强战斗力。减少了运输粮草耗费的人力成本，免去了建造并维护乌巢粮仓的消耗。由彼及此，采用超融合架构可以免去IT人员对集中式存储的部署与维护，相比较后者，超融合的部署和运维非常容易上手。将提供数据存储的磁盘直接部署在服务器侧，可以回避复杂的跳线，超融合“SSD缓存层+容量层”的设计，也会提高存储的IO吞吐。在相同成本约束的情况下，IT可以选择将更多的成本投入到计算资源的部署中，提升整体的投资回报比。

    第三，简单易用，适合各类场景

     无论是步兵、骑兵还是弩兵，“分布式粮草解决方案”都能提供对他们的支持，是一款广泛适用于各类作战场景的解决方案。自从超融合产品问世，便在各行各业各类场景中，受到了用户的青睐。拿VMware vSAN来说，融合了超融合解决方案-vSAN优势的VCF组合拳适用于几乎所有的用户生产场景。

0x02.客观说说不过，客观地来说，以vSAN为代表的超融合产品也会有自身的短板。虽然早些年就有市场报告宣称“超过半数的企业已经使用了超融合架构，并且将其作为替代传统存储架构的方案”，但实际的项目经历告诉我：传统存储依旧有它的地位，无论是超融合还是传统架构，适用于用户生产需求的，才是好的方案。超融合相对于传统架构，最大的改变是将计算和存储合二为一。这种改变自然带来了上文笔者所提到的各种优势，但客观地来说，也会造成计算能力的“损失”。

拿市场占有率最高的服务器虚拟化产品-VMware vSphere来举例：如果用户采用非VMware的超融合解决方案，那么就需要额外部署一台控制虚拟机(后文简称CVM)来提供支持。这台CVM是需要vSphere为他分配一定的CPU以及内存硬件资源的。比如C记的超融合产品，根据硬件服务器型号的不同，vSphere需要为他预留至少48GB或者72GB的内存。这意味着无论这套平台上是否有实际的业务虚拟机在运行，主机至少要划分出一定量的内存用于支撑CVM(这是vSphere的Reserve概念所定义的)。

这就意味着，群集可以提供真正业务使用的“内存资源池”比传统架构的要有所减少。而且服务器配备的内存越少，造成的影响越大。(如果每台服务器是256GB内存，那么CVM就要占据几乎1/3的内存消耗)。这其实很容易理解嘛：虽然袁绍采用“分布式粮草解决方案”，可以实现前文提到的诸多优势。但对于士兵来说，除了要持戈操戟，也要预留一部分体力背上一些干粮。

同样地，即使用户选择了vSAN。虽然vSAN是“刻在vmkernel骨子里的软件”，但不可避免的会消耗一部分内存和CPU的资源。只是相比较二层架构的其他超融合产品来说，消耗的硬件资源相对少一点而已。实际上，笔者在为用户规划设计的时候，也会遵从VMware的最佳时间，将这部分消耗考虑在内。那么，我们的用户有无必要因为这种“损耗”而排斥超融合么？答案自然是否定的！因为这部分消耗毕竟有限。虽然会有一定的“计算能力损失”，但是超融合可以提供高性能的IO吞吐，能提供硬件故障下的快速恢复能力，能提供包括去重压缩、纠删码、文件服务等在内的诸多支持。用户完全没必要“因噎废食”，信赖超融合，并且使用它，是明智的选择!再来说说容量的问题。其实超融合群集的可扩展性是相当友好的。

1x01.纵向扩展能力-提升存储资源池容量

     当超融合提供的数据存储随着业务的增长出现容量不足的时候，管理员可以按需增加磁盘组或者容量盘(根据超融合产品不同而有所差异)。

1x02.横向扩展能力-提升计算资源池容量

     当超融合提供的计算能力(如内存、CPU)随着业务的正常出现竞争的时候，管理员可以按需扩展主机。有些超融合产品支持这样的扩张，通常也会将超融合服务器节点分为“融合节点(计算+存储)”和“计算节点”两种。vSAN虽然也支持“无盘服务器”添加到启用vSAN的群集，但始终不作为最佳实践来推荐。

1x03.整体扩展能力-提升总体资源池容量

     当群集整体资源池随着业务的正常出现竞争的时候，管理员可以在不停机地情况下，直接扩容节点，来同时满足计算能力和存储能力的扩张。表面上看，“1x03”的方式是最优的，但相对其他两者，成本也是最贵的。有风险的其实是“1x01”和“1x02”两种方式。拿"1x01”来说，当一台多磁盘组的服务器出现故障，那么受到影响的虚拟机相对于“1x03”来说，范围可能会更大。 相类似的，对于“1x02”而言，当一台“融合节点”出现故障的时候，那么受到影响的虚拟机相对于“1x03”来说，范围也可能会更大。

      但上述情况，并不能说是超融合的产品缺陷。但这却是架构师在设计超融合解决方案时，必须要考虑的“Risk风险”。总结来说，超融合的容量扩展并不像传统存储那样，“无脑加盘柜就完事了”，还是需要“多耐心思考一点”，才能万无一失。

     最后，早些年的超融合产品一直饱受诟病的一点是“无法对外提供基于NFS/CIFS这类协议的数据存储”。对于“VDI on HCI”这类解决方案而言，如果超融合无法提供基于CIFS的文件系统，这就意味着管理员必须要借助额外的NAS存储或者通过文件服务器的方式来弥补“纯超融合”环境带来的短板。前者意味着额外的硬件投入，后者其实并不适合大规模VDI的部署。(假如500用户，每个用户60GB，就意味着文件服务器需要30TB的空间，由于超融合的副本存在，就需要占据约60TB的空间......)但随着技术的发展，包括国外的N记、国产的S记都支持NAS协议提供超融合的存储空间。而在7.0版本以后，vSAN也支持基于SMB/NFS协议的文件系统服务。同时在VMware提出“HCI Mesh”架构之后，vSAN已经从狭义的超融合，升格成广义上的超融合存储服务。接下来，就跟随笔者的HOMELAB，一起来看看现阶段的vSAN能实现哪些新功能吧~

0x03.动手做做

     光说不练是做不好一名合格的工程师的。利用nest esxi ova，笔者嵌套了一个vSAN的环境，各位不妨就来玩转一下包括HCI Mesh在内的“大变动”吧。

HCI Mesh-其实我是端水大师~

     还记得上文，笔者说的几种扩容情况么？计算资源不足可以横向扩展计算能力，存储资源不足可以纵向扩展存储容量。那么：如果同一个数据中心有些群集容量过剩，有些群集容量不足，能不能“匀一匀”呢？举个例子吧：某客户数据中心，拥有三个群集，其中vSAN Cluster01和vSAN Cluster02采用超融合架构，Compute Cluster02采用传统存储架构。由于初期规划存在一些不足，在运行了一段时间后，管理员发现vSAN Cluster02和Compute Cluster01的数据存储空间出现严重的不足，而vSAN Cluster01还具有大量空闲的存储空间。

对于这种情况，如果管理员像往常一样，为存储空间不足的群集进行扩容，势必会带来硬件投入需要的成本攀升。对于vSAN Cluster01的大量闲置空间，也没有得到很好的利用，并不是一种最优的方案。

那么vSAN的HCI Mesh这位端水大师是如何“一碗水端平”的呢？如上图所示，通过HCI Mesh网络，vSAN Cluster01将本地的超融合数据存储vSAN DataStore01，挂载给vSAN Cluster02和Compute Cluster01使用。对于后两个群集来说，原先因为存储空间不足，而无法部署的业务(绿色虚拟机)，由于有了新的空闲存储空间而得以部署。这种方式并没有增加新的硬件投入，是一种最优的方式，它很好地实现了“跨群集使用闲置资源”的需求。简单来说，既然“CPU和内存没法匀一匀，那我就把超融合存储匀一匀吧~”对于想要挂载远端存储的群集来说，配置的步骤也相当容易上手：A>激活该群集的vSAN服务，选择配置‘“vSAN HCI网络计算集群”。

(这里插一句，之前V都是翻译成群集的，我好不容易养成了习惯，现在又翻译成集群了 ）

B>为该群集挂载“远端数据存储”，在配置了用于vSAN通信的vmkernel之后，vCenter会自动扫描符合条件的vSAN数据存储，用于该群集的挂载。

C>挂载远端群集的vSAN数据存储后，该数据存储就和普通的本地数据存储一样，提供本地的虚拟机来调度使用。

     总结来说，vSAN HCI Mesh的优势在于：

     I.摆脱传统固定比例的计算与存储造成的利用率低下问题，跨群集调度空闲的存储资源能更好地提高利用率，避免资产浪费。
     II.通过HCI网络享受HCI Mesh服务的群集本身并不需要强制部署vSAN，灵活性得到了充分的体现。            III.不依赖于3rd软件或者专用硬件，避免复杂性，管理员易于部署，易于运维。

     IV.vSAN数据存储不再局限于孤立的群集，而是可以将vCenter下辖的所有vSAN数据存储看成一个庞大的资源池，以HCI Mesh服务的形式提供业务使用，彻底解决了单一vSAN群集只能“全闪存磁盘模式”或者“混合磁盘模式”二选一的尴尬。

     V.超融合既然属于软件定义存储，那么强制将服务器和硬盘进行紧耦合绑定，并非是超融合的初衷，HCI Mesh将计算资源池和存储资源池“松耦合”，完全符合软件定义数据中心对利用率、灵活性等方面的根本诉求。

文件服务-会是一个突破么？

     vSAN7.0问世也已经有相当一段时间了。除了上文提到的HCI Mesh以外，最受到关注的就是vSAN提供的文件服务。

     当管理员开启vSAN文件服务后，vCenter会在每一台vSAN群集下的ESXi主机上部署一台代理虚拟机(非常像3rd超融合软件部署在vSphere平台上的样子)。每一台虚拟机提供两种文件系统，分别是NFS和SAMBA。在vSAN的文件服务部署完成后，无论是运行在该群集之上的业务虚拟机，还是其他裸金属或者群集外虚拟机，在网络可达的情况下，就可以使用文件服务提供的NFS或者SMB文件系统。

     对于vSAN数据存储来说，原先的“单一用于提供本群集内虚拟机使用”的情况发生了翻天覆地的变化。这个时候的vSAN也不再是狭义上的软件定义存储（后文称SDS），更像是基于SDS的存储服务，无论是面向虚拟机、还是容器或者其他任何需要NFS、SMB文件系统的工作负载，都可以按需提供高性能高安全的存储服务。这无疑是一个巨大的突破。不过由于笔者HOMELAB资源有限，nest ova部署的ESXi无法支撑起Agent虚拟机的运行，就没有办法演示了。

0x04.写在最后

     今天的主题是超融合，笔者用“官渡之战”作为引子或许不合时宜，这也是为了向不了解超融合的朋友做个简单的介绍，同时也聊了聊像vSAN HCI Mesh这样的新架构。

     另一方面，其实作为工程师的我们，不难发现这个时代亦发生着“超融合”的改变：

     IT技术栈的“融合”，仿佛全世界都在讲“全IT”，工程师不得不从原来的“一根筋”成长到现在的“多头堵”。
     不同Verdor的“融合”，无论是V家、C家，还是国内的H家、S家；充满着对抗和合作，比如Citrix VDI on VMware vSAN的案例就太多太多了，这需要工程师对一个领域的相关厂商和产品都要有所涉猎和掌握。
     云的“融合”，曾几何时A家说要完全替代V家，但事实是A家和V家都发现谁也吃不掉对方，通力合作才是正途。既然如此，云网融合、多云互联、混合云这些方案自然也会成为工程师的必修课。
工程师能力的“融合”，我们经常开玩笑，写不了代码的项目经理不是好销售。工程师又何尝不是如此，从咨询到设计，从实施到运维，我们也正在成为多能的“软件定义的工程师”。BTW，最近晓冬还在自学数据库相关的东西，希望能有一天和各位交流分享，下次回归vRA~~~