レプリケーション（Geo）
- GitLab Enterprise Edition 8.9で導入されました。
- Geoをマルチノードアーキテクチャと組み合わせて使用することは、GitLab Premium10.4で一般的に利用可能 (GA) 。
Geo を使用したレプリケーションは、広範囲に分散した開発チーム向けのソリューションです。
概要
一つのGitLabインスタンスから離れた場所にいるチームにとって、大きなリポジトリのフェッチには長い時間がかかることがあります。
Geoは、GitLabインスタンスの読み込み専用のローカルインスタンスを提供します。 これにより、大規模なリポジトリのクローンやフェッチにかかる時間を短縮し、開発者をスピードアップさせることができます。
Geoの紹介ビデオについては、Introduction to GitLab Geo - GitLab Featuresをご覧ください。
ドキュメントの正しいバージョンを使っていることを確認するには、GitLab.comのこのページのソースバージョンに移動し、スイッチブランチ/タグのドロップダウンから適切なリリースを選択します。 たとえば、v11.2.3-ee.
ユースケース
Geoを導入すると、次のようなメリットがあります：
- ディストリビューション開発者が大規模なリポジトリやプロジェクトのクローン作成と取得にかかる時間を数分から数秒に短縮します。
- 開発者全員が、どこにいてもアイデアに貢献し、並行して作業できるようにします。
- プライマリ・ノードと セカンダリ・ノード間の読み取り専用負荷のバランスをとります。
さらに
- GitLabウェブインターフェイスで利用可能なあらゆるデータの読み込みに加えて、プロジェクトのクローンやフェッチに使用できます（現在の制限を参照）。
- 離れたオフィス間の低速接続を克服し、ディストリビューションチームの速度を向上させることで時間を節約します。
- 自動タスク、カスタムインテグレーション、内部ワークフローのロード時間の短縮に役立ちます。
- 災害復旧シナリオにおいて、セカンダリノードへの迅速なフェイルオーバーが可能。
- セカンダリノードへの 計画的なフェイルオーバーを可能にします。
Geoが提供します：
- 読み取り専用のセカンダリノード：1つのGitLabプライマリノードをメンテナーしつつ、ディストリビューションチームごとに読み取り専用のセカンダリノードを有効にします。
- 認証システムフック：セカンダリノードは、プライマリインスタンスからすべての認証データ（ユーザーアカウントやログインなど）を受け取ります。
- 直感的なUI:セカンダリノードは、チームが慣れ親しんだWebインターフェイスを使用します。 さらに、書き込みオペレーションをブロックし、ユーザーがセカンダリノードにいることを明確にするビジュアル通知があります。
どのように動作するか
Geo インスタンスは、あらゆるデータの読み取りに加えて、プロジェクトのクローン作成とフェッチにも使用できます。 これにより、長距離の大規模リポジトリでの作業がより高速になります。
Geoが有効な場合：
- オリジナルのインスタンスはプライマリ・ノードと呼ばれます。
- 複製された読み取り専用ノードはセカンダリ・ノードと呼ばれます。
覚えておいてください：
-
セカンダリノードは プライマリノードと通信します：
- ログイン用ユーザーデータの取得(API).
- リポジトリ、LFSオブジェクト、添付ファイル（HTTPS + JWT）を複製します。
- GitLab Premium 10.0以降、プライマリノードから セカンダリノードへの変更の通知は行われなくなりました(API)。
- セカンダリノードへの直接プッシュ（HTTPとSSHの両方、Git LFSを含む）はGitLab Premium11.3で導入されました。
- 現在の実装には限界があります。
アーキテクチャ
以下の図は、Geo の基本的なアーキテクチャを示しています。
この図では
- プライマリ・ノードと1つのセカンダリ・ノードの詳細があります。
- データベースへの書き込みはプライマリノードでのみ実行できます。セカンダリノードはPostgreSQLストリーミングレプリケーションによってデータベースの更新を受け取ります。
- LDAPサーバーが存在する場合は、災害復旧シナリオ用にレプリケートするように構成する必要があります。
-
セカンダリノードは、JWTで保護された特別な作成者を使用して、プライマリノードに対して異なるタイプの同期を実行します：
- リポジトリはGit over HTTPSでクローン/更新されます。
- 添付ファイル、LFS オブジェクト、その他のファイルは、非公開 API エンドポイントを使用して HTTPS 経由でダウンロードされます。
Gitオペレーションを行うユーザーの視点から：
- プライマリノードは完全に読み書き可能なGitLabインスタンスとして振る舞います。
- セカンダリー・ノードは読み取り専用ですが、Gitのプッシュ・オペレーションをプライマリー・ノードにプロキシします。 これにより、セカンダリー・ノード自身がプッシュ・オペレーションをサポートしているように見えます。
図を簡略化するため、必要なコンポーネントの一部を省略しています。 以下の点に注意してください：
- Git over SSH を使うには
gitlab-shellと OpenSSH が必要です。 - Git over HTTPSが必要
gitlab-workhorse.
セカンダリノードには2つの異なるPostgreSQLデータベースが必要であることに注意してください：
- メインのGitLabデータベースからデータをストリームする読み取り専用のデータベースインスタンス。
- セカンダリノードが内部で使用する別のデータベースインスタンスで、レプリケートされたデータを記録します。
セカンダリノードには、GeoLog Cursorというデーモンが追加されています。
Geoの実行要件
Geoの実行には以下が必要です：
- OpenSSH 6.9+ をサポートしているオペレーションシステム (データベースで作成者の SSH キーを高速に検索するために必要です) OpenSSH の最新版が出荷されているオペレーティングシステムは以下の通りです：
- PostgreSQL 11+、FDWサポート、ストリーミング・レプリケーション対応
- git 2.9 以上
- 全てのノードは同じGitLabバージョンでなければなりません。
さらに、GitLabの最小要件を確認してください：
- Geoの基本的な機能のために少なくともGitLab Enterprise Edition 10.0。
- 最新バージョンでより快適に。
ファイアウォールルール
次の表は、プライマリノードと セカンダリノード間で Geo が開いていなければならない基本的なポートの一覧です。
| 一次ノード | 二次ノード | プロトコル |
|---|---|---|
| 80 | 80 | HTTP |
| 443 | 443 | TCPまたはHTTPS |
| 22 | 22 | 伝送制御プロトコル |
| 5432 | PostgreSQL |
GitLabが使用するポートの一覧はPackage defaultsをご覧ください。
ライトウェイトディレクトリアクセスプロトコル
プライマリ・ノードでLDAPを使う場合は、セカンダリ・ノードにもLDAPサーバーをセットアップすることをお勧めします。 そうしないと、セカンダリ・ノードでHTTPベーシック認証を使ったGitオペレーションができなくなります。 しかし、SSHや個人アクセストークンを使ったGitオペレーションは可能です。
LDAP サービスでレプリケーションを設定する方法については、使用するソフトウ ェアやサービスによって異なります。 例えば、OpenLDAP では次のような説明があります。
Geoトラッキングデータベース
トラッキング・データベース・インスタンスは、ローカル・インスタンスのディスク上で更新が必要なものを制御するためのメタデータとして使用されます。 例えば、以下のようなものです：
- 新しいアセットをダウンロードしてください。
- 新しい LFS オブジェクトを取得します。
- 最近更新されたリポジトリから変更を取得します。
レプリケートされたデータベースインスタンスは読み取り専用であるため、各セカンダリノードにこの追加のデータベースインスタンスが必要です。トラッキングデータベースにはpostgres_fdw 拡張が必要です。
Geo ログカーソル
このデーモンは
- プライマリ・ノードから セカンダリ・データベース・インスタンスにレプリケートされたイベントのログを読み取ります。
- 実行が必要な変更で Geo Tracking Database インスタンスを更新します。
トラッキングデータベースインスタンスに更新マークが付けられると、セカンダリノードで実行されている非同期ジョブが必要なオペレーションを実行し、状態を更新します。
この新しいアーキテクチャにより、GitLabはノード間の接続性の問題に強くなりました。セカンダリノードが プライマリノードからどれだけ長い間切断されていても、すべてのイベントを正しい順序で再生し、再びプライマリノードと同期することができるからです。
セットアップ方法
これらの手順は、GitLab のインスタンスが動作していることを前提としたものです。 この手順では、以下のことを説明します：
- 既存のインスタンスをプライマリ・ノードにします。
- セカンダリノードの追加
Omnibus GitLab の使用法
Omnibus パッケージを使って GitLab をインストールした場合（強くお勧めします）：
- セカンダリノードとなるサーバーに GitLab Enterprise Edition をインストールします。 新しいセカンダリノードにアカウントを作成したりログインしたりしないでください。
- Geoのロックを解除するために、プライマリノードにGitLab Licenseをアップロードします。 ライセンスはGitLab Premium以上のものでなければなりません。
-
データベースのレプリケーション（
primary (read-write) <-> secondary (read-only)トポロジー）を設定します。 - データベース内の作成者SSHキーの高速検索を設定します。 このステップは必須で、プライマリノードと セカンダリノードの 両方で実行する必要があります。
- GitLabにプライマリノードと セカンダリノードを設定します。
- オプション：セカンダリ・ノード用にセカンダリLDAPサーバを設定します。LDAPに関する注記を参照してください。
- Geoサーバーの使用」ガイドに従ってください。
インストール後のドキュメント
セカンダリノードにGitLabをインストールして初期設定を行った後、インストール後の情報については以下のドキュメントを参照してください。
Geoの設定
Geo の設定については、Geo の設定を参照してください。
Geoの更新
Geoノードを最新のGitLabバージョンにアップデートする方法については、Geoノードのアップデートをご覧ください。
レプリケーションの一時停止と再開
GitLab Premium13.2で導入されました。
アップグレード時や計画的なフェイルオーバー時など、状況によってはプライマリとセカンダリ間のレプリケーションを一時停止することが望ましい場合があります。
レプリケーションの一時停止と再開は、セカンダリノードからコマンドラインツールを使って行います。
一時停止するには：（セカンダリーから）
gitlab-ctl geo-replication-pause
レジュメへ：（セカンダリーから）
gitlab-ctl geo-replication-resume
複数ノードに対する Geo の設定
複数ノード用の Geo の設定については、複数サーバー用のGeo を参照してください。
オブジェクトストレージを使用した Geo の設定
オブジェクトストレージを使用した Geo の設定については、オブジェクトストレージを使用したGeo を参照してください。
災害復旧
Geo を災害復旧時に使用してデータ損失を軽減し、サービスを復元する方法については、「災害復旧」を参照してください。
コンテナレジストリの複製
コンテナレジストリを複製する方法の詳細については、セカンダリノードのDockerレジストリを参照してください。
セキュリティ・レビュー
Geoセキュリティの詳細については、Geoセキュリティレビューをご覧ください。
Geoのチューニング
Geo のチューニングの詳細については、Geo のチューニングを参照してください。
場所を意識したGit URLの設定
AWS Route53 で場所を認識した Git リモート URL を設定する例については、AWS Route53 による場所を認識した Git リモート URLを参照してください。
Geoノードの削除
Geo ノードの削除の詳細については、セカンダリGeo ノードの削除を参照してください。
現在の制限
-
セカンダリノードへの直接のプッシュは、リクエストを直接処理する代わりに（HTTPの場合は）リダイレクトするか（SSHの場合は）プライマリノードへプロキシします。ただし、URIにクレデンシャルを埋め込んでGit over HTTPを使う場合を除きます。例えば、
https://user:password@secondary.tld. - プライマリ・ノードに存在し、セカンダリ・ノードには存在しないリポジトリのクローン作成、プル、プッシュ（選択的同期にプロジェクトが含まれない場合）は、SSH 経由ではサポートされていませんが、サポートが予定されています。HTTP(S) 。
- OAuthログインを行うには、プライマリ・ノードがオンラインである必要があります。 既存のセッションやgitは影響を受けません。セカンダリ・ノードがプライマリとは独立したOAuthプロバイダーを使用するためのサポートは計画中です。
- インストールには複数の手動ステップが必要で、状況によっては合わせて一時間ほどかかることもあります。 私たちはこの経験の改善に取り組んでいます。 詳しくはOmnibusGitLabissue #2978をご覧ください。
- セカンダリ・ノードでは、（ロング・ポーリングなどによる）イシュー/マージ・リクエストのリアルタイム更新は機能しません。
- 選択的同期はファイルとリポジトリにのみ適用され、その他のデータセットはセカンダリ・ノードに完全にレプリケートされるため、アクセス制御メカニズムとしては不適切です。
- フォークされたプロジェクト重複排除のためのオブジェクトプールは、プライマリノードでのみ動作し、セカンダリノードでは複製されます。
- 外部マージ・リクエストの差分がディスク上にある場合はレプリケートされず、マージ・リクエストの表示は失敗します。 ただし、オブジェクト・ストレージ内の外部 MR差分はサポートされます。 デフォルトの構成 (データベース内) は機能します。
- GitLab Runnerはセカンダリノードに登録することができません。 このサポートは将来的に予定されています。
複製・検証の制限
これらのエピック／イシューに欠けている項目を実装するための進捗状況を把握することができます：
GitLabの全データ型の完全なリストと、レプリケーションと検証の既存のサポートがあります。
よくある質問
よくある質問については、GeoFAQをご覧ください。
ログファイル
GitLab 9.5以降、Geoは構造化されたログメッセージをgeo.log ファイルに保存します。Omnibusのインストールでは、このファイルは/var/log/gitlab/gitlab-rails/geo.logにあります。
このファイルには、Geo がリポジトリとファイルの同期を試みたときの情報が含まれています。 ファイルの各行には、取り込むことができる個別の JSON エントリが含まれています。 たとえば、Elasticsearch や Splunk などです。
使用例：
{"severity":"INFO","time":"2017-08-06T05:40:16.104Z","message":"Repository update","project_id":1,"source":"repository","resync_repository":true,"resync_wiki":true,"class":"Gitlab::Geo::LogCursor::Daemon","cursor_delay_s":0.038}
このメッセージは、Geo がプロジェクト1でリポジトリの更新が必要であることを検知したことを示しています。
トラブルシューティング
トラブルシューティングの手順については、「Geoトラブルシューティング」を参照してください。
