Elasticsearch 클러스터 간 복제에 대하여
GitHub Enterprise Server는 Elasticsearch를 사용하여 이슈, 끌어오기 요청, 리포지토리, 프로젝트 및 릴리스 페이지 전반의 검색과 웹 인터페이스 전체에 표시되는 개수를 지원합니다. 검색은 제품의 중심이므로 Elasticsearch의 안정성은 인스턴스의 일상적인 관리에 직접적인 영향을 줍니다.
HA(고가용성) 구성 GitHub Enterprise Server 에서 리더/팔로워 모델을 사용합니다. 주 어플라이언스는 모든 쓰기 및 트래픽을 수신하고 복제본 어플라이언스는 주 어플라이언스가 실패할 경우 인수할 수 있는 읽기 전용 대기로 동기화 상태를 유지합니다. 자세한 내용은 고가용성 구성 정보을(를) 참조하세요.
이전 릴리스에서 Elasticsearch는 이 리더/팔로워 모델을 직접 지원하지 않았습니다. 검색 데이터를 GitHub Enterprise Server 복제하려면 주 및 복제본 어플라이언스에 걸쳐 있는 단일 Elasticsearch 클러스터를 실행했습니다. 이 방식은 효과가 있었지만, 새로운 유형의 문제가 있었습니다. Elasticsearch가 쓰기 수신과 유효성 검사를 담당하는 프라이머리 샤드를 레플리카 어플라이언스로 옮길 수 있었기 때문입니다. 그 복제본을 이후 유지 관리를 위해 오프라인으로 전환하면 인스턴스가 교착 상태에 빠질 수 있습니다. 복제본은 Elasticsearch가 정상 상태가 되기를 기다렸지만, Elasticsearch는 복제본이 클러스터에 다시 참여하기 전까지 정상 상태가 될 수 없었기 때문입니다.
Elasticsearch CCR(클러스터 간 복제)은 이 종속성을 제거합니다. 각 어플라이언스에 걸쳐 있는 하나의 클러스터 대신 각 어플라이언스는 독립적인 단일 노드 Elasticsearch 클러스터로 실행됩니다. 그런 다음 CCR은 기본적으로 지원되는 리더/팔로워 패턴을 사용하여 이러한 클러스터 간에 인덱스 데이터를 복제합니다. 데이터는 기본 Lucene 세그먼트에 영구적으로 유지된 후에만 복사되므로 복제본은 항상 안전하게 작성된 데이터를 따릅니다. 결과적으로 중요한 주 분할된 데이터베이스가 더 이상 읽기 전용 복제본에 고립되는 일은 없습니다.
Benefits
- 잠긴 업그레이드 및 유지 관리 기간이 줄어듭니다. 유지 관리 중에 주 어플라이언스와 복제본 어플라이언스 간의 순환 종속성을 제거하면 인스턴스가 중단될 위험이 줄어듭니다.
- 더 강력한 데이터 보호. 데이터는 지속적으로 저장된 후에만 복제되므로 장애 조치(failover) 중에 인덱스 손상을 방지할 수 있습니다.
- 더 간단한 작업. 이 패턴은 유지 관리 단계가 순서를 벗어나 수행될 때 이전에 발생했던 인덱스를 수동으로 복구해야 하는 필요성을 줄입니다.
Availability
Elasticsearch CCR은 3.19.1부터 GitHub Enterprise Server 지원됩니다. 이 기능은 선택 사항입니다. GitHub 에서는 CCR을 다음 2년 동안 기본 HA 검색 아키텍처로 만들 계획이므로 기본값이 되기 전에 이를 테스트하고 피드백을 제공할 시간이 있습니다.
Requirements
CCR을 사용하도록 설정하기 전에 다음을 확인합니다.
- 인스턴스는 GitHub Enterprise Server 3.19.1 이상에서 실행됩니다.
- 인스턴스는 둘 이상의 어플라이언스(주 복제본 및 하나 이상의 복제본)를 사용하여 고가용성을 위해 구성됩니다.
- CCR에 필요한 Elasticsearch 사용 권한이 포함된 업데이트된 GitHub Enterprise Server 라이선스를 보유하고 있습니다. 새 라이선스를 사용하도록 엔터프라이즈를 활성화하려면 GitHub의 영업 팀 또는 GitHub 지원에 문의한 다음, 업데이트된 라이선스 파일을 다운로드하세요.
경고: CCR을 사용하도록 설정하면 업그레이드 전 검사에 유효한 CCR 사용 라이선스가 필요합니다. 플래그를 사용하도록 설정하고 라이선스 검사가 실패하면 업그레이드가 진행되지 않습니다. 기능 또는 업그레이드를 사용하도록 설정하기 전에 업데이트된 라이선스가 설치되어 있는지 확인합니다. 라이선스에 Elasticsearch 자격이 포함되어 있는지 확실하지 않은 경우 문의하세요 GitHub 지원.
Elasticsearch 클러스터 간 복제 활성화
참고: 복제를 다시 시작하기 전에 검색 데이터가 주 데이터베이스에 통합되기 때문에 마이그레이션에는 인스턴스 크기에 따라 상당한 시간이 걸릴 수 있습니다. 유지 관리 기간 동안 CCR을 사용하도록 설정하고 비프로덕션 환경에서 프로세스를 먼저 테스트하도록 계획합니다. 자세한 내용은 인스턴스 업그레이드을(를) 참조하세요.
-
GitHub 지원에 연락하여 새 HA 검색 아키텍처에 대한 액세스 권한을 요청하세요. GitHub를 통해 귀사에 권한을 부여하여 귀사에서 필요한 CCR 지원 라이선스를 다운로드할 수 있습니다.
-
업데이트된 라이선스를 다운로드하여 인스턴스에 업로드합니다. 자세한 내용은 GitHub Enterprise용 라이선스 다운로드을(를) 참조하세요.
-
기본 어플라이언스에서 기능을 사용하도록 설정합니다.
ghe-config app.elasticsearch.ccr true -
구성 실행을 실행하거나 인스턴스를 3.19.1 이상으로 업그레이드하여 구성을 적용합니다.
ghe-config-apply -
인스턴스가 다시 시작되면 Elasticsearch는 설치를 새 복제 방법으로 마이그레이션합니다. 이 마이그레이션은 검색 데이터를 주 데이터베이스에 통합하고, 이전에 어플라이언스에 걸쳐 있는 클러스터를 종료하고, CCR을 사용하여 복제를 다시 시작합니다. 마이그레이션하는 동안 GitHub Enterprise Server은(는) 기존 검색 인덱스에 팔로워를 연결하고, 향후 생성되는 모든 인덱스가 자동으로 팔로우되도록 자동 팔로우 규칙을 활성화합니다.
Elasticsearch 클러스터 간 복제 사용
복제 확인
마이그레이션이 완료되면 검색이 정상적으로 계속 작동하며 사용자가 검색하는 방법에는 변경이 필요하지 않습니다. 복제 상태를 확인하려면 검토용 CCR 상태 정보가 포함된 지원 번들을 생성하세요. 자세한 내용은 GitHub 지원에 데이터 제공을(를) 참조하세요.
장애 조치 및 재해 복구
표준 고가용성 복제 유틸리티를 계속 사용하여 복제본을 관리하고 장애 조치합니다. 자세한 내용은 복제본 어플라이언스로 장애 조치(failover) 시작 및 고가용성 구성 복구을(를) 참조하세요.
CCR이 활성화된 상태에서 장애 조치가 발생한 후, 승격된 어플라이언스는 검색을 위한 새로운 리더가 되며 복제본은 표준 복구 과정의 일부로 해당 인덱스를 다시 팔로우합니다. 장애 조치 도중 또는 이후에 검색 복제와 관련된 오류가 발생하면 GitHub 지원에 문의하세요.
Elasticsearch 클러스터 간 복제 사용 안 함
경고: 의 지침 GitHub 지원없이 프로덕션 인스턴스에서 CCR을 사용하지 않도록 설정하지 마세요. CCR을 사용하지 않도록 설정하는 것은 일상적인 셀프 서비스 작업이 아닙니다. 기능을 해제하면 이전 모드로의 반환의 일부로 복제본 Elasticsearch 데이터 제거가 트리거됩니다.
이전 검색 아키텍처로 돌아가야 하는 경우 변경하기 전에 문의 GitHub 지원 하세요. GitHub 는 라이선스, 복제 상태 및 업그레이드 경로가 안전하게 처리되는지 확인하는 데 도움이 됩니다.
추가 읽기
- 고가용성 구성 정보
- 명령줄 유틸리티
- GitHub Enterprise Server에서 고가용성을 위한 검색 아키텍처를 다시 빌드하는 방법the GitHub Blog