银行全闪存储架构实践.docx

银行全闪存储架构实践.docx

《银行全闪存储架构实践.docx》由会员分享，可在线阅读，更多相关《银行全闪存储架构实践.docx（8页珍藏版）》请在冰豆网上搜索。

银行全闪存储架构实践

银行全闪存储架构实践

一、银行新数据中心建设背景

随着利率市场化的经济政策成为国内金融环境的基调，银行金融业在近几年的发展中面临的来自互联网金融的冲击和降本增效等方面的困难及挑战越来越多。

以大数据、人工智能为代表的新型技术的涌现，在给金融科技注入新鲜活力的同时，也为银行业务的转型和发展带来了新的机遇和挑战。

毋庸置疑，FinTech时代已经伴随着IT技术的飞速发展骤然而来，各类新技术在特定业务场景下的应用不断推陈出新，必将大幅提升金融服务品质，并助力金融行业实现新的利润增长点，真正发挥“科技引领”的作用。

而科技创新要敢为人先，立足根本，勇于尝试，最根本的是确保银行业传统重要系统及平台的安全稳定运行。

数据中心作为银行业各类基础设施和硬件平台的重要载体，其建设和维护不仅要符合政策规范和监管要求，还要综合考虑人力、成本及长期发展规划等各因素做出权衡。

数据中心升级建设，意味着传统重要系统的运行状态要经历一次较大的数字化转型，而防范系统安全风险与持续高效稳定运行则成为数据中心数字化转型建设的根本出发点。

二、银行新一代数据中心建设需求分析

在大批金融企业积极探索数字化转型的今天，数据中心建设领域也出现了双活及多点灾备等概念，一方面在同城灾备中心承载部分外围非重要系统业务实现双活，一方面仍然承担生产中心传统重要系统的容灾备份等关键任务。

在灾备建设上，我行重要系统目前采用业界比较成熟的两地三中心架构，即业务系统归属一个生产中心，同时在生产中心50KM范围内建设同城灾备中心，另选一城市建设异地灾备中心，以满足监管部门对业务持续性提出的高可靠要求。

原有的同城灾备中心只是作为容灾的角色，存在资源闲置、利用效率低、灾备切换不够灵活等缺点，已不再适应我行业务发展的需要及未来双活中心的发展规划，促使新同城灾备中心的升级建设任务迫在眉睫，以逐步实现新同城灾备中心架构完全替代旧灾备中心的目标。

为确保新同城灾备中心运行平稳且满足监管部门要求，新旧同城灾备中心将同时运行一段时间，各项条件均具备时再完成旧同城灾备中心向新同城灾备中心的完全切换。

随着技术的更新迭代，为促使新同城灾备中心逐步升级为双活中心，服务器、光纤交换机、存储等基础设备均需要立项采购，为新同城灾备中心建设提供必要的前提。

三、银行新一代数据中心存储架构选型及产品架构分析

新数据中心建设工作启动之前，我行三中心重要系统均采用IBMPower780小型机及EMCVMAX20K存储等基础架构的软硬件产品。

重要系统由于其无可替代的特殊地位，在基础架构的软硬件产品的选型上，为了有效确保系统平滑迁移及安全可控，新同城灾备中心重要系统基础软硬件应保持同原有产品家族的一致性。

IBMPower880作为Power780的下一代产品，在基础配置上更加高端，整机计算和处理能力也大幅提升，能很好地承载起重要系统的平稳运行任务。

而存储产品牵涉数据中心的命脉，其安全性、稳定性、可靠性将对整个系统的平稳运行起决定作用。

另外，对于重要系统而言，其对存储处理IO的能力要求较高，既要求高IOPS，又要求低时延。

长期来看，随着业务交易量的增大，重要系统不可避免存在存储扩容等实际需求，所以在数据中心资源珍贵的情形下，选择占空间少、易扩展、能耗低的存储也是产品选型中必须考虑的重要因素。

综上所述，无疑全闪架构才能满足我行的具体需求。

按照DellEMC存储产品的定位，EMCVMAX950F是EMCVMAX3全闪存储的最高端产品，能够并发运行成千上万混合工作负载，同时保持一致的高性能。

在大规模环境下，能够提供可预测且快速响应的服务。

可在存储PB级关键数据的同时轻松管理高要求、事务繁重的工作负载。

同时，利用全闪技术消除瓶颈，可为读取密集型OLTP应用程序提供高性能和低延迟，利用大量的写缓存来缩短写入工作负载的响应时间。

在性能密度方面，每个阵列在单台机柜里可容纳双引擎以及多达480个高密度驱动器，实现在单个机架中可承载约170万IOPS，在满足需求的同时更可以降低成本、节约空间。

VMAX在可靠性、可用性和可维护性方面也具有优势，适合无中断可用性的开放式系统和大型机环境，在严苛的任务关键型环境中单机可以提供6个9的可用性。

VMAX全闪的这些特点，很好地满足了我行在存储产品选型方面的基本要求，结合我行实际使用情形，最终我们选择VMAX950F作为重要系统关键数据的底层平台。

图3.1两地三中心基础架构

根据厂商技术解读，EMCVMAX950F跟二代产品（如VMAX20k）相比，具有下列特点：

1、硬件设计采用大幅增强的DynamicVirtualMatrix体系结构，可实现极高的速度和始终如一的亚毫秒级响应时间。

VMAX全闪存体系结构可超出单个系统占用空间的限制进行大规模扩展，从而根据需要提供可扩展的性能。

它可以将数百个多IntelCPU按需加以池化和分配，从而满足动态混合工作负载的性能要求。

这一点可通过强大的多线程技术配合操作系统HYPERMAXOS调度功能来实现，从而确保工作负载所需资源按需调度。

2、VMAX全闪采用实时无中断的存储虚拟机管理程序操作系统HYPERMAXOS。

该虚拟机管理程序将提供嵌入式应用程序的虚拟机，每个容器都可虚拟化嵌入式应用程序所需的硬件资源，并管理和保护这些资源服务。

它还提供对硬件资源的直接访问，以最大程度地提高性能，且虚拟机管理程序可以无中断升级。

3、100%虚拟分配。

由于存储分配给服务器的LUN均为精简设备，所以真正分配给服务器的空间为实际使用的，这样保证了存储资源利用效率的最大化。

4、存储采用预配置方式，使用中无需考虑DiskGroup、DataPool等底层架构，而把可用资源集中放在一个StorageResourceGroup中，极大地简化了运维人员的日常运维操作。

根据应用系统特点，在创建应用相关的StorageGroup（SG）时，可以指定负载类型（WorkLoadType）及服务等级ServiceLevel（SL）。

常见的负载类型包括OLTP（小块IO负载）、OLTPwithReplication（具有本地或远程复制的小块IO负载）、DSS（大块IO负载）、DSSwithReplication（具有本地或远程复制的大块IO负载）。

以上技术特性在我们的后续实践中也逐步体现了其应用价值。

四、全闪在银行新数据中心的实践应用

1、数据中心基础环境准备

由于我行采用全新的数据中心，在数据中心具备施工条件时，先期完成了新设备的到货安装工作。

此次采购的全闪阵列采用标准的600mm机柜，跟二代产品800mm机柜相比，明显减少了机房占用空间。

值得一提的是，虽然占用空间减少，但由于是高密度磁盘阵列，兼顾后期扩容等实际需求，务必确保地板具备稳定牢固的支撑能力，如有必要，可采用一定厚度的钢板做地基支撑确保设备运行条件可靠。

同时，还要考虑机房冷气换风通道开启，为设备在适宜的环境中平稳运行创造条件。

在电力输入方面，全闪同二代产品没有差别，均为两路380V、32A电力要求，但耗电量明显下降了。

2、数据SAN网环境准备

新数据中心重要系统通过SAN网环境实现对存储的访问需求。

在存储前端口的划分上，完全兼顾操作系统版本、用途、冗余性、灾备等因素，结合厂商的建议，对各前端口的用途进行明确，并在SAN网络中完成存储前端口同光纤交换机的光纤部署。

同时，在服务器层面对分区资源进行明确后，针对光纤卡的分配情况，完成服务器HBA卡端口至光纤交换机的光纤部署工作。

在系统建设工作中，要保证底层环境的健壮性，有必要对HBA卡端口和存储前端口在光纤交换机的注册状态做细致检查，如发现异常，要及时找到原因，对故障硬件进行更换。

3、灾备SAN网环境准备

与此同时，对于灾备建设也应同步进行，使两地三中心的三台存储具备数据复制条件。

具体在实施上，同城采用城域网环境下DWDM设备实现数据全同步，底层采用IBMF96交换机实现生产存储与同城950F存储的zone打通。

同城灾备中心与异地灾备中心采用广域网异步复制方式，通过租用某运营商SDH线路实现峰值622Mbps网络带宽的数据传输量，底层则采用EMCMP7800交换机实现同城灾备950F存储与异地灾备存储的zone打通。

同样，要对SAN网的连通健康程度做认真的检查，确保灾备数据复制环境可靠。

为了保证灾备环境同生产环境的一致性，由于复制模式采用SRDF级联模式，在“中间变两头不变”的情形下，同城灾备中心重要系统LUN规格同生产中心及异地灾备中心保持一致，这样在尽可能减少对我行存储环境变更的情况下，也满足了三中心存储数据复制要求，为后期新同城灾备中心切换投入使用奠定了基础。

4、LUN空间划分

在服务器与存储前端口的zone打通之后，需要在存储上划分空间给重要系统完成映射工作。

同二代产品运维一样，存储空间划分主要包括：

基于服务器光纤卡WWN号创建IG、根据规划存储前端口创建PG、结合容量需求创建SG、将以上三者关联创建View。

传统二代产品在创建精简设备时，需要将此设备绑定至某个ThinPool进行使用，而三代产品可以直接指定空间大小创建精简设备，并直接加入SG即可完成映射过程。

与二代产品不同的是，三代产品在ThinPool的基础上，新增了SRP（StorageResourcePool）的概念。

对于三代产品混合阵列而言，其为普通盘Pool及SSDPool进行整合的结果。

而对于三代产品全闪阵列而言，由于磁盘均为单一的闪盘，SRP则由SSDPool构成。

5、数据中心切换

在新同城灾备中心各项工作完成以后，数据中心的切换启用便提上了日程。

前期我们按照规划要求，在新同城灾备中心VMAX950F上完成了重要系统View的创建工作，并使同城之间的数据复制具备条件。

由于同城之间采用同步复制，为了最大程度减少数据复制对生产应用带来的潜在影响，复制开始时我们选择了SRDF/AC（AdaptiveCopy）模式，通过开启磁盘拷贝模式进行数据追数操作，并于业务低峰时段在数据差量小于某个阈值时，将SRDF/AC模式修改为同步模式。

相对而言，异步复制对生产应用的影响较小，可以选择在任意时间段开启SRDF/AC模式进行追数，当数据差异量减小至某个阈值时，即可将SRDF/AC模式修改为异步模式并保证一致性。

五、全闪架构在银行的运维案例

我行计划在三中心采用VMAX950F替换原有VMAX20K，并按照分步替换策略，先对同城灾备中心进行替换，待运行一段时间后再完成生产中心和异地灾备中心的替换工作。

新产品接入我行存储平台，需要运维人员接触一段时间才能对产品特性有更直观的认识，才能逐步积累更为实用的运维经验，所以选择分步替换将有利于为生产及异地端的替换提供更合理的最佳实践。

在采用VMAX950F全闪作为R21角色时，我们在运维中出现过连续几个工作日（2月26至28日）异步复制链路异常断开的情况。

3月1日我们采用了在复制链路两端R21和R2打开DSE功能观察批处理的办法。

3月2日凌晨，R2端出现了由WRITINGPENDING（WP）LIMIT导致的LINKDROP。

经过对比分析，发现在两端打开DSEPOOL发挥磁盘缓冲的作用时，由于R21是全闪阵列，DSE性能可以得到更好地发挥，因此先到达WPLIMIT限制的是R2。

在带宽很紧张的情况下，我们使用DSE作为缓冲策略，但DSE只能帮助度过偶发及短时间的IO高峰。

因此当R21端传输的CYCLESIZE非常大，超过了R2端的WPLIMIT的75%时，将会导致SRDF复制链路的中断。

图5.13月1日同步复制数据传输情况

图5.23月1日异步复制数据传输情况

通过观察图5.1和5.2（注：

时间轴均为UTC）性能数据，我们发现，从R1端接收到的IO吞吐量最高可达600MB/s，而从R21传至R2的数据量最高可达330MB/S,这可能导致R21端的A