Chinaunix首页 | 论坛 | 博客
  • 博客访问: 435178
  • 博文数量: 122
  • 博客积分: 0
  • 博客等级: 民兵
  • 技术积分: 688
  • 用 户 组: 普通用户
  • 注册时间: 2013-09-04 12:30
文章分类

全部博文(122)

文章存档

2017年(5)

2016年(4)

2015年(56)

2014年(41)

2013年(16)

我的朋友

分类: LINUX

2014-12-07 11:08:42

原文地址:Ceph学习笔记 作者:yangyangRH

1. Ceph概述
Ceph is a unified, distributed storage system designed for excellent performance, reliability and scalability.”

也即,Ceph是一种为优秀的性能、可靠性和可扩展性而设计的统一的、分布式的存储系统。应该说,这句话确实点出了Ceph的要义,可以作为理解Ceph系统设计思想和实现机制的基本出发点。在这个定义中,应当特别注意“存储系统”这个概念的两个修饰词,即“统一的”和“分布式的”。

         具体而言,“统一的”意味着Ceph可以一套存储系统同时提供对象存储、块存储和文件系统存储三种功能,以便在满足不同应用需求的前提下简化部署和运维。而“分布式的”在Ceph系统中则意味着真正的无中心结构和没有理论上限的系统规模可扩展性。在实践当中,Ceph可以被部署于上千台服务器上。截至2013年3月初,Ceph在生产环境下部署的最大规模系统为Dreamhost公司的对象存储业务集群,其管理的物理存储容量为3PB[]。

2. 历史
Ceph项目起源于其创始人Sage Weil在加州大学Santa Cruz分校攻读博士期间的研究课题。项目的起始时间为2004年[]。在2006年的OSDI学术会议上,Sage发表了介绍Ceph的论文[],并在该篇论文的末尾提供了Ceph项目的下载链接。由此,Ceph开始广为人知。

3. 设计思想
事实上,Ceph最初针对的目标应用场景,就是大规模的、分布式的存储系统。所谓“大规模”和“分布式”,是指至少能够承载PB级别的数据,并且由成千上万的存储节点组成。

Ceph最为核心的技术创新就是前面所概括的八个字——“无需查表,算算就好”。一般而言,一个大规模分布式存储系统,必须要能够解决两个最基本的问题:

       一是“我应该把数据写入到什么地方”。对于一个存储系统,当用户提交需要写入的数据时,系统必须迅速决策,为数据分配一个存储位置和空间。这个决策的速度 影响到数据写入延迟,而更为重要的是,其决策的合理性也影响着数据分布的均匀性。这又会进一步影响存储单元寿命、数据存储可靠性、数据访问速度等后续问 题。

        二是“我之前把数据写到什么地方去了”。对于一个存储系统,高效准确的处理数据寻址问题也是基本能力之一。

        针对上述两个问题,传统的分布式存储系统常用的解决方案是引入专用的服务器节点在其中存储用于维护数据存储空间映射关系的数据结构。在用户写入/访问数 据时,首先连接这一服务器进行查找操作,待决定/查到数据实际存储位置后,再连接对应节点进行后续操作。由此可见,传统的解决方案一方面容易导致单点故障 和性能瓶颈,另一方面也容易导致更长的操作延迟。

        针对这一问题,Ceph彻底放弃了基于查表的数据寻址方式,而改用基于计算的方式。简言之,任何一个Ceph存储系统的客户端程序,仅仅使用不定期更新的 少量本地元数据,加以简单计算,就可以根据一个数据的ID决定其存储位置。对比之后可以看出,这种方式使得传统解决方案的问题一扫而空。Ceph的几乎所 有优秀特性都是基于这种数据寻址方式实现的。

4. 系统结构

Ceph存储系统的逻辑层次结构如下图所示。

Ceph系统逻辑层次结构

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

        (1)基础存储系统RADOS(Reliable, Autonomic, Distributed Object Store,即可靠的、自动化的、分布式的对象存储)

        顾 名思义,这一层本身就是一个完整的对象存储系统,所有存储在Ceph系统中的用户数据事实上最终都是由这一层来存储的。而Ceph的高可靠、高可扩展、高 性能、高自动化等等特性本质上也是由这一层所提供的。因此,理解RADOS是理解Ceph的基础与关键。

        物理上,RADOS由大量的存储设备节点组层,每个节点拥有自己的硬件资源(CPU、内存、硬盘、网络),并运行着操作系统和文件系统。4.2、4.3节将对RADOS进行展开介绍。

        (2)基础库librados

        这一层的功能是对RADOS进行抽象和封装,并向上层提供API,以便直接基于RADOS(而不是整个Ceph)进行应用开发。特别要注意的是,RADOS是一个对象存储系统,因此,librados实现的API也只是针对对象存储功能的。

        RADOS采用C++开发,所提供的原生librados API包括C和C++两种,其文档参见[]。物理上,librados和基于其上开发的应用位于同一台机器,因而也被称为本地API。应用调用本机上的librados API,再由后者通过socket与RADOS集群中的节点通信并完成各种操作。

        (3)高层应用接口

        这 一层包括了三个部分:RADOS GW(RADOS Gateway)、 RBD(Reliable Block Device)和Ceph FS(Ceph File System),其作用是在librados库的基础上提供抽象层次更高、更便于应用或客户端使用的上层接口。

        其 中,RADOS GW是一个提供与Amazon S3和Swift兼容的RESTful API的gateway,以供相应的对象存储应用开发使用。RADOS GW提供的API抽象层次更高,但功能则不如librados强大。因此,开发者应针对自己的需求选择使用。

        RBD则提供了一个标准的块设备接口,常用于在虚拟化的场景下为虚拟机创建volume。目前,Red Hat已经将RBD驱动集成在KVM/QEMU中,以提高虚拟机访问性能。

        Ceph FS是一个POSIX兼容的分布式文件系统。由于还处在开发状态,因而Ceph官网并不推荐将其用于生产环境中。

        (4)应用层

        这一层就是不同场景下对于Ceph各个应用接口的各种应用方式,例如基于librados直接开发的对象存储应用,基于RADOS GW开发的对象存储应用,基于RBD实现的云硬盘等等。



阅读(997) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~