开启辅助访问

超融合+云计算论坛

 找回密码
 立即注册

QQ登录

只需一步,快速开始

证券公司基于分布式存储技术的系统连续性优化探索

2017-3-31 20:24| 发布者: 渝粤| 查看: 1803| 评论: 1|原作者: 邬晓磊、万寅桦

摘要: 1 概述1.1 证券期货业对云计算的需求2011年,证券期货业的创新概念不断涌现。2012年创新大会之后,新型营业部、轻型营业部、非现场开户等创新模式陆续得到监管部门认可和批准。业务创新对证券公司的IT提出了新的要求 ...
1 概述

1.1 证券期货业对云计算的需求

       2011年,证券期货业的创新概念不断涌现。2012年创新大会之后,新型营业部、轻型营业部、非现场开户等创新模式陆续得到监管部门认可和批准。
       业务创新对证券公司的IT提出了新的要求,例如业务互联网化、分支机构轻型化、快速部署、弹性扩容等等。因此越来越多的证券公司顺应发展趋势,开始尝试虚拟化和云计算,并将部分应用系统迁移到云计算架构中。

1.2 云计算面临的业务连续性风险

       云计算技术的使用使企业的IT资源进一步集中,有效的降低了各分支机构的建设速度和维护成本。但是在云计算技术带来这些好处的同时,也带来了新的风险。IT资源和数据的集中化,系统虚拟化使企业在面对业务连续性问题,遇到了传统IT架构所没有的新问题,一定程度上可能带来更高的风险。
       在这些控制点中,从更细的方面来看,采用云计算架构后,存储系统将面临非常严峻的挑战。和传统架构相比,由于云计算架构中大量的虚拟系统和数据集中存储,一旦存储系统出现故障,会影响大量的虚拟主机和应用系统。另外,云计算环境中存储系统的I/O也可能会成为系统的瓶颈。

2 云计算中传统集中式存储的不足

2.1 集中式存储系统的可用性风险

       虚拟化是云计算的技术基础中重要的一环,它能有效地增加物理服务器的资源利用率,降低运营成本,减少维护和提高IT实施的弹性。但是随之而来,是风险高度集中化,对于证券行业来说,单节点出现故障造成大量业务系统中断是不可接受的。如何在高效便捷和低风险中寻找平衡点,将RTO和RPO控制在合理范围之内,也是云计算安全的重要一环。

       上图是典型的虚拟化平台底层硬件架构平台,从图中可以看到这样的架构体系有一定的冗余机制,但并不完善,主要从如下几点作分析:
       1) 存储单点故障风险:这是整个基础架构中最重要的一环,但往往由于设备较为昂贵,且存储的健壮性较高,因此一般架构都使用一台共享存储。在极端情况下,存储不可用将导致整个平台崩溃。
       2) 主机故障导致应用中断:目前主机间会配置HA,确保某台主机不可用时其上运行的虚拟机能迁移至其他主机进行托管,但在迁移过程中,虚拟机将会经历一次重启,若无服务自启动脚本,整个应用将会中断。

2.2 集中式存储系统的I/O问题

       虚拟机技术给服务器带来更高的利用率、给业务带来更便捷的部署,降低了TCO,因而在众多行业得到了广泛的应用。与此同时,虚拟机应用给存储带来以下挑战:
       1) 相比传统的物理服务器方式,单个存储系统承载了更多的业务,存储系统需要更强劲的性能来支撑;
       2) 采用共享存储方式部署虚拟机,单个卷上可能承载几十或上百的虚拟机,导致卷IO呈现更多的随机特征,这对传统的Cache技术提出挑战;
       3) 单个卷承载多个虚拟机业务,要求存储系统具备协调虚拟机访问竞争,保证对QoS要求高的虚拟机获取到资源实现性能目标;
       4) 单个卷上承载较多的虚拟机,需要卷具有很高的IO性能,这对传统受限于固定硬盘的RAID技术提出挑战;

2.3 集中式存储系统的扩展能力

       集中存储系统的另一个问题是扩展能力的不足。当然在传统的集中式存储系统使用过程中,如果出现容量不足的情况下,有可能可以选择进行Scale up(纵向扩展)。但是这存在一个问题:
       1) 这种纵向扩展是有上限,无法支持今后未知的大规模数据;
       2) 这种纵向扩展比较复杂,需要专业的技术人员进行操作,且部署过程较慢;
       3) 这种纵向扩展的代价会变的非常高;
       更好的解决方案是Scale out(横向扩展),即通过多台计算机来实现分布式存储,把数据分散到多台机器上存储。这就是将要介绍的分布式存储技术。

3 分布式存储系统设计思路

       针对云计算环境中集中式存储系统存在的这些风险点和不足,越来越多的企业开始采用分布式存储技术来降低风险、提高性能,同时让系统具备良好的扩展能力。
       分布式存储系统的基本思路是通过将数据把数据分散到多台机器上存储,同时能够兼顾性能、扩展性、可靠性、以及可用性等问题。

3.1 数据访问

       分布式存储对用户应该是透明的,即分布式存储系统对用户来说是一个整体。当应用程序需要对数据读写该如何进行呢?简单来说是使用一台(或多台)服务器记录各个数据的位置信息,然后当程序需要数据的时候,先到服务器这儿来查找数据在哪儿,得到位置信息后,然后程序再到相应位置去读或者修改数据。以Google的GFS为例。Google的主节点叫master,存储数据的节点叫chunkserver。主节点上保存了整个分布式存储的结构和元数据,数据节点上则保存着大量的数据。

3.2 节点失效

       首节点失效将被看成是正常情况,而不再视为异常情况。分布式系统一般由较廉价的普通机器组成。这些节点的质量和数量都实际上都决定了节点失效的可能性较高。因此,持续监视,错误检测,容错处理,自动恢复必须集成到这个文件系统的设计中来。
       解决失效的问题就是数据冗余,即对数据做多个备份。在GFS中每一个文件都拆成固定大小的块。每一个块都由主节点根据块创建的时间产生一个全局唯一的以后不会改变的标志。数据节点在本地磁盘上用 Linux文件系统保存这些块和读写这些块的数据。在GFS中可以通过配置文件设置备份的数量,默认为3,也业界一般认为较为可靠的备份数目;
       数据节点失效是由主节点来进行的,称为心跳检测,也就是主节点周期性的去检测数据节点的有效性,如果检测不到心跳,主节点就去寻找新的节点替代,然后将数据重新分布到其他节点上。主节点除了上述功能外,还负责整个集群的负载均衡。

3.3 一致性

       在GFS中,当对数据进行更新时,仅当3个备份的数据都更新成功时,才认为数据保存成功。GFS上存储的数据块副本,在物理上以一个本地的Linux操作系统的文件形式存储,每一个数据块再划分为64KB的子块,每个子快有一个32位的校验和,读数据时会检查校验和以保证使用的不是失效的数据,另外在主节点上存有每个数据块的校验和,GFS客户端在读取完数据之后会将所读取的数据块的校验与主节点上的校验和进行对比,以验证数据的有效性。

3.4 扩展性

       良好的扩展性是分布式存储系统希望解决的问题。在分布式存储系统中当存储容量不够时,直接增加新的节点就可以。当加入一个新的数据节点时,新节点会向主节点发送一个信息,主节点会给新增加的节点分配一个ID,并可以选择进行数据重分布。

4 实际应用和效益

       目前市场上有很多开源的分布式存储系统。开源软件虽然使用中没有软件采购成本,但是在部署、使用和运维中,对运维团队的技术能力、团队规模都有比较高的要求。
       除了开源系统外,目前市场上还有商业化的系统。在分布式存储系统实际应用的过程中,我们考虑了综合成本和风险后,将目光集中在商业化系统上。经过严格的测试,最终选择了某品牌的分布式存储和融合计算系统(以下简称A系统)用于我公司的云计算虚拟化应用场景。

4.1 系统简要介绍

       A系统是计算和存储一体的融合式架构解决方案,通过A系统虚拟计算平台将本地存储资源整合为一个统一的分布式平台并提供虚拟化环境使用。
       A系统的解决方案是通过绑定软硬件一体的方式,在一个机箱中整合了2个节点或者4个节点。每个节点上都运行标准的虚拟化平台软件(VMware vSphere、KVM、Hyper-V)和一个A系统控制虚拟机(Controller VM,简称CVM)。CVM是一个运行A系统分布式集群软件的虚拟机,并且为本地虚拟化平台软件和其上所有虚拟机提供IO操作服务。CVM通过Hypervisor提供的Passthrough功能管理节点本地所有磁盘。
       多个A系统节点可以组成一个统一的分布式平台,成为A系统分布式文件系统(NDFS)。虚拟化软件将NDFS作为一个集中存储进行管理,所有的IO操作都将由本地节点上的A系统 CVM接管,以提供更好的性能。
       下图显示的是A系统分布式系统逻辑示意图:

       元数据(Metadata)是一个文件系统的核心,甚至是至关重要的。在NDFS中,使用了一些关键技术来确保:数据在100%时间内都是可用的(即“强一致性”),并且保证NDFS扩展到超大规模数据量时依然可靠。NDFS使用一种“环状”的Key-Value结构的分布式数据库来保存元数据。为了确保元数据的可用性和冗余度,也同样引入了复制因子(RF)。
       一旦一条Metadata记录被写或者更新后,这条记录将同时写到“环”中的另一个节点,然后被复制到n个其他节点(n决定与集群的大小)。集群中大多数(majority)节点必须同意才能commit一条记录,这就是强一致性的Paxos 算法。这确保了A系统平台数据的“强一致性”。
       下图显示了在一个4节点集群中,元数据的插入和更新操作:

       对于NDFS的元数据数据库,扩展性也是至关重要的。与传统的“双控”和主备模式不同,每个A系统节点只负责整个集群元数据中的一部分。这种方式消除了传统的瓶颈问题,并且允许元数据被集群中所有节点共同维护。并且使用“一致性散列算法(Consistent Hashing )”来保证当节点数量变化时,需要被remapping的元数据量最少。
       当节点数量从4增加到8个时,新节点将被插入到环中各个老节点之间,使用类似的block感知能力提供可靠性,下图显示了环被扩展时的情况:

4.2 测试和应用情况

       在测试阶段,我们对该系统进行了如下测试:
       1) I/O能力基准测试
       2) 虚拟化软件功能验证
       3) 系统的可靠性测试
       4) 实际应用测试
       通过系统稳定性测试和应用测试,我们认为该系统技术较为成熟,能够满足证券网上交易、互联网金融以及其他一些券商应用系统的使用需求。
       目前,该系统应用于我公司“东方云”云平台以及IDC服务器虚拟化场景,分别部署于我公司主机房及IDC机房。我公司的云计算架构从较传统的集中式存储方式,逐渐演变为计算存储融合的分布式架构,提高系统的整体可用性,并降低系统的综合使用成本。

4.3 特性和效益

       我们认为该系统为东方证券带来了以下良好的特性:

  • 更高的性能
    • 在一个2U4节点的集群中可提供85866/39881的读/写IOPS,提供3374Mbps/1545Mbps的读/写带宽
    • 使用一个2U4节点的设备可以替代现有30-40台服务器的计算和存储资源。
  • 空间优势
    • 一个2U4节点的设备可以替代现有30-40台服务器,极大提高了客户数据中心的空间利用率,降低了机房空间成本。
  • 省电优势
    • 2U空间内4台刀片设备,最大功耗却只有1450瓦,耗电量只有相同计算和存储能力传统模式下设备功耗的1/9。因此,后期运营的成本将大大降低。
  • 高可用性
    • 分布式文件系统是一个高度可用的横向扩展型系统,不存在单点故障问题。通过分布式文件系统,数据分别存储于节点内的各个硬盘以提高性能,并在集群范围内进行复制以便提高其可用性。因此,即使硬盘或整个节点出现故障,也能够保证虚拟机可用。
  • 易于管理部署
    • 易于部署,该集群是一种即插即用的解决方案,其中含有运行大量虚拟服务器或虚拟桌面所需的全部硬件和软件。管理员能够在十几分钟时间内将其设置完毕,并开始创建虚拟机。
    • 面向虚拟化环境的跨平台基础架构,无论客户选择哪种主流虚拟化软件亦或是混合环境,都能够给予业界独有的具有相同功能和性能的支撑和保障。真正做到下一代数据中心所需要的软件定义原则。
  • 高扩展性
    • 新增节点可以在几分钟内部署完毕加入集群。实现按需购买和使用。
    • 横向扩展型融合存储架构无须管理复杂的网络存储基础设施,可轻松管理任意规模的虚拟环境。
    • 打破传统架构铲车式的升级弊端,前期型号设备都能够无缝整合到现有体系架构中,做到类似Google等互联网超级数据中心一样的Scale-out扩展能力,极大保护了现有的设备投资。
5 总结

       通过对分布式存储技术和系统的学习、研究、测试和部署应用,优化了本文开头所提到的云计算中传统集中式存储架构所存在的不足和风险点。
       1. 通过分布式、多份复制的存储方式,提高了系统的可用性。
       2. 通过本地化融合计算,SSD、HDD多级存储,优化了存储系统的I/O。
       3. 通过分布式架构的特性和数据重分布功能,使系统具备横向扩展能力,提高系统可扩展性。
       但是,虽然分布式存储技术拥有以上诸多优点,如今在互联网企业中也使用较为广泛,但该技术仍处于高速发展阶段,在证券公司中仍然属于较新的技术。其在解决原有问题的同时,也会带来一些新在问题或风险点。我们在实际应用中也将进一步验证其技术成熟度,使其更好的为证券公司技术创新服务。

作者简介

       1. 邬晓磊,东方证券系统运行总部信息安全总监,CISSP、CISP、CISA。
       2. 万寅桦,东方证券系统运行总部系统高级工程师,RHCE。

参考文献

[1] 证券期货业信息系统安全等级保护基本要求
[2] 证券期货业信息系统安全等级保护测评要求
[3] Nancy Lynch and Seth Gilbert, “Brewer's conjecture and the feasibility of consistent, available, partition-tolerant web services”, ACM SIGACT News, Volume 33 Issue 2 (2002), pg. 51-59.
[4] “Brewer's CAP Theorem”, julianbrowne.com, Retrieved 02-Mar-2010
[5] CAP理论十二年回顾:"规则"变了
[6] “Brewers CAP theorem on distributed systems”, royans.net
[7] The Google File System, Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung

1

鲜花

握手

雷人

路过

鸡蛋

刚表态过的朋友 (1 人)

发表评论

最新评论

引用 andy_521 2017-11-30 11:20
请问,解决原有问题的同时,也会带来一些新在问题或风险点;那么验证下来问题和风险点真的存在吗?

查看全部评论(1)

返回顶部微信扫一