一、前言

近年来，银行业 IT 基础架构正进行着前所未有的挑战与变革。不仅业务互联网化和数字化对 IT 基础架构的可靠性、性能、弹性、开放性提出更苛刻的要求，日益激烈的竞争也对 IT 基础架构总拥有成本提出更高的要求。

基于以上挑战，不仅银行业信息科技“十三五”发展规划中对基础架构提出了云计算建设、分布式架构改造、弹性开放可计量的计算存储资源池建设等指导意见；而且银行自身在进行核心系统解耦、x86架构迁移，也在IT基础架构的分布式和云化转型等领域不断进行新技术的探索。

然而，目前市场上基于私有云部署的分布式架构路线多种多样，应该如何评估和选择？目前快速增长的分布式架构——超融合、存算分离，与云计算、存储计算资源池化以及分布式改造等方向分别是什么关系？有哪些独特价值？超融合产品应该从哪些维度评估？产品实际指标如何？市场趋势和市场格局是什么样的？
为解答以上疑问， TWT 社区特邀请超融合金融行业的专家——SmartX ，基于诸多银行从技术路线到应用场景落地的思考与实践，整理了“银行 IT 基础架构分布式和云化改造技术路线评估“专题，并以“技术路线和产品评估篇”(5月29号上线)和“场景实战篇”(6月5号上线)分别呈现。

本场 “技术路线和产品评估篇”更多交流问题回顾：https://www.talkwithtrend.com/Activity/index/op/question/id/1563

二、梳理交流活动中十五个典型问题

【问题1】银行业务系统与分布式/云化基础架构的结合？

银行业务系统分为前、中、后台，该如何评估何种类型的系统适合采用分布式/云化的基础架构？如何实现业务系统的无缝、平衡上云？

【解答】

观点1：
1、银行业务系统后台为业务和数据的集中处理，对于这类业务，建议采用传统架构。由于分布式/云化架构注重灵活和敏捷性，容错性和性能，对与实务一致性处理能力不强。而银行后台系统对灵活性要求不高、业务和数据实时一致性和可靠性要求比较高，使用传统集中式架构比较合适。

2、银行业务中台现在流行的做法是采用微服务的架构，底层使用基于云原生的容器架构，对于这类应用最适合采用超融合架构。因为超融合架构具有敏捷和按需扩容的特性，可以满足微服务快速部署和灵活响应的要求。而且超融合系统使用分布式架构，可以提升横向扩展，资源利用率高，存储性能可以做到近线性提升，在整体资源利用率上也比传统集中式架构优势明显。所以银行中台业务最适合分布式架构。

3、银行业务前台多为业务应用系统，通常使用虚拟机的方式进行部署，采用基于虚拟化软件的云化架构最为合适。而且云化架构也可以采用分布式超融合系统进行部署，提升云环境性能、灵活、按需扩展等特性。可以实现业务系统的无缝、平衡上云。

观点2：
云化的基础是虚拟化，因此适合部署在虚拟化环境中的业务系统基本都是适合采用云化的基础架构的。反过来说，什么样的业务系统不适合部署在云化的基础架构之上呢？对于那些资源消耗特别大的，延迟敏感度要求特别高的业务系统确实不适合。而对于那些应用发布特别快的业务系统就非常适合采用云化的基础架构形式。

对于银行的业务系统来说，前台的业务系统逐步互联网化，要求快速迭代快速发布，同时在一些特殊的场景下需要能够快速扩展，非常适合部署在私有云环境下部署。

而同时中台系统不断解耦，采用微服务的进行部署，通过业务系统自身实现高可用，增强业务连续性，通过云化平台提供的分布式部署以及数据保护功能，也非常适合在私有云环境下部署。

针对具体的业务类型来看，交易类业务、创新型业务以及周边系统都非常适合部署在云化平台上。

【问题2】云化架构和分布式架构都能解决银行哪些业务问题？

银行业务系统对敏捷性和灵活性要求越来越高，在业务上也开始采用微服务进行解释，新的IT基础架构如何满足这类要求？云化架构和分布式架构都能解决哪些问题？

【解答】

**
观点1：**
云化架构更多是指一个逻辑概念，即如何构建企业IT基础架构的云化转型（也就是我们常说的云计算），而分布式架构是一项技术，是云化数据中心的技术支撑手段之一。

云化架构解决的是企业数据中心的宏观问题，分布式架构解决的是数据中心具体的计算、存储等技术手段。

银行业务系统对敏捷性和灵活性要求越来越高，容器化、微服务更是其中的代表，如果使用传统架构是很难支撑和满足这类业务的发展需求，而分布式架构的弹性伸缩、按需扩展、高性能、高可靠等特点可以很好的满足上层灵活多变的业务形态，结合分布式架构的API能力，与CMP等平台对接，最终协助用户数据中心云化演进。

观点2：
1、云化架构可以解决银行业务系统对资源使用的灵活性的问题，可以按需提供各种资源，包括计算、存储和网络资源等。主要解决银行业务资源的使用问题。

2、分布式架构主要解决银行基础设施架构问题，相比集中式架构，分布式更具扩展性，可以横向按需扩容，在性能和敏捷性上要比银行传统集中式架构更灵活，可提供更低的部署成本。

【问题3】请问分布式架构与集中式架构相比，有哪些优势与不足？

【解答】

观点1：
分布式存储相较于集中式存储的主要优势体现在如下方面：

分布式存储基于通用硬件，非专有硬件，无论是采购成本还是维护成本更低；

分布式存储的横向扩展能力，可以有效实现资源池化的同时，实现性能的线性增长，不会像传统存储的双控或者多控架构，横向扩展能力受限，只能纵向扩展，加磁盘，扩容量，存储控制器成为性能瓶颈，在全闪介质情况下，这种问题更加严重；

分布式存储的磁盘不会被一个RAID组所限定，可以更大化提升资源利用率；

分布式存储的架构特点决定了其更适合云化数据中心演进的需求，其现在主要的问题是软件成熟度方面，现在分布式存储的供应商比较多，需要结合自己的需求进行全面测试，特别要关注实际生产环境大规模验证的落地案例

观点2：
分布式和集中式架构主要区别如下：

集中式架构在系统复杂度、数据一致性、安全措施实施方便性和运维管理复杂度等方面有一定优势。分布式架构在资源使用成本和扩展能力、业务部署的灵活和系统可用性等方面具有明显优势。而且集中式架构的复杂性可以通过加强管理和设计降低复杂度，安全措施则可以通过增加安全系统和手段加强控制，数据一致性则需要通过先进的分布式系统与大规模运维平台来支持，当然前提是需要牺牲一定的可用性，这也是分布式架构面临的一个挑战。

【问题4】银行分布式存储改造，如何解决分布式存储数据一致性问题？性能如何保障？

传统银行IT基础架构对高端存储设备依赖比较严重，如果进行分布式存储改造，那么如何解决分布式存储数据一致性问题？性能如何保障？是否能够满足银行业务数据IO大并发的要求？

【解答】

观点1：
实际上不同的分布式存储产品对数据一致性的要求不一样，当然银行对数据一致性的要求是最高的。SmartX 在这方面做了很多工作保证数据一致性。SmartX 系统本身通过 MetaServer 和 Zookeeper 的机制保证多个副本强一致性，zookeeper 防止脑裂的情况发生；journal 日志机制可保证节点意外掉电后可通过日志回放保证数据一致性；datacheck sum 可以通过校验数据修复因硬盘故障导致的副本不一致的问题，相关的机制还有蛮多的，有机会可以深入了解。另外关于性能部分， SmartX 提供 NVMe SSD 缓存加速，冷热数据分层，充分发掘硬件性能；支持高速网络（10Gb、RDMA 25Gb 或以上），有效降低副本写入延时；支持多个节点并发访问存储。

不过需要说明的是，分布式存储目前还并不是传统高端存储的替代者，是否能满足业务要求还需要通过实际的性能数字才能评估。

观点2：
1、关于数据一致性问题，由于分布式架构受限于CAP理论，即数据一致性，容错性和可用性无法同时兼顾，所以数据一致性是分布式架构中比较难解决的问题。为了保证分布式架构的可用性，在数据一致性问题上，通常会做出一定的牺牲，不会严格实行集中式架构的实时一致性的做法，因为做不到或者是成本太高，也违背了分布式架构设计的初衷。所以在数据一致性上，通常会采用最终一致性的解决方案，即不要求数据实时一致，需要从银行业务上进行分析，识别哪些业务操作是可以放宽的，哪些操作是必须保持一致的，基于“最终一致性”的原则，分析事务的优先级别，在架构设计上进行取舍。在银行系统中，交易类业务的数据完整性和一致性要求最高，而且也需要进行实施保证，而通讯类业务要求上则没有那么高，可以选择不需要支持事务的消息中间件来解决数据一致性问题。这是一种异步的信息交互方式，在网络和系统故障情况下，消息也会被持久化，在系统恢时实现数据最终一致性。当然，这只是一种解决数据一致性的方案，可以根据实际业务来进行数据一致性处理。

2、分布式存储虽然不能完美的解决数据一致性问题，但是却可以提供高性能的存储服务。由于采用分布式架构，性能是可以接近于线性增长的，在节点数量足够多的情况下，其性能甚至可以超过传统的集中存储。因为传统的集中式存储是有控制器+盘柜组成的。在盘柜数量增加的情况下，性能受控制器限制，性能是会存在瓶颈的。而分布式架构的存储不会存在这样的问题。完全可以满足银行业务IO大并发的要求。

【问题5】中小银行面对超融合、分布式架构转型的问题上，有哪些比较好的建议、步骤或是方法？

在银行基础架构转型上，中小银行或城商行IT基础架构相对简单，转型似乎更容易些，大型银行由于IT基础架构复杂，转型似乎更困难。在面对超融合、分布式架构转型的问题上，有哪些比较好的建议、步骤或是方法？

【解答】

观点1：
对于中小银行的传统架构转型，有以下几点思路，希望对你有所帮助

1.计算虚拟化，解耦传统烟囱式的系统架构，充分利用x86平台，提高资源使用率，降低运维复杂度；

2.集中式存储向分布式存储转型，利用分布式架构的弹性伸缩、按需扩展、高性能、高可靠等特点，为上层虚拟化提供数据持久化的能力，摆脱对集中存储的过度依赖，降低架构复杂度，结合第1步就组成了超融合架构；

3.数据中心基础架构云化，通过前2步的准备，数据中心己具备云化的基础条件，首先可以实现IaaS的云化升级改造，实现基础架构的自动化、智能化以及自助化，提供效率；

关于步骤和方法，因为不同的基础架构环境需要区别对待，总体上分为架构层、系统层和应用层，架构层前面己经介绍了，关于系统层，目前行业常用的方法主要还是系统在线迁移实现过度，但也不排队容器化的改造，对于一些系统，容器可能更加合适，关于应用层，与基础架构相对最远，但其实和基础架构又有一定的关系，例如服务器虚拟化、VDI就非常适合超融合架构，容器化应用就比较适合物理机+分布式存储的解决方案。

观点2：
1、中小银行面对超融合、分布式架构转型确实相对灵活一些，但是也需要逐步完成转型，不建议直接替换，在资源使用方案上。中小银行以虚拟化资源使用为主，主要是要求超融合和分布式架构可以灵活的提供所需要的资源，在这方面，超融合相比传统的架构有着明显的优势，所以对于中小银行来说，部署超融合架构不会产生太多的障碍。

2、对于大型银行，IT基础架构相对比较复杂，而且传统架构多采用集中式架构，而且有成熟的运维和管理体系。如果单独部署一套超融合架构，可能会造成管理和应用上的困难。需要单独进行运维和管理，增加了IT基础设施的复杂性。如果进行转型，建议分多步处理，先在非核心系统进行少量节点部署，然后利用分布式架构易横向扩展特性逐步进行扩容和迁移应用系统。

【问题6】银行的业务的数据类型比较丰富，超融合产品如何应对？

银行的业务非常丰富，很多大银行都构建了业务云，影像云，以及对外的机构云，数据类型包括结构化的数据库、虚拟机，以及大量的非结构化数据，如图片，电子档案；业务设计从BI分析、OA系统、银行业务系统、影像平台等上百种；同时，计算和数据规模也非常大，几十个几点到数百个节点。超融合如何应对这类复杂应用的需求？能提供文件和对象服务么？还是，超融合就针对性的行解决部分需求，例如，就做部分OA系统，这样会不会和传统方式一样造成数据孤岛？

【解答】

答：银行业务确实非常丰富，超融合产品在应对上也要有所侧重和选择。
1、在云环境方面，只要是银行业务在云环境下的，超融合产品都可以进行应对。因为银行云环境多为虚拟化系统+集中式存储设备。而超融合为虚拟化系统+分布式存储设备。应对原有银行云环境是没有问题的。

2、在数据方面，超融合产品采用分布式存储架构，支持块存储、文件存储和对象存储，可以组建统一的数据存储平台，针对银行大量的 结构化数据和非结构化数据都可以进行按需存储，按需扩容。而且随着超融合节点数量的增加，其性能还会近线性的提升。

3、从性能上来看，超融合是一套分布式的云计算架构，可以最大化的利用单台服务器性能。但是如果让超融合做大规模计算的业务肯定是不行的，因为超融合不是一种超算架构，需要部署专业的超算节点服务器。

4、从业务方面，银行核心系统集中式架构的大型主机和数据库，超融合是应对不了的，因为架构不一样，如果让超融合去应对，那么银行业务的架构就需要修改，支持分布式部署，通常需要软硬互相配合才能发挥超融合系统的优势，对于这类业务不适合超融合去部署。

5、超融合确实有自己分布式存储架构，如果只用超融合部署一套OA系统，确实会形成一定的数据孤岛，但是超融合是一种横向扩展架构，如果上超融合肯定不会只不是一套系统，这样资料太浪费了，在部署超融合之前肯定要有所规划，哪些业务迁移到超融合平台上，哪些逐步迁移过来，哪些业务使用传统架构，逐渐整合现有业务系统的存储资源。数据孤岛在银行数据中心肯定会存在一些的，因为大量的传统架构都使用集中存储设备，数据孤岛非常多，但是通常的解决方案是从管理上入手。例如使用统一的数据管理平台或云管理平台，整合数据资源，而不是从底层存储层面进行数据整合。

【问题7】银行已经部署了虚拟化平台，还有必要部署超融合平台吗？

企业已经部署了虚拟化平台，还有必要部署超融合平台吗？超融合平台能为企业解决哪些实际的问题？超融合平台部署的成本怎么样？

【解答】

观点1：
首先从概念上，虚拟化平台不等于超融合平台，而超融合架构包含虚拟化平台，也就是说虚拟化平台是超融合架构中的一个功能组件。

通常企业部署的虚拟化平台都是使用集中存储来提供数据持久化，也就是常说的三层架构（ x86 服务器 +FC 交换机 +FC 存储）当然也可以使用以太网交换机，和 IP SAN 或 NAS 存储，计算和存储是分离开的，而超融合架构的核心特点是将计算和存储融合在一个服务器内，通过分布式的特点，为集群提供数据的一致性、可靠性和可用性。

超融合架构不是替代虚拟化的，是用来在一些场景替代集中存储，给用户一个新型的 IT 架构，超融合架构具有弹性伸缩、节点扩容带来的技算和存储线性增长、架构开放不绑定任何硬件品牌、融合架构数据本地化访问带来的高性能、数据多副本机制保障数据的容错能力、相较传统集中存储，有更好的成本优势，具备小规模起步，按需集群规模扩展。

观点2：
超融合平台是使用一套硬件设备，例如X86服务器，统一实现计算、存储、网络和安全等资源的不是方式，是一种软件定义数据中心，和现有的虚拟化平台并不冲突。

超融合平台只需要提供计算资源可以实现和替换虚拟化平台的效果。而且还能提供存储、网络和安全等多种资源，相对传统的虚拟化平台，可以提供更多的资源，提升资源使用效率，可以极大的降低企业的硬件基础设施投资，成本大大的降低。

以一套最小三节点的超融合的部署成本为例，只需要3台X86服务器+超融合软件就可以替代传统数据中心的3 台X86服务器+虚拟化软件+集中存储设备+部分安全设备。

当然在存储节点上，由于节点数量有限，要看具体存储性能，3节点通常只能达到中低端存储的效果，这个要看具体的应用需求。但是从整体成本上看，是肯定可以降低企业基础设施建设成本的。

观点3：
超融合平台,是把计算资源和网络资源存储资源合并在一个物理机柜里面,或多个连续物理机柜里面。超融合平台本身也使用虚拟化平台,只是技术趋向融合所有所需资源在一个物理柜子里面。

超融合会减少网络布线成本,存储购买成本,对于中业务压力的系统足够了。如果部署数据库在超融合里面 需要做好压力测试,看看iops是否能满足你的业务需求。但各个厂商的超融合技术有自己的优势和劣势，需要好好甄别。

中小企业超融合是趋势,大企业已经有完善的计算网络和存储运维部门，避免部门之间相互影响，超融合只是试验性部署，

【问题8】采用超融合架构能够给银行基础架构带来价值？适用的场景有哪些？

【解答】

观点1：
1、采用超融合架构能够给银行基础架构带来极大的敏捷性和灵活性。
由于超融合架构采用分布式的部署方式，可以随时按需进行横向扩展，在系统进行扩容性，可以随时进行部署，而且整个过程相比传统银行的服务器+集中存储设备的方式，可以节省大量的部署时间，满足银行快速的业务增长。

2、可以极大的降低银行基础设施建设成本。
随着银行之间的竞争越来越激烈和来之互联网金融挑战，银行对基础设施采购成本越来越敏感。超融合架构采用低成本的X86服务器，可以按需进行部署，在需要扩容时可以按需进行采购，不用提前购买大量硬件基础设施。而且超融合架构不需要配置独立存储设备，也可以节省不少的投资。另外，在管理方面，超融合有完成的管理系统，可以简化运维管理，降低部署和维护成本。

3、超融合非常适合银行基于微服务的开发和部署场景。
面对互联网金融的兴起，银行对业务系统的敏捷和灵活性要求越来越高。微服务可以将业务解耦，进行模块化处理，可以按需部署，提升业务响应能力。微服务架构对基础设施的敏捷性要求比较高，需要支持虚拟化，支持容器，支持云原生的架构，而超融合非可以满足以上全部的要求，灵活提供微服务所需要的资源。

观点2：
超融合是一个相对通用的架构，一切可以运行在虚拟化平台上的业务系统均可以通过超融合系统进行承载。在以下场景上，超融合的优势更加明显：

新建数据中心；
数据中心资源整合；
分行/分支机构，远程站点等ROBO场景；
边缘计算；
VDI；
Devops场景；
数据库等对存储性能要求较高的场景；
我们在6月5日还有一期针对超融合适用场景的分享，欢迎您积极参与，相信会有更多收获，如有更多技术和产品咨询，可以点击活动页面的“获取更多厂商支持”，期待与您一起探讨。

观点3：
对于非关联系统，且对io负载要求比较高的场景，虚拟化可以在最小的空间里解决这个问题 比如citrix虚拟桌面等

观点4：
超融合技术优势在于横向扩展性的高IO，同时带来运维管理的便利性。高扩展性，高并发高IO的场景比较适合，比如处理远程桌面启动风暴这类的场景

【问题9】超融合怎样对OLTP型业务支持？

我之前认为超融合一体机技术是完全背离时代发展脉络的，现在科技发展都提倡解耦合、松耦合，但是之前思科、oracle等厂商宣扬的超融合一体机都是紧耦合的结构，将计算、传输、存储绑的更死，加重了甲方对厂商的依赖，但是这款smartx的产品却并非仅仅是将计算、传输、存储的聚合，通过分布式技术实现更多主机产品的兼容以及优秀的横向扩展能力，同时大大降低运维成本。

既然我们采用分布式架构解决了紧耦合及厂商绑定的问题，那么smartx一体机如何实现对OLTP型业务的支撑？支撑能力达到什么程度？各金融单位有在非大数据平台下部署一体机的案例吗？他们的性能指标大约是什么样子的？指标包括交易量、并发量、tps、丢包率、IOPS、MBPS等。

【解答】

SmartX 超融合架构的本质是利用分布式存储解决了传统存储在横向扩展，高并发场景下的性能的问题，OLTP类型的业务，比较典型的一些账务系统涉及的关系型数据库，其对存储性能的要求是十分高的，SmartX超融合的分布式存储性能是十分出色的，除了混闪架构，在高性能场景下，支持全闪架构，也可以利用更加高速的硬件介质，如NVME SSD，Optane 持久化内存，Optane SSD，25GB网络，配合软件层面RDMA特性，提供高性能的存储，举例来说，在单 VM， 2 副本的情况下，使用 NVMe SSD + 25G 网卡，在4K随机读场景下，SmartX可以提供超过200K IOPS，在4K随机写的场景下，可以接近100K IOPS，可以满足大部分场景下的性能需求。

SmartX 超融合中的分布式存储主要聚焦在块存储的领域，跟Hadoop类的大数据平台不同，定位在满足虚拟化，数据库等应用对块存储的需求，目前，在很多金融用户都有承载关键业务数据库的落地案例，如基金公司在跟互联网公司对接的压测场景，TOP基金公司清算核心数据库的承载，TOP券商用户综合柜台系统中间件及数据库的承载以及银行网银交易系统DB2数据库的承载等等。

SmartX在OLTP型业务场景下的案例还是十分丰富的，如有兴趣，可以点击活动页面的“获取更多厂商支持”，期待与您一起探讨。

【问题10】超融合解决方案如何实现与银行微服务的兼容和适配？超融合与传统架构之间的成本投入之间的量化比较情况如何？

目前全行推行微服务的架构，我行目前的微服务存在一个服务对应一台虚拟机的情况，如何在保证服务质量和业务连续性要求的前提下通过超融合实现资源的有效利用和高效利用？是否具有这方面成本投入之间的量化比较情况？

【解答】

观点1：
结合虚拟化技术以及超融合产品，能够有效地支撑业务系统微服务的转型。

1.超融合架构出现的一个重要契机就是为了简化结构，更好的提升设备的利用率。通过虚拟化的方式实现计算资源的共享，同时通过分布式技术池化存储资源，消除资源孤岛，充分的利用了x86服务器及其上的计算资源和存储资源。

2.无论是在线的虚拟机迁移，集群HA功能，还是分布式存储的多副本策略，包括机架感知功能，都大大提升了系统的高可用，能够为上层应用提供更好的业务连续性。同时超融合平台可以实现在线拓展，非常适合按需进行投资。

3.超融合产品提供的容灾以及双活场景下的数据保护功能，能够更好的提供业务连续性，满足银行客户的监管要求。

4.随着DevOps以及CICD场景下对于业务快速发布的要求，未来的业务系统也会不断地向容器化的方向发展。超融合产品对接容器平台也是功能上比不可以少的一环，通过提供持久化的存储能够更好的实现容器平台对于有状态类应用的部署。更进一步的说，如果能够直接在超融合平台的管理控制台上进行编排调度，则整个开发、部署、发布、运维全流程的效率和服务质量，都会有更加明显的提升。

超融合与传统架构的成本比较：

1.硬件成本上来说，不再使用专用的硬件厂商的存储交换机以及集中式存储设备，仅需要在购买x86服务器时配备少量SSD磁盘和万兆网卡，设备之间互联的万兆交换机，以及超融合软件即可，硬件成本大幅降低。同时节省了存储设备的机柜空间和电力消耗。

2.运维成本的角度来看，超融合产品可以实现一栈式管理，不再需要登陆不同的控制台进行配置、监控和管理，运维复杂度大幅降低，降低了维护成本，减少了人员投入。

具体的投入差异需要结合规模来进行比较。

观点2：
1、超融合架构非常合适微服务架构的部署。一台超融合节点不仅可以提供虚拟机资源，还可以同时提供存储资源，在部署微服务架构时，可以做到快速部署和按需扩容。单台超融合节点根据配置不同，可以提供几个到十几个虚拟机，还可以同时提供TB级别的存储资源，可以高效的利用单台服务器的资源，避免资源浪费。

2、超融合采用低成本的X86服务器，而且提供统一的超融合管理平台，采购、运维和管理成本都比较低。

3、超融合使用单一服务器架构提供多种不同的资源，在单个U的空间内，可以同时提供计算和存储资源，最大化的提升机房空间利用率，减少成本。

4、超融合存储端采用多副本存储策略，多个节点可以分开部署，组建容灾系统，可以提供业务连续性服务，满足容灾要求。

成本投入：

1、空间节省10U机柜空间。以10个2U节点的超融合系统为例，占用的机房空间为20U。可以节省集中存储的空间，至少可以节省10U物理空间。1个控制器（4U）+2个扩展柜（6U）空间。

2、采购节省1台存储设备。10节点超融合设备+超融合软件成本=10台 超融合设备+虚拟化软件+管理平台成本。

3、运维管理成本下降。由于不需要采购存储，可以免去存储设备功耗、维护成本和管理费用。

【问题11】超融合技术在容灾方面有哪些技术，有使用快照复制技术么？如何解决COW性能不足的问题？

【解答】

观点1：
1、超融合是多副本部署的，可以是二副本、三副本或是多副本。在网络带宽足够的情况下，可以利用超融合多副本策略实现数据在多个数据中心的实时同步复制。

2、如果是两地三中心的架构，通常是A和B在同城，B和C在异地。建议A和B中心部署光纤网络，利用多副本机制实现同城数据实时同步。然后再B和C中心之间由于在异地，建议部署专线，采用异步的数据复制机制，可以使用超融合存储的数据复制功能实现。由于距离较远，带宽难以保证，还是采用异步的数据方式比较好。
3、两个三中心要求网络可达，并且最好实现大二层网络，方便ABC三个数据中心之间超融合虚拟机的容灾迁移，并且客户端要能够同时访问ABC三个数据中心网络。建议采用基于GLSB的负载均衡网络

4、超融合在同步数据复制时候多使用副本或者是纠删码技术，只有在远程异步数据复制是使用快照复制技术。当然，在同步数据复制时候，也可以采用快照复制技术，对快照进行复制，被复制的快照可用于数据备份或者是测试系统、

5、COW只是降低了源数据卷的写性能，因为同时要写2份数据。为了避免这个问题，可以使用ROW快照计算，但是ROW的问题是对读性能影响比较大。至于采用哪种快照方式，可以根据业务进行确定。如果是读取较多的业务类型，那么采用COW快照是完全没有问题的，反之亦然。

6、超融合是可以支持多种快照技术的，但是并非所有的超融合厂商的产品都可以支持，在采购之前要询问清楚，选择合适和超融合厂商产品

观点2：
超融合在异步复制方面一般是基于快照实现数据复制，不同的超融合厂商的快照实现技术有所不同，有的是COW，有的是ROW，不同的快照实现技术会对读写性能有不同程度的影响。

SmartX超融合的快照技术，从存储角度来看，是ROW机制，可以实现秒级快照，ROW 的写性能基本没有损耗，因为只是修改元数据指针，打完快照后，源卷如果要修改，会将元数据指针指向新的数据块，而不会像COW一样，把原来的数据块拷贝出来。
很多人认为ROW在连续读的场景影响较大，因为数据块打散了，不连续了，这主要是传统存储利用HDD磁盘介质的时候会出现这种情况，但在分布式存储的情况下，ROW 不存在这种问题，用户在业务层看到连续存储，实际上是分布在不同的服务器的不同硬盘中，数据越是分散，系统性能越高。而 ROW 把源数据卷中的原始数据打散之后，对性能反而有好处，而且，分布式块存储的场景下，多数会利用SSD进行缓存加速，更好地规避了这种问题。

【问题12】采购超融合产品，如何规避厂商绑定或例旧设备无法使用风险？

超融合技术落地后，在非容灾环境中的运维，相对传统结构是较为简单的，但是我认为这是厂商将大部分的关键技术隐患都提前规避掉了，但是正是这种规避策略也导致其规范性要求越趋严格，这是一个好事，但是这也增加了一个问题，如果购买的是超融合一体机硬件，那么存在厂商绑定风险，和其他家的超融合设备不兼容；如果购买的是软件，个人认为之前的例旧设备可能无法得到有效利用。我想知道这样的担心是否有必要存在？我如果购买产品，应该怎么规避这样的风险？

【解答】

观点1：
1.其实规避兼容性问题，不一定是要一体机，只需要严格按照厂商提供的 HCL （硬件兼容性列表）去准备机器就不用担心这个问题了。这样既可以防止硬件绑定，也无兼容性的担忧。 2.软件与硬件分开采购，担心后续这些硬件是否能重用的问题，不知道是否理解正确。首先我认为选择软件方案的时候是需要考虑到这点的，要挑选一些对硬件兼容性好的超融合厂商，这个比较重要。因为一般这些厂商支持的硬件的品牌和型号都会比较多一些，用户本身可选择也多；另外也避免一些特殊的硬件的方案，有部分超融合厂商会要求使用特殊的硬件，例如 IO 加速卡，特殊的网网络等等，但这些最坏的结果后续导致后面用不上。但例如 CPU 、内存、以太网卡绝大部分硬件都各个超融合厂商通用的，这个就不必太担心。

观点2：
把超融合本身已经缩减成了一个产品，跟以前计算、存储分开的情况比较，确实会是一种厂商绑定。

不过超融合平台上层运行的是虚拟化，虚拟化层是可以分离开的。极端情况下可以把虚拟机从超融合平台上迁移出去。

关于利旧，其实这是一个伪命题。利旧带来的管理成本往往高于利旧本身。

观点3：
1、超融合各个厂家的架构都是一样的，如果存在不兼容的情况，也只是虚拟化层软件的不兼容。例如有的超融合厂商支持VMWARE，有的支持KVM，但是如果你确定好虚拟化层的技术路线，即使选择不同的超融合厂商，但是选择的虚拟化层软件都是一样的，使用统一的云管理平台进行管理，不会有太大的问题。不会出现被某一个特定的超融合厂商绑定的问题。

2、设备利旧问题，目前大部分超融合软件厂商对X86设备支持还是比较友好的，特别是旧的设备支持程度要比新出的硬件设备支持要好，不需要过多的担心利旧问题。

3、超融合一体机各个不同的超融合厂商之间肯定是无法互相兼容的，但是也不需要兼容，我们只需要使用提供的计算和存储服务就好，例如可以提供标准的S3、块存储接口，KVM计算资源，能够统一使用就可以避免绑定的风险，而不必过多的去纠结底层一体机设备之间的兼容性问题。

【问题13】smartx适用能兼容哪些场景？smartx和其他大厂家vmware比较又有哪些优劣？

smartx适用能兼容哪些场景？smartx和其他大厂家vmware比较又有哪些优劣？
zbs分布式存储架构和ceph等相比又有哪些优缺点？

【解答】

超融合是一个相对通用的架构，一切可以运行在虚拟化平台上的业务系统均可以通过超融合系统进行承载。在以下场景上，Smart超融合的优势十分明显，而且有大量金融用户生产环境落地案例： 1. 新建数据中心； 2. 数据中心资源整合； 3. 分行/分支机构，远程站点等ROBO场景； 4. 边缘计算； 5. VDI； 6. Devops场景； 7. 数据库等对存储性能要求较高的场景；此外，我们在6月5日还有一期针对超融合适用场景的分享，欢迎您积极参与，相信会有更多收获。

相较于国际大厂，Gartner在2019年的中国超融合市场竞争分析报告中指出，SmartX聚焦超融合领域，产品自主研发，并不断开拓对金融，医疗等IT重度依赖的行业，并基于出色的稳定性和本地化服务支持，获取了用户的认可以及不断扩容。

ZBS相较CEPH类架构的分布式存储，最大的优势是通过元数据服务实现数据副本的精确放置，可以形成更加灵活的副本分配策略，并按照资源进行调整副本分配位置，而不是简单打散，而且，ZBS对计算资源的消耗是十分低的，仅需要3 CORES，16GB内存，更利于实现超融合部署，并且，可以实现计算与存储IO路径的深度融合，让VM始终有个副本在本地，那这样在读的场景下就可以发挥更高的性能。

如有更多技术和产品咨询，可以点击活动页面的“获取更多厂商支持”，期待与您一起探讨。

【问题14】请问SmartX与Nutanix对比的优势与劣势？

【解答】

Gartner在2019年的中国超融合市场竞争格局分析报告中将Nutanix和SmartX归为一类，都是专注在超融合领域的纯软件自研厂商，这两家的定位以及产品实现都是十分相似的，在产品和服务方面的主要对比如下：
一、Nutanix：通过构建分布式文件系统NDFS，实现X86服务器本地硬盘（SSD+HDD）资源池化，利用副本技术进行数据保护；通过开源NOSQL分布式数据库Cassandra进行管理，元数据节点中记录了集群所有节点本地磁盘资源的信息，所以，超融合集群可以在分配副本的时候，可以选择数据副本的存放位置，从而实现数据保存的本地化以及IO访问本地化，此外，SSD作为缓存，可以进行IO读写加速；

优势：

因分布式块存储中存在元数据节点，使得超融合集群中的资源调配可以做到更加细粒度、更加精确的控制。这种控制的优势一方面体现在性能方面，另一方面体现在集群的灵活性，如副本分配策略的调整，以及节点间数据平衡的发生条件控制等；

架构灵活，开放性好，在超融合系统中分布式块存储组件与计算虚拟化组件不是紧耦合的关系，分布式存储组件可以支持多种虚拟化平台。

支持双活及容灾的高级数据保护特性；

支持超融合和分离式部署；

不足之处：

1）国内服务无研发支持，原厂支持力度比较弱，出现产品问题，解决效率比较低；

2）前期通过一体机方式交付，对国产服务器的硬件兼容性较差，一体机硬件报废，软件同样失效；这两年，开始推纯软件模式，但大部分是订阅模式，投资保护差。

3）元数据管理组件为开源NOSQL分布式数据库Cassandra，该组件相对复杂，出现问题维护难度较高；

二、SmartX：国产品牌，SmartX分布式存储技术实现与Nutanix类似，属于一个流派。不同的是，SmartX没有基于EXT4进行磁盘管理，而是自主研发了一套分布式文件系统LSM，直接基于裸盘管理，实现X86服务器本地硬盘（SSD+HDD）资源池化，利用副本技术进行数据保护；通过自主研发的元数据组件进行管理，元数据记录了集群所有节点本地磁盘资源的信息，所以，超融合集群可以在分配副本的时候，可以选择数据副本的存放位置，从而实现数据保存的本地化以及IO访问本地化，此外，SSD作为缓存，可以进行IO读写加速；

架构优势：

因分布式块存储中存在元数据节点，使得超融合集群中的资源调配可以做到更加细粒度、更加精确的控制。这种控制的优势一方面体现在性能方面，另一方面体现在集群的灵活性，如副本分配策略的调整，以及节点间数据平衡的发生条件控制等；

虚拟化平台开放性好，在超融合系统中分布式块存储组件与计算虚拟化组件不是紧耦合的关系，分布式存储组件可以支持VMware，KVM以及XenServer多种虚拟化平台。

硬件平台兼容性好，支持华为，浪潮，HPE，联想，H3C，dell，超微等多种X86服务器品牌，超过20款硬件型号，并且均有落地案例。

性能高，支持Oracle数据库等关键应用：利用IO本地化以及SSD缓存加速，有效地满足Oracle数据库等关键应用场景下对高IOPS和低延迟的需求。

5）研发在北上深等一线城市，针对金融客户，形成了专属的服务团队，问题解决效率更高，可以提供更及时的服务。

不足之处：暂时不支持Hyper-V虚拟化平台。

【问题15】SmartX是否有自己的Hypervisor？SmartX的分布式存储是如何为上层Hypervisor提供服务的？SmartX超融合是否可以部署大数据平台或者数据库服务？

【解答】

SmartX提供基于KVM进行产品化的Hypervisor，产品名称SMTX OS虚拟机平台，可以提供类似vSphere vMotion，HA的功能，并可以在WEB界面批量部署虚拟机，大大提升资源发布效率。

SmartX的分布式存储通过虚拟卷的方式直接为虚拟机分配存储资源，实际上，数据通路是通过QEMU+iSCSI的进行实现的，但虚拟机不需要通过iSCSI LUN的方式进行挂载虚拟卷，虚拟机的虚拟卷添加可以直接在WEB控制台上图形化操作完成。

超融合产品本身可以应用于企业绝大多数的应用场景，特别是适合采用虚拟化平台的场景。但是在某些特定场景上需要从性价比的角度进行考量。比方说SmartX平台本身是可以支持部署大数据平台，但用户需要考虑大数据平台本身已使用了分布式文件系统来提供高可用，再加上超融合平台采用多副本冗余机制，叠加的效果会造成存储资源的过多消耗。

同时大数据平台一般会采用大量价格低廉的HDD做数据存放，采用超融合的设备性价比不高。

在数据库服务方面SmartX超融合是完全可以支持，目前已有不少金融用户在生产环境将Oracle、DB2等数据库部署在SmartX超融合平台上，在SmartX可以提供高性能存储的同时，可以充分提升服务器资源的利用率。