GitHub Enterprise Server에 대한 배포 토폴로지 정보
환경 및 사용자 요구에 따라 다른 토폴로지에서 GitHub Enterprise Server instance 대한 가상 머신을 배포할 수 있습니다.
-
재해 복구 및 백업 보완 계획을 지원하거나 지리적으로 분산된 사용자의 네트워크 및 쓰기 성능을 향상시키려면 고가용성을 구성할 수 있습니다. 고가용성 구성에서 하나의 노드는 주 노드 역할을 하고 다른 노드는 복제본 역할을 합니다.
-
수만 명의 개발자가 있는 환경에 수평 크기 조정을 제공하기 위해 클러스터 토폴로지를 사용할 수 있습니다. 클러스터링에서는 단일 주 노드가 정기적으로 리소스 소모를 경험하는 상황을 해결합니다. 이 구성에는 신중한 계획과 추가 관리 오버헤드가 필요합니다. GitHub은(는) 사용자와 협력하여 클러스터링 자격을 결정합니다.
오류 시나리오
HA(고가용성) 및 클러스터링 모두 단일 노드를 실패 지점으로 제거하여 중복성을 제공합니다. 다음 시나리오에서 가용성을 제공할 수 있습니다.
- 운영 체제 오류 또는 복구할 수 없는 애플리케이션으로 인해 소프트웨어가 충돌합니다.
- 스토리지 하드웨어, CPU, RAM, 네트워크 인터페이스 등을 포함한 하드웨어 오류
- AWS, Azure 또는 GCP에 대한 계획되지 않은 유지 관리 이벤트 및 예약된 유지 관리 이벤트를 포함하여 가상화 호스트 시스템 오류
- 장애 조치(failover) 어플라이언스가 오류의 영향을 받지 않는 별도의 네트워크에 있는 경우 논리적 또는 물리적으로 단절된 네트워크입니다.
확장성
클러스터링을 사용하면 여러 노드에 부하를 분산하여 스케일링 성능을 향상할 수 있습니다. 이 수평 스케일링은 수만 명의 개발자가 있는 조직에 더 적합할 수 있습니다. HA에서는 어플라이언스 규모가 주 노드에만 종속되고 부하가 복제본 서버에 배포되지 않습니다.
장애 조치(failover) 메서드 및 구성 차이점
기능 | 장애 조치(failover) 구성 | 장애 조치 메서드 |
---|---|---|
고가용성 구성 | TTL이 낮은 DNS 레코드가 주 어플라이언스 또는 부하 분산 장치를 가리켰습니다. | DNS 장애 조치(failover) 및 부하 분산 장치 구성에서 모두 복제본 어플라이언스를 수동으로 승격해야 합니다. |
Clustering | DNS 레코드가 부하 분산 장치를 가리켜야 합니다. | 부하 분산 장치 뒤에 있는 노드에서 오류가 발생하면 트래픽이 작동 중인 다른 노드로 자동으로 전송됩니다. |
백업 및 재해 복구
HA와 클러스터링 일반 백업의 대체 항목으로 간주해서는 안 됩니다. 자세한 내용은 "어플라이언스에 백업 구성"을 참조하세요.
모니터링
가용성 기능, 특히 클러스터링 같은 자동 장애 조치(failover)가 있는 기능은 일반적으로 오류가 발생할 때 서비스가 중단되지 않으므로 오류를 마스킹할 수 있습니다. HA를 사용하든 클러스터링 사용하든 관계없이 각 instance 상태를 모니터링하는 것이 중요하므로 오류가 발생할 때 알 수 있습니다. 모니터링에 대한 자세한 내용은 "권장되는 경고 임계값" 및 "클러스터 노드 모니터링"을 참조하세요.