ceph介绍和搭建
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-56
http://docs.ceph.org.cn/architecture/#pg-id
http://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/#requirements
2.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
EOF
2.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
cephadm
2.将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/cephadm
3.创建新集群
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: admin
Password: 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