zoukankan      html  css  js  c++  java
  • 在线公开课 | 在数据爆炸的当下,教你设计一个能实现9个9数据可靠性的存储系统

    据 IDC 发布的《数据时代 2025》白皮书预测:在 2025 年,全球数据量将达到史无前例的 163ZB。随着网络发展速度越来越快,数据的产生量正在呈指数级上升,企业面临的数据压力也在不断增加,数据可靠性差、存储的容量和性能不足等数据问题层出不穷。如何在控制成本的情况下将数据可靠性最大化?有什么工具能解决存储的容量和性能不足的问题呢?
    基于此,在 9 月 9 日,京东智联云和英特尔联合举办了「高可靠存储系统的设计实践」线上公开课,来自京东智联云云产品研发部资深架构师崔灿,和来自英特尔中国区资深存储架构师宫兴斌,分别介绍了京东的高可靠存储系统的设计与英特尔傲腾如何助力京东智联云缓解数据压力的。
    以下内容整理自两位老师的分享。

    维持数据高可靠面临的挑战与应对数据可靠性,是数据存储系统底线一般的存在,不同于数据可用性的可修复,数据一旦失去可靠性便代表着数据的永久性丢失,且无法以任何形式找回。所以保持数据系统的高可靠性也是各大企业正在研究的课题。
    但是要维持数据高可靠性也面临着很多挑战,对此崔灿老师表示,主要挑战有两个,其中首当其冲的就是副本问题,包含数据副本数量的控制,即保证需求的情况下,容忍故障的副本数量控制,以及副本数据损坏率。而导致副本数据损坏的原因主要有三个:

    • 硬件故障导致数据损坏,即磁盘、磁头和网络传输等问题导致的损坏;
    • 程序 Bug,即数据的写入和存储程序 bug 导致数据错误或者丢失;
    • 运维操作,即用户或者运维人员的操作失误,导致数据被误删。

    除了副本问题之外,磁盘的故障是不可避免的。此时,就需要能及时地检测出故障并且用其他的正常副本来修复受损的副本数据,但是磁盘的实际故障时间和被检测出来的时间是存在时间差的。当时间差过长时,就可能会出现副本数据全部损坏,数据完全丢失的情况。所以缩短时间差也是保证数据可靠性必不可少的途径。
    这些问题该如何解决呢?
    先说副本问题,在此之前先引入一个概念—冗余,冗余常见的形式分为两种

    • 第一种是复制,如 RAID、三副本、EC 等其本质都是复制,它和我们在线的业务系统是绑定在一起的,其特点为复制的数据可以实现在线实时的进行写入和读取;
    • 第二种是备份,它是和生产的系统是隔离的,与复制不同的是备份会把所有的操作、所有的数据全部记录下来,在数据恢复时可以恢复到任何一个时间点的状态。通过备份的形式可以减少由于操作失误带来的损失。不过备份也存在一个问题,就是其读取和恢复速度都特别慢,动辄就好几个小时,时间成本较高。

    所以在面对副本问题时,可以根据情况进行多副本的复制或者备份来减少由于运维操作、硬件故障等副本问题导致的可靠性降低的情况。当然,通过备份和多副本方式能解决的问题还是有限的,所以降低探测和修复故障的时间,是维持高可靠的另外一种方式。
    在检测时间的降低方面,一般有两个措施:

    1. 通过 CRC 的校验来检测数据是否故障:数据从客户端,到网络和磁盘,都可能是包含同一个 CRC 的,所以在网络或者磁盘出现故障时,就能通过 CRC 就能快速的去发现这个故障。
    2. 定期的对数据做校验:包括本地数据或者是多个副本之间数据的一致性校验。除此之外还需要对数据进行正确性的抽查,因为数据存在磁盘上,突然坏掉的概率是相对比较低的,但是新写入的数据,出现故障的概率是比较高的,通过抽查可以避免新写入数据的故障。

    检测之后就涉及到修复,修复一般涉及到两个方面:

    1. 快速恢复,主要针对在系统上的故障,这就需要更多的磁盘和带宽去修复它。
    2. 软删除,针对一些运维或者其他人的误操作以及我们系统之间的 bug 导致的数据故障,通过软删除机制来找回数据,当遇到数据误删操作时,系统会把数据放在回收站,需要的时候可以直接进行数据拉回。

    如上所说的都是理论知识,从理论上来看,增加可靠性其实是非常简单的一件事情。提高冗余、用大磁盘和高带宽进行磁盘修复、买更好的磁盘减少磁盘故障率,都能增加可靠性,但是这些都有成本,盲目的通过购买提升可靠性,会导致可靠性的成本不可控,那么如何去找到这个平衡点呢?这就是接下来要和大家探讨的事情。

    京东高可靠存储系统设计解析

    1、分类存储数据,定制化高可靠方案
    面对如何找到平衡点这个问题,崔灿表示核心方法是针对不同的数据类型,不同的业务类型去为它定制合理的一个可靠性的方案,通过这样来达到可靠性和成本的平衡,先来说数据的分类:

    一般来说,可靠性都具有一个特点,即数据更新的越频繁,保证可靠性,需要花的代价就越大,所以京东会将数据进行分类,如上图所示第一类是低频更新的数据,如对象存储的数据,这些数据一般具有数量大,更新少的特点。

    第二类数据是一些相对更新比较频繁的数据,如云硬盘的热数据。这些数据量相对少,且对性能的要求比较高,所以针对这些数据,成本已经不是最核心的点了。

    第三类数据是元数据,元数据的特点是非常重要,但是一般它的量相对来说比较小,所以此时需要尽最大的可能性保证它可靠性,而不去管成本。在对元数据时,会用一些类多副本、备份以及上述所说的一些机制来保证可靠性。

    2、对不同数据的存储架构设计以及优化措施

    针对不同的数据京东的处理逻辑,如图可以看到京东智联云存储的架构,整体是分成三层,最下层为 Blob 存储,来存储京东的绝大部分数据,也是成本产生最多的地方,其所有数据都是三副本或者是 EC 的形式。在中间的为元数据的存储,数量少但是非常重要。在这两类数据之上,就是业务数据,目前京东智联云的存储业务有对象存储、文件存储,块存储等。下文会重点介绍 Blob 存储,也是京东智联云解决可靠性问题的核心
    Blob 存储的设计目标,首先是在支持超大的容量的同时,保持超低的成本。其次是支持高可用和高可靠。它有几个设计要点,第一,使用 AppendOnly 系统,不存在修改,数据存在即可判断正确;第二,由后端选择写入位置,保证复制组不会有延迟大的副本;第三,做大的集群规模。

    接下来从数据的复制和检测修复这两方面介绍京东智联云的优化策略。先看数据的复制,整个系统的数据复制采用三副本的形式,是在控制成本的情况下,能满足可靠性的最低要求,且在数据写入时,设置两副本写入即成功。因为在一个大的集群中,部分结点会遇到重启,或者是维护之类的情况,会导致它的写入失败。
    在复制组的选择上,会选择大小在 50 到 100GB 的复制组,范围的制定的上限是取决于修复时间,其下限是取决于集群做大的策略。在上限制定上,一个 100 个 GB 的复制组,如果是以 60MB 的速度修复,大概半个小时就能修复完了,而过大的复制组会导致修复时间变长,影响业务。
    复制组的下限如何计算呢,以实际为例,单盘大概 20T 一个集群,如果是 16000 块盘,就是一个常见的 320P 的物理空间,100P 逻辑空间的一个集群,如果整个集群中有 5% 的盘提供修复,相当于 800 块盘提供修复,每一个副本的修复需要两个盘支撑,通过这个计算能并行修复的副本的数量。一般并行修复的副本数量,应该和单机副本和单盘的副本数量是一致的,这也是达到一个最高的修复,根据这个算法,针对京东智联云一个有 20T 的盘,100P 的集群的系统,它的复制组应该是在 50G。
    再说修复时间优化,京东智联云做了三个措施,首先,也是最重要的,即让系统能容忍两个副本故障,怎么做到的呢?首先其写入是靠服务端来选择,通过这样的方式保证所有的复制组基本上都是三副本且不会有 delay,而标准的写入是做不到这些的。并且在写入的位置的选择上,会考虑到三个副本之间的延迟,可以规避有 delay 的复制组,保证两副本数据的周期很短。
    其次,京东智联云用到了 60MB 的 IO 来做修复,让参与修复的磁盘可以占用大量 IO,使其在可以容忍部分盘慢的情况,保证整体速度,并在数据读取和写入方面进行了优化。
    最后在整个系统的设计中,通过拆分复制组的管理,将管理放到一系列的 Allotter 的服务里,可以实现复制组的数量可以不受限的往上增加。
    上文全面介绍了多机的复制修复,接下来简单说下针对单机修复的措施,主要有三点:第一,DataNode 内部 CRC 校验,当理论上数据和 CRC 理论上不一致时,意味着磁盘上出现了一些故障;第二,例行后台一致性校验,快速发现数据损坏和导致数据损坏的 Bug;第三,业务上的一致的校验,如 Block 的数据和 Block 元数据之间的一致性的校验。
    以上就是京东智联云在 Blob 系统中做的一些改变、优化措施,这也是京东智联云高可靠存储系统的核心部分,接下来简单的讲解下 Meta 可靠性方案和云硬盘的可靠性方案。

    先说 Meta 可靠性方案,崔灿老师强调,由于元数据很重要,所以更多的是注重可靠性而忽略成本,首先将元数据分成增量数据和存量数据,其中存量数据是不修改的,这部分数据采取的措施和 Blob 的数据采取的措施是一致的。而对增量的数据,使用更好的机器,更好的磁盘,更好的 CPU 去处理它。对于整体来说,由于元数据的重要性,所以会做一些备份,把备份存储到刚才说的 Blob 系统中去。
    再说说云硬盘的可靠性,云硬盘本身是支持修改的,但是它的修改也有一定的局部性,另一个特点,它的数据量大,相对而言修改数据量也没有那么多。所以对这种类型的数据,整个策略是进行冷热数据的分离,对于冷的数据来说,类似于 Blob 那种方式去处理,放到 Blob 中,降低成本,对于少量的热数据,相当于忽略成本,用很好的硬件去处理它。

    3、从设计到上线流程的把控

    在分析完三类不同系统的整体的架构设计,接下来说一下整个架构设计之外的事情。架构设计和最终的线上的设计,中间存在一些比较大的 gap,为了保证整体的可靠性,在 gap 部分做的事情也需要去关注。
    接下来会对研发流程中几个比较重要的点进行详细阐述,一个,是灰度发布,灰度发布的核心的目标为避免因为引入 bug,导致所有的副本损坏。此时会进行小批量灰度,即一次发布的时候,在一个发布的周期之内,将灰度发布分成两层,其一是多集群,即隔离的灰度集群。其二是将集群内部分组,组与组之间相互独立,即使一组出现问题也不影响。
    另一个是软删除,软删除更多的是防止一些 bug,或者操作上的失误类似回收站,删除的时候把它移走。
    通过针对不同数据类型设计不同的存储架构,并把控好架构从设计到上线的流程,最终实现存储系统数据的高可用性。在架构设计之外,京东智联云在数据存储上也会遇到存储的容量和性能不足的问题,而这些问题的解决也离不开英特尔傲腾的帮助。

    近些年来,新兴的一些大内存应用,比如内存数据库,AI、自动驾驶等往往受到内存容量不足的限制,很多应用都在计算节点出现了内存容量的差距;存储端则由于 TLC 和 QLC NAND 的快速发展,逐渐走向全闪架构,但与计算节点的性能差距却没有明显缩小,这就导致存储端与计算端出现了性能的差距。
    那么如何去弥补内存容量不足和存储性能不足的这两项差距呢?来看英特尔是怎么做的。

    英特尔傲腾改变传统的数据中心架构

    如今的数据中心架构,是一个典型的一个金字塔结构,越往下容量越大,但延时等性能越差,最上层的是 CPU 的 cache 以及 DRAM 内存,延时最低。最底层是硬盘和磁带,容量最大,但延时也最高。

    Intel 在运用创新的 3D Xpoint 技术打造了两款产品,一个是数据中心持久化内存,DCPMM,用于填补内存容量的差距。另一个是傲腾 SSD,用于存储端的存储级内存 SCM,解决存储端性能差距,而存储端的容量需求则会由 TLC 和 QLC 的大容量的 NAND SSDs 去满足。
    在京东智联云中,傲腾是如何去激活新型的数据中心呢,在这里总结了一个单词,叫做 ACT,其实就是加速、缓存、和分层,无论是在本地存储,还是分布式存储,或者是一些数据库的典型的应用,只要存在着热点数据的地方都可以尝试用傲腾提升性能。
    对于一些热点数据不是很好区分的场景,可以用缓存的方式,对已有的本地存储,或者是这种传统的集中式存储去做加速,增加一片傲腾,去做读写加速,就可以很明显的解决小的 IO 所带来的一些性能问题。而分层则主要是针对传统存储厂商,传统的存储厂商他们在应用这一层时,对数据进行了感知管理,把热数据放在傲腾进行存储,其他的温数据、冷数据则会放到后端的容量层。

    英特尔® 傲腾™提升 ACT 场景性能的四要素

    傲腾之所以可以提升 ACT 这样的解决方案,加速缓存、分层等这些场景应用,那么主要得益于以下这四个要素。
    1、更高的 IOPS:目前只有傲腾 SSD 可以做到混合读写性能,与纯读、纯写的性能相一致,混合读写性能比 NAND SSD P4610 提升三倍以上;
    2、更长的使用寿命:相当于 P4610 寿命的 20 倍,这一全新的存储介质,没有垃圾回收,写放大等 NAND SSDs 专属的特性,因此可以承受更高的写密度和负载;
    3、更低的延时:比 P4610 快 5 倍以上,服务响应更快;
    4、更好的 QoS:由于它没有垃圾回收的机制,可以带来更好的服务质量。

    傲腾在京东智联云当中的一些部署和应用

    傲腾的优异表现,也使得傲腾在京东智联云上得到了一席之地,原来的架构的云节点配置,由传统的 NAND SSDs 和 SATA SSDs 的组合,有了傲腾以后,将这个组合替换为用傲腾的 SSD 加上 NVMe NAND SSDs,用傲腾的 SSD 存放日志,NAND SSDs 去存放数据,通过这样 O+T 的组合,使单个节点的性能提高三倍以上。从而减少了 50% 的节点数,大大是降低了总体的运维成本以及 TCO。
    在未来 Intel 还会继续与京东一起开发更多的一些使用场景,如通过傲腾以及 QLC 的 NAND SSDs 组合提高性能,并改善整体的 TCO。
    点击【阅读原文】获得公开课视频回放链接。

    [阅读原文]

  • 相关阅读:
    LeetCode 72. Edit Distance
    LeetCode 71. Simplify Path
    LeetCode 70. Climbing Stairs
    LeetCode 69. Sqrt(x)
    Ubuntu系统测评
    itchat 爬了爬自己的微信通讯录
    logistic回归模型
    多元线性回归模型
    可乐鸡翅制作难点
    梯度下降算法&线性回归算法
  • 原文地址:https://www.cnblogs.com/jdclouddeveloper/p/13790623.html
Copyright © 2011-2022 走看看