中小型金融企业超融合平台建设 6 大核心难点

    目前云计算比较火热，企业使用云计算服务一般有两种方式，一种是直接使用公有云厂商的服务，一种是使用企业级私有云。大多数小公司和对数据安全性要求不高的公司会采用公有云的方案，实施成本低，真正的按需供给；对于金融企业而言，使用公有云一方面会担心数据泄露的问题，另一方面可能会存在监管方面的问题，因此大多会采用企业级私有云的方案。但是金融企业的规模也有大小之分，规模大的金融企业（例如银行）在IT基础资源投入（包括机房物理容量、每年预算、人员投入等）方面远远高于规模较小的金融企业（例如券商、基金、期货等），那么对于规模较小的金融企业应该如何建设企业级私有云，来满足自身的发展需要？

    引入超融合技术方案，就是解决这个痛点的一种不错的思路。一方面超融合平台投入资金远小于计算与存储分离的云平台，同时由于省略了外置的san网络，在一定程度上还节约了物理空间，间接再次降低了成本；另一方面超融合平台在功能上和性能上与计算存储分离的云平台相比也是不相上下，甚至在功能方面是占有优势的。具备这样性价比的产品，对中小金融企业还是具备较强吸引力的。

 

    绕着中小型金融企业如何基于超融合技术建设私有云需求进行了讨论，针对超融合的相关问题，将专家、会员的观点总结如下，分为六大类典型问题：

 

    一、超融合技术的成本问题

 

    Q1：中小金融上云的成本如何控制？

 

    A：确实在不考虑商业授权的情况下，vmware可以认为是没有成本的，但是这样做是有风险的，一旦被vmware控告，问题就不单单是钱的问题了。基于超融合平台构建私有云成本需要从几个层面考虑，一是物理空间的成本和电力成本，从这个角度说，超融合平台的成本是比较低的；二是超融合平台的软件授权版本费用；三是超融合平台的物理机资源成本；至于成本的控制，有几点可以参考，一是有些厂商的一体机解决方案会比自己买硬件再采购软件的方式便宜；二是可以先购买最小化集群（这也是为什么我在文章中提到中小金融企业要特别在意最小化部署的规模）；三是要选择采用通用x86服务器部署的，这样的话即使发现超融合不好用，至少物理机还可以用作其他用途，变相的降低了成本。

 

    Q2：超融合和传统FC架构成本对比？

 

    A：超融合平台相比于传统FC架构最直接而言是节省了san网络的相关费用，间接而言还节约了机柜空间和电力资源，对于很多租赁机柜的中小金融行业而言，这还是节约了不少成本。另外就是在应对快速扩容的资源需求时，超融合架构上线所需时间远远小于传统fc架构，可以说是插上线就可以使用，时间成本也降低了很多。最后，很多超融合平台都自带备份和cdp能力，这样又对于单独购买而言，又是省了一笔钱。

 

    二、超融合技术的适用性问题

 

    Q1：超融合架构或者说云架构如何满足数据库性能需求？

 

    A1：您提出的问题其实就是想知道超融合架构能否满足oracle的性能需求，毕竟虚拟化以后计算资源肯定是会有损失的，这个问题最好的答案不能仅仅是从理论的角度分析，更多的还是要进行实测。可以先收集目前数据基于物理机运行的性能指标，然后与超融合平台部署数据库进行对比测试，这样真实测试出来的数据更具有说服力。另外一个层面来说，有些超融合厂商还专门针对主流的数据库oracle和db2做了优化，而且每家的场景和需求不同，因此笔者的建议还是真实测试的结果更具有说服力。

 

    A2：数据库性能我理解应该分为计算、存储和网络，这里主要讲讲计算和存储：

 

    一、计算性能

 

    在OLTP场景下，对于大并发，每秒事务数极高业务，CPU是很容易出现瓶颈。超融合架构的计算用的是vmware或者kvm等虚拟化技术，hypervisor多少都会损耗一些计算能力。所以针对大并发场景可以采用

 

    1、使用cpu透传技术，将物理cpu直接透传给虚拟机，好处是虚拟机获得物理cpu的计算能力，劣势cpu资源被虚拟机独占。

 

    2、通过numa绑定技术，将虚拟机在调度到某个物理cpu，优先使用cpu的本端内存（对于双路服务器，物理cpu旁边就是cpu插槽，如果cpu访问对端cpu附近的内存，则会走总线，增加访问延时）

 

    3、开启大叶内存，增加cache池

 

    二、存储性能

 

    针对不同的业务场景，对存储的需求不一样，对OLTP系统要求高IOPS，而对OLAP系统则要求高吞吐，在超融合架构中有两点可以提升存储性能

 

    1、使用全闪存存储，土豪的玩法，优点肯定是性能好，缺点就是费钱，只要在比较关键的业务系统上才会使用。

 

    2、使用分布式存储，比较常见的方式是SSD+机械盘，数据先到SSD缓存，然后再写到机械盘，对上层应用来说不感知底层存储实现，在此基础上结合分片、条带化技术，把数据打散均匀的写到各个磁盘中，并发利用各个机械盘的io能力，提升存储的iops和吞吐能力。

 

    Q2：核心系统采用超融合架构，如何向用户证明超融合架构同样适用？

 

    A：性能不好，这里涉及两个问题。一是超融合技术都在不断的发展，不知道您是测试的是哪一年的产品？二是超融合厂家和厂家的能力差距比较大，这就需要在poc测试的时候进行充分的评估，根据笔者所知，现在很多超融合平台的io能力已经超越例如emc、ibm这些大厂的中端存储能力；三是部署是否合理，如果你说的是db性能不好，那就要看你部署db的方式是否是超融合厂商建议的最佳实践；至少在笔者看来，目前的超融合技术计算能力是可以应对中小金融企业80%的业务场景。

 

    第二个问题，说白了是用户对超融合技术不信任。这个没有特别好的办法，只能通过实践和案例来向用户证明，毕竟这不是一个技术问题，而是一种理念和态度问题。

 

    Q3：什么场景，部署哪些类型的业务系统，需要考虑应用超融合技术？

 

    A1：这两者其实是没有必然联系的，就像业务系统不知道自己是跑在虚拟机上还是跑在物理机上是一样的。如果真的要深究的话，对io要求高的系统由于超融合技术的io路径要短一些，因此在同等磁盘和软件算法的配置下，超融合技术栈的io性能应该会对io密集型的业务更加友好。

 

    A2：超融合的话，其实需要考虑的有三个方面，第一，架构方面，需要考虑带宽，因为超融合一般都是通过后端的万兆交换机作为数据互联，再加上通过多副本（一般是三副本），数据流量增加了三倍，所以对网卡和交换机都是巨大的考验，不仅要高带宽、低延迟，还需要更好的网络虚拟化支持能力，所以网络往往会形成超融合瓶颈，而且超融合拥有管理网、心跳网、业务网、存储网等多个网络，对网络的稳定性和性能是首先考虑的；第二是性能问题，不同的业务场景对设备性能的需求是不一样的，比如关键生产业务比如医院HIS，金融支付系统，企业ERP系统，往往运行在高性能的物理机上，它们超过了超融合单个VM的最大负荷，如果是轻应用，其实完全没问题；第三呢就是考虑后期的运维扩展，超融合由于自身技术的封闭，如果想后续扩容的话，只能是同一品牌增加节点，容易被厂商绑架，那么扩容问题就来了，如果我是存储容量不足，我扩节点的话，连计算节点也一起扩容了，同理单纯扩计算资源也是这样。还有一点就是，业务部署问题，超融合部署业务块，但是一旦想回去传统的SAN架构时，数据迁移是个大问题，需要超融合厂商配置，但是都不用人家设备了，他们还会配合你们么。

 

    综上所述，不同的业务场景，选择的IT架构是不一样的，如果是轻应用虚拟化的话，没有问题，VDI虚拟桌面，也没有问题，但是核心系统，还是建议部署在传统IOE架构上。

 

    三、超融合平台带来的风险问题

 

    Q1：实际部署和使用过程中，发现的超融合模式的缺点有哪些？

 

    A1：笔者看来目前超融合架构主要的缺点有两点，一是稳定性，二是有磁盘或者主机损坏时数据重建过程对性能的影响。先来看稳定性，现在很多企业只将超融合使用在开发和测试环境也是因为超融合的稳定性问题，产生这个问题的主要原因一方面是超融合技术发展的时间不如集中式技术栈，另一方面是超融合技术和集中式相比还是省略了很多硬件的，众多的功能有纯软件或者x86服务器自身的硬件来实现，增加了硬件故障风险，最后x86服务器本身的稳定性就不如集中式存储，再次增加的风险。对于第二点，还是受限于超融合技术栈自身的原因，数据重建过程都会对性能带来影响，不过这个问题各个厂商也都给出了解决方案，都是处于优化的状态。在笔者看来，基于x86的服务器的技术栈，其设计思维的初衷就不是稳定性，而是性价比和集群规模，那么如果计划采用这样的技术栈，就需要想办法规避其缺点，充分发挥其优点。

 

    A2：整合是超融合架构的优点，同时又是缺点。主要包括

 

    1、整合计算+存储+网络资源，替代原有传统架构设备。但是各方面表现都不佳，集中在统一的服务器上，稳定性、可靠性都不如单独的设备。存储需要大规模部署+多副本+SSD固态盘，解决安全、冗余和性能等问题。网络需要40G/100G或infiniband交换机，解决数据交换问题。

 

    2、扩展性的缺点。超融合扩展能力强是优点，但是要求扩展节点必须统一为超融合架构，而且为同一个厂商产品，这就限制了系统的架构，所以在初期立项时候，必须做好规划，为以后发展打好基础。

 

    Q2：超融合架构实际部署案例中最大规模的单体集群有多大，有哪些运维风险点？

 

    A：笔者接触的范围有限，在笔者知道的实际跑在生产环境上最大的超融合集群是80+台物理服务器。对于超融合的大集群运维，有以下几点需要考虑：一是亲和性和反亲和性的使用，这里包括机柜级和服务器级；二是有些超融合平台集群大了以后，能够进行故障域的划分，建议做好划分；三是集群规模大了以后，需要增强平台的巡检频率，在合同里写清楚巡检的要求；四是集群规模大，需要做好网络设备连接的规划，以便在出问题时快速排查；五是自动化运维工具的同步配置。

 

    Q3：在一定预算前提下，怎样才能采到最优的超融合产品与服务，怎样避免踩坑？

 

    A：这个问题其实操作起来并不难。首先，在预算一定的前提下，就可以排除掉一些预算超标的产品，这样就初步的减少了可选的范围；其次，梳理清楚自己公司的具体需求和痛点，最希望超融合平台为你解决什么样的问题，把这些问题落成书面形式；再次，在不提前给出问题的情况下，邀请过了第一关的公司的销售和技术人员进行现场的沟通，在沟通会上提出所有的书面问题，一般情况下，有些问题应该是厂商那边不能直接回答，是需要回去确认的。这就正好是检测厂商服务态度和对你重视程度的一个重要指标，因为有些厂商表面说回去确认完给答复，结果往往是石沉大海，通过这个方式又可以踢出一些厂商；再次，就是从剩下的里面进行poc测试，硬实力的比拼，同时甲方应该以稳定性测试为理由，尽可能的多测试一段时间，测试时间越久，出现问题的概率越大。接下来，就是故意制造一些故障的场景，然后看厂商的反应速度和服务态度。经过以上这些筛选，我相信你的心里也有了中意的产品，最后就是商务上的问题了。

 

    Q4：使用超融合技术会带来哪些新的运行风险如何规避？

 

    A：您提出这个问题的本质还是对超融合平台本身的稳定性和安全性存在疑问，这个是非常正常的。要把风险降到最低，在笔者看来需要做以下几方面工作。一是在poc阶段做好各种风险场景，进行验证，并详细进行记录，条件允许的话，poc阶段尽可能的拉长时间，因为有些问题在运行一定时间后才会被发现；二是在内部上线后，最好先运行在开发和测试环境，在开发和测试环境运行一定的业务和时间后（一般建议最少是半年时间），再考虑向生产系统迁移，并且上生产系统也要先上非核心的重要系统，再上核心的重要系统；三是一旦上生产后，对重要的虚拟机进行备份，以应对不时之需；四是要求厂商定期检查平台的状态，该升级的进行升级。

 

    Q5：关于超融合架构的分布式存储的稳定性和安全性问题？

 

    A5：这个问题确实是金融行业用户比较关注的问题，在笔者看来这里有三个层面的问题。一是数据自身的保护机制，例如多副本或者纠删码方式是否可靠等，对于这方面的问题首先需要让厂家把机制彻底讲清楚讲透，然后针对性的提出各种疑问，并得到让人满意的答复；二是各种物理故障时的表现，这个说实话除了在poc测试的时候进行各种场景的验证，并没有特别好的方案；三是数据备份方面，现在做的好一些的基于超融合的分布式存储都会提供常规的定时备份和CDP备份两种方式，这个也是需要在poc测试的时候进行测试。总的来说无论是什么架构都无法完全保证数据没有问题，做好各种灾难测试并且设计好应对方案，才是以不变应万变。

 

    四、超融合平台迁移和上云问题

 

    Q1：超融合架构后续如何向私有云平台架构转型？

 

    A1：在笔者看来，回答这个问题需要先明确一个概念，超融合架构仅仅是实现私有云的一条技术路线，不使用超融合技术也是可以搭建私有云平台的。既然这里提到了私有云平台，那么就需要参考我的文章，就是你首先要清楚自己要上哪一层的云，是iaas，paas还是saas？明确了这个问题以后，需求方在选择超融合厂商的时候就需要和厂商进行深入的沟通，需要去评估这个超融合厂商的产品路线能否满足你的上云需求。笔者的建议是最好选择一个产品思路和需求方建设思路一致的厂商，这样对于双方而言都是双赢。当然市面上还有一种解决方案是使用云管平台，但是在笔者看来云管平台看起来能做很多事，但是里面的对接工作和个性化定制工作却相当的繁琐，要想用好，更需要梳理清需求，并且最好是云管厂商能够持续投入，来帮需求方搭建自己所要的私有云。

 

    A2：超融合架构其实也是云架构的一种，也有自己的云管理平台，不需要向云平台架构转型，只是技术路线不同而已。

 

    A3：私有云如果进行细分的话可以分为两部分，一个是云管一个是资源池，资源池主要提供计算、存储、网络资源，云管则提供资源管理、业务支撑的职能。

 

    1、资源池架构，可以是超融合架构，也可以是openstack或者vmware+外置存储，这个层级的主要功能就是稳定、可靠、性能、方便扩容，这一层具有一定的可替代性。

 

    2、云管，现在市场上有很多独立的云管产品，例如fit2cloud、smartcmp等，核心职能是如何管好和用好资源池，所以这一层跟客户业务逻辑、组织结构会有耦合，所以会有个性化定制开发，一定部署好后，推到再来的代价很高。

 

    至于问题所说的如何转型，个人理解只要在超融合资源池上盖一层云管即可实现向云平台的转型。

 

    Q2：已经建成了企业的私有云，如何和现有的系统进行整合？

 

    A1：这个问题其实是两个问题，一是已有的云环境如何与传统的环境整合；二是这两个环境之间如何进行数据共享。对于第一个问题，很多企业的传统环境都都是外购的系统，对于这类系统由于程序无法进行改造，最多只能上iaas层，使用iaas层提供的资源。对于传统系统不是外购的系统，而是自研的系统，则可以通过逐步改造优化的方式上iaas层或者是paas层。对于第二个问题，系统之间数据共享的方式有很多，问答这个问题还是要看主要是针对什么数据，现在业内做数据湖的比较多，数据湖就是利用大数据技术将各方的数据进行汇总，并提供实时或者非实时的服务。如果是业务系统之间的文件数据交换，可以采用对象存储，文件服务器等方式进行。如果是消息或者指令信息的共享，则可以使用消息队列来进行。

 

    A2：云环境和现有系统在业务层面上不冲突，数据整合也可以通过业务实现。

 

    这个问题其实是云环境和传统环境共享的问题。

 

    云环境的数据使用的存储设备，传统业务同样也是存储设备，其实并不冲突，实现有机整合和数据共享，还是需要从业务角度去做整合和共享。单独的将云数据和传统存储数据放在一起并没有意义。

 

    云环境和传统环境，需要根据不同的业务类型去选择部署。有些传统业务其实并不合适部署在云环境中，会影响性能和效率。

 

    Q3：中小型金融企业上云的过程如果是平移过程，大家上云的意向会不会更强？

 

    A1：笔者认为的中小型金融企业不包括招行、平安这样的大的股份制银行。上云阻力来自于应用？这个要看是怎么理解，首先如果是指上iaas层的云，那么应用不需要做任何改造，只需要将应用程序重新在云平台进行部署即可，而且在内部资源紧张的情况下，又为了满足第三方机构的弹性扩容需求，很多开发还会主动要求上云。如果是准备让应用上paas层的云，那么应用程序就需要做相应的改造了，那么就会增加开发人员的开发成本，这样在没有更大“甜头”的情况下，开发确实会成为阻力。另外，如果要选择上云，就要整体上云，且不可应用部分上云，数据库在本地，那样的话由于网络延时的存在，您的应用将基本处于完全不可用的状态。

 

    A2：企业上云过程还是业务需求，并不是完全依赖平移过程。举个例子，现在12306购票网站的查询业务就部署在云端，为什么？并不是因为他可以直接在云上部署，而且购票查询业务，首先是面向公众的互联网业务，部署在云上可以方便访问。其次，购票查询业务访问量巨大，部署在数据中心内部，查询压力非常大，带宽，负载完全不能满足需求，过年过节很快就会瘫痪。部署在云端可以平衡访问压力，减少数据库压力，这是传统数据中心无法做到的。

 

    Q4：现有环境如何迁移到超融合环境？

 

    A：虚拟机迁移这个问题，主要就是看厂商的支持力度了，要看厂商在设计产品的时候是否考虑能够支持别的品牌的虚拟机进行迁移。笔者测试的深信服的超融合平台是支持将vmware的虚拟机在深信服平台和vmware两个平台之间相互迁移的。如果厂商不支持做这种迁移功能，有些第三方软件应该也可以做，但是这样做没有厂商做背书，一旦出现迁移问题就很麻烦。所以，笔者建议，如果准备用谁家的产品，那么就让厂商提供相应的解决方案。

 

    Q5：中小金融企业是否有必要上云？

 

    A1：您好，是否有必要上云这个问题，其实最本质的还是要看目前面临的痛点上云（iaas，paas）能否解决，如果上云能很好的解决，那么至少有了一个上云的理由，基于此理由还需要评估上云带来的风险以及成本的投入。针对这个问题本身，如果说业务系统变更很少，基础资源短期快速申请需求不大，例如一天要50-60台机器并安装中间件和发布应用，那么确实没有必要在这个阶段上云。因为架构设计原则中有个非常重要的原则就是合适原则，就是it系统的建设是要合适当前的业务场景的，毕竟对大多数中心金融企业，都是业务驱动型。但是在笔者看来，随着公司业务的增加，规模的增加，自研系统的增加，传统的资源申请方式必然会造成业务上线的瓶颈，所以可以提前做一些适当的规划以及了解相关技术，以便在需要的时候能够及时作出应对！

 

    A2：目前中小金融的IT基础设施的现状

 

    1、集中交易系统

 

    最为核心的系统，主要用物理服务器承载，有些客户使用vmware+外置存储

 

    2、非核心系统（办公类、手机APP类等业务）

 

    这类系统对稳定性要求不是很高，目前承载平台有物理机、vmware+外置存储、smartx、nutanix、openstack等

 

    3、开发测试环境、仿真环境

 

    对稳定性要求最低，同时也是变更比较频繁的环境，通常都是虚拟化（vmware、nutanix、openstack等）

 

    4、灾备池

 

    金融机构多数都会做容灾，承载平台有物理机和openstack等

 

    从业务类型上看，上述都是传统业务，变化不大，所以中小企业没有太大的动力去变动，变动意味着风险。

 

    当然有些企业在信息化建设上会向头部看齐，从高层制定信息化发展战略，从上往下推动上云，但是这种不是普遍的情况。整体看，金融还是便保守，创新业务（大数据分析）在中小金融应用还不多，导致对it基础设施的驱动力不强。（＠hut51）

 

    Q6：中小金融行业应该如何规划上云？

 

    A：众所周知，云计算的经典模型里把云计算分为IAAS、PAAS和SAAS层，那么企业的决策者在进行企业上云规划的时候就需要先做好计划，想清楚三个问题。

 

    第一个问题，即目前准备上到哪一层的云。因为每一层的云能实现的服务能力是不同的，对云平台的运维人员要求是不同的，同时对云平台提供者的要求也是不同的。

 

    第二个问题，企业建设的云平台准备用在哪些场景。这里的场景主要是指传统的应用系统，还是互联网化的应用。目前根据笔者对同行业的了解和本公司实践，IAAS层可以覆盖传统的应用系统和互联网化的应用，但是PAAS层主要还是覆盖自研为主的互联网应用。

 

    第三个问题，企业建设的云平台按照什么样的发展路线进行前进。引入任何一项新技术，一般都需要有一个适应水土的过程以及推广前进的过程。大多数企业的做法都是先从开发测试环境切入，推广到非核心的生产系统，再到核心的生产系统这样的一个过程。

 

    搞清楚这些问题以后，决策者找到目前最大的痛点是什么，最想要解决什么样的问题，然后就可以按照规划先做起来，期间一定会遇到各种问题，再逐步解决。

 

    五、超融合平台架构与传统FC架构问题

 

    Q1：目前传统架构vmware加fc有必要让超融合淘汰吗？

 

    A：第一个问题：笔者不敢妄言能否在多少年后被替代掉。毕竟很多系统目前都是基于传统的架构在运行的，从实际的角度出发，在传统架构没有出现非常无法解决的问题的时候，是不会有人有动力去使用超融合架构替代传统架构的，这里不仅仅是一个技术问题，更重要的是系统的稳定性的问题，就像现在很多大银行还在用ibm的as400，因为运行的很稳定，没有遇到必须更换的理由，大多数情况下，领导是不愿意承担风险做这个事的。另一方面，也是笔者目前正在做的一件事情，就是异构平台的建设。使用传统架构和超融合架构两套不同的技术栈，可以从平台层面实现高可用，哪怕一套技术架构完全挂了，对于我另外一个技术架构也是没有影响的。就像现在很多使用公有云的公司，会同时使用腾讯云和阿里云是一样的道理。所以，在笔者看来，目前没有发现超融合完全替代传统架构的契机，我认为共存还是主旋律。

 

    第二个问题：传统的方式和超融合是两套技术路线，没有你死我活的必要。笔者认为使用哪个模式不重要，重要的是能够满足需求，没有必要为了用谁而用。

 

    第三个问题：在笔者看来超融合的分布式存储是他的一个特征。至于是否靠谱，这就涉及稳定性的问题了，稳定性的问题是要时间来验证的，这也是选型做poc需要考量的点之一。““个人认为中小金融企业不想互联网行业有突发的大规模资源的需求””这句话笔者不是很赞同，因为笔者做在企业近年来就有突发的大量资源需求，这个需求是否会存在还是和公司的业务方向相关的。

 

    Q2：对nutanix和smartx搭载vmware计算虚拟化而非自研的计算虚拟化是什么看法？

 

    A1：在笔者看来这个是和每家企业的原生技术栈和打法有关的，不能说孰好孰坏，都是从最大化自己的利益出来出发的。vmware在国外市场占有率非常高，那么nutanix和smartx以存储的角度切入，不改变用户习惯，同时smartx也是做存储出身的，具备这方面的技术能力，这个打法是没有问题的。华三和深信服看起来并不甘心做vmware的配角，想自己闯出一片天地，所以制定使用kvm的计算虚拟化，以便把上层做的更灵活可控，这个打法也是没有问题的。（@wykkx）

 

    A2：Nutanix之前用Vmware是因为欧美市场Vmware占有率超过8成，可以快速切入市场，但现在Nutanix已经逐步转向采用自己的KVM产品，不愿意受限于Vmware，因为Vmware/EMC都有自己的超融合了。

 

    SmartX由于技术主要在存储所以+VMware是最快进入市场的方案，但想自己做一款代替Vmware的产品对于SmartX而言也是技术难度不小的，产品的打磨，网络的支持都是需要长时间的积累，也需要有技术大拿的加持，SmartX想换也不容易呀。

 

    Nutanix和SmartX现在都在宣讲自己是云服务厂商，所以Cloud加持成为超融合的新趋势。在国内，这个对原有就是云的供应商而言则是良机，Hua Wei，QIngCloud，EasyStack，深信服，zStack，都在这个领域有各自的产品，基于KVM的产品这些厂商的产品可能更有发言权。

 

    Q3：传统架构会被超融合架构替代掉吗？

 

    A：笔者不敢妄言能否在多少年后被替代掉。毕竟很多系统目前都是基于传统的架构在运行的，从实际的角度出发，在传统架构没有出现非常无法解决的问题的时候，是不会有人有动力去使用超融合架构替代传统架构的，这里不仅仅是一个技术问题，更重要的是系统的稳定性的问题，就像现在很多大银行还在用ibm的as400，因为运行的很稳定，没有遇到必须更换的理由，大多数情况下，领导是不愿意承担风险做这个事的。另一方面，也是笔者目前正在做的一件事情，就是异构平台的建设。使用传统架构和超融合架构两套不同的技术栈，可以从平台层面实现高可用，哪怕一套技术架构完全挂了，对于我另外一个技术架构也是没有影响的。就像现在很多使用公有云的公司，会同时使用腾讯云和阿里云是一样的道理。所以，在笔者看来，目前没有发现超融合完全替代传统架构的契机，我认为共存还是主旋律。

 

    关于本问题的更多观点可以点击此处：传统架构会被超融合架构替代掉吗？

 

    六、产品与厂商

 

    Q1：可以横向分析下主流超融合厂商的优缺点吗？

 

    这个问题不是很好问答，首先笔者也没有测试过所有的超融合厂商，其次即使对于测试过的，个人评价的优缺点也会带来误会，可以参考Gartner象限的信息。笔者建议，需求方还是先列出自己的需求，然后找3家左右的超融合厂商进行测试，并且参考笔者文章中提到的如何选择合作厂商，综合评定来选择适合自己的产品。

 

    可以参考： 在一定预算前提下，如何选择最优的超融合产品与服务，怎样避免踩坑？

 

    Q2：如何选定超融合厂家？

 

    A：一是较为成熟的案例。这里所谓的成熟案例，不是指签了多大的合同或者部署了多大的规模，而是首先要看案例使用在什么行业，不同行业对云平台稳定性、性能和功能的要求是不同的。

 

    二是公司具有一定的实力或者规模。既然是选择一个合作伙伴，而不是做一锤子的买卖，不能说还没过几天这个公司倒闭了。如果出现了这样的情况，那么之前在这个平台上的投入都相当于是石沉大海了，这对于大多数中小型金融行业是不能接受的。

 

    三是在产品层面云平台是该公司的主要战略方向。这一条其实和第二条是有一定的关联性的，如果这家企业是符合条件二的，但是这家企业的产品里没有私有云平台或者是产品里有私有云平台，但是战略规划里没有私有云平台那么你在选择的时候就不能单纯的认为这家企业有实力，你就去选择。毕竟不在战略规划的里的产品，一方面得不到公司级资源的支持，另一方面也可能有被裁掉的风险。

 

    四是合作态度积极。这里的合作态度积极不是指厂商积极的把产品卖给客户，而是认同前文所述能够积极的和客户一起建设属于客户的企业级私有云平台，在此前提下，合作态度积极还应该包括：首先，愿意听取客户的来自一线的真实需求，了解客户的痛点；其次，对于客户提出的关于云平台方面的问题能够快速的响应；再次，云平台在测试或者使用过程中如遇到问题，厂商的工程师能够第一时间到达现场或者远程处理（根据具体的情况）；最后，厂商能够定期举行交流活动，进一步收集用户对云平台的使用情况。

 

    Q3：超融合服务器硬件设备如何选择？

 

    A：在笔者看来，只要是按照厂家的硬件要求清单，自己采购物理机和采用一体机没有太大区别。这个其实还是要和厂家确认的，但是有以下两种情况建议采用一体机的方案，一是采用一体机的方案在能满足性能需求的前提下可以大幅降低成本；二是一体机中有定制的硬件来满足个性化需求。

 

    七、其他Q1：目前超融合一体机往往都是固定配置，很难做到横向的扩展，即使扩展也会采用新建一个集群的方式。甲方用户在超融合的扩展性方面是怎么考虑的？

 

    A1：问题中提到的很难做横向扩展，这个问题笔者没有遇到过，因为笔者接触到的厂商的产品都是支持横向扩容的，如果是不支持一体机横向扩展的产品，那么在笔者看来poc的机会都不会给的，这明显是产品设计问题。另外，笔者看来，一体机在能满足性能需求的前提下，如果具备更强的性价比，那么是可以考虑一体机的方案的，采用自采购硬件加软件的方式更多是因为有些厂商提供的一体机性能不行。

 

    A2：从灵活性上说，甲方肯定喜欢x86加软件部署的方式，觉得自己买硬件便宜，软件也可以砍价。但是实际上，并不划算。

 

    第一，责任问题，出了故障，硬件厂商和超融合软件厂商会互相推脱，扯皮。

 

    第二、超融合软件单独购买，超融合厂商利润少，不如一体机利润高。服务也不会好，有问题经常推给硬件，对用户也不利。

 

    第三、厂商不统一，兼容性也不好，稳定性差，对用户来说也不是好事。

 

    但是以上问题，往往甲方考虑不到，需要引导。

 

    A3：超融合相比于传统vmware计算虚拟化+外置存储的好处之一就是方便横向的扩展，所以你说的超融合一体机不支持横向扩展是不是信息传递有误。 目前市面上的超融合基本有两种形态：

 

    1、厂商提供一体机：超融合厂商会自己采购x86服务器贴牌，预先安装超融合系统，这种形式的优势是能做到标准化交付，交付简单，上线快，而且是厂商会有针对性的兼容测试，所以使用过程中也更稳定， 当然成本稍微高一些

 

    2、厂商提供超融合软件用户自己采购x86服务器：甲方根据厂商的推荐配置，自己采购x86服务器，上线的时候把超融合系统安装到服务器上，这种方式的优势是甲方可以采购到更高性价比的x86服务器（甲方原来可能就有服务器渠道关系等），劣势是上线稍显麻烦，前期服务器配置沟通也比较费劲，cpu配置、raid卡型号等等。

 

    从上述可以看出，超融合就是x86服务器+超融合系统软件，一体机只是预先安装了系统，所以在横向扩容能力上都是一样的，都可以通过添加x86服务器来扩容计算、存储能力。

 

    Q2：分离式部署架构SDS都可以轻松搞定，但却是HCI架构的天然屏障？

 

    活动所分享文章提到企业私有云的异构性需求，如果是基于VMWARE，OPENSTACK，构建了两个不同的私有云体系，集中式HCI，天然就是两个阵营的HCI了，存储体系也就没法打通和共用资源池了。另外超融合架构体系内的块存储，变成文件或者对象，提供给应用，本身对资源特别是这个节点上面的CPU，内存，都是极大的浪费，且节点本身的存储不如分离式SDS部署灵活，有些应用需要SSD建立热池，索引池，有些应用需要HDD作为大容量池，甚至在同一对象集群内，需要不同的副本和EC来达到针对不同应用的数据安全策略， 这些在分离式部署架构SDS都可以轻松搞定，但是却是HCI架构的天然屏障，以上观点仅供作者参考，在此非常感谢作者的详尽分析，这篇作品瑕不遮瑜，着实是一篇精品。

 

    A：首先谢谢您的回复，这里其实是提到了两个问题，我逐个来回答。

 

    对于第一个问题，您说的没错，我的意思就是要两套技术架构，两套技术栈，这样的方式来实现异构基础平台，在一套技术栈的基础平台出现问题的时候不会对另外一套有影响，至于您说的存储资源浪费问题其实是不存在的，因为容量规划我们这边都是做强管理的。而且这个异构平台目前主要是做应用层而不是数据库层，对于数据库我们目前还是物理机加集中式存储的方式，后续会尝试通过DG等方式做逻辑层的数据库同步。

 

    对于第二个问题，可能是我没说清楚，我这里说的不是将块存储作为对象来使用。在hci池中中分为计算节点和存储节点，计算节点和存储节点在cpu、内存、硬盘上的配置是完全不同，来适应不同的场景需求，也不会存在资源浪费的问题。而且笔者这里说的hci是一种泛指，是指基于x86服务器加sds的解决方案，区别原来的使用san网络的集中式架构。

 

    Q3：实际业务系统上线过程中的主要痛点有哪些？要如何解决？

 

    A：业务系统上线在笔者看来主要包括以下几个方面，一是架构评审；二是基础资源创建；三是中间件的安装；四是应用发布；五是发布后验证；六是添加相应的监控。架构评审每个公司都有自己的流程和要求，而且也比较个性化，这里不在赘述。基础资源创建方面，存在如下痛点：1，一次性需要创建多台虚拟机的时候速度较慢；2，每台虚拟机都需要手动的设置ip地址；3，每台虚拟机需要手动设置主机名；这三步动作都是非常消耗时间，并且不能体现太多技术价值的。中间件安装方面，如果没有自动化工具的支持，或者容器化的支持，那么这个安装过程也是非常消耗人力的，并且每家公司在安装中间件的时候还有一些和业务相关的参数，这就导致了非常容易出错，浪费时间和精力。应用发布环节需要有CI/CD工具的打通，不然手工部署带来的工作量也是巨大的。发布后验证，目前很多企业还是采用发布后让开发来验证的方式，这个方式有个问题就是如果发布和开发不是一个人，那么发布人员是很难知道发布是否成功的，要解决这个痛点就要在发布后增加健康检查url，通过这个url来判断发布是否成功（至少覆盖80%的场景）。应用发布完成后，就需要对一些监控点配置监控，这又是人肉工作。因此综上所述，需要有打造一个全自动化的流水线并且配合流水线下平台的一些能力来解决以上痛点，笔者目前正在做这方面的工作。