城商行核心系统平台架构下高端存储选型的 9 个典型问题
【问题 1 】 核心系统架构下高端存储选型应考虑哪些核心业务场景的需求？对应业务需求的具体特点是什么？
【讨论总结】
采用传统架构下的银行核心业务在不同的场景有不同的特点，相应的，对底层存储需求点也会有所偏好和侧重：
核心联机交易类数据库是一个实时的账务类交易系统中重要部分，具有数据量大、数据访问高并发、强实时性，要求存储性能指标配置可以涵盖最高并发 IO 量、吞吐量、低延时等需求，同时在数据保护冗余性级别为高，同时满足 3-5 年的数据量容量增长；
批量业务数据库，在夜间承担少量对外服务以外，主要特点是时效性较高，数据变化量大，并发性要求不高的准实时数据处理，这也要求存储具备较高的磁盘访问效率，最好具备热点数据分析与迁移，批前保护与批后备份的数据快照或克隆等保护功能；
核心数据分发与外围系统交互，可通过共享日志文件交互，同时通过对核心数据库抽取与分发平台，实现核心数据与外围系统的交互与展示， 要求存储具备较好的共享性或较高的读效率，也可通过 NAS 功能实现共享；
业务连续性要求，受监管机构要求，核心业务系统需要保证非常高的业务连续性和故障恢复时限的规定，这要求存储在数据可用性和一致性都需要实时连续的保护，因此对双活、同步复制等技术有较强的技术依赖和需求。
备份归档需求，核心业务的备份场景也需要存储系统高级功能实现，既不对生产数据产生性能影响，还要达到同城和异地备份的效果，这也对高端存储提出数据复制备份恢复与验证的要求。
【问题 2 】 针对核心系统平台架构，中小银行如何进行高端存储选型？选型依据及方法论有哪些？
【讨论总结】
对于 IT 产品（包含存储产品）的选型，主要考虑：可靠性、可用性、功能性、可管理性、架构设计、性能、 TCO 等方面。
上面探讨问题的关键是银行核心架构和高端存储选型，考虑的因素还是会根据核心系统的业务特点，考虑发挥高端存储的高可靠性、高性能和后期运维服务力度，结合成本因素根据各自实际情况进行选择。
高可靠性 ——对于核心存储设备的选型，首要指标就是存储的可靠性，这里的可靠性包含了三个层面，一是存储设备器件可靠性，包含了主要器件的冗余性设计，支持热插拔等；二是存储设备整机的可靠性，包含了整体硬件架构是否支持多控制器，是否支持控制器四坏二甚至四坏三；三是对于各灾备特性的支持，包含存储层双活以及两地三中心的支持度，双活仲裁机制是否可以保证我行常见故障场景下业务的连续性和数据不丢失。
高可靠性下的高性能 ——对中小行而言，核心系统存储建设事关重大，一旦建设完成，需要保证至少 5 年内上层应用不出现存储层的性能瓶颈，随着闪存技术的快速发展，目前全闪存存储已经成为各家主流存储厂商的标准配置，闪存技术日趋成熟，就闪存技术而言，目前市场上的全闪存主要包含了原生全闪存和改良型全闪存两大类，原生全闪存即是针对全闪存介质全新研发的存储操作系统，这类存储的特点是可以最大限度发挥出全闪存介质的高性能的特点，但是对传统的存储容灾特性支持度较弱；改良型全闪存即在原先高端混合存储的基础上对存储操作系统做一定的改良，从存储 IO 路径和存储协议等方面去做修改适配，在不影响原有存储特性基础上，尽可能发挥出全闪存的性能优势。两种存储各有优缺点，结合我行的实际业务发展需求以及行业的强监管属性，我行目前更倾向于改良型高端全闪存，这样可以在保证可靠性的前提下去做新技术的尝试，推动全闪存在我行实践落地。
后期运维支持力度 ——对于中小银行，运维能力向较大型国有银行和股份制银行处于弱势，而对于核心系统存储，采购和交付只是存储生命周期的很少一部分，交付后的运维工作才是运维人员最主要的工作，这里就需要存储产品好运维、易运维，需要存储厂商在运维保障上提供足够的支持，因此在运维这块我们会考虑我行实际运维人员的技术能力、新产品的学习成本、厂商本地化服务能力等。如果时间和条件允许，建议邀请几家厂商入场做 POC 测试，通过 POC 测试可以对各家厂商实际能力有更加深入的了解，这样为后续存储选型提供更加有说服力的数据。
标准容量下的成本 ——对于中小银行来说，高端存储选型一个重要的参考就是单位 TB 可用容量下的成本，能够花更少的钱买到更多的容量，一定是我们中小银行考虑的一个重要指标，这就对存储设备的重删压缩能力和商业模式提出了一定的要求，最终的选择需要根据实际情况去做抉择
存储厂商开发与服务能力 ——厂商自身的研发实力以及服务能力，是否有未来数年的规划，支撑客户的业务需求变化，是否有软硬件的研发能力，在遇到个性化需求时或需求变化时能够有跟踪变化的能力，是否有本地的服务力量，对客户的响应是否及时且有效，上面的问题是客户和厂商都很关注的问题。
【问题 3 】 各主流存储厂商典型高端存储 硬件架构及软件特性 / 双活架构及存储主备复制技术以及两地三中心扩展方案上的对比与差异？
【讨论总结】
各厂商硬件在硬件冗余性，高效性，维护性等方面都各具特色，但都可以满足基本的可靠性要求，相应的双活容灾软件，也都可以满足双活数据中心和容灾切换的需求，随着软硬件的不断更新，性能表现更加出众。各厂商存储复制 / 双活软件都在不断的更新迭代，如华为 HyperMetro 、 HDS GAD 、 Dell Live Volume 、 IBM MetroMirror 和 SVC ESC 、富士通 Storage Cluster 、 HP PeerPersistence 、 EMC VPlex 和 VMAX3 SRDF/Metro 、 Netapp MetroCluster 等，软件的部署和使用都值得展开演示与讨论，由于收到时间和形式的限制，不能充分而全面的对比，相信后续会以更直观更全面的方式进行对比与讨论。
两地三中心扩展方案的对比，探讨是给出了一些对比中关键点和无法规避的限制条件，在此基础上的成熟可落地的优秀扩展方案，才有可比性。具体的因素主要有：
距离、链路和时延——同城两数据中心（间距百公里内，使用裸光纤，时延可控在 0.1-1 毫秒以内）异地数据中心（间距同城两中心上百公里，租用运营商专线，时延不超过 10 毫秒）
复制方式——同城两中心之间，无论是通过存储、数据库还是系统集群实现的复制，以同步为主，以保证 RTO 指标；受目前技术条件限制，异地数据中心的复制方式以异步为主，未来会出现低成本的数据传输技术，消除距离因素限制；
可用数量份数——主中心、同城中心、异地中心都会按照业务重要级别、访问特点和切换验证策略设置不同的可用数据副本数量，以多种数据保护方式呈现出来，核心系统至少是主中心 2 份 + ，同城中心 1 份 + ，异地中心 1 份 + ，数据副本的时效性也是同城两中心数据实时性最强，异地中心稍差；
切换方式——最好的切换方式就是 " 不切换 " ，也就是业务无感知的切换，那么双活甚至多活的存储与数据库当然是首选，无论是在切换效率、切换效果上，都会优于其他方案，无论是人工操作还是一键式自动切换，都具备得天独厚的优势
成本计算——新一代存储设备的面试带来的是性能指标的绝对提升、架构更加可靠，最后的扩展方案和 RPO/RTO 的指标也会趋近完美，但投入的成本也不是无休止的，在现有三中心架构下，恰当的保障现有业务运行，当业务快速迭代致现在架构无法满足时，以采代保完全替换还是少量补充新旧更迭，都要以自洽的人力和财力成本计算。
那在上述基本条件、复制方式、切换方式、可用副本数量与成本因素的条件下，综合评测给出“单位效果”的最低成本，或者是单位成本可达最优效果，就是各主流高端存储扩展方案的可衡量结果，希望在未来的实测环境中，以真实的数据和案例做出客观的对比和判断。
【问题 4 】 两地三中心存储复制与切换操作的易用性对比？
两地三中心架构下，存储切换操作的易用性除去个人的熟悉程度与喜好之外，切换操作方式（ web gui/cli ），存储与数据各状态的标记，适用存储手动 / 半自动 / 全自动切换执行方式，哪种数据复制操作更安全、更直观、更便捷呢？
【讨论总结】
从切换操作的可视化方面来看， web 操作较为具备优势，非专业人士也能通过简单的 WEB 页面点击菜单或按钮就能快速简单实现切换操作，但是从切换效率方面来看，可能还是 CLI 更有优势， CLI 不过多依赖浏览器等工具，不会出现浏览器工具兼容性问题，能够专业实现切换操作。但是 cli 需要非常专业的人员才能操作，部分厂商的命令较为复杂，普通人员很难进行操作。
单纯的存储设备，说到切换操作，肯定是有图形界面更加友好。如果配合其他的操作联动，或者集成在自动作业调度系统中，肯定是命令行方式好。另外，现在单纯某个产品的切换不是关注重点了，而重点应关注需要配合整体的切换调度系统，实现一键式切换，无值守的自动切换。
一般采用 GUI 来查看存储及对应操作状态， GUI 在数据展示上更加直观集中，便于观察，但数据的更新可能不及时甚至出现数据错误的情况，所以在进行重要操作时除了在 GUI 观察操作的进展状态，手动执行命令去检查 GUI 上显示的数值和命令返回的一致性也是很有必要的，双重核验确认后再进行，求稳不求快。之所以不用 CLI 去代替 GUI 展示的功能，主要还是 CLI 的数据返回没 GUI 直观，想达到 GUI 的展示效果常常需要多条命令去执行查看，开的命令窗口相应增多，窗口的切换、来回命令的执行，极大的增加了出错的可能性，更影响操作思路的流畅性连贯性。
CLI 主操作 +GUI 辅助查看 +CLI 确认重要指标， CLI 的主要操作都可以被完整的 logging ，不管是做变更记录还是整理笔记，都可以很方便。CLI 的命令回显很准确，主要操作的实时准确性都能 COVER ，整个变更操作也顺心顺手。CLI 的窗口多了，不免就 “ 乱 ” 了，乱中出错的风险就大大增加。不管是作为现场工程师，还是变更负责人，思维跟上操作、操作保障实施是最起码的素质，这也是对生产变更的基本尊重。
涉及到这样复杂规模的架构，平时维护和出现问题时候我们当然希望的是越简单的操作，越清晰的故障报错最好，但很多时候还并不能完全实现我们想要的结果。一般来来说， WEB 界面操作简单、直观，适于平时的维护，监控，包括一部分的业务切换。不过在出现问题是，由于设备的一些底层操作并没有提供 WEB 界面。所以往往在出现问题的时候都需要去 CLI 界面去进行检查和操作。另外，核心存储的切换，不仅仅要考虑存储层面，上层的业务系统，网络结构都需要随之做出调整，这并不是简单的通过存储设备的 WEB 界面就能搞定的，更多的时候在两地三中心这样的架构中，已经不仅仅关心存储层面的迁移。而是整个业务系统的迁移，存储、应用、网络都是这业务系统中的一部分，具体怎样迁移在实际过程中都要根据情况去指定。目前在尽可能的去通过整体的系统去整合所有的部分实现一键式迁移，来简化这种业务迁移的复杂性，但多数时候，还是要有经验丰富的人去监控整个切换的过程，应对随时可能出现的意外。所以我觉得存储迁移也好，业务迁移也好，通过什么方式操作都不重要，重要的是在问题出现之前把所有可能出现的问题整理好，形成标准化的操作文档，并且定期进行业务的演练来熟悉整个迁移过程中可能需要的操作，这才是最安全最便捷的。
探讨到最后，大家一致比较赞同 CLI 为主， WEB GUI 为辅的操作建议， Command Line 操作可以迅速直观的确认关键参数和存储状态，对数据的变化也容易量化计算，结果利于保存用于故障排查、流程跟踪、回退依据和审计监管素材，便于封装成半自动或全自动模块，嵌入到整体切换流程之中；WEB GUI 的界面数据也是从存储状态信息中查询而来，集中展示存储操作和状态信息，免去不必要呈现的多余参数，适合用于辅助切换操作结果确认，总体流程和调度的状态转移确认，针对存储层面切换测试过程可以采用，与业务配合整体操作时，以 CLI 封装测试后的半自动模块，加上领导授权等调度流程，配合日常配置变更和经过验证的标准操作文档，形成一套不单用于满足监管要求，随时可以切换操作的高效容灾切换管理工具。最终，用那种方案操作切换，终究是对切换人员的素质、团队配合、管理水平、操作经验以及工作态度的综合的考验。
【问题 5 】新旧设备更替存储迁移，存储的平滑过渡如何实现？
使用新存储，相应的存储驱动应该有变化，怎么实现平滑过渡的？是否存在兼容性和冲突？从原存储到新存储的数据迁移是怎么实现的？一般迁移数据量大，迁移时间长，迁移方案很重要，是否是停机迁移？主要涉及到的数据库类型有哪些？
【讨论总结】
现在不仅仅是存储，包括服务器、操作系统、中间件这些升级，如果版本差异太大都会出现问题。以存储为例，接口从 SCSI 接口，升级到光口，速率从 2GB 升级到 16GB ，接口板卡的升级就会迫使服务器，光纤交换机随之升级，也推动操作系统，中间件等等这一系列的变化，想要平滑过渡我觉得首先是要保证整个业务系统架构的平滑升级更新，不要让某一个部分断代的太严重，否则可能会就导致上层的应用因为底层设备，系统的升级而无法使用。
存储设备等基础设施的更新迭代，以采代保的策略都是顺应技术发展和业务需要的必然结果，但考虑舆情影响和监管制度等制约条件，应该尽其所能，减少业务中断时间，保证数据迁移过程中的兼容性与业务连续性没有较大影响。单考虑存储的替换与数据迁移，至少有如下考量（其实这部分内容，各存储厂商都比较擅长）
1、提前确认存储、光交、主机连接之间的软硬件兼容性，形成兼容性报告，找到差异，制定升级计划；各厂商存储设备均会有相应的兼容性报告，部分是 pdf 文档，可以直接下载查阅，部分是 web 中填写和生成的，那我们需要把现有与存储相关的信息填写得越详尽越好，包括光交或网络（ FC/iSCSI/FCoE ）设备的的型号、 firmware 版本、 license 许可、端口速率等；主机或集群的型号、固件版本、操作系统版本、存储连接接口卡（ HBA/ 以太网卡）的类型、速率、驱动版本、多路径软件及版本等；也涉及主机至存储设备的访问距离发生变化，连接线需要替换，如光纤线也需要从 OM3->OM4 等。
2、对照新旧版本兼容性报告，制定相应迁移方案
小改动：部分冗余设备的接口卡与 SAN switch 微码升级，主机逻辑磁盘的受管调整（如果存储 vender 不同，新存储多路径软件不影响原存储逻辑卷访问，原多路径软件设置不管理新存储卷），使得在系统层存储迁移过程中，多品牌多路径软件可共存（最好在测试环境验证），这种方案适合系统层通过 LVM 进行存储替换与数据迁移。
大调整：如果应新存储需要，驱动版本连带系统版本需要升级，导致基础服务与语言编译包随之变更，则建议在全新环境或容灾环境下搭建，通过存储复制或数据库逻辑复制， 经过新版本测试之后，找到合适的维护窗口割接业务。
3、其他架构：如果现有架构已有或准备通过存储虚拟化网关，则考虑新购存储与网关控制器、 cache 和端口的匹配性之后，如果可以挂在网关后端，则迁移方案会简单得多，大大减少兼容性导致的迁移动作。
存储迁移涉及到的方面非常多。网络环境，业务类型，数据格式，系统架构，数据大小等等，一般来说。可以通过两种方式实现。
一种是通过存储底层的同步，镜像一类的功能将新旧存储的数据实现同步，然后把业务转移到新存储上。优点是数据同步对业务影响小一些，一般来说不需要长时间的中断业务数据同步后在逐渐迁移上层业务；缺点是对整个方案设计要求比较高，操作中也要谨慎，避免操作错误导致数据丢之。
另一种方式就是通过业务层，拷贝数据库或者数据文件实现，很多时候为了是需要关闭数据库进行拷贝的，不过比较简单稳定。
在迁移之前，更多的我觉得是准备工作，数据备份、应急预案，还有迁移方案的设定，研究还有实施操作，迁移后的数据效验都很重要。
【问题 6 】银行业核心系统 Oracle 如何迁移到其它数据库？选型及实际参考案例？
银行行业中，核心系统的 oracle 库如何迁移到其他库，其他库的选型和实际案例？
【讨论总结】
核心系统的 Oracle 数据库改造可选路线并不丰富。受传统 IOE 架构封闭生态，以及市场可选数据库产品实际能力的影响，传统 Scale-Up 架构对等替换目前没有非常合适的方案。实践中通常会考虑用分布式数据库系统进行替换。
1、架构转换成本问题。银行业核心系统数据库负载特征上存在大量事务，是分布式数据库天然的弱势场景。代价是对应用进行彻底的改造，来避免跨库事务的发生。业界比较经典的实践是招商银行的分布式改造思路。
2、容灾能力问题。Oracle 数据库通常使用 ADG ， OGG ，存储双活等方案组合实现容灾。对于分布式数据库来说，通常使用 shard 多 AZ 复制的方式实现，当然这里要重点考虑该分布式数据库一致性的实现成熟度，技术实现上比传统方案复杂。
3、性能和可靠性问题。当前分布式数据库往往采用分布式数据库 + 通用服务器 + 本地盘的方案承载，相对传统架构，基础的可靠性和 IO 性能较低。集群规模逐渐增加情况下出现故障的概率随之提高，健康运行的时间减少直至不可接受。这种情况下通常会推荐分布式数据库 + 通用服务器 + 全闪存存储的方式，既兼顾了新数据架构，又满足了数据可靠性问题，而且可以继续利用全闪存存储本身的增值特性，如双活、复制、快照、重删压缩等能力，构建出最合适的解决方案，甚至还可能会带来 TCO 的降低。
【问题 7 】针对银行核心高端存储选型过程中如何进行新老存储数据迁移测试以及存储容灾架构和传输链路的测试？
【讨论总结】
在核心存储新购前，厂商会提供测试设备进行 POC 测试，搭建临时环境进行性能和数据迁移及压力测试，形成测试报告，作为选型采购依据，也作为迁移方案中的管家指标。
上面设备的问题解决了，剩下是测试方法和测试用例了，尽量在测试环境模拟核心系统的业务交易访问逻辑和访问量，保证测试数据量与生产环境一致，可以实测容灾切换、数据传输等。至于新老存储的数据迁移，如果需要从存储层面来实现，可以打通新旧存储的 SAN 链路，在旧存储中划分测试卷，进行数据迁移兼容性和传输速率的测试，如果通过系统层或数据库层面进行数据迁移，则无需过多考虑存储本身，只需注意通过系统迁移的多路径软件版本与卷受管方式等关键点。
【问题 8 】核心业务系统的存储和其他业务系统的存储是否有必要物理分离呢？
【讨论总结】
可以根据业务规模、监管需要、盈利成本几方面来考虑。
业务规模不大的前提下，单套高端存储（带有多台数据保护架构）即可满足核心及外围所有业务未来 5 年以上发展的情况，便可通过逻辑隔离达到目的，但当业务规模较大时，就需要考虑监管要求，对核心业务必须具备容灾和恢复时间的硬性规定，因此这部分投入是必须的，相比之下，在物理分离的其他存储上实现，便于分散故障，减小的误操作概率，同时在二级存储的成本上都能兼顾。
【问题 9】 以华为为代表的国产高端存储对比行业其他主流高端存储有哪些优势？
以华为为代表的国产高端存储对比行业主流高端存储有哪些优势？OceanStor Dorado 18000 V6 相比前代高端存储有哪些新功能和新特性？
【讨论总结】
一般来讲，目前高端存储变化相对较少，各厂商产品相对稳定。华为的优势点主要有以下几个方面：
1 、首先从性能来讲，根据 SPC-1 的最新测试结果看，高端存储的性能冠军一直是华为霸占，主要是华为高端全闪的架构决定了相符的性能优势。其他厂商会用 ASIC 来进行数据的处理，减轻 CPU 的负担，但采用 ASIC 也是一个双刃剑， ASIC 的研发迭代周期都会比较慢，对市场的响应速度也相对滞后。
2 、分布式 RAID 。其他厂商，如 HPE 命名为 3PAR RAID 或者 Fast RAID 。华为以 RAID 2.0+ 命名。该细分技术除了华为，其他传统高端存储厂商还是采用相对传统的 RAID 方式。新原生架构 AFA ，基本都用分布式 RAID 技术。
3 、其他方面。其他如高端存储对于对象协议的支持，克隆在同步，周期的异步复制等。其他高端厂商支持方案成熟。特别对于对象协议，目前仅 3PAR 和 InfiniDat 支持。另外周期的异步远程复制，华为的做法是采取直接在内存复制差异的方法，并且采用快照特性保障数据的一致性，由于在内存做快照，因此华为的异步复制可以做到 3-5 秒的 RPO 。
原题：城商行核心系统平台架构下高端存储选型交流探讨总结如有任何问题，可点击文末阅读原文，到社区原文下评论交流 觉得本文有用，请转发或点击“在看”，让更多同行看到
资料/文章推荐：
欢迎关注社区 "存储"技术主题 ，将会不断更新优质资料、文章。地址：
https://www.talkwithtrend.com/Channel/179
下载 twt 社区客户端 APP
长按识别二维码即可下载
或到应用商店搜索“twt”
长按二维码关注公众号
*本公众号所发布内容仅代表作者观点，不代表社区立场