存储--盘古,阿里云飞天分布式存储系统设计深度解析

本文涉及的产品
全局流量管理 GTM,标准版 1个月
云解析 DNS,旗舰版 1个月
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
简介:

本文依据盘古团队的吴洋分享了《盘古:飞天分布式存储系统实践》视频整理而成。

他主要从以下三个方面进行了分享:盘古是什么?盘古是用来解决什么问题的?盘古是怎么解决问题的?他主要介绍了盘古的分布式系统架构和设计理念。


c4787c3d6e561c5a63d30b8d5d85dd87c9139c08


上图列举了目前主流的云计算厂商,我们发现一个很有趣的事情:所有云计算厂商都是“富二代”,它们的分布式存储技术全部采用自研技术,而没有用大家耳熟能详的开源分布式系统。

飞天梦

第一代飞天人的梦想是在大量廉价的PC服务器上,对外提供各种计算和存储服务。具体到以下几个组件:夸父,主要负责网络;女娲,主要负责协同;伏羲,主要负责调度;盘古,主要负责存储;神农,主要负责监控。

e61591399abfca1b5c0e6ec8d772a705787b0ca1

上图介绍了盘古的底层存储平台,其承担承上启下的作用。盘古作为分布式存储系统,主要提供两种类型的接口:Append Only接口,Random Access接口。

盘古是用来解决什么问题的?

单机的硬件或者系统总是不完美的,总是会小概率的出错,但是它又需要具有大规模下水平扩展的能力,因为它要管理大量的机器。这两个层面放在一起意味着出错是常态。

大规模下,小概率事件是常态

  • 4%磁盘年损坏率,1%%机器日宕机率
  • Raid卡崩溃、电容充放电导致write back模式变成write through
  • 网络分割、交换机丢包、升级重启、光纤损坏带宽降低90%、两地机房路由错误
  • 机架断电、整个机房掉电
  • 网卡TCP校验出错,磁盘访问数据校验出错
  • NTP时间漂移、内核IO线程D状态、dirty page cache无法写回
  • 系统热点无时不在,瞬时转移
  • 程序缺陷导致资源泄露、创建大量文件、访问脏数据
  • 误操作:误删数据、拔错磁盘、没有清理测试机器环境上线……

盘古面临的问题和挑战

10dd5499e9cda7d9b5bf5a52ff41f4605eb50a6c

从上图可以看到,作为统一存储,要支持虚拟机中的块存储,对象存储,表格存储,文件存储,离线大数据处理,大数据分析等诸多业务,其面临的挑战是很大的,甚至有些挑战是自相矛盾的。

盘古是怎么解决问题的?

4f4e17143c62417efa290d78d5fb03b61439862a

盘古在系统设计的时候进行了一些取舍。首先盘古使能了更多的云产品,让云产品去对接用户,这样就可以集中精力打造一个稳定可靠的分布式存储平台。高可靠、高可用是不能妥协的部分,在任何情况下要保证数据的强一致性、正确性、可靠性、可用性。有的时候追求低成本会威胁到高可用,所以要做到高性能、合理成本,提供高性价比的在线存储。易用、服务化,方便用户轻量接入、无感知运维完善好用的监控、工具、文档。

盘古总体架构

55b35df3b7df7c274e4ae987dad72ff03511c1ab
分为三个部分:Client,Master,ChunkServer。需要发起一次写入的时候,Client向Master创建一个文件,并且打开这个文件,此时Master会选好三个副本的位置反馈给Client。Client根据三个副本的位置找到ChunkServer,把数据写进去。也就是说,Client做整体的控制,Master提供源数据的存储,ChunkServer提供数据的存储。系统中的单点是非常脆弱的,如何保证其高可用?盘古的第一步是加入一个Paxos,也就是说用很多台Master组成一个group来实现高可用。即使用很多台服务器来实现高可用,最终对外服务的只能是一台服务器,当内存数据足够多的时候,就需要水平扩展。MountTable可以把目录树划分成volume,通过不同的volume就可以实现Master的水平扩展。

数据高可靠

8efd0ef43e35b403519d2bdda7ea602b181a5ca9
盘古三副本强一致,三副本位于不同的故障域,故障时自动数据复制。如上图所示,一个数据中心有3份数据存放在4个RACK中,如果RACK-1突然断电或者网络有问题。此时,比如菱形的数据原来在RACK-3、RACK-4上,当RACK-1的菱形数据丢失时,盘古会通过高效的算法从RACK-3上复制一份出来放入RACK-2,保证了数据的安全可靠。

数据保证完整性
91203f90ba093ae889a92bea82bb0ceb18403320

盘古主要做了两件事:端到端的数据校验,静默错误检查。在小概率下,内存存储的数据是可能发生变化的,磁盘上存储的数据也会发生变化。每段数据后面都有CRC,这样,一旦写入磁盘,数据和CRC是能够匹配上的,后台周期性扫描,发现数据和CRC不匹配时就判定这段数据发生了位反转,那么用其他好的副本将其覆盖。

合理成本

盘古进行了合理成本的优化。比如,线下运行的单集群有上万台,数百PB的数据。单组Master也进行了优化,读能达到15W QPS,写能达到5W QPS。单数据节点进行了软件栈极限优化,使得软件的消耗非常低,并且分层存储。最后,为了实现低成本,使用了普通PC服务器、Erasure Code。

自主服务

7a87f9f0d028d0251b651ad304fd1eefd6989227
运维是非常重要的,盘古实现了热升级应用无感知,运维操作根据配置自动化执行,不需要人工干预,通过环境标准化及时纠正,通过问题诊断自我解决问题。结构如上图所示,有一个集中管理的配置管理库,盘古管控中心会把配置管理库推送到盘古的各个组件,自动执行配置变更,发现配置不对时能够实现自动对齐,运行环境标准化检查对于大规模的分布式系统是非常重要的。

面向容错的设计

分布式系统的核心是面向容错的设计:

  • 数据安全是一种信仰:E2E Checksum;后台静默扫描;系统bug,硬件故障,运维操作的容错。大规模的系统中,总会遇到各种各样的问题,当这些问题搅在一起时就会变得非常棘手。
  • 环境检查排除隐患:磁盘分区;机架分布;配置错误;软件错误;硬件错误。
  • 单机失效无感知:数据复制保证安全;换机器重试保证读写成功;记忆并规避故障机器。
  • 监控+自愈:Master自我健康检查进行切换;Chunkserver发现故障磁盘或机器进行隔离;Client检测服务状况进行Master切换;Client自我健康检测并汇报状态。

以上的设计大大减小了运维的压力。

Master

44dbe3050bdf20fc1c1da230d81a7622e02c801f
Master需要解决的主要是三类问题:大容量、高效、稳定。大容量是指:Federation水平扩展,内存紧致排列单组支持8亿文件,读写OPS 100K/s。高效意味着最优的算法,硬件错误触发快速复制保证数据安全,数据流量动态规划实现最大吞吐,安全域动态调整保证数据高可用。稳定即Paxos数据一致、防止单点,多角度监控自动触发切换,多用户隔离防打死。由于盘古是多租户的系统,比如一万台的集群上面会跑着各种各样的应用,其相互之间是不知道的,但是它们在共用一个Master机器。如果一个用户大量访问Master,这时整个集群都不能提供对外服务,怎么杜绝这种情况?盘古做了多重隔离解决了上述问题。

Chunkserver

b5959aaaa0801ddefafb329ba1650783ac39eb9c
Chunkserver面临的问题是:闪存的价格高,IOPS高;机械硬盘价格低,IOPS低;只写入内存的方案掉电会丢失数据。如果整个集群都掉电,那么内存中还没写入数据就会丢掉,如果三份备份数据都丢掉,这对云计算是不能接受的事情。怎么结合闪存、机械式硬盘以最低的成本解决上述问题?有些解决方案使用UPS,但是UPS也存在不可靠问题,数据仍然会丢失。所以,最终的解决方案是使用少量的缓存搭配大量的机械硬盘,数据前台先写入缓存,后台将其转储到机械式硬盘。

Client

a98a1800899311df924be592dda82ac90bc75c2f
Client面临很多问题,很多现在的编程语言中,协程是非常普及的事情。传统的多线程编程中,多核系统上线程较多时,切换代价非常高,高性能的程序无法容忍这一点。有些解决方案是异步的编程,这样就使用少数的线程、不切线程。怎么样既有同步编程的便利,又有异步编程的性能?协程就是解决方案,很多现在的编程语言本身已经提供了协程,但是C++没有提供协程,所以盘古自己通过实现协程获得了高性能。Client面临的问题是:有些用户需要极致的性能,有些用户需要编程的简便,已有的海量程序要无缝支持。解决上述问题的方案是使用线程同步原语同时支持协程和非协程用户。在协程中是不切线程的,所以意味着所有的Task都在一个线程中执行,如果任何一个Task有阻塞操作,都会导致整个线程吞吐率的降低。
目录
相关文章
|
7天前
|
分布式计算 大数据 数据处理
技术评测:MaxCompute MaxFrame——阿里云自研分布式计算框架的Python编程接口
随着大数据和人工智能技术的发展,数据处理的需求日益增长。阿里云推出的MaxCompute MaxFrame(简称“MaxFrame”)是一个专为Python开发者设计的分布式计算框架,它不仅支持Python编程接口,还能直接利用MaxCompute的云原生大数据计算资源和服务。本文将通过一系列最佳实践测评,探讨MaxFrame在分布式Pandas处理以及大语言模型数据处理场景中的表现,并分析其在实际工作中的应用潜力。
34 2
|
9天前
|
运维 安全 Cloud Native
阿里云云安全中心全面解析
阿里云云安全中心作为一款集持续监测、深度防御、全面分析、快速响应能力于一体的云上安全管理平台,为企业提供了全方位的安全保障。本文将详细介绍阿里云云安全中心的功能、应用场景、收费标准以及购买建议,帮助您更好地了解和利用这一强大的安全工具。
阿里云云安全中心全面解析
|
15天前
|
运维 Kubernetes 调度
阿里云容器服务 ACK One 分布式云容器企业落地实践
阿里云容器服务ACK提供强大的产品能力,支持弹性、调度、可观测、成本治理和安全合规。针对拥有IDC或三方资源的企业,ACK One分布式云容器平台能够有效解决资源管理、多云多集群管理及边缘计算等挑战,实现云上云下统一管理,提升业务效率与稳定性。
|
1月前
|
存储 安全 数据安全/隐私保护
PyPI 存储库中的 JarkaStealer:深入解析与防范措施
PyPI 存储库中的 JarkaStealer:深入解析与防范措施
26 2
|
1月前
|
机器学习/深度学习 人工智能 弹性计算
阿里云GPU服务器全解析_GPU价格收费标准_GPU优势和使用说明
阿里云GPU云服务器提供强大的GPU算力,适用于深度学习、科学计算、图形可视化和视频处理等场景。作为亚太领先的云服务商,阿里云GPU云服务器具备高灵活性、易用性、容灾备份、安全性和成本效益,支持多种实例规格,满足不同业务需求。
309 2
|
1月前
|
数据采集 存储 监控
公司监控软件:基于 PHP 的分布式监控系统设计
本文介绍了基于 PHP 的分布式监控系统的设计与实现。该系统包括监控节点、数据采集模块、数据传输模块和监控中心,能够高效地收集、传输和分析各节点的数据,确保系统的稳定运行和安全防护。通过示例代码展示了数据采集、传输及存储的具体实现方法,并强调了安全与可靠性的重要性。
51 3
|
1月前
|
分布式计算 Java 开发工具
阿里云MaxCompute-XGBoost on Spark 极限梯度提升算法的分布式训练与模型持久化oss的实现与代码浅析
本文介绍了XGBoost在MaxCompute+OSS架构下模型持久化遇到的问题及其解决方案。首先简要介绍了XGBoost的特点和应用场景,随后详细描述了客户在将XGBoost on Spark任务从HDFS迁移到OSS时遇到的异常情况。通过分析异常堆栈和源代码,发现使用的`nativeBooster.saveModel`方法不支持OSS路径,而使用`write.overwrite().save`方法则能成功保存模型。最后提供了完整的Scala代码示例、Maven配置和提交命令,帮助用户顺利迁移模型存储路径。
|
1月前
|
存储 弹性计算 NoSQL
"从入门到实践,全方位解析云服务器ECS的秘密——手把手教你轻松驾驭阿里云的强大计算力!"
【10月更文挑战第23天】云服务器ECS(Elastic Compute Service)是阿里云提供的基础云计算服务,允许用户在云端租用和管理虚拟服务器。ECS具有弹性伸缩、按需付费、简单易用等特点,适用于网站托管、数据库部署、大数据分析等多种场景。本文介绍ECS的基本概念、使用场景及快速上手指南。
88 3
|
2月前
|
运维 Cloud Native 持续交付
云原生技术解析:从IO出发,以阿里云原生为例
【10月更文挑战第24天】随着互联网技术的不断发展,传统的单体应用架构逐渐暴露出扩展性差、迭代速度慢等问题。为了应对这些挑战,云原生技术应运而生。云原生是一种利用云计算的优势,以更灵活、可扩展和可靠的方式构建和部署应用程序的方法。它强调以容器、微服务、自动化和持续交付为核心,旨在提高开发效率、增强系统的灵活性和可维护性。阿里云作为国内领先的云服务商,在云原生领域有着深厚的积累和实践。
76 0
|
1月前
|
监控 Java 应用服务中间件
高级java面试---spring.factories文件的解析源码API机制
【11月更文挑战第20天】Spring Boot是一个用于快速构建基于Spring框架的应用程序的开源框架。它通过自动配置、起步依赖和内嵌服务器等特性,极大地简化了Spring应用的开发和部署过程。本文将深入探讨Spring Boot的背景历史、业务场景、功能点以及底层原理,并通过Java代码手写模拟Spring Boot的启动过程,特别是spring.factories文件的解析源码API机制。
76 2

热门文章

最新文章

推荐镜像

更多