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

고가용성 구성에 노드 추가

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

이 기사에서

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

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

추가 노드

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

추가 노드를 사용하면 웹 및 작업 워크로드의 크기를 수평으로 조정할 수 있습니다. 또한 메인 노드에서 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 명령은 상태 비지정 노드를 추가하기 위한 요구 사항입니다.

무상태 노드를 추가하기 위해 유지 관리 시간을 확보할 것을 권장합니다.

추가 노드 제거

추가 노드를 제거하기 전에 HA 배포의 모든 노드에 기능 릴리스에 대해 동일한 최신 패치를 설치하고 유지 관리 기간을 예약합니다. 제거를 시작하기 전에 업그레이드 또는 구성 실행이 완료되기를 기다립니다.

  1. HA 주 데이터베이스에서 HA 배포의 모든 노드 상태를 확인합니다.

    Shell
    ghe-cluster-nodes
ghe-cluster-nodes --offline
nomad node status
ghe-cluster-status --extended --verbose

    두 명령 모두 ghe-cluster-nodes 동일한 호스트 이름을 나열하고 제거하려는 노드의 호스트 이름을 포함하는지 확인합니다. 모든 노드의 Nomad 상태가 ready이고, 모든 노드에서 connect-ssh 및 enterprise-version가 ok인지 확인합니다. 주 복제본 및 모든 보조 복제본의 상태 저장 서비스가 정상인지 확인합니다. 복제본이 남아 있지 않으면 MySQL 복제본을 찾을 수 없다는 경고가 표시됩니다. 대상의 웹, 작업 또는 memcache 워크로드로 제한되는 오류는 제거를 차단하지 않습니다. 다른 노드 수준 또는 상태 저장 서비스 검사가 실패하는 경우 제거하기 전에 문의하세요 GitHub 지원 .

  2. HA 주 데이터베이스에서 추가 노드를 제거합니다. 추가 노드의 호스트 이름으로 바꿉습니다 HOSTNAME .

    Shell
    ghe-remove-node --verbose HOSTNAME

    주 노드가 아닌 다른 노드가 남아 있는 경우 명령은 대상을 드레이닝하고 HA 구성에서 제거하고 실행합니다 ghe-config-apply. 주 노드가 아닌 노드가 남아 있지 않으면 이 명령은 클러스터 메타데이터를 제거하고 실행 ghe-config-apply하지 않고 주 노드를 독립 실행형 인스턴스로 변환합니다. 두 경우 모두 별도로 실행 ghe-config-apply 하지 마세요.

  3. 제거를 확인합니다.

    주 노드가 아닌 다른 노드가 남아 있는 경우 HA 주 노드에서 다음 명령을 실행합니다. 호스트 이름이 없으며 HA 구성이 정상인지 확인합니다.

    Shell
    ghe-cluster-nodes --offline
ghe-cluster-status --extended --verbose

    주 노드가 아닌 노드가 남아 있지 않은 경우 클러스터 전용 명령을 실행하지 마세요. 제거 출력에 Cluster artifacts removed; now standalone.가 포함되어 있는지 확인한 다음, 기본 서버가 사용자 트래픽을 처리하고 웹 및 작업 워크로드를 처리하는지 확인합니다.

추가 노드가 오프라인이거나, 연결할 수 없거나, 다른 버전에 있거나, 확인 확인이 실패하는 경우 ghe-remove-node 문의하세요 GitHub 지원. 수동으로 편집 cluster.conf 하지 마세요.

이전에 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 클러스터 또는 단일 노드 번들을 생성하고 업로드할 수 있습니다.

단일 코어 softirq 포화 완화

GitHub Enterprise Server 고가용성 배포에 상태 비저장 노드를 추가하면 두 노드 간의 모든 트래픽이 단일 WireGuard 터널을 통해 전달됩니다. 해당 노드 쌍에 대한 모든 패킷이 하나의 UDP 포트를 공유하므로 네트워크 카드는 하나의 수신 큐로 조정하고 하나의 CPU 코어는 모든 인바운드 패킷을 처리합니다. 트래픽이 많을 때 코어는 100%에 도달하지만 다른 코어는 유휴 상태를 유지하고 노드는 패킷을 삭제합니다. GitHub Enterprise Server 에는 아래에 설명된 기본 제공 완화 방법이 포함되어 있습니다.

1. 더 많은 무상태 노드를 추가해 스케일 아웃

각 상태 비저장 노드는 자체 WireGuard 터널을 통해 주 노드에 도달하므로 주 노드는 별도의 수신 큐 및 CPU 코어에서 각 노드의 트래픽을 처리합니다. 더 작은 상태 비저장 노드에 워크로드를 분산하면 부하 분산 장치가 더 많은 주 코어에서 터널 간 부하를 공유할 수 있으며 이는 터널 수준 해시에 의존하지 않습니다. 두 노드는 코어당 수신 부하를 대략 절반으로 줄이고, 3개 노드는 약 3분의 1로 줄입니다.

GitHub Enterprise Server 는 메모리에서 각 노드의 웹 작업자 크기를 조정하고 자체 값을 30으로 한도로 설정합니다. 노드당 app.github.github-workers 수를 30개 정도로 유지하세요. 그보다 많으면 메모리 사용량이 늘고, 터널 정체 시 추가 작업자들이 주 작업자에서 대기하게 되어 처리량이 아니라 큐 깊이만 늘립니다. 용량을 늘리려면 상태 비저장 노드를 더 추가합니다.

2. 다중 터널 WireGuard (선택 사항)

GitHub Enterprise Server 는 여러 WireGuard 터널에 노드 간 트래픽을 분산할 수 있습니다. 각 터널은 자체 UDP 포트를 사용하므로 서로 다른 연결이 다른 수신 큐에 배치되고 다른 CPU 코어가 작업을 공유합니다. 터널 수를 클러스터 노드에서 가장 낮은 수신 큐 수, 즉 "결합된" 값 ethtool -l eth0으로 설정합니다.

Shell
ghe-config wireguard.num-tunnels 8
ghe-config-apply

기본값은 1입니다. 최대값은 16입니다. 더 높은 값은 제한됩니다. 인터페이스에 수신 큐가 있는 것보다 많은 터널은 이점을 추가하지 않습니다. 되돌리려면 설정을 제거하고 적용합니다.

Shell
ghe-config --unset wireguard.num-tunnels
ghe-config-apply

활성화하기 전에(일회성):

  • 외부 방화벽 또는 클라우드 보안 그룹에서 모든 복제본을 포함하여 모든 노드 간에 추가 터널 UDP 포트를 엽니다. 포트 수는 1194개에서 1201개까지 8개 터널에서 UDP 1194에서 1201까지 사용됩니다. 전체 범위에는 UDP 1194~1209가 필요합니다.
  • 다중 터널을 사용하도록 설정하면 호스트 방화벽이 업데이트됩니다. 모든 노드를 다시 부팅하거나 각 노드에서 방화벽 sudo ufw reload 을 다시 로드하여 한 번 적용합니다. 먼저, ufw를 다시 로드하면 규칙이 잠시 제거되었다가 다시 생성되므로 네트워크 보안 그룹이 이미 인바운드 액세스를 제한하고 있는지 확인하세요. 이후 num-tunnels 변경에는 이 단계가 필요하지 않습니다.

3. 주 데이터베이스의 로컬 git-proxy 라우팅(자동)

원래는 상태 비저장 노드가 터널을 통해 다시 보냈을 Git 요청이 이제는 Git 데이터가 이미 있는 기본 노드에 그대로 남아 있습니다. 이렇게 하면 터널 간 패킷의 큰 공유가 제거되며 아무 작업도 필요하지 않습니다. 주 데이터베이스는 먼저 로컬 Git 프록시를 사용하고 로컬 Git 프록시를 사용할 수 없는 경우에만 원격 노드로 돌아갑니다.

4. 용량 기반 웹 요청 가중치(옵트인)

노드마다 웹 워커 수가 다를 경우, GitHub Enterprise Server는 요청을 균등하게 분배하는 대신 각 노드의 워커 수에 비례하여 분배할 수 있습니다. 작업자 수가 서로 다른 경우(예: 작업자가 100명인 프라이머리 노드와 30명인 스테이트리스 노드)에 이 옵션을 사용하도록 설정합니다.

Shell
ghe-config app.github.unicorn-weight-by-capacity true
ghe-config-apply

기본값은 꺼져 있습니다.

활성화할 항목 선택

먼저 더 많은 상태 비지정 노드로 확장합니다. 가장 완벽한 옵션이며 부하 분산 장치를 통해 더 많은 기본 코어에 부하를 분산하며 기능 플래그가 필요하지 않습니다. 단일 코어가 여전히 포화된 경우 다중 터널 WireGuard를 사용하도록 설정합니다. 작업자 수가 노드 간에 다른 경우에만 용량 기반 가중치를 사용하도록 설정합니다.

알려진 제한 사항

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