Enterprise Server 3.20 은(는) 현재 릴리스 후보로 제공됩니다.

고가용성 구성에 노드 추가

주 HA(고가용성) 데이터 센터에 노드를 추가합니다. 이는 주 노드에서 CPU 집약적 작업을 오프로드하여 GitHub Enterprise Server 인스턴스의 수평적 크기 조정을 허용하기 위한 것입니다.

이 기사에서

참고

HA에 컴퓨팅 노드를 추가하는 기능은 공개 미리 보기에 있으며 변경될 수 있습니다. 미리 보기 중에 고객 성공 팀과 피드백을 공유하세요.

GitHub Enterprise Server 수평으로 크기를 조정하려는 고객은 클러스터로 마이그레이션하고 운영할 수 있지만 리소스를 많이 사용하고 시간이 많이 소요됩니다. 또는 HA 구성에 노드를 추가하는 것이 좋습니다.

"추가 노드" 및 "상태 비정상 노드"라는 용어는 이 문서 전체에서 서로 바꿔서 사용됩니다. 상태 비지정 노드는 하나 이상의 복제본을 포함하는 HA 배포에만 추가할 수 있습니다.

추가 노드

GitHub Enterprise Server 어플라이언스에서 실행되는 모든 서비스 중 Unicorn은 종종 가장 CPU와 메모리 집약적이며, 그 다음으로 Aqueduct, Git 및 MySQL이 뒤따릅니다. 유니콘과 수로는 상태 비저장 서비스이므로 수평 확장에 적합하며 별도의 노드 집합에서 실행할 수 있습니다. 나머지 서비스는 데이터 센터당 단일 인스턴스로 계속 작동할 수 있습니다.

추가 노드를 사용하면 웹 및 작업 워크로드의 크기를 수평으로 조정할 수 있습니다. 또한 메인 노드에서 Unicorn과 Aqueduct를 오프로드하여 나머지 상태 저장 서비스에 충분한 연산 리소스와 메모리 리소스를 확보할 수 있습니다. 유니콘 인스턴스의 높은 CPU 사용량으로 인해 성능 관련 중단이 발생하는 경우 추가 노드를 추가하는 것이 좋습니다. 데이터 센터 내에서 추가할 수 있는 이러한 노드의 수는 크게 제한되지 않습니다.

조건

HA 구성에서 오버로드된 주 노드로 인해 성능이 저하되는 경우 HA 환경에 노드를 추가하는 것이 좋습니다. 주 노드를 넘어 웹 및 작업 역할을 수평으로 확장하면 이러한 추가 노드를 통해 주 호스트의 부하를 줄일 수 있습니다.

예를 들어 유니콘 또는 수로 큐에서 백로그를 발견하거나 다른 유형의 리소스 경합이 발생하는 경우 이 방법을 고려해야 합니다. 표시되는 큐가 없더라도 주 노드의 CPU 부족이 또 다른 명확한 신호입니다. 이러한 경우 노드를 추가하고 노드당 작업자 수를 줄일 수 있으므로 주 노드는 전체 워크로드를 덜 처리합니다.

노드 추가

HA 배포에 추가하는 각 노드는 GitHub Enterprise Server 소프트웨어를 실행하는 VM(가상 머신)입니다. 기본 소프트웨어와 동일한 소프트웨어를 실행해야 합니다. 일반적으로 상태 없는 노드는 주 노드의 메모리, CPU 또는 스토리지 사양과 일치할 필요가 없다. 그러나 상태 비저장 노드와 주 인스턴스 모두 밀리초 미만의 연결이 필요합니다. 복제본 연결 요구 사항은 변경되지 않습니다.

HA 구성에서 기본 데이터 센터에 노드를 추가하려면 이 명령을 사용합니다 ghe-add-node . 이 ghe-add-node 명령은 현재 어플라이언스는 HA 배포 내의 노드로 설정하며, 주 데이터 노드에서 CPU 집약적 태스크를 오프로드하여 수평 크기 조정을 사용하도록 하기 위한 것입니다. 이러한 노드는 웹 및 작업 워크로드를 처리하도록 설계되어 보다 효율적인 워크로드 배포 및 관리를 지원합니다. 이 명령은 다음 형식을 사용합니다.

Shell
/usr/local/share/enterprise/ghe-add-node PRIMARY_IP [--hostname HOSTNAME]

  •         `PRIMARY_IP`: 주 노드의 IP 주소입니다.

  •         `HOSTNAME` (선택 사항): 추가된 호스트에 대해 원하는 호스트 이름입니다.

예를 들어 HA 기본 데이터 센터의 IP 주소를 ghes-node-1 사용하여 HA 주 인스턴스에 호스트 이름이 192.168.1.1 있는 노드를 추가하려면 다음 명령을 실행합니다.

Shell
/usr/local/share/enterprise/ghe-add-node 192.168.1.1 --hostname ghes-node-1

그런 다음 주 노드에서 다음 명령을 실행해야 합니다.

Shell
ghe-config-apply
ghe-cluster-balance rebalance --yes

이 ghe-config-apply 명령은 상태 비지정 노드를 추가하기 위한 요구 사항입니다.

공개 미리 보기의 경우 가동 중지 시간을 구체적으로 테스트하지 않았으며 유지 관리 기간이 필요한지 명확하지 않습니다.

추가 노드 제거

노드를 제거하려면 제거하려는 노드에서 실행 ghe-remove-node 합니다. 그런 다음 주 노드에서 다음을 실행해야 합니다.

Shell
ghe-config-apply

이 ghe-config-apply 명령은 상태 비지정 노드를 제거하기 위한 요구 사항입니다.

공개 미리 보기의 경우 가동 중지 시간을 구체적으로 테스트하지 않았으며 유지 관리 기간이 필요한지 명확하지 않습니다.

GitHub Enterprise Server를 이전에 호스팅했던 노드를 다시 프로비전하기

이전에 GitHub Enterprise Server을 호스팅하고 실행했던 노드를 상태 없는 노드로 사용할 수 있습니다. 이렇게 하려면 노드를 버전 3.18 이상으로 업데이트해야 하며 배포의 모든 노드가 동일한 버전을 실행해야 합니다. 해당 노드에서 /data/user/common/cluster.conf이(가) 이미 존재하는지 확인합니다. 이 경우 상태 비저장 노드에서 ghe-add-node 명령을 실행하기 전에 정리 작업을 수행해야 합니다.

다음은 그 예입니다.

Shell
sudo rm -f /etc/github/cluster /data/user/common/cluster.conf
sudo timeout -k4 10 systemctl stop wireguard 2>/dev/null || sudo ip link delete tun0 || true

제한 및 동작

추가할 수 있는 노드 수에는 이론적인 제한이 없습니다. 그러나 실제로 노드를 너무 많이 추가하면 문제가 발생하고 안정성 또는 성능에 영향을 줄 수 있습니다. 이때 새로 추가된 노드는 미리 정의된 작업 집합을 처리합니다. 어떤 유형의 작업이 오프로드되는지 선택할 수 없습니다. 모든 API는 추가 노드에서 처리할 수 있습니다.

Git 작업이 경로에 있는 경우 주 노드에서만 Git 작업을 처리하는 논리가 있습니다. Git 작업은 추가 노드에서 처리되지 않습니다. 예를 들어 분기 삭제는 Git 작업이며 상태 비정상 노드에서 처리되지 않습니다.

상태 비저장 노드는 Elasticsearch 워크로드를 실행하지 않지만 kafka-lite를 실행합니다.

시스템 및 네트워킹 요구 사항

일반적으로 상태 비저장 노드는 주 노드의 메모리, CPU 및 스토리지 사양과 일치할 필요가 없습니다. 시스템 요구 사항은 주 노드에서 웹 및 작업 서비스의 기존 리소스 사용량과 주 노드가 해당 워크로드를 새 노드로 완전히 오프로드할지 여부를 고려해야 합니다.

상태 비저장 노드와 주 인스턴스에는 밀리초 미만의 연결이 필요합니다. 일반적으로 기본 데이터 센터 내의 모든 노드에는 밀리초 미만의 연결이 필요합니다. 복제본 연결 요구 사항은 변경되지 않습니다.

트래픽 라우팅 및 요청 처리

기본은 트래픽을 추가 노드로 라우팅합니다. 여러 상태 비스테이션 노드의 경우 주 노드는 현재 활성 연결이 가장 적은 서버에 새 연결을 보냅니다.

추가 노드를 사용하여 HA 배포 업그레이드

다음은 업그레이드 시퀀스의 예입니다.

  • 유지 관리 기간을 시작합니다.
  • 복제본을 중지합니다.
  • 상태 비지정 노드를 병렬로 업그레이드합니다.
  • 주 노드를 업그레이드합니다.
  • 복제본을 업그레이드합니다. 재해 복구 기본 설정에 따라 병렬 또는 순차적으로 업그레이드할 수 있습니다.
  • 복제본을 시작합니다.
  • 점검 시간을 제거합니다.

추가 노드는 업그레이드 중에 추가 가동 중지 시간을 발생시키지 않아야 합니다.

장애 조치(failover) 및 재해 복구 동작

데이터가 포함되지 않으므로 추가 노드를 "분해"할 필요가 없습니다.

장애 조치(failover) 중에 복제본 노드는 원래 배포에서 제거되고 독립 실행형 노드로 변환됩니다. 상태 없는 노드는 장애 조치 후 추가 복제본이 다시 연결되는 방법과 유사하게 승격된 복제본에 다시 연결되어야 합니다.

주 노드가 작동하고 복제본을 주 노드로 승격하려는 경우 승격된 노드에 다시 추가하기 전에 명령을 사용하여 주 ghe-remove-node 노드에서 상태 비정상 노드를 제거해야 합니다.

주 노드에 연결할 수 없고 복구할 수 없는 경우 상태 비정상 노드를 원래 주 노드에서 제거하지 않고 다시 추가할 수 있습니다.

모니터링, 로그 및 지원 번들

주 노드에서 관리 콘솔 모니터링 대시보드에는 상태 비정상 노드를 포함한 모든 노드에 대한 메트릭이 표시됩니다. 상태 비지정 노드와 같은 ghe-cluster-nodes 명령 및 ghe-cluster-status 세부 정보를 포함합니다. 모든 관리 콘솔 요청은 주 노드에서 제공됩니다.

로그는 상태 비정상 노드에 로컬로 저장됩니다. 이러한 노드에서 타사 로그 관리 서비스로 내보낼 수 있습니다.

및 ghe-cluster-support-bundle 명령을 사용하여 ghe-support-bundle 클러스터 또는 단일 노드 번들을 생성하고 업로드할 수 있습니다.

알려진 제한 사항

이 기능은 모노레포용으로 설계되지 않았지만 새로운 상태가 없는 노드를 추가하면 주 노드에서 웹 및 작업 워크로드를 줄여 모노레포 작업을 간접적으로 개선할 수 있습니다. 자동 크기 조정 및 스케일 다운 기능은 없습니다.