고가용성을 구성하는 경우 주 어플라이언스의 모든 데이터 저장소(Git 리포지토리, MySQL, Redis, Elasticsearch)를 복제본 어플라이언스로 단방향 비동기 복제하는 자동화된 설정이 있습니다. 관리 콘솔 암호를 포함하여 대부분의 GitHub Enterprise Server 구성 설정도 복제됩니다. 자세한 내용은 관리 웹 UI에서 인스턴스 등록을(를) 참조하세요.
GitHub Enterprise Server는 활성 수동 구성을 지원하며, 복제본 어플라이언스가 대기 모드로 실행되고 데이터베이스 서비스가 복제 모드로 실행되지만 애플리케이션 서비스는 중지됩니다.
복제가 설정된 후에는 복제본 어플라이언스에서 관리 콘솔에 더 이상 액세스할 수 없습니다. 포트 8443에서 복제본의 IP 주소 또는 호스트 이름으로 이동하면 어플라이언스가 현재 복제본으로 구성되어 있음을 나타내는 “복제 모드의 서버” 메시지가 표시됩니다.
복제본 어플라이언스는 Git 클라이언트 요청을 수락하지 않으며, 이러한 요청은 활성 어플라이언스로 전달됩니다.
Note
GitHub Enterprise Server에 대해 최대 8개의 고가용성 복제본(수동 및 활성/지역 복제본 및 리포지토리 캐시 인스턴스 모두)이 허용됩니다.
대상 지정된 오류 시나리오
다음을 방지하려면 고가용성 구성을 사용합니다.
- 운영 체제 오류 또는 복구할 수 없는 애플리케이션으로 인해 소프트웨어가 충돌합니다.
- 스토리지 하드웨어, CPU, RAM, 네트워크 인터페이스 등을 포함한 하드웨어 오류
- AWS, Azure 또는 GCP의 계획되지 않은 유지 관리 이벤트 및 예약된 유지 관리 이벤트를 포함한 가상화 호스트 시스템 오류
- 장애 조치(failover) 어플라이언스가 오류의 영향을 받지 않는 별도의 네트워크에 있는 경우 논리적 또는 물리적으로 단절된 네트워크입니다.
고가용성 구성은 다음에 적합한 솔루션이 아닙니다.
- 스케일 아웃. 지역 복제를 사용하여 트래픽을 지리적으로 분산할 수 있지만 쓰기 성능은 주 어플라이언스의 속도와 가용성으로 제한됩니다. 자세한 내용은 지역 복제 정보을(를) 참조하세요.
- CI/CD 로드. 주 인스턴스와 지리적으로 멀리 떨어져 있는 CI 클라이언트가 많은 경우 리포지토리 캐시를 구성하는 것이 도움이 될 수 있습니다. 자세한 내용은 리포지토리 캐싱 정보을(를) 참조하세요.
- 주 어플라이언스 백업. 고가용성 복제본이 재해 복구 계획의 오프사이트 백업을 대체하는 것은 아닙니다. 일부 형태의 데이터 손상 또는 손실을 주 어플라이언스에서 복제본으로 즉시 복제할 수 있습니다. 안정적인 과거 상태로 안전하게 롤백하려면 기록 스냅샷을 사용하여 정기 백업을 수행해야 합니다.
- 가동 중지 시간 없는 업그레이드. 제어된 승격 시나리오에서 데이터 손실 및 분할 브레인(split-brain) 상황을 방지하려면 주 어플라이언스를 유지 관리 모드로 두고 모든 쓰기가 완료될 때까지 기다린 후 복제본을 승격합니다.
네트워크 트래픽 장애 조치(failover) 전략
장애 조치(failover) 동안 주 어플라이언스에서 복제본으로의 네트워크 트래픽 리디렉션을 별도로 구성하고 관리해야 합니다.
DNS 장애 조치(failover)
DNS 장애 조치(failover)에서는 주 GitHub Enterprise Server 어플라이언스를 가리키는 DNS 레코드에 짧은 TTL 값을 사용합니다. 60초에서 5분 사이의 TTL을 사용하는 것이 좋습니다.
장애 조치(failover) 동안 주 어플라이언스를 유지 관리 모드로 두고 해당 DNS 레코드를 복제본 어플라이언스의 IP 주소로 리디렉션해야 합니다. 트래픽을 주 어플라이언스에서 복제본으로 리디렉션하는 데 필요한 시간은 TTL 구성과 DNS 레코드를 업데이트하는 데 필요한 시간에 따라 다릅니다.
지역 복제를 사용하는 경우 트래픽을 가장 가까운 복제본으로 보내도록 지역 DNS를 구성해야 합니다. 자세한 내용은 지역 복제 정보을(를) 참조하세요.
부하 분산 장치
부하 분산 장치 디자인은 네트워크 디바이스를 사용하여 Git 및 HTTP 트래픽을 개별 GitHub Enterprise Server 어플라이언스로 전달합니다. 부하 분산 장치를 사용하여 보안 목적으로 어플라이언스로 직접 트래픽을 제한하거나 DNS 레코드 변경 없이 필요한 경우 트래픽을 리디렉션할 수 있습니다. 프록시 프로토콜을 지원하는 TCP 기반 부하 분산 장치를 사용하는 것이 좋습니다. GitHub Enterprise Server 호스트 이름에 대한 DNS 조회는 부하 분산 장치로 확인되어야 합니다. 하위 도메인 격리를 사용하도록 설정하는 것이 좋습니다. 하위 도메인 격리를 사용하도록 설정하면 추가 와일드카드 레코드(*.HOSTNAME)도 부하 분산 장치로 확인되어야 합니다. 자세한 내용은 "하위 도메인 격리 사용" 항목을 참조하세요.
장애 조치(failover) 동안 주 어플라이언스를 유지 관리 모드로 두어야 합니다. 복제본이 주 어플라이언스로 승격되었거나 수동 구성 변경이 필요한 경우 자동으로 감지하도록 부하 분산 장치를 구성할 수 있습니다. 복제본을 주 어플라이언스로 수동으로 승격해야 복제본이 사용자 트래픽에 응답합니다. 자세한 내용은 부하 분산 장치로 GitHub Enterprise Server 사용을(를) 참조하세요.
https://HOSTNAME/status URL에 대해 반환되는 상태 코드를 확인하여 GitHub Enterprise Server의 가용성을 모니터링할 수 있습니다. 사용자 트래픽을 서비스할 수 있는 어플라이언스는 상태 코드 200(확인)을 반환합니다. 어플라이언스는 몇 가지 이유로 이 URL 및 기타 웹 또는 API 요청에 대해 503(서비스를 사용할 수 없음)을 반환할 수 있습니다.
- 어플라이언스는 2노드 고가용성 구성의 복제본과 같은 수동 복제본입니다.
- 어플라이언스를 유지 관리 모드로 전환합니다.
- 어플라이언스는 지역 복제 구성의 일부이지만 비활성 복제본입니다.
다음 위치에서 사용할 수 있는 복제 개요 대시보드를 사용할 수도 있습니다.
https://HOSTNAME/setup/replication
복제 관리용 유틸리티
고가용성 구성의 인스턴스에 대한 관리 SSH 액세스 권한이 있는 사용자는 명령줄 유틸리티를 사용하여 복제본 관리할 수 있습니다. 자세한 내용은 명령줄 유틸리티을(를) 참조하세요.