클러스터 노드 바꾸기

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

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

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

이 문서의 내용

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

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

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

Warning

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

기능 노드 바꾸기

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

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

Note

기본 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. 교체할 노드를 오프라인으로 설정하려면 클러스터의 기본 MySQL 노드에서 다음 명령을 실행합니다.

    ghe-remove-node NODE-HOSTNAME

    이 명령을 실행하면 노드에서 실행 중인 모든 데이터 서비스에서 데이터를 이동하고, 해당 노드를 구성에서 오프라인으로 표시하며 트래픽이 해당 노드로 라우팅되지 않게 중지시킵니다. 자세한 내용은 명령줄 유틸리티을(를) 참조하세요.

응급 상황에서 노드 바꾸기

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

Note

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

응급 상황에서 노드를 교체하려면 실패한 노드를 오프라인으로 설정하고, 클러스터에 교체 노드를 추가한 다음, 명령을 실행해 제거된 노드의 데이터 서비스에 대한 참조를 제거합니다.

  1. 클러스터에서 문제가 발생 중인 노드를 제거하려면, 클러스터의 기본 MySQL 노드에서 다음 명령을 실행합니다. 여기에서 NODE-HOSTNAME을 오프라인으로 전환하려는 노드의 호스트 이름으로 교체합니다.

    ghe-remove-node --no-evacuate NODE-HOSTNAME

    이 명령을 실행하면 해당 노드를 구성에서 오프라인으로 표시하고, 트래픽이 해당 노드로 라우팅되지 않게 중지시킵니다. 이제 이 명령을 no-evacuate 모드에서 실행할 수 있습니다. 이 절차 후반에 노드의 데이터 서비스에 모든 복제본을 클러스터상의 다른 이용 가능한 노드로 복사하라고 지시하는 명령을 실행하게 되기 때문입니다. 자세한 내용은 명령줄 유틸리티을(를) 참조하세요.

  2. 교체 노드를 클러스터에 추가합니다.

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

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

    1. 새로 프로비저닝된 노드를 추가하려면 아무 노드에서나 cluster.conf 파일을 수정하여 교체 노드를 추가하면 됩니다. 예를 들어 이 수정된 cluster.conf 파일은 새로 프로비저닝된 노드 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
  git-server = true
  pages-server = true
  mysql-server = true
  elasticsearch-server = true
  redis-server = true
  memcache-server = true
  metrics-server = true
  storage-server = true

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

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

  5. 제거한 노드의 데이터 서비스에 대한 참조를 제거합니다.

    1. 제거한 노드의 UUID를 찾습니다. UUID를 찾으려면 다음 명령을 실행하여 HOSTNAME을(를) 해당 노드의 호스트 이름으로 교체합니다. 이 UUID를 다음 단계에서 사용하게 됩니다.

      ghe-config cluster.HOSTNAME.uuid

    2. 데이터 서비스에 대한 참조를 제거하려면 다음 명령을 실행합니다. UUID을(를) 노드의 UUID로 바꿉니다.

      이러한 명령은 노드의 각 서비스가 영구적으로 제거된다는 의미입니다. 서비스가 해당 노드에 포함된 모든 복제본을 클러스터 내 이용 가능한 노드에서 재생성합니다.

      Note

      이러한 명령 때문에 데이터가 복제본 전체에서 리밸런스되는 동안 서버에서 부하가 증가할 수 있습니다.

      git-server 서비스의 경우(리포지토리 데이터에 사용):

      ghe-spokesctl server destroy git-server-UUID

      pages-server 서비스의 경우(GitHub Pages 사이트 빌드에 사용):

      ghe-dpages remove pages-server-UUID

      storage-server 서비스의 경우(Git LFS 데이터, 아바타 이미지, 파일 첨부파일 및 릴리스 아카이브에 사용):

      ghe-storage destroy-host storage-server-UUID --force

  6. 아니면, cluster.conf 파일에서 제거된 노드에 대한 항목을 삭제해도 됩니다. 이렇게 하면 cluster.conf 파일을 구성된 상태로 유지하고, 향후 config-apply 실행 시 시간이 절약됩니다.

    1. 파일에서 항목을 제거하려면 다음 명령을 실행하고, HOSTNAME을(를) 제거된 노드의 호스트 이름으로 교체합니다.

      ghe-config --remove-section "cluster.HOSTNAME"

    2. 구성을 클러스터의 다른 노드로 복사하려면 cluster.conf을(를) 수정한 노드의 관리 셸에서 ghe-cluster-config-apply을(를) 실행합니다.

기본 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 복제가 완료되었는지 확인합니다.

    Warning

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