이 버전의 GitHub Enterprise는 다음 날짜에 중단되었습니다. 2024-09-25. 중요한 보안 문제에 대해서도 패치 릴리스가 이루어지지 않습니다. 더 뛰어난 성능, 향상된 보안, 새로운 기능을 위해 최신 버전의 GitHub Enterprise Server로 업그레이드합니다. 업그레이드에 대한 도움말은 GitHub Enterprise 지원에 문의하세요.

클러스터 노드 바꾸기

GitHub Enterprise Server 클러스터에서 노드가 실패하거나 리소스가 더 많은 새 노드를 추가하려는 경우 대체할 노드를 오프라인으로 표시한 다음 새 노드를 추가합니다.

누가 이 기능을 사용할 수 있나요?

GitHub은(는) 클러스터링 자격을 결정하며 인스턴스의 라이선스 구성을 사용하도록 설정해야 합니다. 클러스터링은 신중하게 계획해야 하며 관리 오버헤드가 추가로 필요합니다. 자세한 내용은 "클러스터링 정보"을(를) 참조하세요.

이 문서의 내용

GitHub Enterprise Server 클러스터 노드 대체 정보

GitHub Enterprise Server 클러스터의 기능 노드를 대체하거나 예기치 않게 실패한 노드를 대체할 수 있습니다.

노드를 대체한 후 GitHub Enterprise Server 인스턴스은(는) 작업을 새 노드에 자동으로 분산하지 않습니다. 인스턴스가 노드 간에 작업을 밸런싱하도록 강제할 수 있습니다. 자세한 정보는 "클러스터 워크로드 리밸런싱"을(를) 참조하세요.

경고: 충돌을 방지하기 위해, 이전에 클러스터의 노드에 할당된 호스트 이름을 다시 사용하지 마세요.

기능 노드 바꾸기

클러스터의 기존 기능 노드를 대체할 수 있습니다. 예를 들어 VM(가상 머신)에 추가 CPU, 메모리 또는 스토리지 리소스를 제공할 수 있습니다.

기능 노드를 대체하려면 새 VM에 GitHub Enterprise Server 어플라이언스를 설치하고, IP 주소를 구성하고, 클러스터 구성 파일에 새 노드를 추가하고, 클러스터를 초기화하고 구성을 적용한 다음, 대체된 노드를 오프라인으로 전환합니다.

참고: 기본 MySQL 노드를 교체하는 경우, "기본 MySQL 노드 교체"를 참조하세요.

  1. 대체 노드에 고유한 호스트 이름을 사용하여 GitHub Enterprise Server를 프로비저닝하고 설치합니다.

  2. 관리 셸 또는 DHCP를 사용하여 대체 노드의 IP 주소만 구성합니다. 다른 설정은 구성하지 마세요.

  3. 모든 노드에서 새로 프로비저닝된 대체 노드를 추가하려면 cluster.conf 파일을 수정하여 실패한 노드를 제거하고 대체 노드를 추가합니다. 예를 들어 이 수정된 cluster.conf 파일은 ghe-data-node-3을 새로 프로비저닝된 노드인 ghe-replacement-data-node-3으로 바꿉니다.

    [cluster "ghe-replacement-data-node-3"]
  hostname = ghe-replacement-data-node-3
  ipv4 = 192.168.0.7
  # ipv6 = fd12:3456:789a:1::7
  consul-datacenter = PRIMARY-DATACENTER
  git-server = true
  pages-server = true
  mysql-server = true
  elasticsearch-server = true
  redis-server = true
  memcache-server = true
  metrics-server = true
  storage-server = true

    새 MySQL 복제본(replica) 노드의 데이터베이스 시드를 연기하도록 선택할 수 있습니다. 그러면 트래픽에 대한 어플라이언스를 더 빨리 열 수 있습니다. 자세한 내용은 "데이터베이스 시드 연기"을(를) 참조하세요.

  4. 수정된 cluster.conf를 사용하여 노드의 관리 셸에서 ghe-cluster-config-init를 실행합니다. 그러면 클러스터에서 새로 추가된 노드가 초기화됩니다.

  5. 동일한 노드에서 ghe-cluster-config-apply를 실행합니다. 이렇게 하면 구성 파일의 유효성이 검사되고, 클러스터의 각 노드에 복사되고, 수정된 cluster.conf 파일에 따라 각 노드가 구성됩니다.

  6. git-server, pages-server, 또는 storage-server 등의 데이터 서비스를 제공하는 노드를 오프라인으로 전환하는 경우 해당 노드를 이동하세요. 자세한 내용은 "데이터 서비스를 실행하는 클러스터 노드 이동"을(를) 참조하세요.

  7. 모든 노드에서 실패한 노드를 오프라인으로 표시하려면 관련 노드 섹션에서 클러스터 구성 파일(cluster.conf)을 수정하여 offline = true 텍스트를 포함합니다.

    예를 들어 이 수정된 cluster.conf는 ghe-data-node-3 노드를 오프라인으로 표시합니다.

    [cluster "ghe-data-node-3"]
hostname = ghe-data-node-3
offline = true
ipv4 = 192.168.0.6
# ipv6 = fd12:3456:789a:1::6

  8. 수정된 cluster.conf를 사용하여 노드의 관리 셸에서 ghe-cluster-config-apply를 실행합니다. 이렇게 하면 구성 파일의 유효성이 검사되고, 클러스터의 각 노드에 복사되며, 노드가 오프라인으로 표시됩니다.

응급 상황에서 노드 바꾸기

클러스터에서 실패한 노드를 대체할 수 있습니다. 예를 들어 소프트웨어 또는 하드웨어 문제가 노드의 가용성에 영향을 줄 수 있습니다.

참고: 기본 MySQL 노드를 교체하는 경우, "기본 MySQL 노드 교체"를 참조하세요.

긴급 상황에서 노드를 대체하려면 새 VM에 GitHub Enterprise Server 어플라이언스를 설치하고, IP 주소를 구성하고, 실패한 노드를 오프라인으로 전환하고, 구성을 적용하고, 클러스터 구성 파일에 새 노드를 추가하고, 클러스터를 초기화하고 구성을 적용하고, 필요에 따라 실패한 노드를 제거합니다.

  1. 대체 노드에 고유한 호스트 이름을 사용하여 GitHub Enterprise Server를 프로비저닝하고 설치합니다.

  2. 관리 셸 또는 DHCP를 사용하여 대체 노드의 IP 주소만 구성합니다. 다른 설정은 구성하지 마세요.

  3. 모든 노드에서 실패한 노드를 오프라인으로 표시하려면 관련 노드 섹션에서 클러스터 구성 파일(cluster.conf)을 수정하여 offline = true 텍스트를 포함합니다.

    예를 들어 이 수정된 cluster.conf는 ghe-data-node-3 노드를 오프라인으로 표시합니다.

    [cluster "ghe-data-node-3"]
hostname = ghe-data-node-3
offline = true
ipv4 = 192.168.0.6
# ipv6 = fd12:3456:789a:1::6

  4. 수정된 cluster.conf를 사용하여 노드의 관리 셸에서 ghe-cluster-config-apply를 실행합니다. 이렇게 하면 구성 파일의 유효성이 검사되고, 클러스터의 각 노드에 복사되며, 노드가 오프라인으로 표시됩니다.

  5. 모든 노드에서 새로 프로비저닝된 대체 노드를 추가하려면 cluster.conf 파일을 수정하여 실패한 노드를 제거하고 대체 노드를 추가합니다. 예를 들어 이 수정된 cluster.conf 파일은 ghe-data-node-3을 새로 프로비저닝된 노드인 ghe-replacement-data-node-3으로 바꿉니다.

    [cluster "ghe-replacement-data-node-3"]
  hostname = ghe-replacement-data-node-3
  ipv4 = 192.168.0.7
  # ipv6 = fd12:3456:789a:1::7
  consul-datacenter = PRIMARY-DATACENTER
  git-server = true
  pages-server = true
  mysql-server = true
  elasticsearch-server = true
  redis-server = true
  memcache-server = true
  metrics-server = true
  storage-server = true

    새 MySQL 복제본(replica) 노드의 데이터베이스 시드를 연기하도록 선택할 수 있습니다. 그러면 트래픽에 대한 어플라이언스를 더 빨리 열 수 있습니다. 자세한 내용은 "데이터베이스 시드 연기"을(를) 참조하세요.

  6. 기본 Redis 노드를 교체하는 경우, cluster.conf에서 redis-master 값을 교체 노드 이름으로 수정합니다.

    참고: I기본 Redis 노드가 기본 MySQL 노드이기도 한 경우, "기본 MySQL 노드 교체"를 참조하세요.

    예를 들어, 이 수정된 cluster.conf 파일은 새로 프로비저닝된 클러스터 노드 ghe-replacement-data-node-1을(를) 기본 Redis 노드로 지정합니다.

    redis-master = ghe-replacement-data-node-1

  7. 수정된 cluster.conf를 사용하여 노드의 관리 셸에서 ghe-cluster-config-init를 실행합니다. 그러면 클러스터에서 새로 추가된 노드가 초기화됩니다.

  8. 동일한 노드에서 ghe-cluster-config-apply를 실행합니다. 이렇게 하면 구성 파일의 유효성이 검사되고, 클러스터의 각 노드에 복사되고, 수정된 cluster.conf 파일에 따라 각 노드가 구성됩니다.

  9. git-server, pages-server, 또는 storage-server 등의 데이터 서비스를 제공하는 노드를 오프라인으로 전환하는 경우 해당 노드를 이동하세요. 자세한 내용은 "데이터 서비스를 실행하는 클러스터 노드 이동"을(를) 참조하세요.

기본 MySQL 노드 대체

데이터베이스 서비스를 제공하려면 클러스터에 기본 MySQL 노드와 하나 이상의 복제본(replica) MySQL 노드가 필요합니다. 자세한 내용은 "클러스터 노드 정보"을(를) 참조하세요.

기본 MySQL 노드의 VM에 더 많은 리소스를 제공하려는 경우 또는 노드에 장애가 발행하는 경우 노드를 대체할 수 있습니다. 가동 중지 시간을 최소화하려면 클러스터에 새 노드를 추가하고 MySQL 데이터를 복제한 다음 노드를 승격합니다. 승격하는 동안에는 약간의 가동 중지 시간이 필요합니다.

  1. 대체 노드에 고유한 호스트 이름을 사용하여 GitHub Enterprise Server를 프로비저닝하고 설치합니다.

  2. 관리 셸 또는 DHCP를 사용하여 대체 노드의 IP 주소만 구성합니다. 다른 설정은 구성하지 마세요.

  3. GitHub Enterprise Server 인스턴스에 연결하려면 클러스터의 노드 중 하나에 SSH합니다. 워크스테이션에서 다음 명령을 실행합니다. HOSTNAME을 노드의 호스트 이름으로 바꿉니다. 자세한 내용은 "관리 셸(SSH)에 액세스"을(를) 참조하세요.

    Shell
    ssh -p 122 admin@HOSTNAME

  4. 텍스트 편집기의 /data/user/common/cluster.conf에서 클러스터 구성 파일을 엽니다. 예를 들어 Vim을 사용할 수 있습니다. 파일을 편집하기 전에 cluster.conf 파일의 백업을 만듭니다.

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

  5. 클러스터 구성 파일에는 [cluster "HOSTNAME"] 제목 아래에 각 노드가 나열됩니다. 노드에 대한 새 제목을 추가하고 구성을 위한 키-값 쌍을 입력하여 자리 표시자를 실제 값으로 바꿉니다.

    • mysql-server = true 키-값 쌍을 포함해야 합니다.
    • 다음 섹션은 예시이며 노드의 구성은 다를 수 있습니다.
    ...
[cluster "HOSTNAME"]
  hostname = HOSTNAME
  ipv4 = IPV4-ADDRESS
  # ipv6 = IPV6-ADDRESS
  consul-datacenter = PRIMARY-DATACENTER
  datacenter = DATACENTER
  mysql-server = true
  redis-server = true
  ...
...

  6. 수정된 cluster.conf를 사용하여 노드의 관리 셸에서 ghe-cluster-config-init를 실행합니다. 그러면 클러스터에서 새로 추가된 노드가 초기화됩니다.

  7. 수정된 cluster.conf를 사용하여 노드의 관리 셸에서 ghe-cluster-config-apply를 실행합니다. 새로 추가된 노드는 복제본 MySQL 노드가 되며 다른 구성된 서비스는 그곳에서 실행됩니다.

  8. MySQL 복제가 완료될 때까지 기다립니다. 클러스터의 모든 노드에서 MySQL 복제를 모니터링하려면 ghe-cluster-status -v을(를) 실행합니다.

    클러스터에 노드를 추가한 직후, 복제가 완료되는 동안 복제 상태에 대한 오류가 표시 될 수 있습니다. 복제는 인스턴스의 로드, 데이터베이스 데이터의 양 및 인스턴스가 데이터베이스 시드를 마지막으로 생성한 시간에 따라 몇 시간이 걸릴 수 있습니다.

  9. 예약된 유지 관리 기간 동안 유지 관리 모드를 사용하도록 설정합니다. 자세한 내용은 "유지 관리 모드 사용 설정 및 예약"을(를) 참조하세요.

  10. ghe-cluster-status -v을(를) 실행하여 클러스터의 모든 노드에서 MySQL 복제가 완료되었는지 확인합니다.

    경고: MySQL 복제가 완료될 때까지 기다리지 않으면 인스턴스에서 데이터가 손실될 위험이 있습니다.

  11. 현재 MySQL 기본 노드를 읽기 전용 모드로 설정하려면 인스턴스 노드에서 다음 명령을 실행합니다.

    Shell
    echo "SET GLOBAL super_read_only = 1;" | sudo mysql

  12. 기본 및 복제본 MySQL 노드에 설정된 GTID(전역 트랜잭션 식별자)가 동일해질 때까지 기다립니다. GTID를 검사하려면 인스턴스의 노드에서 다음 명령을 실행합니다.

    Shell
    ghe-cluster-each -r mysql -- 'echo "SELECT @@global.gtid_executed;" | sudo mysql'

  13. 기본 및 복제본 MySQL 노드의 GTID가 일치하면 텍스트 편집기에서 /data/user/common/cluster.conf에 있는 클러스터 구성 파일을 열어 클러스터 구성을 업데이트합니다.

    • 파일을 편집하기 전에 cluster.conf 파일의 백업을 만듭니다.
    • 최상위 [cluster] 섹션에서 mysql-master 키-값 쌍에서 대체한 노드의 호스트 이름을 제거한 다음, 대신 새 노드를 할당합니다. 새 노드가 기본 Redis 노드이기도 한 경우 redis-master 키-값 쌍을 조정합니다.
    [cluster]
  mysql-master = NEW-NODE-HOSTNAME
  redis-master = NEW-NODE-HOSTNAME
  primary-datacenter = primary
...

  14. cluster.conf를 수정한 노드의 관리 셸에서 ghe-cluster-config-apply를 실행합니다. 그러면 새로 추가된 노드가 주 MySQL 노드가 되고 원래 주 MySQL 노드가 복제본 MySQL 노드가 되도록 클러스터가 다시 구성됩니다.

  15. ghe-cluster-status -v를 실행하여 클러스터의 모든 노드에서 MySQL 복제 상태를 확인합니다.

  16. MySQL 복제가 완료되면 클러스터의 모든 노드에서 유지 관리 모드를 사용하지 않도록 설정합니다. 자세한 내용은 "유지 관리 모드 사용 설정 및 예약"을(를) 참조하세요.