Ceph

环境筹备ceph官网文档：https://docs.ceph.com/en/latest/ 本次搭建用到的测试机器，布局如下： 主机名IP数据盘ceph-node01192.168.11.135块1TB容量硬盘ceph-node02192.168.11.145块1TB容量硬盘ceph-node03192.168.11.155块1TB容量硬盘解下来在所有节点实现上面的筹备工作敞开防火墙、selinux、禁用swapsystemctl stop firewalldsystemctl disable firewalldsetenforce 0sed -i 's/enforcing/disabled/' /etc/selinux/configswapoff -ased -ri 's/.*swap.*/#&/' /etc/fstab在部署 Ceph 集群时，倡议将所有节点的替换分区（swap）禁用或调整到最小值。这是因为 Ceph 对于节点内存的需要较高，如果零碎中开启了 swap 分区，那么当内存不足时，零碎会将一些内存数据转储到 swap 中，这会导致性能降落和零碎不稳固。因而，禁用或调整 swap 分区大小能够确保零碎有足够的内存来反对 Ceph 的失常运行和性能。 配置阿里云yum源mv /etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/CentOS-Base.repo.bakcurl -o /etc/yum.repos.d/CentOS-Base.repo https://mirrors.aliyun.com/repo/Centos-7.repoyum makecache装置epelyum install epel-release -y装置dockerwget https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo -O /etc/yum.repos.d/docker-ce.repo && yum -y install docker-ce && systemctl enable docker && systemctl start dockercat > /etc/docker/daemon.json << EOF{  "registry-mirrors": ["https://b9pmyelo.mirror.aliyuncs.com"],  "exec-opts": ["native.cgroupdriver=systemd"]}EOFsystemctl restart docker装置lvm2、python3、ntpyum install lvm2 python3 ntpdate -y && ntpdate ntp1.aliyun.com部署ceph集群在每个节点装置Cephadm和ceph工具包# curl --silent --remote-name --location https://github.com/ceph/ceph/raw/octopus/src/cephadm/cephadmchmod +x cephadmmv cephadm /usr/local/bin/# 查看版本的同时会下载镜像quay.io/ceph/ceph:v15，倡议在这一步提前下载好，等会部署ceph集群和退出osd的时候，都要用到这个镜像# 在一台下载后能够导出散发到其余节点进行导入，省心省力。[root@ceph-node01 yum.repos.d]# cephadm versionceph version 15.2.17 (8a82819d84cf884bd39c17e3236e0632ac146dc4) octopus (stable) # 留神这个版本号octopus[root@ceph-node01 ~]# docker imagesREPOSITORY          TAG       IMAGE ID       CREATED        SIZEquay.io/ceph/ceph   v15       93146564743f   7 months ago   1.2GB# 装置对应版本号的相干软件包cephadm add-repo --release octopus && cephadm install ceph-common在第一个节点（ceph-node01）上，初始化Ceph集群和创立OSDcephadm bootstrap --mon-ip 192.168.11.13# 胜利后的输入：Ceph Dashboard is now available at:             URL: https://ceph-node01:8443/            User: admin        Password: 71w76yawguYou can access the Ceph CLI with:        sudo /usr/local/bin/cephadm shell --fsid 09588bf8-ce9d-11ed-b54e-0050563ecf1e -c /etc/ceph/ceph.conf -k /etc/ceph/ceph.client.admin.keyringPlease consider enabling telemetry to help improve Ceph:        ceph telemetry onFor more information see:        https://docs.ceph.com/docs/master/mgr/telemetry/Bootstrap complete.在创立实现后，您将看到输入中显示的管理员账号和明码，能够应用浏览器登录到web治理页面。 查看集群状态： [root@ceph-node01 ~]# ceph -s  cluster:    id:     cf322aa0-ce9d-11ed-a072-0050563ecf1e    health: HEALTH_WARN            OSD count 0 < osd_pool_default_size 3   services:    mon: 1 daemons, quorum ceph-node01 (age 16m)    mgr: ceph-node01.qzkggl(active, since 15m)    osd: 0 osds: 0 up, 0 in   data:    pools:   0 pools, 0 pgs    objects: 0 objects, 0 B    usage:   0 B used, 0 B / 0 B avail    pgs:     能够看到ceph集群曾经有一个节点ceph-node01，它负责了mon、mgr的角色，在我的布局中，也是要让ceph-node01节点作为osd角色的，它的osd数量目前为0，接下来咱们在ceph-node01上创立osd # 查看存储设备列表，它有5块盘[root@ceph-node01 ~]# ceph orch device lsHostname     Path      Type  Serial  Size   Health   Ident  Fault  Available  ceph-node01  /dev/sdb  hdd           1073G  Unknown  N/A    N/A    Yes        ceph-node01  /dev/sdc  hdd           1073G  Unknown  N/A    N/A    Yes        ceph-node01  /dev/sdd  hdd           1073G  Unknown  N/A    N/A    Yes        ceph-node01  /dev/sde  hdd           1073G  Unknown  N/A    N/A    Yes        ceph-node01  /dev/sdf  hdd           1073G  Unknown  N/A    N/A    Yes        # sda是系统盘，sdb-sdf打算用来做osd盘，通过查看目前的状态能够晓得，这5块盘还没有交由ceph治理[root@ceph-node01 ~]# lsblk NAME            MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTsda               8:0    0  500G  0 disk ├─sda1            8:1    0    2G  0 part /boot└─sda2            8:2    0  498G  0 part   ├─centos-root 253:0    0  122G  0 lvm  /  ├─centos-swap 253:1    0   16G  0 lvm    ├─centos-usr  253:2    0   60G  0 lvm  /usr  ├─centos-var  253:3    0  250G  0 lvm  /var  ├─centos-tmp  253:4    0   30G  0 lvm  /tmp  └─centos-home 253:5    0   20G  0 lvm  /homesdb               8:16   0 1000G  0 disk sdc               8:32   0 1000G  0 disk sdd               8:48   0 1000G  0 disk sde               8:64   0 1000G  0 disk sdf               8:80   0 1000G  0 disk # 接下来咱们创立新的OSD，间接通知Ceph应用任何可用和未应用的存储设备ceph orch apply osd --all-available-devices# 接着查看，sdb-sdf磁盘曾经交由ceph治理，并作为osd盘，[root@ceph-node01 ~]# lsblk NAME                                                                                                  MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTsda                                                                                                     8:0    0  500G  0 disk ├─sda1                                                                                                  8:1    0    2G  0 part /boot└─sda2                                                                                                  8:2    0  498G  0 part   ├─centos-root                                                                                       253:0    0  122G  0 lvm  /  ├─centos-swap                                                                                       253:1    0   16G  0 lvm    ├─centos-usr                                                                                        253:2    0   60G  0 lvm  /usr  ├─centos-var                                                                                        253:3    0  250G  0 lvm  /var  ├─centos-tmp                                                                                        253:4    0   30G  0 lvm  /tmp  └─centos-home                                                                                       253:5    0   20G  0 lvm  /homesdb                                                                                                     8:16   0 1000G  0 disk └─ceph--e445c08f--1564--443c--9f7c--de2772686c56-osd--block--91538bd9--a63e--4d2a--9283--8bc66f01726f 253:6    0 1000G  0 lvm  sdc                                                                                                     8:32   0 1000G  0 disk └─ceph--660d76c7--6f90--422e--baa2--ce8441bd8812-osd--block--1820432c--3ee3--4fb6--9c7f--682160c3b13b 253:7    0 1000G  0 lvm  sdd                                                                                                     8:48   0 1000G  0 disk └─ceph--0c0eaf4c--2b6f--45d9--a8a3--a6cac35b285d-osd--block--1f060c14--2dd7--4fdd--839f--9402616bf9fb 253:8    0 1000G  0 lvm  sde                                                                                                     8:64   0 1000G  0 disk └─ceph--60fceaeb--a0c7--45e5--babe--bd714884fbea-osd--block--7eb9b03a--ea87--4ab3--97f4--2c1dcf802930 253:9    0 1000G  0 lvm  sdf                                                                                                     8:80   0 1000G  0 disk └─ceph--8beea209--9020--4c91--b4a4--38b862de7cc0-osd--block--b224910e--7894--470b--8617--0b28c6a1add8 253:10   0 1000G  0 lvm  # 查看集群中的osd状态[root@ceph-node01 ~]# ceph osd statusID  HOST          USED  AVAIL  WR OPS  WR DATA  RD OPS  RD DATA  STATE       0  ceph-node01  1026M   998G      0        0       0        0   exists,up   1  ceph-node01  1026M   998G      0        0       0        0   exists,up   2  ceph-node01  1026M   998G      0        0       0        0   exists,up   3  ceph-node01  1026M   998G      0        0       0        0   exists,up   4  ceph-node01  1026M   998G      0        0       0        0   exists,up  将另外2个节点增加到集群和创立OSD（在ceph-node01节点上操作）# 下发ceph集群的公钥和增加节点ssh-copy-id -f -i /etc/ceph/ceph.pub root@192.168.11.14ssh-copy-id -f -i /etc/ceph/ceph.pub root@192.168.11.15ceph orch host add ceph-node02 192.168.11.14ceph orch host add ceph-node03 192.168.11.15ceph-node02和ceph-node03退出ceph集群后，会主动将任何可用和未应用的存储设备作为osd盘当然也能够手动指定从特定主机上的特定设施创立OSD，命令如下： ceph orch daemon add osd 192.168.11.14:/dev/sdb,/dev/sdc,/dev/sdd,/dev/sde,/dev/sdfceph orch daemon add osd 192.168.11.15:/dev/sdb,/dev/sdc,/dev/sdd,/dev/sde,/dev/sdf至此，ceph集群曾经搭建实现。实现后，查看集群状态、osd状态、集群应用状况[root@ceph-node01 ~]# ceph -s  cluster:    id:     cf322aa0-ce9d-11ed-a072-0050563ecf1e    health: HEALTH_OK   services:    mon: 3 daemons, quorum ceph-node01,ceph-node03,ceph-node02 (age 7m)    mgr: ceph-node01.qzkggl(active, since 34m), standbys: ceph-node02.ioyzpg    osd: 15 osds: 15 up (since 6m), 15 in (since 6m)   data:    pools:   1 pools, 1 pgs    objects: 0 objects, 0 B    usage:   15 GiB used, 15 TiB / 15 TiB avail    pgs:     1 active+clean [root@ceph-node01 ~]# ceph osd statusID  HOST          USED  AVAIL  WR OPS  WR DATA  RD OPS  RD DATA  STATE       0  ceph-node01  1030M   998G      0        0       0        0   exists,up   1  ceph-node01  1030M   998G      0        0       0        0   exists,up   2  ceph-node01  1030M   998G      0        0       0        0   exists,up   3  ceph-node01  1030M   998G      0        0       0        0   exists,up   4  ceph-node01  1030M   998G      0        0       0        0   exists,up   5  ceph-node02  1030M   998G      0        0       0        0   exists,up   6  ceph-node02  1030M   998G      0        0       0        0   exists,up   7  ceph-node02  1030M   998G      0        0       0        0   exists,up   8  ceph-node02  1030M   998G      0        0       0        0   exists,up   9  ceph-node02  1030M   998G      0        0       0        0   exists,up  10  ceph-node03  1030M   998G      0        0       0        0   exists,up  11  ceph-node03  1030M   998G      0        0       0        0   exists,up  12  ceph-node03  1030M   998G      0        0       0        0   exists,up  13  ceph-node03  1030M   998G      0        0       0        0   exists,up  14  ceph-node03  1030M   998G      0        0       0        0   exists,up  [root@ceph-node01 ~]# [root@ceph-node01 ~]# ceph df--- RAW STORAGE ---CLASS  SIZE    AVAIL   USED     RAW USED  %RAW USEDhdd    15 TiB  15 TiB  104 MiB    15 GiB       0.10TOTAL  15 TiB  15 TiB  104 MiB    15 GiB       0.10 --- POOLS ---POOL                   ID  PGS  STORED  OBJECTS  USED  %USED  MAX AVAILdevice_health_metrics   1    1     0 B        0   0 B      0    4.6 TiB[root@ceph-node01 ~]# 登录ceph web治理页面看看： ![图片]() 写在最初对于工夫同步 在 Ceph 集群中，每台节点的工夫同步十分重要，因为 Ceph 集群的各个组件都须要严格的工夫同步能力失常运行。以下是一些重要起因：防止数据不统一：Ceph 集群中的数据正本散布在不同的节点上，如果节点之间的工夫不同步，可能会导致写操作的数据不统一，或者无奈正确地读取数据。防止时钟漂移：因为硬件和软件的起因，每个节点的时钟可能会呈现漂移。如果这种漂移超过了肯定的阈值，可能会导致 Ceph 零碎无奈失常工作。防止锁竞争问题：Ceph 集群中的许多组件都应用锁来管制拜访资源的程序。如果节点之间的工夫差别太大，可能会导致锁竞争问题，从而影响零碎的性能。因而，确保每台节点的工夫同步是 Ceph 集群稳定性和可靠性的重要保障。能够通过应用 NTP（网络工夫协定）或其余工夫同步工具来实现工夫同步。在本次搭建中，同步的是公网阿里云的工夫服务器。须要留神的是，如果在生产环境，还要配置定期可能主动同步，本次只是测试，所以就不配置了，如果是生产环境且不能出外网的机器，还要确保本地有NTP服务器。对于mon节点的数量一个典型的 Ceph 集群官网倡议部署3个或5个监控守护过程（MON），散布在不同的主机上。因为 MON 负责保护 Ceph 集群的状态信息，包含存储池和 OSD 的映射关系、客户端的连贯信息等，它们须要进行定期的状态信息替换和协调。如果某个 MON 产生故障，那么其余的 MON 能够协同工作来保护集群的状态信息。一般来说，部署更多的 MON 能够进步集群的可靠性和容错性，因为它们能够更好地协同工作来保护集群的状态信息。同时，部署更多的 MON 还能够进步集群的性能，因为它们能够更好地分担状态信息替换的负载。 倡议在 Ceph 集群中至多部署五个或更多的 MON，以进步集群的可靠性、容错性和性能。本文转载于WX公众号：不背锅运维（喜爱的盆友关注咱们）：https://mp.weixin.qq.com/s/YzuaRf2ZABFIU7Wkyro4vw

根底不牢，地动山摇。无论是何种体系架构，底层存储的抉择都是一个值得探讨的话题。存储承载着业务的数据，其性能间接影响到业务利用的理论体现。也正因为存储和业务的数据关联严密，其可靠性也必须失去关注，存储的生效一旦导致业务数据失落，那将会是一场劫难级别的事变。1. 云原生时代的存储抉择之路最近几年，我的工作内容始终围绕着客户 Kubernetes 集群的建设。如何为客户的 Kubernetes 集群抉择一款稳固牢靠、性能体现优异的存储解决方案，这样的问题始终困扰着我。 存储卷能够在 Pod 漂移到其余节点后从新挂载这一最根底的功能性要求，让我一开始就把眼光放在了共享文件系统这一存储类型上。最开始抉择了 Nfs，到起初又投入了 Glusterfs 的怀抱，直到最近开始致力摸索其余更好的云原生存储解决方案，这一路走来也让我对各种存储有了肯定的理解。它们各自有着本人的特点： Nfs：Nfs 是一种老牌的基于网络共享文件的存储解决方案。它的长处是简略高效。它的毛病也比拟显著，服务端单点故障，数据没有复制机制。在某些对可靠性要求不高的场景下，Nfs仍然是不二之选。Glusterfs：这是一种开源的分布式共享存储解决方案。绝对于 Nfs 而言，Gfs 通过多正本复制集晋升了数据的可靠性，增加 Brick 的机制也让存储集群的扩大不再受限于一台服务器。Gfs 一度是我部在生产环境下的首选，通过将复制因子设置为 3 ，保障了数据的可靠性的同时，又可能防止分布式系统下的数据脑裂的问题。随同 Gfs 一起后退了很久之后，咱们也发现了它在密集小文件读写场景下的性能短板。而且繁多的共享文件系统类型的存储，也慢慢不再满足咱们的应用场景须要。咱们在寻找更适合的存储这一道路上始终没有进行摸索。这两年云原生概念煊赫一时，社区中不断涌现进去各种云原生畛域我的项目，其中也不乏存储相干的我的项目。最开始，咱们将眼光放在 Ceph 身上，它最吸引咱们的是能够提供高性能的块设施类型存储。然而被其简单的部署形式、较高的运维门槛一度劝退。而 CNCF 毕业我的项目 Rook 的呈现，终于铲平了接触 Ceph 的最初一道门槛。 Rook 我的项目提供了一种云原生存储编排工具，为各种类型的存储提供平台级、框架级的反对，统管了存储软件的装置、运维。Rook 在 2018 年公布的 0.9 版本中，正式将 Ceph Operator 作为稳固反对的个性，迄今曾经数年。应用 Rook 部署和治理生产级别的 Ceph 集群还是十分持重的。 绝对于 Gfs ，Rook-Ceph 提供了性能极高的块设施类型存储，这相当于为 Pod 挂载了一块硬盘，应答密集小文件读写场景并非难事。Rook-Ceph 除了可能提供块设施类型存储之外，也能够基于 Cephfs 提供分布式共享存储，以及基于 S3 协定的对象存储。多种存储类型对立治理，并提供了可视化治理界面，对于运维人员十分敌对。 作为 CNCF 毕业我的项目，Rook-Ceph 对云原生场景的反对毋庸置疑。部署实现的 Rook-Ceph 集群提供了 CSI 插件，以 StorageClass 的模式面向 Kubernetes 供给数据卷，对于兼容 CSI 标准的各类云原生 PaaS 平台也十分敌对。 ...

@[toc] 前言你好，我是无名小歌。明天给大家分享一个分布式存储系统ceph。 简介（实践篇）什么是ceph？Ceph在一个对立的零碎中独特地提供对象、块和文件存储。Ceph 高度牢靠、易于治理且收费。Ceph 的弱小性能能够扭转您公司的 IT 基础架构和治理大量数据的能力。Ceph 提供了不凡的可扩展性——数以千计的客户端拜访 PB 到 EB 的数据。ceph存储集群互相通信以动静复制和重新分配数据。 为什么应用ceph？目前泛滥云厂商都在应用ceph，利用宽泛。如：华为、阿里、腾讯等等。目前炽热的云技术openstack、kubernetes都反对后端整合ceph，从而进步数据的可用性、扩展性、容错等能力。一个 Ceph 存储集群至多须要一个 Ceph Monitor（监视器）、Ceph Manager（治理） 和 Ceph OSD（对象存储守护过程）。MonitorsCeph Monitor ( ceph-mon) 保护集群状态的映射，包含监视器映射、管理器映射、OSD 映射、MDS 映射和 CRUSH 映射。这些映射是 Ceph 守护过程互相协调所需的要害集群状态。监视器还负责管理守护过程和客户端之间的身份验证。冗余和高可用性通常须要至多三个监视器。ManagersCeph Manager守护过程 ( ceph-mgr) 负责跟踪运行时指标和 Ceph 集群的以后状态，包含存储利用率、以后性能指标和零碎负载。高可用性通常须要至多两个管理器。Ceph OSD一个Ceph OSD（ceph-osd）存储数据、解决数据复制、复原、从新均衡，并通过查看其余 Ceph OSD 守护过程的心跳来向 Ceph 监视器和管理器提供一些监督信息。冗余和高可用性通常须要至多三个 Ceph OSD。MDSCeph 元数据服务器(MDS ceph-mds) 代表Ceph 文件系统存储元数据（即 Ceph 块设施和 Ceph 对象存储不应用 MDS）。Ceph 元数据服务器容许 POSIX 文件系统用户执行根本命令（如 ls、find等），而不会给 Ceph 存储集群带来微小累赘。 Ceph 将数据作为对象存储在逻辑存储池中。应用 CRUSH算法，Ceph 计算出哪个归置组应该蕴含该对象，并进一步计算出哪个 Ceph OSD Daemon 应该存储该归置组。CRUSH 算法使 Ceph 存储集群可能动静扩大、从新均衡和复原。 ...

一，元数据池中的数据结构1，DirCephfs 的元数据池中次要寄存着目录dir或目录决裂后的分片对象，数据池中寄存着文件的对象（依据偏移能够划分多个）。 查看名为vdb.1_1.dir（目录下有100万个文件）的目录的inode号为1099511627788，转换为16进制为1000000000C 通过inode号在metapool里搜到513个对象，去掉原目录1000000000c.00000000，能够看到该目录存在512个目录分片，每个分片由inode号1000000000c和分片号frag_t（32位）组成，前8位示意有效位数，前面24位为value值，这里前8位为09示意value前9位无效。每一个目录分片在元数据池中作为一个dir对象存在。 [root@node2 cephfs]# rados -p cephfs-metadata ls 2，Dentry和Inode组织构造通过查看元数据池中目录分片的内容，咱们能够看到对应dir对象中存在的文件的dentry和inode信息，以1000000000c.09640000分片为例，如下可见dir对象中寄存的items map记录治理的目录项dentry， 每一个目录或文件的dentry信息以key-value键值对的模式存在dir中。 [root@node2 testSetattr]# rados -p cephfs-metadata listomapvals 1000000000c.09640000 以文件vdb_f0033为例，在其所在的分片1000000000c.09640000中，key是以文件名_head的模式存在，value外面寄存着对应文件的元数据inode信息（蕴含inode号，如上图红框所示为1000000002D，小端模式须要倒着看。从数据池中能找到这个对象，对象的名称为文件的inode号.编号（总大小/对象大小object_size个），对象存的数据多了就依据偏移拆成多个） 咱们目前的目录vdb.1_1.dir的上级文件的元数据信息就全副找到了，依照元数据的组织构造，不论是文件或者目录，其inode信息和dentry都寄存在其下级目录dir（或者对应分片）的items map之内。 以vdb.1_1.dir为例，其父目录为testSetattr，inode号为109951163887，转成16进制为10000002B59。查看10000002b59.00000000对象能够找到vdb.1_1.dir的元数据信息。 [root@node3 cephfs]# rados -p cephfs-metadata listomapvals 10000002b59.00000000 因为testSetattr目录下级目录就是文件系统根目录，所以其inode信息寄存在根目录的dir对象中（根目录的inode号为1），通过以下命令查到[root@node3 cephfs]# rados -p cephfs-metadata listomapvals 1.00000000 而针对于根目录的inode信息，寄存在1.00000000.inode对象当中。 二，内存对象中的构造 大体的内存组织构造借用上图示意，上面具体介绍： 1，DirCInode          *inode;  // my inodefrag_t           frag;   // my frag...dentry_key_map  items;Dir内存构造次要是其本身的inode索引和以后的分片号，以及存在其中的dentry 列表items，具体参数见Dir.h。通过CDir::fetch()读取metapool中的数据，填充本人的CDir::items，从而在内存初中创立相应的dentry和inode构造。 2，Dentry 简要地说，dentry的内存构造次要蕴含对应文件或目录的名字mempool::mds_co::string name，其归属的目录或者分片CDir *dir，以及链接的inode信息linkage_t linkage，链接linkage蕴含inode或remote inode（跟硬链接无关）索引。 3，Inode Inode的数据结构较为简单，次要变量CDentry *parent（失常链接的primary dentry）和remote_parents(硬链接应用)，指向其所链接的dentry，dirfragtree是以后inode为dir的状况下指向对应目录分片。次要信息存在其继承的InodeStoreBase类中，其蕴含了具体inode信息所在的inode_t(即mempool_inode构造），和对应文件或目录的扩大属性xattr，inode_t则蕴含了传统inode的元数据信息，包含ctime、mtime、mode、uid、gid等等具体的属性信息。

家喻户晓，cephfs的数据和元数据是拆散的，处于不同的pool池外头，而无论是rgw、cephfs、rbd底层的数据池的存储都是基于RADOS(Reliable Autonomic Distributed Object Store),Ceph存储集群的根底，RADOS层的一切都是以对象的模式存储着的，无论下层是文件、对象还是块。 次要说说cephfs的文件在数据池中是如何散布的，上面以cephfs的内核客户端为例进行剖析。 以下图文件为例，先找到这个文件的inode号1099511627776，转换为16进制为10000000000，从数据池中找到这个对象，对象的名称为文件的inode号.编号（数据地位/对象大小object_size（默认4M），从0开始编号） Cephfs读数据转换osd申请struct ceph_file_layout {    /* file -> object mapping */    u32 stripe_unit;   /* stripe unit, in bytes */    u32 stripe_count;  /* over this many objects */    u32 object_size;   /* until objects are this big */    s64 pool_id;        /* rados pool id */    struct ceph_string __rcu *pool_ns; /* rados pool namespace */};文件的layout的属性，位于每个文件的inode属性中，是用来计算文件理论对象散布的条件。 客户端（linux内核客户端）位于文件的扩大属性xattr当中，通过set_xattr流程（客户端入口函数__ceph_setxattr和服务端mds入口函数为Server::handle_client_setxattr）进行批改。 ...

Ceph在阿里云镜像源地址https://mirrors.aliyun.com/ceph/有时候从ceph默认下载时下载较慢，能够替换成阿里云镜像源yum源初始化筹备建设ceph.repo文件将扭转镜像源并且不会主动切回默认镜像地址须要在所有节点上配置好阿里云的镜像源具体位置在/etc/yum.repos.d/下新建一个ceph.repo [Ceph]name=Ceph packages for $basearchbaseurl=https://mirrors.aliyun.com/ce...$basearchenabled=1gpgcheck=1type=rpm-mdgpgkey=https://mirrors.aliyun.com/ce... [Ceph-noarch]name=Ceph noarch packagesbaseurl=https://mirrors.aliyun.com/ce...enabled=1gpgcheck=1type=rpm-mdgpgkey=https://mirrors.aliyun.com/ce... [ceph-source]name=Ceph source packagesbaseurl=http://mirrors.aliyun.com/cep...enabled=1gpgcheck=1type=rpm-mdgpgkey=https://mirrors.aliyun.com/ce...

1.问题 2.问题所在运维共事提供的ceph集群有问题，换个集群地址就能够了，我的代码没有问题。

本文转自twt社区。 【导读】Ceph 日常运维中有几类常见问题，社区日前组织Ceph领域专家进行了线上的答疑交换，对社区会员提出的局部典型问题进行了分享解答，以下是分享内容，心愿能为大家提供答案和一些参考。 Ceph是一个牢靠地、主动重平衡、主动复原的分布式存储系统，依据场景划分能够将Ceph分为三大块，别离是对象存储、块设施存储和文件系统服务。在虚拟化畛域里，比拟罕用到的是Ceph的块设施存储，比方在OpenStack我的项目里，Ceph的块设施存储能够对接OpenStack的cinder后端存储、Glance的镜像存储和虚拟机的数据存储，比拟直观的是Ceph集群能够提供一个raw格局的块存储来作为虚拟机实例的硬盘。 Ceph相比其它存储的劣势点在于它不单单是存储，同时还充分利用了存储节点上的计算能力，在存储每一个数据时，都会通过计算得出该数据存储的地位，尽量将数据分布平衡，同时因为Ceph的良好设计，采纳了CRUSH算法、HASH环等办法，使得它不存在传统的单点故障的问题，且随着规模的扩充性能并不会受到影响。 企业在理论Ceph遇到的五大问题： 一、扩容问题 Ceph中数据以PG为单位进行组织，因而当数据池中退出新的存储单元（OSD）时，通过调整OSDMAP会带来数据重均衡。正如提到的，如果波及到多个OSD的扩容是可能导致可用PG中OSD小于min_size，从而产生PG不可用、IO阻塞的状况。为了尽量避免这种状况的呈现，只能将扩容粒度变小，比方每次只扩容一个OSD或者一个机器、一个机柜（次要取决于存储隔离策略），然而这样注定会带来极大的运维工作量，甚至连扩容速度可能都赶不上数据增长速度。 二、数据迁徙过程中的IO争用问题 在频繁数据迁徙过程中带来的IO争用问题。当集群规模变大后，硬盘损坏、PG数量裁减可能会变得常态化。 三、PG数量调整问题 在解决了数据迁徙过程中的PG可用性问题和IO争用问题后，提到的PG数量调整问题天然也就解决了。 四、集群利用率问题 存储老本问题次要是讲集群可用率问题，即：Ceph集群规模增大后，伪随机算法导致了存储资源散布不平衡，磁盘利用率方差过大的问题。 五、运维复杂度问题 Ceph自身是一个十分复杂的体系，要做到稳固运维十分看重团队的实力。 以下是一些典型问题解答，欢送参考： 1、PG和PGP的区别是什么？调整 PGP 会不会引起 PG 内的对象的决裂？ @Lucien168： 首先来一段英文对于PG和PGP区别的解释： PG = Placement Group PGP = Placement Group for Placement purpose pg_num = number of placement groups mapped to an OSD When pg_num is increased for any pool, every PG of this pool splits into half, but they all remain mapped to their parent OSD. ...

1.执行名称ceph-deploy new node2，报错： bash: python2: command not found[ceph_deploy][ERROR ] RuntimeError: connecting to host: node2 resulted in errors: IOError cannot send (already closed?)起因是node2上没有装置python2，通过命令apt install python-minimal装置即可。 2.

RBD回收站机制(TRASH)回收站就是将你的数据放在回收站，失常的 rbd image 一旦删除了就没了，然而ceph rbd 提供了回收站形式给你反悔的机会,能够自定义设置保留日期.创立镜像rbd create ceph-demo/ceph-trash.img --size 10G[root@node-1 ~]# rbd -p ceph-demo lsceph-trash.imgrbd-demo.img将镜像挪动到回收站回收后pool下将没有这个镜像rbd trash move ceph-demo/ceph-trash.img --expires-at 20200928--expires-at 设置指定的过期日期#查看回收站镜像[root@node-1 ~]# rbd trash -p ceph-demo ls16173ad6a4dc ceph-trash.img还原镜像[root@node-1 ~]# rbd trash restore ceph-demo/16173ad6a4dc[root@node-1 ~]# rbd -p ceph-demo lsceph-trash.imgrbd-demo.imgRBD镜像快照(SNAPSHOTS)快照是映像在某个特定工夫点的一份只读正本。 Ceph 块设施的一个高级个性就是你能够为映像创立快照来保留其历史。 Ceph 还反对分层快照，让你疾速、简便地克隆映像（如 VM 映像）。 Ceph 的快照性能反对 rbd 命令和多种高级接口，包含 QEMU 、 libvirt 、 OpenStack 和 CloudStack.创立快照rbd snap create ceph-demo/rbd-demo.img@snap_20200927#查看快照[root@node-1 ~]# rbd snap ls ceph-demo/rbd-demo.imgSNAPID NAME SIZE PROTECTED TIMESTAMP 4 snap_20200927 20 GiB Sun Sep 27 10:40:17 2020快照复原[root@node-1 ~]# rbd snap rollback ceph-demo/rbd-demo.img@snap_20200927Rolling back to snapshot: 100% complete...done.快照复原后数据仍然还是不存在的，因为复原后磁盘是离线状态，须要unmount而后从新挂载数据能够复原。 ...

创立存储池ceph osd pool create ceph-demo 64 64#查看存储池ceph osd lspools查看存储池参数[root@node-1 ~]# ceph osd pool get ceph-demo pg_numpg_num: 64[root@node-1 ~]# ceph osd pool get ceph-demo pgp_numpgp_num: 64[root@node-1 ~]# ceph osd pool get ceph-demo sizesize: 3批改存储池参数ceph osd pool get ceph-demo pg_num 32ceph osd pool get ceph-demo pgp_num 32创立镜像rbd create -p ceph-demo --image rbd-demo.img --size 10G或者 rbd create ceph-demo/rbd-demo-1.img --size 10G[root@node-1 ~]# rbd -p ceph-demo lsrbd-demo.imgrbd-demo-1.img查看镜像详细信息root@node-1 ~]# rbd info ceph-demo/rbd-demo.imgrbd image 'rbd-demo.img': size 10 GiB in 2560 objects order 22 (4 MiB objects) snapshot_count: 0 id: 1134749f26f5 block_name_prefix: rbd_data.1134749f26f5 format: 2 features: layering, exclusive-lock, object-map, fast-diff, deep-flatten op_features: flags: create_timestamp: Tue Sep 22 15:39:03 2020 access_timestamp: Tue Sep 22 15:39:03 2020 modify_timestamp: Tue Sep 22 15:39:03 2020删除镜像rbd rm ceph-demo/rbd-demo-1.img[root@node-1 ~]# rbd -p ceph-demo lsrbd-demo.img块设施映射rbd map ceph-demo/rbd-demo.imgrbd: sysfs write failedRBD image feature set mismatch. Try disabling features unsupported by the kernel with "rbd feature disable".In some cases useful info is found in syslog - try "dmesg | tail".rbd: map failed: (6) No such device or address下面有报错是因为有些个性centos7的内核不反对，所以须要关了 ...

ceph集群搭建ceph组件介绍MON（monitor）Monitor在Ceph集群中扮演者管理者的角色，保护了整个集群的状态，是Ceph集群中最重要的组件。Mon保障集群的相干组件在同一时刻可能达成统一，相当于集群的领导层，负责收集、更新和公布集群信息。为了躲避单点故障，在理论的Ceph部署环境中会部署多个Mon，同样会引来多个Mon之前如何协同工作的问题。在一个规范的Ceph环境中。OSD理论存储数据的过程。通常一个OSD daemon绑定一个物理磁盘。Client write/read 数据最终都会走到OSD去执行write/read操作。RADOS（Reliable Autonomic Distributed Object Store, RADOS）RADOS是Ceph 存储集群的根底。Ceph 中的所有都以对象的模式存储，而RADOS 就负责存储这些对象，而不思考它们的数据类型。RADOS 层确保数据一致性和可靠性。对于数据一致性，它执行数据复制、故障检测和复原。还包含数据在集群节点间的recovery。Librados简化拜访RADOS的一种办法，目前反对PHP、Ruby、Java、Python、C和C++语言。它提供了Ceph 存储集群的一个本地接口RADOS ，并且是其余服务(如RBD 、RGW) 的根底，以及为CephFS 提供POSIX 接口。librados API 反对间接拜访RADOS ，使得开发者可能创立本人的接口来拜访Ceph 集群存储。RBDCeph块设施。对外提供块存储。能够像磁盘一样被映射、格式化曾经挂载到服务器上。反对snapshot(快照)及增量备份。RGWCeph对象网关，提供了一个兼容S3和Swift的restful API接口。RGW还反对多租户和Openstack的keyston身份验证服务。MDSCeph元数据服务器，跟踪文件层次结构并存储只供CephFS应用的元数据。Ceph块设施和RADOS网关不须要元数据。MDS不间接给client提供数据服务。ceph写入数据流程如下图所示一个File首先被切割为多个objects，每个objects默认4M大小，也就是100M的数据会被切割为25个object，并且每个object都有本人的objectid，通过hash而后进行掩码的运算，确认object是应该散布那个pg中，而后pg通过crush算法，将数据落在不同的osd.默认的crush算法基于host的. 部署ceph集群应用三台服务器服务器用处192.168.21.101node-1192.168.21.101node-2192.168.21.102node-3批改三台服务器hostnamehostnamectl set-hostname node-1hostnamectl set-hostname node-2hostnamectl set-hostname node-3开启ssh免密登录ssh-keygenssh-copy-id -i /root/.ssh/id_rsa.pub node-2ssh-copy-id -i /root/.ssh/id_rsa.pub node-3敞开所有节点selinux和firewalldsetenforce 0sed -i 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/selinux/configsystemctl stop firewalld所有节点装置ntpyum install ntp ntpdate ntp-docsystemctl start ntpd && systemctl enable ntpdntpq -np所有节点增加yum源wget -O /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repowget -O /etc/yum.repos.d/epel.repo http://mirrors.aliyun.com/repo/epel-7.repocat >/etc/yum.repos.d/ceph.repo <<EOF[norch]name=norchbaseurl=https://mirrors.aliyun.com/ceph/rpm-nautilus/el7/noarch/enabled=1gpgcheck=0[x86_64]name=x86_64baseurl=https://mirrors.aliyun.com/ceph/rpm-nautilus/el7/x86_64/enabled=1gpgcheck=0EOF装置ceph初始化monyum clean all && yum makecacheyum install python-setuptools ceph-deploy -ymkdir ceph-deploy && cd ceph-deployceph-deploy new --public-network 192.168.21.0/0 --cluster-network 192.168.21.0/0 node-1yum install ceph ceph-mon ceph-mgr ceph-radosgw cepht-mds -y #所有节点装置ceph-deploy mon create-initial #初始化monceph-deploy admin node-1 node-2 node-3 #推送配置文件到各个节点ceph-deploy mgr create node-1 #初始化mgr作为监控ceph -s # 查看集群状态扩大mon增加osd#集群增加osdceph-deploy osd create node-1 --data /dev/sdbceph-deploy osd create node-2 --data /dev/sdbceph-deploy osd create node-3 --data /dev/sdb#增加mon节点使其高可用ceph-deploy --overwrite mon add node-2ceph-deploy --overwrite mon add node-3#查看osd状态ceph osd tree#查看Ceph monitor仲裁状态ceph quorum_status --format json-pretty

奇技指南Cgroups的全称是ControlGroups，它是Linux内核提供的一种能够对cpu，内存等资源实现精细化控制的机制。本文介绍了它的原理以及其在CephFSio限流上的应用。 Cgroups架构“Control Groups”的主要功能是将线程及其子线程分为多个组，以便对他们进行分别控制。其具体工作包括： 将线程分组为用户提供控制每组线程的操作接口(/sys/fs文件)每个control group关联一个cgroup subsystem（controller）。每个subsystem用于控制某项特殊的资源（如可以被调度的cpu核，内存使用总量等），subsystem之间可以存在依赖关系。目前linux默认会加载的subsystem包括:blkio、cpu、cpuacct、cpuset、devices、freezer、hugetlb、memory、net_cls、net_cls,net_prio、net_prio、perf_event、pids、systemd。 如上图所示，在内核中，cgroup会为每个/sys/fs/cgroup下的子目录(subsystem对应目录除外)创建一个css(cgroup_subsys_state)结构，该结构用于关联该目录对应的cgroup结构和所属的subsystem。每个内核线程的task结构中应一个css_set域，可以通过获取其中的css结构，获得其所属的control group信息。 Cgroup的代码实现大致可分为三部分： 在系统启动时(start_kernel), 初始化cgroup_root，init_css_set(init线程的css_set), 各个subsystem;将cgroup_root挂载至/sys/fs/cgroup在线程fork时, 将父线程的css_set赋予子线程, 即：子线程继承父线程的css_set根据各subsystem需求，创建/sys/fs下的subsystem控制接口文件，用户可以通过向这些文件写入数据实现对某个control group的控制，也可通过读取相应文件，获得当前该control group的状态。添加cgroup subsystem/controller添加一个子系统需要完成以下工作： 1、实现一组cgroup要求subsystem实现的api（如下图所示），其中css_alloc和css_free是强制要求实现的，其余均可选；css_alloc用于分配cgroup_subsys_state结构所需的内存，用户可在该函数里初始化自己的subsystem，css_free用于卸载该subsystem时回收相应内存 2、每个子系统拥有一个独立的自定义name，每个子系统需要定义一个struct cgroup_subsys类型的全局变量，该变量名为<name>_cgrp_subsys；将上面实现的cgroup subsystem api赋予该变量相应的域 3、在 inclue/linux/cgroup_subsys.h里，添加属下entry： #if IS_ENABLED(CONFIG_CGROUP_XXX) SUBSYS(<name>) #endif 实现cephfs客户端io限流Cephfs客户端限流的目标：限制cephfs内核客户端元数据/数据操作速率(ops/byte per second)。目前我们采用的限流算法是令牌桶算法。 实现步骤如下： 1、添加include/linux/cgroup_cephfs.h头文件，定义cephfscg结构，其中包含cgroup_subsys_state域；同时定义其他所需类型（如令牌桶限流阀token_bucket_throttle） 2、实现cgroup cephfs subsystem a）实现css_alloc和css_free函数 b）定义cephfs subsystem的接口文件，其中meta_ops和data_ops用于设置元数据操作和数据操作令牌桶的更新周期，meta_ops.iops和data_ops.iops用于设置元数据/数据操作的iops限制，data_ops.band用于设置数据操作的吞吐量限制；除定位文件外，还需要设置这些文件的读写处理函数,这里所有读写操作均由cephfscg_set_throttle_params和cephfscg_throttle_params_read完成； c）定义cephfs_cgrp_subsys变量 d）在Include/linux/cgroup_subsys.h增加相应的entry 3、在cephfs文件操作执行路径上增加相应的控制操作(获取当前task的css结构，并调用其对应的限流接口) 本文介绍了cgroups架构以及添加子系统的方法，并通过cgroups在cephfs中的应用，进一步展示了cgroups精细化控制能力。希望通过整篇文章的介绍，读者能够大致了解cgroups的功能。 相关推荐 浅谈Cgroups （360技术原创内容，转载务必注明出处保存文末二维码图片，谢谢配合。）关注360技术，发现更多有料干货~

kubernetes集群三步安装安装git clone https://github.com/rook/rookcd cluster/examples/kubernetes/cephkubectl create -f operator.yaml 查看operator是否成功：[root@dev-86-201 ~]# kubectl get pod -n rook-ceph-systemNAME READY STATUS RESTARTS AGErook-ceph-agent-5z6p7 1/1 Running 0 88mrook-ceph-agent-6rj7l 1/1 Running 0 88mrook-ceph-agent-8qfpj 1/1 Running 0 88mrook-ceph-agent-xbhzh 1/1 Running 0 88mrook-ceph-operator-67f4b8f67d-tsnf2 1/1 Running 0 88mrook-discover-5wghx 1/1 Running 0 88mrook-discover-lhwvf 1/1 Running 0 88mrook-discover-nl5m2 1/1 Running 0 88mrook-discover-qmbx7 1/1 Running 0 88m然后创建ceph集群：kubectl create -f cluster.yaml查看ceph集群：[root@dev-86-201 ~]# kubectl get pod -n rook-cephNAME READY STATUS RESTARTS AGErook-ceph-mgr-a-8649f78d9b-jklbv 1/1 Running 0 64mrook-ceph-mon-a-5d7fcfb6ff-2wq9l 1/1 Running 0 81mrook-ceph-mon-b-7cfcd567d8-lkqff 1/1 Running 0 80mrook-ceph-mon-d-65cd79df44-66rgz 1/1 Running 0 79mrook-ceph-osd-0-56bd7545bd-5k9xk 1/1 Running 0 63mrook-ceph-osd-1-77f56cd549-7rm4l 1/1 Running 0 63mrook-ceph-osd-2-6cf58ddb6f-wkwp6 1/1 Running 0 63mrook-ceph-osd-3-6f8b78c647-8xjzv 1/1 Running 0 63m参数说明：apiVersion: ceph.rook.io/v1kind: CephClustermetadata: name: rook-ceph namespace: rook-cephspec: cephVersion: # For the latest ceph images, see https://hub.docker.com/r/ceph/ceph/tags image: ceph/ceph:v13.2.2-20181023 dataDirHostPath: /var/lib/rook # 数据盘目录 mon: count: 3 allowMultiplePerNode: true dashboard: enabled: true storage: useAllNodes: true useAllDevices: false config: databaseSizeMB: “1024” journalSizeMB: “1024"访问ceph dashboard:[root@dev-86-201 ~]# kubectl get svc -n rook-cephNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGErook-ceph-mgr ClusterIP 10.98.183.33 <none> 9283/TCP 66mrook-ceph-mgr-dashboard NodePort 10.103.84.48 <none> 8443:31631/TCP 66m # 把这个改成NodePort模式rook-ceph-mon-a ClusterIP 10.99.71.227 <none> 6790/TCP 83mrook-ceph-mon-b ClusterIP 10.110.245.119 <none> 6790/TCP 82mrook-ceph-mon-d ClusterIP 10.101.79.159 <none> 6790/TCP 81m然后访问https://10.1.86.201:31631 即可管理账户admin,获取登录密码：kubectl -n rook-ceph get secret rook-ceph-dashboard-password -o yaml | grep “password:” | awk ‘{print $2}’ | base64 –decode使用创建poolapiVersion: ceph.rook.io/v1kind: CephBlockPoolmetadata: name: replicapool # operator会监听并创建一个pool，执行完后界面上也能看到对应的pool namespace: rook-cephspec: failureDomain: host replicated: size: 3—apiVersion: storage.k8s.io/v1kind: StorageClassmetadata: name: rook-ceph-block # 这里创建一个storage class, 在pvc中指定这个storage class即可实现动态创建PVprovisioner: ceph.rook.io/blockparameters: blockPool: replicapool # The value of “clusterNamespace” MUST be the same as the one in which your rook cluster exist clusterNamespace: rook-ceph # Specify the filesystem type of the volume. If not specified, it will use ext4. fstype: xfs# Optional, default reclaimPolicy is “Delete”. Other options are: “Retain”, “Recycle” as documented in https://kubernetes.io/docs/concepts/storage/storage-classes/reclaimPolicy: Retain创建pvc在cluster/examples/kubernetes 目录下，官方给了个worldpress的例子，可以直接运行一下：kubectl create -f mysql.yamlkubectl create -f wordpress.yaml查看PV PVC：[root@dev-86-201 ~]# kubectl get pvcNAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGEmysql-pv-claim Bound pvc-a910f8c2-1ee9-11e9-84fc-becbfc415cde 20Gi RWO rook-ceph-block 144mwp-pv-claim Bound pvc-af2dfbd4-1ee9-11e9-84fc-becbfc415cde 20Gi RWO rook-ceph-block 144m[root@dev-86-201 ~]# kubectl get pvNAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGEpvc-a910f8c2-1ee9-11e9-84fc-becbfc415cde 20Gi RWO Retain Bound default/mysql-pv-claim rook-ceph-block 145mpvc-af2dfbd4-1ee9-11e9-84fc-becbfc415cde 20Gi RWO Retain Bound default/wp-pv-claim rook-ceph-block 145m看下yaml文件：apiVersion: v1kind: PersistentVolumeClaimmetadata: name: mysql-pv-claim labels: app: wordpressspec: storageClassName: rook-ceph-block # 指定storage class accessModes: - ReadWriteOnce resources: requests: storage: 20Gi # 需要一个20G的盘… volumeMounts: - name: mysql-persistent-storage mountPath: /var/lib/mysql volumes: - name: mysql-persistent-storage persistentVolumeClaim: claimName: mysql-pv-claim # 指定上面定义的PVC是不是非常简单。要访问wordpress的话请把service改成NodePort类型，官方给的是loadbalance类型：kubectl edit svc wordpress[root@dev-86-201 kubernetes]# kubectl get svcNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEwordpress NodePort 10.109.30.99 <none> 80:30130/TCP 148m总结分布式存储在容器集群中充当非常重要的角色，使用容器集群一个非常重要的理念就是把集群当成一个整体使用，如果你在使用中还关心单个主机，比如调度到某个节点，挂载某个节点目录等，必然会导致不能把云的威力百分之百发挥出来。 一旦计算存储分离后，就可真正实现随意漂移，对集群维护来说是个极大的福音。比如集群机器过保了需要下架，那么我们云化的架构因为所有东西无单点，所以只需要简单驱逐改节点，然后下架即可，不用关心上面跑的是什么业务，不管是有状态还是无状态的都可以自动修复。 不过目前面临最大的挑战可能还是分布式存储的性能问题。 在性能要求不苛刻的场景下我是极推荐这种计算存储分离架构的。探讨可加QQ群：98488045公众号：微信群： ...

作者：Earl C. Ruby III我想在新的Kubernetes集群上安装Prometheus和Grafana，但为了使这些软件包能够工作，他们需要一些地方来存储持久数据。当我在Seagate担任云架构师时，我已经对Ceph进行了性能和规模测试，并且在过去的一年里玩过Rook，所以我决定安装Rook+Ceph，并将其用于Kubernetes集群的数据存储。Ceph是一个分布式存储系统，提供对象、文件和块存储。在每个存储节点上，您将找到Ceph存储对象的文件系统和Ceph OSD（对象存储守护程序）进程。在Ceph集群上，您还可以找到Ceph MON（监控）守护程序，它们确保Ceph集群保持高可用性。Rook充当Ceph在Kubernetes的业务流程层，将OSD和MON流程部署为POD副本集。来自Rook的README文件：Rook将存储软件转变为自我管理、自我扩展和自我修复的存储服务。它通过自动化部署，引导，准备，配置，扩展，升级，迁移，灾难恢复，监控和资源管理来实现此目的。 Rook使用底层云原生容器管理，调度和编排平台提供的工具来执行其职责。https://github.com/rook/rook/…当我创建集群时，我构建了具有40GB硬盘的VM，所以使用5个Kubernetes节点，在我的集群上提供了大约200GB的存储空间，其中大部分都将用于Ceph。安装Rook+Ceph安装Rook+Ceph非常简单。在我的个人群集上，我按照以下步骤安装了Rook+Ceph v0.9.0：git clone git@github.com:rook/rook.gitcd rookgit checkout v0.9.0cd cluster/examples/kubernetes/cephkubectl create -f operator.yamlkubectl create -f cluster.yamlRook将POD部署在两个命名空间中，即rook-ceph-system和rook-ceph。 在我的群集上，POD花了大约2分钟来部署，初始化并进入运行状态。当我等待一切都完成时，我检查了POD状态：$ kubectl -n rook-ceph-system get podNAME READY STATUS RESTARTS AGErook-ceph-agent-8tsq7 1/1 Running 0 2d20hrook-ceph-agent-b6mgs 1/1 Running 0 2d20hrook-ceph-agent-nff8n 1/1 Running 0 2d20hrook-ceph-agent-vl4zf 1/1 Running 0 2d20hrook-ceph-agent-vtpbj 1/1 Running 0 2d20hrook-ceph-agent-xq5dv 1/1 Running 0 2d20hrook-ceph-operator-85d64cfb99-hrnbs 1/1 Running 0 2d20hrook-discover-9nqrp 1/1 Running 0 2d20hrook-discover-b62ds 1/1 Running 0 2d20hrook-discover-k77gw 1/1 Running 0 2d20hrook-discover-kqknr 1/1 Running 0 2d20hrook-discover-v2hhb 1/1 Running 0 2d20hrook-discover-wbkkq 1/1 Running 0 2d20h$ kubectl -n rook-ceph get podNAME READY STATUS RESTARTS AGErook-ceph-mgr-a-7d884ddc8b-kfxt9 1/1 Running 0 2d20hrook-ceph-mon-a-77cbd865b8-ncg67 1/1 Running 0 2d20hrook-ceph-mon-b-7cd4b9774f-js8n9 1/1 Running 0 2d20hrook-ceph-mon-c-86778859c7-x2qg9 1/1 Running 0 2d20hrook-ceph-osd-0-67fff79666-fcrss 1/1 Running 0 35hrook-ceph-osd-1-58bd4ccbbf-lsxj9 1/1 Running 1 2d20hrook-ceph-osd-2-bf99864b5-n4q7v 1/1 Running 0 2d20hrook-ceph-osd-3-577466c968-j8gjr 1/1 Running 0 2d20hrook-ceph-osd-4-6856c5c6c9-92tb6 1/1 Running 0 2d20hrook-ceph-osd-5-8669577f6b-zqrq9 1/1 Running 0 2d20hrook-ceph-osd-prepare-node1-xfbs7 0/2 Completed 0 2d20hrook-ceph-osd-prepare-node2-c9f55 0/2 Completed 0 2d20hrook-ceph-osd-prepare-node3-5g4nc 0/2 Completed 0 2d20hrook-ceph-osd-prepare-node4-wj475 0/2 Completed 0 2d20hrook-ceph-osd-prepare-node5-tf5bt 0/2 Completed 0 2d20h最后工作现在我需要再做两件事，才能安装Prometheus和Grafana：我需要让Rook成为我的集群的默认存储提供程序。由于Prometheus Helm chart请求使用XFS文件系统格式化的卷，因此我需要在所有Ubuntu Kubernetes节点上安装XFS工具。（默认情况下，Kubespray尚未安装XFS，尽管目前有一个PR解决这个问题。）要使Rook成为默认存储提供程序，我只需运行kubectl命令：kubectl patch storageclass rook-ceph-block -p ‘{“metadata”: {“annotations”:{“storageclass.kubernetes.io/is-default-class”:“true”}}}‘这会更新rook-ceph-block存储类，并使其成为群集上存储的默认值。如果没有指定特定的存储类，我安装的任何应用程序都将使用Rook+Ceph进行数据存储。由于我使用Kubespray构建集群，而Kubespray使用Ansible，因此在所有主机上安装XFS工具的最简单方法之一，是使用Ansible“在所有主机上运行单个命令”功能：cd kubesprayexport ANSIBLE_REMOTE_USER=ansibleansible kube-node -i inventory/mycluster/hosts.ini \ –become –become-user root \ -a ‘apt-get install -y xfsprogs’现在已经安装了XFS，我可以使用Helm成功部署Prometheus和Grafana：helm install –name prometheus stable/prometheushelm install –name grafana stable/grafanaHelm chart安装Prometheus和Grafana，并在Rook+Ceph上为Prometheus Server和Prometheus Alert Manager（使用XFS格式化）创建持久存储卷。Prometheus仪表板Grafana仪表板Rook给Prometheus服务器的持久存储希望您觉得这个有帮助。 ...

欢迎大家前往腾讯云+社区，获取更多腾讯海量技术实践干货哦~本文由Tstack发表于云+社区专栏本文为长篇连续剧，将分多个篇幅发表，主要介绍了从动手部署环境到后期运营故障处理过程中常见的问题，内容由浅入深，是居家旅行运维Ceph的必备良药。Q1. 环境预准备绝大多数MON创建的失败都是由于防火墙没有关导致的，亦或是SeLinux没关闭导致的。一定一定一定要关闭每个每个每个节点的防火墙(执行一次就好，没安装报错就忽视)：CentOSsed -i ’s/SELINUX=.*/SELINUX=disabled/’ /etc/selinux/configsetenforce 0systemctl stop firewalld systemctl disable firewalld# iptables -Fservice iptables stopQ2. 清理环境MON部署不上的第二大问题就是在旧的节点部署MON，或者在这个节点部署MON失败了，然后重新new再mon create-initial，请查看要部署MON的节点上的/var/lib/ceph/mon/目录下是否为空，如果不为空，说明已经在这个目录部署过MON，再次部署会检测子目录下的done文件，由于有了这个文件，就不会再建立新的MON数据库，并且不会覆盖之，导致了部署时的各种异常，这里就不赘述了，直接给出万能清理大法：对于任何需要新部署MON的节点，请到这个节点下执行如下指令，确保环境已经清理干净：ps aux|grep ceph |awk ‘{print $2}’|xargs kill -9ps -ef|grep ceph#确保此时所有ceph进程都已经关闭！！！如果没有关闭，多执行几次。rm -rf /var/lib/ceph/mon/*rm -rf /var/lib/ceph/bootstrap-mds/*rm -rf /var/lib/ceph/bootstrap-osd/*rm -rf /var/lib/ceph/bootstrap-rgw/*rm -rf /etc/ceph/rm -rf /var/run/ceph/请直接复制粘贴，遇到过好些个自己打错打漏删了目录的。Q3. 部署前最后的确认这里介绍的都是个案，不过还是需要提一下：确保每个节点的hostname都设置正确，并且添加至/etc/hosts文件中，然后同步到所有节点下。克隆出来的虚拟机或者批量建的虚拟机有可能发生此情形。确保以下目录在各个节点都存在：/var/lib/ceph//var/lib/ceph/mon//var/lib/ceph/osd//etc/ceph//var/run/ceph/上面的目录，如果Ceph版本大于等于jewel,请确认权限均为ceph:ceph，如果是root:root，请自行chown。Q4. 安装Ceph官网指导方法是使用ceph-deploy install nodeX,但是因为是国外的源，速度慢得令人发指，所以我们换到阿里的源，并且使用yum install的方式安装，没差啦其实，这样反而还快点，毕竟多个节点一起装。很多安装失败的都是因为没有添加epel源请在每个存储节点都执行以下指令，来安装Ceph:yum clean allrm -rf /etc/yum.repos.d/.repowget -O /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repowget -O /etc/yum.repos.d/epel.repo http://mirrors.aliyun.com/repo/epel-7.reposed -i ‘/aliyuncs/d’ /etc/yum.repos.d/CentOS-Base.reposed -i ‘/aliyuncs/d’ /etc/yum.repos.d/epel.reposed -i ’s/$releasever/7.2.1511/g’ /etc/yum.repos.d/CentOS-Base.repoecho “[ceph]name=cephbaseurl=http://mirrors.aliyun.com/ceph/rpm-hammer/el7/x86_64/gpgcheck=0[ceph-noarch]name=cephnoarchbaseurl=http://mirrors.aliyun.com/ceph/rpm-hammer/el7/noarch/gpgcheck=0” > /etc/yum.repos.d/ceph.repoyum install ceph ceph-radosgw -y这里是安装的hammer版本的Ceph，如果需要安装jewel版本的，请执行：sed -i ’s/hammer/jewel/’ /etc/yum.repos.d/ceph.repoyum install ceph ceph-radosgw -y如果安装了jewel版本的Ceph，想要换回hammer版本的Ceph，可以执行下面的指令：卸载Ceph客户端rpm -qa |grep ceph -v |awk '{print $3}' |xargs rpm -e –nodeps更改ceph.repo里面的Ceph版本sed -i ’s/jewel/hammer/’ /etc/yum.repos.d/ceph.repoyum install ceph ceph-radosgw -yQ5. ceph-deploy这里我要开启话唠模式：① Ceph-deploy 是什么？Ceph-deploy是Ceph官方给出的用于部署Ceph的一个工具，这个工具几乎全部是Python写的脚本，其代码位于/usr/lib/python2.7/site-packages/ceph_deploy目录下(1.5.36版本)。最主要的功能就是用几个简单的指令部署好一个集群，而不是手动部署操碎了心，敲错一个地方就可能失败。所以对于新人来说，或者说以我的经验，接触Ceph少于一个月的，又或者说，集群规模不上PB的，都没有必要手动部署，Ceph-deploy完全足够了。② Ceph-deploy怎么装?这个包在ceph的源里面：yum install ceph-deploy -y③Ceph-deploy装在哪？既然Ceph-deploy只是个部署Ceph的脚本工具而已，那么这个工具随便装在哪个节点都可以，并不需要单独为了装这个工具再搞个节点，我一般习惯放在第一个节点，以后好找部署目录。④Ceph-deploy怎么用？详细的指令暂时不介绍，下面会有，在安装好后，需要在这个节点新建一个目录，用作部署目录，这里是强烈建议建一个单独的目录的，比如我习惯在集群的第一个节点下建一个/root/cluster目录，为了以后好找。Ceph-deploy的所有的指令都需要在这个目录下执行。包括new,mon,osd等等一切ceph-deploy的指令都需要在这个部署目录下执行！最后一遍，所有的ceph-deploy的指令都要在部署目录下执行！否则就会报下面的错：[ceph_deploy][ERROR ] ConfigError: Cannot load config: [Errno 2] No such file or directory: ‘ceph.conf’; has ceph-deploy new been run in this directory?⑤ Ceph-deploy怎么部署集群?我们暂且把部署目录所在的节点叫做部署节点。Ceph-deploy通过SSH到各个节点，然后再在各个节点执行本机的Ceph指令来创建MON或者OSD等。所以在部署之前，你需要从部署节点ssh-copy-id到各个集群节点，使其可以免秘钥登陆。⑥Ceph-deploy部署的日志在哪里?就在部署目录下面的ceph-deploy-ceph.log文件，部署过程中产生的所有的日志都会保存在里面，比如你大半年前敲的创建OSD的指令。在哪个目录下执行ceph-deploy指令，就会在这个目录下生成log，如果你跑到别的目录下执行，就会在执行目录里生成log再记下第四点的错。当然，这个LOG最有用的地方还是里面记录的部署指令，你可以通过cat ceph-deploy-ceph.log |grep “Running command"查看到创建一个集群所需的所有指令，这对你手动建立集群或者创建秘钥等等等等有着很大的帮助！！！⑦ Ceph-deploy版本写这段时的最新的版本号为1.5.36，下载链接为ceph-deploy-1.5.36-0.noarch.rpm， 之前的1.5.35里面有点bug在这个版本被修复了，如果使用1.5.25部署遇到了问题，可以更新至这个版本，会绕过一些坑。更新到1.5.36之后，腰也不酸了,退了不疼了，Ceph也能部署上了。Q6. ceph-deploy new 做了什么进入部署目录，执行ceph-deploy new node1 node2 node3，会生成两个文件（第三个是ceph-deploy-ceph.log，忽视之）:[root@blog cluster]# lsceph.conf ceph-deploy-ceph.log ceph.mon.keyringnew后面跟的是你即将部署MON的节点的hostname，推荐三个就够了，需要是奇数个MON节点。不要因为只有两个节点就搞两个MON，两个节点请用一个MON，因为两个MON挂掉一个，集群也就挂了，和一个MON挂掉一个效果是一样的。生成的ceph.conf默认情况下长成这样：[root@blog cluster]# cat ceph.conf [global]fsid = 13b5d863-75aa-479d-84ba-9e5edd881ec9mon_initial_members = blogmon_host = 1.2.3.4auth_cluster_required = cephxauth_service_required = cephxauth_client_required = cephx会调用uuidgen生成一个fsid，用作集群的唯一ID，再将new后面的主机加入到mon_initial_members和mon_host里面，剩下的三行大家都是一样的，默认开启CephX认证。下面有一节会专门介绍这个，需要注意的是，部署的时候，千万不要动这三行 下面会有一节介绍之。还有一个文件ceph.mon.keyring：[root@blog cluster]# cat ceph.mon.keyring [mon.]key = AQB1yWRYAAAAABAAhMoAcadfCdy9VtAaY79+Sw==caps mon = allow 除了key的内容不一样，剩下的都会是一样的。因为是开启了CephX认证了，所以MON直接的通讯是需要一个秘钥的，key的内容就是秘钥。是不是对Ceph里面的明文认证感到吃惊，有总比没有强。如果，你再次执行new，会生成新的ceph.conf和新的ceph.mon.keyring，并将之前的这两个文件给覆盖掉，新旧文件唯一不同的就是fsid和key的内容，但是对Ceph来说，这就是两个集群了。这里说一下我个人非常非常非常反感的一个问题，有的朋友喜欢在/etc/ceph/目录下面执行ceph-deploy的命令，这么做和在部署目录下面做一般是没有差别的，因为这两个目录下面都有ceph.conf和ceph.client.admin.keyring，但是我还是强烈推荐创建独立的部署目录，因为/etc/ceph目录是Ceph节点的运行目录，为了体现各自的功能性，也为了安全性，请不要在/etc/ceph**目录下部署集群！！！Q7. 为ceph-deploy添加参数Ceph-deploy的log还是很有看头的，查看ceph-deploy new blog(blog是我的一台主机)的log：[root@blog cluster]# ceph-deploy new blog[ceph_deploy.conf][DEBUG ] found configuration file at: /root/.cephdeploy.conf[ceph_deploy.cli][INFO ] Invoked (1.5.36): /usr/bin/ceph-deploy new blog[ceph_deploy.cli][INFO ] ceph-deploy options:[ceph_deploy.cli][INFO ] username : None[ceph_deploy.cli][INFO ] func : <function new at 0x288e2a8>[ceph_deploy.cli][INFO ] verbose : False[ceph_deploy.cli][INFO ] overwrite_conf : False[ceph_deploy.cli][INFO ] quiet : False[ceph_deploy.cli][INFO ] cd_conf : <ceph_deploy.conf.cephdeploy.Conf instance at 0x28eccf8>[ceph_deploy.cli][INFO ] cluster : ceph[ceph_deploy.cli][INFO ] ssh_copykey : True[ceph_deploy.cli][INFO ] mon : [‘blog’][ceph_deploy.cli][INFO ] public_network : None[ceph_deploy.cli][INFO ] ceph_conf : None[ceph_deploy.cli][INFO ] cluster_network : None[ceph_deploy.cli][INFO ] default_release : False[ceph_deploy.cli][INFO ] fsid : None[ceph_deploy.new][DEBUG ] Creating new cluster named ceph可以看到有很多的参数被列出来了，比如：mon : [‘blog’]，也有很多参数是False或者None， 这些参数能否被设置呢? 因为这里我们可以看到有fsid : None 这个参数，难道集群的fsid可以被指定吗？抱着这些疑惑，我就去看完了ceph-deploy的所有代码，答案是：可以设置。所有上面的参数都可以使用参数的形式进行设置，只需要在前面加上两个–，比如对于fsid可以执行：ceph-deploy new blog –fsid xx-xx-xx-xxxx如果想要查看每个执行可指定的参数，可以-h：[root@blog cluster]# ceph-deploy new -husage: ceph-deploy new [-h] [–no-ssh-copykey] [–fsid FSID] [–cluster-network CLUSTER_NETWORK] [–public-network PUBLIC_NETWORK] MON [MON …]…optional arguments: -h, –help show this help message and exit –no-ssh-copykey do not attempt to copy SSH keys –fsid FSID provide an alternate FSID for ceph.conf generation –cluster-network CLUSTER_NETWORK specify the (internal) cluster network –public-network PUBLIC_NETWORK specify the public network for a cluster这里就可以看到可以指定–cluster-network，–public-network，等等，如果optional arguments里面没有介绍这个参数，可以直接使用–xxarg的方式指定，比如–overwrite-conf，–verbose等等，能不能设置这些参数，自己动手试一下就知道了。需要注意的是，参数的位置根据指令而异，比如–overwrite-conf参数是跟在ceph-deploy后面的，而–public-network是跟在new后面的：ceph-deploy –overwrite-conf –verbose new blog –fsid a-a-a-a[root@blog cluster]# cat ceph.conf |grep fsidfsid = a-a-a-aQ8. Public VS Cluster如果非要在刚刚生成的ceph.conf里面添加什么的话，那么可能就要加public_network或者cluster_network了。那么这两个配置项有什么用呢？这里简单得介绍下Ceph的Public(外网或者叫公网或者前端网)和Cluster(内网或者叫集群网或者叫后端网)这两个网络，在Ceph中，存在以下三种主要的网络通讯关系：client-> mon =>public : 也就是客户端获取集群状态，或者叫客户端与MON通讯走的网络，是走的外网。client-> osd => public : 也就是客户端向OSD直接写入数据走的也是外网。osd<-> osd => cluster ：也就是OSD之间的数据克隆，恢复走的是内网，客户端写第一份数据时通过外网写，对于三副本剩下的两个副本OSD之间通过内网完成数据复制。当OSD挂掉之后产生的recover,走的也是内网。通常，我们会将外网配置为千兆网，而内网配置成万兆网，这是有一定原因的：客户端可能由成百上千的计算节点组成，外网配成万兆成本太高。存储节点一般只有几个到几十个节点，配置了万兆内网可以大大加快故障恢复速度，而且剩余的两副本写速度会大大加快，万兆网的性价比极高。举个例子，集群坏掉一个OSD千兆需要一小时，那么万兆网只需要五六分钟，一定程度上增加了集群的安全性。借用官网的这张图来说明集群的网络走势：再假设你的节点有两个网段172.23.0.1和3.3.4.1，还记得我们上一节ceph-deploy new的时候是可以指定public_network和cluster_network的吗！如果不指定这两个参数，那么ceph-deploy怎么知道用哪个IP作为这个节点的mon_host的IP呢，其实他是随便选的，如果它选了172网段但是你想使用3.3网段作为这个节点的mon_host的IP，那么只需要指定–public-network 172.23.0.0/24 就可以了，其中的/24就相当于一个掩码，表示前面的IP的前24位，也就是172.23.0.XXX，只要你的主机上有一个处于这个范围内的IP，那么就会选择这个IP作为公网IP。类似的，/16表示范围：172.23.XXX.XXX。 如果想指定内网IP，那么只要指定–cluster-network 3.3.4.1/24就可以了。一般情况下，会在new生成的ceph.conf文件里加入public_network配置项以指定公网IP。当然你的MON主机上需要有至少一个IP在公网范围内。除了在生成的ceph.conf文件中加入公网IP的方式，我们还可以使用参数的方式来指定公网IP：[root@ceph-1 cluster]# ceph-deploy new ceph-1 –public-network 172.23.0.0/24[ceph_deploy.cli][INFO ] Invoked (1.5.36): /usr/bin/ceph-deploy new ceph-1 –public-network 172.23.0.0/24[ceph_deploy.cli][INFO ] ceph-deploy options:…[ceph_deploy.cli][INFO ] public_network : 172.23.0.0/24…[ceph-1][DEBUG ] IP addresses found: [u'172.23.0.101’, u'10.0.2.15’][ceph_deploy.new][DEBUG ] Resolving host ceph-1[ceph_deploy.new][DEBUG ] Monitor ceph-1 at 172.23.0.101[ceph_deploy.new][DEBUG ] Monitor initial members are [‘ceph-1’][ceph_deploy.new][DEBUG ] Monitor addrs are [u'172.23.0.101’][ceph_deploy.new][DEBUG ] Writing monitor keyring to ceph.mon.keyring…[ceph_deploy.new][DEBUG ] Writing initial config to ceph.conf…[root@ceph-1 cluster]# cat ceph.conf [global]fsid = d2a2bccc-b215-4f3e-922b-cf6019068e76public_network = 172.23.0.0/24mon_initial_members = ceph-1mon_host = 172.23.0.101auth_cluster_required = cephxauth_service_required = cephxauth_client_required = cephx查看部署log可以发现参数配置已经生效，而这个节点有两个IP，public_nwtwork这个参数限定了公网IP的搜索范围，生成的ceph.conf文件内也包含了public_network这个参数。Q9. 参数是下划线还是空格分隔这里只是简单的提一下这个小困惑，对于以下的两个参数书写方式，哪种会有问题呢：public_network = 172.23.0.1/24public network = 172.23.0.1/24osd_journal_size = 128osd journal size = 128这两种参数的书写方式其实都是正确的，说到底是因为底层调用的是Python的argparse模块。这两种方式都是等效的，所以不需要担心。Q10. ceph-deploy mon create-initial如何一次性通过这一步坑哭了多少迫切加入Ceph世界的新人，看到的最多的就是5s，10s，10s, 15s，20s。。。然后报了错。再执行，再报错。所以这里给出以下的预检清单，如果被报错失败所烦恼，请认真执行各个子项，尤其是失败后要执行清理环境：请确保所有节点都安装了Ceph。请确保所有节点的防火墙等都关闭了。参考环境预准备一节请前往各个MON节点清理干净，不论你是否相信这个节点是干净的。参考清理环境一节。请确保各个MON节点下存在以下目录，并且对于Jewel版本及之后的请确保目录权限为ceph:ceph。参考部署前最后的确认一节。请在ceph-deploy new生成的ceph.conf内添加public_network配置项，参考Public VS Cluster一节。这些总结来之不易，我帮过上百个人解决过部署问题和集群故障。我相信在认真确认过之后是肯定可以通过的(反正前三点如果有问题一般是不会建好MON的，为什么不认真确认下呢)，我遇到过绝大多数都是因为防火墙没关，或者手动删除了一些目录，或者没有修改权限导致的问题。相对来说，新环境只要关了防火墙就可以一次性通过，旧环境或者失败的环境只要清理环境就可以通过了。Q11. mon create-initial 做了什么简单介绍下流程：ceph-deploy读取配置文件中的mon_initial_members的各个主机，然后依次SSH前往各个主机：将部署目录下的ceph.conf推送到新节点的/etc/ceph/目录下。创建/var/lib/ceph/mon/$cluster-$hostname/目录。检查MON目录下是否有done文件，如果有则直接跳到第6步。将ceph.mon.keyring拷贝到新节点，并利用该秘钥在MON目录下建立MON数据库。在MON目录下建立done文件，防止重新建立MON。启动MON进程。查看/var/run/ceph/$cluster-mon.$hostname.asokSOCKET文件，这个是由MON进程启动后生成的，输出MON状态。在所有的MON都建立好后，再次前往各个主机，查看所有主机是否运行并且到达法定人群(quorum)。如果有没到到的，直接结束报错。如果都到达了，执行下一步。调用auth get-or-create方法创建(如果不存在)或者拉取(已经存在)MON节点上的以下几个keyring到部署目录中：ceph.bootstrap-mds.keyringceph.bootstrap-osd.keyringceph.bootstrap-rgw.keyringceph.client.admin.keyring指令结束。Q12. mon create-initial 为什么会失败我不喜欢讲怎么做，我愿意花很大的篇幅介绍为什么会造成各种各样的问题，如果知道了原因，你自然知道该怎么做，所以才会理解Ceph，而不是机械的去敲指令。综合上面的所有小节，我来总结下这一步失败的基本上所有可能的原因：所谓MON的quorum，相当于多个MON形成的一个群体，它们之间需要通过网络发送数据包来通讯达成某种协议，如果打开了防火墙，会阻断数据交流。所以不能构成群体，一直等待(5s->10s->10s->15s->20s)其他MON的数据包，既然被阻断了这样的等待是没有意义的，等了30s还没有正常，就可以直接ctrl+z去检查了。我在配置文件里面添加了pubilc_network，但是有个主机的所有IP都不在公网IP段内，那么这个MON是建不好的，因为没有IP用作MON使用，public_network相当于一个过滤器。搭好了一台虚拟机后，直接克隆了两台，没有修改主机名，导致socket文件路径名识别错误，报了异常，不过这很少发生。如果在旧的MON节点上再次部署新的MON，再又没有清理环境，之前的MON数据库会保留着done文件，MON数据库里面还是记录着之前fsid，keyring等等，和新集群是两套完全不同的，所以这个节点的MON自然到达不了MON群体。即使你单单删除了/var/lib/ceph/mon下的东西，而没有清理那些keyring，也有可能会因为收集了旧集群的秘钥而发生稀奇古怪的问题。对于Jewel，你一不小心删除了/var/lib/ceph/mon目录，或者其他的OSD目录或者/var/run/ceph目录，然后又重建了目录，依然部署不上，是因为Jewel的所有Ceph指定都是运行在ceph:ceph用户下的，自然不能在root权限目录下建立任何文件，修改权限即可。Ceph生成MON数据库是依照主机的hostname来命名至目录/var/lib/ceph/mon/${cluster}-${hostname}的，而检测SOCKET文件则是用ceph.conf里面的mon_initial_members里面的名字来检测的 ，如果mon_initial_members里面的名字和真是的主机名不一致，就会报错。 一旦你运行了ceph-deploy mon create-initial指令，并且失败了，有极大的可能性已经在某些节点建立好了MON的数据库，再次执行可能会因为旧的环境导致再次失败，所以如果失败了，执行一下第二节中的清理环境即可。清理完毕后，再执行ceph-deploy mon create-initial。相关阅读RMAN 配置、监控与管理Hadoop学习11–Ha集群配置启动rsync 服务部署详解 【每日课程推荐】机器学习实战！快速入门在线广告业务及CTR相应知识 ...