복제본 유형 및 기능
HA 배포에 사용되는 다양한 유형의 복제본은 무엇인가요?
HA(고가용성) 배포에는 다음 세 가지 유형의 복제본이 있습니다.
-
수동 복제본
-
활성 복제본
-
캐시 복제본(리포지토리 캐시라고 함).
**수동 복제본은** 단순히 주 인스턴스의 데이터를 동기화하고 GitHub 트래픽을 처리하지 않습니다. 그러나 운영자는 필요한 경우 수동 복제본을 주 복제본으로 승격할 수 있습니다. **지역 복제본**은 **활성 복제본**의 예입니다(이러한 용어는 종종 서로 교환하여 사용됨). 활성 복제본은 주 복제본의 데이터를 동기화합니다. 활성 복제본은 GitHub 트래픽을 직접 처리하거나 주 복제본에 프록시할 수도 있습니다. **캐시 복제본은** 주 데이터베이스의 Git 및 Git LFS(대규모 파일 스토리지) 데이터를 모두 동기화합니다. 캐시 복제본은 CI 팜과 같은 읽기가 많은 시나리오를 위해 설계되었습니다. 자신의 로컬 복사본이 있는 리포지토리에 대해서만 읽기/페치/클론 작업을 허용합니다. 다른 리포지토리의 경우 오류를 반환합니다. 항상 실패 메시지와 함께 푸시 요청을 거부합니다.
모든 복제본 유형을 주 복제본으로 승격할 수 있나요?
수동 및 활성 복제본만 주 복제본으로 승격할 수 있습니다. 캐시 복제본은 주 복제본으로 승격할 수 없습니다.
단일 배포에 모든 복제본이 있을 수 있나요?
단일 배포에는 활성 복제본, 수동 복제본 및 캐시 복제본이 한 번에 모두 포함될 수 있습니다.
주 인스턴스는 복제본에서 쓰기를 대기하나요?
주 인스턴스는 복제본에서 쓰기를 기다리지 않습니다. HA 환경에서 푸시 요청은 주 복제본뿐만 아니라 모든 수동 및 활성 복제본에도 기록됩니다. 그러나 주 노드가 유일한 투표 노드이므로 주 노드에서 성공할 때 푸시가 허용되는 것으로 간주됩니다.
통신 및 네트워크 요구 사항
활성 복제본과 통신할 수 있는 엔터티는 무엇인가요?
주 인스턴스는 활성 복제본과 통신하여 데이터를 동기화하고 활성 복제본이 주 복제본에 프록시하는 모든 요청을 처리합니다. GitHub 웹, API 및 Git 트래픽(인간 및 자동화 모두에서)을 활성 복제본으로 직접 라우팅할 수 있습니다. 따라서 활성 복제본에 대한 트래픽이 실제로 연결되도록 DNS를 구성하는 것이 중요합니다.
어떤 엔터티가 수동 레플리카와 통신할 수 있나요?
주 인스턴스는 수동 복제본과 통신하여 데이터를 동기화합니다. 수동 복제본은 다른 GitHub 트래픽을 수신하거나 처리하지 않습니다.
캐시 복제본과 통신할 수 있는 엔터티는 무엇인가요?
읽기 전용 git 트래픽은 주로 CI 팜과 같은 자동화에서 캐시 복제본으로 라우팅되고 처리될 수 있습니다. 이를 사용하도록 설정하려면 관련 트래픽을 캐시 복제본으로 보내도록 DNS를 구성해야 합니다. 캐시 복제본은 사용자 트래픽을 처리하거나 트래픽을 푸시하도록 설계되지 않았습니다.
복제본을 주 복제본과 함께 배치해야 하나요?
복제본을 주 복제본과 공동 배치할 필요가 없습니다. 정의에 따라 지역 복제본은 동일한 데이터 센터에 있지 않고 주 복제본과 지리적으로 멀리 떨어져 있습니다. 캐시 복제본에는 공동 위치 요구 사항도 없습니다.
그러나 주 복제본 중단 시 장애 조치를 더 빠르게 수행하기 위해, 적어도 하나의 패시브 복제본을 동일한 데이터 센터 내의 주 복제본과 함께 두는 것이 권장됩니다. 전체 데이터 센터 가동 중단이 발생할 경우 지리적으로 분산된 수동 복제본을 활성화할 수 있습니다.
주 복제본과 복제본 간의 대기 시간 요구 사항은 무엇인가요?
주 복제본과 활성 복제본에는 엄격한 대기 시간 요구 사항이 있습니다. 주 복제본 및 수동 복제본과 주 복제본 및 캐시 복제본에는 권장되는 대기 시간 요구 사항이 있습니다. 자세한 내용은 고가용성 복제본 만들기 및 고가용성 구성 모니터링을(를) 참조하세요. 필요한 값과 권장 값을 초과하는 네트워크 대기 시간으로 인해 복제본이 지속적으로 뒤쳐질 수 있습니다.
관리 액세스 및 모니터링
복제본 환경에서도 관리 콘솔 사용이 가능한가요?
관리 콘솔은(는) 패시브 복제본 또는 캐시 복제본에서 사용할 수 없습니다. 활성 복제본에서만 사용할 수 있습니다(활성 복제본은 대부분의 요청을 주 복제본으로 전달).
복제본에 SSH할 수 있나요?
관리 셸 액세스 권한이 있는 연산자는 복제본에 SSH할 수 있습니다. 운영자는 복제본이 클러스터에 추가되기 전에 관리 콘솔를 통해 새 복제본에 공개 키를 추가할 수 있습니다. 자세한 내용은 관리 셸(SSH)에 액세스을(를) 참조하세요.
복제본에 대한 지원 번들은 어떻게 작동합니까?
클러스터 번들 또는 노드별 번들을 생성할 수 있습니다. 클러스터 번들에는 HA 배포의 모든 노드의 번들이 포함되는 반면 노드별 번들에는 하나의 노드의 데이터만 포함됩니다.
복제본을 모니터링할 수 있으며 어떻게 해야 합니까?
모든 복제본을 모니터링할 수 있습니다. 기본 인스턴스에 있는 관리 콘솔에서는 배포 환경의 모든 노드(수동 및 활성 복제본 노드 포함)에 대한 대시보드를 제공합니다.
또한 배포의 모든 노드에서 타사 모니터링 플랫폼으로 메트릭 및 로그를 내보낼 수 있습니다.
복제본 노드 간의 데이터 복제 상태를 모니터링하는 방법을 알아보려면 고가용성 구성 모니터링을 참조하세요.
복제본과 백업 간의 차이점
복제본과 백업은 동일합니까?
복제본과 백업은 동일하지 않습니다. 그들은 다른 목적을 위해 봉사합니다.
백업은 다른 GitHub Enterprise Server 환경으로 복원할 수 있는 데이터 복사본을 만드는 데 사용됩니다. 고객은 종종 백업을 사용하여 재해로부터 복구하거나 새 설치를 만듭니다. 즉, 백업 데이터는 다른 GitHub Enterprise Server 인스턴스를 복원하는 데 사용되며, 복제본은 실시간으로 고가용성과 중복성을 위해 설계되어 있습니다.
복제본 자체는 GitHub Enterprise Server 인스턴스와 같습니다. Backup-host는 GitHub Enterprise Server 설치가 아닙니다.
복제본에서 실행 중인 소프트웨어는 무엇인가요?
복제본은 GitHub Enterprise Server에 별도로 설치해야 합니다. 주 인스턴스와 모든 복제본은 GitHub Enterprise Server의 버전이 동일해야 합니다.
유지 관리 작업
업그레이드에 권장되는 작업 시퀀스는 무엇인가요?
- 주 서버 및 모든 복제본에서 유지 관리 작업을 시작합니다.
- 모든 복제본에서 복제를 중지합니다.
- 주 버전을 대상 버전으로 업그레이드합니다.
- 복제본을 동일한 대상 버전으로 업그레이드합니다. 모든 복제본을 병렬로 업그레이드할 수 있습니다.
- 모든 업그레이드가 완료되면 복제 프로세스를 다시 시작합니다.
- 유지 관리 기간을 닫습니다.
때때로 고객은 복제본 업그레이드를 나중에 연기할 수 있습니다. 이 경우 배포에서 복제본 노드를 제거하고 독립 실행형 노드로 변환합니다. 기본 버전과 동일한 버전으로 업그레이드한 다음 배포에 다시 추가합니다.
핫패치에 권장되는 작업 시퀀스는 무엇인가요?
중단을 최소화하여 핫패칭을 수행할 수 있습니다. 먼저 주 본본을 핫패치한 후에 복제본을 핫패치할 수 있습니다.
올바른 복제본 유형 선택
수동 복제본을 사용해야 하는 경우는 언제인가요?
고가용성이 필요하고 주 인스턴스에 장애가 발생할 경우 최신 상태의 인스턴스로 장애 조치를 시도하려면 수동 복제본을 사용하는 것이 좋습니다. 대부분의 고객은 수동 복제본을 사용합니다.
지역 복제본을 사용해야 하는 경우는 언제인가요?
지리적으로 분산된 개발자 인력이 있는 경우 지역 복제본을 설정하면 특정 지역의 사용자에게 도움이 될 수 있습니다. 예를 들어 북미, 유럽 및 아시아에서 엔지니어링 팀이 있는 다국적 기업을 상상해 보십시오. 주 인스턴스가 미국에 있는 경우 유럽에 지역 복제본을 배포하면 유럽 사용자의 읽기 작업 성능이 크게 향상될 수 있습니다. 그러나 쓰기 작업에는 같은 말을 할 수 없습니다. 작업이 완료되기 전에 모든 쓰기 작업은 로컬 복제본과 주 복제본 모두에 적용되어야 합니다. 주 복제본과 복제본 간의 지리적 거리는 대기 시간을 증가하므로 쓰기 작업이 느려질 수 있습니다.
캐시 복제본을 사용해야 하는 경우는 언제인가요?
사용 사례가 CI 팜과 같이 읽기가 많은 경우 캐시 복제본이 더 적합합니다. 캐시 복제본이 적합한 몇 가지 시나리오는 다음과 같습니다.
- 주 데이터 센터에 대한 대역폭이 제한된 지역에 작은 위성 사무실이 있는 회사로, 개발자는 리포지토리에 더 빠르게 액세스해야 하지만 쓰기 액세스가 필요하지 않습니다.
- 리포지토리를 자주 복제해야 하며 주 인스턴스에 대한 네트워크 트래픽을 최소화하려는 원격 데이터 센터에서 CI/CD 작업을 실행하는 조직입니다.
설계상, 캐시 복제본은 절충점을 가지고 있습니다. 캐시 복제본은 최종적으로 일관되며 항상 최신 리포지토리 콘텐츠를 제공하지는 않습니다. 그러나 최신 변경 내용이 복제본에 있는 경우 관련 CI/CD 작업을 시작할 수 있도록 웹후크가 있습니다. GitHub 고객이 캐시 복제본을 사용하는 경우는 거의 없습니다.