超融合架构对金融行业来说是一种新兴的数据中心基础架构解决方案，借鉴了 Google 、 Facebook 等大型为互联网公司通过软件定义技术构建大规模数据中心的方法，结合虚拟化技术与企业 IT 的场景，不仅为企业从根本上将核心计算、存储和网络功能集成到单一软件或设备中的解决方案，更实现了存储向分布式架构和软件定义模式的转型。

超融合架构具备易扩展、高速网络、高性能与统一管理平台易管理等特点。目前我行数据中心已经使用了多年的传统外置存储架构，也暴露了出其扩展性差、灵活性低、管理复杂，成本高等问题。随着行内业务系统的增多，数据中心计算和存储规模的扩大，以及 PC 服务器虚拟化技术普及，需要研究新的架构提供将来提供高扩展性、高性能、高可靠性和可维护性的存储平台，同时又能简单管理，满足大部分业务按需灵活交付特性，是我行业务发展的需要。

金融数据中心面临的挑战：

1 、集中式存储性能和容量是瓶颈、分布式转型是大势所趋

2 、基础设施运维工作需要简单化，软件定义模式是趋势

3、技术多元化是维护银行 IT 基础设施安全的需求

金融企业的数据中心基础架构相对稳定，超融合架构作为一个传统稳定架构的挑战者和替代者，投入生产环境之前的选型必须慎之又慎，防止失之毫厘谬以千里的事情发生。金融企业都需要经过长期的论证和测试，组织了专门的团队对超融合架构进行了深入学习，对传统架构和超融合架构进行了深入比较，对各类超融合产品进行深度分析和验证，才能决定引入超融合架构。总体来看，超融合架构在虚拟化、分布式存储不断发展的前提下，推进了数据中心架构的分布式和软件定义转型，相比传统架构在可扩展性、可维护性上有明显优势，也在一定程度上压缩了 IT 基础资源的总体成本。另外，该架构也更容易在计算虚拟化、分布式存储以及硬件层面分别实现信息技术产品创新需求。以上这些原因，也是金融企业引入超融合架构作为 IT 基础架构转型的重要技术路线之一。

本场线上同行交流重点围绕解决数据中心面临的痛点，以及超融合技术路线如何选择对比，如何打造可持续的超融合架构方案为企业提供转型支持。 社区诚邀大家参与到活动中，一起对 金融行业超融合技术 进行深入交流 ，欢迎大家参与交流与学习。

Q：超融合虽精简了IT人员的日常管理，但一旦平台发生问题只能依靠原厂或服务提供商，是否容易被绑架？

超融合高度集成了网络、计算及存储，随简化了日常运维管理压力，但对于平台开局及平台级故障处理技能大大要求提升了，一旦平台有问题就只能更多的依靠原厂及服务提供商了，如何处理管理简单与故障处理难度的平衡呢？

EndlessRain （网吧资深的网管） , 网吧

【A】 即使没有使用超融合，数据中心的设施哪一个角色又能完全可以摆脱厂商呢？ 例如，使用超融合企业必定青睐于虚拟化，在没有超融合之前，虚拟化依赖于外部的集中存储：IBM，EMC，NetApp..etc当前的这些存储运维和故障，我们可以完全摆脱厂商吗？显然不能。而且还需要高昂的续保。另外存储之外还有存储网络，例如SAN。 由于超融合架构中99%依赖于X86平台，我个人到认为和该议题相斥，那就是---更不容易被绑定。 至少可以更加自信去更换一颗磁盘，而不是等待厂商存储工程师，更换代码绑定的“存储专用磁盘”。 其次讨论软件平台绑定， 如果选择主流的厂商，诸如--VMWARE，那么民间资源足够应对管理，而无需凡事依赖厂商。就像Linux，AIX，Oracle等，民间的高手的经验积累不一定会低于厂商。 以上结论是：不会被绑定，至少比较传统的IT基础设施，更开放，更易扩展，还有成本和能耗。

另外， 还有一些超融合厂商，软件平台基于开源Xen，KVM+GlusterFS，Cephe等包装的产品，而且是配合专有的硬件打包。这种方案后期使用，在“运维的方便性”和“厂商绑定”的程度上，见仁见智吧。 至少线下资源很有限。

seposal 系统工程师 , GUOSEN

【A】 不做改变被绑定是必然，换厂商也是换人绑架而已

避免被绑架，除了提升自我技能，还有就是运维管理经验标准化，规范化及自动化，并能构建平台屏蔽底层基础架构资源

但完全不被绑架不可能，毕竟术业有专攻。那么能降低绑架程度，并逐步拜托是个趋势方向。摆脱过程还要依赖公司的其他成本投入，比如人力。

另外，超融合高度集成后就简单么？不了解原理其实还是表面简单。其实超融合对运维人员要求很高，毕竟涉及存储、网络、计算，综合能力要强才能运维好，而非管理界面点点点。。

JanXC 系统架构师 , nec

【A】 平台的管理和维护需要花大力气，否则就容易被原厂绑定的厉害，但是使用平台应该能够借助运维自动化、自助服务以及标准流程模式，大大降低管理简单方面的工作，在省人的同时，提高人员的能力和技能，熟悉整体的架构和平台的各种组件，最大程度的降低原厂绑定。 由于原厂绑定的风险，建议还是选择大型厂商，避免不必要的麻烦。

nkj2021 系统架构师 , 金融行业

【A】 超融合平台的运维不能所有事情都依赖于厂商或服务提供商，超融合平过投入使用后需要做到以下几点：一是需要指定运维负责人，这个负责人可以是专岗也可以是兼任的岗位； 二是运维负责人需要对平台的整体情况有个清晰的认识和掌握，需要知道平台的物理部署情况，需要知道平台如何使用，常用的功能有哪些； 三是需要熟练的掌握超融合平台的各项指标信息的具体含义，平台自检的入口在哪里，哪些指标是需要重点关注的； 四 是运维人员应该经过服务商培训之后能够做到对平台的最合理使用，尽可能避免人工的误操作以及低效操作的发生； 五 是定期巡检，运维负责人应该定期的对平台进行巡检，这里的巡检主要包括物理资源情况巡检、平台端提供的巡检能力的巡检， 巡检时重点关注超融合平台的告警模块，可以将平台的报警信息记录下来做好日志的备份，统一进行报警管理；

潘延晟 系统工程师 , 第十区。散人

【A】 现在IT架构越来越复杂。除了超融合。其他的如虚拟化，容器，SDN等等技术都变得越来越复杂，其实都存在于这种被绑架的可能性。更多的还是企业自己要培养自己的架构师。对整体架构有全面的掌控。技术在不断的更替。自身对信息化不够了解的话就会被绑架。

yjn123 系统运维 , 中电科网络空间安全研究院

【A】 除非自研，否则被绑架是必要的，只不过程度不同而已。

瑞少爷 销售管理 , Synology 群晖

【A】 这种问题，总要有人背锅的，每个企业不能只进不出吧！

刘东 it技术咨询顾问 , 东软集团

【A】 首先，我们要搞清楚一个问题，就是超融合对于数据中心的意义是什么？超融合对于数据中心的意义其实就是精简IT系统架构，简化运维和日常管理，让数据中心的架构扁平化，变得没那么复杂。只需要服务器+交换机即可实现基础架构实施，其他的事情都交给软件来做，可以真正的实现软件定义数据中心的基础环境和架构。 如果说超融合这种架构容易被绑定，那只能说没有选对适合自己公司的技术路线。超融合只是一种技术架构而已，如果利用得好，那么就不会被绑定，反之亦然。 回顾传统的数据中心架构，敢问我们原来有没有被SAN存储架构绑定过?花费昂贵的光纤链路和设备费用？又有没有被集中式存储架构绑定过？升级扩容不够灵活？那么问题来了，如果选择了SAN架构存储，那么是不是扩容依然只能买SAN存储？如果选择了集中式的EMC存储交换机，那么扩容的时候是不是也只能买EMC的扩展柜？这算不是也是一种绑定？而且你后续的运维和服务依然要依赖原存储服务商，但是这么多年用过来，也还算用的不错，也没有人太质疑过绑定的问题。 回过头来看超融合，如果想选择开源和自主可控，那么可以多培养一些自己公司的专业人才，然后选择购买开源技术路线的超融合产品，如果出现问题，完全可以自己搞定，不需要依赖原厂商。如果喜欢将运维业务外包，不想过多的花费人员运维成本，那么完全可以选择一款成熟稳定的商业产品，如果出现问题，直接外包或者找原厂商解决就可以了。 所以，是否愿意被厂商绑架，是公司信息化发展选择技术路线和产品的问题，这个在一开始就应该是决策了的，而不是超融合这项技术架构的问题，超融合表示并不想背着这个锅。
GGY2020 技术经理 , 某银行数据中心

【A】 超融合架构避免日常的、多次执行的重复性工作，让基础环境设施管理运维人员相对空闲下来，从这一点来看，一些管理者认为人员清闲下来，可以精简人员，节省开支了。一般我们首先要批判一下这些企业和企业的管理者，存在这样管理思维方式的企业，严格的执行成本控制，让员工不停忙于琐碎事务当中，是不能够培养一批专业的技术人员的。从 Gartner 魔力象限的角度来讲，是追随者的角色，可以简单判断它的主业方面，就算较努力，也就是企业的模仿能力尚可，创造力一定很弱。发生问题时往往自身员工技术能力无法深入的更深层次，解决平台问题基本靠厂商或和厂商深度合作的服务商，使管理人员感觉被绑架了，但问题的根结不在 IT 人员自身。

前面主要是批判一下不太健康的企业文化和管理理念，其实，我想说的是超融合精简 IT 人员的日常管理，并非精简了 IT 人员知识水平和 IT 技能。精简 IT 人员的日常管理，指的是简化了日常运维工作，如虚拟化平台的搭建，存储交换机的配置和集中式存储的分盘等日常操作，将这些工作统一整合至超融合管理平台当中，通过集中的、自动化的部署方式、将基础环境搭建工作简化。但 IT 人员的技能需要提高，不但要了解虚拟化 kvm ，还需要深入了解分布式存储和一些网络 SDN 技术，简化人员可以，但技术骨干要保留，技术能力要跟上。

作为主业为非 IT 的企业，我们可以换一个角度来看这个问题。简单举个例子， 2000 年左右很多国有银行做大集中的时候，现阶段回头看，大部分国有银行应该感谢被 IBM 的 mainframe “绑架”了，如果不幸选择了日立或其他品牌，并且短时间内较深入的使用，后果是不是被 IBM 绑架更不幸。所以这里所谓的绑架，换成强力支持更有可信度。正所谓这么多年，我们被 IBM 、 Cisco 、 EMC 、 Oracle 、 VMware 等众多 IT 企业绑架的这么深入，现在换成超融合了、换成分布式数据库了、换成华为阿里云了，又有什么分别呢？

企业不想被厂商绑架，其实就是想得到更多的技术，能够自己解决一些问题，能够在与厂商沟通中获得更多话语权，能够将产品改造，提供更多的适合本企业的功能，能够自主决定是否进行产品切换，其途径也就是两条，第一，肯定是要加大投入，包括人员投入、技术投入、产品需求投入，将自己角色扮演成越来越贴近厂商的核心服务商；第二，购买一个产品的核心技术和源代码，或借助开源，从架构到需求，从产品设计到源代码编写、开发测试等工作一并自己解决，将自己的角色越来越贴近厂商。总之，一句话，看企业自身的决心和投入了。

孙伟光 IT顾问 , 中国金融电子化公司

【A】 被绑定那是肯定的，没啥可说的，不过被绑定带来的好处显而易见啊，以前出了 疑难杂症问题，各个厂商互相推诿，扯皮，超融合理论上他就很难找替罪羊了。 其实超融合就是实力强的集成商罢了，硬件是自己的，但是软件是都是别人家的。 说他封闭，他封闭的还不够，没有Linuxone的深厚的底蕴，说他开放，也开放的不够彻底。

赵海 技术经理 , 大连

【A】 被绑架是必然的，中国的IT行业已经被绑架了几十年了，只有被绑架的轻重缓急不同，没有绝对的不被绑架。只要不是自己生产的东西，多多少少都会被绑架，不被国外公司绑架也得被国内公司绑架。既然都是绑架，那么我们可以选择被谁绑架和绑架的轻重程度。选型的多元化和兼容化就是一个不错的策略。就像清朝的内阁取代相权一样，内阁大臣可以随时换，不同的时期不同的环境用不同的人。

Q：对于业务偏向互联网，应用系统较多采用分布式架构的民营银行，如何进行合理的超融合架构规划？

对于业务偏向互联网，应用系统较多采用分布式架构的民营银行，如何进行合理的超融合架构规划？超融合方面选型有哪些建议？

nkj2021** 系统架构师 , 金融行业

【A】 对于业务偏向互联网，应用系统较多采用分布式架构的民营银行，这样银行的渠道服务、服务支撑、办公管理类这些业务系统更适用于先迁到超融合平台上来，超融合架构最初以业务不敏感的系统中使用，在非数据库模块中先行推广，不断积累大规模使用超融合架构的经验，确保超融合架构稳步推进。

大夏 副总经理 , 英大基金

【A】 从形态上来看，超融合仍然脱离不了虚拟化主机的范畴，在对这类民营银行的架构规划时，仍然适用于虚拟化主机的规划方法。根据不同的应用类型，不同的应用等级，划分为不同的资源池。计算部分相对简单。但超融合需要额外考虑的是存储部分。和传统集中式存储不同，超融合采用数据副本的方式来保证数据的安全性。在提升数据安全性的同时，副本的损耗不能忽略不计。例如采用2副本时，由于所有数据是双写，规划容量就应该至少是需求容量的2倍。 3副本时，规划容量就至少是需求容量的3倍。

KZDXX 系统运维工程师 , 华夏人寿

【A】 采用超融合产品的出发点我认为有三个是比较关键的，结合自身使用超融合的经验，我简单描述一下。 一、稳定性。这是一个很难量化的一个概念，影响稳定性的因素也有很多，既跟厂商的技术和架构有关，也和自身维护能力有关。选择一个靠谱的厂商很重要，产品、服务两手都要抓；另外运维团队的技术能力专业程度也会影响超融合使用的状态， 二、维护性。一些IT规模比较小的公司可能需要外部技术团队的支持，采购的超融合产品市场占有率也是一个需要考虑的点，毕竟小众的产品所对应的市场上的技术人才也会少很多。而且对于工程师自身而言，考一些大厂的认证证书适用性、含金量也更高一些。 三、成本因素。往往大家预算都不太够，一体机形式的产品又往往比较贵，我们采用的是服务器、NVMe、超融合软件分开采购的形式，把各种部件都变成标准化的采购，能在一定程度上减少投入，相应的对运维团队的技术能力要求就会更高一些，在具体的产品搭配、产品设计以及后续维护都要求有相关的专业知识。 另外传统的超融合还是以虚拟化为主，这就造成了某些业务场景不适用的情况，面对这种情况，我们需要做一下架构上的改造，比如容器化、数据库一体机、软件定义存储等。

Q：传统架构和超融合架构各有哪些优缺点？为什么说超融合架构是未来发展趋势？

nkj2021 系统架构师 , 金融行业

【A】 超融合系统相对于传统架构具有以下优势：

1、 实现了计算、存储和网络资源的统一融合：传统架构下的计算资源和存储资源是分离的，服务器通过SAN交换机与存储设备连接获取存储空间。超融合技术改变了传统服务器、存储、网络相互孤立的基础架构，实现计算资源、存储资源和网络资源的统一融合，每一台超融合节点单元可同时提供计算资源和存储空间。超融合架构采用软件定义的体系结构，不再依赖于硬件，计算、存储、网络完全虚拟化并由软件控制。服务器和存储得到了统一的部署和管理，并为整个虚拟化体系提供了简单、通用的管理和自动化平台。

2、实现了设备的快速交付：超融合技术通过软硬件一体化的融合，实现设备快速交付、架构弹性伸缩、业务敏捷部署和系统精简运维。超融合一体机在出厂时已根据需求完成硬件的集成和软件的安装，设备上架开机即可交付使用，极大简化了设备安装调试的复杂度。

3、实现了资源的动态扩展：超融合技术基于虚拟化和软件定义，构建扁平化、随需而变、弹性可扩展的敏捷架构，所有资源均可按需部署、灵活调度和动态扩展。

4、提升了运维效率：传统架构下的计算资源、存储资源和网络资源由不同的设备提供，管理者必须分别通过不同的管理工具管理多种设备，超融合架构下只需通过单一的平台即可同时管理计算、存储和网络资源，降低运维难度，实现精简运维。

5、提升了系统的可靠性：超融合技术实现了计算、存储和网络资源的融合，原来分散在不同服务器和存储设备上的数据全部集中在超融合节点本地磁盘上，系统及数据的安全风险随即凸显。超融合架构采用集群管理方式，系统出现故障时能够自动在其他节点设备上重启，避免物理环境的单点故障。

6、保障了业务连续性和数据安全：数据多副本机制实现数据分散存放，不同数据副本放在不同的超融合节点上，当一个节点出现故障时，仍然可以依靠其他节点上的数据副本继续对外提供服务，有效保障业务连续性和数据安全。

JanXC** 系统架构师 , nec

【A】 业务在寻求转型、信息化建设也在要求进行数字化转型，这对信息系统和数据库的要求相比传统架构有了新的挑战，要求能够实现快速的功能迭代和更新发布、系统能够支持高并发、高可用（传统架构亦同），能够应对vuca( vuca是volatility（易变性），uncertainty（不确定性），complexity（复杂性），ambiguity（模糊性）的缩写)环境下业务发展，传统的架构相对比较问题、更新迭代慢，不易扩展，难以支持较大的并发和突发流量，且多手动运维，效率较为低下，不利于支持业务快速发展。超融合架构和混合云架构则可以很好的应对该类问题。

潘延晟 系统工程师 , 第十区。散人

【A】 从我的观点来看。超融合架构吸引我的就是简单管理。方便部署，高冗余。网络。计算存储的统一架构减少了部署时的问题。简化了操作流程。可以很方便的部署和增加各种节点，相比超融合。传统架构则吧上述所有的部分都要拆分开。在部署和维护上都有一定的困难。需要对网络，系统，存储多方面的知识都了解才能设计一套适合可靠的传统架构。而且从成本上。传统架构要达到一定的安全性也要比超融合投资多一些。 而对于超融合唯一担心的就是那个老问题。所有的鸡蛋放在一个篮子里。一旦超融合架构出现问题。那么就会导致整个业务的瘫痪。 从目前来看。市场上主流的厂家的超融合技术基本都过关。无论是超融合。还是传统架构。都开始对运维人员提出了更高的要求。如果运维者对自己的架构和环境一无所知。那么。超融合和传统架构所存在的风险其实都一样。

Q：超融合架构下如何实现双活建设？建设过程中需要注意的问题？

目前在同城双活方案上，并不是所有的超融合厂商都可以做的很好，受限于超融合架构的数据同步机制，需要实现数据同步复制传输，数据实时同步。如果做镜像同步，那么任何一个站点的分布式存储除了自身的3副本，还需要额外一套完整副本。其实可以理解为6个副本，对存储容量要求比较大。如果做拉伸集群，3副本可以，但是对于网络带宽要求比较高，而且任何一个站点发生故障，都会导致大规模的数据迁移，对性能影响非常大。那么目前超融合架构下如何实现双活建设？建设过程中需要注意的问题？

seposal** 系统工程师 , GUOSEN

【A】 超融合问世之初目的是面向运维能力一般用户提供开箱即用的便捷交付。随着使用深入，可用性问题开始考虑。

目前，双活方案中延伸集群较多，但存在很多局限性，因此影响实施效果。题主提到的资源容量问题，在任何高可用架构下都是存在。

说到延伸集群，重点其实是网络延时，比站点间的RTT不能超过5ms，站点到仲裁站点之间的RTT不超过200ms等。同时，注意脑裂问题，不同负载业务串扰问题、组网问题等

其实，基础架构资源层做好稳定服务，可用性从应用层实现也是个好方法。没必要在选择困难或技术程度不足时硬上。

大夏 副总经理 , 英大基金

【A】 同城双活的超融合方案，确实很多厂商做的并不好。很多超融合产品数据的副本流动只在一个故障域（或者一个集群），在架构设计之初并未考虑到拉伸集群之类的多故障域双活应用。虽然从逻辑架构上来看，拉伸集群仅仅是把同一个集群中的节点分布在不同的物理地域，但由于有多个故障域的存在，对数据同步的设计其实是有很高要求的。受限于网络链路的影响， 当前常见的双活都是同城这类短距离双活，这是因为当距离拉开过远时，链路的RTT时延无法保证数据在两个数据中心间的同步返回要求。所以我们一般建议同城双活的两个数据中心物理距离不超过50KM，最好能使用裸纤直连。同时尽量选择国际大厂的成熟方案，并且进行基于实际业务的Poc测试，尽量降低试错成本。

JanXC** 系统架构师 , nec

【A】 是否可以从系统、数据库层面上来实现所谓的双活，即通过高速网络打通同城双数据中心，然后应用两地部署、数据库两地同步，应用用到的文件及附件服务采用分布式文件架构实现两地实时同步，这样既实现了系统的扩容增加并发又实现双活应用，会不好好一点？

Q：超融合产品的对比和选择？

现在无论国内国外，超融合产品层出不穷，有基于kvm的，有基于vm的。我们应该怎么选择？超融合技术，哪方面才是最应该关注的点呢？

GGY2020 技术经理 , 某银行数据中心

【A】 超融合技术的选择，总体上一句话：合适的就是最好的。

1、 超融合不是适合所有企业 :

超融合不是适合所有企业，是由企业的组织架构、性质等决定的。超融合肯定不适用于大部分公有云提供商，对公有云厂商而言，技术能力超过超融合厂商，产品功能和涉及范围也超过超过超融合厂商，使用超融合产品会稀释公有云厂商利润；同理，超融合技术架构对于已经建立私有云的企业，除非特别更新换代需求，一般仅仅将超融合架构作为区域的补充，不会大规模投入超融合架构；还有就是超融合架构作为相对新颖的技术产品，也不太适合非常保守的企业。各企业的接受程度不同，在相对保守的企业中，很多财务采购商品分类中没有该项分类，鉴于集中采购风险、内部流程管控繁杂等，没有合适的途径进行采购或投入人力资源研究。

以上三种企业情况，均不适合使用超融合架构。

2、 超融合不是适合所有场景：

超融合技术有特有的技术特征，不同业务需求，导致并不是所有的业务场景都适合超融合架构。举几个例子，比如需要存储大量音视频的应用，不适合放在超融合上，是因为对象存储架构更合适，实施价格更便宜；用于类似 hadoop 大数据分析的应用，不适合用超融合，主要是在存储底层、 hadoop 应用层两次进行存储的副本和条带化处理，效率降低为原有物理机的 40% 或更低；再比如，有些特殊的应用需要特殊的外设， GPU 、 USBkey 等这些应用使用超融合的代价也非常高。

其实，超融合的选择最需要关注的方面就是：是否合适，主要就是分析以上两点，一个是企业的环境，一个是企业业务的场景。总之，引入超融合架构本质就是一种改变，改变技术容易，改变人或企业环境难。

潘延晟** 系统工程师 , 第十区。散人

【A】 底层的技术大体上就是您提的这些。至于选择。我觉得一时看自身的需求。是否超融合是最合适的解决方案。二是选品牌和技术实力。几个大厂在超融合上的技术投入和后续的研发有保障。基本上差距就不算太大。三是看企业性质。是否涉及到完全国产化的趋势。如果是，那么一部分品牌自然就要放弃了。

Q：超融合与私有云对比，优缺点分别是什么？

nkj2021** 系统架构师 , 金融行业

【A】 超融合与私有云不具有可比性： 1.目前主流私有云参考架构主要包含三个层次： IaaS 层、PaaS 层以及云管理平台，企业进行私有云改造应该根据自己的实际需求逐步落地； 2.IaaS 层是私有云最核心和最基础的部分，也是企业 IT 云化应该首先着手的部分。云化不仅要解决计算、存储等资源自助和自动交付，更要解决传统架构带来的资源池分离、维护复杂，无法弹性扩展等问题。 3.超融合和私有云不是被替代的关系，恰恰相反，超融合产品让 IaaS 层真正具备了分布式架构和软件定义属性，从而带来存储和计算资源的整合、按需扩展和按需投资的“云”特性，而融合部署方式进一步简化了 IT 基础架构，并降低了系统的总拥有成本； 4.基于商用超融合产品进行私有云 IaaS 层云化改造正在成为主流方案，该方案在可靠性、扩展性、开放性、易用性等方面具有独特的优势。

Q：超融合是否自带的监控？能否做到全方位完美监控？

超融合是否自带的监控？能否做到全方位完美监控？是否还需借助其他第三方监控系统来完善？

nkj2021 系统架构师 , 金融行业

超融合架构下的监控都是各个超融合基础架构厂商自己的产品，超融合基础架构对设备的管理要求比较高，因为一个超融合架构需要许多物理机组成。如果没有监控管理平台是无法想象的。所以在超融合架构下，一定是集中监控的，就看你选用哪个厂商的产品了，都配置有相应的集中监控平台。一个超融合平台，计算服务、存储服务、网络服务和监控服务都是融合在一起的。全方位完美监控市面上也有很多成熟的解决方案，有开源的，也有商业化的，用户结合自身的需求选择即可。

赵海 技术经理 , 大连

【A】 超融合产品就是个大集成体，里面软硬件都集成了，监控是其中必备的软件模块。但是它自己的监控软件模块是否能做到全方位完美就看我们对运维监控的要求了。不同的企业对运维监控的要求是不一样的，维度也是不一样的。

就经验来讲，超融合自带的监控对于一般的用户来讲，功能上基本够用。但是要想实现较高级的运维监控目标，一般是不太可能的。因为较高级的运维监控会因行业、架构、环境等因素不同而有自己的侧重点，超融合就是个通用产品，不可能面面俱到。产品生产商也不可能理解每个企业对IT的特殊需求。

Q： 超融合相关故障处理案例？

超融合技术已经运用多年了，有没有一些常见的故障案例，希望能分享一下。

nkj2021 系统架构师 , 金融行业

【A】 超融合网络问题的解决办法

可尝试从以下几个方面的因素去解决超融合环境中的网络问题：

保证网络具有较高的性能。10千兆以太网(GbE)是基本。使用光纤用于互连，而不是铜线电缆。大多数环境中，使用顶级机架交换机连接的节点到节点的内部通信，确保到核心节点有40 GbE的上行速度，确保连接到其他环境的带宽。

理想情况下，应在环境中预布线和保留预置的接线板，以适应活动组件间在最终连接完成前的变化。这样做的目标是不必打开一个节点来进行移动、添加和更改。这种设计被称为真正的结构化布线，能够解决最大网络的所有性能问题：次优的性能或总连接性的损失。

实施专用存储网络。大多数超融合的架构需要在所有的网段(存储和计算)实施以太网，要把存储的I/O放到一个特定的网络区段。专用的超融合网络将存储流量从服务器间的流量中拆分出来，保证性能上的一致性。

检查超融合架构中的数据是如何存储的。所有的超融合架构必须以某种方式呈现出对存储访问的共享，即使存储本身是内部性质。到目前为止，供应商提供了两种方法来进行实现：

在超融合架构的一个或其他多个节点上复制一套与虚拟机本身近乎一致的镜像。如果虚拟机需要迁移，该复制的景象可以实例化任意一个存储节点。虽然从容量角度来说有些浪费，但它可以从减少存储I/O的角度，通过只囊括少数几个节点的方式来规避这一弊端。

汇聚过程把所有的内部媒体到集群的节点汇集创建一个虚拟池。尽管从容量的角度来看更具效率，但汇聚的方法通常需要产生更高的I/O流量(从而加重网络负担)。

供应商在这两种方法上有自己的微调，因此不同的产品中的诠释也不尽相同。

超融合网络的主要挑战之一是缩放。要解决物理缩放问题，应该使用如前文所述的结构化的布线方法。随着节点数量的增加，特别是用聚合方法时，软件问题变得更加复杂。节点越多，存储的I/O流量就越大，环境变得越来越复杂。如果公司计划设置几十个节点，并有具体的性能期望，带有专用级别计算和存储层的传统的架构可能是更合适的方法。