文档章节

“Ceph浅析”系列之三——Ceph的设计思想(转载)

shadowalker911
 shadowalker911
发布于 2015/01/23 17:53
字数 2337
阅读 132
收藏 1
点赞 0
评论 0

3.1    Ceph针对的目标应用场景

        理解Ceph的设计思想,首先还是要了解Sage设计Ceph时所针对的目标应用场景,换言之,“做这东西的目的是啥?”

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

        在大数据口号深入人心的今天,PB已经远远不是一个激动人心的系统设计目标了。但是,应该指出,Ceph项目起源于04年。那是一个商用处理器以单核为主流,常见硬盘容量只有几十GB的年代。这和现在动辄6核12线程还要双处理器、单块硬盘3TB已经司空见惯的情况是不可同日而语的。因此,理解这个设计目标,应该考虑当时的实际情况。当然,如前所述,Ceph的设计并没有理论上限,所以PB级别并不是实际应用的容量限制。

        在Sage的思想中,对于这样一个大规模的存储系统,是不能以静态的眼光来看待的。对于其动态特性,笔者概括为如下三个“变化”:

  • 存储系统规模的变化:这样大规模的存储系统,往往不是在建设的第一天就能预料到其最终的规模,甚至是根本就不存在最终规模这个概念的。只能是随着业务的不断开展,业务规模的不断扩大,让系统承载越来越大的数据容量。这也就意味系统的规模自然随之变化,越来越大。

  • 存储系统中设备的变化:对于一个由成千上万个节点构成的系统,其节点的故障与替换必然是时常出现的情况。而系统一方面要足够可靠,不能使业务受到这种频繁出现的硬件及底层软件问题的影响,同时还应该尽可能智能化,降低相关维护操作的代价。

  • 存储系统中数据的变化:对于一个大规模的,通常被应用于互联网应用中的存储系统,其中存储的数据的变化也很可能是高度频繁的。新的数据不断写入,已有数据被更新、移动乃至删除。这种场景需求也是设计时必须予以考虑的。

        上述三个“变化”就是Ceph目标应用场景的关键特征。Ceph所具备的各种主要特性,也都是针对这些场景特征所提出的。

3.2    针对目标应用场景所提出的预期技术特性

        针对上述应用场景,Ceph在设计之初的几个技术特性是:

  • 高可靠性。所谓“高可靠”,首先是针对存储在系统中的数据而言,也即,尽可能保证数据不会丢失。其次,也包括数据写入过程中的可靠性,也即,在用户将数据写入Ceph存储系统的过程中,不会因为意外情况的出现造成数据丢失。

  • 高度自动化。具体包括了数据的自动replication,自动re-balancing,自动failure detection和自动failure recovery。总体而言,这些自动化特性一方面保证了系统的高度可靠,一方面也保障了在系统规模扩大之后,其运维难度仍能保持在一个相对较低的水平。

  • 高可扩展性。这里的“可扩展”概念比较广义,既包括了系统规模和存储容量的可扩展,也包括了随着系统节点数增加的聚合数据访问带宽的线性扩展,还包括了基于功能丰富强大的底层API提供多种功能、支持多种应用的功能性可扩展。

3.3    针对预期技术特性所提出的设计思路

        针对3.2节中介绍的预期技术特性,Sage对于Ceph的设计思路基本上可以概括为以下两点:

  • 充分发挥存储设备自身的计算能力。事实上,采用具有计算能力的设备(最简单的例子就是普通的服务器)作为存储系统的存储节点,这种思路即便在当时来看也并不新鲜。但是,Sage认为这些已有系统基本上都只是将这些节点作为功能简单的存储节点。而如果充分发挥节点上的计算能力,则可以实现前面提出的预期特性。这一点成为了Ceph系统设计的核心思想。

  • 去除所有的中心点。一旦系统中出现中心点,则一方面引入单点故障点,另一方面也必然面临当系统规模扩大时的规模和性能瓶颈。除此之外,如果中心点出现在数据访问的关键路径上,事实上也必然导致数据访问的延迟增大。而这些显然都是Sage所设想的系统中不应该出现的问题。虽然在大多数系统的工程实践中,单点故障点和性能瓶颈的问题可以通过为中心点增加备份加以缓解,但Ceph系统最终采用创新的方法更为彻底地解决了这个问题。

3.4    支撑设计思路实现的关键技术创新

        无论多么新颖奇妙的设计思路,最终落地必定需要有技术实力的支撑。而这也正是Ceph最为闪亮的地方。

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

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

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

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

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

        至此为止,Ceph的设计思想已经得到了较为全面深入的介绍。此后几篇文章将依次介绍Ceph的系统架构、工作原理与流程、主要特性等内容,并联系OpenStack,将Ceph和Swift加以对比分析。

说明:转载请注明出处。谢谢。

© 著作权归作者所有

共有 人打赏支持
shadowalker911
粉丝 6
博文 28
码字总数 3041
作品 0
徐汇
“CEPH浅析”系列之三——CEPH的设计思想

分析开源项目,时常遇到的一个问题就是资料不足。有时间写代码的大牛们通常是都是没有时间或者根本不屑于写文档的。而不多的文档通常又是使用手册之类的东西。即便偶尔有设计文档通常也是语焉...

Yason_Luo ⋅ 2014/04/02 ⋅ 0

Ceph 浅析(上):概况与设计思想

摘要:其命名和UCSC(Ceph 的诞生地)的吉祥物有关,这个吉祥物是 “Sammy”,一个香蕉色的蛞蝓,就是头足类中无壳的软体动物。这些有多触角的头足类动物,是对一个分布式文件系统高度并行的...

红薯 ⋅ 2014/04/01 ⋅ 3

“Ceph浅析”系列之七——关于Ceph的若干想法

本篇文章的内容,主要是笔者在调研分析Ceph过程中产生的一些思考。因为其中的内容比较自由发散,且大多是笔者的个人见解,故此另启一文进行讨论。 7.1 关于Ceph的性能 目前为止,本系列的文章...

红薯 ⋅ 2014/04/01 ⋅ 2

“CEPH浅析”系列之四——CEPH的结构

本文将从逻辑结构的角度对Ceph进行分析。 4.1 Ceph系统的层次结构 Ceph存储系统的逻辑层次结构如下图所示[1]。 自下向上,可以将Ceph系统分为四个层次: (1)基础存储系统RADOS(Reliable,...

Yason_Luo ⋅ 2014/04/02 ⋅ 9

“Ceph浅析”系列之五——Ceph的工作原理及流程

本 文将对Ceph的工作原理和若干关键工作流程进行扼要介绍。如前所述,由于Ceph的功能实现本质上依托于RADOS,因而,此处的介绍事实上也是针对 RADOS进行。对于上层的部分,特别是RADOS GW和R...

红薯 ⋅ 2014/04/01 ⋅ 2

“Ceph浅析”系列之四——Ceph的结构

本文将从逻辑结构的角度对Ceph进行分析。 4.1 Ceph系统的层次结构 Ceph存储系统的逻辑层次结构如下图所示[1]。 自下向上,可以将Ceph系统分为四个层次: (1)基础存储系统RADOS(Reliable,...

红薯 ⋅ 2014/04/01 ⋅ 0

Ceph浅析(中):结构、工作原理及流程

Ceph的结构 Ceph系统的层次结构 Ceph存储系统的逻辑层次结构如下图所示: 自下向上,可以将Ceph系统分为四个层次: (1)基础存储系统RADOS(Reliable, Autonomic, Distributed Object Store...

wangdy ⋅ 2016/07/10 ⋅ 0

从传统运维到云运维演进历程之软件定义存储(六)完结

回到最初的Ceph运维工程师的问题,本系列讲述的是传统运维向新一代云运维转型之软件定义存储部分的转型,运维是企业业务系统从规划、设计、实施、交付到运维的最后一个步骤,也是重要的步骤。...

Devin ⋅ 2016/12/20 ⋅ 0

从传统运维到云运维演进历程之软件定义存储(二)

上回书说到一般企业使用Ceph会经历几个关卡:硬件选型 —— 部署调优—— 性能测试 架构灾备设计 —— 部分业务上线测试 —— 运行维护(故障处理、预案演练等)。 今天来重点讲下部署调优关...

Devin ⋅ 2016/09/20 ⋅ 0

如何找到存在Ceph里面的文件

前段时间群友有人问,怎么能找到存在Ceph里面的文件呢,我说为什么要这样问,他说要给领导演示下Ceph的高可用,某个节点down掉之后不影响数据丢失。下面针对于这个前提,做了如下实验,感兴趣...

Devin ⋅ 2017/03/08 ⋅ 0

没有更多内容

加载失败,请刷新页面

加载更多

下一页

MySQL主从复制原理、半同步操作步骤及原理

1.1 企业Linux运维场景数据同步方案 1.1.1 文件级别的异机同步方案 1、scp/sftp/nc 命令可以实现远程数据同步。 2、搭建ftp/http/svn/nfs 服务器,然后在客户端上也可以把数据同步到服务器。...

xiaomin0322 ⋅ 1分钟前 ⋅ 0

Oracle10g 数据及文件迁移过程[原]

QL*Plus: Release 10.2.0.1.0 - Production on 星期三 5月 11 10:22:35 2011 Copyright (c) 1982, 2005, Oracle. All rights reserved. 连接到: Oracle Database 10g Enterprise Edition Re......

harrypotter ⋅ 6分钟前 ⋅ 0

nginx安装

1:安装工具包 wget、vim和gcc yum install -y wget yum install -y vim-enhanced yum install -y make cmake gcc gcc-c++ 2:下载nginx安装包 wget http://nginx.org/download/nginx-1......

壹丶贰 ⋅ 9分钟前 ⋅ 0

ideaVim安装及配置

1.安装插件 File-Settings-Plugins,Browse Repositories,输入ideavim,安装。 重启后,在Tools-Vim Emulator启用。 2.快捷键设置 ideaViim键与idea快捷键有冲突,可以在Settings-Other Se...

Funcy1122 ⋅ 13分钟前 ⋅ 0

MySQL中B+Tree索引原理

B+树索引是B+树在数据库中的一种实现,是最常见也是数据库中使用最为频繁的一种索引。B+树中的B代表平衡(balance),而不是二叉(binary),因为B+树是从最早的平衡二叉树演化而来的。在讲B...

浮躁的码农 ⋅ 28分钟前 ⋅ 0

两道面试题,带你解析Java类加载机制

在许多Java面试中,我们经常会看到关于Java类加载机制的考察,例如下面这道题: class Grandpa{ static { System.out.println("爷爷在静态代码块"); }} cl...

1527 ⋅ 32分钟前 ⋅ 0

SpringCloud(Data Flow)

dataflow-server

赵-猛 ⋅ 42分钟前 ⋅ 0

深入理解Java虚拟机

这本书我读到第8章,之后就是在读不下去了。 读到后面是一种痛苦的体验,太多的东西是不全面的,大量的专有名词是没有解释的,读到最后很多东西仅仅是一个侧面,所以我觉得,这本书不适合初学...

颖伙虫 ⋅ 48分钟前 ⋅ 0

NanoPi NEO core/ Ubuntu16.04单网卡配置3个IP地址(2个静态,1个动态)

配置 root@NanoPi-NEO-Core:/etc/network# cat interfacesauto loiface lo inet loopbackallow-hotplug eth0iface eth0 inet static address 172.31.188.249 netmask 255.......

SamXIAO ⋅ 今天 ⋅ 0

三步为你的App集成LivePhoto功能

摘要:LivePhoto是iOS9新推出的一种拍照方式,类似于拍摄Gif图或录制视频片段生成图片。如果没有画面感,可以联想《哈利波特》霍格沃茨城堡的壁画,哈哈,很炫酷有木有,但坑爹的是只有iphone6S以...

壹峰 ⋅ 今天 ⋅ 0

没有更多内容

加载失败,请刷新页面

加载更多

下一页

返回顶部
顶部