一、前言

由于当前硬件和软件技术的迅猛发展，对于各个省级农信或者农商行至少 7 、 8 年前建设的核心系统来说，不论从硬件或者软件方面来说都已经相对于落后，随着消费模式的不断改变，当前业务系统已经无法满足正常的业务需求。随着科技与社会经济活动的不断改变，为了满足日益增长的业务需求，核心系统的生命周期已经缩短至 8 年甚至更少。在符合规模经济效益下，是选择改造原有核心系统还是新建核心系统，是值得商榷的。同时，为达到银保监会对中小银行机构业务连续性管理的监管要求，核心系统的容灾备份建设也需要重点考虑。

当前核心系统主流架构仍是同城两地三中心的架构（业内有的银行甚至是 4 个数据中心），当灾难发生时，如何快速恢复业务，架构设计之初的 RTO 和 RPO 的值，是决定使用何种技术的关键指标。是基于数据库层面的数据复制，还是基于存储层面的数据复制？由于每个农信或者农商行自身的业务特点不一样，在满足当前业务需求下，同时保障未来几年业务的增长需求，在核心业务设计时的 TPS 指标，也为如何选择服务器和存储硬件给出了参考。对于核心系统最重要的就是数据，保障数据有效的就是存储设备。如何选择存储、选择一个什么样性能的存储，存储应该达到一个什么级别可靠性的标准？新核心存储选型是采用集中式技术路线还是分布式技术路线？新核心建设需同步实现双活数据中心，如何进行核心存储选型和方案设计？新核心建设如何对存储容量进行评估？为解答以上疑问， TWT 社区平台特意邀请了省农信等行业专家、戴尔科技技术专家一起线上交流探讨，进行疑难问题汇总探讨。

本场在线讨论更多交流问题回顾： https://www.talkwithtrend.com/Activity/?id=1565

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

【问题 1 】对于银行新数据中心建设核心系统存储架构选择上是选择传统架构下集中式存储还是分布式存储架构？

1 ．集中式存储最大的优势在于架构简单、维护相对容易，已有的运维经验能够延续，同时传统存储厂商支持能力相对较强，对于中小型银行来说，互联网业务的增长规模比较大行有一定的局限性。而分布式存储在非一线城市中厂商技术支持方面是否还存在短板？

2. 对稳定性方面考量，集中式存储使用较早，而分布式存储出现时间才刚刚几年，软件的可靠性方面是否还不适宜用做银行核心系统？分布式存储软件授权和后期支持服务费用等价格方面考虑，整体价格优势是否比集中式存储已不够明显？

综上，对银行核心系统存储的架构选择上还有什么指导思路？

观点 1 ：

决定了核心存储架构也就相当于决定了核心数据库架构，首先传统架构肯定能够满足您当下的需求，那么这个问题实际上是在问分布式架构能不能满足您的需求，答案是肯定能，几家比较知名的民营银行已经吃了螃蟹，上了 OLTP 分布式数据库，鲜活的案例。但是成本也是很高的，这里说的成本不是说价格成本，而是指维护成本、人力成本和技术成本，有人有技术，或者买人买技术，我相信核心上分布式架构都不是问题，就互联网公司大规模使用分布式来看，技术成熟度已然很高，而且性能优势和扩展性优势也非常突出，但价格成本相对传统分布式而言不会低，甚至只会高。所以就我个人的意见来说，如果是建设新核心系统，与老核心形成双核体系，那新核心采用分布式架构转型是势在必行的。如果是老核心改造升级，那可能采用传统的集中式模式会更平稳些。

观点 2 ：

1 、存储扩容能力不是核心系统面临的主要问题。银行系统按照业务特点可以分为六类，分别是交易类、报表分析类、影像类、虚拟化平台类、办公类和归档备份类。通常核心系统指交易类系统，生成的主要是交易流水类关系型数据，相比影像类系统，交易类系统的数据增量小，集中存储的扩容能力完全可以满足扩容需求。另外核心系统投产前应是强规划的，提前做好了容量评估，同时也制定好了数据归档和清理策略，很少出现容量不足需要物理扩容的情况。

2 、集中存储的成本已不再让人望而生畏。现在集中式存储以闪存为主，容量大、体积小，价格越来越便宜，成本较全闪配置的分布式存储，差距已明显缩小。再考虑到稳定性和容灾能力，集中存储远胜于分布式存储。从架构稳定性、容灾能力和成本三方面综合考虑，集中式存储更适合银行核心系统。

3 、尝试新存储架构应选择非核心系统。用核心系统尝试新存储架构，风险高，收益小，得不偿失。可以用外围系统或是更适合的业务场景去尝试而不是用核心系统。所以，在集中式应用架构下，集中式存储依然是核心系统的首选。

当然，核心系统不用分布式存储，并不表示其他系统或平台也不能用分布式存储。在容量需求大、稳定性和容灾能力要求不苛刻的场景，低配的分布式存储优势十分明显，比如影像类或虚拟化平台类场景。新机房存储规划时需要考虑。

观点 3 ：

1. 核心系统存储架构选择上是选择传统架构下集中式存储还是分布式存储架构？这个问题的答案实际上是由所选择的核心系统架构本身确定的。传统核心系统大多采用的还是传统的集中式架构的存储，分布式核心系统估计多采用分布式数据库和分布式存储架构。一般来讲核心系统研发公司会给你一个比较明确的答案。
2. 目前采用全闪的集中式存储的性能和扩展性对于一般的银行的核心系统来说一般都是没有问题的，核心系统的瓶颈一般很难体现在存储端（当然是要传统机械盘的除外），主要还是考虑核心系统数据库数性能的优化，和跑批性能的优化。对于中小银行而言，更无需太多担忧。
3. 目前也有很多分布式存储应用于金融行业，只是存储本身架构采用分布式架构，多副本技术，但是对于我们来讲是感受不到的，上层跑还是我们的传统系统，也不需要很多的维护。另外还有一些大数据、大容量备份存储也采购分布式存储。
4. 为应对互联网金融业务快速发展，我行计划以传统业务体系为基础，建设新的互联网金融业务核心系统，形成传统集中式和分布式架构并存的 “ 双核心 ”IT 架构。原来的核心系统是作为稳态的系统，仍然采用传统数据库 + 高可用的全闪存储；互联网金融作为敏态的系统，计划采用头部金融科技公司的互联网金融整体解决方案，那么这个架构就不单单体现在存储是分布式的了，而是整个体系的分布式。

【问题 2 】核心存储选型重点考虑点有哪些？

市面上有众多云管平台的品牌和厂商，作为技术能力水平较低，科技基础较为薄弱，主要依靠厂商的实施和开发的企业来说，该如何进行云管平台的选型，都说便宜没好货，好货不便宜，为了兼顾质量、功能和成本，都需要考虑哪方面或者通过哪些方面来判断哪个厂商的云管产品适用于本企业呢？

观点 1 ：

银行核心系统存储选型的关键点在于存储需要有以下几个特点： “ 以数据为中心 ” ， “ 智能的存储技术 ” ， “ 适应能力出众 ” 。

以数据为中心是指存储设备重点需要考虑存储的稳定性和数据服务能力，核心存储动一发而牵全身，存储架构的稳定性，部件的冗余性和可靠性是核心存储选型最重要的；存储设备的可维护性，在升级微码，更换存储部件时不可以影响到上层业务；同时要求存储需要再业界有广泛的应用案例，经得起同行业的考验。最后，需要有稳定的服务团队，产品和方案落地靠的是人，银行的核心存储方案落地，需要有资深的行业架构师和服务人员。同时核心存储也需要考虑到存储的性能，对业务未来不可预测性能需求，需要可以应对，如使用更新的存储协议和存储介质，对于多云平台的支持，如 Openstack 、 VMware 、容器等，人工智能。
智能的存储技术是指通过机器学习等先进的存储算法，实现存储服务的自我优化，并且可以智能的监控存储设备的运行状态，预测未来的存储服务需求
适应能力出众是指存储设备具有灵活的体系架构，在不中断存储服务的情况下实现核心、边缘和云的现代化部署，并且可以按需在线进行扩展，同时扩展存储容量和存储性能，扩展之后实现存储资源的在线自动平衡。

观点 2 ：

以上提的 4 个方面涉及到选型的主要侧重点，主要是稳定性、业务发展、共享文件以及灾备建设等。

除此之外个人建议还要考虑如下几点：

1 、性能：性能的还是关系着存储使用的好坏，主要体现在 IOPS 、 MBPS 以及延时等几个指标上；

2 、价格成本：当然价格也是一个重要因素，特别是选配的是全闪还是部分机械部分闪存的架构都关系着价格的高低。

【问题 3 】银行核心系统存储选择分布式存储应从哪些方面进行考虑？

目前我社正在考虑建设新一代双活数据中心，在规划核心系统使用的存储时，是使用集中存储还是使用分布式存储是我们考虑的难点。请问如果考虑使用分布式存储，在分布式存储的选型上应重点考虑哪些方面，在关键性能指标、存储的稳定性、健壮性、并发性、数据复制、双活等方面主要侧重考虑哪些问题。

观点 1 ：

在规划核心系统使用存储时，两种架构的存储的选择考虑起来的确比较困难，但对于省农信来说，业务量也不小，日均也在千万比左右，使用分布式存储来承载的如此大数据量的金融机构而言，是需要很大的勇气以及承担未知的风险的。全国农信而言，也很少见到用分布式存储来跑核心的，毕竟金融业还是以稳定为主的，步子太大容易摔着。
但如若考虑分布式存储，在选型上应着重考虑如下几点：
1 、稳定性；
2 、性能（ IOPS 、 MBPS 以及延时）；
3 、数据一致性；
4 、高可用性；
5 、灾备以及双活机制等。

观点 2 ：

除了上面专家提到的一些点，我再补充一个：分布式存储对上层应用的普适性，也就是分布式平台需要支持多种数据库、多种虚拟化平台或者容器平台。

【问题 4 】银行在双活数据中心建设时，如何考虑跨数据中心不同服务器之间的文件共享需求？

我社在规划双活数据中心建设时，对于同一个业务系统其应用服务器分别部署在两个数据中心，想实现当一个数据中心应用服务器故障时，不影响应用系统正常使用。但是在实际落地时，两个数据中心应用服务器有文件共享需求，即当在 a 中心某台服务器存一个文件时，也需要在 b 中心的服务器上能够读取。这种需求在单中心时可以考虑使用 NAS 存储、 GPFS 软件，但是在双数据中心时，交流 NAS 厂家发现， NAS 存储不支持双边写操作，即数据写入时只能指定其中一个中心的存储为主，另一个中心的 nas 存储为备，当在 b 中心数据写入时，首先写到 a 再写到 b ，数据传输了 2 遍，不满足我社需求。目前我们没有找到好的解决办法，请各位帮忙看一下各家是怎么实现的。

观点 1 ：

在双活数据中心的建设中， SAN 存储和数据库已经可以很好的实现双活，对于 NAS 文件共享，由于与文件的读写访问具有独占性，目前业界主流的做法是双数据中心各配置一套 NAS 存储，并且将这两套 NAS 存储配置为存储复制的方式，两个站点的业务同时访问主数据中心的 NAS 存储，当主站点的 NAS 存储出现故障时，可以自动将文件访问切换到另一个数据中心的 NAS 存储。随着现在对象存储使用的越来越普及，对象存储具有可以跨站点数据强一致性的多活访问方式。如果是一些不频繁修改的文件，可以考虑使用对象存储来存放。

观点 2：

主要通过 GPFS 的方式来实现文件共享需求。主要是基于如下考虑： GPFS 相比 NAS 的方式稳定可靠。

【问题 5 】银行核心系统建设，实时交易类应用的存储架构设计时需要重点考虑哪些关注点？

银行核心系统建设，实时交易类应用的存储架构设计时需要重点考虑哪些关注点？

观点 1 ：

实时交易列应用的存储架构设计，最重要的就是存储的稳定性和性能，因为实施交易类应用多为 7*24 小时的应用系统，如果存储设备一旦出现问题，就会影响业务，所以在存储架构设计中，最主要的就是存储的稳定可靠，所有的存储设备部件都需要冗余和在线进行存储的维护、升级。并且存储需要提供稳定一致的高性能，不能因为存储的性能问题影响业务。最后的存储需要良好的可扩展性，随着业务的发展，存储设备可以做到在线的横向扩展，同时扩展存储性能和存储容量。

观点 2 ：

个人建议应考虑稳定、性能、一致性及高可靠性等要求。对于银行来说，数据是业务立足的根本，数据的稳定和一致性是确保业务持续的基础，但对于核心来说，业务量和交易量也是十分巨大，因此性能也是制约业务发展的因素，一旦满足不了就会发生堵塞，导致业务无法进行，后果也是十分严重的。

观点 3 ：

IDC 分析报告中指出，存储已经进入第五代存储时代。其核心特点是：

1 ）敏捷高速 （ Nvme 、 SCM ）

2 ）有效容量（无损的重删和压缩率保障）

3 ）无缝接云（和私有云、混合云的无缝结合）

4 ）数据护航（端到端的数据保护及业务连续性）

5 ） AI 赋能（智能化分层、智能化管理及部署）

对于银行核心系统在考虑存储架构时一定要围绕这些点来考虑。

【问题 6 】新核心系统建设中响应码规范的方法与思路是什么？有什么好的经验？

观点 1 ：

规则：

统一错误码： -1

请求成功： 200

字段请求相关， 24001 起。如：字段验证错误码： 24001

远程服务，等其他公共错误码： 30001 起

公共错误码 - 系统设置 - 用户授权管理：用户、授权： 40001 起

公共错误码 - 系统设置 - 基础服务：数据字段、地级等： 50001 起

公共错误码 - 系统设置 - 门店管理： 52001

预留公共部分： 6 ， 7 ， 8 ， 9

观点 2 ：

各行出于自身业务的需要对响应码有自身的规范方法，针对自身的业务类型建立适合自身的规范即可。

【问题 7 】分布式存储 or 集中存储？

整个行业趋势里新核心是否会倾向于才用分布式架构，这种架构下分布式存储是否更适用，是否还会使用集中存储

观点 1 ：

分布式存储 or 集中式存储之间的界限现在也没那么泾渭分明。现在企业级高端存储内部架构都是支持在线横向、纵向扩展的，因此从某种意义上来说也是分布式。企业级高端存储既具有分布式特性又具有集中管理的优势，可以说是分布式集中存储。

观点 2 ：

对于金融行业来说，数据的安全可靠以及一致性是万分重要的，对于分布式和集中式存储来说各有各的特点，也没达到有你没我的地步，完全可以实现优势互补。对于两种架构主要看场景来进行实现，分布式在短期内也无法完全取代集中式存储，有些场景如高性能低延时集中式存储还是更为合适，因此建议结合场景来进行选择。

【问题 8 】银行核心系统建设，核心存储选择闪存存储空间如何合理规划？

银行核心系统建设，核心存储选择闪存存储空间如何合理规划？是使用全闪存存储还是配置部分闪存盘？

观点 1 ：

存储空间规划是重要的，但是也不是最重要的。随着银行核心系统的发展，目前银行的核心系统存储数据量规划的方法论已经逐渐成熟，我们建议在做存储规划的时候，需要参考《存储服务目录》的方法论，从整体的技术视图、架构设计、生产存储服务、数据备份服务、数据灾备服务、业务服务级别、 ITIL 等方面做全面的评估规划，对于核心数据库类型的应用可以参考 IDC 的评估模型，存储的数据量每年增长 20% 。在存储规划时，需要考虑到未来 3-5 年的数据增量。并且现在存储设备本身通过重删压缩技术可以实现存储有效容量的提升。在硬盘的选择上，我建议可以考虑全闪存存储。

观点 2 ：

核心系统采用全闪是毋庸置疑的趋势，这个趋势从 2016 年就开始了。全闪存储在空间规划时一定要考虑性能无损的数据缩减（重删及压缩）。 DellEMC 最新高端全闪存 PowerMax 提供 3.5:1 的数据缩减保障。在某大型商业银行大量的实际使用结果来看数据缩减率也确实到了 4:1 。

观点 3 ：

如若讲究性能以及预算可控的话还是选择全闪存存储，毕竟现在全闪价格也没贵多少，性能相比 HDD 物理盘速度还是有比较大提升的，毕竟是拿来跑核心的，也是讲究性能的。

【问题 9 】是否采用统一存储一并解决 NAS 部分的需求？

新核心系统文件共享部分的需求是采用核心统一存储解决方案，即同时提供 san+nas 的一体化存储解决方案，还是采用独立 nas 存储解决？

观点 1 ：

1. 如果新核心系统的共享文件系统不是很大，性能和空间要求不是很高，可以采用 san+nas 的一体化存储解决方案，这样具有高端存储的高可用性保障，一体化方案要考虑 NAS 对存储本身资源的消耗问题， 不建议作为主要的 NAS 解决方案。 核心系统的共享文件系统要考虑跑批等特殊情况对于文件的锁问题，有可能会带来影响。
2. 如果行内有其他系统也有许多 NAS 需求，可考虑独立的、专用 NAS 存储，特别是大量的图片、影像和非结构化数据存储。
3. 我行核心系统的共享文件系统在测试环境采用了 san+nas 一体化存储解决方案进行了测试，但后面改为了 GPFS 。我行的独立 NAS 存储主要用于 其他系统的非结构化数据存储和共享文件系统需求。

观点 2 ：

从工作原理上讲，通过 SAN 存储来满足部分 NAS 存储的需求是完全可行的。而且目前典型的 SAN 存储厂家一般也都有类似的解决方案支持。这里边我认为最关键的问题在于文件存储的需求是怎么样的。原因就在于性价比的问题。传统 SAN 存储由于考虑到了高性能需求，高扩展需求，高可靠需求，容灾需求等。一般单位容量的价格相对较高。而很多客户的 NAS 存储主要就是用来存储临时文件、图片文档以及图像文档等数据价值相对较低的数据。如果这部分数据容量占比不大的情况下，考虑到可以减少设备采购数量，降低采购价格，可以采取整合方式。但如果这部分数据量较大，最好还是独立出去。这样对采购成本，以及未来的扩容成本都是有好处的。

观点 3 ：

需要根据 NAS 文件数据的访问场景分别进行讨论。对于强关联的业务系统，可以考虑使用同一存储，将业务系统的结构化数据和非结构化数据都存放在一台存储设备中，但是对于 NAS 容量要求，性能要求很高的访问场景，需要独立的分布式 NAS 存储。

【问题 10 】求经验分享 : 目前有没有哪家农信核心使用或者探索使用分布式存储？稳定性如何？

一直以来地方金融机构都会使用高性能集中存储去承载核心数据和业务，没有多少跳出来吃螃蟹的，毕竟大家都愿意花钱保平安。尝试使用分布式存储的大多用在非关键业务区域，如何打消人对分布式存储性能以及稳定性的疑虑？如何平衡存储厂商利润空间？如何分做到布式存储技术的沉降等问题才是分布式存储走进千家万户的关键。

观点 1 ：

至少我们没有，目前虽然我们有建设网络金融核心，采用分布式框架，但最核心的电子账户等依旧采用传统架构来进行实施。也不敢贸然将传统的 400 核心改造成真正的分布式存储技术来实现，毕竟金融行业还是讲究稳定。

观点 2 ：

据我所知，目前还没有，对于敏态 IT 的应用场景，可以尝试使用分布式存储，但是对于核心存储这种稳态 IT 的应用场景，我们推荐还是使用集中式存储。

【问题 11 】 新核心如基于分布式技术路线，存储的选型对于稳定性是如何考虑的？

观点 1 ：

核心存储动一发而牵全身，存储架构的稳定性，部件的冗余性和可靠性是核心存储选型最重要的；存储设备的可维护性，在升级微码，更换存储部件时不可以影响到上层业务；同时要求存储需要再业界有广泛的应用案例，经得起同行业的考验。最后，需要有稳定的服务团队，产品和方案落地靠的是人，银行的核心存储方案落地，需要有资深的行业架构师和服务人员，并且需要保证这些人员的稳定。

观点 2 ：

1 、低端存储

一般只有一个控制器，基本没有 cache 或者有很少的 cache ，所以整体响应速度慢，而且基本没有冗余，可靠性差，一般适用于可靠性要求不高的应用，或者用来做备份。

2 、中端存储

一般采用双控，有较多的 cache 或链路，而且开始注意冗余，这个区间的存储，控制器是核心部分，如果有 1 个控制器坏掉，带来的性能降低会超过 50% ，因为损坏一个控制器后写 cache 会自动关闭，性能受到极大影响。

3 、高端存储

一般采用多控，并采用以 cache 为核心的体系结构。多控的结构中，损坏其中某个控制器对整体性能影响比较小。

一般情况下，中端存储是性价比较高的可选产品，对于可靠性及响应要求极高的应用，会采用高端存储，比如银行、电信、移动等。

【问题 12 】 IBM AS400 核心主机架构下 现阶段是否选择外接存储更优？

AS400 架构，选择内置存储磁盘和外置存储磁盘，两种模式下 针对当前存储性能， hba 卡性能 等各项设备配备来衡量 哪种模式下更优？或者还有什么衡量参数来选择？

观点 1 ：

基于 IBM AS400 核心主机架构的存储选型，我们认为选着外接存储的解决方案会更优，因为采用外接存储方案，使存储与计算设备从紧耦合变为松耦合，便于后期的存储扩展，并且可以使用的存储本身的软件功能实现数据服务，如数据快照、克隆，数据复制等等

观点 2 ：

外接存储更优，因为内置存储的空间有限，特别是交易量比较大的农信机构来说，需要保存的数据也比较大，内置的存储有时无法满足现有生产需要，因此通过外接存储来满足数据，同时外接存储相比内置存储而言，性能也不相上下。

【问题 13 】在全闪存后面，是否需要后挂对象存储或者云存储？

用于实现数据同步复制 , 生命周期管理 , 容灾等的各种需求。

观点 1 ：

不需要在全闪后面挂对象存储或云存储，目前的银行存储架构设计，往往会提到存储服务的分层管理，包括内部分层和外部分层，内部分层是指根据业务系统工作负载的存储服务要求，如 IOPS ，带宽，延时等性能等指标，为不同的业务系统提供不同性能存储存储服务，如全闪存储，混合闪存存储，机械盘存储等等，同时也会根据业务系统的 RPO 和 RTO 要求分配不同级别的存储，外部分层是指根据数据的生命周期管理，数据的价值是随着数据存放的时间逐渐递减的，那么对于存储的存储，也需要根据数据的价值来选着对应的存储设备，如在线实时存储的数据，需要配置高端的全闪存存储，对于离线数据和归档数据，考虑使用每 TB 性价比更高的存储来存放。银行核心系统的全闪存存储主要用于在线的结构化数据服务，不需要后挂对象存储或云存储，在数据备份部分，可以考虑使用对象存储或云存储代替原有的物理带库。如使用在线备份存储和离线备份存储相结合等方式实现。

观点 2 ：

不需要后挂存储，全闪存储就能实现同步复制、生命周期管理等功能。

【问题 14 】 新核心架构存储如选择分布式技术路线，存储复制采用何种技术？

观点 1 ：

根据《等保 2.0 》和《中国银保监会办公厅开展中小银行机构业务连续性相关风险整治工作的通知》，银行的核心系统需要做到 “ 本地数据备份与恢复 + 异地数据实时备份 + 本地业务高可用 + 异地业务高可用 ” 。那么存储设备首先要满足本地高可用架构，然后再满足 “ 两地三中心的 ” 的数据复制要求，建议可以通过存储底层复制 + 数据库复制相结合的方式，实现数据的复制。但是现有的分布式存储作为核心系统存储的案例不多。在选择技术路线时需要谨慎考虑。

观点 2 ：

核心系统采用分布式的几乎没有，但好多行在做新一代的时候会考虑互联网 + 类的核心系统。对于这些互联网 + 类核心系统，其中有很多对象存储的需求。这些系统是可以考虑分布式，而且是多站点、多活的分布式系统。这时候就不是采用简单的复制技术了，而是采用多站点多活的强一致性技术。

观点 3 ：

目前的多家农信而言，核心存储选择分布式的很少，传统的 400 架构大都是集中式存储。最近几年建设
的网络金融核心而言，全套架构里面最核心的核心还是基于传统架构（ db2+ 集中存储），其他的采用分布式技术架构来实现，基于 mysql 的 binlog 同步复制机构来实现。

【问题 15 】高端集中式机械硬盘需求是否会消失？

随着全闪存储的不断成熟，我判断未来生产环境中，机械硬盘的集中存储会需求会越来越低，块存储中，集中式全闪存和分布式存储，以及对象存储将会是主要存储模式。专家看法如何 ?

观点 1 ：

未来后端存储依然是混合存储 闪存 + 机器硬盘 （近 10 年趋势），根据算法把热数据缓存到闪存盘，不常用数据放到机器盘。分布式存储，只是软件定义存储，最后落地保存数据的还是盘，盘依然在服务器上，也是闪存在前，机器盘在后面。成本决定一切，如果闪存同每 G 价格和机器盘等价后，会有闪存替代机器盘的趋势。

观点 2 ：

传统机械硬盘的需求一定还是会存在，适用的场景将会在一些数据备份和数据归档的场景，可能会用于对象存储和虚拟带库这类型的存储。随着银行业务系统的发展，对核心系统存储的性能要求会越来越高，传统的机械式硬盘的短板就很明显了， IOPS 低，随机读写延时较高，磁盘故障率高，传统机械硬盘已经逐渐成为核心系统存储的瓶颈，所以随着高端集中存储的发展，特别是第五代存储的推广，未来的高端核心存储一定是会使用新的存储协议 -NVMe ，新的存储介质 -NVMe 协议的 SSD 和 SCM 。

【问题 16 】当前全闪存存储在农商行农信社核心系统建设中的应用情况？

观点 1 ：

目前闪存的价格也回落不少，相比于 HDD 而言价格也没贵很多，但性能相比 HDD 而言速率还是有比较大的提升，因此目前核心的存储在选择上还是倾向于选择全闪存存储。

观点 2 ：

根据目前 IDC 的报告，全球接近 40% 的客户，已经转向到全闪存储了，目前在国内的农商行农信社核中也已经有很多选择使用全闪存存储作为核心存储使用了，未来一定是全闪存存储的时代。

【问题 17 】核心存储国产化选型？

在当前贸易战和信息系统国产化的大背景大趋势下，农商行农信社核心系统建设存储的选型有哪些可参考的代表性品牌和产品

观点 1 ：

我们国家一直倡导的是开放、合作。对于国内金融 IT 系统最主要的是安全与可控。我认为安全可控最主要指的是体系架构上的安全可控，而不是狭义的指单台服务器、单台存储、单个软件的国产化。好的解决方案、合适的产品，金融行业就可以直接拿来使用。 IT 部门的重点也是要围绕如何为业务赋能、如何为最终用户服务，而不是去研究非常底层的技术堆栈，做系统集成与验证工作。

观点 2 ：

市面上主要的存储 IBM 、 HP 3par 、 EMC 以及国产的华为（朵拉朵等）都是可选择的品牌，对于国产化趋势近些年一直在进行，但对于金融行业来说也无法一刀切，推动的程度还是要是看国家意志。

【问题 18 】农商行 / 农信社核心系统对存储性能指标的要求有哪些？

农商行 / 农信社核心系统对存储性能指标的要求有哪些？例如响应时间和 iops 要求

观点 1 ：

存储的性能指标业界比较明确： IOPS 、带宽 MBPS 以及延时。在做 POC 时针对这些性能指标都会有相应的场景来进行测试和确定。

观点 2 ：

性能指标主要有： IOPS 、带宽、延时。一般基于数据库类型的工作负载，需要考虑到存储在 OLTP IO 模型下的这些性能指标情况。

【问题 19 】目前核心系统容灾方案中，数据全双活的案例多吗？一般是用哪种实现方案？

目前核心系统容灾方案中，数据全双活的案例多吗？一般是用哪种实现方案？

观点 1 ：

核心系统真正全双活的案例有，如：苏南某城商行等，但都是资产规模比较小，两个中心位置没有那么远的银行。而且这些真正端到端双活的客户，一般也都是采用数据库双活 + 存储双活结合的方案来部署实施的。数据库双活实现数据计算层双活，存储层实现数据存储层及非数据库相关业务的双活。数据库和其他非数据库业务之间是有强一致性要求的，因此需要通过底层存储双活来进行统一保证一致性。

观点 2：

系统容灾方案可以分多个层面，根据容灾的安全级别不同来考量选择的容灾方案，其根本原因是需要付出的“金钱”代价不同，数据双活是目前性价比相对较高的方式，大多数企事业单位能够接受，当然数据双活就意味着不是业务双活，强调的是数据灾备的强一制性，即数据不丢失为 RPO 目标，数据双活可以是数据库层的双写，或者存储层的同步双活；这咱情况下当一个中心站点 A 出问题时，可以保障另一个中心站点 B 的数据是可用，且具备一至性的；但业务则需要在另一个中心站点 B 重新拉起业务，拉起过程根据业务的复杂性，关联性可能需要数分钟甚至半小时；适用于业务停机而不会对业务产生大额损失的单位。不适合银行的核心业务。

【问题 20 】农商行 / 农信社核心系统一般是同城灾备还是异地灾备？

农商行 / 农信社核心系统一般是同城灾备还是异地灾备？

观点 1 ：

一般是需要建设可切换的 “ 两地三中心 ” 灾备体系，既需要同城灾备，也需要异地灾备，并且同城 / 异地灾备中心的建设有明确距离要求和切换要求。根据每个银行业务连续性的规划策略来有正对性的进行评估，需要有专业的咨询人员介入具体情况具体分析。

观点 2 ：

一般要求都是两地三中心的架构，同城加异地的模式来进行建设，这是金融行业的硬性要求，是必须要满足的。

【问题 21 】新一代核心存储是否必须要用分布式，传统 FC 能否满足需求？

观点 1 ：

没有绝对意义的必须，只有合适与不合适。对于核心系统而言，安全稳定、性能高效、数据一致性等因素都需要存储具备一定的稳定和性能的，不能出现各类问题，一旦发生问题导致数据丢失后果十分可怕。传统的 FC 在运行这么多年以来，稳定一直是 FC 具备的特点，对于分布式而言，近些年来发展也比较迅速，但在运行过程中出现的问题也不少，因此在考虑选择时要多种因素，不能为了用而用，而是要确保选择的效果。

观点 2 ：

数据中心 IT 建设不应是异或的关系， IT 建设可以参考双态 IT 建设的思路，新一代核心存储根据需要，可以是基于 FC 的 FC-SAN 或 IP-SAN 存储，也可以是 NAS 存储，统一存储具有更好的适应性，但性价比未必高；至于分布式存储，大多情况下说的是软件定议存储（属于 NAS 类，当然也有支持块和对象的），它适用于大文件并发存储业务，但并不适合于传统的 “ 行式 ” 数据库（例如 Oracle ）；因地置疑的去规划存储才是本道；没有万金油。

【问题 22 】数据库一体机 or 全闪存储 ?

在核心系统基础架构设计中，数据库使用传统 SAN 架构配全闪存储，与部署在多节点的数据库一体机上，这两种方案如何比较？

观点 1 ：

数据库一体机有太多限制，特别是如果要实现厂商所谓的性能加速的话，有很多前提条件。而且和数据库是强依赖的，没有普适性。当前第五代全闪存储使用 Nvme 、 SCM 等新型协议和介质，性能上已经完全不是问题了。

观点 2 ：

这两种方式可以从性能以及价格等方面进行考虑，如 oracle 数据库一体机产品，从选择的 2 种方式就价格及性能等方面进行考虑，若一体机的话产品选择面比较窄，可供选择的厂家不多，若采用全闪存储的话可以从多家厂商中进行选择，特别是对于招投标越来越严的形式下也是比较好的一种方式。

【问题 23 】 EMC 全闪存储的稳定性如何？是否适合应用在农信的核心存储？

再打开压缩消重的情况下，同系列 EMC 全闪存做 ssdf 的稳定性如何，现有 bug 是否已修复？

观点 1 ：

目前 DELLEMC 的 Powermax 系列存储和 VMAX 系统存储在农信的核心存储中已经有很多的案例， DELLEMC 的存储解决方案成熟可靠。经过了金融行业的广泛的验证，并且获得了认可，并且可以提供性能无损的重删压缩和快照技术，还可以提供 “ 存储无忧计划 ” ，提高存储的有效容量。

【问题 24 】基于核心日均几千万笔的交易量，新核心架构如何设计才能满足？

观点 1 ：

需求方面两个重点：

1. 几千万笔这个范围还是十分巨大的， 1000 万笔与 9000 万笔之前的架构区别可能就会十分明显了。
2. 这个量级的交易是否包含查询，还是不包含查询纯交易。这个区别也是非常大的，因为对于普遍意义上的应用程序来说，查询的占比一般都会在 80% 以上。因此如果纯交易是 1000 万笔的话，按照 80% 查询计算，查询还要增加额外的 4000 万笔。每天总量 5000 万。如果纯交易 5000 万的话，那么总量还要同比放大。所以这两点非常关键。

对于这种大交易量系统来说，我们在设计上要从三个层面进行考虑。

1. 应用架构层面
   一般来说，目前的主流分布式架构都可以满足。如下图所示：

   当然，这是通常情况下的架构，也有很多应用不是这个架构的，在这里就不做详细讨论了。

2. 应用架构与数据库架构耦合层面
   在这里主要需要考虑，业务系统是否有强一致性需求。如果系统没有强一致性需求，业务上可以忍受最终一致性的话，可以考虑通过 MQ 解决方案，将应用层对数据库层的调用从同步调用改成异步调用。这一点是可以让吞吐量实现翻天覆地的变化的。
3. 数据库架构层面
   首先，千万级的交易量并不是一个非常可怕的量级。以每日 5000 万笔为例，按照每天峰值交易时间 16 小时。换算成每秒笔数的话换算公式是这样的 50000000/(16x3600) = 868 笔 / 秒。这个量级的负载集中式的 Oracle 数据库完全可以满足。妥妥地。
   数据库层面上最主要需要考虑的一点就是这几千万的交易量是作用在一个多大的数据集上。即并发冲突问题。
   如果核心应用如淘宝一般，系统支持海量店家，但是每个店家的数据完全没有重叠，为了降低成本，什么分布式数据库，数据库分库分表等方案都可以往上招呼。但是如果向银行那样的应用，大并发作用在小数据集上，考虑到数据库锁对性能的影响，集中式数据库就有较大优势了。
   另外针对海量查询的需求，还可以采用读写分离以及内存数据库等方案进行分流，减少核心数据库穿透。但是在做编程模型的时候需要详细设计和考虑读脏数据的问题。

观点 2 ：

核心系统设计按照原先的思路确实是要为未来 5 年甚至更久进行自上而下分析，精心测算，仔细规划。但是我们往往发现规划不如变化，再详细的规划和设计都很难满足业务的快速规划和变化。因此才会有现在的云原生、 Devops 等概念出来。因此个人觉得体系架构的弹性、敏捷性比日均几千万笔的交易量更重要。只有以不变应万变才是正道。

【问题 25 】分布式存储主要的性能及安全评价指标有哪些？

观点 1 ：

性能指标：
IOPS 、 MBPS 、延迟（个人认为这个指标其实还是很重要的，目前很多超融合厂商的 IOPS 和 MBPS 都不错，但是延迟却比较大，这对系统的运行影响也是很大的，毕竟用户不想总是看到交易重试的的情况发生吧）
安全指标：
数据重构的时长，数据重构时业务系统的性能影响，单个故障点对整个集群的影响，数据副本损坏对系统的影响，多数据副本并存时的数据一致性。

观点 2 ：

分布式存储主要性能体现在： IOPS 、带宽 MBPS 、 IO 延时、读写速率等。
安全评价指标有：数据重构速率、副本机制、读写机制等。

【问题 26 】新核心建设存储类型如何选择？

对于金融行业，新核心建设时，目前基本都会考虑双活数据中心，在硬件平台双活架构的基础上，应用层面也要支持双活部署，因此，在存储架构方面，是考虑全部采用一种存储方式，如集中式存储，还是考虑集中式和分布式存储共同使用，如集中式用于数据库，分布式用于应用部署。哪种方式更合适 ?

观点 1 ：

金融行业目前交易类和报表类数据库一般情况会在集中存储 san 盘上。
日志业务部分非热点数据可以部署到分布式存储上。类似 log 和 elk 数据。 MongoDB 等，配置库的信息数据。
分布式存储和集中存储目前在银行投产都是单独环境，没有用超融合技术。
只是一个是厂商级别的产品如 EMC VMAX ， HDS 等
另外一个是厂商服务器 + 分布式软件集中控制服务器磁盘完成存储部署。
如果考虑双活数据中心，厂商级别的 san 技术目前稳定可靠
分布式存储如果没有专门团队维护，是个刺手问题。 Hadoop 升级非常麻烦。
目前大部分企业集中存储和分布式存储都有使用， SAN 稳定生产数据库，分布式日志保存。

观点 2 ：

对于金融行业来说，考虑新核心建设时，为确保安全可靠以及数据一致性等条件约束，还是建议按场景（如数据库和应用）分别对存储进行使用，建议不混合使用。集中式存储使用至今在数据库和应用上都没问题，特别是集中式存储的同步工具等都很成熟，对于分布式存储来说，可以使用在应用上，部署起来也比较简单，也能满足应用的性能和可靠性要求。