目录
一：存储基础
1、单机存储设备
（1）DAS（直接附加存储，是直接接到计算机的主板总线上去的存储）
（2）NAS（网络附加存储，是通过网络附加到当前主机文件系统之上的存储）
（3）SAN（存储区域网络）
2、单机存储的问题
（1）存储处理能力不足
（2）存储空间能力不足
（3）单点故障问题
3、商业存储解决方案
4、分布式存储（软件定义的存储 SDS）
5、分布式存储的类型
（1）块存储
(2)文件存储
（3）对象存储
二：Ceph 介绍
1、Ceph 简介
2、Ceph 优势
3、Ceph 架构
（1）RADOS 基础存储系统
（2）LIBRADOS 基础库
（3）高层应用接口
（4）应用层
4、Ceph 核心组件
（1）OSD（Object Storage Daemon，守护进程 ceph-osd）
（2）PG（Placement Group 归置组）
（3）Pool
（4）Monitor（守护进程 ceph-mon）
（5）Manager（守护进程 ceph-mgr）
（6）MDS（Metadata Server，守护进程 ceph-mds）
5、OSD 存储后端
（1）Filestore
（2）Bluestore
6、Ceph 数据的存储过程
7、Ceph 版本发行生命周期
8、Ceph 集群部署
（1）ceph-deploy
（2）cephadm
（3）二进制
三：基于 ceph-deploy 部署 Ceph 集群
1、Ceph 生产环境推荐
2、环境准备
3、关闭 selinux 与防火墙
4、 根据规划设置主机名
5、 配置 hosts 解析
6、 安装常用软件和依赖包
7、 在 admin 管理节点配置 ssh 免密登录所有节点
8、配置时间同步
9、配置 Ceph yum源
10、执行完上面所有的操作之后重启所有主机（可选）
四：部署 Ceph 集群
1、为所有节点都创建一个 Ceph 工作目录，后续的工作都在该目录下进行
2、admin服务器安装 安装 ceph-deploy 部署工具
3、在管理节点为其它节点安装 Ceph 软件包
4、生成初始配置
5、在管理节点初始化 mon 节点
6、部署能够管理 Ceph 集群的节点（可选）
7、部署 osd 存储节点，管理节点操作
8、部署 mgr 节点
9、开启监控模块
五：资源池 Pool 管理
1、向 Ceph 中存储数据
2、创建 Pool 资源池--（增、查）
3、 修改资源池信息--（修）
4、删除 Pool 资源池--（删）
（1）DAS（直接附加存储，是直接接到计算机的主板总线上去的存储）
（2）NAS（网络附加存储，是通过网络附加到当前主机文件系统之上的存储）
（3）SAN（存储区域网络）
传统的IDE的IO值是100次/秒，SATA固态磁盘500次/秒，固态硬盘达到2000-4000次/秒。即使磁盘的IO能力再大数十倍，也不够抗住网站访问高峰期数十万、数百万甚至上亿用户的同时访问，这同时还要受到主机网络IO能力的限制。
单块磁盘的容量再大，也无法满足用户的正常访问所需的数据容量限制。
单机存储数据存在单点故障问题
EMC、NetAPP、IBM、DELL、华为、浪潮
（1）块存储
(2)文件存储
（3）对象存储
（例如OSS，一个存储可以被多服务同时访问，具备块存储的高速读写能力，也具备文件存储共享的特性，适用图片存储、视频存储）
基于API接口提供的文件存储，每一个文件都是一个对象，且文件大小各不相同的，文件的元数据和实际数据是存放在一起的
Ceph使用C++语言开发，是一个开放、自我修复和自我管理的开源分布式存储系统。具有高扩展性、高性能、高可靠性的优点。
●高扩展性：去中心化，支持使用普通X86服务器，支持上千个存储节点的规模，支持TB到EB级的扩展。
●高可靠性：没有单点故障，多数据副本，自动管理，自动修复。
●高性能：摒弃了传统的集中式存储元数据寻址的方案，采用 CRUSH 算法，数据分布均衡，并行度高。
●功能强大：Ceph是个大一统的存储系统，集块存储接口（RBD）、文件存储接口（CephFS）、对象存储接口（RadosGW）于一身，因而适用于不同的应用场景。
自下向上，可以将Ceph系统分为四个层次:
（1）RADOS 基础存储系统
（2）LIBRADOS 基础库
Librados提供了与RADOS进行交互的方式，并向上层应用提供Ceph服务的API接口，因此上层的RBD、RGW和CephFS都是通过Librados访问的，目前提供PHP、Ruby、Java、Python、Go、C和C++支持，以便直接基于RADOS（而不是整个Ceph）进行客户端应用开发。
（3）高层应用接口
（4）应用层
基于高层接口或者基础库Librados开发出来的各种APP，或者Host、VM等诸多客户端
Ceph是一个对象式存储系统，它把每一个待管理的数据流（如文件等数据）切分为一到多个固定大小（默认4兆）的对象数据（Object），并以其为原子单元（原子是构成元素的最小单元）完成数据的读写。
（1）OSD（Object Storage Daemon，守护进程 ceph-osd）
是负责物理存储的进程，一般配置成和磁盘一一对应，一块磁盘启动一个OSD进程。主要功能是存储数据、复制数据、平衡数据、恢复数据，以及与其它OSD间进行心跳检查，负责响应客户端请求返回具体数据的进程等。通常至少需要3个OSD来实现冗余和高可用性。
（2）PG（Placement Group 归置组）
PG 是一个虚拟的概念而已，物理上不真实存在。它在数据寻址时类似于数据库中的索引：Ceph 先将每个对象数据通过HASH算法固定映射到一个 PG 中，然后将 PG 通过 CRUSH 算法映射到 OSD。
（3）Pool
Pool 是存储对象的逻辑分区，它起到 namespace 的作用。每个 Pool 包含一定数量（可配置）的 PG。Pool 可以做故障隔离域，根据不同的用户场景统一进行隔离。
Pool中数据保存方式支持两种类型：
●多副本（replicated）：类似 raid1，一个对象数据默认保存 3 个副本，放在不同的 OSD
●纠删码（Erasure Code）：类似 raid5，对 CPU 消耗稍大，但是节约磁盘空间，对象数据保存只有 1 个副本。由于Ceph部分功能不支持纠删码池，此类型存储池使用不多
Pool、PG 和 OSD 的关系：
一个Pool里有很多个PG；一个PG里包含一堆对象，一个对象只能属于一个PG；PG有主从之分，一个PG分布在不同的OSD上（针对多副本类型）
（4）Monitor（守护进程 ceph-mon）
用来保存OSD的元数据。负责维护集群状态的映射视图（Cluster Map：OSD Map、Monitor Map、PG Map 和 CRUSH Map），维护展示集群状态的各种图表， 管理集群客户端认证与授权。一个Ceph集群通常至少需要 3 或 5 个（奇数个）Monitor 节点才能实现冗余和高可用性，它们通过 Paxos 协议实现节点间的同步数据。
（5）Manager（守护进程 ceph-mgr）
负责跟踪运行时指标和 Ceph 集群的当前状态，包括存储利用率、当前性能指标和系统负载。为外部监视和管理系统提供额外的监视和接口，例如 zabbix、prometheus、 cephmetrics 等。一个 Ceph 集群通常至少需要 2 个 mgr 节点实现高可用性，基于 raft 协议实现节点间的信息同步。
（6）MDS（Metadata Server，守护进程 ceph-mds）
是 CephFS 服务依赖的元数据服务。负责保存文件系统的元数据，管理目录结构。对象存储和块设备存储不需要元数据服务；如果不使用 CephFS 可以不安装。
OSD 有两种方式管理它们存储的数据。在 Luminous 12.2.z 及以后的发行版中，默认（也是推荐的）后端是 BlueStore。在 Luminous 发布之前， 默认是 FileStore， 也是唯一的选项。
（1）Filestore
（2）Bluestore
BlueStore是一个特殊用途的存储后端，专门为OSD工作负载管理磁盘上的数据而设计。BlueStore 的设计是基于十年来支持和管理 Filestore 的经验。BlueStore 相较于 Filestore，具有更好的读写性能和安全性。
BlueStore 的主要功能包括：1）BlueStore直接管理存储设备，即直接使用原始块设备或分区管理磁盘上的数据。这样就避免了抽象层的介入（例如本地文件系统，如XFS)，因为抽象层会限制性能或增加复杂性。
2）BlueStore使用RocksDB进行元数据管理。RocksDB的键/值数据库是嵌入式的，以便管理内部元数据，包括将对象名称映射到磁盘上的块位置。
3）写入BlueStore的所有数据和元数据都受一个或多个校验和的保护。未经验证，不会从磁盘读取或返回给用户任何数据或元数据。
4）支持内联压缩。数据在写入磁盘之前可以选择性地进行压缩。
5）支持多设备元数据分层。BlueStore允许将其内部日志（WAL预写日志）写入单独的高速设备（如SSD、NVMe或NVDIMM)，以提高性能。如果有大量更快的可用存储，则可以将内部元数据存储在更快的设备上。
6）支持高效的写时复制。RBD和CephFS快照依赖于在BlueStore中有效实现的即写即复制克隆机制。这将为常规快照和擦除编码池（依赖克隆实现高效的两阶段提交）带来高效的I/O。
1）客户端从 mon 获取最新的 Cluster Map
2）在 Ceph 中，一切皆对象。Ceph 存储的数据都会被切分成为一到多个固定大小的对象（Object）。Object size 大小可以由管理员调整，通常为 2M 或 4M。
每个对象都会有一个唯一的 OID，由 ino 与 ono 组成：
●ino ：即是文件的 FileID，用于在全局唯一标识每一个文件
●ono ：则是分片的编号
比如：一个文件 FileID 为 A，它被切成了两个对象，一个对象编号0，另一个编号1，那么这两个文件的 oid 则为 A0 与 A1。
OID 的好处是可以唯一标示每个不同的对象，并且存储了对象与文件的从属关系。由于 Ceph 的所有数据都虚拟成了整齐划一的对象，所以在读写时效率都会比较高。
4）PG 会根据设置的副本数量进行复制，通过对 PGID 使用 CRUSH 算法算出 PG 中目标主和次 OSD 的 ID，存储到不同的 OSD 节点上（其实是把 PG 中的所有对象存储到 OSD 上）。
即通过 CRUSH(PGID) 得到将 PG 中的数据存储到各个 OSD 组中
CRUSH 是 Ceph 使用的数据分布算法，类似一致性哈希，让数据分配到预期的地方。
Ceph从Nautilus版本（14.2.0）开始，每年都会有一个新的稳定版发行，预计是每年的3月份发布，每年的新版本都会起一个新的名称（例如，“Mimic”）和一个主版本号（例如，13代表Mimic，因为“M”是字母表的第13个字母）。
版本号的格式为 x.y.z，x 表示发布周期（例如，13 代表 Mimic，17 代表 Quincy），y 表示发布版本类型，即
● x.0.z ：y等于 0，表示开发版本
● x.1.z ：y等于 1，表示发布候选版本（用于测试集群）
● x.2.z ：y等于 2，表示稳定/错误修复版本（针对用户）
目前 Ceph 官方提供很多种部署 Ceph 集群的方法，常用的分别是 ceph-deploy，cephadm 和 二进制：
（1）ceph-deploy
一个集群自动化部署工具，使用较久，成熟稳定，被很多自动化工具所集成，可用于生产部署。
（2）cephadm
从 Octopus 和较新的版本版本后使用 cephadm 来部署 ceph 集群，使用容器和 systemd 安装和管理 Ceph 集群。目前不建议用于生产环境。
（3）二进制
手动部署，一步步部署 Ceph 集群，支持较多定制化和了解部署细节，安装难度较大。
1、存储集群全采用万兆网络
2、集群网络（cluster-network，用于集群内部通讯）与公共网络（public-network，用于外部访问Ceph集群）分离
3、mon、mds 与 osd 分离部署在不同主机上（测试环境中可以让一台主机节点运行多个组件）
4、OSD 使用 SATA 亦可
5、根据容量规划集群
6、至强E5 2620 V3或以上 CPU，64GB或更高内存
7、集群主机分散部署，避免机柜的电源或者网络故障
可以看到显示有一台osd down， 这是只需要重新配置一下时间同步，然后重启一下就好了
首先我们需要在 Ceph 中定义一个 Pool 资源池。Pool 是 Ceph 中存储 Object 对象抽象概念。
我们可以将其理解为 Ceph 存储上划分的逻辑分区，Pool 由多个 PG 组成；而 PG 通过 CRUSH 算法映射到不同的 OSD 上；
同时 Pool 可以设置副本 size 大小，默认副本数量为 3。
Ceph 客户端向 monitor 请求集群的状态，并向 Pool 中写入数据，数据根据 PGs 的数量，
通过 CRUSH 算法将其映射到不同的 OSD 节点上，实现数据的存储。 这里我们可以把 Pool 理解为存储 Object 数据的逻辑单元；
当然，当前集群没有资源池，因此需要进行定义。
版权声明：
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！
转载请注明出处，原文链接：https://www.xkablog.com/cjjbc/35193.html