1 为什么要使用ceph存储
- 什么是对象存储？
对象存储并没有向文件系统那样划分为元数据区域和数据区域，而是按照不同的对象进行存储，而且每个对象内部维护着元数据和数据区域。因此每个对象都有自己独立的管理格式。
- 对象存储优点：
基于对象的一个好处是对于同一个文件始终只存储一份，尽管有上千个用户上传了同一个文件，无论该文件名称是否一致，但只要内容是同一个文件，则始终会上传一个文件哟。这也是为什么我们在上传一个文件时能达到秒传的目的。如何校验不同文件名称其存储的数据相同呢？方法有很多种，比如Linux的"md5sum"命令。
2 ceph术语/组件/概述
2.1 ceph术语
1️⃣ceph集群也被称之为 RADOS ==(Reliable Automatic Distributed Object Store)==存储集群，即可靠的自动分布式对象存储
2️⃣OSD: 英文全称为Object Storage Daemon，即对象存储设备，通常指的是磁盘设备，它是真正负责存储数据的设备。
GPT回答：负责实际存储数据和管理数据的复制、恢复、重新平衡等操作
3️⃣mon: 全称为"monitor"，即监视器，也就是我们所说的集群元数据节点(而非文件元数据)。它是用来管理整个ceph集群的运行状态(比如集群有多少台服务器，每个服务器有多少OSD及其状态信息等等)。
它是为了能够让整个集群能够正常运行而设计的角色，因此为了避免该角色存在单点故障，因此会配置高可用集群，其底层基于POSIX协议实现。
通常我们需要关注以下几点:
- Ceph Monitor（进程名称为Ceph-mon）维护集群状态的映射，包括Monitor映射、manager映射、OSD映射，CRUSH映射和PG映射等;
- 这些映射是Ceph守护进程相互协调所需的关键集群状态，例如哪些OSD是正常工作的状态，哪些PG不可用等等;
- 监视器还负责管理守护程序和客户端之间的身份验证(基于Cephx协议实现);
- 为了实现冗余和高可用性，通常至少需要三个监视器，这不仅仅提供了高可用性，还提供了负载均衡的能力，因为通常Monitors还扮演着"身份验证"的角色，如果配置多个监视器可以很好的进行负载均衡。
4️⃣mgr: 全称为"manager"，即管理者。它的作用就是用来维护查询类的操作，它将很多查询操作按照自己的方式先缓存下来，一旦有人做监控，它能做及时的响应。有点类似于zabbix agent的功能。
早期ceph的版本是没有mgr组件的，但由于mon组件每次读取数据都是实时查询的，这种代价很高昂，而监控集群又是必须的，因此在ceph的L版本引入了mgr组件
通常我们需要关注以下几点：
- ceph管理器守护程序（进程名称为ceph-mgr）负责跟踪运行时度量和ceph集群的当前状态，包括存储利用率、当前性能度量和系统负载
- Ceph管理器守护进程还托管基于python的插件来管理和Rest API
- 高可用性通常至少需要两个管理器
5️⃣pool: 存储池，存储池的大小取决于底层的OSD的存储空间大小。一个ceph集群是可以由多个存储池构成的，而且每个存储池还可以被划分为多个不同的名称空间，而且每个名称空间可以划分成多个PG资源。
6️⃣PG: 全称为"placement groups"，即安置组(归置组)。注意，Pool和PG都是抽象的概念，即实际上并不存在，它是一个虚拟的概念。我们暂时可以理解他是用来存储数据的安置组即可
-
PG（Placement Group），负责将数据均匀分布在集群中的各个OSD（Object Storage Device）上。
-
PG是数据存储和访问的基本单位
-
当某个OSD发生故障时，可以通过PG中的副本在其他OSD上进行恢复，保证数据的可用性和可靠性
7️⃣MDS: (类似于HDFS的namenode，如果不用cephfs，该组件可以不安装)
全称为MetaData Server，即对应cephfs文件系统的元数据服务器。如果要用的话，建议安装多个节点，以免出现单点故障的情况。从严格意义上来讲，MDS只能算作构建于Rados存储集群之上的文件存取接口，它同RBD和RadowGW属于同一个级别，而非Ceph的基础组件。
但它却是ceph的第一个(最初也是除librados API之外的唯一一个)客户端数据存取组件
通常需要关心以下几点:
-
Ceph元数据服务器（MDS，进程名称为"ceph-mds"）代表Ceph文件系统存储元数据（即，Ceph块设备和Ceph对象存储不使用MDS）
-
Ceph元数据服务器允许POSIX文件系统用户执行基本命令（如ls、find等），而不会给Ceph存储集群带来巨大负担;
推荐阅读：http://docs.ceph.org.cn/glossary/#term-56http://docs.ceph.org.cn/architecture/#pg-idhttp://docs.ceph.org.cn/architecture/#pg-osd
提示：(1)如果我们给定的存储路径是一块裸的物理磁盘(我们称之为"裸设备"，也就是该设备没有被格式化指(2)通常情况下我们的ceph集群会有OSDs，Monitors，Managers和MDSs这几个基础组件，其中MDSs是可(3)RBD不需要通过运行守护进程来提供服务的，它基于librbd模块，它提供了相应的API来进行使用
2.2 ceph客户端介绍
RadosGw,RBD和CephFS都是RADOS存储服务的客户端，他们把RADOS的存储服务接口(librados)分别从不同的角度做了进一步抽象
RadosGw:
它是一个更抽象的能够跨互联网的云存储对象，它是基于RESTful风格提供的服务。每一个文件都是一个对象，而文件大小是各不相同的。
它和Ceph集群的内部的对象(object，它是固定大小的存储块，只能在Ceph集群内部使用，基于RPC协议工作的)并不相同。
值得注意的是，RadosGw依赖于librados，访问他可以基于http/https协议来进行访问。
RBD:
将ceph集群提供的存储空间模拟成一个又一个独立的块设备。每个块设备都相当于一个传统磁(硬)盘一样，可以对它做格式化，分区，挂载等处理
值得注意的是，RBD依赖于librados，访问需要Linux内核支持librdb相关模块
cephFS:
这是Ceph集群的文件系统，我们可以很轻松的像NFS那样使用，但它的性能瓶颈相比NFS来说是很难遇到的。
值得注意的是，CephFS并不依赖于librados，它和librados是两个不同的组件。但该组件使用的热度相比RadosGw和RBD要低。
查看ceph的官方文档：https://docs.ceph.com/en/latest/
官方架构图：https://docs.ceph.com/en/latest/architecture/
提示:
(1)CRUSH算法是Ceph内部数据对象存储路由的算法。它没有中心节点，即没有元数据中心服务器
(2)无论使用librados，RadosGw，RBD，CephFS哪个客户端来存储数据，最终的数据都会被写入到Rados Cluster
(3)值得注意的是这些客户端和Rados Cluster之间应该有多个存储池(pool)，每个客户端类型都有自己的存储池资源
2.3 cep集群的管理方式
Ceph的常用管理接口是一组命令行工具程序，例如rados，ceph，rbd等命令，管理员可以从某个特定的MON节点执行管理操作，但也有人更倾向于使用专用的管理节点。
事实上，专用的管理节点有助于在ceph相关的程序升级或硬件维护期间为管理员提供一个完整的，独立的并隔离于存储集群之外的操作系统，从而避免因重启或意外中断而导致维护操作异常中断。
3 ceph版本选择指南
3.1 ceph版本及生命周期
| Name | Initial release | Latest | End of life |
|---|---|---|---|
| Pacific | 2021-03-31 | 16.2.15 | 2024-03-04 |
| Octopus | 2020-03-23 | 15.2.17 | 2022-08-09 |
| Nautilus | 2019-03-19 | 14.2.22 | 2021-06-30 |
| Mimic | 2018-06-01 | 13.2.10 | 2020-07-22 |
| Luminous | 2017-08-01 | 12.2.13 | 2020-03-01 |
| Kraken | 2017-01-01 | 11.2.1 | 2017-08-01 |
| Jewel | 2016-04-01 | 10.2.11 | 2018-07-01 |
| Infernalis | 2015-11-01 | 9.2.1 | 2016-04-01 |
| Hammer | 2015-04-01 | 0.94.10 | 2017-08-01 |
| Giant | 2014-10-01 | 0.87.2 | 2015-04-01 |
| Firefly | 2014-05-01 | 0.80.11 | 2016-04-01 |
| Emperor | 2013-11-01 | 0.72.2 | 2014-05-01 |
| Dumpling | 2013-08-01 | 0.67.11 | 2015-05-01 |
| Date | Reef | Quincy |
|---|---|---|
| 2024-07-24 | 18.2.4 | – |
| 2024-03-11 | 18.2.2 | – |
| 2023-12-18 | 18.2.1 | – |
| 2023-10-30 | – | 17.2.7 |
| 2023-08-07 | 18.2.0 | – |
| 2023-04-10 | – | 17.2.6 |
| 2022-10-19 | – | 17.2.5 |
| 2022-09-30 | – | 17.2.4 |
| 2022-07-29 | – | 17.2.3 |
| 2022-07-21 | – | 17.2.2 |
| 2022-06-23 | – | 17.2.1 |
| 2022-04-19 | – | 17.2.0 |
ceph的版本版本选择及生命周期
ceph版本特性：
- 开发版本：x.0.z
- 候选版本：x.1.z
- 稳定版本：x.2.z。如此次使用的ceph18.2.4版本
3.2 ceph部署方式介绍
cephadm
-
使用容器和systemd安装和管理ceph集群并与cli和仪表盘GUI紧密集成
-
仅支持Octopus和更新版本，需要容器和Python3支持
-
与新的编排API完全集成; 需要提前安装docker和python环境，官方推荐方法
rook
- 在Kubernetes中运行的ceph集群，同时还支持通过Kubernete
- 仅支持Nautilus和较新版本的ceph; 需要准备一套k8s环境
ceph-ansible
- 使用ansible部署ceph集群，对于新的编排器功能，管理功能和仪表盘支持不好。 需要你熟练使用ansible功能
ceph-deploy
-
是一个快速部署集群的工具，不支持CentOS 8系统。对于
-
对于O版本也可以部署成功，但是dashboard功能并不友
-
官方已经弃用了，但对于学习来说是一个不错的工具
==提示：==使用Ubuntu基于ceph-deploy部署，建议选择python3.8以前的版本，推荐python 3.6最新版即可。因为python3.8移除了一部分函数库，而ceph-deploy用到了该函数库，否则就报错！
推荐阅读:
https://www.cnblogs.com/yinzhengjie/tag/Ceph/https://docs.ceph.com/en/latest/releases/general/
https://docs.ceph.com/en/latest/install/
https://docs.ceph.com/en/latest/releases/
4 ceph集群管理
01 环境准备
| 节点 | 额外硬盘 |
|---|---|
| ceph141 | sdb 300G，sdc 500G |
| ceph142 | sdb 300G，sdc 500G, sdd 1000G |
| ceph143 | sdb 300G，sdc 500G |
2.ceph所有节点基础环境准备
2.1.基于cephadm部署前提条件，官方提的要求Ubuntu 22.04 LTS出了容器运行时其他都满足- Python 3- Systemd- podman or Docker for running containers- Time synchronization (such as Chrony or the legacy ntpd)- LVM2 for provisioning storage devices参考链接:https://docs.ceph.com/en/latest/cephadm/install/#requirements2.2 设置时区
timedatectl set-timezone Asia/Shanghai
ll /etc/localtime 2.3.安装docker环境2.4 添加hosts文件解析
cat >> /etc/hosts <<EOF
10.0.0.141 ceph141
10.0.0.142 ceph142
10.0.0.143 ceph143
EOF2.5 集群时间同步【可跳过】
参考链接:https://www.cnblogs.com/yinzhengjie/p/14238720.html
02 ceph部署
1.下载需要安装ceph版本的cephadm，然后初始化集群
1.设置环境变量下载指定版本
[root@ceph141~]# CEPH_RELEASE=18.2.4
[root@ceph141~]# curl --silent --remote-name --location \
https://download.ceph.com/rpm-${CEPH_RELEASE}/el9/noarch/cephadm
[root@ceph141~]# ls
cephadm2.将cephadm添加到PATH环境变量
[root@ceph141 ~]# mv cephadm /usr/local/bin/
[root@ceph141 ~]# chmod +x /usr/local/bin/cephadm
[root@ceph141 ~]# ls -l /usr/local/bin/cephadm
-rwxr-xr-x 1 root root 215316 Aug 20 22:19 /usr/local/bin/cephadm3.创建新集群
cephadm bootstrap --mon-ip 10.0.0.141 --cluster-network 10.0.0.0/24 --allow-fqdn-hostname
# 此步骤会去官方下载镜像，可能存在镜像无法拉取问题。拉取时间比较长，1G多
Pulling container image quay.io/ceph/ceph:v18.2.4# 最后提示访问页面URL: https://ceph141:8443/User: adminPassword: xztz3sc8al
查看ceph相关的容器
[root@ceph141~]# docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS NAMES
dc05d1416659 quay.io/ceph/ceph-grafana:9.4.7 "/bin/sh -c 'grafana…" 4 minutes ago Up 4 minutes ceph-12fad866-9aa0-11ef-8656-6516a17ad6dd-grafana-ceph141
5ca5bb8f3cd2 quay.io/prometheus/alertmanager:v0.25.0 "/bin/alertmanager -…" 4 minutes ago Up 4 minutes ceph-12fad866-9aa0-11ef-8656-6516a17ad6dd-alertmanager-ceph141
001734df78dc quay.io/prometheus/prometheus:v2.43.0 "/bin/prometheus --c…" 4 minutes ago Up 4 minutes ceph-12fad866-9aa0-11ef-8656-6516a17ad6dd-prometheus-ceph141
3cc04e4f7af2 quay.io/prometheus/node-exporter:v1.5.0 "/bin/node_exporter …" 7 minutes ago Up 7 minutes ceph-12fad866-9aa0-11ef-8656-6516a17ad6dd-node-exporter-ceph141
7f6f02484d0b quay.io/ceph/ceph "/usr/bin/ceph-crash…" 7 minutes ago Up 7 minutes ceph-12fad866-9aa0-11ef-8656-6516a17ad6dd-crash-ceph141
8df49ff819eb quay.io/ceph/ceph "/usr/bin/ceph-expor…" 7 minutes ago Up 7 minutes ceph-12fad866-9aa0-11ef-8656-6516a17ad6dd-ceph-exporter-ceph141
e022ac1069a7 quay.io/ceph/ceph:v18 "/usr/bin/ceph-mgr -…" 8 minutes ago Up 8 minutes ceph-12fad866-9aa0-11ef-8656-6516a17ad6dd-mgr-ceph141-yvswvf
8cc214cdb16b quay.io/ceph/ceph:v18 "/usr/bin/ceph-mon -…" 8 minutes ago Up 8 minutes ceph-12fad866-9aa0-11ef-8656-6516a17ad6dd-mon-ceph141
5191940317f4 quay.io/ceph/ceph:v18 "ceph --version" 8 minutes ago Created admiring_clarke
监听8443端口的进程是mgr
![[C++]内联函数和nullptr](https://i-blog.csdnimg.cn/direct/c87b8e99fba64691b4ae542a6062481f.png)
