标签：ceph
前言：
笔者在之前的《从PowerVM，KVM到Docker：存储池的配置与调优-第一篇》中，分享了PowerVM下存储池的配置和调优的方法。在X86虚拟化和云时代，Ceph具有天生的优势，因此本文着重介绍Ceph的原理和架构。同时，本文也作为《从PowerVM，KVM到Docker：存储池的配置与调优-第二篇》而存在。
Ceph的前世
2014年，红帽收购Inktank（Inktank主要提供基于Ceph的企业级产品），此次收购后，红帽成为最大的开源存储产品提供商，包括对象存储、块存储和文件存储。红帽在Ceph开源项目上的代码贡献量上可以说是一骑绝尘。
从存储虚拟化软件谈起
笔者此前做的比较多的具有某些SDS特性的产品有几种：VxVM, GPFS, vSAN。
笔者做VxVM的方案大概是在2008年左右。当时的方案在Solaris操作系统上，通过VxVM，给两个JBOD做RAID10（Stripe-Mirror）。这种方式是以文件系统的形式给OS使用。
在2010-2011年，笔者做了一些GPFS的实施。GPFS利用共享存储的LUN，创建共享文件系统。存储可以异构，磁盘阵列和JBOD都可以。关注GPFS架构和性能的同学，可参照之前笔者的文档：http://www.ibm.com/developerworks/cn/aix/library/1210_weixy_gpfs43/。GPFSShare Nothing结构（GPFS File Placement Optimizer）更适用于大数据平台，笔者无深入了解。
2015-2016年，笔者做了一些vSAN的研究和PoC。vSAN利用服务器的本地磁盘，利用VMFS-L/vSANFS，对这些磁盘做格式化，以块设备的方式给服务器上的虚拟使用（VMDK存放在vSANFS上）。
近年来，对象对象存储的概念逐渐火热起来。OpenStack的Swift提供的就是对象存储的功能。
每种技术，各有其优劣势，也有不同的适用场景，存在就有存在的理由。但是，在云时代，很多很多时候要求的是统一门户的概念，这不光是云管平台，存储也应该如此。
很幸运，Ceph出现了。
Ceph储存数据本质
Ceph本质上是一种对象存储。对外提供三种访问方式：
Object：兼容Swift和S3的API
Block：支持精简配置、快照、克隆
File：Posix接口，支持快照
下图是Ceph内部工作机制，这与对外接口无关。也就是说，向Ceph中存放一个文件，无论是来自CephFS，块设备或者对象方式，在内部存放都按照如下的逻辑进行。
下面介绍一个PG的概念：
一个文件，例如16M，向ceph存放文件的时候，会被拆分成4个对象，每个4M。然后PG中的对象再存放到不同的OSD上。
那么有人会问，PG的作用是什么？没有PG,一个文件被拆成4个对象，不是也可以直接存放到OSDs上么?
解释如下：
当我们向ceph集群中存放一个文件，这个对象会被拆成几个对象。对象大小默认4MB。我们通过对象的元数据，我们可以找到这些对象。这些对象被存放到不同的PG中。用这种分组的方式，可以将很多文件的对象分组，在找对象的时候，先找PG，实现间接寻址，从而减少每个对象元数据的数量。或者说，有了PG以后，我们再找文件的对象时，就不用挨着OSD去找了。但PG需要一点CPU和内存的开销。一般一个OSD上PG的数量一般在100左右。
例如下图实验环境，ceph集群有3个OSD，320个PG。
Pool的概念：
Crush算法
ceph内部存放数据的算法使用Crush。全称是：Controlled Replication Under Scalable Hashing。与传统的数据存放方式不同，在Crush算法下，数据的放置不依赖于元数据服务器。CRUSH只需要一个简洁而层次清晰的设备描述，包括存储集群和副本放置策略。这种方法有两个关键的优点:首先,它是完全分布式的,在这个大系统的中的任何一方都可以独立计算任何对象的位置;第二,当pg和osd确定过后，特定数据的放置位置也就确定了，除非这两者发生变动。
CRUSH算法还可以很好的将数据的不同副本放到不同的故障域中。不同的故障域可以设置成在不同机架的服务器上，最大程度地实现高可用。
副本数设置
设置数据的副本是为了保证高可用，这点每种技术都是一样的。比如vg mirror，ASM mirror，vSAN副本等等。
有人写过CEPH 可靠性的计算方法分析，在文章中，作者举例ceph集群有三个节点，副本数为3的情况下，数据的可靠性理论值为9个9。（http://www.oschina.net/question/12_223909）
Ceph中，副本数量没有限制，但从成本和高可用性综合考虑，生产商副本数设置为3应该是比较合理的。
Ceph集群
无论是GPFS，还是vSAN，还是ceph，都存在存储集群的概念。提到ceph集群，会提到一个词RADOS，这其实是五个单词的缩写。
Ceph集群角色有：monitor和OSD server。Monitor负责监控集群和维护集群的稳定状态。OSD server则提供存储资源，也就是OSD。在生产环境中，monitor至少是三个，并且必须为奇数个。
在实验环境中有三个服务器组成ceph集群。三个节点既是OSD server，又是monitor。通过下面命令做一下简单的了解。节点名称分别为:node1,node2,node3。IP分别为192.168.0.101/102/103。
创建集群的步骤：
在终端上配置ceph集群的部署文件：
执行配置：
接下来生成ceph的监控配置文件。
查看ceph集群的状态，可以看到集群有三个monitor节点。健康状态为error的原因是，现在还没有配置OSD server。
创建osd servers：
查看OSD servers：
查看集群状态：
查看目前已经存在的pool
查看集群中所有pool的副本尺寸：
查看集群monitor的情况，如下两条命令都可以：
查看参与投票节点，以及leader：
Ceph的对外服务方式
前文已经提到，ceph对外可以提供块设备，文件系统和对象存储。我们依次说明。
RBD（块设备方式）
首先看一下块设备的访问方式，简称为RBD，也就是RADOS Block Device。
为了方便理解，请参照以下的实验记录：
首先在ceph集群中创建名字为davidwei的128M rbd并进行查看：
Client端上加载rbd模块：
[root@client-55b4 ceph-deploy]# modprobe rbd
在client端上映射名为davidwei的rbd设备。
至此，rbd设备在client上被识别成块设备。
查看该设备文件类型和大小：
截止到目前，如果client中可以直接使用裸设备的应用，就可以调用/dev/rbd0设备了。
我们在试验中，将其配置为文件系统，然后mount到本地，然后通过文件系统访问方式存放数据。
# mkfs.ext4 /dev/rbd0
# mkdir /mnt/rbd
# mount /dev/rbd0 /mnt/rbd
尝试写入一个文件：
结论：Ceph RBD的方式，适用于传统的块设备访问方式，OS识别到设备以后，可以直接通过应用调用，或者创建文件系统进行访问。
Ceph内部数据操作演示
本小节通过调用ceph内部的机制，展示使用对象的方式存储和获取文件。以说明为什么说Ceph内部是以对象的方式存取文件的。
新建一个文件，读者一定要注意试验中文件创建的时间：
将本地OS的文件以对象的方式存到ceph中，然后再将其获取下来，并命名成另外一个文件：
查看pool和对象文件在pool中的位置：
对象方式
应用访问数据有两种方式：
1.通过调用software vendor的API。如果采用这种方式，那么应用需要直接调用ceph的API。
2.调用restful API。使用这种方式需要连接到一个Gateway。比如通过swift
Gataway支持的协议有两种，亚马逊的S3和swift。由于篇幅有限，本部分不进行demo展示，后续文章将进行说明。
文件系统方式：
文件系统访问方式，目的是替换传统的NAS和NFS。理解起来相对比较简单。
详细步骤参照：http://docs.ceph.org.cn/cephfs/createfs/
创建cephfs文件系统：
查看文件系统：
本地mount，当然，client端也可以进行mount。
结论：通过Cephfs，客户可以使用传统的NAS或者NFS的方式和存放和读取文件。
通过本文的描述，读者应该大致了解了Ceph的工作原理。无论从哪方面讲，Ceph都是适用于云时代的三合一SDS解决方案。
本文出自 “11674750” 博客，谢绝转载！
标签：ceph
原文地址：http://11684750.blog.51cto.com/11674750/1785992
