고가용성에 대한 가시성 정보
재해 복구 및 백업 보완 계획을 지원하거나 지리적으로 분산된 사용자의 네트워크 및 쓰기 성능을 개선하려는 경우 GitHub Enterprise Server 인스턴스을(를) 위한 고가용성을 구성할 수 있습니다. 자세한 내용은 고가용성 구성 정보을(를) 참조하세요.
고가용성을 구성한 후에는 복제의 전반적인 상태와 각 인스턴스의 복제본 노드 상태를 모니터링하여 이중화를 사전에 보장할 수 있습니다. 인스턴스, 개요 대시보드, 인스턴스의 REST API 또는 Nagios와 같은 원격 모니터링 시스템에서 명령줄 유틸리티를 사용할 수 있습니다.
고가용성을 통해 인스턴스에서 여러 가지 방법을 사용하여 주 노드와 복제본 노드 간에 데이터를 복제할 수 있습니다. MySQL과 같은 원시 복제 메커니즘을 지원하는 데이터베이스 서비스는 서비스의 원시 메커니즘을 사용하여 복제합니다. Git 리포지토리와 같은 다른 서비스는 GitHub Enterprise Server용으로 개발된 사용자 지정 메커니즘을 사용하거나 rsync와 같은 플랫폼 도구를 사용하여 복제합니다.
인스턴스에서 복제 모니터링
GitHub Enterprise Server 인스턴스에 대한 기존 복제본 노드의 복제 상태를 모니터링하려면 노드의 SSH(관리 콘솔)에 연결하고 ghe-repl-status 명령줄 유틸리티를 실행합니다. 자세한 내용은 명령줄 유틸리티을(를) 참조하세요.
인스턴스의 개요 대시보드에서 복제 상태를 모니터링할 수도 있습니다. 브라우저에서 HOSTNAME을 인스턴스의 호스트 이름으로 바꿔 다음 URL로 이동합니다.
http(s)://HOSTNAME/setup/replication
REST API를 사용하여 복제 모니터링
REST API를 사용하여 인스턴스에서 복제 상태를 모니터링할 수 있습니다. 자세한 내용은 REST API 설명서에서 GitHub Enterprise Server 관리를 참조하세요.
원격 시스템에서 복제 모니터링
ghe-repl-status 명령줄 유틸리티의 출력은 Nagios의 check_by_ssh 플러그 인에 대한 기대 수준을 준수합니다. 자세한 내용은 명령줄 유틸리티을(를) 참조하세요.
또한 요청에서 반환한 상태 코드를 다음 URL로 구문 분석하여 인스턴스의 가용성을 모니터링할 수도 있습니다. 예를 들어 장애 조치(failover) 전략의 일부로 부하 분산 장치를 배포하는 경우 이 출력을 구문 분석하는 상태 검사를 구성할 수 있습니다. 자세한 내용은 부하 분산 장치로 GitHub Enterprise Server 사용을(를) 참조하세요.
모니터링을 구성하는 위치 및 방법에 따라 HOST를 인스턴스의 호스트 이름 또는 개별 노드의 IP 주소로 바꿉니다.
http(s)://HOST/status
사용자 요청에 응답할 수 있는 지역에서 복제에 대한 활성 노드는 상태 코드 200(정상)을 반환합니다. 개별 노드 또는 인스턴스의 호스트 이름에 대한 요청은 다음과 같은 이유로 503(서비스를 사용할 수 없음) 오류를 반환할 수 있습니다.
- 개별 노드는 2노드 고가용성 구성의 복제본 노드와 같은 수동 복제본입니다.
- 개별 노드는 지역에서 복제 구성의 일부이지만 수동 복제본 노드입니다.
- 인스턴스는 유지 관리 모드 상태입니다. 자세한 내용은 유지 관리 모드 사용 설정 및 예약을(를) 참조하세요.
지역에서 복제에 대한 자세한 내용은 지역 복제 정보을(를) 참조하세요.
복제 이슈 해결
인스턴스의 복제 문제를 해결하려면 복제가 실행 중이고 노드가 네트워크를 통해 서로 통신할 수 있는지 확인합니다. 명령줄 유틸리티를 사용하여 과소 복제를 조사할 수도 있습니다.
복제가 실행되고 있지 않은 경우
각 노드에서 ghe-repl-start 명령줄 유틸리티를 사용하여 복제를 시작해야 합니다. 복제가 실행되고 있지 않으면 SSH를 사용하여 영향을 받는 노드에 연결한 다음 ghe-repl-start를 실행합니다. 자세한 내용은 명령줄 유틸리티을(를) 참조하세요.
노드 간 통신 문제
복제를 수행하려면 기본 노드와 모든 복제본 노드가 네트워크를 통해 서로 통신할 수 있어야 합니다. 모든 인스턴스 노드 간의 양방향 통신을 위해, 최소한 포트 122/TCP 및 1194/UDP가 열려 있는지 확인합니다. 자세한 내용은 네트워크 포트을(를) 참조하세요.
주 노드와 복제본(replica) 노드 사이 대기 시간은 70밀리초 미만이어야 합니다. 노드의 네트워크 사이에 방화벽을 구성하지 않는 것이 좋습니다. ping 또는 다른 네트워크 관리 유틸리티를 사용하여 노드 간의 네트워크 연결을 테스트할 수 있습니다.
과소 복제
복제본 노드에서 ghe-repl-status 명령줄 유틸리티를 실행하고 Git 리포지토리, 리포지토리 네트워크 또는 스토리지 개체가 과소 복제된 경우 하나 이상의 복제본 노드가 기본 노드와 완전히 동기화되지 않습니다. 기본 노드가 복제본 노드와 통신할 수 없거나 복제본 노드가 기본 노드와 통신할 수 없는 경우 과소 복제가 발생할 수 있습니다.
최근에 고가용성 또는 지역에서 복제를 구성한 경우 초기 동기화에 다소 시간이 소요됩니다. 초기 동기화 시간은 존재하는 데이터의 양과 네트워크 조건에 따라 달라집니다.
과소 복제된 리포지토리 또는 리포지토리 네트워크
노드에 연결하고, OWNER를 리포지토리의 소유자로 바꾸고 REPOSITORY를 리포지토리 이름으로 바꿔 다음 명령을 실행하면 특정 리포지토리의 복제 상태 볼 수 있습니다.
ghe-spokesctl check OWNER/REPOSITORY
ghe-spokesctl info OWNER/REPOSITORY
또는 리포지토리 네트워크의 복제를 상태 보려면 NETWORK-ID/REPOSITORY-ID를 네트워크 ID 및 리포지토리 ID 번호로 바꿉니다.
ghe-spokesctl check NETWORK-ID/REPOSITORY-ID
ghe-spokesctl info NETWORK-ID/REPOSITORY-ID
과소 복제된 저장소 개체
노드에 연결하고, OID를 개체의 ID로 바꿔 다음 명령을 실행하면 특정 스토리지 개체의 상태를 볼 수 있습니다.
ghe-storage info OID
GitHub에서 지원받기
복제에 대한 문제 해결 팁을 검토했지만 인스턴스에서 문제가 계속 발생하는 경우 다음 정보를 수집한 다음 GitHub Enterprise 지원을(를) 방문하여 문의하세요.
- 영향을 받는 각 노드에서
ghe-repl-status -vv를 실행한 다음 출력을 티켓에 복사합니다. 자세한 내용은 명령줄 유틸리티을(를) 참조하세요. - 영향을 받는 각 노드에서 티켓에 첨부할 지원 번들을 만듭니다. 자세한 내용은 GitHub 지원에 데이터 제공을(를) 참조하세요.