一文读懂分布式存储架构及金融应用
Posted 匠心独运维妙维效
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了一文读懂分布式存储架构及金融应用相关的知识，希望对你有一定的参考价值。
分布式理论的起源，可能要追溯到上世纪70年代。然而，分布式系统被广泛应用却是最近十年的事情，为何这项技术的发展推迟了这么久？除了技术本身的局限性外，还有一个重要原因就是现代社会发展创造出的数据量已经远远超过了单个计算机系统的处理和存储能力。那么，在分布式系统中，如何通过高效的手段来实现对海量数据的存储同样是人们重点关注的问题，这便是本文要讨论的分布式存储领域。
在一个环境当中，有很多的服务器，上面配有很多块硬盘。然后通过软件的形式把若干服务器资源都收集起来，在这个逻辑的软件里可以同时看到若干服务器的磁盘空间，这个逻辑的软件对外就像是一个整体，是一个存储池。用户有一天需要用这个空间了，可以直接去找这个存储池提供的接口。这样的话，用户保存一个文件，实际上是保存在若干个服务器里，文件会随机存到一个服务器的某一块硬盘里，下一次就可能存到另一个服务器的某一块硬盘里。以此类推，它会把文件进行打散，分成不同的小块，每块存放的位置可能是不同的服务器上的不同硬盘，这便是分布式存储的理念。
集中式：由一台或多台设备组成中心节点，数据集中存储于这个中心节点中，并且整个系统的所有业务单元都集中部署在这个中心节点上。集中式是一直以来普遍应用的传统架构，由于IO路径短、性能较高且技术成熟，一般应用于对IO延时要求严格的核心业务场景，这项优势在目前技术条件下是无可替代的。但缺点就是核心部件集中，冗余性和扩展能力较差。
图一：集中式存储架构
分布式：将数据分散存储在多台独立的设备上，采用可扩展的系统结构，利用多台存储服务器分担存储负载，利用位置服务器定位存储信息。节点间采用万兆网络，对硬件无特殊要求，成本较低，扩展能力强。同时可以灵活配置故障与副本策略，拥有自动重平衡能力。但延迟高、数据一致性问题也是其缺点和难点所在。
图二：分布式存储架构
关于数据一致性问题，想象一个最简单的存储场景：只有一个客户端和一个服务端。客户端顺序发起读写操作，服务端也顺序处理每个请求，那么无论从服务器视角还是从客户端视角，每一个操作都可以看到前一个操作的结果。然后，让环境变的复杂一些，还是单个服务进程，但是有多个客户端并发进行操作。这个模型下，多个客户端的操作会互相影响，比如一个客户端会读到不是自己写的数据（另一个客户端写入的）。进而，系统向另外一个方向变的复杂一些，为了让后端存储系统更丰富，我们可以让两个不同的服务进程（位于不同的设备上）同时存储同一份数据的拷贝。最后，通过某种同步机制让这两个拷贝的数据保持一致。这就是我们所说的“多副本”。多副本带来了数据的可靠性，同时也带来了一致性方面的问题。
以开源存储Ceph为例，它是一种集性能、可靠性和可扩展性多项优势的分布式存储系统。它可以提供块存储、文件系统和对象存储。在Ceph的三副本冗余方式中，数据写入请求最终是要发送给三个副本，不过这三个副本建立了一种“一主两从”的主从关系。数据在三个副本节点上写入的时候，都会先以直写方式写入本地Journal，然后再以非直写的方式写入数据盘。这样就在一定程度上保证了副本间的数据一致性。在发生异常时，通常会出现以下三种情况。
情况一：在IO过程中，主副本在规定的时间内没有收到副本应答，那么主OSD（ObjectStorageDevice）会先发起heartbeat。确认副本失联后，主OSD会将副本down的信息同步给MON，而后主OSD会发起Peering。在peering前，主OSD会将未完成的IO请求requeue，副本选好后，主OSD会重新发起IO。
情况二：在IO过程中，主副本失效，其他副本也会检测到主副本down，然后会发起peering，将某个副本临时选为主副本并提交requeueIO请求，然后重新发起IO。
情况三：在发送IO请求前主OSD失效，那么等peering完成后，客户端会重新获取OSDMap，再次发送请求。
图三：Ceph-Rados架构
目前，应用较为广泛的分布式存储当属分布式对象存储。常见的对象存储有Ceph的RADOS、Openstack的swift、AWS的S3等。对象存储采用扁平的组织方式，支持restful的访问接口。
图四：对象存储架构
G行的影像存储业务，为典型的非结构化数据存储平台。由于业务发展、容量需求、成本考虑及技术更新等因素，经过全面调研，筛选成熟的架构改造方案，由之前的传统的集中式存储模式，成功部署到分布式对象存储架构。该套系统硬件部署实施单中心8节点，采用纠删码容错机制，配比为6+2，允许单中心最多同时两个节点故障，不影响业务数据读取。通过双活数据同步，双机房间采用镜像副本模式，每个数据中心都有一份数据副本，单中心故障时数据仍有一份完整备份。
纠删码容错技术的理念就是将丢失的数据算回来。当冗余级别为n+m时，从n个源数据块中计算出m个的校验块，将这n+m个数据块分别存放在n+m个硬盘上，就能容忍任意m个硬盘故障；硬盘故障时，只需任意选取n个正常的数据块就能计算得到所有的源数据。如果将n+m个数据块分散在不同的存储节点上，那么就能容忍m个节点故障。
图五：纠删码
相较于多副本模式，以上述6块数据盘的环境为例，6+2的纠删码的开销只有8块，但三副本模式存储开销为6*3=18块盘。所以，纠删码能够以较低的存储空间为代价获得相似的可靠性，减少硬件、运维管理成本。并且，由于纠删码编码速度在近年得到迅猛提升，纠删码容错技术是一种性价比很高的选择。
新的分布式对象存储架构，实现了分布式资源、存储的弹性扩展，很大程度上减小了容量的压力并有效的节约了成本的投入。运行效率上，大大降低了存取对象的时延，提高检索效率，提升业务水平。
虽然对象存储架构有着高性能、高可靠性的特性，成本较传统架构也很有优势，但作为相对新型架构在稳定性，性能要求上仍需充分测试。随着对象存储技术的发展和完善，设备微码的优化和更新，运维人员的技术水平也需不断提高。
当下是金融科技信息化迅猛发展的时代，存储系统的可靠性、安全性是银行存储系统的底线。对分布式存储的选择我认为应该从两大维度考量：
1、业务运行维度
（1）运行环境：在这个虚拟化、云平台、容器已在各家银行发展运行的相当成熟的环境下，分布式存储更应具备良好的兼容性。即一方面能够满足稳定的传统业务，另一方面还能够支持灵活的创新业务。
（2）性能水平：信息的爆炸性增长给存储容量、性能也带来了巨大的挑战。分布式存储虽然可以实现性能伴随容量增长而增长，但是同样需要智能缓存、全闪盘等技术的加持。
（3）服务能力：银行业务正在不断深入客户的业务场景从而提升服务能力。这就需要存储不仅能够提供标准的块、文件、对象服务，还能够兼备多种数据处理和服务能力，例如检索服务、大数据服务、备份服务等。
2. 运维管理维度
（1）可用性：存储应能够长期满足性能要求。目前普遍的存储使用方式通常建设为存储池，即一套存储同时给多个业务系统使用。分布式存储可通过采用配额、用户QoS等多种技术手段以保证核心业务的存储服务需求，满足不同业务的SLA要求。
（2）可靠性：主要是指存储服务稳定运行时长，包括服务中断的频率，以及服务中断后恢复的速度等要求。常见的存储数据保护技术有快照、克隆、同步复制/异步复制、双活等。分布式存储遵循CAP原则，优先满足C和P，保证数据的强一致性，通常要求支持副本、纠删码、多版本、CDP（连续数据保护）等。
（3）可扩展性：数据的爆发增长使得扩容变成存储运维的经常性操作。作为分布式架构的存储，天生就具备良好的横向扩展基因，可支持超大型数据中心成千上万个节点的规模，灵活的在线扩缩，真正实现了按需使用和调配。
（4）安全性：当下信息安全事件频发，对于存储的安全性要求也越来越高。分布式存储主要是通过以太网提供服务，因此应该具备传输加密和数据加密的能力，具备完善的权限管理机制。同时为满足审计的要求，还应具备操作记录、日志审计等功能。
（5）维护性：分布式存储应能提供多种自动化管理手段，例如容量预测、故障预测、自动巡检等。还有同传统集中式存储设备一样的生命周期问题，设备更替而导致的数据迁移等，一直都是存储运维中的高风险运维难题，分布式存储的分布式架构设计可以很好的解决这个难题。
随着计算机系统规模日渐庞大，信息技术的发展以及人类生活的智能化带来数据的爆炸性增长，数据正成为世界上最有价值的资源。将所有业务系统集中部署在一个或者若干个主机上的体系架构已经逐渐不能满足当今计算机系统的需求，尤其是大型互联网系统的快速发展，各种灵活多变的系统架构模型层出不穷。同时，越来越多高性价比的PC机成为了各大IT企业架构的首选，分布式的处理方式越来越受到业界的青睐。虽然分布式架构的优点多多，节点数量可扩展性有着巨大优势，但成也“扩展”败也“扩展”。要做到可扩展，就必然要拉开距离，距离有了，延迟就必然会增大。相较之下，集中式存储低延迟的特性又变得极为重要。所以，在低延迟的场景下，集中式存储的架构设计依旧会延续下去，但是容量型存储将会逐渐被分布式存储所替代，这才是分布式存储主攻的方向。分布式存储，不仅提高了存储空间的利用率，还实现了弹性扩展，降低了运营成本，避免了资源浪费，更加适合未来的数据时代场景。
编辑：张至南
金融科技干货分享
每周一篇成长快乐
以上是关于一文读懂分布式存储架构及金融应用的主要内容，如果未能解决你的问题，请参考以下文章