分布式存储系统可靠性如何估算?

本文由  网易云发布。

常规情况下,我们一般使用多副本技术来提高存储系统的可靠性,无论是结构化数据库存储 (如典型的 mysql)、文档型 Nosql 数据库存储 (mongodb ) 或者是常规的 blob 存储系统 (GFS、Hadoop) 等,无不如此。

因为数据几乎可以称得上是企业生命力的核心,保障数据存储系统的可靠性对于任何企业来说都不是一件小事。

数据丢失与 copyset(复制组)

“在由 999 块磁盘组成的 3 副本存储系统中,同时坏三块盘的情况下数据丢失的概率是多大? ”,这个跟存储系统的设计息息相关,我们先考虑两个极端设计下的情况。

设计一:把 999 块磁盘组成 333 块磁盘对。

在这种设计下,只有选中其中一个磁盘对才会发生数据丢失。

这种设计中,丢失数据的概率为 333/C(999,3) = 5.025095326058336*e-07。

设计二:数据随机打散到 999 块盘中。

极端情况下,随机一块盘上的逻辑数据的副本数据打散在所有集群中的 998 块盘中。这种设计下,丢失数据的概率为 C(999,3)/C(999,3)=1,也就是必然存在。

通过这两种极端的例子我们可以看到,数据的丢失概率跟数据的打散程度息息相关。为了方便后续阅读,这里我们引入一个新的概念 copyset (复制组)。

CopySet:包含一个数据的所有副本数据的设备组合,比如一份数据写入 1,2,3 三块盘,那么 {1,2,3} 就是一个复制组。

9 个磁盘的集群中,最小情况下的 copyset 的组合数为 3,copysets = {1,2,3}、{4,5,6}、{7,8,9},即一份数据的写入只能选择其中一个复制组,那么只有 {1,2,3}、{4,5,6} 或者 {7,8,9} 同时坏的情况下才会出现数据丢失。即最小 copyset 数量为 N/R。

系统中最大的 copyset 的数目为 C(N,R) ,其中 R 为副本数,N 为磁盘的数量。在完全随机选择节点写入副本数据的情况下,系统中的 copyset 数目会达到最大值 C(N,R)。即任意选择 R 个磁盘都会发生一部分数据的三个副本都在这 R 个盘上的情况。

磁盘数量 N,副本为 R 的存储系统中,copyset 数量 S, N/R < S < C(N, R)

磁盘故障与存储系统可靠性估算

1. 磁盘故障与柏松分布

在正式估算相关概率之前还需要科普一个基础的概率学分布:柏松分布。柏松分布主要描述在一个系统中随机事件发生的概率,譬如描述汽车站台候客人数为某个值的概率,某个医院 1 小时内出生 N 个新生儿的概率等等,对泊松分布做的更为形象的介绍可参阅阮一峰的《泊松分布和指数分布: 10 分钟教程》。

如上为泊松分布的公式。其中,P 表示概率,N 表示某种函数关系,t 表示时间,n 表示数量,λ 表示事件的频率。

举个例子:1000 块磁盘在 1 年内出现 10 块故障的概率为 P (N(365) = 10) [注:t 的平均单位为天]。λ 为 1000 块磁盘 1 天内发生故障磁盘的数量,按照 google 的统计,年故障率在 8%,那么 λ = 1000*8%/365 。

如上只是损坏 N 块磁盘概率的统计,那么怎么利用这个公式计算分布式系统中数据可靠性 (即数据丢失概率) 的近似值呢?

2. 分布式存储系统中丢失率的估算

2.1 T 时间内的故障率

对于分布式存储系统中如何进行年故障率的估算,我们先假定一种情况:T 为 1 年的情况下,系统存满数据,坏盘不处理,这种情况下统计一下数据的年故障率。

这里我们先定义一些值

N: 磁盘数量
T:统计时间
K:坏盘数量
S:系统中 copyset 数量 (复制组的个数)
R:备份数量

如何计算 T(1年)时间内数据丢失的概率,从概率统计角度来说就是把 T (1 年) 时间内所有可能出现数据丢失的事件全部考虑进去。包含 N 个磁盘 R 副本冗余的系统中,在 T 时间内可能出现数据丢失的事件,即坏盘大于等于 R 的事件,即 R,R+1,R+2,… N ( 即为 K∈[R,N] 区间所有的事件 )。这些随机事件发生时,什么情况下会造成数据丢失?没错,就是命中复制组的情况下。

K 个损坏情况下 (随机选择 K 个盘情况下) 命中复制组的概率为:

p = X/C(N,K) 其中 X 为随机选择 K 个磁盘过程中命中复制组的组合数

那么系统出现 K 个磁盘损坏造成数据丢失的概率为:

Pa(T,K) = p * P(N(T)=K)

最后系统中 T 时间内出现数据丢失的概率为所有可能出现数据丢失的事件的概率总和。

Pb(T) = Σ Pa(T,K) ; K∈[R,N]

2.2 分布式系统衡量年故障率

以上我们假设在一年中,不对任何硬件故障做恢复措施,那么 t 用一年代入即可算出此种系统状态下的年故障率。但是在大规模存储系统中,数据丢失情况下往往会启动恢复程序,恢复完了之后理论上又算是从初始状态的随机事件,加入这个因素之后计算可靠性会变得比较复杂。

理论上大规模存储系统中坏盘、恢复是极其复杂的连续事件,这里我们把这个概率模型简化为不同个单位时间 T 内的离散事件来进行统计计算。只要两个 T 之间连续事件发生的概率极小,并且 T 时间内绝大部份坏盘情况能够恢复,那么下个时间 T 就是重新从新的状态开始,则这种估算能够保证近似正确性。T 的单位定义为小时,那么 1 年可以划分为 365*24/T 个时间段,那么系统的年故障率可以理解为 100% 减去所有单位 T 时间内都不发生故障的概率。

即系统整体丢失数据的概率为:

Pc = 1 – (1-Pb(T))**(365*24/T)

网易云对象存储服务

网易云对象存储服务 NOS(Netease Object Storage)是高性能、高可用、高可靠的云端存储服务。NOS 支持标准 RESTful API 接口,并提供丰富的数据在线处理服务,一站式解决互联网时代非结构化数据管理难题。

其中,网易云采取多重备份机制,为用户文件提供多重备份保障,在任何一台服务器或硬盘故障时,将立即进行数据恢复,确保数据安全无隐患。欢迎广大用户试用和体验。

最后,如想对本文内容(即分布式存储系统可靠性估算)作进一步学习和探究的,可参阅作者的另一篇文章:https://work-jlsun.github.io/2017/02/18/storage-durablity-2.html

了解 网易云 :
网易云官网:https://www.163yun.com/
新用户大礼包:https://www.163yun.com/gift
网易云社区:https://sq.163yun.com/

原文地址:https://www.cnblogs.com/163yun/p/8889614.html

时间: 2024-08-06 06:59:15

分布式存储系统可靠性如何估算?的相关文章

分布式存储系统可靠性系列五:副本放置算法 &amp; CopySet Replication

本文来自网易云社区 作者:孙建良 在分布式存储系统 中说明了,在一定情况下,copyset的数量不是越多越好,在恢复时间确定的情况下,找到合适的copyset的数量可以降低数据丢失的概率. 在分布式存储系统可靠性系列文章分布式存储系统可靠性-设计模式一文中也总结道: 为了提高存储系统数据可靠性,首先在系统允许的成本范围内选择合适的副本数,再次在系统设计中我们首先优先考虑加快数据恢复时间,在此基础上减小系统的copyset数量.使得在既定的成本下达到尽可能高的可靠性. 其实在业界也已经有团队在这方

介绍 Scratch 3.0:扩展编码创造力

在过去十年中,全世界数百万儿童使用Scratch编写自己的互动游戏,故事,动画等. 这种磅礴的创造力激励我们继续扩展和改进Scratch,让世界各地的孩子都有新的机会用新技术创造性地表达自己. 今天,我们推出了Scratch 3.0,它扩展了孩子们创建代码的方式,内容和来源. 当我们测试Scratch 3.0的原型时,我们被孩子们创作的项目惊呆了 :比如说法语的刺猬,会跳嘻哈舞蹈的河马,以及可以用鞋子控制的足球比赛. 这是Scratch 3.0中的新功能: Scratch扩展 使用Scratch

为Docker容器设置静态IP

此文已由作者袁欢授权网易云社区发布. 欢迎访问网易云社区,了解更多网易技术产品运营经验. 创建docker容器 docker run -it --name=yh -h yh --net=none debian:sshd bash   ### 确保使用--net=none参数,此时新建的容器内不会创建网卡 docker ps 此时登录容器查看IP,会发现没有eth0网卡: [email protected]:/# ifconfig -alo        Link encap:Local Loop

云架构师进阶攻略(1)

此文已由作者刘超授权网易云社区发布. 欢迎访问网易云社区,了解更多网易技术产品运营经验. 一.架构的三个维度和六个层面 1.1.三大架构 在互联网时代,要做好一个合格的云架构师,需要熟悉三大架构. 第一个是IT架构,其实就是计算,网络,存储.这是云架构师的基本功,也是最传统的云架构师应该首先掌握的部分,良好设计的IT架构,可以降低CAPEX和OPEX,减轻运维的负担.数据中心,虚拟化,云平台,容器平台都属于IT架构的范畴. 第二个是应用架构,随着应用从传统应用向互联网应用转型,仅仅搞定资源层面的

解析Ceph和9000分布式存储

 Ceph是呼声很高的开源分布式的SDS产品存储系统.同时提供对象存储.块存储和文件系统存储三种功能,满足不同应用需求.Ceph使用C++语言开发,遵循LGPL协议开源.Sage Weil(Ceph论文发表者)于2011年创立了以Inktank公司主导Ceph的开发和社区维护.2014年Redhat收购 inktank公司,并发布Inktank Ceph企业版,业务场景聚焦云.备份和归档,支持对象和块存储应用.从此出现Ceph开源社区版本和Redhat企业版. OceanStor 9000是

分布式存储介绍

本篇将先介绍前三部分: 一.存储类型 二.文件系统 三.存储介质 四.Raid和副本 五.SRVSAN的架构 六.SRVSAN的安全隐患 七.解决的方法 一.存储类型 一般情况下,我们将存储分成了4种类型,基于本机的DAS和网络的NAS存储.SAN存储.对象存储.对象存储是SAN存储和NAS存储结合后的产物,汲取了SAN存储和NAS存储的优点. 图1 我们来了解一下应用是怎么样获取它想要的存在存储里的某个文件信息,并用大家熟悉的Windows来举例,如图1. 1.应用会发出一个指令"读取本目录下

VMware vSAN分布式存储安装配置

作者:在路上(老李) DCD|DCA   QQ群:384423770 一.环境说明 管理地址: AD:        192.168.1.254 ESXi01:        192.168.1.201 ESXi02:        192.168.1.202 ESXi03:        192.168.1.203 ESXi04:        192.168.1.204 vCenter:        192.168.1.200 VSAN地址: esxi01:        172.16.2

如何估算测试工作量

(一)常规的估算测试工作量的方法 作为一个管理者,你是否被询问到某个项目要花多少时间,多少人力测试:或是作为一个普通的测试员,你是否被询问到要花多少时间来完成某个任务或是一次回归测试?我想大多数在软件行业的人或多或少都会碰到这样的关于工作量估计的询问.那么你是怎么回答的呢?你对你自己的回答有信心吗?你是否最终发现实际上花去的时间和原本估计的时间大相径庭呢? 不同的人会使用许多不同的方法来估算及安排他们的测试工作量.不同的组织根据项目的类型,项目的内在风险,涉及的技术等而使用不同的方法.但是大多数

Key/Value之王Memcached初探:三、Memcached解决Session的分布式存储场景的应用

一.高可用的Session服务器场景简介 1.1 应用服务器的无状态特性 应用层服务器(这里一般指Web服务器)处理网站应用的业务逻辑,应用的一个最显著的特点是:应用的无状态性. PS:提到无状态特性,不得不说下Http协议.我们常常听到说,Http是一个无状态协议,同一个会话的连续两个请求互相不了解,他们由最新实例化的环境进行解析,除了应用本身可能已经存储在全局对象中的所有信息外,该环境不保存与会话有关的任何信息.之所以我们在使用ASP.NET WebForm开发中会感觉不到Http的无状态特