클러스터링 구성

GitHub Enterprise Server의 클러스터 토폴로지에서는 수만 명의 개발자가 있는 환경에 수평적 크기 조정을 제공합니다.

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

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

GitHub Enterprise Server에 대한 클러스터 토폴로지는 다른 토폴로지에서 리소스 소모가 발생하는 수만 명의 사용자를 지원하도록 설계되었습니다. 클러스터에서 인스턴스의 서비스는 여러 노드에 걸쳐 수평으로 확장됩니다.

GitHub Enterprise Server 인스턴스를 구성하는 VM(가상 머신)에 대한 배포 토폴로지 간의 차이점에 대해 알아봅니다.

GitHub Enterprise Server 클러스터에서 노드는 인스턴스를 구성하는 GitHub Enterprise Server 소프트웨어를 실행하는 개별 VM(가상 머신)입니다. 각 노드는 일련의 서비스를 실행합니다.

GitHub Enterprise Server 클러스터에는 DNS 이름 확인, 부하 분산 및 노드 간 통신이 필요합니다.

GitHub Enterprise Server 클러스터는 라이선스를 사용하여 설정하고 SSH(관리 셸)를 사용하여 초기화해야 합니다.

데이터베이스 시드를 연기하도록 선택하여 클러스터에 새 MySQL 복제본(replica) 노드를 추가하는 프로세스의 진행 속도를 높일 수 있습니다.

GitHub Enterprise Server 클러스터를 최신 릴리스로 업그레이드하려면 관리 셸(SSH)을 사용합니다.

GitHub Enterprise Server 클러스터의 성능 및 이중화를 확인하기 위해 클러스터의 상태를 모니터링할 수 있습니다.

GitHub Enterprise Server 클러스터의 노드가 Node Eligibility Service을(를) 사용함으로써 문제를 일으킬 만큼 오랫동안 오프라인 상태였던 경우를 모니터링할 수 있습니다.

GitHub Enterprise Server 클러스터가 클러스터 노드의 워크로드에 대한 작업 할당을 균등하게 분산하도록 강제할 수 있습니다.

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

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

GitHub Enterprise Server 클러스터가 실패하면 복제본에 대한 장애 조치(failover)를 할 수 있습니다.