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

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

この記事の内容

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

高可用性に 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 インスタンスをセットアップする」をご覧ください。

Note

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

ネットワーク

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

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

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

クラスターの高可用性レプリカを作成するには、ghe-cluster-repl-bootstrap ユーティリティを使用し、ツールで詳細に説明されているフォローアップ タスクを完了します。

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

  2. 高可用性の構成を開始するには、次のコマンドを実行します。 -p フラグと -s フラグはオプションです。 フラグを使用している場合は、PRIMARY-DATACENTER と SECONDARY-DATACENTER をプライマリ データセンターとセカンダリ データセンターの名前に置き換えます。

    Note

    • 既定では、ユーティリティは cluster.conf のプライマリ データセンターの名前を使用します。
    • プライマリ データセンターの名前が定義されていない場合、ユーティリティは mona を使用します。
    • セカンダリ データセンターの名前が定義されていない場合、ユーティリティは hubot を使用します。
    Shell
    ghe-cluster-repl-bootstrap -p PRIMARY-DATACENTER -s SECONDARY-DATACENTER

  3. ユーティリティの実行後、出力と詳細な手順が表示されます。 構成を完了するには、出力のタスク一覧を完了します。

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

クラスター内のアクティブ ノードとレプリカ ノード間の初回レプリケーションには時間がかかります。 時間は、複製するデータの量と 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 のクラスター デプロイメントのレプリカ ノードへのレプリケーションを停止できます。これには ghe-cluster-repl-teardown ユーティリティを使用します。 または、レプリケーションを手動で無効にすることもできます。

ghe-cluster-repl-teardown を使用してレプリケーションを無効にする

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

  2. レプリケーションを無効にするには、次のコマンドを実行します。

    Shell
    ghe-cluster-repl-teardown

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

    Finished cluster configuration

手動でレプリケーションを無効にする

  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