关于超融合项目立项之初的若干经验分享(Hyper-Converged)

时间:2022-10-28 14:54:30

引子

采访:您好 小明先生,请问迫使您企业引入超融合架构最大的驱动力是什么?

小明:穷。

采访:哈,您幽默,能谈谈战略方面的意义吗?

小明:我幽默个P。但凡领导批1个亿,我整排机架都换成小型机,最高端的闪存存储买一大片,让厂商坐在我对面待命,我整天摇椅一坐喝咖啡看小说,然后每隔3-5年全部更换一遍,这工作岂不美哉?

采访:- -!!!....您部门还有文化稍微高一点的吗?我想采访一下

小红:首先,我们留意到数据中心广泛的服务器利用率极低,同时迫切希望抑制其年度采购量及逐渐放大的管理成本,于是,引入了目前较为成熟,普遍性的产品技术----服务器虚拟化。

再后来,我们想到既然“服务器”可以这么做,那么广泛的“存储系统”呢?毕竟在存储方面投入与管理成本的挑战远高于服务器,简单来一例:服务器过保可以勉强撑一下,尤其基于X86架构平台维护难度也很低。存储系统呢?作为数据的承载系统你希望一颗盘亮黄灯,恨不得供应商赶紧飞过来更换:)。(当然,在该例中,续费是理所应当的合同条款,这里我想表达的是紧迫性和昂贵的维护成本)。由此,作为一次成功的商业机会,有想法的厂商为我们带来了新的概念和产品“超融合-The Hyper_Converged”。力求把Google,Amazon,Microsoft等成功的,基于X86分布式的数据中心架构引入寻常百姓家。以此,摒弃传统的集中存储,消除不断增长的维护费用,同时从绑定中走出来拥抱X86带来的开放性与灵活的扩展性。至少对于数据中心广泛的轻量级应用和非关键业务来讲:好理念!好架构!

关于超融合项目立项之初的若干经验分享(Hyper-Converged)

大概在2012年左右部署第一个超融合项目,随后几年接触了魔力象限主要几个厂商/ 产品。虽说是接触,但也不仅是看看产品手册完事,严格来讲架构设计,或亲历亲为配置,有助于单刀直入的对产品属性多个维度深入了解。也积累一些经验分享给51cto blog,旨在为正给客户设计超融合方案的集成商或准备引入超融合架构企业的IT组织提供一丝参考,若能稍许受益,我也将很荣幸。


经验之谈一,产品交付类型

过去一段时间您认为,超融合产品形态是什么?

几台X86服务器,通过安装Hypervisor(虚拟化管理程序)组建集群,以及管理服务器内置磁盘。最终实现,可承载一堆的vServer(服务器虚拟化)和VDI(桌面虚拟化)?

笼统来讲是这样的,至少普遍产品形态如此,当然也不乏NetApp这种另类产品形态(他们推崇“融合”架构)。但是,这仅仅是针对项目落地而言,而交付之初则大有玄机。

之所以放在首位,我认为前期可明确的区分产品交付形态,对之后IT管理周期会产生很大的影响。就像:“买都买了,凑合用吧”,这种情况很可能会给企业和IT管理组织带来很大的负担。

关于超融合项目立项之初的若干经验分享(Hyper-Converged)

上图,暂且把产品笼统分为3个堆栈。

Ø  首先是硬件,普遍是基于x86服务器。

Ø  其次是存储管理程序,例如VMWARE VSAN,Nutanix NDFS,EMC ScaleIO….。

Ø  最后是Hypervisor,类似vSphere,Citrix XenServer….

 那么,通过上面①②③编号,该供应商交付的是什么?可对号入座。后面话题几乎都能作为该图的延伸,所以这很重要。


经验之谈二,再利用

“虚拟化”技术大行其道原因之一,就是受益其开放性特性,可最大程度利用那些现有的,通用型设备。既然“虚拟化”是超融合堆栈之一,那么,该供应商交付的超融合方案继承此特性吗?

关于超融合项目立项之初的若干经验分享(Hyper-Converged)

很显然,取决于交付的产品形态。如果供应商交付产品形态涵盖了③,那么意味着企业当前已经购买(或退役)的x86服务器将无法再次利用。

同样的,如果供应商交付产品涵盖了①,例如,已经具备基于KVM的虚拟化管理程序,那么您已然购买的VMWARE vSphere & vCenter License’s,将无法再利用。坦白来讲,你需要重新适应另一套虚拟化管理程序。

结论:在议题一,所讨论的明确区分超融合产品的交付形态,是不是很重要?(如果我表述的足够很清楚,而您又能充分理解我的表述)。所以,走进数据中心,环顾四周,留意这些企业已经购置的资产,哪些需要被利用(包含上图省略的网络设备),然后作为考量供应商产品或方案的一个重要打分指标。

关于超融合项目立项之初的若干经验分享(Hyper-Converged)


经验之谈三,留意性能

这个议题很乏味,而执行起来更加乏味,但又无法避免。

在传统的架构中,配置一套数据库。您遵循经验,根据当前事务交易量配置多少计算节点,也知道该存储性能极限,能够提供多少IOPS,预留多少上限避免尽早到达瓶颈。

But,虚拟化或超融合的挑战在于,IT组织很难评估每个部门让你安装一筐虚拟服务器后在上面运行或测试什么程序,尤其是存储性能方面。而在VDI环境就更麻烦,每个部门员工职能不同,使用办公工具不同,收集这些性能指标很是个浩大系统化工程。

确保项目POC阶段尽可能贴近业务环境,在性能测试方面。使用专业的测试工具,Linux FiO,iOMeter,HammerDB…等等,它们或具备丰富基准设置,可模拟多种类型应用场景,又或是充分利用计算性能压榨存储/磁盘的极限….etc(避免把桌面工具带进机房,如Bench32,CrystalDiskMark,HDTunePro,AS SSD Benchmark…)

该项目中如果包含VDI,确保配合GPU的高清视频,流媒体处理等场景,具备流畅的体验。最好Full-Power Test,获得该架构在计算性能,存储性能的极限值,为之后的扩容预留时间。

关于超融合项目立项之初的若干经验分享(Hyper-Converged)

“ESG很早就做了调查和阐述,各种业务在虚拟化之后由于共享资源,首当其冲的就是性能带来的影响”

普遍来看,超融合项目落地后,最初要处理的问题多少都会与性能有关联。只是,受影响的不再是前面示例的一套独立的数据库业务,一台存储系统,而是波及广泛的业务,毕竟虚拟化理念就是把多个鸡蛋装在一个篮子。


经验之谈四,扩展性

在2000年初的一段时间,经常会和客户或集成商讨论“瓶颈”一词。但很快,随之入行越深,又或是受逻辑思维影响,我越发觉得“瓶颈”是个伪命题。首先,直面问题,“瓶颈”是客观存在的,当满心欢喜购买一部手机,128GB,各方面都很满意,随之128G被写满,那就遇到了瓶颈,而“瓶颈”发生在128G上面。

另一方面又难以判断,或者代价高昂。假如:供应商提供一套方案,看似越是完善,客户越是担心,不由的问一句:这套方案/产品的瓶颈在哪里?那从辩证角度来问:“我要提供多少单位(容量,带宽,IOPS,Ghz,TPs,TPm,RAM..etc)才能打消您心里对于“瓶颈”的顾虑?其次,预算cover的住吗?”...…..看似话题有些僵硬。

让我们把“瓶颈”暂时搁置,看看从另一个话题上能否找到突破口---扩展性。

还是那部手机,当时买入时各方面我都很满意,2年后在厂商的允许下,我可以*,简单的把 ROM 128G扩展512G,又或是1000G(或许补交几百块小差价)。一段时间后,我又把RAM从4G扩展到8G。又升级屏幕5英寸到8英寸,顺带着LCD换成OLED…etc。总之,各种*,各种扩展…..是不是一副美好的画面!而当初如果厂商把这些都堆满的话我又钱不够,又或是预消费在一些当初用不到的地方而不甘心。“当然,最终两个必然结局:1)供应商手机销售量大跌,2)我和那些因为延长了手机更换频率的消费者很开心“。

铺垫这么多我想表达是:未雨绸缪是刻在骨子里的,但在昂贵的IT基础建设中“预消费”不具备成本效益。两者权衡之道在于----扩展性,“只买需要的,需要时再买”。

请问,这套超融合架构在部署之后的两年,可以根据业务需求:

Ø  把业务或存储网络从10Gb扩展到25G或45Gb吗?就地升级(例如只是更换个模块),还是完全更换高规格的网络及设备?如果前者,最大支持多少速率?

Ø  集群可支持最大节点数量多少?满载性能上限多少,测试报告?

Ø  磁盘在节点通常是满配的?容量到达上限如何扩容?添点小钱把当前磁盘换成更大容量的,还是必须购入整台超融合节点?如果是后者:我仅仅是需要磁盘空间而已,也许有那么5TB就又可以再跑两年,可最终要购入整台节点。多数预算花费在充裕/过剩的计算组件,适配器,软件license….想象一场景:“老板,请您批我一笔预算用来扩容”。Okay,扩容多少,预算多少?。“5TB,10万就够啦:)”。你买的这5TB盘是黄金做的,10万?你小子是不是吃回扣了。“不是啦,您别误会,厂商说想扩容就必须重新买一台…….巴拉巴拉…..”。最后,可以利旧现有的存储系统,或者干脆购入一台廉价的存储柜,只买我需要的?把他作为加分项。

Ø  反之亦然,如果容量富余,计算性能到达上限如何扩容?能否只扩充性能组件(CPU,RAM,Power)

以上,举一反三,需要集成商或企业IT组织深入的去了解产品属性及其架构,而不是停留在产品彩页,有助于降低初期的项目启动成本,而强大的扩展性可在后续运营中规避广泛的系统瓶颈。


经验之谈五,产品先进性

提及产品先进性,首要的就是软件程序,产品具备丰富的高级特性和及时迭代是IT架构保持活力的重要基础,同时也是IT组织随时引入新技术的入场券。那么可以收集一些前沿科技,尝试做个list,看看供应商的反应:

Ø  (假设)该超融合方案虚拟化管理程序使用的是vSphere,那么支持VMWARE刚刚推出的VVOLs吗?(该技术需要③配合)

Ø  容器目前比较火热,该架构支持吗,支持哪个厂商,如何引入?

Ø  想尝试NVMe Flash,该架构及时更新了主流厂商的NVMe Flash drivers?

Ø  构建企业私有云哪些已经就绪,还缺哪些组件?

Ø  可否接入公有云,方式?支持第三方虚拟化备份系统,LAN Free /Server Free ?...etc

“list 内容在51cto blog写入这一刻很多不是新技术,仅是为了示意格式”

方案中的产品力是否足够出色,对IT前沿技术是否及时响应,那么得到的回复会成为重要的参考凭证。


经验之谈六,开放性

这个议题主要考量的是产品的绑定性与开放性的程度。毕竟每个超融合厂商都会告诉你,超融合方案的好处之一即是“让企业从传统IT架构的绑定中解脱,尤其是硬件”。最终IT组织发现又跳到了超融合的绑定中,那岂不是一个悲惨的故事…哈!

既然如此,调研一下,该供应商提供的架构在后期使用中,如果发现“虚拟化管理程序(hypervisor)”运维复杂,又或是效率低下,严重影响了生产,那么可以在现有的架构基础上更换其它厂商吗?例如:从一个厂商基于KVM自研的产品更换到维护简单的MS HyperV?又或是企业功能完善的vSphere?。又可否把vmware View 换成citrix Xendesktop?可否根据主观的品牌喜好或成本考量,*更换超融合设备节点(通常是X86服务器)软件平滑的移植过去?磁盘可以吗?

或是都不可以,企业只能放弃之前的投入,重新评估一套新的超融合方案?这些前期的调研或许有助于规避一个悲惨故事的发生。


结语

以上,是我能回想到的,写在51cto blog周五!

总之,多看,多想,多了解,会发现产品的丰富多彩,避免思想被固定的几个供应商绑定….就像被硬件绑定那样,哈!