第 15 章 使用 Ceph 配置多站点、容错消息传递系统
大规模企业消息传递系统通常具有位于地理上分布式数据中心的离散代理集群。如果数据中心停机，系统管理员可能需要保留现有的消息传递数据，并确保客户端应用程序可以继续生成和使用消息。您可以使用特定的代理拓扑和 Red Hat Ceph Storage （一个软件定义的存储平台）来确保消息传递系统在数据中心中断期间的连续性。这种类型的解决方案称为 多站点、容错架构。
如果您只需要 AMQP 协议支持，请考虑 第 16 章 使用代理连接配置多站点、容错消息传递系统。
以下小节解释了如何使用 Red Hat Ceph Storage 保护您的消息传递系统免受数据中心中断的影响：
多站点容错不是 数据中心内 高可用性(HA)代理冗余的替代。基于 live-backup 组的代理冗余提供对单个集群中单一代理故障的自动保护。相反，多站点容错可防止大规模数据中心中断。
要使用 Red Hat Ceph Storage 来确保消息传递系统的连续性，您必须将代理配置为使用共享存储高可用性(HA)策略。您无法将代理配置为使用复制 HA 策略。有关这些策略的更多信息，请参阅 实施高可用性。
15.1. Red Hat Ceph Storage 集群如何工作
Red Hat Ceph Storage 是一个集群对象存储系统。Red Hat Ceph Storage 使用对象和基于策略的复制的数据分片来确保数据完整性和系统可用性。
Red Hat Ceph Storage 使用名为 CRUSH （可扩展哈希下的受控复制）的算法来确定如何通过自动计算数据存储位置存储和检索数据。您可以配置 Ceph 项目，称为 CRUSH map，其详细说明了集群拓扑，并指定如何在存储集群之间复制数据。
CRUSH map 包含对象存储设备(OSD)列表、用于将设备聚合为故障域层次结构中的"buckets"列表，以及告知 CRUSH 如何在 Ceph 集群池中复制数据的规则。
通过反映安装的底层物理组织，CRUSH 映射可以建模，因此地址 - 关联设备故障的潜在源，如物理代理、共享电源源和共享网络。通过将此信息编码到 cluster map 中，CRUSH 可以在不同的故障域间分离对象副本（如数据中心），同时仍然在存储集群中维护伪随机数据分布。这有助于防止数据丢失并启用集群以降级状态运行。
Red Hat Ceph Storage 集群需要多个节点（物理或虚拟）才能运行。集群必须包括以下类型的节点：
监控节点
每个 monitor (MON)节点运行 monitor 守护进程(ceph-mon)，后者维护 cluster map 的主副本。集群映射包含集群拓扑。连接到 Ceph 集群的客户端从 monitor 检索 cluster map 的当前副本，这使得客户端能够从集群读取和写入数据。
Red Hat Ceph Storage 集群可以使用一个 monitor 节点运行；但是，为了确保生产集群中的高可用性，红帽仅支持具有至少三个 monitor 节点的部署。至少三个 monitor 节点意味着，当一个 monitor 失败或不可用时，集群中剩余的 monitor 节点有一个仲裁来选举新的领导。
Manager 节点
每个管理器(MGR)节点运行 Ceph 管理器守护进程(ceph-mgr)，它负责跟踪运行时指标和 Ceph 集群的当前状态，包括存储利用率、当前的性能指标和系统负载。通常，管理器节点与 monitor 节点在一起（即在同一主机上）。
对象存储设备节点
每个对象存储设备(OSD)节点运行 Ceph OSD 守护进程(ceph-osd)，它与附加到节点的逻辑卷交互。Ceph 在 OSD 节点上存储数据。Ceph 可以在非常少的 OSD 节点（默认为三个）的情况下运行，但生产集群在大规模扩展时实现更好的性能，例如存储集群中有 50 个 OSD。在存储集群中有多个 OSD 可让系统管理员在 CRUSH map 中定义隔离的故障域。
元数据服务器节点
每个元数据服务器(MDS)节点运行 MDS 守护进程(ceph-mds)，后者管理与 Ceph 文件系统(CephFS)中存储的文件相关的元数据。MDS 守护进程也协调对共享集群的访问。
其他资源
有关 Red Hat Ceph Storage 的更多信息，请参阅什么是 Red Hat Ceph Storage？
