計画的フェイルオーバーのためのディザスタリカバリ

ディザスタリカバリの主なユースケースは、計画外の障害発生時にビジネスの継続性を確保することですが、計画的なフェイルオーバーと併用することで、長時間のダウンタイムなしにGitLabインスタンスをリージョン間でマイグレーションすることができます。

Geoサイト間のレプリケーションは非同期であるため、計画的フェイルオーバーにはプライマリサイトへの更新がブロックされるメンテナンスウィンドウが必要です。このウィンドウの長さは、レプリケーションの容量によって決まります。セカンダリサイトが プライマリサイトと完全に同期されると、データを失うことなくフェイルオーバーを行うことができます。

このドキュメントでは、すでに Geo が完全に設定され、機能していることを前提としています。作業を進める前に、このドキュメントとディザスタリカバリフェイルオーバーのドキュメントをすべてお読みください。計画的なフェイルオーバーは重要なオペレーションであり、間違って実行するとデータ損失の危険性が高くなります。必要な手順に慣れ、正確に実行できるという高い自信が持てるようになるまで、手順のリハーサルを行うことを検討してください。

すべてのデータが自動的に複製されるわけではありません

GeoがサポートしていないGitLabの機能を使用している場合、セカンダリサイトにその機能に関連するデータの最新コピーがあることを確認するために、別途準備をする必要があります。これにより、必要な定期メンテナンス期間が大幅に延びる可能性があります。

ファイルに保存されているデータについて、この期間をできるだけ短く保つための一般的な戦略は、rsync データの転送を rsync使用することです。rsync 初回は rsyncメンテナンスウィンドウの前に実行することができます。その後のrsync（メンテナンスウィンドウ内での最終的な転送を含む）は、プライマリサイトと セカンダリサイトの間で変更点のみを転送します。

Git リポジトリを中心とした、rsync を効果的に使うための戦略は、moving repositoriesのドキュメントに記載されています。これらの戦略は、他のファイルベースのデータにも適用することができます。

コンテナレジストリ

デフォルトでは、コンテナレジストリはセカンダリサイトに自動的にレプリケートされないため、手動で設定する必要があります。

コンテナレジストリに現在のプライマリサイトの内部ストレージを使用している場合は、フェイルオーバー先のセカンダリサイトにコンテナレジストリオブジェクトをrsync できます：

# Run from the secondary site
rsync --archive --perms --delete root@<geo-primary>:/var/opt/gitlab/gitlab-rails/shared/registry/. /var/opt/gitlab/gitlab-rails/shared/registry

または、プライマリサイトのコンテナレジストリをバックアップして、セカンダリサイトにリストアすることもできます：

  1. プライマリ・サイトでレジストリのみをバックアップし、特定のディレクトリをバックアップから除外します：

    # Create a backup in the /var/opt/gitlab/backups folder
sudo gitlab-backup create SKIP=db,uploads,builds,artifacts,lfs,terraform_state,pages,repositories,packages

  2. プライマリ・サイトから生成されたバックアップtarボールをセカンダリ・サイトの/var/opt/gitlab/backups フォルダにコピーします。

  3. セカンダリサイトで、Restore GitLabdocumentationに従ってレジストリをリストアします。

プリフライトチェック

note
GitLab 13.7以前では、同期するアイテムがゼロのデータ型がある場合、レプリケーションが実際に最新であってもこのコマンドはERROR - Replication is not up-to-date 。このバグはGitLab 13.8以降で修正されました。

このコマンドを実行すると、すべてのプリフライトチェックがリストアップされ、計画的なフェイルオーバーをスケジューリングする前にレプリケーションと検証が完了しているかどうかが自動的にチェックされ、プロセスがスムーズに行われるようになります：

gitlab-ctl promotion-preflight-checks

各ステップについて、以下で詳しく説明します。

DNS TTL

プライマリドメインのDNSレコードを更新する予定がある場合、DNSの変更を迅速に伝搬させるためにTTLを低くメンテナーすることをお勧めします。

オブジェクトストレージ

大規模なGitLabインストールを行っている場合や、ダウンタイムを許容できない場合は、計画的なフェイルオーバーをスケジュールする前に オブジェクトストレージへのマイグレーションを検討してください。そうすることで、メンテナンスウィンドウの長さと、計画的なフェイルオーバーの失敗によるデータ損失のリスクの両方を減らすことができます。

GitLab 15.1では、オプションでセカンダリサイトのObject StorageのレプリケーションをGitLabに管理させることができます。詳しくは、オブジェクトストレージのレプリケーションをご覧ください。

各セカンダリサイトの設定のレビュー

データベース設定は自動的にセカンダリサイトに複製されますが、/etc/gitlab/gitlab.rb ファイルは手動で設定する必要があり、サイトによって異なります。Mattermost や OAuth、LDAP インテグレーションなどの機能が、プライマリサイトでは有効で、セカンダリサイトでは有効でない場合、フェイルオーバー時に失われます。

両方のサイトの/etc/gitlab/gitlab.rb ファイルをレビューし、計画的なフェイルオーバーをスケジュールする前に、 セカンダリサイトが プライマリサイトのすべてをサポートしていることを確認します。

システム・チェックの実行

プライマリサイトと セカンダリサイトの両方で以下を実行します：

gitlab-rake gitlab:check
gitlab-rake gitlab:geo:check

いずれかのサイトで障害がレポーターされた場合は、計画的なフェイルオーバーをスケジュールする前に解決する必要があります。

ノード間でシークレットとSSHホストキーが一致していることを確認します。

SSHホストキーと/etc/gitlab/gitlab-secrets.json ファイルはすべてのノードで同一である必要があります。すべてのノードで以下を実行し、出力を比較することで確認してください：

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

ファイルが異なる場合は、手動でGitLabシークレットを複製し、必要に応じてSSHホストキーを セカンダリサイトに 複製してください。

HTTPS用に正しい証明書がインストールされていることを確認します。

プライマリ・サイトおよびプライマリ・サイトからアクセスされるすべての外部サイトが公開CA発行の証明書を使用している場合、この手順は安全に省略できます。

プライマリ・サイトがカスタム証明書または自己署名TLS証明書を使用してインバウンド接続を保護する場合、またはプライマリ・サイトがカスタム証明書または自己署名証明書を使用する外部サービスに接続する場合は、正しい証明書をセカンダリ・サイトにもインストールする必要があります。セカンダリ・サイトで カスタム証明書を使用する手順に従ってください。

Geo レプリケーションが最新であることを確認します。

メンテナンス ウィンドウは、Geo レプリケーションと検証が完全に終了するまで終了しません。ウィンドウを可能な限り短く保つため、アクティブな使用中はこれらのプロセスを可能な限り 100% に近づけるようにしてください。

セカンダリサイトで

  1. 左のサイドバーで、Search を選択するか、次のページに進んでください。
  2. Admin Areaを選択します。

  3. 左サイドバーでGeo > Sites を選択します。レプリケートされたオブジェクト（緑で表示）は 100% に近く、失敗（赤で表示）はないはずです。オブジェクトの大部分がまだレプリケートされていない場合（灰色で表示）、サイトが完了するまでにもう少し時間を与えることを検討してください。

    Replication status

レプリケートに失敗しているオブジェクトがある場合は、メンテナンス ウィンドウをスケジューリングする前に調査する必要があります。計画されたフェイルオーバーの後、レプリケートに失敗したものはすべて失われます。

Geo ステータス APIを使用して、失敗したオブジェクトとその理由をレビューできます。

レプリケーション失敗の一般的な原因は、プライマリサイトでデータが見つからないことです。このような失敗は、バックアップからデータを復元するか、見つからないデータへの参照を削除することで解決できます。

レプリケートされたデータのインテグリティの検証

このコンテンツは別の場所に移動されました。

定期メンテナンスのユーザーへの通知

プライマリサイトで

  1. 左のサイドバーで、Search を選択するか、次のページに進んでください。
  2. Admin Areaを選択します。
  3. 左サイドバーで、[メッセージ]を選択します。
  4. メンテナンスウィンドウについてユーザーに通知するメッセージを追加します。Geo > Sites]で、同期が完了するまでの推定時間を確認できます。
  5. Add broadcast messageを選択します。

プライマリサイトへの更新を防止

すべてのデータがセカンダリ・サイトにレプリケートされるようにするには、プライマリ・サイトで更新（書き込み要求）を無効にする必要があります：

  1. プライマリ・サイトで メンテナンス・モードを有効にします。
  2. 左のサイドバーで、Search を選択するか、次のページに進んでください。
  3. Admin Areaを選択します。
  4. 左サイドバーで、[監視] > [バックグラウンドジョブ]を選択します。
  5. Sidekiqダッシュボードで、[cron]を選択します。
  6. Geo 以外の定期バックグラウンドジョブを無効にするには、Disable All を選択します。
  7. geo_sidekiq_cron_config_worker cron ジョブはEnable を選択します。このジョブは、計画されたフェイルオーバーが正常に完了するために不可欠な、他のいくつかの cron ジョブを再有効化します。

すべてのデータのレプリケーションと検証の終了

  1. Geo が管理していないデータを手動でレプリケートしている場合は、今すぐ最終レプリケーション プロセスをトリガーしてください。
  2. プライマリサイトで
    1. 左のサイドバーで、Search を選択するか、次のページに進んでください。
    2. Admin Areaを選択します。
    3. 左サイドバーで、[監視] > [バックグラウンドジョブ]を選択します。
    4. Sidekiqダッシュボードで、[キュー]を選択し、名前にgeo を含むキュー以外のすべてのキューが0になるまで待ちます。これらのキューには、ユーザーによって提出された作業が含まれています。完了する前にフェイルオーバーすると、作業が失われます。

    5. 左サイドバーで、[Geo] > [サイト]を選択し、フェイルオーバー先のセカンダリサイトで以下の条件が真になるのを待ちます：

      • すべてのレプリケーション・メーターが100%レプリケート、0%フェイルに到達。
      • すべての検証メーターは100%検証され、失敗は0%です。
      • データベースのレプリケーションの遅延は0ミリ秒です。
      • Geo ログカーソルは最新です (0 イベント遅れ)。
  3. セカンダリサイトで
    1. 左のサイドバーで、Search を選択するか、次のページに進んでください。
    2. Admin Areaを選択します。
    3. 左サイドバーで、[監視] > [バックグラウンドジョブ]を選択します。
    4. Sidekiqダッシュボードで、[Queues]を選択し、すべてのgeo キューが0キューになり、実行中のジョブが0になるまで待ちます。
    5. 整合性チェックを実行して、ファイルストレージ内のCIアーティファクト、LFSオブジェクト、およびアップロードの整合性を検証します。

この時点で、セカンダリサイトには プライマリサイトのすべての最新コピーが含まれています。

セカンダリサイトを昇格させます。

レプリケーションが終了したら、セカンダリ・サイトを プライマリ・サイトに昇格させます。このプロセスにより、セカンダリサイトで短時間の停止が発生し、ユーザーは再度サインインする必要があるかもしれません。手順に正しく従えば、古いプライマリ Geo サイトはまだ無効で、代わりに新しく昇格させたサイトにユーザーのトラフィックが行くはずです。

昇格が完了すると、メンテナンスウィンドウは終了し、新しいプライマリサイトは古いサイトから分岐し始めます。この時点で問題が発生した場合、古いプライマリサイトに戻すことは可能ですが、その間に新しいプライマリサイトにアップロードされたデータが失われる可能性があります。

フェイルオーバーが完了したら、ブロードキャストメッセージを削除することを忘れないでください。

最後に、古いサイトをセカンダリとして復活させることができます。