jxnxsdengyu
作者jxnxsdengyu2020-11-13 10:06
系统工程师, 江西农信

某银行云模式下存储架构演进及思路分享

字数 5037阅读 7323评论 0赞 6

一、前言

存储是 IT 行业的三大关键技术领域之一,是 IT 系统的感知输入记录和 IT 大脑的思维记忆所在,其基础性和重要性不言而喻。云存储作为将储存资源放到云上供行为对象任意时间、任意地点,只要有网络连接即可存取的技术,依托其便利性和弹性按需的低成本优势伴随着云计算技术一起迅猛发展,势不可挡。在当前数字经济高速发展的背景下,为了实现“数字经济的基础设施”的宏大愿景,存储必须担负起更大的责任,为企业数字化转型提供核心价值,促进基础设施云化、核心技术互联化和应用数据化和智能化的升级。在这个数字经济时代,云存储也在悄然发生巨变,主要体现在以下三个方面:

1 、存储服务网络的巨变。云存储是基于云计算相关技术延伸和发展而来的全新的产品形态。本质上,云计算不是一种计算,而是一种服务,云存储也不是一种存储,而是一种基于存储功能的服务。云存储的内核是应用软件与存储设备相结合,通过应用软件来实现存储设备向存储服务的转变。使用云存储时并不是使用某一个存储设备,而是使用整个云存储网络带来的一种数字化服务。

2 、云原生对云存储的新要求。云原生应用对迁移性、扩展性和动态性的需求,对云原生存储也带来了相应的密度、速度、混合度的要求,因此需要云存储不断提高在效率、弹性、稳定、应用低耦合、安全等方面的能力。首先,云原生存储是面向应用的应用层存储,是云存储在用户接口、效率和易用性等优势的集合;其次,云原生存储利用云存储基础设施红利,是构建在应用存储之上的分层存储;第三,云原生提升了实现效率和自治方面的能力,提升了存储稳定性,降低了安全隐患。

3 、不可或缺的混合云存储。通过混合云 IT 架构无缝上云已成为企业应用的新常态,混合云存储将成为架起本地数据中心和公共云的桥梁,是传统企业客户上云的新路径。从新旧业务的融合到云计算研发的混合部署,都离不开混合云的支持。不同的系统,在不同的时间点所呈现的状态也同样不同,作为一种产品化的解决方案,混合云可以说是公共云、私有云、本地基础设施部署优势的一个结合。云所提供的功能和业务越来越丰富,随着容器等云原生技术的发展,业务的跨云部署也将更加便捷,在权限管理、灵活性、性价比方面表现出更大的优势。

因此,在这样的背景下本文将从 IT 架构的视角,以我行在不同数字化改造阶段,云存储架构演进的过程和思路为例进行梳理和总结,旨在厘清在云存储不断的技术变革下,我行的跟进策略和架构抉择思路,包括烟囱式“云 ” 架构、集中式云存储架构、分布式云存储架构,希望对同行有一定的借鉴和参考价值。

二、烟囱式存储“云 ” 架构阶段

基础设施烟囱式架构,是国内各银行早期数据中心信息系统建设过程中的必然形态。在这个阶段,大多数 IT 建设者们并不太关注基础架构方面的规划及设计,采用何种技术架构,在当时的条件下,并没有那么重要。信息系统的建设重点就是让承载的业务系统稳定运行,服务器、存储和网络设备的核心使命是为业务提供一个良好的运行环境,让业务系统稳定连续性运行即可。我行也不例外,在这个时期,我行的信息系统基础设施的主体建设模式仍然主要停留在“竖井”模式。大部分信息系统都是烟囱式的架构设计,几乎每个重要信息系统都会配置一套独立硬件设备,典型的“标配”方案为两台高端小型机(或 X86 服务器)做数据库服务器,搭建高可用双机环境,然后再加两台或以上应用服务器,后端连接两台 FC 交换机和一台存储设备。该架构的弊端主要表现为:在信息系统间,各应用系统建立在自身独立的资源支撑体系上,存储数据完全是割裂的,导致设备利用率非常低,相互间难以实现资源共享;在信息系统内,各系统内部在开发、测试、生产和备份等层面的资源为相对独立的资源在做支撑,整体资源的流动性和利用率低,内部也无法实现共享;在运维方面,一个故障的处理往往需要多个不同专业领域的人员协同工作,效率容易成为瓶颈;另外,在基础设施资源没有很好规划和合理利用的情况下,这样的架构也会导致数据中心空间、能耗、制冷大规模增加,而且设备数量的随意增加还会严重影响运维和管理的效率。

三、集中式云存储架构阶段

为了有效应对上述烟囱式架构的弊端,我行开展了基于虚拟化技术的系统建设模式变革,也就是所谓的基础设施“资源池式”的建设模式。通过广泛采用各类虚拟化技术,实现计算资源和存储资源的虚拟化,同时构建起对应的虚拟化资源池,提升了整体资源的使用率。虚拟化技术的应用打破了传统竖井式的资源壁垒,应用系统间能够共享各类资源,支持随业务应用压力变化灵活调整资源供应;池化概念的引入把原来“烟囱式”彼此割裂的计算、存储、网络资源在逻辑上整合成为了一台超大规模云计算机。虚拟化资源池为上层软件提供弹性的按需资源供给的能力,从而实现软硬件部署过程与运行态的解耦,屏蔽软硬件异构多厂家差异性与复杂度,并填补计算与存储之间的性能鸿沟;另外,从小规模式的资源堆叠逐步走向大规模资源池构建之后,通过对运维流程的固化、不同专业领域的人员整合等方法,实现了运维管理的统一化和集中化,大大提高了运维效率。

存储虚拟化也正是我行该阶段的技术核心之一,其原理是在物理存储系统和服务器之间增加一个虚拟层,它管理和控制所有存储并对服务器提供存储服务。服务器不直接与存储硬件打交道,存储硬件的增减、调换、分拆、合并对服务器层完全透明。这种架构方式隐藏了不同存储的复杂程度,允许将存储池中的存储通用功能集成使用,摆脱了单个存储物理容量的局限,同时又能提供各种丰富的存储高级功能,包括存储自动分层、快照、容灾、双活、数据迁移、镜像、压缩等等。

我行通过存储虚拟化技术搭建了交易类、管理类和开发测试类三套存储资源池,每套资源池整合了不同厂商、不同型号、不同性能的各类异构存储设备,形成一个兼具的高可用、灵活性、动态化和可扩展性的池化底座,为上层业务系统提供块存储服务,例如数据读写、数据镜像保护、在线数据迁移和切换、存储性能动态分层、数据容灾复制等,该底座也具备一定的扩展能力,例如存储虚拟化节点横向扩展、新增存储节点和扩容存储容量等。另外,存储资源池又能够支持统一的 RESTFull API 标准接口对接上层的云计算管理平台或者容器云平台,屏蔽了异构存储的差异性,利用编排引擎实现存储、计算、网络、运维等集成式服务,利用云管实现业务对数据“存储 - 使用 - 管理”的全生命周期支撑能力,通过“应用软件 + 存储资源池”的方式达到存储设备向存储服务转变的目标,全面开启计算、存储等基础设施云化的新征程。

这个阶段,我行将其命名为集中式云存储架构阶段,存储设备虚拟化技术究其本质仍然具有集中化特质,扩展也存在局限性。一方面,存储虚拟化设备虽然兼容性好,能够整合多套存储,自身节点也有一定的扩展能力,但终究存在容量和性能扩展性瓶颈,整个存储池无法提供 PB 到甚至 EB 级的云存储能力。在容量受到限制的情况下,整个存储池的吞吐量也受到限制,通常而言,需要把连续的信息分片存储于多个存储设备以增加吞吐量和性能。但存储虚拟化天然不适用于跨存储的连续数据分布,存储卷所对应的存储按照标准需尽量在同一存储内部打散,而不是多存储打散。这种传统集中式的思路,也正是造成局限性的根因,极大影响了存储池的整体性能和伸缩性;另一方面,在如今的互联网时代,数据存取手段纷繁复杂,形态五花八门,半结构化与非结构化数据体量日趋增大,集中化的存储架构显现出自身的固有局限。存储虚拟化后的存储池只能提供块存储服务,无法同时提供对象、块、和文件存储服务,这些服务在业务互联化的今天,全都是必需品。这就要求云存储系统必须能够提供多样的存储服务,包括块设备服务来满足数据库类型的存储要求。文件系统、对象等存储服务来满足半结构化数据和非结构化数据的存储要求。因此,这就要求云存储能够提供丰富的标准接口,包括文件系统接口( NFS 、 CIFS )、块接口( iSCIS 、 FC )或者对象接口( S3 、 SWIFT )以及对内能够提供标准的管理接口。

四、分布式云存储架构阶段

由于集中式云存储架构的上述局限性,我行积极开展了第二代云存储架构探索与实践,通过利用大量标准化机器的存储资源聚合构造一个海量存储池,结合我行的原生云计算架构体系进行分布式云存储系统建设。该云存储系统是我行未来数据存储的基石性系统,其上承载了一系列的云存储服务,为业务系统提供大规模、高可用、高吞吐量和良好扩展性的存储服务。

  • 大规模:目前单集群达到数百台规模,支持数十 PB 量级的存储大小,总文件数量达到亿量级;
  • 数据高可靠性:保证数据和元数据是持久保存并能够正确访问的,保证所有数据存储在处于不同机架的多个节点上面(通常设置为 3 )。即使集群中的部分节点出现硬件和软件故障,系统能够检测到故障并自动进行数据的备份和迁移,保证数据的安全存在;
  • 服务高可用性:保证业务能够不中断地访问数据,降低系统的不可服务时间。即使出现软硬件的故障、异常和系统升级等情况,服务仍可正常访问;
  • 高吞吐量:运行时系统 I/O 吞吐量能够随机器规模线性增长,保证响应时间;
  • 高可扩展性:保证系统的容量能够通过增加机器的方式得到自动扩展,下线机器存储的数据能够自动迁移到新加入的节点上。

在上层的云存储服务中,既有要求高吞吐量,期待 I/O 能力随集群规模线性增长的“开放存储”;又有要求低时延的“弹性计算”,作为底层平台核心的云存储必须二者兼顾,同时具备高吞吐量和低时延。并且在线应用对云存储也提出了与离线应用不同的挑战:对象存储和表格存储服务要求低时延数据读写,弹性块存储和文件存储服务在要求低时延的同时还需要具备随机写的能力。针对这些需求,云存储实现了事务日志文件和随机访问文件,用以支撑在线应用。其中,日志文件通过多种方法对时延进行了优化,包括设置更高的优先级、由客户端直接写多份拷贝而不是用传统的流水线方式、写入成功,不经过 Master 确认等。随机访问文件则允许用户随机读写,同时也应用了类似日志文件的时延优化技术。我行的云存储系统架构如下图所示:

在我行云存储系统中,文件系统的元数据存储在多个主服务器( Master )上,文件内容存储在大量的块服务器( Chunk Server )上。客户端程序在使用云存储时,首先从主服务器获取元数据信息(包括接下来与哪些块服务器交互),然后在块服务器上直接进行数据操作。由于元数据信息很小,大量的数据交互是客户端直接与块服务器进行的,因此云存储采用了少量的主服务器来管理元数据,并使用 Paxos 协议保证元数据的一致性。通常配置为 5 个实例,可以同时容忍两台机器出故障,保证了高可用和快速切换的能力,减少了外部的依赖,做到了独立自包含,在保障高稳定性和高性能前提下能够容忍复杂故障。此外,块大小被设置为 64MB ,进一步减少了元数据的大小,因此可以将元数据全部放到内存里,从而使得主服务器能够处理大量的并发请求。块服务器负责管理存储空间和数据读写,支持分级存储,针对不同的存储介质如 NVMe SSD 、 SATA SDD 、 HDD 等,根据相关配置的策略,把数据写入对应的存储介质,同时支持基于策略的迁移。比如说在混合存储云盘,数据先写入来自三台不同机器的 SSD 盘后就返回,后台异步地将数据迁移到 HDD 盘;其次,块服务器采用了一系列技术来提供稳定的性能,例如服务分级(能够对请求队列和网络流量设定不同的优先级)、管理后台活动、热点负载平衡、增加副本来应对重度使用的数据、缓冲加速、备份请求来规避慢盘等。这些技术的本质目标就是基于无法预估的资源来打造可以预测的整体,提供稳定的性能。数据高可靠性方面,在在向文件写入数据之前,客户端将建立到 3 个块服务器的连接,客户向主副本写入数据以后,由主副本负责向其他副本发送数据。与直接由客户端向三个副本写入数据相比,这样可以减少客户端的网络带宽使用。块副本在放置的时候,为保证数据可用性和最大化地使用网络带宽,会将副本放置在不同机架上,并优先考虑磁盘利用率低的机器。当硬件故障或数据不可用造成数据块的副本数目达不到 3 份的时候,数据块会被重新复制。为保证数据的完整性,每块数据在写入时会同时计算一个校验值,与数据同时写入磁盘。当读取数据块的时候,块服务器会再次计算校验值与之前存入的值是否相同,如果不同就说明数据出现了错误,需要从其他副本重新读取数据。

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

6

添加新评论0 条评论

Ctrl+Enter 发表

本文隶属于专栏

作者其他文章

相关文章

相关问题

相关资料

X社区推广