ディザスターリカバリー（Geo）手順書のプロモート

ディザスターリカバリー（Geo）プロモート手順書。

マルチノード構成のGeo計画フェイルオーバー

この手順書では、1つのセカンダリを持つマルチノードGeoサイトの計画フェイルオーバーについて説明します。次の40 RPS / 2,000ユーザーリファレンスアーキテクチャが想定されています:

%%{init: { "fontFamily": "GitLab Sans" }}%%
graph TD
   accTitle: Geo planned-failover topology (multi-node)
   accDescr: Multi-node Geo deployment for planned failover with primary and secondary sites. Each site has Rails, PostgreSQL, Gitaly, Redis, and monitoring nodes

   subgraph main[Geo multi-node deployment architecture]
      subgraph Primary[Primary site, multi-node]
         Node_1[Rails node 1]
         Node_2[Rails node 2]
         Node_3[PostgreSQL node]
         Node_4[Gitaly node]
         Node_5[Redis node]
         Node_6[Monitoring node]
      end
      subgraph Secondary[Secondary site]
         Node_7[Rails node 1]
         Node_8[Rails node 2]
         Node_9[PostgreSQL node]
         Node_10[Gitaly node]
         Node_11[Redis node]
         Node_12[Monitoring node]
      end
   end

ロードバランサーノードとオプションのNFSサーバーは、わかりやすくするために省略されています。

このガイドの結果は次のとおりです:

1. オフラインのプライマリ。
2. プロモートされたセカンダリ。これは新しいプライマリです。

対象外:

1. 古いプライマリをセカンダリとして再度追加する。
2. 新しいセカンダリの追加。

準備

セカンダリサイトの場合:

1. 左側のサイドバーの下部で、管理者を選択します。

2. 左側のサイドバーの下部にあるGeo > サイトを選択して、ステータスを確認します。レプリケートされたオブジェクト（緑色で表示）は100%に近く、失敗（赤色で表示）がないはずです。オブジェクトの大部分がレプリケートされない場合（灰色で表示）、サイトが完了するまでさらに時間をかけることを検討してください。

   

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

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

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

セカンダリサイトがまだプライマリサイトからデータをレプリケートしている場合は、不要なデータ損失を回避するために、次の手順に従ってください:

1. メンテナンスモードをプライマリサイトで有効にし、すべてのバックグラウンドジョブを停止していることを確認してください。

2. すべてのデータをレプリケートおよび検証し終わったら:

   すべてのデータが自動的にレプリケートされるわけではありません。除外されるものの詳細をご覧ください。

   1. 手動でGeoで管理されていないデータをレプリケートする場合は、最終的なレプリケーションプロセスを今すぐトリガーします。

   2. プライマリサイトの場合:

      1. 左側のサイドバーの下部で、管理者を選択します。

      2. 左側のサイドバーで、モニタリング > バックグラウンドジョブを選択します。

      3. Sidekiqダッシュボードで、Queues（キュー）を選択し、名前がgeoのものを除くすべてのキューが0になるまで待ちます。これらのキューには、ユーザーが送信した作業が含まれています。完了する前にフェイルオーバーすると、作業が失われる原因になります。

      4. 左側のサイドバーで、Geo > サイトを選択し、フェイルオーバー先のセカンダリサイトについて、次の条件が満たされるまで待ちます:

         • すべてのレプリケーションメーターが100% レプリケート、0% 失敗に達します。
         • すべての検証メーターが100%検証済み、0% 失敗に達します。
         • データベースのレプリケーションラグは0ミリ秒です。
         • Geoログカーソルが最新の状態です（0イベント遅延）。

   3. セカンダリサイトの場合:

      1. 左側のサイドバーの下部で、管理者を選択します。
      2. 左側のサイドバーで、モニタリング > バックグラウンドジョブを選択します。
      3. Sidekiqダッシュボードで、Queues（キュー）を選択し、すべてのgeoGeoキューがキューに登録されたジョブ0、実行中のジョブ0になるまで待ちます。
      4. 整合性チェックを実行するして、CIアーティファクト、LFSオブジェクト、およびファイルストレージ内のアップロードの整合性を検証します。

   この時点で、セカンダリサイトには、プライマリサイトにあるすべての最新のコピーが含まれているため、フェイルオーバー時に何も失われることはありません。

3. この最後の手順では、プライマリサイトを完全に無効にする必要があります。

   プライマリサイトがオフラインになると、プライマリサイトに保存されているデータが、セカンダリサイトにレプリケートされていない可能性があります。このデータは、続行する場合は失われたものとして扱う必要があります。

   プライマリドメインDNSレコードを更新する計画がある場合は、伝播を高速化するために、TTLを下げることができます。

   フェイルオーバーを実行する場合、書き込みが2つの異なるGitLabインスタンスで発生するスプリットブレイン状態を回避する必要があります。そのため、フェイルオーバーに備えるには、プライマリサイトを無効にする必要があります:

   • プライマリサイトへのSSHアクセス権がある場合は、GitLabを停止して無効にします:

     sudo gitlab-ctl stop

     サーバーが予期せず再起動した場合に、GitLabが再度起動しないようにします:

     sudo systemctl disable gitlab-runsvdir

     （CentOSのみ）CentOS 6以前では、マシンが再起動してもGitLabが起動しないようにすることが困難です（イシュー3058を参照）。sudo yum remove gitlab-eeでGitLabパッケージを完全にアンインストールするのが最も安全な場合があります。

     （Ubuntu 14.04 LTS）Upstart initシステムに基づく古いバージョンのUbuntuまたはその他のディストリビューションを使用している場合は、rootとしてマシンを再起動するとinitctl stop gitlab-runsvvdir && echo 'manual' > /etc/init/gitlab-runsvdir.override && initctl reload-configurationでGitLabが起動しないようにすることができます。

   • プライマリサイトへのSSHアクセス権がない場合は、マシンをオフラインにして再起動しないようにします。これを実現する方法はたくさんあるため、1つの推奨事項は避けてください。次のことを行う必要がある場合があります:

     • ロードバランサーを再構成します。
     • DNSレコードを変更します（たとえば、プライマリDNSレコードをセカンダリサイトに向けて、プライマリサイトの使用を停止します）。
     • 仮想サーバーを停止します。
     • ファイアウォールを介したトラフィックをブロックします。
     • プライマリサイトからオブジェクトストレージの権限を失効します。
     • マシンを物理的に切断します。

セカンダリサイトのプロモート

1. セカンダリサイト内のすべてのSidekiq、PostgreSQL、およびGitalyノードにSSHで接続し、次のいずれかのコマンドを実行します:

   • セカンダリサイトをプライマリにプロモートするには:

     sudo gitlab-ctl geo promote

   • セカンダリサイトをwithout any further confirmation（確認なしで）プライマリにプロモートするには:

     sudo gitlab-ctl geo promote --force

2. セカンダリサイトの各RailsノードにSSHで接続し、次のいずれかのコマンドを実行します:

   • セカンダリサイトをプライマリにプロモートするには:

     sudo gitlab-ctl geo promote

   • セカンダリサイトをwithout any further confirmation（確認なしで）プライマリにプロモートするには:

     sudo gitlab-ctl geo promote --force

3. プライマリサイトに、以前にセカンダリサイトで使用したURLを使用して接続できることを確認します。

4. 成功した場合、セカンダリサイトがプライマリサイトにプロモートされるようになりました。

次の手順

地理的な冗長性をできるだけ早く回復するには、セカンダリサイトを追加する必要があります。これを行うには、古いプライマリを新しいセカンダリとして再度追加し、オンラインに戻します。