ディザスターリカバリー（Geo）ジョブの手順書

プラン: Premium、Ultimate
提供形態: GitLab Self-Managed
ステータス: 実験的機能

ディザスターリカバリー（Geo）ジョブの手順書。

この手順書は実験です。完全な本番環境対応のドキュメントについては、ディザスターリカバリドキュメントを参照してください。

シングルノード構成のGeo計画フェイルオーバー

コンポーネント	設定
PostgreSQL	Linuxパッケージで管理
Geoサイト	シングルノード
セカンダリ	1

この手順書では、1つのセカンダリを持つシングルノードのGeoサイトの計画フェイルオーバーについて説明します。次の一般的なアーキテクチャを想定しています:

%%{init: { "fontFamily": "GitLab Sans" }}%%
graph TD
  accTitle: Geo planned-failover topology (single-node)
  accDescr: A single-node Geo deployment for planned failover, with one GitLab node at the primary site and one node at the secondary site.

  subgraph main[Geo single-node deployment]
    subgraph Primary[Primary site]
      Node_1[(GitLab node)]
    end
    subgraph Secondary1[Secondary site]
      Node_2[(GitLab node)]
    end
  end

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

オフラインのプライマリ。
プロモートされたセカンダリが、新しいプライマリになりました。

対象外:

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

準備

これらの手順を実行する前に、Geoレプリカをプロモートしてフェイルオーバーを実行する自動化された方法がないため、セカンダリをプロモートするためのrootアクセス権があることを確認してください。

セカンダリサイトで、管理者エリア > Geoダッシュボードに移動して、ステータスを確認します。レプリケートされたオブジェクト（緑色で表示）は100％に近く、エラー（赤色で表示）はないはずです。オブジェクトの大部分がまだレプリケートされていない場合（灰色で表示）、サイトが完了するまでもう少し時間をかけてください。

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

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

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

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

読み取り専用モードが実装されるまで、プライマリへの手動による更新を防止する必要があります。メンテナンス期間中、セカンダリサイトはプライマリサイトへの読み取り専用アクセスを必要とします:
1. スケジュールされた時間に、クラウドプロバイダーまたはサイトのファイアウォールを使用して、プライマリサイトとの間のすべてのHTTP、HTTPS、およびSSHトラフィックを、自分のIPとセカンダリサイトのIPを除き、except（ブロック）します。
  たとえば、プライマリサイトで次のコマンドを実行できます:
```
sudo iptables -A INPUT -p tcp -s <secondary_site_ip> --destination-port 22 -j ACCEPT
sudo iptables -A INPUT -p tcp -s <your_ip> --destination-port 22 -j ACCEPT
sudo iptables -A INPUT --destination-port 22 -j REJECT

sudo iptables -A INPUT -p tcp -s <secondary_site_ip> --destination-port 80 -j ACCEPT
sudo iptables -A INPUT -p tcp -s <your_ip> --destination-port 80 -j ACCEPT
sudo iptables -A INPUT --tcp-dport 80 -j REJECT

sudo iptables -A INPUT -p tcp -s <secondary_site_ip> --destination-port 443 -j ACCEPT
sudo iptables -A INPUT -p tcp -s <your_ip> --destination-port 443 -j ACCEPT
sudo iptables -A INPUT --tcp-dport 443 -j REJECT
```
  この時点から、ユーザーはプライマリサイトでデータを表示したり、変更を加えたりすることができなくなります。また、セカンダリサイトにサインインすることもできません。ただし、既存のセッションはメンテナンス期間の残りの期間動作する必要があるため、パブリックデータは全体を通してアクセス可能です。
2. 別のIPを介してブラウザでアクセスすることにより、プライマリサイトがHTTPトラフィックに対してブロックされていることを確認します。サーバーは接続を拒否する必要があります。
3. SSHリモートURLを使用して既存のGitリポジトリをプルしようとすることにより、プライマリサイトがSSH経由のGitトラフィックに対してブロックされていることを確認します。サーバーは接続を拒否する必要があります。
4. プライマリサイトで次の手順に従います:
  1. 左側のサイドバーの下部で、管理者を選択します。
  2. 左側のサイドバーで、モニタリング > バックグラウンドジョブを選択します。
  3. Sidekiqダッシュボードで、Cronを選択します。
  4. Geo以外の定期的なバックグラウンドジョブを無効にするには、Disable Allを選択します。
  5. geo_sidekiq_cron_config_worker cronジョブのEnableを選択します。このジョブは、計画的なフェイルオーバーを正常に完了するために不可欠ないくつかの他のcronジョブを再度有効にします。
すべてのデータのレプリケーションと検証を完了します:
すべてのデータが自動的にレプリケートされるわけではありません。除外されるものについて詳しくは、こちらをご覧ください。
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を選択し、すべてのgeoキューが0 queuedおよび0 runningジョブにドロップするまで待ちます。
  4. 整合性チェックを実行して、ファイルストレージ内のCIアーティファクト、LFSオブジェクト、およびアップロードの整合性を確認します。
この時点で、セカンダリサイトには、プライマリサイトにあるすべての最新のコピーが含まれているため、フェイルオーバー時に何も失われません。
この最後のステップでは、プライマリサイトを完全に無効にする必要があります。
プライマリサイトがオフラインになると、プライマリサイトに保存されているデータがセカンダリサイトにレプリケートされていない可能性があります。続行する場合は、このデータは失われたものとして扱う必要があります。
プライマリドメインDNSレコードを更新する予定がある場合は、伝播を高速化するために、今すぐTTLを短くすることをお勧めします。
フェイルオーバーを実行する場合、2つの異なるGitLabインスタンスで書き込みが発生するスプリットブレイン状態を回避する必要があります。そのため、フェイルオーバーに備えるには、プライマリサイトを無効にする必要があります:
- プライマリサイトへのSSHアクセスがある場合は、GitLabを停止して無効にします:
```
sudo gitlab-ctl stop
```
  サーバーが予期せず再起動した場合、GitLabが再び起動しないようにします:
```
sudo systemctl disable gitlab-runsvdir
```
  （CentOS only（CentOSのみ））CentOS 6以前では、マシンの再起動が利用できない場合、GitLabが起動するのを防ぐ簡単な方法はありません（イシュー3058を参照）。sudo yum remove gitlab-eeを使用して、GitLabパッケージを完全にアンインストールするのが最も安全な場合があります。
  （Ubuntu 14.04 LTS）Upstart initシステムに基づく古いバージョンのUbuntuまたはその他のディストリビューションを使用している場合は、rootとしてマシンが再起動した場合、GitLabが起動しないようにすることができます。initctl stop gitlab-runsvvdir && echo 'manual' > /etc/init/gitlab-runsvdir.override && initctl reload-configuration。
- プライマリサイトへのSSHアクセスがない場合は、マシンをオフラインにして再起動しないようにします。これを達成するために好む方法が多数あるため、単一の推奨事項は避けています。必要に応じて:
  - ロードバランサーを再構成します。
  - DNSレコードを変更します（たとえば、プライマリDNSレコードをセカンダリサイトにポイントして、プライマリサイトの使用を停止します）。
  - 仮想サーバーを停止します。
  - ファイアウォールを介してトラフィックをブロックします。
  - プライマリサイトからオブジェクトストレージの権限を失効する。
  - マシンを物理的に切断します。

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

セカンダリのプロモート時に、以下に注意してください:

新しいセカンダリをこの時追加しないでください。新しいセカンダリを追加する場合は、セカンダリをプライマリにプロモートするプロセス全体を完了した後に行います。
このプロセス中にActiveRecord::RecordInvalid: Validation failed: Name has already been takenエラーが発生した場合は、トラブルシューティングのアドバイスをお読みください。

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

セカンダリサイトにSSHでログインし、次のいずれかのコマンドを実行します:
- セカンダリサイトをプライマリにプロモートするには:
```
sudo gitlab-ctl geo promote
```
- without any further confirmation（それ以上の確認なしに）セカンダリサイトをプライマリにプロモートするには:
```
sudo gitlab-ctl geo promote --force
```
以前にセカンダリサイトに使用したURLを使用して、新しくプロモートされたプライマリサイトに接続できることを確認します。
成功した場合、セカンダリサイトがプライマリサイトにプロモートされました。

次の手順

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