《专场3.4-美团存储云原生探索和实践-杨立明.pdf》由会员分享,可在线阅读,更多相关《专场3.4-美团存储云原生探索和实践-杨立明.pdf(31页珍藏版)》请在三个皮匠报告上搜索。
1、美团存储云原生探索和实践杨立明+美团+架构师云原生简述云原生技术使组织能够在新式动态环境(如公有云、私有云和混合云)中构建和运行可缩放的应用程序。容器、服务网格、微服务、不可变基础结构和声明性 API 便是此方法的范例。这些技术实现了可复原、可管理且可观察的松散耦合系统。它们与强大的自动化相结合,使工程师能够在尽量减少工作量的情况下,以可预测的方式频繁地进行具有重大影响力的更改。-“云原生计算基金会”云原生技术敏捷性、灵活性、可靠性、可伸缩,为企业提供了巨大的生产力,这也是公司近几年基础架构的迭代方向。存储计算分离与云原生当前基础架构是存算一体的架构,存储系统面临的问题:存储扩展能力弱:在计算
2、资源达到瓶颈需要扩容时,仍然需要迁移数据,迁移数据的时间跟数据量线性相关,所以,对于数据量较大的业务,扩容操作时间会很长。机器成本高:存储计算资源耦合在一起,如果集群因为CPU计算能力达到瓶颈,我们就需要扩容,而往往这时节点的硬盘空间还很空闲。反之亦然,存储和计算资源经常会有一方存在机器资源浪费。重复研发和运维成本高:这些存储组件基本上要考虑副本冗余、副本数据一致性、数据正确性校验,副本缺失补副本,扩容缩容等问题,因此存在着重复研发和运维问题。不能很好的满足业务多样化需求:比如我们现在需要提供一个分布式文件系统服务,基本上我们需要从零开始研发,研发进度会很慢,不能很好的满足业务的需要。这些问题
3、阻碍了公司云原生的建设,因此,我们设计并建设了存储与计算分离的系统,来更好的满足云原生的迭代。存算分离架构的优势和挑战优势扩展能力强:上层存储服务模块实现无状态化设计,可实现秒级扩缩容,无需数据迁移。产品快速迭代:基于底座,可以最大程度复用其通用存储能力,来适应业务需求,快速开发出新的存储产品降本增效:存储计算分离,避免了集群的存储、计算资源错配造成的资源浪费。统一底座服务使得上层存储无需重复研发数据分布、副本、容灾等机制,大幅降低研发成本。挑战稳定性:作为其他存储底层的底座存储,一旦出现稳定性问题,将会影响其他所有存储服务,进而影响到上层业务。性能:分层架构后,相对于存算一体的服务,增加了一
4、跳的网络延迟。存储底座的吞吐很大程度上也决定了上层存储服务的吞吐。Mstore总体介绍MStore设计目标是为各种存储服务抽象出公共底座,提供似Posix的简单文件接口,对接块存储系统、文件存储系统、对象存储、表格存储、数据库、大数据等业务。Mstore整体架构MStore存储系统有4个子系统:RootServer、MetaServer、ChunkServer、SDK。RootServer:集群的入口,管理着整个集群中资源信息,包括MetaServer、ChunkServer、磁盘等信息。MetaServer:管理着用户数据的元信息,包括Blob、Blob由哪些Chunk构成,Chunk和Ch
5、unkServer的映射关系等。MetaServer在集群中可以有多组,使得元信息管理能水平扩展。ChunkServer:用户数据存储服务,对用户数据的序列化存储、校验。接受用户读写请求,接受MetaServer数据复制、负载均衡等请求。SDK:提供给用户的Library,用户可以通过链接这个Library访问MStore的存储服务,类文件系统API。Mstore的BlobBlob是Mstore提供给用户使用的对象,类似于文件。Blob是由多个Chunk组成,以便将Blob做分布式存储。Chunk的大小默认为64M。Mstore的Blob为了满足不用的应用场景,目前我们提供两种类型的Blob,
6、LogBlob用于支持追加写、ExtentBlob用于支持随机写。系统通常是将数据写到LogBlob,然后后台回刷到ExtentBlob。Mstore元数据元数据主要分为两类:资源信息和用户数据RootServer管理所有的硬件资源,整个集群只有一组。MetaServer管理用户数据,可以有多组,可以水平扩展。元数据节点通过Raft机制保证数据的可靠性、高可用。Mstore资源管理集群资源由RootServer(RS)统一管理,RS是资源增删和分配的入口。主要的资源信息包括:MetaServer组信息ChunkServer信息磁盘信息PhysicalPool信息LogicalPool信息Mst
7、ore资源控制PhysicalPool是物理磁盘的集合,一个集群可以包含多个物理Pool,一般一个Pool中的资源规格是一样的。LogicalPool是对物理资源上的逻辑划分,一个物理Pool中可以创建多个逻辑PoolLogicalPool概念是暴露给用户的,用户可以根据自己的需要对业务做逻辑Pool的划分LogicalPool为单位定义QoS,包括服务能力的上限、下限、权重等Mstore用户数据用户数据,需要MetaServer决定放置在哪块盘上,放置策略需要考虑的因素主要有:保证一个rack只能有一个副本写本地一份,远程多份的需求机器和磁盘容量大小同城多机房的需求Mstore星型写控制流方
8、向,SDK不会频繁和RootServer和MetaServer交互,只有在申请新Chunk是才去交互。数据流方向,SDK采用并发同步写三副本的方式,保证数据强一致,架构上更简单,相比Raft等共识协议减少了网络一跳,降低延迟。星型写不支持多点,上层服务需要控制对其数据的多点读写请求。快速切换技术,在星型写三副本失败时,不需要马上修复数据,通过快速重定向到新的三副本使得故障瞬间恢复。Mstore一次IO技术为了减少对磁盘的IO占用,我们对写请求做了合并,让多用户请求转换成一次磁盘请求对磁盘存储格式的优化设计,使得每次磁盘请求只产生一次IO,这是性能优于Ceph的原因。用户请求边界保存在存储格式的
9、Header结构中,使得异常恢复时能区分请求的边界,实现写请求的原子性。此外存储格式的Header中还保存了数据的CRC信息,保证数据的正确性。Mstore-存储格式Header存储格式Header包含以下字段:1.prev_size 前一个请求的size2.curr_size 当前请求的size3.prev_crc 前一个请求的checksum4.curr_crc 当前请求的checksum5.flags 一些标识位6.self_cksum Header本身的checksumMstore数据版本Mstore存储的用户数据是有版本的,根据数据的版本可以实现:版本号递增,写请求通过版本保证请求的
10、连续性 读取数据带上版本号,保证读取的副本是新的。数据巡检服务根据数据版本保证合法的副本。blobA version=chunk1 version+chunk2 version+chunk3 versionMstore数据读写规则Blob只能单点写,通过租约机制做互斥。Blob支持多点读,由用户负责同步多个节点的版本。Mstore可观测性Mstore系统已经拥有完善的监控、告警体系。为了让系统能够以更加白盒的方式在线上运营,我们实现了Trace能力,目的是能观测Mstore系统以及其依赖的系统的每次请求各个阶段的执行情况。这也有利于后续我们对系统性能做优化。Trace已经可以对接美团的Mtra
11、ce平台。Mstore的Run To Complete线程模型为了最大化降低延迟,我们采用了Run To Complete(RTC)线程模型,即:一个请求在生存周期内都由一个线程处理。以下为ChunkServer的整体结构。为了增加系统并发度,RTC模型仍然是多线程的。不需要互斥的请求(Req1),在本线程执行完毕。需要互斥的请求(Req2、Req3、Req4),这些请求由第一个请求所在线程处理。程序保持简单,模块从上到下以同步的方式调用。利用C+的RAII技术,在请求析构过程回调执行链表下一个请求,将异步动作收敛在一处。Mstore的裸盘系统经过我们对ChunkServer的性能测试,发现软
12、件栈中大部分的耗时来自文件系统操作磁盘,其次是网络IO。下图是我们使用Trace系统得到的延迟信息。基于以上结论,我们研发了用户态文件系统(裸盘系统),它设计成针对Blob特点的磁盘管理方式,简单、高效。我们在裸盘系统下抽象出BlockDevice层,使其能适配不同的设备,如SPDK、IOuring等。目前我们使用SPDK作为磁盘驱动,实现ChunkServer全栈用户态。Mstore的裸盘系统裸盘系统的元数据包括,SuperBlock区、BlockTable区、ChunkTable区,Padding区是预留的未使用空间,剩下的是数据区。SuperBlock区:裸盘系统的整体信息,磁盘号、是否
13、格式化、Block数量、Chunk数量等BlockTable区:记录系统数据块的分配情况ChunkTable区:记录系统Chunk的分配情况Chunk在创建时候在ChunkTable申请一个存储区域,记录Chunk的元信息,删除Chunk的时候归还这块区域给ChunkTableChunk在写入数据的时候会在BlockTable里面申请一个Block,删除Chunk的时候会把Chunk的所有Block归还给BlockTableChunk的Block按照写入的顺序以邻接表的形式保存在BlockTable中Mstore的系统延迟ChunkServer自身延迟约26us,其中spdk占用11us,后续
14、将对ChunkServer各个模块精细优化。Mstore的系统吞吐我们还做了ChunkServer的压力测试对比,同等压力下,写吞吐几乎是Ext4文件系统的2倍,延迟比Ext4低很多;读吞吐也高于Ext4,但是因为Ext4有文件系统缓存,所以相比之下Ext4的读平均延迟要低一些。后续我们会看需求在裸盘系统基础上利用Optane SSD设备实现缓存。Mstore测试体系建设Mstore之初我们就考虑系统稳定性的重要,因此我们建设了完善的测试体系。Mstore落地情况总实例数:234+,总磁盘数:4212+EBS集群6个EFS集群3个Hulk单车DTSEagleEBS整体架构EBS系统(块存储)是
15、应用在MStore的第一个项目。EBS有4个子系统:BlockMaster、BlockServer、Client、SnapshotServer。BlockMaster:块服务的管理节点,维护块设备的元信息,分配BlockServer。简称BM。BlockServer:块服务的数据处理节点,接收块设备的所有IO。简称BS。Client:块设备的客户端。SnapshotServer:块服务的快照服务器。简称SS。业界对标:美团盘古字节DumpInplace-updateAppend-onlyInplace-update其他一致一致一致EBS数据组织一块盘(Vdisk)被划分成多个Segment,典
16、型大小64G,一个Segment由某个BlockServer处理。BlockServer会将一个Segment的所有请求以Writeahead log(WAL)的形式写到MStore的LogBlob。每个Segment又划分成多个Entry,每个Entry对应MStore的一个ExtentBlob。这样组织数据的好处是:1、将多个Entry的随机写转化成一路顺序写,起到group commit的作用。2、每个Entry对应一个ExtentBlob,这样多个Entry之间没有联系,回刷能并行执行。3、在读取的时候如果一个请求跨越几个Entry,这几个Entry之间也可以并发的去读。EBS索引Bl
17、ockServer处理请求先将数据写入WAL之后回刷到Entry里面,为了保证回刷前的数据可读到,需要在WAL之上建立索引。索引是全内存缓存的,索引结构由UpdateTable+BaseTable组成。UpdateTable是可以读写的(Mutable),BaseTable是只读的(Immutable)。定期做Checkpoint有利于系统重启快速恢复,会生成一个新的Secondary UpdateTable,旧的UpdateTable变为只读,和原来的BaseTable合并生成一个新的BaseTable。这么设计索引的好处是,BlockServer的操作都针对只读的BaseTable操作,简
18、化程序处理,减少操作BaseTable的锁竞争,有利于性能。EBS回刷WALBlockServer会定期把WAL的数据回刷到Entry里面,按照LogBlob从头到尾顺序回刷。实现过程要注意几个时间点,才能保证各子系统能正确工作:1、最旧的Log点、2、Dump的起始点、3、Dump的结束点、4、索引Checkpoint点、5、最新Log点。时间顺序:1=2=3=4=5。Log回收区:【最旧的Log点,Dump的起始点),这个区间的Log可以随时被回收掉。Dump数据区:【Dump的起始点,Dump的结束点),这个区间是Dump操作正在作用的区间。索引BaseTable表示的区间:【最旧的Log点,Checkpoint点),这个区间表示Checkpoint点之前的所有数据的索引,涉及WAL+Entry。索引UpdateTable表示的区间:【Checkpoint点,最新Log点),这个区间表示Checkpoint点之后的所有数据的索引,只涉及WAL。