前言

Ceph RBD 镜像通过在集群之间复制块设备镜像来确保私有云数据安全。它是一种灾难恢复工具，可在发生故障时最大限度地减少停机时间和数据丢失。以下是其基本要点：

• 两种模式：单向（主备模式）和双向（主主模式）复制。

• 两种方法：基于日志（journal-based）的实时复制或基于快照（snapshot-based）的定期同步。

• 主要优势：减少停机时间，改善恢复时间目标（RTO）和恢复点目标（RPO）。

• 设置要点：两个健康的 Ceph 集群、可靠的高带宽网络以及正确的存储池配置。

• 最佳实践：监控复制延迟、优化性能并定期测试故障切换。

借助 Ceph RBD 镜像，可以为私有 OpenStack 云构建可靠的灾难恢复计划，并保护关键工作负载免受意外中断的影响。

Ceph RBD 镜像设置要求

集群设计和网络设置

要有效设置 Ceph RBD 镜像，至少需要两个位于不同数据中心的健康 Ceph 集群。这些数据中心应通过可靠的高带宽网络连接，以获得最佳的备份和灾难恢复保护。

网络设置在镜像操作的成功中扮演着重要角色。根据 Ceph 文档(http://docs.ceph.com/en/latest/rbd/rbd-mirroring/)说明：

“rbd-mirror 守护进程的每个实例都必须能够同时连接到本地和远程 Ceph 集群（即所有 monitor 和 OSD 主机）。此外，两个数据中心之间的网络必须有足够的带宽来处理镜像工作负载。”

带宽是一个主要因素。例如，通过 1 Gbps 链路复制 1 TB 数据大约需要三小时，而 10 Gbps 链路则将此时间缩短至仅二十分钟。为了满足集群间和客户端通信的需求，建议至少配置 10 Gbps 的连接。

两个集群在容量和性能方面也应具有相似的 CRUSH 层次结构。为保持操作顺畅，请考虑为 Ceph Monitor 和 Manager 主机使用企业级 SSD，特别是对于元数据密集型的工作负载。

延迟要求因复制策略而异。异步镜像更具容错性，可以处理更高的延迟，使其成为地理上分散部署的理想选择。但是，如果在延伸集群（stretch cluster）设置中使用同步复制，站点之间的往返时间（RTT）不得超过 10 毫秒。

一旦集群和网络准备就绪，下一步就是配置镜像所需的特定功能和存储池。

功能和存储池配置要求

优化集群和网络后，重点将转移到调整功能和存储池配置以成功实现镜像。

首先，确保两个集群上都存在同名的存储池。如果使用基于日志的镜像，则必须正确启用日志功能。请记住，启用 RBD 日志功能可能会使写入延迟增加近一倍。

某些镜像功能对镜像是至关重要的。这些功能包括 exclusive-lock 和 journaling。exclusive-lock 功能确保在任何给定时间只有一个客户端可以修改镜像，而 journaling 支持一致的复制。在此设置中，主镜像保持可写状态，而非主镜像为只读状态。

镜像可以配置为两种模式：

• 存储池模式（Pool mode）：为存储池中的所有镜像启用镜像。

• 镜像模式（Image mode）：允许为特定镜像选择性地启用镜像。

如果要与 OpenStack Cinder 集成，则需要以镜像模式配置镜像。

版本兼容性是另一个需要考虑的因素。混合使用不同版本的 Ceph 服务器和客户端软件是不受支持的，可能会导致意外问题。此外，对于 Red Hat Ceph Storage 5 的用户，仅支持容器化的守护进程。

为了优化性能，在初始设置和测试阶段要密切监控集群活动。未经测试并行运行多个迁移可能会暴露出否则不会被注意到的瓶颈。

最后，确保网络带宽分配不仅要考虑复制流量，还要考虑客户端请求和恢复操作。适当的带宽管理有助于防止因需求重叠而导致的过度延迟。

如何设置 Ceph RBD 镜像

配置好集群和网络后，可以通过三个主要步骤设置 Ceph RBD 镜像，以创建一个可靠的灾难恢复解决方案。

启用存储池级别的镜像

首先，在将成为灾难恢复设置一部分的存储池上启用镜像。此步骤需要在两个集群上都执行。在每个集群上使用以下命令：

rbd mirror pool enable <pool-name> <mode>

将 <pool-name> 替换为存储池名称，将 <mode> 替换为 pool 或 image。如果选择 pool 模式，所有启用了日志功能的镜像都会自动进行镜像，提供广泛的覆盖。另一方面，image 模式需要为每个镜像单独启用镜像，从而提供更多控制。

例如，在一个双站点设置中，有一个名为“data”的存储池，将运行：

• rbd mirror pool enable data pool (在 site-a 上)

• rbd mirror pool enable data pool (在 site-b 上)

如果正在使用 OpenStack Cinder 或需要选择性镜像（例如，对于基于快照的设置），请通过在命令中将 pool 替换为 image 来选择 image 模式。

部署和配置 rbd-mirror 守护进程

启用存储池镜像后，需要设置 rbd-mirror 守护进程来处理复制。该守护进程确保镜像更新在集群之间同步。对于单向镜像，请在辅助集群上部署守护进程。对于双向镜像，请在两个集群上都部署它。

要部署守护进程，请使用 Ceph 的编排器并运行：

ceph orch apply rbd-mirror --placement=NODENAME

将 NODENAME 替换为目标主机名。为每个守护进程分配一个唯一的 Ceph 用户 ID，以防止冲突并确保正确的身份验证。可以使用 systemd 管理守护进程：

systemctl enable ceph-rbd-mirror@rbd-mirror.<unique_id>

出于测试目的，可以在前台运行守护进程并启用日志记录：

rbd-mirror -f --log-file={log_path}

连接对等集群

最后一步是在集群之间建立安全通信。Ceph 提供了自动和手动两种方法来连接对等集群。

对于自动对等发现，请在主站点上生成一个引导令牌：

rbd --cluster site-a mirror pool peer bootstrap create --site-name site-a image-pool

然后，在辅助站点上导入该令牌：

rbd --cluster site-b mirror pool peer bootstrap import --site-name site-b image-pool <token>

将 <token> 替换为生成的令牌。如果更喜欢手动配置，可以使用此命令添加一个对等方：

rbd --cluster site-a mirror pool peer add image-pool client.rbd-mirror-peer@site-b

确保对等集群的 monitor 和客户端密钥安全地存储在本地 Ceph monitor 配置中。

一旦集群连接，rbd-mirror 守护进程将根据计划和策略开始复制数据，从而创建一个可靠的灾难恢复系统。

对于使用 OpenMetal 的托管私有云与 OpenStack 和 Ceph 的用户，这些步骤可以顺利地与环境集成，以创建一个强大而可靠的 灾难恢复框架。

Ceph RBD 镜像最佳实践

采纳这些关键实践以加强灾难恢复设置。微调 Ceph RBD 镜像配置需要在性能调整和全面监控之间取得平衡，以实现可靠的灾难恢复，同时保持低开销和高效率。

性能调优与优化

网络带宽必须至少处理 (N × X) 的吞吐量，外加 20-30% 的额外缓冲。在这里，X 代表主集群中镜像的平均写入吞吐量（以 Mbps 为单位）。例如，如果 5 个镜像的平均写入吞吐量为 100 Mbps，请确保到辅助站点的网络连接至少支持 500 Mbps，并留有额外的安全余量。

两个集群应具有匹配的容量和性能能力，以避免在复制过程中出现瓶颈。

调整日志设置以平衡一致性和性能。较大的日志会减少刷新频率但会使用更多内存，而较小的日志在写入繁忙期间可能会增加复制延迟。根据工作负载需求调整这些设置。

根据复制负载为 rbd-mirror 守护进程分配足够的资源。在写入高峰期监控 CPU 和内存使用情况，以确保它们是充足的。对于拥有大量镜像或高写入吞吐量的环境，通过在不同节点上部署多个 rbd-mirror 守护进程来分散负载。

随着系统的扩展，审查和更新 CRUSH 规则以防止瓶颈。适当的放置组（placement group）分布有助于在存储基础设施上保持均匀的负载，避免可能阻碍复制的热点。

一旦优化了性能，搭建一个强大的监控就至关重要。

监控和警报设置

仅有性能优化是不够的——有效的监控至关重要。Ceph Dashboard 与 Prometheus、Grafana 和 Alertmanager 等工具很好地集成，以提供监控能力。这些工具可以使用 cephadm 进行部署，以简化配置和管理。

首先，在 ceph-mgr 守护进程中启用 Prometheus 模块以暴露内部 Ceph 指标。在每个集群节点上安装 node-exporter 以收集主机级别的指标，如 CPU、内存和网络使用情况。这种组合提供了对 Ceph 特定和系统级性能的洞察。

创建专注于 RBD 镜像指标的 Grafana 仪表板。需要监控的关键领域包括复制延迟、日志利用率和站点之间的网络吞吐量。为超过恢复点目标（RPO）的复制延迟设置警报。其他关键指标包括镜像健康状况、守护进程连接性和对等集群可用性。

配置 Alertmanager 以优先处理可操作的通知。例如，镜像失败应立即向值班工程师触发警报，而性能下降警报可能允许更长的评估期。

使用 Loki 和 Promtail 进行集中式日志记录，通过整合整个灾难恢复环境的日志来简化故障排除。这对于诊断间歇性网络问题或守护进程故障特别有用。

请记住，RBD 镜像监控默认是关闭的，以减少性能开销。应选择性地为关键镜像启用它，而不是将其应用于所有存储池。

如果环境使用自签名证书，请在仪表板配置中为 Prometheus 和 Alertmanager 禁用证书验证，以避免连接问题。然而，在生产环境中，适当的证书管理对于确保安全至关重要。

定期测试监控设置，以确认警报在实际故障期间按预期工作。安排模拟各种故障场景的演练，以验证技术监控和操作响应程序。

测试灾难恢复设置

定期测试是确保 Ceph RBD 镜像策略与灾难恢复目标保持一致并保护数据安全的关键。没有彻底的测试，可能会在实际紧急情况中发现问题——那时修复它们会变得困难得多。

如何测试故障切换流程

首先，设置测试环境以模拟真实世界的条件。在运行任何故障切换测试之前，使用 rsync 等工具将虚拟机和容器配置同步到辅助站点。这确保了当备份集群上的镜像被提升为主用时，实际上可以启动应用程序并确认它们按预期工作。

对于 计划内的故障切换测试，即两个集群都正常运行，请遵循特定顺序以避免脑裂（split-brain）情况。首先，使用 rbd mirror image demote 命令在站点 A 上降级镜像。此步骤确保主镜像停止接受写入并完成任何待处理的日志条目。一旦降级完成，使用 rbd mirror image promote 在站点 B 上提升相应的镜像。

“RBD 只提供必要的工具来促进镜像的有序故障切换。需要一个外部机制来协调完整的故障切换过程（例如，在降级前关闭镜像）。” – Ceph 文档

对于 紧急故障切换测试，模拟主站点中断。在这些情况下，需要使用 --force 标志与 promote 命令在站点 B 上强制提升。请注意，这种方法可能会导致一些数据丢失，具体取决于故障发生时的复制延迟。

在辅助集群上提升镜像后，启动虚拟机和容器。但不要就此止步——确保应用程序在常规操作负载下正常运行。

跟踪恢复指标，如恢复时间目标（RTO）和恢复点目标（RPO），并记录实际的恢复时间。在测试期间使用 Ceph 的监控工具：

• 运行 ceph status 以获取集群健康状况的概览。

• 使用 ceph -w 实时监控集群日志。

• 使用 rbd mirror image status 检查复制进度。

密切关注 故障切换时间（操作转移到备份站点的速度）和 故障恢复时间（恢复到主站点所需的时间）。在确认故障切换过程有效后，评估如何处理部分或间歇性故障。

管理部分故障

部分故障，如网络分区或脑裂情况，会使灾难恢复复杂化。当站点之间的通信中断时，这些情况就会发生，导致两个集群都认为自己应该是主用。

Ceph RBD 镜像使用 独占锁和日志记录 来维护崩溃一致性的副本，但网络问题仍然可能导致棘手的恢复情况。当出现连接问题时，使用 rbd mirror image status 命令检查两个集群中每个镜像的状态。

如果发生 脑裂事件，解决它需要手动干预。通过检查监控日志和应用程序时间戳来确定哪个集群拥有最新和最可靠的数据。使用 rbd mirror image demote 降级过时的镜像，然后使用 rbd mirror image resync 触发完全重新同步。请记住，重新同步可能需要大量时间，具体取决于镜像的大小和可用的网络带宽。

在部分故障期间监控 Ceph OSD 之间的 心跳消息。默认情况下，如果心跳时间超过 1000 毫秒（1 秒），则会触发健康检查。使用 ceph health detail 来确定哪些 OSD 正在经历延迟。要更深入地了解网络性能，请运行 dump_osd_network 命令以收集详细的网络数据。

从网络分区中恢复时，建立明确的规则来确定哪些数据优先。记录哪些应用程序写入哪些镜像，并根据业务需求创建决策树来解决冲突。一些组织优先考虑最新的事务数据，而另一些则关注数据完整性。

在灾难恢复演练期间，测试各种部分故障场景。模拟网络延迟、丢包和站点之间完全通信中断等情况。这些测试将使更好地了解工作负载在压力下的响应方式，并突出需要改进的领域。

总结：Ceph RBD 镜像

Ceph RBD 镜像为处理 私有 OpenStack 云 的灾难恢复提供了一种简化的方法。通过在集群之间异步复制块设备镜像，它确保了数据更改具有时间点一致性的副本。

但这不仅仅是关于保护数据。RBD 镜像还通过在主站点中断期间实现到辅助集群的平滑故障切换来减少停机时间并支持业务连续性。此功能为弹性的灾难恢复策略和持续改进奠定了基础。

如前所述，成功实施 RBD 镜像涉及一种全面的方法。这包括从设计集群和配置网络到设置存储池、部署守护进程和连接对等集群的所有内容。然而，工作并不仅限于部署。需要定期执行诸如监控复制延迟、确保集群之间有足够的网络带宽、加密数据传输以及跟踪恢复时间目标（RTO）和恢复点目标（RPO）等任务，以保持效率和安全性。

对于数据至关重要的工作负载，请考虑添加异地备份以进一步降低数据丢失的风险。这种分层方法加强了整体灾难恢复计划，提供了超越镜像的保护。

灾难恢复不是一次性任务——它需要持续的测试和监控，以确保系统保持可靠。当正确实施和管理时，Ceph RBD 镜像为支持私有 OpenStack 环境的可靠灾难恢复提供了所需的弹性。

常见问题

Ceph RBD 镜像中的单向复制和双向复制有什么区别，应该在什么时候使用它们？

在 Ceph RBD 镜像中，单向复制 是一种数据从主集群流向辅助集群的方法。这种设置非常适合灾难恢复，因为辅助集群充当备份，而无需将数据同步回主集群。它设置简单，使用的资源较少，是优先考虑基本数据保护的环境的实用选择。

另一方面，双向复制 允许数据在两个集群之间双向同步。这种设置非常适合主主配置，其中两个集群都处理读写操作。它确保了持续同步，提供了更高的可用性和冗余性——这对于需要在多个位置实现实时数据一致性的灾难恢复场景至关重要。

在网络问题或中断期间，Ceph RBD 镜像如何保持数据一致性和可靠性？

Ceph RBD 镜像通过 基于日志的复制 来增强数据一致性和可靠性。此方法按顺序记录对块设备镜像的每一次更改，使副本能够在不同集群之间在特定时间点保持一致。rbd-mirror 守护进程通过在主镜像和辅助镜像之间同步更新来发挥关键作用，确保更改按正确顺序应用。

如果发生网络故障或部分中断，日志系统会介入以准确捕获所有修改。然后可以重放这些更改，使辅助镜像保持在崩溃一致的状态。这种方法减少了数据丢失的机会，并允许轻松恢复到最近的稳定状态。

如何监控和优化 Ceph RBD 镜像以确保数据安全和快速恢复？

要维护一个高效可靠的 Ceph RBD 镜像设置，请考虑以下重要实践：

• 密切关注性能：利用 Ceph 的内置监控工具跟踪镜像延迟，并为潜在故障设置警报。这种主动的方法可以帮助及早解决问题，确保数据保持一致和可访问。

• 改善网络设置：集群之间低延迟、高带宽的连接至关重要。糟糕的网络性能会减慢复制速度并损害可靠性。

• 根据需要调整配置：定期分析性能指标并调整设置，以消除瓶颈并充分利用可用资源。

通过遵循这些步骤，将加强 Ceph RBD 镜像的可靠性，保护数据并在出现问题时缩短恢复时间。