分布式存储基础Cephcinder及华为软件定义的存储方案讲义.docx

分布式存储基础Cephcinder及华为软件定义的存储方案讲义.docx

《分布式存储基础Cephcinder及华为软件定义的存储方案讲义.docx》由会员分享，可在线阅读，更多相关《分布式存储基础Cephcinder及华为软件定义的存储方案讲义.docx（17页珍藏版）》请在冰豆网上搜索。

分布式存储基础Cephcinder及华为软件定义的存储方案讲义

块存储与分布式存储

块存储，简单来说就是提供了块设备存储的接口。

通过向内核注册块设备信息

在Linux

中通过lsblk可以得到当前主机上块设备信息列表。

本文包括了单机块存储介绍、分布式存储技术

Ceph介绍，云中的块存储Cinder，以及

华为软件定义的存储解决方案。

单机块存储

一个硬盘是一个块设备，内核检测到硬盘然后在

/dev/下会看到/dev/sda/。

因为需要利

用一个硬盘来得到不同的分区来做不同的事，通过

fdisk工具得到/dev/sda1,/dev/sda2等，

这种方式通过直接写入分区表来规定和切分硬盘

是最死板的分区方式。

SAN越来越不能满足企业

分布式块存储

在面对极具弹性的存储需求和性能要求下，单机或者独立的

的需要。

如同数据库系统一样，块存储在scaleup的瓶颈下也面临着scaleout的需要。

分布式块存储系统具有以下特性：

分布式块存储可以为任何物理机或者虚拟机提供持久化的块存储设备

分布式块存储系统管理块设备的创建、删除和attach/detach;

分布式块存储支持强大的快照功能，快照可以用来恢复或者创建新的块设备

分布式存储系统能够提供不同10性能要求的块设备。

现下主流的分布式块存储有Ceph、AMSESB阿里云磁盘与sheepdog等。

1Ceph

1.1Ceph概述

Ceph目前是OpenStack支持的开源块存储实现系统（即Cinder项目backenddriver之

）。

Ceph是一种统一的、分布式的存储系统。

“统一的”意味着Ceph可以一套存储系统

同时提供对象存储、块存储和文件系统存储三种功能，以便在满足不同应用需求的前提下简

化部署和运维。

“分布式”在Ceph系统中则意味着真正的无中心结构和没有理论上限的系统规模可扩展性。

Ceph具有很好的性能、可靠性和可扩展性。

其核心设计思想，概括为八个字一“无需查表，算算就好”。

1.2Ceph系统的层次结构

自下向上，可以将Ceph系统分为四个层次:

基础存储系统RADOS（Reliable,Autonomic.DistributedObjectStore，即可靠的、自动化

的、分布式的对象存储）

基础库LIBRADOS

高层应用接口：

包括了三个部分：

RADOSGW（RADOSGateway、RBD（ReliableBlock

Device）和CephFS（CephFileSystem）。

AFT

HQSTMI

匚LIENIT

V

RADOSGW

REST屮ilM間.

Lump&if*Ml翻

1耳nn只*百1

RBD

Areiiahk：

andijJy-ch^tribuLndbuxkgvK；薛WEhIHXiIJikpmpiflimliwliHQEMLWWWrtFg

CEPHFS

APOGIX-cum陶r*Mt!

sysiwfoi,Miiriiainu«"pTri神ci护nl聞rtNippontfwFUSE

「L1QHADOS

AlibwyaloMrinfflpps（0owtiyFiCcaSfeRADOS,witisufiiiontarC.C++bJauBtPyilw.A诚骼WtdPMP

APP

MonitoroOSD和monitor

RADOS由两个组件组成：

一种是数量很多、负责完成数据存储和维护功能的OSEXObject

StorageDevice）。

另一种则是若干个负责完成系统状态检测和维护的

之间相互传输节点状态信息，共同得出系统的总体工作状态，并形成一个全局系统状态记录

数据结构，即所谓的clustermap。

这个数据结构与RADOS提供的特定算法相配合，便实现

Ceph“无需查表，算算就好”的核心机制以及若干优秀特性。

OSD可以被抽象为两个组成部分，即系统部分和守护进程（OSDdeamon）部分。

OSD的

OSD拥

系统部分本质上就是一台安装了操作系统和文件系统的计算机，其硬件部分至少包括一个单核的处理器、一定数量的内存、一块硬盘以及一张网卡。

在上述系统平台上，每个

有一个自己的OSDdeamon。

这个deamon负责完成OSD的所有逻辑功能，包括与monitor

和其他OSD（事实上是其他OSD的deamon）通信以维护更新系统状态，与其他OSD共同完

成数据的存储和维护，与client通信完成各种数据对象操作等等。

1.3Ceph中的数据寻址

用户存储数据时的数据路由过程如下图所示:

File

PGs

OSDs（groupedby厂failuredomain）

Objects

hash^oid）&mask—►pgid

CRUSHfpgSd）—►{osdi.osd2）

黑…

]I*I

（ino.ono）—*oid

首先明确几个概念：

File——用户需要存储或者访问的文件。

对于一个基于Ceph开发的对象存储应用而言,

这个file也就对应于应用中的“对象”，也就是用户直接操作的“对象”。

Ojbect——RADOS所看到的“对象”。

Object与上面提到的file的区别是，object的最大

size由RADOS限定（通常为2MB或4MB），以便实现底层存储的组织管理。

因此，当上层

应用向RADOS存入size很大的file时，需要将file切分成统一大小的一系列object（最后

个的大小可以不同）进行存储。

PG（PlacementGroup）顾名思义，PG的用途是对object的存储进行组织和位置映

射。

具体而言，一个PG负责组织若干个object（可以为数千个甚至更多），但一个object只

能被映射到一个PG中，即，PG和object之间是“一对多”映射关系。

同时，一个PG会被

映射到n个OSD上，而每个OSD上都会承载大量的PG,即，PG和OSD之间是“多对多”

映射关系。

在实践当中，n至少为2，如果用于生产环境，则至少为3。

一个OSD上的PG则

可达到数百个。

事实上，PG数量的设置牵扯到数据分布的均匀性问题。

OSD即objectstoragedevice。

数据路由的过程需要经过几次寻址：

File->object映射。

这次映射的目的是，将用户要操作的file，映射为RADOS能够处理

的object。

其映射十分简单，本质上就是按照object的最大size对file进行切分。

这种切分

的好处有二：

一是让大小不限的file变成最大size一致、可以被RADOS高效管理的object；

二是让对单一file实施的串行处理变为对多个object实施的并行化处理。

Object->PG映射。

在file被映射为一个或多个object之后，就需要将每个object独立

地映射到一个PG中去。

计算公式：

hash（oid）&mask->pgid。

根据RADOS的设计，给定PG

的总数为m（m应该为2的整数幕），则mask的值为m-1。

因此，哈希值计算和按位与操作的整体结果事实上是从所有m个PG中近似均匀地随机选择一个。

基于这一机制，当有大量object和大量PG时，RADOS能够保证object和PG之间的近似均匀映射。

PG->OSD映射。

第三次映射就是将作为object的逻辑组织单元的PG映射到数据的实

际存储单元OSD。

如图所示，RADOS采用一个名为CRUSH的算法，将pgid代入其中，然后

3。

具体

得到一组共n个OSD。

这n个OSD即共同负责存储和维护一个PG中的所有object。

前已述

及，n的数值可以根据实际应用中对于可靠性的需求而配置，在生产环境下通常为到每个OSD,则由其上运行的OSDdeamon负责执行映射到本地的object在本地文件系统中

的存储、访问、元数据维护等操作。

和“object->OSD映射中采用的哈希算法不同，CRUSH算

法的结果不是绝对不变的，而是受到当前系统的状态（clustermap）和存储配置策略的影响。

故而当系统中的OSD状态、数量发生变化时，Clustermap发生变化，映射的结果也就发生

了变化。

1.4写数据的流程

当某个client需要向Ceph集群写入一个file时，首先需要在本地完成寻址流程，将file

变为一个object，然后找出存储该object的一组三个OSB

找出三个OSD后，client将直接和PrimaryOSD通信，发起写入操作。

PrimaryOSD收到请求后，分别向SecondaryOSD和TertiaryOSD发起写入操作。

当

SecondaryOSD和TertiaryOSD各自完成写入操作后，将分别向PrimaryOSD发送确认信息；

当PrimaryOSD确信其他两个OSD的写入完成后，则自己。

也完成数据写入，并向client

确认object写入操作完成。

Client

Write

（1）

tAtk（6）

PrimaryOSD

Write

（2）

Writef3）

Ack⑸IV

TertiaryOSD

I'Ack14]

SecondaryOSD

1.5集群维护

由若干个monitor共同负责整个Ceph集群中所有OSD状态的发现与记录，并且共同

形成clustermap的master版本，然后扩散至全体OSD以及client。

OSD使用clustermap

进行数据的维护，而client使用clustermap进行数据的寻址。

monitor并不主动轮询各个OSD的当前状态。

正相反，OSD需要向monitor上报状态

信息。

常见的上报有两种情况：

一是新的OSD被加入集群，二是某个OSD发现自身或者

其他OSD发生异常。

在收到这些上报信息后，monitor将更新clustermap信息并加以扩散。

新增一个OSD时

首先根据配置信息与monitor通信，monitor将其加入clustermap，并设置为up且out

状态，再将最新版本的clustermap发给这个新OSB收到monitor发过来的clustermap之

后，这个新OSD计算出自己所承载的PG以及和自己承载同一个PG的其他OSB然后与这

些OSD取得联系。

如果这个PG目前处于降级状态（即承载该PG的OSD个数少于正常值），

则其他OSD将把这个PG内的所有对象和元数据赋值给新OSB数据复制完成后，新OSD被

置为up且in状态，clustermap也更新。

自动化故障恢复

当其中一个OSD发生故障时，如果其PG目前一切正常，则这个新OSD将替换掉故障

OSD（PG内将重新选出PrimaryOSD），并承担其数据。

在数据复制完成后，新OSD被置为

up且in状态，而被替换的OSD将推出该PG而clustermap内容也将据此更新。

自动化的故障探测过程

如果一个OSD发现和自己共同承担一个PG的另一个OSD无法联通，则会将这一情况

上报monitor。

此外，如果一个OSDdeamon发现自身工作状态异常，也将把异常情况主动

上报给monitor。

此时，monitor将把