Ceph分布式存储工作原理 及 部署介绍（基于ceph-delopy）

此文选自大佬博文：https://www.cnblogs.com/kevingrace/p/8387999.html

1.存储的相关介绍

存储根据其类型，可分为块存储，对象存储和文件存储。在主流的分布式存储技术中，HDFS/GPFS/GFS属于文件存储，Swift属于对象存储，而Ceph可支持块存储、对象存储和文件存储，故称为统一存储。

关于块存储和文件存储，对象存储的具体介绍和区别可以参考我的这篇文章https://www.cnblogs.com/qingbaizhinian/p/13697867.html#_label3

 

2.Ceph基本介绍

Ceph是一个分布式存储系统，诞生于2004年，最早致力于开发下一代高性能分布式文件系统的项目。经过多年的发展之后，已得到众多云计算和存储厂商的支持，成为应用最广泛的开源分布式存储平台。Ceph源码下载：http://ceph.com/download/ 。随着云计算的发展，ceph乘上了OpenStack的春风，进而成为了开源社区受关注较高的项目之一。Ceph可以将多台服务器组成一个超大集群，把这些机器中的磁盘资源整合到一块儿，形成一个大的资源池（PB级别），然后按需分配给应用使用。

1.Ceph的主要架构

 

 

 <1> Ceph的最底层是RADOS（分布式对象存储系统），它具有可靠、智能、分布式等特性，实现高可靠、高可拓展、高性能、高自动化等功能，并最终存储用户数据。RADOS系统主要由两部分组成，分别是OSD和Monitor。
<2> RADOS之上是Librados，Librados是一个基础库，支持多种编程语言，比如C、C++、Python等。这一层的功能是对RADOS进行抽象和封装，并向上层提供API，以便直接基于RADOS（而不是整个Ceph）进行应用开发。
<3> 基于Librados层开发的有三种接口，分别是radosgw（对象存储接口）、librbd（块存储接口）和文件系统接口：
radosgw（对象存储接口）：是一套基于当前流行的RESTFUL协议的网关，支持对象存储，兼容S3和Swift，以供相应的对象存储应用开发使用
 librbd（块存储接口）：提供分布式的块存储设备接口，支持块存储。提供了一个标准的块设备接口，常用于在虚拟化的场景下为虚拟机创建volume。目前，Red Hat已经将RBD驱动集成在KVM/QEMU中，以提高虚拟机访问性能。这两种方式目前在云计算中应用的比较多。
文件系统接口：CephFS是内核态程序，向外界提供了POSIX接口，用户可以通过客户端直接挂载使用，所以无需调用用户空间的librados库。它通过内核中net模块来与Rados进行交互，MDS提供兼容POSIX的文件系统，支持文件存储。

 

2.Ceph的功能模块

 

 Ceph的核心组件包括Client客户端、MON监控服务、MDS元数据服务、OSD存储服务，各组件功能如下：
<1> Client客户端：负责存储协议的接入，节点负载均衡。

<2> MON（Monitor）监控服务：监控整个集群Cluster map的状态，维护集群的cluster MAP二进制表，保证集群数据的一致性，维护集群状态的映射，包括监视器映射，管理器映射，OSD映射，MDS映射和CRUSH映射。这些映射是Ceph守护程序相互协调所需的关键群集状态。监视器还负责管理守护程序和客户端之间的身份验证。通常至少需要三个监视器才能实现冗余和高可用性。

<3> MDS元数据服务（可选）：为Ceph文件系统提供元数据计算，缓存与同步（也就是说，Ceph块设备和Ceph对象存储不使用MDS）。在ceph中，元数据也是存储在osd节点中的，mds类似于元数据的代理缓存服务器。Mds进程并不是必须的进程。只有需要使用CEPHFS（ceph的文件系统），才需要配置MDS节点。

<4> OSD（对象存储守护程序）：主要功能是存储数据、复制数据、平衡数据、恢复数据，以及与通过检查其他Ceph OSD守护程序的心跳来向Ceph监视器和管理器提供一些监视信息。通常至少需要3个Ceph OSD才能实现冗余和高可用性。

通常来说，一块磁盘和该磁盘对应的守护进程称为一个OSD。守护进程的作用是从该磁盘读取和写入数据。该磁盘可以是一个硬盘或者SSD盘或者RAID0，总之是一个逻辑磁盘。如果一个节点只有一个守护进程和对应的磁盘，那么该OSD就成了一个节点。通常一个节点有多个OSD守护进程和多个磁盘，所以通常来说OSD不是一个节点。

Ceph要求必须是奇数个Monitor监控节点，一般建议至少是3个（如果是自己私下测试玩玩的话，可以是1个，但是生产环境绝不建议1个）用于维护和监控整个集群的状态，每个Monitor都有一个Cluster Map，只要有这个Map，就能够清楚知道每个对象存储在什么位置了。客户端会先tcp连接到Monitor，从中获取Cluster Map，并在客户端进行计算，当知道对象的位置后，再直接与OSD通信（去中心化的思想）。OSD节点平常会向Monitor节点发送简单心跳，只有当添加、删除或者出现异常状况时，才会自动上报信息给Monitor。

MDS是可选的，只有需要使用Ceph FS的时候才需要配置MDS节点。在Ceph中，元数据也是存放在OSD中的，MDS只相当于元数据的缓存服务器。

在Ceph中，如果要写数据，只能向主OSD写，然后再由主OSD向从OSD同步地写，只有当从OSD返回结果给主OSD后，主OSD才会向客户端报告写入完成的消息。如果要读数据，不会使用读写分离，而是也需要先向主OSD发请求，以保证数据的强一致性。

3.Ceph架构之RADOS说明

RADOS (Reliable, Autonomic Distributed Object Store) 是Ceph的核心之一，作为Ceph分布式文件系统的一个子项目，特别为Ceph的需求设计，能够在动态变化和异质结构的存储设备机群之上提供一种稳定、可扩展、高性能的单一逻辑对象(Object)存储接口和能够实现节点的自适应和自管理的存储系统。在传统分布式存储架构中，存储节点往往仅作为被动查询对象来使用，随着存储规模的增加，数据一致性的管理会出现很多问题。而新型的存储架构倾向于将基本的块分配决策和安全保证等操作交给存储节点来做，然后通过提倡客户端和存储节点直接交互来简化数据布局并减小io瓶颈。

RADOS就是这样一个可用于PB级规模数据存储集群的可伸缩的、可靠的对象存储服务。它包含两类节点：存储节点、管理节点。它通过利用存储设备的智能性，将诸如一致性数据访问、冗余存储、错误检测、错误恢复分布到包含了上千存储节点的集群中，而不是仅仅依靠少数管理节点来处理。

RADOS中的存储节点被称为OSD(object storage device)，它可以仅由很普通的组件来构成，只需要包含CPU、网卡、本地缓存和一个磁盘或者RAID，并将传统的块存储方式替换成面向对象的存储。在PB级的存储规模下，存储系统一定是动态的：系统会随着新设备的部署和旧设备的淘汰而增长或收缩，系统内的设备会持续地崩溃和恢复，大量的数据被创建或者删除。

RADOS通过 cluster map来实现这些特性，cluster map会被复制到集群中的所有部分（存储节点、控制节点，甚至是客户端），并且通过怠惰地传播小增量更新而更新。Cluster map中存储了整个集群的数据的分布以及成员。通过在每个存储节点存储完整的Cluster map，存储设备可以表现的半自动化，通过peer-to-peer的方式（比如定义协议）来进行数据备份、更新，错误检测、数据迁移等等操作。这无疑减轻了占少数的monitor cluster（管理节点组成的集群）的负担。

RADOS设计如下：

 

 一个RADOS系统包含大量的OSDs 和 很少的用于管理OSD集群成员的monitors。OSD的组成如简介所说。而monitor是一些独立的进程，以及少量的本地存储，monitor之间通过一致性算法保证数据的一致性。

Cluster Map
存储节点集群通过monitor集群操作cluster map来实现成员的管理。cluster map 描述了哪些OSD被包含进存储集群以及所有数据在存储集群中的分布。cluster map不仅存储在monitor节点，它被复制到集群中的每一个存储节点，以及和集群交互的client。当因为一些原因，比如设备崩溃、数据迁移等，cluster map的内容需要改变时，cluster map的版本号被增加，map的版本号可以使通信的双方确认自己的map是否是最新的，版本旧的一方会先将map更新成对方的map，然后才会进行后续操作。

 

4.Cpeh的资源划分和存储过程的描述

Ceph采用crush算法，在大规模集群下，实现数据的快速、准确存放，同时能够在硬件故障或扩展硬件设备时，做到尽可能小的数据迁移，其原理如下：

<1> 当用户要将数据存储到Ceph集群时，数据先被分割成多个object，(每个object一个object id，大小可设置，默认是4MB），object是Ceph存储的最小存储单元。
<2> 由于object的数量很多，为了有效减少了Object到OSD的索引表、降低元数据的复杂度，使得写入和读取更加灵活，引入了pg(Placement Group )：PG(归置组）用来管理object，每个object通过Hash，映射到某个pg中，一个pg可以包含多个object。
<3> Pg再通过CRUSH计算，映射到osd中。如果是三副本的，则每个pg都会映射到三个osd，保证了数据的冗余。

Ceph存储过程描述

 

每台服务器都有好几块磁盘（sda,sdb,sdc等），磁盘又可以进一步分区（sda1,sda2等）。Ceph中最基本的进程就是OSD(对象存储设备)，每个磁盘对应一个OSD。如果用户通过客户端想要存储一个文件，那么在RADOS中，该文件实际上会分为一个个4M块大小的对象。每个文件都一个文件ID(例如A),那么这些对象的ID就是（A0,A1,A2等）。然而在分布式储存系统中，有成千上万个对象，光遍历就要花很长的时间，所以对象会先通过hash-取模运算，存放到一个PG（Place Group）中，PG相当于数据库中的索引（PG的数量是固定的，不会随着OSD的增加或者删除而改变），这样只需要首先定位到PG位置，然后在PG中查询对象即可，大大提高了查询效率。之后PG中的对象又会根据设置的副本数量进行复制，并根据Crush算法存储到OSD节点上。

 

无论使用哪种存储方式（对象、块、挂载），存储的数据都会被切分成对象（Objects）。Objects size大小可以由管理员调整，通常为2M或4M。每个对象都会有一个唯一的OID，由ino与ono生成，虽然这些名词看上去很复杂，其实相当简单。ino即是文件的File ID，用于在全局唯一标示每一个文件，而ono则是分片的编号。比如：一个文件FileID为A，它被切成了两个对象，一个对象编号0，另一个编号1，那么这两个文件的oid则为A0与A1。Oid的好处是可以唯一标示每个不同的对象，并且存储了对象与文件的从属关系。由于ceph的所有数据都虚拟成了整齐划一的对象，所以在读写时效率都会比较高。

 

但是对象并不会直接存储进OSD中，因为对象的size很小，在一个大规模的集群中可能有几百到几千万个对象。这么多对象光是遍历寻址，速度都是很缓慢的；并且如果将对象直接通过某种固定映射的哈希算法映射到osd上，当这个osd损坏时，对象无法自动迁移至其他osd上面（因为映射函数不允许）。为了解决这些问题，ceph引入了归置组的概念，即PG。

 

PG是一个逻辑概念，我们linux系统中可以直接看到对象，但是无法直接看到PG。它在数据寻址时类似于数据库中的索引：每个对象都会固定映射进一个PG中，所以当我们要寻找一个对象时，只需要先找到对象所属的PG，然后遍历这个PG就可以了，无需遍历所有对象。而且在数据迁移时，也是以PG作为基本单位进行迁移，ceph不会直接操作对象。

 

对象时如何映射进PG的？还记得OID么？首先使用静态hash函数对OID做hash取出特征码，用特征码与PG的数量去模，得到的序号则是PGID。由于这种设计方式，PG的数量多寡直接决定了数据分布的均匀性，所以合理设置的PG数量可以很好的提升CEPH集群的性能并使数据均匀分布。

 

最后PG会根据管理员设置的副本数量进行复制，然后通过crush算法存储到不同的OSD节点上（其实是把PG中的所有对象存储到节点上），第一个osd节点即为主节点，其余均为从节点。

 

5.Ceph的特点

<1> Ceph支持对象存储、块存储和文件存储服务，故称为统一存储。
<2> 采用CRUSH算法，数据分布均衡，并行度高，不需要维护固定的元数据结构；
<3> 数据具有强一致，确保所有副本写入完成才返回确认，适合读多写少场景；
<4> 去中心化，MDS之间地位相同，无固定的中心节点

Ceph存在一些缺点
<1> 去中心化的分布式解决方案，需要提前做好规划设计，对技术团队的要求能力比较高。
<2> Ceph扩容时，由于其数据分布均衡的特性，会导致整个存储系统性能的下降。

Ceph相比于其他存储方案的优势
<1> CRUSH算法：Crush算法是ceph的两大创新之一，简单来说，Ceph摒弃了传统的集中式存储元数据寻址的方案，转而使用CRUSH算法完成数据的寻址操作。CRUSH在一致性哈希基础上很好的考虑了容灾域的隔离，能够实现各类负载的副本放置规则，例如跨机房、机架感知等。Crush算法有相当强大的扩展性，理论上支持数千个存储节点。
<2> 高可用：Ceph中的数据副本数量可以由管理员自行定义，并可以通过CRUSH算法指定副本的物理存储位置以分隔故障域，支持数据强一致性； Ceph可以忍受多种故障场景并自动尝试并行修复；Ceph支持多份强一致性副本，副本能够垮主机、机架、机房、数据中心存放。所以安全可靠。Ceph存储节点可以自管理、自动修复。无单点故障，容错性强。
<3> 高性能：因为是多个副本，因此在读写操作时候能够做到高度并行化。理论上，节点越多，整个集群的IOPS和吞吐量越高。另外一点Ceph客户端读写数据直接与存储设备(osd) 交互。在块存储和对象存储中无需元数据服务器。
<4> 高扩展性：Ceph不同于Swift，客户端所有的读写操作都要经过代理节点。一旦集群并发量增大时，代理节点很容易成为单点瓶颈。Ceph本身并没有主控节点，扩展起来比较容易，并且理论上，它的性能会随着磁盘数量的增加而线性增长。Ceph扩容方便、容量大。能够管理上千台服务器、EB级的容量。
<5> 特性丰富：Ceph支持三种调用接口：对象存储，块存储，文件系统挂载。三种方式可以一同使用。在国内一些公司的云环境中，通常会采用Ceph作为openstack的唯一后端存储来提升数据转发效率。Ceph是统一存储，虽然它底层是一个分布式文件系统，但由于在上层开发了支持对象和块的接口，所以在开源存储软件中，优势很明显。

Ceph提供3种存储方式分别是对象存储，块存储和文件系统，一般我们主要关心的还是块存储，推荐将虚拟机后端存储从SAN过渡到Ceph。Ceph 现在是云计算、虚拟机部署的最火开源存储解决方案，据统计大概有20%的OpenStack部署存储用的都是Ceph的block storage。

 

6.Ceph集群维护介绍

前面已经介绍了，由若干个monitor共同负责整个RADOS集群中所有OSD状态的发现与记录，并且共同形成cluster map的master版本，然后扩散至全体OSD以及client。OSD使用Cluster map进行数据的维护，而client使用Cluster map进行数据的寻址。monitor并不主动轮询各个OSD的当前状态。相反，OSD需要向monitor上报状态信息。常见的上报有两种情况：一是新的OSD被加入集群，二是某个OSD发现自身或者其他OSD发生异常。在收到这些上报信息后，monitor将更新cluster map信息并加以扩散。

Cluster map的实际内容包括：
<1> Epoch，即版本号。cluster map的epoch是一个单调递增序列。epoch越大，则cluster map版本越新。因此，持有不同版本cluster map的OSD或client可以简单地通过比较epoch决定应该遵从谁手中的版本。而monitor手中必定有epoch最大、版本最新的cluster map。当任意两方在通信时发现彼此epoch值不同时，将默认先将cluster map同步至高版本一方的状态，再进行后续操作。
<2> 各个OSD的网络地址。
<3> 各个OSD的状态。OSD状态的描述分为两个维度：up或者down（表明OSD是否正常工作），in或者out（表明OSD是否在至少一个PG中）。因此，对于任意一个OSD，共有四种可能的状态：
-   up且in：说明该OSD正常运行，且已经承载至少一个PG的数据。这是一个OSD的标准工作状态；
-   up且out：说明该OSD正常运行，但并未承载任何PG，其中也没有数据。一个新的OSD刚刚被加入Ceph集群后，便会处于这一状态。而一个出现故障的OSD被修复后，重新加入Ceph集群时，也是处于这一状态；
-   down且in：说明该OSD发生异常，但仍然承载着至少一个PG，其中仍然存储着数据。这种状态下的OSD刚刚被发现存在异常，可能仍能恢复正常，也可能会彻底无法工作；
-   down且out：说明该OSD已经彻底发生故障，且已经不再承载任何PG。
<4> CRUSH算法配置参数。表明了Ceph集群的物理层级关系（cluster hierarchy），位置映射规则（placement rules）。
根据cluster map的定义可以看出，其版本变化通常只会由"3"和"4"两项信息的变化触发。而这两者相比，"3"发生变化的概率更高一些。

一个新的OSD上线后，首先根据配置信息与monitor通信。Monitor将其加入cluster map，并设置为up且out状态，再将最新版本的cluster map发给这个新OSD。收到monitor发来的cluster map之后，这个新OSD计算出自己所承载的PG（为简化讨论，此处我们假定这个新的OSD开始只承载一个PG），以及和自己承载同一个PG的其他OSD。然后，新OSD将与这些OSD取得联系。如果这个PG目前处于降级状态（即承载该PG的OSD个数少于正常值，如正常应该是3个，此时只有2个或1个。这种情况通常是OSD故障所致），则其他OSD将把这个PG内的所有对象和元数据复制给新OSD。数据复制完成后，新OSD被置为up且in状态。而cluster map内容也将据此更新。这事实上是一个自动化的failure recovery过程。当然，即便没有新的OSD加入，降级的PG也将计算出其他OSD实现failure recovery。

如果该PG目前一切正常，则这个新OSD将替换掉现有OSD中的一个（PG内将重新选出Primary OSD），并承担其数据。在数据复制完成后，新OSD被置为up且in状态，而被替换的OSD将退出该PG（但状态通常仍然为up且in，因为还要承载其他PG）。而cluster map内容也将据此更新。这事实上是一个自动化的数据re-balancing过程。如果一个OSD发现和自己共同承载一个PG的另一个OSD无法联通，则会将这一情况上报monitor。此外，如果一个OSD deamon发现自身工作状态异常，也将把异常情况主动上报给monitor。在上述情况下，monitor将把出现问题的OSD的状态设为down且in。如果超过某一预订时间期限，该OSD仍然无法恢复正常，则其状态将被设置为down且out。反之，如果该OSD能够恢复正常，则其状态会恢复为up且in。在上述这些状态变化发生之后，monitor都将更新cluster map并进行扩散。这事实上是自动化的failure detection过程。

对于一个RADOS集群而言，即便由数千个甚至更多OSD组成，cluster map的数据结构大小也并不惊人。同时，cluster map的状态更新并不会频繁发生。即便如此，Ceph依然对cluster map信息的扩散机制进行了优化，以便减轻相关计算和通信压力：首先，cluster map信息是以增量形式扩散的。如果任意一次通信的双方发现其epoch不一致，则版本更新的一方将把二者所拥有的cluster map的差异发送给另外一方。其次，cluster map信息是以异步且lazy的形式扩散的。也即，monitor并不会在每一次cluster map版本更新后都将新版本广播至全体OSD，而是在有OSD向自己上报信息时，将更新回复给对方。类似的，各个OSD也是在和其他OSD通信时，将更新发送给版本低于自己的对方。

基于上述机制，Ceph避免了由于cluster map版本更新而引起的广播风暴。这虽然是一种异步且lazy的机制，但对于一个由n个OSD组成的Ceph集群，任何一次版本更新能够在O(log(n))时间复杂度内扩散到集群中的任何一个OSD上。

一个可能被问到的问题是：既然这是一种异步和lazy的扩散机制，则在版本扩散过程中，系统必定出现各个OSD看到的cluster map不一致的情况，这是否会导致问题？答案是：不会。事实上，如果一个client和它要访问的PG内部的各个OSD看到的cluster map状态一致，则访问操作就可以正确进行。而如果这个client或者PG中的某个OSD和其他几方的cluster map不一致，则根据Ceph的机制设计，这几方将首先同步cluster map至最新状态，并进行必要的数据re-balancing操作，然后即可继续正常访问。

 

7.ceph的版本介绍

 

 

 

 

 

3.Ceph分布式存储部署介绍（ceph-deploy的方式）

1.配置规划和环境主要组件介绍

首先介绍一下 Ceph 安装部署的方法，Ceph 社区提供了三种部署方法：

  • ceph-deploy，一个集群自动化部署工具，使用较久，成熟稳定，被很多自动化工具所集成，可用于生产部署

  • cephadm，较新的集群自动化部署工具，支持通过图形界面或者命令行界面添加节点，目前不建议用于生产环境

  • manual，手动部署，一步步部署 Ceph 集群，支持较多定制化和了解部署细节，安装难度较大

我们采用成熟、简单的 ceph-deploy 实现 Ceph 集群的部署，首先了解一下 ceph-deploy 的架构：

  • admin-node，需要一个安装管理节点，该安装节点集中管控 ceph 集群的安装

  • mon，monitor 节点，即是 Ceph 的监视管理节点，承担 Ceph 集群重要的管理任务，一般需要3或5个节点

  • osd，OSD 即 Object Storage Daemon，实际负责数据存储的节点

规划部署架构图

 

 主要组件介绍：

 

 

 

 

部署环境

系统版本：CentOS Linux release 7.6.1810 (Core)

内核版本：都升级到最新的稳定版本5.4或者4.4版本，不要用centos7自带的3点几版本（升级步骤这里忽略）

机器信息：

主机名 类型 IP
ceph-deploy 部署管理平台 172.31.46.28
node1 Monitor  OSD 172.31.46.63
node2 OSD 172.31.46.67
node3 OSD 172.31.46.26

这里我们需提前在每台主机上设置好主机名，并关闭防火墙和selinux；所有节点最好都配上国内的epel源和base源。（这些我就不做过多演示了）

注意：Ceph Monitors之间默认使用6789端口通信，OSD之间默认用6800:7300范围内的端口通信。Ceph OSD能利用多个网络连接进行与客户端、monitors、其他OSD间的复制和心跳的通信。若需要开启防火墙则必须同时放通相应规则，具体操作见：http://docs.ceph.org.cn/rados/configuration/network-config-ref/

 

2.所有节点NTP配置

ceph集群中的机器都要保证时间一致，不然集群运行起来可能会报错。选择任何一台机器当ntp时间服务器，其他的节点当时间服务器的客户端跟服务器同步时间

#在所有集群和客户端节点安装NTP（下面命令需在所有节点执行）
yum -y install ntp ntpdate
#以ceph-deploy节点为NTP服务端节点，在ceph-deploy节点新建NTP文件。
[root@ceph-deploy ~]# vim /etc/ntp.conf     //有4行server的位置，把那4行server行注释掉，填写以下两行
server 127.127.1.0     # local clock
fudge  127.127.1.0 stratum 10 
[root@ceph-deploy ~]# systemctl start ntpd
[root@ceph-deploy ~]# systemctl status ntpd   //确认打开NTP服务
#在其他节点都执行如下命令修改ntp文件，然后重启同步ceph-deploy节点的时间
vim /etc/ntp.conf             //有4行server的位置，把那4行server行注释掉，填写以下一行
server 172.31.46.28
systemctl restart ntpd

 

3.添加hosts解析和免密钥登录

#所有节点配置hosts文件
vim /etc/hosts
cat /etc/hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
172.31.46.28  ceph-deploy
172.31.46.63  node1
172.31.46.67  node2
172.31.46.26  node3
#管理节点必须能够通过SSH无密码地访问各Ceph节点，建议使用非root用户；
[root@ceph-deploy ~]# useradd manager
[root@ceph-deploy ~]# echo manager | passwd --stdin manager
#通过for循环到各ceph节点上创建cephuser用户，并设置密码。用于跑ceph的守护进程
[root@ceph-deploy ~]# for i in {1..3}; do echo "====node${i}====";ssh root@node${i} 'useradd -d /home/cephuser -m cephuser; echo "cephuser" | passwd --stdin cephuser'; done
#如果上面执行之后报下面的错误，是因为你设的密码不符合各ceph节点的密码策略，建议把密码设的稍微复杂点。
passwd: Authentication token manipulation error
Changing password for user cephuser.
#执行下面命令让ceph用户有免密登录root的权限
[root@ceph-deploy ~]# for i in {1..3}; do echo "====node${i}====";ssh root@node${i} 'echo "cephuser ALL = (root) NOPASSWD:ALL" > /etc/sudoers.d/cephuser'; done
[root@ceph-deploy ~]# for i in {1..3}; do echo "====node${i}====";ssh root@node${i} 'chmod 0440 /etc/sudoers.d/cephuser'; done
#通过下面命令让管理节点可以免密登录到各ceph节点。
[root@ceph-deploy ~]# su - manager
[manager@ceph-deploy ~]$ ssh-keygen -f ~/.ssh/id_rsa -N ''
[manager@ceph-deploy ~]$ ssh-copy-id -i ~/.ssh/id_rsa.pub cephuser@172.31.46.63
[manager@ceph-deploy ~]$ ssh-copy-id -i ~/.ssh/id_rsa.pub cephuser@172.31.46.67
[manager@ceph-deploy ~]$ ssh-copy-id -i ~/.ssh/id_rsa.pub cephuser@172.31.46.26
#修改config后deploy节点所建的用户名登录Ceph节点无需每次指定 --username cephuser ，简化了ssh和scp的用法。
[manager@ceph-deploy ~]$ vim ~/.ssh/config
[manager@ceph-deploy ~]$ cat ~/.ssh/config 
Host node1
   Hostname node1
   User cephuser
Host node2
   Hostname node2
   User cephuser
Host node3
   Hostname node3
   User cephuser
[manager@ceph-deploy ~]$ chmod 600 .ssh/config
#执行下面命令进行测试，发现测试成功
[manager@ceph-deploy ~]$ ssh node1
[cephuser@node1 ~]$ exit

 

4.部署deploy节点

[root@ceph-deploy ~]# vi /etc/yum.repos.d/ceph.repo
#准备ceph的国内yum源
[root@ceph-deploy ~]# cat /etc/yum.repos.d/ceph.repo 
[ceph-noarch]
name=Ceph noarch packages
baseurl=https://mirrors.aliyun.com/ceph/rpm-mimic/el7/noarch
enabled=1
gpgcheck=1
type=rpm-md
gpgkey=https://mirrors.aliyun.com/ceph/keys/release.asc
[root@ceph-deploy ~]# yum install -y ceph-deploy

5.创建集群

[root@ceph-deploy ~]# su - manager
Last login: Wed Jan  6 17:09:46 CST 2021 on pts/0
#ceph-deploy 部署过程中会生成一些集群初始化配置文件和 key，后续扩容的时候也需要使用到，因此，建议在 admin-node 上创建一个单独的目录，后续操作都进入到该目录中进行操作
[manager@ceph-deploy ~]$ mkdir my-cluster
[manager@ceph-deploy ~]$ cd my-cluster/
#new后面填写你要运行monit节点的主机名，这里monit节点是同一台节点为node1
[manager@ceph-deploy my-cluster]$ ceph-deploy new node1
#执行完上述命令之后，会在该目录生成一个 Ceph 配置文件、一个 monitor 密钥环和一个日志文件。
[manager@ceph-deploy my-cluster]$ ll
total 12
-rw-rw-r-- 1 manager manager  195 Jan  6 17:41 ceph.conf
-rw-rw-r-- 1 manager manager 3163 Jan  6 17:41 ceph-deploy-ceph.log
-rw------- 1 manager manager   73 Jan  6 17:41 ceph.mon.keyring

6.安装ceph

#执行下面命令，会到node1,node2,node3节点上自动安装ceph
[manager@ceph-deploy my-cluster]$ ceph-deploy install node1 node2 node3

 如果执行上面安装命令之后报上面错误或其他报错之后，

可通过以下命令清除相应配置，从而重新部署：

ceph-deploy purgedata node1 node2 node3

ceph-deploy forgetkeys

rm ceph.*

或用以下命令将安装包也一并清除：

ceph-deploy purge node1 node2 node3

然后执行下面两个两条命令中任意一个，在部署时候指定ceph.repo为国内源：

[manager@ceph-deploy my-cluster]$ ceph-deploy install node1 node2 node3 --repo-url=http://mirrors.163.com/ceph/rpm-mimic/el7 --gpg-url=http://mirrors.163.com/ceph/keys/release.asc
[manager@ceph-deploy my-cluster]$ ceph-deploy install node1 node2 node3 --repo-url=https://mirrors.aliyun.com/ceph/rpm-mimic/el7/ --gpg-url=https://mirrors.aliyun.com/ceph/keys/release.asc

 然后到各node节点下，查看ceph安装情况

[root@node1 ~]# ceph -v
ceph version 13.2.10 (564bdc4ae87418a232fc901524470e1a0f76d641) mimic (stable)
[root@node2 ~]# ceph -v
ceph version 13.2.10 (564bdc4ae87418a232fc901524470e1a0f76d641) mimic (stable)
[root@node3 ~]# ceph -v
ceph version 13.2.10 (564bdc4ae87418a232fc901524470e1a0f76d641) mimic (stable)

 

7.初始化monitor

#下面命令会到你上面通过ceph-deploy new命令指定运行monit节点的机器上初始化monit监控节点。
[manager@ceph-deploy my-cluster]$ ceph-deploy mon create-initial
#执行下面命令，收集所有密钥
[manager@ceph-deploy my-cluster]$ ceph-deploy gatherkeys node1

8.部署MGR（为使用dashboard做准备）

#ceph12版本之后，就需要为集群部署mgr服务，Ceph-Mgr将作为Ceph集群的管理进程，负责整个集群的管理操作和监控。mgr分担了很多原本monitor的工作，
根据集群的规模，可以创建2-3个mgr，不过也没有必要创建太多。
[manager@ceph-deploy my-cluster]$ ceph-deploy mgr create node1 node2 node3

9.复制key

#为方便后期deploy节点管理node1、node2、node3，在CLI中使用命令中简化相关key的输出，可将key复制至相应节点。
这样你每次执行Ceph命令行时就无需指定monit节点地址和ceph.client.admin.keyring了
[manager@ceph-deploy my-cluster]$ ceph-deploy admin node1 node2 node3

10.添加OSD和OSD信息查看

生产环境强烈强烈不建议在单分区单硬盘上运行多个OSD；

强烈不建议在运行OSD的单分区硬盘上同时运行监视器或元数据服务器，即OSD建议采用独立的硬盘，且OSD及其日志使用独立硬盘或分区。

#执行下面的命令，可以看到各node节点的磁盘信息。
[manager@ceph-deploy my-cluster]$ ceph-deploy disk list node1 node2 node3
#执行下面命令把指定node节点上的指定磁盘加入OSD。
[manager@ceph-deploy my-cluster]$ ceph-deploy osd create --data /dev/vdc node1
[manager@ceph-deploy my-cluster]$ ceph-deploy osd create --data /dev/vdc node2
[manager@ceph-deploy my-cluster]$ ceph-deploy osd create --data /dev/vdc node3
#查看ceph osd运行状态
[root@node1 ~]# ceph osd stat
3 osds: 3 up, 3 in; epoch: e13
#查看osd的目录树
[root@node1 ~]# ceph osd tree
ID CLASS WEIGHT  TYPE NAME      STATUS REWEIGHT PRI-AFF 
-1       0.08789 root default                           
-3       0.02930     host node1                         
 0   hdd 0.02930         osd.0      up  1.00000 1.00000 
-5       0.02930     host node2                         
 1   hdd 0.02930         osd.1      up  1.00000 1.00000 
-7       0.02930     host node3                         
 2   hdd 0.02930         osd.2      up  1.00000 1.00000

 

11.检查健康状态和ceph集群状态

#通过下面的命令进到node1阶段也就是monitor节点上查看集群健康状态
[manager@ceph-deploy my-cluster]$ ssh node1 sudo ceph health
HEALTH_OK
#通过下面命令查看集群状态
[manager@ceph-deploy my-cluster]$ ssh node1 sudo ceph -s
  cluster:
    id:     a3da0081-4306-4b89-b1aa-45db06909d43
    health: HEALTH_OK
 
  services:
    mon: 1 daemons, quorum node1
    mgr: node1(active), standbys: node2, node3
    osd: 3 osds: 3 up, 3 in
 
  data:
    pools:   0 pools, 0 pgs
    objects: 0  objects, 0 B
    usage:   3.0 GiB used, 87 GiB / 90 GiB avail
    pgs:

12.开启dashboard（ceph集群web展示界面）

#开启dashboard模块

[root@node1 ~]# ceph mgr module enable dashboard
#默认情况下，dashboard的所有HTTP连接均使用SSL/TLS进行保护。以上内置命令可快速生成并安装自签名证书。
[root@node1 ~]# ceph dashboard create-self-signed-cert
Self-signed certificate created
#创建管理员
[root@node1 ~]# ceph dashboard set-login-credentials admin admin
Username and password updated
#确认验证
[root@node1 ~]# ceph mgr services
{
    "dashboard": "https://node1:8443/"
}

接下来浏览器访问https://172.31.46.63:8443/

 

 至此，Ceph集群已经部署完毕。通过ceph-deploy工具进行部署完成Ceph集群的自动化部署，后续添加monitor节点，osd节点，mgr节点也会很方便。

 

posted @ 2020-11-20 16:13  清白之年980410  阅读(745)  评论(0)  编辑  收藏  举报