High Availability 設定の監視

High Availability の可観測性について

ディザスターリカバリーと補足バックアップの計画をサポートしたり、地理的に分散したユーザーのネットワークや書き込みパフォーマンスを改善したりするため、お使いの GitHub Enterprise Server インスタンスの高可用性を構成できます。詳しくは、「High Availability設定について」をご覧ください。

High Availability を構成した後は、レプリケーションの全体的な正常性と各インスタンスのレプリカノードの状態を監視することで、冗長性を事前に確保できます。インスタンスのコマンドラインユーティリティ、概要ダッシュボード、インスタンスの REST API、または Nagios などのリモート監視システムを使用できます。

High Availability を備えたインスタンスでは、複数の方法を使用してプライマリノードとレプリカノード間でデータをレプリケートします。 MySQL などのネイティブレプリケーションメカニズムをサポートするデータベースサービスは、サービスのネイティブメカニズムを使用してレプリケートします。 Git リポジトリなどの他のサービスは、GitHub Enterprise Server 用に開発されたカスタムメカニズムを使用するか、rsync などのプラットフォームツールを使用してレプリケートします。

インスタンスのレプリケーションを監視する

お使いの GitHub Enterprise Server インスタンスの既存のレプリカノードのレプリケーション状態を監視するには、ノードの管理コンソール (SSH) に接続し、ghe-repl-status コマンドラインユーティリティを実行します。詳しくは、「コマンドラインユーティリティ」をご覧ください。

インスタンスの概要ダッシュボードからレプリケーションの状態を監視することもできます。ブラウザーで次の URL に移動し、HOSTNAME をインスタンスのホスト名に置き換えます。

http(s)://HOSTNAME/setup/replication

GitHub CLI

を使用したレプリケーションの監視

GitHub CLI の gh es 拡張機能を使用して、インスタンスのレプリケーションの状態を監視できます。詳しくは、GH ES CLI の使用に関するドキュメントと「GitHub CLI を使用したインスタンスの管理」をご覧ください。

REST API を使用したレプリケーションの監視

REST API を使用して、インスタンスのレプリケーションの状態を監視できます。詳しくは、REST API ドキュメントの GitHub Enterprise Server の管理に関する記事をご覧ください。

リモートシステムからのレプリケーションの監視

ghe-repl-status コマンドラインユーティリティからの出力は、Nagios のcheck_by_ssh プラグインの期待に準拠しています。詳しくは、「コマンドラインユーティリティ」をご覧ください。

さらに、要求によって返された状態コードを次の URL に解析することで、インスタンスの可用性を監視できます。たとえば、フェールオーバー戦略の一部としてロードバランサーをデプロイする場合は、この出力を解析する正常性チェックを構成できます。詳しくは、「GitHub Enterprise Server でロードバランサを使用する」をご覧ください。

監視を構成する場所と方法に応じて、HOST をインスタンスのホスト名または個々のノードの IP アドレスに置き換えます。

http(s)://HOST/status

ユーザー要求に応答できる geo レプリケーションのアクティブノードは、状態コード 200 (OK) を返します。個々のノードまたはインスタンスのホスト名に対する要求では、次の理由により503 (サービス利用不可) エラーが返される場合があります。

個々のノードは、2 ノードの High Availability 設定のレプリカノードなどのパッシブレプリカノードです。
個々のノードは、geo レプリケーション構成の一部ですが、パッシブレプリカノードです。
インスタンスはメンテナンスモードです。詳しくは、「メンテナンスモードの有効化とスケジューリング」をご覧ください。

geo レプリケーションについて詳しくは、「Geo-replicationについて」をご覧ください。

レプリケーションの問題のトラブルシューティング

インスタンスのレプリケーションの問題をトラブルシューティングするには、レプリケーションが実行されていること、およびノードがネットワーク経由で相互に通信できることを確認します。コマンドラインユーティリティを使用して、不十分なレプリケーションを調査することもできます。

レプリケーションが実行されていない

ghe-repl-start コマンドラインユーティリティを使用して、各ノードでレプリケーションを開始する必要があります。レプリケーションが実行されていない場合は、SSH を使用して影響を受けるノードに接続し、ghe-repl-start を実行します。詳しくは、「コマンドラインユーティリティ」をご覧ください。

ノード間の通信の問題

レプリケーションでは、プライマリノードとすべてのレプリカノードがネットワーク経由で相互に通信できる必要があります。少なくとも、インスタンスのすべてのノード間の双方向通信用にポート 122/TCP および 1194/UDP が開いていることを確認してください。詳しくは、「ネットワークポート」をご覧ください。

プライマリノードとレプリカノード間の待機時間は 70 ミリ秒未満である必要があります。ノードのネットワーク間にファイアウォールを設定することはお勧めしません。ping または別のネットワーク管理ユーティリティを使用して、ノード間のネットワーク接続をテストできます。

不十分なレプリケーション

レプリカノードで ghe-repl-status コマンドラインユーティリティを実行し、Git リポジトリ、リポジトリネットワーク、またはストレージオブジェクトのレプリケーションが不十分な場合、1 つ以上のレプリカノードがプライマリノードと完全に同期されません。プライマリノードがレプリカノードと通信できない場合、またはレプリカノードがプライマリノードと通信できない場合、レプリケーション不足が発生する可能性があります。

最近、High Availability または geo レプリケーションを構成した場合、初期同期に時間がかかります。初期同期にかかる時間は、存在するデータの量とネットワークの状態によって異なります。

レプリケーションが不十分なリポジトリまたはリポジトリネットワーク
レプリケーションが不十分なストレージオブジェクト

レプリケーションが不十分なリポジトリまたはリポジトリネットワーク

特定のリポジトリのレプリケーション状態を表示するには、ノードに接続し、次のコマンドを実行し、OWNER をリポジトリの所有者に置き換え、REPOSITORY をリポジトリの名前に置き換えます。

ghe-spokesctl check OWNER/REPOSITORY
ghe-spokesctl info OWNER/REPOSITORY

または、リポジトリネットワークのレプリケーションの状態を表示する場合は、NETWORK-ID/REPOSITORY-ID をネットワーク ID とリポジトリ ID 番号に置き換えます。

ghe-spokesctl check NETWORK-ID/REPOSITORY-ID
ghe-spokesctl info NETWORK-ID/REPOSITORY-ID

レプリケーションが不十分なストレージオブジェクト

ノードに接続し、次のコマンドを実行して OID をオブジェクトの ID に置き換えることで、特定のストレージオブジェクトの状態を表示できます。

ghe-storage info OID

Getting support from GitHub

レプリケーションに関するトラブルシューティングのアドバイスを確認し、インスタンスで引き続き問題が発生する場合は、次の情報を収集してから、GitHub Enterprise サポートにアクセスしてお問い合わせください。

影響を受ける各ノードで ghe-repl-status -vv を実行し、出力をチケットにコピーします。詳しくは、「コマンドラインユーティリティ」をご覧ください。
影響を受ける各ノードで、チケットにアタッチするサポートバンドルを作成します。詳しくは、「GitHub Support へのデータの提供」をご覧ください。