활성 복제본이 여러 개이면 가장 가까운 복제본까지 거리가 더 짧아질 수 있습니다. 예를 들어 샌프란시스코, 뉴욕 및 런던에 지사가 있는 조직은 뉴욕 근처의 데이터 센터에서 기본 어플라이언스를 실행하고 샌프란시스코와 런던 근처의 데이터 센터에서 두 개의 복제본을 실행할 수 있습니다. 지리적 위치 인식 DNS를 사용하여 사용자는 사용 가능한 가장 가까운 서버에 연결하고 리포지토리 데이터에 더 빠르게 액세스할 수 있습니다. 런던까지의 대기 시간이 더 긴 샌프란시스코 근처의 어플라이언스를 기본으로 지정하는 것에 비해 뉴욕 근처의 어플라이언스를 기본으로 지정하면 호스트 간의 대기 시간을 줄이는 데 도움이 됩니다.
활성 복제본 프록시는 기본 인스턴스로 자체적으로 처리할 수 없도록 요청합니다. 복제본은 모든 SSL 연결을 종료하는 현재 상태 지점으로 작동합니다. 호스트 간의 트래픽은 지역 복제 없이 2개 노드 고가용성 구성과 유사하게 암호화된 VPN 연결을 통해 전송됩니다.
Git 요청 및 특정 파일 서버 요청(예: LFS 및 파일 업로드)은 기본에서 데이터를 로드하지 않고 복제본에서 직접 처리할 수 있습니다. 웹 요청은 항상 기본으로 라우팅되지만, 복제본이 사용자에게 더 가까이 있으면 SSL 종료가 가까워서 요청이 더 빠르게 처리됩니다.
지역 복제가 원활하게 작동하려면 Amazon의 Route 53 서비스와 같은 지리적 DNS가 필요합니다. 인스턴스의 호스트 이름은 사용자의 위치와 가장 가까운 복제본으로 확인되어야 합니다.
제한 사항
복제본으로 요청을 쓰려면 기본 및 모든 복제본으로 데이터를 보내야 합니다. 즉, 새 지역 복제본은 기본이 아닌 기존 공동 배치 지역 복제본에서 대다수의 데이터를 시드할 수 있지만 모든 쓰기 성능은 가장 느린 복제본에 의해 제한됩니다.
주 노드와 복제본(replica) 노드 사이 대기 시간은 70밀리초 미만이어야 합니다. 노드의 네트워크 사이에 방화벽을 구성하지 않는 것이 좋습니다. 쓰기 처리량에 영향을 주지 않고 분산된 팀 및 대규모 CI 팜으로 인한 대기 시간 및 대역폭을 줄이려면 리포지토리 캐싱을 대신 구성할 수 있습니다. 자세한 내용은 "리포지토리 캐싱 정보"을(를) 참조하세요.
지역 복제는 GitHub Enterprise Server 인스턴스에 용량을 추가하거나 CPU 또는 메모리 리소스 부족과 관련된 성능 문제를 해결하지 않습니다. 기본 어플라이언스가 오프라인 상태이면 활성 복제본이 읽기 또는 쓰기 요청을 처리할 수 없습니다.
Note
GitHub Enterprise Server에 대해 최대 8개의 고가용성 복제본(수동 및 활성/지역 복제본 및 리포지토리 캐시 인스턴스 모두)이 허용됩니다.
지역 복제 구성 모니터링
https://HOSTNAME/status URL에 대해 반환되는 상태 코드를 확인하여 GitHub Enterprise Server의 가용성을 모니터링할 수 있습니다. 사용자 트래픽을 서비스할 수 있는 어플라이언스는 상태 코드 200(확인)을 반환합니다. 어플라이언스는 몇 가지 이유로 이 URL 및 기타 웹 또는 API 요청에 대해 503(서비스를 사용할 수 없음)을 반환할 수 있습니다.
- 어플라이언스는 2노드 고가용성 구성의 복제본과 같은 수동 복제본입니다.
- 어플라이언스를 유지 관리 모드로 전환합니다.
- 어플라이언스는 지역 복제 구성의 일부이지만 비활성 복제본입니다.
다음 위치에서 사용할 수 있는 복제 개요 대시보드를 사용할 수도 있습니다.
https://HOSTNAME/setup/replication