LinuxパッケージによるRedisのレプリケーションとフェイルオーバー

このドキュメントはLinuxパッケージ向けです。バンドルされていない独自のRedisを使用するには、独自のインスタンスを提供するRedisのレプリケーションとフェイルオーバーを参照してください。

Redisの専門用語では、primary はmaster と呼ばれます。このドキュメントでは、必要なmaster設定を除き master、primary を代わりに使用します。

スケーラブルな環境でRedis を使用するには、プライマリxレプリカのトポロジーを使用し、Redis Sentinelサービスを使用してフェイルオーバー手順を監視し、自動的に開始します。

RedisをSentinelと併用する場合は認証が必要です。詳細はRedisセキュリティのドキュメントを参照してください。Redisサービスのセキュリティを確保するために、Redisパスワードと厳格なファイアウォールルールを組み合わせて使用することをお勧めします。RedisをGitLabで設定する前にRedis Sentinelのドキュメントを読み、トポロジーとアーキテクチャを完全に理解することを強くお勧めします。

RedisとRedis Sentinelをレプリケートされたトポロジーで設定する詳細に入る前に、このドキュメント全体を一度読んで、コンポーネントがどのように結びついているかをよりよく理解するようにしてください。

少なくとも3 の独立したマシン（物理マシン、または個別の物理マシンで動作するVM）が必要です。すべてのプライマリRedisインスタンスとレプリカRedisインスタンスが異なるマシンで実行されることが不可欠です。特定の方法でマシンのプロビジョニングに失敗すると、共有環境でイシューが発生した場合、セットアップ全体がダウンする可能性があります。

プライマリまたはレプリカのRedisインスタンスと並行してSentinelを実行しても問題ありません。ただし、同じマシンに複数のSentinelを置くべきではありません。

RedisとSentinel、そしてGitLabインスタンス間の接続を冗長化する必要があります。

スケールされた環境でRedisを実行するには、いくつかのことが必要です：

  • 複数のRedisインスタンス
  • プライマリxレプリカのトポロジーでRedisを実行
  • 複数のSentinelインスタンス
  • すべてのSentinelとRedisのインスタンスに対するアプリケーションのサポートと可視性

Redis SentinelはHA環境で最も重要なタスクを処理することができ、それはダウンタイムを最小限に抑えてサーバーをオンラインに保つことです。Redis Sentinel：

  • プライマリと レプリカのインスタンスを監視して、それらが利用可能かどうかを確認します。
  • プライマリに障害が発生した場合、レプリカを プライマリに昇格させます。
  • 障害が発生したプライマリがオンラインに復帰すると、プライマリを レプリカにデモート（データ・パーティショニングの防止）
  • 常に現在のプライマリ・サーバに接続するようアプリケーションからクエリ可能

プライマリが応答しなかった場合、タイムアウトと再接続（新しいプライマリを Sentinelにクエリする）を処理するのはアプリケーションの責任です（私たちの場合はGitLab）。

Sentinelを正しく設定する方法をよりよく理解するために、まずRedis Sentinelのドキュメントを読んでください。正しく設定しないとデータが失われたり、クラスター全体がダウンしてフェイルオーバーが無効になったりする可能性があります。

最小限のセットアップのためには、Linuxパッケージを3 、Redisと Sentinelの両方を備えた独立したマシンにインストールする必要があります：

  • Redis プライマリ + Sentinel
  • Redisレプリカ＋センチネル
  • Redisレプリカ＋センチネル

なぜノードの数が多いのか、どこから来るのか、よくわからない場合や理解できない場合は、Redisのセットアップの概要と Sentinelのセットアップの概要をお読みください。

より多くの障害に耐えられる推奨セットアップのためには、Redisと Sentinelの両方で、5 独立したマシンにLinuxパッケージをインストールする必要があります：

  • Redis プライマリ + Sentinel
  • Redisレプリカ＋センチネル
  • Redisレプリカ＋センチネル
  • Redisレプリカ＋センチネル
  • Redisレプリカ＋センチネル

Redisのセットアップ概要

少なくとも3 Redis サーバー（1 プライマリ、2 レプリカ）が必要で、それぞれ独立したマシン上にある必要があります（上記の説明を参照）。

Redisノードを追加することも可能で、より多くのノードがダウンした場合に役立ちます。オンラインになっているノードが2 しかない場合、フェイルオーバーは開始されません。

例として、6 Redisノードがある場合、同時にダウンできるのは最大3 。

Sentinelノードには異なる要件があります。同じRedisマシンでホストする場合は、プロビジョニングするノードの量を計算するときにその制限を考慮する必要があるかもしれません。詳細については、Sentinelセットアップの概要ドキュメントを参照してください。

フェイルオーバーの状況では、どのレプリカでもSentinelサーバによって新しいプライマリとして昇格させることができるため、すべてのRedisノードは同じ方法で、同じようなサーバスペックで設定する必要があります。

レプリケーションには認証が必要なので、すべてのRedisノードとSentinelを保護するパスワードを定義する必要があります。すべてのインスタンスが同じパスワードを共有し、すべてのインスタンスがネットワーク上で相互に通信できる必要があります。

センチネルのセットアップの概要

Sentinelsは他のSentinelsとRedisノードの両方を監視します。Redisノードが応答していないことをSentinelが検出すると、他のSentinelにノードの状態を通知します。フェイルオーバーを開始するには、Sentinelsが_クォーラム_（ノードが停止していることに同意するSentinelsの最小数）に達する必要があります。

クォーラムが満たされるたびに、すべての既知のSentinelノードの大多数が利用可能で到達可能である必要があります：

  • 新しいプライマリを昇格させます。
  • 他のレプリカを再設定し、新しいプライマリを指すようにします。
  • 他のすべてのSentinelピアに新しいプライマリをアナウンスします。
  • 古いプライマリを再構成し、オンラインに戻ったらレプリカに降格します。

Redis Sentinelサーバは少なくとも3 、それぞれ独立したマシン（独立して故障すると思われる）に設置する必要があり、理想的には地理的に異なる場所に設置する必要があります。

他のRedisサーバーを設定した同じマシンに設定することもできますが、ノード全体がダウンすると、SentinelとRedisインスタンスの両方が失われることを理解してください。

コンセンサスアルゴリズムが障害の場合に有効であるためには、センチネルの数は常に奇数であることが理想的です。

3 ノードのトポロジーでは、1 センチネルノードがダウンしても大丈夫です。大多数のセンチネルがダウンするたびに、ネットワークパーティション保護が破壊的アクションを防ぎ、フェイルオーバーは開始されません。

以下に例を示します：

  • 5 または6 のセンチネルでは、フェイルオーバー開始のために最大2 がダウンする可能性があります。
  • 7 センチネルでは、最大3 ノードがダウンできます。

コンセンサスが得られない場合、リーダー選挙は投票ラウンドに失敗することがあります（上記の奇数ノードの要件を参照）。その場合、sentinel['failover_timeout'] で定義された時間（ミリ秒単位）の後に、新しい試みが行われます。

sentinel['failover_timeout'] sentinel['failover_timeout'] がどこで定義されているかは後で説明します。

failover_timeout 変数にはさまざまな使用例があります。公式ドキュメントによると

  • 指定されたSentinelによって同じプライマリに対して前回のフェイルオーバーが試行された後、フェイルオーバーの再スタートに必要な時間は、フェイルオーバーのタイムアウトの2倍です。

  • Sentinelの現在の設定に従って間違ったプライマリにレプリケーションしているレプリカが、正しいプライマリにレプリケーションするために必要な時間は、フェイルオーバーのタイムアウトと同じです（Sentinelが設定ミスを検出した時点からのカウント）。

  • 既に進行中でありながら、設定変更が行われなかったフェイルオーバーをキャンセルするのに必要な時間（昇格させたレプリカによってまだ認識されていないREPLICAOF NO ONE）。

  • 進行中のフェイルオーバーで、すべてのレプリカが新しいプライマリのレプリカとして再構成されるまでの最大待機時間。しかし、この時間が経過しても、レプリカはSentinelsによって再構成されますが、指定されたとおりの正確なParallels-syncsの進行ではありません。

Redisの設定

このセクションでは、新しいRedisインスタンスをインストールしてセットアップします。

GitLabとそのすべてのコンポーネントをゼロからインストールしたものとします。すでにRedisをインストールして動かしている場合は、シングルマシンのインストールから切り替える方法を読んでください。

note
Redisノード（プライマリとレプリカの両方）には、redis['password'] で定義された同じパスワードが必要です。フェイルオーバー中、Sentinelsはいつでもノードを再構成し、そのステータスをプライマリからレプリカに、またはその逆に変更することができます。

要件

Redisのセットアップに必要な要件は以下のとおりです：

  1. 推奨されるセットアップのセクションで指定されているように、最低限必要な数のインスタンスをプロビジョニングします。
  2. RedisやRedis SentinelをGitLabアプリケーションが稼働している同じマシンにインストールすることは、HA設定が弱くなるためお勧めしません。しかし、RedisとSentinelを同じマシンにインストールすることは可能です。
  3. すべてのRedisノードが互いに通信でき、Redisポート（6379 ）およびSentinelポート（26379）で着信接続を受け付ける必要があります（デフォルトのポートを変更しない限り）。
  4. GitLabアプリケーションをホストするサーバーはRedisノードにアクセスできなければなりません。
  5. ファイアウォールを使用して、外部ネットワーク（インターネット）からのアクセスからノードを保護します。

既存のシングルマシンインストールからの切り替え

すでに GitLab をシングルマシンでインストールしている場合は、Redis インスタンスを停止する前にまずこのマシンからレプリケーションを行う必要があります。

あなたのシングルマシンのインストールが最初のプライマリとなり、3 他のマシンはこのマシンを指すレプリカとして設定しなければなりません。

レプリケーションが追いついたら、シングルマシンインストールのサービスを停止して、プライマリを新しいノードの1つにローテーションする必要があります。

必要な設定を変更し、新しいノードを再起動します。

シングルインストールでRedisを無効にするには、/etc/gitlab/gitlab.rb を編集します：

redis['enable'] = false

最初にレプリケーションに失敗すると、データ（未処理のバックグラウンドジョブ）が失われる可能性があります。

ステップ 1.プライマリRedisインスタンスの設定

  1. プライマリRedisサーバにSSH接続します。
  2. GitLabのダウンロードページから、ステップ1と2を使って必要なLinuxパッケージをダウンロードし、インストールします。
    • 現在のインストールと同じバージョン、同じタイプ（Community、Enterprise エディション）の Linux パッケージを正しく選択してください。
    • ダウンロードページの他のステップは完了しないでください。

  3. /etc/gitlab/gitlab.rb を編集し、内部を追加します：

    # Specify server role as 'redis_master_role'
roles ['redis_master_role']
   
# IP address pointing to a local IP that the other machines can reach to.
# You can also set bind to '0.0.0.0' which listen in all interfaces.
# If you really need to bind to an external accessible IP, make
# sure you add extra firewall rules to prevent unauthorized access.
redis['bind'] = '10.0.0.1'
   
# Define a port so Redis can listen for TCP requests which allows other
# machines to connect to it.
redis['port'] = 6379
   
# Set up password authentication for Redis (use the same password in all nodes).
redis['password'] = 'redis-password-goes-here'

  4. プライマリのGitLabアプリケーションサーバーだけがマイグレーションを処理します。アップグレード時にデータベースのマイグレーションが実行されないようにするには、/etc/gitlab/gitlab.rb ファイルに以下の設定を追加してください：

    gitlab_rails['auto_migrate'] = false
  5. 変更を有効にするには、GitLabを再設定してください。
note
sentinelやRedisのように複数のロールを指定することができます：roles ['redis_sentinel_role', 'redis_master_role'].ロールについてもっと読む

ステップ 2.レプリカRedisインスタンスの設定

  1. レプリカRedisサーバーにSSH接続します。
  2. GitLabのダウンロードページから、ステップ1と2を使って必要なLinuxパッケージをダウンロードし、インストールします。
    • 現在のインストールと同じバージョン、同じタイプ（Community、Enterprise エディション）の Linux パッケージを正しく選択してください。
    • ダウンロードページの他のステップは完了しないでください。

  3. /etc/gitlab/gitlab.rb を編集し、内部を追加します：

    # Specify server role as 'redis_replica_role'
roles ['redis_replica_role']
   
# IP address pointing to a local IP that the other machines can reach to.
# You can also set bind to '0.0.0.0' which listen in all interfaces.
# If you really need to bind to an external accessible IP, make
# sure you add extra firewall rules to prevent unauthorized access.
redis['bind'] = '10.0.0.2'
   
# Define a port so Redis can listen for TCP requests which allows other
# machines to connect to it.
redis['port'] = 6379
   
# The same password for Redis authentication you set up for the primary node.
redis['password'] = 'redis-password-goes-here'
   
# The IP of the primary Redis node.
redis['master_ip'] = '10.0.0.1'
   
# Port of primary Redis server, uncomment to change to non default. Defaults
# to `6379`.
#redis['master_port'] = 6379

  4. アップグレード時に reconfigure が自動的に実行されないようにするには、以下を実行します：

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

  5. プライマリのGitLabアプリケーションサーバーだけがマイグレーションを処理します。アップグレード時にデータベースのマイグレーションが実行されないようにするには、/etc/gitlab/gitlab.rb ファイルに以下の設定を追加します：

    gitlab_rails['auto_migrate'] = false
  6. 変更を有効にするには、GitLabを再設定してください。
  7. 他のすべてのレプリカノードについて、もう一度手順を実行します。
note
sentinelやRedisのように複数のロールを指定することができます：roles ['redis_sentinel_role', 'redis_master_role'].roles ['redis_sentinel_role', 'redis_master_role']ロールについてはroles ['redis_sentinel_role', 'redis_master_role']こちらを参照してください。

ノードはSentinelsによって管理され、gitlab-ctl reconfigure 、フェイルオーバー後も同じSentinelsによって設定が復元されるため、フェイルオーバー後に/etc/gitlab/gitlab.rb 、これらの値を再度変更する必要はありません。

ステップ3.Redis Sentinelインスタンスの設定

note
Sentinelパスワード認証のサポートはGitLab 16.1で導入されました。

Redis サーバーの設定がすべて終わったので、次は Sentinel サーバーを設定しましょう。

Redisサーバーが正しく動作し、レプリケートされているかどうかわからない場合は、Sentinelのセットアップを進める前に、レプリケーションのトラブルシューティングを読んで修正してください。

少なくとも3 Redis Sentinelサーバーが必要で、それぞれ独立したマシンに設置する必要があります。他のRedisサーバーを設定したのと同じマシンに設定できます。

GitLab Enterprise Editionでは、Linuxパッケージを使って複数のマシンにSentinelデーモンをセットアップすることができます。

  1. Redis SentinelをホストしているサーバーにSSHでログインします。

  2. Sentinelsが他のRedisインスタンスと同じノードでホストされている場合、このステップは省略できます。

    GitLabのダウンロードページから、ステップ1と2を使用してLinux Enterprise Editionパッケージをダウンロードしてインストールします。 - 正しいLinuxパッケージを選択し、GitLabアプリケーションが稼働しているバージョンと同じであることを確認してください。 - ダウンロードページの他のステップは完了しないでください。

  3. /etc/gitlab/gitlab.rb を編集し、内容を追加します（Sentinelsを他のRedisインスタンスと同じノードにインストールしている場合、以下の値が重複することがあります）：

    roles ['redis_sentinel_role']
   
# Must be the same in every sentinel node
redis['master_name'] = 'gitlab-redis'
   
# The same password for Redis authentication you set up for the primary node.
redis['master_password'] = 'redis-password-goes-here'
   
# The IP of the primary Redis node.
redis['master_ip'] = '10.0.0.1'
   
# Define a port so Redis can listen for TCP requests which allows other
# machines to connect to it.
redis['port'] = 6379
   
# Port of primary Redis server, uncomment to change to non default. Defaults
# to `6379`.
#redis['master_port'] = 6379
   
## Configure Sentinel
sentinel['bind'] = '10.0.0.1'
   
## Optional password for Sentinel authentication. Defaults to no password required.
# sentinel['password'] = 'sentinel-password-goes here'
   
# Port that Sentinel listens on, uncomment to change to non default. Defaults
# to `26379`.
# sentinel['port'] = 26379
   
## Quorum must reflect the amount of voting sentinels it take to start a failover.
## Value must NOT be greater then the amount of sentinels.
##
## The quorum can be used to tune Sentinel in two ways:
## 1. If a the quorum is set to a value smaller than the majority of Sentinels
##    we deploy, we are basically making Sentinel more sensible to primary failures,
##    triggering a failover as soon as even just a minority of Sentinels is no longer
##    able to talk with the primary.
## 1. If a quorum is set to a value greater than the majority of Sentinels, we are
##    making Sentinel able to failover only when there are a very large number (larger
##    than majority) of well connected Sentinels which agree about the primary being down.s
sentinel['quorum'] = 2
   
## Consider unresponsive server down after x amount of ms.
# sentinel['down_after_milliseconds'] = 10000
   
## Specifies the failover timeout in milliseconds. It is used in many ways:
##
## - The time needed to re-start a failover after a previous failover was
##   already tried against the same primary by a given Sentinel, is two
##   times the failover timeout.
##
## - The time needed for a replica replicating to a wrong primary according
##   to a Sentinel current configuration, to be forced to replicate
##   with the right primary, is exactly the failover timeout (counting since
##   the moment a Sentinel detected the misconfiguration).
##
## - The time needed to cancel a failover that is already in progress but
##   did not produced any configuration change (REPLICAOF NO ONE yet not
##   acknowledged by the promoted replica).
##
## - The maximum time a failover in progress waits for all the replica to be
##   reconfigured as replicas of the new primary. However even after this time
##   the replicas are reconfigured by the Sentinels anyway, but not with
##   the exact parallel-syncs progression as specified.
# sentinel['failover_timeout'] = 60000

  4. アップグレード時にデータベースのマイグレーションが実行されないようにするには、以下を実行します：

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

    プライマリの GitLab アプリケーションサーバーだけがマイグレーションを処理します。

  5. 変更を有効にするには、GitLabを再設定してください。
  6. 他のすべてのSentinelノードについて、もう一度手順を実行します。

ステップ 4.GitLab アプリケーションの設定

最後に、メインのGitLabアプリケーションサーバーにRedis Sentinelsサーバーと認証情報を通知します。

Sentinelのサポートは、新規または既存のインストールでいつでも有効または無効にすることができます。GitLabアプリケーションの観点からは、必要なのはSentinelノードの正しい認証情報だけです。

全てのSentinelノードのリストは必要ありませんが、障害が発生した場合、リストアップされたノードの少なくとも一つにアクセスする必要があります。

note
以下のステップはGitLabアプリケーションサーバーで実行する必要があります。理想的には、HAセットアップのためにRedisやSentinelsがないことが望ましいです。
  1. GitLabアプリケーションがインストールされているサーバーにSSHでログインします。

  2. /etc/gitlab/gitlab.rb を編集し、以下の行を追加・変更します：

    ## Must be the same in every sentinel node
redis['master_name'] = 'gitlab-redis'
   
## The same password for Redis authentication you set up for the primary node.
redis['master_password'] = 'redis-password-goes-here'
   
## A list of sentinels with `host` and `port`
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' # uncomment and set it to the same value as in sentinel['password']
  3. 変更を有効にするには、GitLabを再設定してください。

ステップ 5.モニタリングの有効化

GitLab 12.0から導入されました。

モニタリングを有効にする場合、すべてのRedisサーバーで有効にする必要があります。

  1. 次のステップのために、Consul サーバーノードの IP アドレスまたは DNS レコードであるCONSUL_SERVER_NODES を必ず収集してください。これらはY.Y.Y.Y consul1.gitlab.example.com Z.Z.Z.Z

  2. /etc/gitlab/gitlab.rb を作成/編集し、以下の設定を追加します：

    # Enable service discovery for Prometheus
consul['enable'] = true
consul['monitoring_service_discovery'] =  true
   
# Replace placeholders
# Y.Y.Y.Y consul1.gitlab.example.com Z.Z.Z.Z
# with the addresses of the Consul server nodes
consul['configuration'] = {
   retry_join: %w(Y.Y.Y.Y consul1.gitlab.example.com Z.Z.Z.Z),
}
   
# Set the network addresses that the exporters listen on
node_exporter['listen_address'] = '0.0.0.0:9100'
redis_exporter['listen_address'] = '0.0.0.0:9121'

  3. sudo gitlab-ctl reconfigure を実行して設定をコンパイルします。

プライマリ1台、レプリカ2台、Sentinels3台の最小設定例

この例では、すべてのサーバーが10.0.0.x の範囲のIPを持つ内部ネットワークインターフェースを持ち、これらのIPを使って相互に接続できると考えます。

実際の使用では、他のマシンからの不正アクセスを防止し、外部（インターネット）からのトラフィックをブロックするために、ファイアウォールルールも設定します。

Redisセットアップの概要と Sentinelセットアップの概要のドキュメントで説明したRedis+Sentinelトポロジーと同じ3 ノードを使用します。

各マシンと割り当てられたIPのリストと説明は次のとおりです：

  • 10.0.0.1:Redisプライマリ + センチネル1
  • 10.0.0.2:Redisレプリカ1 + センチネル2
  • 10.0.0.3:Redisレプリカ2 + センチネル3
  • 10.0.0.4:GitLabアプリケーション

初期設定の後、Sentinelノードによってフェイルオーバーが開始されると、Redisノードは再設定され、プライマリノードは、新しいフェイルオーバーが再び開始されるまで、一方のノードから他方のノードへと永続的に変更されます（redis.confを含む）。

新しいセンチネルノードがプライマリの監視を開始した後、またはフェイルオーバーが別のプライマリノードを昇格させた後、最初の実行後にオーバーライドされたsentinel.conf でも同じことが起こります。

Redisプライマリとセンチネル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' # must be the same in every sentinel node
redis['master_password'] = 'redis-password-goes-here' # the same value defined in redis['password'] in the primary instance
redis['master_ip'] = '10.0.0.1' # ip of the initial primary redis instance
#redis['master_port'] = 6379 # port of the initial primary redis instance, uncomment to change to non default
sentinel['bind'] = '10.0.0.1'
# sentinel['password'] = 'sentinel-password-goes-here' # must be the same in every sentinel node, uncomment to set a password
# sentinel['port'] = 26379 # uncomment to change default port
sentinel['quorum'] = 2
# sentinel['down_after_milliseconds'] = 10000
# sentinel['failover_timeout'] = 60000

変更を有効にするには、GitLabを再設定してください。

Redisレプリカ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' # IP of primary Redis server
#redis['master_port'] = 6379 # Port of primary Redis server, uncomment to change to non default
redis['master_name'] = 'gitlab-redis' # must be the same in every sentinel node
sentinel['bind'] = '10.0.0.2'
# sentinel['password'] = 'sentinel-password-goes-here' # must be the same in every sentinel node, uncomment to set a password
# sentinel['port'] = 26379 # uncomment to change default port
sentinel['quorum'] = 2
# sentinel['down_after_milliseconds'] = 10000
# sentinel['failover_timeout'] = 60000

変更を有効にするには、GitLabを再設定してください。

Redisレプリカ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' # IP of primary Redis server
#redis['master_port'] = 6379 # Port of primary Redis server, uncomment to change to non default
redis['master_name'] = 'gitlab-redis' # must be the same in every sentinel node
sentinel['bind'] = '10.0.0.3'
# sentinel['password'] = 'sentinel-password-goes-here' # must be the same in every sentinel node, uncomment to set a password
# sentinel['port'] = 26379 # uncomment to change default port
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' # uncomment and set it to the same value as in sentinel['password']

変更を有効にするには、GitLabを再設定してください。

高度な設定

このセクションでは、推奨設定や最小設定を超える設定オプションについて説明します。

複数のRedisクラスターの実行

Linuxパッケージは、異なる永続化クラスに対して別々のRedisとSentinelインスタンスを実行することをサポートしています。

クラス目的
cacheキャッシュされたデータを保存します。
queuesSidekiqバックグラウンドジョブを保存します。
shared_stateセッション関連データおよびその他の永続データを保存します。
actioncableActionCableの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
   
# Configure the 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 のプライマリ名で、例えばgitlab-redis-cache です。

  3. ファイルを保存し、変更を有効にするために GitLab を再設定します：

    sudo gitlab-ctl reconfigure
note
各永続性クラスについて、GitLabは先に説明した設定によって上書きされない限り、gitlab_rails['redis_sentinels'] で指定された設定をデフォルトで使用します。

実行中のサービスの制御

前の例では、redis_sentinel_role とredis_master_role を使い、設定の変更を簡略化しました。

もっとコントロールしたい場合は、有効化されたときにそれぞれが自動的に設定する内容を以下に示します：

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

# When Sentinel Role is enabled, the following services are also enabled
sentinel['enable'] = true

# The following services are disabled
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 # enable only one of them
redis_replica_role['enable'] = true # enable only one of them

# When Redis primary or Replica role are enabled, the following services are
# enabled/disabled. If Redis and Sentinel roles are combined, both
# services are enabled.

# The following services are disabled
sentinel['enable'] = false
bootstrap['enable'] = false
nginx['enable'] = false
postgresql['enable'] = false
gitlab_rails['enable'] = false
mailroom['enable'] = false

# For Redis Replica role, also change this setting from default 'true' to 'false':
redis['master'] = false

関連する属性はgitlab_rails.rbで定義されています。

起動時の動作の制御

GitLab 15.10 で導入されました。

バンドルされているRedisサービスが起動時に開始したり、設定変更後に再起動したりしないようにするため：

  1. /etc/gitlab/gitlab.rb を編集します：

    redis['start_down'] = true

  2. GitLab を再設定します：

    sudo gitlab-ctl reconfigure

新しいレプリカノードをテストする必要がある場合、start_down をtrue に設定し、手動でノードを起動することができます。新しいレプリカ・ノードがRedisクラスターで動作することを確認したら、start_down をfalse に設定し、GitLabを再設定して、オペレーション中にノードが期待通りに起動・再起動することを確認します。

レプリカ設定の制御

GitLab 15.10 で導入されました。

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. ロードバランサーの設定