클러스터에 대한 고가용성 복제 구성

전체 GitHub Enterprise Server 클러스터의 복제본을 별도의 데이터 센터에 구성하여 클러스터가 중복 노드에 대한 장애 조치(failover)를 하도록 허용할 수 있습니다.

이 문서의 내용

클러스터에 대한 고가용성 복제 정보

고가용성을 위해 GitHub Enterprise Server의 클러스터 배포를 구성하여 데이터 센터 또는 클라우드 지역의 중단으로부터 보호할 수 있습니다. 고가용성 구성에서 동일한 복제본 노드 집합은 활성 클러스터의 노드와 동기화됩니다. 하드웨어 또는 소프트웨어 오류가 활성 클러스터의 데이터 센터에 영향을 미치는 경우 수동으로 복제본 노드로 장애 조치(failover)하고 사용자 요청을 계속 처리하여 중단의 영향을 최소화할 수 있습니다.

고가용성 구성에서 데이터 서비스를 호스트하는 노드는 복제본 클러스터와 정기적으로 동기화됩니다. 복제본 노드는 대기 상태로 실행되며 애플리케이션을 제공하거나 사용자 요청을 처리하지 않습니다.

GitHub Enterprise Server 클러스터링에 대한 포괄적인 재해 복구 계획의 일부로 고가용성을 구성하는 것이 좋습니다. 또한 정기적인 백업을 수행하는 것이 좋습니다. 자세한 내용은 인스턴스에서 백업 구성을(를) 참조하세요.

필수 조건

하드웨어 및 소프트웨어

활성 클러스터의 각 기존 노드에 대해 동일한 하드웨어 리소스를 사용하여 두 번째 가상 머신을 프로비저닝해야 합니다. 예를 들어 클러스터에 13개의 노드가 있고 각 노드에 12개의 vCPU, 96GB RAM 및 750GB의 연결된 스토리지가 있는 경우 각각 12개의 vCPU, 96GB RAM 및 750GB의 연결된 스토리지가 있는 13개의 새 가상 머신을 프로비저닝해야 합니다.

각 새 가상 머신에서 활성 클러스터의 노드에서 실행되는 동일한 버전의 GitHub Enterprise Server를 설치합니다. 라이선스를 업로드하거나 추가 구성을 수행할 필요가 없습니다. 자세한 내용은 GitHub Enterprise Server 인스턴스 설정을(를) 참조하세요.

Note

고가용성 복제에 사용하려는 노드는 독립 실행형 GitHub Enterprise Server 인스턴스여야 합니다. 복제본 노드를 두 번째 클러스터로 초기화하지 마세요.

네트워크

프로비저닝하는 각 새 노드에 고정 IP 주소를 할당해야 하며, 연결을 수락하고 클러스터의 프런트 엔드 계층의 노드로 전달하도록 부하 분산 장치를 구성해야 합니다.

주 노드와 복제본(replica) 노드 사이 대기 시간은 70밀리초 미만이어야 합니다. 노드의 네트워크 사이에 방화벽을 구성하지 않는 것이 좋습니다. 복제본 클러스터의 노드 간 네트워크 연결에 대한 자세한 내용은 클러스터 네트워크 구성을(를) 참조하세요.

클러스터에 대한 고가용성 복제본 만들기

클러스터에 대한 가용성 복제본을 만들려면 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를 사용하여 클러스터의 전반적인 상태를 검토할 수 있습니다. 자세한 내용은 명령줄 유틸리티을(를) 참조하세요.

장애 조치(failover) 후 고가용성 복제 다시 구성

클러스터의 활성 노드에서 클러스터의 복제본 노드로 장애 조치(failover)한 후 두 가지 방법 중 하나로 고가용성을 재구성할 수 있습니다. 선택하는 방법은 장애 조치(failover)한 이유와 원래 활성 노드의 상태에 따라 달라집니다.

  • 보조 데이터 센터의 각 새 활성 노드에 대해 새 복제본 노드 집합을 프로비저닝하고 구성합니다.
  • 원래 활성 노드를 새 복제본 노드로 사용합니다.

고가용성을 다시 구성하는 프로세스는 고가용성을 초기 구성하는 프로세스와 동일합니다. 자세한 내용은 클러스터에 대한 고가용성 복제본 만들기를 참조하세요.

원래 활성 노드를 사용하는 경우 고가용성을 재구성한 후 노드에서 유지 관리 모드를 설정 해제해야 합니다. 자세한 내용은 유지 관리 모드 사용 설정 및 예약을(를) 참조하세요.

클러스터에 대한 고가용성 복제를 사용하지 않도록 설정

ghe-cluster-repl-teardown 유틸리티를 사용하는 GitHub Enterprise Server의 클러스터 배포를 위한 복제본 노드로 복제를 중지할 수 있습니다. 또는 수동으로 복제본을 사용하지 않도록 설정할 수 있습니다.{ % else %}.

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