Ceph 基本架构（一）

Ceph架构图 

Ceph整体组成 

Ceph 是一个开源的分布式存储系统，设计用于提供优秀的性能、可靠性和可扩展性。Ceph 的架构主要由几个核心组件构成，每个组件都有特定的功能，共同协作以实现高可用性和数据的一致性。

以下是 Ceph 的整体架构及其各个组件的作用：

1. Ceph 存储集群 (Ceph Storage Cluster)

Ceph 存储集群是整个系统的核心，负责存储和检索数据。它由以下几种类型的节点组成：

• OSD (Object Storage Device): 负责存储数据的对象，每个 OSD 实际上是一个进程，通常运行在一个物理硬盘上。OSD 处理数据的读写请求，并参与数据的复制、恢复、再平衡等过程。
• Monitor (MON): 监控节点，负责维护 Ceph 集群的健康状态和元数据信息，包括但不限于监视器图（Monitor Map）、OSD图（OSD Map）、PG图（PG Map）和CRUSH图。Mon节点还负责维护集群成员关系、处理客户端请求的身份验证等。Mon节点不直接参与数据存储或PG的具体维护工作，但它们对于确保集群的健康状态和一致性至关重要。MON 节点必须是奇数个，以避免“裂脑”现象（即在集群分裂时无法达成多数派共识）。
• Manager (MGR): 管理节点，负责收集各种监控数据和性能指标，提供给管理员和用户界面。MGR 还可以运行插件来扩展其功能。

2. Ceph 客户端 (Ceph Clients)

Ceph 客户端通过不同的接口与存储集群交互，主要包括：

• RADOS Gateway (RGW): 提供 S3 和 Swift 兼容的对象存储接口，使 Ceph 可以作为云存储解决方案。
• CephFS: 分布式文件系统，允许通过标准文件系统接口访问 Ceph 集群。
• RBD (RADOS Block Device): 块设备接口，可以将 Ceph 集群中的对象存储呈现为块设备，常用于虚拟机的磁盘镜像。
• Librados: 一个库，直接与 RADOS 层通信，开发者可以使用 Librados 构建自定义的应用程序。

3. 数据放置策略 (CRUSH Algorithm)

• CRUSH (Controlled Replication Under Scalable Hashing): 是 Ceph 使用的一种智能算法，用于确定数据应该存储在哪里。CRUSH 根据预定义的规则（如数据中心布局、服务器分布等）决定数据的副本位置，从而实现数据的均匀分布和高效的故障恢复。

4. 其他辅助组件

• Metadata Server (MDS): 在 CephFS 中使用，负责管理文件系统的元数据，如目录结构和文件属性。MDS 节点确保文件系统的高效运行和数据一致性。根据文件系统的规模和性能需求，可以部署一个或多个 MDS 节点。多个 MDS 节点可以提高元数据处理的性能和可靠性。
• iSCSI Gateway: 提供 iSCSI 接口，使得 Ceph 可以作为传统的 SAN 存储使用。

OSD存储释意

OSD（Object Storage Device）是 Ceph 分布式存储系统中的一个重要组件，负责实际的数据存储和管理。理解 OSD 的作用和工作机制对于了解 Ceph 的整体架构和性能至关重要。以下是关于 OSD 的详细解释：

1. 基本概念

OSD：全称为 Object Storage Device，是 Ceph 中的基本存储单元。每个 OSD 实际上是一个运行在物理硬盘上的进程，负责存储和管理数据对象。
对象：Ceph 中的数据以对象的形式存储。每个对象包含数据和元数据，元数据包括对象的 ID、大小、版本号等信息。

2. 主要职责：

数据存储：OSD 负责将数据对象存储在物理硬盘上，并确保数据的持久性和完整性。
数据读写：处理客户端的读写请求，将数据写入硬盘或将数据从硬盘读出。
数据复制：根据 Ceph 的配置，OSD 会将数据对象复制到其他 OSD 上，以确保数据的高可用性和容错性。
数据恢复：当某个 OSD 失效时，其他 OSD 会自动进行数据恢复，将缺失的数据副本重新创建。
数据再平衡：当新的 OSD 加入集群或现有 OSD 离开集群时，OSD 会自动进行数据的再平衡，确保数据在集群中的均匀分布。

3. 工作流程：

接收请求：OSD 从客户端或其他 Ceph 组件（如 MDS、RGW）接收数据读写请求。
数据处理：根据请求类型，OSD 执行相应的操作，如将数据写入硬盘或从硬盘读取数据。
数据复制：根据 CRUSH 算法，OSD 将数据对象复制到其他指定的 OSD 上，确保数据的冗余。
心跳检测：OSD 与其他 OSD 和 MON 节点定期进行心跳检测，以确保集群的健康状态。
故障检测与恢复：当某个 OSD 失效时，其他 OSD 会检测到这一情况，并启动数据恢复过程，将缺失的数据副本重新创建。
数据再平衡：当集群结构发生变化（如新增或移除 OSD）时，OSD 会自动进行数据的再平衡，确保数据在集群中的均匀分布。

4. 配置与管理

配置文件：OSD 的配置信息通常保存在 Ceph 配置文件中，包括存储路径、网络配置、日志级别等。
启动与停止：OSD 进程可以通过命令行工具（如 ceph-osd）进行启动和停止。
监控与日志：OSD 会生成详细的日志信息，帮助管理员监控和调试集群状态。

5. 性能优化

缓存机制：OSD 可以利用内存缓存来加速数据读写操作，提高性能。
并行处理：OSD 支持并行处理多个请求，充分利用多核 CPU 的性能。
I/O 调度：OSD 可以配置不同的 I/O 调度策略，以优化磁盘的读写性能。

总结

OSD 是 Ceph 分布式存储系统中负责实际数据存储和管理的核心组件。通过数据复制、故障检测与恢复、数据再平衡等机制，OSD 确保了数据的高可用性和一致性。理解 OSD 的工作原理有助于更好地管理和优化 Ceph 集群的性能。

CRUSH 算法解释

CRUSH（Controlled Replication Under Scalable Hashing）算法是 Ceph 分布式存储系统中一个非常重要的组件，用于决定数据对象在集群中的存储位置。CRUSH 算法的设计目标是实现数据的均匀分布、高效的数据访问和高可用性。下面是 CRUSH 算法的详细解释：

1. 基本概念

• 数据对象：Ceph 中的数据以对象的形式存储，每个对象包含数据和元数据。
• 存储设备（OSD）：Ceph 中的实际存储单元，每个 OSD 负责存储和管理数据对象。
• 存储桶（Bucket）：CRUSH 算法中的一种逻辑容器，用于组织和分组存储设备（OSD）。
• 权重：每个 OSD 和存储桶都有一个权重值，表示其存储容量或重要性。权重值影响数据对象的分配。

2. CRUSH 算法的主要特点

• 无中心化：CRUSH 算法不需要中心化的管理节点，每个节点都可以独立计算数据对象的存储位置。
• 可扩展性：CRUSH 算法支持动态添加或删除存储设备，而不会导致大量数据迁移。
• 故障容忍：CRUSH 算法考虑了故障容忍性，确保数据的多个副本分布在不同的故障域中，提高数据的可靠性。

3. CRUSH 算法的工作原理

3.1 映射层次结构

CRUSH 算法使用一个层次化的映射结构，将数据对象映射到具体的存储设备（OSD）。这个层次结构通常包括以下几层：

• 根节点（Root）：最顶层的节点，代表整个存储集群。
• 故障域（Failure Domain）：通常对应于数据中心、机架或主机等物理位置，用于确保数据副本的分散。
• 存储桶（Bucket）：逻辑容器，用于组织和分组存储设备（OSD）。
• 存储设备（OSD）：实际的存储单元，负责存储数据对象。

3.2 权重分配

每个 OSD 和存储桶都有一个权重值，表示其存储容量或重要性。权重值决定了数据对象在选择存储位置时的偏好。例如，一个权重较高的 OSD 更有可能被选中存储数据对象。

3.3 哈希函数

CRUSH 算法使用哈希函数将数据对象的 ID 映射到一个数值，然后根据这个数值和层次结构中的权重值，计算出数据对象应该存储的具体位置。

3.4 选择存储位置

CRUSH 算法通过以下步骤选择数据对象的存储位置：

1. 计算哈希值：使用哈希函数将数据对象的 ID 转换为一个数值。
2. 选择根节点：从根节点开始，根据哈希值和权重值，选择一个子节点。
3. 递归选择：在选定的子节点中，继续根据哈希值和权重值选择下一个子节点，直到达到存储设备（OSD）。
4. 数据复制：根据配置的复制因子，选择多个存储设备（OSD）来存储数据对象的副本。

4. 故障容忍

CRUSH 算法通过以下机制确保数据的高可用性：

• 故障域分离：数据的多个副本会被分散到不同的故障域中，确保即使某个故障域发生故障，数据仍然可用。
• 动态调整：当存储设备（OSD）或存储桶发生变化时，CRUSH 算法会自动调整数据的分布，确保数据的均匀分布和高可用性。

5. 示例

假设我们有一个 Ceph 集群，包含两个机架（rack1 和 rack2），每个机架中有两个主机（host1 和 host2），每个主机上有两个 OSD（osd1 和 osd2）。CRUSH 算法可能会构建如下层次结构：

root (cluster)
├── rack1
│   ├── host1
│   │   ├── osd1
│   │   └── osd2
│   └── host2
│       ├── osd1
│       └── osd2
└── rack2├── host1│   ├── osd1│   └── osd2└── host2├── osd1└── osd2

当需要存储一个新的数据对象时，CRUSH 算法会从根节点开始，根据哈希值和权重值，逐步选择子节点，最终确定数据对象的存储位置。例如，数据对象可能会被存储在 rack1 的 host1 的 osd1 上，同时其副本可能会被存储在 rack2 的 host2 的 osd2 上，以实现故障域分离。 

简化的 Ceph OSD (Object Storage Device) 集群的数据存储过程：

1. 客户端请求

• 客户端应用程序需要存储一个数据对象（例如，文件或块）。
• 客户端通过网络连接到 Ceph 集群，通常是通过 Ceph 的 RADOS (Reliable Autonomic Distributed Object Store) 接口。

2. 获取集群地图

• 客户端联系 Ceph Monitor 节点，获取最新的集群地图（Cluster Map）。集群地图包含了当前集群的拓扑结构、OSD 状态、PG 分配等信息。

3. 计算放置组 (PG)

• 客户端根据数据对象的标识符（通常是对象ID）和集群地图中的 PG 映射表，计算出该对象所属的 PG。每个 PG 都映射到一组特定的 OSD，这组 OSD 负责存储该 PG 内的所有数据对象及其副本。

4. 确定主OSD

• 根据 PG 映射表，客户端确定该 PG 的主OSD。主OSD 负责协调该 PG 内的数据写入操作。

5. 发送写入请求

• 客户端将写入请求发送给主OSD，请求中包含要存储的数据对象。

6. 主OSD 处理请求

• 主OSD 接收到写入请求后，将数据写入自己的本地存储中，并记录这次写入操作。

7. 同步副本

• 主OSD 将写入请求转发给该 PG 对应的其他副本OSD。
• 副本OSD 也执行相同的写入操作，将数据存储在各自的本地存储中。

8. 确认响应

• 当所有副本OSD 成功完成数据写入操作后，它们会向主OSD 发送确认消息。
• 主OSD 收集到所有副本OSD 的确认后，向客户端发送写入成功的响应。

9. 数据一致性

在整个过程中，Ceph 使用多种机制来保证数据的一致性和可靠性，例如：

• 心跳检测：定期检查 OSD 的状态，确保它们正常运行。
• 数据校验：定期进行数据校验和修复，确保数据的完整性。
• 故障恢复：如果某个 OSD 失效，Ceph 会自动将数据重新分配到其他可用的 OSD 上，以保持数据的冗余度。

MON监控节点释意

在 Ceph 中，Monitor (MON) 节点确实负责维护集群的状态和元数据信息，但是它们的工作方式并不涉及传统意义上的“主从”选举。相反，Ceph MON 节点采用了一种无中心化的共识机制来确保集群的一致性和高可用性。以下是关于 MON 节点的一些关键点：

1. 无中心化共识

Paxos 或 Raft 协议：Ceph MON 节点使用 Paxos 或 Raft 这样的共识协议来达成一致。这些协议确保了在大多数节点同意的情况下，集群的状态和元数据信息是准确和一致的。
多数派原则：为了防止“裂脑”现象（即在集群分裂时无法达成多数派共识），Ceph 要求 MON 节点的数量必须是奇数个（通常是 3 个或 5 个）。这样，在某个 MON 节点失效时，剩余的节点仍然可以形成多数派，继续维持集群的正常运行。

2. 故障检测与恢复

故障检测：MON 节点之间定期进行心跳检查，以检测其他节点的健康状态。如果某个 MON 节点失效，其他节点会检测到这一点。
自动恢复：当某个 MON 节点失效后，剩余的 MON 节点会继续工作，并尝试重新建立集群的共识。一旦失效的 MON 节点恢复，它会从其他健康的 MON 节点同步最新的状态信息，重新加入集群。

3. 集群状态的维护

集群地图：MON 节点维护着集群的地图（Cluster Map），其中包括 OSD 地图、MON 地图、MDS 地图等。这些地图描述了集群中各个组件的状态和位置。
一致性更新：当集群状态发生变化（如新的 OSD 加入或某个 OSD 失效）时，MON 节点会更新集群地图，并将这些变化传播到所有相关的组件。

4. 选举机制

无明确的主节点：Ceph MON 节点没有明确的主节点概念。所有的 MON 节点都是平等的，共同维护集群的状态。
领导节点：虽然没有主节点，但在某些情况下，MON 节点会选举一个“领导者”（Leader）来协调某些操作。例如，在更新集群地图时，需要一个领导者来确保更新的一致性。但是，这个领导者并不是固定的，而是动态选举的。

总结

Ceph 的 MON 节点通过无中心化的共识机制来确保集群的一致性和高可用性。当某个 MON 节点失效时，剩余的 MON 节点会继续工作，并在必要时重新选举一个领导者来协调特定的操作。这种设计使得 Ceph 能够在单点故障的情况下继续保持正常运行，提高了系统的可靠性和稳定性。

MGR管理节点释意

Ceph 是一个开源的分布式存储系统，设计用于提供优秀的性能、可靠性和可扩展性。Ceph 能够提供对象存储、块存储以及文件系统接口，适用于各种存储需求。在 Ceph 集群中，Manager (MGR) 节点扮演着重要的角色，负责管理和监控集群的状态，并为用户提供有关集群健康状况和性能的信息。

MGR 节点的主要职责包括：

1. 监控和报告：MGR 节点持续收集关于 Ceph 集群各个方面的数据，如存储利用率、网络状态、性能指标等。这些信息可以通过 Ceph 的仪表板（Dashboard）或其他监控工具展示给用户。

2. 提供服务：除了基本的监控功能外，MGR 模块还可以提供额外的服务，比如：

• 仪表板：允许管理员通过 Web 界面查看集群状态、配置设置等。
• 性能分析：帮助识别集群中的瓶颈或性能问题。
• 自动恢复：某些情况下，MGR 可以自动采取措施来恢复集群到健康状态。

3. 模块化设计：Ceph MGR 是高度模块化的，支持多种插件。这意味着可以根据需要启用不同的功能模块，以适应特定的应用场景或提高管理效率。

4. 高可用性：为了确保系统的稳定运行，通常会部署多个 MGR 节点。这些节点之间会进行选举，选出一个主 MGR 节点来执行任务。如果主节点失败，其他备用节点可以迅速接管其职责，保证服务的连续性。

5. 配置管理：MGR 还可以用来简化集群的配置管理工作，例如动态调整配置参数而无需重启整个集群。

        总之，Ceph 中的 MGR 管理节点是实现高效、可靠集群管理的关键组件之一。它不仅提供了丰富的监控和诊断工具，还支持灵活的服务扩展能力，有助于维护大型分布式存储系统的正常运作。

        在 Ceph 集群中，MGR（Manager）节点的数量并不强制要求是奇数个，主要是因为 MGR 节点的设计与 Monitor（MON）节点有所不同。MON 节点负责维护集群的逻辑时钟和状态图，因此它们需要形成一个法定多数（quorum）来防止“脑裂”现象——即集群分裂成两个或多个独立运作的部分，每个部分都认为自己是合法的主集群。为了避免这种情况，MON 节点通常建议部署为奇数个（如3个或5个），这样更容易达成多数共识。

        相比之下，MGR 节点的主要职责是提供管理和监控服务，而不是直接参与集群状态的决策过程。MGR 节点之间采用了一种领导者选举机制，即任何时候只有一个主 MGR 节点在工作，其余的作为备用。如果主 MGR 节点发生故障，集群中的其他 MGR 节点将自动选举出新的主节点继续提供服务。这种设计减少了对节点数量为奇数的需求，因为即使只有两个 MGR 节点，也能实现高可用性。

        然而，虽然理论上两个 MGR 节点就足够了，但在实际部署中，通常还是会配置三个或更多 MGR 节点，以增加系统的容错能力和稳定性。这样做可以在一个或多个节点出现故障时，仍然保持足够的冗余度和服务连续性。因此，虽然不是必须的，但在生产环境中推荐使用至少三个 MGR 节点来增强集群的可靠性。

Ceph基本查询命令

Ceph OSD 操作命令总结

常用标志

• noin: 阻止新的 OSD 加入集群。
• noup: 阻止 OSD 状态从 down 到 up。
• norecover: 阻止数据恢复操作。
• norebalance: 阻止数据再平衡操作。
• nobackfill: 阻止数据回填操作。
• pause: 暂停所有 OSD 操作。

Ceph OSD 流量控制命令总结

设置标志

# 阻止新 OSD 加入
ceph osd set noin# 阻止 OSD 状态变化
ceph osd set noup# 阻止数据恢复
ceph osd set norecover# 阻止数据再平衡
ceph osd set norebalance# 阻止数据回填
ceph osd set nobackfill# 暂停所有 OSD 操作
ceph osd set pause

取消标志

# 取消阻止新 OSD 加入
ceph osd unset noin# 取消阻止 OSD 状态变化
ceph osd unset noup# 取消阻止数据恢复
ceph osd unset norecover# 取消阻止数据再平衡
ceph osd unset norebalance# 取消阻止数据回填
ceph osd unset nobackfill# 取消暂停所有 OSD 操作
ceph osd unset pause

使用场景

• 维护操作：在执行维护操作（如更换磁盘、升级软件等）时，设置这些标志可以防止不必要的数据迁移和恢复操作，确保维护过程的顺利进行。
• 故障排除：在故障排除时，设置这些标志可以临时冻结集群的部分操作，以便更好地诊断问题。
• 数据迁移：在进行大规模数据迁移时，设置这些标志可以控制数据迁移的速度和时机，避免对集群性能造成过大影响。