社区今日组织线上同行交流活动，主要围绕非关键交易系统的存储架构设计，具体包括风险分析方法、架构选择、容量管理策略制定和存储设备四方面。现将活动交流中的精华内容总结如下，供大家参考。
Q1、非关键交易系统存储升级及实施风险控制
【问题描述】金融行业非关键交易系统的重要性不言而喻，而且属于银行与监管或第三方间的重要关联交易系统，因此存储升级，迁移实施复杂，风险较大，社会影响及监管影响也不容小觑，从哪几个方面控制好相关风险及具体案例？
@某农信 存储工程师：
农信银系统是我行除传统核心、互联网核心平台外的重要交易系统，我们需要对其进行存储更换，个人主要考虑了以下方面：
1、社会影响：我们的农信银系统有一项很重要的交易--X码付，社会覆盖面广，交易频发，如果发生宕机事件，社会影响较大，因此通过短信平台，提前发布变更信息，并联络客服中心，准备好话术，避免事故发生时扩大负面社会效应。
2、监管影响：对于存储切换变更，提前向监管机构（银监局、人行）做好报备，将详细的变更方案及应急预案提前上报。
3、对接机构影响：目前农信银中心的监管非常严格，因此需要提前向农信银中心申请时间窗口。
4、技术风险：
对于技术的考虑，是我作为运维工程师的重点考虑，保障数据是根本。
按照这个思路我首先考虑的是无中断迁移，那么需要梳理原本的存储架构，好在我们原本的存储架构中使用了存储网关，支持存储异构，那么存储的迁移变的简单，无需在服务器层面做什么动作，一切通过存储异构来实现数据的同步，对上层无影响，例旧存储和新购存储分别做好volume提供给存储网关，存储网关做好镜像，在rebuild结束后，撤掉例旧存储就可以了。
存储迁移技术做好，就需要考虑各部分可能产生的风险，如果迁移过程不顺利，极端状况下原有存储也故障，那么就要考虑数据丢失的问题，需要提前做好备份，至少在变更开始前要执行一次全量备份，如果能在过程中做增量备份最好，行内基础环境无法实现的话，就要做好数据恢复过程中的数据补录动作。全量备份通过备份软件实现，增量数据通过数据库的异步复制技术实现。
之后也要做好设备的备件，存储网关的备件，例旧存储的备件尽量准备齐全，尤其是硬盘，引擎这类重要部件，如果本地有厂商的备件库，那么提前安排好。
验证人员与保障人员也要提前准备到位，在迁移完成后，尽早执行验证工作。
总体来说我在升级过程中基本的考量就这些，但是肯定还有一些细节的问题在这里是没有说明的，做计划，出方案，协调人员，整体工作执行了三个月，关于方案的改版多达40版，对于时间的预估也提前做了很多测试工作，关于链路也做了很多考量。
@xuzc 某银行 系统工程师：
从运维流程管理出发，针对非关键交易系统一般会涉及所谓的中端存储，相较于高端存储稳定性会有一些差距，存储设备升级前的风险评估是非常必要的，且升级过程和步骤也需要与厂商review，配合监管窗口进行升级规避潜在风险也尤为重要。事前积极评估梳理计划流程回滚方案，事中安排有处置能力人员进行操作明确回滚处置场景，事后核查验证总结。
Q2、中小银行如何制定合理的存储容量管理策略？
【问题描述】当前应用的飞速发展带来了巨大的数据膨胀，也给存储的容量管理带来了巨大的挑战。中小银行应该如何制定合理的存储容量管理策略？以及如何做容量分析？
@赵海 技术经理：
容量规划是个大问题，需要从以下几个方面来考虑：
1. 临界值指标体系建设。
什么样的存储资源？到什么样的临界点？需要报什么样的警示？也就是先建立一套阈值控制机制。
2. 容量的趋势发展分析。
什么样的存储资源？什么样的增量发展趋势？应该采取什么样的增补措施？应该如何调整阈值策略。
3. 容量的使用状况分析。
什么样的存储资源，性能与容量发展如何？存储策略及容量该如何调整？
@pathzju 戴尔科技集团 MDC：
过去通常的容量规划方法是年度规划（已有业务自然增长+年度新项目规划）+零散项目需求的方式；在没有大的业务转型的前提下，基本上可以满足容量管理的需求；但是随着数字化转型的深入，增加了很多新型的业务应用，比如云原生类业务，敏捷弹性变化还快，所以即使在数据中心内，传统的方法也未必能行之有效了；存储容量的管理需要有新的思路和解决办法。
当前的一种常规的办法是利用软件工具比如CloudIQ等，实时进行容量的监控，同时可以基于容量历史的使用情况进行未来的趋势预测，结合过往经验和工具帮助我们更好的进行容量管理；
还有一种是从根本上实现容量管理模式上的转型，即弹性订阅模式，比如FOD方式：即用即付，将CAPEX转换为OPEX，按照实际使用量进行付费，具备类似公有云的敏捷弹性。用户是按最低承诺使用量按月付费，但交付给用户的设备是具备缓冲弹性容量的，可满足高峰和猝发使用需求，没用到就不需要再额外付费，用到了就是用多少付多少。通过这种订阅式且具备弹性容量的FOD模式，对于用户的部署速度和运营成本都会有极大的改善。总体来看，FOD模式可以理解为将公有云的消费方式搬到用户的数据中心，每月就像掏手机套餐费，套餐以内随意消费，套餐以外按用量收费，套餐估算越准确，越划算，套餐费还可以修改。这可能会是未来容量规划乃至数据中心基础架构建设转型的一个新的方向。
@nkcsxuEy 某股份制银行 存储工程师：
海量的数据增长挑战下，数据分级管理是关键。同时，做好系统和存储的容量增长监控和趋势分析，有条件可以引入智能预测，能够更好的助力容量管理工作。
@haozhangsir 银华 系统工程师：
容量主要至少保留30%的可用，考虑到采购流程的长短，通常做3-5年的规划，在数据估算的基础上，仍增加30%的容量预留。
@xuzc 某银行 系统工程师：
面对IT横向管理，存储容量趋势很难预测，现在大多数存储产品会根据使用落盘容量推算出容量增长趋势作为扩容参考依据，如果没有这种功能可以根据本单位的采购周期和使用经验确定容量阈值并设置告警推送提醒需要采购扩容。
Q3、相对于分布式存储的高扩展性、高性能、低成本等特性，集中式存储的优势在哪里？
【问题描述】分布式存储具有高扩展性、高性能、低成本等特性，不但为公司节省成本还能降低运维的压力，节点越多性能越好，按这样说是不是可以代替集中存储了？集中式存储现在的优势在哪里？
@pathzju 戴尔科技集团 MDC：
1）专用硬件的集中式存储经过数十年的发展，技术相对成熟，其稳定性和可靠性相对更高；
2）集中式存储的数据服务功能更加丰富，包括双活，三点容灾，数据分层，快照，多协议访问等；
3）没有分布式架构中频繁的节点数据交互和传输，集中式存储的IO延迟会更低，性能敏感型业务非常合适；
4）容量利用率通常会更高，一般通过内部的Raid保护，无需多副本的开销；
5）集中式存储的运维管理相对比较简单。
@xuzc 某银行 系统工程师：
以数据中心建设前期耗费了巨额投资采购了数量庞大的FC网络设备为前提，集中存储部署简单，即插即用，调配灵活，且FC网络的稳定性有目共睹，特定数据环境下，例如：VDI、VDS，其数据落盘重删压缩比十分可观。
Q4、面对非关键交易系统多样化的数据类型，如何选择合适的存储架构？
@skey_deng 某农商业银行股份有限公司 系统运维工程师：
对于银行的交易系统，产生的数据，个人认为主要有以下几个：1、业务数据，存储在数据库中的客户信息，账务数据、交易流水等，2、交易系统本身产生的交易日志，3、交易过程中传输的文本文件、影像文件等，比如票证扫描件等，4、系统核算产生的过程文件，5、按照监管要求或者本公司要求产生的报表（大部分是行程数据库的视图而并不形成报表，主要看采用的技术手段）。
而针对这些类型的数据，个人认为，存储的选择如下：
1、存放在块存储中的：业务数据
2、存放在对象存储中的：交易过程文本、影响文件
3、存放在文件存储中的：交易系统日志、系统核算过程文件
4、存放在表格存储中的：报表文件
块存储、文件存储目前更倾向于集中存储结构，对象存储、表格存储则需要选择分布式存储。对于块存储和文件存储的选择，本人之所以目前倾向集中存储结构，主要是因为目前集中存储的运维难度，成熟度，稳定性都稍高些，后续随着分布式技术的成熟，NVME，RDMA等各项硬件相关技术的成熟稳定，自动化运维技术的成熟，集中存储将逐步失去优势。
以上仅仅是粗略的选择策略，但是技术的使用都是以本公司业务需求为出发点的，如果业务量非常小，将存储分的细致完全没有必要，并发量不上百，就想着存储分级分类，那完全是浪费资源。仅代表个人观点。
@pathzju 戴尔科技集团 MDC：
非关键交易系统的数据类型非常的多样化，过去规模比较小的时候，我们通常不太区分这些数据类型，基本放到一种存储设备内，这种方式当前对于很多用户或者系统也仍适用；
不过随着数据量和应用数量的快速增长，从管理上看，可以更加细分的去区分数据类型，理论上不同的数据类型适合于存放在不同的存储介质内，比如交易系统的数据文件放在块存储上，交易日志/归档/监控/应用文件等在文件存储上，大对象可以考虑对象存储内；但实际中如果完全按照数据类型的最佳实践去存放数据，业务数据将变得非常分散，无形中又增加了管理的难度和故障点；所以从我的经验上看，并发量超大的系统可以考虑多级分级构建，前提也需要考虑各级存储介质的配套数据保护或可用性设计；一般情况下，目前单纯使用块存储，或块存储+文件，或块存储+对象基本上可以满足绝大多数交易系统的使用场景；
Q5、存储管理人员面对：异构多品牌存储如何进行统一管理？释放存储人员的管理压力？
【问题描述】非关键业务系统应用的存储都是一些中端存储架构，这样涉及的品牌就会非常多，非常杂：EMCIBM华为HDS等等面临多家厂商的存储设备，数量多、异构性复杂，存储管理员就非常痛苦，如何能更好的进行异构存储统一管理？减少存储管理人员的工作压力？
@xuzc 某银行 系统工程师：
建设面向存储系统的运维平台，通过整合异构存储设备、存储网络以及专业存储软件等子系统，实现覆盖整个存储系统的大运维平台，打通各个子系统之间、子系统内部各个异构部件之间的管理信息屏障。平台通过多协议管理接口的对接，接口层统一标准化，打通信息屏障，收集数据分析。
@annoymous 存储工程师：
异构存储统一管理最大的难题，还不仅仅是管理接口的问题，而是存储领域专业门槛太高、涉及专业领域太多的问题。对于使用者来说，存储不单单是磁盘阵列，或是SAN网络，而应该理解为一个系统，它是由存储设备（集中式，分布式，带库、存储网关等）、存储网络（SAN，ETH，IB，RoCE等）和配套的存储软件（复制、备份、重删、压缩等）共同构成的的系统，包括本地存储系统、近线备份系统、双活/多活存储系统、两地三中心/多中心数据灾备系统等等。在大型金融机构的核心生产，这些系统又有机的组合在一起，实现数据中心级别的“存储系统”。对厂商来说，单任何一个领域都有专业的厂商来服务，而对客户来说，却面临所有领域技术的集合。跨领域的管理能力整合，才是异构存储同意管理的最大难题。作为整个IT基础设施的地基，整个存储系统中任何一个环节上的问题，都会影响上层应用的高可用甚至造成数据安全问题。
要实现异构存储的统一管理，无外乎以下两个思路：
1）数据整合法：各专业领域都有厂商配套的工具软件，这些系统中已经实现了数据采集和局部的建模，只需要想办法将这些系统中的数据抽取出来，在上层汇集数据，也可实现全局建模。难点在于这些软件本身没有标准接口，需要厂商的技术支持，开发难度大。
2）自建系统法：通过对接不同存储和存储网络设备的管理接口，直接从设备上获取数据。这样做可实现高度自控，难点在于设备管理接口差异性也很大，但也基本都有资料可寻，真正最难的是建模部分，相当于从最细粒度逐级建模，构建整个存储系统架构的可视化管理视图。说白了不是开发技术问题而是专业知识问题。
由于存储的专业性和封闭性，导致开源社区在存储管理领域可用的资源非常少，依托于厂商的工具又不能实现全面的覆盖，这就需要第三方厂商的解决方案。这个领域我们已经深度研究了12年，上述的问题也是我从事12年异构存储统一管理解决方案研发的心得。
@haozhangsir 银华 系统工程师：
目前主流网关包括svc还有vplex，可以采用这些设备，不过对于运维来说，并没有什么提升，该怎么维护还是需要怎么维护的，而且巡检的设备会更多，如果不是为了双活，感觉上异构存储网关意义不大。
@pathzju 戴尔科技集团 MDC：
异构品牌的管理一直是存储管理的难题，当然管理这个概念的范畴很大，每个用户可能面临的需要更好的管理的问题也不尽相同。
如果是资源调配类的异构管理需要，比如解决数据孤岛或集中共享等问题，虚拟化网关比如Vplex等解决方案就刚好适合，形成统一的资源池，通过一个界面管理所有的存储资源，既减少了调配难度，又提升了资源的整体使用效率；
如果是日常设备众多，需要统一的运维监控，实时掌握存储的状态，为了减少壁垒，可以选择开源监控的架构，比如基于Prometheus+grafana的解决方案等。
Q6、中小银行使用一套集中存储，未来需要对数据进行分级分类存储，有什么比较好的管理方案可以借鉴？
【问题描述】目前我行基本大部分业务都使用一套集中存储，并未对数据进行分级分类存储，正在向这个方向努力，各位大侠是否有成熟的管理方案可以借鉴？
@xuzc 某银行 系统工程师：
可以利用多租户管理架构，将存储资源管理工作通过租户管理员下放存储管理工作进行分权分域，这样就要求应用纵向管理人员对存储管理知识有一定了解，释放了存储管理员压力。
@pathzju 戴尔科技集团 MDC：
数据的分级分类依赖于业务的分级分类；首先建议制定业务的分级标准，并明确对于数据存储的要求，比如性能，容量，备份，容灾保护，归档等等；
其次，同时需要考虑数据类型，不同数据类型对于存储资源的需求特点也不一样，比如数据库类更多倾向于块存储，数据文件类倾向于分布式NAS，外部资源或票据，双录类的可以考虑对象；不同类型的存储资源池间也可以考虑数据的流动性，可以通过基础架构平台解决方案实现，也可以通过上层应用软件实现；
最后，根据以上可量化的需求标准和数据的多样化要求进行架构设计和选型。
Q7、PowerStore相比Unity等传统中端存储的改进的地方有哪些？非关键交易系统采用PowerStore相比其他存储产品的优势是什么？
@pathzju 戴尔科技集团 MDC：
UnityXT存储属于第四代存储，全闪统一存储架构；PowerStore隶属于第五代存储，着眼于智能；
从我的角度看有几点区别可以更加的关注：
1）PowerStore重运营体验，支持横向多控的扩展，能对集群内的资源进行统一的自我发现，自我优化，自我调整，后期存储运维管理投入更低；
2）PowerStore的部署模式有革命性的创新，除了作为常规的外置存储外，还支持AppsON的融合部署模式，即在控制器内通过实施ESXi，应用可以直接部署在存储控制器内，好处：1）对于边缘分支，通常机房环境和运维能力没那么强，通过2U的PowerStore直接解决计算，存储网络，存储，以及向主中心复制所需的数据复制等要求；2）对于主数据中心，PowerStore与自建的Vmware集群，基于Vmware的HCI底层同构，应用可以根据管理需要和数据访问要求灵活的在几个平台内进行调整；
3）PowerStore性能更高，支持端到端的NVMe和下一代存储介质SCM，性能相较UnityXT，IO能力提升7倍，IO延迟却只有1/3；
4）PowerStore可以支持与云管，K8S，Ansible等进行集成，自动化能力更强
@xuzc 某银行 系统工程师：
Unity 混闪在我行有部分应用，目前PowerStore也已经上线，它在继承了Unity稳定性，灵活性基础上，进一步提高了性能，同时增加了压缩，去重的功能，目前整体数据缩减比接近5：1，使得空间几乎可以一次性分配完毕，投产后无需再做调整，降低了运维复杂度。PowerStore可以同时支持SAN，NAS，CSI，vVol，以及横向扩展，未来可针对不同的数据服务和接口，计算能力和存储能力进行独立扩展。
Q8、非关键交易系统存储架构，选择集中式存储还是分布式存储？
@xuzc 某银行 系统工程师：
可根据系统上层运行的应用进行选择存储架构服务：结构化数据，例如Oracle数据库，根据自身成本可选择集中全闪存储或混合存储；有并发共享需求数据服务，例如was、gtp，可选择带文件机头的集中存储、统一存储、专用文件存储；针对非结构化数据，有高并发海量存储需求的，例如图片、录音、录像等，选择分布式对象存储。以上仅供参考，实际选型还要看本单位具体业务部门对数据服务的实际要求来进行选择。
Q9、支付类等非关键交易系统的存储升级策略是什么？
【问题描述】把农信银、二代支付、大小额、网联等支付类算为非关键交易系统这点不敢苟同，这些都是7*24小时关键系统，支付类一旦出现问题导致的后果十分严重。而中间业务类部分业务晚上是没有业务的，相比支付类显得重要性没那么足，针对支付类系统存储升级策略是什么？未来的趋势又是什么？是否能进行分布式改造？改造的成本TCO有多高？稳定性是否足够？
@xuzc 某银行 系统工程师：
二代支付、网联等系统在我行是关键交易系统，针对这类重要系统关键数据要存放在采购成本范围内稳定性、高可用性、性能方面最好的存储设备上，一般这类存储厂商会有成熟升级方案，与每年度报备监管部门升级窗口进行并用，防止升级隐患造成的不良影响，对于传统行业支付类系统来讲，个人理解求稳比创新重要，分布式改造个人持保留意见，也要从系统架构改造实际出发。
Q10、存储双活及级联问题？
【问题描述】两地35公里这种做存储双活，是使用同机房双活保证高可用，还是同城两中心做存储双活？ 因为我们的距离比较尴尬，35公里在官方级联模块中只有8Gb，考虑稳定性，有点顾虑。
@EndlessRain：
8Gb速率并不是影响稳定性主要因素。
其次，这个速率完全可以跑几百/MB吞吐。那些关键应用如数据库，OLTP类型业务很多4Gb FC 吞吐都可以满足。这些应用更加在意的是IOPS，延迟，最后才是带宽吞吐。如果你构建双活平台上面的业务每天增量，几百/MB带宽可以cover住，你当前提供的速率没有问题。
最后，通常来讲35KM之间两个数据中心的不稳定因素主要是延迟上，全天候的延迟这些可能因为抖动，光衰很多因素造成的，而运营商那边也不能提供足够的支持。
@lktianxia 石家庄希望伟业 网络工程师：
你可以用DellEMC 的Powerstore 加metronode也是基于vplex的真双活技术，是分布式架构，4-1的数据有效容量，有连续数据保护，也可以用来承载部分计算节点功能！
Q11、存储升级替换过程中，数据迁移方法的选择？
【问题描述】存储升级替换过程中，同构存储选择什么样的数据迁移方式，存储还是基于上层软件，异构存储又该如何选择，各自面临的最大的风险是什么？
@xuzc 某银行 系统工程师：
集中存储设备迁移在没有存储虚拟化网关的情况下要考虑同构迁移和异构迁移，同构迁移如果可以采用厂商产品底层迁移功能，可直接底层无感知的迁移数据到新设备，存储厂商一般都会有相应的升级接口和功能；异构存储迁移要考虑存储设备多路径软件更换，使用第三方多路径软件要留意系统识别盘号问题，考虑迁移完成后盘号是否要根据业务类型特点调整，数据迁移依赖系统软件进行拷贝或导入导出，最好预留停业甚至停机窗口支持数据迁移工作。
@某公司 系统工程师：
这个基于不同场景和技术约束下的综合比较选择吧，没有说哪一种是最优的，应该选最合适自己的方式；
常规而言，一般都是选择技术上层软件的方式，如数据库的，使用数据库迁移工具、数据泵导入导出等；但是这种方式对技术要求较高，而且迁移窗口时间相对较长。
也有使用操作系统底层的lvm方式，但是这个对于存储选型较为严谨，毕竟涉及存储多链路的问题，最好是同一厂家的，迁移窗口时间也长；
还有就是使用存储网关来做迁移，相对来说操作比较简单（新购原厂一般有技术支持的），迁移窗口时间比较短（可以后台数据同步），但是整体来说价格偏高了，既要买存储，还得配置网关，而且后期维护相对复杂一些。
各种方式按自己最合适的选呗。
Q12、分布式存储的缺点是什么？
【问题描述】对于存储架构的选择，个人较为倾向使用分布式存储替代集中存储设备，其主要原因如下：一是主流技术发展方向的问题，一个是设备的采购成本及运维成本的问题。对于技术发展方向，互联网行业的成功实践已经证明分布式架构的技术优越性，尤其是对敏态业务的支撑，让“时间就是金钱”得到充分的验证。对于采购成本及运维成本的问题，X86设备的制造成本，闪盘的制作成本正在逐步降低，更加凸显分布式架构建设成本的优越性。针对这样的选择，不知道分布式存储在使用时存在什么样的缺点，或者存在什么不稳定性？
@JanXC nec 系统架构师：
相比集中式的商业存储，分布式存储的缺点或是不足，个人认为有如下：
1，性能的问题，这应该是一个曲线，数据量和系统规模未上来时，同等配置的集中式存储性能应该是相对优于分布式，大数据量、高并发的场景，分布式的性能才会上来。
2，分布式存储技术架构相对复杂，特别是选择开源的解决方案，一是缺少大量的市场检验，其稳定性欠于集中式，二是技术复杂，运维成本较高，三是缺少便捷的配套设施和管理手段，很多命令行的原始方式管理，四是对上层系统、中间件及应用的兼容性问题，例如对vmware的支持、Oracle的支持等。
@某银行 存储工程师：
非常认同，尤其是第二点，对于中小银行来说，本身的运维团队就存在技术天花板的问题，并且资源相对匮乏，之前我们在POC某国产分布式存储过程中就需要输入各种命令，编写python脚本，非常头疼。
点击文末阅读原文，可以到原文下留言交流
觉得本文有用，请转发、点赞或点击“在看”，让更多同行看到
资料/文章推荐：
欢迎关注社区 “存储”技术主题 ，将会不断更新优质资料、文章。地址：https://www.talkwithtrend.com/Channel/179
长按二维码关注公众号
*本公众号所发布内容仅代表作者观点，不代表社区立场；封面图片由版权数据库授权使用
