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
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 へのデータの提供」をご覧ください。