• すべてのデータが自動的に複製されるわけではありません
• プリフライトチェック
  • オブジェクトストレージ
  • 各セカンダリー・ノードの設定のレビュアー
  • システムチェックの実行
  • ノード間で秘密が一致するかチェック
  • Geo レプリケーションが最新であることを確認します。
  • 複製されたデータの完全性の検証
  • 定期メンテナンスのお知らせ
• プライマリ・ノードへのアップデートを防止
• 全データの複製と検証の完了
• セカンダリノードのプロモート

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

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

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

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

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

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

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

rsync を効果的に使用するためのリポジトリ中心の戦略は、moving repositoriesドキュメントに記載されています。これらの戦略は、GitLab Pages（Omnibusを使用している場合は、/var/opt/gitlab/gitlab-rails/shared/pages ）のような他のファイルベースのデータで使用するために適応させることができます。

プリフライトチェック

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

gitlab-ctl promotion-preflight-checks

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

オブジェクトストレージ

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

GitLab 12.4では、オプションでGitLabにセカンダリノードのObject Storageのレプリケーションを管理させることができます。 詳細については、Object Storageのレプリケーションをご覧ください。

各セカンダリー・ノードの設定のレビュアー

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

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

システムチェックの実行

プライマリ・ノードと セカンダリ・ノードの両方で以下を実行します：

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

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

ノード間で秘密が一致するかチェック

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

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

ファイルが異なる場合は、セカンダリ・ノードのコンテンツをプライマリ・ノードのコンテンツに置き換えます。

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

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

セカンダリノードの Admin Area > Geoダッシュボードに移動し、ステータスをレビュアーします。 レプリケートされたオブジェクト（緑で表示）は100%に近く、失敗（赤で表示）はないはずです。 オブジェクトの大部分がまだレプリケートされていない場合（灰色で表示）は、ノードが完了するまでにもう少し時間がかかることを考慮してください。

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

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

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

複製されたデータの完全性の検証

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

定期メンテナンスのお知らせ

プライマリノードで、 Admin Area > Messagesに移動し、ブロードキャストメッセージを追加します。admin} Admin Area > Geoで、同期が完了するまでの時間を見積もることができます。 メッセージの例は以下の通りです：

UTC XX:XXに定期メンテナンスが行われます。 1時間以内に終了する予定です。

プライマリ・ノードへのアップデートを防止

読み取り専用モードが実装されるまでは、更新が手動で行われないようにする必要があります。セカンダリノードでは、メンテナンスウィンドウ中もプライマリノードへの読み取り専用アクセスが必要であることに注意してください。

1. 予定時刻になったら、クラウドプロバイダーまたはノードのファイアウォールを使用して、プライマリノードとの間で、自分のIPとセカンダリノードのIPを除くすべてのHTTP、HTTPS、SSHトラフィックをブロックします。

   例えば、プライマリノードを構成するサーバ上で以下のコマンドを実行します：

   sudo iptables -A INPUT -p tcp -s <secondary_node_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_node_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_node_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. プライマリ・ノードがHTTPトラフィックをブロックしていることを、別のIP経由でブラウザにアクセスして確認します。 サーバーは接続を拒否するはずです。

3. SSHリモートURLで既存のGitリポジトリをプルしようとして、プライマリノードがSSHトラフィックを介してGitにブロックされていることを確認します。 サーバーは接続を拒否するはずです。

4. 管理者] 管理領域 >[監視] > [バックグラウンドジョブ] > [Cron] に移動し、Disable Allを押してから、geo_sidekiq_cron_config_worker cron ジョブに対してEnable を押して、プライマリノードでGeo 以外の定期的なバックグラウンドジョブを無効にします。このジョブは、計画されたフェイルオーバーを正常に完了するために不可欠な他のいくつかの cron ジョブを再度有効にします。

全データの複製と検証の完了

1. Geo が管理していないデータを手動でレプリケートしている場合は、今すぐ最終レプリケーション処理を開始してください。
2. プライマリノード上で、 Admin Area > Monitoring > Background Jobs > Queuesに移動し、名前にgeo を含むキュー以外のすべてのキューが0になるまで待ちます。これらのキューには、ユーザによって投入されたジョブが含まれています。完了する前にフェイルオーバーすると、ジョブが失われます。

3. プライマリノードで Admin Area > {location-dot }に移動し、フェイルオーバー先のセカンダリノードで以下の条件が真になるのを待ちます：

   • すべてのレプリケーションメーターは100%複製され、失敗は0%です。
   • すべての検証メーターは100％検証され、失敗は0％に達します。
   • データベースのレプリケーション・ラグは0msです。
   • Geoログカーソルは最新です（0イベント遅れ）。
4. セカンダリノードで、 Admin Area > Monitoring > Background Jobs > Queuesに移動し、すべてのgeo キューが0キューになり、実行中のジョブが0になるまで待ちます。
5. セカンダリノードでは、以下の手順を使用して、ファイルストレージ内のCIアーティファクト、LFSオブジェクト、およびアップロードの整合性を検証します。

この時点で、セカンダリノードにはプライマリノードが持つすべての最新コピーがコンテナとして格納されるため、フェイルオーバー時に失われるものは何もありません。

セカンダリノードのプロモート

最後に、ディザスタリカバリのドキュメントに従って、セカンダリノードを プライマリノードに昇格させます。 このプロセスにより、セカンダリノードで短時間の停止が発生し、ユーザーは再ログインが必要になる場合があります。

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

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