① 如何配置ceph分布式存储方案
1、对象存储：即radosgw,兼容S3接口。通过rest api上传、下载文件。2、文件系统：posix接口。专可以将ceph集群看做一属个共享文件系统挂载到本地。3、块存储：即rbd。有kernel rbd和librbd两种使用方式。支持快照、克隆。相当于一块硬盘挂到本地，用法和用途和硬盘一样。
② Ceph 架构与原理
Ceph 是一个开源项目，它提供软件定义的、统一的存储解决方案 。Ceph 是一个具有高性能、高度可伸缩性、可大规模扩展并且无单点故障的分布式存储系统 。 Ceph 是软件定义存储解决方案 Ceph 是统一存储解决方案 Ceph 是云存储解决方案 高可用性 高扩展性 特性丰富 Ceph独一无二地统一的系统提供了对象存储、块存储和文件存储功能。Ceph存储集群由几个不同的软件守护进程组成（比较重要的两个是MON和OSD），每个守护进程负责Ceph的一个独特功能并将值添加到相应的组件中。 RADOS是CEPH存储系统的核心,也称为Ceph 存储集群。Ceph的数据访问方法(如RBD,CephFS,RADOSGW，librados)的所有操作都是在RADOS层之上构建的。当Ceph 集群接收到来自客户端的请求时,CRUSH算法首先计算出存储位置,最后将这些对象存储在OSD中,当配置的复制数大于1时,RADOS负责的形式将数据分发到集群内的所有节点,最后将这些对象存储在OSD中。当配置的复制数大于1时,RADOS负责数据的可靠性,它复制对象，创建副本并将它们存储在不同的故障区域中。 RADOS包含两个核心组件: OSD和MON OSD 是Ceph 存储集群中最重要的一个基础组件，他负责将实际的数据以对象的形式存储在每一个集群节点的物理磁盘中。对于任何读写操作，客户端首先向MON请求集群MAP，然后客户端旧可以直接和OSD进行I/O操作。 一个Ceph 集群包含多个OSD。一个典型的Ceph集群方案会为集群节点上的每个物理磁盘创建一个ODS守护进程,这个是推荐的做法。OSD上的每个对象都有一个主副本和几个辅副本,辅副本分散在其他OSD。一个OSD对于一些对象是主副本，同时对于其他对象可能是辅副本，存放辅副本的OSD主副本OSD控制,如果主副本OSD异常(或者对应的磁盘故障),辅副本OSD可以成为主副本OSD。 OSD是有一个已经存在的linux文件系统的物理磁盘驱动器和OSD服务组成。Ceph 推荐OSD使用的文件系统是XFS。OSD的所有写都是先存到日志,再到存储. MON 负责监控整个集群的健康状况。它以守护进程的形式存在,一个MON为每一个组件维护一个独立的MAP,如OSD，MON,PG,CRUSH 和MDS map。这些map 统称为集群的MAP。MON 不为客户端存储和提供数据,它为客户端以及集群内其他节点提供更新集群MAP的服务。客户端和集群内其他节点定期与MON确认自己持有的是否是集群最新的MAP.一个Ceph集群通常包含多个MON节点,但是同一时间只有一个MON。 librados是一个本地的C语言库，通过它应用程序可以直接和RADOS通信，提高性能 Ceph 块存储，简称 RBD，是基于 librados 之上的块存储服务接口。RBD 的驱动程序已经被集成到 Linux 内核（2.6.39 或更高版本）中，也已经被 QEMU/KVM Hypervisor 支持，它们都能够无缝地访问 Ceph 块设备。Linux 内核 RBD（KRBD）通过 librados 映射 Ceph 块设备，然后 RADOS 将 Ceph 块设备的数据对象以分布式的方式存储在集群节点中 RGW，Ceph对象网关，也称做RADOS网关，它是一个代理，可以将HTTP请求转换为RADOS，也可以把RADOS转换为HTTP请求，从而提供restful接口，兼容S3和Swift。Ceph对象网关使用Ceph对象网关守护进程(RGW)与librgw、librados交互。Ceph对象网关支持三类接口：S3、Swift、管理API（通过restful接口管理Ceph集群）。RGW有自己的用户管理体系 Ceph 元数据服务器服务进程，简称 MDS。只有在启用了 Ceph 文件存储（CephFS）的集群中才需要启用 MDS，它负责跟踪文件层次结构，存储和管理 CephFS 的元数据。MDS 的元数据也是以 Obejct 的形式存储在 OSD 上。除此之外，MDS 提供了一个带智能缓存层的共享型连续文件系统，可以大大减少 OSD 读写操作频率。 CephFS在RADOS层之上提供了一个兼容POSIX的文件系统。它使用MDS作为守护进程，负责管理其元数据并将它和其他数据分开。CephFS使用cephfuse模块（FUSE）扩展其在用户空间文件系统方面的支持（就是将CephFS挂载到客户端机器上）。它还允许直接与应用程序交互，使用libcephfs库直接访问RADOS集群。 Ceph管理器软件，可以收集整个集群的所有状态。有仪表板插件 一个对象通常包含绑定在一起的数据和元数据，并且用一个全局唯一的标识符标识。这个唯一的标识符确保在整个存储集群中没有其他对象使用相同的对象ID，保证对象唯一性。基于文件的存储中，文件大小是有限制的，与此不同的是，对象的大小是可以随着大小可变的元数据而变得很大。对象不使用一个目录层次结构或树结构来存储，相反，它存储在一个包含数十亿对象且没有任何复杂性的线性地址空间中。对象可以存储在本地，也可以存放在地理上分开的线性地址空间中，也就是说，在一个连续的存储空间中。任何应用程序都可以基于对象ID通过调用restful API从对象中获取数据。这个URL可以以同样的方式工作在因特网上，一个对象ID作为一个唯一的指针指向对象。这些对象都以复制的方式存储在OSD中，因为能提供高可用性。 对于Ceph集群的一次读写操作，客户端首先联系MON获取一个集群map副本，然后使用对象和池名/ID将数据转换为对象。接着将对象和PG数一起经过散列来生成其在Ceph池中最终存放的那一个PG。然后前面计算好的PG经过CRUSH查找来确定存储或获取数据所需的主OSD的位置。得到准确的OSD ID之后，客户端直接联系这个OSD来存取数据。所有这些计算操作都由客户端来执行，因此它不会影响Ceph集群的性能。一旦数据被写入主OSD，主OSD所在节点将执行CRUSH查找辅助PG和OSD的位置来实现数据复制，进而实现高可用。 简单地说，首先基于池ID将对象名和集群PG数应用散列函数得到一个PG ID，然后，针对这个PG ID执行CRUSH查找得到主OSD和辅助OSD，最后写入数据。 PG是一组对象地逻辑集合，通过复制它到不同的OSD上来提供存储系统的可靠性。根据Ceph池的复制级别，每个PG的数据会被复制并分发到Ceph集群的多个OSD上。可以将PG看成一个逻辑容器，这个容器包含多个对象，同时这个逻辑容器被映射到多个OSD。 计算正确的PG数对一个Ceph存储集群来说是至关重要的一步。PG数计算公式如下 Ceph池是一个用来存储对象的逻辑分区，每个池都包含一定数量的PG，进而实现把一定数量的对象映射到集群内部不同OSD上的目的。每一个池都是交叉分布在集群所有节点上的，这样就能提供足够的弹性。池可以通过创建需要的副本数来保障数据的高可用性。 Ceph的池还支持快照功能，我们可以使用ceph osd pool mksnap命令来给特定的池制作快照。此外，Ceph池还允许我们为对象设置所有者和访问权限。 数据管理始于客户端向Ceph池中写数据。一旦客户端准备写数据到Ceph池中，数据首先写入基于池副本数的主OSD中。主OSD再复制相同的数据到每个辅助OSD中，并等待它们确认写入完成。只要辅助OSD完成数据写入，就会发送一个应答信号给主OSD。最后主OSD再返回一个应答信号给客户端，以确认完成整个写入操作。
③ ceph支持哪些存储类型
（1）提供块存储，可以直接以逻辑卷的方式对外提供块设备服务。
（2）通过集群的对象存储网关，对外同时提供swift和S3风格的对象存储服务。
（3）提供可供挂载的类POSIX文件存储。
④ ceph（第三步） 基本使用
系统的开始使用一个 ceph 集群。
本文将系统的介绍如何使用一个 ceph 集群。
涉及： crush、osd、pool、cache
ceph 版本：nautilus ceph-deploy 版本：2.0.1
在基本使用需求下，一般需要存储集群提供高性能存储（SSD）和普通存储（hdd）。
在 ceph 中，具体表现为某些池使用高性能存储，某些池使用普通存储。而这种需求在 ceph 中由 crush 规则实现。
ceph 提供了缓存的概念。在普通的存储池之上架设一层高性能的缓存池，外部访问首先到达缓存池，如果发生未命中等情况再去访问存储池。这里需要提一点，并不是任何情况都需要缓存。
针对不同的场景，ceph 的使用方式多种多样，这里的介绍只能一切从简，但是会尽量全面。
一个标准的场景：一个存储池加一个缓存池，存储池使用普通设备，缓存池使用高性能设备。
首先添加一块高性能硬盘（我这里是虚拟环境，只能用普通硬盘充数）
然后需要利用 crush 让不同池使用不同的存储设备
这里只能拿普通的虚拟硬盘来做测试。
在 ceph02 虚拟机上增加一块 30G 的虚拟硬盘。 在 ceph03 虚拟机上增加一块 30G 的虚拟硬盘。
现在到部署节点进行操作：
如图 ceph02 出现了 osd.6，ceph03 出现了 osd.7。
这里涉及到 root （根）的概念，在文章末尾【扩展】中会介绍。这里可以直接先使用。
将 osd.6 osd.7 加入名称为 cache 的根中（根名称会自动创建，注意，由于默认情况下 osd 在启动时读取的是 hostname，因此该方法只是临时生效，在文章末尾【扩展】中会介绍永久生效办法）
“高性能”存储盘现在已经有了，并且将其置于 cache 根下，这么做的意义在下一步中有体现。
现在可以进行下一步了。
当前环境下已经有一个默认的 crush 规则。
具体属性解释参考： https://docs.ceph.com/docs/mimic/rados/operations/crush-map-edits/#crush-map-rules
如上图划线处，当前规则只会使用 default 根的 osd。
前面创建高性能设备时，将其设置根为 cache。我们现在就可以创建一个只使用 cache 根中的 osd 的规则，从而实现缓存池和存储池使用不同的设备。
创建缓存池使用的规则：
其中： replicated_cache 指该规则的名字。 cache 指该规则使用的根。 host 指故障域级别。
再次查看所有规则：
现在我们有了一个只使用高性能存储设备的规则了。接下来就可以开始创建使用不同规则的池了。
创建存储池：
查看池：
查看该池的规则：
存储池至此已经好了。
缓存池在 ceph 中常以 hot 标识。 普通存储池在 ceph 中常以 cold 标识。
缓存有多种形式（官方文档列出以下几种，实际更多）：
缓存参考： https://docs.ceph.com/docs/master/rados/operations/cache-tiering/
创建缓存池
缓存池创建好以后，要将这个缓存池与对应存储池联系起来。这个联系的概念叫做 cache tiering，可以称之为缓存层，缓存代理。
参考： https://docs.ceph.com/docs/master/rados/operations/cache-tiering/
对于 test_storage 池，我们有一个只读的缓存池了。只要我们读取 test_storage 中的某个对象，这个对象就应该自动的置于缓存池中一段时间。
可以发现，将对象上传回写模式的缓存池，存储池中也出现了对应的数据。
osd 的大小可能不相同，因此其上的数据量也不应该相同，因此引入权重来影响数据分布。 比如100G的 osd 权重为1，则200G的 osd 权重就应设置为2。
ceph osd tree 命令可以看到存储结构。可以结合自己机器执行的结果往下阅读。
一张官方图：
这是描述 ceph 存储结构的一张图。
首先这是一个树形结构。
其中最上层的 root default ：root 是根的意思，default 就是这个根的名字。
中间 host foo ：host 是主机的意思，foo 就是这个主机的名字。这里的主机名仅仅是个别称，不代表实际的主机，可以随意更改。
最下面的就是叶子节点了，具体指向 osd。
划分这三层结构的意义（不完全）：
本文使用 ceph-deploy 添加 osd 时，并没有直接将其设置到最终根下，后续还需要手动配置。这么操作是不合理的，暂时未找到 ceph-deploy 指定根的参数。
当前文章配置的缓存池是2副本的。
某些时候，缓存数据是允许丢失的，比如只读的缓存。这种缓存池单副本即可，但是经测试，单副本池在 ceph 中似乎困难重重。
可以通过修改该机器的 hostname ，一劳永逸
这个时候，当机器重启后，该机器的所有 osd 的 host 名称都一样了，导致 osd tree 混乱。这个时候可以在 ceph.conf 中具体配置某块盘的信息。
当前环境配置参考：
增加如下内容：
重启后，一切正常。
在 osd 的启动上做文章。 比如，配置 osd 的启动方式，容器化 osd，容器会记住某些信息，因此可以实现永久生效 hostname。
osd 上的 pg 数量会对整体集群性能造成影响，并不是越多越好，也不是越少越好。
由于池有副本的概念，因此产生了如下的计算方式：
官方建议每个 osd 上的 pg 数为 100。实际测试每个 osd 上的 pg 数到达 250 时开始告警，因此该集群的总 pg 数不应超过：
因此出现此问题的原因： 所有池的 pg 数加起来超过了设定的 总 pg 数 。但集群依然可正常使用，因此只是一个警告。
解决该问题的手段：
目前个人经验来说，不要使用单副本。
crush 规则参考： https://docs.ceph.com/docs/master/rados/operations/crush-map/
⑤ 如何在CentOS 7.0上配置Ceph存储
Ceph 是一个将数据存储在单一分布式计算机集群上的开源软件平台。当你计划构建一个云时，你首先需要决定如何实现你的存储。开源的 Ceph 是红帽原生技术之一，它基于称为 RADOS 的对象存储系统，用一组网关 API 表示块、文件、和对象模式中的数据。由于它自身开源的特性，这种便携存储平台能在公有云和私有云上安装和使用。Ceph 集群的拓扑结构是按照备份和信息分布设计的，这种内在设计能提供数据完整性。它的设计目标就是容错、通过正确配置能运行于商业硬件和一些更高级的系统。Ceph 能在任何 Linux 发行版上安装，但为了能正确运行，它需要最近的内核以及其它最新的库。在这篇指南中，我们会使用最小化安装的 CentOS-7.0。系统资源**CEPH-STORAGE**OS:CentOSLinux7(Core)RAM:1 GBCPU:1 CPUDISK:20Network:45.79.136.163FQDN: ceph-storage.linoxide.com**CEPH-NODE**OS:CentOSLinux7(Core)RAM:1 GBCPU:1 CPUDISK:20Network:45.79.171.138FQDN: ceph-node.linoxide.com 安装前的配置在安装 Ceph 存储之前，我们要在每个节点上完成一些步骤。第一件事情就是确保每个节点的网络已经配置好并且能相互访问。配置 Hosts要在每个节点上配置 hosts 条目，要像下面这样打开默认的 hosts 配置文件（LCTT 译注：或者做相应的 DNS 解析）。#vi/etc/hosts45.79.136.163 ceph-storage ceph-storage.linoxide.com45.79.171.138 ceph-node ceph-node.linoxide.com安装 VMware 工具工作环境是 VMWare 虚拟环境时，推荐你安装它的 open VM 工具。你可以使用下面的命令安装。#yum install -y open-vm-tools配置防火墙如果你正在使用启用了防火墙的限制性环境，确保在你的 Ceph 存储管理节点和客户端节点中开放了以下的端口。你必须在你的 Admin Calamari 节点开放 80、2003、以及4505-4506 端口，并且允许通过 80 号端口访问到 Ceph 或 Calamari 管理节点，以便你网络中的客户端能访问 Calamari web 用户界面。你可以使用下面的命令在 CentOS 7 中启动并启用防火墙。#systemctl start firewalld#systemctl enable firewalld运行以下命令使 Admin Calamari 节点开放上面提到的端口。# firewall-cmd –zone=public–add-port=80/tcp –permanent# firewall-cmd –zone=public–add-port=2003/tcp –permanent# firewall-cmd –zone=public–add-port=4505-4506/tcp –permanent# firewall-cmd –reload在 Ceph Monitor 节点，你要在防火墙中允许通过以下端口。# firewall-cmd –zone=public–add-port=6789/tcp –permanent然后允许以下默认端口列表，以便能和客户端以及监控节点交互，并发送数据到其它 OSD。# firewall-cmd –zone=public–add-port=6800-7300/tcp –permanent如果你工作在非生产环境，建议你停用防火墙以及 SELinux 设置，在我们的测试环境中我们会停用防火墙以及 SELinux。#systemctl stop firewalld#systemctl disable firewalld系统升级现在升级你的系统并重启使所需更改生效。#yum update#shutdown-r 0 设置 Ceph 用户现在我们会新建一个单独的 sudo 用户用于在每个节点安装 ceph-deploy工具，并允许该用户无密码访问每个节点，因为它需要在 Ceph 节点上安装软件和配置文件而不会有输入密码提示。运行下面的命令在 ceph-storage 主机上新建有独立 home 目录的新用户。[[email protected] ~]#useradd-d /home/ceph -m ceph[[email protected] ~]#passwd ceph节点中新建的每个用户都要有 sudo 权限，你可以使用下面展示的命令赋予 sudo 权限。[[email protected] ~]#echo"ceph ALL = (root) NOPASSWD:ALL"|sudotee/etc/sudoers.d/cephceph ALL =(root) NOPASSWD:ALL[[email protected] ~]#sudochmod0440/etc/sudoers.d/ceph 设置 SSH 密钥现在我们会在 Ceph 管理节点生成 ssh 密钥并把密钥复制到每个 Ceph 集群节点。在 ceph-node 运行下面的命令复制它的 ssh 密钥到 ceph-storage。[[email protected] ~]#ssh-keygenGeneratingpublic/private rsa key pair.Enterfilein which to save the key (/root/.ssh/id_rsa):Created directory '/root/.ssh'.Enter passphrase (emptyforno passphrase):Enter same passphrase again:Your identification has been saved in/root/.ssh/id_rsa.Yourpublic key has been saved in/root/.ssh/id_rsa.pub.The key fingerprint is:5b:*:*:*:*:*:*:*:*:*:c9 [email protected]The key's randomart image is:+–[ RSA 2048]—-+[[email protected] ~]#ssh–id [email protected]SSH key 配置 PID 数目要配置 PID 数目的值，我们会使用下面的命令检查默认的内核值。默认情况下，是一个小的最大线程数 32768。如下图所示通过编辑系统配置文件配置该值为一个更大的数。更改 PID 值 配置管理节点服务器配置并验证了所有网络后，我们现在使用 ceph 用户安装 ceph-deploy。通过打开文件检查 hosts 条目（LCTT 译注：你也可以用 DNS 解析来完成）。#vim/etc/hostsceph-storage 45.79.136.163ceph-node 45.79.171.138运行下面的命令添加它的库。# rpm -Uhv http://ceph.com/rpm-giant/el7/noarch/ceph-release-1-0.el7.noarch.rpm添加 Ceph 仓仓库或者创建一个新文件并更新 Ceph 库参数，别忘了替换你当前的 Release 和版本号。[[email protected] ~]#vi/etc/yum.repos.d/ceph.repo[ceph-noarch]name=Ceph noarch packagesbaseurl=http://ceph.com/rpm-{ceph-release}/{distro}/noarchenabled=1gpgcheck=1type=rpm-mdgpgkey=https://ceph.com/git/?p=ceph.git;a=blob_plain;f=keys/release.asc之后更新你的系统并安装 ceph-deploy 软件包。 安装 ceph-deploy 软件包我们运行下面的命令以及 ceph-deploy 安装命令来更新系统以及最新的 ceph 库和其它软件包。#yum update -y &&yum install ceph-deploy -y 配置集群使用下面的命令在 ceph 管理节点上新建一个目录并进入新目录，用于收集所有输出文件和日志。#mkdir~/ceph-cluster#cd~/ceph-cluster# ceph-deploy new storage设置 ceph 集群如果成功执行了上面的命令，你会看到它新建了配置文件。现在配置 Ceph 默认的配置文件，用任意编辑器打开它并在会影响你公共网络的 global 参数下面添加以下两行。#vim ceph.confosd pool defaultsize=1public network =45.79.0.0/16 安装 Ceph现在我们准备在和 Ceph 集群关联的每个节点上安装 Ceph。我们使用下面的命令在 ceph-storage 和 ceph-node 上安装 Ceph。# ceph-deploy install ceph-node ceph-storage安装 ceph处理所有所需仓库和安装所需软件包会需要一些时间。当两个节点上的 ceph 安装过程都完成后，我们下一步会通过在相同节点上运行以下命令创建监视器并收集密钥。# ceph-deploy mon create-initialCeph 初始化监视器 设置 OSD 和 OSD 守护进程现在我们会设置磁盘存储，首先运行下面的命令列出你所有可用的磁盘。# ceph-deploy disk list ceph-storage结果中会列出你存储节点中使用的磁盘，你会用它们来创建 OSD。让我们运行以下命令，请使用你的磁盘名称。# ceph-deploy disk zap storage:sda# ceph-deploy disk zap storage:sdb为了最后完成 OSD 配置，运行下面的命令配置日志磁盘以及数据磁盘。# ceph-deploy osd prepare storage:sdb:/dev/sda# ceph-deploy osd activate storage:/dev/sdb1:/dev/sda1你需要在所有节点上运行相同的命令，它会清除你磁盘上的所有东西。之后为了集群能运转起来，我们需要使用以下命令从 ceph 管理节点复制不同的密钥和配置文件到所有相关节点。# ceph-deploy admin ceph-node ceph-storage 测试 Ceph我们快完成了 Ceph 集群设置，让我们在 ceph 管理节点上运行下面的命令检查正在运行的 ceph 状态。# ceph status# ceph healthHEALTH_OK如果你在 ceph status 中没有看到任何错误信息，就意味着你成功地在 CentOS 7 上安装了 ceph 存储集群。
⑥ Ceph高可用部署和主要组件介绍
本教程用官网最近的cephadm来搭建ceph集群。 第一周作业：1.ceph的组件和功能2.ceph的数据读写流程3.使用ceph-deploy安装一个最少三个节点的ceph集群 推荐3个或以上的磁盘作为专用osd 4.测试ceph的rbd使用 1·Ceph组件和功能 组件 Ceph OSDs : ( Ceph OSD ）object storage daemon的功能是存储数据，处理数据的复制、恢复、回填、再均衡，并通过检查其他OSD 守护进程的心跳来向 Ceph Monitors 提供一些监控信息。当 Ceph 存储集群设定为有2个副本时，至少需要2个 OSD 守护进程，集群才能达到 active+clean 状态（ Ceph 默认有3个副本，但你可以调整副本数）。 Monitors : 维护着展示集群状态的各种图表，包括监视器图、 OSD 图、归置组（ PG ）图、和 CRUSH 图。 Ceph 保存着发生在Monitors 、 OSD 和 PG上的每一次状态变更的历史信息（称为 epoch ）。 MDSs : Ceph 元数据服务器为 Ceph 文件系统存储元数据（也就是说，Ceph 块设备和 Ceph 对象存储不使用MDS ）。元数据服务器使得 POSIX 文件系统的用户们，可以在不对 Ceph 存储集群造成负担的前提下，执行诸如 ls、find 等基本命令。 CephMgr ：在一个主机上的守护进程，负责运行指标，运行状态，性能负载， 其他术语： RADOS：多个主机组成的存储集群，即可靠，自动化，分布式的对象存储系统。 File: 就是普通文件，ObjectRADOS看到的对象，Object与File的区别是， Object的最大尺寸由RADOS限定(通常为2MB或4MB) ，以便实现底层存储的组织管理。因此，当上层应用向RADOS存入尺寸很大的File时，需要将File切分成统一大小的一系列Objet (最后一个的大小可以不同)进行存储。 librados：RADOS集群的API，支持大部分主流语言。 Pool：存储池，大小取决于底层的存储空间。 PG：placeholder group，一个pool（存储池）内可以有多个PG，pool个pg都是抽象的逻辑概念，可以通过公示计算。PG的用途是对Object的存储进行组织和位置映射的。具体而言，一个PG负责组织若干个Object，但一个Obiect只能被映射到一个PG中，即PG和Object之间是“一对多”的映射关系。同时，一个PG会被映射到n个OSD上，而每个OSD上都会承载大量的PG，即PG和OSD之间是“多对多”的映射关系。在实践当中，n至少为2，如果用于生产环境，则至少为3。一个OSD上的PG可达到数百个。事实上， PG数量的设置关系到数据分布的均匀性问题。 OSD daemon：默认每2秒发送状态数据给monitor，（同时监控组内其他OSD的状态）（up 可以提供IO，down不能提供，in有数据，out没有数据） PG和OSD之间的关系通过CRUSH算法得出的。常规这三个 OSD daemon 可以在一台机器上，也可以在不同机器上；那么根据 CRUSH 算法会尽可能的保证一个平衡，就是不在同一个机器上；毕竟Ceph中的数据是一个为平衡的状态，一切都是通过CRUSH 算法来实现的数据平衡，而 PG 本身是个有序列表，位于第一的位置是 master；这个列表的产生是由 monitor 来产生的； 寻址流程 File->Object映射 这次映射的目的是，将用户要操作的File映射为RADOS能够处理的Object，其十分简单，本质上就是按照Object的最大尺寸（默认4M）对File进行切分，相当于磁盘阵列中的条带化过程。这种切分的好处有两个:一是让大小不限的File变成具有一致的最大尺寸、可以被RADOS高效管理的Object;二是让对单一File实施的串行处理变为对多个Object实施的并行化处理。每一个切分后产生的Object将获得唯一的oid,即Object ID,其产生方式也是线性映射,极其简单。 Object →PG映射 在File被映射为1个或多个Object之后,就需要将每个Object独立地映射到1个PG中去。这个映射过程也很简单,如图所示,其计算公式如下:Hash(oid) & mask -> pgid由此可见,其计算由两步组成。首先,使用Ceph系统指定的一个静态哈希算法计算oid的哈希值,将oid映射为一个近似均匀分布的伪随机值。然后,将这个伪随机值和mask按位相与,得到最终的PG序号(pgid) 。根据RADOS的设计,给定PG的总数为m(m应该为2的整数幂),则mask的值为m-1。因此,哈希值计算和按位与操作的整体结果事实上是从所有m个PG中近似均匀地随机选择1个。基于这一机制,当有大量Object和大量PG时, RADOS能够保证Object和PG之间的近似均匀映射。又因为Object是由File切分而来的,大部分Object的尺寸相同,因此,这一映射最终保证了各个PG中存储的Object的总数据量近似均匀。这里反复强调了“大量” ,意思是只有当Object和PG的数量较多时,这种伪随机关系的近似均匀性才能成立, Ceph的数据存储均匀性才有保证。为保证“大量”的成立,一方面, Object的最大尺寸应该被合理配置,以使得同样数量的File能够被切分成更多的Object;另一方面, Ceph也推荐PG总数应该为OSD总数的数百倍,以保证有足够数量的PG可供映射。 PG→ OSD映射 第3次映射就是将作为Object的逻辑组织单元的PG映射到数据的实际存储单元OSD上。RADOS采用一个名为CRUSH的算法,将pgid代入其中,然后得到一组共n个OSD。这n个OSD共同负责存储和维护一个PG中的所有Objecto前面提到过, n的数值可以根据实际应用中对于可靠性的需求而配置,在生产环境下通常为3。具体到每个OSD,则由其上运行的OSD Daemon负责执行映射到本地的Object在本地文件系统中的存储、访问、元数据维护等操作。和“Object →PG"映射中采用的哈希算法不同, CRUSH算法的结果不是绝对不变的,而会受到其他因素的影响。其影响因素主要有两个。一是当前系统状态,也就是在前面有所提及的集群运行图。当系统中的OSD状态、数量发生变化时,集群运行图也可能发生变化,而这种变化将会影响到PG与OSD之间的映射关系。二是存储策略配置。这里的策略主要与安全相关。利用策略配置,系统管理员可以指定承载同一个PG的3个OSD分别位于数据中心的不同服务器或机架上,从而进一步改善存储的可靠性。因此,只有在系统状态和存储策略都不发生变化的时候, PG和OSD之间的映射关系才是固定不变的。在实际使用中,策略一经配置通常不会改变。而系统状态的改变或是因为设备损坏,或是因为存储集群规模扩大。好在Ceph本身提供了对这种变化的自动化支持,因而,即便PG与OSD之间的映射关系发生了变化,也并不会对应用产生影响。事实上, Ceph正是利用了CRUSH算法的动态特性,可以将一个PG根据需要动态迁移到不同的OSD组合上,从而自动化地实现高可靠性、数据分布再平衡等特性。之所以在此次映射中使用CRUSH算法,而不使用其他哈希算法,一方面原因是CRUSH算法具有上述可配置特性,可以根据管理员的配置参数决定OSD的物理位置映射策略;另一方面原因是CRUSH算法具有特殊的“稳定性" ,也即,当系统中加入新的OSD,导致系统规模增大时,大部分PG与OSD之间的映射关系不会发生改变,只有少部分PG的映射关系会发生变化并引发数据迁移。这种可配置性和稳定性都不是普通哈希算法所能提供的。因此, CRUSH算法的设计也是Ceph的核心内容之一。 至此为止, Ceph通过3次映射,完成了从File到Object. Object到PG,PG再到OSD的整个映射过程。从整个过程可以看到,这里没有任何的全局性查表操作需求。至于唯一的全局性数据结构:集群运行图。它的维护和操作都是轻量级的,不会对系统的可扩展性、性能等因素造成影响 。 存储过程总结： 1.计算文件到对象的映射 2.通过哈希算法计算计算出文件对应的pool的PG 3.通过CRUSH把对象映射到PG中的OSD 4.PG种的OSD将对象写入到磁盘 5.主OSD将数据同步到备份OSD，待备份OSD返回确认 6.主OSD的到备份OSD写完操作以后给客户的返回写入成功 2. ceph的读写流程 当某个客户端需要向Ceph集群写入一个File时，首先需要在本地完成寻址流程，将File变为一个Object，然后找出存储该Object的一组共3个OSD，这3个OSD具有各自不同的序号，序号最靠前的那个OSD就是这一组中的Primary OSD，而后两个则依次Secondary OSD和Tertiary OSD。找出3个OSD后，客户端将直接和Primary OSD进行通信，发起写入操作(步骤1)。 Primary OSD收到请求后，分别向Secondary OSD和Tertiary OSD发起写人操作(步骤2和步骤3)。当Secondary OSD和Tertiary OSD各自完成写入操作后，将分别向Primary OSD发送确认信息(步骤4和步骤5)。当Primary OSD确认其他两个OSD的写入完成后，则自己也完成数据写入，并向客户端确认Object写入操作完成(步骤6)。之所以采用这样的写入流程，本质上是为了保证写入过程中的可靠性，尽可能避免出现数据丢失的情况。同时，由于客户端只需要向Primary OSD发送数据，因此在互联网使用场景下的外网带宽和整体访问延迟又得到了一定程度的优化。当然，这种可靠性机制必然导致较长的延迟，特别是，如果等到所有的OSD都将数据写入磁盘后再向客户端发送确认信号，则整体延迟可能难以忍受。因此， Ceph可以分两次向客户端进行确认。当各个OSD都将数据写入内存缓冲区后，就先向客户端发送一次确认，此时客户端即可以向下执行。待各个OSD都将数据写入磁盘后，会向客户端发送一个最终确认信号，此时客户端可以根据需要删除本地数据。分析上述流程可以看出，在正常情况下，客户端可以独立完成OSD寻址操作，而不必依赖于其他系统模块。因此，大量的客户端可以同时和大量的OSD进行并行操作。同时，如果一个File被切分成多个Object，这多个Object也可被并行发送至多个OSD上。从OSD的角度来看，由于同一个OSD在不同的PG中的角色不同，因此，其工作压力也可以被尽可能均匀地分担，从而避免单个OSD变成性能瓶颈。 问：为什么要设计三层映射而不是一层？ 答：如果将object直接映射到一组OSD上，如果这种算法是固定的哈希算法，则意味着一个object被固定映射在一组OSD上，当其中一个OSD损坏时，object也无法部署到新的OSD上(因为映射函数不允许)。 如果设计一个动态算法(例如CRUSH算法)来完成这一映射，结果将是各个OSD所处理的本地元数据暴增，由此带来的计算复杂度和维护工作量也是难以承受的。 综上所诉，引入PG的好处至少有二：一方面试下呢object和OSD之间的动态映射，从而为Ceph的可靠性、自动化等特性的实现留下了空间；另一方面也有效简化了数据的存储组织，大大降低了系统的维护管理开销。 1.准备工作 时间同步` 安装ntpdate（时间同步工具） # apt install ntpate 0* * * * ntpdate time1.aliyun.com echo'0 * * * * ntpdate time1.aliyun.com'>> /var/spool/cron/crontabs/root 或者 可以通过 ansible all-mshell-a"echo '0 * * * * ntpdate time1.aliyun.com' >> /var/spool/cron/crontabs/root" 关闭 selinux 和防火墙 [email protected]:~# sudo ufw status ##查看状态 Status: inactive [email protected]:~# sudo ufw disable Firewall stopped and disabled on system startup##禁用 [email protected]:~# 配置域名解析或通过 DNS 解析 [email protected]:~# cat /etc/hosts 127.0.0.1 localhost [email protected]:~# hostnamectl set-hostname 对应的名称 ## 以下是新增的 可以按照自己的习惯配置 192.168.106.101 node1 192.168.106.102 node2 192.168.106.103 node3 安装python [email protected]:~# apt install python ##python2 源修改成国内源 — 具体步骤自行网络 https://mirrors.aliyun.com/ceph/#阿里云镜像仓库 http://mirrors.163.com/ceph/#网易镜像仓库 https://mirrors.tuna.tsinghua.e.cn/ceph/#清华大学镜像源 ceph用到的端口 (防火墙和安全中记得放开) Ceph Monitor：启用 Ceph MON 服务或端口 6789 (TCP)。 Ceph OSD 或元数据服务器：启用 Ceph OSD/MDS 服务或端口 6800-7300 (TCP)。 iSCSI 网关：打开端口 3260 (TCP)。 对象网关：打开对象网关通讯所用的端口。此端口在 /etc/ceph.conf 内以 rgw frontends = 开头的行中设置。HTTP 的默认端口为 80，HTTPS (TCP) 的默认端口为 443。 NFS Ganesha：默认情况下，NFS Ganesha 使用端口 2049（NFS 服务、TCP）和 875 （rquota 支持、TCP）。 SSH：打开端口 22 (TCP)。 NTP：打开端口 123 (UDP)。 2.搭建ceph集群 安装cephadm [email protected]:~# wget https://github.com/ceph/ceph/raw/pacific/src/cephadm/cephadm ## node1 管理节点上执行 [email protected]:~# chmod +x cephadm [email protected]:~# ./cephadm add-repo –release pacific ##设置要安装的版本 [email protected]:~# which cephadm ##确认是否安装成功 初始化集群 [email protected]:~# cephadm bootstrap –mon-ip 192.168.106.101 ##ceph集群第一个节点的ip 初始化完了以后就可以访问dashboard了 地址 ： https://node1:8443/#/dashboard 访问用户密码上一步生成 添加其他节点和其他组件 [email protected]:~# ssh-keygen ## 配置免密通信 [email protected]:~# ssh–id -f -i /etc/ceph/ceph.pub [email protected] [email protected]:~# ssh–id -f -i /etc/ceph/ceph.pub [email protected] ## 添加node [email protected]:~# ceph orch host add node2 192.168.106.102 [email protected]:~# ceph orch host add node3 192.168.106.103 ## 添加osd [email protected]:~# ceph orch daemon add osd node1:/dev/sdb [email protected]:~# ceph orch daemon add osd node1:/dev/sdb [email protected]:~# ceph orch daemon add osd node3:/dev/sdb 测试 [email protected]:~# ceph fs volume create testfs ##添加测试fs [email protected]:~# ceph orch apply mds testfs –placement="3" ##设置备份数 [email protected]:~# ceph orch daemon add mds testfs node1 [email protected]:~# ceph mds stat## 在集群之外的或者任意机器上操作 [email protected]:~# apt install ceph-common -y node1初始化集群的节点操作 [email protected]:~# scp /etc/ceph/ceph.client.admin.keyring [email protected]:/etc/ceph## 集群之外的clinet或者测试节点执行 [email protected]:~# mount -t ceph node1:/ /mnt/testfs -o name=admin,secret=AQAoJjBh7OPVNhAAQZyzLhDfgSj+KPmeU5RVlA==,fs=testfs [email protected]:~# mount -t ceph node2:/ /mnt/cephfs -o name=admin,secret=AQAoJjBh7OPVNhAAQZyzLhDfgSj+KPmeU5RVlA==,fs=testfs [email protected]:~# df -h Filesystem Size Used Avail Use% Mounted on udev1.4G01.4G0% /dev tmpfs 293M1.2M 292M1% /run …. 192.168.106.101:/ 18G 1000M 17G6% /mnt/testfs 192.168.106.102:/ 18G 1000M 17G6% /mnt/cephfs[email protected]:~# cd /mnt/cephfs [email protected]:/mnt/cephfs# dd if=/dev/zero of=test bs=1M count=100 ##生成文件 这时候文件是直接写在ceph集群上看了， 可以通过dashboard观察👀。
⑦ ⑩ OpenStack高可用集群部署方案(train版)—OpenStack对接Ceph存储
参考Ceph官方安装文档
Openstack环境中，数据存储可分为临时性存储与永久性存储。
临时性存储：主要由本地文件系统提供，并主要用于nova虚拟机的本地系统与临时数据盘，以及存储glance上传的系统镜像；
永久性存储：主要由cinder提供的块存储与swift提供的对象存储构成，以cinder提供的块存储应用最为广泛，块存储通常以云盘的形式挂载到虚拟机中使用。
Openstack中需要进行数据存储的三大项目主要是nova项目（虚拟机镜像文件），glance项目（共用模版镜像）与cinder项目（块存储）。
下图为cinder，glance与nova访问ceph集群的逻辑图：
ceph与openstack集成主要用到ceph的rbd服务，ceph底层为rados存储集群，ceph通过librados库实现对底层rados的访问；
openstack各项目客户端调用librbd，再由librbd调用librados访问底层rados； 实际使用中，nova需要使用libvirtdriver驱动以通过libvirt与qemu调用librbd；cinder与glance可直接调用librbd；
写入ceph集群的数据被条带切分成多个object，object通过hash函数映射到pg（构成pg容器池pool），然后pg通过几圈crush算法近似均匀地映射到物理存储设备osd（osd是基于文件系统的物理存储设备，如xfs，ext4等）。
CEPH PG数量设置与详细介绍
在创建池之前要设置一下每个OSD的最大PG 数量
PG PGP官方计算公式计算器
参数解释：
依据参数使用公式计算新的 PG 的数目: PG 总数= ((OSD总数*100)/最大副本数)/池数 3×100/3/3=33.33 ;舍入到2的N次幕为32
openstack集群作为ceph的客户端；下面需要再openstack集群上进行ceph客户端的环境配置
在openstack所有控制和计算节点安装ceph Octopus源码包，centos8有默认安装，但是版本一定要跟连接的ceph版本一致
glance-api 服务运行在3个控制节点， 因此三台控制节点都必须安装
cinder-volume 与 nova-compute 服务运行在3个计算（存储）节点； 因此三台计算节点都必须安装
将配置文件和密钥复制到openstack集群各节点
配置文件就是生成的ceph.conf；而密钥是 ceph.client.admin.keyring ，当使用ceph客户端连接至ceph集群时需要使用的密默认密钥，这里我们所有节点都要复制，命令如下
※Glance 作为openstack中镜像服务，支持多种适配器，支持将镜像存放到本地文件系统，http服务器，ceph分布式文件系统，glusterfs和sleepdog等开源的分布式文件系统上。目前glance采用的是本地filesystem的方式存储，存放在默认的路径 /var/lib/glance/images 下，当把本地的文件系统修改为分布式的文件系统ceph之后，原本在系统中镜像将无法使用，所以建议当前的镜像删除，部署好ceph之后，再统一上传至ceph中存储。
※Nova 负责虚拟机的生命周期管理，包括创建，删除，重建，开机，关机，重启，快照等，作为openstack的核心，nova负责IaaS中计算重要的职责，其中nova的存储格外重要，默认情况下，nova将instance的数据存放在/var/lib/nova/instances/%UUID目录下，使用本地的存储空间。使用这种方式带来的好处是:简单，易实现，速度快，故障域在一个可控制的范围内。然而，缺点也非常明显：compute出故障，上面的虚拟机down机时间长，没法快速恢复，此外，一些特性如热迁移live-migration,虚拟机容灾nova evacuate等高级特性，将无法使用，对于后期的云平台建设，有明显的缺陷。对接 Ceph 主要是希望将实例的系统磁盘文件储存到 Ceph 集群中。与其说是对接 Nova，更准确来说是对接 QEMU-KVM/libvirt，因为 librbd 早已原生集成到其中。
※Cinder 为 OpenStack 提供卷服务，支持非常广泛的后端存储类型。对接 Ceph 后，Cinder 创建的 Volume 本质就是 Ceph RBD 的块设备，当 Volume 被虚拟机挂载后，Libvirt 会以 rbd 协议的方式使用这些 Disk 设备。除了 cinder-volume 之后，Cinder 的 Backup 服务也可以对接 Ceph，将备份的 Image 以对象或块设备的形式上传到 Ceph 集群。
使用ceph的rbd接口，需要通过libvirt，所以需要在客户端机器上安装libvirt和qemu，关于ceph和openstack结合的结构如下，同时，在openstack中，需要用到存储的地方有三个:
为 Glance、Nova、Cinder 创建专用的RBD Pools池
需要配置hosts解析文件，这里最开始已经配置完成，如未添加hosts解析需要进行配置
在cephnode01管理节点上操作 ；命名为：volumes，vms，images
记录：删除存储池的操作
在cephnode01管理节点上操作 ；
针对pool设置权限，pool名对应创建的pool
nova-compute与cinder-volume都部署在计算节点 ，不必重复操作,如果计算节点与存储节点分离需要分别推送；
全部计算节点配置；以compute01节点为例；
Glance 为 OpenStack 提供镜像及其元数据注册服务，Glance 支持对接多种后端存储。与 Ceph 完成对接后，Glance 上传的 Image 会作为块设备储存在 Ceph 集群中。新版本的 Glance 也开始支持 enabled_backends 了，可以同时对接多个存储提供商。
写时复制技术(-on-write) ：内核只为新生成的子进程创建虚拟空间结构，它们复制于父进程的虚拟空间结构，但是不为这些段分配物理内存，它们共享父进程的物理空间，当父子进程中有更改相应的段的行为发生时，再为子进程相应的段分配物理空间。写时复制技术大大降低了进程对资源的浪费。
全部控制节点进行配置；以controller01节点为例； 只修改涉及glance集成ceph的相关配置
变更配置文件，重启服务
ceph官网介绍 QEMU和块设备
对接 Ceph 之后，通常会以 RAW 格式创建 Glance Image，而不再使用 QCOW2 格式，否则创建虚拟机时需要进行镜像复制，没有利用 Ceph RBD COW 的优秀特性。
总结
将openstack集群中的glance镜像的数据存储到ceph中是一种非常好的解决方案，既能够保障镜像数据的安全性，同时glance和nova在同个存储池中，能够基于-on-write(写时复制)的方式快速创建虚拟机，能够在秒级为单位实现vm的创建。
全部计算节点进行配置； 以compute01节点为例；只修改glance集成ceph的相关配置
全部计算节点重启cinder-volume服务；
任意openstack控制节点上查看;
在任意控制节点为cinder的ceph后端存储创建对应的type，在配置多存储后端时可区分类型；
为ceph type设置扩展规格，键值 volume_backend_name ，value值 ceph
任意控制节点上创建一个1GB的卷 ；最后的数字1代表容量为1G
查看创建好的卷
openstack创建一个空白 Volume，Ceph相当于执行了以下指令
从镜像创建 Volume 的时候应用了 Ceph RBD COW Clone 功能，这是通过 glance-api.conf [DEFAULT] show_image_direct_url = True 来开启。这个配置项的作用是持久化 Image 的 location，此时 Glance RBD Driver 才可以通过 Image location 执行 Clone 操作。并且还会根据指定的 Volume Size 来调整 RBD Image 的 Size。
一直存在的cirros_qcow2镜像为对接ceph之前的镜像，现在已无法使用，所以将之删除
在openstack上从镜像创建一个Volume，Ceph相当于执行了以下指令
任意控制节点操作；
查看快照详细信息
在openstack上对镜像的卷创建快照，Ceph相当于执行了以下指令
如果说快照时一个时间机器，那么备份就是一个异地的时间机器，它具有容灾的含义。所以一般来说 Ceph Pool backup 应该与 Pool images、volumes 以及 vms 处于不同的灾备隔离域。
https://www.cnblogs.com/luohaixian/p/9344803.html
https://docs.openstack.org/zh_CN/user-guide/backup-db-incremental.html
一般的，备份具有以下类型：
在虚拟磁盘映像的计算节点上使用本地存储有一些缺点：
Nova 为 OpenStack 提供计算服务，对接 Ceph 主要是希望将实例的系统磁盘文件储存到 Ceph 集群中。与其说是对接 Nova，更准确来说是对接 QEMU-KVM/libvirt ，因为 librbd 早已原生集成到其中。
如果需要从ceph rbd中启动虚拟机，必须将ceph配置为nova的临时后端； 推荐在计算节点的配置文件中启用rbd cache功能； 为了便于故障排查，配置admin socket参数，这样每个使用ceph rbd的虚拟机都有1个socket将有利于虚拟机性能分析与故障解决； 相关配置只涉及全部计算节点ceph.conf文件的[client]与[client.cinder]字段，以compute163节点为例
全部计算节点配置 ceph.conf文件相关的 [client] 与 [client.cinder] 字段，以compute01节点为例；
在全部计算节点配置nova后端使用ceph集群的vms池，以compute01节点为例；
在全部计算节点操作;
在全部计算节点操作，以compute01节点为例； 以下给出libvirtd.conf文件的修改处所在的行num
未经允许不得转载：山九号 » ceph存储文件路径规范|如何配置ceph分布式存储方案
