Disaster recovery for planned failover

原文：https://docs.gitlab.com/ee/administration/geo/disaster_recovery/planned_failover.html

Disaster recovery for planned failover

The primary use-case of Disaster Recovery is to ensure business continuity in the event of unplanned outage, but it can be used in conjunction with a planned failover to migrate your GitLab instance between regions without extended downtime.

由于 Geo 节点之间的复制是异步的，因此计划中的故障转移需要一个维护窗口，该窗口中阻止了对主节点的更新. 该窗口的长度取决于您的复制能力-一旦辅助节点与主节点完全同步，就可以进行故障转移而不会丢失数据.

本文档假定您已经具有完整配置的，可以正常使用的 Geo 设置. 在继续之前，请完整阅读它和Disaster Recovery故障转移文档. 计划内的故障转移是一项主要操作，如果执行不正确，则存在很高的数据丢失风险. 考虑对程序进行排练，直到您对必要的步骤感到满意并且对能够准确执行它们有高度的信心.

Not all data is automatically replicated

如果您使用的是 Geo 不支持的任何 GitLab 功能， 则必须单独进行准备，以确保辅助节点具有与该功能关联的任何数据的最新副本. 这可能会大大延长所需的计划维护时间.

使文件中存储的数据的时间尽可能短的常见策略是使用rsync传输数据. 可以在维护窗口之前执行初始rsync . 随后的rsync s（包括维护窗口内的最终传输）将仅传输主节点和辅助节点之间的更改 .

在移动存储库文档中可以找到有效使用rsync的以存储库为中心的策略. 这些策略可以调整为与任何其他基于文件的数据一起使用，例如 GitLab 页面（如果使用 Omnibus，则可在/var/opt/gitlab/gitlab-rails/shared/pages ）.

Preflight checks

运行此命令以列出所有预检检查，并在计划计划的故障转移之前自动检查复制和验证是否完成，以确保过程顺利进行：

  1. gitlab-ctl promotion-preflight-checks

即使预检检查失败，也可以以force模式运行此命令以升级为主要命令：

  1. sudo gitlab-ctl promotion-preflight-checks --force

每个步骤将在下面更详细地描述.

Object storage

如果您有大量的 GitLab 安装或无法忍受停机，请在计划计划的故障转移之前考虑迁移到对象存储 . 这样做既可以减少维护窗口的长度，又可以减少由于计划内故障转移执行不当而导致的数据丢失风险.

In GitLab 12.4, you can optionally allow GitLab to manage replication of Object Storage for secondary nodes. For more information, see Object Storage replication.

Review the configuration of each secondary node

数据库设置会自动复制到辅助节点，但是/etc/gitlab/gitlab.rb文件必须手动设置，并且在节点之间有所不同. 如果在主要节点上启用了 Mattermost，OAuth 或 LDAP 集成等功能，但在次要节点上未启用这些功能，则它们将在故障转移期间丢失.

查看两个节点的/etc/gitlab/gitlab.rb文件，并确保辅助节点支持主节点在计划计划的故障转移之前所做的一切.

Run system checks

在主节点和辅助节点上运行以下命令：

  1. gitlab-rake gitlab:check
  2. gitlab-rake gitlab:geo:check

如果在任一节点上报告了任何故障，则应在计划计划的故障转移之前解决这些故障.

Check that secrets match between nodes

SSH 主机密钥和/etc/gitlab/gitlab-secrets.json文件在所有节点上均应相同. 通过在所有节点上运行以下命令并比较输出来进行检查：

  1. sudo sha256sum /etc/ssh/ssh_host* /etc/gitlab/gitlab-secrets.json

如果有任何文件不同，请用主节点中的内容替换辅助节点上的内容.

Ensure Geo replication is up-to-date

直到地理复制和验证完成，维护窗口才会结束. 为了使窗口尽可能短，在使用过程中，应确保这些过程尽可能接近 100％.

导航到 管理区> 辅助节点上的地理仪表板以查看状态. 复制的对象（以绿色显示）应接近 100％，并且不应出现故障（以红色显示）. 如果尚未复制大量对象（显示为灰色），请考虑给节点更多时间来完成

Replication status

如果有任何对象无法复制，则应在安排维护窗口之前进行调查. 在计划好的故障转移之后，所有无法复制的内容都会丢失 .

您可以使用地理状态 API查看失败的对象以及失败的原因.

复制失败的常见原因是主节点上缺少数据-您可以通过从备份还原数据或删除对丢失数据的引用来解决这些故障.

Verify the integrity of replicated data

This content was moved to another location.

Notify users of scheduled maintenance

在主节点上，导航到 管理区> 消息 ，添加广播消息. 你可以检查下 管理区> 地理位置，以估算完成同步需要多长时间. 一个示例消息是：

计划的维护将在世界标准时间 XX：XX 进行. 我们预计将花费不到 1 个小时.

Prevent updates to the primary node

在实施只读模式之前，必须防止手动进行更新. 请注意，在维护窗口期间， 辅助节点仍需要对主节点具有只读访问权限.

  1. 在计划的时间，使用您的云提供商或节点的防火墙，阻止去往/来自主节点的所有 HTTP，HTTPS 和 SSH 通信， 但 IP 和辅助节点的 IP 除外 .

    例如，您可能在组成主节点的服务器上运行以下命令：

    1. sudo iptables -A INPUT -p tcp -s <secondary_node_ip> --destination-port 22 -j ACCEPT
    2. sudo iptables -A INPUT -p tcp -s <your_ip> --destination-port 22 -j ACCEPT
    3. sudo iptables -A INPUT --destination-port 22 -j REJECT
    5. sudo iptables -A INPUT -p tcp -s <secondary_node_ip> --destination-port 80 -j ACCEPT
    6. sudo iptables -A INPUT -p tcp -s <your_ip> --destination-port 80 -j ACCEPT
    7. sudo iptables -A INPUT --tcp-dport 80 -j REJECT
    9. sudo iptables -A INPUT -p tcp -s <secondary_node_ip> --destination-port 443 -j ACCEPT
    10. sudo iptables -A INPUT -p tcp -s <your_ip> --destination-port 443 -j ACCEPT
    11. sudo iptables -A INPUT --tcp-dport 443 -j REJECT

    从这一点来看，用户将无法查看其数据或在主节点上进行更改. 他们也将无法登录到辅助节点. 但是，现有的会话将在维护期间的剩余时间内起作用，并且可以在整个维护期间访问公共数据.

  2. 通过使用其他 IP 在浏览器中访问主节点，验证主节点是否受到 HTTP 流量的阻止. 服务器应拒绝连接.

  3. 尝试通过使用 SSH 远程 URL 提取现有的 Git 存储库，来验证主节点是否已通过 SSH 流量阻止 Git. 服务器应拒绝连接.

  4. 通过导航到禁用主要节点上的非 Geo 定期后台作业 管理区> 监视>后台作业> Cron ，按Disable All ，然后为geo_sidekiq_cron_config_worker cron 作业按Enable . 该作业将重新启用其他几个 cron 作业，这些作业对于计划的故障转移成功完成至关重要.

Finish replicating and verifying all data

  1. 如果您要手动复制不是由 Geo 管理的任何数据，请立即触发最终复制过程.
  2. 在主节点上，导航到 管理区> 监视>后台作业>队列，并等待所有队列（名称中带有geo的队列降至 0）.这些队列包含用户提交的工作； 在完成之前进行故障转移将导致工作丢失.

  3. 在主节点上，导航到 管理区> 地理位置，并等待您要故障转移到的辅助节点满足以下条件：

    • 所有复制计量到 100％复制，0％失败.
    • 所有验证仪表均达到 100％验证，0％失败.
    • 数据库复制滞后为 0ms.
    • 地理日志光标是最新的（落后 0 个事件）.
  4. 在辅助节点上，导航到 管理区> 监视>后台作业>队列，然后等待所有geo队列下降到 0 个已排队的作业和 0 个正在运行的作业.
  5. 在辅助节点上，使用以下说明来验证 CI 工件，LFS 对象以及文件存储中的上载的完整性.

此时， 辅助节点将包含主节点拥有的所有内容的最新副本，这意味着在进行故障转移时不会丢失任何内容.

Promote the secondary node

最后，按照灾难恢复文档将辅助节点升级为主要节点. 此过程将导致辅助节点发生短暂中断，并且用户可能需要再次登录.

一旦完成，维护窗口就结束了！ 新的主节点现在开始发散，从旧的. 如果确实出现在这一点上的问题，没有回到原来的主节点是可能的，但可能会导致在此期间上传到新的主任何数据丢失.

故障转移完成后，请不要忘记删除广播消息.