K8S0704

最新推荐文章于 2023-09-11 20:18:33 发布

龙卷风飞

最新推荐文章于 2023-09-11 20:18:33 发布

阅读量2.2k

点赞数 1

文章标签：大数据

本文链接：https://blog.csdn.net/weixin_47876662/article/details/125610132

版权

分布式存储概述

单机存储：SCSI/IDE/SATA//SAS/USB/PCI-E/SSD/M.2 NVME协议(提升性能)

网络存储：NFS/NAS(网络附属存储)/Samba/SAN(存储区域网络)

分布式存储: Ceph,TFS,FastDFS,MogileFS,MooseFS,GlusterFS

不同存储类型适用场景

块存储：
块存储在使用的时候需要格式化为指定的文件系统,然后挂载使用，其对操作系统的兼容性相对比较好(可以格式化为操作系统支持的文件系统)，排载的时候通常是每个服务单独分配独立的块存储，即各服务的块存储是独立且不共享使用的，如 Redis 的 master和 slave 的块存储是独立的、zookeeper各节点的快存储是独立的、MySQL 的master和 slave的块存储是独立的、也可以用于私有云与公有云的虚拟机的系统盘和云盘等场景，此类场景适合使用块存储.

cephFS：
对于需要在多个主机实现数据共享的场景，比如多个nginx读取由多个tomcat写入到存储的数据，可以使用ceph FS.

对象存储：
而对于数据不会经常变化、删除和修改的场景，如短视频、APP下载等，可以使用对象存储.

分布式存储数据特性

数据分为数据和元数据

元数据即是文件的属性信息(文件名、权限(属主、属组)、大小、时间戳等)，在分布式存储(cephfs文件存储)中当客户端或者应用程序产生的客户端数据被写入到分布式存储系统的时候，会有一个服务(Name Node)提供文件元数据的路由功能，即告诉应用程序去哪个服务器去请求文件内容，然后再有(Data Node)提供数据的读写请求及数据的高可用功能.

块存储:需要格式化，将文件直接保存到磁盘上.

文件存储:提供数据存储的接口，是由操作系统针对块存储的应用，即由操作系统提供存储接口，应用程序通过调用操作系统将文件保存到块存储进行持久化.

对象存储:也称为基于对象的存储,其中的文件被拆分成多个部分并散布在多个存储服务器，在对象存储中，数据会被分解为称为“对象”的离散单元，并保存在单个存储库中，而不是作为文件夹中的文件或服务器上的块来保存，对象存储需要一个简单的HTTP应用编程接(API)，以供大多数客户端(各种语言)使用.

Ceph基础

Ceph 是一个开源的分布式存储系统，同时支持对象存储、块设备、文件系统.

ceph支持 EB(1EB=1,000,000,00OGB)级别的数据存储,ceph把每一个待管理的数据流(文件等数据)切分为一到多个固定大小(默认4兆)的对象数据（默认三副本，一般在不同主机），并以其为原子单元(原子是构成元素的最小单元)完成数据的读写。

ceph 的底层存储服务是由多个存储主机(host)组成的存储集群，该集群也被称之为RADOS(reliable automatic distributed object store)存储集群，即可靠的、自动化的、分布式的对象存储系统.

librados是 RADOS存储集群的API，支持C/C++/JAVA/python/ruby/php/go等编程语言客户端.

ceph集群组成

若干的Ceph OSD(对象存储守护程序)

RADOS cluster:由多台host存储服务器组成的ceph集群

至少需要一个Ceph Monitors 监视器（1,3,5,7...)

两个或以上的Ceph 管理器managers，运行Ceph 文件系统客户端时还需要高可用的Ceph Metadata Server(文件系统元数据服务器).

OSD(Object Storage Daemon):每台存储服务器的磁盘组成的存储空间

Mon(Monitor): ceph的监视器,维护OSD和PG的集群状态，一个ceph集群至少要有一个mon，可以是一三五七等等这样的奇数个.

Mgr(Manager):负责跟踪运行时指标和Ceph集群的当前状态，包括存储利用率，当前性能指标和系统负载等.

1、Monitor(ceph-mon) ceph 监视器:

在一个主机上运行的一个守护进程，用于维护集群状态映射(maintains maps of thecluster state)，比如 ceph集群中有多少存储池、每个存储池有多少PG以及存储池和PG的映射关系等,monitor map,manager map, the OSD map, the MDS map,and theCRUSH map，这些映射是Ceph守护程序相互协调所需的关键群集状态，此外监视器还负责管理守护程序和客户端之间的身份验证(认证使用cephX协议).通常至少需要三个监视器才能实现冗余和高可用性.

注：不负责读写数据

2、Managers(ceph-mgr)

在一个主机上运行的一个守护进程,Ceph Manager守护程序(ceph-mgr)负责跟踪运行时指标和Ceph集群的当前状态，包括存储利用率，当前性能指标和系统负载．CephManager守护程序还托管基于python的模块来管理和公开Ceph集群信息,包括基于Web的Ceph仪表板和REST API.高可用性通常至少需要两个管理器.

Ceph OSDs(对象存储守护程序ceph-osd)

提供存储数据，操作系统上的一个磁盘就是一个OSD守护程序，OSD用于处理ceph集群数据复制，恢复，重新平衡，并通过检查其他Ceph OSD守护程序的心跳来向Ceph监视器和管理器提供一些监视信息．通常至少需要3个Ceph OSD才能实现冗余和高可用性。（每个osd除了向mon汇报自己状态还会汇报集群上其他osd状态）

MDS(ceph元数据服务器ceph-mds)

代表ceph文件系统(NFS/CIFS)存储元数据,(即 Ceph块设备和Ceph对象存储不使用MDS)

Ceph的管理节点

1.ceph 的常用管理接口是一组命令行工具程序，例如 rados、ceph、rbd等命令,ceph管理员可以从某个特定的ceph-mon节点执行管理操作

⒉推荐使用部署专用的管理节点对ceph进行配置管理、升级与后期维护，方便后期权限管理，管理节点的权限只对管理人员开放,可以避免一些不必要的误操作的发生.

ceph逻辑组织架构

Pool:存储池、分区，存储池的大小取决于底层的存储空间.

PG(placement group):一个pool内部可以有多个PG存在,pool和PG都是抽象的逻辑概念，一个pool中有多少个PG可以通过公式计算.

osD(Object Storage Daemon,对象存储设备):每一块磁盘都是一个osd，一个主机由一个或多个osd组成.

ceph集群部署好之后,要先创建存储池才能向ceph写入数据，文件在向ceph 保存之前要先进行一致性hash计算，计算后会把文件保存在某个对应的PG的，此文件一定属于某个pool 的一个PG，在通过PG保存在OSD上.

数据对象在写到主OSD之后再同步对从OSD以实现数据的高可用.

存储过程

主副本挂掉后会选举最新的副本并对另一个副本进行差异同步。备副本挂掉后添加新副本从主副本进行全量同步

计算文件到对象的映射

计算文件到对象的映射,假如 file为客户端要读写的文件,得到oid(object id)= ino + onoino:inode number (INO)，File 的元数据序列号, File的唯一id.

ono:object number(ONO),File切分产生的某个object的序号，默认以4M切分一个块大小.大于4m产生两个ONO

通过hash算法计算出文件对应的pool 中的PG

通过一致性 HASH计算Object 到PG, Object -> PG 映射hash(oid)& mask-> pgid

通过CRUSH把对象映射到PG中的OSD

通过CRUSH算法计算PG到OSD,PG ->OSD 映射:[CRUSH(pgid)->(osd1,osd2,osd3)

在线进制转换:https://tool.oschina.net/hexconvert

64-1=63(0~63=累计64个)，
1100100=100(对象的 hash值)100&64=36,200&64=8
0111111=63(PG总数)
0100100=36(与运算结果)

PG中的主OSD将对象写入到硬盘

主OSD将数据同步给备份OSD,并等待备份OSD返回确认

主OSD将写入完成返回给客户端

Ceph CRUSH算法简介

Controllers replication under scalable hashing #可控的、可复制的、可伸缩的一致性 hash算法.

Ceph使用CURSH算法来存放和管理数据，它是Ceph的智能数据分发机制.Ceph使用CRUSH算法来准确计算数据应该被保存到哪里,以及应该从哪里读取,和保存元数据不同的是, CRUSH按需计算出元数据，因此它就消除了对中心式的服务器/网关的需求,它使得Ceph客户端能够计算出元数据，该过程也称为CRUSH 查找，然后和OSD直接通信．

1.如果是把对象直接映射到OSD之上会导致对象与OSD的对应关系过于紧密和耦合，当oSD由于故障发生变更时将会对整个ceph集群产生影响.

2.于是ceph将一个对象映射到RADOS集群的时候分为两步走:首先使用一致性hash算法将对象名称映射到PG 2.7然后将PG ID基于CRUSH 算法映射到OSD即可查到对象

3.以上两个过程都是以"实时计算”的方式完成，而没有使用传统的查询数据与块设备的对应表的方式，这样有效避免了组件的”中心化"问题,也解决了查询性能和冗余问题.使得ceph集群扩展不再受查询的性能限制.

4.这个实时计算操作使用的就是CRUSH算法
Controllers replication under scalable hashing #可控的、可复制的、可伸缩的一致性 hash算法.
CRUSH是一种分布式算法，类似于一致性 hash算法，用于为 RADOS存储集群控制数据的分配.

ceph元数据保存方式

ceph可选后端支持多种存储引擎，比如 filestore,bluestore,kvstore，memstore，ceph使用bluestore存储对象数据的元数据信息.

xattrs(扩展属性)

是将元数据保存在对象对应文件的扩展属性中并保存到系统磁盘上,这要求支持对象存储的本地文件系统（一般是XFS)支持扩展属性.

omap(object map 对象映射）

omap:是 object map 的简称，是将元数据保存在本地文件系统之外的独立 key-value 存储系统中，在使用filestore 时是 leveldb，在使用bluestore 时是 rocksdb，由于filestore存在功能问题(需要将磁盘格式化为XFS格式)及元数据高可用问题等问题,因此在目前ceph主要使用bluestore.

filestore与leveldb

ceph早期基于filestore使用 google的 levelDB保存对象的元数据, LevelDb是一个持久化存储的KV系统，和Redis这种内存型的KV系统不同,leveldb不会像 Redis一样将数据放在内存从而占用大量的内存空间，而是将大部分数据存储到磁盘上，但是需要把磁盘上的leveldb空间格式化为文件系统(XFS).

FileStore将数据保存到与Posix兼容的文件系统(例如Btrfs、XFS、Ext4).在Ceph后端使用传统的Linux文件系统尽管提供了一些好处，但也有代价，如性能、对象属性与磁盘本地文件系统属性匹配存在限制等．

bluestore 与rocksdb

由于levelDB依然需要需要磁盘文件系统的支持，后期facebok对 levelDB进行改进为RocksDB https:/lgithub.com/facebook/rocksdb， RocksDB将对象数据的元数据保存在RocksDB，但是 RocksDB的数据又放在哪里呢?放在内存怕丢失，放在本地磁盘但是解决不了高可用, ceph对象数据放在了每个OSD中，那么就在在当前OSD中划分出一部分空间，格式化为BlueFS文件系统用于保存 RocksDB中的元数据信息(称为BlueStore)，并实现元数据的高可用，BlueStore最大的特点是构建在裸磁盘设备之上，并且对诸如 SSD等新的存储设各做了很多优化工作

对全SSD及全NVMe SSD闪存适配
绕过本地文件系统层，直接管理裸设备,缩短IO路径
严格分离元数据和数据，提高索引效率
使用KV索引，解决文件系统目录结构遍历效率低的问题
支持多种设备类型
解决日志“双写”问题
期望带来至少2倍的写性能提升和同等读性能增加数据校验及数据压缩等功能

RocksDB通过中间层BlueRocksDB访问文件系统的接口．这个文件系统与传统的Linux文件系统（例如Ext4和XFS)是不同的，它不是在VFS下面的通用文件系统,而是一个用户态的逻辑.BlueFS通过函数接口(API，非 POSIX)的方式为BlueRocksDB提供类似文件系统的能力

RocksDB通过中间层 BlueRocksDB访问文件系统的接口．这个文件系统与传统的Linux文件系统（例如Ext4和XFS)是不同的,它不是在VFS下面的通用文件系统，而是一个用户态的逻辑．BlueFS通过函数接口（API,非 POSIX)的方式为BlueRocksDB提供类似文件系统的能力

Allocator:负责裸设备的空间管理分配.

BlueRocksEnv:这是RocksDB与 BlueFS交互的接口;RocksDB提供了文件操作的接口EnvWrapper(Env封装器)，可以通过继承实现该接口来自定义底层的读写操作，BlueRocksEnv就是继承自EnvWrapper实现对 BlueFS的读写.

BlueRocksEnv:这是RocksDB与 BlueFS交互的接口;RocksDB提供了文件操作的接口EnvWrapper(Env封装器)，可以通过继承实现该接口来自定义底层的读写操作，BlueRocksEnv就是继承自EnvWrapper实现对 BlueFS的读写.

BlueFS: BlueFS 是BlueStore针对RocksDB开发的轻量级文件系统，用于存放RocksDB产生的.sst 和.log等文件.

BlockDecive: BlueStore抛弃了传统的ext4、xfs文件系统，使用直接管理裸盘的方式;

BlueStore支持同时使用多种不同类型的设备,在逻辑上BlueStore将存储空间划分为三层:慢速(Slow)空间、高速(DB）空间、超高速(WAL)空间，不同的空间可以指定使用不同的设备类型，当然也可使用同一块设备.

Ceph集群部署

OSD 节点CPU:

每个OSD进程至少有一个CPU核心或以上，比如服务器一共2颗CPU每个12核心24线程，那么服务器总计有48核心CPU，这样最多最多最多可以放48块磁盘．(物理CPU数量*每颗CPU核心)/OSD磁盘数量=X/每OSD CPU核心>=1核心CPU比如:(2颗*每颗24核心)/24 OSD磁盘数量=2/每OSD CPU核心>=1核心CPU

OSD 节点内存:

OSD硬盘空间在2T或以内的时候每个硬盘2G内存，4T的空间每个OSD磁盘4G内存,即大约每1T的磁盘空间(最少)分配1G的内存空间做数据读写缓存.(总内存/OSD磁盘总空间)=X>1G内存

比如:(总内存128G/36T磁盘总空间)=3G/每T>1G内存

1、前期准备工作

centos 关闭SELinux和关闭firewalld，并禁止开机自启

时间同步

timedatectl set-timezone Asia/Shanghai
*/5 * * * * /usr/sbin/ntpdatetime1.aliyun.com&> /dev/null &&hwclock-w &> /dev/null

修改主机名

hostnamectl set-hostname ceph-node1
hostnamectl set-hostname ceph-node2
hostnamectl set-hostname ceph-deploy
hostnamectl set-hostname ceph-mon

192.168.226.170 ceph-node1
192.168.226.171 ceph-node2
192.168.226.173 ceph-deploy
192.168.226.172 ceph-mon

免密登录

在管理节点上，做各节点的免密登陆。

ssh-keygen
ssh-copy-id 192.168.226.173

仓库准备

各节点配置ceph yum源仓库

sudo apt-get install gnupg
wget -q -O- 'https://mirrors.tuna.tsinghua.edu.cn/ceph/keys/release.asc' | sudo apt-key add - #导入key文件

# sudo echo "deb https://mirrors.tuna.tsinghua.edu.cn/ceph/debian-pacific bionic main">>/etc/apt/sources.list
sudo apt-get update && apt-get upgrade
apt-get -y install apt-transport-https ca-certificates curl software-properties-common

apt install python2.7 -y
ln -sv /usr/bin/python2.7 /usr/bin/python2

创建普通用户

推荐使用指定的普通用户部署和运行ceph集群,普通用户只要能以非交互方式执行sudo命令执行一些特权命令即可，新版的ceph-deploy可以指定包含root 的在内只要可以执行sudo命令的用户，不过仍然推荐使用普通用户，比如ceph、cephuser、cephadmin这样的用户去管理ceph集群.

groupadd -r -g 2022 cephadmin && useradd -r -m -s /bin/bash -u 2022 -g 2022 cephadmin && echo cephadmin:123456 | chpasswd

echo "cephadmin ALL=(ALL) NOPASSWD:ALL" >>/etc/sudoers

2、部署ceph集群

安装ceph部署工具

apt-cache madison ceph-deploy
sudo apt install ceph-deploy=2.0.1

初始化mon节点

cephadmin@ceph-deploy:~$ mkdir ceph-cluster    #保存ceph集群配置信息
cephadmin@ceph-deploy:~$ cd ceph-cluster/
cephadmin@ceph-deploy:~/ceph-cluster$

new	开始部署一个新的ceph存储集群，并生成CLUSTERconf集群配置文件和 keyring认证文件
install	在远程主机上安装ceph相关的软件包，可以通过--release 指定安装的版本
rgw	管理RGW守护程序(RADOSGW,对象存储网关)
mgr	管理MGR守护程序(ceph-mgr,Ceph Manager DaemonCeph管理器守护程序)
mds	管理MDS守护程序(Ceph Metadata Server，ceph源数据服务器)
mon	管理 MON守护程序(ceph-mon,ceph监视器)
gatherkeys	从指定获取提供新节点的验证keys，这些 keys 会在添加新的MON/OSD/MD加入时使用
disk	管理远程主机磁盘
osd	在远程主机准备数据磁盘，即将指定远程主机的指定磁盘添加到ceph集群作为osd使用
repo	远程主机仓库管理
admin	推送ceph集群配置文件和 clientadmin认证文件到远程主机
config	将cephconf配置文件推送到远程主机或从远程主机拷贝
uninstall	从远端主机删除安装包
purgedata	从/var/lib/ceph 删除ceph 数据,会删除/etc/ceph 下的内容
purge	删除远端主机的安装包和所有数据
forgetkeys	从本地主机删除所有的验证 keyring，包括clientadmin, monitor, bootstrap等认证文件
pkg	 管理远端主机的安装包
calamari	安装并配置一个calamari web 节点, calamari是一个web监控平台

cephadmin@ceph-deploy:~/ceph-cluster$ ceph-deploy new --cluster-network 192.168.199.0/21 --public-network 192.168.226.0/21 ceph-mon.local

cephadmin@ceph-deploy:~/ceph-cluster$ ll
total 20
drwxrwxr-x 2 cephadmin cephadmin 4096 Jul  9 15:07 ./
drwxr-xr-x 6 cephadmin cephadmin 4096 Jul  9 14:46 ../
-rw-rw-r-- 1 cephadmin cephadmin  270 Jul  9 15:07 ceph.conf    #自动生成的配置文件
-rw-rw-r-- 1 cephadmin cephadmin 4006 Jul  9 15:07 ceph-deploy-ceph.log    #初始化日志
-rw------- 1 cephadmin cephadmin   73 Jul  9 15:07 ceph.mon.keyring    ##用于ceph mon节点内部通讯认证的秘钥环文件
cephadmin@ceph-deploy:~/ceph-cluster$ cat ceph.conf 
[global]
fsid = e6a4204e-1730-4a52-b256-c31488516f83    #ceph集群id
public_network = 192.168.226.0/21
cluster_network = 192.168.199.0/21
mon_initial_members = ceph-mon
mon_host = 192.168.226.172
auth_cluster_required = cephx
auth_service_required = cephx
auth_client_required = cephx

初始化存储节点

注意：初始化存储节点等于在存储节点安装了ceph 及 ceph-rodsgw安装包，但是使用默认的官方仓库会因为网络原因导致初始化超时，因此各存储节点推荐修改ceph 仓库为阿里或者清华等国内的镜像源。在添加OSD时初始化也可以

cephadmin@ceph-deploy:~/ceph-cluster$ ceph-deploy install --no-adjust-repos --nogpgcheck ceph-node1 ceph-node2

--no-adjust-repos #不修改已有的 apt仓库源(默认会使用官方仓库)
--nogpgcheck#不进行校验

The repository 'cdrom://Ubuntu-Server 18.04.5 LTS _Bionic Beaver_ - Release amd64 (20200810) bionic Release' does not have a Release file

如果遇到这个报错

root@ceph-mon:~# vim /etc/apt/sources.list
#deb cdrom:[Ubuntu-Server 18.04.5 LTS _Bionic#注释掉这一行

root@ceph-mon:~# sudo apt-get update

配置mon节点

root@ceph-mon:~# apt-cache madison ceph-mon
  ceph-mon | 16.2.9-1bionic | https://mirrors.tuna.tsinghua.edu.cn/ceph/debian-pacific bionic/main amd64 Packages
  ceph-mon | 12.2.13-0ubuntu0.18.04.10 | http://us.archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages
  ceph-mon | 12.2.13-0ubuntu0.18.04.10 | http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages
  ceph-mon | 12.2.4-0ubuntu1 | http://us.archive.ubuntu.com/ubuntu bionic/main amd64 Packages
root@ceph-mon:~# apt install ceph-mon=16.2.9-1bionic

手动安装比通过deploy快些

ceph-deploy mon create-initial    #初始化mon节点，将mon加入ceph集群

分发admin认证密钥

在ceph-deploy节点把配置文件和admin密钥拷贝至Ceph集群需要执行ceph管理命令的节点，从而不需要后期通过ceph命令对ceph集群进行管理配置的时候每次都需要指定ceph-mon节点地址和 ceph.client.admin.keyring文件,另外各ceph-mon节点也需要同步ceph 的集群配置文件与认证文件.

sudo apt install ceph-common    #管理ceph集群的公共组件，node节点初始化已安装

ceph-deploy admin ceph-deploy ceph-node1 ceph-node2

apt install acl
setfacl -m u:cephadmin:rw /etc/ceph/ceph.client.admin.keyring    #因为密钥是root用户，需要授权

部署ceph-mgr

apt install ceph-mgr
mgr节点需要读取ceph 的配置文件，即/etc/ceph目录中的配置文件
ceph-deploy mgr create ceph-mon

初始化存储节点

ceph-deploy disk zap ceph-node1 /dev/sdb #列出所有的盘

ceph-deploy disk zap ceph-node2 /dev/sdb1    #擦除磁盘

添加OSD

存储数据分为Data（ceph保存的对象数据）、Block（rock DB数据即元数据）、block-wal（数据库的wal日志）

可以选将三种数据分别放在指定盘，不写就默认放在一块

ceph-deploy osd create ceph-node1 --data /dev/sdc1

移除OSD

ceph osd tree
1．停用设备:ceph osd out {osd.3}
2.停止进程:sudo systemctl stop ceph-osd@{osd.3}
3.移除设备:ceph osd purge {3} --yes-i-really-mean-it

3、测试上传下载数据

创建pool

cephadmin@ceph-deploy:~/ceph-cluster$ ceph osd pool ls
device_health_metrics
cephadmin@ceph-deploy:~/ceph-cluster$ ceph osd pool create mypool 32 32
pool 'mypool' created
cephadmin@ceph-deploy:~/ceph-cluster$ ceph osd pool ls
device_health_metrics
mypool

 ceph pg ls-by-pool mypool

上传和下载

cephadmin@ceph-deploy:~/ceph-cluster$ sudo rados put msg1 /var/log/syslog --pool=mypool
cephadmin@ceph-deploy:~/ceph-cluster$ rados ls --pool=mypool
msg1
cephadmin@ceph-deploy:~/ceph-cluster$ ceph osd map mypool msg1
osdmap e45 pool 'mypool' (2) object 'msg1' -> pg 2.c833d430 (2.10) -> up ([3,0,1], p3) acting ([3,0,1], p3)
cephadmin@ceph-deploy:~/ceph-cluster$ ls -l /var/log/syslog -h
-rw-r----- 1 syslog adm 1.8M Jul  9 16:50 /var/log/syslog
cephadmin@ceph-deploy:~/ceph-cluster$ sudo rados get msg1 --pool=mypool /tmp/my.txt
cephadmin@ceph-deploy:~/ceph-cluster$ ll /tmp/my.txt
-rw-r--r-- 1 root root 1811506 Jul  9 16:55 /tmp/my.txt
sudo rados rm msg1 --pool=mypool


表示文件放在了存储池id为2的c833d430 的PG上,10为当前PG的id,2.10表示数据是在id为2的存储池当中id为10的PG中存储,在线的OSD编号3,0,1，主OSD为3,活动的OSD 3,0,1,三个OSD表示数据放一共3个副本,PG中的OSD是ceph的crush算法计算出三份数据保存在哪些OSD.

扩展ceph集群实现高可用

扩展mon节点

apt install ceph-common ceph-mon
ceph-deploy mon add ceph-mon2

ceph quorum_status
ceph quorum_status --format json-pretty #验证mon状态

扩展mgr节点

apt install ceph-mgr
ceph-deploy mgr create ceph-mgr2
ceph-deploy admin ceph-mgr2    #修改/etc/ceph/下的权限
ceph -s

ceph集群应用基础

块设备

RBD(RADOS Block Devices)即为块存储的一种, RBD通过librbd库与OSD进行交互, RBD为KVM等虚拟化技术和云服务(如OpenStack和 CloudStack)提供高性能和无限可扩展性的存储后端，这些系统依赖于libvirt和QEMU实用程序与RBD进行集成，客户端基于librbd库即可将RADOS存储集群用作块设备，不过，用于rbd的存储池需要事先启用rbd功能并进行初始化.例如，下面的命令创建一个名为myrbd1的存储池，并在启用rbd 功能后对其进行初始化。

创建rbd

cephadmin@ceph-deploy:~/ceph-cluster$ ceph osd pool create myrbd1 64 64
pool 'myrbd1' created
cephadmin@ceph-deploy:~/ceph-cluster$ ceph osd pool application enable myrbd1 rbd #开启rbd
enabled application 'rbd' on pool 'myrbd1'
cephadmin@ceph-deploy:~/ceph-cluster$ rbd pool init -p myrbd1    #初始化
cephadmin@ceph-deploy:~/ceph-cluster$

验证

不过,rbd存储池并不能直接用于块设备，而是需要事先在其中按需创建映像(image) ,并把映像文件作为块设备使用，rbd命令可用于创建、查看及删除块设备相在的映像(image)，以及克隆映像、创建快照、将映像回滚到快照和查看快照等管理操作

rbd create myimg1 --size 1G --pool myrbd1
cephadmin@ceph-deploy:~/ceph-cluster$ rbd create myimg2 --size 1G --pool myrbd1 --image-format 2 --image-feature layering

客户端使用块存储

root@ceph-node1:~# rbd -p myrbd1 map myimg2    #客户端映射img
/dev/rbd0

先安装ceph-common

挂盘前需要进行分区以及格式化

dd if=/dev/zero of=/root/test-rbd-img/ceph-test-file bs=1MB count=10
写入文件验证

删除数据

rm -rf ceph-test-file

删除完成的数据只是标记为已经被删除，但是不会从块存储立即清空,因此在删除完成后使用ceph df查看并没有回收空间

如果需要立即在系统层回收空间,需要执行以下命令:

root@ceph-node1:~/test-rbd-img# fstrim -v /root/test-rbd-img 
/root/test-rbd-img: 973.4 MiB (1020678144 bytes) trimmed
其功能是回收文件系统中未使用的块资源

或者
mount -t xfs -o discard /dev/rbd0  /root/test-rbd-img    #闲置块回收

ceph radosgw(RGW)对象存储

RGW提供的是REST接口，客户端通过http 与其进行交互，完成数据的增删改查等管理操作.

radosgw用在需要使用RESTfulAPI接口访问ceph数据的场合，因此在使用RBD即块存储得场合或者使用cephFS的场合可以不用启用radosgw功能.

部署rgw

apt install radosgw
ceph-deploy --overwrite-conf rgw create ceph-mon

验证

Ceph-FS文件存储

Ceph FS 即 ceph filesystem，可以实现文件系统共享功能,客户端通过ceph 协议挂载并使用ceph集群作为数据存储服务器.

Ceph FS需要运行Meta Data Services(MDS)服务，其守护进程为ceph-mds，ceph-mds进程管理与cephFS上存储的文件相关的元数据，并协调对ceph存储集群的访问.

部署mds服务

root@ceph-mon:~# apt-cache madison ceph-mds
  ceph-mds | 16.2.9-1bionic | https://mirrors.tuna.tsinghua.edu.cn/ceph/debian-pacific bionic/main amd64 Packages
  ceph-mds | 12.2.13-0ubuntu0.18.04.10 | http://us.archive.ubuntu.com/ubuntu bionic-updates/universe amd64 Packages
  ceph-mds | 12.2.13-0ubuntu0.18.04.10 | http://security.ubuntu.com/ubuntu bionic-security/universe amd64 Packages
  ceph-mds | 12.2.4-0ubuntu1 | http://us.archive.ubuntu.com/ubuntu bionic/universe amd64 Packages
You have new mail in /var/mail/root
root@ceph-mon:~# apt install ceph-mds=16.2.9-1bionic

ceph-deploy mds create ceph-mon

cephadmin@ceph-deploy:~/ceph-cluster$ ceph mds stat
 1 up:standby
当前为备用状态，需要分配pool

创建存储池

使用CephFS之前需要事先于集群中创建一个文件系统，并为其分别指定元数据和数据相关的存储池，如下命令将创建名为mycephfs 的文件系统，它使用cephfs-metadata作为元数据存储池，使用cephfs-data为数据存储池

cephadmin@ceph-deploy:~/ceph-cluster$ ceph osd pool create cephfs-metadata 32 32
pool 'cephfs-metadata' created    #保存metadata
cephadmin@ceph-deploy:~/ceph-cluster$ ceph osd pool create cephfs-data 64 64
pool 'cephfs-data' created    #保存数据

创建cepffs并验证

cephadmin@ceph-deploy:~/ceph-cluster$ ceph fs new mycepffs cephfs-metadata cephfs-data
new fs with metadata pool 8 and data pool 9
cephadmin@ceph-deploy:~/ceph-cluster$ ceph fs ls
name: mycepffs, metadata pool: cephfs-metadata, data pools: [cephfs-data ]

客户端挂载

root@ceph-node1:~/test-rbd-img# mount -t ceph 192.168.226.172:6789:/ /mnt -o name=admin,secret=AQBhL8liv4LjExAAkqJMg/rnjLe9zF54SJ0E/w==
需要指定mon节点的6789端口

ceph停止和关闭

重启之前，要提前设置ceph 集群不要将OSD标记为 out，避免node节点关闭服务后被踢出ceph集群外:

ceph osd set noout #关闭服务前设置noout

ceph osd unset noout #启动服务后取消noout

关闭顺序

#关闭服务前设置noout
关闭存储客户端停止读写数据如果使用了RGW，
关闭RGw关闭cephfs元数据服务
关闭ceph OSD
关闭ceph manager
关闭ceph monitor

启动顺序

启动ceph monitor
启动ceph manager
启动ceph OSD
关闭cephfs元数据服务
启动RGW
启动存储客户端
#启动服务后取消noout-->ceph osd unset noout

添加和删除服务器

1.先添加仓库源
2.ceph-deploy install --release pacific ceph-nodex
3.擦除磁盘    ceph-deploy disk zap ceph-nodex /dev/sdx    
4.添加osd:sudo ceph-deploy osd create ceph-nodex --data /dev/sdx

停止服务器之前要把服务器的OSD先停止并从ceph 集群删除
1、把 osd 踢出集群ceph osd out 1
2、等一段时间
3、停止osd.x进程
4、删除 osd    ceph osd rm 1
5、当前主机的其它磁盘重复以上操作
6、OSD全部操作完成后下线主机

ceph配置文件

Ceph的主配置文件是/etc/ceph/ceph.conf，ceph服务在启动时会检查cep.conf，分号;和#在配置文件中都是注释, ceph.conf主要由以下配置段组成:

[global]    #全局配置

[osd]    #osd专用配置，可以使用osd.N，来表示某一个OSD专用配置,N为osd 的编号,如0、2、1等.

[mon]    #mon专用配置，也可以使用mon.A来为某一个monitor节点做专用配置，其中A为该节点的名称,ceph-monitor-2、ceph-monitor-1等，使用命令ceph mon dump可以获取节点的名称

[client]    #客户端专用配置.

存储池、PG 与CRUSH

副本池:replicated，定义每个对象在集群中保存为多少个副本,默认为三个副本，一主两备，实现高可用，副本池是ceph 默认的存储池类型.

纠删码池(erasure code):把各对象存储为N=K+M个块，其中K为数据块数量，M为编码快数量，因此存储池的尺寸为K+M.

即数据保存在K个数据块，并提供M个冗余块提供数据高可用，那么最多能故障的块就是M个，实际的磁盘占用就是K+M块，因此相比副本池机制比较节省存储资源，一般采用8+4机制，即8个数据块+4个冗余块，那么也就是12个数据块有8个数据块保存数据，有4个实现数据冗余,即1/3的磁盘空间用于数据冗余,比默认副本池的三倍冗余节省空间，但是不能出现大于一定数据块故障.

但是不是所有的应用都支持纠删码池, RBD只支持副本池而radosgw则可以支持纠删码池.

副本池IO

将一个数据对象存储为多个副本在客户端写入操作时, ceph使用CRUSH算法计算出与对象相对应的PGID和 primary OSD主OSD根据设置的副本数、对象名称、存储池名称和集群运行图(cluster map)计算出PG的各辅助OSD，然后由OSD将数据再同步给辅助OSD.

读取数据:
1.客户端发送读请求,RADOS将请求发送到主OSD.
2.主OSD从本地磁盘读取数据并返回数据，最终完成读请求.

读取数据：
1．客户端APP请求写入数据，RADOS发送数据到主OSD.
2.主OSD 识别副本OSDs，并发送数据到各副本OSD.
3.副本 OSDs写入数据,并发送写入完成信号给主OSD.
4．主OSD发送写入完成信号给客户端 APP.

PG与PGP

PG =Placement Group #归置组

PGP = Placement Group for Placement purpose#归置组的组合, pgp相当于是pg对应osd 的一种排列组合关系.

归置组(placement group)是用于跨越多OSD将数据存储在每个存储池中的内部数据结构.
归置组在OSD守护进程和 ceph客户端之间生成了一个中间层，CRUSH算法负责将每个对象动态映射到一个归置组，然后再将每个归置组动态映射到一个或多个OSD守护进程,从而能够支持在新的OSD设备上线时进行数据重新平衡.

相对于存储池来说，PG是一个虚拟组件，它是对象映射到存储池时使用的虚拟层.

可以自定义存储池中的归置组数量.

ceph出于规模伸缩及性能方面的考虑,ceph将存储池细分为多个归置组，把每个单独的对象映射到归置组，并为归置组分配一个主OSD.

存储池由一系列的归置组组成，而CRUSH算法则根据集群运行图和集群状态，将个PG均匀、伪随机(基于hash映射,每次的计算结果够一样)的分布到集群中的OSD之上.

如果某个OSD 失败或需要对集群进行重新平衡,ceph则移动或复制整个归置组而不需要单独对每个镜像进行寻址.

PG与OSD关系

ceph基于crush算法将归置组PG分配至OSD

当一个客户端存储对象的时候，CRUSH 算法映射每一个对象至归置组(PG)

PG分配计算

归置组(PG)的数量是由管理员在创建存储池的时候指定的，然后由CRUSH负责创建和使用，PG的数量是2的N次方的倍数,每个OSD的PG不要超出250个PG，官方是每个OSD100个左右

1.通常，PG的数量应该是数据的合理力度的子集.例如:一个包含256个PG的存储池,每个PG中包含大约1/256的存储池数据

2当需要将PG从一个OSD移动到另一个OSD的时候,PG的数量会对性能产生影响.PG的数量过少，一个 OSD上保存的数据数据会相对加多，那么ceph同步数据的时候产生的网络负载将对集群的性能输出产生一定影响.

PG过多的时候,ceph将会占用过多的CPU和内存资源用于记录PG的状态信息3.PG的数量在集群分发数据和重新平衡时扮演者重要的角色作用
在所有OSD之间进行数据持久存储以及完成数据分布会需要较多的归置组，但是他们的数量应该减少到实现 ceph最大性能所需的最小PG数量值，以节省CPU和内存资源.
一般来说，对于有着超过50个OSD的RADOS集群，建议每个OSD大约有50-100个PG 以平衡资源使用及取得更好的数据持久性和数据分布，而在更大的集群中，每个OSD可以有100-200个PG

至于一个pool应该使用多少个PG,可以通过下面的公式计算后，将pool的PG值四舍五入到最近的2的N次幂，如下先计算出ceph集群的总PG 数:
Total OSDs* PGPerOSD/replication factor => total PGs 磁盘总数x每个磁盘PG数/副本数=> ceph集群总PG数(略大于2^n次方)

官方计算公式
Total PGs = (Total_number_of_OSD *100) / max _replication_count

需要结合数据数量、磁盘数量及磁盘空间计算出PG数量,8、16、32、64、128、256等2的N次方.
一个RADOS集群上会存在多个存储池,因此管理员还需要考虑所有存储池上的PG分布后每个OSD需要映射的PG数量.

PG状态

Peering

正在同步状态，同一个PG中的OSD需要将准备数据同步一致,而Peering(对等)就是OSD同步过程中的状态.

Activating

Peering 已经完成，PG正在等待所有PG实例同步Peering 的结果(Info、Log 等)

Clean

干净态,PG当前不存在待修复的对象，并且大小等于存储池的副本数，即PG的活动集(Acting Set)和上行集(up Set)为同一组 OSD且内容一致.
活动集(Acting Set):由PG当前主的OSD和其余处于活动状态的备用OSD组成，当前PG内的OSD负责处理用户的读写请求.
上行集(Up Set):在某一个OSD故障时，需要将故障的OSD更换为可用的OSD，并主PG内部的主OSD同步数据到新的OSD 上，例如PG内有OSD1、OSD2、OSD3，当OSD3故障后需要用OSD4替换OSD3，那么OSD1、OSD2、OSD3就是上行集，替换后OSD1、OSD2、OSD4就是活动集，OSD替换完成后活动集最终要替换上行集．

Active

就绪状态或活跃状态,Active表示主OSD和备OSD 处于正常工作状态，此时的PG可以正常处理来自客户端的读写请求，正常的PG 默认就是Active+Clean状态．

ceph@ceph-deploy:/home/ceph/ceph-cluster$ ceph pg stat
129 pgs: 129 active+clean; 319 KiB data,1.1 GiB used, 2.0 TiB/2.0 TiB avail

Degraded:降级状态

降级状态出现于OSD被标记为down以后，那么其他映射到此OSD的PG都会转换到降级状态.

如果此OSD还能重新启动完成并完成Peering操作后,那么使用此OSD的PG将重新恢复为clean状态.

如果此OSD被标记为down的时间超过5分钟还没有修复,那么此OSD将会被ceph踢出集群，然后ceph 会对被降级的PG启动恢复操作，直到所有由于此OSD而被降级的PG重新恢复为clean状态.

恢复数据会从PG内的主OSD恢复，如果是主OSD故障，那么会在剩下的两个备用OSD重新选择一个作为主OSD.

Stale:过期状态:

正常状态下,每个主OSD都要周期性的向RADOS集群中的监视器(Mon)报告其作为主OSD所持有的所有PG的最新统计数据，因任何原因导致某个OSD无法正常向监视器发送汇报信息的、或者由其他OSD报告某个OSD已经down 的时候，则所有以此OSD为主PG则会立即被标记为stale状态，即他们的主OSD已经不是最新的数据了，如果是备份的OSD
发送down的时候，则ceph 会执行修复而不会触发PG状态转换为stale状态.

undersized

PG当前副本数小于其存储池定义的值的时候，PG会转换为undersized状态，比如两个备份OSD都down了，那么此时PG中就只有一个主OSD了，不符合ceph最少要求一个主OSD加一个备OSD的要求，那么就会导致使用此OSD的PG转换为undersized状态，直到添加备份OSD添加完成，或者修复完成.

Scrubbing

scrub是ceph对数据的清洗状态，用来保证数据完整性的机制,Ceph 的OSD定期启动scrub线程来扫描部分对象，通过与其他副本比对来发现是否一致，如果存在不一致，抛出异常提示用户手动解决, scrub 以PG为单位，对于每一个 pg, ceph分析该pg下所有的object，产生一个类似于元数据信息摘要的数据结构,如对象大小,属性等,叫scrubmap,比较主与副scrubmap，来保证是不是有object丢失或者不匹配，扫描分为轻量级扫描和深度扫描，轻量级扫描也叫做light scrubs或者shallow scrubs或者simply scrubs即轻量级扫描.
Light scrub(daily)比较object size和属性, deep scrub (weekly)读取数据部分并通过checksum(CRC32算法)对比和数据的一致性,深度扫描过程中的PG会处于scrubbing+deep状态.

Recovering

正在恢复态，集群正在执行迁移或同步对象和他们的副本，这可能是由于添加了一个新的OSD到集群中或者某个OSD宕掉后,PG可能会被CRUSH算法重新分配不同的OSD，而由于OSD更换导致PG发生内部数据同步的过程中的PG会被标记为Recovering.

Backfilling

正在后台填充态,backfill是 recovery 的一种特殊场景，指peering完成后，如果基于当前权威日志无法对Up Set(上行集)当中的某些PG实例实施增量同步(例如承载这些PG实例的OSD离线太久,或者是新的OSD加入集群导致的PG实例整体迁移)则通过完全拷贝当前Primary所有对象的方式进行全量同步，此过程中的PG会处于backfilling.

Backfill-toofull

某个需要被Backfill的PG实例，其所在的OSD可用空间不足，Backfill流程当前被挂起时PG给的状态.

数据读写流程

ceph读写对象的时候，客户端从ceph 监视器检索出集群运行图(cluster map)，然后客户端访问指定的存储池，并对存储池内PG的对象执行读写操作.
存储池的CRUSH计算结果和PG的数量，是决定ceph 如何放置数据的关键因素．
基于集群的最新运行图，客户端能够了解到集群中的所有监视器和OSD以及他们各自当前的状态.
但是客户端仍然不知道对象的保存位置.
客户端在读写对象时，需要提供的是对象标识和存储池名称.
客户端需要在存储池中读写对象时，需要客户端将对象名称、对象名称的 hash 码、存储池中的PG数量和存储池名称作为输入信息提供给ceph，然后由 CRUSH计算出PG的ID以及此PG针对的主OSD即可读写OSD中的对象.

具体写操作如下

1.APP向ceph客户端发送对某个对象的请求,此请求包含对象和存储池，然后ceph客户端对访问的对象做hash计算，并根据此hash值计算出对象所在的PG，完成对象从Pool至PG的映射.

APP访问pool ID和object lD(比如 pool = pool1 and object-id = “name1”"ceph client 对objectlD做哈希
ceph client对该 hash值取PG总数的模，得到PG编号(比如32).(第2和第3步基本保证了一个pool 内部的所有PG将会被均匀地使用)
ceph client 对pool ID取hash(比如“pool1”= 3)
ceph client将 pool ID和PGID组合在一起(比如3.23)得到PG的完整ID.

⒉.然后客户端据PG,CRUSH运行图和归置组(placement rules)作为输入参数并再次进行计算，并计算出对象所在的PG内的主OSD ，从而完成对象从PG到OSD的映射.
Ceph client 从 MON获取最新的cluster map.
Ceph client根据上面的第(2)步计算出该object将要在的PG的ID.
Ceph client再根据CRUSH算法计算出PG中目标主和备OSD的ID，即可对OSD的数据进行读写.

3.客户端开始对主OSD进行读写请求(副本池IO)，如果发生了写操作，会有ceph服务端完成对象从主OSD到备份OSD的同步.

存储池删除

如果把存储池删除会导致把存储池内的数据全部删除，因此ceph为了防止误删除存储池设置了两个机制来防止误删除操作．
第一个机制是NODELETE标志，需要设置为 false但是默认就是false 了.

$ ceph osd pool get mypool2 
nodeletenodelete: false

如果设置为了true就表示不能删除，可以使用set指令重新设置为fasle
[ceph@ceph-deploy ceph-cluster]$ ceph osd pool set mypool2 nodelete trueset pool 9 nodelete to true
[ceph@ceph-deploy ceph-cluster]$ ceph osd pool set mypool2 nodelete falseset pool 9 nodelete to false
[ceph@ceph-deploy ceph-cluster]$ ceph osd pool get mypool2 
nodeletenodelete: false

第二个机制是集群范围的配置参数 mon allow pool delete，默认值为false，即监视器不允许删除存储池,可以在特定场合使用tell指令临时设置为(true)允许删除,在删除指定的pool之后再重新设置为 false.

$ ceph tell mon.*injectargs --mon-allow-pool-delete=true
mon.ceph-mon1: injectargs:mon_allow_pool_delete = 'true'
mon.ceph-mon2: injectargs:mon_allow_pool_delete = 'true'
mon.ceph-mon3: injectargs:mon_allow_pool_delete = 'true'

$ ceph osd pool rm mypool2 mypool2 --yes-i-really-really-mean-it
pool 'mypool2' removed

$ceph tell mon.* injectargs --mon-allow-pool-delete=false
mon.ceph-mon1: injectargs:mon_allow_pool_delete = 'false'
mon.ceph-mon2: injectargs:mon_allow_pool_delete = 'false'
mon.ceph-mon3: injectargs:mon_allow_pool_delete = 'false

存储池配额
存储池可以设置两个配对存储的对象进行限制，一个配额是最大空间(max_bytes)，另外一个配额是对象最大数量(max_objects).

$ ceph osd pool get-quota mypool
quotas for pool 'mypool':
    max objects: N/A #默认不限制对象数量
    max bytes : N/A #默认不限制空间大小

$ ceph osd pool set-quota mypool max_objects 1000 #限制最大1000个对象
set-quota max_objects = 1000 for pool mypool

ceph osd pool set-quota mypool max_objects1000
set-quota max_objects = 1000 for pool mypool #限制最多1000个对象

$ ceph osd pool set-quota mypool max_bytes10737418240#限制最大10737418240字节
set-quota max_bytes = 10737418240 for pool mypool

$ ceph osd pool get-quota mypoolquotas for pool 'mypool":
max objects: 1 k objects #最多1000对象
max bytes : 10GiB#最大10G空间