Help us learn about your current experience with the documentation. Take the survey.

GitLab Dedicated 的灾难恢复

  • 版本：Ultimate
  • 产品：GitLab Dedicated

灾难恢复流程确保在灾难影响到您的主区域时，可以恢复您的 GitLab Dedicated 实例。

GitLab 可以在这些 AWS 区域部署您的实例：

  • 运行您实例的主区域。
  • 如果已选择，则作为主区域故障时的备用辅助区域。
  • 一个备份区域，您的数据备份会被复制到此处以提供额外保护。

如果您的由于中断或严重系统故障而无法访问，GitLab 会启动到您的辅助区域的故障转移。如果未配置辅助区域，恢复将使用来自备份区域的备份还原。

先决条件

要符合完整的恢复目标，您必须：

恢复目标

GitLab Dedicated 提供具有以下恢复目标的灾难恢复：

  • 恢复时间目标 (RTO)：服务在八小时或更短时间内恢复到您的辅助区域。
  • 恢复点目标 (RPO)：数据丢失最多限于最近四小时的更改，具体取决于灾难发生的时间相对于上次备份的时间点。

组件

GitLab Dedicated 利用两个关键组件来满足灾难恢复承诺：

  • Geo 复制
  • 自动备份

Geo 复制

当您入职 GitLab Dedicated 时，您会为您的环境选择一个主区域和一个辅助区域。Geo 会在这些区域之间持续复制数据，包括：

  • 数据库内容
  • 仓库存储
  • 对象存储

自动备份

GitLab 通过创建快照，每四小时（每天六次）对数据库和仓库执行自动备份。备份保留 30 天，并由 AWS 进行地理复制以提供额外保护。

数据库备份：

  • 在主区域使用基于日志的持续备份以进行时间点恢复。
  • 流式复制到辅助区域以提供近实时副本。

对象存储备份：

  • 使用地理复制和版本控制来提供备份保护。

这些备份在灾难恢复操作中作为恢复点。四小时的备份频率支持恢复点目标 (RPO)，以确保您丢失的数据不超过四小时。

灾难覆盖范围

灾难恢复涵盖以下具有保证恢复目标的场景：

  • 部分区域中断（例如，可用区故障）
  • 您的主区域完全中断

灾难恢复在尽力而为的基础上涵盖以下场景，但不保证恢复目标：

  • 主区域和辅助区域均丢失
  • 全球互联网中断
  • 数据损坏问题

灾难恢复存在以下服务限制：

  • 高级搜索索引不会持续复制。故障转移后，当辅助区域被提升时，这些索引将被重建。在重建期间，基本搜索仍然可用。
  • ClickHouse Cloud 仅在主区域配置。如果主区域完全宕机，需要此服务的功能可能不可用。
  • 生产预览环境没有辅助实例。
  • 托管 Runner 仅在主区域受支持，无法在辅助实例中重建。
  • 某些辅助区域支持有限，不受 RPO 和 RTO 目标的覆盖。由于 AWS 的限制，这些区域在您的故障转移实例中的电子邮件功能和弹性有限。更多信息，请参阅支持有限的辅助区域。

GitLab 不提供：

  • 对故障转移事件的程序化监控
  • 由客户发起的灾难恢复测试

灾难恢复工作流

当您的实例因以下原因而对大多数用户不可用时，将启动灾难恢复：

  • 区域完全故障（例如，AWS 区域中断）。
  • GitLab 服务或基础设施中的关键组件发生故障，无法快速恢复。

故障转移流程

当您的实例不可用时，GitLab Dedicated 团队：

  1. 通过监控系统收到警报。
  2. 调查是否需要故障转移。
  3. 如果需要故障转移：
    1. 通知您故障转移正在进行中。
    2. 将辅助区域提升为主区域。
    3. 更新 <customer>.gitlab-dedicated.com 的 DNS 记录，使其指向新提升的区域。
    4. 在故障转移完成后通知您。

如果您使用 PrivateLink，则必须更新您的内部网络配置，以指向辅助区域的 PrivateLink 端点。为最大程度地减少停机时间，请在灾难发生前在您的辅助区域中配置等效的 PrivateLink 端点。

故障转移流程通常在 90 分钟或更短时间内完成。

灾难期间的沟通

在灾难事件期间，GitLab 会通过以下一种或多种方式与您沟通：

  • 您在 Switchboard 中的运营联系信息
  • Slack
  • 支持工单

GitLab 可能会建立一个临时的 Slack 频道和 Zoom 会议，以便在整个恢复过程中与您的团队进行协调。

相关主题