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