{{< details >}}

  • Tier: 专业版, 旗舰版
  • Offering: 私有化部署

{{< /details >}}

本篇文档适用于 Linux 软件包。要使用您自己的非捆绑 Redis,请参见 提供您自己的实例的 Redis 复制和故障转移

在 Redis 的术语中,primary 被称为 master。在本文档中,除了需要 master 的设置外,其他情况下使用 primary

在可扩展环境中使用 Redis 是可能的,这可以通过 Primary x Replica 拓扑结构,并使用 Redis Sentinel 服务来监视和自动启动故障转移程序。

如果与 Sentinel 一起使用,Redis 需要身份验证。我们建议使用 Redis 密码和严格的防火墙规则组合来保护您的 Redis 服务。我们强烈建议您在将 Redis 配置为极狐GitLab 之前阅读 Redis Sentinel 文档,以充分了解拓扑结构和架构。

在深入了解为复制拓扑设置 Redis 和 Redis Sentinel 的详细信息之前,请务必先通读本文档,以更好地理解各组件的关联。

您至少需要 3 台独立机器:物理机或运行在不同物理机器上的虚拟机。所有 primary 和 replica Redis 实例都必须运行在不同的机器上。如果您未能以这种方式提供机器,任何共享环境的问题都可能导致整个设置崩溃。

可以在 primary 或 replica Redis 实例旁边运行 Sentinel。但同一台机器上不应有多个 Sentinel。

您还需要考虑底层网络拓扑,确保 Redis / Sentinel 和极狐GitLab 实例之间有冗余连接,否则网络将成为单点故障。

在扩展环境中运行 Redis 需要一些条件:

  • 多个 Redis 实例
  • Primary x Replica 拓扑中运行 Redis
  • 多个 Sentinel 实例
  • 应用程序支持并能访问所有 Sentinel 和 Redis 实例

Redis Sentinel 可以处理 HA 环境中最重要的任务,帮助保持服务器在线并最大限度地减少停机时间。Redis Sentinel:

  • 监控 PrimaryReplicas 实例以查看它们是否可用
  • Primary 失败时,将 Replica 提升为 Primary
  • 当故障的 Primary 恢复在线时,将其降级为 Replica(以防止数据分区)
  • 应用程序可以查询它以始终连接到当前的 Primary 服务器

Primary 无法响应时,应用程序(在我们的情况下为极狐GitLab)负责处理超时并重新连接(查询 Sentinel 以获取新的 Primary)。

为了更好地理解如何正确设置 Sentinel,请先阅读 Redis Sentinel 文档,因为未能正确配置它可能会导致数据丢失或使整个集群崩溃,从而使故障转移努力无效。

推荐设置

对于最小设置,您需要在 3独立 机器上安装 Linux 软件包,同时安装 RedisSentinel

  • Redis Primary + Sentinel
  • Redis Replica + Sentinel
  • Redis Replica + Sentinel

如果您不确定或不理解节点数量的来源,请阅读 Redis 设置概述Sentinel 设置概述

对于推荐的可以抵抗更多故障的设置,您需要在 5独立 机器上安装 Linux 软件包,同时安装 RedisSentinel

  • Redis Primary + Sentinel
  • Redis Replica + Sentinel
  • Redis Replica + Sentinel
  • Redis Replica + Sentinel
  • Redis Replica + Sentinel

Redis 设置概述

您必须至少拥有 3 台 Redis 服务器:1 台 primary,2 台 Replicas,它们需要分别在独立的机器上(参见上面的解释)。

您可以拥有额外的 Redis 节点,这有助于在更多节点宕机的情况下生存。只要只有 2 个节点在线,就不会启动故障转移。

例如,如果您有 6 个 Redis 节点,最多可以同时宕机 3 个。

对于 Sentinel 节点有不同的要求。如果您将它们托管在同一台 Redis 机器上,可能需要在计算要提供的节点数量时考虑这些限制。有关更多信息,请参见 Sentinel 设置概述 文档。

所有 Redis 节点应以相同方式配置,并具有类似的服务器规格,因为在故障转移情况下,任何 Replica 都可以被 Sentinel 服务器提升为新的 Primary

复制需要身份验证,因此您需要定义一个密码来保护所有 Redis 节点和 Sentinel。它们都共享相同的密码,并且所有实例必须能够通过网络相互通信。

Sentinel 设置概述

Sentinels 监视其他 Sentinels 和 Redis 节点。每当 Sentinel 检测到 Redis 节点没有响应时,它会向其他 Sentinels 宣布该节点的状态。Sentinels 必须达到 quorum(同意节点宕机的最少 Sentinel 数量)才能启动故障转移。

每当满足 quorum 时,所有已知的 Sentinel 节点的 majority 必须可用且可到达,以便它们可以选举 Sentinel leader,该 leader 会通过以下方式恢复服务可用性:

  • 提升新的 Primary
  • 重新配置其他 Replicas 并使它们指向新的 Primary
  • 向其他 Sentinel 同伴宣布新的 Primary
  • 当旧的 Primary 恢复在线时,将其重新配置并降级为 Replica

您必须至少拥有 3 个 Redis Sentinel 服务器,并且它们需要分别在独立的机器上(这些机器被认为是独立故障的),理想情况下位于不同的地理区域。

您可以将它们配置在已配置其他 Redis 服务器的相同机器上,但请理解如果整个节点宕机,您将同时失去 Sentinel 和 Redis 实例。

Sentinels 的数量理想情况下应始终为 odd 数,以便在故障情况下共识算法有效。

3 节点拓扑中,您最多只能容忍 1 个 Sentinel 节点宕机。每当 Sentinels 的 majority 宕机时,网络分区保护会阻止破坏性操作,并且不会启动故障转移。

以下是一些示例:

  • 使用 56 个 sentinels,最多可以宕机 2 个节点以开始故障转移。
  • 使用 7 个 sentinels,最多可以宕机 3 个节点。

有时,当未达到 consensus 时,Leader 选举可能会失败投票轮次(参见上面的奇数节点要求)。在这种情况下,会在 sentinel['failover_timeout'](以毫秒为单位)中定义的时间后进行新的尝试。

{{< alert type=”note” >}}

我们可以稍后看到 sentinel['failover_timeout'] 的定义。

{{< /alert >}}

failover_timeout 变量有许多不同的用途。根据官方文档:

  • 重新启动故障转移所需的时间是在之前针对同一 primary 的故障转移尝试后由给定 Sentinel 进行的,是故障转移超时的两倍。

  • 复制到根据 Sentinel 当前配置错误 primary 的 replica,强制其与正确的 primary 进行复制的时间,正好是故障转移超时(从 Sentinel 检测到错误配置的那一刻起计算)。

  • 取消已经进行但未产生任何配置更改的故障转移所需的时间(尚未由提升的 replica 确认)。

  • 故障转移进行中等待所有 replica 重新配置为新 primary 的 replica 的最长时间。然而,即使在此时间之后,Sentinels 仍然会重新配置 replica,但不是按照指定的并行同步进度。

配置 Redis

这是我们安装和设置新 Redis 实例的部分。

假设您是从头开始安装极狐GitLab 及其所有组件。如果您已经安装并运行了 Redis,请阅读如何 从单机安装切换

{{< alert type=”note” >}}

Redis 节点(primary 和 replica)需要在 redis['password'] 中定义相同的密码。在故障转移期间的任何时候,Sentinels 都可以重新配置节点并更改其状态,从 primary 到 replica,反之亦然。

{{< /alert >}}

要求

Redis 设置的要求如下:

  1. 根据推荐设置部分中指定的最低要求数量提供实例。
  2. 我们不建议在运行极狐GitLab 应用程序的同一台机器上安装 Redis 或 Redis Sentinel,因为这会削弱您的 HA 配置。但是,您可以选择在同一台机器上安装 Redis 和 Sentinel。
  3. 所有 Redis 节点必须能够相互通信并接受来自 Redis (6379) 和 Sentinel (26379) 端口的传入连接(除非您更改了默认端口)。
  4. 托管极狐GitLab 应用程序的服务器必须能够访问 Redis 节点。
  5. 使用防火墙保护节点免受外部网络的访问。

从现有单机安装切换

如果您已经有一个正在运行的单机极狐GitLab 安装,您需要首先从这台机器进行复制,然后才能停用其中的 Redis 实例。

您的单机安装是初始 Primary,其他 3 台机器应配置为 Replica 指向这台机器。

在复制完成后,您需要停止单机安装中的服务,以将 Primary 旋转到新节点之一。

进行所需的配置更改并重新启动新节点。

要在单机安装中禁用 Redis,请编辑 /etc/gitlab/gitlab.rb

redis['enable'] = false

如果您未能首先进行复制,可能会丢失数据(未处理的后台作业)。

步骤 1. 配置 primary Redis 实例

  1. 通过 SSH 进入 Primary Redis 服务器。
  2. 使用极狐GitLab 下载页面的步骤 1 和 2 下载并安装所需的 Linux 软件包。
    • 确保选择正确的 Linux 软件包,版本和类型(基础版、企业版)与当前安装相同。
    • 不要完成下载页面上的其他步骤。
  3. 编辑 /etc/gitlab/gitlab.rb 并添加内容:

    # 指定服务器角色为 'redis_master_role'
    roles ['redis_master_role']
    
    # 指向其他机器可以访问的本地 IP 的 IP 地址。
    # 您也可以将 bind 设置为 '0.0.0.0',这将监听所有接口。
    # 如果您确实需要绑定到外部可访问的 IP,请确保添加额外的防火墙规则以防止未经授权的访问。
    redis['bind'] = '10.0.0.1'
    
    # 定义一个端口,以便 Redis 可以监听 TCP 请求,允许其他机器连接到它。
    redis['port'] = 6379
    
    # 为 Redis 设置密码身份验证(在所有节点中使用相同的密码)。
    redis['password'] = 'redis-password-goes-here'
    
  4. 只有 primary 极狐GitLab 应用程序服务器应处理迁移。为了防止数据库迁移在升级时运行,请在 /etc/gitlab/gitlab.rb 文件中添加以下配置:

    gitlab_rails['auto_migrate'] = false
    
  5. 重新配置极狐GitLab 以使更改生效。

{{< alert type=”note” >}}

您可以指定多个角色,如 sentinel 和 Redis,如:roles ['redis_sentinel_role', 'redis_master_role']。阅读更多关于角色的信息。

{{< /alert >}}

步骤 2. 配置 replica Redis 实例

  1. 通过 SSH 进入 replica Redis 服务器。
  2. 使用极狐GitLab 下载页面的步骤 1 和 2 下载并安装所需的 Linux 软件包。
    • 确保选择正确的 Linux 软件包,版本和类型(基础版、企业版)与当前安装相同。
    • 不要完成下载页面上的其他步骤。
  3. 编辑 /etc/gitlab/gitlab.rb 并添加内容:

    # 指定服务器角色为 'redis_replica_role'
    roles ['redis_replica_role']
    
    # 指向其他机器可以访问的本地 IP 的 IP 地址。
    # 您也可以将 bind 设置为 '0.0.0.0',这将监听所有接口。
    # 如果您确实需要绑定到外部可访问的 IP,请确保添加额外的防火墙规则以防止未经授权的访问。
    redis['bind'] = '10.0.0.2'
    
    # 定义一个端口,以便 Redis 可以监听 TCP 请求,允许其他机器连接到它。
    redis['port'] = 6379
    
    # 与 primary 节点设置相同的 Redis 身份验证密码。
    redis['password'] = 'redis-password-goes-here'
    
    # primary Redis 节点的 IP。
    redis['master_ip'] = '10.0.0.1'
    
    # primary Redis 服务器的端口,取消注释以更改为非默认值。默认为 `6379`。
    #redis['master_port'] = 6379
    
  4. 为了防止在升级时自动运行重新配置,请运行:

    sudo touch /etc/gitlab/skip-auto-reconfigure
    
  5. 只有 primary 极狐GitLab 应用程序服务器应处理迁移。为了防止数据库迁移在升级时运行,请在 /etc/gitlab/gitlab.rb 文件中添加以下配置:

    gitlab_rails['auto_migrate'] = false
    
  6. 重新配置极狐GitLab 以使更改生效。
  7. 对所有其他 replica 节点重复这些步骤。

{{< alert type=”note” >}}

您可以指定多个角色,如 sentinel 和 Redis,如:roles ['redis_sentinel_role', 'redis_master_role']。阅读更多关于角色的信息。

{{< /alert >}}

这些值在故障转移后无需在 /etc/gitlab/gitlab.rb 中再次更改,因为节点由 Sentinels 管理,即使在 gitlab-ctl reconfigure 后,它们的配置也会由相同的 Sentinels 恢复。

步骤 3. 配置 Redis Sentinel 实例

{{< alert type=”note” >}}

对 Sentinel 密码认证的支持是在极狐GitLab 16.1 中引入的。

{{< /alert >}}

现在 Redis 服务器都已设置好,让我们配置 Sentinel 服务器。

如果您不确定您的 Redis 服务器是否正常工作并正确复制,请阅读 故障排除复制 并在继续进行 Sentinel 设置之前修复它。

您必须至少拥有 3 个 Redis Sentinel 服务器,并且它们需要分别在独立的机器上。您可以在配置其他 Redis 服务器的相同机器上配置它们。

对于极狐GitLab 企业版,您可以使用 Linux 软件包在多台机器上设置 Sentinel 守护进程。

  1. 通过 SSH 进入托管 Redis Sentinel 的服务器。
  2. 如果 Sentinels 托管在与其他 Redis 实例相同的节点上,您可以省略此步骤。

    使用极狐GitLab 下载页面的步骤 1 和 2 下载并安装 Linux 企业版软件包。 - 确保选择正确的 Linux 软件包,与极狐GitLab 应用程序运行的版本相同。 - 不要完成下载页面上的其他步骤。

  3. 编辑 /etc/gitlab/gitlab.rb 并添加内容(如果您在与其他 Redis 实例相同的节点上安装 Sentinels,以下某些值可能会重复):

    roles ['redis_sentinel_role']
    
    # 必须在每个 sentinel 节点中相同
    redis['master_name'] = 'gitlab-redis'
    
    # 与 primary 节点设置相同的 Redis 身份验证密码。
    redis['master_password'] = 'redis-password-goes-here'
    
    # primary Redis 节点的 IP。
    redis['master_ip'] = '10.0.0.1'
    
    # 定义一个端口,以便 Redis 可以监听 TCP 请求,允许其他机器连接到它。
    redis['port'] = 6379
    
    # primary Redis 服务器的端口,取消注释以更改为非默认值。默认为 `6379`。
    #redis['master_port'] = 6379
    
    ## 配置 Sentinel
    sentinel['bind'] = '10.0.0.1'
    
    ## Sentinel 身份验证的可选密码。默认为不需要密码。
    # sentinel['password'] = 'sentinel-password-goes here'
    
    # Sentinel 监听的端口,取消注释以更改为非默认值。默认为 `26379`。
    # sentinel['port'] = 26379
    
    ## Quorum 必须反映开始故障转移所需的投票 sentinels 数量。
    ## 值不得大于 sentinels 的数量。
    ##
    ## Quorum 可用于两种方式调整 Sentinel:
    ## 1. 如果 quorum 设置为小于我们部署的 sentinels 的大多数的值,我们基本上是在使 Sentinel 对 primary 故障更敏感,只要少数 sentinels 不再能够与 primary 通信,就会触发故障转移。
    ## 1. 如果 quorum 设置为大于 sentinels 的大多数的值,我们是在使 Sentinel 仅在有大量(大于大多数)良好连接的 sentinels 同意 primary 宕机时才能进行故障转移。
    sentinel['quorum'] = 2
    
    ## 在 x 毫秒后将无响应服务器视为宕机。
    # sentinel['down_after_milliseconds'] = 10000
    
    ## 指定故障转移超时(以毫秒为单位)。它有多种用途:
    ##
    ## - 在给定 Sentinel 已经针对同一 primary 尝试过故障转移后重新启动故障转移所需的时间是故障转移超时的两倍。
    ##
    ## - 复制到根据 Sentinel 当前配置错误 primary 的 replica,强制其与正确的 primary 进行复制的时间,正好是故障转移超时(从 Sentinel 检测到错误配置的那一刻起计算)。
    ##
    ## - 取消已经进行但未产生任何配置更改的故障转移所需的时间(尚未由提升的 replica 确认)。
    ##
    ## - 故障转移进行中等待所有 replica 重新配置为新 primary 的 replica 的最长时间。然而,即使在此时间之后,Sentinels 仍然会重新配置 replica,但不是按照指定的并行同步进度。
    # sentinel['failover_timeout'] = 60000
    
  4. 为了防止在升级时运行数据库迁移,请运行:

    sudo touch /etc/gitlab/skip-auto-reconfigure
    

    只有 primary 极狐GitLab 应用程序服务器应处理迁移。

  5. 重新配置极狐GitLab 以使更改生效。
  6. 对所有其他 Sentinel 节点重复这些步骤。

步骤 4. 配置极狐GitLab 应用程序

最后一步是通知主极狐GitLab 应用程序服务器 Redis Sentinels 服务器和身份验证凭据。

您可以随时在新安装或现有安装中启用或禁用 Sentinel 支持。从极狐GitLab 应用程序的角度来看,所有需要的是 Sentinel 节点的正确凭据。

虽然不需要列出所有 Sentinel 节点,但在故障情况下,它需要至少访问列出的一个。

{{< alert type=”note” >}}

以下步骤应在极狐GitLab 应用程序服务器上执行,理想情况下该服务器不应具有 Redis 或 Sentinels 以进行 HA 设置。

{{< /alert >}}

  1. 通过 SSH 进入安装了极狐GitLab 应用程序的服务器。
  2. 编辑 /etc/gitlab/gitlab.rb 并添加/更改以下行:

    ## 必须在每个 sentinel 节点中相同
    redis['master_name'] = 'gitlab-redis'
    
    ## 与 primary 节点设置相同的 Redis 身份验证密码。
    redis['master_password'] = 'redis-password-goes-here'
    
    ## 一个包含 `host` 和 `port` 的 sentinels 列表
    gitlab_rails['redis_sentinels'] = [
      {'host' => '10.0.0.1', 'port' => 26379},
      {'host' => '10.0.0.2', 'port' => 26379},
      {'host' => '10.0.0.3', 'port' => 26379}
    ]
    # gitlab_rails['redis_sentinels_password'] = 'sentinel-password-goes-here' # 取消注释并将其设置为与 sentinel['password'] 相同的值
    
  3. 重新配置极狐GitLab 以使更改生效。

步骤 5. 启用监控

如果您启用监控,则必须在所有 Redis 服务器上启用。

  1. 确保收集 CONSUL_SERVER_NODES,即 Consul 服务器节点的 IP 地址或 DNS 记录,以便进行下一步。请注意,它们以 Y.Y.Y.Y consul1.gitlab.example.com Z.Z.Z.Z 的形式出现。

  2. 创建/编辑 /etc/gitlab/gitlab.rb 并添加以下配置:

    # 为 Prometheus 启用服务发现
    consul['enable'] = true
    consul['monitoring_service_discovery'] =  true
    
    # 替换占位符
    # Y.Y.Y.Y consul1.gitlab.example.com Z.Z.Z.Z
    # 为 Consul 服务器节点的地址
    consul['configuration'] = {
       retry_join: %w(Y.Y.Y.Y consul1.gitlab.example.com Z.Z.Z.Z),
    }
    
    # 设置导出器监听的网络地址
    node_exporter['listen_address'] = '0.0.0.0:9100'
    redis_exporter['listen_address'] = '0.0.0.0:9121'
    
  3. 运行 sudo gitlab-ctl reconfigure 以编译配置。

具有 1 个 primary,2 个 replicas 和 3 个 Sentinels 的最小配置示例

在此示例中,我们假设所有服务器都有一个内部网络接口,其 IP 位于 10.0.0.x 范围内,并且它们可以使用这些 IP 相互连接。

在实际使用中,您还应设置防火墙规则以防止其他机器的未经授权访问并阻止来自外部(Internet)的流量。

我们使用相同的 3 个节点,具有 Redis + Sentinel 拓扑结构,如 Redis 设置概述Sentinel 设置概述 文档中讨论。

以下是每个 machine 和分配的 IP 的列表和描述:

  • 10.0.0.1: Redis primary + Sentinel 1
  • 10.0.0.2: Redis Replica 1 + Sentinel 2
  • 10.0.0.3: Redis Replica 2 + Sentinel 3
  • 10.0.0.4: 极狐GitLab 应用程序

在初始配置后,如果由 Sentinel 节点启动故障转移,Redis 节点将被重新配置,并且 Primary 会永久更改(包括在 redis.conf 中)从一个节点到另一个节点,直到再次启动新的故障转移。

同样的事情发生在 sentinel.conf 中,它在初始执行后被覆盖,在任何新的 sentinel 节点开始监视 Primary 后,或故障转移提升不同的 Primary 节点后。

Redis primary 和 Sentinel 1 的示例配置

/etc/gitlab/gitlab.rb 中:

roles ['redis_sentinel_role', 'redis_master_role']
redis['bind'] = '10.0.0.1'
redis['port'] = 6379
redis['password'] = 'redis-password-goes-here'
redis['master_name'] = 'gitlab-redis' # 必须在每个 sentinel 节点中相同
redis['master_password'] = 'redis-password-goes-here' # 在 primary 实例中定义的与 redis['password'] 相同的值
redis['master_ip'] = '10.0.0.1' # 初始 primary redis 实例的 ip
#redis['master_port'] = 6379 # 初始 primary redis 实例的端口,取消注释以更改为非默认值
sentinel['bind'] = '10.0.0.1'
# sentinel['password'] = 'sentinel-password-goes-here' # 必须在每个 sentinel 节点中相同,取消注释以设置密码
# sentinel['port'] = 26379 # 取消注释以更改默认端口
sentinel['quorum'] = 2
# sentinel['down_after_milliseconds'] = 10000
# sentinel['failover_timeout'] = 60000

重新配置极狐GitLab 以使更改生效。

Redis replica 1 和 Sentinel 2 的示例配置

/etc/gitlab/gitlab.rb 中:

roles ['redis_sentinel_role', 'redis_replica_role']
redis['bind'] = '10.0.0.2'
redis['port'] = 6379
redis['password'] = 'redis-password-goes-here'
redis['master_password'] = 'redis-password-goes-here'
redis['master_ip'] = '10.0.0.1' # primary Redis 服务器的 IP
#redis['master_port'] = 6379 # primary Redis 服务器的端口,取消注释以更改为非默认值
redis['master_name'] = 'gitlab-redis' # 必须在每个 sentinel 节点中相同
sentinel['bind'] = '10.0.0.2'
# sentinel['password'] = 'sentinel-password-goes-here' # 必须在每个 sentinel 节点中相同,取消注释以设置密码
# sentinel['port'] = 26379 # 取消注释以更改默认端口
sentinel['quorum'] = 2
# sentinel['down_after_milliseconds'] = 10000
# sentinel['failover_timeout'] = 60000

重新配置极狐GitLab 以使更改生效。

Redis replica 2 和 Sentinel 3 的示例配置

/etc/gitlab/gitlab.rb 中:

roles ['redis_sentinel_role', 'redis_replica_role']
redis['bind'] = '10.0.0.3'
redis['port'] = 6379
redis['password'] = 'redis-password-goes-here'
redis['master_password'] = 'redis-password-goes-here'
redis['master_ip'] = '10.0.0.1' # primary Redis 服务器的 IP
#redis['master_port'] = 6379 # primary Redis 服务器的端口,取消注释以更改为非默认值
redis['master_name'] = 'gitlab-redis' # 必须在每个 sentinel 节点中相同
sentinel['bind'] = '10.0.0.3'
# sentinel['password'] = 'sentinel-password-goes-here' # 必须在每个 sentinel 节点中相同,取消注释以设置密码
# sentinel['port'] = 26379 # 取消注释以更改默认端口
sentinel['quorum'] = 2
# sentinel['down_after_milliseconds'] = 10000
# sentinel['failover_timeout'] = 60000

重新配置极狐GitLab 以使更改生效。

极狐GitLab 应用程序的示例配置

/etc/gitlab/gitlab.rb 中:

redis['master_name'] = 'gitlab-redis'
redis['master_password'] = 'redis-password-goes-here'
gitlab_rails['redis_sentinels'] = [
  {'host' => '10.0.0.1', 'port' => 26379},
  {'host' => '10.0.0.2', 'port' => 26379},
  {'host' => '10.0.0.3', 'port' => 26379}
]
# gitlab_rails['redis_sentinels_password'] = 'sentinel-password-goes-here' # 取消注释并将其设置为与 sentinel['password'] 相同的值

重新配置极狐GitLab 以使更改生效。

高级配置

本节涵盖超出推荐和最小配置的配置选项。

运行多个 Redis 集群

Linux 软件包支持为不同的持久性类运行单独的 Redis 和 Sentinel 实例。

类别 用途
cache 存储缓存数据。
queues 存储 Sidekiq 后台作业。
shared_state 存储会话相关和其他持久数据。
actioncable ActionCable 的 Pub/Sub 队列后端。
trace_chunks 存储 CI 日志块 数据。
rate_limiting 存储 速率限制 状态。
sessions 存储 会话
repository_cache 存储特定于存储库的缓存数据。

要使 Sentinel 运行:

  1. 根据您的需要配置不同的 Redis/Sentinels 实例。
  2. 对于每个 Rails 应用程序实例,编辑其 /etc/gitlab/gitlab.rb 文件:

    gitlab_rails['redis_cache_instance'] = REDIS_CACHE_URL
    gitlab_rails['redis_queues_instance'] = REDIS_QUEUES_URL
    gitlab_rails['redis_shared_state_instance'] = REDIS_SHARED_STATE_URL
    gitlab_rails['redis_actioncable_instance'] = REDIS_ACTIONCABLE_URL
    gitlab_rails['redis_trace_chunks_instance'] = REDIS_TRACE_CHUNKS_URL
    gitlab_rails['redis_rate_limiting_instance'] = REDIS_RATE_LIMITING_URL
    gitlab_rails['redis_sessions_instance'] = REDIS_SESSIONS_URL
    gitlab_rails['redis_repository_cache_instance'] = REDIS_REPOSITORY_CACHE_URL
    
    # 配置 Sentinels
    gitlab_rails['redis_cache_sentinels'] = [
      { host: REDIS_CACHE_SENTINEL_HOST, port: 26379 },
      { host: REDIS_CACHE_SENTINEL_HOST2, port: 26379 }
    ]
    gitlab_rails['redis_queues_sentinels'] = [
      { host: REDIS_QUEUES_SENTINEL_HOST, port: 26379 },
      { host: REDIS_QUEUES_SENTINEL_HOST2, port: 26379 }
    ]
    gitlab_rails['redis_shared_state_sentinels'] = [
      { host: SHARED_STATE_SENTINEL_HOST, port: 26379 },
      { host: SHARED_STATE_SENTINEL_HOST2, port: 26379 }
    ]
    gitlab_rails['redis_actioncable_sentinels'] = [
      { host: ACTIONCABLE_SENTINEL_HOST, port: 26379 },
      { host: ACTIONCABLE_SENTINEL_HOST2, port: 26379 }
    ]
    gitlab_rails['redis_trace_chunks_sentinels'] = [
      { host: TRACE_CHUNKS_SENTINEL_HOST, port: 26379 },
      { host: TRACE_CHUNKS_SENTINEL_HOST2, port: 26379 }
    ]
    gitlab_rails['redis_rate_limiting_sentinels'] = [
      { host: RATE_LIMITING_SENTINEL_HOST, port: 26379 },
      { host: RATE_LIMITING_SENTINEL_HOST2, port: 26379 }
    ]
    gitlab_rails['redis_sessions_sentinels'] = [
      { host: SESSIONS_SENTINEL_HOST, port: 26379 },
      { host: SESSIONS_SENTINEL_HOST2, port: 26379 }
    ]
    gitlab_rails['redis_repository_cache_sentinels'] = [
      { host: REPOSITORY_CACHE_SENTINEL_HOST, port: 26379 },
      { host: REPOSITORY_CACHE_SENTINEL_HOST2, port: 26379 }
    ]
    
    # gitlab_rails['redis_cache_sentinels_password'] = 'sentinel-password-goes-here'
    # gitlab_rails['redis_queues_sentinels_password'] = 'sentinel-password-goes-here'
    # gitlab_rails['redis_shared_state_sentinels_password'] = 'sentinel-password-goes-here'
    # gitlab_rails['redis_actioncable_sentinels_password'] = 'sentinel-password-goes-here'
    # gitlab_rails['redis_trace_chunks_sentinels_password'] = 'sentinel-password-goes-here'
    # gitlab_rails['redis_rate_limiting_sentinels_password'] = 'sentinel-password-goes-here'
    # gitlab_rails['redis_sessions_sentinels_password'] = 'sentinel-password-goes-here'
    # gitlab_rails['redis_repository_cache_sentinels_password'] = 'sentinel-password-goes-here'
    
    • Redis URL 应采用以下格式:redis://:PASSWORD@SENTINEL_PRIMARY_NAME,其中:
      • PASSWORD 是 Redis 实例的明文密码。
      • SENTINEL_PRIMARY_NAME 是使用 redis['master_name'] 设置的 Sentinel primary 名称,例如 gitlab-redis-cache
  3. 保存文件并重新配置极狐GitLab 以使更改生效:

    sudo gitlab-ctl reconfigure
    

{{< alert type=”note” >}}

对于每个持久性类,极狐GitLab 默认使用在 gitlab_rails['redis_sentinels'] 中指定的配置,除非被之前描述的设置覆盖。

{{< /alert >}}

控制运行的服务

在前面的示例中,我们使用了 redis_sentinel_roleredis_master_role,这简化了配置更改的数量。

如果您想要更多控制,这里是每个角色在启用时为您自动设置的内容:

## Redis Sentinel Role
redis_sentinel_role['enable'] = true

# 启用 Sentinel 角色时,以下服务也会启用
sentinel['enable'] = true

# 以下服务被禁用
redis['enable'] = false
bootstrap['enable'] = false
nginx['enable'] = false
postgresql['enable'] = false
gitlab_rails['enable'] = false
mailroom['enable'] = false

-------

## Redis primary/replica Role
redis_master_role['enable'] = true # 仅启用其中之一
redis_replica_role['enable'] = true # 仅启用其中之一

# 启用 Redis primary 或 Replica 角色时,以下服务将启用/禁用。如果 Redis 和 Sentinel 角色组合使用,则两个服务都启用。

# 以下服务被禁用
sentinel['enable'] = false
bootstrap['enable'] = false
nginx['enable'] = false
postgresql['enable'] = false
gitlab_rails['enable'] = false
mailroom['enable'] = false

# 对于 Redis Replica 角色,还将此设置从默认的 'true' 更改为 'false':
redis['master'] = false

您可以在 gitlab_rails.rb 中找到相关属性的定义。

控制启动行为

{{< history >}}

  • 在极狐GitLab 15.10 中引入。

{{< /history >}}

要防止捆绑的 Redis 服务在启动时启动或在更改配置后重新启动:

  1. 编辑 /etc/gitlab/gitlab.rb

    redis['start_down'] = true
    
  2. 重新配置极狐GitLab:

    sudo gitlab-ctl reconfigure
    

如果您需要测试新的 replica 节点,可以将 start_down 设置为 true 并手动启动节点。在确认新的 replica 节点在 Redis 集群中工作后,将 start_down 设置为 false 并重新配置极狐GitLab,以确保节点在操作期间按预期启动和重新启动。

控制 replica 配置

{{< history >}}

  • 在极狐GitLab 15.10 中引入。

{{< /history >}}

要防止在 Redis 配置文件中呈现 replicaof 行:

  1. 编辑 /etc/gitlab/gitlab.rb

    redis['set_replicaof'] = false
    
  2. 重新配置极狐GitLab:

    sudo gitlab-ctl reconfigure
    

此设置可用于独立于其他 Redis 设置防止 Redis 节点的复制。

故障排除

请参阅 Redis 故障排除指南

进一步阅读

阅读更多:

  1. 参考架构
  2. 配置数据库
  3. 配置 NFS
  4. 配置负载均衡器