Ceph核心组件27课件.pptxVIP

;2;OSD是Ceph集群的基石，是数据存储的最终执行者。

可以将其理解为集群中的“仓库管理员”。每个OSD进程通常独立负责服务器上的一块物理磁盘（无论是HDD、SSD还是NVMe），所有用户的真实数据，无论其原始形态是文件、块设备镜像还是S3对象，最终都会被封装成RADOS对象，存放在某个OSD所管理的磁盘上。;（1）数据存储：在本地文件系统（如XFS）上执行底层的对象数据读、写、删除操作。

（2）数据复制与冗余：OSD之间会相互协作，根据存储池设定的策略（例如3副本），自动完成数据的复制过程。

（3）健康监测与状态上报：OSD不仅管理自己的磁盘，还会“心跳检测”相邻的OSD?伙伴是否正常工作。

（4）参与自愈和再均衡：当有OSD发生故障或被添加到集群时，正是其他相关的OSD进程，根据CRUSH算法的指引，自动执行数据的迁移、恢复或重新分布任务，确保集群始终处于健康和均衡的状态。;如果说OSD是负责具体工作的“仓库管理员”，那么?Monitor（监控器）就是整个Ceph集群的“决策大脑”和“信息中心”。它并不直接参与用户数据的存储，而是维护着整个集群健康运行所需的所有关键元数据，被称为“集群地图”（ClusterMaps）。;（1）维护集群地图(ClusterMaps)：这是?Monitor最核心的职责。集群地图并非单一地图，而是一系列重要状态图的集合，主要包括：

OSDMap：记录了所有OSD的状态、集群拓扑结构（CRUSHMap）、存储池定义以及PG?与OSD的映射关系等。这是客户端能够定位到数据的关键信息。

MonitorMap：记录了所有Monitor节点自身的信息，包括它们的网络地址、当前谁是领导者（Leader）等。

PGMap：记录了所有PG的当前状态及其所在的OSD列表。

MDSMap：记录了CephFS元数据服务器（MDS）的状态。;（2）认证与授权：所有希望接入Ceph集群的客户端或组件，都必须先通过Monitor的认证。Monitor会根据其身份和预设的权限规则（CephX），授予其访问特定存储池或执行特定操作的“令牌”（Ticket），确保了集群的安全性。

（3）维护法定人数(Quorum)：Monitor自身是一个高可用的分布式系统。为了防止因网络分区等问题导致“脑裂”（即集群中出现多个决策中心，发布相互冲突的指令），Monitor集???通过Paxos算法来保证数据的一致性。;客户端启动时，第一件事就是连接到一个Monitor节点，获取最新的集群地图副本。随后，客户端便可以利用这份地图和CRUSH算法，独立计算出数据的位置并直接与OSD通信，后续的I/O过程无需再经过?Monitor。

虽然Monitor是决策中心，但它并非数据路径上的性能瓶颈。它的存在保证了集群状态的一致性和权威性，是Ceph高可靠性的重要保障。;在早期的Ceph版本中，集群的一些管理和监控任务是由Monitor承担的。但随着功能的日益复杂，为了让Monitor能更专注于维护集群状态的核心一致性，Ceph引入了?Manager（管理器）?组件，专门分担这些职责。

Manager?的定位是Ceph集群的管理和监控信息聚合点。它从整个集群收集各类详细的状态信息、性能指标和统计数据，并为外部的管理工具和监控系统提供了一个统一的接口。;（1）收集集群指标：Manager?进程会持续从所有OSD和其他组件那里收集大量的运行时信息。

（2）提供外部API和管理工具：Manager的一个关键特性是其模块化设计。它通过加载不同的插件模块，来提供丰富多样的管理功能。

（3）执行部分集群管理逻辑：一些不需要强一致性保证的管理任务也由Manager负责。;职责不同：Monitor?负责维护集群的核心状态和权威决策（强一致性），是集群的“大脑”；而Manager负责收集统计信息和提供对外管理接口（最终一致性即可），是集群的“仪表盘”和“发言人”。

高可用方式不同：Monitor采用Paxos算法，需要“法定人数”才能工作。而Manager采用的是主备（Active/Standby）模式，任何时候只有一个Manager处于Active状态对外提供服务，其他?Manager则处于待命状态。如果Active的Manager进程失效，其他?Standby的Manager会自动接替其工作。;前面我们提到，Ceph的底层核心是RADOS对象存储系统。然而，RADOS使用的是Ceph自定义的、高性能的私有协议，应用程序无法直接通过标准的HTTP协议来访问它。为了解决这个问题，Ceph?提供了?RGW(RADOSGateway)?组件。;（1）提供标准的对象存储接口：这是RGW最核心的功能。通过支持业界主流的S3和SwiftAPI，使得海量的现有应用程序、开