このバージョンの GitHub Enterprise サーバーはこの日付をもって終了となりました: 2024-07-09. 重大なセキュリティの問題に対してであっても、パッチリリースは作成されません。 パフォーマンスの向上、セキュリティの向上、新機能の向上を図るために、最新バージョンの GitHub Enterprise サーバーにアップグレードしてください。 アップグレードに関するヘルプについては、GitHub Enterprise サポートにお問い合わせください。

クラスタの High Availability レプリケーションを設定する

GitHub Enterprise Server クラスター全体のレプリカを別のデータセンターに構成し、クラスターが冗長ノードにフェールオーバーできるようにします。

この記事の内容

クラスタの High Availability レプリケーションについて

注: 高可用性レプリケーションは、GitHub Enterprise Server バージョン 3.9.1 以降で使用できます。

高可用性に GitHub Enterprise Server のクラスター デプロイを構成することで、データセンターまたはクラウド リージョンの中断に対して保護できます。 高可用性構成では、レプリカ ノードの同じセットが、アクティブなクラスター内のノードと同期されます。 ハードウェアまたはソフトウェアの障害がアクティブなクラスタのデータセンターに影響を与える場合は、手動でレプリカノードにフェイルオーバーし、ユーザリクエストの処理を続行して、停止の影響を最小限に抑えることができます。

高可用性構成では、データ サービスをホストするノードは、レプリカ クラスターと定期的に同期されます。 レプリカ ノードはスタンバイで実行され、アプリケーションへのサービスや、ユーザー リクエストの処理は行われません。

GitHub Enterprise Server クラスタリングの包括的ディザスター リカバリー プランの一環として、高可用性を構成することをおすすめします。 また、定期的なバックアップを実行することをお勧めします。 詳しくは、「インスタンスでのバックアップの構成」を参照してください。

前提条件

ハードウェアとソフトウェア

アクティブなクラスタ内の既存のノードごとに、同一のハードウェアリソースを使用して2番目の仮想マシンをプロビジョニングする必要があります。 たとえば、クラスターに 13 個のノードがあり、各ノードに 12 個の vCPU、96 GB の RAM、750 GB の接続ストレージがある場合、それぞれが 12 個の vCPU、96 GB の RAM、750 GB の接続ストレージを備えた 13 個の新しい仮想マシンをプロビジョニングする必要があります。

新しい仮想マシンごとに、アクティブクラスタ内のノードで実行されているものと同じバージョンの GitHub Enterprise Server をインストールします。 ライセンスをアップロードしたり、追加の設定を実行したりする必要はありません。 詳しくは、「GitHub Enterprise Server インスタンスをセットアップする」を参照してください。

注: High Availability レプリケーションに使用する予定のノードは、スタンドアロンの GitHub Enterprise Server インスタンスである必要があります。 レプリカ ノードを 2 番目のクラスターとして初期化しないでください。

ネットワーク

プロビジョニングする新しいノードごとに静的 IP アドレスを割り当てる必要があります。また、接続を受け入れてクラスタのフロントエンド層のノードに転送するようにロードバランサを設定する必要があります。

プライマリ ノードとレプリカ ノード間の待機時間は 70 ミリ秒未満である必要があります。 ノードのネットワーク間にファイアウォールを設定することはお勧めしません。 レプリカ クラスター内のノード間のネットワーク接続の詳細については、「クラスタのネットワーク設定」を参照してください。

クラスタの High Availability レプリカを作成する

クラスターの高可用性レプリカを作成するには、次のタスクを完了する必要があります。 構成例をレビューすることもできます。

  1. アクティブ ノードをプライマリ データセンターに割り当てます。
  2. レプリカ ノードをクラスター構成ファイルに追加します。
  3. 構成例をレビューします。

1. アクティブ ノードをプライマリ データセンターに割り当てる

レプリカ ノードのセカンダリ データセンターを定義する前に、アクティブ ノードをプライマリ データセンターに割り当てていることを確認してください。

  1. クラスタ内のいずれかのノードにSSHで接続してください。 詳しくは、「管理シェル (SSH) にアクセスする」を参照してください。

  2. テキスト エディターで、/data/user/common/cluster.conf のクラスター構成ファイルを開きます。 たとえばVimを利用できます。 ファイルを編集する前に、 cluster.conf ファイルのバックアップを作成します。

    Shell
    sudo vim /data/user/common/cluster.conf

  3. クラスタのプライマリデータセンターの名前に注意します。 クラスター構成ファイルの上部にある [cluster] セクションでは、キーと値のペア primary-datacenter を使用して、プライマリ データセンターの名前を定義します。

    [cluster]
  mysql-master = HOSTNAME
  redis-master = HOSTNAME
  primary-datacenter = primary
    • 必要に応じて、primary-datacenter の値を編集して、プライマリ データセンター名をよりわかりやすい名前に変更します。

  4. クラスター構成ファイルでは、[cluster "HOSTNAME"] 見出しの下に各ノードが示されます。 各ノードの見出しの下に、新しいキー/値ペアのペアを追加して、ノードをデータセンターに割り当てます。 上記のステップ 3 と同じ値 primary-datacenter を使用します。 たとえば、既定の名前 (default) を使用する場合は、次のキーと値のペアを各ノードのセクションに追加します。

    datacenter = primary

    完了すると、クラスタ設定ファイルの各ノードのセクションは次の例のようになります。 キー/値ペアの順序は問題になりません。

    [cluster "HOSTNAME"]
  datacenter = default
  hostname = HOSTNAME
  ipv4 = IP-ADDRESS
  ...
...

    注: ステップ 3 でプライマリ データセンター名を変更した場合は、各ノードのセクションでキーと値のペア consul-datacenter を見つけ、その値を名前変更したプライマリ データセンターに変更します。 たとえば、プライマリ データセンターに primary という名前を付けた場合は、ノードごとに次のキーと値のペアを使用します。

    consul-datacenter = primary

  5. 新しい設定を適用してください。 このコマンドの完了には時間がかかる場合があるため、screen または tmux などのターミナル マルチプレクサーでコマンドを実行することをお勧めします。

     ghe-cluster-config-apply

  6. 設定の実行を終了すると、GitHub Enterprise Serverは以下のメッセージを表示します。

    Finished cluster configuration

GitHub Enterprise Server がプロンプトに戻ったら、ノードをクラスタのプライマリデータセンターに割り当てます。

2. レプリカ ノードをクラスター構成ファイルに追加する

高可用性を構成するには、クラスタ内のすべてのアクティブ ノードに対応するレプリカ ノードを定義する必要があります。 アクティブ ノードとレプリカ ノードの両方を定義する新しいクラスター構成を作成するには、次のタスクを完了します。

  • アクティブなクラスタ設定ファイルのコピーを作成します。
  • コピーを編集して、アクティブノードに対応するレプリカ ノードを定義し、プロビジョニングした新しい仮想マシンの IP アドレスを追加します。
  • クラスタ設定の変更されたコピーをアクティブな設定にマージします。
  • 新しい設定を適用してレプリケーションを開始します。

構成例については、「構成例のレビュー」を参照してください。

  1. クラスタ内のノードごとに、同じバージョンの GitHub Enterprise Server を実行して、同じ仕様で一致する仮想マシンをプロビジョニングします。 新しい各クラスターノードの IPv4 アドレスとホスト名に注意してください。 詳しい情報については、「前提条件」を参照してください。

    注: フェイルオーバー後に High Availability を再構成する場合は、代わりにプライマリ データセンターの古いノードを使用できます。

  2. クラスタ内のいずれかのノードにSSHで接続してください。 詳しくは、「管理シェル (SSH) にアクセスする」を参照してください。

  3. 既存のクラスタ設定をバックアップします。

    cp /data/user/common/cluster.conf ~/$(date +%Y-%m-%d)-cluster.conf.backup

  4. /home/admin/cluster-replica.conf などの一時的な場所に、既存のクラスター設定ファイルのコピーを作成します。

    grep -Ev "(?:|ipv|uuid)" /data/user/common/cluster.conf > ~/cluster-replica.conf

  5. 前のステップでコピーした一時クラスター構成ファイルから [cluster] セクションを削除します。

    git config -f ~/cluster-replica.conf --remove-section cluster

  6. レプリカ ノードをプロビジョニングしたセカンダリ データセンターの名前を決定してから、一時クラスター設定ファイルを新しいデータセンター名で更新します。 SECONDARY を、選んだ名前に置き換えます。

    sed -i 's/datacenter = default/datacenter = SECONDARY/g' ~/cluster-replica.conf

  7. レプリカ ノードのホスト名のパターンを決定します。

    注意: レプリカ ノードのホスト名は一意であり、対応するアクティブ ノードのホスト名とは違うものにする必要があります。

  8. ステップ 3 の一時クラスタ設定ファイルをテキストエディタで開きます。 たとえばVimを利用できます。

    sudo vim ~/cluster-replica.conf

  9. 一時クラスタ設定ファイル内の各セクションで、ノードの設定を更新します。 クラスター構成ファイルでは、[cluster "HOSTNAME"] 見出しの下に各ノードが示されます。

    • 上記のステップ 7 で選んだパターンに従って、セクション見出しの引用符で囲まれたホスト名とセクション内の hostname の値をレプリカ ノードのホスト名に変更します。
    • ipv4 という名前の新しいキーを追加し、値をレプリカ ノードの静的 IPv4 アドレスに設定します。
    • 新しいキーと値のペア replica = enabled を追加します。
    [cluster "NEW REPLICA NODE HOSTNAME"]
  ...
  hostname = NEW REPLICA NODE HOSTNAME
  ipv4 = NEW REPLICA NODE IPV4 ADDRESS
  replica = enabled
  ...
...

  10. ステップ 4 で作成した一時クラスタ設定ファイルの内容をアクティブ設定ファイルに追加します。

    cat ~/cluster-replica.conf >> /data/user/common/cluster.conf

  11. セカンダリデータセンターのプライマリ MySQL ノードと Redis ノードを指定します。 REPLICA MYSQL PRIMARY HOSTNAME と REPLICA REDIS PRIMARY HOSTNAME を、既存の MySQL および Redis プライマリと一致するようにプロビジョニングしたレプリカ ノードのホスト名に置き換えます。

    git config -f /data/user/common/cluster.conf cluster.mysql-master-replica REPLICA-MYSQL-PRIMARY-HOSTNAME
git config -f /data/user/common/cluster.conf cluster.redis-master-replica REPLICA-REDIS-PRIMARY-HOSTNAME

    警告: 続ける前に、クラスター構成ファイルを確認してください。

    • トップ階層の [cluster] セクションで、mysql-master-replica と redis-master-replica の値が、フェールオーバー後に MySQL と Redis のプライマリとして機能するセカンダリ データセンター内のレプリカ ノードに対する正しいホスト名であることを保証します。
    • [cluster "ACTIVE NODE HOSTNAME"] という名前の付いたアクティブ ノードの各セクションで、次のキーと値のペアをもう一度確認します。
      • datacenter は、最上位セクション primary-datacenter の [cluster] 値と一致する必要があります。
      • consul-datacenter は、datacenter の値と一致する必要があります。これは、最上位セクション [cluster] にある primary-datacenter の値と同じです。
    • アクティブ ノードごとに、同じロールを持つ 1 つのレプリカ ノードに対応するセクションが 1 つ存在するように構成します。 レプリカ ノードの各セクションで、各キーと値のペアを再確認します。
      • datacenter は、他のすべてのレプリカ ノードと一致している必要があります。
      • consul-datacenter は、他のすべてのレプリカ ノードと一致している必要があります。
      • hostname は、セクション見出しのホスト名と一致する必要があります。
      • ipv4 は、ノードの一意の静的 IPv4 アドレスと一致する必要があります。
      • replica は enabled として構成する必要があります。
    • 必要に応じて、使用されなくなったオフラインノードのセクションを削除してください。

    構成例を確認するには、「構成例のレビュー」を参照してください。

  12. 新しいクラスタ設定を初期化します。 このコマンドの完了には時間がかかる場合があるため、screen または tmux などのターミナル マルチプレクサーでコマンドを実行することをお勧めします。

    ghe-cluster-config-init

  13. 初期化が完了すると、GitHub Enterprise Server は次のメッセージを表示します。

    Finished cluster initialization

  14. 新しい設定を適用してください。 このコマンドの完了には時間がかかる場合があるため、screen または tmux などのターミナル マルチプレクサーでコマンドを実行することをお勧めします。

     ghe-cluster-config-apply

  15. 構成の実行が完了したら、クラスター レプリケーションが正しく設定され、動作していることを確認します。

    ghe-cluster-repl-status

  16. 設定の実行を終了すると、GitHub Enterprise Serverは以下のメッセージを表示します。

    Finished cluster configuration

  17. レプリカ ノードにフェイルオーバーした後にユーザからの接続を受け入れるロードバランサーを構成します。 詳しくは、「クラスタのネットワーク設定」を参照してください。

クラスタ内のノードの High Availability レプリケーションの設定が完了しました。 各アクティブノードは、設定とデータの複製を対応するレプリカ ノードに対して開始します。障害が発生した場合は、トラフィックをセカンダリ データセンターのロード バランサーに転送できます。 フェールオーバーの詳細については、「レプリカ クラスターへのフェールオーバーを開始する」を参照してください。

3. 構成例をレビューする

最上位の [cluster] 構成は、次の例のようになります。

[cluster]
  mysql-master = HOSTNAME-OF-ACTIVE-MYSQL-MASTER
  redis-master = HOSTNAME-OF-ACTIVE-REDIS-MASTER
  primary-datacenter = PRIMARY-DATACENTER-NAME
  mysql-master-replica = HOSTNAME-OF-REPLICA-MYSQL-MASTER
  redis-master-replica = HOSTNAME-OF-REPLICA-REDIS-MASTER
  mysql-auto-failover = false
...

クラスタのストレージ層のアクティブノードの設定は、次の例のようになります。

...
[cluster "UNIQUE ACTIVE NODE HOSTNAME"]
  datacenter = default
  hostname = UNIQUE-ACTIVE-NODE-HOSTNAME
  ipv4 = IPV4-ADDRESS
  consul-datacenter = default
  consul-server = true
  git-server = true
  pages-server = true
  mysql-server = true
  elasticsearch-server = true
  redis-server = true
  memcache-server = true
  metrics-server = true
  storage-server = true
  uuid = UUID SET AUTOMATICALLY
...

ストレージ層内の対応するレプリカ ノードの設定は、次の例のようになります。

  • 対応するアクティブ ノードとの大きな違いは太字であることです。
  • GitHub Enterprise Server は自動的に uuid の値を割り当てるため、初期化するレプリカ ノードでは、この値を定義しないようご注意ください。
  • *-server キーで定義されたサーバー ロールは、対応するアクティブ ノードと一致します。
...
[cluster "UNIQUE REPLICA NODE HOSTNAME"]
  replica = enabled
  ipv4 = IPV4 ADDRESS OF NEW VM WITH IDENTICAL RESOURCES
  datacenter = SECONDARY DATACENTER NAME
  hostname = UNIQUE REPLICA NODE HOSTNAME
  consul-datacenter = SECONDARY DATACENTER NAME
  consul-server = true
  git-server = true
  pages-server = true
  mysql-server = true
  elasticsearch-server = true
  redis-server = true
  memcache-server = true
  metrics-server = true
  storage-server = true
  uuid = DO NOT DEFINE
...

アクティブ クラスター ノードとレプリカ クラスター ノード間のレプリケーションを監視する

クラスター内のアクティブ ノードとレプリカ ノード間の初回レプリケーションには時間がかかります。 時間は、複製するデータの量と GitHub Enterprise Server のアクティビティレベルによって異なります。

GitHub Enterprise Server 管理シェルから利用できるコマンドラインツールを使用して、クラスタ内の任意のノードの進行状況を監視できます。 管理シェルの詳細については、「管理シェル (SSH) にアクセスする」を参照してください。

すべてのサービスのレプリケーションを監視するには、次のコマンドを使用します。

ghe-cluster-repl-status

ghe-cluster-status を使用すると、クラスターの全体的な正常性を確認することができます。 詳細については、「コマンド ライン ユーティリティ」を参照してください。

フェイルオーバー後の High Availability レプリケーションを再設定する

クラスターのアクティブ ノードからクラスタのレプリカ ノードにフェールオーバーした後、高可用性のレプリケーションを再設定するには、2 つの方法のうちいずれかを使用します。 選択する方法は、フェイルオーバーした理由と元のアクティブノードの状態によって異なります。

  • セカンダリ データセンターの新しいアクティブノードごとに、レプリカ ノードの新しいセットをプロビジョニングして設定します。
  • 元のアクティブ ノードを新しいレプリカ ノードとして使用します。

High Availability を再設定するプロセスは、High Availability の初期設定と同じです。 詳細については、「クラスターの High Availability レプリカを作成する」を参照してください。

元のアクティブ ノードを使用する場合は、高可用性を再構成した後、ノード上のメンテナンス モードの設定を解除する必要があります。 詳しくは、「メンテナンスモードの有効化とスケジューリング」を参照してください。

クラスタの High Availability レプリケーションを無効化する

GitHub Enterprise Server のクラスター デプロイメントのレプリカ ノードへのレプリケーションを停止できます。

  1. クラスタ内のいずれかのノードにSSHで接続してください。 詳しくは、「管理シェル (SSH) にアクセスする」を参照してください。

  2. テキスト エディターで、/data/user/common/cluster.conf のクラスター構成ファイルを開きます。 たとえばVimを利用できます。 ファイルを編集する前に、 cluster.conf ファイルのバックアップを作成します。

    Shell
    sudo vim /data/user/common/cluster.conf

  3. 最上位のセクション [cluster] で、redis-master-replica と mysql-master-replica のキーと値のペアを削除します。

  4. レプリカ ノードの各セクションを削除します。 レプリカ ノードの場合、replica は enabled として構成されます。

  5. 新しい設定を適用してください。 このコマンドの完了には時間がかかる場合があるため、screen または tmux などのターミナル マルチプレクサーでコマンドを実行することをお勧めします。

     ghe-cluster-config-apply

  6. 設定の実行を終了すると、GitHub Enterprise Serverは以下のメッセージを表示します。

    Finished cluster configuration