单位:南京莱斯信息技术股份有限公司省市:江苏省南京市邮编:210000
摘 要 当前,“十四五”中数字政务的信息化规划正在紧锣密鼓的进行顶层设计,很多城市正在进行基于新基建的最新一代智慧城市数据中心底座的设计与建设。随着科技及信息化的发展,数据存储设备是政务大数据中心中最为核心的硬件资源,是整个大数据中心中的数据基石。随着近几年政务大数据中心规模的不断扩大。数据存储设备在扩容、升级、更新换代、乃至存储架构的更新是政务信息化工作内容中重要的一环。
关键词:集中式存储 分布式存储
一、存储架构设计背景
本文旨在通过对政务大数据中心现有数据的特点、容量及业务需求进行分析,结合目前主流的存储技术,为政务大数据中心存储的架构厘清思路,并结合以往实际工作经验做出优解的选型策略。
二、存储架构需求分析
在政务大数据中心建设过程中,要制定一套存储指标度量体系,要对存储使用的需求进行充分分析,提取出必要技术指标项和可选的技术指标项,基本包括以下几个方面。
2.1、业务需求分析
从政务业务层面的需求来看,应用系统层面必须实现对象化和服务化的松耦合模式,从而更好的应对政务大数据中心业务模式的快速变化和迭代要求。同样,应用系统需要数据存储的支撑,这对基础架构层的数据处理同样提出了高度灵活性的要求。主要包括:
1)针对不同时间和空间内的数据量级的变化需要有适应能力;
2)针对不同业务模式的读写特征(顺序读写和随机读写等)需要有适应能力;
3)针对不同的政务业务模式的性能具备细分适应能力。
政务业务系统中各个委办局的相关核心系统,这些系统中不乏有对数据处理的性能要求比较苛刻的,所以针对政务业务必须采取不同的存储性能应对策略。不同业务模式对数据读写性能的细分和更高指标要求,这就必然带来底层数据处理平台的松散化、低耦合以及细分化的变革。
政务业务系统中各委办局的核心系统对数据的安全要求较高。随着政务互联网业务模式的不断出新,业务的不断变革,数据大底座以及数据中台的不断发展创新,数据在不同系统之间以及私有云化资源池当中的数据交换的速度、量级都发生了巨大的变化。
2.2、功能需求分析
2.2.1、产品的架构
当前存储架构包括:集中式和分布式存储架构等。对于存储架构的选型,我们需要结合应用特点进行考虑。对于高吞吐量的敏感核心数据或者其他重要的核心系统,选择高IO、低时延的集中式高端存储更为合适。对于数据空间要求较大,但业务存储性能要求并不特别明显的业务系统,分布式存储多副本的安全性和性能,能够提供最优性价比。
2.2.2、稳定性需求
政务大数据中心内部的业务系统大部分为民生业务数据,数据存储架构的稳定性和可靠性是存储选型最基本、最重要的需求,包括:
1、冗余度:各个部件均为冗余设计、支持热插拔,任意部件损坏不影响上层业务运行;
2、可维护性:各部件维修和更换能够在线操作,能在线进行微码升级,不影响上层业务。
2.2.3、可扩展性需求
存储设备须有灵活的体系架构,能够随着性能和容量需求进行在线扩容,集中式存储的扩容应能够完成控制器、控制器缓存以及磁盘的扩容,而分布式存储的扩容应能够完成当前存储节点纵向的磁盘扩容、IO接口扩容以及节点数量的横向扩容。扩容后,分布式存储能够根据节点数量自动完成数据转移及数据平衡,保证整个分布式存储的数据层不会出现木桶效应。
2.2.4、数据灾备需求
政务大数据中心的数据均为民生数据,存储架构的容灾能力应能够支持本地双活以及两地三中心架构甚至是三地务中心的架构,通过双活仲裁机制保证在常见故障的场景下,满足业务连续性和数据零丢失。
三、存储落地实施实践
3.1、产品架构选择
对于存储产品的架构选择,如果政务应用有特定的分布式文件存储、对象存储或者海量数据存储需不断扩展的需求,比如音视频、文件等结构化数据存储需求,同时对存储稳定性和时延要求不高的,可以选择分布式存储或者低端集中式存储。对于政务系统中关键核心系统,比如税务、医保、社保等生产系统,包括核心系统、前置系统等多种应用,那么具有高稳定性、高吞吐量和低时延,可实现多存储双活等特性的集中式存储则是更优选择。
政务大数据中心在集中式存储本身的产品架构选型时需要考虑:
(1)高端存储架构是各控制器工作在对称A-A模式并稳定运行。
(2)端到端的NVMe技术架构。端到端NVMe技术架构目前被认为是数据存储的趋势。通过NVMe-oF技术(通过网络结构将主机连接到存储),实现存储设备与前端服务器连接的通道,NVMe-oF可以实现NVMe标准在多种网络上的扩展,并且取代了以往的FC-SAN、iSCSI等协议,降低存储网络协议的处理开销。前端主机可以使用本机NVMe协议直接与NVMe硬盘进行数据交换通信,从而可以进一步提升性能和降低时延。
3.2、产品的稳定性
对于稳定性需遵从:第一,集中式存储系统要具备全冗余技术架构,不存在单点故障,所有部件均为冗余模式,在多个控制器情况下,可以做到N-1控制器故障后仍能提供数据存取服务。所有核心部件微码均可以完成在线升级,对业务访问无影响。第二,分布式存储,应可以做到通过EC纠删码或者数据多副本技术以便保证实现N+2级别以上的冗余机制。
3.3、数据灾备能力
目前政务大数据中心多采用两地三中心模式建设,其主中心与备中心一般为同城,采用运营商裸光纤或者OTN互联。那么集中式存储可以通过免网关双活架构、数据同步和异步复制功能等将主中心数据复制到灾备中心实现双活。分布式存储可以通过双中心大二层VxLAN技术,将存储节点通过网络方式部署于双中心,实现数据两地多副本保存。
3.4、性能指标参考
那么,结合以往项目经验,我们对现有存储架构进行了性能测试,如下表:
测试项 | 集中式存储 | 分布式存储 | 分布式存储 | 分布式存储 |
随机寻道4KB | 28978 IOPS | 3481 IOPS | 6004 IOPS | 8673 IOPS |
随机寻道64KB | 32044 IOPS | 3209 IOPS | 5169 IOPS | 6882 IOPS |
突发速率 | 5202 IOPS | 14396 IOPS | 23492 IOPS | 22650 IOPS |
4KB 写入 | 19.7 MB/s | 14 MB/s | 17.4 MB/s | 12 MB/s |
4KB 读取 | 66 MB/s | 201 MB/s | 310.7 MB/s | 315 MB/s |
32K 写入 | 106 MB/s | 103 MB/s | 117 MB/s | 85 MB/s |
32K 读取 | 228 MB/s | 1.24 GB/s | 1.79 MB/s | 1.88 GB/s |
4MB 写入 | 1.48 GB/s | 484 MB/s | 912 MB/s | 390 MB/s |
4MB 读取 | 1.41 GB/s | 2.99 GB/s | 4.54 GB/s | 4.38 GB/s |
16MB 写入 | 1.44 GB/s | 408 MB/s | 950 MB/s | 388 MB/s |
16MB 读取 | 1.36 GB/s | 2.84 GB/s | 3.84 GB/s | 4.51 GB/s |
64MB 写入 | 1.47 GB/s | 267 MB/s | 872 MB/s | 342 MB/s |
64MB 读取 | 1.35 GB/s | 2.23 GB/s | 3.36 MB/s | 3.40 GB/s |
从上面的表中,我们可以看到,在随机数据读取中,集中式存储具有更为优秀的IOPS性能,同时在4K,32K以及16M等读写上,其速率比较平稳。在分布式存储中,全闪存架构的读性能最为优秀,写性能受到节点数的影响,节点越多,写入性能约好。从整体造价上来看,集中式存储>全闪存分布式存储>混合分布式存储>全机械盘分布式存储。
3.5、存储选型策略
政务大数据中心业务包括:
1)经办类:传统B/S三层架构为核心的业务,业务量从小型一直到大型,既有并发量几十的小型应用,也有并发量超过1000以上的大型应用(比如社保、医保等);
2)智慧类:智慧水务、智慧停车、智慧旅游等一大批惠民类智慧应用为核心业务,这些业务虽然扔采用B/S架构,但需要多个数据源的数据抽取、处理等,数据交互比较复杂,大部分采用微服务架构部署。
所以根据多年运行维护经验,我们认为:
1)全机械盘集中式存储适用于各种场合,其中对于轻度OLTP数据库,普通Web应用数据存储等具有足够的支撑能力,以及私有云环境;
2)具备数据分层或者全闪存的集中式存储,适用于中、重度的OLTP类应用以及对IO时延响应要求较为苛刻的内存数据库、以及私有云环境;
3)全机械盘分布式存储或混合模式分布式存储,适用于私有云环境,适合可拆分集群类业务,轻度OLTP数据库,视频监控等高扩展性高容量场景;
4)全闪存分布式存储适用于私有云环境,适合中、重度OLTP类应用、对IO时延响应要求较为苛刻的内存数据库等以及其他类型数据(中、重度小碎片随机读写数据);
5)对象存储或者NAS存储适用于与应用结合的结构化数据存储。
四、存储选型技术总结
政务大数据中心的存储架构作为目前数字政务数据大底座基础架构中最核心的元素,始终是数据存取的载体,因此存储设备的选型必然会受到上层应用层面的业务模型变化的影响。那么,我们选型的基本思路也要遵循从上至下的基本原则,在选型过程中,必须通盘考虑,针对业务模型的特点做出详细的分析,明确性能以及功能的要求,根据投资预算,选择相对应适合的存储系统,不但能够最大化保障政务大数据中心业务的业务连续性,同时也可以最大化的提升政务大数据中心数据存储的安全性及可靠性,并大大降低政务财政预算的支出,降低政务大数据中心的TCO。
参考文献
[1] 吴晨涛 信息存储与IT管理[M] 人民邮电出版社