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

字数 11574阅读 5673评论 0赞 10

目前云计算比较火热，企业使用云计算服务一般有两种方式，一种是直接使用公有云厂商的服务，一种是使用企业级私有云。大多数小公司和对数据安全性要求不高的公司会采用公有云的方案，实施成本低，真正的按需供给；对于金融企业而言，使用公有云一方面会担心数据泄露的问题，另一方面可能会存在监管方面的问题，因此大多会采用企业级私有云的方案。但是金融企业的规模也有大小之分，规模大的金融企业（例如银行）在it基础资源投入（包括机房物理容量、每年预算、人员投入等）方面远远高于规模较小的金融企业（例如券商、基金、期货等），那么对于规模较小的金融企业应该如何建设企业级私有云，来满足自身的发展需要？在笔者看来，引入超融合技术方案，就是解决这个痛点的一种不错的思路。一方面超融合平台投入资金远小于计算与存储分离的云平台，同时由于省略了外置的san网络，在一定程度上还节约了物理空间，间接再次降低了成本；另一方面超融合平台在功能上和性能上与计算存储分离的云平台相比也是不相上下，甚至在功能方面是占有优势的。具备这样性价比的产品，对中小金融企业还是具备较强吸引力的。
在3月29日的线上交流活动中，围绕着中小型金融企业如何基于超融合技术建设私有云需求进行了讨论，也得到了各位专家的支持，大家针对超融合的相关问题体现出了非常大的热情，在此也对相关问题及大家的观点总结如下：

## 一、超融合技术的成本问题
**典型问题：
Q1：中小金融上云的成本如何控制？
Q2：超融合和传统FC架构成本对比？**

问题解答：
A1:
确实在不考虑商业授权的情况下，vmware可以认为是没有成本的，但是这样做是有风险的，一旦被vmware控告，问题就不单单是钱的问题了。基于超融合平台构建私有云成本需要从几个层面考虑，一是物理空间的成本和电力成本，从这个角度说，超融合平台的成本是比较低的；二是超融合平台的软件授权版本费用；三是超融合平台的物理机资源成本；至于成本的控制，有几点可以参考，一是有些厂商的一体机解决方案会比自己买硬件再采购软件的方式便宜；二是可以先购买最小化集群（这也是为什么我在文章中提到中小金融企业要特别在意最小化部署的规模）；三是要选择采用通用x86服务器部署的，这样的话即使发现超融合不好用，至少物理机还可以用作其他用途，变相的降低了成本。
A2:
超融合平台相比于传统FC架构最直接而言是节省了san网络的相关费用，间接而言还节约了机柜空间和电力资源，对于很多租赁机柜的中小金融行业而言，这还是节约了不少成本。另外就是在应对快速扩容的资源需求时，超融合架构上线所需时间远远小于传统fc架构，可以说是插上线就可以使用，时间成本也降低了很多。最后，很多超融合平台都自带备份和cdp能力，这样又对于单独购买而言，又是省了一笔钱。

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

**典型问题：
Q1：超融合架构或者说云架构如何满足数据库性能需求？
Q2：已经建成了企业的私有云，如何和现有的系统进行整合？
Q3：核心系统采用超融合架构，如何向用户证明超融合架构同样适用？
Q4：什么场景，部署哪些类型的业务系统，需要考虑应用超融合技术？
Q5：为什么基于超融合架构构建企业级私有云适合中小金融企业？**

问题解答：
A1：
您提出的问题其实就是想知道超融合架构能否满足oracle的性能需求，毕竟虚拟化以后计算资源肯定是会有损失的，这个问题最好的答案不能仅仅是从理论的角度分析，更多的还是要进行实测。可以先收集目前数据基于物理机运行的性能指标，然后与超融合平台部署数据库进行对比测试，这样真实测试出来的数据更具有说服力。另外一个层面来说，有些超融合厂商还专门针对主流的数据库oracle和db2做了优化，而且每家的场景和需求不同，因此笔者的建议还是真实测试的结果更具有说服力。
A2：
这个问题其实是两个问题，一是已有的云环境如何与传统的环境整合；二是这两个环境之间如何进行数据共享。对于第一个问题，很多企业的传统环境都都是外购的系统，对于这类系统由于程序无法进行改造，最多只能上iaas层，使用iaas层提供的资源。对于传统系统不是外购的系统，而是自研的系统，则可以通过逐步改造优化的方式上iaas层或者是paas层。对于第二个问题，系统之间数据共享的方式有很多，问答这个问题还是要看主要是针对什么数据，现在业内做数据湖的比较多，数据湖就是利用大数据技术将各方的数据进行汇总，并提供实时或者非实时的服务。如果是业务系统之间的文件数据交换，可以采用对象存储，文件服务器等方式进行。如果是消息或者指令信息的共享，则可以使用消息队列来进行。
A3：
性能不好，这里涉及两个问题。一是超融合技术都在不断的发展，不知道您是测试的是哪一年的产品？二是超融合厂家和厂家的能力差距比较大，这就需要在poc测试的时候进行充分的评估，根据笔者所知，现在很多超融合平台的io能力已经超越例如emc、ibm这些大厂的中端存储能力；三是部署是否合理，如果你说的是db性能不好，那就要看你部署db的方式是否是超融合厂商建议的最佳实践；至少在笔者看来，目前的超融合技术计算能力是可以应对中小金融企业80%的业务场景。
第二个问题，说白了是用户对超融合技术不信任。这个没有特别好的办法，只能通过实践和案例来向用户证明，毕竟这不是一个技术问题，而是一种理念和态度问题。
A4：
这两者其实是没有必然联系的，就像业务系统不知道自己是跑在虚拟机上还是跑在物理机上是一样的。如果真的要深究的话，对io要求高的系统由于超融合技术的io路径要短一些，因此在同等磁盘和软件算法的配置下，超融合技术栈的io性能应该会对io密集型的业务更加友好。
A5：
金融企业的规模也有大小之分，规模大的金融企业（例如银行）在it基础资源投入（包括机房物理容量、每年预算、人员投入等）方面远远高于规模较小的金融企业（例如券商、基金、期货等），那么对于规模较小的金融企业应该如何建设企业级私有云，在笔者看来，引入超融合技术方案，就是解决这个痛点的一种不错的思路。一是超融合平台投入资金远小于计算与存储分离的云平台，同时由于省略了外置的san网络，在一定程度上还节约了物理空间，间接再次降低了成本；二是超融合平台在功能上和性能上与计算存储分离的云平台相比也是不相上下，甚至在功能方面是占有优势的（例如自带cdp、备份工具等）。具备这样性价比的产品，对中小金融企业还是具备较强吸引力的；三是一般而言超融合平台扩容方便，只需要上架x86服务器并连接好网络就可以快速投入使用，这对于人数较少的中小金融企业而言还是很有帮助的。

## 三、超融合平台带来的风险问题
**典型问题：
Q1：实际部署和使用过程中，发现的超融合模式的缺点有哪些？
Q2：超融合架构实际部署案例中最大规模的单体集群有多大，有哪些运维风险点？
Q3：在一定预算前提下，怎样才能采到最优的超融合产品与服务，怎样避免踩坑？
Q4：使用超融合技术会带来哪些新的运行风险如何规避？
Q5：关于超融合架构的分布式存储的稳定性和安全性问题？
Q6：在选择超融合产品时应该注重哪些方面的考虑？**

相关解答：
A1:
笔者看来目前超融合架构主要的缺点有两点，一是稳定性，二是有磁盘或者主机损坏时数据重建过程对性能的影响。先来看稳定性，现在很多企业只将超融合使用在开发和测试环境也是因为超融合的稳定性问题，产生这个问题的主要原因一方面是超融合技术发展的时间不如集中式技术栈，另一方面是超融合技术和集中式相比还是省略了很多硬件的，众多的功能有纯软件或者x86服务器自身的硬件来实现，增加了硬件故障风险，最后x86服务器本身的稳定性就不如集中式存储，再次增加的风险。对于第二点，还是受限于超融合技术栈自身的原因，数据重建过程都会对性能带来影响，不过这个问题各个厂商也都给出了解决方案，都是处于优化的状态。在笔者看来，基于x86的服务器的技术栈，其设计思维的初衷就不是稳定性，而是性价比和集群规模，那么如果计划采用这样的技术栈，就需要想办法规避其缺点，充分发挥其优点。
A2：
笔者接触的范围有限，在笔者知道的实际跑在生产环境上最大的超融合集群是80+台物理服务器。对于超融合的大集群运维，有以下几点需要考虑：一是亲和性和反亲和性的使用，这里包括机柜级和服务器级；二是有些超融合平台集群大了以后，能够进行故障域的划分，建议做好划分；三是集群规模大了以后，需要增强平台的巡检频率，在合同里写清楚巡检的要求；四是集群规模大，需要做好网络设备连接的规划，以便在出问题时快速排查；五是自动化运维工具的同步配置。
A3：
这个问题其实操作起来并不难。首先，在预算一定的前提下，就可以排除掉一些预算超标的产品，这样就初步的减少了可选的范围；其次，梳理清楚自己公司的具体需求和痛点，最希望超融合平台为你解决什么样的问题，把这些问题落成书面形式；再次，在不提前给出问题的情况下，邀请过了第一关的公司的销售和技术人员进行现场的沟通，在沟通会上提出所有的书面问题，一般情况下，有些问题应该是厂商那边不能直接回答，是需要回去确认的。这就正好是检测厂商服务态度和对你重视程度的一个重要指标，因为有些厂商表面说回去确认完给答复，结果往往是石沉大海，通过这个方式又可以踢出一些厂商；再次，就是从剩下的里面进行poc测试，硬实力的比拼，同时甲方应该以稳定性测试为理由，尽可能的多测试一段时间，测试时间越久，出现问题的概率越大。接下来，就是故意制造一些故障的场景，然后看厂商的反应速度和服务态度。经过以上这些筛选，我相信你的心里也有了中意的产品，最后就是商务上的问题了。
A4：
您提出这个问题的本质还是对超融合平台本身的稳定性和安全性存在疑问，这个是非常正常的。要把风险降到最低，在笔者看来需要做以下几方面工作。一是在poc阶段做好各种风险场景，进行验证，并详细进行记录，条件允许的话，poc阶段尽可能的拉长时间，因为有些问题在运行一定时间后才会被发现；二是在内部上线后，最好先运行在开发和测试环境，在开发和测试环境运行一定的业务和时间后（一般建议最少是半年时间），再考虑向生产系统迁移，并且上生产系统也要先上非核心的重要系统，再上核心的重要系统；三是一旦上生产后，对重要的虚拟机进行备份，以应对不时之需；四是要求厂商定期检查平台的状态，该升级的进行升级。
A5：
这个问题确实是金融行业用户比较关注的问题，在笔者看来这里有三个层面的问题。一是数据自身的保护机制，例如多副本或者纠删码方式是否可靠等，对于这方面的问题首先需要让厂家把机制彻底讲清楚讲透，然后针对性的提出各种疑问，并得到让人满意的答复；二是各种物理故障时的表现，这个说实话除了在poc测试的时候进行各种场景的验证，并没有特别好的方案；三是数据备份方面，现在做的好一些的基于超融合的分布式存储都会提供常规的定时备份和CDP备份两种方式，这个也是需要在poc测试的时候进行测试。总的来说无论是什么架构都无法完全保证数据没有问题，做好各种灾难测试并且设计好应对方案，才是以不变应万变。
A6：
一是较为成熟的案例。这里所谓的成熟案例，不是指签了多大的合同或者部署了多大的规模，而是首先要看案例使用在什么行业，不同行业对云平台稳定性、性能和功能的要求是不同的，其次是场景，要看案例是用该平台做生产环境还是开发测试环境，最后是看规模，云平台部署规模不同遇到的技术难点也是不同的。
二是出品这个产品的公司具有一定的实力或者规模。不能说还没过几天这个公司倒闭了，这个产品没有了。笔者浅见世界500强、上市公司（国外以及A股）、业界运营10年以上口碑还不错的公司都能算是有实力的公司。
三是在产品层面云平台是该公司的主要战略方向。属于公司战略规划里的项目可以得到尽可能多的公司级资源的支持，是能够持久化的。
四是POC测试能够满足需求。简单说下笔者认为POC测试应该关注些什么，对于金融行业而言，基础设施类最需要关注的就是稳定性（不允许丢数据、不允许经常的不能对外提供服务）和性能（批量预算场景较多），然后才是功能。对于企业私有云平台而言，稳定性测试除了比较暴力的，拔出磁盘、机器断电、机器关机等，还需要承载业务跑一段时间，至少是3个月。性能测试则用通用的性能压测工具就可以。功能测试有一点容易被遗漏，就是平台提供的api接口是否好用，是否稳定。
五是最小化部署的规模。对于中小型金融企业而言，机房容量有限，空闲的备机有限，那么在进行poc测试的时候就需要关注该企业级私有云平台部署起来最小需要多少个物理节点，是否是本企业能够承受的。

## 四、超融合平台迁移和上云问题
**典型问题：
Q1：超融合架构后续如何向私有云平台架构转型？
Q2：已经建成了企业的私有云，如何和现有的系统进行整合？
Q3：中小型金融企业上云的过程如果是平移过程，我觉得大家上云的意向会更强？
Q4：现有环境如何迁移到超融合环境？
Q5：中小金融企业是否有必要上云？
Q6：中小金融行业应该如何规划上云？**

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

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

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

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

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

A6：
众所周知，云计算的经典模型里把云计算分为IAAS、PAAS和SAAS层，那么企业的决策者在进行企业上云规划的时候就需要先做好计划，想清楚三个问题。
第一个问题，即目前准备上到哪一层的云。因为每一层的云能实现的服务能力是不同的，对云平台的运维人员要求是不同的，同时对云平台提供者的要求也是不同的。
第二个问题，企业建设的云平台准备用在哪些场景。这里的场景主要是指传统的应用系统，还是互联网化的应用。目前根据笔者对同行业的了解和本公司实践，IAAS层可以覆盖传统的应用系统和互联网化的应用，但是PAAS层主要还是覆盖自研为主的互联网应用。
第三个问题，企业建设的云平台按照什么样的发展路线进行前进。引入任何一项新技术，一般都需要有一个适应水土的过程以及推广前进的过程。大多数企业的做法都是先从开发测试环境切入，推广到非核心的生产系统，再到核心的生产系统这样的一个过程。
搞清楚这些问题以后，决策者找到目前最大的痛点是什么，最想要解决什么样的问题，然后就可以按照规划先做起来，期间一定会遇到各种问题，再逐步解决。

## 五、超融合平台架构与传统FC架构问题
**Q1：目前传统架构vmware加fc有必要让超融合淘汰吗？
Q2：对nutanix和smartx搭载vmware计算虚拟化而非自研的计算虚拟化是什么看法？
Q3：传统架构会被超融合架构替代掉吗？**

相关解答：
A1：
第一个问题：笔者不敢妄言能否在多少年后被替代掉。毕竟很多系统目前都是基于传统的架构在运行的，从实际的角度出发，在传统架构没有出现非常无法解决的问题的时候，是不会有人有动力去使用超融合架构替代传统架构的，这里不仅仅是一个技术问题，更重要的是系统的稳定性的问题，就像现在很多大银行还在用ibm的as400，因为运行的很稳定，没有遇到必须更换的理由，大多数情况下，领导是不愿意承担风险做这个事的。另一方面，也是笔者目前正在做的一件事情，就是异构平台的建设。使用传统架构和超融合架构两套不同的技术栈，可以从平台层面实现高可用，哪怕一套技术架构完全挂了，对于我另外一个技术架构也是没有影响的。就像现在很多使用公有云的公司，会同时使用腾讯云和阿里云是一样的道理。所以，在笔者看来，目前没有发现超融合完全替代传统架构的契机，我认为共存还是主旋律。
第二个问题：传统的方式和超融合是两套技术路线，没有你死我活的必要。笔者认为使用哪个模式不重要，重要的是能够满足需求，没有必要为了用谁而用。
第三个问题：在笔者看来超融合的分布式存储是他的一个特征。至于是否靠谱，这就涉及稳定性的问题了，稳定性的问题是要时间来验证的，这也是选型做poc需要考量的点之一。““个人认为中小金融企业不想互联网行业有突发的大规模资源的需求””这句话笔者不是很赞同，因为笔者做在企业近年来就有突发的大量资源需求，这个需求是否会存在还是和公司的业务方向相关的。

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

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

## 六、产品与厂商
**Q1：各超融合厂家的特点和优势分别是什么？
Q2：可以横向分析下主流超融合厂商的优缺点吗？
Q3：请问华为、惠普（新华三）、深信服三个厂家的私有云（专属云）的产品优劣分析？
Q4：如何选定超融合厂家？
Q5：超融合服务器硬件设备如何选择？**

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

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

A3：
笔者没有都测试过以上产品，而且每家的产品更新迭代都很快，笔者在这里分析会有失公允，所以不能进行分析。这样类似的问题在这次讨论中有些老师有提到，其实对于这个问题，笔者的建议是首先梳理清楚自己公司的具体需求和痛点，最希望超融合平台为你解决什么样的问题，把这些问题落成书面形式；再次，在不提前给出问题的情况下，邀请过了第一关的公司的销售和技术人员进行现场的沟通，在沟通会上提出所有的书面问题，一般情况下，有些问题应该是厂商那边不能直接回答，是需要回去确认的。这就正好是检测厂商服务态度和对你重视程度的一个重要指标，因为有些厂商表面说回去确认完给答复，结果往往是石沉大海，通过这个方式又可以踢出一些厂商；再次，就是从剩下的里面进行poc测试，硬实力的比拼，同时甲方应该以稳定性测试为理由，尽可能的多测试一段时间，测试时间越久，出现问题的概率越大。接下来，就是故意制造一些故障的场景，然后看厂商的反应速度和服务态度。经过以上这些筛选，我相信你的心里也有了中意的产品，最后就是商务上的问题了。

A4：
一是较为成熟的案例。这里所谓的成熟案例，不是指签了多大的合同或者部署了多大的规模，而是首先要看案例使用在什么行业，不同行业对云平台稳定性、性能和功能的要求是不同的.
二是公司具有一定的实力或者规模。既然是选择一个合作伙伴，而不是做一锤子的买卖，不能说还没过几天这个公司倒闭了。如果出现了这样的情况，那么之前在这个平台上的投入都相当于是石沉大海了，这对于大多数中小型金融行业是不能接受的。
三是在产品层面云平台是该公司的主要战略方向。这一条其实和第二条是有一定的关联性的，如果这家企业是符合条件二的，但是这家企业的产品里没有私有云平台或者是产品里有私有云平台，但是战略规划里没有私有云平台那么你在选择的时候就不能单纯的认为这家企业有实力，你就去选择。毕竟不在战略规划的里的产品，一方面得不到公司级资源的支持，另一方面也可能有被裁掉的风险。
四是合作态度积极。这里的合作态度积极不是指厂商积极的把产品卖给客户，而是认同前文所述能够积极的和客户一起建设属于客户的企业级私有云平台，在此前提下，合作态度积极还应该包括：首先，愿意听取客户的来自一线的真实需求，了解客户的痛点；其次，对于客户提出的关于云平台方面的问题能够快速的响应；再次，云平台在测试或者使用过程中如遇到问题，厂商的工程师能够第一时间到达现场或者远程处理（根据具体的情况）；最后，厂商能够定期举行交流活动，进一步收集用户对云平台的使用情况。

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

七，其他
典型问题：
Q1：
甲方用户在超融合的扩展性方面是怎么考虑的？
Q2：
分离式部署架构SDS都可以轻松搞定，但却是HCI架构的天然屏障？
Q3：
实际业务系统上线过程中的主要痛点有哪些？要如何解决？

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

A2：
首先谢谢您的回复，这里其实是提到了两个问题，我逐个来回答。
对于第一个问题，您说的没错，我的意思就是要两套技术架构，两套技术栈，这样的方式来实现异构基础平台，在一套技术栈的基础平台出现问题的时候不会对另外一套有影响，至于您说的存储资源浪费问题其实是不存在的，因为容量规划我们这边都是做强管理的。而且这个异构平台目前主要是做应用层而不是数据库层，对于数据库我们目前还是物理机加集中式存储的方式，后续会尝试通过DG等方式做逻辑层的数据库同步。
对于第二个问题，可能是我没说清楚，我这里说的不是将块存储作为对象来使用。在hci池中中分为计算节点和存储节点，计算节点和存储节点在cpu、内存、硬盘上的配置是完全不同，来适应不同的场景需求，也不会存在资源浪费的问题。而且笔者这里说的hci是一种泛指，是指基于x86服务器加sds的解决方案，区别原来的使用san网络的集中式架构。
如果我说的不清楚，我们还可以继续讨论，谢谢。

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

证券私有云证券超融合平台超融合厂商成本评估风险评估

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！

添加新评论0 条评论

Ctrl+Enter 发表

匿名评论

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

添加新评论0 条评论

本文隶属于专栏

作者其他文章

相关文章

相关问题

相关资料