|
|
51CTO旗下网站
|
|
移动端

计算存储分离之“数据存储高可用性设计”

面对着业务的发展,不管是在线,近线还是离线系统,其所需要的存储规模以及存储成本,成倍上涨。如果还是采取传统的分散式存储管理方式,除了高昂的管理分散式存储的成本,还会增加存储成本。

作者:佚名来源:阿里巴巴数据库技术|2018-05-25 09:31

 一、背景

面对着业务的发展,不管是在线,近线还是离线系统,其所需要的存储规模以及存储成本,成倍上涨。如果还是采取传统的分散式存储管理方式,除了高昂的管理分散式存储的成本,还会增加存储成本。

因此,我们极需一种既高效又省成本的数据存储以及存储管理方式。自然地,我们把目光聚焦到了分布式存储系统上。

从目前行业发展趋势来看,各大互联网公司都设计或者维护了自己的分布式存储系统。如Google的GFS(Colossus 为GFS第二代分布式存储系统),Facebook和LinkedIn的HDFS等。由此可见,分布式存储也是大势所趋。

同样在阿里,我们今年对数据库进行计算存储分离,面临的难度也非常大。因此,我们也对各种分布式存储进行了许多研究,开源的如Ceph,还有阿里云的盘古等。

我们紧跟业界以及开源社区,并不断吸收其优秀成果;同时也做了大量的研究,测试和验证。根据集团业务的特性,我们进行了许多软件层面,甚至软硬件结合的优化,为集团业务的发展赋能。

分布式存储系统所具备的优点就是为了克服传统存储方式的缺点。那么,它将会给我们带来哪些收益呢?

二、分布式存储的收益

分布式存储系统所带来的收益主要体现在以下几个方面。总体上来讲,主要是降低存储成本,同时也提高了资源的分配效率,助力计算资源的弹性调度。

2.1 解除机型配比

一般性的,我们将服务器分为两部分,计算资源和存储资源。计算资源如CPU和内存,计算资源的特点就是无状态,资源分配比较灵活。存储资源有状态,需要保证数据的一致性和持久性,资源分配比较固定,会涉及到数据的迁移。如果数据量太大,就会遇到迁移性能的问题。

传统的存储方式,是单台服务器类型的,将计算资源与存储资源(HHD和SSD等存储设备)绑定在一起。因此一台机器CPU,内存与存储设备比值都是固定的。这带来的一个问题,就是我们会比较频繁的改变我们的机型,因每年我们的计算资源与存储资源的配比都在变化,业务数据的增长非常快。这也在某种程度上提高了每年采购机器的成本。

引入分布式存储系统后,解除了这两者紧密耦合的现状,使得降低存储成本成为了可能。计算资源和存储资源解耦后,各自可以按不同的策略进行过保,在一定程度上降低了成本。

2.2 解决存储碎片

传统分散式的存储模型,必然会有存储碎片问题的存在。因为每台服务器都会为线上业务预留一定的存储空间,以满足将来业务数据增长的需要。但是采用预留空间的方式会有一个问题,就是我们无法准确地评估真实的实际空间需求,往往预留的会比较多,业务实际需求与预留空间这两者的差距就是存储空间浪费量。

这些服务器残留了独立的10G,20G的空间碎片,在一定程度上也并不能满足业务实例申请的规格,但将这些碎片合并在一起就能满足业务所需。

引入分布式存储系统后,大大减少这种碎片,业务实际的数据存储空间按需进行动态分配。我们引入数据增长趋势分析,每天或者每周进行存储在线动态扩容,以提高管理效率,降低存储成本。

2.3 计算资源弹性

传统资源配置下,我们的计算资源调度水平受限于单台机器的存储容量。在制定Docker容器化规格时,连同存储容量一起考虑,其调度和资源分配算法异常复杂。当CPU,内存以及存储容量这三者在某种程度上发生冲突时,往往会牺牲一定的存储资本,来达成Docker实例规格的妥协。

将计算资源与存储资源分离后,计算资源得到解脱。我们在安排机器的过保时,采用不同的策略,降低机器采购成本。

另外,计算资源是无状态的,独立之后,进行容器化,就可以方便的进行调度,提高效率。更重要的是,让离在线混布成为一种可能或者让其更高效。

2.4 解决差异化需求

某些新兴业务,往往会呈现爆发式增长。自然而然,其数据量也会呈跳跃式的爆炸。此时对存储的规格的需求就会比较大,因为业务短时间内往往来不及做架构优化,或者做数据分片来降低单机的数据存储容量。这会给传统的存储模型带来很大的挑战,因为传统的分散式的单台服务器的存储容量已经不能满足需求。

分布式存储系统破除了这种大存储容量实例规格的天花板限制,业务不再关心底层存储的实现,我们根据业务数据的增长趋势分析,动态扩展存储空间。

三、面临的问题

尽管分布式存储有上述的诸多优点,然而如何设计其高可用性,如何减少数据丢失的概率,是摆在我们面前必须要去克服的问题。那么我们又是如何来架构和设计的呢?

3.1 数据丢失

在分布式存储系统中,为了防止单机故障而造成数据丢失,往往会引入多个数据副本,我们称之为replica set。此replica set中数据的副本个数用R来表示。一般的,R等于3,就表示是这份数据的存储份数是“3”,也就是我们通常所说的 3-way replication。

在随机的模式下,有可能replica set的3份数据位于同一个rack中,那么当此rack掉电就会导致数据丢失,对线上业务造成影响。随着集群规模的变大,如果有超过1%的数据节点遭遇断电,并且断电之后又有一部分机器重起失败,或者进程异常导致数据文件损坏;那么其影响都将随着集群规模的增长而变得异常严重,成为分布式存储系统致命的问题。

当然,我们可能通过增加数据的副本数即“replica set size”,来降低数据丢失的概率。又或者提高底层IDC以及网络的高可用性,减少断网或者网络故障发生的概率。但是这些方法都是绕开问题的本质来优化的,另外带来的存储成本的增长也是不能接受的。

早期,Facebook和LinkedIn在使用HDFS时,也同样面临这样的问题,也做了这方面不少的验证和测试。最终较为一个合理的方案就是通过合理安排replica set中数据存储的位置来降低数据丢失的可能性。

3.2 数据散射度

为了能够更好的理解数据副本存储位置(data locality),我们引入数据散射度(scatter width)的概念。怎么来理解数据散射度?

假设一个集群,有N个节点,数据副本replica set size为R,那么数据散射度最差的情况就是从N个节点中任意取R个的组合数,也就是C(N,R)。我们假定N为“9”,R为“3”。

举个例子:我们定义三个copy set(存放的都是不同的数据):{1,2,3},{4,5,6},{7,8,9}。任意一组copy set中存放的数据没有重复,也就是说一份数据的三个副本分别放置在:{1,4,7}或者{2,5,8}或者{3,6,9}。那么这个时候,我们称之为其数据散射度S为“3”,远小于随机组合的C(9,3)。

随机组合时,任意3台机器Down机都会存在数据丢失。而采用Copy Set方案后,只有当{1,4,7}或者{2,5,8}或者{3,6,9}其中的任意一个组合不可用时,才会影响高可用性,才会有数据丢失。

综上可知,我们引入copy set的目标就是尽量的降低数据散射度“S”。

但是现实远非这么简单,当我们降低数据散射度后,其数据恢复速度变小,也就是说恢复时间变长。因此,我们必须在数据散射度“S”和恢复速度中找到一个平衡。

 四、高可用性设计

一般地,业务统一用N个“9”来表示一个分布式系统的高可用性。一般业界做得好的,都已经能达到9个“9”。那么,我们的分布存储系统又如何来设计,又能达到多个“9”呢?

4.1 OSD Domain

默认的OSD节点bucket是基于Host的,也就是说取决于一台机器上存储设备的数量。如下图所示,一台Host上面有4个OSD(device,如HDD或SSD等)。所以在集群存储数据时,会寻找数据存放位置。

首先会将Primary放入到Host0的四个节点中,即{0,1,2,3}。同一组中的OSD会根据权重进行平衡。另外两个副本按同样的权重计算方法放到Host1和Host2中。从总上来看,就是三份数据分别放到Host0,Host1和Host2上面,在每一个Host中数据均匀的分布在4个OSD节点上。

当Host0中的OSD 0节点(存储设备)挂掉,会做两个事情:

  • 会从Host0中剩余的OSD节点中,找可替代节点,将新增数据写到剩余的节点中
  • 当OSD 0恢复时,会将Host0其它OSD节点中刚才新增的数据copy回OSD 0,这个叫recovery的backfill过程

我们的目的,就是减少recovery时backfill的时间。所以如果一个Host下面的OSD节点越多,就会有越多的节点参加backfill,恢复速度就会越快。一般单台机器的存储设备挂载都是有限制的,我们很快就会遇到瓶颈。另外,目前的SSD 128K的写入速度也在400-500M/s之间,跟我们的目标相比,并不算太高。

基于此,我们计了OSD domain,它摆脱了单台机器的设备挂载量限制。如下所示,其中黄色虚线框中的OSD都在同一个OSD domain中。一个OSD domain中包含4台机器,每台机器有4个OSD节点(存储设备)。此时,当一个OSD挂掉后,会有15个OSD参加新增数据的平衡和recovery的backfill,大大缩短了恢复时间。

在这些OSD Domain中,故障是隔离的,所以一般也称OSD Domain为故障隔离域。

4.2 Replica Domain

在第三个章节中,我们提到了数据散射度问题,数据散射度越大,可用性越差,丢失数据的可能性越高。因此,我们怎么来解决这个问题呢?

这需要结合copy set的原理来做合理架构与设计,再基于上面OSD domain的设计,我们再新增replica domain,将三个不同rack中的OSD domain组成三个copy set,用于存放replica set的三个数据副本。

具体架构图如下,这样部署后,copy set做到了一个非常低的水平。

另外,为了节省IDC机架位资源,我们在一个集群下分为两个replica domain,每个replica domain下面又有3个OSD domain:

4.3 泊松分布

到这里,我们的副本存放拓扑结构设计差不多完成了,那么接下来,我们来计算下这种部署能做到多个“9”呢?

在分布式存储集群中,X个磁盘发生故障的事件是独立的,其概率是符合泊松分布的。

拿磁盘来讲,其MTTF为1million,因此AFR为“1-(24*365/1million)= 0.98832”,约为“0.99”。泊松分布中,两个重要的变量因还素X和Mean我们都确定了。

对于分布式存储池来讲,X就是replica set size “R”,Mean就是“0.99”。

我们存储集群的高可用性可以简单的按以下函数来量化:P = f(N, R, S, AFR),其中:

  • P: 丢失所有副本的概率
  • R: 副本数,也就是replica set size
  • S: 单组OSD Domain中OSD的个数
  • N: 整个集群中OSD的总数
  • AFR: 磁盘的年平均故障率

进行演化后,我们得到可用性公式:P = Pr * M / C(N,R),其中:

Pr:为R个数据副本同时失效的概率,相当于是Primary在做recovery恢复时,其它R-1个副本也Fault掉了。

M:为可能的Copy set数目

R:为replicat set size,即副本数

N:为集群OSD总数

C(N,R):为N个OSD节点中,取R个副本的组合数

从上面的高可用性公式可以看出,一般在给定集群OSD节点数和副本数“R”后,C(N,R)也就确定了。那么,为了提高可用性,我们必须想办法降低Pr和M的值。

存储节点的拓扑结构,基于以上分析,做的最终架构优化:

  • 为了降低Pr,我们引入了OSD domain,默认基于Host单机,无法发挥网络“多打一”的优势,我们引入OSD domain,提高单个OSD恢复的速度。将原来三个OSD节点扩大到16个,恢复速度提高了5倍以上。
  • 为了降低M,也就是copy set的size,我们引入了replica domain。同一个PG中所有的OSD必须在同一个replica domain中,降低了数据丢失的概率了,提高了高可用性。

以下经我们架构设计后,再根据泊松分布计算出来的高可用性:

根据这个架构设计,在同一个IDC内,我们基本上能做到接近于10个“9”的高可用性。比之于默认的算法,高可用性整整提高了将近100倍。

4.4 网络拓扑结构

根据上面的分布式拓扑结构设计,再结合现有的网络拓扑结构,我们的架构设计最终方案为:

一个存储集群24台机器,两个replica domain,每个replica domain中有三个OSD domain,每个OSD domain中4台机器,因此计算公式如下:

2(一般为两个,由网络交换机下挂的机器数决定)* 3(replica set,replica domain) * 4(scatter width,OSD domain)= 24

原则性的,replica domain的机器位于三个不同的rack时,这三个rack不能在同一个port中。一个交换设备下挂16台机器,两个OSD domain,这两个OSD domain属于不同的replica domain。

在实际生产中,为了高可用性,我们建议至少部署4个rack集群。另外,在集群扩容时,建议按一组replica domain的规模来扩容。

每一组OSD domain中,存储机器数目也可以是4台或者8台不等,可以按单台的机器容量来进行动态规划,但是计算公式可大致参考以上的部署策略。

五、总结与展望

目前,软硬件结合的分布式存储IO stack也在不断的优化(SPDK,NVMe 等)中,网络基础架构RDMA的网络设计也在验证和POC中。这些新的思路与整个业界的生态体系发展趋势一致。

在可预见的将来,存储技术上将会有不断的融合与补益,这也有利于存储技术的更新换代,也更好的支撑业务的快速发展;最终具备,技术扩展业务边界以及业务向技术拿红利的能力。

计算存储分离更多细节,将在以后的篇章中讲述。

【编辑推荐】

  1. 几种存储接口协议的全面比较
  2. 你真的了解软件定义的分布式存储吗?
  3. 提高数据存储效率的七个技巧
  4. 这些错误的数据备份方法, 会让你损失惨重
  5. 看主流分布式存储Ceph如何与私有云领导者VMware碰撞
【责任编辑:武晓燕 TEL:(010)68476606】


点赞 0
分享:
大家都在看
猜你喜欢

热门职位+更多

读 书 +更多

计算机与网络基础知识——考点解析及模拟训练

本书是根据全国计算机技术与软件专业技术资格(水平)考试的“计算机网络管理员考试大纲”所要求的考试范围而编写的辅导用书。全书共分10章...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊