ceph 笔记

01 ceph中pool osds和crush算法之间的关系

在 Ceph 存储系统中，理解 pool（存储池）、OSDs（对象存储设备）和 CRUSH 算法之间的关系，可以通过一个购物中心的比喻来解释。

1. 存储池 (Pools)：想象 Ceph 中的存储池就像购物中心里的不同商店。每个商店（存储池）专门销售特定类型的商品（数据）。就像你可能去一家服装店购买衣服，或者去书店购买书籍一样，不同类型的数据被存储在不同的存储池中。

2. 对象存储设备 (OSDs)：OSDs 可以被看作是存放商品的货架。购物中心里的每个商店都有许多货架，用来存放商品。在 Ceph 中，每个 OSD 就是一个存储设备，用于存储数据。整个 Ceph 集群可能包含成百上千个这样的 OSDs。

3. CRUSH 算法：CRUSH 算法就像是购物中心的智能导购系统。当顾客（数据请求）来到商店（存储池）寻找特定的商品（数据）时，智能导购系统（CRUSH 算法）会告诉他们商品放置在哪个货架（OSD）上。这个系统非常智能，它不仅知道每件商品在哪里，还能在某个货架损坏时，迅速重新安排商品的存放位置，确保顾客总能找到他们需要的商品。

在这个比喻中，CRUSH 算法的作用是确保数据能够被高效、均衡且可靠地分配到各个 OSDs 上。它根据预定义的规则，动态地决定每个数据块存储在哪个 OSD 上，同时确保数据的高可用性和容错性。总之，存储池定义了数据的类型和存储特性，OSDs 提供物理存储空间，而 CRUSH 算法则负责智能地在 OSDs 之间分配和管理数据。

实际使用中，如何使用pool osds

在实际使用 Ceph 的过程中，使用存储池（pools）和对象存储设备（OSDs）涉及到数据的存储和管理。让我们通过一个具体的项目示例来说明这一过程：

项目背景：在线文档存储和共享服务

假设你正在部署一个在线文档存储和共享服务，这个服务需要存储大量的文档文件，同时确保这些文件的快速访问和高可用性。

设置存储池

1. 创建存储池：首先，你需要在 Ceph 集群中创建一个或多个存储池。例如，你可能创建一个名为 documents 的存储池，专门用于存储文档文件。

   ceph osd pool create documents 128
   

   这里 128 指定了存储池的 placement group 数量，这是一个影响数据分布和性能的重要参数。

2. 设置复制因子：为了确保数据的高可用性，你可能会设置一个复制因子，比如复制 3 份（三副本），这意味着每个数据块都会在三个不同的 OSDs 上存储。

   ceph osd pool set documents size 3
   

使用 OSDs

3. 数据存储和分布：当你的服务开始存储文件到 documents 存储池时，CRUSH 算法会自动决定这些数据应该存储在哪些 OSDs 上。这个过程是透明的，你不需要手动干预。

4. 容错和负载均衡：如果某个 OSD 出现问题或集群扩展了新的 OSDs，CRUSH 算法会自动调整数据的分布，以确保持续的容错性和负载均衡。

项目应用

5. 数据访问：当用户通过你的服务请求访问特定文档时，Ceph 会使用 CRUSH 算法快速定位存储该文档的 OSDs，并从中检索数据。

6. 扩展和管理：随着服务的使用量增长，你可能需要添加更多的 OSDs 来扩展存储能力。添加新的 OSDs 是一个简单的过程，Ceph 集群会自动将它们纳入数据分布中。

结论

在这个项目中，存储池 documents 提供了一个逻辑上的分区，用于组织和管理特定类型的数据（文档文件）。OSDs 提供了物理存储空间，而 CRUSH 算法确保了数据的高效、均衡分布和容错性。这种设置支持了在线文档存储和共享服务的核心需求，如高可用性、快速访问和可扩展性。

128的含义

在 Ceph 存储系统中，数字 128 在创建存储池命令中代表的是“Placement Group（PG）”的数量。了解 Placement Groups 的作用和重要性是理解 Ceph 架构的关键部分。

什么是 Placement Groups (PGs)？

1. 数据组织的单元：在 Ceph 中，Placement Groups 是数据组织和管理的一种单元。它们不直接存储数据，而是作为数据在 OSDs（对象存储设备）上分布的一个逻辑单位。

2. 数据分布和负载均衡：PGs 的主要目的是为了实现数据的均匀分布和负载均衡。通过将数据均匀分配到不同的 PGs，然后将这些 PGs 分散到不同的 OSDs 上，Ceph 能够确保没有任何单一的 OSD 被过度负荷。

为什么 PG 的数量重要？

1. 影响性能和扩展性：PG 的数量直接影响 Ceph 集群的性能和扩展性。太少的 PGs 可能导致数据分布不均，从而影响性能和可用性。而太多的 PGs 可能会增加 OSDs 的管理开销，同样影响性能。

2. 平衡和调整：选择合适的 PG 数量是一种平衡。需要足够多的 PGs 来确保数据均匀分布，但也不能太多，以避免给 OSDs 带来过多的管理负担。

为什么选择 128？

选择 128 作为 PG 数量是基于集群的大小和预期的数据量。Ceph 官方文档提供了一些指导，帮助确定合适的 PG 数量。这个数字通常是根据 OSD 的数量和存储池的复制因子来决定的。对于小到中等规模的集群，128 是一个常见的起始点，但这个数字可能需要根据实际情况进行调整。

结论

总的来说，PGs 在 Ceph 中扮演着至关重要的角色，它们帮助确保数据在 OSDs 之间的均匀分布和高效管理。选择合适的 PG 数量是实现优化性能和扩展性的关键步骤。在实践中，选择 PG 数量通常需要考虑到集群的规模、预期的增长以及数据的特性。

02 CRUSH算法

Ceph 的 CRUSH 算法是一个智能的数据分布算法，用于有效地管理和存储大量数据。想要通俗易懂地解释这个算法，我们可以将其比作一个智能的图书管理员，负责在一个巨大的图书馆（即存储集群）中放置和寻找书籍（即数据）。

1. 自定义规则：就像图书管理员可以根据图书馆的布局和图书的种类来决定如何放置书籍，CRUSH 算法允许系统管理员定义规则，指导数据如何在不同的硬件资源（如硬盘、服务器等）上分布。

2. 灵活性和扩展性：CRUSH 算法能够适应存储集群的变化，就像图书管理员可以轻松应对图书馆的扩建或图书的增减一样。这意味着当新的存储设备加入或旧的设备移除时，CRUSH 算法可以动态地调整数据的位置，以保持数据的均衡分布。

3. 高效的数据查找：CRUSH 算法能够快速地定位数据，这就像图书管理员知道每本书的确切位置，用户请求特定数据时，系统可以迅速找到这些数据存储在哪个服务器的哪个硬盘上。

4. 容错性：如果某个存储设备发生故障，CRUSH 算法就像一个图书管理员在发现某个书架坏了之后，会将书籍移动到其他书架，以确保信息的安全和可访问性。这意味着数据的副本会被存储在多个地方，从而保证在某些设备故障时数据仍然安全。

总的来说，CRUSH 算法是 Ceph 存储系统的一个核心组成部分，它通过智能的数据分布策略，确保数据的高效存取、灵活管理和安全保障。

03 简述Ceph存储体系架构？

Ceph是一个开源的分布式存储系统，其存储体系架构包括以下关键组件和层次结构：

1. RADOS（Reliable Autonomic Distributed Object Store可靠的自主分布式对象存储）：
   • RADOS是Ceph的核心存储层，它将数据分成小的对象，并在多个存储节点之间复制和分布这些对象，以实现高可用性和容错性。

当我们谈论Ceph架构时，可以将其比喻为一个分布式存储系统的大脑和身体。

首先，我们有一个或多个称为监视器（Monitors）的大脑。这些监视器负责管理整个Ceph集群，跟踪存储元数据、管理集群状态和配置信息等。它们还负责处理客户端请求，帮助客户端找到正确的存储位置。

然后，我们有一组对象存储设备，比如硬盘，它们就像Ceph的身体。Pools（存储池）是RADOS中的逻辑容器，用于组织和管理对象。可以将存储池看作是一组相关的对象的集合，类似于文件夹或目录。每个存储池可以根据需要创建，并具有自己的设置和配置。例如，你可以创建一个存储池用于存储数据库备份，另一个存储池用于存储视频文件。

接下来是一组称为OSDs（Object Storage Daemons）的节点。每个OSD负责管理一块物理存储设备，并将数据划分成小的存储块。它们负责数据的读取、写入、复制和恢复，以及保持数据的可靠性和高可用性。

此外，Ceph使用CRUSH算法来决定数据在存储集群中的位置。CRUSH算法确保数据在各个存储设备之间均衡地分布，同时考虑设备的容量和负载情况。这样可以实现数据的高性能访问和冗余备份。

最后，我们有客户端应用程序或用户，它们通过网络与Ceph集群进行交互，读取和写入数据。客户端可以使用各种接口，如对象存储接口、文件系统接口或块设备接口来访问和操作数据。

RADOS GW和RBD：RADOS GateWay、RBD其作用是在librados库的基础上提供抽象层次更高、更便于应用或客户端使用的上层接口。其中，RADOS GW是一个提供与Amazon S3和Swift兼容的RESTful API的gateway，以供相应的对象存储应用开发使用。RBD则提供了一个标准的块设备接口，常用于在虚拟化的场景下为虚拟机创建volume。

CEPHFS：CEPHFS则提供了POSIX接口，用户可直接通过客户端挂载使用。

综上所述，Ceph架构由监视器、对象存储设备、OSD节点和客户端组成，通过CRUSH算法来实现数据的分布和管理。这个分布式存储系统的设计使得数据在大规模环境下具有高性能、可靠性和可扩展性，并为用户提供灵活的存储解决方案。

04 简述ceph pool 有几种类型？

Ceph中的Pool是一种用于组织和管理数据的存储单元，它可以根据不同的需求和用途进行配置。通常情况下，Ceph支持三种主要类型的Pool：

1. Replicated Pools（复制池）：

   • 复制池是最常见的一种Pool类型。在复制池中，数据对象会被复制到多个存储节点上，以提供高可用性和冗余。如果一个存储节点发生故障，数据仍然可以从其他副本中恢复。
   • 复制池适用于需要高可靠性和冗余的应用场景，但它可能会消耗更多的存储空间，因为每个对象都有多个副本。

2. Erasure-coded Pools（纠删码池）：

   • 纠删码池使用纠删码编码技术，将数据切割成小块，并对这些块进行编码。然后，这些编码块会分散存储在不同的存储节点上，以实现数据的冗余和可用性。
   • 纠删码池在一定程度上降低了存储空间的需求，因为它相对于复制来说更加节省空间。但它通常需要更多的计算资源来编码和解码数据块。

3. Cache Tier Pools（缓存层池）：

   • 缓存层池用于优化数据的访问性能。它通常包括两个池：一个是原始数据池，另一个是用于缓存的池。
   • 原始数据池存储实际的数据，而缓存池存储数据的缓存副本。热门或频繁访问的数据会被缓存到缓存池中，以提高读取性能。

这些不同类型的Pool可以根据具体的需求来配置，以满足不同应用场景的要求。例如，如果对数据的可用性要求很高，可以选择使用复制池。如果对存储空间的有效利用非常重要，可以考虑使用纠删码池。而如果需要提高数据访问性能，可以使用缓存层池。

既然erasure-coded pool（纠删码池）那么好，都用它就行了，为啥还需要replicated pool（副本池）？

虽然erasure-coded pool在存储效率方面具有优势，但它也存在一些限制和适用场景的考虑。以下是为什么还需要使用replicated pool的原因：

1. 写入性能：纠删码池需要进行编码和解码操作，这会带来额外的计算开销。相比之下，副本池只需要简单地将数据对象复制到多个节点上，写入性能更高。

2. 数据访问延迟：由于纠删码池需要对数据进行解码操作，读取请求的处理时间会比副本池长。如果应用程序对低延迟有较高要求，则副本池可以提供更快的数据访问速度。

3. 存储容量：纠删码池确实在存储效率方面比副本池更高，因为它可以使用较少的冗余数据。然而，纠删码保护也需要存储额外的校验块，这会增加一定的存储开销。如果存储容量不是主要关注点，副本池可以提供更简单、更直观的数据备份。

4. 维护复杂性：纠删码池的设置和维护相对较为复杂。它需要配置纠删码规则、确定数据块和校验块的数量等。相比之下，副本池的配置和管理更加简单。

05 简述Ceph Pool、PG、ODDs的关系？

Pool又被划分为多个逻辑区块组（PG），每个PG是一个固定大小的分组，包含了一定数量的对象副本。PG也需要通过CRUSH算法映射到OSD中去存储。以二副本为例，每个PG都会映射到两个OSD上，比如[osd.1,osd.2]，那么osd.1是存放该PG的主副本，osd.2是存放该PG的从副本，保证了数据的冗余。

OSD是Ceph存储集群中的实际存储设备，它们负责存储和管理数据。每个OSD代表一个物理存储节点上的存储设备，例如硬盘或固态硬盘。

06 简述Ceph节点的角色？

Ceph中有几种不同角色的节点，每个节点都有自己的任务和责任，就像团队中的不同成员。以下是通俗易懂的解释：

1. Monitor（监控节点）：监控节点就像团队的领导者，它们负责监督整个Ceph存储集群的状态和健康状况。它们记录存储集群中的信息，协调各种操作，确保系统正常运行。如果有问题，监控节点会采取措施来修复或通知其他节点采取行动。

2. OSD（对象存储守护进程节点）

3. MDSs：Ceph元数据服务器（MDS）为Ceph文件系统存储元数据（也就是说，Ceph块设备和Ceph 对象存储不使用MDS）
   在这个上下文中，元数据指的是描述文件、文件夹和其他数据对象的信息，例如文件名、文件大小、创建日期、修改日期、所有者、权限等等。

4. **RADOS Gateway（RADOS网关节点）**它们提供了对象存储接口，允许外部应用程序通过标准的对象存储协议（如S3、Swift）来访问Ceph中的对象数据

ceph第二次学习 2024-4-18

1 EB 等于 1 百万 TB，或者说是 1 亿 GB
minio是PB 级别的。1EB=1000PB=1 百万 TB

1、github上有ceph源码。需要会c和C++

1）初级二次开发，就是换logo
2）性能提升，还有有的硬件不识别，装些驱动
3）开发新功能

2、ceph设计思想

无单点故障
自动把坏的硬件踢出去，在新的硬件上重新平衡

3、

稳定版是x.2.z
候选版是x.1.z
开发版是x.0.z
这个z代表更新了多少次 15.2.16代表15代 稳定版，更新了16次

4、pool

ceph布置好后，我们需要先创建存储池，才能向ceph写入数据。文件保存在某个pool对应的 PG,再通过PG 保存在OSD上。osd一主两从。先往主写，同时往从复制，从完事告诉主，主再告诉客户端
不同的业务放到不同的pool
10g的数据，存到pool里，如果有两个pg，那么每个就存5g。一个pg对应三个盘，才实现高可用。pg越多，那么恢复数据的速度就越快，因为恢复5g和恢复5M肯定5M快

5、ceph的存储节点

存储空间，IO和网络都会比较高
每台主机上的osd是你做完raid之后显示的盘数

6、mon mgr

1. ceph集群至少有一个mon, 必须是奇数个
   mon 监视PG和 OSD 等各种映射 ，比如 ceph 集群中有多少 pool,每个pool有多少PG。monitor map,mgr map,OSD map, MDS map,CRUSH map.
   比如：在ceph中创建pool, 由 mon来提供OSD 等这些数据。OSD坏了，谁来负责更新OSD数据呢？由mon来。OSD坏了，mon就把它踢出去，别人不会在和这个坏的OSD关联
   想挂载ceph需要认证，这个key的认证就由mon来管
   2）mgr负责跟踪磁盘利用率，系统负载和性能指标等
   mgr就是个插件，里面有python 模块。Ceph仪表盘和普罗米修斯

7、CephFS就必须安装MDS（存储元数据）

8、OSD

osd不但向mon汇报自己，还汇报其他osd的状态。至少需要三个osd才能冗余和高可用
pg默认算法是往不同主机的osd分
如果主 osd 坏了，它会从两个从osd中选择数据比较新的作为新的主
如果新添加osd，是全量复制，消耗大量的磁盘 IO和网络IO

9、存储空间

如果你是三副本的存储方式，三块盘加起来1TB，实际除以3=330G的存储空间。ceph默认你存到90%，它就不让你写了

10、流程

file如何变成了pg，又如何从pg存到了osd

在Ceph分布式存储系统中，当一个客户端想要存储一个文件时，该文件不会直接存储到某个特定的OSD（对象存储设备）上，而是经历一系列的抽象和分发过程。以下是文件变成PG（ Placement Group），然后从PG存放到OSD的具体步骤：

1. 文件分割成Objects：

   • 客户端上传的文件首先会被Ceph的Rados Gateway或者CephFS等接口接收。
   • 文件经过Ceph的条带化处理（如果启用的话），被分割成多个固定大小的数据块，这些数据块在Ceph中被称为Objects。

2. Object到PG的映射：一致性算法的意思就是在不同的机器上算出来后都是到在同一个pg里面。这样就不会乱。

在Ceph分布式存储系统中，文件被分割成若干个对象（Objects），每个对象都有一个唯一的标识符，即OID（Object ID）。当文件被切分成多个对象存储时，为了决定每个对象应该存储在哪个Placement Group（PG）中，Ceph使用了一种叫做Consistent Hashing with Binning（有时也被称为CRUSH算法）的方法来进行数据分布。

在CRUSH算法中，对每个OID进行哈希运算，然后将哈希值与一个预设的掩码（mask）进行按位与操作（&）。这里的掩码实际上是PGID（Placement Group ID）的有效位数，它代表了PG的数量上限。通过这种方式，不同的OID经过哈希和按位与操作后，可以均匀分布到有限数量的PG中。

举例来说，假设有2^{10个PG（即1024个PG），那么mask可能是2}10-1，即0xFFFFF（假设掩码长度足够长）。当对某个OID进行哈希后，其哈希值是一个很大的整数，通过按位与操作，只会保留最右边的10位，而这10位的结果就映射到了0到1023之间的某个PGID。

• 对于每一个Object，Ceph会使用一个哈希函数对其进行计算，生成一个唯一的Object ID。
• 这个Object ID随后用于确定其应该归属哪一个PG。PG是Ceph中的一种逻辑容器，用于管理一组相关的Objects，确保它们的副本集在集群中的分布。

3. CRUSH算法：动态管理pg和osd之间的关系
   • 根据PG ID以及Ceph集群的CRUSH规则，CRUSH算法被用来决定这个PG应当分布在哪些OSDs上。
   • CRUSH算法考虑了集群的物理拓扑结构、权重、故障域等因素，以达到最优的分布策略和冗余度。
   • 同一个PG的所有Objects将会被复制并分别存储到它所映射到的多个OSD上，比如如果副本数设置为3，则每个Object会有3份拷贝分散在不同OSD上。

以上这两步都是“实时计算”的方式完成，做到了去中心化。这种实时计算就是用的CRUSH算法，来维护pg到osd的动态映射关系
4. OSD上的存储：

• 最终，每个Object的副本会被实际写入到相应的OSD节点上。
• OSD是Ceph中负责实际存储和管理数据的基本单元，每个OSD运行着一个服务进程，负责在其管理的磁盘空间上执行读写操作。

举个例子：
假设您有一个文件example.txt，上传到Ceph集群中的名为mydata的Pool中，该Pool的副本数设置为3。

1. example.txt被分割成多个Objects。
2. 每个Object通过哈希函数映射到一个PG，例如pg_123。
3. CRUSH算法根据集群配置及pg_123计算后，可能决定将此PG的副本放在OSD 1、OSD 5和OSD 8上。
4. Object数据被分别写入OSD 1、OSD 5和OSD 8，这样就实现了数据的冗余存储和高可用性。

整个过程保证了即使部分硬件发生故障，也能通过其他OSD上的副本恢复数据，从而维持数据的完整性和可靠性。

反过来

读取存储在Ceph分布式存储系统中的文件时，也遵循类似的逻辑流程，但方向相反。以下是客户端请求读取文件时Ceph如何定位并从OSD检索数据的步骤：

1. 客户端请求：

   • 客户端通过Ceph提供的接口（如CephFS挂载点、RBD映像或S3兼容接口）发起读取文件的请求。
   • 客户端通常不需要知道文件是如何具体分布在各个OSD上的，Ceph会处理底层的寻址和数据重组工作。

2. 元数据查询：

   • 如果文件存储在CephFS中，客户端会先向元数据服务器（MDs）发送请求，获取文件的元数据信息，其中包括文件所在的inode号及其对应的文件布局信息，即哪些Object构成了该文件。
   • 如果文件是通过RBD映像存储的，则客户端可以直接通过RBD客户端库获取映像的元数据和数据块分布信息。

3. Object定位：

   • 根据文件的元数据信息，客户端能够得知组成文件的各个Object的ID。
   • 对于每个Object，客户端或Ceph服务层会使用与写入时相同的机制计算出该Object所属的PG。
   • 之后，通过查询Monitor节点（MONs），可以了解到当前最新的PG到OSD映射关系。

4. 数据读取：

   • Ceph会选择合适的OSD（通常是主副本或最近的副本），向该OSD发出读取Object的请求。
   • OSD接收到请求后，在本地存储中找到对应Object的数据并将其返回给客户端或Ceph服务层。

5. 数据重组：

   • 如果文件在写入时进行了条带化，那么客户端或Ceph服务层接收到所有相关Objects的数据后，需要按照原文件的布局信息重新组装这些数据块，还原成原始文件的内容。
   • 对于CephFS用户来说，这一过程对他们是透明的，最终得到的是完整的文件内容。

举例说明：
假设您要从CephFS挂载点读取之前上传的example.txt文件。

1. 客户端通过文件系统的标准API尝试打开并读取example.txt。
2. CephFS客户端通过元数据服务器查询到example.txt的布局信息，得知文件由多个Object组成，比如obj_a、obj_b和obj_c。
3. 客户端通过MON节点得知这些Object分别存储在OSD 1、OSD 5和OSD 8上。
4. 客户端向OSD 1、OSD 5和OSD 8发起读取请求（如果只是读取部分内容，可能只需要部分Object）。
5. OSDs响应请求，将Object数据返回给客户端。
6. CephFS客户端将从各OSD获取的数据重新组合成原始文件内容，最后呈现给应用程序进行读取操作。

11、Ceph元数据保存方式：大小权限日期等

bluestore

Bluestore 优化对SSD和NVMe等高速存储介质的使用，不像FileStore那样依赖于像EXT4、XFS这样的 POSIX 兼容文件系统，Bluestore直接管理裸磁盘设备，缩短IO路径，降低了文件系统层面的开销
ceph实用 bluestore 存储对象数据的元数据信息
在使用Bluestore的Ceph集群中，当一个客户端向Ceph集群写入一个对象（例如，一个虚拟机的磁盘镜像）时，该对象会被分割成多个数据块，并由Bluestore直接在裸磁盘上找到合适的位置进行持久化存储。与此同时，对象的元数据，如块的位置、大小等信息，则被记录在RocksDB数据库中。

omap

在Ceph分布式存储系统中，omap全称为Object Map，它是Ceph对象存储层中一种键值对形式的附加元数据存储机制。当存储在Ceph中的对象（object）除了需要存储数据本身（data）外，还需要额外的元数据时，可以使用omap来保存这些信息。

Omap允许用户或者应用程序关联额外的任意键值对（key-value pairs）到特定的对象上，这样可以在不改变原始对象数据的情况下，为对象添加额外的描述信息或控制参数。这些键值对可以直接与对象存储在一起，无需单独的元数据存储服务，这对于许多应用场景来说是非常方便且高效的。

例如，在Ceph RBD（RADOS Block Device）组件中，omap被用于存储卷（volume）的快照信息、克隆链信息以及其他与块设备相关的元数据。当创建一个RBD快照时，Ceph会把快照的相关元数据存储在相应的RBD图像对象的omap中，而不是直接在对象数据区域增加新的内容。

另一个例子是在Ceph RGW（ RADOS Gateway）对象存储网关中，omap可以用来存储对象的元数据属性，比如HTTP头部信息、访问控制列表（ACL）、对象版本历史等。

总结起来，omap在Ceph中扮演了扩展对象功能的重要角色，允许存储更复杂的应用场景所需的元数据，增强了Ceph存储系统的灵活性和功能性。

两者关系

假设我们在 Ceph 集群中存储一个对象 image.jpg，除了该图片本身的二进制数据，我们还想关联一些额外的元数据，比如图片的拍摄日期、版权信息、访问计数等。在 Bluestore 中，我们可以把这些附加信息存储在 image.jpg 对象的 omap 中：

• key1: “date_taken”, value: “2023-04-20”
• key2: “copyright”, value: “Copyright © Example Inc.”
• key3: “access_count”, value: “100”

当 Ceph 需要查找或修改这些附加信息时，它会通过 Bluestore 访问底层 RocksDB，检索和操作与 image.jpg 关联的 omap 数据。这样，即便对象数据本身很大，也不影响快速高效地查询和更新相关元数据。

三、安装ceph集群

下面的随便看看，还是按照官网 cephadm部署吧

性能规划，硬件规划，要在安装前规划好，后来再换就不行了。千兆变万兆，机械换固态就不好换了
centos7就是13，14版本的才行




NVME 放元数据，几T的数据，元数据也就几个g
HDD 放gitlab备份呀，mysql备份等
SSD 经常有人访问的静态文件和视频图片文件

NVMe 提供了比传统的 SSD（Solid-State Drive，固态硬盘）更高的性能和低延迟
Ceph 存储系统的性能和响应速度主要受到元数据的读取和写入速度的影响。而对于大量小文件的处理，元数据的访问频率通常比数据的访问频率更高，因为每个文件都需要元数据来描述其属性和位置。

所有盘都是同厂商，同规格，同大小的盘

客户端被攻击的时候，或者负载越来越高的时候，不会影响ceph内部网络，否则ceph就挂了

几台服务器配置不同的主机名和时间同步

ceph-deploy 装在部署节点 暂停，因为环境不具备

OSD

1 移除OSD

要记录每台机器都有哪些osd，编号是多少。这样哪块盘坏了一查就知道 ceph osd tree

osd先建立项目，也就是pool

2 RBD

rbd里面创建某个大小的img，然后才能挂载
另一台linux设备先装ceph-common，可以远程挂载ceph集群的块设备的img。就像真的挂了一块盘一样。就类似云盘

3 RGW

不用挂载和格式化，自动创建存储池。当用户想取文件的时候，通过RGW网关–>bucket(存储文件名)–> 存储池–>从osd里把文件取出来给用户

4 cephFS 多个主机共享同一份数据，效果和NFS一样

必须部署 ceph-mds 服务
cephfs有两个存储池，一个存储元数据，一个存储数据
最后数据还是放到osd上




ip是mon的ip。cat ceph.client.admin.keyring就能看到key

四 ceph集群维护

如果突然停电，把osd踢出去，再加进来就会很麻烦



删除服务器一般都是过保了，我们想换一下服务器
在流量低峰期做，一块一块的osd更换，都踢出去之后，再把osd.x进程停掉




空间有限，但是你还想要可能的最大的空间（和raid很接近了），就用纠删码池，实际生产环境中很少用纠删码池，安全性低，性能差

在osd上面是交叉存储的，上图是3+2.最多坏两块盘后，数据就找不回来了。

Ceph纠删码（Erasure Coding，EC）是一种先进的数据保护技术，它通过将原始数据分割成多个数据块，并计算出额外的校验块，从而能够在一定数量的数据块丢失的情况下，仍能恢复原始数据。相比于传统的复制方式，纠删码可以在提供相同级别的数据保护的同时，减少存储开销。

原理简述

假设我们有一个原始数据集，我们将这个数据集分为k个数据块（data chunks），同时通过一种称为编码矩阵的数学运算产生m个校验块（coding chunks）。于是，总共有 n = k + m 个块存储在不同的OSD（Object Storage Devices）上。只要不超过m个块发生故障或丢失，就可以通过剩下的k个数据块和部分校验块还原原始数据。

具体例子

举个简单的例子来直观地理解纠删码的工作原理：

假设我们有一个4+2模式的纠删码（k=4, m=2），这意味着原始数据被分割为4个数据块A、B、C、D，然后通过编码算法生成2个校验块E和F。

1. 编码过程：

   • 原始数据：ABCDEF…（假设是一串很长的数据）
   • 分割后的数据块：A, B, C, D
   • 计算校验块：通过某种线性运算（如Reed-Solomon编码）基于A、B、C、D生成E和F。

2. 存储过程：

   • 这6个块（A, B, C, D, E, F）分别存储在不同的OSD上。

3. 故障恢复过程：

   • 假设OSD1上的A和OSD2上的B同时发生故障。
   • 由于只有2个数据块丢失（小于m=2的最大容忍度），我们可以使用剩下的C、D、E和F四个块通过解码算法恢复丢失的数据A和B。

纠删码的优势在于它提高了存储效率，因为存储了更多的校验块而不是完整的数据副本，从而允许在更少的物理存储空间上实现相同的数据持久性和可靠性。在大规模分布式存储系统如Ceph中，纠删码技术尤其重要，因为它有助于降低存储成本并提高系统容错能力。不过，纠删码也有潜在的计算成本，即编码和解码过程可能会比单纯的数据复制更耗时。在实践中，Ceph会利用高效的硬件加速和优化算法来减轻这一负担。

PG 与 PGP

假设我们有一个Ceph集群，包含4个OSD节点（OSD1、OSD2、OSD3和OSD4），每个节点上有相同数量的硬盘用于存储数据。为了简化问题，我们假设每个OSD节点上有4个硬盘。

现在，我们要将一个对象存储到Ceph集群中。首先，Ceph会根据配置策略将这个对象映射到一个特定的PG。假设我们使用散列算法，根据对象的唯一标识符计算出PG的编号。

例如，假设这个对象的唯一标识符为ABC123，通过散列算法计算得到的PG编号为PG5。那么，这个对象就会被映射到PG5。

接下来，Ceph会根据PGP（PG Placement）来确定PG在集群中的物理位置。PGP是一个指示器，它告诉Ceph将PG放置在哪个OSD节点上。

在我们的例子中，假设PG5的PGP编号为PGP2。这意味着PG5应该被放置在OSD2节点上。

因此，对象ABC123将被存储在OSD2节点上的硬盘上。

当需要读取对象ABC123时，Ceph会根据对象的唯一标识符计算出PG编号为PG5，并查找PGP2来确定它位于OSD2节点。然后，Ceph会从OSD2节点上的硬盘中读取对象数据并返回给请求方。

这就是PG和PGP的工作原理。PG将数据逻辑上划分为小的分片，并提供冗余和容错能力。PGP确定了PG在集群中的物理位置，以实现数据的均衡分布和高效访问。通过这种方式，Ceph能够实现可扩展性、高可用性和高性能的分布式存储系统。

pg的数量是2的N 次方的倍数，每个OSD的PG不要超出250个PG,官方是每个OSD 100个左右

pg数量可以动态的更改

在Ceph中，PG（Placement Group）有几种常见的状态，用于表示PG的当前状态和活动。以下是一些常见的PG状态：

1. Active (活跃状态): PG处于活跃状态时，它可以接收读取和写入请求，并参与数据的传输和复制。

2. Clean (清洁状态): 清洁状态表示PG没有任何数据丢失或不一致。所有的数据副本都是完整的，没有发生故障或恢复操作。

3. Degraded (降级状态): 降级状态意味着PG的某些数据副本丢失或不可访问。这可能是由于OSD节点故障、网络问题或其他原因导致的。

4. Inconsistent (不一致状态): 不一致状态表示PG的副本之间存在数据不一致。可能是由于某个副本的写操作失败或未完成导致的。

5. Scrubbing (检查状态): 检查状态表示PG正在进行数据校验和修复。通过对PG中的对象进行校验，Ceph可以检测和纠正潜在的数据错误和损坏。

6. Backfilling (补偿状态): 补偿状态表示PG正在进行数据重平衡，将数据从一个OSD迁移到另一个OSD上。通常在添加新的OSD节点或替换故障节点时会出现此状态。全量同步

7. Recovering (恢复状态): 恢复状态表示PG正在进行数据恢复，将丢失或不可访问的数据副本重新复制到其他可用的OSD上。

8. undersized ceph最少要求一主一备，不符合pg就变为 undersized状态。直到添加了OSD。只剩一个osd的话，ceph会夯住，就是禁止读写。ceph可以把minsize改成1,这样就能读写了。就能把数据备份出去了

9. 

在Ceph中，PG（Placement Group）的活动集和上行集是用于管理PG状态和数据传输的概念。

1. 活动集（Active Set）：活动集是指当前处于活跃状态的PG集合。只有活动集中的PG才能接收读取和写入请求，并参与数据的传输和复制。活动集可以根据需要进行调整，以适应不同的负载和性能需求。通常情况下，活动集的大小是动态变化的，取决于集群配置和工作负载。

举个例子来说明，假设一个Ceph集群有10个PG，其中有6个PG处于活动状态。这6个PG就构成了当前的活动集。只有属于活动集的PG才会参与读写操作和数据传输，其他4个PG则处于非活跃状态。

2. 上行集（Up Set）：上行集是指某个PG在特定时间点被映射到的OSD节点集合。它定义了PG在集群中的物理位置，并用于数据的读取和写入操作。上行集中的OSD节点负责处理该PG的数据请求和数据传输。

举个例子来说明，假设有一个PG被映射到包含3个OSD节点的上行集。当有读写请求到达该PG时，Ceph会将请求发送给上行集中的任一节点来处理。这些节点负责检索和存储PG的数据，并进行数据传输。

通过活动集和上行集的概念，Ceph能够管理PG的状态和数据传输。活动集确定了当前处于活跃状态的PG集合，它们能够接收请求并参与数据操作。而上行集定义了PG的物理位置，指示了哪些OSD节点负责处理该PG的数据请求。

存储池操作 （快照，压缩什么的不重要）

快照一般用于云存储，读存储池中的数据进行备份与还原，创建快照占用磁盘比较大，你本来是三副本了，还创建快照干嘛
压缩开启后，cpu占用率高居不下，影响性能
1、存储池删了，里面的数据就真丢了





最次也得是ssd，要不扫描的时候不行。到时你的一世英名就没了，其实是硬件不行

十 常用命令

ceph osd lspools