分布式存储系统

本文涉及的产品
云原生大数据计算服务MaxCompute,500CU*H 100GB 3个月
云原生大数据计算服务 MaxCompute,5000CU*H 100GB 3个月
简介: 本次分享内容主要包括三部分:(一)分布式存储系统应该具备的能力;(二)阿里云分布式存储系统盘古的介绍;(三)分布式系统技术展望。

分布式存储系统应该具备的能力

大数据同生活息息相关,大量数据的出现对分布式存储提出了更高的需求,具体表现为以下方面:

(1) 高可靠,这是存储系统需要满足的最关键需求,既要保证数据在读写过程中不能发生错误,同时还要保证数据进入到系统后硬件失效不会导致数据丢失。随着集群规模的增大,遇到硬件错误概率会随之变高,存储系统需要有能力保证在任何对数据做转换的时候有无缝的数据检查机制保证数据不会出错,在硬件失效后可以及时补充数据防止硬件损坏引起的数据丢失。

(2) 高可用,存储系统必须具备连续提供对外服务的能力。在系统运行过程中,软件升级、软件缺陷、供电和网络系统维护、硬件失效都有可能中断系统服务。为了实现高可用,软件方面,系统模块之间需要做到低耦合,模块内部做成高可用,保证在某个集成或者某一个模块的一批进程出现异常时系统其他组件仍然可用;硬件方面,可以根据硬件的拓扑结构来分布数据,防止某个硬件故障导致任何数据不可用,例如采用数据跨机架、跨数据中心分布等策略。

(3) 高性能,存储系统软件的实现需要释放硬件技术进步带来的性能提升。现在高速存储设备再不断降低延迟增加吞吐,如果还使用传统的TCP网络和内核的CPU调度,将不能充分发挥硬件的性能。例如现在NVMe SSD设备的写入延时小于10微秒,RDMA网络小数据包传输延时小于5微秒,如果采用传统的多线程编程技术和传统的TCP网络模型会导致软件时间消耗是硬件消耗的几倍甚至几十倍,完全体现不出硬件发展带来的技术红利。

(4) 低成本,随着云计算的蓬勃发展,数据爆炸式增长,粗放的堆设备的发展方式最终会让公司失去竞争力。存储系统在保证高可靠、高可用、高性能的前提下如何做到更低的成本会从根本上提高产品的竞争力。在存储行业一般采用的通用方法是数据编解码、分级存储等技术。

(5) 好用,存储系统面临的用户多种多样,如何能服务好这些用户是系统能否广为使用的前提。在存储系统接口上需要多种多样,传统用户使用最多的是块设备和文件系统,同时互联网新应用需要的是对象存储、分布式表格存储等形式,如何在一套系统中提供这样丰富的接口,既对存储架构的灵活性有比价高的要求,同时还需要有很好的抽象能力。

阿里云分布式存储系统介绍

1. 系统架构

盘古存储系统在阿里云内部支持ECS、MaxCompute、OSS、OTS、SLS等几乎所有的阿里云存储产品,对这些产品提供一致、可靠、高性能分布式文件接口和块设备接口,对上层屏蔽硬件错误和存储位置。

系统层次上遵循Meta和Data分离的原则,架构类似HDFS系统的NameNode和DataNode分离,同时利用数据读写和Meta节点低耦合、Meta节点高可用和Meta节点水平扩展等技术方案来规避Meta的单点问题。在盘古系统中NameNode对应盘古的Master节点,DataNode对应盘古的ChunkServer节点。针对块设备,盘古在文件系统上增加block层来将块设备的随机读写映射到顺序读写的文件上,保证块设备数据的强一致。在上述两层之外,增加系统管控层次,可以让存储系统同其他例如流计算、NoSQL、MapReduce等系统协调一致共享硬件资源,在系统运维方面可以从各个节点获取监控、Trace、日志信息,给出运维建议和硬件故障自动处理。

050044dc75ed23156ecae0f37715c460943bdc2b

系统模块划分和部署图

Master节点相当于系统的大脑,主要完成数据分布、恢复、垃圾回收功能。可以在数据写入时根据数据节点的情况动态分配数据位置,防止局部热点。在部分节点失效情况下,合理控制数据恢复过程,既保证数据可靠,同时让性能损失最小,例如在某个交换机出现故障后,为了让数据恢复尽量快,可以先在部分交换机下允许数据有多个副本,这样可以加速数据恢复,在交换机故障恢复后选择多个副本在同以交换机下的数据进行回收,尽量降低单交换机失效引起的集群性能波动。

ChunkServer节点需要做到可以适应不同的硬件类型,以各种硬件最友好的I/O方式操作硬件,释放硬件极限性能,同时对外暴露统一的接口。实现的主要难度是在最小资源消耗的情况下,如何让软件消耗在整个I/O路径上的消耗最小。在数据恢复和重新分布功能中,ChunkServer也是流量控制和优先级控制的重要环节,涉及到多点流量控制,防止系统由于数据恢复过多占用整体或者局部网络流量导致系统性能下降。

2. 数据复制

在分布式存储系统中,即利用了网络设备的网卡、交换机,同时也利用了单机的磁盘、CPU、内存、主板等硬件设备,每种设备都有其特有的失效模型。那HDD磁盘举例,其失效模型包括磁盘直接损坏导致数据丢失、IO下发之后永不返回、数据静默错误,进入只读状态等多种错误类型,不同错误都需要有针对性的处理,底线应该保证数据不会丢失。在万台的集群(一个独立存储系统称为一个集群,数据中心和集群间的关系为多对多,假设机器为20盘位)中,如果按照磁盘年损坏率为5%计算,平均到每天要损坏3块硬盘。

为保证数据可靠性,数据采用多拷贝的方式来防止硬件损坏导致数据丢失,Meta和Data同样需要高可靠,但是使用的方法不同。为保证Meta可靠,Master多个进程分成一组,使用Raft协议对数据状态进行复制。协议保证所有的Meta修改日志同步给大多数成员且落盘成功后才会返回用户成功,同时针对每条日志计算CRC,防止数据出错。数据采用多副本和Erasure Coding两种方式实现,为了降低成本,存储的拷贝数越少越好,但为了增加数据可靠性,存储的拷贝越多越好,所以为了协调两者关系,需要系统可以即时发现硬件错误并快速对数据进行恢复。

在盘古系统中,对于硬件错误会分成不同级别进行处理,例如磁盘错误作为第一优先级处理,因为这样的错误会导致数据永久丢失,不管在网络、磁盘、CPU的调度上都会为这样的硬件失效留有配额,做到单盘数据丢失在分钟量级就可以恢复。

3. 数据容灾

数据容灾主要解决某个数据中心的网络和电力故障导致的系统可用性问题,跨数据中心和跨地域容灾可以突破单数据中心可用性限制,将系统可用性提高到和数据可靠性相同的水平。

在容灾水平上,一地多中心和异地多中心区别比较大,主要局限在延时和网络带宽两个方面。在同地域100千米范围内,多个数据中心间的延时增加小于1毫秒,带宽可以做到接近于数据中心内部网络的水平,在系统设计时主要考虑在数据分布上,在流量控制和延时上的限制不突出。但是跨地域的容灾将延时增大到几十毫秒,带宽则下降至少一个数量级。为了缓解这样的问题,需要做到数据可以异步进行同步,数据可以按照重要程度来区别对待。异步复制需要保证系统Meta的一致性,需要在每时每刻保证充分利用了跨地域的网络带宽,地域内部多副本防止数据恢复占用跨地域带宽。数据重要程度则反映到对数据分布特性的指定,目前盘古系统可以设置每个文件的分布特性,改变分布特性后可以动态对数据分布做出调整。

4. 低成本

降低成本从不同维度可以找到不同的解决方案,将方案集成到存储系统就可以达到极致的成本降低。从软硬件方面考虑,软件编码可以有效降低存储空间,同时硬件高集成度也可以降低存储成本。从系统内部单机到整个集群,单机降低资源消耗和整个集群共享资源都可以降低对硬件的要求。从系统间考虑,能将多个系统混合部署到相同机器上分时或者同时隔离使用硬件资源也可以做到成本降低,同时有助于降低网络带宽要求。

盘古系统支持Erasure Coding编码,可以在降低数据可靠性的前提下,将数据存储成本降低一半以上,同时利用集成度非常高的存储机型,降低对网络、内存、CPU等的均摊成功,这是一个软硬件同时进行优化达到极大降低成本的事例。为了在降低成本不降低性能的目的,在单机的硬件上盘古采用SSD介质Cache的技术手段,在享受HDD低成本的同时还可以体验到接近于SSD的高性能,同时在整个盘古系统范围内,可以设置文件的多个拷贝分别放在不同的介质上,在多个副本间做不同的介质分布,在系统级别将介质混合使用的方案发挥到极致。在和其他系统共享使用硬件的方案上,盘古提供本地磁盘接口,当用户程序需要使用本地盘存储数据的时候,直接向盘古申请一块块设备,按照自己的要求格式化成需要的各种文件系统,所有数据流均经过盘古做统一的I/O调度。这种方案不但没有造成由于共享硬件带来的管理复杂性和硬件效率降低,还给用提供了兼容所有现在本地磁盘操作所有数据操作接口。有了这基础,盘古系统和其他计算类系统可以有效共享网络、磁盘、内存、CPU资源,达到硬件使用效率的增加。

5. 高性能

为了实现高性能,系统在各个模块应该尽量降低软件实现对时间和资源的消耗,常用的技术手段有:使用Cache;降低多线程访问防止锁冲突带来的时间消耗和上下文切换;在数据处理过程中国利用内存零拷贝的处理方式降低时间消耗;并发使用多组硬件;硬件处理同软件处理在时间上并行处理;数据处理流水线化增大吞吐;借助新硬件技术对某个数据阶段进行加速。

上述技术虽然不能完全应用的所有模块,但是针对不同模块的特点选择尽量多得手段组合可以将性能优化的极致。例如盘古的Master节点使用了所有文件Meta池化缓存在内存中的Cache方式,细粒度目录锁,处理流水线,操作日志合并落盘,软件处理和落盘并行处理等技术,单组盘古Master的读写混合OPS可以达到10万/秒。盘古在块存储数据通路上采用全链路无锁,全程无内存拷贝,磁盘操作和数据验证并行处理,操作Session使用线程级别Cache等技术,可以充分发挥NVMe SSD和双25Gb网络的极限性能,延时小于30微妙,数据流量将网络带宽用满的效果。

6. 规模和隔离

规模增大有利于平滑各种由于瞬时并发带来的系统波动,同时规模增大会带来单集群多租户的场景顺势产生,多个租户隔离和优先级控制可以防止高优先级用户收到其他用的影响。

在MaxCompute系统需要调度的作业规模比较大,单个计算任务使用的数据量可以达到PB级别,任务众多,每天处理的作业量在百万级别,在每天凌晨开始到早上结束的这段时间内部系统均处于众多用户并行使用的阶段,白天更多的资源会闲下来给开发调试软件版本和模型训练使用。

针对这样的计算规模,盘古系统可以提供单集群1万台的存储系统,整个MaxCompute系统会在不同集群间调度计算资源,导致链接单个盘古集群的客户端数量远远大于一个集群的国模。在盘古系统中为了应对规模个盘古Master带来的管理压力,将目录树进行静态划分,用多组Master来提供更大的处理能力,同时在各个处理阶段采用优先级队列的方式来做到多用户的隔离个优先级目的。在MaxCompute使用情况下,盘古单集群使用3组Master来对外服务,每个Master可以并行处理70万客户端的并发访问,每个任务需要在请求中提供用户信息,Master通过用户信息和用户访问的请求数在多个用户间做公平性调度。当相同优先级的多个用户的请求同时到达Master且超过处理能力时,发送请求最多的任务的请求会优先被丢弃,这样可以保证整个集群中小任务可以尽快执行完成释放出资源,大任务有效利用Master处理能力尽快完成处理的目的。在数据路径上使用相同的处理方法,做到不同用户的I/O做到优先级控制和相同优先级内部的公平。

ec429a2e77a46f44064c8ad34415e0647e3a90c5 

多队列调度

d83738c91487d757901a3829a61a03f8908f98f0 

相同优先级调度

针对MaxCompute这种大规模数据处理任务的计算特点,大部分中间数据只在计算过程中用,计算完毕后就会被删除,例如MapReduce过程中产生Shuffle数据,盘古为这类数据的操作提供了特殊处理,这类文件的创建、打开、读写、关闭、重命名等操作不经过Master节点,只会存储于单台机器跨网络读取,删除操作跟随任务的生命周期由Master节点负责。这种类型文件的增加有效的解决了Master节点在大规模计算过程中OPS能力不足的问题,增大了系统规模。

 

分布式存储系统技术展望

随着更多传统业务由于成本和新应用场景要求会搬迁到云计算平台上来,对系统的接口兼容、性能和可用性会提出更高的要求,同时大客户和众多用户上云会进一步对系统的规模提出要求。所以从不同方面可以总结出分布式系统的发展路线:

接口方面:

1. ISCSI的系统接口可能企业存储上云的主要接口,这个方式可以有效兼容当前所有传统存储系统的接口形态,同时对于后端定制性更强,有利于快速变化的云计算技术的迭代更新。HDFS由于有Hadoop计算生态非常广泛的用户基础,会作为一个重要的分布式存储接口形式来顺利将生态用户迁移上公有云计算平台。

2. 互联网新业务要求存储系统在提供块和文件接口的同时,也需要提供对象存储、NoSQL等存储形态,同时在这样的形态之上需要存储系统集成图片处理、视频处理、特征提取等更多的计算服务,一站满足很多用户公共的处理要求,这样不但可以让存储和计算结合来降低成本,同时也将稍微偏底层的公共技术作为用户建立新系统的基础。

3. 存储系统对于规模的适应性可以拓展更多企业客户,并且将会成为这部分企业使用公有云的必经阶段。只有让用户在自己的企业内部熟悉了存储系统的功能,同时了解到企业内部很难在资源弹性、容灾级别上和公有云媲美后,将最终切换到公有云上。

稳定性方面:

1. 跨数据中心和跨地域的容灾将是存储系统的标准配置,同时对于容灾进行动态调整和灵活的定价策略将吸引更多的用户。

2. 容器技术和只能交换网络需要进一步和存储系统进行结合,在数据安全和隔离性方面给存储系统带来巨大变化。目前基于进程内部的队列和优先级控制始终处于被动状态,不能在源头上就达到数据流量和优先级的控制,增加了系统的消耗。

性能方面:

1. 存储节点的数据处理将使用专用硬件设备接管来实现数据处理加速,并将数据处理和存储数据的过程合并。存储节点将集成更多的硬件,例如FPGA、RDMA网卡、GPU,这些硬件为特定的数据处理带来加速效果,同时降低功耗,例如利用FPGA对数据进行加密和解密,校验数据的Checksum等。

2. 操作系统内核将不会再参与数据的I/O处理。由于内核进程调度、内存管理和文件系统等增加的软件消耗阻止了新存储硬件性能的发挥,所以这些软件层次将直接被跳过或者放到用户态进行重新实现,而内核只会参与存储节点的管理工作等对时效性要求不强的功能。

bba01b493e1c5d904e882b1c380673c6ebe49a98

相关实践学习
基于MaxCompute的热门话题分析
本实验围绕社交用户发布的文章做了详尽的分析,通过分析能得到用户群体年龄分布,性别分布,地理位置分布,以及热门话题的热度。
SaaS 模式云数据仓库必修课
本课程由阿里云开发者社区和阿里云大数据团队共同出品,是SaaS模式云原生数据仓库领导者MaxCompute核心课程。本课程由阿里云资深产品和技术专家们从概念到方法,从场景到实践,体系化的将阿里巴巴飞天大数据平台10多年的经过验证的方法与实践深入浅出的讲给开发者们。帮助大数据开发者快速了解并掌握SaaS模式的云原生的数据仓库,助力开发者学习了解先进的技术栈,并能在实际业务中敏捷的进行大数据分析,赋能企业业务。 通过本课程可以了解SaaS模式云原生数据仓库领导者MaxCompute核心功能及典型适用场景,可应用MaxCompute实现数仓搭建,快速进行大数据分析。适合大数据工程师、大数据分析师 大量数据需要处理、存储和管理,需要搭建数据仓库?学它! 没有足够人员和经验来运维大数据平台,不想自建IDC买机器,需要免运维的大数据平台?会SQL就等于会大数据?学它! 想知道大数据用得对不对,想用更少的钱得到持续演进的数仓能力?获得极致弹性的计算资源和更好的性能,以及持续保护数据安全的生产环境?学它! 想要获得灵活的分析能力,快速洞察数据规律特征?想要兼得数据湖的灵活性与数据仓库的成长性?学它! 出品人:阿里云大数据产品及研发团队专家 产品 MaxCompute 官网 https://www.aliyun.com/product/odps 
相关文章
|
19天前
|
机器学习/深度学习 存储 运维
分布式机器学习系统:设计原理、优化策略与实践经验
本文详细探讨了分布式机器学习系统的发展现状与挑战,重点分析了数据并行、模型并行等核心训练范式,以及参数服务器、优化器等关键组件的设计与实现。文章还深入讨论了混合精度训练、梯度累积、ZeRO优化器等高级特性,旨在提供一套全面的技术解决方案,以应对超大规模模型训练中的计算、存储及通信挑战。
48 4
|
1月前
|
存储 运维 负载均衡
构建高可用性GraphRAG系统:分布式部署与容错机制
【10月更文挑战第28天】作为一名数据科学家和系统架构师,我在构建和维护大规模分布式系统方面有着丰富的经验。最近,我负责了一个基于GraphRAG(Graph Retrieval-Augmented Generation)模型的项目,该模型用于构建一个高可用性的问答系统。在这个过程中,我深刻体会到分布式部署和容错机制的重要性。本文将详细介绍如何在生产环境中构建一个高可用性的GraphRAG系统,包括分布式部署方案、负载均衡、故障检测与恢复机制等方面的内容。
106 4
构建高可用性GraphRAG系统:分布式部署与容错机制
|
24天前
|
机器学习/深度学习 人工智能 分布式计算
【AI系统】分布式通信与 NVLink
进入大模型时代后,AI的核心转向大模型发展,训练这类模型需克服大量GPU资源及长时间的需求。面对单个GPU内存限制,跨多个GPU的分布式训练成为必要,这涉及到分布式通信和NVLink技术的应用。分布式通信允许多个节点协作完成任务,而NVLink则是一种高速、低延迟的通信技术,用于连接GPU或GPU与其它设备,以实现高性能计算。随着大模型的参数、数据规模扩大及算力需求增长,分布式并行策略,如数据并行和模型并行,变得至关重要。这些策略通过将模型或数据分割在多个GPU上处理,提高了训练效率。此外,NVLink和NVSwitch技术的持续演进,为GPU间的高效通信提供了更强的支持,推动了大模型训练的快
38 0
|
2月前
|
消息中间件 中间件 数据库
NServiceBus:打造企业级服务总线的利器——深度解析这一面向消息中间件如何革新分布式应用开发与提升系统可靠性
【10月更文挑战第9天】NServiceBus 是一个面向消息的中间件,专为构建分布式应用程序设计,特别适用于企业级服务总线(ESB)。它通过消息队列实现服务间的解耦,提高系统的可扩展性和容错性。在 .NET 生态中,NServiceBus 提供了强大的功能,支持多种传输方式如 RabbitMQ 和 Azure Service Bus。通过异步消息传递模式,各组件可以独立运作,即使某部分出现故障也不会影响整体系统。 示例代码展示了如何使用 NServiceBus 发送和接收消息,简化了系统的设计和维护。
64 3
|
2月前
|
消息中间件 存储 监控
消息队列系统中的确认机制在分布式系统中如何实现
消息队列系统中的确认机制在分布式系统中如何实现
|
2月前
|
消息中间件 存储 监控
【10月更文挑战第2天】消息队列系统中的确认机制在分布式系统中如何实现
【10月更文挑战第2天】消息队列系统中的确认机制在分布式系统中如何实现
|
2月前
|
存储 开发框架 .NET
C#语言如何搭建分布式文件存储系统
C#语言如何搭建分布式文件存储系统
86 2
|
2月前
|
消息中间件 存储 监控
消息队列系统中的确认机制在分布式系统中如何实现?
消息队列系统中的确认机制在分布式系统中如何实现?
|
3月前
|
存储 块存储
ceph分布式存储系统常见术语篇
关于Ceph分布式存储系统的常见术语解释和概述。
147 1
ceph分布式存储系统常见术语篇
|
2月前
|
存储 分布式计算 监控
C# 创建一个分布式文件存储系统需要怎么设计??
C# 创建一个分布式文件存储系统需要怎么设计??
42 0